Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

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

David,



Regards
   Brian Carpenter

On 09-May-19 09:55, David Farmer wrote:
> 
> 
> On Wed, May 8, 2019 at 2:54 PM Fernando Gont <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     The question is probably why not use IPv4 to disable IPv4. Entangling
>     one protocol with another generally leads to increased complexity, and
>     interesting attack vectors.
> 
>     I wonder why, if the issue is really a layer 2- one (e.g., stations
>     being awaken unnecessarily), the problem is not solved at layer 2- --
>     e.g. filtering at layer to, based on the Ether Proto.
> 
>     Thoughts?
> 
> 
> First, I don't think this flag is tangling the streams so to speak, IPv4 and IPv6 are tangled by the dual-stack model. I think of the flag as trying to untangle IPv6 from IPv4 so we can run IPv6-Only on dual-stack hosts.
> 
> The primary signal for a dual-stack host to not configure an IPv4 address should be the failure to receive an IPv4 address from a DHCPv4 Server [RFC2131]. This flag should be a secondary signal for a dual-stack host to not auto-configured an IPv4 Link-Local addresses [RFC3927] assuming an address has not received via DHCPv4, to not perform any IPv4 service discovery (such as mDNS [RFC6762]) using IPv4 Link-Local Addresses, and further, to limit the number of attempts that are made to configure an IPv4 address via DHCPv4. 
> 
> Otherwise, without this secondary signal, when a dual-stack host does not receive an IPv4 address from a DHCPv4 Server it would normally auto-configured an IPv4 Link-Local addresses, perform IPv4 service discovery (such as mDNS [RFC6762]) using IPv4 Link-Local addresses, and some dual-stack hosts are quite persistent in their attempt to configure an IPv4 address. It is these sides effects of not receiving an IPv4 address from a DHCPv4 Server that the flag needs to mitigate and that are necessary to untangle IPv6 from IPv4 to run IPv6-Only on dual-stack hosts.
> 
> This secondary signal needs to be expressed with an IPv6 mechanism so that it is compatible with Layer 2 filtering of IPv4 Ethertypes, however, use of the flag doesn't require this filtering. If this signal is expressed in IPv4 then it is impossible for the signal to be received in the presence of Layer 2 filtering of IPv4 Ethertypes. 
> 
> The following is the rewrite I propose for the logic in the Host Behavior Considerations Section based on the above restatement of the purpose of the flag. 
> 
> ---
> 
> A host that receives any RAs with the flag set to 1 SHOULD NOT auto-configured an IPv4 Link-Local Addresses [RFC3927] when it fails to receive an IPv4 address via DHCPv4 [RFC2131] and therefore SHOULD NOT perform IPv4 service discovery (such as mDNS [RFC6762]) using IPv4 Link-Local addresses.
> 
> A host that receives only RAs with the flag set to 1 SHOULD make a limit number of attempts to configure an IPv4 address via DHCPv4 and then make no further attempts. OPTIONAL, such a host could make no attempt to configure an IPv4 address at all. 
> 
> As soon as a host receives any RAs with the flag set to 0 it SHOULD attempt to configure an IPv4 address via DHCPv4 if it does not already have an IPv4 address configured, and MAY continue to periodically attempt to configure an IPv4 address via DHCPv4 if it does not receive an IPv4 address from a DHCPv4 Server as long as it is receiving any RAs with the flag set to 0.
> 
> A host that successfully configures an IPv4 address received via DHCPv4 SHOULD continue using it and attempt to renew it when necessary regardless the status of the flag in the RAs it is receiving. Further, it MAY perform IPv4 service discovery (such as mDNS [RFC6762]) using the configured IPv4 address.
> 
> Thanks.
> 
> -- 
> ===============================================
> David Farmer               Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota  
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>