Zoals eerder vermeld, worden opties die bij IPv4 achteraan in de header verscholen waren, bij IPv6 is verschillende "extension"-headers gestoken. De bedoeling van het opdelen in verschillende headers is het minimaliseren van de informatie die verwerkt moet worden om een IP-pakket ter beschikking te krijgen. In tegenstelling tot de IPv6-header, zijn de extension headers onbeperkt in lengte.
+---------------+------------------------ | IPv6 header | TCP header + data | | | Next Header = | | TCP | +---------------+------------------------ +---------------+----------------+------------------------ | IPv6 header | Routing header | TCP header + data | | | | Next Header = | Next Header = | | Routing | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv6 header | Routing header | Fragment header | fragment of TCP | | | | header + data | Next Header = | Next Header = | Next Header = | | Routing | Fragment | TCP | +---------------+----------------+-----------------+-----------------
Wanneer er van verschillende extension-headers gebruik wordt gemaakt, dan moeten deze volgens een vaste volgorde geplaatst worden:
Zoals de naam het zegt, moet de Hop-by-Hop header door elke node op het pad tussen begin- en eindstation gelezen worden. Deze header is voornamelijk handig voor het overbrengen van managment-informatie (SNMP) of het debuggen van routers.
Verder zijn er twee Destination headers: de eerste header is bestemd voor de eerste node in het pad, de laatste voor het eindstation. De eerste header wordt mogelijkerwijs ook gelezen door andere nodes, die aangegeven zijn in de Source Routing Header.De Source Routing header biedt de zender de mogelijkheid om te specifiëren langs welke nodes het pakket moet verzonden worden. Deze mogelijkheid bestond ook al in IPv4, maar werd vrijwel nooit gebruikt omdat er serieuze veiligheidsrisico's aan vast hingen: een antwoord op een Source Routed-pakket moest langs dezelfde route teruggestuurd worden. Het is echter niet zeker of de Source Node inderdaad diegene is die het pakket verstuurd had. M.a.w. het was perfect mogelijk door het sturen van een Source Routing-optie alle antwoorden te onderscheppen: men weet toch langs waar het antwoord zal terugkomen. IPv6 laat de eis dat het antwoord dezelfde weg terug moet volgen, vallen.
De fragmentation header dient om grotere datapakketten dan de MTU (Maximum Transmission Unit) door te sturen. Zoals eerder vermeld, voorziet IPv6 niet meer in fragmentatie tijdens transmissie, maar moet de zender zelf de MTU bepalen (MTU Discovery) en in fragmentatie voorzien indien het te versturen pakket de maximale grootte overschrijdt. De fragmentatie-header bevat een veld dat de volgorde van het verstuurde fragment binnen het totale pakket omschrijft.
MTU discovery:
Maximum Transmission Unit van FDDI: 4500 bytes
Maximum Transmission Unit van Ethernet: 1500 bytes
+--ICMP Datagram Too Big--<-\
v \
+---+ FDDI +-----+ FDDI +-----+ Ethernet +-----+ FDDI +---+
| X |--------| rtr |-------| rtr |-------------| rtr |---------| Y |
+---+ +-----+ +-----+ MTU = 1500 +-----+ +---+
\ ^
->-MTU Discovery Message-/
- De zender stuurt een MTU Discovery Message met een grootte van zijn
locale MTU: 4500 bytes
- De tweede router stuurt een ICMP (Internet Control Message
Protocol)-message met als boodschap: "Datagram too big"
- De zender verlaagt de grootte van zijn MTU Discovery Message tot er geen
ICMP-messages meer binnenkomen.
De authenticatie- en encryptieheader zijn vormen de basis van de belangrijkste nieuwigheden van IPv6: uitgebreide veiligheidsvoorzieningen.