Twee weken geleden organiseerden we een prijsvraag waarin we de lezers van Security.NL vroegen wat zij wilden weten over IPv6. We hebben het geweten ook, want er is massaal gereageerd. Deze week zullen we elke dag een aantal van de interessantste vragen laten beantwoorden door IPv6 expert Iljitsch van Beijnum. Ook maken we de inzendingen bekend die het boek "Running IPv6" hebben gewonnen. Voor iedereen die z'n IPv6 kennis wil opfrissen hadden we eerder dit interview met van Beijnum.

Deel 1: Vragen en antwoorden van maandag 3 april
Deel 2: Vragen en antwoorden van dinsdag 4 april
Deel 3: Vragen en antwoorden van woensdag 5 april
Deel 4: Vragen en antwoorden van donderdag 6 april

Vraag: Is IPv6 veiliger dan IPv4?

Dat is nog eens kort maar krachtig. Alleen veronderstelt deze vraag dat er een schaal van veiligheid is die loopt van "Windows XP zo uit de doos zonder firewall" tot "Fort Knox" waarop je IPv4 en IPv6 onder zou kunnen brengen. Zo simpel is het niet. Er zijn absoluut een aantal dingen die in IPv6 een stuk beter en dus hopelijk veiliger zijn dan in IPv6. Bijvoorbeeld, door de grotere adresruimte kunnen wormen zich veel minder makkelijk verspreiden. Door controles op de hop limit kunnen ICMP-pakketten die wel op het LAN, maar niet op het internet thuishoren buiten de deur gehouden worden. Dat zoveel dingen automatisch gaan geeft weer meer risico, maar daar staat SEND (SEcure Neighbor Discovery) tegenover dat het mogelijk maakt autoconfiguratie te beveiligen (als je systeem tenminste SEND aan boord heeft). En...

Vraag: Zal dit protocol kunnen geëxploiteerd worden door de
verbeteringen/vernieuwingen die zijn aangebracht sinds ipv4 ? Zal de protocol
gemanipuleerd kunnen worden door de hacker-cultuur ?

IPv6 zit op zich wel goed in elkaar, problemen als bijvoorbeeld smurf attacks die lange tijd mogelijk waren met IPv4 zal je hier niet tegen komen. Maar omdat de IPv6-code nieuwe code is, kan het natuurlijk zo zijn dat hier nieuwe bugs in zitten die voor nieuwe beveiligingsproblemen zorgen. Wees dus voorzichtig.

Vraag: Is er een mogelijkheid om met de implementatie van IPv6 meteen de
spamproblematiek in te dammen zonder dat het huidige smtp-protocol al te
veel verandering moet ondergaan? Wat zijn hierin de aandachtspunten?

Zolang je bereid bent informatie van onbekenden te ontvangen blijf je altijd tot op zekere hoogte spam houden. Het feit dat het SMTP- protocol geen enkele vorm van authenticatie heeft waardoor een spammer er uitgebreid op los kan liegen helpt natuurlijk niet. Maar dit alles staat los van de IP-versie die je gebruikt. Het enige voordeel van IPv6 wat betreft spam is dat het niet meer praktisch haalbaar is om wormen te laten scannen op open systemen en die dan te misbruiken om te spammen. Maar open systemen zijn ook op tal van andere manieren te vinden dus veel zal het niet uitmaken.

Vraag: Het IPv6 protocol stelt dat voor de Authentication Header de (verouderde) MD5 en SHA-1 Hash algoritmes ondersteunt moeten worden. Blijf je niet het probleem houden, dat bij welke beveiliging je ook voor IPv6 vast legt, deze altijd (te snel) veroudert zal raken?

Je doelt hier op IPsec, waarbinnen je weer AH (Authentication Header) en ESP (Encapsulating Security Payload) hebt, en daaronder weer verschillende hashing- en encryptie-algoritmen. Op het moment dat IPsec gestandaardiseerd werd is MD5 has hashing-algoritme in de standaard opgenomen om te zorgen dat twee IPsec-implementaties altijd een algoritme gemeen zouden hebben. Dat wil niet zeggen dat je verplicht bent een algoritme dat intussen als onveilig beschouwd wordt daadwerkelijk te gebruiken: als je wilt kan je één of meer nieuwe algoritmen gebruiken en MD5 uitschakelen om een "bidding down attack" te voorkomen.

De laatste winnende vraag:

Vraag: Wat zijn nu (naast IPSec ipv SSL) de grootste security verbeteringen t.o.v.
IPv4. Ranges zijn minder duidelijk, en de uitgaande HOP limit is mooi, maar
In hoeverre zijn bijvoorbeeld firewalls goed compatible met IPv6. Linuxes kennen ip6tables, maar hoe zit dit bijvoorbeeld ook met MAC en windows systemen.

In hoeverre zijn de web-services veilig in te stellen met IPv6 voor alle verschillende OS-en. Veel software (nee, niet apache, postfix of wat anders) zijn juist alleen specifiek geschreven voor IPv4 implementaties, hoe zit het met dit soort services als straks IPv6 de standaard is en IPv4 verdwijnt? Moeten er dan ook tunnels gecre-eerd worden, en kunnen dan alleen mensen met een IPv4 tunnel deze services bereiken?

