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

[David Farmer <[e-mail]>]

Whoops, I lost the list somehow.

---------- Forwarded message ---------
From: David Farmer <[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]>




On Tue, May 7, 2019 at 4:26 PM Manfredi (US), Albert E <
[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]
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]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================