IPv6 Jonas Westerlund Institutionen för Informationsbehandling Åbo Akademi, Åbo, Finland

Transkript

1 IPv6 Jonas Westerlund Institutionen för Informationsbehandling Åbo Akademi, Åbo, Finland

2 Abstrakt I denna uppsats skall jag ta upp dom grundläggande egenskaper hos Internet Protocol version 6 (IPv6) IPv6 specificerades första gången i Request for Comment (RFC) nummer 1883 av Deering och Hinden i december 1995 Standarden har reviderats efter det, och i december 1998 publicerade Deering och Hinden RFC2460 ACM klassificering : ACM SIG: C26, C22, C21 SIGCOMM 2

3 Innehållsförteckning Abstrakt 2 Innehållsförteckning3 1 Inledning4 2 Bakgrund 4 3 IPv6 egenskaper 5 31 Representation av adresser 5 32 Representation av adressprefix6 33 Identification av adresstyp 6 34 Unicast adresser7 4 Headern 8 41 Hop-by-hop options header10 42 Destination options11 43 Routing header Fragment header13 45 Authentication Header13 46 Encrypted Security Payload 15 5 Övergång till IPv6 16 Källor17 3

4 1 Inledning En av dom största orsakerna till att byta Internet Protokoll (IP) är den att Internet adresserna sakta men säkert håller på och ta slut, speciellt i Asien och Europa är läget alarmerande Kravet på att det skall vara möjligt att ordna upp adresserna i strikta hierarkier minskar på antalet lediga adresser och det är redan svårt för företag och organisationer att få adressrymder Också nya tekniker som IP-telefoni ställer krav på bättre, snabbare och säkrare förbindelser över Internet 2 Bakgrund I början av 1990-talet började Internet Activites Board (IAB) studera problemet med ökningen av Internet Man visste att antalet anslutna datorer skulle fortsätta öka, men man visste inte att Internet skulle spridas till annat än datorer, tex mobiltelefoner eller bilar Första stegen mot ett nytt Internet Protokoll togs 1994 när IAB formulerade en Request For Comment (RFC) (RFC 1752) Denna RFC blev godkänd i juli 1995 och i januari 1996 publicerades det detaljerade förslaget i ytterligare fyra RFCn (RFC 1883, RFC 1884, RFC 1885 samt RFC 1886) och den kanske viktigaste, RFC 1933, publicerades i april samma år RFC 1933 behandlade hur man skulle övergå från IPv4 till IPv6 [UIPv6] Förändringar som har gjorts från IPv4 är att adressrymden har utökats fyra gånger, från 32 bitars adress till 128 bitar 1 Också headerns design har ändrats från att vara av fix längd, till mera variabel, genom att använda olika tilläggs headers[rfc 2460] Man kan tycka att det är lite överdrivet att utöka antalet möjliga adresser från 2 32 (429 x 10 9 ) till (340 x ), men på det sättet undvikes framtida problem med adressbrist, och dessutom blir det enklare att ordna upp i routing hierarkier Ett problem med IPv4 är att man delade upp adresserna i A, B och C klass nät Idén med uppdelningen av adresserna var säkert god, det medför ju att till exempel ett företag får adresser som är nära varandra Som exempel finns det 128 st A klass nät och varje har ungefär 16 miljoner möjliga adresser Redan i januari 1996 var 92 st upptagna B klass näten innehåller 1 En bit är ett binärt tal, som antingen kan vara en etta eller en nolla Om en adress är 32-bitar lång, innehåller den alltså 32 binära tal 4

5 65536 adresser och C klass näten 255 adresser Detta leder till att det verkliga antalet möjliga adresser är betydligt mindre än 4 miljarder [IIwCR] 3 IPv6 egenskaper Det finns tre olika sorters adresstyper i IPv6: unicast, anycast och multicast En unicast adress identifierar en enskild nod 2 Anycast adresser tilldelas grupper av noder Ett paket som skickas till en anycast adress går till den av noderna som är närmast En multicast adress är också tilldelad en grupp av noder, men ett paket som skickas till en multicast adress kommer att skickas till alla adresser i gruppen Det finns ingen broadcast adress i IPv6, eftersom dess funktion tas över av multicast adressen 31 Representation av adresser Den enda skillnaden som användaren egentligen märker vid ett byte från IPv4 till IPv6 är adressnotationen Den välkända IPv4 adressen består ju av 4 trippler av decimaltal, separerade med punkter (tex ) och den nya IPv6 adressen består av åtta grupper om 4 hexadecimala tal, separerade med kolon [Understanding IPv6] (tex 2001:09b0:1f05:6a11:0000:0000:0000:0001) På grund av olika metoder att allokera vissa typer av IPv6 adresser kommer det att bli vanligt att adresser innehålla långa strängar av nollor För att göra användningen av sådana adresser lättare kan man dels lämna bort inledande nollor och ersätta hela fält av nollor med "::" Alltså exemplet ovan blir 2001:9b0:1f05:6a11::1 Men man kan använda "::" endast en gång per adress, alltså 2001:9b0:1f05:6a11::b0ff::1 är ingen tillåten förkortning av 2001:09b0:1f05:6a11:0000:b0ff:0000:0001 Eftersom det under övergångstiden från IPv4 till IPv6 kommer att finnas adresser av båda sorterna anslutna till Internet på samma gång, så är det praktiskt om IPv4 adresser kan representeras i IPv6 notation Därför kan man representera en IPv4 adress genom att byta ut de 32 2 I ett nätverk är en nod en knutpunkt varifrån information kan sändas, tas emot eller skickas vidare, till exempel en dator eller en router 5

