KPN repareert bug met dubbel uitgegeven IPv6-adressen in Box 12-modem

KPN heeft een firmware-update uitgebracht voor zijn Box 12-modem waarmee een langslepend probleem met IPv6-adressen is opgelost. Ook zitten er nieuwe functies in de webinterface, waaronder de mogelijkheid om het modem op Engels in te stellen.

KPN schrijft op zijn forum dat het versie V12.C.24.16.14 voor de Box 12 heeft uitgebracht. Eerder bracht het bedrijf een bèta van die firmware uit. Nu is die versie definitief.

In de firmwareversie repareert KPN een probleem waarover gebruikers al weken klagen. De Box 12 deelt daarbij in sommige gevallen twee IPv6-adressen uit in plaats van een. Een daarvan werkt vervolgens niet, waardoor het betreffende apparaat niet online komt. KPN zegt dat die bug nu definitief is opgelost.

Er zitten meerdere bugfixes in de firmware-update, waaronder een bug waarbij het gastwifinetwerk uit stond na een herstart en waarbij SuperWifi 2-verbindingen soms niet goed werkten. KPN heeft ook de mogelijkheid toegevoegd de interfacetaal op Engels te zetten. Daarnaast is er een aantal instellingen aangepast en versimpeld.

Reacties (44)

[lenwar]

Dit is wel heel pijnlijk en precies 'mijn probleem', met hoe IPv6 in de praktijk werkt. Je ISP heeft invloed op de IP-adressen in je netwerk. Je kunt dus door een spontane wijziging van je ISP problemen in je eigen netwerk krijgen.

Stel dat KPN om reden X je IPv6-range veranderd, dan krijgen alle apparaten in je LAN een ander IP-adres. Nou is dit voor verreweg de meeste consumenten geen probleem (gezien die alleen maar alles op auto-alles hebben staan), maar als thuis eigen DNS-servers hebt staan, dan 'kan' dat vervelend uitpakken
(( N.B. Ik heb persoonlijk nooit meegemaakt dat KPN dat heeft gedaan, maar ze zouden het in theorie kunnen doen, al dan niet door een 'foutje' ))

[Riddled]

Hiervoor kan je unique local address (ULA) gebruiken en alles dus 2 IPv6 adressen toewijzen: 1 ULA voor intern gebruik (waar je dan je interne DNS naar wijst), en eentje van je ISP om over het internet te gebruiken.

[Gimmeabrake]

Ligt het aan mij, of is de complexiteit van alles gerelateerd aan IPv6 een stuk hoger, vergeleken met IPv4? Ik ben software developer van beroep, infra is eerder een hobby. Ik heb een klein homelab waar mijn home automation enzo draait. Toen ik voor Matter/Thread IPv6 aan de praat moest krijgen heb ik een heel weekend lopen klooien - wat een gedoe was dat zeg. Het werkt nu, en ik maak mezelf wijs dat ik het enigszins begrijp, maar volgens mij valt dat stiekem nog vies tegen.

Wat me met name ook tegenvalt is de informatie die ik online kan vinden. Blogs en filmpjes over IPv6 doen me een beetje denken aan filmpjes van Veritasium - de eerste 5 minuten denk je "ja ja, dat snap ik allemaal wel", en dan opeens uit het niets gaat de complexiteit door het dak en ben ik het helemaal kwijt. Een beetje zoals de How to draw an owl-meme.

Ik hoop dat de komende jaren nog een keer het kwartje gaat vallen, want tot nu toe probeer ik IPv6 te vermijden als de pest, en ik besef wel dat we met zijn alleen een keer over moeten.

[GertMenkel]

Mwah, ik denk dat een hoop mensen gewend zijn geraakt aan de eigenaardigheden van NAT en DHCP. Ook heb je veel mensen die vasthouden aan het uit het hoofd leren van IP-adressen (MDNS staat standaard aan en bespaart je zoveel hersencellen!), dat is wel iets lastiger als je meer bits toevoegt natuurlijk.

Over het algemeen werkt het spul gewoon out-of-the-box, al hebben IoT-makers er een handje van om een minimale implementatie te leveren die nergens mee overweg kan. Matter moet, aldus de spec, IPv6 automatisch doen, dus als je daar mee hebt moeten klooien, heeft waarschijnlijk iemand zich niet aan de spec gehouden...

