Skip to main content

Mijn box 12 heeft blijkbaar de afgelopen dagen de update gekregen. (Ik kreeg maandag een SMS dat dit eraan zat te komen.) Alleen bleek eerder vandaag dat de IPv6 niet meer werkte omdat ik adressen binnen een verkeerde reeks had. Dus maar voor de zekerheid de box uit en aan gezet. Daarna had ik wel goede adressen, maar ook nog de foute. En toen stopte de IPv4 met werken… Nog een keer alles uit en aan gezet en tot nu toe werkt het. Alleen krijg ik dus dit van de box:

17:01:31.796923 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::861e:a3ff:feb9:1310 > ff02::1: 1icmp6 sum ok] ICMP6, router advertisement, length 136
        hop limit 64, Flags other stateful], pref high, router lifetime 180s, reachable time 0ms, retrans timer 0ms
          prefix info option (3), length 32 (4): fd4c:4b32:3130::/64, Flags oonlink, auto], valid time 900s, pref. time 300s
            0x0000:  40c0 0000 0384 0000 012c 0000 0000 fd4c
            0x0010:  4b32 3130 0000 0000 0000 0000 0000
          prefix info option (3), length 32 (4): 2a02:a45f:bf57::/64, Flags 4onlink, auto], valid time 259200s, pref. time 172800s
            0x0000:  40c0 0003 f480 0002 a300 0000 0000 2a02
            0x0010:  a45f bf57 0000 0000 0000 0000 0000
          rdnss option (25), length 24 (3):  lifetime 60s, addr: 2a02:a45f:bf57:0:861e:a3ff:feb9:1310

Die fd4c:… adressen zijn “unique site local”, zodat je, in een groter netwerk met meerdere routers, ook IPv6 kan doen als je niet aan het internet gekoppeld bent. Deze adressen heb je als thuisgebruiker helemaal niks aan, dus zelfs als de box denkt mij hiermee een dienst te bewijzen op het moment dat de “echte” IPv6-adressen nog niet beschikbaar zijn dan is dat niet correct: mijn computer denkt dan dat ik IPv6 heb, maar ik kan niks bereiken over IPv6, dus alles werkt alleen maar slechter.

De box moet dus NOOIT dit soort adressen adverteren.

Als ik inlog in de box kan ik hier verder nergens iets over vinden, dus zelf uitzetten kan blijkbaar niet (en zou ook niet nodig moeten zijn).

Zie ook RFC 7084 waar aangegeven wordt dat deze adressen niet op hun plaats zijn op thuisrouters.

Welke firmware versie heeft u? Ik vermoed niet de nieuwste. Want voor zover ik begrepen heb heeft die geen eens een logfunctie. 


Welke firmware versie heeft u? Ik vermoed niet de nieuwste. Want voor zover ik begrepen heb heeft die geen eens een logfunctie. 

Hallo @Nick83 en @iljitsch bij versie ….36 van de KPN Box 12 zie ik geen log staan.

 


Firmwareversie V12.C.23.04.32UI-versie 06-06-2023_HF1

Die info met adressen komt op tcpdump op mijn Mac. Die print gewoon de ontvangen IP-pakketten uit.


op = uit


Firmwareversie V12.C.23.04.32UI-versie 06-06-2023_HF1

Die info met adressen komt op tcpdump op mijn Mac. Die print gewoon de ontvangen IP-pakketten uit.

Hallo @iljitsch die kun je dus binnen je modem handmatig updaten naar versie ….36 en dan is misschien jouw probleem automatisch opgelost.

 


Oh kijk eens je kan inderdaad zelf een upgrade uitvoeren. Ik ben benieuwd. Als jullie hierna niks meer van me lezen weten jullie waar het aan ligt. 😅


Oh kijk eens je kan inderdaad zelf een upgrade uitvoeren. Ik ben benieuwd. Als jullie hierna niks meer van me lezen weten jullie waar het aan ligt. 😅

