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

[Brian E Carpenter <[e-mail]>]

On 2018-10-21 06:34, Ola Thoresen wrote:
> 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,

It seems to me that for 99.99% of hosts today, there is no admin in that
sense and what you get is the O/S factory default setting. For example,
if the factory default is to reduce the frequency of DHCP solicitations
when it sees this flag, then it's mission accomplished: less battery and
air time wasted on IPv4 packets.

But anyway, can you point to language in the draft that is incompatible
with what you wrote?

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

Where is the vagueness in the definition? Which sentences in the -03 draft
are vague?

> We don't have a flag to tell the OS to not run DECnet, Appletalk or 
> IPX.  We simply disable these on the clients.  

But that is *managed* clients. Most clients, especially BYOD clients,
are unmanaged and arrive with dual stack IP enabled.

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

Even if that drains the batteries on constrained devices?

     Brian