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

[David Farmer <[e-mail]>]

On Fri, May 10, 2019 at 7:56 AM Sander Steffann <[e-mail]> wrote:

> Hi Bjoern,
>
> > It also says:
> >
> >   A host MAY delay all IPv4 operations at start-up or reconnection
> >   until a reasonable time has elapsed for RA messages to arrive.  If
> >   all RAs received have the flag set to 1, a host SHOULD NOT attempt
> >   IPv4 operations.
>
> And that last bit is exactly where the problem is: it is too strong.
> Something like "If all RAs received have the flag set to 1, a host SHOULD
> NOT aggressively retry any failed IPv4 operations (like obtaining a DHCP
> lease) and operate without using IPv4 as much as possible to reduce
> unwanted/unnecessary IPv4 traffic on the network. Especially operations
> that transmit broadcast packets should be avoided to save the battery life
> of other devices on the network."
>
> So, as has been suggested before: turn it from an off-flag to a useful
> heuristic. I will remain strongly opposed to a hard off-flag for the
> reasons explained previously. I still think Bert is right: "Not necessary,
> not sufficient, therefore, IMO, not needed." so I'll probably never be a
> supporter of this draft, but if we are talking about a heuristic then I can
> at least reevaluate my objections to see if we can reach consensus.
>

I have to agree that a "hard off" for IPv4, especially global scope unicast
IPv4 is not necessary, it is not the problem. If a dual-stack host doesn't
get an IPv4 DHCPOFFER, it won't do global scope unicast IPv4. The primary
problem described in the problem statement is RFC 3927 and futile IPv4
service discovery using Link-Local IPv4 addresses. I am suggesting we
change the flag to be a "hard off" only for RFC 3927, and then its a
heuristic hint to fairly quickly stop, or at least severely limit, periodic
IPv4 DHCPDISCOVERS, or a "soft off" for global scope unicast IPv4.

Furthermore, at least in the near-term, I don't believe IPv6-Only networks
are going to be very common. Therefore, I don't think delaying the initial
IPv4 DHCPDISCOVERS until the IPv6 RAs can be analyzed is a good tactic.
While I think it should be permitted, I don't think it should be
encouraged, at least until IPv6-Only networks become the dominant solution
and dual-stack or IPv4-Only networks are rare. Which is by no means the
case today. Today, delaying initial IPv4 DHCPDISCOVERS is bad advice.

Thanks
-- 
===============================================
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
===============================================