Let op dat het niet zo is dat IPsec in IPv6 SSL in IPv4 vervangt. Zowel IPsec als SSL zijn beide toepasbaar in IPv4 en IPv6. IPsec heeft als voordeel dat ook het TCP-deel beveiligd wordt waardoor een aanvaller de sessie niet kan verbreken. Maar voorlopig heeft IPsec nog te veel (handmatige) configuratie nodig om SSL te kunnen vervangen.

Op de Mac heb je standaard ip6fw, de IPv6-versie van ipfw aan boord. In Service Pack 2 van Windows XP zit enige firewallfunctionaliteit. Ik geloof dat die ook op IPv6 van toepassing is, maar de manier waarop dit alles werkt in Windows is me te onduidelijk om daar iets definitiefs over te kunnen zeggen. Overigens ben je in BSD en Linux beter af met PF, dit is één van de weinige firewall/filtersystemen die IPv4 en IPv6 tegelijk aankunnen.

Programma's die geschreven zijn voor de socket API moeten aangepast worden om met IPv6 te kunnen werken. Dingen die in Java of voor een andere hogere taal/API geschreven zijn werken in sommige gevallen wel zonder aanpassingen met IPv6. Je kan echter vrij makkelijk een IPv4- service in IPv4 beschikbaar maken via NAT-PT, "bump-in-the-stack" of "bump-in-the-API". Het probleem zit 'm meer bij de clients: zolang die geen IPv6 kunnen blijf je toch IPv4 nodig hebben.

Met dank aan Iljitsch van Beijnum voor het beantwoorden van al deze vragen,Vraag: Wat is de verwachte levensduur van IPv6? Er zijn zo onwerkelijk veel adressen mogelijk dat je haast zou denken er decades mee vooruit te kunnen, maar in het verleden heeft men er vaak genoeg flink naast gezeten, alhoewel ik het me nu zo moeilijk voor kan stellen.
Toen 25 - 30 jaar geleden het huidige IPv4-protocol ontworpen werd wisten de mensen die daaraan werkten natuurlijk best wel dat 32 bits niet zo enorm groot is. Maar in die tijd was iedere aardbewoner aansluiten helemaal niet aan de orde: er werd toen gedacht aan militaire en onderzoeksnetwerken. Daarvoor was 32 bits ruim voldoende. Begin jaren '90 toen de Internet Engineering Task Force aan IPv6 begon was het inmiddels duidelijk dat ook anderen wel aangesloten wilden worden en was het doel: "IPv6 has been designed to enable high-performance, scalable internetworks that should operate as needed for decades."

Er zijn allerlei mooie berekeningen in de omloop over de hoeveelheid IPv6-adressen. Bijvoorbeeld: de aarde heeft een oppervlak van 510.065.284,702 vierkante kilometer als we de Wikipedia mogen geloven. Het aantal IPv6-adressen is 3,4 keer 10 tot de macht 38. Er gaan een biljoen (miljoen keer miljoen) vierkante millimeter in een vierkante kilometer. Dit geeft 667.134.927.874.467.426 IPv6-adresen per vierkante millimeter aardoppervlak. Dat is voldoende voor 155 miljard IPv4-internetten voor elk van die vierkante millimeters. Echt heel snel gaat dat niet op.

Wel is het zo dat de 128 bits in een aantal stukken verdeeld worden waardoor we er wat harder doorheen gaan. De rechter of onderste 64 bits worden gebruikt binnen een subnet zoals een ethernet. Hier zie je vaak het MAC-adres in terug. Bedrijven, maar ook personen, kunnen een blok adressen van hun ISP krijgen dat voldoende is voor 65000 van die subnetten. Dit kost nog eens 16 bits. Van de 128 bits mag je er dus zelf 80 invullen en worden er 48 gebruikt om aan te geven van wie het blok is. Verder worden er drie bits voor toekomstige uitbreiding apart gehouden, waardoor er 45 overblijven. Net als dat je niet wat nummers uit 070 naar 020 kan brengen als de telefoonnummers in Amsterdam op zijn gaan er een aantal bits verloren in de praktijk. Dit kan oplopen tot 20%. Blijft over 36 bits. Dit is voldoende voor 68 miljard eindgebruikers. Dus zelfs met dit gooi- en smijtwerk met bits hebben we meerdere adresblokken per aardbewoner. Ieder van die adresblokken heeft voldoende ruimte om duizenden keren alle ethernetkaarten die ooit gemaakt zijn in onder te brengen.

Ofwel: het zal wel even duren voordat de IPv6-adressen op zijn. Maar zeg nooit nooit.

Hiermee komen we op de volgende vraag:

Vraag: Wat zijn de voordelen waarom er ooit voor gekozen dat adressen van laag 2 in ipv6 gebruikt mogen worden? Het enige voordeel wat ik geregeld tegen kom is een mogelijk makkelijker beheer. Nadelen oa verstrengeling van lagen, niet verplicht zijn, netwerk moet zelfde vorm laag2 adressen gebruiken en de adressen van laag 2 zijn niet gegarandeerd uniek per nic.
De reden hiervoor is dat dit het mogelijk maakt een adres te generen uit je MAC-adres als onderste 64 bits. De bovenste of linker 64 bits worden periodiek door routers uitgezonden. Dit heet "stateless autoconfiguration". Het voordeel hiervan is dat zolang routers dezelfde 64 bits uitzenden en het MAC-adres niet verandert, een systeem altijd hetzelfde adres heeft, zonder dat je dit met de hand in moet stellen of je een DHCP-server moet draaien met een ingewikkelde configuratie om dit allemaal bij te houden. In principe horen MAC-adressen wel uniek te zijn, maar voor de zekerheid zal een IPv6-systeem eerst kijken of er niet al een ander systeem het gekozen adres in gebruik heeft door middel van "duplicate address detection".

