Vägledning för införande av IPv6

Vägledning för införande av IPv6 Framtagen i samarbete mellan e-delegationen, Sveriges kommuner och Landsting samt Kommunförbundet i Stockholm Län

IT-FORUM 2 (19) Innehållsförteckning Innehållsförteckning... 2 Förord... 2 1 Inledning... 3 1.1 Revisionshistorik... 3 1.2 Syntax... 3 1.3 Dokumentbeskrivning... 3 2 Sammanfattning... 4 3 Bakgrund... 5 3.1 Historik... 5 3.2 Motivering till IPV6... 5 3.1.3 Utmaningar med införande av IPv6... 7 4 Konsekvensanalys IPv6... 9 4.1 Konsekvenser av ett icke-införande av IPv6... 9 4.2 Gällande svenska regler kring IPv6... 9 4.3 Operativa frågeställningar... 9 4.4 Risker vid införande... 10 4.5 Internationell jämförelse... 10 4.6 Vid utlokaliserad drift (outsourcing)... 11 5 Handlingsplan IPv6... 12 5.1 Definiera införandeplan... 12 5.2 Införande vid utlokaliserad drift (outsourcing)... 12 6 Praktisk införandeplan IPv6... 14 6.1 Genomför konsekvensanalys... 14 6.2 Resurser... 14 6.3 Inventering... 14 6.4 Införskaffande av adressrymd från operatör... 15 6.5 Testbädd... 15 6.6 Utbildning... 16 6.7 Dokumentation och rutiner... 16 6.8 IP-adressplanering... 16 6.9 Externa tjänster tillgängliga via IPv6... 17 6.10 Intern kommunikation via IPv6... 18 6.11 Drift och förvaltning... 18 7 Referenser... 19 Förord Denna vägledning är framtagen i samarbete mellan edelegationen, Sveriges Kommuner och Landsting (SKL) samt Kommunförbundet i Stockholms län (KSL) under sommaren 2010. Syftet är att ge den enskilda myndigheten, kommunen eller landstinget en handfast vägledning för att snabbt och smidigt kunna införa IPv6. Denna vägledning är en första version vilken vi har för avsikt att uppdatera vid årsskiftet 2010/2011. Tips på förbättringar, tillägg och ändringar skickas till info@edelegationen.se.

IT-FORUM 3 (19) 1 Inledning 1.1 REVISIONSHISTORIK Version Datum Beskrivning 0.1 2010-08-02 Tomas Rzepka Första draft 0.2 2010-08-03 Tomas Rzepka Infogat förändringsförslag från Andreas Nilsson och Thomas Nilsson samt utökat information punkt 4.5 IP-adressplanering. 0.3 2010-08-09 Carl Ljungqvist Lagt till sammanfattning etc. 0.4 2010-08-10 Carl Ljungqvist Konsekvensanalys och införandeplan på en övergripande nivå 0.5 2010-08-19 Andreas Nilsson Korrekturläsning och faktagranskning 0.6 2010-08-20 Carl Ljungqvist infogat förändringsförslag efter yttrande från KSL och e Delegationen. 0.7 2010-08-23 Carl Ljungqvist Internationell status med IPv6 0.8 2010-08-23 Thomas Nilsson Adderat SKL samt förord. 0.9 2010-08-23 Thomas Nilsson Uppdaterat innehållsförteckningen. 1.0 2010-08-26 Carl Ljungqvist Adderat vägledning vid outsourcing 1.1 2010-08-27 Carl Ljungqvist Korrektur av tillägg 1.2 Tomas Rzepka Förändringar och förtydligande kapitel 1.3, 3.2 och 6.3. Korrigerat referenser samt stavfel. 1.2 SYNTAX I dokumentet används ett system för texthänvisningar där varje hänvisning följs av ett nummer inom hakparenteser. Hänvisningarna beskrivs i referenslistan i kapitel 7. 1.3 DOKUMENTBESKRIVNING Dokumentet är skrivet med IT-strateger, IT-chefer, infrastrukturansvariga eller motsvarande som målgrupp. Det tar upp både den tekniska bakgrunden till IPv6 samt hur denna teknik skulle kunna införas i den egna organisationen. För en mer teknisk djuplodande beskrivning av IPv6 hänvisas den läsande till bl.a. källorna som finns i referenslistan i kapitel 7.

