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

[Andrei Borzenkov]

On Wed, Jul 12, 2017 at 8:06 AM, Mantas Mikulėnas <grawity at gmail.com> wrote:
> On Tue, Jul 11, 2017, 22:24 Ian Pilcher <arequipeno at gmail.com> wrote:
>>
>> On 07/11/2017 02:58 AM, Lennart Poettering wrote:
>> > 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.