"Kan IPv4 al uit?" Over ons jaarlijkse IPv6-only experiment

Wat is het IPv6-only experiment?

Het is achteraf gemakkelijk om te zeggen wat beter had gekund aan de ontwikkeling van IPv6 (of ‘IPng’, zoals het aanvankelijk werd genoemd), maar de engineers die hier al begin van de jaren ’90 over nadachten en aan werkten, moesten het doen zonder al onze hedendaagse kennis. Het liep dan ook iets anders dan gehoopt. Vooral de transitie van oud naar nieuw viel tegen. Dat werd een langdurig proces en komt eigenlijk pas sinds kort goed op stoom. En hoewel we inmiddels in een stroomversnelling zitten, mogen we ervan uitgaan dat IPv4 nog geruime tijd naast IPv6 blijft bestaan. IPv4 zit immers diep verweven in allerlei software en netwerkinfrastructuren, maar ook in de hoofden van softwareontwikkelaars en netwerkengineers. Toch is de ultieme wens dat IPv4 en IPv6 ooit voldoende ontvlochten zullen zijn en we op enig moment daadwerkelijk kunnen ‘internetten’ zonder IPv4.

Ons IPv6-only experiment, dat we eens in de zoveel tijd doen, beoogt precies dat te onderzoeken: wat is de stand van zaken van het moment en wat gaat er allemaal stuk als we IPv4 daadwerkelijk helemaal uitzetten, zelfs als we software gebruiken die claimt ‘IPv6-ready’ te zijn? Eerlijk gezegd; in de begindagen van onze IPv6-only experimenten waren we doorgaans al vrij snel klaar. Het werkte technisch min of meer, maar was praktisch gezien eigenlijk geen doen. Vaak was de lol er na een eerste paar pogingen al snel vanaf. Als de software al meewerkte, gingen er ergens anders wel dingen mis. Het waren toch met name de ‘usual suspects’ wier sites goed werkten. Maar door de jaren heen verbeterde de situatie. En de minder goede ervaringen van destijds staan inmiddels in schril contrast met de tegenwoordige situatie! We testen bij dit experiment vanuit gebruikersperspectief. Het is geen uitputtend onderzoek van alle ruim 2,1 miljoen .nl-domeinnamen die op een of andere manier claimen bereikbaar te zijn via IPv6. Het doel is meer om steekproefsgewijs een gevoel te krijgen bij de kwaliteit, als we IPv4 helemaal uitzetten en om te onderzoeken waar nog ruimte voor verbetering is.

Onze onderzoeksopzet

De manier waarop we het experiment doen is niet altijd hetzelfde geweest. Door de jaren heen hebben we de lat hoger gelegd. Dus waar we ooit vrij simpel begonnen met een ethernet-interface zonder IPv4-adres daarop geconfigureerd, al dan niet een handje geholpen met wat NAT64/DNS64, om tenminste toch nog iets te kunnen bereiken, gaan we tegenwoordig een paar stappen verder. Want op enkele probleem na, werkt alles gewoon als er via zo’n transitie-mechanisme nog een lijntje met de IPv4-wereld is. Dus dat is allang niet spannend meer. De insteek van ons tegenwoordige onderzoek is dan ook om echt helemaal geen IPv4 meer te gebruiken. Niet omdat we dat nu al zouden willen aanbevelen voor de gemiddelde gebruiker, maar puur omwille van het experiment. We werken met een desktopsysteem waar helemaal geen IPv4 op bestaat. Dat kunnen we doen dankzij de goede mensen achter het FreeBSD-project. Het mooie aan hun opensource besturingssysteem is namelijk, dat je de zogenaamde kernel kunt compileren zonder de IPv4-stack. Bij ons weten zijn zij daarin uniek. Hierna starten we de desktop op. Omwille van de volledigheid passen we hier en daar nog wat zaken aan. Zo halen we de 127.0.0.1-vermelding uit /etc/hosts, ook al staat die vermoedelijk niet in de weg. Verder veranderen we de standaardinstelling 0.freebsd.pool.ntp.org in ntp.conf, naar 2.freebsd.pool.ntp.org, omdat die node helaas de enige is die bereikbaar is via IPv6. Dat soort minimale aanpassingen dus, om het feest compleet te maken. Het is soms even zoeken naar dit soort ‘verborgen’ IPv4-zaken. Zo heeft avahi-daemon.conf bijvoorbeeld een ‘use-ipv4=yes’-regel, die we hebben aangepast naar ‘no’. Het maakt allemaal niet zo heel veel uit, er is immers geen IPv4-stack aanwezig, maar het is ook een beetje een sport om dit soort dingen te vinden en een compliment voor de ontwikkelaars dat ze zo’n optie überhaupt aanbieden. Omdat het kan, configureren we ook de e-mail, zodat we uit het systeem mails kunnen ontvangen. Dat is allemaal goed te doen met IPv6 bij de grote big-tech waar we klant zijn. Verder is het gewoon een standaard 13.0-RELEASE van FreeBSD, inclusief Gnome3 en/of XFce4 grafische desktop. We installeren daarop wat extra standaardsoftware, zoals uiteraard een Firefox- en een Chromium-webbrowser.

