Hi Vincent,
On Sat, Nov 01, 2025 at 06:23:50PM +0100, Vincent Danjean wrote:
> > - `dhcp 1` is stateless DHCP and will not assign an address on it's own.
>
> I've lots of interfaces on this machine (vlan for internal networks, vpn,
> interface to reach virtual machines, uplinks). This interface is the only
> one having
>
> dhcp 1
>
> And this is the only one interface that runs dhclient (IPv6):
>
> 3399342 ? Ss 0:00 dhclient -6 -v -P -pf /run/dhclient6.en-rezine.pid -lf /var/lib/dhcp/dhclient6.en-rezine.leases -I -df /var/lib/dhcp/dhclient.en-rezine.leases en-rezine
>
> I've two other dhclient but for IPv4 (on the same interface and on the other uplink)
>
> I'm pretty sure that "dhcp 1" is the reason for "dhclient -6 ..." to be running.
Ah! `request_prefix 1` switches the meaning of `dhcp 1` from "stateless"
(dhclient -S) to "stateful" IA_NA in addtion to IA_PD (dhclient -P). Wow
could this be documented any worse -- interfaces(5) is just a bunch of lies
ATM haha :-).
> > - `accept_ra 0` will prevent kernel SLAAC address and (default) route
> > creation entirely, leaving no address configuration method enabled
> > (other than link-local). Further, no stateful DHCPv6 client will be
> > enabled by RA flag M being advertised by the network since that's not
> > supported by dhclient AFAIK.
>
> I use this config indeed to prevent the default route to be set (here again
> this is due to the multi ISP settings and specific routing policy),
Right, so you're creating your own (static) routes in scripts then?
Could you elaborate on what the setup looks like. I would like to have
multihoming natively supported in ifupdown eventually so an existing setup
is good food for design thought :-).
> This ISP does not give me a SLAAC address. In fact, it does not
> give me any routable IPv6 address directly. I just use a link-local IPv6
> (hence the "inet6 auto" setup in /etc/network/interface) and
> I route my IPv6 traffic to an other IPv6 link-local address (fe80::...)
Ah, that makes sense :-).
> I had to learn it initially by accepting RA and looking at the provided
> value.
>
> I plan to monitor RA to check that this IPv6 link-local address does not
> change, but it is only on my TODO list for now. The gateway changes only
> once (a few months ago) for 8 years and it was due to a hardware change
> on the ISP side (so the mac address of its interface changes).
>
> When it occurs, I had forgotten this static setup and it took me a while
> to find why the IPv6 connexion was not working anymore.
With dhcpcd you can get updates on the link-local address of the announcing
router in hook scripts (dhcpcd-run-hooks(8)) and use it to keep it
updated. You can see whats available with dhcpcd -T -- "test" mode. It
prints what the script environment will look like with the real leases in
your network:
$ sudo dhcpcd -T wlan0 | grep ^nd1_from
nd1_from='fe80::6f0:21ff:fe45:c393'
You should be careful to only use routers with non-zero ndX_lifetime
however!
You can also use this to get keep DHCP-PD prefix information updated in
your firewall/routing setup:
$ dhcpcd -T wlan0 -6 --dhcp6 --ia_pd 2>/dev/null | grep ^new_dhcp6
new_dhcp6_ia_pd1_prefix1=2001:db8::'
new_dhcp6_ia_pd1_prefix1_length='62'
new_dhcp6_ia_pd1_prefix1_pltime='2754'
new_dhcp6_ia_pd1_prefix1_vltime='3754'
new_dhcp6_ia_pd1_t1='1377'
new_dhcp6_ia_pd1_t2='2203'
> > > and also a /48 via prefix delegation (in DHCP),
> >
> > - `request_prefix` defaults to OFF in both method auto and dhcp.
>
> When "dhcp 1" is there and "dhclient -6 ..." is run, I can see:
> [...]
> XMT: X-- IA_PD 00:77:00:09
> XMT: | X-- Requested renew +3600
> XMT: | X-- Requested rebind +5400
> XMT: | | X-- IAPREFIX 2001:XXXX:XXXX:XXXX::/56
> XMT: | | | X-- Preferred lifetime +7200
> XMT: | | | X-- Max lifetime +7500
> XMT: V IA_PD appended.
> [...]
> > None of what you describe should be working.
>
> ;-) I would be pleased to do some experiments if you want to
Without having `request_prefix 1` this cannot be working. The conditional
for launching dhclient with -P (IA_PD) in ifupdown/inet6.defn for method
`auto` is:
if (var_true("dhcp", ifd) && execable("dhclient") && var_true("request_prefix", ifd))
and similarly for method dhcp just not requiring the `dhcp` variable:
if (execable("dhclient") && var_true("request_prefix", ifd))
The request_prefix variable defaults to 0 in both cases (see the number
surrounded by [ ]):
request_prefix int -- Request a prefix through DHCPv6 Prefix Delegation (0=off, 1=on) [0]
request_prefix int -- Request a prefix through DHCPv6 Prefix Delegation (0=off, 1=on) [0]
The config you showed me (missing any request_prefix line) cannot do what
you describe.
> Supporting `request_prefix` with dhcpcd is on my TODO list. You can easily
> drop down to dhcpcd.conf even without support in ifupdown though.
FYI: I've added support now, the code could use someone to test it and
evaluate what the dhcpcd-run-hooks script environment looks like for
PD. *hint* *hint* ;-).
https://salsa.debian.org/debian/ifupdown/-/merge_requests/28/diffs?commit_id=15da291cbfc4136524aaae4cb348b17d9faf5eb0
> > > Also note that I'm a user of the /etc/dhcp/dhclient-enter-hooks.d
> > > interface. Due to the multi-ISP setup, I remove with a script
> > > the default IPv4 route classically added by DHCP for my different ISP.
> > > The routing is manually handled by shorewall config.
> >
> > Makes sense. I'd be happy to support the old dhclient-*-hooks.d interface,
> > but we need to review all the existing scripts in Debian to make sure
> > nothing will break spectacularly.
> >
> > Could you help review them for compatibility if I look at where the
> > incompatibilities with dhcpcd's hook environment might lie?
>
> I can do some experiments. It is a VM. I can clone it to make tests and
> quickly go back to the previous state.
You may want to look at [debvm], which makes testing so much faster (than
what I used to do anyway). Only caveat is you need to install ifupdown
manually and neuter systemd-networkd which it defaults to for some ungodly
reason ;P.
[debvm]: https://packages.debian.org/trixie/debvm
Helmut's introductory talk: https://hamburg-2023.mini.debconf.org/talks/3-debvm-ephemeral-virtual-debian-machines/
I use
$ debvm-create -r trixie -o ~/vm/ifupdown-trixie.debvm -z 20G -k ~/.ssh/authorized_keys -s systemdnetwork -- --include=ifupdown,ifupdown-ng,dhcpcd-base,tcpdump,zile
to make my test environment and
$ debvm-run -i ~/vm/ifupdown-sid.debvm -- -snapshot
to boot the VM. Note: The -snapshot will make this boot throw away disk
image changes, omit it to make persistent changes.
--Daniel
Attachment:
signature.asc
Description: PGP signature