Förstudierapport IPv6

Transkript

1 Förstudierapport IPv6 För Inera och Sjunet Syfte: Syftet med förstudien är att säkra upp att Sjunet är på rätt väg och att alla anslutna kunder erhåller korrekt underlag och information för att i sin egen regi driva igenom en övergång till IPv6 med start under 2011 eller så snart som möjligt.

2 Rev. And distribution: Organisation Inera AB IPnett AB Name and function Leif Carlsson, beställare IPnett AB, leverantör Rev. and history Rev Date Change Responsibiliy Comments 1.0 IPnett AB First draft 1.1 IPnett AB Second draft Receivers / users of this document Organisation Inera AB IPnett AB Sjunets kunder & tjänsteleverantörer Description Primary user of the document Primary supplier of the document Secondary user of the document Approval Name Company Signature Lars Nilsson IPnett AB Leif Carlsson Inera AB Page 2 of 40

3 Table of content 1 Inledning Slutet för IPv4 är nära Bakgrund Metod Sammanfattning Tillvägagångssätt Slutsats Fakta och Teknik IPv6 Fakta Skillnader mellan IPv4 och IPv IPv6 adresser är 128-bit långa och representeras av hexadecimala tal Inledande nollor kan förkortas Typer av IPv6 adresser Unicast Global Unicast Address Unique Local Addresses Link Local Unicast adresser IPv4 mapped IPv6 Addresses Multicast adresser Anycast Loopback adresser Subnätmask DNS (Domain Name Server) ICMPv Neighbor Discovery Path MTU Discovery Multicast Listener Discovery (MLD) Felhanteringen i ICMPv Kontroll av nåbarhet (ping6 traceroute6) IPv6 tunnlar över IPv ISATAP Teredo to IPv4 tunnlar över IPv DS-Lite (Dual Stack-Lite) Konsekvenser och risker Kända problem med IPv Konsekvenser att vänta Page 3 of 40

4 4.3 Pågående upphandlingar etc Säkerhet Filtrering av ICMPv Tillvägagångssätt Vad behöver man för att lyckas Projektledare Inventering Utbildning Laborationer Genomförande Verifiera resultat Transiteringstekniker för IPv4 och IPv6 integration Dubbla Stackar (Dual Stack) CGNAT (Carrier-Grade NAT) Övriga transiteringsmekanismer En sömlös övergång med RFC Förslag på tillvägagångssätt för Sjunet Förslag på tillvägagångssätt för anslutna kunder i Sjunet RIPE Allokering Workshop Föreslagen adressering Nätskiss Nätskiss Resultat av intervjuer och utskick av frågeformulär Enkätsvar Slutsats Gratis online utbildningar och böcker Länkar och Referenser Tabell med Bilder Bild 1: IPv4 addresser på väg att ta slut Bild 2: IPv4 och IPv6 jämförelse av ramar Bild 3: Bilden visar en IPv6 adress uppbyggnad Bild 4: ISATAP tunnling mellan ISATAP klienter och genom en ISATAP router Bild 5: Ovan bild beskriver hur en ISATAP adress kan se ut Bild 6: Bilden illustrerar ISATAP kommunikation Bild 7: Kommunikation vid uppsättning av Teredo tunnel Bild 8: Ovan bild beskriver hur en 6to4 adress kan se ut Bild 9: Kommunikation vid uppsättning av 6to4 tunnel Bild 10: DS-Lite tunnlar IPv4 paket inom IPv6 pake Bild 11: IPSec ingår i IPv6 protokollet Bild 12: Sjunet IPv6 allokering Page 4 of 40

5 Bild 13: IPv6 Subnetting Bild 14: IPv6 Adress typer 1 Bild 15: IPv6 Adress typer 2 Bild 16: Nätskiss1 laboration IPnett AB Bild 17: Nätskiss2 laboration IPnett AB Page 5 of 40

