IPv4 och IPv6 header

Internet Protocol (IP) är det grundläggande protokollet som används för att routa data över nätverk och har varit en avgörande komponent för att möjliggöra den globala internet vi har idag. I detta avsnitt kommer vi att utforska skillnaderna mellan IPv4 och IPv6 och varför övergången till IPv6 är en nödvändighet för att möta de växande utmaningarna i den digitala världen.

IPv4

IPv4-header (styrinformation) består det av flera fält som specificerar olika egenskaper hos IP-paketet. Dessa fält inkluderar Version, Header Length (IHL), Type Of Services (TOS), Total Length, Identification, Flags, Fragment Offset, Time To Live (TTL), Protocol, Checksum samt Source  och destination address. IPv4-huvudet är 20-60 byte långt beroende på om ytterligare alternative (Options) används.

IPv4 definierades i RFC 791 (september 1981) som Internet Protocol, DARPA Internet Program Protocol Specification.

IPv6

IPv6-header skiljer sig från IPv4 genom att vara mer effektivt och enklare. Det har också ett fast format på 40 byte. I IPv6-huvudet hittar vi fält som Version, Traffic Class, Flow Control, Payload Length, Next Header, Hop Limit, Source och Destination Address. Ett intressant inslag i IPv6 är att det möjliggör en enklare hantering av tjänster för överföringskvalitet genom att införa ett flödeskontroll som identifierar och prioriterar paket inom en specifik nätverkstrafik.

IPv6 header definieras i RFC 2460 (December 1998) som Internet Protocol, Version 6 (IPv6) Specification.

Bild 1: IPv4 och IPv6 header

Genom att jämföra dessa två huvuden kan vi se att IPv6-huvudet är mer optimerat och har fler möjligheter att hantera moderna nätverkskrav, särskilt med tanke på det utökade adressutrymmet och möjligheten att prioritera vissa datapaket för bättre tjänstekvalitet. IPv6 är en nödvändig framsteg för att möta de växande behoven i dagens internetanvändning.

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

Fälten

  • Version – Fältet har värde 4 för IPv4 och värde 6 för IPv6.
  • 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 för räkna ut längden. 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.
  • Type of Service (ToS) – Fältnamnet ä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.
  • 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.

  • Identification – Detta är ett 16-bitars fält som genererar ett unikt identifikationsnummer för ett paket. När ett paket fragmenteras, associeras varje fragment med samma identifikationsnummer för att kunna sättas ihop igen korrekt av mottagaren.
  • Flags – Detta är ett 3-bitars fält som indikerar statusen för fragmentet. Den första biten används inte och är alltid satt till noll. Den andra biten representerar DF (Do Not Fragment) och har värdet 1 om paketet inte får fragmenteras, vilket är vanligt för de flesta protokoll. Den tredje biten representerar MF (More Fragments) och har värdet 1 om fler fragment finns, det vill säga att paketfragmentering har skett.
  • Fragment Offset – Detta 13-bitars fält används för att markera varje paketfragment med ett specifikt värde som informerar mottagaren om i vilken ordning fragmenten ska sättas ihop för att återskapa det ursprungliga paketet. Fragment Offset anger den relativa positionen för varje fragment i det ursprungliga paketet och hjälper mottagaren att korrekt rekonstruera datan.

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 cirkulerar i nätverket oändligt, vilket förhindrar routing-loopar. Värdet i dessa fält minskas med 1 varje gång ett IPv4- eller IPv6-paket passerar en router. När fältet når värdet 0, kasseras paketet och en ICMPv4 eller ICMPv6 ”Time Exceeded” (Tidsöverskriden) -meddelande skickas tillbaka till avsändaren. Ursprungligen var TTL i IPv4 avsett att representera den faktiska maximala tiden som paketet använde för att ta sig genom nätverket, inte antalet routrar det passerade. Enligt RFC 791 är tiden som mäts i sekunder, där värdet 1 motsvarar en sekund. Således är den maximala tiden för TTL-fältet 255 sekunder eller 4,25 minuter. I praktiken minskar routrar TTL-värdet med 1 istället för att beräkna den verkliga tiden som paketet har använt på sin resa till mottagaren.
  • Protocol – Fältet ”Protocol” i IPv4 indikerar vilket protokoll som inkapslas i dataavsnittet av ett IPv4-paket. I IPv6 används ett liknande fält kallat ”Next Header”, vilket anger vilken typ av header som förväntas följa efter den primära headern. Om det bara finns den primära IPv6-headern utan några förlängningshuvuden specificerade, anger fältet ”Next Header” protokollet som är inkapslat som en del av datan.

Både IPv4 och IPv6 använder numeriska värden i fältet ”Protocol” och ”Next Header”, med några ytterligare värden för IPv6. Exempelvis är värdet 6 för TCP i båda protokoll medan värdet 1 identifierar ICMPv4 och 3A för ICMPv6.

  • Header Checksum – En kontrollsumma för IPv4-header tillhandahålls för att skydda mot eventuella fel som kan uppstå under dataöverföring. Denna checksumma är en 16-bitars enkel kontrollsumma, inte en mer komplex cyklisk redundanskontroll (CRC) som används i Ethernet. Kontrollsumman kontrollerar endast integriteten för IPv4-headern och inte hela paketet. Varje router längs vägen verifierar och beräknar om detta fält. Om kontrollsumman misslyckas, tas paketet bort.

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

    • Source IP-adress
    • Destination IP-adress
    • Nyttolastens längd (Payload) för övre lagers protokoll (TCP/UDP-header och data)
    • IPv6-värdet för Next Header (inklusive eventuella Extension Headers)
  • IPv4 och IPv6 source- och destination-adresser – Den största skillnaden mellan dessa två versioner är adress storleken, men funktionerna för avsändaren (source) som genererar datapaket och destinationen (mottagaren) som tar emot överförda paket är liknande. Avsändaren använder alltid en unicast IP-adress, medan mottagaren kan ha en unicast, multicast, anycast eller broadcast-adress beroende på adressversionen.