IPv4 och IPv6 header

IPv4 header definierades i RFC 791 (September 1981) som Internet Protocol, DARPA Internet Program Protocol Specification. För en bättre förståelse kommer här att jämföras IPv4 och IPv6 header med hjälp av publicerade bilder på Internet.

Bild 1: IPv4 och IPv6 header

Bild 1 illustrerar skillnader genom att markera fält med olika färg:

  • Gul: samma fält för bägge protokoll
  • Mörk blå: fält som försvinner och inte finns på IPv6
  • Ljus blå: fält som byter namn och placering
  • Grönt: ny fält i IPv6

IPv6 header definieras i RFC 2460 (December 1998) som Internet Protocol, Version 6 (IPv6) Specification. Det som visas på bild 1 är huvudstrukturen (“main IPv6 header“) eftersom i IPv6 finns fler till header kallade “extension headers“.

På bild 1 presenteras bägge protokollen med samma bredd och det kan tolkas som att de är samma bitars bredd, men det är bara en logisk representation eftersom IPv4-header är 32 bitars bred och IPv6-header är 64 bitars bred.

Bild 2: IPv4 32 bitar bredd och IPv6 64 bitar bredd

Fälten

  • Version – Båda header börjar med fältet Version, men i IPv4 headern är alltid fältets värde 4 och i IPv6 är värdet 6.
  • Internet Header Length (IHL) – Det minimala värdet i IPv4 är 5 (0101 = 5; 5 x 4 = 20 byte) och det maximala värdet är 60 byte (1111 = 15, 15 x 4  = 60 byte). IPv6 har inte IHL-fält eftersom dess header har ett fast värde på 40 byte. Bild 2 illustrerar att IPv4 header innehåller 32 bitar eller 4 byte per rad. Om du räknar antal rader som är 5 kan du enkel multiplicera 5 x 4. Det samma gäller för IPv6, men varje rad innehåller 64 bitar eller 8 byte. Om du räknar antal rader som är 5 kan du multiplicera 5 x 8 och få fram 40 byte.
  • Type of Service (ToS) – IPv4 fältnamnet som ändrades i IPv6 till Traffic Class. Annars har de samma funktion för pakethantering exempelvis ordning i vilken paketen överförs  samt deras prioriteringar. Värdet i Traffic Class beskriver paketets prioritet.
  • IPv6 Flow Label – Ett nytt fält som används för att markera sekvenser av paket avsedda till en eller flera mottagare. Fältets syfte är att hjälpa till med identifiering av paket i grupper. En “flödes-indikator” som nätleverantörer kan använda för att behandla olika typer av tjänster, protokoll eller dataöverföringar. Just nu finns inte så många implementationer till detta fält förutom lastbalansering och tunneling.
  • IPv4 Total Length –  Anger i byte den totala storleken på hela paketet inklusive dess header. Den maximala storleken är 65 535 bytes ( 216). De flesta IPv4 paket är oftast mycket mindre.

    Bild 3: Fältet Payload Length i IPv6
  • IPv6 Payload Length är en 16 bitar fält som indikerar storleken i byte av nyttolasten (data utan styrinformation). I detta fält kan inkluderas header-tillägg (fler styrinformation) som en del av nyttolasten. Fälten IPv4 Total Length och IPv6 Payload Length har mycket gemensamt med en tydlig skillnad. IPv6 Payload anger endast storleken på nyttolasten i byte utan att inkludera den primära headern.

IPv4 och IPv6 MTU

De flesta datalänkar reglerar dataöverföringar med maximala storleken, känd som MTU eller Maximum Transmission Unit. MTU är ett mått som inkluderar den totala paketlängden, inklusive dess header. Detta gäller för både IPv4 och IPv6.

IPv4 kräver att varje nod (mellanliggande nätverkshanterare) i nätverket klarar av paketöverföring på 68 byte utan fragmenteringar. Detta på grund av IPv4 header maximalt storlek är på 60 byte. Det innebär att nyttolasten (payload) kan vara max 8 byte, men som oftast är större. Alternativt kan 8 byte omfatta ett annat protokoll, annars måste ske paketfragmentering. Varje klient-mottagare i destinationsnätverket måste kunna ta emot IPv4 paket med minsta storleken på 576 byte (flera paketfragment).

IPv6 kräver minimalt MTU på 1280 byte, men rekommenderas en MTU på 1500 byte.

IPv4 paketfragmentering

Bild 4: Datalänk med mindre MTU

IPv4 har designats för olika bandbredd därmed varierande datalänk typer. I en sådan nätverksmiljö tillåts routrar fragmentera stora paket när det behövs. Till exempel när en router tar emot ett för stort paket som inte kan vidarebefordras på grund av att utgående interface har mindre MTU, se bild 4. Det innebär att paketet måste fragmenteras för vidarebefordring men det förutsätter att flaggan DF är satt till noll, om DF flaggan är satt till ett (DF=1) kommer paketet att tas bort. Om DF är satt till noll fragmenteras paketet och när alla paketfragment kommer fram till mottagare är dennes arbetsuppgift att återsamla dessa till de ursprungliga paketen.

Mer om fält i IPv4 och IPv6 fält

  • Identification – 16 bitar som genererar en identifikationsnummer för ett paket och när ett paket fragmenteras associeras varje fragment med paketets identifikationsnummer.
  • Flags – 3 bitar som indikerar vad som händer med ett fragment. Första biten används inte och sätts till noll, den andra känns som DF som står för Do Not Fragment när den är satt till 1. De flesta protokoll lägger inte mycket uppmärksamhet till fragmentering och DF flaggan sätts då till noll. Den tredje biten som är MF flaggan eller More Fragments som sätts till 1 om paketfragmentering sker.
  • Fragment Offset – sammanlagt 13 bitar används för att markera paketfragment med ett visst värde som talar om för mottagare i vilken ordning fragmenten ska sättas ihop till paketet.