6 nedersta 3 bitarna till 'normal IPv4 notation', och fylla ut de 96 översta 4 med nollor IPv4 adressen ovan skulle alltså bli: 0000:0000:0000:0000:0000:0000: , som förstås kan förkortas till :: Representation av adressprefix Textrepresentationen av IPv6 adressprefix följer samma standard som IPv4, alltså i formen IPv6-adress/prefix-längd där 'prefix-längd' är ett decimalt värde som berättar hur många av dom 'översta' bitarna som prefixet består av Exempel: 2001:9b0:1f05::/48 där 48 säger att dom 48 översta bitarna (alltså 2001:9b0:1f05::) hör till prefixet Detta betyder alltså att man kan 'förkorta' nodens adress (2001:9b0:1f05:6a11::1) och nodens subnet (2001:9b0:1f05:6a11::/64) till 2001:9b0:1f05:6a11::1/64 [RFC 1519] 33 Identification av adresstyp Typen av adress (uni-, any-, multicast osv) bestäms av ett prefix som består av dom första bitarna i adressen enligt följande tabell: Adresstyp Binärt prefix IPv6 notation Ospecifierad 000 (128 bitar) ::/128 Loopback 001 (128 bitar) ::1/128 Multicast FF00::/8 Link-local unicast FE80::/10 Site-local unicast FEC0::/10 Global unicast (övriga) Tabell 1 Adresstyper [RFC 3513] 3 Dom bitarna i adressen som finns längst till höger 4 Dom bitarna i adressen som finns längst till vänster 6

7 När man anycast adresser tilldelas så väljs dom från unicast adressrymden, alltså inga speciella subnät 5 är tilldelade för anycast adresserna Därför går det inte att särskilja unicast adresser från anycast adresser [RFC 3513] 34 Unicast adresser Det finns olika typer av unicast adresser, framför allt global unicast, site-local unicast och linklocal unicast Globala unicast adresser används för att kommunicera med nätverket, medan sitelocal adresser används inom noden, till exempel för att skicka paket åt sej själv En global unicast adress är alltså nodens 'egentliga' IP-adress, den adressen som finns i sändar respektive mottagarfältet i headern på paketet Enligt RFC 3513 går det att dela upp en global unicast adress i tre delar, den första (n-bitar lång) är det globala routing prefixet, den andra (m-bitar lång) är identifikationen på subnätet och den sista (128-m-n bitar lång) består av själva gränssnittets 6 identifikation Link-local adresser används endast på det egna subnätet, till exempel för konfiguration Paket med link-local adress som sändare eller mottagare får inte skickas vidare av routers 5 Ett subnät är en del av ett nätverk 6 Gränssnittet är det som man ansluter noden till nätverket med, till exempel ett nätverkskort 7

8 4 Headern En av nackdelarna med IPv4 är den komplexa headern 7 IPv4 headern består av 14 olika fält, inklusive 2 adressfält, ett för sändaren och ett för mottagaren IPv4 headern är 20 bytes 8 lång, och om förändringar bara hade gjorts åt adressfältena (så att en 128 bitar lång adress skulle passa istället för en 32 bitar lång) så skulle IPv6 headern ha blivit 80 byte lång, och det är inte önskvärt Därför förkortades headern till endast åtta fält, vilket leder till att den blir endast 40 byte lång Detta leder till att storleken headern blir endast det dubbla, 40 byte istället för 20 byte, trots att den innehåller två adresser som är fyra gånger större[uipv6] Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address Destination Address Fig 1 IPv6 header [RFC 2460] Dom olika fälten i headern är version, traffic class, flowlabel, payload length, next header, hop limit, source adress och destination adress Version är ett 4 bitar stort fält som innehåller nummer 6 Traffic class fältet är 8 bitar långt, och kan användas för att skilja mellan olika klasser och typer av IPv6 paket, ungefär som 'Type of service' paketet i IPv4 Det 20-bit långa fältet 'Flow label' kan användas av sändaren för att ange vilka paket som hör till samma ström av paket en 7 En header är den del av paketet som kommer först, beroende på protokoll innehåller den olika information, men i headern finns ofta instruktioner på vad det är för paket, vart paketet är påväg och varifrån det kommer, jämför med till exempel en fraktsedel på ett 'vanligt' paket 8 En byte är 8 bit 8

