IPv6 Roll Out

[HEKAYA]

My internet is only working on my browser and no where else

 

[ADrunkTeddyBear]

Question @Afrigirl On Unify with Vuma Reach line, which IPv6 do I choose?

Currently running the ONT with the DMZ set to to cloud gateway

 

[Afrigirl]

View attachment 1913891

Question @Afrigirl On Unify with Vuma Reach line, which IPv6 do I choose?

Currently running the ONT with the DMZ set to to cloud gateway

Hi.

Please try SLAAC

 

[Fsh]

@Afrigirl, I'm trying to configure IPv6 on my Unifi UCG but documentation is a bit scarce on what and how it needs to be configured -- especially when it comes to what the PD value is that should be used.

My FNO is Octotel and I can see that my router gets an IPv6 address when configuring it to use DHCPv6 but it does not show the prefix. With some research and logging on the router I can see that a /56 is returned but still cannot get it working. Setting it to Auto, /64, /56, pretty much anything does not seem to work.

FYI: definitely need more than a /64

Any suggestions / help

 

[Fsh]

@Afrigirl, I'm trying to configure IPv6 on my Unifi UCG but documentation is a bit scarce on what and how it needs to be configured -- especially when it comes to what the PD value is that should be used.

My FNO is Octotel and I can see that my router gets an IPv6 address when configuring it to use DHCPv6 but it does not show the prefix. With some research and logging on the router I can see that a /56 is returned but still cannot get it working. Setting it to Auto, /64, /56, pretty much anything does not seem to work.

FYI: definitely need more than a /64

Any suggestions / help

Update — with the help of my clever friend Claude, I dug into this at the packet level. The DHCPv6 side turns out to work perfectly; the fault is one specific thing on the routing side.

Working: IA_NA (WAN address), and IA_PD — tested with Auto, /64, /56, and /48 hints; the server answers every one with the same delegated prefix: 2c0e:7f02:xxxx:x00::/56, sane lifetimes. Full pcap of the exchanges available.

Broken: the delegated /56 has no return route to my circuit. Traffic sourced from the delegated prefix gets zero return packets — tcpdump on my WAN shows echo requests egressing with nothing coming back — while the same router, same moment, pinging from its WAN (IA_NA) address gets ~2.5ms to Cloudflare.

Control test: an arbitrary extra address added inside the WAN on-link /64 (2c0f:f4c0:xxxx::/64) is fully reachable — the BNG resolves it via ND and traffic flows normally. So routing works for the on-link /64 and specifically not for the PD prefix.

Conclusion: on my circuit, the DHCPv6 server delegates a prefix correctly, but there's no route for the delegated prefix back to me.

 

[Mzezman]

Update — with the help of my clever friend Claude, I dug into this at the packet level. The DHCPv6 side turns out to work perfectly; the fault is one specific thing on the routing side.

Working: IA_NA (WAN address), and IA_PD — tested with Auto, /64, /56, and /48 hints; the server answers every one with the same delegated prefix: 2c0e:7f02:xxxx:x00::/56, sane lifetimes. Full pcap of the exchanges available.

Broken: the delegated /56 has no return route to my circuit. Traffic sourced from the delegated prefix gets zero return packets — tcpdump on my WAN shows echo requests egressing with nothing coming back — while the same router, same moment, pinging from its WAN (IA_NA) address gets ~2.5ms to Cloudflare.

Control test: an arbitrary extra address added inside the WAN on-link /64 (2c0f:f4c0:xxxx::/64) is fully reachable — the BNG resolves it via ND and traffic flows normally. So routing works for the on-link /64 and specifically not for the PD prefix.

Conclusion: on my circuit, the DHCPv6 server delegates a prefix correctly, but there's no route for the delegated prefix back to me.

You are setting up the /56 on the WAN correct? And then setting prefix delegation on the LAN side for each VLAN?

Edit: On Openserve I had to use SLAAC on WAN with /56 then PD on LANs

 

[Fsh]

You are setting up the /56 on the WAN correct? And then setting prefix delegation on the LAN side for each VLAN?

Edit: On Openserve I had to use SLAAC on WAN with /56 then PD on LANs

Correct on the WAN and LAN setups.