En dat brengt ons op het tweede deel van deze vraag:

Vraag: Hoe steekt die zelfconfiguratie van IPv6 in elkaar en wat zijn de voordelen zoal?

Korte vraag: Zijn DHCP servers echt verleden tijd met IPv6?

In zekere zin zijn DHCP-servers verleden tijd: je hebt ze niet nodig voor het configureren van een adres of een default gateway. Er is wel een IPv6-versie van DHCP (DHCPv6) en in principe is het mogelijk daarmee adressen uit te delen, maar over het algemeen wordt DHCPv6 voornamelijk gebruikt om extra info zoals DNS-adressen uit te delen. Daarnaast is er "DHCPv6 prefix delegation" waarmee het mogelijk is om een heel blok IPv6-adressen uit te delen aan een router, die dit dan weer met stateless autoconfiguration door kan geven aan andere systemen. Daarnaast is het zo dat huidige operating systems geen support voor DHCPv6 aan boord hebben.

Vraag: Op wat voor manier worden fysieke (MAC) adressen aan IPv6 adressen gekoppeld en wat voor security issues zijn hierop van toepassing?
In veel gevallen zie je het MAC-adres terug in het IPv6-adres. Bijvoorbeeld:

% ifconfig en0
en0: flags=8863 mtu 1500
inet6 fe80::20a:95ff:fecd:987a%en0 prefixlen 64 scopeid 0x4
inet6 2001:1af8:6::20a:95ff:fecd:987a prefixlen 64 autoconf
ether 00:0a:95:cd:98:7a

Er wordt één bit geflipt en in het midden verschijnt ff:fe om het 48- bit MAC adres in 64 bits te laten passen. Het belangrijkste nadeel hiervan is dat als je nu naar een ander netwerk gaat waar de 64 bovenste bits van het adres anders zijn, de mensen/servers waarmee je communiceert je nog altijd kunnen herkennen aan het MAC-adres in de onderste 64 bits. Om deze reden specificeert RFC 3041 dat je in plaats hiervan ook een random nummer in de onderste 64 bits mag zetten. Windows XP doet dit standaard en gebruikt deze adressen dan om naar buiten te gaan terwijl het MAC-gegenereerde adres voor inkomende sessies gebruikt kan worden. In andere OSen moet je dit zelf aanzetten. Tenzij ik me vergis gaat Windows Vista nog een stap verder en wordt daar een random gegenereerd MAC-adres gebruikt. Dit voorkomt dat mensen kunnen scannen op een bepaald merk ethernetkaart. Als je het merk weet, weet je de eerste 24 bits van het MAC-adres dus heb je nog maar 24 bits te gokken, wat redelijk te doen is. 48 of 64 bits gokken/scannen niet, dat duurt te lang.

Vraag: Heb je met IPv6 ook een klasse-indeling vergelijkbaar met de klasse- indeling in IPv4?
Nee, klassen zoals A, B en C zoals vroeger in IPv4 heb je niet in IPv6. Wel is het zo dat de scheiding dat de bovenste 64 bits voor je subnet zijn en de onderste voor binnen het subnet er vrij diep in zit: als je bijvoorbeeld een 56-bits subnet gebruikt kan je geen autoconfiguratie meer doen. Maar je kan het wel handmatig instellen en de routers en routingprotocollen kunnen hier ook zonder problemen mee omgaan.

Vraag: Mag je met ipv6, voor elk domain een ip gebruiken?
Volgens mij is het zelfs toegestaan om bij IPv4 voor virtuele servers een apart adres te gebruiken, hoewel het RIPE NCC al een hele tijd van je eist dat je dan akkoord gaat met het overgaan op name based virtual hosting in de toekomst. Het kan zijn dat die toekomst inmiddels aangebroken is, maar ik kan daar geen informatie over vinden op hun site.

In IPv6 is de regel dat als je zeker weet dat je nooit meer dan een enkel adres nodig hebt, je een enkel adres krijgt. Als je zeker weet dat je nooit meer dan een enkel subnet nodig hebt krijg je een 64-bit subnet. In alle andere gevallen krijg je een 48-bit blok. ISPs kunnen hier wel van afwijken, maar dat is dan hun eigen keuze. Met zo'n 64- bit blok kan je met gemak alle websites van het hele internet een eigen adres geven als je de voorkeur geeft aan IP-gebaseerde virtual hosting. Wel betekent dit meer configuratiewerk voor nieuwe virtuele servers. Maar kort en goed is het antwoord op je vraag ja.

En als laatste de prijswinnaar van deze vragenronde:

Vraag: Kan er, net zoals nu bij RIPE, ipadressen gereserveerd worden. En zo ja, wat zijn de eisen en voorwaarden?
Lang verhaal. De korte versie: alleen ISPs die verwachten binnen twee jaar 200 klanten IPv6-adressen te geven kunnen momenteel een eigen onafhankelijk IPv6-adresblok krijgen. Ben je geen ISP of verwacht je dat je de 200 niet haalt, dan moet je dus adressen van een ISP (of een tunnel broker service waar je een IPv6-tunnel kan krijgen) gebruiken, en deze weer inleveren als je naar een andere ISP gaat.