IPv4 en IPv6 zijn eigenlijk niet zo heel anders. De een doet ARP, de ander doet NDP, de een is 4 bytes, de ander wat meer. IPv6 geeft je netwerk standaard 2^64 adressen, IPv4 maar 1. Bij IPv6 routeert je router het verkeer, bij IPv4 ook (behalve dat je router van iedere verbinding poorten en IP-adressen herschrijft, checksums opnieuw berekend, soms inhoud van je pakketten herschrijft, en een tabel met port forwards naast de firewalltabel moet bijhouden, allemaal vanwege NAT).

De grootste oorzaak van verwarring lijkt het feit dat je meerdere adressen hebt te zijn, maar dat is gedaan zodat mensen je apparaat niet kunnen tracken als je van WiFi-netwerk verandert (je standaardadres is gebaseerd op je MAC-adres) en om het probleem van IPv4 op te lossen dat je netwerk nutteloos is als er geen configuratieserver (zoals DHCP) aan staat; bij IPv6 kun je twee apparaten met een kabel aan elkaar hangen en praten ze met elkaar, bij IPv4 moet je eerst een Ip-adres instellen. Het belangrijkste om daar te weten is "een is voor praten met de andere kant van de kabel (denk 169.254.0.0/16 in IPv4 maar dan verdwijnt die niet zomaar na DHCP), een is permanent voor het ontvangen van inkomend verkeer, en de rest is om te zorgen dat websites je device niet uniek kunnen identificeren".

Netwerken zijn helaas niet makkelijk, ook niet bij IPv4. Over de jaren is de kennis over IPv4 allemaal in ons hoofd gesijpeld, en dat maakt IPv6 een stuk uitdagender lijken dan het daadwerkelijk is.

[Reactie gewijzigd door GertMenkel op 25 april 2025 14:28]

[Memori]

Interessant. Het was mij niet helemaal duidelijk na het lezen van jou verhaal dus ik heb er even wat (snel) dieper ingedoken. Klopt dit verhaal een beetje?:

• In IPv6 heeft elke device een Link-Local adres (beginnend met fe80::) dat alleen met het locale netwerk of "buren" kan communiceren. De 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 van IPv4, maar dan alles onder één prefix.
• Elke device heeft ook een Global Unicast Address (GUA). Dit adres kan met het open internet communiceren. Het krijgt een prefix van de ISP (uniek per internet verbinding), en de rest wordt door de device zelf gegenereerd. Als je een statisch IP adres wilt hebben, moet je dus een statish prefix van de ISP krijgen. Wanneer jij een server host of bijvoorbeeld Home Assistant, is dit het adres waarna je wilt toe verbinden.
• Typisch wordt de GUA niet gebruikt om naar andere services / sites te verbinden. Daarvoor wordt een Temporary Address (TA) gegenereerd. Elke nieuwe verbinding een nieuw adres.
• Een collision van TA met GUA is mogelijk maar zeer zeldzaam, en dit wordt automatisch opgelost.
• De prefix 2001:db8:: is de example.com van IPv6 adressen.

[GertMenkel]

Kleine opmerking: link-local is link-local, dat wil zeggen dat een extra router in het midden niet per se bereikbaar is of te vinden is. Voor de veiligheid kun je het beste aannemen dat het alleen werkt tussen apparaten aan dezelfde kabel/op hetzelfde access point. Wil je een alternatief voor 192.168/10/172.16, dan moet je naar ULA's kijken.

Je zult niet een tijdelijk adres per verbinding krijgen. Met ipv6 privacy extensions wisselt je IP standaard elke dag. Dat is vrij te kiezen, maar als je te vaak wisselt (heb zelf met "iedere minuut" geëxperimenteerd) kun je zoveel hangende IP's krijgen dat je netwerkstack instort. Je computer geeft je tijdelijke adres pas vrij als hij zeker weet dat geen enkele applicatie het oude adres meer gebruikt, en sockets willen nog wel eens blijven hangen.

Als je een interne server opzet, zou ik een ULA configureren. Dat is in feite een apparaat dat roept "op dit netwerk is fd12:234:…:/64 in gebruik". Net als bij de GUA kiezen apparaten zelf een IP, maar dit IP is niet vanuit internet bereikbaar. Omdat dit vrij te kiezen is, blijft dat IP dus ook hetzelfde als je van provider wisselt. Als je Home Assistant instelt op diens GUA en van KPN naar Freedom gaat, moet je al je apparaten opnieuw instellen. Gebruik je een ULA, dan werkt alles nog.