Figuur 1: Een 'ifconfig' van ons testsysteem.

Nieuw aan het meest recente onderzoek, is dat we ook gebruik hebben gemaakt van een DNS-resolver die alleen maar via IPv6 met de buitenwereld kon communiceren. En hoewel dat nog wel een paar verrassingen opleverde, is het überhaupt een wonder te noemen dat we ons deze frivoliteit konden veroorloven zonder al meteen te stranden in teleurstellingen. Ook hieruit blijkt weer; we gaan de goede kant op met de adoptie van IPv6! We gebruiken hiervoor trouwens de ‘local_unbound’-applicatie die FreeBSD meelevert. Wel zo gemakkelijk. Die moesten we nog wel even vertellen dat hij aan ::1 moet ‘binden’ (de default is 127.0.0.1). Overigens moet dit niet verward worden met iets anders wat we ook wel eens hebben gedaan. Zie bijvoorbeeld https://42.dnslabs.nl/ (als dat lukt). Deze pagina krijg je alleen te zien als zowel jouw verbinding, als de resolvers die worden gebruikt beschikken over IPv6-connectiviteit. Dat blijkt minder vanzelfsprekend dat je zou denken en gaat nog wel eens mis.

Bevindingen

Wat allereerst opvalt is dat het technisch allemaal in orde en volwassen is. We zien geen ernstige zaken in de logs. Eigenlijk wisten we dit al, vanuit onze experimenten met NAT64/DNS64 (zelf draai ik op mijn werkplek uitsluitend met deze setup) en bijvoorbeeld oude aankondigingen van Apple. Dan wordt het daarna natuurlijk interessant om te kijken of deze technisch werkende setup ook daadwerkelijk enigszins nuttig te gebruiken is op het internet. Maar vooral ook; wat kan nog beter? Uiteraard werken Google, YouTube, Netflix, Facebook en Instagram (voor sommige gebruikers is dit de definitie van ‘het internet’). Dat deze bedrijven goed bezig zijn met IPv6, is inmiddels wel algemeen bekend. Ja, zelfs https://web.whatsapp.com werkt gewoon prima. Veel overheidssites doen het ook uitstekend. Dus defensie.nl, politie.nl, rivm.nl, of coronadashboard.rijksoverheid.nl; het ziet er allemaal heel netjes uit, zonder zelf maar 1 IPv4-packet nodig te hebben. Eigenlijk zijn er behoorlijk veel sites die gewoon puik werken, te veel om ze allemaal te noemen. Al zijn er natuurlijk ook nog genoeg sites die helemaal niet via IPv4 te bereiken zijn.

IPv6-geschikte sites zijn zeker niet alleen maar overheidssites, wat je misschien zou verwachten vanwege de geldende ‘pas-toe-of-leg-uit’-verplichting. We zien een goed geslaagde toepassing van IPv6 over de hele linie. Mogelijk hebben onze incentiveregeling [1, 2] en diensten zoals die van Cloudflare hier ook een positieve invloed op (gehad).