Morgen de volgende ronde met vragen en antwoorden. De prijswinnaars kunnen het boek "Running IPv6" binnenkort in de bus verwachten.,Vraag: Zullen alle ISPs IPv6 ondersteunen?
Dat hangt er natuurlijk helemaal vanaf of IPv6 een succes wordt of niet. In het verleden heeft bijvoorbeeld de Amerikaanse overheid het OSI netwerksysteem proberen in te voeren (GOSIP) of de programmeertaal ADA. Uiteindelijk is het toch "de markt" die bepaalt wat succesvol is. Als dat met IPv6 het geval is, waar ik wel optimistisch over ben, dan zullen na verloop van tijd alle ISPs IPv6 ondersteunen. Maar hier wordt verschillend over gedacht:

Vraag: Ook al zouden alle IP's op zijn is er geen noodzaak om over te stappen. Immers iedereen die al een IPv4 adres heeft gaat niet moeilijk doen, want alles zal gewoon blijven werken.

[...]

Dus 2012 word niet het jaar voor IPv6. Pas indien overstappen zonder veel investering kosten kan zal men er voorzichtig de stappen gaan zetten. Verder is het verkeerd om naar de wereld te kijken, immers het Chineze probleem is niet het onze.

IP blokken zijn in vijven gedeeld. Wij in Europa maken gebruik van blokken die door RIPE beheerd worden. Pas als die op zijn en ze niet nieuwe blokken krijgen van IANA hebben we een tekort.

Verder zijn er miljoenen adressen die niet in gebruik zijn, maar wel geclaimd worden door bedrijven en organisaties. Sommige hebben al wat van hun IP's ingeleverd en anderen verkopen hun blokken.

Ook heb je in Europa maar een beperkt aantal IP adresen nodig. Immers de adres space is 4.294.967.296 trek daar een derde vanaf voor rfc1928, broadcast etc..

Hou je een slordige 3 miljard over. De wereld bevolking bestaat uit 6,4 miljard. In europa 655 miljoen. Dus 700 miljoen adressen voor alle inwoners 1 plus alle webdiensten is meer dan voldoende. Wij zouden dan te nimmer ipv6 hoeven te gebruiken.

Ten zij men elk apparaat een IP adres wil geven (iets wat waarvoor men ipv6 wil gaan gebruiken) maar dan is het nog maar de vraag of mensen en ISP's hun infrastructuur willen veranderen omdat te kunnen faciliteren. Ook is er nog geen sprake van een "killer" applicatie of druk vanuit bepaalde hoek. Dus de noodzaak om over te stappen is er gewoon niet.
Zo onderhand is het wel duidelijk dat mensen in meerderheid niet bereid zijn om op IPv6 over te stappen alleen omdat het nieuwe protocol op een paar punten beter is dan het oude. Uiteindelijk komt het dan toch neer op de adressen. Er zijn er 3,7 miljard bruikbaar, waarvan er nog 1,4 miljard vrij zijn. Afgelopen jaren werden er zo'n 150 miljoen nieuwe adressen per jaar uitgegeven, ondanks het feit dat er veel van Network Address Translation gebruik gemaakt wordt. Hier zijn de adressen die teruggegeven worden al vanaf. In die 150 miljoen lijkt ook een opgaande lijn te zitten, dus tenzij er ineens iets onverwachts gebeurt zijn ergens tussen 2010 en 2015 de IPv4-adressen op.

Voor de mensen die op dat moment al een IPv4-adres hebben heeft dat niet echt consequenties: die kunnen dit gewoon blijven gebruiken. Maar die ISPs zoals Planet Internet die eens in de één a twee jaar een blok van een half miljoen nieuwe adressen aanvragen hebben dan wel een probleem. (Softbank in Japan kreeg vorig jaar 16,8 miljoen adressen, Comcast in de VS 12,5 miljoen, France Telecom onlangs 8 miljoen.) Tot nu toe hebben in Nederland eindgebruikers over het algemeen hun eigen NAT onder controle, waardoor het mogelijk is poorten open te zetten voor filesharing, VoIP en dergelijke. Als ISPs geen adressen meer kunnen krijgen zullen ze bestaande adressen over meer en meer klanten gaan verdelen en dus NAT voor de klant doen, waardoor protocollen die poorten open willen hebben steeds lastiger zullen draaien. Dit geldt met name voor nieuwe ISPs die weinig adressen hebben en dus veel klanten achter één adres moeten zetten. Op dat moment wordt het handig om IPv6 als extra protocol te draaien om zo toch peer-to-peer protocollen te kunnen blijven gebruiken. Vervolgens wordt het ook voor mensen die zelf wel gewoon een IPv4- adres hebben interessant om IPv6 te draaien omdat ze dan rechtstreeks met degenen die diep achter NAT zitten in IPv4 kunnen communiceren.

Voor degenen die denken dat één adres per persoon wel voldoende is: het Nederlandse telefoonsysteem gebruikt 9 cijfers, wat voldoende is voor 720 miljoen nummers. Dat is 45 nummers per inwoner. Blijkbaar was 8 cijfers, wat vier nummers per inwoner geeft, niet genoeg.

Overigens is het niet zo dat straks in China de adressen op zullen zijn terwijl wij ze hier nog wel hebben: de adressen komen uit een wereldwijde voorraad waar er nu nog ruim een miljard in zitten.