[Gimmeabrake]

Matter moet, aldus de spec, IPv6 automatisch doen, dus als je daar mee hebt moeten klooien, heeft waarschijnlijk iemand zich niet aan de spec gehouden...

In mijn geval niet denk ik. Mijn provider Freedom Internet zal het allemaal netjes geregeld hebben, denk ik. Ik had het zelf nog niet netjes geregeld. Ik draai OPNSense op mijn router, en had na mijn laatste verhuizing IPv6 overal uitgezet met het idee dat ik me er later wel een keer in ging verdiepen. Bij het kopen van Tado X radiatorknoppen - die Matter/Thread gebruiken, was ik even vergeten dat ik dan dus ook mijn IPv6-setup werkend moest gaan krijgen.

Je bewijst met de rest van je verhaal wat mij betreft eigenlijk mijn punt. Er is een groot verschil tussen wat een infraprofessional met netwerken doet, en wat een hobbyist ermee doet. Profi's overschatten denk ik ook hoeveel kennis je moet hebben om een fancy thuisnetwerkje neer te zetten, en daarmee dus ook wat wij hobbyisten allemaal al begrijpen.

Als hobbyist hoef je voor een IPv4-setup alleen een paar simpele concepten hoog over te begrijpen. Je moet begrijpen hoe IPv4-adressen en -netwerken werken, en je moet begrijpen wat de technologien NAT en DHCP doen. Daarmee kun je al een zelf een router veilig configureren. Begrijpen stelt hierbij ook niet veel voor: DHCP is voor ons "dat ding wat je aanzet dat IP-adressen uitdeelt". Je hoeft niet te weten dat DHCP op layer 2 pakketjes uitwisselt om je layer 3 IP-adres te hosselen. Ik heb pas geleerd wat ARP-tables zijn toen een infra-collega me een keer vertelde over Ettercap, en ik me voor de lol een beetje in verdiepte. NAT is voor ons dummies juist heerlijk, elk interne apparaat heeft een intern één IP-adres, en dat adres is makkelijk te herkennen als intern adres omdat het IPv4-adres in een herkenbare range valt. Door NAT zijn ook VLANs best makkelijk te begrijpen. Je moet eigenlijk alleen maar beseffen dat je nu interne netwerken niet meer fysiek hoeft te scheiden met aparte kabels, maar dat netwerken over dezelfde kabel kunnen gaan doordat er labels op je netwerkpakketjes worden geplakt. Met SDN-oplossingen zoals Unifi is dit ook zo in elkaar geklikt.

Maar nu is er IPv6. Mijn router heeft een IPv4-adres, maar een IPv6-range. Mijn apparaten krijgen opeens allemaal een adres in die range. Het veilige gevoel wat ik van NAT kreeg, dat het eigenlijk een firewall as a technology is, is al uit het raam. Daarnaast is er nu DHCPv6, dat opeens heel anders is - en er is nu opeens iets dat SLAAC heet en een alternatief schijnt te zijn? Maar wat doet DHCPv6 eigenlijk als ik zelf niet meer een intern netwerk definieer? En wat zijn die link-local adressen opeens, en waarom heb ik geen controle over hoe die worden aangemaakt? En hoe werken VLANs dan als alles gewoon zelf een WAN-adres en link-local adres krijgt? Moet ik zelf ook nog netwerken definiëren, en komt er dan nog een derde adres bij? En hoe gaat de firewall dan met al die adressen om? Welk verkeer wordt er geblokkeerd, en welk verkeer niet?

Als je al jaren professioneel met netwerkinfra bezig bent heb je nog veel diepgaander begrip van hoe netwerken werken, beantwoord je al die vragen waarschijnlijk zo. Voor de gemiddelde Tweaker die niet in de netwerkelarij zit, is IPv6 volgens mij nog veel hocus pocus.

[GertMenkel]

De fritzbox van Freedom heeft allerlei issues met ipv6 bij mij, vage firmware-issues met de firewall bijvoorbeeld.

Als hobbyist hoef je voor ipv6 niets te doen. Of je nu DHCP of SLAAC doet, je apparaten krijgen gewoon een adres.

Dankzij SLAAC is DHCP niet nodig binnen je thuisnetwerk bij ipv6 (al zie je dat netwerkbeheerders die vast zitten aan ipv4 dat vaak alsnog opzetten). Je router roept "ik heb een route naar internet en mij ip begint met 2001::db8", en je computer kiest zelf een uniek IP dat met 2001::db8 en routeert automatisch het verkeer via je router.

