Weird DHCPv6-Lease issue

Hello everyone,

I have a quite weird DHCPv6 issue with my OpenWRT router (18.06.1 r7258-5eb055306f):
I have recently added a DLAN line to my network. I had been noticing network issues in that line for a while, then I could isolate it to IPv6 issues. Today I found the culprit: One DLAN Adapter has the IPv6 suffix ::1, the other ::2.
::1 is already my OpenWRT router, though ...
The adapters are set to DHCPv6, and OpenWRT correctly listed them with the ::1 suffix and even started reverse DNSing the (it's own!) IP to the hostname of the DLAN adapter¹.

The DHCP config originally was

config host
        option name 'dlan-office-3G'
        option dns '1'
        option mac '[the MAC, IPv4 lease works fine]'
        option ip ''
        option leasetime '12h'

Then I changed it to

config host
        option name 'dlan-office-3G'
        option dns '1'
        option mac '[the MAC, IPv4 lease works fine]'
        option ip ''
        option leasetime '12h'
        option hostid '10'
        option duid '[the 20 char hex DUI that was shown for the original lease]'

This did not change anything. The adapter still takes the ::1 with unlimited lease time.

A dozen other devices get sane DHCPv6 leases with lease time around 2h, without any special configuration (configured like the first config above, or not at all).

I am not that firm with the details of DHCPv6. Can the client override the address issued by the DHCPv6 server AND report it back to the server, which then accepts the new address as the client's? Or is this necessarily an issue on the OpenWRT side?
Is it intended that this even works with the DHCP servers own address?
Is there any other config I could test or do I have to try to wireshark into the DHCPv6 dialog?

For now, I have worked around this by deactivating DHCPv6 in the DLAN adapter and instead assigning a random suffix in my link-local prefix bock.
Side question: Where is the block within fe80:: determined? I don't see that configured anywhere, not do I see a place to set it. Can I rely on it to be static in my network?

¹Which is how I found out. Traceroutes over completely different network connections suddenly returned the DLAN adapter as the first hop.

Normally a host should never get the same IP address with the router. After being assigned an IP, it must verify that this IP is not used.
Check the contents of /tmp/hosts/odhcpd to verify the allocated IP.
Try to reboot the OpenWrt and the DLAN at the same time, so this file is created from scratch using the configuration in /etc/config/dhcp
If the problem persists, we'll do some more troubleshooting.

Thanks! I have unplugged the router now, unplugged the DLAN adapter, replugged the router, waited for it to reboot, then replugged the adapters.
This has lead to the explicitly assigned suffixes to be respected. This essentially solves my problem, but it of course leaves this pitfall for everyone else. (I am mainly stating that here because I send a link to this thread to the vendor tech support and would like them to keep on reading after "my problem is solved", because I don't think THEIRS is).

If I do NOT explicitly set a suffix for the DUI, the adapters will still grab ::1/::2 addresses. I assume this is an issue with the stateless address assignment in the DLAN adapter, that is probably been used when no explicit address is assigned from the DHCPv6 server.
In any case, I am pretty sure that the IPv6 implementation in the DLAN adapters has some severe issues. The webinterface also ONLY lists a link-local address that isn't even in my link-local net. (And looks a bit human chosen: fe80::babe:f4ff:fe4e) (Sorry, my fault.)
Addresses are also not listed in the adapter Web interface, so IPv6 implementation may not be great.

It doesn't answer to the link-local address listed by OpenWRT, but is does answer to the global address listed there. Pretty messed up ...

In the OpenWRT camp, I currently only see two issues:

  • Apparently I have to restart my router to make the explicit suffix assignments work. Restarting the adapters does not seem to be sufficient.
  • Should it be possible for a client to statelessly assign the routers IPv6 address to itself, notify the router about it, and the router happily accepts that and starts reverse resolving it's own IP address to the clients host name?

The link local addresses are all within fe80::/64 and the host part is formed by the mac-address of the interface. Otherwise they wouldn't work.

Not to restart the adapter, but the dhcp6d. This one is the dhcp6 server.

No, this sounds fundamentally wrong.

Wait, aren't link-local addresses all within fe80::/10, but the network chooses a /64 block in there? My secondary question was where that block is chosen, and I also remarked that the dlan adapter show a another (possibly human-chosen/explicitly set) block on their web interface.

Not to restart the adapter, but the dhcp6d. This one is the dhcp6 server.

Then it seems that luci does not do that after edits in the "DHCP and DNS" tab?

No, this sounds fundamentally wrong.

I agree, and I think this is clearly in the OpenWRT domain. Since my wife is also in homeoffice, I currently cannot test around limitless, but I think there already is enough evidence. ::1 for the DLAN adapter definitely showed up in the OpenWRT web interface, and [prefix]::1 was definitely rdns'ed to
dig @ -x [global prefix]::1

fe80::/10 is reserved for link local. But the first 10 bits of the network segment are used and the rest 54 are zero.

I think you are confusing the network part with the host part of the IPv6 address. You can post them both here to clear it out.

It's possible. Or if there is some error in configuration when restarting the service, it won't be reported on the Luci and eventually the server won't be restarted.

Some more troubleshooting needs to be done there to verify what went wrong.

So I tried to assign my wife the suffix :babe, and apparently what had to be done was to restart (reload apparently was not sufficient) odhcpd.

fe80::/10 is reserved for link local. But the first 10 bits of the network segment are used and the rest 54 are zero.

You are absolutely right, I did confuse that, and also mixed up with ULA and local-link addresses. Mea culpa.
So where is the ULA prefix set? :slight_smile:

Very romantic <3

In the global network settings section.
If you are in 19.07 Luci it is in a new tab next to Interfaces.

Thanks, I'll update in my vacation, when I don't need it for home office :slight_smile:

1 Like

Sorry to bother you one last time, but you seem to know your shit :slight_smile:
This sets the first 48bit, and then the last 16bit of the prefix seem to enumerated the interface, but I don't find the logic behind that order. It is not order in the config, or vlan id or anyting. Obviously, I would like to have my main net on 0, so I could omit that field (and in my case the previous one) entirely on my most used addresses. Any idea?

The 16 bit network id is drawn pseudo-randomly iirc. Try setting option ip6hint 0 on your LAN interface.

Thanks, that apparently worked.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.