6 Confidential 12/22/ Inledning 1.1 Slutet för IPv4 är nära Den 4 Mars 2011 är datumet då IPv4 adresserna är slut enligt den senaste prognosen från IANA som är högsta organet som hanterar IP adresser och ansvarar för utdelning av dessa till världsdelar. I Europa och Afrika (EMEA) hanteras IP adresstilldelning av RIPE och är i skrivande stund slut den 6 december Bild 1: IPv4 addresser på väg att ta slut 1.2 Bakgrund Anslutningstakten till Sjunet ökar och möjligheter att få tillgång till riktiga IPv4 adresser håller på att suddas ut. Detta kan få till följd att inkopplingshastigheten till Sjunet kan komma att stanna upp om man inte hittar alternativa sätt att ansluta nya kunder. Viktigt är att de alternativa sätt man kan utnyttja inte behöver göras om i framtiden. Utdelningen av IPv4 adresser är ett problem på grund av att adresserna börjar ta slut. Därför måste övergången till IPv6 inledas så snart som möjligt så att tempot på anslutningarna inte stoppas upp. IPv4 adresserna som i vår del av världen delas ut till Operatörer (Local Internet Registry eller LIR) från RIPE (se: håller snabbt på att ta slut. Eftersom samtliga anslutna enheter inom Sjunet använder IP-adresser baserad på IPv4 så är det svårt att erhålla nya adresser vid anslutning Page 6 of 40

7 av nya kunder idag. Totalt i hela världen finns idag endast 4 % av IPv4 adresserna lediga och de minskar i snabb takt. Detta gör att vi måste titta på hur vi kan säkra upp framtiden genom att påbörja övergången till IPv6. Detta material är tänkt att användas som underlag för förståelse av problematiken runt en övergång till IPv6 och av saker som måste utföras. Utmaningen alla står inför är att övertygas om att detta behövs. Majoriteten vet inte vad det är för skillnad mellan IPv4 och IPv6 och i de flesta fall saknas kunskapen om att IP i detta fall står för Internet Protocol. De flesta som känner till IP har mest praktisk erfarenhet av Internet Protocol version 4 (IPv4), naturligtvis för att det har varit den plattform som ensamt använts på Internet sedan dess födelse. Den senaste tiden har fokus på version 6 av protokollet ökat. Detta av anledning att IPv4 adresserna håller på att ta slut och därmed kommer det att bli problematiskt att ansluta nya kunder och tjänster i framtiden på Internet, vilket kommer att betyda samma sak för Sjunet. Slutet för IPv4 har annonserats länge och överlevnaden har hela tiden förlängts med nya tekniker för att spara på adresserna. Men nu är läget så akut inom EMEA och USA att till och med USA s president har engagerat sig i ämnet. I Europa trycker EU på att alla organisationer så snabbt som möjligt ska lägga resurser på att utföra en smidig övergång från IPv4 till IPv6. Asien ligger långt före övriga världen och har framgångsrikt tagit ledningen av införandet av IPv6. Även Universitetsnät världen över ligger i framkant då det gäller införande och utnyttjande av den nya standarden IPv6, som egentligen inte gör någon skillnad för den normala brukaren. Tillgången på adresser och det akuta läge som råder kan liknas lite av problematiken inför år 2000 och Millenniumbuggen. Tidpunkten för slutet är bara lite mer diffus. 1.3 Metod Metoder som använts i denna förstudie är intervjuer med personal från anslutna kunder samt tjänsteleverantörer, utskick av frågeformulär, informationssökande på Internet samt tekniska laborationer. Detta ger oss ett underlag för hur en övergång kan tänkas ske. Page 7 of 40

8 Confidential 12/22/ Sammanfattning 2.1 Tillvägagångssätt Eftersom antalet IPv4 adresser som kan delas ut i världen nästan är slut så är utmaningen att försöka förstå hur detta kan komma att påverka Sjunet, ansluta kunder och tjänsteleverantörer. Eftersom Sjunet har en hög anslutningstakt så är det av största vikt att framtida anslutningar inte bromsas upp av att det inte finns adresser att tillgå. För att ta reda på kunskapsnivån gjordes ett utskick bestående av ett frågeformulär. Detta för att ta reda på vart alla inblandade parter står och kunskapen runt detta ämne. Frågeformuläret besvarades av 25 utav totalt 34 utskickade och finns sammanställt under sektion 8 - "Resultat av intervjuer och utskick av frågeformulär". Ett par kunder besöktes också för att djupare diskutera ämnet och innehållet i rapporten. Frågeformulären tillsammans med besöken påvisar att man behöver beslut från beslutsfattare för att kunna genomföra och prioritera en övergång till IPv6. Beslut, direktiv, resurser och kompetens är det man upplever sig ha behov av för att iscensätta en övergång till IPv6. Detta dokument bör beskriva hur verkligheten egentligen ser ut och försöka hjälpa till så att resurser samt medel tas fram så att ett genomförande kan utföras innan problem uppstår. Denna rapport är tänkt att kunna användas av alla inblandade i det kommande arbete som alla står inför vid övergången från IPv4 till IPv Slutsats Skillnaden mellan versionerna är i huvudsak IP adressfälten som har utökats för att kunna adressera fler noder. Protokollet har även standardiserats vilket förenklar och snabbar upp hantering i nätverksutrustningar. Förutom förenklingen finns skillnader för att säkra upp kommunikationen med inbyggda möjligheter för kryptering av innehållet, samt också en förenklad funktionalitet för automatisk konfigurering av adresser. Förenklingen och att alla enheter kan erhålla egna riktiga IP adresser har gjort att säkerheten för den nya standarden har höjts. Alla undersökningar som vi funnit visar på att man bör göra en övergång till IPv6 genom att successivt införa IPv6 protokollet. Detta parallellt med nuvarande protokollstandarden IPv4 och noggrant iterera utrullningsprocessen genom laborationer och verifiering av resultat. Page 8 of 40

9 Intervjuer och besök visar att det finns bl.a. medicinsk utrustning som man inte helt enkelt ändrar på utan att drabbas av både höga kostnader och utdragna processer. Dessa problem löses enklast genom att ordna så att de gamla systemen kan kommunicera som vanligt. När de sedan skall ersättas bör nya upphandlingar kräva funktionsparitet mellan IPv6 och IPv4, dvs. funktioner som tillhandahålls på IPv4 skall även fungera på samma sätt på IPv6. Om inte funktionsparitet uppfylls skall det krävas en tidsplan på när det kan levereras. Risker som automatiska konfigurerade tunnlar kan innebära en säkerhetsrisk i införandet av Ipv6. Övergången bör ske genom att varje ansluten punkt och det centrala nätet först och främst färdigställs för att hantera IPv6 kommunikation. Detta innebär att alla funktioner för IPv6 och tillsammans med namnuppslag (Resolve DNS) information först måste finnas centralt, sedan på tjänsteleverantörers tjänster. En s.k. Bigbang är inte genomförbar i denna typ av nätverk. Varje ansluten kund och leverantör bör få en egen IPv6 tilldelning utifrån den allokering som redan delats ut till det egna LIR:et från RIPE med adressen 2a01:58/32. Vi visar i avsnittet Workshop hur en tilldelning skulle kunna gå till för alla anslutna kunder till Sjunet. Här har vi tilldelat varje kund två nät, ett laborationsnät och ett skarpt nät. Page 9 of 40

10 3 Fakta och Teknik 3.1 IPv6 Fakta Skillnader mellan IPv4 och IPv6 Bild 2: IPv4 och IPv6 jämförelse av ramar IPv6 adresser är 128-bit långa och representeras av hexadecimala tal En IP adress som är av version 4 består av fyra grupper av decimala tal där varje grupp representerar 8 bitar. Varje grupp bildar ett tal mellan 0 och 255 där varje tal separeras med en punkt och som tillsammans bildar en 32 bitar lång adress. En IPv4 adress kan t.ex. se ut på följande vis Detta ger ca 4.2 miljarder (2 ) unika ip adresser. Den största förändringen mellan en IPv4 och en IPv6 adress är längden. En IPv6 adress består av 128 bitar. Dessa bitar delas in i 8 grupper där varje grupp representerar 16 bitar. Varje grupp bildar fyra hexadecimala tecken där grupperna separeras med kolon. En IPv6 adress kan t.ex. se ut på följande sätt 21DA:00D3: FA61: FE68:0000:00FF:FE28:9C5A. Totalt kan IPv6 erbjuda ca 340,3 sextiljoner (2 ) unika IP adresser Inledande nollor kan förkortas Eftersom en IPv6 adress är väldigt lång och således komplicerad att både skriva och komma ihåg av oss människor kan en IPv6 adress förkortas genom att ta bort ett antal nollor. Inledande nollor i en grupp kan förkortas bort. Om en grupp om 16 bitar (eller 4 hexadecimala tecken) består av fyra nollor kan dessa helt uteslutas och skrivas ihop med två på varandra följande kolon. En IPv6 adressen som ser ut på följande vis Page 10 of 40

11 2a01:0058:0000:0000:0000:0000:6392:07ab/64 kan således förkortas på all dessa sätt 2a01:058:0000:0000:0000::6392:07ab/64 2a01:58:0:0:0:0:6392:07ab/64 2a01:58:0::0:6392:07ab/64 2a01:58::6392:07ab/64 2a01:58::6392:7ab/64 Dock är 2004::73ed::edaf/64 inte en giltig IPv6 adress eftersom man inte vet hur många 0000-grupper som har förkortats bort på vardera sida om dubbelkolonen. Sektionen av nollor kan bara förkortas om den endast består av nollor. Endast ett dubbelkolon "::" i talets representation är tillåtet. Bild 3: Bilden visar en IPv6 adress uppbyggnad Typer av IPv6 adresser Till skillnad från IPv4 där broadcast är en väldigt utbredd funktion så finns inte denna i IPv6. Tre kategorier av IPV6 adresser finns: 1) Unicast adresser - En unicast adress agerar som en identifierare av ett enskilt interface med en matchande unik adress. Ett IPv6 paket som sänds till en unicast adress levereras till det interface som identifieras av värdet i destinationsfältet. 2) Multicast adresser - En multicast adress agerar som en identifierare för en grupp av destinationer som alla är enskilda noder. 3) Anycast adresser - En anycast adress agerar som en identifierare för ett fång Interface som kan tillhöra olika noder. Ett IPv6 paket med destinationen Anycast levereras ett av de interface som identifieras av adressen Unicast En IP adress används som ett unikt id till t.ex. en dator. För att adressera data trafik så sätts en unicast IP adress som avsändare och en som mottagare. Denna typ av kommunikation är vanligast när en dator kommunicerar med en annan dator. Nedan fyra typer av unicast adresser finns tillgängliga: Global Unicast Addresses Unique Local Addresses (ULA) Link-Local Unicast Addresses IPv4 mapped IPv6 Addresses Page 11 of 40

