Only one prefix being given though DHCPv6 with ra_management = 1

[silkeh]

When the router has both a private (ULA) and a public prefix, setting ra_management = 1 results in only the private prefix being given with DHCPv6.

I've set up a test network which reliably demonstrates this with the following prefixes:

• ULA prefix: fd18:b74d:c58e::
• WAN prefix: fd14:4ffd:f08f:4::

I've uploaded the configuration:

• /etc/config/dhcp
• /etc/config/network
• ifstatus wan6

With ra_management = 2, the test computer receives the following IPs: (capture)

inet6 fd14:4ffd:f08f:4::be8/64 scope global tentative 
inet6 fd18:b74d:c58e::be8/64 scope global tentative

With ra_management = 1, the test computer has the following IPs: (capture)

inet6 fd18:b74d:c58e::be8/64 scope global 
inet6 fd14:4ffd:f08f:4:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic 
inet6 fd18:b74d:c58e:0:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic 

The expected result is that ra_management = 1 results in:

inet6 fd18:b74d:c58e::be8/64 scope global
inet6 fd14:4ffd:f08f:4::be8/64 scope global
inet6 fd14:4ffd:f08f:4:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic 
inet6 fd18:b74d:c58e:0:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic

Removing the ULA from the config does result in the public prefix being given:

inet6 fd14:4ffd:f08f:4::be8/64 scope global 
inet6 fd14:4ffd:f08f:4:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic

[sbyx]

This is actually intended behavior for ra_management=1 if your client does not support the DHCPv6 reconfigure feature. The background here is that if you have stateless addresses via RAs there is no need to hand out more than one address via DHCPv6 since we mainly want to use DHCPv6 for collecting hostnames and having stable internal names. Giving out all addresses again has the disadvtange of senseless duplication and losing the ability to quickly renumber clients in cases where external public addresses change.

[silkeh]

If it's intended behaviour, it may be prudent to note this in the documentation. The logging should be modified as well, as it mentions both prefixes:

odhcpd: DHCPV6 CONFIRM IA_NA from 000100011db655f30800270c6862 on br-lan: not on-link
odhcpd: DHCPV6 SOLICIT IA_NA from 000100011db655f30800270c6862 on br-lan: ok fd14:4ffd:f08f:4::be8/128 fd18:b74d:c58e::be8/128 
odhcpd: DHCPV6 REQUEST IA_NA from 000100011db655f30800270c6862 on br-lan: ok fd14:4ffd:f08f:4::be8/128 fd18:b74d:c58e::be8/128 

[init-js]

Is there any way to tweak this behavior? Having public addresses being leased out improves usability on the end hosts when running publicly visible internet services (you have a relatively stable IP on which you can bind sockets, and dynamic-dns can be taken in charge by the host). ra_management=2 is great that way.

android support and privacy improvements with slaac make ra_management=1 preferable. But ULA also helps to configure internal services (e.g. ULA IPs can be written to config files on various computers on the network).

What would you advise to receive both ULA and public ips on the end hosts? Can odhcpd be configured with different settings (ra_management=2) on an additional interface/vlan section, but with the same leases database?

edit: maybe I'm thinking about this the wrong way. maybe it's simpler to figure out the WAN prefix (e.g. with a cron job), suffix that with a static host part to form a public IP (e.g. build ::cafe), and add that IPv6 to my main interface, or to a macvlan.

[Shulyaka]

Hi,

I also have this issue. The problem is that with ra_management=1 the client receives only one address via DHCPv6, but in the lease file there are both (with WAN and ULA prefixes). And when this lease file is used by dnsmasq to resolve a client hostname, it also gives both addresses in its response. So, depending on the software, I have 50% chances of reaching the computer over IPv6.

[badfish]

I want to support android devices on my network, so I need ra_management=1. But I also want to give my servers memorable public addresses such as ::2 and ::3 (my router gets ::1). This issue means that there's no way to do that via dhcp. Worse: odhcpd records the leases that it has not advertised, so the luci status page shows that the servers have correctly leased their addresses when in fact they have not, and dns returns non-functioning addresses for them. Either odhcpd should advertise the static leases explicitly set up in luci, or luci should prevent configuring static leases that are not going to work.

[AndreBL]

Badfish, take a look at the ip6neigh project here on GitHub. By using with this tool with OpenWrt you can name all your host's SLAAC addresses easily. Perhaps the memorable numbers won't be needed anymore.