Dat er veel goed gaat, wordt al snel duidelijk en is leuk, maar niet het meest spannend. Laten we daarom ook eens kijken waar het nog misgaat. Allereerst de site van politie.nl. Op eerste oog prima. Maar onderwater viel op dat w.usabilla.com geen IPv6 heeft. Als gebruiker van de site is dat verder geen enkel probleem, maar de webmaster zal dit waarschijnlijk graag gerepareerd willen zien. Het is iets wat we vaker tegenkwamen. We zien verschillende ‘onderwater-zaken’, zoals trackers en webmaster-tools die nog niet allemaal werken (maar veel ook wel). Meestal niet hinderlijk voor de bezoeker en soms zelfs prettig (geen advertenties!), maar af en toe toch irritant. Zo heeft revu.nl zijn behoorlijk prominente cookiemuur aan privacymanager.io uitbesteed en die doen kennelijk nog geen IPv6. Dus hoewel revu.nl wel geschikt lijkt, kwamen we toch niet op de site, omdat we niet voorbij de cookiemuur kwamen:

Figuur 3: Een IPv4-only cookiemuur op revu.nl verhinderde ons de toegang tot de website.

Daarna door naar LinkedIn. Hier kwam een ander probleem naar boven, dat we eerder niet zagen. Op zich werkt de site namelijk prima via IPv6, maar omdat we zo strikt zijn en ditmaal ook de DNS-resolving hebben betrokken, ging het specifiek voor ons toch mis. Want ‘www.linkedin.com’ is (in ons geval) een CNAME voor ‘www-linkedin-com.l-0005.l-msedge.net’, de CDN van Microsoft en de beide authoritative nameservers van het ‘l-msedge.net’-domein zijn alleen maar via IPv4 te bereiken. We hebben geen idee waarom, want ons lijkt dit nergens voor nodig. Een soortgelijk probleem speelt bij Bing, dat prima kan werken over IPv6, alleen zijn de nameservers van, in dit geval, de domeinnaam ‘trafficmanager.net’ ook nog niet via IPv6 bereikbaar. Idem voor openstreetmap.org, dat samenwerkt met het CDN van Fastly. Ook daar geen IPv6-connectiviteit op de nameservers. Best jammer, want los van de DNS werken alle genoemde site verder prima via IPv6-only.

Wat kwamen we verder tegen?

Een aantal websites, waaronder bijvoorbeeld die van NOS, zag er ronduit lelijk uit. Nadere inspectie wees uit dat dit veelal komt omdat nog niet alle onderdelen die nodig zijn voor de correcte weergave van de site, via IPv6 bereikbaar zijn. Voor de NOS-site is dat onder andere ‘cdn.nos.nl’:

Figuur 4 De website van de NOS vertoont gebreken bij een bezoek over alleen IPv6.

Vaak zien we dat het missende CSS-stylesheets betreft. Of niet-werkende video-content. Zo is de site van het AD op zich prima te lezen, maar werkt het afspelen van een video vervolgens dan toch niet. Eigenlijk is het jammer, zo’n site die maar half werkt onder IPv6. Dat vonden ze bij de gemeente Nijmegen ook en daar waren ze zelfs in staat om het probleem binnen 24 uur op te lossen!

Soms komen we sites tegen die via IPv6 andere content geven dan over IPv4, als we dat verifiëren. Denk bijvoorbeeld aan een standaard Apache-pagina via IPv6.

Een ander punt dat opviel is Geo-locatie. Dat hapert nog wel eens.

Een wat wrang voorbeeld hiervan vonden we op de verder prachtige site https://ipv6-test.com/. Hun speedtest probeert de dichtstbijzijnde test-server te vinden, maar dat lukt niet, omdat de onderliggende API’s van de dienst ‘db-ip.com’ alleen maar via IPv4 zijn te bereiken. Als gevolg daarvan kom je niet verder.

