IPv6 pakkeheader

TDAT2004-A Datakommunikasjon med nettverksprogrammering

Oppgave 38 - IPv6 Pakkeheader

Skrevet av Elena Falkenberg Nordmark og Erlend Tobiassen

1. Innledning

IPv6-pakker er delt i to. De har en nyttelast med data, og en header med informasjon om adressering av pakkene. Header-en har en hoveddel med fast størrelse, og en valgfri del som man kaller utvidelses-header. Den faste delen inneholder all informasjonen som er nødvendig for en ruter, i mens den valgfrie delen inneholder informasjon som hjelper ruteren å forstå hvordan den skal behandle pakkene som blir sendt.

Relevante bestemmelser:

• • 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

IPv6 har vært drøftet lenge, men et stort behov for IPv6 kom av at man begynte å gå tom for IPv4-adresser. Adresserommet til IPv4 var for lite da det "kun" var 2³² forskjellige adresser, men med alt av mobil, servere, laptoper og PCer ble disse fort oppbrukt i nyere tid. IPv6 utvider adresserommet til 2¹²⁸ forskjellige adresser, noe som skal holde i nærmeste fremtid.

Header-formatet til IPv6 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 utvidelses-header.

Det er ingen checksum i IPv6-header-en. Dette 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 videresending så effektiv som mulig, har ikke IPv6-headeren noen checksum-felt, lar IPv6 andre lag under seg i OSI-modellen håndtere feilkilder. 

3. Virkemåte

3.1 Version

Versjonsfeltet er det første feltet i IPv6 pakke-header-en. Feltet er 4 bit langt og består alltid av konstanten 6, derav IPv6. På binært blir det (0110)₂. 

3.2 Traffic Class

Trafikklassefeltet inneholder to verdier. De første seks siffrene i binær er tatt i bruk av differentiated services (DSCP) og de to siste er brukt til ECN. 

3.2.1 Differentiated Services

Differentiated services er en måte for nettverk å prioritere forskjellige pakker på, for eksempel slik at Skype-samtaler skal fungere på ett nettverk selv om noen andre laster ned noe. Dette kalles ofte for Quality of Service (QoS). I teorien er det 2⁶ mulige prioriteringstyper. Wikipedia har følgene tabell^[1] over vanlige verdier. 

3.2.2 Explicit Congestion Notification (ECN)

Eksplisitt trafikkforstoppelselsesadvarsel er en måte for to endepunkter, som begge støtter ECN, å si i fra om at det er trafikkforstoppelselse uten å 'droppe' pakker, slik som de ellers ville gjort. ECN-feltet består av to bits. De da 2² mulige verdiene vises i følgene tabell.

3.3 Flow Label

Flytbeskrivelsesfeltet identifiserer en sammenhengene flyt med pakker som har tilhørighet. Hovedbruksområdet til dette feltet er som et hint til rutere og switcher at pakkene hører sammen og burde ideelt sett ta samme vei til målet. Slik kan omstokking av pakker som kommer ute av rekkefølge minimeres.

3.4 Payload Length

Nyttelastlengdefeltet spesifiserer lengden på nyttelasten i bytes, der lengden inkluderer alle eventuelle utvidelses-headers. Dette feltet skal settes til 0 hvis en Hop-by-Hop utvidelses-header som tar i bruk jumbograms er tilstedet.

3.5 Next Header

Neste-header-feltet angir hvilken type header som kommer etter den nåværene header-en, dette kan være hvilken som helst header som har en tilsvarene verdi, men som oftest er det enten en utvidelses-header eller TCP/UDP-header. Vi beskriver de forskjellige utvidelses-header-ene i ett senere avsnitt.

3.6 Hop limit

Hoppbegrensningsfeltet sier noe om hvor mange hopp en pakke kan gjøre før pakken blir kastet bort. Dette feltet var kjent som levetid(TTL) i IPv4, men for at switcher o.l. skal slippe å regne ut tiden pakker ligger i buffer, brukes antall hopp istedet. Dette betyr at enheten kun trenger å trekke 1 fra feltet.

3.7 Source Address

Kildeadressefeltet spesifiserer IPv6-adressen til den enheten som har sendt pakken. Når en motakker svarer, vil den svare på denne adressen.

3.8 Destination Address

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 2⁸ 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.

4.1 Hop-by-Hop

4.2 Routing Header

4.3 Fragment Header

4.4 Destination Options Header

5. Eksempel

For å se på ett kjapt eksempel har vi satt opp wireshark og spesifisert filteret ipv6.version == 6. Vi finner en TCP pakke som har blitt sendt over IPv6:

Det som er markert i blått er IPv6 header-en, vi leser at hele byte-strengen er:

(60 00 00 00 00 20 06 40 20 01 46 46 50 02 00 00 c4 a6 36 0b 19 f3 2b 2d 20 01 07 00 03 00 00 01 00 00 00 00 00 00 00 30)₁₆

Ut i fra tabellen vår med hvert felt sin lengde får vi følgene oppdeling

6. Referanser

Differentiated Services (Wikipedia)[1] 

IPv6 Packet (Wikipedia) 

Timeline of IPv6 (ipv6)

IPv6 Header (ipv6)

IPv6 Headers (tutorialspoint)