IT-FORUM 4 (19) 2 Sammanfattning Då antalet IP-adresser som kan delas ut i världen nu är närmast obefintligt, är behovet av att börja använda IPv6 större än tidigare. De IPv4-adresser som redan utdelats kommer inte bli ogiltiga, däremot kommer användare som bara får en IPv6-adress tilldelad till sig inte kunna nå IPv4-adresser. Behovet för en organisation att synas på Internet även med IPv6-adresser är sålunda allt viktigare. Det gäller i synnerhet att de viktigaste tjänsterna, som webb, mejl och DNS-servrar, publiceras utåt med IPv6- adresser. Anledningen till att IPv6 inte slagit igenom på allvar än är lite av ett moment 22-läge. Det finns idag få tjänster framtagna för att nås via IPv6, sålunda finns ingen efterfrågan på IPv6 och vice versa. I den inledande utrullningen av IPv6 (läs: de kommande 5-10 åren) kommer de två adressrymderna för IPv4 och IPv6 att samexistera. Detta kallas för dual-stack och måste kunna hanteras av aktuell utrustning. Att införa IPv6 i ett slag är en näst intill omöjlig uppgift och riskerar att göra övergången för stor för att hantera. Projektet bör därför delas upp i mindre delar. Innan arbetet med IPv6 kan börja, är det viktigt att kontrollera med aktuell ISP att de kan tilldela organisationen IPv6-adresser för internetåtkomst. Detta sker på samma sätt som för IPv4-adresser. En inventering av vilken utrustning som klarar av IPv6 behöver också göras, t.ex. om nätverksutrustning (switchar och routrar) klarar av att ha en IPv6-adress som administrationsgränssnitt och att brandväggen kan filtrera IPv6-trafik lika säkert som IPv4. Då IPv6-adresser är mycket längre än IPv4-adresser, är det mycket svårare att hantera dessa manuellt. Därför ställs det större krav på DNS-tjänster och förvaltningssystem av adressrymden.

IT-FORUM 5 (19) 3 Bakgrund IP version 6 är nästa generations informationsbärare för nätverksbaserad kommunikation över Internet och har främst tagits fram för att lösa den adressbrist som IP version 4 medför. IETF 1 har i IPv6 även sett till att göra förbättringar på en mängd andra punkter. 3.1 HISTORIK Internet Protocol (IP) har som funktion att se till att datorer på ett datornätverk kan kommunicera med varandra och utbyta data. Varje dator i ett nätverk baserat på IP tilldelas en unik IP-adress. När IPv4, den version av IP-protokollet som är mest utbredd idag, togs fram och blev en standard 1981 kunde man knappast förutse den explosionsartade användning av Internet som vi har idag. IPv4 använder 32-bitars adressrymd vilket ger maximalt 4 294 967 296 (2 32 ) adresser. På 1990-talet insåg man att adresserna snart skulle ta slut och tog då fram nya regler för hur adresser skulle delas ut (CIDR 2 ) samt en standard för hur en stor mängd datorer kan dela på ett mindre antal IP-adresser som kan kommunicera med Internet, kallad NAT 3. NAT var en temporärt effektiv lösning på problemet med adresstillgång, men trots detta håller IPv4-adresserna på att ta slut. Detta beror på att allt fler enheter kopplas upp mot Internet samt att användning av Internet ökar kraftigt i flera världsdelar som tidigare haft begränsad användning. IPv4-adresserna förespås av flera experter på området ta slut någon gång under 2011-2012[1]. IPv6 har tagits fram för att öka adressmängden, men även för att förbättra protokollet på flera andra punkter. Anledningen till hoppet direkt från v4 till v6, är att siffran 5 redan var upptagen i och med att man på 1970-talet tog fram ett protokoll kallat Internet Stream Protocol (ST, beskrivet i RFC1819) som då fick versionsnummer 5. 3.2 MOTIVERING TILL IPV6 IPv6 innebär främst dessa fördelar: Större adressmängd Effektivare informationsflöde Förbättrad säkerhet Framtidssäkerhet Större adressmängd 1 Internet Engineering Task Force Öppen organisation med arbetsgrupper för att ta fram standarder för kommunikation över Internet. www.ietf.org 2 Classless Inter-Domain Routing Ger större möjlighet att partitionera subnät i mindre delar än vad som var tillåtet tidigare. IETF RFC1518, RFC1519. 3 Network Address Translation Adressöversättning av publika IP-adresser (adresser routbara över Internet) till privata adresser (adresser icke routbara över Internet) och vise versa. NAT komplicerar vis typ av peer-to-peer kommunikation, exempelvis IPtelefoni eller VPN-förbindelser mellan företag och organisationer. IETF RFC 1918.