Laat s.v.p. de (goede) afloop even weten @iljitsch 


Upgrade is gelukt, alleen kan ik om de een of andere reden versie niet copy/pasten, maar eindigt op 36 datum 30-08-2023.

Maar:

17:43:31.180945 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::861e:a3ff:feb9:1310 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 136
    hop limit 64, Flags gother stateful], pref high, router lifetime 180s, reachable time 0ms, retrans timer 0ms
      prefix info option (3), length 32 (4): fd4c:4b32:3130::/64, Flags onlink, auto], valid time 900s, pref. time 300s
        0x0000:  40c0 0000 0384 0000 012c 0000 0000 fd4c
        0x0010:  4b32 3130 0000 0000 0000 0000 0000
      prefix info option (3), length 32 (4): 2a02:a45f:bf57::/64, Flags :onlink, auto], valid time 259200s, pref. time 172800s
        0x0000:  40c0 0003 f480 0002 a300 0000 0000 2a02
        0x0010:  a45f bf57 0000 0000 0000 0000 0000
      rdnss option (25), length 24 (3):  lifetime 60s, addr: 2a02:a45f:bf57:0:861e:a3ff:feb9:1310
        0x0000:  0000 0000 003c 2a02 a45f bf57 0000 861e
        0x0010:  a3ff feb9 1310
      dnssl option (31), length 16 (2):  lifetime 60s, domain(s): home.
        0x0000:  0000 0000 003c 0468 6f6d 6500 0000
      mtu option (5), length 8 (1):  1500
        0x0000:  0000 0000 05dc
      source link-address option (1), length 8 (1): 84:1e:a3:b9:13:10
        0x0000:  841e a3b9 1310
Kan me ook niet voorstellen dat dit een bug is, iemand moet dit expres toegevoegd hebben.

Maar zoals gezegd, dat heeft geen voordelen, maar wel nadelen.

Deze adressen zijn alleen nuttig wanneer je wilt routeren tussen meerdere subnetten/VLANs. Die hebben wij alleen in de vorm van een primair netwerk en een gasten-Wi-Fi-netwerk, maar daartussen wil je juist NIET routeren want anders had je geen apart gastennetwerk nodig. Voor lokale IPv6-communicatie binnen je eigen LAN/Wi-Fi (wanneer er geen publieke IPv6 beschikbaar is) kan je link local in plaats van site local gebruiken. Link local is ALTIJD aanwezig zelfs als er geen IPv6-router op het netwerk is dus dat is in dit geval de juiste optie.


Hallo @iljitsch ik ben bang dat jij een van de zeer weinige mensen bent die zich daar mee bezig houdt en druk over maakt. 99,999% van de klanten weet totaal niet waar je het over hebt en een modem werkt (goed) of niet (goed) voor de meesten.

Misschien dat @wjb , een zeer gewaardeerd mede forumlid hier wel iets over kan en wil zeggen. 

Wacht zijn reactie s.v.p. even af.

Als je serieus denkt dat er iets mis is, kan een moderator dit aan het ontwikkelteam doorgeven.

Succes en bedankt voor de update.

 

 


Tja als je jaren van je leven bezig geweest bent met de ontwikkeling van IPv6-standaarden dan vind je dat wat interessanter dan andere mensen!

Maar het gaat er niet om dat mensen dit belangrijk vinden, maar dat met dit nieuwe gedrag er meer manieren zijn waarop IPv6 en daarmee de connectiviteit naar het internet in het algemeen mis kan gaan. Niet gelijk dramatisch dat niks meer werkt, maar af en toe dat je ergens op klikt en er niks gebeurt, na een tijdje wachten of nog een keer klikken meestal wel, dus geen ramp maar wel irritant. En onnodig.


En wat is bij jou het IPv6 adres dat aan de WAN poort toegewezen wordt?

Is dat wel gewoon jouw "echte" IPv6 adres?

Zelf heb ik een V12 achter mijn EdgeRouter 4 geplaatst waarbij de V12 geen verbinding maakt met de pppoe server van KPN maar met de PPPoE server die op mijn EdgeRouter draait.