12 Global Unicast Address Dessa adresser är de publika IPv6 adresser som delas ut av LIR. Dessa adresser är uppbyggda så att de alltid börjar på 2000::/ Unique Local Addresses Dessa adresser är IPv6 motsvarighet till IPv4 adresser som /8, /12, /16. Dessa kan t.ex. användas av ett helt företag eller organisation. Adresserna är uppbyggda så att de kan kommunicera internt men inte externt på Internet och behöver således inget publikt prefix. Routrar kommer inte att skicka vidare dessa adresser mot Internet utan endast hålla kommunikationen med dessa adresser inom företaget eller organisationen. Dessa adresser är uppbyggda så att de alltid börjar på FC00::/ Link Local Unicast adresser Dessa adresser tilldelas på varje enskild länk, typiskt ett Ethernet nätverk. Dessa behöver inte vara unika förutom på det egna nätverket. Routrar skickar inte vidare adresser som är av Link-Local typ utan dessa är endast avsedda att användas inom ett nätverkssegment. Dessa adresser är uppbyggda så att de alltid börjar på FE80::/ IPv4 mapped IPv6 Addresses Dessa adresser används för att inbädda IPv4 adresser i IPv6 adresser och kan se ut på följande sätt: ::FFFF: Dessa adresser är uppbyggda så att de alltid börjar med ::FFFF/ Multicast adresser Ett annat sätt att kommunicera på är Multicast. Vid Multicast kommunicerar t.ex. en sändare med flera mottagare. Multicast används till exempel vid videokonferenser eller bredbands-tv och kan se ut på följande sätt: FF01::2. Dessa adresser är uppbyggda så att de alltid börjar med: FF00::/ Anycast Den tredje och sista adresstypen är Anycast. En Anycast adress är egentligen bara en vanlig Unicast adress med skillnaden att samma adress finns på fler än en nod. Denna adresstyp är vanlig vid t.ex. lastbalansering Loopback adresser En loopback adress pekar på sig själv t.ex. den egna datorns nätverkskort. Detta är ett sätt att adressera sig själv och är användbart i många situationer. I IPv4 kan en loopback adress se ut på följande sätt Precis som i IPv4 finns det en motsvarande adress i IPv6. Denna ser ut på följande sätt: 0000:0000:0000:0000:0000:0000:0000:0001. Oförkortat så blir detta istället: :: Subnätmask I IPv4 har varje IP adress en tillhörande subnätmask t.ex Denna subnätmask identifierar nätverks ID respektive antal hostar som kan användas för nätverket. IPv6 använder sig också av en subnätmask men nätverks ID är inbyggt i IP adressen. För att tala om vad som är nätverksdelen i en IPv6 adress använder man sig av ett s.k. prefix. Prefixets längd i antal bitar skrivs ut efter IP adressen. Page 12 of 40

13 Nätverksadressen Första adressen: Sista adressen: 2a01:0058:1234::/48 2a01:0058:1234:0000:0000:0000:0000:0000 2a01:0058:1234:FFFF:FFFF:FFFF:FFFF:FFFF Detta nätverk kan alltså innehålla 2 unika adresser. Nedan beskrivs hur en IPv6 adress är uppbyggd av dess olika delar. Normalt används de första 48 bitarna som nätverksprefix. Nästa 16 bitar används som subnät ID och används definierar subnät. De sista 64 bitarna används till ändutrustning t.ex. datorer. Om det blir nödvändigt med fler subnät kan fler än 16 bitar användas för subnät ID. Detta brukar dock inte vara nödvändigt då 16 bitar subnät ID samt 64 bitar för t.ex. datorer ger olika subnät/vlan och kvantiljoner unika adresser för datorer eller ändutrustning. För beskrivning av IP adressens uppbyggnad se bild DNS (Domain Name Server) Inom IPv4 används Host (A) poster för att slå upp IP adress till dator/tjänstenamn vilket skulle kunna liknas med en dynamisk telefonkatalog. Exakt samma DNS:er gäller för IPv6 där Host (AAAA) poster används istället. På samma sätt som i IPv4 för reverse (in-addr.arpa) så finns det en ip6.arpa för bakåtuppslag dvs. IP adress till namnuppslag ICMPv6 Internet Control Message Protocol version 6 (ICMPv6) är IPv6 implementationen av ICMP. Det är den del av IPv6 protokollet som hanterar information och meddelanden mellan noder, t.ex. 'ping' ('ping6'). ICMPv6 är en mycket viktig och betydande del av IPv6 protokollet. ICMPv6 har i princip samma funktion som ICMP för IPv4 med nedan viktiga tillägg: Neighbor Discovery En funktion i ICMPv6 är Neighbor Discovery. Denna funktion möjliggör att en dator automatiskt hittar en ny användbar IPv6 adress. Funktionen kan även hitta och använda en ny gateway samt även byta till en bättre gateway om det dyker upp en som anses bättre på nätverket. Funktionen har även möjlighet att annonsera sina tjänster samt svara på tilltal när de efterfrågas gällande vilka funktioner och begränsningar den innehar. Den kan även lära sig närvaro av sina grannar samt vilka funktioner som de tillhandahåller. Hitta servrar och tjänster på nätverket är också en av dess funktion. Detta är en avsevärd förbättring jämfört med ICMPv4 och ger detaljerat dessa funktioner: Finna routrar på anslutna länkar Finna adress-prefix på anslutna länkar Finna ut vad största paketstorlek kan vara på alla länkar mellan källa och destination Autokonfiguration, s.k. Stateless konfiguration på nätverksinterface Mappning mellan IP adress och datalänk adress Finna ut var nästa nod är (Nästa router, next-hop) Page 13 of 40