IT-FORUM 6 (19) IPv6 använder 128-bitars adressrymd vilket ger c:a 3,4 x 10 38 (2 128 ) adresser [2]. Detta innebär att det finns tillräckligt med unika adresser att tilldela alla enheter som ansluts till Internet med en eller flera unika IP-adresser utan att oroas över adresstillgången. Effektivare informationsflöde IPv6 effektiviserar informationsflödet bland annat genom följande funktioner. Vissa protokoll lägger till adressinformation i det egna protokollets data som information för mottagande part. Mellanliggande NAT-enheter måste i dessa fall förstå det specifika protokollet och implementera en ALG-funktion 4 för att översätta protokollets IP-data så att mottagande part kommunicerar tillbaka till en korrekt IPadress (IP-adress på NAT-enhetens nätverksgränssnitt som står närmast mottagaren). Exempel på protokoll där ALG krävs är FTP som används vid filöverföring och SIP som främst används inom IP-telefoni. I och med att adressöversättning (NAT) inte behöver tillämpas med IPv6 underlättar det kommunikation för en mängd olika tillämpningar.[3] IP-huvudet i IPv6 är förenklad så att routrar i nätverket inte behöver hantera kalkylering av kontrollsummor på paket då detta oftast redan är implementerat i transportprotokoll som TCP 5. I och med att användning av PMTU 6 är obligatoriskt i IPv6 behöver inte mellanliggande routrar hantera fragmentering. [4] Förbättrad säkerhet IPv6 är i sig inte säkrare än IPv4. Dock så finns några tilläggsfunktioner som gör IPv6 säkrare om dessa implementeras. IP Security (RFC4301)[5] ett krav för att en nod skall räknas som IPv6 kompatibel (RFC4294). IP Security (IPSec) har länge varit en etablerad standard för krypterade anslutningar över Internet, dock i form av ett tillägg ovanpå IPv4-stacken. Att IPSec är införlivat i standarden för IPv6 påskyndar spridning av protokollet till andra typer av enheter som skrivare och smarta telefoner samt att behovet av tredjepartsapplikationer minskar då funktionen byggs in i operativsystemets IP-stack. Attacker mot Neighbor Discovery Protocol (NDP) kan säkras med SEcure Neighbor Discovery (SEND). Liknande förslag har funnits för IPv4 men aldrig blivit en standard. För kommunikation mellan enheter som sitter på samma länk nät används i IPv4 Adress Resolution Protocol (ARP). I IPv6 har detta ersatts av Neighbor Discovery Protocol (NDP) som fungerar på liknande sätt. Både ARP och NDP kan enkelt attackeras så att utrustning i nätet matas med felaktig adressinformation, så kallad ARP/NDP poisoning. Detta leder i sin tur till att trafik skickas till en angripande part som har för avsikt att avlyssna kommunikationen. Protokollet SEcure Neighbor Discovery (SEND) kan användas istället för NDP i IPv6. SEND säkerställer kryptografiskt integriteten 4 Application Layer Gateway Funktion skriven för specifikt applikationsprotokoll för att inspektera/förändra data i kommunikationsflödet. 5 Transport Control Protocol - Förbindelse orienterat dataöverföringsprotokoll. IETF RFC793. 6 Path MTU discovery Teknik för att mellan två noder hitta den största möjliga paketstorleken. IETF RFC1981.

IT-FORUM 7 (19) på informationen som erhålls från nätverksgränssnittet om andra enheter på samma länk nät.[6] Tyvärr har SEND ännu inte implementerats i någon större utsträckning, exempelvis så saknas det stöd för SEND i Microsofts operativsystem Windows. RIPE håller på att ta fram ett stöddokument för vilka säkerhetsfunktioner IPv6 utrustning skall ha för att motverka exempelvis Man-In-The-Middle attacker [7]. Detta dokument kan användas vid kravställning vid inköp av utrustning. Framtidssäkert Förutom den nästintill obegränsade adressrymden ger standarden även möjlighet till utökning av protokollet. Detta gör IPv6 flexibelt och ny funktionalitet kan adderas inkrementellt, utan att skapa en ny version av IP-protokollet [4]. 3.1.3 Utmaningar med införande av IPv6 Införande av IPv6 innebär en del utmaningar. I detta avsnitt listas några av de större punkter som är värda att notera. Kan organisationens Internetleverantör tillhandahålla IPv6? Det är inte alla Internetleverantörer som kan tillhandahålla IPv6 [8]. Därför är det i ett tidigt skede viktigt att kontrollera att detta är möjligt samt vilken leveranstid leverantören kan utlova. Om IPv6 inte kan tillhandahållas och leverantören inte har några planer på att införa detta inom den närmaste tiden, kan det vara nödvändigt att upphandla en ny Internetleverantör. Alternativt kan tunnling 7 användas för att inkapsla IPv6 över IPv4 till en annan operatör, men detta är ingen hållbar lösning på längre sikt. Samexistens mellan IPv4 och IPv6 IPv4 kommer att leva kvar långt tid framöver på grund av interoperabilitetskrav med äldre applikationer och de många resurser på Internet som inte kan hantera IPv6. För att lösa övergången till IPv6 används en så kallad dual-stack där noderna i nätverket implementerar både IPv4 och IPv6. Om en nod vill kommunicera med IPv4 adress, används IPv4-stacken. Vill noden kommunicera med IPv6 adress, används IPv6- stacken. Noderna har således en eller flera samtidiga IPv4 och IPv6 adresser [9]. Detta medför att infrastrukturens konfiguration blir mer komplex och därmed försvåras även felsökning av kommunikationsproblem. Stöd för IPv6 på applikations- och nätverksnivå För att IPv6 skall ge en positiv nyttoeffekt måste protokollet samexistera och interagera med nätverksinfrastrukturen och de applikationer organisationen använder. Inventering och tester av berörda komponenter är viktigt för att minimera 7 Tunnlar Paket som av anledning inte kan överföras till mottagare på normalt sätt inkapslas i ett annat paket ger möjlighet att överföra informationen. I detta fall inkapslas IPv6 paketen i IPv4 paket för att nå sin mottagare då det ej finns någon bärare för IPv6. På andra sidan tunneln extraheras IPv6 paketet from IPv4 paketet och skickas ut på bärare för IPv6.