Vraag: IPv6 bestaat al een goede 10 jaar. In de originele planning, als ik mij niet vergis, zou IPv6 gemeengoed zijn eind vorige eeuw - dit is niet gelukt, mede door het gebrek aan ondersteuning vanuit de markt. Veel huidige (IP-)systemen ondersteunen IPv6, maar nog veel meer niet. ISP's genoeg die alleen IPv4 aanbieden en laten we de beheerders van al
deze systemen en netwerken niet vergeten, wat weten zij van IPv6? Eerlijk is eerlijk: zelf ben ik ook nog niet 'over', maar ben wel druk bezig me weer in te lezen in de materie.
Mijn vraag is: hoe gaat IPv6 _wel_ gemeengoed worden, als er nog geen grote vraag naar is? NAT werkt uitstekend; ik zie de voordelen van IPv6 t.o.v. NAT wel, maar of het de kosten voor het herinrichten van netwerken, apparaten, IP-sheets, het opleiden van mensen enz. wel verantwoord betwijfel ik.
In theorie bestaat IPv6 inderdaad tien jaar, want eind 1995 kwam de RFC met de eerste IPv6-specificatie uit. Daarna duurde het natuurlijk nog een paar jaar voordat de eerste IPv6 hard- en software er daadwerkelijk was. En pas sinds ongeveer 2003 is het redelijk volwassen, voor die tijd was alles nog volop in ontwikkeling. Nog steeds zijn er wel een paar dingen die nog wat beter kunnen, zoals een goede manier om achter je DNS-adressen te komen. Begin jaren '90 werd gedacht dat de IPv4-adressen in 2005 op zouden zijn, vandaar dat er toen geroepen werd dat we moesten opschieten. In 2003 leek het erop dat het nog wel 25 jaar ging duren maar toen ging het ineens weer een stuk harder, en nu is 60% van de IPv4-adressen in gebruik en wordt het tijd om eens na te gaan denken. We hebben nog wel minstens een jaar of vijf, dus haast is niet nodig. Het voordeel van een geleidelijke overgang is dat het heel weinig geld kost: binnen vijf jaar wordt toch nagenoeg alle apparatuur en software vervangen dus als je dan oplet dat je spullen koopt die in de toekomst IPv6 kunnen draaien zit je goed.

