Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

[Ola Thoresen <[e-mail]>]

On 20/10/2018 00:12, Ole Troan wrote:

>>
>>     Whatever happened to "We believe in rough consensus and running
>>     code"?
>>
>>
>> It isn't "We require ..."
>
> It isn’t. But it’s quite a big span between “it’s a hint” and “though 
> shall disable ipv4 unless you have bloody good reason not to”.
>
> In my view, I don’t see much purpose in the bit unless it’s 
> prescriptive. As in the last category.
>

On this, we can agree. Having a flag as a "hint" does not make much 
sense.  You can't trust it, so you would STILL need to verify if the 
flag is actually telling the truth, or if it is just set - either 
malicious, or by mistake.

On the other hand, I do not see how this can be a hard requirement.  Or 
at least I can not see operating systems actually obyeing such a flag.  
IF the client administrator has configured IPv4 dhcp client settings, 
why should the OS trust a flag in an RA-packet more than the OS-admins 
configuration?

Just look at the already defined flags "O" and "M" - which are not even 
breaking the barrier between the IP-protocols.  I know at least a couple 
of implementations which will send a DHCPv6-request no matter what the 
RA is signaling in its M and O-flags.  And I know implementations that 
will not automatically send dhcp-requests no matter what flags are set 
in the RA-packets.

We don't need even more flags that might or might not be ignored by the 
operating systems.  And which have a somewhat vague definition.

We don't have a flag to tell the OS to not run DECnet, Appletalk or 
IPX.  We simply disable these on the clients.  And even if we had such a 
flag in DHCPv4 or RA, I - as an admin - would prefer the clients to not 
rely on such a flag, but try to get some kind of network access on any 
enabled network protocol in the client.


Rgds.

Ola (T)