Modem in bridge modus, IPv6 werkt niet: dhcp6 NoAddrsAvail, NoPrefixAvail

[sytsevg]

Beste community,

Omdat de Ziggo klantenservice mijn probleem niet kon oplossen hebben ze doorverwezen naar de community.

Ik gebruik de nieuwste SmartWifi modem van Ziggo met bridge-modus aan. Deze is verbonden met een Cloud Gateway Ultra. Voor toegang tot IPv6, heb ik  DHCPv6 op de Cloud Gateway Ultra met Prefix Delegation op /57 (oud UPC gebied) ingesteld. Dit werkte allemaal prima tot recent, waar als ik kijk naar de DHCPv6 Solicit/Advertise berichten op de Cloud Gateway Ultra:

09:40:07.232126 IP6 (flowlabel 0x1c374, hlim 1, next-header UDP (17) payload length: 145) fe80::[redacted] > ff02::1:2.547: [bad udp cksum 0x8edb -> 0x44dd!] dhcp6 solicit (xid=ec6bed (elapsed-time 65535)
(option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name [redacted] opt_67 opt_82)
(client-ID hwaddr type 1 xx:xx:xx:xx:xx:xx)
(reconfigure-accept)
(Client-FQDN)
(IA_NA IAID:1 T1:0 T2:0)

(IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/57 pltime:0 vltime:0)))

09:40:07.250556 IP6 (hlim 64, next-header UDP (17) payload length: 237) fe80::[redacted].547 > fe80::[redacted].546: [udp sum ok] dhcp6 advertise (xid=ec6bed
(client-ID hwaddr type 1 xx:xx:xx:xx:xx:xx)
(server-ID hwaddr/time type 1 time [redacted] xx:xx:xx:xx:xx:xx)
(IA_NA IAID:1 T1:0 T2:0 (status-code NoAddrsAvail))
(IA_PD IAID:1 T1:0 T2:0 (status-code NoPrefixAvail))
(DNS-server 2001:b88:1002::10 2001:b88:1202::10 2001:730:3e42:1000::53))

Hetzelfde advertise bericht krijg ik terug voor /56.

Ik begrijp niet waarom het nu niet meer werkt, voor de Ziggo klantenservice was dit te technisch om te beantwoorden.

Heeft iemand een idee waar het fout gaat of hoe ik dit kan oplossen?

Thanks!

[tobiastheebe]

Het valt mij op dat de UDP checksum als 'bad' voor de DHCPv6 solicit als 'bad' aangemerkt wordt. Maakt het verschil als je een andere DUID (onderdeel van de client ID) instelt? Vermoedelijk moet dat wel via SSH. Wellicht ten overvloede: houd er ook rekening mee dat je een andere IA_NA en IA_PD ontvangt als dit werkt.

Overigens verbaast het mij niet dat de klantenservice deze vraag niet kon beantwoorden.

[Jeff]

Kan je eens proberen om de pre-fix delegation size op /56 te zetten. Sinds enige tijd heb ik deze in oud UPC gebied ook op /56 staan en dit werkt prima.

[tobiastheebe]

Dit is al geprobeerd: "Hetzelfde advertise bericht krijg ik terug voor /56." Het zou mooi zijn als /56 uiteindelijk de standaard wordt in fUPC.

[caesar]

@tobiastheebe 

Waarom moet je zelf een pre-fix delegation opgeven? Wordt die niet meegestuurd als antwoord op een DHCPv6 request?

[MR_CHIP]

---

@caesar  schreef:

@tobiastheebe 

Waarom moet je zelf een pre-fix delegation opgeven? Wordt die niet meegestuurd als antwoord op een DHCPv6 request?

---

Bij SLAAC standaard instelling wordt dat toch niet gebruikt 

[tobiastheebe]

Dat klopt, echter bij sommige routers is het noodzakelijk om een prefix length hint te sturen met de DHCPv6 solicit.

[tobiastheebe]

Het gaat hier om WAN, niet LAN. Aan WAN-zijde is alleen (stateful) DHCPv6 beschikbaar.

[sytsevg]

@tobiastheebeIk heb een nieuwe DUID gegenereerd, maar ik krijg nog steeds dezelfde advertise:

16:30:17.032375 IP6 (hlim 64, next-header UDP (17) payload length: 237) fe80::[redacted].547 > fe80::[redacted].546: [udp sum ok] dhcp6 advertise (xid=3c6820 (client-ID hwaddr type 1 xx:xx:xx:xx:xx:xx) (server-ID hwaddr/time type 1 time [redacted] xx:xx:xx:xx:xx:xx) (IA_NA IAID:1 T1:0 T2:0 (status-code NoAddrsAvail)) (IA_PD IAID:1 T1:0 T2:0 (status-code NoPrefixAvail)) (DNS-server 2001:b88:1002::10 2001:b88:1202::10 2001:730:3e42:1000::53))

Wat ik begreep over de UDP checksum als 'bad' is niet meteen 'bad', blijkbaar is de tcpdump de berichten aan het opvangen voordat het naar de netwerk stack gaat waar het wel goed afgehandeld wordt. Dit dan alleen met uitgaande berichten, als het zo binnenkomt dan is het idd een probleem.

[tobiastheebe]

In dit geval zou het waardevol zijn om te controleren of wel een IA_NA en IA_PD worden toegewezen als het modem in router mode wordt geconfigureerd. Dit kan gecontroleerd worden op de pagina Beheer → Informatie in de webinterface.

[sytsevg]

Ik had dit samen met de klantenservice eerst geprobeerd, eerst de modem in router mode, firmware update, en kijken naar de IPv4/IPv6 adres, ik zag kort alleen een lokale ipv6 adres, maar geen globale, toen werd het al weer naar bridge mode gezet. Misschien hadden we beter langer kunnen wachten?

[tobiastheebe]

Als bij router mode geen global unicast address (begint bij Ziggo met 2001 of 2a02) zichtbaar is bij Beheer → Informatie, dan gaat er mogelijk iets mis op de DHCPv6 server op het CMTS.

[Jeff]

Oops.... overheen gelezen. Het riekt er inderdaad naar dat er iets niet goed gaat op de CMTS. 

[PeterH2020]

Mijn ultra staat zo ( ziggo  gebied )

 

 

[CitizenE]

Ik heb sinds gistermiddag precies hetzelfde probleem. Geen IPv6 adres allocatie op de WAN interface via DHCPv6. Krijg dezelfde server response:
IA_NA IAID:1 T1:0 T2:0 (status-code NoAddrsAvail)) (IA_PD IAID:1 T1:0 T2:0 (status-code NoPrefixAvail)

fUPC gebied (Amsterdam).

Setup: Ubiquiti UDR en Ubee U1318. PD size op /57. UDR herstart, Ubee herstart. DHCPv6 uit en aan gezet. 

[tobiastheebe]

Heb jij ook al /56 geprobeerd? Het kan zijn dat een aanpassing naar /56 gaande is in fUPC.

[CitizenE]

Dank voor de suggestie. Maakt helaas niet uit. Ik krijg dezelfde server response.

[PeterH2020]

Kan zijn dat er ook daar al  ombouw naar de nieuwe Nodes wordt gedaan.

Je kan even proberen om het modem via de reset knop ( 15 sec )  te resetten.

[tobiastheebe]

De nodes hebben echter niets met DHCPv6 te maken, de server bevindt zich op het CMTS.

[PeterH2020]

Dat is niet helemaal waar, als de nieuwe NODE geplaatst is gaat de communicatie niet meer via het LC maar rechtstreeks naar de nieuwe CMTS in het RC.