14 NUD (Neighbor Unreachability Detection), Upptäcka när en granne på länken inte längre är nåbar DAD (Duplicate Address Detection), kontrollera så att erhållen eller kalkylerad adress inte kolliderar med andra på datalänken Gateway kan informera om en bättre väg mellan källa till destination Neighbor Discovery använder fem ICMPv6 pakettyper: Router Solicitation, ICMPv6 type 133. Router Advertisement, ICMPv6 type 134. Neighbor Solicitation, ICMPv6 type 135. Neighbor Advertisement, ICMPv6 type 136. Redirect, ICMPv6 type Path MTU Discovery Data överföringen på Internet fungerar som bäst när största möjliga paketstorlek används. PMTU Discovery är till för att hitta den största möjliga paketstorlek som kan användas vid data överföringen mellan två noder på Internet. I IPv6 till skillnad från IPv4 kan inte routrar på vägen ändra eller fragmentera (dela upp) paket, utan endast sändande nod kan fragmentera. Detta innebär att ett paket som är för stort för datalänken resulterar i att ett ICMPv6 packet too big sänds till avsändande nod. Problem som kan uppstå i och med detta är om t.ex. brandväggar inte tillåter ICMPv6 packet too big meddelanden till sändande noder. Alternativt om tunnlar inte sänder korrekt information. Detta kan vara ett möjligt problemområde i framtida Internet baserat på endast IPv Multicast Listener Discovery (MLD) ICMPv6 funktionen MLD påminner om IGMP för IPv4. MLD är till för att serva multicast prenumeranter på anslutna länkar. Protokollet är en del av ICMPv6 istället för ett eget protokoll som det är i IPv Felhanteringen i ICMPv6 Det finns fyra olika felmeddelanden som kan returneras till avsändaren då ett paket inte kan levereras till dess destination, dessa är: Destination Unreachable (ICMPv6 Type 1) Packet Too Big (ICMPv6 Type 2) Time Exceeded (ICMPv6 Type 3) Parameter Problem (ICMPv6 Type 4) Page 14 of 40

15 Kontroll av nåbarhet (ping6 traceroute6) Nåbarhet av t.ex. utrustning utförs med hjälp av echo request och echo reply som används av funktionerna ping och traceroute i IPv4 och av ping6 och traceroute6 i IPv6. Pakettyperna är: Echo request (ICMPv6 Type 128) Echo reply (ICMPv6 Type 129) IPv6 tunnlar över IPv4 En orsak till att det tagit så lång tid för IPv6 att bli en använd standard kan vara att det är stor skillnad mellan de två versionerna och kompatibilitet mellan dessa saknas. En övergång till IPv6 innebär nästan alltid att man behöver köra IPv4 och IPv6 parallellt i nätverket. Detta är en av anledningarna till att det har tagits fram ett antal olika tunneltekniker där IPv6 inbäddas i IPv4 för att transporteras mellan två IPv6 ändpunkter. På detta sätt kan två IPv6 enheter kommunicera med varandra över ett IPv4 nätverk som helt skulle kunna sakna stöd för IPv6. Det finns olika typer av dessa tunnlar, manuellt konfigurerbara och automatiska. Nedan beskrivs några typer av tunnlar som idag används. Konfigurerbara tunnlar måste konfigureras manuellt. IPv4 tunnel ändpunkt adresser samt IP routes måste i Windows konfigureras manuellt. Detta kan t.ex. göras genom att använda 'netsh' kommandot. Automatiska tunnlar är tunnlar som sätts upp automatiskt utan någon konfiguration. Tre vanliga automatiska tunneltyper är ISATAP (Intra-Site Automatic Tunnel Addressing Protocol), Teredo och 6to4. Dessa tunneltyper beskrivs nedan ISATAP Denna automatiska tunnelmetod används för att transportera IPv6 över ett IPv4 nätverk och kan endast användas där användare inte sitter bakom någon NAT (Network Address Translation) utrustning. För att ISATAP ska fungera så krävs det att det finns en ISATAP router implementerad med dubbla IP stackar (dual stack), dvs. stöd för både IPv4 och IPv6. Routerns uppgift är att hjälpa klienter vid automatkonfigurering och den fungerar som gateway för både IPv4 och IPv6 trafiken. Page 15 of 40

16 Bild 4: ISATAP tunnling mellan ISATAP klienter och genom en ISATAP router Bild 5: Ovan bild beskriver hur en ISATAP adress kan se ut De första 64 bitarna erhålls från ISATAP servern. Nästkommande 32 bitar är lika för alla ISATAP klienter och är 0000:5EFE. De sista 32 bitarna är klientens IPv4 adress. En ISATAP adress kan således se ut på följande sätt: 2004:af8:6392:7ab::5EFE: Bild 6: Bilden illustrerar ISATAP kommunikation Page 16 of 40

