Vijf misverstanden over IPv6

1. IPv6 lost het IPv4-tekort op

'Het probleem is dat de overgang naar IPv6 het IPv4-tekort niet op korte termijn oplost', aldus Van Beijum. 'Een provider kan niet zeggen: ik heb geen IPv4-adressen meer, dus krijgt u van mij een IPv6-adres. Want zo'n klant kan dan 99 procent van het internet niet bereiken. Dat accepteert hij niet. Daarom geeft een provider een klant liever een trage, gedeelde IPv4-verbinding met maar drie TCP/IP-poorten, dan een snelle IPv6-verbinding. Dat is het trieste van het hele verhaal.'

'Eind 2011 heeft RIPE NCC naar verwachting geen IPv4-adressen meer te verdelen', vervolgt hij. 'Providers zullen noodgedwongen vaker verschillende nieuwe gebruikers achter één IPv4-adres plaatsen via NAT. Maar dat is niet oneindig lang vol te houden. Problemen zullen waarschijnlijk niet meteen optreden. Maar over twee, drie jaar kan de situatie opeens onhoudbaar blijken. Je kunt het vergelijken met een kikker in een kookpot. Als je die meteen in het kokend water gooit, springt hij eruit. Maar als je hem in koud water zet en dan langzaam opwarmt, komt hij nooit op het idee om uit de kookpot te springen.'

2. IPv6 is arbeidsintensief

'Het nadeel van IPv6 is inderdaad dat alle netwerkonderdelen moeten worden aangepast, van de server, tot de firewall, besturingssystemen en de DNS-server', zegt Van Beijnum. 'Die onderdelen moeten bovendien niet alleen worden aangepast, maar ook nog eens worden aangezet. Tot die tijd kun je geen communicatiesessie opstarten. Sceptici zeggen daarom wel eens dat het veel eenvoudiger is om via een NAT-box een aantal clients tegelijk achter één IPv4-adres plaatsen. Dat lijkt aantrekkelijk, maar in de praktijk blijkt die ene aanpassing toch altijd een volgende uit te lokken, en een volgende. Dat resulteert uiteindelijk in zo veel aanpassingen dat de overgang naar IPv6 eenvoudiger is.'

3. NAT is een oplossing voor het IPv4-tekort

'NAT in het algemeen dwingt internetverkeer af dat verloopt volgens een client-serverarchitectuur', zegt Van Beijnum. En die architectuur vloekt met programma's die IP-pakketten versturen via een peer-to-peer (p2p)-netwerk.

Zo'n p2p-netwerk is gedecentraliseerd: het kent geen vaste werkstations en servers zoals in het client-servermodel, maar enkel gelijkwaardige aansluitingen ('peers' ). Ze functioneren allemaal zowel als client en als server voor de andere aansluitingen in het netwerk.

'Wanneer twee 'peers' beide achter een NAT-box staan, kunnen ze niet of slechts lastig een verbinding met elkaar opzetten, waardoor audio en videogesprekken niet tot stand kunnen komen', legt Van Beijnum uit. De internetonderzoeker weet dit ook uit eigen ervaring. 'Thuis heb ik twee BitTorrent-machines staan. De één staat achter een NAT-box, de ander niet. Met die laatste laptop, die een eigen IP-adres heeft, kan ik vier tot tien keer sneller bestanden downloaden.'

'Overigens is er in NAT rekening gehouden met dit probleem', nuanceert Van Beijnum. Ontwikkelaars van p2p-applicaties kunnen in hun applicaties specifieke poorten definiëren voor binnenkomend verkeer, gebruikmakend van onder meer het Internet Gateway Device Protocol. Op die manier kunnen ze ervoor zorgen dat er voldoende TCP/IP-poorten beschikbaar komen voor downloaden. Het probleem met die oplossing is volgens Van Beijnum echter dat hij weliswaar werkt bij thuisgebruikers of binnen lan's achter een NAT, 'maar bij providers staan die NAT-boxen altijd dieper in het netwerk. Daardoor is het voor p2p-programma's vrijwel onmogelijk om binnen provider-netwerken poorten open te zetten voor p2p-verkeer.'

Hoe intensiever providers gebruik zullen maken van NAT, hoe trager p2p-applicaties zullen worden, voorspelt Van Beijnum. Data-intensieve p2p-applicaties kampen nog eerder met vertragingen en uitval. Videoconferencing is een voorbeeld van zo'n data-intensieve applicatie. Maar ook p2p-applicaties zoals instant messaging en VoIP gaan het volgens de onderzoeker 'heel moeilijk krijgen' naarmate providers NAT intensiever toepassen.

4. Het end-to-end-argument is achterhaald