9 ström identifieras unikt med en kombination av sändarens adress och en 'ström etikett' Flera olika aktiva strömmar kan finnas på samma gång mellan samma sändare och mottagare, man har då olika strömetikett för varje ström Strömetiketten bestäms av ett numeriskt värde mellan 1 och FFFFFF (hexadecimalt), detta värde får inte vara samma som andra strömetiketter som är eller har varit i användning Payload length fältet anger hur lång datan som följer efter IPv6-headern är Eftersom fältet är 16-bitar långt, begränsas längden på datan till 65Kbytes, men för att undgå det kan man använda en 'Jumbo Payload'-tilläggs header (för att ange att en jumbo payload extension header används läggs värdet '0' payload length fältet) (se nedan) Fältet next header anger vilken typ av header som kommer direkt efter IPv6 headern, dom vanligaste är TCP och UDP Formatet är det samma som för IPv4, och bestämdes av RFC 1700, se tabellen nedan för exempel Det 8-bitar långa fältet hop limit anger hur många gånger ett paket skall skickas vidare (jämför Time To Live i IPv4), varje gång ett paket skickas minskas värdet med 1 och när värdet blir 0 förkastas paketet Eftersom fältet är 8-bitar långt är det största värdet 255, alltså är det största antalet möjliga noder mellan 2 IPv6 värdar 254 Fälten source adress och destination adress är 128-bitar långa, och anger källan och destinationen på paketet Decimalt värde Nyckelord Protocol 0 HBH Hop-by-hop option 1 ICMP Internet Control Message (IPv4) 6 TCP Transmission Control 17 UDP User Datagram 43 RH Routing Header 44 FH Fragmentation Header 50 ESP Encapsulating Security Protocol 51 AH Authentication Header 58 ICMP Internet Control Message (IPv6) 60 DOH Destination Options Header Tabell 2 [IIwCR] För att minska på header storleken har man infört ett antal olika tilläggs headers Problemet med IPv4 är att det finns ett antal fält i headern som bara används ibland, men varje router måste kolla varje del av headern, för att kolla om det finns information som den måste göra något åt Detta gör att varje nod belastas extra, och det försvårar överföringen av information Eftersom största delen av paketen behöver en väldigt enkel header, använder man istället tilläggs headers Tilläggs headersen måste behandlas i den ordningen som dom förekommer i paketet, därför 9

10 rekommenderas det att man försöker använda dem i samma ordning så ofta som möjligt, RFC 2460 föreslår följande ordning: IPv6 header Hop-by-hop options header Destination options Routing header Fragment header Authentication header Encapsulation/Encrypted Security Payload header Destination options upper-layer header Varje tilläggs header, förutom destination options, får finnas endast en gång per paket Det första destination options fältet kontrolleras av alla noder som finns listade i routing headern, och det andra kontrolleras endast av den slutliga mottagaren Förutom den första destination options headern undersöks endast hop-by-hop headern av varje nod, eftersom den innehåller sådan information som behövs av varje nod, dom övriga används bara av sändaren och mottagaren 41 Hop-by-hop options header Hop-by-hop headern läses som sagt av varje nod paketet passerar, den innehåller information som varje nod behöver veta Hop-by-hop headern måste alltid vara placerad direkt efter IP headern, och för att ange att en hop-by-hop header används placeras värdet 0 i next header fältet på IP headern Next Header Hdr Ext Len Options Fig 2 Hop-by-hop header [RFC 2460] 10

