IPv6-pakke ( eng. IPv6-pakke ) er en informationsblok , der er formateret til transmission over computernetværk, der understøtter IPv6 -protokollen .
Pakker består af den kontrolinformation, der er nødvendig for at levere pakken til destinationen og den nyttelast, der skal sendes. Kontrolinformationen er opdelt i én indeholdt i den faste hovedhoved og én indeholdt i én af de valgfrie ekstra overskrifter. Nyttelasten er typisk et datagram eller højere transportlagsprotokolfragment , men det kan også være netværkslagsdata (såsom ICMPv6 ) eller linklagsdata (såsom OSPF ).
IPv6-pakker transmitteres normalt ved hjælp af linklagsprotokoller såsom Ethernet , som indkapsler hver pakke i en ramme . En IPv6-pakke kan også sendes ved hjælp af en højere lag tunnelingsprotokol , såsom 6to4 eller Teredo .
I modsætning til IPv4 fragmenterer routere ikke IPv6-pakker i situationer, hvor pakken er større end forbindelses -MTU'en , og værter anbefales kraftigt [1] at implementere Path MTU-opdagelsesmekanismen for at bestemme stiens MTU-størrelse. Ellers bliver de nødt til at bruge den mindst tilladte MTU i IPv6-netværk, svarende til 1280 oktetter . Slutnoder KAN fragmentere en pakke, før den sendes, hvis den er større end MTU-stien.
Den faste overskrift på en IPv6-pakke består af 40 oktetter (320 bit) [1] og har følgende format:
Indrykning i oktetter | 0 | en | 2 | 3 | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Indrykning i stykker | 0 | en | 2 | 3 | fire | 5 | 6 | 7 | otte | 9 | ti | elleve | 12 | 13 | fjorten | femten | 16 | 17 | atten | 19 | tyve | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | tredive | 31 | |
0 | 0 | version | Trafik klasse | flow label | |||||||||||||||||||||||||||||
fire | 32 | nyttelast længde | Næste overskrift | Hop grænse | |||||||||||||||||||||||||||||
otte | 64 | kildeadresse | |||||||||||||||||||||||||||||||
C | 96 | ||||||||||||||||||||||||||||||||
ti | 128 | ||||||||||||||||||||||||||||||||
fjorten | 160 | ||||||||||||||||||||||||||||||||
atten | 192 | Destinationsadresse | |||||||||||||||||||||||||||||||
1C | 224 | ||||||||||||||||||||||||||||||||
tyve | 256 | ||||||||||||||||||||||||||||||||
24 | 288 |
Beskrivelse af felter:
For at forbedre ydeevnen og med forventning om, at moderne teknologier i forbindelses- og transportlagene giver et tilstrækkeligt niveau af fejldetektering, [5] har headeren ikke en kontrolsum .
Udvidede overskrifter indeholder yderligere information og placeres mellem den faste overskrift og protokolhovedet på højere niveau [1] . Typen af den første udvidede overskrift er angivet i feltet Næste overskrift i den faste overskrift, og hver udvidet overskrift har et lignende felt, der gemmer typen af den næste udvidede overskrift. Feltet Næste overskrift i den sidste overskrift indeholder typen af protokol med højere lag, der findes som nyttelast.
Hver udvidet overskrift skal være et multiplum af 8 i oktetter. Nogle overskrifter skal udvides til den korrekte størrelse.
Udvidede overskrifter må kun behandles af slutnoden, med undtagelse af Hop-By-Hop Options headeren , som skal behandles af hver mellemliggende knude langs pakkens vej, inklusive afsender og modtager. Hvis der er flere udvidede overskrifter i pakken, anbefales det at sortere dem som angivet i tabellen nedenfor. Bemærk, at alle udvidede overskrifter er valgfrie og ikke må optræde mere end én gang i en pakke, med undtagelse af Destination Options -headeren , som kan forekomme to gange.
Hvis en node ikke kan behandle en udvidet header, SKAL den kassere pakken og sende en Parameter Problem -meddelelse ( ICMPv6 type 4 kode 1). Hvis feltet Next Header i den udvidede header er 0, skal noden gøre det samme.
Udvidet overskrift | Type | Beskrivelse |
---|---|---|
Hop-for-Hop-muligheder | 0 | Parametre, der skal behandles af hver transitknude. |
Destinationsmuligheder | 60 | Parametre, der kun bør behandles af modtageren. |
Routing | 43 | Giver afsenderen mulighed for at angive en liste over noder, som pakken skal krydse. |
Fragment | 44 | Headeren indeholder information om pakkefragmentering. |
Authentication Header (AH) | 51 | Indeholder oplysninger, der bruges til at godkende det meste af pakken. Se IPsec . |
Encapsulating Security Payload (ESP) | halvtreds | Giver datakryptering til sikre forbindelser. Se IPsec . |
Hop-by-hop Options udvidet header er nødvendig for at videregive yderligere muligheder, der håndteres af hver node langs pakkens vej, inklusive afsender og modtager. Den udvidede Destination Options - header er nødvendig for at videregive yderligere muligheder til slutnoden eller noderne. Overskriftsformatet er det samme for begge udvidede overskrifter.
Indrykning i oktetter | 0 | en | 2 | 3 | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Indrykning i stykker | 0 | en | 2 | 3 | fire | 5 | 6 | 7 | otte | 9 | ti | elleve | 12 | 13 | fjorten | femten | 16 | 17 | atten | 19 | tyve | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | tredive | 31 | |
0 | 0 | Næste overskrift | HDR Ext Len | Muligheder |
Indrykning i oktetter | 0 | en | 2 | 3 | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Indrykning i stykker | 0 | en | 2 | 3 | fire | 5 | 6 | 7 | otte | 9 | ti | elleve | 12 | 13 | fjorten | femten | 16 | 17 | atten | 19 | tyve | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | tredive | 31 | |
0 | 0 | Indstillinger Type | Opt Data Line | Indstillinger Data |
Den udvidede Routing- header bruges til at angive en liste over transitknudepunkter, som pakken skal passere, før den når modtageren.
Indrykning i oktetter | 0 | en | 2 | 3 | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Indrykning i stykker | 0 | en | 2 | 3 | fire | 5 | 6 | 7 | otte | 9 | ti | elleve | 12 | 13 | fjorten | femten | 16 | 17 | atten | 19 | tyve | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | tredive | 31 | |
0 | 0 | Næste overskrift | HDR Ext Len | Rutetype | Segmenter tilbage | ||||||||||||||||||||||||||||
fire | 32 | Typespecifikke data |
Header undertype 0 er forældet på grund af det faktum, at headeren kan bruges til at organisere et DoS-angreb [6] . Hvis værdien af feltet Segmenter venstre er nul, SKAL knudepunktet ignorere den udvidede overskrift for ruteføring og fortsætte med at behandle de næste udvidede overskrifter. Hvis værdien af feltet Segments Left er ikke-nul, SKAL noden kassere pakken og sende en Parameter Problem -meddelelse ( ICMPv6 type 4, kode 0).
For at sende en pakke, der er større end stien MTU , opdeler afsenderen pakken i fragmenter. Den udvidede Fragment - header indeholder de oplysninger, der er nødvendige for, at modtageren kan samle den originale (ikke-fragmenterede) pakke.
Indrykning i oktetter | 0 | en | 2 | 3 | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Indrykning i stykker | 0 | en | 2 | 3 | fire | 5 | 6 | 7 | otte | 9 | ti | elleve | 12 | 13 | fjorten | femten | 16 | 17 | atten | 19 | tyve | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | tredive | 31 | |
0 | 0 | Næste overskrift | Reserveret | Fragment offset | Res | M | |||||||||||||||||||||||||||
fire | 32 | Identifikation |
Bag de faste og udvidede overskrifter er transportlagsprotokollens nyttelast , såsom et TCP -segment eller et UDP - datagram. Næste header -feltet i den sidste IPv6-header angiver nyttelasttypen, der er gemt i pakken.
Payload Length fixed header-feltet er 16 bit , så den maksimalt mulige nyttelast og udvidede headers er 65535 oktetter . Den maksimale rammestørrelse for mange linklagsprotokoller er meget mindre.
En IPv6-pakke kan bære flere data ved at bruge jumbo-nyttelast -indstillingen i den udvidede Hop-By-Hop Options- header [7] . Denne indstilling tillader udveksling af pakker med en nyttelaststørrelse på 1 byte mindre end 4 GiB (2 32 − 1 = 4294967295 bytes). En pakke med et sådant indhold kaldes et jambogram.
Da TCP- og UDP-protokollerne begge har længdefelter begrænset til 16 bit, er implementering af modificerede transportlagsprotokoller påkrævet for at understøtte jambogrammer. Jumbogrammer kan kun fungere på forbindelser med en MTU større end 65583 oktetter (større end 65535 oktetter for nyttelasten, 40 oktetter for den faste header og 8 oktetter for den udvidede Hop-By-Hop Options header ).
IPv6-pakker bliver aldrig fragmenteret af routere . Pakker, der er større end netværksforbindelsens MTU , kasseres, og en Packet too Big -meddelelse ( ICMPv6 type 2) sendes til afsenderen . Lignende adfærd i IPv4 opstår, hvis Don't Fragment- bitten er indstillet .
IPv6-endeknudepunkter forventes at udføre Path MTU-opdagelse for at bestemme den maksimalt tilladte størrelse af pakker, de kan sende, og den højere lag-protokol vil begrænse pakkestørrelsen. Men hvis protokollen for højere lag ikke er i stand til at gøre det, MÅ afsenderen bruge den udvidede Fragment -header til at udføre IPv6-pakkefragmentering. Alle protokoller, der bærer IPv6-pakker, skal have en MTU, der er lig med eller større end 1280 oktetter. Protokoller, der ikke er i stand til at transmittere en 1280-oktet-pakke i én blok, skal fragmenteres og samles igen uden at påvirke IPv6-laget [1] .
En pakke, der indeholder et fragment af den originale (store) pakke, består af to dele: den ikke-fragmenterbare del af den originale pakke, som er den samme for alle fragmenter, og den fragmenterbare del, identificeret ved fragmentets offset.
Den ikke-fragmenterbare del af pakken består af en fast overskrift og udvidede overskrifter på den originale pakke (valgfrit).
Værdien af feltet Næste overskrift i den sidste overskrift af den ikke-fragmenterede del skal være 44, hvilket indikerer, at den næste overskrift vil være Fragment . I Fragment -headeren skal feltet Next Header være lig med typen af den første header i den fragmenterede del. Fragment - headeren efterfølges af et fragment af den originale pakke. Størrelsen af hvert fragment af den fragmenterede del skal være et multiplum af 8, bortset fra det sidste fragment.
Den modtagende node, der har samlet alle fragmenterne, kasserer den udvidede Fragments -header og placerer fragmenterne ved de forskydninger, der er angivet i feltet Fragment Offset ganget med 8. Pakker, der indeholder fragmenter, behøver ikke at ankomme i den korrekte rækkefølge, og de vil blive omarrangeret af den modtagende node, hvis det er nødvendigt.
Hvis ikke alle fragmenter blev indsamlet 60 sekunder efter modtagelse af det første fragment, annulleres samlingen af den originale pakke, og alle modtagne fragmenter kasseres. Hvis det første fragment modtages (med Fragmant Offset sat til nul), sendes en meddelelse om Fragment Reassembly Time Exceeded ( ICMPv6 type 3 kode 1) til afsenderen af den fragmenterede pakke.
Den maksimale størrelse på den originale pakke må ikke overstige 65.535 oktetter, og hvis den originale pakke er større efter genmontering, skal den kasseres.
Hoved | |
---|---|
Implementering |
|
Migration fra IPv4 til IPv6 |
|
Relaterede protokoller |
|