Als je dat mechanisme niet wil gebruiken, kun je DHCP aanzetten, met de opmerking dat Android geen DHCPv6 doet dus ik vraag me af waarom je de moeite zou nemen. Het wordt nog wel eens gebruikt om DNS-servers en WINS-servers in te stellen, en voor het verkrijgen van een blok adresruimte als je routers achter routers hangt, maar op je computer is het praktisch optioneel.

Link-local is een adres op de link. Daarmee kun je twee computers met een ethernetkabel aan elkaar hangen en kunnen ze gewoon met elkaar communiceren. Iets dat ontbrak bij IPv4, en is opgelost met halfoplossingen zoals 169.254.0.0/16.

Je adressen werken net zoals bij IPv4. Ook bij ipv4 kun je gewoon tien IP's aan een interface hangen. Die hoeven ook allemaal niet naar internet te leiden. Ik kan 10.1.2.3, 192.168.1.252, 192.168.1.253, 172.17.44.98, en 100.100.33.55 veilig aan mijn ethernetadapter hangen en daarmee vier netwerken bereiken, eentje zelfs met twee IP's. Mijn computer kiest de beste route voor het verkeer, of die nu via DHCP of Route Advertisements worden gecommuniceerd naar mijn PC.

Je mág extra netwerken definiëren, net zoals in mijn IPv4-voorbeeld. Ligt er maar net aan wat je wilt, natuurlijk. Ik vind een ULA naast mijn GUA praktisch, maar je kunt zonder ULA prima werken. Je zult dan wel je interne adressen in je hosts file/DNS server moeten veranderen als je van provider wisselt. Daarmee is het grootste probleem met IPv6 voor veel netwerkenthusiastelingen opgelost.

VLANs werken op een laag onder IP dus die werken hetzelfde. Je stelt ze in per interface.

Je hebt gelijk dat NAT een gevoel van veiligheid geeft, maar meer dan een gevoel is dat niet. De veiligheid komt van je firewall, en die staat op default-deny voor binnenkomend verkeer. NAT bypasst zelfs je handmatige firewall-regels, waardoor aanvallen als NAT-slipstreaming je firewall compleet kunnen omzeilen op consumentenhardware en ieder IPv4-apparaat op het internet bereikbaar kunnen maken.

Als je niets weet van netwerken, hoef je je er geen zorgen over te maken. Dingen als VLAN's en ULA's en DHCP komen niet aan bod als je niks van netwerken weet. Het probleem begint juist als je een klein beetje in de netwerkwereld gaat duiken en erachter komt dat het IP dat je computer denkt te hebben bij IPv4 helemaal niet het IP is dat de rest van de wereld ziet

[Xander2]

Over het algemeen werkt het spul gewoon out-of-the-box, ..

Nope, bij vrijwel iedere ISP heb ik gezeik en fine-tuning nodig. Ook bij extern geplaatste GSM apparaten in buitenland. Dan, Windows accepteert niet altijd DNS broadcasts via ipv6 etc. Het gaat nooit vlekkeloos. ULA geeft te veel vrij (yup sommige dure licensing software lepelen die door), dhcpv6 conflicten waar de ISP fout zit maar ik met het gezeik zit. Pakketten met ipv6 adres die onverhoopt door worden gezet ook al zeg je anders.

NAT ipv4 is solide en garandeert privacy in het achterliggende netwerk. Privacy, geen encryptie, geen magische veiligheid, maar ik kan wel zien op een aantal kernpunten wat er gebeurt. Dat werkt out-of-the-box. ipv4 is in 1 blik duidelijk welke machine het over gaat, ipv6 is puzzelen en vergelijken. Want ULA klinkt leuk maar sommige boards randomizen hun MAC. Net als smartphones, met reden. Feest.

Ik kan prima routen, firewallen en controle uitoefenen op het achterliggende netwerk zonder met alle ipv6 extensies en mogelijkheden rekening te houden. Het is oersimpel. De uitlevering van IP adressen/adres lookup is op één punt dat ik vaststel, de router bepaalt of en hoe de routing, niet het apparaat, complete misvatting van de ontwerpers. Geen gezeik met een ipv6 stack met andere timing/invulling extensies en vervolgens niet bereikbaar is (ja, leuke printers e.d.).

