...
- RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification
- RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP
2. Ønsket funksjonalitet
Behovet IPv6 har vært drøftet lenge, men et stort behov for IPv6 kom av at antall IPman begynte å gå tom for IPv4-adresser ble brukt opp. Adresserommet til IPv4 var for lite da det "kun" var 232 forskjellige adresser i IPv4, men med alt av mobil, servere, laptoper og PCer ble disse fort oppbrukt i nyere tid. IPv6 utvider adresserommet til 2128 forskjellige adresser. Adresserommet blir definert i IPv6-headeren, noe som skal holde i nærmeste fremtid.
Header-formatet til IPv6 holder overhead-en så lav som mulig. Ved er designet for at rutere og switcher skal kunne prosessere og videresende pakker så fort som mulig, til tross for at IPv6-headeren er større enn IPv4-headeren. Et av tiltakene som er tatt for å holde prosesstiden nede er å fjerne unødvendige og valgfrie felter fra hoved-header-en, og heller plassere dem i en ekstra header, optimaliseres måten header-en blir prosessert i rutere på. Et eksempel på et valgfritt felt er feltet for støtte for fragmentering, som da er plassert i en ekstra header. Om det ikke er en ekstra header, så vil sendelser med for stor størrelse ikke bli sendt, og senderen vil i stedet få meldingen "Packet Too Big". utvidelses-header.
Det er ingen checksum i IPv6-header-en. Dette er fordi en stor grunn til at IPv6 er raskere å sende videre for switcher. I IPv4 hvis switchen for eksempel vil endre på motakeraddressen eller TTL-feltet måtte den utregne checksummen på nytt siden IPv4-headeren var inkludert i checksummen. Fordi man ønsker å gjøre den videresending så effektiv som mulig, så man lar andre lag, som transport- eller applikasjonslaget, få styre med feilhåndtering, har ikke IPv6-headeren noen checksum-felt, lar IPv6 andre lag under seg i OSI-modellen håndtere feilkilder.
3. Virkemåte
| Byte | 0 | 1 | 2 | 3 | |||||
|---|---|---|---|---|---|---|---|---|---|
| Byte | Bit | 0 3 | 4 7 | 8 11 | 12 15 | 16 19 | 20 23 | 24 27 | 28 31 |
| 0 | 0 | Version | Traffic Class | Flow Label | |||||
| 4 | 32 | Payload Length | Next header | Hop limit | |||||
| 8 | 64 |
| |||||||
| 12 | 96 | ||||||||
| 16 | 128 | ||||||||
| 20 | 160 | ||||||||
| 24 | 192 |
| |||||||
| 28 | 224 | ||||||||
| 32 | 256 | ||||||||
| 36 | 288 | ||||||||
...
Motakeradressefeltet er IPv6-adressen til enheten som skal motta pakken.
4. Utvidelses-headers
I motsetning til IPv4 har ikke IPv6 noen felt utover det som er nødvendig, i stedet har IPv6 støtte for 28 forskjellige typer med utvidelses-headers hvor en pakke kan inneholde så mange av disse som den trenger gjennom nesteheaderfeltet. Vi kommer ikke til å se på hvert enkelt felt for hver utvidelse her, men hver enkelt er beskrevet i RFC-bestemmelser. De utvidelsene vi tar for oss her er de som har blitt definert i RFC 2460. Alle utvidelses-header-ene skal ha feltene Next Header og Hdr Ext Len. Next Header feltene skal ha samme funksjon som i hoved-header-en.
...