17 Teredo Teredo är en tunnelteknik som möjliggör tillgång till IPv6 för användare som sitter bakom en NAT utrustning. Denna tunnelteknik inkapslar IPv6 paketen i UDP paket istället för att göra det direkt i IPv4 som andra tekniker. I och med detta så är det möjligt att passera NAT utrustningar för dessa tunnlar med undantaget symmetrisk NAT. Vanligast bland utrustning som utför NAT är att dessa endast översätter TCP eller UDP trafik och måste konfigureras manuellt för att översätta övriga protokoll. Detta medför ett problem därför att IPv6 trafiken som färdas genom en brandvägg eller liknande som genomför NAT kommer nu att blockeras. Av denna anledning är Teredo designat till att istället inkapsla IPv6 paketen i UDP. Teredo använder sig av Teredo klienter, Teredo servrar samt Teredo relays för att åstadkomma en fungerande infrastruktur och samspel med IPv4. Bilden nedan illustrerar detta förfarande. Bild 7: Kommunikation vid uppsättning av Teredo tunnel Teredo Server En Teredo server är en nod som kan kommunicera på både IPv4 och IPv6. Denna hjälper Teredo klienter vid tunneluppsättning och IPv6 konfiguration samt initiering av datatrafik mellan Teredo klienter och IPv6 anslutna datorer. Servern är även ansvarig för att ta reda på vilken typ av NAT klienten använder sig av. Detta är viktigt eftersom adresstilldelningen och IPv6 kommunikationen beror av NAT typen i fråga. En Teredo server medverkar endast vid adresstilldelning samt stöd vid IPv6 kommunikation, den är alltså inte med i själva trafikflödet utan detta görs av Teredo Relays som beskrivs nedan. Teredo servrar lyssnar på UDP port Page 17 of 40

18 Teredo Klient En Teredo klient är en IPv4 eller IPv6 nod som stöder Teredo och kan åstadkomma en Teredo tunnel. Via denna tunnel kan en IPv6 klient kommunicera med andra IPv6 eller IPv4 klienter via s.k. Teredo relay servrar. Teredo är förinstallerat på t.ex. Windows Vista och framåt. Teredo Relay En Teredo Relay server är en IPv4/IPv6 router som kan skicka datatrafik mellan Teredo klienter både på IPv4 och på IPv6. I vissa fall samverkar alltså en Teredo relay med en Teredo server för att initiera kommunikation mellan Teredo klienter och IPv6 anslutna datorer. Teredo relay lyssnar på UDP port 3544 efter Teredo klienter to4 6to4 är liksom Teredo ett system för att automatiskt skapa tunnlar för IPv6 unicast kommunikation mellan IPv6 och IPv4. Till skillnad från Teredo så kräver 6to4 en publik IPv4 IP adress. 6to4 har även ett större adressutrymme (en /48) och mindre overhead jämfört med Teredo. 6to4 fungerar bäst med en 6to4 router som används vid det lokala nätverket. Routern använder sig av en publik IPv4 adress för att konstruera ett 6to4 prefix och agerar IPv6 router. Denna tilldelar IPv6 adresser till de klienter som är autokonfigurerade för 6to4 samt kapslar in och paketerar upp IPv6 trafiken som skickas till och från nätverket. 6to4 är precis som med Teredo tänkt till att användas tills dess att IPv6 finns så pass utbrett att IPv6 kan användas. Liksom Teredo finns 6to4 implementerat i Windows. Bild 8: Ovan bild beskriver hur en 6to4 adress kan se ut De första 64 bitarna i en 6to4 IP adress består av ett s.k. 6to4 prefix och börjar alltid med 2002::/16. Nästkommande 32 bitar utgörs av den publika IPv4 adressen. På så vis kan trafiken routas tillbaka till sändaren på samma sätt som i IPv4. Nästkommande 16 bitar innehåller subnät ID vilket gör att vi kan använda oss av olika subnät. 6to4 gör huvudsakligen tre saker Tilldelar ett block av IPv6 adresser till någon som har en publik IPv4 adress. Kapslar in IPv6 paket i IPv4 paket för att kunna skickas över IPv4. Routar trafik mellan 6to4 nätverk och IPv6 nätverk. För att transportera trafik mellan IPv4 och IPv6 används en s.k. 6to4 relay router. Denna router agerar sluss för alla 6to4 paket mot IPv4. Page 18 of 40

19 Bild 9: Kommunikation vid uppsättning av 6to4 tunnel IPv4 tunnlar över IPv DS-Lite (Dual Stack-Lite) DS-Lite hjälper IPv6 noder att nå IPv4 destinationer. Tidigare var det viktigaste att lösa så att IPv4 noder kan nå IPv6 destinationer, men nu när IPv4 adresserna snart inte längre kan delas ut så blir det allt viktigare att hitta en lösning som kan ge tillgång till IPv4 noder från IPv6 noder. Fördelen med DS-Lite är att tekniken kombinerar utrullningen av IPv6 med delning av IPv4 adresser, vilket uppmuntrar industrin att börja röra sig mot IPv6. Funktionen i DS-Lite när t.ex. en dator i ett kundnät sänder ett IPv4 paket till en extern destination så bäddas IPv4 paketet in i ett IPv6 paket för transport genom operatörsnätet fram till en s.k. CGNAT (Carrier-Grade Network Address Translation). I CGNAT så plockas IPv4 paketet ut och översätts till en public IPv4 adress innan leverans på det publika Internet sker. Denna teknik möjliggör att IPv4 privata nät kan kommunicera med IPv4 Internet över IPv6 infrastruktur. Ett annat namn för Carrier-Grade NAT är Large Scale NAT (LSN). I DS-Lite så använder alla kundanslutningar riktiga IPv6 adresser och kan använda privata IPv4 adresser som sedan används för att unikt mappa kunddator med externt delad IPv4 adress. Bild 10: DS-Lite tunnlar IPv4 paket inom IPv6 pake Page 19 of 40