Voor het activeren van IPv6 en het opleiden van mensen ligt dit wat anders, maar ook daarbij geldt dat als je vijf jaar hebt het veel minder hoeft te kosten dan wanneer je het ineens erg snel moet doen. En vergeet ook niet dat IPv6 nog altijd IP is: het is voor 90% hetzelfde als wat je gewend bent. (Mijn boek is maar ongeveer 250 pagina's en daar staat heel wat meer in dan wat de gemiddelde helpdesker over IPv6 moet weten.)

Nog een vraag over kosten:

Vraag: Het in gebruik nemen van IPv6 gaat gepaard met hoge kosten, zoals bijna elke vernieuwing. Zo is één van de problemen het oplossen van het routeren van IPv6 over een IPv4-netwerk.

Is het niet kostenbesparend om i.p.v. aanpassing van hardware (en software!) gewoon nieuwe hardware gratis (of voor een klein bedrag) beschikbaar te stellen aan de diverse gebruikers?

Voor de gebruikers wel, maar niet voor degene die de gratis hardware subsidieert, lijkt me...

Vraag: Er is een aantal dingen die ik graag zou willen weten van IPv6. Om er toch één uit te picken zou ik graag lezen of er _nadelen_ van IPv6 zijn ten opzichte van IPv4 en zo ja waarom deze nadelen er zijn.

Mochten er geen nadelen zijn dan lijkt het mij interessant meer te weten over de veiligheidsopties van IPv6 en hoe deze verschillen ten opzichte van IPv4.
De pakketheaders zijn groter, waardoor je iets meer bandbreedte aan overhead kwijt bent. Daarnaast is het vooralsnog niet mogelijk om op een goede manier als gewone eindgebruiker met IPv6 van twee of meer ISPs gebruik te maken (multihoming).

Bij IPv6 is goed nagedacht over de beveiliging van ICMP dus dingen als foute redirects of smurf attacks kunnen niet meer voorkomen. Verplichte IPsec helpt in theorie maar minder in praktijk omdat je het nog wel met de hand in moet stellen. De grotere adressen hebben als voordeel dat scannen van adresreeksen niet meer te doen is, dus bijvoorbeeld een slammer worm kan met IPv6 niet. Wel is het zo dat als je op het lokale LAN zit je door allerlei autoconfiguratie wat meer dingen kan zien en/of beïnvloeden dan met IPv4. Bijvoorbeeld, je kan makkelijk de adressen van alle systemen op het LAN achterhalen tenzij de machines een firewall/filter hebben draaien, en als IPv6 aan staat heeft een machine altijd een link local adres op het LAN zelfs als-ie geen echt adres heeft.

Vraag: Al enige tijd heb ik een IPv6 tunnel lopen via de tunnelbroker van xs4al, en ben dan ook zeer geinteresseerd in dit onderwerp, en vind het een goed teken dat er aandacht voor is.

Als (eind-)gebruiker van IPv6 ben ik eigenlijk benieuwd naar problemen die de diverse partijen (ISP, transit provider, enz.) hebben bij het opzetten en leveren van de IPv6 connectiviteit.

Samengevat eigenlijk: Wat houd de diverse partijen tegen om grootschalig IPv6 mogelijk te maken ? Professionele apparatuur kan over het algemeen al overweg met IPv6 ... dus het lijkt wel alsof we allemaal zitten te wachten tot onze buurman ermee begint.
Dat laatste heb je heel goed gezien. Eindgebruikers doen geen IPv6 omdat (onder andere) de contentleveranciers het niet doen en hun ADSL/ kabel-modem/routers het niet aan boord hebben. ISPs doen het niet omdat hun klanten er niet of nauwelijks om vragen. Contentleveranciers doen het niet omdat alle "eyeballs" op IPv4 zitten en omdat de load-balancerleveranciers nog niet zo ver zijn met IPv6. In je eentje IPv6 doen is toch een eenzame aangelegenheid.

Als laatste de winnende vraag van vandaag:

Vraag: ik zou graag willen weten of het mogelijk is om een bedrijf over te zetten naar IPv6 terwijl hun internet verbinding nog steeds via IPv4 gaat.
Dat is inderdaad mogelijk. Er zijn twee dingen die je kan doen: allereerst kan je IPv6 doen via een tunnel. Hierbij heb je 6to4 tunnels die helemaal automatisch werken. Als je een Windows XP machine hebt met een echt adres (dus niet achter NAT) en je zet IPv6 aan, bijvoorbeeld door "ipv6 install" te typen, dan zal de machine automatisch IPv6 doen via zo'n 6to4 tunnel. Deze IPv6-adressen herken je omdat ze met 2002: beginnen. Andere systemen kunnen ook 6to4 maar het moet wel met de hand aangezet en/of ingesteld worden. Je kan ook IPv6 krijgen via een tunnel broker zoals SixXS.

Wat je ook kan doen is intern IPv6 draaien en dan met de IPv4- buitenwereld praten via een proxy of een gateway. Wel moet je software dan IPv6 ondersteunen, wat nog lang niet voor alle software het geval is.

Morgen de volgende ronde met vragen en antwoorden. De prijswinnaars kunnen het boek "Running IPv6" binnenkort in de bus verwachten.,Vraag: IPv4 kent nogal wat tekortkomingen als het gaat om Multicast. Niet alleen zijn er veel te weinig unieke multicast adressen beschikbaar, maar ook het gebruik van NAT zorgt voor nogal wat incompatibiliteit. Met IPv6 zouden al deze problemen opgelost worden, echter de huidige IGMPv2 oplossing (ook wel anysource multicast genoemd) is niet echt geschikt voor multicast distributie van IPTV.

Zal met de komt van IPv6 tevens IGMPv3 op grote schaal geadopteerd worden door fabrikanten of bevat de IPv6 multicast implementatie een ander protocol als IGMP?

Even een kleine uitleg voor degenen die niet zo thuis zijn in bovenstaande materie: multicast is een techniek waarbij je één pakket verstuurt en dat het netwerk er automatisch voor zorgt dat dit bij meerdere ontvangers aankomt. Dit is uiteraard ideaal om audio en video (IP televisie = IPTV) te verspreiden omdat je dan niet naar iedere ontvanger een aparte stream hoeft te sturen. Multicast heeft wel een aantal aparte protocollen in ISP-routers nodig, vandaar dat het voor de meeste internetgebruikers op dit moment niet beschikbaar is.

De originele multicast is Any Source Multicast (ASM) waarbij iedere ontvanger ook kan zenden. Source Specific Multicast (SSM) is simpeler, maar heeft wel een nieuwere versie van het protocol nodig dat hosts gebruiken om tegen routers te vertellen welke multicasts ze willen ontvangen. Bij IPv4 gebruik je het Internet Group Management Protocol (IGMP) versie 2 voor ASM en versie 3 voor SSM. Bij IPv6 heet dit Multicast Listener Discovery: MLDv1 voor ASM en MLDv2 voor SSM. Bij IPv6 heb je 96 bits om multicastgroepen te nummeren dus dat zal het probleem niet zijn.

Het is me niet duidelijk wat precies de status van MLDv2 is: er was nogal wat gedoe omdat hier door Apple patent op geclaimd zou worden. Vreemd genoeg heeft MacOS echter geen MLDv2-support aan boord.

Mijn verwachting is dat de komende jaren zowel IGMPv3 als MLDv2 op grotere schaal beschikbaar zullen komen, maar of het ook in oudere operating systems alsnog ingebouwd zal worden is de vraag.

Een ander onderwerp:

Vraag: 'k Ben eigenlijk nog het meest benieuw naar hoe je nu in hemelsnaam nog een beetje zinnig een DNS moet onderhouden met dit soort lange adressen.

Voor de "forward" DNS is het niet moeilijk: in plaats van of naast een A record van bijvoorbeeld 192.0.2.1 komt er een AAAA record van bijvoorbeeld 2001:db8:31:5:95ff:fef5:246e te staan. Wel een stuk langer inderdaad, maar daar is copy & paste voor uitgevonden. In de reverse DNS wordt het wat irritanter:

a.7.8.9.d.c.e.f.f.f.5.9.a.0.2.0.5.0.0.0.1.3.0.0.8.b.d.0.1.0.0.2 IN PTR www.example.com.

Zie ook dit voorbeeldhoofdstuk over de DNS in mijn.

Het eerste deel van de volgende vraag gaat hier ook deels over:

Vraag: Hoe gaat ipv6 om met dhcp en dns.

Als een host zelf een ipadres kan genereren vanuit zijn macadres zou een dhcp server niet nodig zijn in de kleinere netwerken. Hoe kun je dan toch gebruik maken van een dns server. Wordt dit allemaal handwerk om in te kloppen? Kijkt de host op zijn netwerk om te zien over er nog een dns-server, ntp server en een default gateway aanwezig is. Je kan dan natuurlijk een dhcpv6 server laten draaien werkt dit al goed samen met een dns server? Hoe werkt stateful configuration en stateless configuration.

Ik denk ipv6 sneller gebruikt gaat worden als er sites of services zijn met informatie die niet of langzamer te bereiken zijn onder ipv4. Het kan b.v. een nieuwe versie van een bittorrent systeem of multicast (tv) uitzendingen. Tevens zou het handig zijn als de adsl providers eindelijk dual stack gaan draaien met multicast op ipv6 ondersteuning.

Vraag: Een DCHP-server is inderdaad niet nodig bij IPv6 (ook niet in grote netwerken): hosts ontdekken een default gateway en de eerste 64 bits van hun adres aan de hand van "router advertisements" die door IPv6- routers uitgezonden worden. Serveradressen zoals voor DNS en NTP kan je (nog) niet op die manier vinden dus die moet je met de hand instellen, via DHCPv6 ontdekken, of, wat de meeste mensen doen, daar IPv4 voor gebruiken.

DNS-management is inderdaad ingewikkeld onder IPv6, omdat je niet vantevoren weet wat voor adres een bepaald systeem zal hebben. Ik denk dat de uiteindelijke oplossing hiervoor zal zijn dat systemen hun adres automatisch in de DNS registreren via het Dynamic DNS protocol.

Met het tweede deel van je vraag kan ik het alleen maar eens zijn.

Vraag: Meer te weten te komen over Versie IP6 zodat ik kan toetsen of ik zelf
een grotere slagings percentage heb om weer aan een baan te komen. Als ik dus op een sollicitatie-gesprek, dan kan ik roepen dat ik e.e.a. over versie IP6 weet, en of dat positief zal werken.

Ligt eraan voor wat voor baan je solliciteert lijkt me... Ik geloof niet dat er nu al werkgevers zijn die specifiek selecteren op IPv6- kennis (over een paar jaar misschien wel), maar voor technische beroepen is het bijna altijd een grote plus als een werkgever ziet dat je interesse in de materie hebt.

En de winnende vraag:
Vraag: Wat zijn de gevolgen van IPv6 voor de root zone? Het lijkt erop dat 13
nameservers met IPv6 niet past in de 512 bytes. Betekent dit dat slechts een deel van de root servers IPv6 gaat serven?

(Zie ook de eerdere link naar het hoofdstuk uit mijn boek voor meer uitleg.)

De meeste DNS'en kunnen tegenwoordig meer dan 512 bytes aan via het EDNS0-mechanisme, en bovendien zouden servers de vraag opnieuw via TCP moeten stellen als het antwoord niet in 512 bytes past. Als we hun notulen van de bijeenkomst vorige maand in Dallas mogen geloven, is ICANN's DNS Root Server System Advisory Committee hier nu uit maar moeten we nog even afwachten welke oplossing ze gekozen hebben:

"There is now generally agreed on text about draft recommendation for adding v6 glue to the root zone. RSSAC would like to have the report from Bill Manning on his analysis of resolver behaviour before proceeding. Expected draft report after 31march2006."

Morgen de volgende ronde met vragen en antwoorden. De prijswinnaars kunnen het boek "Running IPv6" binnenkort in de bus verwachten.,Vraag: Kan ik met IPv6 de koelkast laten communiceren met de keukenmachine en in geval van een tekort een boodschappenlijst sturen naar de supermarkt?

Een beetje flauwe vraag, maar toch een antwoord: stel je voor dat je inderdaad een koelkast hebt met een ingebouwd inventarismanagementsysteem. Automatisch een boodschappenlijstje naar de supermarkt sturen kan dan ook wel over IPv4, maar stel dat je vanaf je werk wilt zien of de melk nu wel of niet op is. Dan moet je dus van buitenaf een verbinding maken met de koelkast. Met IPv4 wordt dat lastig, omdat het uitdelen van statische IP-adressen aan koelkasten nogal veel adressen opmaakt. Bij IPv6 zou dit makkelijker kunnen omdat je hier voldoende adressen hebt voor dit soort toepassingen en NAT niet nodig is zodat communicatie van buiten naar binnen in principe gewoon kan. Natuurlijk moet je wel regelmatig updates draaien op de koelkast als je 'm van buitenaf bereikbaar wilt maken.

Vraag: Wat is de meest voor de hand liggende transitie van IPv4 naar IPv6? Met andere woorden hoe zullen we geleidelijk over gaan van IPv4 naar IPv6 en welke stappen kunnen we hierin onderscheiden? En natuurlijk daaraan gekoppeld de vraag wat de werkelijke trigger zal zijn die deze transitie zal doen plaatsvinden, want de schaarste van IPv4 adressen hebben we al tig jaar en die heeft in de tussentijd nog steeds niet voor de overgang gezorgd.

Wat je op dit moment ziet is dat veel bedrijven IPv6 in hun produkten inbouwen: operating systems hebben het al, professionele routers bijna allemaal en software begint langzaam te komen. Ik verwacht dat dit doorgaat, zodat ieder jaar het aantal produkten dat IPv6 aankan groter wordt. Er zullen ook wel meer en meer mensen daadwerkelijk IPv6 gaan inzetten, maar waarschijnlijk blijft dit voorlopig een zeer laag percentage. Pas op het moment dat het voor iedereen duidelijk is dat IPv4 een aflopende zaak is zullen meer mensen gaan overstappen. Ik verwacht dat dit moment aanbreekt wanneer we nog voor drie jaar IPv4-adressen hebben. Op dit moment hebben we nog 1421 miljoen IPv4- adressen vrij en er zijn er de afgelopen 12 maanden 154 miljoen uitgegeven. In dat tempo hebben we nog 9,2 jaar zonder met groei in de adresuitgifte rekening te houden.

Zodra het duidelijk is dat de IPv4-adressen echt binnen een paar jaar op zijn zullen sommige organisaties waarschijnlijk al overstappen op IPv4+IPv6 of zelfs op alleen IPv6. Op het moment dat ISPs geen nieuwe IPv4-adressen voor nieuwe klanten kunnen krijgen zullen ISPs op steeds grotere schaal NAT voor klanten gaan toepassen bovenop de NAT die gebruikers zelf al doen en worden applicaties als VoIP, videochat en peer-to-peer filetransfer steeds lastiger. Met name ISPs die weinig IPv4-adressen hebben zullen dan IPv6 als alternatief promoten. Uiteindelijk wordt het dan ook voor mensen die voldoende IPv4- adressen hebben interessant om IPv6 te gaan draaien zodat ze makkelijker met anderen die diep achter NAT zitten in IPv4 kunnen communiceren.

Op dit moment zie je dat iedereen die IPv6 doet hiernaast altijd ook IPv4 draait. Op een zeker moment zullen mensen alleen IPv6 willen of kunnen draaien, en als ze dan nog met de IPv4-wereld willen kunnen communiceren moet dit via een gateway. (Zie het antwoord op de laatste vraag.)

Vraag: Wat is(in jouw ogen) de meest waarschijnlijk oplossing voor het IPV6 multihoming probleem van kleine organisaties?

Op dit moment bestaat de officiële manier om met twee of meer ISPs te praten (= multihoming) eruit dat je een eigen adresblok van minstens 256 IPv4-adressen gebruikt en met elk van die ISPs het BGP routingprotocol draait. (Hier gaat mijn vorige boek over.) Dit is niet echt supersimpel en grote aantallen van die kleine adresblokjes in de routingtabellen van de grote routers bij ISPs zouden wel eens grote problemen kunnen gaan geven in de toekomst. Daarom kan je als eindgebruiker geen eigen IPv6-adresblok (dat onafhankelijk van een ISP is) krijgen. Als alternatief werkt de IETF nu in de shim6 werkgroep aan een techniek waarbij je van iedere ISP adressen uit de reeks van die ISP krijgt, en als de ISP waarover je communiceert dan down gaat worden de actieve sessies automatisch zonder onderbreking op een ander adres van een andere ISP overgezet.

En de winnende vraag van vandaag:

Vraag: Wat ik me eigenlijk elke keer afvraag als ik het met collega's over IPv6 heb is of er een makkelijke manier is om te inventariseren welke hardware er binnen je netwerk niet 'IPv6 ready' is.

Je kan natuurlijk alle hardware handmatig checken maar zou dit niet makkelijker kunnen?

Ik zie namelijk bij veel van onze klaten 'oude' jet directs staan die geen IPv6 aan kunnen. En om nou IPv4 en IPv6 naast elkaar te laten draaien.. dat wil je in principe niet.

Ik heb hier flink over zitten denken maar uiteindelijk is de enige betrouwbare methode het in de documentatie opzoeken en/of aan de leverancier vragen. Je kan wel een multicast ping (ping6 naar ff02::1) doen om te zien of er soms systemen op het lokale netwerk zitten die IPv6 aan boord hebben, of als je op een systeem waarvan je niet weet of het IPv6 doet een ping naar het localhost adres (::1) doen, maar daarmee haal je niet boven water welke systemen wel IPv6 kunnen maar het uit hebben.

Het is zeer waarschijnlijk dat bij de overgang naar IPv6 er een hoop "legacy" systemen over zullen blijven die alleen IPv4 kunnen. Dit zie je bij iedere grote overgang. Dit betekent niet dat je tot het einde der tijden IPv4 in heel je netwerk moet blijven draaien: een goede oplossing is NAT-PT, wat staat voor Network Address Translation - Protocol Translation. Hierbij wordt het IPv4-adres gecodeerd in het IPv6-adres, bijvoorbeeld 2001:db8:31:5:abc:def:192.0.2.1. (Dit is een geldige schrijfwijze voor een IPv6-adres, het is hetzelfde als 2001:db8:31:5:abc:def:c000:201.) De 2001:db8:31:5:abc:def::-reeks gaat naar een gateway die het IPv6-pakket vertaalt naar een IPv4- pakket voor 192.0.2.1 en natuurlijk pakketten die terugkomen ook weer vertaalt naar IPv6. Zo kan je dus je Jetdirects die alleen IPv4 doen toch bereiken via IPv6. Uiteraard heeft dit wel alle nadelen van NAT. Of misschien komt HP met een update uit en is dit alles niet nodig...