IT-FORUM 8 (19) negativa effekter vid införande av IPv6. Aktiva nätverkskomponenter som routrar och brandväggar måste hantera IPv6 på samma sätt som IPv4. Äldre nätverkskomponenter kan behöva ersättas. Server och klientapplikationer skall inte störas av dual-stack implementation och måste vid införande eller inom en överskådlig framtid kunna kommunicera över IPv6. Upprätthålla säkerheten i nivå med IPv4 Det är viktigt att säkerheten inte försämras vid införande av IPv6. De säkerhetsfunktioner som är implementerade med IPv4 måste ge samma skydd efter införande av IPv6, något som är långt ifrån självklart. Ett vanligt exempel bland säkerhetsprodukter är att enheten kan adresseras med IPv6 men att säkerhetsfunktionerna inte kan analysera och blockera skadlig trafik. Det är därför viktigt att vara noggrann med att begära en lista över funktioner som stöder eller inte stöder IPv6. Det är också viktigt att analysera användning av IPv6-tunnlar, vilka i värsta fall kan kringgå de befintliga säkerhetsfunktioner som finns implementerade. IPv6-tunnlar ger noder som enbart har en IPv4-adress möjlighet att kommunicera med IPv6 noder genom att inkapsla IPv6-paket i IPv4-paket och skicka dessa till en speciell nod som sedan extraherar IPv6-paketet och skickar det till mottagaren över ren IPv6. Detta implementeras som standard i senare versioner av Microsofts operativsystem, som Windows Vista och Windows 7. [10] Administrativa gränssnitt för IPv6 funktioner Man bör kontrollera att produkter med IPv6 stöd även ger ett likvärdigt administrativt gränssnitt som vid administration av IPv4. Produkters VANLIGA gränssnitt kan i vissa fall inte vara uppdaterat och användaren hänvisas till att administrera IPv6- funktionalitet via konfigurationsfiler eller kommandotolk (CLI), något som kan försvåra det dagliga arbetet. Högre krav på DNS infrastruktur IPv6-adressernas längd gör att DNS blir en än viktigare funktion i infrastrukturen. En välordnad DNS-struktur för både klienter, servrar och annan utrustning är en förutsättning för framgångsrik användning av IPv6, likaså att organisationens DNS har hög tillgänglighet. Väl ordnad namnstandard underlättar support och felsökning, DNS information bör registreras för all utrustning med IPv6 adress. Likväl så bör inte IPv6-adresser registreras för tjänster som inte är driftsatta med IPv6. Om en klient med dual-stack har IPv6 påslaget och som preferens över IPv4 och får DNS-svar innehållande IPv6 information kommer klienten att ansluta via IPv6. Om klienten inte kan ansluta till servern över IPv6 skall den gå tillbaka till IPv4. Processen kan dock ta tid och upplevas som långsam av användaren. DNS-poster med IPv6 information skall således inte publiceras innan tjänsten har en för alla klienter nåbar IPv6 adress.

IT-FORUM 9 (19) 4 Konsekvensanalys IPv6 Konsekvensen av att vänta för länge med att införa IPv6 i en organisation kan bli att berörda aktörer tvingas ta till skyndsamma åtgärder med risk för mindre bra lösningar. Därför bör myndigheter verka för att genomföra konsekvensanalyser för införande av IPv6 snarast. De operativa konsekvenserna bör beaktas utifrån den aktuella organisationens administrativa och tekniska infrastruktur. Utöver de punkter som är beskrivna i avsnitt 3.1.3 ovan, så listas ett antal områden som bör analyseras inför ett införande. 4.1 KONSEKVENSER AV ETT ICKE-INFÖRANDE AV IPV6 Den definitiva konsekvensen av ett icke-införande av IPv6 kommer vara att organisationens resurser inte är nåbara från de delar av Internet som bara använder IPv6-adresser. Det går heller inte att nå de tjänster som enbart publiceras över IPv6. Det finns ett antal riskområden med att inte stödja IPv6 som bör analyseras inklusive: att externa parter som enbart har tillgång till IPv6 inte kan nå organisationens tjänster (t.ex. webb, e-post och DNS) att organisationen inte kan nå IPv6-baserade nätverkstjänster att organisationen får mindre tid för utbildning och att få driftserfarenhet av IPv6 och därmed möjlighet att eventuellt upptäcka vad som måste korrigeras för att fungera med IPv6 vilka tjänster och system som idag kräver IPv6 för att fungera fullt ut huruvida aktuell ISP kan leverera fler IPv4-adresser vid behov 4.2 GÄLLANDE SVENSKA REGLER KRING IPV6 Området regleras idag inte i svensk rätt (enligt Regeringskansliets Faktapromemoria 2007/08:FPM126). 4.3 OPERATIVA FRÅGESTÄLLNINGAR Följande frågeställningar bör besvaras inför ett införande av IPv6. Interna nätverksprojekt, upphandlingar etc. Om det pågår upphandlingar av inköp av nätverksutrustning, är IPv6 medtaget som ett krav på den nya utrustningen? Kan ett projekt för att införa IPv6 samexistera med pågående nätverksprojekt eller måste projektplanerna göras om? Befintlig IT-infrastruktur, nätverk och applikationsportfölj Vilka är konsekvenserna av inventeringen enligt kap. 6.3 (nedan) vid ett beslut att införa IPv6? Resultatet av inventeringen ger förutsättningar för fortsatta kostnadsberäkningar och tidsplanering. Om krav på IPv6-stöd finns vid ordinarie upphandlingstillfälle för en organisation, som sker i cykler baserade på teknisk och/eller ekonomisk livslängd, uppstår ingen merkostnad, vilket det däremot gör om man är tvungen att genomföra en extra upphandling i förtid för att tillmötesgå kravet på IPv6.

IT-FORUM 10 (19) Prioritering vid stegvis införande En kostnads-/nyttoanalys kan genomföras för att utreda vilka tjänster som skulle lida mest av att inte kunna nås via IPv6? Vilket mervärde skulle IPv6 kunna tillföra inom områden som säkerhet administration routing mobilitet trafikprioritering Kan införandet ske på ett sätt som möjliggör dual stack, det vill säga samexistens av IPv4/IPv6 i samma nätverk? Utbildning av medarbetare Kunskapsnivån hos medarbetarnas som skall planera/införa/administrera/förvalta IPv6 bör inventeras. Vilken utbildningsinsats krävs och hur och var kan den genomföras? Nya förvaltningsrutiner; stöd för IPv6 i förvaltningssystem Klarar de aktuella stödsystemen och rutinerna av att hantera IPv6-adresser? Hur hanterar organisationen administrativt de nya, mycket större IP-adressrymderna? 4.4 RISKER VID INFÖRANDE Precis som med andra typer av införandeprojekt, är det viktigt att innan projektstart ta reda på vilka risker finns det under tiden ett införande av IPv6 pågår och vad kan göras för att minimera dessa samt ta fram reservplaner. 4.5 INTERNATIONELL JÄMFÖRELSE För många företag i Sverige, som är ett exportberoende land, är det viktigt att kunna nås via IPv6. Det är främst i Asien och Sydamerika som IPv6 växer fortast 8, och där är det inte alltid säkert att man kan nå IPv4-baserade tjänster. Sålunda måste även svenska organisationer stödja IPv6 för att fortsätta kunna ta emot e-post från asiatiska eller sydamerikanska kontakter eller visa upp sin webbplats för dessa användare. I USA är det sedan juni 2008 obligatoriskt för amerikanska myndigheter att stödja IPv6. Detta efter ett beslut av Office of Management Budget i augusti 2005 9. Inom EU är det ett mål att få 25% av de europeiska användarna på Internet att använda IPv6 under 2010 enligt en handlingsplan för införandet av IPv6 i Europa (kallad KOM(2008) 313). I denna konstateras att det är angeläget att Internetvärlden förmås övergå IPv6 då en övergång till IPv6 möjliggör utökade industriella tillämpningar av Internet som kan bidra till tillväxt och sysselsättning. 8.SE, http://ipv6forum.se/ 9 Memorandum M-05-22, Transition Planning for Internet Protocol Version 6 (IPv6),

IT-FORUM 11 (19) 4.6 VID UTLOKALISERAD DRIFT (OUTSOURCING) Det som ovan skrivits om att utföra en konsekvensanalys för den egna organisationen vid införande av IPv6, är lika tillämpligt när organisationen har sin drift utlagd på annan part (outsourcing). Den största risken vid införande av IPv6 i en utlokaliserad miljö, är att driftparten inte har (eller tänker skaffa sig) stöd för IPv6. Detta bör kunna undvikas genom att man som beställare har krav på stöd för IPv6 vid upphandling (eller omförhandling) av sin driftmiljö. En annan risk är att driftparten inte kan separera kundernas driftmiljöer tillräckligt väl, vilket innebär att även om stöd finns, går detta inte att införa i praktiken då många andra kunder kommer att drabbas av förändringarna. Genom att kräva en egen instans i driftmiljö borde detta kunna undvikas. Observera att det kan vara relevant att be om IPv6-referenser från driftleverantören: om de har erfarenhet av tekniken, andra IPv6-kunder etc.

IT-FORUM 12 (19) 5 Handlingsplan IPv6 Införande av IPv6 kräver utbildning, planering och ett väldefinierat mål för att övergången skall bli lyckad. Målbilden ur ett kortare perspektiv, liksom tidsplanen, kan variera mellan organisationer, men fullständigt kompatibilitet med IPv6 inom en överskådlig tid bör vara det slutliga målet. Enligt SOU 2010:20 [11] innebär det troligen att om man väntar för länge med att påbörja införandet av IPv6 kan det uppstå situationer där berörda aktörer tvingas ta till skyndsamma åtgärder med risk för mindre bra lösningar. Därför bör myndigheter verka för att genomföra konsekvensanalyser för införande av IPv6 snarast. 5.1 DEFINIERA INFÖRANDEPLAN Ett införande av IPv6 i ett slag är en näst intill omöjlig uppgift och riskerar att göra övergången för stor för att hantera. Dra istället nytta av att IPv4 och IPv6 kan samexistera och inför IPv6 stegvis. Det mest effektiva sättet att driva införandet av IPv6 är att göra det i projektform med tydliga delmål och tidsplan. Nedan är ett förslag till hur ett införande av IPv6 kan gå till. De respektive punkterna utvecklas närmare i kap. 6. 1. Genomför konsekvensanalys av ett IPv6-införande. Stöd för detta finns ovan i kap. 4. 2. Avdela resurser för ett införande av IPv6. 3. Genomför en inventering av utrustning och applikationer. 4. Införskaffa en IPv6 adressrymd från Internetleverantören. 5. Om möjligheten finns, sätt upp ett testnät/testbädd där funktionaliteten kan testas om osäkerhet finns för nivå av IPv6-stöd i system eller applikationer. 6. Vid behov, utbilda den personal som ska utföra konfigurationen av IPv6. 7. Se över dokumentation och rutiner kring hantering av IPv6. 8. Gör en IP-adressplanering, både för den externa och interna infrastrukturen. 9. Baserat på resultatet av konsekvensanalysen prioritera vilka externa tjänster som ska kunna nås över IPv6. Exempel på tjänster är a. DNS b. E-post c. Publik webbsida/e-tjänster 10. Inför IPv6 för den interna kommunikationen: a. Tilldela servar och klienter IPv6 adresser b. Internetåtkomst för klienter via IPv6 (för att nå externa tjänster). c. Migrera interna applikationer till IPv6 steg för steg. 11. Fullfölj migreringen mot IPv6 5.2 INFÖRANDE VID UTLOKALISERAD DRIFT (OUTSOURCING) Innan IPv6 införs när driften är utlokaliserad bör punkten 1) genomföras av den beställande organisationen, helst i dialog med driftparten.

