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

[Mantas Mikulėnas]

On Wed, Jul 12, 2017 at 9:32 AM, Andrei Borzenkov <arvidjaar at gmail.com>
wrote:

> 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.
>

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.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170712/ee2de496/attachment-0001.html>