Een 'beknopte uitleg' van IPv6

[caesar]

Voorwoord.
Ik heb dit artikel indertijd geschreven voor het Ziggo Gebruikersforum (onder een ander pseudoniem), en ik heb het nu wat geactualiseerd voor het Ziggo Community forum.

Inleiding.
Na een niet helemaal gelukte eerste poging, is Ziggo nu opnieuw begonnen met de uitrol van IPv6. Dit document heeft als doel heel globaal duidelijk te maken wat dat is, waarom het moet worden ingevoerd, en wat de gevolgen zijn voor de thuisgebruikers. Het is geen uitgebreide technische verhandeling over IPv6, daarvoor is de nodige informatie te vinden op het internet en zijn diverse handboeken te koop.

Wat is IPv6?
Op het internet maken we gebruik van het Internet Protocol, afgekort IP. Van oudsher maakten we gebruik van IP versie 4, afgekort IPv4. Bij de ontwikkeling van IPv4 heeft men nooit voorzien dat het gebruikt zou worden voor wat vandaag het internet heet. Ieder apparaat dat op het internet wordt aangesloten heeft een eigen uniek adres nodig, en zo'n twintig jaar geleden werd al duidelijk dat het concept van IPv4 niet toereikend is om de toekomstige groei in adressen mogelijk te maken. Men heeft toen besloten een geheel nieuwe versie van IP te ontwikkelen, en die versie heet IPv6. Overigens zijn de IPv4 adressen nu op, Ziggo heeft er nog wel genoeg voor de eigen klanten, maar wereldwijd zijn ze echt op.

De huidige status van IPv6.
Laat er geen enkel misverstand over bestaan, de internet community loopt minstens vijf jaar achterop bij wat de status van IPv6 nu had moeten zijn. Het is het bekende verhaal van iedereen die op iedereen zat te wachten, totdat iemand het initiatief zou nemen om iets te gaan doen.

Wat zijn de gevolgen van de invoering van IPv6 voor mij?
Dat is een beetje afhankelijk van de vraag van wat voor soort gebruiker u bent. Er van uit gaande dat je een doorsnee gebruiker bent die een beetje browst op het internet, wat bestandjes download, en e-mails verstuurt en ontvangt wat zijn dan de consequenties?

• Je heeft een router nodig die IPv6 ondersteund, de modem/routers die Ziggo al enige tijd uitlevert zullen na een firmware update zeker IPv6 ondersteunen. Heb je een eigen router, dan zult je moeten nagaan of die IPv6 ondersteunt, al dan niet na een firmware upgrade. Is dat niet het geval, dan zul je wellicht een passende modem/router van Ziggo kunnen krijgen of anders zelf een nieuwe router moeten kopen.
• Ziggo moet IPv6 activeren op het modem of de modem/router (en dat duurt nog ?????)
• Wat moet je doen om op uw PC IPv6 te installeren? Met 99% waarschijnlijkheid niets, alle PC's met Windows Vista en hoger hebben standaard IPv6 geïnstalleerd.
• Wat moet je doen om IPv6 te activeren op uw PC? Niets, het staat al aan.
• Wat moet je doen om uw applicaties (zoals de browser) gebruik te laten maken van IPv6? Niets, ze gaan er automatisch gebruik van maken als ze IPv6 ondersteunen, en alle browsers doen dat.
• Wat merk je er van als de applicatie gebruik maken van IPv6? Niets, je werkt zoals je altijd werkt.

Conclusie: de meeste gebruikers merken er niets van als IPv6 geactiveerd wordt.


En nu wat meer technische achtergrond.
Het voorafgaande was een hele korte samenvatting van wat IPv6 is, en welke invloed het zal hebben op het werken met internet voor de meeste gebruikers. De volgende paragrafen gaan wat meer op technische details in. Begrijp je het niet helemaal? Lees dan rustig door, verder op staat zeker wel iets dat je wel weer zult begrijpen.

Gaat IPv6 het bestaande IPv4 vervangen?
Het antwoord op deze vraag is heel duidelijk, ja en nee. Om met het laatste te beginnen, als met deze vraag bedoeld wordt of IPv4 uitgezet wordt als IPv6 aan gezet wordt, dan is het antwoord nee. Netwerk programmatuur bestaat uit een vele kleine stukjes programmatuur die bij elkaar horen. Denk bijvoorbeeld aan http dat u gebruikt bij het browsen, of smtp dat u gebruikt bij het verzenden van email. Al die stukjes bij elkaar noemen we een stack. In de IPv4 stack zitten de nodige onvolkomenheden, en daarom heeft men voor IPv6 een volledig nieuwe stack gebouwd. Oppervlakkig gezien lijkt die wel heel sterk op de IPv4 stack, maar onder de motorkap zijn er toch vele verschillen. Hoewel het denkbaar geweest zou zijn dat de IPv6 stack ook met de kleinere IPv4 adressen om zou kunnen gaan, is dat dus daarom niet mogelijk. U gaat dus IPv6 naast IPv4 gebruiken, en dat heet in het jargon in dual stack draaien. Echter op den duur zal IPv4 uitsterven, en houden we alleen IPv6 over. Dus in die zin is het antwoord op de vraag ja, uiteindelijk vervangt IPv6 het oude IPv4.

IPv4 en IPv6 adresruimte en adressen.
De adresruimte van IPv4 is 32 bit. Dat betekent dat er 232 = 4.294.967.295 adressen mogelijk zijn, variërend van 0.0.0.0 tot 255.255.255.255 . Die ca. vier miljard adressen lijken heel veel, maar het zijn er veel te weinig. Neem bijvoorbeeld een gezin met vier personen, hoeveel apparaten met een netwerk aansluiting kun je dan tegenkomen? Laten we eens tellen, drie PC's, vier smartphones, een smart TV, een BluRay speler, een NAS, een printer, een router, en dan zitten we al op twaalf adressen. Als er maar een half miljard van dat soort gezinnen zijn, dan komen we al op zes miljard adressen.

Voor IPv6 heeft men daarom gekozen voor een 128 bit adresruimte, ofwel de astronomische adresruimte van 340.282.366.920.938.463.463.374.607.431.768.211.456 (ca. 4 miljard x 4 miljard x 4 miljard x 4 miljard) adressen. Je kunt daarmee met het grootste gemak iedere zandkorrel op het aardoppervlak van een hele serie adressen voorzien.

Een IPv4 adres wordt meestal geschreven in de zogenaamde dotted decimal notation, ofwel decimale schrijfwijze met puntjes. Eén van de IPv4 adressen van youtube.com is bijvoorbeeld 74.125.235.37. Ieder groepje van cijfers representeert 8 bits, en heeft daarmee de maximale decimale waarde van 255. In de automatiseringswereld is dit feitelijk een heel vreemde manier van weergave, veel gebruikelijker is een hexadecimale notatie. Je zou dat adres dan hebben kunnen schrijven als 4a.7d.eb.25.

Voor IPv6 heeft men daarom wel gekozen voor deze veel gebruikelijker hexadecimale notatie. Het IPv6 adres van youtube is 2404:6800:4001:c01::5d. Ieder groepje van 4 cijfers representeert hier 16 bits, en er zouden dus 8 groepjes moeten zijn (8 x 16 = 128). Hier staan echter maar 5 groepjes, en niet ieder groepje is 4 cijfers groot. Om met het laatste te beginnen, voorloop nullen mogen worden weggelaten, dus 005d mag geschreven worden als 5d. Tussen c01 en 5d staat “::”. Dat betekent dat daar de ontbrekende 3 groepjes staan, en dat ieder groepje als waarde 0000 heeft. Je mag het adres daarom ook schrijven als 2404:6800:4001:0c01:0000:0000:0000:005d. Om begrijpelijke redenen kan die “::” maar op één plaats in het adres voorkomen, als op een andere plaats in het adres ook groepjes van nullen staan dan moet dat geschreven worden als bijvoorbeeld 0:0.

