[systemd-devel] systemd-networkd not sending DHCP v6 requests

[Ian Pilcher]

I'm playing using systemd-networkd (rather than the legacy network
service) on my Banana Pi CentOS 7 firewall. (See the "Bouncing
interface once chrony is synced" thread for background.)

I have "DHCP=yes" in the [Network] section of my WAN interface
(eth0.256.network):

[Match]
Name=eth0.256

[Network]
DHCP=yes
IPForward=yes
#IPv6AcceptRA=yes - Not supported in v219

[DHCP]
UseHostname=no

For some reason, though, only the IPv4 DHCP request is being sent. I
have verified with tcpdump that no "dhcp6 solicit" packets are ever
sent.

I also have a 32-bit ARM VM (qemu) running CentOS 7. It does not
exhibit this behavior; i.e. systemd-networkd does send dhcp6 solicit
packets from this VM. The most significant difference between the VM
and the firewall is that the firewall has an extremely minimal set of
packages installed.

Is there some library or package that is required for DHCP v6 to work
(something that might have slipped by an RPM packager)?

Any other ideas?

[Mantas Mikulėnas]

Post by Ian Pilcher
I'm playing using systemd-networkd (rather than the legacy network
service) on my Banana Pi CentOS 7 firewall. (See the "Bouncing
interface once chrony is synced" thread for background.)
[
]
For some reason, though, only the IPv4 DHCP request is being sent. I
have verified with tcpdump that no "dhcp6 solicit" packets are ever
sent.
I also have a 32-bit ARM VM (qemu) running CentOS 7. It does not
exhibit this behavior; i.e. systemd-networkd does send dhcp6 solicit
packets from this VM. The most significant difference between the VM
and the firewall is that the firewall has an extremely minimal set of
packages installed.

Do both systems receive router advertisements? Standard DHCPv6 is only
triggered by RAs with the "managed" flags set. (I vaguely recall RFEs for
forced DHCPv6, as some ISPs don't bother with RA on the WAN side, but I'm
not sure if that was implemented. Even if it were, DHCPv6 doesn't carry
"default gateway" information...)

Is there some library or package that is required for DHCP v6 to work

Post by Ian Pilcher
(something that might have slipped by an RPM packager)?

All networking code is in-tree, including the DHCP and RA processing.

[Lennart Poettering]

Post by Ian Pilcher
I'm playing using systemd-networkd (rather than the legacy network
service) on my Banana Pi CentOS 7 firewall. (See the "Bouncing
interface once chrony is synced" thread for background.)
I have "DHCP=yes" in the [Network] section of my WAN interface
[Match]
Name=eth0.256
[Network]
DHCP=yes
IPForward=yes
#IPv6AcceptRA=yes - Not supported in v219
[DHCP]
UseHostname=no
For some reason, though, only the IPv4 DHCP request is being sent. I
have verified with tcpdump that no "dhcp6 solicit" packets are ever
sent.

Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
do so. Hence, areyou sure the RA spoken on your network properly
indicates that?

Lennart

[Ian Pilcher]

Post by Lennart Poettering
Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
do so. Hence, areyou sure the RA spoken on your network properly
indicates that?

Interesting. I am seeing somewhat different behavior (but note that
this is systemd-networkd 219 on CentOS 7, which is pretty old).

* On networks with no router advertisements at all, systemd-networkd 219
will eventually send out dhcp6 solicit packets.

* On a network with router advertisements that include prefix info
(option 3), systemd-networkd 219 will send dhcp6 solicit packets.

* If the router advertisements on a network do not include any prefix
information, however, systemd-networkd 219 will never send any dhcp6
solicit packets and never configure an IPv6 address.

Unfortunately, my ISP's router sends RAs without prefix information.
(Clients get their addresses via DHCPv6, and are presumably expected to
simply assume a 64 bit prefix length.)

So it looks like I won't be able to use systemd-networkd to get around
the dhclient wall clock problem, at least until RHEL/CentOS see an
updated version of systemd (systemd-networkd 231 does seem to behave
differently).

[Mantas Mikulėnas]

Post by Ian Pilcher

Post by Lennart Poettering
Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
do so. Hence, areyou sure the RA spoken on your network properly
indicates that?

Interesting. I am seeing somewhat different behavior (but note that
this is systemd-networkd 219 on CentOS 7, which is pretty old).
* On networks with no router advertisements at all, systemd-networkd 219
will eventually send out dhcp6 solicit packets.
* On a network with router advertisements that include prefix info
(option 3), systemd-networkd 219 will send dhcp6 solicit packets.
* If the router advertisements on a network do not include any prefix
information, however, systemd-networkd 219 will never send any dhcp6
solicit packets and never configure an IPv6 address.
Unfortunately, my ISP's router sends RAs without prefix information.
(Clients get their addresses via DHCPv6, and are presumably expected to
simply assume a 64 bit prefix length.)
So it looks like I won't be able to use systemd-networkd to get around
the dhclient wall clock problem, at least until RHEL/CentOS see an
updated version of systemd (systemd-networkd 231 does seem to behave
differently).

What global flags do each network's RAs have? If I remember correctly,
there are two, "Managed Addresses" and "Managed Other", which trigger
DHCPv6 – if neither of them is set, that is supposed to mean DHCPv6 is
unneeded.

[Andrei Borzenkov]

Post by Ian Pilcher

Post by Lennart Poettering
Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
do so. Hence, areyou sure the RA spoken on your network properly
indicates that?

Interesting. I am seeing somewhat different behavior (but note that
this is systemd-networkd 219 on CentOS 7, which is pretty old).
* On networks with no router advertisements at all, systemd-networkd 219
will eventually send out dhcp6 solicit packets.
* On a network with router advertisements that include prefix info
(option 3), systemd-networkd 219 will send dhcp6 solicit packets.
* If the router advertisements on a network do not include any prefix
information, however, systemd-networkd 219 will never send any dhcp6
solicit packets and never configure an IPv6 address.
Unfortunately, my ISP's router sends RAs without prefix information.
(Clients get their addresses via DHCPv6, and are presumably expected to
simply assume a 64 bit prefix length.)
So it looks like I won't be able to use systemd-networkd to get around
the dhclient wall clock problem, at least until RHEL/CentOS see an
updated version of systemd (systemd-networkd 231 does seem to behave
differently).

What global flags do each network's RAs have? If I remember correctly, there
are two, "Managed Addresses" and "Managed Other", which trigger DHCPv6 – if
neither of them is set, that is supposed to mean DHCPv6 is unneeded.

Citation please. RFC 2462 says:

On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
into ManagedFlag. If the value of ManagedFlag changes from FALSE to
TRUE, and the host is not already running the stateful address
autoconfiguration protocol, the host should invoke the stateful
address autoconfiguration protocol, requesting both address
information and other information. If the value of the ManagedFlag
changes from TRUE to FALSE, the host should continue running the
stateful address autoconfiguration, i.e., the change in the value of
the ManagedFlag has no effect. If the value of the flag stays
unchanged, no special action takes place. In particular, a host MUST
NOT reinvoke stateful address configuration if it is already
participating in the stateful protocol as a result of an earlier
advertisement.


There are no statements anywhere (I can find) that host MUST NOT
invoke stateful autocnfiguration if RA has M flag set to false. It is
entirely up to host to use stateful autocnfioguration in addition (or
for that matter instead of) SLAAC.

If you have reference to RFC that says otherwise, please provide it.

[Mantas Mikulėnas]

Post by Andrei Borzenkov

Post by Mantas Mikulėnas

Post by Ian Pilcher

Post by Lennart Poettering
Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
do so. Hence, areyou sure the RA spoken on your network properly
indicates that?

Interesting. I am seeing somewhat different behavior (but note that
this is systemd-networkd 219 on CentOS 7, which is pretty old).
* On networks with no router advertisements at all, systemd-networkd 219
will eventually send out dhcp6 solicit packets.
* On a network with router advertisements that include prefix info
(option 3), systemd-networkd 219 will send dhcp6 solicit packets.
* If the router advertisements on a network do not include any prefix
information, however, systemd-networkd 219 will never send any dhcp6
solicit packets and never configure an IPv6 address.
Unfortunately, my ISP's router sends RAs without prefix information.
(Clients get their addresses via DHCPv6, and are presumably expected to
simply assume a 64 bit prefix length.)
So it looks like I won't be able to use systemd-networkd to get around
the dhclient wall clock problem, at least until RHEL/CentOS see an
updated version of systemd (systemd-networkd 231 does seem to behave
differently).

What global flags do each network's RAs have? If I remember correctly,

there

Post by Mantas Mikulėnas
are two, "Managed Addresses" and "Managed Other", which trigger DHCPv6 –

if

Post by Mantas Mikulėnas
neither of them is set, that is supposed to mean DHCPv6 is unneeded.

On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
into ManagedFlag. If the value of ManagedFlag changes from FALSE to
TRUE, and the host is not already running the stateful address
autoconfiguration protocol, the host should invoke the stateful
address autoconfiguration protocol, requesting both address
information and other information. If the value of the ManagedFlag
changes from TRUE to FALSE, the host should continue running the
stateful address autoconfiguration, i.e., the change in the value of
the ManagedFlag has no effect. If the value of the flag stays
unchanged, no special action takes place. In particular, a host MUST
NOT reinvoke stateful address configuration if it is already
participating in the stateful protocol as a result of an earlier
advertisement.
There are no statements anywhere (I can find) that host MUST NOT
invoke stateful autocnfiguration if RA has M flag set to false. It is
entirely up to host to use stateful autocnfioguration in addition (or
for that matter instead of) SLAAC.
If you have reference to RFC that says otherwise, please provide it.

I see that 2462 was obsoleted by 4862, which no longer defines either flag
at all.

I hereby apologize for being wrong and for offending you with dissemination
of my inaccurate knowledge.

[Ian Pilcher]

Post by Mantas Mikulėnas
What global flags do each network's RAs have? If I remember correctly,
there are two, "Managed Addresses" and "Managed Other", which trigger
DHCPv6 – if neither of them is set, that is supposed to mean DHCPv6 is
unneeded.

The managed and other config flags are both set:

09:07:36.859265 00:01:5c:77:bc:46 > 33:33:00:00:00:01, ethertype IPv6
(0x86dd), length 70: (hlim 255, next-header ICMPv6 (58) payload length:
16) fe80::201:5cff:fe77:bc46 > ff02::1: [icmp6 sum ok] ICMP6, router
advertisement, length 16
hop limit 0, Flags [managed, other stateful], pref medium,
router lifetime 1800s, reachable time 3600000ms, retrans time 0ms

[Auke Kok]

Post by Ian Pilcher
I'm playing using systemd-networkd (rather than the legacy network
service) on my Banana Pi CentOS 7 firewall. (See the "Bouncing
interface once chrony is synced" thread for background.)
I have "DHCP=yes" in the [Network] section of my WAN interface
[Match]
Name=eth0.256
[Network]
DHCP=yes
IPForward=yes
#IPv6AcceptRA=yes - Not supported in v219
[DHCP]
UseHostname=no
For some reason, though, only the IPv4 DHCP request is being sent. I
have verified with tcpdump that no "dhcp6 solicit" packets are ever
sent.

I have a "similar" issue: with 'DHCP=both', only an ipv4 address is
obtained, even though my dhcp server is capable of giving other OS's
with e.g. NetworkManager both ipv4 and ipv6 addresses.

Auke