<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 12, 2017 at 9:32 AM, Andrei Borzenkov <span dir="ltr"><<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Wed, Jul 12, 2017 at 8:06 AM, Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> wrote:<br>
> On Tue, Jul 11, 2017, 22:24 Ian Pilcher <<a href="mailto:arequipeno@gmail.com">arequipeno@gmail.com</a>> wrote:<br>
>><br>
>> On 07/11/2017 02:58 AM, Lennart Poettering wrote:<br>
>> > Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to<br>
>> > do so. Hence, areyou sure the RA spoken on your network properly<br>
>> > indicates that?<br>
>><br>
>> Interesting. I am seeing somewhat different behavior (but note that<br>
>> this is systemd-networkd 219 on CentOS 7, which is pretty old).<br>
>><br>
>> * On networks with no router advertisements at all, systemd-networkd 219<br>
>> will eventually send out dhcp6 solicit packets.<br>
>><br>
>> * On a network with router advertisements that include prefix info<br>
>> (option 3), systemd-networkd 219 will send dhcp6 solicit packets.<br>
>><br>
>> * If the router advertisements on a network do not include any prefix<br>
>> information, however, systemd-networkd 219 will never send any dhcp6<br>
>> solicit packets and never configure an IPv6 address.<br>
>><br>
>> Unfortunately, my ISP's router sends RAs without prefix information.<br>
>> (Clients get their addresses via DHCPv6, and are presumably expected to<br>
>> simply assume a 64 bit prefix length.)<br>
>><br>
>> So it looks like I won't be able to use systemd-networkd to get around<br>
>> the dhclient wall clock problem, at least until RHEL/CentOS see an<br>
>> updated version of systemd (systemd-networkd 231 does seem to behave<br>
>> differently).<br>
><br>
><br>
> What global flags do each network's RAs have? If I remember correctly, there<br>
> are two, "Managed Addresses" and "Managed Other", which trigger DHCPv6 – if<br>
> neither of them is set, that is supposed to mean DHCPv6 is unneeded.<br>
><br>
<br>
</div></div>Citation please. RFC 2462 says:<br>
<br>
On receipt of a valid Router Advertisement (as defined in<br>
[DISCOVERY]), a host copies the value of the advertisement's M bit<br>
into ManagedFlag. If the value of ManagedFlag changes from FALSE to<br>
TRUE, and the host is not already running the stateful address<br>
autoconfiguration protocol, the host should invoke the stateful<br>
address autoconfiguration protocol, requesting both address<br>
information and other information. If the value of the ManagedFlag<br>
changes from TRUE to FALSE, the host should continue running the<br>
stateful address autoconfiguration, i.e., the change in the value of<br>
the ManagedFlag has no effect. If the value of the flag stays<br>
unchanged, no special action takes place. In particular, a host MUST<br>
NOT reinvoke stateful address configuration if it is already<br>
participating in the stateful protocol as a result of an earlier<br>
advertisement.<br>
<br>
<br>
There are no statements anywhere (I can find) that host MUST NOT<br>
invoke stateful autocnfiguration if RA has M flag set to false. It is<br>
entirely up to host to use stateful autocnfioguration in addition (or<br>
for that matter instead of) SLAAC.<br>
<br>
If you have reference to RFC that says otherwise, please provide it.<br>
</blockquote></div><br>I see that 2462 was obsoleted by 4862, which no longer defines either flag at all.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I hereby apologize for being wrong and for offending you with dissemination of my inaccurate knowledge.<br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>></div></div>
</div></div>