Degenen die gewend zijn zelf IPv4 adressen uit te geven zullen zich nu vertwijfeld afvragen hoe ze dit soort adressen moeten bedenken. Dat doe je normaal gesproken ook niet. Bij IPv6 is het gebruikelijk (maar niet verplicht) om de adressen automatisch toe te laten kennen, bijvoorbeeld via DHCPv6. Dit komt later nog aan de orde. Bij sommige apparatuur is dat ook de enige mogelijkheid. Overigens zullen de meeste gebruikers hun IPv4 adressen ook al automatisch via DHCP laten toekennen.

Als laatste hebben we dan nog het masker. Bij IPv4 zijn we gewend het masker op te geven, we hebben dan bijvoorbeeld het IPv4 adres 192.168.112.30 met masker 255.255.255.0 . Bij dit masker zien we dat van de 32 bits de eerste 24 bits op staan. Een modernere notatie van dat adres plus het masker is daarom 192.168.112.30/24 . Het (sub)netwerk waartoe dit adres behoort is 192.168.112.0/24. Deze notatie met “/24” wordt de CIDR notatie genoemd (Classless Inter-Domain Routing), en die notatie wordt gebruikt bij IPv6.

Er bestaan verder meerdere soorten IPv6 adressen, maar ook daarover later meer.

Uw router en IPv6 bij u thuis.
Tenzij je een PC direct op een modem hebt aangesloten, zult je thuis een router gebruiken. Zo'n router heet in het vakjargon een Customer Edge Router, dus vertaald een klant router aan de rand van het internet. Strikt genomen gedraagt zo'n router zich bij IPv4 niet als router maar als end node. Dat behoeft natuurlijk enige uitleg.

Je krijgt van Ziggo maar één IPv4 adres, en dat adres wordt gebruikt door de WAN (Wide Area Network = Ziggo kant) poort van uw router. De apparatuur aan de LAN kant van de router heeft natuurlijk ook IPv4 adressen, maar dat zijn adressen uit de zogenaamde private address ranges. Dat zijn groepjes adressen die niet op het internet gebruikt worden, en die je daarom thuis kunt gebruiken. Die ranges zijn 10.0.0.0/8, 172.16.0.0/12, en 192.168.0.0/16 . Surf je nu met je PC naar bijvoorbeeld Google, dan wordt dat private address van uw PC vervangen door het IPv4 adres van de WAN poort van de router. Dit heet Network Address Translation, afgekort NAT.

Voor Google lijkt het dus alsof de router iets opvraagt, en niet de PC. Zou de PC een echt global IPv4 adres gehad hebben, en zou de router zich gedragen als een 'echte' router, dan zou Google het adres van de PC zien. Het internet heeft dus geen weet van alle apparatuur op je LAN, het internet ziet alleen maar die ene WAN poort van de router bij IPv4 adressen. Vandaar dus dat bij IPv4 de router zich gedraagt als end node.

Bij IPv6 werkt het geheel anders. Je krijgt dan niet slechts één adres, of een paar adressen van Ziggo, nee van Ziggo krijg je een /56 netwerk. Dat betekent dat je zelf 128 – 56 = 72 bit aan adresruimte hebt. Je kunt thuis in je eigen LAN dus 256 x 4 miljard x 4 miljard adressen uitgeven,. Anders gezegd, je krijgt in je privé netwerk 1000 miljard keer de adresruimte van het gehele IPv4 internet, dus dat lijkt voorlopig wel voldoende.

Standaard IPv6 (sub)netwerken waarop PC's, servers, printers etc. worden aangesloten zijn /64 netwerken. De IPv6 stacks van die apparatuur gaat daar vaak van uit. Je kunt dus thuis maar liefst 256 van die /64 subnetten bouwen met de aangeboden adresruimte. De router krijgt van Ziggo dat /56 netwerk aangeboden, en zal dat onderverdelen. Momenteel zullen van die 256 mogelijk netwerken slechts één of twee direct gebruikt worden met een standaard IPv6 CE router. Dat tweede netwerk kan het zgn. guest WiFi netwerk zijn dat veel routers kennen.

Alle adressen die uitgegeven worden zijn wereldwijd unieke adressen die ook op het internet gebruikt worden. De router functioneert nu dus wel als echte router, en geeft de IPv6 adressen die op het LAN gebruikt worden door aan de web sites etc. op het internet die bezocht worden. Google ziet dus nu wel het (IPv6) adres van de PC. De WAN poort van de router is niet opgenomen in deze adresruimte! Bij IPv6 heeft de WAN poort een adres dat thuis hoort adresruimte van de backbone van Ziggo.

Om IPv6 te kunnen gebruiken heb je dus een router nodig, want alleen die router kan de IPv6 adressen uitdelen. Ziggo zal niet de twaalf individuele IPv6 adressen aan de apparatuur uit het eerdere voorbeeld van het gezin gaan uitdelen, en dat wil je ook niet zoals straks bij de veiligheid ter sprake zal komen.

Veiligheid.
Bij de zojuist besproken IPv4 NAT werking treedt een neveneffect op. Meerdere PC's op het LAN kunnen tegelijkertijd verbindingen opbouwen naar het internet. De router houdt al die verbindingen uit elkaar, en als er data terug gestuurd wordt vanaf het internet, dan weet de router naar welke PC op het LAN die data gestuurd moet worden.

Je kunt echter niet zomaar vanaf het internet een verbinding opzetten naar een PC op het LAN. Immers, je kunt vanaf het internet alleen maar de WAN poort van de router aansturen, en die kan daar zelf niets mee en weet (zonder aanvullende configuraties) ook niet welk apparaat op het LAN wel aangestuurd moet worden.

Het gevolg is dus dat alle apparaten op het LAN niet zonder meer vanaf het internet toegankelijk zijn. Dat biedt dus een grote mate van veiligheid, ook al is dat slechts een neveneffect van NAT. Als je nu toch bijvoorbeeld een webserver wil laten draaien op je LAN, dan moet je gebruik maken van portforwarding. Port 80 is bijvoorbeeld de standaard port van web servers. Je kunt nu op de router opgeven dat een aanvraag voor een verbinding met port 80 op de WAN poort van de router wordt doorgegeven naar port 80 van het adres van één bepaalde PC op de LAN kant van de router. Dit heet portforwarding.

Maar wat als ik nu een tweede webserver wil opzetten op mijn LAN? Dat kun je alleen maar doen door een ander poort nummer te gebruiken aan de WAN kant, bijvoorbeeld port 2080. Dan wordt port 2080 aan de WAN kant doorgegeven aan poort 80 van de tweede PC. In het eerste geval kun je met http://mijnserver naar de webserver van de eerste PC (omdat port 80 de standaard port voor http is), in het tweede geval moet dat met http://mijnserver:2080 , en dan kom je bij de webserver van de tweede PC.

Zou een CE router bij IPv6 net zo functioneren als een normale IPv6 router, dan zou het mogelijk zijn om vanaf het internet toegang te krijgen tot alle IPv6 apparaten op het lokale LAN. Alle IPv6 adressen aan de LAN kant zijn immers echte internet adressen. Toch is dat niet het geval, een goede CE router blokkeert standaard al het binnenkomend IPv6 verkeer vanaf het internet. Als dus beweerd wordt dat bij IPv6 alle apparaten helemaal openstaan voor het internet omdat ze een echt IPv6 internet adres hebben, dan is die bewering onjuist.

Om vanaf het internet toch toegang te krijgen tot apparaten op het LAN moet op de router de toegang tot de betreffende poorten van die apparaten open gezet worden. Sommigen classificeren dit als firewall instellingen, anderen noemen het IPv6 portforwarding. In beide gevallen bedoelt men exact hetzelfde. Al met al lijkt de situatie bij IPv6 heel sterk op de situatie bij IPv4. Het grote verschil is wel dat bij IPv6 altijd de adressen van de PC's op het LAN gebruikt worden in plaats van het adres van de WAN poort van de router. Bij IPv6 wordt in principe geen NAT gebruikt wordt, hoewel IPv6 NAT wel bestaat.

Applicaties kunnen ook zelf de router opdracht geven om poorten open te zetten, dat gaat dan via UPnP (Universal Plug and Play). Dit werkt zowel bij IPv4 als bij IPv6.

Soorten IPv6 adressen.
Bij IPv4 zijn we gewend dat een interface slechts één adres heeft. Dat is het meest gebruikelijk, maar het kunnen er overigens wel meer zijn. Bij IPv6 is het regel dat een interface meerdere adressen heeft.

Zodra het IPv6 protocol aangezet wordt op een interface (er hoeft dus geen IPv6 netwerk actief te zijn!) wordt er meteen een link-local address gegenereerd, en dat adres begint met fe80: . Als je bij Windows in de command prompt, dos box, of hoe je het scherm wilt noemen, het commando ipconfig /all geeft, dan zul je bij alle interfaces zo'n adres zien, zoals bijvoorbeeld een adres als fe80::290:f5ff:fed9:a55f%11 .

Het tweede gedeelte van dit adres (vanaf 290) is het zogenaamde EUI-64 address dat wordt afgeleid van het hardware of MAC adres (in dit geval 00-90-F5-D9-A5-5F) van de interface. De %11 hoort niet bij het adres, het is een zone index in de PC, en dat is hier niet verder van belang.

Twee apparaten die op een switch zijn aangesloten kunnen via deze adressen met elkaar communiceren. Deze adressen zijn niet routeerbaar, twee apparaten kunnen dus niet via een router met elkaar communiceren als ze dit type adressen gebruiken. Denk er aan dat bij een CE router met vier LAN poorten die poorten deel uitmaken van een switch, er vindt tussen die poorten geen routering plaats!

Een tweede type adres dat uitsluitend lokaal op het LAN gebruikt wordt is het Unique Local Address (ULA). Deze adressen vallen binnen het netwerk fc00::/7. Ze kunnen beschouwd worden als de IPv6 vervanger van de private address range bij IPv4. Ze kunnen wel gerouteerd worden, maar uitsluitend binnen het eigen LAN. Deze adressen kunnen dus net zo als bij IPv4 niet gebruikt worden voor verbindingen van en naar het internet. Binnen deze range valt nog Private Administration range fd00::/8. Een voorbeeld van zo'n adres is fd00::290:f5ff:fed9:a55f. Merk op dat het adres sterk lijkt op het voorafgaande link-local address omdat het ook weer het EUI-64 address bevat.

En dan krijgen we tenslotte de global IPv6 adressen zoals ze door Ziggo zullen worden uitgegeven. Ziggo gaat de klanten adressen uitgeven uit de adresreeks 2001:1c00::/23 . Een IPv6 adres van een PC van een Ziggo klant zou er dan bijvoorbeeld zo uit kunnen zien: 2001:1c01:2222:3301:290:f5ff:fed9:a55f. Zoals eerder vermeld is dit een /64 adres, en de eerste 64 bits (2001:1c01:2222:3301:) van dit adres noemen we de prefix.

Ook in dit voorbeeld bestaat het adres weer gedeeltelijk uit het EUI-64 addres. Dat is echter bij Windows niet standaard het geval! Om maximale bescherming en privacy op het internet te waarborgen genereert Windows willekeurige (random) adressen binnen het eigen netwerk. Binnen het netwerk 2001:1c01:2222:3301:/64 zal Windows willekeurige adressen genereren, en dat kunnen er zeer vele zijn! Het kunnen er zelfs zoveel zijn, dat de router er niet mee om kan gaan. Aan het einde van dit artikel vind je daarom instellingen waarmee je deze privacy setting ongedaan kunt maken, waardoor Windows een global adres op basis van het EUI-64 addres gaat gebruiken. Dat kan ook erg handig zijn als IPv6 portforwarding op de router ingesteld moet worden.

Resumerend zul je bij één interface altijd een link-local address adres vinden, mogelijk een Unique Local Address (afhankelijk van de router en zijn instellingen), en zeer waarschijnlijk meerdere global IPv6 adressen. Om het helemaal makkelijk te maken kunnen sommige (niet-Ziggo) routers ook gebruikt worden om aansluitingen te krijgen op twee ISP's. Dan komt er dus nog een reeks global IPv6 adressen (of één) uit een ander netwerk bij.

Als laatste hebben we dan nog het loopback of local host adres. Bij IPv4 is dat 127.0.0.1, bij IPv6 is het ::1.

Hoe worden adressen uitgegeven?
Het is natuurlijk mogelijk om op een apparaat zelf handmatig een IP adres te configureren. Echter meestal zal gebruik gemaakt worden van het Dynamic Host Configuration Protocol. Bij IPv4 is DHCPv4 de enige mogelijkheid om automatisch een adres toegekend te krijgen, bij IPv6 bestaat naast DHCPv6 de mogelijkheid om via het Neighbour Discovery Protocol IPv6 adressen toe te kennen. In feite is die laatste methode de meest gebruikte bij CE routers.

Via DHCP kunnen vele instellingen opgehaald worden, niet alleen maar het IP adres. Die instellingen heten bij DHCP options, en met de options kunnen de instellingen voor DNS servers, de default gateway, de domeinnaam, timeservers en nog vele andere zaken opgehaald worden. De WAN poort van de CE router haalt via DHCPv6 ook de adresrange binnen die de router mag uitgeven op zijn LAN poorten.

Aan de LAN kant van de CE router kunnen IPv6 adressen worden uitgegeven op twee manieren. De eerste is via Stateless Address Autoconfiguration (SLAAC) waarbij gebruik gemaakt wordt van het Neighbour Discovery Protocol. De router stuurt berichten uit met daarin o.a. het prefix gedeelte van zowel de ULA (indien geconfigureerd) als de global adressen. De IPv6 stack van het apparaat dat een adres moet hebben vult die prefix zelf aan, vaak met het EUI-64 adres gedeelte. Ook het adres van de default gateway (router) kan met SLAAC worden geconfigureerd, echter gegevens van DNS servers etc. niet!

De tweede methode is via Statefull Address Autoconfiguration waarbij gebruik gemaakt wordt van DHCPv6. Via DHCP kunnen veel meer instellingen geconfigureerd worden, dus ook de adressen van de DNS servers.

Een combinatie van beide is ook mogelijk, het adres wordt geconfigureerd met SLAAC, en vervolgens worden alle andere relevante instellingen via DHCP geconfigureerd. Dit heet stateless DHCPv6.

Het nog niet opgeloste global DNS probleem.
We komen nu bij onderwerp waar de IP gemeenschap blijkbaar nog niet goed over nagedacht heeft, het lijkt aan de aandacht ontsnapt te zijn. Ik heb daar zelf wat gedachten over ontwikkeld, en dat vind je hier terug. Het is geen eenvoudige kost, dus het is echt iets voor de doorbijters.

Als we een web site op het internet willen bereiken dan doen we dat niet door handmatig een IP adres in te tikken. In plaats daarvan geven we een naam op, bijvoorbeeld www.google.nl. De browser zal dan via DNS bij een DNS server het IPv4 en IPv6 adres van www.google.nl opvragen, en vervolgens met één van die adressen de verbinding opbouwen.

Het IPv4 adres van de WAN poort van onze CE routers heeft ook een door Ziggo toegewezen DNS naam, echter die naam is nogal cryptisch en kan net zo als het IPv4 adres zo veranderd worden door Ziggo. Daar hebben de klanten dus weinig aan. Als je nu wel een webserver hebt draaien die vanaf het internet toegankelijk moet zijn, dan kun je bij een externe organisatie een DNS naam registreren. Een heel bekend bedrijf waar dat kan is dyndns.org. Je kunt daar bijvoorbeeld de naam jansen.dyndns.org registreren, en die koppelen aan het IPv4 adres van de WAN poort van je router. Bijna alle routers hebben een stukje software aan boord dat er voor kan zorgen dat jansen.dyndns.org altijd verwijst naar het juiste IPv4 adres, ook als Ziggo dat adres wijzigt. Dit heet dynamische DNS.

Als alle portforwarding ook goed ingesteld staat, dan kan iemand vanaf het internet bij je webserver komen door jansen.dyndns.org op te geven in zijn browser.

Denk er echter wel aan dat jansen.dyndns.org niet de echte DNS naam van de WAN poort is, het is slechts een alias. De echte DNS naam van de WAN poort is nog steeds die cryptische Ziggo naam. Als je een zogenaamde reversed name lookup doet, ofwel een naam zoeken bij het IP adres van de WAN poort, dan komt uitsluitend de Ziggo naam tevoorschijn.

De apparaten op ons LAN krijgen een global IPv6 adres, en moeten dus via dat adres vanaf het internet benaderd worden, en niet via het IPv6 adres van de WAN poort van de router. Het global IPv6 adres van een apparaat op ons LAN moet dus ook voorzien worden van een global DNS naam, zodat je er bij kunt komen vanaf het internet. Natuurlijk spelen er ook veiligheidsaspecten, maar dat is een ander hoofdstuk en staat los van de principiële methode om die apparaten te kunnen bereiken.

Een global DNS naam moet bij voorkeur geregistreerd worden bij de DNS server van de organisatie die eigenaar is van de betreffende adres reeks. De IPv6 adressen die wij krijgen behoren toe aan Ziggo, en dus zouden de global DNS namen met bijbehorende IPv6 adressen bij de DNS servers van Ziggo geregistreerd moeten worden. Je zou dan het IPv6 adres van je NAS daar kunnen registreren met de naam nas.ziggo.nl. Op zich is dat een volledig juiste wijze van werken, maar zo kan het natuurlijk niet.

Mijn buurman zal zijn NAS wellicht ook willen registreren, en misschien ook wel als nas.ziggo.nl. Dat werkt dus niet. Daarnaast wil Ziggo natuurlijk niet dat klanten direct in de namespace van Ziggo namen gaan registreren, dat wordt een rommeltje. Daar zijn twee oplossingen voor, iedere klant kan een sub-domain binnen de Ziggo namespace krijgen, en/of een eigen domain naam.

In het geval van een eigen sub-domain kun je denken aan een naam als caesar.ziggo.nl of caesar.customer.ziggo.nl, en dan kan ik mijn NAS registreren als nas.caesar.ziggo.nl of nas.caesar.customer.ziggo.nl. Vanzelfsprekend moet gewaarborgd zijn dat alleen de betreffende klant bij zijn eigen sub-domain wijzigingen kan uitvoeren.

Een eigen domain-name zou caesar.org kunnen zijn, echter dat houdt wel in dat de betreffende klant zich moet registreren als eigenaar van het domein, en waarschijnlijk ieder jaar een klein bedrag moet betalen om zijn eigen domein naam geregistreerd te houden. Zo'n eigen domain-name met de bijbehorende registraties van IPv6 adressen etc. zou wel geregistreerd moeten worden bij de DNS servers van Ziggo!

Ziggo zou beide methodes kunnen ondersteunen, zodat de klant kan kiezen. De sub-domain methode zou in mijn optiek de standaard methode voor iedere klant moeten zijn.

Het local DNS probleem.
De global IPv6 adressen en DNS namen moeten dus bij Ziggo worden geregistreerd. Maar wat nu als je op je eigen LAN contact wilt leggen met een ander apparaat, en de verbinding met Ziggo ligt er uit. Dan heb je een fiks probleem, want de DNS server is ook niet bereikbaar.

Hiervoor zijn de ULA adressen feitelijk bedoeld. Dat zijn immers private adressen die alleen binnen je eigen LAN gebruikt kunnen worden. Als de router nu ook een local domain aanbiedt met een bijbehorende DNS server, dan is het probleem opgelost.

De router zou dan bijvoorbeeld het lokale domein my.router kunnen aanbieden, en de NAS zou daarmet zijn ULA adres geregistreerd kunnen worden als nas.my.router. Ook de private IPv4 adressen op het LAN kunnen in die DNS geregistreerd worden, zodat ook apparaten zonder IPv6 adres in in de lokale DNS staan.

Als je nu vanuit bijvoorbeeld je browser contact wilt leggen met je NAS, dan kun je volstaan met nas in de adresbalk in te tikken. De DNS server in de router zal dan het ULA adres terug sturen naar de browser, en de browser zal daarmee aan de slag gaan om de verbinding op te bouwen.

Maar wat nu als ik in mijn browser opgeef dat ik naar nas.caesar.customer.ziggo.nl wil? Dan krijgt de browser het global IPv6 adres aangeleverd om te gebruiken. Dan zou het geheel eigenlijk zodanig moeten functioneren dat de NAS niet direct aangesproken wordt, maar via de router. Daarbij zou de router dit als verkeer vanaf het internet moeten beschouwen, zodat de gebruiker kan controleren of alle beveiligingen tegen inbraak vanaf het internet actief zijn. Hetzelfde gebeurt ook als we via het IPv4 WAN adres van de router verbinding zouden zoeken met de NAS.

Overigens dient de router er voor te zorgen dat zowel de lokale als de globale DNS server bijgehouden wordt.

Afsluiting DNS bespreking.
Het voorafgaande zijn mijn eigen ideeën over hoe DNS zou moeten werken voor de apparaten op ons LAN. Er zijn echter ook een aantal RFC's van de IETF die dezelfde kant opgaan. Het lijkt er op dat de internet community meer bezig geweest is met het nadenken over netwerken in datacenters etc., en niet veel aandacht geschonken heeft aan de specifieke problemen van CE routers en het administreren van apparaten op thuis LAN's. De ISP's zagen IPv6 vooral als kostenpost, en besteedden ook weinig aandacht aan de gewenste functionaliteit. En nu moet dit alles nog ingevuld worden.

Nawoord.
Het voorafgaande is bedoeld om een geïnteresseerde gebruiker zoveel informatie te geven dat hij een globaal idee heeft van de werking van IPv6 op zijn thuisnetwerk. De informatie is zeker niet volledig, daarvoor bestaan boeken over IPv6. Ik hoop dat de informatie echter wel voldoende is om alles wat aan IPv6 informatie te zien is op routers en PC's te kunnen begrijpen.

Addendum.
Windows genereert standaard zeer vele IPv6 global adressen, dit is de zogenaamde privacy setting. Je router kan daar problemen mee krijgen, en om die settings ongedaan te maken moet je met de rechter muisknop de command prompt in administrator mode starten. Geef dan de volgende settings in:

• netsh interface ipv6 set global randomizeidentifiers=disabled store=active
• netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
• netsh interface ipv6 set privacy state=disabled store=active
• netsh interface ipv6 set privacy state=disabled store=persistent

Om de IPv6 tunnel protocollen ook uit te schakelen (die gebruik je niet) kun je deze opdrachten ook nog toevoegen:
• netsh interface ipv6 set teredo state disabled
• netsh interface ipv6 6to4 set state disabled
• netsh interface ipv6 isatap set state disabled

[robbo]

Interessant Caesar! thanks voor al die moeite. Ik had hier en daar al mij laten informeren over ipv6 maar jouw uitleg is zeer compact en duidelijk. En ik denk zeker goed te begrijpen voor iedereen. Gr. Rob

[Takwan]

Beste Caesar ,

Wat een Top Topic ^^ zal voor veel mensen helpen , zeker nu de beide forums samen gaan
duidelijk en zeer goed beschreven :cool:

