Som de flesta redan vet, är adressrymden i IPv4 begränsad till ca 4 miljarder adresser, ett utrymme som snart tar slut. Lösningen på problemet är att gå över från IPv4 till IPv6 som har 128-bitars adressrymd och således nästintill obegränsat med IP-adresser.
Även om IPv6 protokoll funnits i 12 år, så är användningen, konstigt nog, fortfarande låg. Många företag och ISP-er har fortfarande varken börjat implementera eller planerat att implementera IPv6 inom snar framtid. Något som jag tror kommer ändras väldigt snart i takt med att adresserna tar slut.
Statusen för IPv4 är sådan att centralorganisationen för adressallokering, IANA, redan för några månader sedan delade ut sina sista block till RIR-en (Regional Internet Registry), och inom loppet av två veckor räknar man att första RIR-en (APNIC) kommer dela ut sina sista adresser till lokala ISP-er och företag. Det kommer troligtvis vara ett uppvaknande för många IT-chefer och ansvariga runt om i världen.
Jag jobbar som IT-ansvarig på ett svenskt företag och för ungefär två månader sen införde jag IPv6. Nu tänkte jag beskriva processen jag valde, vilka svårigheter jag stötte på, allt taget ur verkligheten med faktiska exempel. Konkreta exempel på ”hur?” var väldigt svårt att hitta när man väl bestämde sig för utrullning.
Vi har 2 kontor, med varsin internet-förbindelse samt en dedikerad förbindelse mellan kontoren. IP-Only är leverantör av alla våra förbindelser.
Redan på planeringsbordet var jag säker på att största och absoluta kravet var att verksamheten inte fick bli störd på något sätt, något som kan tyckas självklart, men kan vara lite mindre självklart hur man lyckas med.
Andra kravet var att IPv6 ”stödet” skulle vara ”native”-stöd, alltså inga halvdana tunnellösningar med tredje part som ändå kanske måste migreras bort inom några år.
Tredje kravet var att säkerheten inte skulle bli lidande (ingår delvis i krav 1).
Mer krav än så fanns det inte i det skedet.
Det bästa sättet att implementera IPv6 är att börja utifrån och arbeta sig inåt mot nätverken. Med andra ord, se till att man har en IPv6 förbindelse som fungerar, sedan en brandvägg som stödjer IPv6, ett DMZ med företagets web, dns och mailserver som stödjer IPv6, och slutligen resten av interna nätverket.
Nu till problemen.
1 Det största problemet de flesta kommer att ha är att få sin ISP att faktiskt leverera IPv6. I mitt fall hade jag en ISP som var ett av de första i Sverige att erbjuda IPv6 (IP-Only) så efter en beställning, hade jag ett par dagar senare, IPv6 levererat till båda av våra kontor. Jag kan tänka mig att problemen kan variera från allt att ISPns säljorganisation inte riktigt vet vad IPv6 är, till att man har svårt att få rätt vägledning om ”vad” man egentligen ska beställa. Jag följde RIPE-s rekommendationer och beställde två konsekutiva ”/48”-prefixer till våra två kontor.
2. Det andra stora problemet är ens egen okunskap. På många sätt hade det varit bättre ifall IPv6 hade varit väldigt olikt IPv4, för då hade man behövt starta från början, men i det här fallet upplevde jag skillnaderna i protokollen förvirrande. I IPv4 är man van att tänka i ”nätmask”-format och det beteendet lever kvar ganska länge i huvudet, trots att begreppet inte existerar i IPv6 utan ”prefix” används istället. Prefix är egentligen enklare att förstå än ”nätmask” som ”maskar av” subnätet från den signifikanta adressen.
3. Det tredje problemet var att säkerställa att verksamheten inte blir störd. Att utföra en så pass fundamental förändring som införande av nytt protokoll i en heterogen miljö med otroligt många separata system, innebär risk att något inte fungerar som det ska eller slutar fungera helt och hållet.
4. Fjärde problemet är avsaknad av IPv6 stöd i utrustningen. Efter en analys av detta problem kom jag till slutsatsen att endast våra brandväggar är berörda. Våra core routrar är vanliga linuxmaskiner så IPv6-stöd fanns, och switcharna managerades via ett management-nät så jag bestämde helt enkelt att inte tvinga IPv6 på det nätet.
Dessa 4 problem visste jag om redan på planeringsbordet. Nu till utförandet!
Problem 1 löstes för 1 år sedan då vi valde en operatör som redan hade IPv6 i sin portfölj. Nog tänkte jag inte på det då, men idag är jag glad att jag valt IP-Only.
Problem 2 löstes genom att leta information på nätet och fördjupa sig i hur protokollet fungerar. Även om det är ”enkelt” att konfigurera ett nät att köra IPv6 så krävs det förståelse och kunskap för att möta upp de kraven om säkerhet, tillgänglighet och för att undvika att störa verksamheten.
Problem 3 är ett problem som måste lösas kontinuerligt i varje delmoment man gör. Ett av de självklara valen man måste göra är att köra ”dual stack configuration”, d.v.s. man kör båda protokollen samtidigt. En värd har då både en IPv4 och IPv6-adress och kan kommunicera genom att använda sig av båda. Notera också att de flesta operativsystem automatisk väljer IPv6 om det är möjligt, och det är viktigt att man kommer ihåg det annars kan man stöta på problem. Jag återkommer till detta senare.
Problem 4 var lite svårare. Även om alla våra interna routrar hade stöd för IPv6 (och jag valde att lämna switcharna på IPv4), så hade inte våra brandväggar det. Som det såg ut då kunde jag varken byta ut dem, eller uppgradera dem utan att störa verksamheten. Därför löste jag det genom att sätta upp helt nya brandväggar. I mitt fall blev det m0n0wall som installerades. Nog duger det med standard-linux med ip6tables, men just i det här skedet kände jag att jag inte ville lägga till fler möjligheter för misstag. M0n0wall har exemplariskt enkelt gränssnitt och stödet för IPv6 är riktigt bra.
När brandväggarna var installerade på vardera av kontoren och mina /48-prefixer levererade var det bara att sätta igång med praktiska implementationen. I m0n0wall måste man först slå på IPv6 stöd. Därefter har man möjlighet att mata in IPv6-adresser på de olika interfacen. Mina 48-or levererades över ett länknät, så jag började med att konfigurera mina WAN-interface i enlighet med informationen jag fick från IP-Only. Länknätet har 64-bitars prefix och mitt WAN måste ha den IP-adressen som min ISP angivit eftersom den IP-adressen används för routingen av det 48-nätet jag fått. Viktigt att komma ihåg är att man ser till att ”router advertisment” är avstängt på det interfacet. En sak jag saknade med m0n0wall är möjligheten att endast konfigurera IPv6 och lämna IPv4 okonfigurerat, men det gick inte i web-gränssnittet. I det här skedet gick det inte att pinga exempelvis ”ipv6.google.com” troligtvis för att trafiken kom från vårt länknät som inte nödvändigtvis var globalt routad.
Nu till konfigureringen av vårt 48-nät. Innan jag fortsatte kontrollerade jag att det inte fanns några för ”generösa” IPv6-brandvägsregler. Det är vanligt (men felaktigt enligt mig) att administratörer slappnar av när de kör NAT på sina brandväggar för att man ”inte kan nå” värdar innanför nätverket och därför ibland slarvar med brandväggsregler. Med IPv6 är det inte nödvändigt att NAT-a och det medför att all slarv innebär öppna hål i brandväggen. När jag var säker på att all IPv6-trafik blockerades var det bara att fortsätta. Första frågan är hur man hanterar det 48-nätet som vi tilldelats. Att konfigurera LAN interfacet med det 48-nätet vore dumt, så jag valde att dela upp det i mindre subnät. Vi har ett antal olika subnät i IPv4, alla med olika VLAN-ID i våra switchar. Jag bestämde att varje IPv4 subnät skulle få ett motsvarande /64-bitars prefix i IPv6. (liten kuriösa: ett /48-bit prefix innehåller 65 536 /64-bit prefix. Om varje anställd skulle få en IP-adress för varje cell i sin kropp, skulle jag ha adresser för ungefär 32 000 anställda).
Låt oss säga att 2001:0DB8:4096::/48 är vårt 48-bitars nät jag fått av IP-Only. Det nätet delades upp i /64 bitars prefix som i sin tur tilldelades till var sitt VLAN. För att få det enklare att administrera och känna igen, valde jag VLAN-ID som den sista 16-bitars gruppen i det 64-bitars prefixet. Dvs VLAN med VLAN-ID 3 tilldelades 2001:0DB8:4096:3::/64 och så vidare.
Först konfigurerades LAN-interfacet med 2001:0DB8:4096::1/64. Nästa interface att konfigurera var vår DMZ (VLAN ID 7 hos oss) med ett antal servrar däribland våra web-, dns- och mail-servrar. Följande min plan konfigurerade jag 2001:0DB8:4096:7::1/64 på DMZ-interfacet. Där slog jag på router advertisment. Genom att logga in på en av maskinerna i DMZ kunde jag konstatera att den omedelbart konfigurerades med korrekt prefix och route, mha SACP (Stateless autoconfiguration protocol). Jag bekräftade att alla servrar på det nätet hade gjort det och verifierade att de kunde kommunicera med varandra. Därefter fortsatte jag sedan att titta genom brandväggsregler. Jag öppnade upp i brandväggen för ICMP6 och testade att pinga ipv6.google.com från DMZ. SUCCESS!
Därefter anpassade jag brandväggsreglerna att tillåta trafik till de tjänsterna som kördes i DMZ, http, https, smtp, dns. Jag återigen dubbelkontrollerade att ingen trafik tilläts från DMZ till våra interna nät (mer än svarstrafik). Eftersom det är svårt att testa IPv6 access utifrån (man har ingen tillgång till andra IPv6-kapabla hostar på Internet), fick det duga med lokala tester.
Först ute var Apache på vår webbserver. Den svarade inte på IPv6 adressen. Efter att ha dubbelkollat att ingen IP-adress fanns specificerad i ”Listen”-direktivet krävdes det bara att starta om processen och så började den svara. För att den ska lättare hittas utifrån, adderade jag en AAAA-post i vår DNS som pekade på serverns IPv6-adress och vips, vi var online på IPv6 med vår webbserver.
(En sak jag noterade senare efter att ha tittat på hur ”andra” gjort det, var att jag använde SACP-adressen för vår AAAA-record, vilket blev något i stil med: 2001:0DB8:4096:7:10dd:10ff:fed7:1a36 . De flesta andra jag tittat på, använder istället en ”enklare” adress vilket man får sätta manuellt. Tekniskt har det ingen betydelse, men jag antar att det blir lite ”snyggare”. Dvs något i stil med: 2001:0DB8:4096:7::5 eller liknande).
Vår mailserver kör mailsystem Zimbra, ett mailsystem som består av Postfix, Spamassassin och ett antal andra ”open source” delar. Jag räknade med att det som behövde “IPv6-anpassas” var de delar som behövde kommunicera med omvärlden, dvs Postfix som pratade SMTP, Zimbras egna IMAP-mjukvara, samt webbservern som tjänstgjorde som webmail samt administrationsgränssnitt. Det visade sig att det enda som krävdes för att få den att fungera med IPv6, var att konfigurera Postfix att lyssna på alla interfaces (inet_interfaces all) och sedan starta om hela Zimbra. Resten band till IPv6-interfacet automatiskt.
Därefter var det bara att lägga in en ny AAAA-post i DNS-en och vips så tar vi emot mail via IPv6.
När man lägger till AAAA poster har man ett val. Antigen lägger man en AAAA-post som är ett eget unikt namn (ipv6.example.com, såsom Google exempelvis gör), eller så lägger man till en AAAA-post till det namn man redan har en A-post för (www.example.com med både A och AAAA-post).
För mig var det obegripligt varför man skulle vilja ha två olika unika namn för olika protokoll med det utkristalliserades allt eftersom jag fortsatte med utrullningen. Om man har en AAAA-post, med samma namn som A-post, och en dual-stack klient försöker skapa en förbindelse, så kommer de flesta implementationerna föredra IPv6 så fort de har något mer än ”link-local” adress på någon av sina interfaces. Om det nu är fel med routingen eller brandväggsregler eller vad det nu kan vara under utrullningen, kommer klienten vänta… vänta…vänta… och sedan ge upp och falla tillbaka till IPv4. Den fördröjningen blir uppemot 10-20 sekunder, vilket är inte alls acceptabelt av de flesta. Det innebär att du bör kolla, INNAN du skapar AAAA-poster som heter likadant som A-poster, att den IPv6-adressen är nåbar från alla håll. I synnerhet om du ska skapa en sådan post för det interna nätverket. Ett tips är att använda sig av /etc/hosts eller c:\windows\system32\drivers\etc\hosts för att testa din IPv6 anslutning innan några AAAA-poster sätts upp, eller så kommer du få många skrik av dina användare.
Jag spenderade en del tid på att göra en del tester på våra maskiner i DMZ innan jag fortsatte vidare inåt.
Innan man börjar låta servrar och klienter köra IPv6 på interna nätverket är det återigen läge att trippelkolla sina brandväggsregler, eftersom de får adresser som är globalt nåbara.
I vårt fall sitter vår brandvägg direktförbunden via ett management-nät med vår core router (en linuxmaskin) som är ansvarig för att routa mellan olika subnät. Alla servrar och klienter pratar endast med routern vilken i sin tur routar Internettrafik via brandväggen ut. På management-interfacet (det som sitter på samma VLAN som brandväggen) konfigurerade jag adress 2001:0DB8:4096::2/64 och satte 2001:0DB8:4096::1 som default route (I mitt fall pekar detta på annan maskin än IPv4 eftersom jag satte upp separat brandvägg för IPv6-trafik). På resten av interfaces, satte jag upp /64-bitars prefix motsvarande det VLAN-ID som användes på det subnätet:
2001:0DB8:4096:50::1/64
2001:0DB8:4096:51::1/64
…
2001:0DB8:4096:60::1/64
I m0n0wall adderade jag statiska routes till dessa subnät via 2001:0DB8:4096::2.
Jag kunde verifiera med hjälp av ping6 att jag hade anslutning till ipv6.google.com. Det som återstod var att se till att klienterna får information om prefix och routes. Eftersom routern kör Linux, installerade jag radvd (Linux IPv6 Router Advertisment Daemon) och såg till att operativsystemet vidarebefordrade IPv6-paket. Efter att ha gjort en simpel konfiguration av radvd, startade jag upp den. Direkt efter kontrollerade jag IP-informationen på min dator. Interfacet kopplat till det subnätet hade omedelbart fått information om prefixet samt route. Ett snabbt test med ping6 mot ipv6.google.com bekräftade resultatet. Likaså fungerade det också med en browser.
Jag tog då en promenad genom kontoret och bad slumpmässigt valda personer att testa med en browser och det fungerade för alla.
Sammanfattningsvis gjorde jag följande saker för att rulla ut IPv6 på ett av kontoren:
- Satte upp en separat brandvägg (kanske inte nödvändigt för de som redan har IPv6-kapabla brandväggar)
- Konfigurerade WAN på brandväggen
- Konfigurerade LAN på brandväggen (management nät)
- Konfigurerade DMZ på brandväggen med router advertisment påslaget)
- Konfigurerade Interfacen på core routern
- Konfigurerade statiska routes till de olika subnäten på brandväggen
- Installerade och konfigurerade Radvd på routern
Med 7 steg gjordes en komplett utrullning av IPv6 på kontoret. Andra kontoret utrullades på samma sätt, med addition av ett direkt länknät mellan core-routrar samt nödvändiga routes som möjliggjorde intern kommunikation mellan näten.
Nästa blogginlägg kommer innehålla lite mer av mina erfarenheter kring utrullningen.



Senaste kommentarer