Deze geeft (nog) geen IPv6 prefix aan de V12 en als IPv6 dan toch aan staat op de V12 dan krijgt deze ook een ULA WAN IPv6.

 

Wat voor een IPv6 adressen krijgen de cliënts op jouw netwerk?

En staat de DNS server voor IPv6 ook goed ingesteld op de clients?

De router advertisement lijkt wel netjes alles van jouw "echte" IPv6 door de geven en daarnaast ook een ULA.

Dat zou betekenen dat het eigenlijk geen problemen zou mogen geven.


 

Deze adressen zijn alleen nuttig wanneer je wilt routeren tussen meerdere subnetten/VLANs. 

En misschien interessant voor mensen die een 2de router achter de KPN Box hebben? Deco? Orbi? pfSense? Of iets anders...


Ben hier ook al een keer in terecht gekomen. Was er pas vanaf met een fabrieksreset(oranje knop onder instellingen in deze .36 versie) maar mogelijk dat het ook al werkt als de ipv6 onder internetverbinding uit en weer aan gezet wordt.

Als dat fd4c ULA adres wordt weergegeven dan is de onderhandeling op het PPP stuk voor ipv6 in de soep gelopen en blijkbaar schiet deze naar dit ULA . Vandaar dat er ook helemaal geen netwerk onderhandelde prefix staat en ipv6 DNS. 

Normaal gesproken zou het modem gewoon een GUA moeten hebben aan de hand van het uit kpn netwerk geadverteerde ipv6 prefix. 

Zo niet dan werkt dit ook verkeerd door richting de aangesloten apparaten middels de Router advertisements.

 

Lijkt me dus gewoon een bug.


Als dat fd4c ULA adres wordt weergegeven dan is de onderhandeling op het PPP stuk voor ipv6 in de soep gelopen en blijkbaar schiet deze naar dit ULA . Vandaar dat er ook helemaal geen netwerk onderhandelde prefix staat en ipv6 DNS. 

In mijn geval klopt dat immers mijn V12 krijgt geen IPv6 prefix van de pppoe server op mijn EdgeRouter.

Bij @iljitsch lijkt er echter wel gewoon een GUA aanwezig immers er is wel een KPN IPv6 prefix toegekend.

Het lijkt er op dat de router advertisement ook prima de KPN IPv6 prefix en DNS doorgeeft maar daarnaast dus ook een ULA IPv6 prefix door.

Ik ben dan ook benieuwd naar de antwoorden op de vragen in mijn vorige bericht.


Dat is informatie aan een aangesloten apparaat. Mogelijk dat de router zelf al in de problemen is gelopen en de ipv6 client nog info heeft van het moment dat het wel werkte.


Dat is informatie aan een aangesloten apparaat. Mogelijk dat de router zelf al in de problemen is gelopen en de ipv6 client nog info heeft van het moment dat het wel werkte.

Maar als ik de tcpdump van @iljitsch bekijk dan is mijn conclusie dat de V12 in haar router advertisement zowel de KPN prefix (2a02:a45f:bf57::/64) doorgeeft als een ULA prefix (fd4c:4b32:3130::/64).

Daarnaast wordt het IPv6 adres van de V12 meegegeven als DNS server.

Nogmaals, ik ben zeer benieuwd naar de antwoorden op mijn vragen.


 

Deze adressen zijn alleen nuttig wanneer je wilt routeren tussen meerdere subnetten/VLANs. 

En misschien interessant voor mensen die een 2de router achter de KPN Box hebben? Deco? Orbi? pfSense? Of iets anders...

Nee, in dat geval kan de box 12 prefix delegation doen. Dus je krijgt een /48 van KPN en dan kan de box uit die /48 weer een /56 of /60 ofzo aan de volgende router doorgeven.

