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

From: Joel Jaeggli <[email-masked]>
Date: Thu, 1 Nov 2018 05:19:11 -0700

> On Oct 20, 2018, at 10:34, Ola Thoresen <[email-masked] <mailto:[email-masked]>> 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). 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
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Nov 2018 18:06:14 +0100

Le 01/11/2018 à 13:19, Joel Jaeggli a écrit :
>> 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.
>>
>> 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)
>>
>>
> [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Nov 2018 15:13:28 +1300

fwiw I have reproduced Alex's test by installing scapy on a Linux box
and using it to forge RAs as from my home gateway with the IPv6-only bit set.
Nothing breaks on the other hosts (Windows 10 and Android), which is
as it should be, and Wireshark confirms that the packets are delivered
and are excellent forgeries.

Regards
   Brian

On 2018-10-25 02:17, Alexandre Petrescu wrote:
> correction: b.res=2 (instead of 1).
> 
> attached the packet capture
> 
> 
> Le 24/10/2018 à 14:43, Alexandre Petrescu a écrit :
>> Hi,
>>
>> Le 24/10/2018 à 12:30, Job Snijders a écrit :
>> [...]
>>> This is not discrimination. If authors don't have the capability to 
>>> develop running code themselves, and also don't have access to
>>> resources nor are able to convince others to implement a protocol
>>> specification... the IETF's prime directive of interoperability can't
>>> be met anyway.
>>
>> On windows install python and scapy, then make an RA[*] and write
>> b.res=1. This sets the 6th Reserved flag, now called 'IPv6-Only'.
>>
>> I just sent one, hoping sky wouldnt fall on my head :-)
>>
>> Alex
>> [*] how to make an RA with scapy tool is described at
>> https://samsclass.info/124/proj11/proj9xN-scapy-ra.html
>>