20 4 Konsekvenser och risker 4.1 Kända problem med IPv6 Vad ser vi för risker med Ipv6? En risk är att man ställs inför en ny teknik och att man inte riktigt vet vad som kan hända vid införandet för att man saknar praktisk erfarenhet. Kända problem som t.ex. tunnlar som automatkonfigureras och trafik som går andra vägar än vad som är tänkt är bara exempel på problem man kan tänkas ställas inför. Vi har pratat med kollegor i branschen som har haft problem vid användning av Teredo tunnlar. Kollegorna har beskrivit hur plötsligt företagets lokala nätverk stannade upp och blev långsamt. Alla inblandade var tekniskt intresserade och laborerade på sin fritid hemma med IPv6 för att lära sig att förstå vilka problem man kan tänkas ställas inför. När dessa inblandade använde sina bärbara datorer hemma och på kontoret med IPv6 konfigurerat så började datorerna som var anslutna på kontoret att automatiskt konfigurera sig och hitta en Teredo tunnel hem till en av medarbetarnas hemmaserver som satt kopplad på en långsam DSL förbindelse som därmed blev default gateway för hela kontoret. 4.2 Konsekvenser att vänta En konsekvens man kan få av att vänta med en övergång till IPv6 är att viss övergång sker utanför ens kontroll. Windows, OS/X 10, Linux, Freebsd och de flesta varianter av PDA er stödjer redan IPv6 och kan kommunicera direkt ur kartong med IPv6. Dessa stödjer även autokonfigurering av IPv6 och vissa har även autokonfigurering av tunnlar som grundinställning. En annan konsekvens med att vänta med införandet är att det finns risk att resurser inte är nåbara från de delar av Internet som bara använder IPv6. En annan konsekvens är att om man inte börjar i tid så kan man hamna under resurs- och tidsbrist och tvingas migrera okontrollerat. 4.3 Pågående upphandlingar etc. Om det pågår upphandlingar på nätverksutrustning eller system som kommunicerar på IP så skall ett absolut krav vara att den nya lösningen kan använda sig av IPv4/IPv6 som standard. Ett bra sätt att hantera detta är att i sin upphandling kräva att det finns samma stöd för IPv6 som det finns för IPv4, s.k. funktionsneutralitet mellan de två protokollen skall gälla. Om detta inte kan uppfyllas av leverantören så skall de leverera en tidsplan då funktionsparitet kan uppnås. 4.4 Säkerhet Det är viktigt att säkerheten inte försämras vid införandet av IPv6. Krav på IPv6 stöd i all utrustning är ett steg att säkerställa detta, tillsammans med att noggrant kontrollera funktionaliteten innan införandet. Även stödet för automatiska tunnlar bör beaktas noggrant. IPSec funktionalitet finns inbyggt i IPv6 protokollet vilket medför en avsevärt säkrare dator-dator kommunikation samt minimerar risken för diverse attacker och intrång. Page 20 of 40

21 Confidential 12/22/2010 Bild 11: IPSec ingår i IPv6 protokollet Filtrering av ICMPv6 ICMPv6 spelar en grundläggande roll när det gäller att sätta upp samt upprätthålla pågående kommunikationer både mellan interface samt för sessioner till andra noder. Detta gör att en alltför aggressiv filtrering av protokollet i brandväggar kan få en förödande effekt på IPV6 kommunikationen medan även en alltför varsam filtrering av ICMPv6 protokollet kan innebära enorma säkerhetshål. Viktigt att tänka på när det gäller brandväggs- och filterhanteringen av ICMPv6 kontra hur ICMP hanteras idag är att ICMP idag ofta är blockat i brandväggar för att skydda sig emot diverse attacker som använder sig av ICMP. När det gäller hanteringen av ICMPv6 i brandväggar så kan man inte blockera dessa rakt av då de uppfyller en grundläggande funktion för IPv6 protokollet. Istället så finns IPSec funktionalitet inbyggt i protokollet som gör att risken för en ICMPv6 baserad attack kraftigt minskar. En generell regel är att man som ISP (Internet Service Provider) inte bör filtrera ICMPv6 meddelanden som transiterar genom sitt nät. Page 21 of 40

22 5 Tillvägagångssätt 5.1 Vad behöver man för att lyckas För att genomföra en lyckad migrering krävs först och främst att beslutsfattare tar ställning till och beslutar om en ev. migrering. Därefter krävs resurser som projektledning, utbildning, inventering och laborationer Projektledare En intern eller extern resurs som leder och startar upp projektet för att införa IPv6 adressering av datorer och nätverksutrusning m.m. Personen behöver kunna leda personal mot ett mål Inventering En noggrann inventering av all nätverksutrustning som sitter kopplade i alla portar och har en aktiv kommunikation mot någon annan nätverksutrustning. Enklast att finna är switchar, routrar, brandväggar, servrar och datorer. Svårare att hitta kan t.ex. vara sjukvårdsutrustning, hisslarm, brandlarm och passagesystem Utbildning Utbilda teknisk personal till den nivå som det finns behov av för att kunna kravställa eller genomföra tekniska konfigurationer Laborationer Bemanna personal för laborationer, skriva laborationsrapporter och redovisa resultat för införande efter tester Genomförande Utföra inkoppling och bl.a. konfigurera nätverksutrustning och datorer med IPv6. Detta kan man i de allra flesta fall utföra helt utan påverkan på den dagliga driften Verifiera resultat Stor del av tiden bör man lägga på att verifiera att allting fungerar som det är tänkt. 5.2 Transiteringstekniker för IPv4 och IPv6 integration Dubbla Stackar (Dual Stack) Ett alternativ är att låta IPv4 och IPv6 existera på alla ingående maskiner och nätverksutrustningar med s.k. dubbla stackar (dual stack). Detta innebär att datorer både kan kommunicera på IPv4 och IPv6. Erhåller en dator t.ex. ett IPv6 DNS svar så kommunicerar den med IPv6 och på samma sätt för IPv4. Största problemet med denna lösning är att den kräver lika många IPv4 adresser som det finns datorer på nätverket CGNAT (Carrier-Grade NAT) För att tillhandahålla tillväxten även när det inte längre finns IPv4 adresser att tillgå så kan man dela de IP adresser man redan har med alla sina kunder genom att tillhandahålla en NAT i Core nätet mot IPv4 destinationer. Det finns flera varianter av CGNAT, Dual Stack Lite (DS-Lite), NAT64 och NAT444 också kallad dubbel NAT som är de mest omtalade. De är lika varandra eftersom de alla delar en liten Page 22 of 40