Ik snap best dat ipv4 globaal een probleem oplevert maar ipv6 is opgesteld met de ouderwets naïeve gedachte dat elk apparaat verbinding met elkaar moet kunnen hebben en zo werkt het niet. Er is geen unaniem vertrouwen mogelijk, onzin, en dus geen reden om p2p zomaar toe te staan, gaat niet gebeuren.

Nee, ik wil standaard geen firewall willen toevoegen, dat regelde NAT prima out-of-the-box en sommige ipv6 routers doen dat al extra voor ipv6 adressen. Voor mij is NATten geen performance probleem. 1 extra stap na adreschecken en voor routing. Een hardware assisted low-power MIPS cpu kan dat al jaren aan voor 1Gb/s snelheden en die IP hashtable met extra geheugen is geen probleem.

De ipv4 methode was meer dan prima, de issues zijn routertabellen en beschikbare adressen. Maar dat is voor 90+% van de gebruikers niet relevant, technisch geen probleem en al die ipv6 extensies maakt o.a. privacy kwetsbaarder.

ipv6 is te complex voor het eindtraject, ipv6 wil te veel en is verkeerd geëngineerd. Dat is een feit wat niet te ontkennen is omdat adoptie buitengewoon moeizaam en langdurig is. Het is mislukt, maar iedereen beweert dat het probleem begrip/kennis is terwijl duidelijk is dat ipv6 een gedrocht is terwijl ipv4 eenvoudiger is en prima functioneert. Er is geen meerwaarde aan ipv6 buiten een grotere adresruimte.

Als je 4 clusters achter ipv4 gehangen had (64 bit ipv 32bit nu als elk modern systeem) waren er nul problemen geweest met de overstap (gewoon een lokale prefix) en was alle functionaliteit behouden met mega uitbreiding.

[nout77]

Dank voor de goede uitleg! Tvt

[necessaryevil]

Ik ga er van uit dat ik mijn standpunt heb gevormd door mijn beperkte kennis en doordat, in jou woorden, er door de jaren heen IPv4 kennis naar binnen is gesijpeld, maar het lijkt me voorlopig toch wel lekker om al m'n apparatuur te verstoppen voor de rest van het internet. Al is het maar om lecht beveiligde apparatuur te firewallen, of omdat mijn provider niet hoeft te weten hoeveel apparaten ik aan het internet heb hangen.

Waar zit mijn denkfout?

[dmantione]

Absoluut niet, je kunt dikke boeken met netwerktheorie zoals DHCP, NAT, ARP allemaal weggooien, IPv6 maakt netwerken veel eenvoudiger. Je moet alleen even anders leren denken.

In het aangehaalde voorbeeld is zelfs het instellen van een ULA niet echt noodzakelijk, want elke machine heeft al volautomatisch een link-local address gebaseerd op zijn mac-adres. In een eenvoudig netwerk (bijv. een thuisnetwerk met een router en 3 computers) werkt dat al prima en kun je zo apparaten met elkaar laten praten zonder afhankelijkheid van de ip-adressen die je van je internetaanbieder krijgt.

[Tozz]

IPv6 is in veel situaties makkelijker. En eigenlijk is het grotendeels gewoon identiek aan IPv4.

Er zijn wel verschillen, zo kent bijvoorbeeld IPv6 geen ARP meer, maar heet dat ND. En zo zijn er nog wel wat zaken anders.

Wat wel vervelend is, in mijn beleving, dat er nog best wel heel veel apparatuur is dat buggy IPv6 support heeft. Dit is daar weer een voorbeeld van. Zo heb ik ooit ook een Cisco SB switch gehad waarbij IPv6 niet werkte in combinatie met VLANs (neighbor discovery gebeurde altijd op het native VLAN, ongeacht wat je instelde). Cisco weigerde dat ook te fixen, ik heb geld teruggestort gekregen van Cisco.

IPv6 support in bijvoorbeeld FortiGate, en dan met name prefix delegation, is ook nog steeds behoorlijk ruk. Vaak werkt het 'ineens' niet meer zonder aanwijsbare reden.

Dat soort problemen maken IPv6 soms echt een 'pain in the ass'.

[Snow_King]

Ligt echt aan jou. IPv6 is juist veel makkelijker. Geen NAT meer, het is gewoon pure routering. Het leven met gewoon weer P2P connecties is veel makkelijker.

We zijn echter zo gewend aan IPv4 met zijn NAT en DHCP dat we dat als makkelijk beschouwen.

