On Wed, Jul 12, 2017 at 9:32 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> On Wed, Jul 12, 2017 at 8:06 AM, Mantas Mikulėnas <graw...@gmail.com> > wrote: > > On Tue, Jul 11, 2017, 22:24 Ian Pilcher <arequip...@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 <graw...@gmail.com>
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel