IPv6 config: understanding WAN6 - IPv6 prefix output

I am having difficulties setting up IPv6 in LEDE. Maybe someone can help me interpret my current IPv6 output of LEDE.

My hardware setup:
LAN-Client => LEDE router (routing mode) => cable router (routing mode) => internet

My current status:
IPv6 on the WAN side of LEDE is working, IPv6 on the LAN side of LEDE is not working.

Both LEDE command line "ifconfig" for eth0.2 and LuCi "Interfaces - WAN6 - General Setup - Status" says
IPv6: xxxx:yyyy:zzzz:834:eacc:18ff:fefd:82bb/64 on the WAN side
(I've anonymized the first 3 address tuples)

Also i can successfully ping6 and traceroute6 different addresses from the LEDE diag page and if I LAN-connect clients directly to my cable router, IPv6 also works for clients.

I suspect that the LEDE IPv6 problem could be that my cable provider maybe does not offer IPV6 prefix delegation, preventing LEDE from working correctly.

My actual question maybe is rather simple:
Can someone help me to understand what the previous "/64" output of LEDE means regarding ownership:
a) is it that my LEDE router is connected to my cable router and that my cable router owns/manages that /64 IPv6-prefix?
b) or is it that my LEDE router got this prefix using "prefix delegation" and now LEDE owns and manages that /64 IPv6-prefix?

I have been trying to figure this out myself for a while now.

 

I have my LEDE router connected to my ISP's router via wireless and like you I cannot get IPv6 working on the Lan side, it works fine on the Wan side. Is this the same setup you are trying to get working.

 

One thing I tried was Nat6 but could get it working properly, If you figure it out could you please post your solution here.

I think the answer is a), the LEDE router got an address assigned via SLAAC from the cable router. The /64 prefix is used for all devices directly connected to the cable router and isn't delegated to the LEDE router. If the cable router doesn't support prefix delegation I guess you need to use NDP proxy, which I'm not sure how to configure.

Do you see the prefix delegation on the main status page? For example:

Type: dhcpv6-pd
Prefix Delegated: XXXX:XXX:8380:d30::/60
Address: XXXX:XXX:600a:2c:c421:e006:2bb8:999d/128
Gateway: fe80::238:dfff:fe08:2c22
DNS 1: 2001:558:feed::1
DNS 2: 2001:558:feed::2
Connected: 9d 21h 32m 31s

I'm requesting a /60 from Comcast so I can use a different /64 with each the lan and guest networks. Works great.

Regards,

Jim

Thanks for your feedback about the working /60 PD and how to find out, if IPv6 prefix delegation is active. That was helpful input for me :slight_smile: So unfortunately not solved, but gave me a better understanding. My status page lists "Type: dhcpv6", so prefix delegation obviously is not active.

According to other forums, my provider might only use /64 for more recent contracts (and I recently booked a speed upgrade, which also gave me IPv6 option for the first time).

I am mostly sure that I've identified all config alternatives so far:
I read that I have to either go for bridge mode(=Wifi access point only mode, no LEDE firewall between LAN and WAN) or use the rather exotic IPv6 NAT for /64 when depending on router-chains.
There is also the "relay mode" for router advertisement and DHCPv6, which I have not yet fully understood in detail, but sounds like this is just a minor config variant, but still requires using either bridge mode or NAT mode on router-chains.

Besides that, currently 'logread' on my SSH command line shows some log output, pointing to some maybe minor problem: https://github.com/openwrt/odhcpd/issues/79. Looks like this is known but not yet fixed (I tried a ~5 day old trunk version and 17.01.3).

I have not yet decided how to proceed. I might phone my provider the next day first, asking about available prefix options first. (But I doubt it will be for free, if available at all)

There are a few Google search result for "openwrt NAT6" (UCI only, not LuCi-based). Scares me a bit and I am currently not really interested into NAT6.
(e.g. look IPv6 behind ISP Router without Prefix Delegation)

Another minor research result, I found was that some provider routers seem to stick to one DHCP option for attached devices, based on the MAC of the attached client device. So when changing LEDE DHCPv6 options, you might have to change LEDE's WAN MAC address, to make the new DHCP options work (but still, if the provider does not offer PD, this will not magically create PD).

And the root cause of the issue seems to be:

  • seems the IPv6 standard wants routing to happen in the leftmost 64bit of the IPv6 address only. So if you want to create subnets in your home, you do need a bit of an address range from the left most 64bit of the IPv6 address. The right most 64bit of the address are solely for client addresses and must not be used for routing purposes (there seem to be some tricks to do so, but lots of client software seems to have problems with such tricks. Also LEDE does not even allow to create subnets within the rightmost 64bits of the address.)
  • and many providers just hand out /64bit to end customers (which is the smallest possible address segment in the standard), although the IPv6 standard encourages providers to hand out more address bits to the customers, to enable customers to create own subnets. Obviously providers want to earn extra money on business contracts that do have >/64 ranges.