11 Fältet next header fungerar på samma sätt som i IP headern, alltså det anger vilken typ av header som kommer som nästa Header extension length (Hdr Ext Len) anger längden på hop-by-hop headern i multipler av 8 byte 9 42 Destination options Destination options headern används för att ange en process som skall utföras av mottagar noden Eftersom destinations options headern också kontrolleras av alla noder på vägen kan man också ange instruktioner som skall utföras av dem Destination options headern innehåller endast tre fält: Option Type Opt Data Len Option Data Fig 3 Destination options header [RFC 2460] Option type fältet är 8 bitar långt, de två första bitarna anger vad noden som behandlar paketet skall göra om den inte förstår vad den skall göra med paketet 00 anger att den skall hoppa över denna header och fortsätta med nästa, 01 betyder att den skall kassera paketet Om de två översta bitarna är 10 skall den kassera paketet och, oberoende av vad mottagaradressen är, skicka ett ICMP 10 paket till sändaren för att berätta att den använder en okänd option type Om dom är 11 skickas en ICMP till sändaren och paketet kasseras, såvida mottagar adressen inte är en multicast adress Den tredje biten i option type fältet anger om option data får ändras (1) eller inte (0) under vägen De fem sista bitarna i fältet anger typen av option som används Option data length (Opt Data Len) anger i byte hur långt Option Data fältet är och Option Data fältet innehåller den specifika informationen som noderna behöver för att behandla paketet 9 Eftersom headern knappast kan vara tom, räknas längden på headern ut genom formeln (n1)*64, alltså värdet 0 betyder att headern är 64bitar lång, värdet 3 betyder att headern är 256 bitar lång osv 10 Internet Control Message Protocol, en utökning av IP-protokollet, används för att skicka felmeddelanden, test paket och annat relaterat till IP[FOLDOC] 11

12 43 Routing header Routing headern anger vilka noder paketet skall passera när det skickas Används till exempel för att ange vilken Internet service provider som skall användas Routing headern kan vara av olika typ, men för tillfället (enligt RFC 2460) finns det endast en specifierad, typ 0: Next Header Hdr Ext Len Routing Type=0 Segments Left Reserved Address[1] Address[2] Address[n] Fig 4 Routing header [RFC 2460] Fälten Next header och header extension length fungerar på samma sätt som för tidigare tilläggs headers Routing type har värdet 0 (eftersom det var en routing header av typ 0) och segments left anger hur många av de uppräknade adresserna som är kvar att besöka Adressen i adress-fältet används som destinations adress i IP headerns destinations adress fält, och routing headern kontrolleras inte före den kommer fram till den noden som är finns i destinationsfältet När en nod kontrollerar en routing header kontrollerar den först värdet i segments left fältet, om värdet är 0 går den vidare till nästa header (som anges i next header fältet) Om så inte är fallet tas följande 12

13 adress ur adresslistan och läggs som destinations adress, och paketet skickas vidare 44 Fragment header Fragment headern används av sändaren för att skicka paket som är större än det som normalt ryms i en frame 11 Till skillnad från IPv4 där routrarna på vägen skötte om fragmenteringen 12 sköts all fragmentering i IPv6 av den sändande noden Om en router stöter på ett paket som är för stort att skicka vidare gör den sändaren medveten om detta med hjälp av ett ICMP paket Den information som kan fragmenteras är den delen som inte behövs av varje nod, alltså alla tilläggs headers förutom hop-by-hop headern och den första destination options headern Allt det övriga kan fragmenteras, alltså delas upp och skickas i olika frames Fragmenteringen ignoreras av alla noder under sändningen förutom den sista, som 'lappar ihop' paketet igen Fragment headern består av 6 fält, och ser ut såhär: Next Header Reserved Fragment Offset ResM Identification Fig 5 Fragment header [RFC 2460] Next header används på samma sätt som övriga headers, det 8-bitar långa och det 2-bitar långa reserved fälten är reserverade för framtida bruk Fragment offset anger i 8 bytes delar på vilket avstånd från början fragmentet har Fältet M anger med en nolla om det är sista paketet och med en etta om det finns flera paket efter detta 45 Authentication Header Med hjälp av Authentication headern så kan både sändaren och mottagaren vara säkra på att informationens integritet sparas, och mottagaren kan vara säker på att paketet faktiskt kommer från rätt avsändare 11 En frame (ram) är dom paketen som skickas på data-link nivå enligt ISO-OSI modellen Största storleken på en ram, Maximum transmission unit (MTU) bestäms av vilket nätverksprotokoll man använder, till exempel ethernet (v2) har en MTU på 1500 bytes [FOLDOC] 12 Uppdelningen (av paket, i det här fallet) 13