IPv6 paketfragmentering

Till skillnad från IPv4, där routrar tillåts fragmentera paket med ett för stor MTU, fragmenteras inte paket av IPv6 routrar. Avsändaren får fragmentera paket vid behov, men inte mellanliggande routrar.

Bild 1 illustrerar fält som inte finns i IPv6. Fälten i andra raden (Identification, Flags, Fragment Offset) som just hanterar paketfragmentering i IPv4 finns inte i IPv6.

När en IPv6-router tar emot ett paket som är större än utgående interface MTU tar routern bort paketet och skickar ett ICMPv6 Packet Too Big meddelande tillbaka till avsändaren. Meddelandet Packet Too Big innehåller MTU-storleken på datalänken i byte så att avsändaren kan ändra paketets storlek för vidareöverföring.

Bild 5: IPv6 routrar utför inte paketfragmentering

så vad är det bästa, små eller stora paketstorlek?

Data är vanligtvis överförd som en serie paket, ibland kallad pakettåg. Ju större paketen är, desto färre paket behövs för dataöverföring. Det gör att det största paketstorleken föredras i enlighet med minsta MTU längs vägen till mottagare. För att kunna identifiera minsta MTU skickas först ett utforskande paket med namnet Path MTU-discovery.

Mer om fält i IPv4 och IPv6 fält

  • Time To Live – IPv4 Time to Live (TTL) och IPv6 Hop Limit fälten säkerställer att paket inte vandrar i ett nätverk under en obestämd tid, som i fallet med routing-loopar. Dessa fälts värde minskas med 1 varje gång en router mottar IPv4 eller IPv6-paket. När fältet innehåller värdet 0 kasseras paket och ett ICMPv4 eller ICMPv6 Time Exceed meddelande skickas till avsändaren. I IPv4 var TTL ursprungligen avsedd att representera den faktiska maximala tiden som paket använder för att sig genom ett nätverk och inte nödvändigtvis antalet routrar paket tar sig genom. RFC 791 säger så här: “Även om ingen lokal information är tillgänglig på den tid som faktiskt förbrukats, måste TTL minskas med 1. Den tid som mäts är i sekunder (dvs. värdet 1 betyder en sekund). Således är den maximala tiden för fältet TTL 255 sekunder eller 4,25 minuter.
    I praktiken minskar routrar TTL värdet med 1 istället att beräkna tiden ett paket har använt i sin resa till mottagaren.
  • Protocol – Fältet Protocol i IPv4 anger protokoll som inkapslas i data delen av ett IPv4-paket.
    Bild 6: Fältet Next Header i IPv6

    IPv6 har ett liknande fält,  Next Header, som anger vilken typ av header som förväntas efter den primära headern. I en situation där det bara finns den primära IPv6 header och inga Extension Header specificerar fältet Next Header protokollet som är inkapslat som en del av data.

    Samma värden som används i IPv4-fältet Protocol används i fältet IPv6 Next Header, tillsammans med några ytterligare värden för IPv6. Några av de vanligaste värdena för båda protokollen är exempelvis 1 för ICMPv4, 6 för TCP, 17 för UDP, 43 för Routing Extension Header IPv6, 44 för Fragment header för IPv6.
  • Header Checksum – En kontrollsumma för IPv4-Header tillhandahålls som skydd mot eventuell signaldeformationer vid dataöverföringar. Detta är inte den mer komplexa cykliska redundanskontrollen (CRC) som används av Ethernet, utan en mycket enklare 16-bitars kontrollsumma som kontrollerar endast IPv4-header och inte hela paketet. Varje router längs vägen verifierar och beräknar om detta fält. Om kontrollsumman misslyckas, tar routern bort paketet.
    Bild 7: Fältet Header and Data Checksum

    Det finns inget kontrollfält i IPv6-Header eftersom teknologier i Data länk skiktet, som Ethernet, utför sina egna kontrollsummor. Till skillnad från IPv4 är i IPv6 obligatorisk att protokoll inkluderar en checksumma, exempelvis TCP och UDP. Dessa två protokoll fungerar över IPv6 utan strukturella ändringar förutom att i beräkningar av checksumman ändrar de från 32-bitar adresser till 128-bitar adresser.
    Både TCP och UDP genererar en låtsas header så att checksumman kan utföras utan att påverka paketet. Följande ingår i beräkningen av checksumman:

    • Source IP-adress
    • Destination IP-adress
    • Övre-skikts protokollens nyttolast längden (TCP / UDP-header och data)
    • IPv6-värdet för Next Header (inklusive eventuella Extension Header)
  • IPv4 och IPv6 source och destinations adresser – Det största skillnaden mellan dessa två versioner är storleken men annars samma funktioner för avsändaren (source) som genererar datapaket och den använder alltid en unicast IP adress och destinationen (mottagare) som mottar överförda paket. Destinationen kan vara unicast, multicast, anycast eller broadcast.

Några frågor om IPv6

  1. Varför inkluderar inte IPv6 ett liknande fält som IHL?
  2. Vilka skillnader mellan IPv4 Total Length fält och IPv6 Payload fält?
  3. Vilken är det största skillnaden mellan IPv4 och IPv6 adresser?
  4. Hur paket fragmenteras i IPv6?
  5. Varför inkluderas inte ett checksumma fält i IPv6?