How to disable ia_na in dhcpcd?

[frankcrawford]

Is there any way to disable ia_na requests with running dhcpcd?

There looks like there may be a mechanism for doing it for dhclient, although I haven't tried it, but cannot see any method for dhcpcd.

My reason for this is that my router, while it supports DHCPv6 does not seem to allow me to set up a fixed IPv6 address, so I'm currently getting an extra address from the DHCPv6 server.

[sshambar]

Sorry for the delay, been on holiday the last week -- just getting back in the game here :)

Well, it's actually quite simple for dhcpcd, but I don't have an easy flag for it atm... basically if you search in 08-ipv6-prefix (around line 3020) you'll see the generated config file template for dhcpcd -- if you just place a "#' in front of the ia_na ${iaid} line and down/up the interface, dhcpcd will no longer request an address (note an address will still be applied by auto-configuration if the router has enabled that though)

If that does what you expect, let me know and I'll add a WAN_IANA_DISABLE or similar flag to allow that behavior to be triggered (for both dhclient and dhcpcd).

[sshambar]

BTW, you can use ./08-ipv6-prefix status to check whether the current status of the client...

[frankcrawford]

Yep, it is currently shown in ./08-ipv6-prefix status as in:

DBG: COMMAND: status INTERFACE: 
WAN enp15s0 (UP method=ignore dhcp=dhcpcd)
    autoconf: 2401:d002:1707:4100::1/64 (valid 537 pref 537)
       ia_na: 2401:d002:1707:4100:5291:e3ff:fec8:f7f3/128 (valid 5799 pref 2199)
       ia_pd: 2401:d002:1707:41f8::/62 (valid 5799 pref 2199)
         DNS: fdd2:7aad:d478:1::1
      Search: 
  Default gateway: fe80::464e:6dff:fedf:2f00
  Assigning source-routes
  LAN enp16s0 (UP)
    assigned: 2401:d002:1707:41f8::1/64 (valid 5799 pref 2199)

I've commented out ia_na ${iaid} now and will see what happens on my next reboot (later today after some patching).

[frankcrawford]

An interesting result, certainly disabling ia_na ${iaid} stopped it from getting or setting a DHCPv6 IP, but ./08-ipv6-prefix status still shows it, i.e. after the reboot:

DBG: COMMAND: status INTERFACE: 
WAN enp15s0 (UP method=ignore dhcp=dhcpcd)
    autoconf: 2401:d002:1707:4100::1/64 (valid 545 pref 545)
       ia_na: 2401:d002:1707:4100:5291:e3ff:fec8:f7f3/128 (valid 7063 pref 3463)
       ia_pd: 2401:d002:1707:41f8::/62 (valid 7063 pref 3463)
         DNS: fdd2:7aad:d478:1::1
      Search: 
  Default gateway: fe80::464e:6dff:fedf:2f00
  Assigning source-routes
  LAN enp16s0 (UP)
    assigned: 2401:d002:1707:41f8::1/64 (valid 7063 pref 3463)

[sshambar]

That's really odd...

• could you make sure the generated config file doesn't have the ia_na entry? (it'll be in /run/nmutils/dhcpcd-enp15s0.conf)
• also try running /etc/NetworkManager/dispatcher.d/08-ipv6-prefix config -a enp15s0 | grep DHCPCD and make sure no extra args are being set for dhcpcd...

[frankcrawford]

So, yes, I checked and no extra arguments and the ia_na issue is commented out in the conf file.

However, looking at the code, I see this:

BOUND6|RENEW6|REBIND6|REBOOT6|DELEGATED6)
        ipv6_wan_update_cstate "boot"
        [[ ${new_dhcp6_ia_na1_ia_addr1-} ||
             ${new_delegated_dhcp6_prefix-} ]] && ipv6_dcd_bind_addr
        [[ ${new_dhcp6_ia_pd1_prefix1-} ]] && ipv6_dcd_bind_prefix
        ;;

so it calls ipv6_dcd_bind_addr for just new_delegated_dhcp6_prefix. That means it creates the file even for just a ia_pd.

However, I also see that dhcpcd does look up the address, so it may be a question for them:

4 S dhcpcd     52422       1  0  80   0 -   774 do_sys Feb03 ?        00:00:11 dhcpcd: enp15s0 [ip6]
5 S root       52423   52422  0  80   0 -   775 do_sys Feb03 ?        00:00:00 dhcpcd: [privileged proxy] enp15s0 [ip6]
5 S dhcpcd     52424   52422  0  80   0 -   771 do_sys Feb03 ?        00:00:00 dhcpcd: [network proxy] enp15s0 [ip6]
5 S dhcpcd     52425   52422  0  80   0 -   770 do_sys Feb03 ?        00:00:00 dhcpcd: [control proxy] enp15s0 [ip6]
5 S dhcpcd     52427   52423  0  80   0 -   775 do_sys Feb03 ?        00:00:00 dhcpcd: [DHCP6 proxy] fe80::5291:e3ff:fec8:f7f3
5 S dhcpcd     52680   52423  0  80   0 -   775 do_sys Feb03 ?        00:00:00 dhcpcd: [DHCP6 proxy] 2401:d002:1707:4100::1
5 S dhcpcd     52681   52423  0  80   0 -   775 do_sys Feb03 ?        00:00:00 dhcpcd: [DHCP6 proxy] 2401:d002:1707:4100:5291:e3ff:fec8:f7f3

