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

[David Farmer <[e-mail]>]

On Sat, May 11, 2019 at 2:21 AM Mikael Abrahamsson <[e-mail]> wrote:

> On Sat, 11 May 2019, Mark Smith wrote:
>
> > I think this is going backwards. We already prefer IPv6 over IPv4 by
> > default in terms of address selection and in happy eyeballs.
> >
> > IPv4 is the legacy protocol, delaying its startup until IPv6 has been
> > initialised is consistent with the IPv6 preference.
>
> Device manufacturers won't do it that way. My take on it is that they will
> do along the lines of what Apple did with their HE deployment. They'll
> start off no advantage for either protocol, gather data, then change to
> delay IPv4 slightly and then perhaps in 10-50 years if IPv6-only with
> IPv4aaS becomes the norm then just use IPv4 as fallback in case IPv6
> doesn't work properly.
>

Furthermore, in most cases, there is no advantage to delaying the IPv4
DHCPDISCOVERS. If an IPv6-Ony network really cares it should be filtering
the IPv4 packets. For the dual-stack host, it is a trade-off of a little
bit more power for a quick startup of IPv4 if it is there. A few more
packets when the host is already awake isn't going to matter that much to
its power draw. The issue for the host is the power draw over time for
continuing futile IPv4 service discovery and IPv4 DHCPDISCOVERS, especially
after it can be determined that they are futile.


> We should not mandate anything here about exact device behaviour, we
> should say "this is a signal from the network that the network
> administrator is indicating that this is an IPv6 only network". That's all
> it is, and now the device manufacturer can decide depending on their
> use-case what is the best way to respond to this signal for that
> particular device.
>

I don't think we should mandate anything either but we should provide some
suggested actions, maybe something like the following;

The lack of any IPv4 DHCPOFFERS in response to initial IPv4
DHCPDISCOVERS is considered the primary signal for a dual-stack host to not
configure a global scope unicast IPv4 address. The presence of only RAs
with this flag set is considered a secondary signal to fairly quickly stop
or severely limit through the aggressive use of exponential
backoff periodic IPv4 DHCPDISCOVERS and to take one of the
following suggested actions to prevent futile IPv4 service discovery
traffic. This non-exhaustive list is in order of preference, but the
particulars of the IPv4 stack implementation will dictate the best solution
for individual implementations. However, option #3 is NOT RECOMMENDED,
especially for general purpose hosts and mobile devices. However, this
could be an appropriate action by constrained devices.

1. Turn off IPv4 service discovery, such as mDNS [RFC6762].
2. Do not auto-configure an IPv4 Link-Local scope address [RFC3927].
3. Turn off the IPv4 stack altogether.

If a dual-stack host receives an RA with the flag cleared, or all the RAs
with the flag set have expired, periodic IPv4 DHCPDISCOVERS and IPv4
service discovery traffic SHOULD be resumed.

If a dual-stack host receives any IPv4 DHCPOFFERS a global scope unicast
IPv4 address SHOULD be configured regardless of the status of this flag.

While currently not recommended, due to today's prevalence of IPv4, a
dual-stack host MAY delay its initial IPv4 DHCPDISCOVERS until the status
of this flag is known. This could also be an appropriate action by
constrained devices.

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