IT-FORUM 13 (19) Införande av IPv6 för enbart de externa tjänsterna/kommunikationen ska inte påverka den interna driften. Det viktiga är att de externa tjänsterna som beställaren önskar av driftparten blir nåbara över IPv6, fortfarande ska vara nåbara över IPv4, samt att driftparten kan påvisa att inga säkerhetsproblem uppstår i och med att trafiken adresseras som IPv6. Hur det kan realiseras omfattas troligen av driftavtalet mellan parterna. Vid införande av IPv6 i den interna miljön, bör beställaren och driftparten i samråd genomföra en plan för utrullningen.

IT-FORUM 14 (19) 6 Praktisk införandeplan IPv6 Andra guider för att införa IPv6 finns framtagna, bland annat.ses rapport Att går över till IPv6 [12]. 6.1 GENOMFÖR KONSEKVENSANALYS En konsekvensanalys genomförs för att skapa ett underlag till hur införandet av IPv6 skall genomföras och förutse risker mm med införandet, se kapitel 4. 6.2 RESURSER Införandet av IPv6 påverkar IT-verksamheten i olika utsträckning. Ansvariga tekniker för nät, säkerhet, server, klient och applikation bör vara delaktiga i projektet. Specialistkonsulter kan allokeras för att förstärka kompetens eller förkorta tiden för införandet. En kontaktlista bör upprättas med varje individs ansvar och åtagande och spridas till alla deltagare i projektet. En tidplan för de olika momenten tas med fördel fram. Utsedd projektledare följer kontinuerligt upp att tidsplanen följs och vidtar åtgärder om så inte är fallet genom att allokera ytterligare resurser eller modifiera tidplanen. 6.3 INVENTERING Inventering och tester av berörda komponenter är viktigt för att undvika negativ påverkan på organisationen och dess tjänster vid införande av IPv6. Inventeringens omfattning beror på vilka komponenter som berörs. Exempel på frågeställningar vid inventering Funktion Övergripande Nätverk Frågeställning Vilken kompetens krävs vid införandet? Hur långvarigt blir driftstoppet vid införande på berörda komponenter/funktioner? Internetleverantör Kan IPv6 levereras? När kan tjänsten levereras? Brandvägg VPN E-postrelä/filter Webbfilter IPS Antivirus I vilken utsträckning hanteras IPv6? Bibehålls säkerhetsfunktionalitet? Är administrationsgränssnitt likvärdigt som vid hantering av IPv4-trafik? Omfattar produktdokumentationen IPv6?

IT-FORUM 15 (19) VPN/MPLS 10 Berörs mobila VPN-klienter? Berörs användare på fjärrkontor via fast/mpls-tunnel? Berörs konsulter och andra externa leverantörer som ansluter via VPN? Router/Layer 3 switch 11 Kan IPv6 hanteras i routern? Hanteras routingprotokoll för IPv6 såsom RIPng, OSPFv3 och MBGP 12? Finns tillräckligt med RAM-minne för att hantera de större routing-tabeller som IPv6 innebär? Är DHCP reläfunktion IPv6 kompatibel? Switch Kan switchadress sättas med IPv6-adress för administration? Operativsystem Server och klient Hanterar operativsystemet IPv6? Vilka anslutningar prioriteras högst, IPv4 eller IPv6? Applikationer Serverapplikationer Kan serverapplikationerna sätta upp IPv6- lyssnare? Klientapplikationer Kan klienter ansluta till en IPv6 serveradress? Hanterar klientapplikationerna DNS AAAA svar (IPV6 motsvarande IPv4 A post)? För nätverksutrustning kan även RIPEs dokument Requirements For IPv6 in ICT Equipment användas som stöd [7]. 6.4 INFÖRSKAFFANDE AV ADRESSRYMD FRÅN OPERATÖR Införskaffande av en IPv6-adressrymd från operatören bör kunna ske på samma sätt som vid anskaffning/utökning av befintliga IPv4-adresser. Aktuell ISP (Internet Service Provider) har förmodligen en aktuell beställningsrutin. Om aktuell ISP inte kan förse anslutningen med IPv6-adresser, är det lämpligt att be om en leveranstidsplan eller överväga att byta ISP. Det är viktigt att kontrollera att ett korrekt SLA (Service Level Agreement) kan kopplas till IPv6-trafik på samma sätt som för IPv4-trafik. 6.5 TESTBÄDD Om möjlighet finns bör tester utföras i testmiljö för de system som påverkas av införandet av IPv6. Detta för att tidigt hitta eventuella fel och brister som kan påverka 10 MPLS - Multiprotocol Label Switching. Teknik som används av operatörer för att skapa virtuella nät i operatörens nät som kommunikationsmässigt knyter ihop två eller fler platser åt en specifik kund. 11 Layer 3 switch Refererar till switch som även har funktionalitet för routing. 12 RIPng (RFC2080), OSPFv3 (RFC2740), MBGP(RFC2283) Protokoll för utbyte av routinginformation anpassade för IPv6.

IT-FORUM 16 (19) driftsmiljön negativt. En annan metod är att införa IPv6 för en pilotgrupp i produktionsmiljön. Pilotgruppen kan bestå av en eller flera personer. Pilotgruppen bör använda infrastrukturen i så hög grad som möjligt för att maximera antalet olika testscenarier. Ett testprotokoll bör upprättas så att funktioner utvärderas och dokumenteras strukturerat. Eventuella brister åtgärdas om möjligt och utvärderas därefter återigen. 6.6 UTBILDNING IPv6 innebär många förändringar i hur IP-protokollet fungerar. För att till fullo förstå hur detta påverkar den egna infrastrukturen bör man som första steg i införandet av IPv6 utbilda personal. Det finns både enklare gratis dokumentation och utbildningar på Internet, samt lärarledda kurser hos utbildningsföretagen. Utbildning kring IPv6 för specifika produkter kan också krävas, i synnerhet när det gäller nätverksutrustning som routrar och brandväggar. 6.7 DOKUMENTATION OCH RUTINER Vid införandet av IPv6 måste även dokumentation och rutiner anpassas för att inkludera IPv6. Utöver att förvaltningsdokumentationen ska kunna hantera IPv6-adresser (t.ex. att formatmallar etc. behöver ändras), så behöver troligen delar av organisationens rutiner ses över. Några exempel på sådan översyn ges nedan. Vid utveckling och införande av nya tjänster bör IPv6 tas med som krav. Dokumentation för äldre system som anpassats med IPv6 måste uppdateras. Dokumentationsmallar uppdateras så att de omfattar IPv6 konfiguration. Kravställning i upphandling bör omfatta IPv6. 6.8 IP-ADRESSPLANERING En IPv6 adress är 128 bitar lång och består av åtta grupper om fyra tecken. Varje grupp representerar 16 bitar. IPv6 adresser är till skillnad från IPv4 adresser hexadecimala, dvs. 0-9, a-f. Adressen följs av ett snedstreck och ett nummer som beskriver bit längden på prefixet. Prefixet hjälper IP stacken att avgöra om trafiken skall skickas lokalt eller routas via närmsta router. Exempel på IPv6 adress: 2001:0db8:1111:2222:3333:4444:5555:6666/64 I exemplet ovan är prefixet 64 bitar, vilket är hälften av 128 bitar, kan vi helt enkelt dela adressen i två lika stora delar. Där den vänstra delen (2001:0db8:1111:2222) är prefix och den högra (3333:4444:5555:6666) den lokala delen, även kallad subnät. Skall ett paket skickas till adresser i spannet 2001:0db8:1111:2222:0000:0000:0000:0000-2001:0db8:1111:2222:ffff:ffff:ffff:ffff skickas de direkt till mottagaren då den sitter på samma lokala nätverk. Övriga paket skickas till närmaste router som i sin tur får vidarebefordra paketet.

IT-FORUM 17 (19) I dagsläget delar operatörerna normalt ut ett prefix på 48 bitar till varje kund, vilket kan delas upp i 65536 stycken 64-bitars subnät. 64-bitars subnät är den minsta rekommenderade subnätmasken 13 i ett IPv6 nät och ger 18 446 744 073 709 551 616 nodadresser [13]. Adressplaneringen består av att tilldela nuvarande IPv4 subnät med IPv6 subnät samt att planera för framtida behov. Enligt gällande rekommendation bör /64 användas för varje segment för att behålla kompabilitet med funktioner i IPv6 som exempelvis Neighbor Discovery. [14] Exempel på hur IPv6 adress kan delas upp: Bit 0 Bit 48 Bit 64 Bit 128 Routing prefix 48 bitar Subnät ID Adresser tillgängliga för noder. tilldelat från operatör 16 bitar 2001:db8:1000 0000- ffff 0000:0000:0000:0000 ffff:ffff:ffff:ffff De 16 bitar som följer efter prefixet från operatören kan användas som identitet för varje subnät. Om VLAN 14 (802.1q) nyttjas kan med fördel samma VLANID som subnät ID användas vilket underlättar administration. Avsätt utrymme mellan subnäten så att det finns möjlighet att utöka med fler subnät på ett strukturerat sätt (se Tabell 1). Resterande 64 bitar är tillgängliga för att tilldela noder. Tabell 1. Exempel på IP-adressplan: Prefix Subnät ID Benämning 2001:db8:1000 0100 Administration av nätverksutrustning 0200 Interna servrar 0300 Publika servrar (DMZ) 1000 Klientnät 2000 IP-telefoni 9000 Testnät Exempel. Initialt finns 0200 för interna servrar men kan utökas med 0201, 0202, Tabell 2. Planering av nodadresserna underlättar administration: ::0001 Standard gateway i varje subnät ::0100 DNS ::0200 E-postsystem ::0300 Filservrar Adresserna ovan(i Tabell 2) är förkortade och visar enbart det 16 sista bitarna. Exempel på adress i subnätet Interna servrar DNS: 2001:db8:1000:0200:0000:0000:0000:0101/64, kan förkortas 2001:db8:1000:0200::0101/64. 6.9 EXTERNA TJÄNSTER TILLGÄNGLIGA VIA IPV6 13 Subnätmask definierar i antal bitar vilken del av IP adressen som är lokal och vilken som tillhör prefix. 14 Virtual LAN Teknik för att bygga logiskt skilda nätverk som transporteras över samma fysiska infrastruktur.