although reading their documentation it does look that it tries to base things on the Router Advertisement, which may include calls to DHCP6 values.

Also, interestingly, it seems to get a different IPv6 delegation (f8 vs fc) than previously, which makes me wonder if it also causes a small difference here, not as a bug but as a feature.

[sshambar]

The $new_delegated_dhcp6_prefix is the excluded prefix in prefix delegation, and is returned by the server as part of the IA_PD request, but the "status" output will mark it "exclude" so it's not confused with "ia_na" :)

Scanning the dhcp6 RFC, I don't see any reason why the server couldn't just send an IA_NA response even if the client didn't request it... either that or dhcpcd is keeping the IA_NA part of the lease (it keeps them in /var/lib/dhcpcd or a similar state directory). If you want to check, you can run a tcpdump capture on the WAN interface and check the packets:

In a BASH session:

$ tcpdump -i enp15s0 -nnvv udp port 547 &
$ systemctl restart dhcpcd6-enp15s0
# wait for the 2-4 packets for DHCP6
$ kill %1 # kills tcpdump

You can check the client -> server packets and ensure there no IA_NA option, and see if the server -> client does have one!

[frankcrawford]

I may have a look sometime, although I did check the dhcpcd lease file and it didn't seem to have that address listed, but otherwise it does look like dhcpcd has requested it or at least received it somewhere along the line.

[frankcrawford]

@sshambar just an update, this seems to have cleaned itself up since then.

I suspect the issue was that the ia_na address still had a lifetime, so the DHCP server was still pushing it anyway even though it wasn't being asked for. As well, the ia_pd range has changed slightly, going back to the old one, I expected.

Thinking about it a bit, the dhclient6 and dhcpcd -6 were using different identifiers, so the DHCP server assumed they were different hosts and served up different ranges, but somewhere the original ia_na address was stuck in the system.

Looking now a few weeks later, it is gone, and running as expected, except it caught me by surprise when it changed the ia_pd range.

[frankcrawford]

Actually, I am wrong on one point, I didn't swap from dhclient6 to dhcpcd -6, I just updated the config for dhcpcd -6, which may still have made the server think it was a new request while still holding the old ones as well.

[sshambar]

Thinking about it a bit, the dhclient6 and dhcpcd -6 were using different identifiers, so the DHCP server assumed they were different hosts and served up different ranges, but somewhere the original ia_na address was stuck in the system.

Yeah, when switching between dhclient and dhcpcd, I had to hand generate the /var/lib/dhcpcd/duid file so that it matched the one used by dhclient... I think I might have grabbed the value from a tcpdump capture as the format in the dhclient *.leases file was difficult to parse :)

It's also critical to use NM ipv6.method=ignore to enable dhcpcd mode, as dhcpcd manages all the addresses directly on the interface, and doesn't offer the level of control via the script interface that dhclient does (journalctl -t ipv6-prefix can provide valuable insights, especially if setting general.conf:nmg_show_debug=1 )

[frankcrawford]

@sshambar did anything to disable requesting an IP get added into the new release?

[sshambar]

No, I haven't played with that as an option yet -- I'll see if I can work it into the next update though :)

[frankcrawford]

That is okay, I may add something myself and do a PR for it.

[frankcrawford]

@sshambar just an update here, since disabling the IA_NA option, I've noticed a strange problem, while the address gets allocated on the LAN ports, after a few days to a week they are listed as "deprecated".

Where as if I enable the IA_NA option it looks to be working fine, not showing any sign of being deprecated.

Any ideas?

[sshambar]

I'm guessing the system is up the whole time? If so, it could be the trigger to "revive" the LAN prefix assignments is missing when there is no ia_na assigned -- I never tested prefix assignment w/o ia_na (as it wasn't a "feature" yet), so I'd have to check the logic to be sure. IIRC, I recall some quirk with dhcpcd not providing a "trigger" to renew ia_pd's though, but it wasn't an issue as the ia_na renews covered it... this could totally be the cause of the problem, and would require creating a custom timer to work around.

Sorry I haven't found the time to work on this (illness in the family taking my free time)... adding this feature properly is still the next thing on my list!

[frankcrawford]

@sshambar not a big problem for me, more just an annoyance that I currently need to also have the random IA_NA request and address.

Failure of the trigger does sound like it, and it does sound more like a bit of a bug with dhcpcd. Have you reported it to them, and/or seen an issue for it on their site? Otherwise I may also take it up with them.