[fm77]

Het is zeer herkenbaar wat je zegt...
Ik heb ook de nodige netwerkcursussen gehad in de afgelopen 20-30 jaar. Maar nu ik er qua werk niet meer mee te maken heb, en het dus zelf moet uitvogelen merk ik dat ik er eigenlijk helemaal niets van snap.
Een apparaat heeft een uniek netwerkadres. Daar kan je mee werken.
Maar met ipv6 ben ik dat helemaal kwijt.

Als voorbeeld heb ik thuis een adguard home server draaien. Daarin probeer ik clients zoveel mogelijk duidelijk in beeld te krijgen door ze een naam te geven. Maar elke keer krijgen ze weer een nieuw ipv6 adres. Is geen pijl op te trekken voor iemand die redelijk verstand dacht te hebben van netwerken
Ook heeft de adguard server meerdere ipv6 adressen, dus is het maar gokken welke de juiste is. Maar wellicht heeft dat te maken met dit probleem (dubbele adressen dus).

Dus ik vind het dus ook vrij lastig om om te schakelen van het oude systeem naar het nieuwe. Ik heb het geprobeerd, maar het wil (nog) niet echt lukken...

[Reactie gewijzigd door fm77 op 25 april 2025 22:39]

[lenwar]

Klopt, maar dit is dan weer ander gedoe als je je netwerk hebt gesegmenteerd. (dus als je wilt dat je ene netwerksegment X ontvangt en een ander netwerksegment Y ontvangt van je DNS-server, enz.) Dan ligt het er weer net aan wat voor spullen je in huis hebt of, en hoe je dat dan weer kunt oplossen.

Maar inderdaad. ULA-adressen kunnen een prima oplossing zijn.

[RobertMe]

ULAs werken prima met een gesegmenteerd netwerk, die zijn juist prima routeerbaar.
Ben je mogelijk niet in de war met link-local adressen? Die zijn juist weer niet routeerbaar.

En @Riddled noemt ULA en dat je 2 IP adressen hebt. Maar je hebt er sowieso al altijd 2, link local en GUA (het publieke adres). Bij het gebruik van ULAs krijg je dus al 3 IP adressen. En dat is dan nog onder de ("incorrecte") aanname dat je maar 1 IP adres per prefix/subnet hebt. Maar eigenlijk heb je er 2. Eentje heeft een vaste suffix, gebaseerd op het MAC adres, maar deze wordt niet gebruikt (voor uitgaand verkeer) en eentje die elke X uur veranderd, die wel wordt gebruikt, voor uitgaand verkeer. Met gebruik van alleen link local + GUA (standaard situatie dus) heb je effectief 3 IP adressen dus. Eentje waarmee je alleen in hetzelfde segment bereikbaar bent (en gebruikt om met anderen binnen het segment te babbelen, broadcast verkeer etc dus), eentje dat je zelf gebruikt om het internet op te gaan (en waar antwoorden op binnen komen), en eentje om vanaf het internet bereikbaar te zijn, voor "nieuw verkeer" ("poort open zettten" doe je op basis van dit adres). Geef je vervolgens op je eigen netwerk ook nog eens ULAs zullen daar naar ik aanneem nog eens 2 adressen bij komen (ook weer een "vaste" en een middels de "privacy extension").

[lenwar]

Ja, je hebt helemaal gelijk. Ik haalde ze door elkaar.

Ik gebruik zelf Unifi hardware en die suffe management software van Ubiquity ondersteunt geen ULA-adressen, aldoende haalde ik het door de war.

[GertMenkel]

Ik heb om die reden een servertje op mijn netwerk draaien dat een ULA aankondigt. Scheelt gedoe als ik ooit van provider wissel. Hoeft niet eens op je router te draaien (al is dat wel zo makkelijk).

Fritz!boxen bieden deze instellingen vanuit de fabriek aan (Network > Network Settings > Additional settings > IPv6 settings > "Assign unique local addresses (ULAs)"; hier kun je ook een eigen prefix kiezen als je daar een voorkeur voor hebt).

[tvtech]

ik snap alleen niet waarom je dan een fd adres krijgt en geen fe kunt instellen. Niet dat dit dan een probleem is, het probleem is juist dat ik niet snap waarom dit een fd adres is terwijl Windows altijd fe80 gebruikt dacht ik. Of is het gewoon dat fc, fd en fe80 adressen allemaal gewoon ULA adressen zijn?

