[FS#289] 6in4: Routed /48 prefix mistakenly applied as /64

[LEDE Bugs]

The following task has a new comment added:

FS#289 - 6in4: Routed /48 prefix mistakenly applied as /64
User who did this - Jo-Philipp Wich (jow-)

----------
OS X might prefer SLAAC if the router offers both SLAAC and DHCPv6 so you can try to force DHCPv6 only in LuCI:
{{https://ibin.co/32PhfMoBSZXI.png}}

There is conflicting information on the internet whether OS X supports DHCPv6 at all so ymmv.

Even if the OS is using DHCPv6 it will most likely only request a /128 (a single IP) out of the /48 pool of the router. This is normal since ordinary clients usually do not explicitely request a prefix via DHCPv6 but only a single IP for themselves, similar to how IPv4 DHCP works.

You can try hook up a Linux VM or virtual LEDE to your LAN, then make its WAN6 interface forcibly request a prefix:
{{https://ibin.co/32PjA5zXEBNk.png}}

This should confirm whether the prefix delegation works properly.

So to summarize; having a /48 available for redelegation (downstream routing) does not mean that involved interfaces will use a /48 netmask. The IPv6 stateless autoconfig (as performed via router discovery / router advertisements) will always use a /64 out of the available /48 and simple (non-router) DHCPv6 clients will only request a /128 out of the available upstream pool.

Think of the /48 as a kind of "subnet pool" where DHCPv6-PD clients can lease parts from; one /48 could for example offer 16 x /52 to 16 different downstream routers which in turn could re-delegate their /52 in the form of 16 different /56 to the next tier of downstream routers and so on until the subnet slice size falls below /64 which would make SLAAC impossible.

The only clients that can make use of (parts of) the /48 are DHCPv6 clients with prefix delegation support which are configured to actually request a subnet for downstream use. I am not aware of such a client for OS X but you can find them for Linux and BSD, e.g. Dibbler or ISC DHCP6.
----------

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=289#comment880