From what I've gather SLAAC is only for Openserve and Vodacom based on Afrihost documents-- but regardless, I did try SLAAC and got no response back from the other side

 

[Gimli_]

Correct on the WAN and LAN setups.

From what I've gather SLAAC is only for Openserve and Vodacom based on Afrihost documents-- but regardless, I did try SLAAC and got no response back from the other side

On Afrihost(Openserve) it is DHCP6 on the WAN, and on the Lan you can use SLAAC. On a pfsense or opensense router you have to set 'track interface' on the lan equal to 'WAN' so that it knows to use the prefix provided by the WAN. Make sure you enable 'Router advertisements'
Openserve provides a /60 but I also heard Octotel provides a /56. I don't know how this differs from UnifiOS, but I hope the above helps

PS. The DHCP6 on the wan is not to delegate prefixes to the LAN, it is to get a prefix from the ISP. It uses the IPv4 PPPOE connection to obtain the IPV6 Prefix.

 

[13en]

Update — with the help of my clever friend Claude, I dug into this at the packet level. The DHCPv6 side turns out to work perfectly; the fault is one specific thing on the routing side.

Working: IA_NA (WAN address), and IA_PD — tested with Auto, /64, /56, and /48 hints; the server answers every one with the same delegated prefix: 2c0e:7f02:xxxx:x00::/56, sane lifetimes. Full pcap of the exchanges available.

Broken: the delegated /56 has no return route to my circuit. Traffic sourced from the delegated prefix gets zero return packets — tcpdump on my WAN shows echo requests egressing with nothing coming back — while the same router, same moment, pinging from its WAN (IA_NA) address gets ~2.5ms to Cloudflare.

Control test: an arbitrary extra address added inside the WAN on-link /64 (2c0f:f4c0:xxxx::/64) is fully reachable — the BNG resolves it via ND and traffic flows normally. So routing works for the on-link /64 and specifically not for the PD prefix.

Conclusion: on my circuit, the DHCPv6 server delegates a prefix correctly, but there's no route for the delegated prefix back to me.

Reach out to the Afrihost NOC team via mail for assistance. ask them to give you a test pppoe account if they insist the issue is on your end. If it works on pppoe that will show they are dropping the ipv6 packets on your dhcpv6 config, you get the PD, but it is not usable because the ipv6 packets are dropped.

 

[Fsh]

Reach out to the Afrihost NOC team via mail for assistance. ask them to give you a test pppoe account if they insist the issue is on your end. If it works on pppoe that will show they are dropping the ipv6 packets on your dhcpv6 config, you get the PD, but it is not usable because the ipv6 packets are dropped.

Update — with the help of my clever friend Claude, I dug into this at the packet level. The DHCPv6 side turns out to work perfectly; the fault is one specific thing on the routing side.

Working: IA_NA (WAN address), and IA_PD — tested with Auto, /64, /56, and /48 hints; the server answers every one with the same delegated prefix: 2c0e:7f02:xxxx:x00::/56, sane lifetimes. Full pcap of the exchanges available.

Broken: the delegated /56 has no return route to my circuit. Traffic sourced from the delegated prefix gets zero return packets — tcpdump on my WAN shows echo requests egressing with nothing coming back — while the same router, same moment, pinging from its WAN (IA_NA) address gets ~2.5ms to Cloudflare.

Control test: an arbitrary extra address added inside the WAN on-link /64 (2c0f:f4c0:xxxx::/64) is fully reachable — the BNG resolves it via ND and traffic flows normally. So routing works for the on-link /64 and specifically not for the PD prefix.

Conclusion: on my circuit, the DHCPv6 server delegates a prefix correctly, but there's no route for the delegated prefix back to me.

FYI... @Afrigirl reached on Saturday just after I posted this and got it all sorted out for me today -- not exactly sure what they did on their side, but EXCELLENT service!

 

[Afrigirl]

FYI... @Afrigirl reached on Saturday just after I posted this and got it all sorted out for me today -- not exactly sure what they did on their side, but EXCELLENT service!

@AfriNatic is the one that reached out. I only came online today. Thank you for for your cooperation, the team and our providers were able to find the issue with our Ipv6 configuration.