14 Next Header Payload Len RESERVED Security Parameters Index (SPI) Sequence Number Field Authentication Data (variable) Fig 6 AH header [RFC 2402] AH består av fem olika fält (6 om man räknar med ett oanvänt, som ärreserverat för framtida bruk) Fältena är Next header, payload length, Security Parameters Index, Sequense Number Field och Authentication data Next header berättar (som för IPv6 headern) vilken typ av header som kommer som nästa, payload length anger totala längden på datan Security parameter index fältet är 32 bitar långt, består av en kombination av destinations adressen och security association, och är unikt för varje dataström Security parameter index fältet bestäms alltid av mottagaren Sequense Number Field anger vilket paket i ordningen det är frågan om Med hjälp av detta fält går det också att implementera skydd mot 'session reply' attacker (en hacker försöker ändra datan i ett IP paket och skicka det på nytt) Authentication data fältet innehåller integrity check value, och vilken algoritm som används anges i security parameters index fältet Integrity check value räknas ut på fälten som förblir oförändrade under sändningen, alltså fält som hop limit och flow label lämnas bort RFC2402 anger Hash Message Authentication Code (HMAC) med Message Digest no 5 (MD5) och HMAC med Secure Hash Algoritm no 1 (SHA-1) 14

15 46 Encrypted Security Payload Med hjälp av Encrypted Security Payload headern så krypterar man resten av IP-paketet, alltså det betyder att ESP-headern måste placeras sist, före själva datan Security Parameters Index (SPI) Sequence Number ~ Payload Data* (variable) ~ Padding (0-255 bytes) Pad Length Next Header ~ Authentication Data (variable) ~ Fig 7 ESP header [RFC 2406] Precis som i authentication headern bestäms security parameter index av mottagaren, och sequence number fungerar på samma sätt som i authentication headern I payload data fältet finns den krypterade datan Det finns två olika grader av kryptering, vilken som används bestäms i security parameter index fältet I 'transport-mode' krypteras endast transport datan och i 'tunnel mode' krypteras hela IP paketet I authentication data fältet finns integrity check value (se authentication headern ovan), och den räknas ut på hela ESP-paketet, förutom authentication data fältet, algoritmen som används bestäms i security parameter index fältet 15

16 5 Övergång till IPv6 För att en övergång från IPv4 till IPv6 skall gå smidigt, måste båda protokollen fungera parallellt, att samtidigt byta IP adress på varje dator ansluten till Internet är inte praktiskt genomförbart Ett av kraven vid planeringen var att administratörer och användare skulle tycka att det var lätt att övergå till IPv6 För att göra övergången enklare har det lagts fram ett par regler, Simple Internet Transition (SIT) Några av huvuddragen är att: det skall vara möjligt att uppdatera noder och routrar en åt gången, utan att andra noder måste uppdateras samtidigt när en router eller nod har uppdaterats till IPv6 skall den fortfarande klara av att använda IPv4 det inte får kosta mera och inget extra förarbete får krävas för att övergå till IPv6 SIT innehåller också ett par mekanismer för att göra övergången enklare, de är: möjligheten att skriva IPv4 adresser som IPv6 adresser en modell där routrarna och noderna som uppgraderas tidigt är både IPv4 och IPv6 kompatibla 'tunnel' tekniken där IPv6 paket kapslas in i IPv4 paket när routrar mellan noderna inte är uppgraderade [IIwCR] Tunneltekniken är den vanligaste i dag för IPv6 noder för att kommunicera med varandra och resten av nätverket Den går ut på att man helt enkelt placerar IPv6 paketen i IPv4 paket, 'ingången' på tunneln paketerar in paketet och 'utgången' paketerar upp paketet igen Man kan i princip dela upp dom olika tunnelalternativen i fyra olika delar: router-till-router, nod-till-router, nod-till-nod och router-till-nod IPv6 routrar sammanbundna med IPv4 infrastruktur kan tunnla IPv6 paket mellan varandra, IPv6 noder kan tunnla IPv6 paket mellan varandra över IPv4 nätverk 16

17 Källor [RFC 2460] [RFC 3513] [FOLDOC] [RFC 1519] [IIwCR] S Deering, R Hinden: RFC Internet Protocol, Version 6 (IPv6) Specification, December 1998 S Deering, R Hinden: RFC Internet Protocol Version 6 (IPv6) Addressing Architecture, April 2003 Free On-Line Dicitionary Of Computing, wwwfoldocorg V Fuller, T Li, J Yu, K Varadhan: RFC Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, September 1993 S Gay, Internetworking IPv6 with Cisco Routers, McGraw-Hill Education, Mars 1998 ( ) [RFC 2402] S Kent, R Atkinson: RFC IP Authentication Header, November 1998 [RFC 2406] S Kent, R Atkinson: RFC IP Encapsulating Security Payload (ESP), November 1998 [UIPv6] D Morton: Understanding Ipv6, PC Network Advisor, Maj 1997, ( ) [RFC 1700] J Reynolds, J Postel: RFC Assigned Numbers, Oktober