[GertMenkel]

fe80 is een speciaal adres, op dezelfde manier dat 10. speciaal is in IPv4.

fe80 is link-local, dus is niet te gebruiken als je bijvoorbeeld een tweede router of een wifi access point hebt. Het is vooral om te praten met mensen op dezelfde switch, eigenlijk.

Officieel is een ULA altijd in fc00::/7, maar een gedeelte daarvan is nog niet toegewezen. fd00::/8 is daarom de standaard.

Er zitten nog wat andere regels aan on conflicten te voorkomen, maar eigenlijk is de rest van het adres na fd eigenlijk vrij instelbaar. Je zou eigenlijk een willekeurig netwerk-ID moeten kiezen, zodat niemand met elkaar in conflict raakt. Zou onhandig zijn als je werk-VPN en je thuisnetwerk allebei netwerk-ID 1234 kiezen en je de voordelen van die ULA's kwijt raakt.

Je hebt na fd nog 40 bits aan adresruimte om zelf te kiezen, dan 16 bits voor subnets (handig als je routers achter routers hangt, want alle clients van een router moeten eigenlijk in een subnet), en dan de normale 64 bits voor het bepalen van een adres a la SLAAC.

Als je IP normaal 200a:1234:...:aabb:ccdd is (gebaseerd op je MAC) , kun je in één privénetwerk met netwerk-ID dedeccddee hebt, en je subnet 1 pakt om mee te beginnen, eindig je dus met IP-adres fdde:decc:ddee:1:aabb:ccdd en kun je alle 2^80 IP-addressen in fdde:decc:ddee::/48 in je privénetwerk bereiken.

Je kunt in theorie gewoon een identifier kiezen, en als je geen moeilijke dingen in je netwerk doet, kun je je subnet-ID in de praktijk ook leeg laten. Niks voorkomt dat je fdd0:123::/64 gebruikt, maar het maakt de kans dat iemand anders ook besluit om op die manier de spec te negeren in hun VPN en dan krijg je dezelfde problemen als wanneer je werk net zoals jij 192.168.1.0/24 gebruikt.

[Reactie gewijzigd door GertMenkel op 25 april 2025 15:34]

[The Third Man]

Dat van het wifi accesspoint klopt toch niet, of mis ik iets? Naar mijn idee is een link local IP adres in v6 nog steeds exclusief layer 3 en zou het dus geen last ervan moeten hebben hoeveel switches, bridges en access points ertussen zitten. Pas als je moet routeren loopt het spaak omdat per definitie link local niet gerouteerd kan worden.

[GertMenkel]

Meestal werkt dat, maar link local is alleen gegarandeerd bruikbaar binnen je netwerksegment (de fysieke link), technisch gezien. Routers forwarden link-local-adressen daarom ook niet. Als je access point zich als router gedraagt (bijvoorbeeld omdat je via DHCPv6 prefix delegation werkt) kun je daarmee in de problemen komen als je ervan uit gaat dat je al je apparaten kan gebruiken. Zodra je een router achter een andere router hangt, weet je zeker dat je een gedeelte met alleen link-local niet kunt bereiken.

Meestal werkt het gewoon bij echte access points, maar ik zou er niet van uit gaan, eigenlijk. Als je een alternatief zoekt voor je klassieke 192.168.0.0/16, zou ik link-local niet noemen.

[Reactie gewijzigd door GertMenkel op 25 april 2025 16:13]

[tvtech]

dank voor deze uitleg!

[Tozz]

Ziggo doet dit helaas met enige regelmaat. Als je bij Ziggo een ander v4 adres krijgt, krijg je ook een andere v6 range.

Nou is dat nog niet het einde van de wereld.. maar in ieder geval de door mij gebruikte router (FortiGate) 'ziet' de wijziging aan de kant van Ziggo niet. Dus mijn clients blijven hangen op IP-space die niet meer bereikbaar is.

Ik moet dan de router rebooten

[DarkForce]

Ziggo doet dit helaas met enige regelmaat. Als je bij Ziggo een ander v4 adres krijgt, krijg je ook een andere v6 range.

Dat is bij KPN niet anders, iemand die klant wordt krijgt nog voor oplevering een IPv4 adres en IPv6 adres toegekend en kenbaar gemaakt via e-mail. Mocht onverhoopt toch iets niet goed gaan dan krijg je als klant een nieuw IPv4 als ook IPv6 adres.

[Tozz]

