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

[Alexandre Petrescu <[e-mail]>]

Le 01/11/2018 à 13:19, Joel Jaeggli a écrit :
>
>
>> On Oct 20, 2018, at 10:34, Ola Thoresen <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> On 20/10/2018 00:12, Ole Troan wrote:
>>
>>>
>>>
>>> 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.
>>
> I can’t really trust (ND, RAs, ARP, DHCP, DHCPv6, MDNS).

It should not be difficult to slightly secure the RA that contains the 
IPv6-only flag.  A check of the existing L2 address in NC for the GW of 
the default route, against the L2 source address of the L2 header of the 
RA containing IPv6-only flag, should add some insurance.  On cellular 
links, the reliance on SIM cards should be sufficient.

Alex

> Lack of trust here extends to most of the signals one might receive in 
> the process of bootstrapping. Of those signals some of them I accept 
> because as part of a faustian bargain I made when attaching to the 
> network, I actually need some of that information. The stuff that I 
> don’t have to accept in order to achieve basic functionality I ignore.
>
> As  case in point all the operating systems I use allow me to specify 
> my own nameserver despite receiving such information  via DHCP/DHCPv6, 
> doing so may come at the expense of some local funcationality but it’s 
> worth it as far as I’m concerned.
>>
>> 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.
>>
> And which is not absolutely necessary for bootstrapping.
>>
>> 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)
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail] <mailto:[e-mail]>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------