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 232 forskjellige adresser, men med alt av mobil, servere, laptoper og PCer ble disse fort oppbrukt i nyere tid. IPv6 utvider adresserommet til 2128 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
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 |
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)2.
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.
0 1 | 2 3 | 4 5 | 6 7 |
---|---|---|---|
Differentiated Services | 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 26 mulige prioriteringstyper. Wikipedia har følgene tabell[1] over vanlige verdier.
DSCP value | Meaning | Drop probability | Equivalent IP precedence value |
---|---|---|---|
(101 110)2 | Expedited forwarding (EF) | N/A | 101 Critical |
(000 000)2 | Best effort | N/A | 000 - Routine |
(001 010)2 | AF11 | Low | 001 - Priority |
(001 100)2 | AF12 | Medium | 001 - Priority |
(001 110)2 | AF13 | High | 001 - Priority |
(010 010)2 | AF21 | Low | 010 - Immediate |
(010 100)2 | AF22 | Medium | 010 - Immediate |
(010 110)2 | AF23 | High | 010 - Immediate |
(011 010)2 | AF31 | Low | 011 - Flash |
(011 100)2 | AF32 | Medium | 011 - Flash |
(011 110)2 | AF33 | High | 011 - Flash |
(100 010)2 | AF41 | Low | 100 - Flash override |
(100 100)2 | AF42 | Medium | 100 - Flash override |
(100 110)2 | AF43 | High | 100 - Flash override |
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 22 mulige verdiene vises i følgene tabell.
Verdi | Betydning | Enumerering |
---|---|---|
(00)2 | Non ECN-Capable Transport | Non-ECT |
(10)2 | ECN Capable Transport | ECT(0) |
(01)2 | ECN Capable Transport | ECT(1) |
(11)2 | Congestion Encountered | CE |
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.
Utvidelses-header | Verdi | Beskrivelse |
---|---|---|
Hop-by-Hop Options | 0 | Alternativer som må bli undersøkt av alle enheter på veien. |
No Next Header | 59 | Bruk for å spesifisere at det ikke kommer noen header etter. |
Destination Options (before routing header) | 60 | Alternativer som kun trengs å undersøkes av motakeren. |
Routing | 43 | Metoder for å spesifisere veien til pakken. I bruk av Mobil IPv6. |
Fragment | 44 | Parametere for 'fragmentasjon' av datagram. |
Authentication Header (AH) | 51 | Inneholder informasjon for å autentisere deler av pakken. |
Encapsulating Security Payload (ESP) | 50 | Inneholder krypterte meldinger for sikker overføring. |
Destination Options (before upper-layer header) | 60 | Alternativer som kun trengs å undersøkes av senderen. |
Mobility (currently without upper-layer header) | 135 | Parametere i bruk for Mobil IPv6. |
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
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
Byte | 0 | 1 | 2 | 3 | |
---|---|---|---|---|---|
Byte | Bit | 0 7 | 8 15 | 16 23 | 24 31 |
0 | 0 | Next Header | Hdr Ext Len | Options and Padding | |
4 | 32 |
Options and Padding | |||
8 | 64 | ||||
12 | 96 |
4.2 Routing Header
Byte | 0 | 1 | 2 | 3 | |
---|---|---|---|---|---|
Byte | Bit | 0 7 | 8 15 | 16 23 | 24 31 |
0 | 0 | Next Header | Hdr Ext Len | Routing Type | Segments Left |
4 | 32 |
Type-specific Data
| |||
8 | 64 | ||||
12 | 96 |
4.3 Fragment Header
Byte | 0 | 1 | 2 | 3 | |||
---|---|---|---|---|---|---|---|
Byte | Bit | 0 7 | 8 15 | 16 23 | 24 28 | 29 30 | 31 |
0 | 0 | Next Header | Reserved | Fragment Offset | Res | M | |
4 | 32 | Identification |
4.4 Destination Options Header
Byte | 0 | 1 | 2 | 3 | |
---|---|---|---|---|---|
Byte | Bit | 0 7 | 8 15 | 16 23 | 24 31 |
0 | 0 | Next Header | Hdr Ext Len | Options | |
4 | 32 |
Options | |||
8 | 64 | ||||
12 | 96 |
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)16
Ut i fra tabellen vår med hvert felt sin lengde får vi følgene oppdeling
Felt | Verdi | Beskrivelse |
---|---|---|
Version | (6)16 | 6 |
Traffic Class | (00)16 | CS0, Non-ECT |
Flow Label | (0 00 00)16 | Ingen flow label |
Payload Length | (00 20)16 | Nyttelasten er 32 bytes |
Next Header | (06)16 | Header type 6 (TCP) |
Hop Limit | (40)16 | 64 hopp igjen |
Source Address | (20 01 46 46 50 02 00 00 c4 a6 36 0b 19 f3 2b 2d)16 | 2001:4646:5002::c4a6:360b:19f3:2b2d |
Destination Address | (20 01 07 00 03 00 00 01 00 00 00 00 00 00 00 30)16 | 2001:700:300:1::30 |
6. Referanser
Differentiated Services (Wikipedia)[1]
IPv6 Packet (Wikipedia)
Timeline of IPv6 (ipv6)
IPv6 Header (ipv6)
IPv6 Headers (tutorialspoint)