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

[David Farmer <[e-mail]>]

On Fri, May 10, 2019 at 8:47 AM David Farmer <[e-mail]> wrote:

>
> 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.
>

I just had an additional thought, should there be any effect on a
statically configured global scope unicast IPv4 address on a host in the
presence of this flag?

This question got me thinking, the problem isn't really having an address
configured on the IPv4 stack or even having the IPv4 stack turned on, the
problem on the wire is IPv4 service discovery and too persistently sending
out periodic IPv4 DHCPDISCOVERS.

So really the effect we needed is not necessarily a "hard off" for the IPv4
stack or even RFC 3927. If the IPv4 stack has an address on it, statically
configured or from RFC 3927, who cares. It is the generation of futile IPv4
service discovery traffic using that address and overly persistently
periodic IPv4 DHCPDISCOVERS that is the issue for local battery and
possibly WiFi airtime.

Therefore, maybe what should be specified is a "hard off" for IPv4 service
discovery in the presence of the flag and limiting IPv4 DHCPDISCOVERS. Then
note depending on the details of the IPv4 stack implementation the
necessary effects can be achieved in several ways;

1. Turn off IPv4 service discovery and limit IPv4 DHCPDISCOVERS.
2. Do not configure an RFC 3927 address, if no IPv4 DHCPOFFER is received
and limit IPv4 DHCPDISCOVERS.
3. Turn off the IPv4 stack altogether.

Noting that the list is in order of preference, but the particulars of the
IPv4 stack implementation will dictate the best solution in each
implementation. Further, option #3 is NOT RECOMMENDED for especially for
general purpose hosts.

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