IT-FORUM 18 (19) Vid ett successivt införande av IPv6, är det ett krav att DNS-servern kan hantera att svara på IPv6-frågor, det vill säga kan hantera AAAA-poster (i enlighet med RFC 3596). Det bör säkerställas att en IPv6-pekning mot DNS-servern är gjord hos er registrar (i.se-zonen) och att denna delegering fungerar. Därefter kan de DNS-poster som pekar mot den eller de tjänst/-er som organisationen vill publicera på IPv6, läggas upp. Om DNS-servern och tjänsterna som ska publiceras över IPv6 står bakom en brandvägg behöver det öppnas för IPv6-trafik mot dessa i enlighet med leverantörens instruktioner. 6.10 INTERN KOMMUNIKATION VIA IPV6 När de grundläggande IPv6-tjänsterna för externt bruk är driftsatta och fungerar, är det dags att konfigurera den interna miljön för IPv6. Generellt kommer många enheter inte att klara av IPv6 (skrivare, stordatorer etc.) vilket gör det lämpligt att planera för dual-stack även här. En kontroll för att verifiera att den gjorda inventeringen stämmer överens med verkligheten behöver genomföras. Det vill säga att IPv6 fungerar på de enheter som hade uttalat stöd för det. Det bör även tillses att eventuella leverantörer av kommunikationstjänster (som exempelvis en MPLS-leverantör mellan två lokala kontor) kan hantera IPv6. 6.11 DRIFT OCH FÖRVALTNING Driftsättning sker efter säkerställande att drift i produktionsmiljön kan hållas på en acceptabel nivå. Innan driftsättning bör backup och återställningsrutiner för utrustning som påverkas av förändringen verifieras. Detta för att säkerställa smidig återställning av system om driftsättning behöver återkallas. Verifiera att förvaltningsdokumentationen stämmer överens med verkligheten och förstås av drifttekniker och övrig personal.

IT-FORUM 19 (19) 7 Referenser [1] Huston, Geoff, IANA, http://www.potaroo.net/tools/ipv4/index.html, Lagerholm, Stephan, Secure64, http://www.ipv4depletion.com/, Hain, Tony, Cisco Systems, http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf [2] ICANN, IPv6 The Internet s vital expansion http://www.icann.org/en/announcements/factsheet-ipv6-26oct07.pdf [3] IPv6 ger en stabil Internetinfrastruktur, http://ipv6forum.se/ [4] IETF, Internet Protocol, Version 6 (IPv6) Specification, http://www.ietf.org/rfc/rfc2460.txt [5] IETF, Security Architecture for the Internet Protocol, http://www.ietf.org/rfc/rfc4301.txt [6] Cisco, IPv6 Secure Neighbor Discovery, http://www.cisco.com/en/us/prod/collateral/iosswrel/ps6537/ps6553/white_paper _c11-563156.html [7] RIPE, Requirements For IPv6 in ICT Equipment (Draft) http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html [8] Certezza, Är din ISP IPv6 ready?, http://www.internetdagarna.se/arkiv/2009/wordpress/wpcontent/uploads/certezza_rev9.pdf [9] IETF, Basic Transition Mechanisms for IPv6 Hosts and Routers, http://www.ietf.org/rfc/rfc4213.txt [10] Microsoft, Teredo Overview, http://technet.microsoft.com/enus/network/cc917486.aspx [11] e-delegationen, Så enkelt som möjligt för så många som möjligt - från strategi till handling för e-förvaltning; SOU 2010:20, http://www.sweden.gov.se/sb/d/12840/a/142306 [12].SE, Att gå over till IPv6; En teknisk guide för införande av IPv6 i ett medelstort företag, http://ipv6forum.se/wordpress/wp-content/uploads/2010/05/ipv6- guide_medbilaga1.pdf, maj 2010 [13] RIPE, IPv6 Address Allocation and Assignment Policy, http://www.ripe.net/ripe/docs/ipv6-policy.html, IPv6 Frequently Asked Questions, http://www.ripe.net/info/faq/rs/ipv6.html [14] IETF, IPv6 Unicast Address Assignment Considerations, http://www.ietf.org/rfc/rfc5375.txt