groet Takwan

[Bas15]

Voor wat betreft het lokale DNS probleem, wat bij IPv4 ook zo is, is er mdns wat steeds meer apparaten ondersteunen.

Dit zie je nu wel eens terug met een thuis nas of router die niet alleen een IP adres laat zien maar ook een naampje zoals "pc-naam".

Ik vind het ook meer voor een client om aan te geven wat zijn naam is bijvoorbeeld in Windows afhankelijk van de zone die je kiest (public , home , office etc). Als je naar een DHCPv4 server kijkt en deze onthoud niet (non volitile memory) aan welke apparaten een IP is toegekent dan kan dit interessante situaties opleveren. Als een windows7 en hoger client verbonden is en de zone op publiek heeft staan dan doet icmp reply niets. En als de dhcp server al zou kijken of een adres al was uitgegeven dan zou deze denken dat dit adres nog vrij is, gevolg: IP conflicten.

Bij IPv6 ligt deze verantwoordelijkheid weer bij de client.

[caesar]

Je ziet hier weer het bekende Unix en IP probleem, op zijn minst een half dozijn verschillende en niet compatibel methodes om in principe hetzelfde te bereiken.

Van oudsher hebben we een heel simpel idee over een IP host (client), dat is een apparaat met één netwerk interface, één IP adres, en één DNS naam. Maar jammer genoeg is dat idee onjuist.

Bij de opzet van IP heeft men een enorme blunder begaan, men heeft niet de eigenlijke host een naam en een adres gegeven, maar een interface. Heeft een apparaat dus 10 interfaces, dan heeft het minstens 10 adressen en namen. Bij OSI bijvoorbeeld is dat niet het geval, daar heeft een apparaat in principe één naam en adres, hoeveel interfaces het ook heeft (het kunnen maximaal drie adressen zijn).

Bij IPv4 kan één interface meerdere IP adressen en meerdere DNS namen hebben, dat is al jaren het geval. Bij IPv6 heeft een interface bijna per definitie meerdere adressen, want met het altijd aanwezige link-local adres kun je vrijwel niets, dus er moet op zijn minste nog een global IPv6 adres bij, en als het even kan ook nog een ULA adres.

Als een IPv6 host in meerdere global IPv6 netwerken hangt (dat kan, er zijn home routertjes die aan twee netwerken gekoppeld kunnen worden, bijv. Ziggo en XS4ALL), dan heeft hij ook twee namen. Bij "naam" moeten we ons er altijd van bewust zijn dat die een unqualified variant heeft ("mijn-pc"), en een fully qualified variant ("mijn-pc.jansen.ziggo.nl"). Bij een aansluiting op twee ISP's komt daar dan nog een tweede naam bij ("mijn-pc.jansen.xs4all.nl"). Hij heeft dan natuurlijk ook twee global IPv6 adressen!

Als je thuis op je LAN ook een domein hebt ("jansen.home") op basis van ULA adressen, dan komt daar nog eens een derde naam (en adres) bij, nl. "mijn-pc.jansen.home".

Maar niemand zegt dat de unqualified hostname overal hetzelfde moet zijn. de xs4all naam zou ook "andere-pc.pietersen.xs4all.nl" kunnen zijn. Alles kan, en dat is nu juist het probleem.

Ik moet op mijn router in de DHCP tabel ook een naam opgeven, en die naam komt dan in DNS te staan. Ik heb onlangs een nieuwe Brother printer gekocht, en hem op mijn router in de DHCP tabel een IPv4 adres en DNS naam gegeven, dus in IPv4 heet hij dan bijvoorbeeld "printer.fritz.box" .

Ik heb ook de IPv6 stack van de printer geactiveerd, en SLAAC zorgde er voor dat hij een global IPv6 en een ULA adres kreeg. Die adressen kon ik in de web interface van de printer terug vinden, echter met reversed name lookup vond ik zo'n cryptische van een MAC adres afgeleidde naam terug. Pas toen ik de host name in de printer zelf had aangepast naar "printer" zag ik bij een nslookup van "printer" zowel het IPv4 als het IPv6 adres. Die naam wordt met stateless DHCPv6 toegevoegd in DNS.

Kortom, het hele DNS gedoe is een vrij lastige materie, en je moet een goed begrip van alles hebben om te begrijpen hoe alles functioneert. Niet zo handig voor de niets vermoedende gebruiker thuis. Nog erger is, zoals ik in het begin van dit draadje al meldt, dat het hele concept van het registreren van global IPv6 adressen en namen van thuis netwerken volledig over het hoofd lijkt te zijn gezien door de IP gemeenschap.

[Roel Broersma]

in mijn ogen slaat Ziggo de plank volledig mis als het gaat om IPv6 en 'Zakelijk Internet';

Neem bijv. een Connect ZZP abbonnement en je krijgt er gratis 8 IP adressen bij (IPv4 adressen). Dat is handig voor ondernemers en bedrijven met een eigen Exchange server, een VPN box,.. etc.
Je krijgt er ook een /64 aan IPv6 adressen bij, echter:

Ziggo maakt geen Reverse DNS aan voor IPv6 adressen omdat er extreem veel adressen zijn...

