IPv6 pakke

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).

Fragment

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.

• Næste overskrift (8 bit): Næste udvidede overskriftstype eller protokoltype, der skal sendes som nyttelast.
• Reserveret (8 bit): Reserveret, skal initialiseres til nul.
• Fragmentoffset (13 bit): Fragmentoffset i otte oktetblokke fra starten af ​​den del af pakken, der skal fragmenteres.
• Res (2 bit): Reserveret, skal initialiseres til nul.
• M (1 bit): Kommer der flere fragmenter. Hvis 0, så er dette det sidste fragment.
• Identifikation (32 bit): Et nummer, der identificerer den originale pakke.

Nyttige data

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.

Normal nyttelastlængde

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.

Jambogrammer

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 ).

Fragmentering

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] .

Fragmentering

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.

Samling af fragmenter

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.

Noter

1. ↑ 1 2 3 4 Internetprotokol, version 6 (IPv6) specifikation. RFC 2460 .
2. ↑ Definition af Differentiated Service Field (DS Field) i IPv4- og IPv6-headerne. RFC 2474 .
3. ↑ Ny terminologi og præciseringer for DiffServ. RFC 3260 .
4. ↑ Tilføjelsen af ​​eksplicit overbelastningsmeddelelse (ECN) til IP. RFC 3168 .
5. ↑ Tekniske kriterier for valg af IP The Next Generation (IPng). RFC 1726 .
6. ↑ Udfasning af Type 0 Routing Headers i IPv6. RFC 5095
7. ↑ IPv6 Jumbogrammer. RFC 2675