De overstap naar IPv6 wordt beschouwd als een mega-operatie. Dit zorgt er vaak voor dat een IPv6 project wordt uitgesteld. Dat is jammer omdat er juist nu nog tijd is voor een rustige en gefaseerde implementatie van IPv6. De kunst is eigenlijk om een dergelijk omvangrijk project in kleine behapbare stukjes te hakken.
Het invoeren van IPv6 is als het vervangen van de gemeentelijke riolering; het is een enorme klus en we weten dat het een keer moet gebeuren maar het liefst stellen we het nog zo lang mogelijk uit. Een van redenen waarom men hier zo tegenaan hikt, is het gegeven dat een IPv6 implementatie je gehele infrastructuur raakt. Op zich is dat waar. Echter in de hoofden van degene die erover moeten beslissen wordt een dergelijk project heel groot gemaakt. Het is op zich niet verkeerd om de impact van IPv6 niet te licht in te schatten maar door IPv6 als één groot blok te beschouwen, krijgt het een verlammende werking. Een extra vertragende factor daarbij is nog dat het moeilijk is uit te leggen aan de hogere ‘baasjes’ waarom we nu al moeten voorsorteren op IPv6; de business-case is moeilijk rond te krijgen.
De kunst is om die grote olifant, die in zijn geheel niet te behappen valt, in plakjes te snijden (‘slicing the elephant’) om zo gefaseerd IPv6 in te voeren. Heel veel werk kan je al doen nog voordat je een eerste it-systeem hoeft aan te raken. Te denken valt aan een inventarisatie of alle hardware en besturingssystemen IPv6 compliant zijn. Verder kan je al beginnen met een aantal medewerkers op cursus te sturen om zo kennisniveau, bewustwording en enthousiasme te verhogen.
Ip-plan
Het eerste grote deelproject is het maken van het IPv6-nummerplan. Dit majeure onderdeel kan helaas niet verder in kleinere stukjes worden opgedeeld omdat een ip-plan als geheel moet worden ontworpen. Verder moet het belang van een ip-plan niet worden onderschat. De keuzes die hierin worden gemaakt zullen de komende tien à twintig jaar hun invloed doen gelden. De kans dat je een nieuw ip-plan kan opstellen is uniek en komt maar een paar keer in een loopbaan langs. Nu is het de tijd bij uitstek om iets te doen met de lessen die kunnen worden geleerd van fouten en inconsistenties in het huidige IPv4-nummerplan. Je kan weer met een schone lei beginnen (en nog steeds hebben we geen enkel stuk hardware aangeraakt..).
Dual stack
Als we dan uiteindelijk toe zijn aan de implementatie, dan is er eigenlijk maar één realistische strategie: de dual-stack strategie. Dit houdt in dat je in de huidige IP(v4)-structuur een IPv6-nummering erbij configureert. Op een host (server of werkstation) kan eenvoudig IPv6 worden geactiveerd (op dezelfde netwerkkaart) en ook in de configuratie van Layer3-interfaces van netwerkcomponenten kan een IPv6-adres naast/onder een IPv4-adres worden ‘ingeklopt’. Dit heeft verder nauwelijks impact op de huidige IPv4-connectiviteit; kan ongestraft naast elkaar bestaan.
Als eerste komt de DNS aan de beurt om IPv6 ‘enabled’ te maken in een dual-stack configuratie; het is immers een centrale- en essentiële dienst voor je gehele netwerk. In veel gevallen is DNS opgenomen in een totaalpakket van IPAM (ip-adres registratie), DNS en DHCP, dus zodra het IPv6-nummerplan gereed is moet het gelijk worden ingevoerd in de IPAM-module. Meteen ook een unieke kans om eindelijk eens af te komen van die eeuwige Excel-lijsten.
Deelsegmenten
Deel de gehele netwerkinfrastructuur vervolgens op in wijzigbare en bij elkaar horende segmenten, zoals: koppelvlak met serviceprovider, core/backbone segment, koppelvlak core-datacentrum, server-segment en eindgebruikerssegment, dmz (demilitarized zone) en firewalls. Maak van de IPv6-implementatie in deze segmenten kleine deelprojecten en voer ze stap voor stap uit. Je trekt vanaf het punt waar IPv6 je netwerk binnenkomt, aan de service-provider zijde, langzaam maar zeker IPv6 steeds verder je netwerk in. Rond elk deelproject netjes af en evalueer voordat je het volgende stuk oppakt. Langzaam maar zeker ontstaat er overal end-to-end IPv6-connectiviteit en de kennis, durf en ervaring onder de ict-medewerkers neemt snel toe. Het zal voorkomen dat je stuit op servers en/of segmenten die niet overweg kunnen met IPv6. Dit worden dan logischerwijs ook deelprojecten. Er zijn voor dit soort situaties echter al beproefde (tussen)oplossingen (NAT64/DNS64, Reverse Proxy, et cetera).
Natuurlijk is het zaak om IPv6 configuraties eerst te proberen in een testomgeving, maar uiteindelijk kan je gewoon een begin maken met het aanpakken van de produktiesegmenten. Wel moet goed worden gelet op de performance van routers en firewalls zodra IPv6 op die componenten is geactiveerd.
Met betrekking tot het uiteindelijke ‘live”‘ gaan van IPv6 zullen diensten aan de Internet-zijde, de voorkant, de hoogste prioriteit krijgen. De reden is dat vanaf internet de eerste urgente aanvragen voor IPv6-connectiviteit zullen komen, van bijvoorbeeld ‘IPv6-only clients’ uit Azië.
Aandachtspunten
Speciaal vermeld moet worden is het wireless segment in combinatie met byod: dit segment zal in de komende jaren een enorme groei doormaken en zal ook een grote variatie van mobiele ‘clients’ kennen. De vele verschillende (versies van) besturingssystemen zullen ieder op hun eigen manier omgaan met IPv6 en al dan niet een ingebakken voorkeur hebben voor IPv6 of IPv4. Een ander aandachtspunt is de voorgeprogrammeerde voorkeur van bijvoorbeeld Windows Vista of Windows 7 om te communiceren via IPv6. Zolang het gebruikerssegment nog niet klaar is voor IPv6 zal het wellicht nodig zijn om dit ongecontroleerde en onvoorspelbare IPv6-verkeer op de ‘access-laag’ te filteren.
Al schrijvende over IPv6 begin ik onderhand wel trek te krijgen in een broodje olifant: ‘Slager…kunt u het in dunne plakjes snijden? Het mag gerust een onsje meer zijn…’.
Allemaal uitstekend advies! Kennis, inventarisatie en plannen zijn cruciale delen van elke implementatie, en zeker voor IPv6. En zoals je al aangeeft kunnen deze stappen al gedaan worden zonder enige productieomgeving te wijzigen.
Wat ik zelf vaak adviseer is om in grote lijnen naar de volgende segmenten te kijken:
– Publieke diensten (DNS, e-mail, web, VPN, etc)
– Core netwerk
– Server netwerken
– Edge netwerken
Er zijn veel (combinaties van) strategieën mogelijk. Vaak zijn publieke diensten een apart DMZ netwerk of ondergebracht bij derden. Dat maakt het relatief eenvoudig om deze op IPv6 aan te bieden, en het is meteen ook nog het belangrijkste segment: de rest van de wereld gaat langzaam maar zeker IPv6 gebruiken en juist dit segment communiceert met die rest van de wereld.
Beginnen met de core van het netwerk in te richten voor IPv6 is ook geen slecht idee. Zeker bij grotere netwerken kan het wel eens een onhaalbare klus zijn om dit snel te doen, dus nu al voorbereiden voor als je het straks echt nodig hebt is geen gek idee. Daarna kunnen dan ook de servers IPv6 krijgen, waardoor deze middels IPv6 bereikt kunnen worden over bijvoorbeeld VPN verbindingen (met bijvoorbeeld IPv6 getunneld over IPv4). Van IP adres conflicten die bij IPv4 vaak optreden heb je met IPv6 geen last meer.
Een aantal handige documenten die van pas kunnen komen bij deze stappen:
– RIPE-554: een handleiding voor inkoop van IPv6-compatible apparatuur, software en diensten
http://www.ripe.net/ripe/docs/current-ripe-documents/ripe-554
– SURFnet handleiding nummerplan opstellen:
http://www.surfnet.nl/nl/nieuws/Pages/HandleidingIPv6-nummerplanverschenen.aspx
Mooi geschreven, Bart. Niet uitstellen, maar gewoon klein beginnen!
Aandachtspunt die je nog niet noemde, is (netwerk)monitoring tools. Deze zijn vaak ook nog niet compatibel, gek genoeg. Om nog maar te zwijgen over veel embedded systemen, firewalls en service modules.
Kortom, IPv6 zal ook standaard opgenomen moeten zijn in de selectiecriteria voor nieuwe infrastructuur, dan is binnen de lifecycle van 3-5 jaar de infrastructuur en in elk geval klaar voor!
Ik heb nog een aandachtspunt toe te voegen. Ik was aan het kijken naar een ipv6 transitieplanning en heb vervolgens een basis analyse gemaakt. Bij het doorlezen van de specificaties van de apparatuur kwam ik erachter dat de performance van switches wordt gehalveerd, waarschijnlijk omdat de pakketten groter worden en de adrestabellen meer geheugen vragen.
Vervolgens toch maar gekeken naar de noodzaak en geadviseerd om ipv6 alleen toe te passen op die plaatsen waar het zin heeft. Met name in de Core van het netwerk is performance reductie onacceptabel en feitelijk ook richting serviceproviders.
Ik ken de consequenties voor firewalls er dergelijke niet, ik schat in dat hier ook reductie in performance gaat ontstaan. Dus vooral goed nadenken en analyseren voordat je grootschalig begint met ipv6 en met name de consequenties beschrijven.
Een belangrijk element voor een dergelijke operatie is het maken van een gedegen risico analyse en bijbehorende risico beperkende maatregelen. Een IPv6 migratie grijpt in op alle elementen van de bedrijfs IT infrastructuur. Van de gebruikers en beheerders zelf, de applicatie’s, hardware/firmware, beheertools, beveiliging, internet verbindingen, WAN netwerk ontwerp, proxies, LAN distributie switches tot aan de eindpunten in de vorm van allerlei soorten (mobiele) apparaten. In het proces van ontwerp, migratie, tot aan de implementatie en het beheer kunnen vele risico’s de bedrijfsvoering in gevaar brengen.
Dual stack implementeren ligt natuurlijk voor de hand maar betekent wel dat je elke wijziging in het netwerk in 2 IP stacks moet gaan doorvoeren en beheren. Met name voor de beveiligs policy kan dat grote gevolgen hebben. Afhankelijk van welke ontwerp strategie is gekozen heeft IPv6 bijvoorbeeld geen NAT functie nodig waar in IPv4 soms lastige NAT regels nodig zijn om verbindingen tussen verschillende netwerken toe te staan. Zolang je dus dual stack draait moet elke wijziging 2x worden ontworpen, getest en gevalideerd alvorens te worden geimplementeerd. Dit betekent dus ook een dubbel risico op uitval of fouten.
De onbekendheid van deze risico’s, het opzien tegen de hoeveelheid werk die nodig lijkt en het daaruit voortvloeiende gebrek aan een business case zijn wellicht de echte reden voor de langzame acceptatie van IPv6 bij veel organisatie’s.
Mooi artikel Bart en nog steeds heel relevant al zal het 99.99% van de mensen worst wezen, het is wel een essentieel internet ding.
Heb me meermalen ingelezen, maar nog zie ik alle facetten die geraakt worden niet voor me. Met de komst van SDN en veel van de tools die bijvoorbeeld Azure mij biedt (URL based, weinig te maken met IP adressen), lijkt het erop dat bijvoorbeeld software ontwikkelaars niet heel veel hoeven aan te passen, maar misschien zie ik iets over het hoofd.
Je aanpak klinkt in ieder geval logisch en behapbaar.
Heel zinnig artikel.
@Willem: het verbaast me dat IPv6 langzamer is dan IPv4. De header van IPv6 is kleiner en simpeler en routing tabellen zijn kleiner. Volgens metingen Cisco is er bijna geen verschil tussen Ipv4 en IPv6:
http://www.cisco.com/web/strategy/docs/gov/IPv6perf_wp1f.pdf
Daarnaast werkt een switch op layer 2, de laag onder IPv4 en IPv6.
@Marcel van Wort: bij een dual stack implementatie is de kans inderdaad 2 keer zo groot dat er iets fout gaat, maar de impact is dan ook 2 keer zo klein.
@Marcel
In sommige L3 switches en vele andere apparatuur wordt IPv6 (nog) niet afgehandeld in een hardware ASIC maar in de software waardoor de performance kan gaan zakken. Bij dual stack zal de apparatuur 2 IP stacks moetn bijhouden wat ook weer invloed heeft op de performance. Goed testen dus vantevoren…
Op basis van alleen alleen protocol efficiency los van de apparatuur zal er niet veel verschil zijn.
Waarom zou de impact kleiner zijn? Afhankelijk van wat er fout gaat kan de impact van fouten net zo groot zijn, zeker bij onbedoelde fouten in de security policy die het netwerk openzetten.
Voor performance en risico impact geldt uiteraard dat de hoeveelheid IPv6 verkeer nog lang niet zo groot als bij IPv4 dus in dat geval zou de impact kleiner zijn.
Je zal gaan zien dat de learning curve weer helemaal opnieuw begint. Sommige dingen heb je niet op IPv4 en juist weer specifiek op IPv6 (geen ARP in IPv6 als voorbeeld). Waar op IPv4 de meeste dingen known zijn gaat er een hele nieuwe wereld open voor iedereen dus beter nu beginnen zodat het later niet allemaal te veel word.