Een laatste bevinding die we nog willen noemen is deze: veel gebruikers typen in hun browser alleen de domeinnaam in, zonder ‘www’ ervoor, zoals ‘example.nl’. En heel vaak volgt er tegenwoordig dan een redirect naar ‘www.example.nl’, vaak ook van ‘http’ naar ‘https’. We merkten dat dit voor sommige sites niet opgaat. De ‘www’-variant werkt perfect via IPv6-only, maar dan moet je dat wel expliciet zo intikken in je browser. Doe je dat niet, dan krijg je geen content te zien. Dit geldt bijvoorbeeld voor ‘tno.nl’, ‘buienradar.nl’ en ‘knmi.nl’. We denken dat dit technisch heel eenvoudig oplosbaar is en vragen ons af waarom dit niet is gedaan. Misschien heeft men er gewoon niet aan gedacht?

Conclusies

We hebben gekeken naar de kwaliteit van websites en diensten die claimen dat ze geschikt zijn voor IPv6, zonder ‘hulp’ van IPv4. En we stellen vast dat de situatie sterk verbeterd is ten opzichte van eerdere vergelijkbare onderzoeken. We zien ook dat resterende problemen gemakkelijk oplosbaar lijken. Ze doen niet denken aan complexe technische uitdagingen, maar er lijkt simpelweg overheen gekeken te zijn. Omdat veruit de meeste IPv6-verbindingen dual-stack zijn, dus ook nog in verbinding staan met de IPv4-wereld, vallen de foutjes niet meteen op. Al met al was dit de beste IPv6only-test ooit. Het is zeer positief om met eigen ogen vast te kunnen stellen dat IPv6 technisch volwassen en bruikbaar is en dat er in een flink tempo content beschikbaar komt via IPv6. Het is daadwerkelijk mogelijk om zonder IPv4 echt veel meer sites [1, 2] te bezoeken of diensten te gebruiken dan hier in deze blog vermeld kunnen worden. Natuurlijk zijn er soms nog kleine problemen (die je pas tegenkomt als je echt met IPv6-only aan de slag gaat). Als het enigszins lukt, melden we dit soort bevindingen aan de ontwikkelaar of het bedrijf in kwestie. Regelrechte doornen in het oog zijn er ook. Zo blijft het teleurstellend dat grote netwerken zoals Twitter en Github (om maar 2 te noemen) ruim de tijd nemen en nog altijd niet volledig IPv6-geschikt zijn (wel deels trouwens). Dat dit meer is dan alleen maar een aardig experiment voor op de vrijdagmiddag, blijkt wel uit officiële publicaties van bijvoorbeeld de Amerikaanse- en Chinese overheid. Zo kondigde de Amerikaanse overheid recent aan dat ze toewerken naar een ‘IPv4-loos’ internet. En onlangs voegden ze ook de daad bij het woord. Weliswaar niet op de meest spannende website ooit, maar toch een overduidelijk signaal:

Figuur 7 Een bewijs van de stappen die Amerika zet in de richting van een IPv4-loos internet: https://clintonwhitehouse2.archives.gov/.

In Nederland zijn er gelukkig steeds meer gebruikers die zo’n IPv4-loze site gewoon kunnen blijven bezoeken. Ziggo en KPN zijn de laatste tijd bijvoorbeeld heel goed bezig en steeds meer internetters krijgen de beschikking over IPv6. We adviseren iedereen die zich met dit onderwerp bezighoudt, waaronder webdevelopers, om zelf ook hun producten aan een IPv6-only test te onderwerpen voordat ze in productie gaan. Een dergelijke test is eenvoudig op te zetten. En we hopen tenslotte dat iedereen die dit leest geïnspireerd is en met ons kan vaststellen dat we, na een weliswaar lange aanloop, in een stroomversnelling zijn gekomen en rap de goede kant op gaan met IPv6. En we zijn benieuwd naar de uitkomsten van ons volgende IPv6-only experiment. Mocht je daarvoor nog leuke tips of ideeën hebben, laat het ons weten!