KPN doet 't wel anders. Ik ben al vele jaren klant bij KPN en heb nog nooit een ander IP-adres gekregen na oplevering (zowel IPv4 als IPv6). Bij een Ziggo aansluiting heb ik elke paar maanden een nieuw IP-adres, meestal na aangekondigde werkzaamheden.

[ApexAlpha]

Echt kansloos dat een bedrijf dat "internet" als kernproduct heeft zo iets gewoon blijkbaar zonder enige QA uitgeeft.

Ik bedoel die laatste alinea ook.

Een "bugje" dat je kernproduct niet werkt met je andere product dat je al jaren verkoopt met de slogan: het werkt gewoon! Nog geen Engelse interface... Guest Wifi werkte blijkbaar ook niet.

Alsof ze het rechtstreeks van de fabrikant doorschuiven naar de klanten en hun de QA laten doen.

Dit soort dingen zijn echt een teken dat er véél te weinig concurrentie is in Nederland, daar worden bedrijven lui en arrogant van. Man man man

[Reactie gewijzigd door ApexAlpha op 25 april 2025 13:53]

[Dragons]

Hoe was dat gezegde ook alweer “de beste stuurlui ….”

[kujinshi]

Toch is het goed dat Tweakers kritisch zijn naar fabrikanten. Want door commerciele druk of andere zaken, worden er slecht geteste producten de markt opgegooid. We zien dat bij vanalles. Van games tot modems tot software tot etc.

[uiltje]

Nou ja, ze doen tenminste iets met IPv6, wat pas echt belachelijk is is een ISP die überhaupt niet aan IPv6 doet. Stel je voor dat er straks services draaien die alleen met IPv6 bereikbaar zijn.

[WorldWideWait]

Mooi dat het eindelijk gefixt is, maar hopelijk rollen ze die ipv6 fixes ook gelijk uit naar Box 10. Die heeft ook problemen met ipv6 verbinding werkend te houden, sinds de kpn firmware geïnstalleerd is. Vermoedelijk hetzelfde probleem (?).

[fvdberg]

Al sinds december ja. Dat modem is onwerkbaar. Ben heel blij weg te zijn bij kpn

[thomas81]

Echt ongelooflijk dat het zo lang heeft geduurd voor een fix... het has gewoon noodzakelijk om ipv6 uit zetten anders laadden somige sites gewoon niet

[zx9r_mario]

Dat probleem zal nooit optreden bij Odido

[readefries]

haha, grappig en verdrietig tegelijk 🥲

[Zidane007nl]

We hebben bij de lokale Scoutinggroep een Box 10 modem. Die gaf de laatste tijd ook alleen maar problemen: geen internet als je verbonden met de Wifi of via LAN. Firewall van de Box 10 aanpassen had geen resultaat.
Uiteindelijk maar een reset naar 'fabrieksinstellingen' uitgevoerd. Ik zet fabrieksinstellingen tussen haakjes gezien het custom Wifi netwerk gewoon nog aanwezig was daarna.

[mad-dog]

Dat klopt die worden opgeslagen bij KPN

[arbraxas]

Kun je intussen al andere wifiextenders aansluiten zonder dat het hele modem op hol slaat?
Wat een gedoe zeg bij KPN.

[Tomhap]

Werkt bij mij prima met een 3-tal Deco M4 aangesloten op het modem.

[gielie]

Ik heb fie box12 nog nooit gebruikt, alles gaat via de UniFi, kan het iedereen aanraden.

[whitemage2003]

Ik heb de laatste boxen van kpn niet eens aan de prik gehangen.
Vorige box opgegraven en terug gestuurd. Nu is de nieuwe weer stof aan het happen, weet niet eens of hij wel werkt.

Mooie is, heb een keer de helpdesk moeten bellen omdat het tv kastje slecht presteerde door software update. Geven ze aan dat ze even een reset uitvoeren... krijg ik vervolgens te horen, u bent er nog met een verbaasde stem . Jazeker maar ik zie niets veranderen (ik had toen nog bellen optie)

En daarna wat geklaagd dat ik de vorige software versie wilde maar dat ging niet. Hebben ze een snellere tv box opgestuurd en het werkte allemaal weer.

[Cruzer]

Omdat het artikel specifiek over experiabox v12 gaat..Ik had hier ook last van met mijn Draytek modem via budget thuis(kpn netwerk) lijkt inmiddels aantal dagen opgelost te zijn.