De Delftse onderzoeker Jos Vrancken stelde eerder dat het end-to-end-argument achterhaald is. Hij betreurt dat binnen de internetgemeenschap wordt vastgehouden aan dit principe. Dat zou volgens Vrancken de verdere ontwikkeling van NAT verhinderen. Van Beijnum is het daar niet mee eens. 'NAT compliceert het netwerk en maakt het daardoor langzamer en minder betrouwbaar.'

'Volgens het end-to-end-argument, dat aan de basis ligt van de IP-technologie, controleert alleen een eindpunt of een IP-pakket goed ontvangen is', legt Van Beijnum uit. 'Op tussenstations worden geen controles uitgevoerd. Het netwerk is dus dom en de eindpunten intelligent. Die domheid maakt een IP-netwerk snel.'

5. IPv6 is een bedreiging voor de privacy

'Op het eerste gezicht lijkt NAT de privacy van gebruikers beter te beschermen', aldus Van Beijnum. 'Achter een NAT-box deel je immers hetzelfde IP-adres met een aantal mensen.'

'IETF werkt echter aan een technische methode om eindgebruikers een voorspelbare reeks TCP/IP-poortnummers toe te kennen', vertelt de onderzoeker. 'Gebruikers zijn dan achteraf altijd te identificeren, ook als ze achter een NAT zaten, omdat is terug te rekenen welke TCP/IP-poorten ze ontvangen hebben.'

Binnen IPv6 is het heel goed mogelijk de privacy van internetgebruikers te beschermen, aldus Van Beijnum. 'Op verzoek van privacybeschermers kunnen netwerkbeheerders over IPv6 binnen een lan gebruikmaken van temporary addresses. Daardoor is niet te traceren vanaf welke client binnen een bepaald lan een applicatie wordt gedraaid.'

Wanneer het netwerk niet gebruik maakt van tijdelijke adressen, biedt IPv6 geen privacybescherming. 'De standaardmanier om IPv6-adressen binnen een LAN toe te kennen verloopt via Stateless Auto Configuration (SLAAC)', legt hij uit. 'In dat geval kent het IPv6-protocol automatisch een IPv6-adres toe aan elk apparaat binnen het netwerk. Om het apparaat te identiferen wordt het MAC-adres van het apparaat in dat IPv6-adres verwerkt.' Hierdoor is echter van elk IP-pakket te achterhalen vanaf welk apparaat in het netwerk het verzonden is. Maar voordelen zijn er ook, aldus Van Beijnum: 'SLAAC maakt een Host Configuration Protocol (DHCP)-server binnen een IPv6-LAN overbodig. Zo'n DHCP-server is wel nodig binnen een IPv4-netwerk, om bij te houden welke IP-adressen aan welke apparaten zijn toegekend.'

IPv6-expert Sander Steffann stelde eerder dat NAT de privacy van internetgebruikers zou schaden omdat providers ín pakketjes moesten kijken om deze te kunnen bezorgen. Steffann schreef: 'Als een provider zijn klanten niet meer elk een eigen adres geeft, hoe houdt de provider dan bij welke gegevens naar welke klant gestuurd moeten worden? Daarvoor moet de provider bijhouden wie wat aan het doen is: Deep Packet Inspection!'

Deze bewering gaat Van Beijnum echter 'veel te ver'. 'Een NAT-box kijkt niet ín het pakket: hij ziet bijvoorbeeld niet welke url bezocht wordt. Je zou hoogstens kunnen zeggen dat een NAT-box kan zien welke poorten een internetgebruiker gebruikt en daaruit kan afleiden welke webapplicaties hij gebruikt. Maar als een provider dat wil, kan hij dat ook zonder NAT al doen: ook een router kan IP-pakketten tellen op basis van poortnummers.'

Iljitsch van Beijnum

Iljitsch van Beijnum is onderzoeker aan de Madrileense UC3M-universiteit en het overheids-onderzoeksinstituut IMDEA Networks. Hij ontwikkelt daar onder meer nieuwe IP-technologie, voor het gefragmenteerd en daardoor efficiënter versturen van IP-pakketten over verschillende paden tegelijk. In zijn huidige functie droeg hij bij aan de ontwikkeling van NAT64. Dat is een mechanisme om IPv6-clients te laten verbinden met IPv4-servers. Hij schrijft met regelmaat artikelen over netwerk-architectuur en internettechnologie op online medium Ars Technica. Hij is lid van deNederlandse TaskForce IPv6.

Van Beijnum publiceerde in 2005 een handboek over het gebruik van IPv6: ' Running IPv6'. In 2002 schreef hij een BGP-handleiding: 'Building Reliable Networks With the Border Gateway Protocol'. In 2005 rondde hij een informatica-opleiding af aan de Haagse Hoogeschool. Van Beijnum was stagiair bij XS4ALL in 1995, werkte bij bART van 1995 tot 1997 en begon in 1997 met vier anderen voor zichzelf als Pine Internet, tegenwoordig Pine Digital Security. Tussen 2000 en 2007 was hij zelfstandig consultant.