Dat er 'extreem veel' IPv6 adressen zijn wil natuurlijk nog niet zeggen dat een ondernemer dan ook maar 1000 Exchange servers gaat draaien. Dit betekend dus feitelijk dat je geen Exchange of andere mailserver op IPv6 kunt zetten.
Volgens de Google/GMail 'Sender Guidelines' moet je namelijk de Reverse DNS goed hebben staan (Zie: https://support.google.com/mail/answer/81126?hl=en#authentication ).

Zie hier de reactie die ik kreeg van de Ziggo Service Desk:



Beste Broersma,

Helaas maken wij geen PTR aan voor IPv6. Dit is technisch niet haalbaar omdat er extreem veel adressen zijn.

Met vriendelijke groet,

Edgar de Groot
B2B Service Desk MLE
088 12 12 500 | bsts@office.ziggo.nl | www.ziggo.nl/zakelijk

cid:image004.png@01CE0A9A.1D22E2F0


Van: Broersma, R. - [Gigaweb B.V.] [mailto:roel@gigaweb.nl]
Verzonden: maandag 9 mei 2016 17:18
Aan: Business Services Technical Support; oc@ziggozakelijk.nl
Onderwerp: Reverse DNS pointers wijzigen/aanmaken

Beste Ziggo Zakelijk,

Wilt u de Reverse-DNS voor het IPv6 adres: 2001:xxxx:xxxx:xxxx::xx zetten op: mail.xxxxxxx

Alvast bedankt!

Met vriendelijke groet,

Roel Broersma
Gigaweb B.V.

[Bas15]

Dat is inderdaad belachelijk, ik heb er welgeteld bij Xs4all 2 aangevraagd. Namelijk 2 exchange servers. Dit wordt ook verwacht voor IPv6 mailservers door google om niet als spam aangemerkt te worden.

Daarnaast is het ook geen rocketscience voor een paar programmeurs en een netwerk man om dit eens uit te werken als interface in het klantportaal te bouwen.

[caesar]

Het probleem is de pure onkunde bij Ziggo. Blijkbaar denken ze dat ze voor ieder mogelijk adres in die /64 adresruimte een reverse DNS entry moeten aanmaken. Een idee dat ik wel vaker tegen kom,

Je moet natuurlijk alleen dat soort van entries aanmaken voor adressen die werkelijk in gebruik zijn!

Overigens krijg je volgens mij een /56 adres range van Ziggo, die je dan kunt onderverdelen in 256 /64 netwerken.

Het grote probleem ligt echter bij de IETF die deze hele materie nog niet geregeld heeft. Daarmee bedoel ik dat jouw Ziggo router die reverse DNS entries zelf moet aanmaken bij de DNS servers van Ziggo. Dat gaat gebeuren in de toekomst, als de IETF eindelijk zover is met het definiëren van de standaards.

[almodovaris]

netsh interface ipv6 set teredo disabled

(zonder "state").

[Random]

In bind9 kan je voor alle forward and reverse adressen met 1 regel automatisch het domein genereren met het commando generate ook kan je daarin bijvoorbeeld het ip in hexadecimaal adres in de domein naam gebruiken zoals ziggo doet. Voor de lol heb ik dat ook zo gedaan op mijn local netwerk werkt super simpel.

$GENERATE 0-32	C0A8A4${0,2,X}.vpn	A	192.168.164.${0,0,d}

[Random]

"Roel Broersma" wrote:

Volgens de Google/GMail 'Sender Guidelines' moet je namelijk de Reverse DNS goed hebben staan.

Ik mail al vele jaren met postfix vanaf mijn dynamische ip adres naar en van gmail adressen. Bepaalde instanties zoals bv mailen met fnv.nl mail adressen gaat dan weer niet en zo zijn er enkele andere instanties waarbij het mailen niet werkt op mijn domein dat ik middels ddns aan mijn thuis IP heb hangen. Bij google krijg ik zelfs een dmarc pass.

Als ik reverse domain zou kunnen instellen zou dat probleem opgelost zijn maar met gmail kan ik in elk geval gewoon een en weer mailen.

[Jbr67]

GE WEL DIG artikel. Prachtig uitgelegd.

Het artikel is al weer wat ouder natuurlijk, maar een paar kleine toevoegingen voor wie op deze pagina belandt:
- met SLAAC kun je wel degelijk DNS-parameters toekennen (zie bijv hier: https://wiki.openwrt.org/doc/uci/radvd)
- het uitzetten van privacy extensions is een serieus risico. Bijv. je laptop wordt traceerbaar over verschillende IPv6 netwerken (de droom van elk dienst die aan tracing van bezoekers doet.. en dat zijn er vast heel veel). Ik raad het af!
- voor DNS is het alleen noodzakelijk dat ziggo de reverse adressen delegeert naar een klantspecifieke DNS-server (al dan niet gehost bij ziggo zelf). Voor de forward zone hoeft dat niet....

[caesar]

Beter gezegd, men heeft een SLAAC extensie bedacht om ook DNS gegevens mee te kunnen sturen (RFC 8106) Dit is weer zo'n prachtig voorbeeld van de IP / Unix knutsel- en frutselcultuur waar ik zo de schurft aan heb. Men bedenkt het liefst tien oplossingen voor één probleem, en dan bij voorkeur ook nog zo dat ze onderling niet compatibel zijn.

Die DNS over SLAAC methode zou gebruikt moeten kunnen worden in het geval er geen stateless DHCP server ter beschikking staat. Maar waarom zou zo'n DHCP server er niet zijn? Ieder onbenullig routertje kun je met DHCP uitrusten. Verder kun je met DHCP een enorme lijst met opties meesturen, gaan we die ook nog opnemen in SLAAC? Iedere CE router die mensen thuis gebruiken moet DHCP ondersteunen, simpel.

In de IT moet je met strak omlijnde kaders werken, en niet om de haverklap weer met een nieuwe frutsel oplossing voor de dag komen. Wist je bijvoorbeeld dat er bijna 9000 computertalen zijn? Daarvan zijn er zeker 8950 overbodig, als het niet meer zijn.

Ik kwam er achter dat mijn PC in de standaard opzet (met privacy extensions) zoveel IPv6 adressen genereerde, dat mijn router er in bleef. Toen heb ik die onzin maar uitgezet. Vandaar.

Je wilt echt niet dat Ziggo reverse adressen lookup naar klantspecifieke DNS servers delegeert. Dat zou betekenen dat wrakke niet bijgewerkte DNS implementaties op even wrakke routertjes plotseling aan het internet worden blootgesteld. Neen, Ziggo dient DNS services op hun servers te verlenen aan de klanten, en de CE routers moeten zodanige functionaliteit hebben dat die DNS services automatisch ingericht worden.

[Jbr67]

caesar wrote:
Beter gezegd, men heeft een SLAAC extensie bedacht om ook DNS gegevens mee te kunnen sturen (RFC 8106) Dit is weer zo'n prachtig voorbeeld van de IP / Unix knutsel- en frutselcultuur waar ik zo de schurft aan heb. Men bedenkt het liefst tien oplossingen voor één probleem, en dan bij voorkeur ook nog zo dat ze onderling niet compatibel zijn.

Nou, die exensie voor een RDNS-lijst meesturen bestaat echt al veel langer, vanaf 2010 al (https://tools.ietf.org/html/rfc6106). Die rfc die jij aanhaalt is een specifieke uitbreiding daarop. En het is JUIST goed om geen DCHP meer de te gebruiken. Dat scheelt weer het optuigen van een extra dienst. Dat is juist het UITGANGSPUNT geweest van IPv6 (en SLAAC)! En SLAAC is gewoon compatibel met de M- en O- opties met DHCPv6 (zowel statefull en stateless)

Die DNS over SLAAC methode zou gebruikt moeten kunnen worden in het geval er geen stateless DHCP server ter beschikking staat. Maar waarom zou zo'n DHCP server er niet zijn? Ieder onbenullig routertje kun je met DHCP uitrusten. Verder kun je met DHCP een enorme lijst met opties meesturen, gaan we die ook nog opnemen in SLAAC? Iedere CE router die mensen thuis gebruiken moet DHCP ondersteunen, simpel.

Naar mijn mening draai je het om. Voor standaard situaties zou je helemaal geen DHCP meer nodig hebben. Dat is juist de kracht van IPv6. Alleen in specifieke gevallen is daar nog noodzaak voor. Hoeveel consumenten sturen "exotische" DHCP-opties mee? Het is toch heerlijk om geen DHCP meer te hoeven instellen? Om daar uberhaupt niets voor te hoeven doen! Interface instellen op de router.. bam: klaar.

In de IT moet je met strak omlijnde kaders werken, en niet om de haverklap weer met een nieuwe frutsel oplossing voor de dag komen. Wist je bijvoorbeeld dat er bijna 9000 computertalen zijn? Daarvan zijn er zeker 8950 overbodig, als het niet meer zijn.

Dat (of ze overbodig zijn) vraag ik me oprecht af. Maar enigszins off topic....

Ik kwam er achter dat mijn PC in de standaard opzet (met privacy extensions) zoveel IPv6 adressen genereerde, dat mijn router er in bleef. Toen heb ik die onzin maar uitgezet. Vandaar.

Dat je het uitzet is natuurlijk je eigen keuze. Ik begrijp dat het niet ging om een frutsel-prustel Unix bak, maar Windows (gezien je oplossing)?
Hoe dan ook ... onzin is het absoluut NIET. Het zorgt ervoor dat je, bij het gebruik maken van een laptop op verschillende IPv6-netwerken, je niet traceerbaar bent aan de laaste 64 bits van je IPv6 adres (die bij SLAAC altijd hetzelfde zijn). Overigens: hier staan privacy extensie ook aan (op Linux en Windows), en ik herken het probleem niet.

Je wilt echt niet dat Ziggo reverse adressen lookup naar klantspecifieke DNS servers delegeert. Dat zou betekenen dat wrakke niet bijgewerkte DNS implementaties op even wrakke routertjes plotseling aan het internet worden blootgesteld.

"cynische mode aan" Gelukkig hangen dat soort brakke DNS-jes nu niet aan het internet ..... "cynische mode uit"

Neen, Ziggo dient DNS services op hun servers te verlenen aan de klanten, en de CE routers moeten zodanige functionaliteit hebben dat die DNS services automatisch ingericht worden.

HE doet het ook zo besef ik me nu .... is best wel wat voor te zeggen idd.

[caesar]

Jbr67 wrote:

caesar wrote:
Beter gezegd, men heeft een SLAAC extensie bedacht om ook DNS gegevens mee te kunnen sturen (RFC 8106) Dit is weer zo'n prachtig voorbeeld van de IP / Unix knutsel- en frutselcultuur waar ik zo de schurft aan heb. Men bedenkt het liefst tien oplossingen voor één probleem, en dan bij voorkeur ook nog zo dat ze onderling niet compatibel zijn.

Nou, die exensie voor een RDNS-lijst meesturen bestaat echt al veel langer, vanaf 2010 al (https://tools.ietf.org/html/rfc6106). Die rfc die jij aanhaalt is een specifieke uitbreiding daarop. En het is JUIST goed om geen DCHP meer de te gebruiken. Dat scheelt weer het optuigen van een extra dienst. Dat is juist het UITGANGSPUNT geweest van IPv6 (en SLAAC)! En SLAAC is gewoon compatibel met de M- en O- opties met DHCPv6 (zowel statefull en stateless)

In de eerste plaats is natuurlijk de vraag waar die router de DNS gegevens vandaan haalt, die moeten er ook op de één of andere manier in komen. Ook weer via SLAAC? Willen we dat? Je kunt DHCP niet weg doen, dus je moet het toch blijven houden op iedere stack. SLAAC kan geen volwaardige vervanger zijn van DHCP, dus het enige wat je er mee bereikt is dat je nu twee oplossingen krijgt voor dezelfde functionaliteit. Mijn router functioneert bijvoorbeeld ook als time server, en stuurt dat ook mee in DHCP. Veel beter zou het zijn als er een goede eenvoudig configureerbare DHCP server op iedere router zou zitten, waar je iedere gewenste optie kunt opnemen.

Die DNS over SLAAC methode zou gebruikt moeten kunnen worden in het geval er geen stateless DHCP server ter beschikking staat. Maar waarom zou zo'n DHCP server er niet zijn? Ieder onbenullig routertje kun je met DHCP uitrusten. Verder kun je met DHCP een enorme lijst met opties meesturen, gaan we die ook nog opnemen in SLAAC? Iedere CE router die mensen thuis gebruiken moet DHCP ondersteunen, simpel.

Naar mijn mening draai je het om. Voor standaard situaties zou je helemaal geen DHCP meer nodig hebben. Dat is juist de kracht van IPv6. Alleen in specifieke gevallen is daar nog noodzaak voor. Hoeveel consumenten sturen "exotische" DHCP-opties mee? Het is toch heerlijk om geen DHCP meer te hoeven instellen? Om daar uberhaupt niets voor te hoeven doen! Interface instellen op de router.. bam: klaar.

Neen, want SLAAC kan nooit een volwaardige vervanger zijn van DHCP, op zijn hoogst een heel beperkte. Dus je komt er niet omheen om op iedere IPv6 stack nog steeds een DHCP client in te richten. Het lost dus niets op, in tegendeel. Je kunt te maken krijgen met strijdige informatie.

In de IT moet je met strak omlijnde kaders werken, en niet om de haverklap weer met een nieuwe frutsel oplossing voor de dag komen. Wist je bijvoorbeeld dat er bijna 9000 computertalen zijn? Daarvan zijn er zeker 8950 overbodig, als het niet meer zijn.

Dat (of ze overbodig zijn) vraag ik me oprecht af. Maar enigszins off topic....

Nou, de talen die we zouden moeten gebruiken, die gebruiken we niet. Het is de grote mode om programma's te maggelen in allerlei scripttaaltjes of in C. Allerlei fouten zoals memory leaks, buffer overflow enz. enz., het is voorgeprogrammeerd met dat spul omdat de programmeurs niet de vaardigheden bezitten en er niet genoeg tijd voor nemen om goede programma's te schrijven. Een taal als ADA/GNAT bijvoorbeeld gebruikt bijna niemand. Logisch, want als je daarmee een programma van 100 regels voor het eerst compileert, dan komen er 200 foutmeldingen uit. Maar als je dan alles zover gecorrigeerd hebt dat die foutmeldingen verdwenen zijn, dan heb je een hele goede kans dat het programma ook foutloos functioneert. Daarmee kun je dus betrouwbare applicaties schrijven, en dat zou een zegen zijn gezien de troep die er vaak geproduceerd wordt.

Ik kwam er achter dat mijn PC in de standaard opzet (met privacy extensions) zoveel IPv6 adressen genereerde, dat mijn router er in bleef. Toen heb ik die onzin maar uitgezet. Vandaar.

Dat je het uitzet is natuurlijk je eigen keuze. Ik begrijp dat het niet ging om een frutsel-prustel Unix bak, maar Windows (gezien je oplossing)?

Klopt

Hoe dan ook ... onzin is het absoluut NIET. Het zorgt ervoor dat je, bij het gebruik maken van een laptop op verschillende IPv6-netwerken, je niet traceerbaar bent aan de laaste 64 bits van je IPv6 adres (die bij SLAAC altijd hetzelfde zijn). Overigens: hier staan privacy extensie ook aan (op Linux en Windows), en ik herken het probleem niet.

Ik heb het toch heus gehad, en denk eens na wat dat voor DNS problematiek kan gaan opleveren als we automatisch DNS registratie gaan krijgen?

Je wilt echt niet dat Ziggo reverse adressen lookup naar klantspecifieke DNS servers delegeert. Dat zou betekenen dat wrakke niet bijgewerkte DNS implementaties op even wrakke routertjes plotseling aan het internet worden blootgesteld.

"cynische mode aan" Gelukkig hangen dat soort brakke DNS-jes nu niet aan het internet ..... "cynische mode uit"

Ja, die zijn er genoeg. Als ze maar niet van onze providers zijn, want dan zouden wij direct gevaar lopen.

Neen, Ziggo dient DNS services op hun servers te verlenen aan de klanten, en de CE routers moeten zodanige functionaliteit hebben dat die DNS services automatisch ingericht worden.

HE doet het ook zo besef ik me nu .... is best wel wat voor te zeggen idd.

Dat is ook een voorstel dat bij de IETF ligt. Maar het is natuurlijk belachelijk dat dit soort zaken nu nog geregeld moeten gaan worden! Ik heb me hier jaren geleden al zorgen over gemaakt, en als je daar dan vragen over ging stellen, dan werd er gereageerd alsof ze water zagen branden.

[Jbr67]

caesar wrote:


In de eerste plaats is natuurlijk de vraag waar die router de DNS gegevens vandaan haalt, die moeten er ook op de één of andere manier in komen. Ook weer via SLAAC? Willen we dat?

En waar haalt de ipv4 router dat nu vandaan? Jawel... via DHCP op het WAN-interface. Dus de keten van DHCP requests, worden vervangen door een keten van SLAAC-requests. Boeien. Dus ja.. via SLAAC: dat is het design van IPv6!

Je kunt DHCP niet weg doen, dus je moet het toch blijven houden op iedere stack. SLAAC kan geen volwaardige vervanger zijn van DHCP, dus het enige wat je er mee bereikt is dat je nu twee oplossingen krijgt voor dezelfde functionaliteit. Mijn router functioneert bijvoorbeeld ook als time server, en stuurt dat ook mee in DHCP. Veel beter zou het zijn als er een goede eenvoudig configureerbare DHCP server op iedere router zou zitten, waar je iedere gewenste optie kunt opnemen.

Let's agree to disagree. SLAAC is een (kleine) vervanger van DHCP. By design. Ik heb helemaal geen behoefte aan (het beheer van) een DHCP-server.

Neen, want SLAAC kan nooit een volwaardige vervanger zijn van DHCP, op zijn hoogst een heel beperkte. Dus je komt er niet omheen om op iedere IPv6 stack nog steeds een DHCP client in te richten. Het lost dus niets op, in tegendeel. Je kunt te maken krijgen met strijdige informatie.

Een beperkte idd. En dat is precies goed genoeg, voor een hele hoop situaties. Tegenstrijdigheid klopt niet: SLAAC en DHCPv6 integreren naadloos (uiteraard moet je wel de juiste instellingen configureren.. .maar dat is echt niet nieuw).

Nou, de talen die we zouden moeten gebruiken, die gebruiken we niet. Het is de grote mode om programma's te maggelen in allerlei scripttaaltjes of in C. Allerlei fouten zoals memory leaks, buffer overflow enz. enz., het is voorgeprogrammeerd met dat spul omdat de programmeurs niet de vaardigheden bezitten en er niet genoeg tijd voor nemen om goede programma's te schrijven. Een taal als ADA/GNAT bijvoorbeeld gebruikt bijna niemand. Logisch, want als je daarmee een programma van 100 regels voor het eerst compileert, dan komen er 200 foutmeldingen uit. Maar als je dan alles zover gecorrigeerd hebt dat die foutmeldingen verdwenen zijn, dan heb je een hele goede kans dat het programma ook foutloos functioneert. Daarmee kun je dus betrouwbare applicaties schrijven, en dat zou een zegen zijn gezien de troep die er vaak geproduceerd wordt

Bufferoverflow en memory leaks zijn bekende (en gerelateerde) problemen idd. Dat vereist skills! Maar, een probleem als Heartbleed was niet voorkomen met een andere taal.Dr zat gewoon missende check in.... (een if ontbrak)

Ik heb het toch heus gehad, en denk eens na wat dat voor DNS problematiek kan gaan opleveren als we automatisch DNS registratie gaan krijgen?

Dat is echt een non-issue. Je hoeft namelijk Privacy extended adressen ubehaupt niet te registeren, want die worden puur en uitsluitend (by design) gebruikt voor UITGAANDE sessies. Alleen het EUIDE-gegenereerde (of DHCPv6/manual) adres hoef je te registeren ...want ALLEEN daarop is een eventuele dienst, zoals een web- ftp- of time-server bereikbaar. En ik denk dat programmeurs in het algemeen dat onderscheid echt wel kunnen realiseren in software (c of een andere taal). Ik geef alvast een voorzetje: If privacy-extended-address then nothing else register-ip.

Ciao,
Jbr

[Escovan]

Ja, ik heb dit topic, en de topics op Gathering of Tweakers, en verwezen topics nu doorgenomen en gelezen en gebundeld voor referentie.
Blijft mijn concrete vraag staan:
- ik wil self-hosten over IPv6 (hoeft niet via IPv4, kan ook niet, want CG-NAT)
- ik heb 1x het voorelkaar gekregen voordat ziggo dat deed via Hyper-V en Hurricane Electric, maar dat was volgens de meer deskundigen toch niet de bedoeling.
- ik heb het vorige week ook voor elkaar gekregen met een kale debian + webserver, door het ECHTE IPv6 in de DNS van mijn DNS-boer te zetten. (Was toch een virtueel MAC-adres)
- later probeerde ik het nog een keer met een webmin constructie, maar dat kreeg ik niet aan de praat over IPv6
- Enerzijds is er Ziggo die liever niet heeft dat consumenten allerlei diensten draaien (is dat nog actueel?)
- Dan is er nog Microsoft die liever niet wil dat je Hyper-V client gebruikt om servertjes publiek mee te draaien. Maar ga weg joh, is debian, ik mag toch zelf weten wat ik daar mee doe. Sowieso, ik ben 1 van die zeldzame consumenten die zelf betaald heeft voor Pro windows licenties. Het wordt wel moeilijk gemaakt dus.
- Dan is er nog de firewall in de Connectbox, waardoor een traceroute6 altijd eerst even "onder water" gaat en dan op de backbone uit komt van Ziggo (30ms, nou met lichtsnelheid wil je die afstand niet lopen)
Ik heb nog niet het lef gehad om de IPv6 firewall uit te zetten in de CB.
Reverse records zou ook leuk zijn, gewoon zodat het "klopt" en er "netjes uitziet" (zoals bij HE.Net) maar mail heb ik bij een andere partij, dus noodzakelijk is het niet.

Wie kan mij kort uitleggen, ik ben geen leek - maar ook geen prof, hoe ik mijn selfhosting met Webmin op mijn 2 dikke bijna-servergrade bakken met Hyper-V aan de gang krijg? Of kan ik beter maar meteen iets met VirtualBox doen?

Ohja en de 2001::/ range daar was toch iets mee? (Die ziggo gebruikt voor de DNS?) Dat is toch voor tussenoplossing en tunnels enzo?
En heb ik goed onthouden dat een /64 een subnet is van 2^64 adressen en /128 één eindpunt adres? Stoort dat niet zodanig dat alle lokale verkeer "bloot staat"?

Iemand die meer weet, ook specifiek over routing, schiet alstublieft. Er moeten aan deze kant wat dots geconnect worden.

-- toevoeging: Ohja, en sorry, maar ik heb niet het geld, of de behoefte daar het geld aan uit te geven om een dedicated server in een datacentrum te zetten.

[Hoot_Posthorn]

Super deze thread. Bommetjenokkievol met informatie.

Paar handy-dandy commando's:

Wat leeft er op mijn netwerk:

ping6 -c2 -I en0 ff02::1

Oftewel ping de multicast groep FF02::1, (all ipv6 talkers op het broadcast segment)
Dit is het equivalent van het ipv4 ARP -AN commando wat je liet zien wat er in de arp-cache zit.

note.. ARP bestaat natuurlijk niet meer in ipv6, en dat is maar goed ook.

ndp -a -n # equivalent aan arp -an. in dit geval hebben we het over het neighbor discovery protocol

Dit leest de ipv6 neighbor cache uit. entries blijven max 24 uur bestaan

netstat -f inet6 -rn

FF02::1 All Nodes Address [RFC4291]
FF02::2 All Routers Address [RFC4291]
FF02::3 Unassigned
FF02::4 DVMRP Routers [RFC1075]
FF02::5 OSPFIGP [RFC2328]
FF02::6 OSPFIGP Designated Routers [RFC2328]
FF02::7 ST Routers [RFC1190]
FF02::8 ST Hosts [RFC1190]
FF02::9 RIP Routers [RFC2080]
FF02::A EIGRP Routers [RFC-savage-eigrp-05]
FF02::B Mobile-Agents
FF02::C SSDP [UPnP_Forum]
FF02::D All PIM Routers
FF02::E RSVP-ENCAPSULATION
FF02::F UPnP [UPnP_Forum]
FF02::10 All-BBF-Access-Nodes [RFC6788]
FF02::11 All-Homenet-Nodes [RFC-ietf-homenet-hncp-10]
FF02::12 VRRP [RFC5798]
FF02::16 All MLDv2-capable routers [RFC3810]
FF02::1A all-RPL-nodes [RFC6550]
FF02::6A All-Snoopers [RFC4286]
FF02::6B PTP-pdelay
FF02::6C Saratoga
FF02::6D LL-MANET-Routers [RFC5498]
FF02::6E IGRS
FF02::6F ADT Discovery
FF02::FB mDNSv6 [RFC6762]
FF02::1:1 Link Name
FF02::1:2 All-dhcp-agents [RFC3315]
FF02::1:3 Link-local Multicast Name Resolution [RFC4795]
FF02::1:4 DTCP Announcement
FF02::1:5 afore_vdp
FF02::1:6 Babel [RFC6126]
(Minder relevante weggelaten)


Groet van Hoot

[hanhoo]

caesar Helder artikel en super goed geschreven!

[caesar]

hanhoo wrote:
caesar Helder artikel en super goed geschreven!

Dank je. Het heeft wat tijd gekost om het te schrijven, maar het leek mij toch wel belangrijk dat ieder die dat wil zich een beetje kan oriënteren over de basis opzet van IPv6. Het verschilt tenslotte nogal van IPv4.