23 mängd IPv4 adresser i pool för en stor mängd användare. Skillnaden ligger endast i hur respektive lösning hanterar CGNAT: NAT444 bärs över IPv4 NAT64 bärs över IPv Övriga transiteringsmekanismer Flera av nedan nämnda mekanismer har valts att utelämnas ur denna rapport. 4in6 6in4 6over4 6rd 6to4 AYIYA DS-Lite ISATAP Teredo TSP TRT SIIT 5.3 En sömlös övergång med RFC 2893 IETF specificerar i RFC 2893 hur man kan erhålla en sömlös övergång från IPv4 till IPv6, nedan kommer en enkel översättning av inledningen. Vi rekommenderar alla som vill veta i detalj hur en sömlös övergång till IPv6 kan gå till att noggrant läsa igenom RFC Nyckeln att lyckas med övergången till IPv6 ligger i kompatibilitet med den stora mängd utrustning som installerats med IPv4 i form av nätverksutrustning som t.ex. värddatorer och routrar. Att hela tiden ha kompatibilitet med IPv4 medan man rullar ut IPv6 sömlöst kommer att göra processen omärkbar för användarna. "Denna specifikation definierar ett antal mekanismer som datorer och routrar kan använda sig av för att bli kompatibla med IPv4 baserade datorer och routrar. Funktionerna är designade att utnyttjas av IPv6 klienter och routrar för att kunna kommunicera med gamla IPv4 tjänster och utnyttja IPv4 routing infrastruktur. Vi misstänker att de flesta noder på Internet kommer att behöva sådan kompatibilitet för en lång tid framöver kanske för alltid. Men IPv6 kan komma att användas även i miljöer där inte kompatibilitet med IPv4 kommer att behövas eller tas hänsyn till. Sådana IPv6 implementationer behöver inte använda dessa lösningar. Mekanismerna som man behöver använda sig av är: Dubbla IP stackar; En teknik för att tillhandahålla dubbel funktionalitet i alla noder och routrar, en stack för IPv4 och en stack för IPv6. Statisk konfigurerade tunnlar för IPv6 över IPv4 ; Punkt till punkt tunnlar som enkapsulerar IPv6 ramen i en IPv4 ram för att bära IPv6 informationen över IPv4 infrastruktur. IPv4-kompatibla IPv6 adresser; En IPv6 adress som har ett format så att en IPv4 adress är inbäddad i adressen. Automatisk tunnling av IPv6 över IPv4; En mekanism för att automatisk använda IPv4 adresser för att tunnla IPv6 över IPv4 nätverk. Page 23 of 40

24 Dessa mekanismer är definierade för att vara en del av en verktygslåda för att lösa en sömlös övergång för alla möjliga miljöer från IPv4 till IPv6. En växande samling verktyg att tillhandahålla för beslutsfattare och tekniker att fritt använda sig av och utnyttja där varje implementation själv bestämmer vilka tekniker som är tillämpningsbara för den egna organisationen. Denna RFC förutsätter att det kommer flera verktyg hela tiden för att underlätta övergången och specificerar endast de verktyg som finns i skrivandets stund, där nya RFC:er kommer att specificera framtida utvecklingar." 5.4 Förslag på tillvägagångssätt för Sjunet Vår rekommendation är att migreringen bör gå till på följande sätt: 1. Säkerställa att IPv6 aktiveras och adresseras i Sjunet från Leverantören TDC snarast. 2. Tilldelning av adressutrymme till alla anslutna CPE (Customer Premises Equipment), ett /47 per Landsting och ett /48 för alla de övriga anslutna är vårt nuvarande förslag. Detta bör ske så snart tilldelning bestämts i planerad Workshop den 19/ i labb hos IPnett AB. 3. Säkerställa att tjänsteleverantörerna i Sjunet genomför övergången till IPv6. Ett absolut krav på framgång är att man så snabbt det bara går kan nå tjänster på IPv6. För att det skall fungera måste leverantörerna i Sjunet leverera samma funktion på IPv6 som de redan gör i dag på IPv4. 4. Sammanställa kravlista på vad ny utrustning skall klara av. Vid inköp av ny utrustning bör en kravlista upprättas där ny utrustning eller funktion skall ha eller erbjuda samma funktion för IPv6 som de i dag gör för IPv4. Om detta krav inte kan följas skall differensen specificeras och en tidsplan upprättas för funktionsparitet på alla funktioner som används. 5.5 Förslag på tillvägagångssätt för anslutna kunder i Sjunet. Skapa ett projekt med detta dokument som underlag. 1. Tillsätt en projektledare som ser till att bemanna och driva projektet. 2. Tillsätt resurser internt från alla systemägare och berörda enheter. 3. Utbildning av berörda resurser och tilldela utrymme för praktiska laborationer. 4. Tillsätt egna eller externa resurser för att verifiera och inhämta information kring stöd i nätverksutrustning. 5. Laborera med adresseringen och funktioner i labb med det tilldelade adressutrymmet. 6. Anslut eget labb mot tjänsteleverantörer. 7. Skapa förutsättningar för att interna tjänster fungerar med både IPv4 och IPv6. 8. Kontrollera att säkerhetsutrustning kan hantera både IPv4 och IPv6. 9. Skapa förutsättning för adressutdelning med DHCPv Adressera system och namnge AAAA posttyper för interna domäner och nåbarhet av tjänster. 11. Adressera klientutrustning med IPv6 så att användande av tjänster med IPv6 som bärare möjliggörs. Page 24 of 40

25 12. Verifiera funktionaliteten noggrant. 13. Rulla ut funktionaliteten i lagom stora mängder så att säkerheten bibehålls. Page 25 of 40

26 Confidential 12/22/ RIPE Allokering Bild 12: Sjunet IPv6 allokering Första /48 kallas Global Routing Prefix och är en normal tilldelning vilket ger utrymme för olika subnät eller VLAN. Detta kan man t.ex. använda för separation av avdelningar, funktioner eller användare. I Sjunet finns en tilldelning utförd på allokeringen 2a01:58::/32 som är 2a01:50:20::/47 eller 2a01:0050:0020:0000:0000:0000:0000:0000 oförkortad. Denna är avsedd för att användas till Landstinget i Uppsala för sina lokaler, fastigheter, datorer, skrivare, servrar, PDA:er, hisslarmer, och telefoner m.m. RIPE Tilldelning route6: 2a01:58:20::/47 descr: Landstinget i Uppsala Lan origin: AS12782 mnt-by: SJUNET-MNT mnt-by: AS12782-MNT source: RIPE # Filtered Bild 13: IPv6 Subnetting Page 26 of 40

27 Confidential 12/22/2010 Bild 14: IPv6 Adress typer 1 Page 27 of 40

28 Confidential 12/22/2010 Bild 15: IPv6 Adress typer 2 Page 28 of 40

