[solved] Stale DHCPv6 leases under Network -> DHCP and DNS

Thanks, I'll have a look at ethers, there is no dhcp6.leases file anywhere (perhaps /var/hosts/odhcpd)

are they in /tmp/dhcp.leases too?

Nnnnope, the IPV6 leases live in another file, the one I mentioned.

1 Like

But it's static - I think you misunderstand the issue.

  • Android clients do not use stateful connection, hence they do not use DHCPv6.
  • It seems you want only DHCPv6 - be sure to disable stateless connections, and be mindful - Android clients will not get an IPv6 address
3 Likes

That is not at all... unlikely :smiley:
I have a fair amount of confusion in my head regarding IPV6.

Adding to the confusion, one host (raspi running raspbian, afaik equivalent to wthat is now debian "oldstable") has a /128 which matches the DNS entry. The two Debian/testing machines have outdated entries.

If I understand you correctly, you're telling me that there is no way I can achieve my goal without some kind of intervention on the hosts if I still want every host to have an IPV6 address and a corresponding DNS entry.

If it helps, internally it would be perfectly acceptable for me if the entries in the DNS were those directly derived from the MAC address (SLAAC, is that it?). I wouldn't be answering queries from outside the network, of course.

By default dnsmasq manages DHCPv4 and odhcpd manages DHCPv6:

Static DHCPv6 leases are issued based on DUID:

2 Likes

Thanks, I'll have a look at the docs you linked, do some testing and come back when I have results.

For now, one question: how do I handle devices with multiple interfaces? I have two laptops, one W10 and one Linux, which have static IPV4 leases mapping both MACs (wired and wifi) to the same name, under the (reasonable for me) assumption that they're not going to be used concurrently.

What do you have to handle, then?

(Besides, most OSes handle this by changing the routing metric on the wired versus wireless interfaces.)

2 Likes

router-side, this:

config host
option name 'laptop'
option ip 'x.y.z.5'
option mac 'mac1 mac2'

client-side, either the cable is plugged in or I switch the wifi off. I could probably just let it be and ignore the extra address I get, sure, but it doesn't change the fact I need to list both MACs for the same lease if I want either of them to get the same hostname.

Add the duid and hostid options according to the wiki.

2 Likes

So, here are the new bits from /etc/config/dhcp:

config host                                          
        option name 'desktop'
        option ip 'x.y.z.4'
        option mac 'mac'      
        option hostid '4'                            
        option duid '0004blahblahblahdesktop'

config host                                      
        option name 'laptop'              
        option mac 'mac1 mac2'  
        option ip 'x.y.z.8'            
        option hostid '8'                        
        option duid '0004blahblahblahlaptop'

config host                                               
        option name 'raspi'                    
        option mac 'mac1 mac2'  
        option ip 'x.y.z.14'      
        option hostid '14'       
        option duid '0001blahblahblahraspi' 
  • Debian (on desktop and laptop) creates type 4 DUIDs (option "Stable privacy" for "address generation" in NetworkManager seems to be the default when I create a new connection).
  • Raspbian creates type 1 DUIDs, no idea how to change it but it doesn't really matter, especially now.

Problem is, even after stopping multiple times dnsmasq, clearing the caches on clients and restarting....
only the raspi answers ping6 from the router and apparently it is not even using the correct hostid, since the last part of the address is ::514 (/128) instead of ::0014

Disabling the privacy extensions (tested on laptop) only removes the additional temporary addresses but the main one is still different and unknown. I guess I need to find out why the clients behave the way they do.

Oh and... how do I even handle Android devices? I thought of using "config domain" entries as if they were truly static addresses, instead of merely predictable, but this keyword does not support IPV6 according to the docs.

I had a look at this but it seems no longer needed: LUCI has a field for DUIDs

1 Like

Housekeeping:

  • I split the part related to Android devices in another post
  • I'm asking in the Debian IPV6 list for help, will update this post with the solution

NetworkManager specifically relies on the parameters addr-gen-mode and ip6-privacy:
https://developer.gnome.org/NetworkManager/stable/nm-settings.html#id-1.2.7.4.19

addr-gen-mode should apply to slaac addresses only, as I understand it; I tried changing the mode and reconnecting: different addresses but here the issue is that the lease is requested, obtained and then ignored. I've also tried disabling PE and nothing changed.

I'll call it a day, I've fixed PE on the raspi and the hostnames for Android devices... I don't have to learn everything TODAY :smiley:

1 Like

In the case of the laptop, the culprit was "ferm" (firewall): once I stopped it, it worked fine.... I'll need to punch a hole for dhcpv6.
My mistake here was taking the "solicit" message as confirmation that all was nominal, while there has to be a "request" as well. Once I saw in /var/log/messages that each dchp6 session was timing out, that was a huge clue. I'll see if the desktop is also timing out, though I don't recall ever installing any firewall there.

One thing I don't really understand yet is how the "hostid" works: if I set it to '0008', I'd expect the last group of the address to be ::8 but it's something else. This happened with the raspi, too, so it might just be me missing the point.

desktop now works, too, must have finally cleared the right lease file :smiley:

fun fact, the address is just what I expected, the hostid mistery deepens :slight_smile:

In addition to the accepted solution and as a quick recap for myself and other future readers:

  • double-check that the dhcp negotiation actually works, especially if you have a firewall
  • the client may cache an existing lease and prefer using it until expiration, rather than accept your new static lease candidate
  • Android (SLAAC-only hosts) need a "config domain" entry with the MAC-derived address: you must manually create it, since it is not automatically created from the existing "config dhcp" entry for IPV4 static leases

Thanks to all who contributed.

3 Likes

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