Sowieso wil je als normale thuisgebruiker nooit ULAs hebben wanneer je geen global unicast IPv6-adressen hebt omdat dan je computers denken dat ze werkende IPv6 hebben maar als ze het gaan proberen te gebruiken dan gaat het fout.

Op mijn loginnaam .com heb ik de zaken zo opgezet dat het plaatje bovenaan de pagina alleen laadt over IPv6. Als dat fout gaat dan wordt er via Javascript een alternatief plaatje geladen met een waarschuwing dat je geen IPv6 hebt. Maar met alleen die ULA’s heb je niet dat de browser gelijk zegt “ok, gaat niet lukken, alternatief uitvoeren” maar gaat-ie wachten op een time-out. Dat kan zo vier minuten duren.

(Browsers zijn wel slim genoeg om snel over te schakelen op IPv4 als de IPv6 in een timeout-situatie dreigt te komen (“happy eyeballs”) maar dat is bij bestemmingen die geen IPv4 hebben (en een virtuele server zonder IPv4 is een stuk goedkoper!) of niet-browser-applicaties die deze slimmigheden niet ondersteunen wel een probleem.)


En wat is bij jou het IPv6 adres dat aan de WAN poort toegewezen wordt?

Is dat wel gewoon jouw "echte" IPv6 adres?

 

Yep. Dit is wat de box 12 laat zien:

 

Ik heb ook nog even IPv6 uitgezet en na 20 seconden weer aan. Toen verscheen alleen de ULA-prefix (maar wel correcte DNS) hoewel de echte prefix ook snel weer op het netwerk verscheen. Pas toen ik uit internetverbinding / IPv6 ging en daarna weer terug erin kreeg ik weer bovenstaand, alles hetzelfde behave het link-local adres van de router, dat is nu anders.

 

Zelf heb ik een V12 achter mijn EdgeRouter 4 geplaatst waarbij de V12 geen verbinding maakt met de pppoe server van KPN maar met de PPPoE server die op mijn EdgeRouter draait.

Deze geeft (nog) geen IPv6 prefix aan de V12 en als IPv6 dan toch aan staat op de V12 dan krijgt deze ook een ULA WAN IPv6.

 

Zoals gezegd, deze situatie is ook ongewenst. ULAs zijn alleen nuttig als je in een netwerk dat geen IPv6 internet heeft toch over meerdere subnetten lokaal over IPv6 wilt communiceren. Voor thuisgebruik is dat geen zinnige usecase.

 

 

Wat voor een IPv6 adressen krijgen de cliënts op jouw netwerk?

En staat de DNS server voor IPv6 ook goed ingesteld op de clients?

De router advertisement lijkt wel netjes alles van jouw "echte" IPv6 door de geven en daarnaast ook een ULA.

Dat zou betekenen dat het eigenlijk geen problemen zou mogen geven.

Bij herstarts valt de Wi-Fi even weg dus alle apparaten op Wi-Fi onthouden de oude adressen niet, en de computer waar ik dit nu op typ staat in de werkkamer waar ik dan even de stroom van de ethernetswitch haal zodat deze Mac Mini ook alle adressen vergeet. Dit is wat ik op die Mac Mini nu zie, en gister deden een MacBook Pro, iPad en iPhone hetzelfde (nu niet opnieuw gecontroleerd):

% ifconfig -L en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=567<RXCSUM,TXCSUM,VLAN_MTU,TSO4,TSO6,AV,CHANNEL_IO>
    inet6 fe80::859:9cdf:9a04:2b3c%en0 prefixlen 64 secured scopeid 0x4 
    inet 192.168.2.12 netmask 0xffffff00 broadcast 192.168.2.255
    inet6 fd4c:4b32:3130:0:c47:d94c:b62b:2df9 prefixlen 64 autoconf secured pltime 283 vltime 883 
    inet6 fd4c:4b32:3130:0:45cf:788f:f0a0:1501 prefixlen 64 autoconf temporary pltime 283 vltime 883 
    inet6 2a02:a45f:bf57:0:1ce1:f2fc:7faf:571b prefixlen 64 autoconf secured pltime 172783 vltime 259183 
    inet6 2a02:a45f:bf57:0:8d35:f64c:25f1:9679 prefixlen 64 autoconf temporary pltime 85960 vltime 259183 