29 7 Workshop Fördela tilldelningen 2a01:58::/32 för hela Sjunet och anslutna kunder. Tilldelningen är tillräckligt stor för att räcka lång tid. Att tänka på är att fördela interna länkar för Sjunet i sig. Som exempel skulle 2a01:58:0000/48 skulle kunna vara användbart för detta. Ett antagande innan utförd workshop tillsammans med Inera är att de största 21 kunderna skulle vara enklare att adressera med /47 istället för /48 som annars är den vanligaste tilldelningen. Detta för att direkt i ett tidigt stadium tilldela ett labbnät för respektive kundanslutning. 7.1 Föreslagen adressering SJUNET Allocation 2A01:58::/32 skulle kunna fördelas enligt nedan tabell: SJUNET Infrastructure Alloc - 2A01:58:0::/47 SJUNET Infrastructure Prod - 2A01:58:0::/48 SJUNET Infrastructure Lab - 2A01:58:1::/48 SJUNET Customer 1 Alloc - SJUNET Customer 1 Prod - SJUNET Customer 1 Lab - SJUNET Customer 2 Alloc - SJUNET Customer 2 Prod - SJUNET Customer 2 Lab - 2A01:58:2::/47 2A01:58:2::/48 2A01:58:3::/48 2A01:58:4::/47 2A01:58:4::/48 2A01:58:5::/48 SJUNET Customer 3 Alloc - 2A01:58:6::/47 SJUNET Customer 3 Prod - 2A01:58:6::/48 SJUNET Customer 3 Lab - 2A01:58:7::/ SJUNET Customer X Alloc - 2A01:58:FFFE::/47 SJUNET Customer X Prod - 2A01:58:FFFE::/48 SJUNET Customer X Lab - 2A01:58:FFFF::/48 SJUNET Customer Site Example SJUNET Customer 1 Lab - 2A01:58:3:0::/64 vlan A SJUNET Customer 1 Lab - 2A01:58:3:1::/64 vlan B SJUNET Customer 1 Lab - 2A01:58:3:2::/64 vlan C SJUNET Customer 1 Lab - 2A01:58:3:3::/64 vlan D --- SJUNET Customer 1 Lab - 2A01:58:3:FF00::/64 p2p-1 SJUNET Customer 1 Lab - 2A01:58:3:FF01::/64 p2p SJUNET Customer 1 Lab - 2A01:58:3:FFFF::/64 p2p-x Page 29 of 40

30 7.2 Nätskiss 1 Bild 16: Nätskiss1 laboration IPnett AB Page 30 of 40

31 7.3 Nätskiss 2 TDC Loopbacks :db8:9998::/48 TDC Point-to-Point :db8:9999::/48 (made up with /64s starting with 2001:db8:9999:1::/64) LR1 Loopback 2001:db8:9998::1/128 Core :db8:9999:1::/64 :1 ge-2/0/2 :1 ge-2/0/5 :1 ge-2/0/ :db8:9999:5::/64 ge-0/0/0.500 :2 CPE- Sjunet 2A01:58:1::1/ :db8:9999:2::/64 :2 ge-2/0/3 EX2200 (L2) :2 ge-2/0/4 Core-2 LR2 Loopback 2001:db8:9998::2/128 LR3 - Loopback 2001:db8:9998::3/128 Core-3 :1 ge-2/0/ DNS DHCPv6 2A01:58:1::53/64 :1 ge-2/0/ :db8:9999:3::/ :db8:9999:4::/64 :2 ge-0/0/ SJUNET 2001:db8::/32 ( TDC simulated address space) :2 ge-0/0/ CPE-1 CPE-2 ge-0/0/2 vlan10-2a01:58:3:0::1/64 vlan20-2a01:58:3:1::1/64 vlan200 Kund 1 EX2200 (L2) Kund 2 ge-0/0/1 vlan200-2a01:58:5:ff00::2/64 vlan10 vlan20 ge-0/0/1 vlan200-2a01:58:5:ff00::1/64 Static routing EX4200 (L3) Client PC Client PC ge-0/0/2 vlan40-2a01:58:5:0::1/64 vlan50-2a01:58:5:1::1/64 EX2200 (L2) vlan40 vlan50 Client PC Client PC SJUNET Customer 1 Alloc - SJUNET Customer 1 Prod - SJUNET Customer 1 Lab - 2A01:58:2::/47 2A01:58:2::/48 2A01:58:3::/48 SJUNET Customer 2 Alloc - SJUNET Customer 2 Prod - SJUNET Customer 2 Lab - 2A01:58:4::/47 2A01:58:4::/48 2A01:58:5::/48 Bild 17: Nätskiss2 laboration IPnett AB Page 31 of 40

32 Confidential 12/22/ Resultat av intervjuer och utskick av frågeformulär 8.1 Enkätsvar Enkäten skickades ut till totalt 34 Landsting och Tjänsteleverantörer. Svar inkom från 25 av dessa. På de frågor där flera svar har kryssats för så har samtliga svar medräknats. Detta innebär att på vissa frågor är antalet svar fler än 25 och den procentuella fördelningen gjord i relationen till totalt antal svar. Vad vet ni om IPv6? Vet ingenting 0% Vet Allt 20% Hört talas om 80% När har ni tänkt införa IPv6? Inget Svar 42% Nu 11% Inom 1 år' 4% Inom 2 år 12% Inom 5 år 31% Page 32 of 40

33 Confidential 12/22/2010 Vad ser ni som svagaste länken i införandet av IPv6? Svårigheten att mot. Kostnade 39% Inget Svar 7% Ointresse 11% Ingen Support i tjänst som lev. 29% Avvakt Oper. 3% Avvakt Lev. 11% Kring vilka områden känner ni osäkerhet (IPv6)? Övrigt 6% Medicinsk Teknik 22% Egna kompetensen 25% Styrsystem, Larm 17% Nätverksutrust ning 12% Datorer,telefo ner, smartphones 18% Page 33 of 40

34 Page 34 of 40

35 Page 35 of 40

36 Page 36 of 40

37 Page 37 of 40

38 8.2 Slutsats Efter en sammanställning av de intervjuer och besök som utförts i samband med denna förstudie så pekar det sammanställda resultatet på att ett stort hinder ligger i att få införandet prioriterat. En annan reflektion är att även utbildning och kompetenshöjande åtgärder bör prioriteras. Ett hinder som upplevs är att det behövs klara och tydliga direktiv på att övergången till IPv6 skall genomföras inom en viss tidsperiod. En dialog med tjänste- och produktleverantörer bör även inledas inom en snar framtid. Successiv övergång Dubbla stackar Utnyttja övergångstekniker för att behålla svårlösta fall intakta Iterera utrullningsprocessen Kräv IPv6 stöd i upphandlingar, funktionsparitet Starta nu Page 38 of 40

39 9 Gratis online utbildningar och böcker 6DEPLOY - IPv6 Deployment and Support - Online Training RIPE NCC Training Courses - Online Training DAY ONE: EXPLORING IPV6 - Free IPv6 Book Page 39 of 40

40 10 Länkar och Referenser Page 40 of 40