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

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

Speaking for myself:

> In the presence of the flag, a host MAY attempt DHCPv4 a limited number of times, but MUST NOT perform Stateless Auto-Configuration of an IPv4 address and MUST NOT perform any service discovery (such as mDNS) unless it receives a unicast IPv4 address from DHCPv4 server or relay on the network.

In effect that expands the current SHOULD NOT text, which says:

>>> A host that receives only RAs with the flag set to 1 SHOULD NOT
>>> attempt any IPv4 operations, unless it subsequently receives at least
>>> one RA with the flag set to zero.

I think that's a reasonable addition, if the document proceeds.

   Brian

On 08-May-19 10:23, David Farmer wrote:
> Whoops, I lost the list somehow.
> 
> ---------- Forwarded message ---------
> From: *David Farmer* <[e-mail] <mailto:[e-mail]>>
> Date: Tue, May 7, 2019 at 5:13 PM
> Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
> To: Manfredi (US), Albert E <[e-mail] <mailto:[e-mail]>>
> 
> 
> 
> 
> On Tue, May 7, 2019 at 4:26 PM Manfredi (US), Albert E <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On Mon, 29 Apr 2019, Ole Troan wrote:
> 
>     > At the 6man meeting at IETF 104 in Prague there was support to close the working group last call and advance
>     > draft-ietf-6man-ipv6only-flag-05 to the IESG.
>     >
>     > This call is to confirm that decision on the mailing list.
>     >
>     > Please give objections and comments to this decision to the mailing list, by 2019-05-13.
> 
>     I've not changed my mind on this. The flag seems unnecessary, and if anything, can cause confusion and problems. It seems to have been motivated by people wanting to see what it would be like to get all IPv4 users off the network, at an IETF meeting, and then people have been trying to make the case that it would be generically useful.
> 
>     There are other ways of sunsetting IPv4 if a network wants to, exactly the same as any number of older network protocols have been obsoleted, never needing any new explicit flag for the purpose. And I would way prefer for equipment vendors themselves, such as smartphone vendors, to create their own heuristics, if they feel that IPv4 is so wasteful of battery power. The onus should be on them, IMO, not on the IETF, and certainly not on other users of the network who might not know or pay attention to that flag.
> 
>     The KISS principle holds. Only add complications if it's essential.
> 
> 
> The two alternatives to this flag I've heard discussed are;
> 
> 1. Layer 2 filtering of Etherthypes 0x0800 and 0x0806
> 2. RFC2563 to signal host to not use Link-local IPv4
> 
> The problem is, these two options are incompatible with each other. You can either block IPv4 traffic or signal the host that not to use Link-local IPv4, you really can't do both at the same time.
> 
> I just had a thought, what if the host behavior for the flag was changed to be more like the behavior specified for RFC2563? 
> 
> In the presence of the flag, a host MAY attempt DHCPv4 a limited number of times, but MUST NOT perform Stateless Auto-Configuration of an IPv4 address and MUST NOT perform any service discovery (such as mDNS) unless it receives a unicast IPv4 address from DHCPv4 server or relay on the network.
> 
> This way a Rogue RA with this flag set is much less dangerous than a Rouge DHCPv4 server and doesn't directly impede IPv4 internet access. It would impede Link-local IPv4, but only if there is not a functioning DHCPv4 server or the attacker can also block the DHCPv4 process in addition to announcing a rogue RA with the flag set.
>  
> Would that be acceptable?
> 
> -- 
> ===============================================
> 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
> ===============================================
> 
> 
> -- 
> ===============================================
> 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
> --------------------------------------------------------------------
>