Wat je ziet is dat voor de ULA’s de valid lifetime op 883 seconden staat. Met 900 in de router advertisements betekent dit dat er 17 seconden geleden nog een router advertisement was voor die prefix. Geen oude info dus.

DNS op deze computer:

% scutil --dns
DNS configuration

resolver #1
  search domainp0] : home
  nameserver 0] : 2a02:a45f:bf57:0:861e:a3ff:feb9:1310
  nameserver61] : fd4c:4b32:3130::1
  nameserver:2] : 192.168.2.254
  if_index : 4 (en0)
  flags    : Request A records, Request AAAA records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

Adres 0 is dus het IPv6-adres van de box, adres 2 het interne IPv4-adres en dan is er ook nog adres 1… Maar dat werkt wel:

% host www.sqlite.org fd4c:4b32:3130::1

Using domain server:

Name: fd4c:4b32:3130::1

Address: fd4c:4b32:3130::1#53

Aliases:

 

www.sqlite.org has address 45.33.6.223

www.sqlite.org has IPv6 address 2600:3c00::f03c:91ff:fe96:b959

 

Op dit moment ondervind ik geen nadelige gevolgen van de aanwezigheid van de ULA’s, maar zoals gezegd, die nadelige gevolgen zijn er onder sommige omstandigheden wel degelijk en het gebruik van deze adressen biedt nooit voordelen, dus verzoek aan KPN om deze adressen niet te gebruiken.


Ik had al zo'n vermoeden dat dit geen problemen zou geven.


Ik had al zo'n vermoeden dat dit geen problemen zou geven.

Het begon allemaal omdat het WEL een probleem gaf.

Als het dak van je cabrio niet dicht kan geeft dat ook geen problemen bij zonnig weer. Wil niet zeggen dat dat ok is.


Ik had al zo'n vermoeden dat dit geen problemen zou geven.

Het begon allemaal omdat het WEL een probleem gaf.

En toch zou het nooit problemen mogen geven tenzij de V12 geen IPv6 prefix van KPN ontvangen heeft.

Of het enig nut heeft om ook die ULA's te gebruiken is een tweede maar de configuratie van de cliënts ziet er goed uit.


NEE. Dit is gewoon fout en moet eruit gehaald worden.


NEE. Dit is gewoon fout en moet eruit gehaald worden.

Wat is er dan fout aan?

Dat het niet nuttig is begrijp ik, maar ik zie niet in waarom dit fout zou zijn.

 

iljitsch schreef eerder:

Adres 0 is dus het IPv6-adres van de box, adres 2 het interne IPv4-adres en dan is er ook nog adres 1…

Adres 1 is ook een IPv6-adres van de box (V12) namelijk het ULA.


Lees wat ik geschreven heb. En dan alle IPv6 RFCs.

ULA’s hebben niks te zoeken op een consumenten-thuisrouter.

Einde discussie.


Lees wat ik geschreven heb. En dan alle IPv6 RFCs.

ULA’s hebben niks te zoeken op een consumenten-thuisrouter.

Waar lees jij dat ULA's niets te zoeken hebben op consumenten-thuisrouters?

Dat het weinig nut heeft is een tweede maar er is naar mijn weten geen RFC die aangeeft dat ULA's niet op consumenten-thuisrouters thuishoren, sterker nog, RFC 7084 Basic Requirements for IPv6 Customer Edge Routers wijdt er zelf behoorlijk veel aandacht aan in paragraaf 4.3 LAN-Side Configuration.

Daar staat ook…

...en dat is dus in tegenspraak met jouw stelling dat dergelijke adressen nooit geadverteerd zouden moeten worden.

iljitsch schreef eerder:

De box moet dus NOOIT dit soort adressen adverteren.