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

[David Farmer <[e-mail]>]

Sorry I had a premature launch of my message. :(

On Thu, May 9, 2019 at 1:10 AM Mark Smith <[e-mail]> wrote:

> On Thu, 9 May 2019 at 07:56, David Farmer <[e-mail]> wrote:
> >
> >
>
> <snip>
>
> > The primary signal for a dual-stack host to not configure an IPv4
> address should be the failure to receive an IPv4 address from a DHCPv4
> Server [RFC2131].
>
>
> The primary goal is to reduce and ideally entirely eliminate
> link-layer broadcasts on the link caused by IPv4.
>
> DHCPDISCOVERS are link-layer broadcasts. Using any form of DHCPv4 to
> disable IPv4 is directly counter to the primary goal.
>

 As I see it, at least for the foreseeable future, we want dual-stack hosts
to perform equally well on dual-stack networks as on IPv6-Only networks. So
in my opinion, this means we don't want to completely eliminate
DHCPDISCOVERS, at least at the beginning of the attachment process. Maybe
someday in the future, IPv4 will become rare enough we can delay even these
initial DHCPDISCOVERS, but at this point, I don't think that is a wise move.

As I see it, we want a positive signal to dual-stack hosts that further
DHCPDISCOVERS, after the initial few, are futile and can be stopped fairly
quickly. But upon attachment to a network, at least for now, a dual-stack
host should assume it is more likely to be attaching to a dual-stack
network than to an IPv6-Only network. Therefore, it should send both an
IPv6 ROUTER SOLICITATION and an IPv4 DHCPDISCOVER at roughly the same time,
moments after the network attachment is stable.

On dual-stack networks, the host will receive a response to both of these
queries and configure both IPv4 and IPv6. However, on an IPv6-Only network,
the host will not receive any DHCPOFFERS in response to the DHCPDISCOVER,
but it will get a response to the IPv6 ROUTER SOLICITATION, one or more
ROUTER ADVERTISEMENTS, hopefully with this flag set. At this point, the
dual-stack host knows it SHOULD NOT auto-configured an IPv4 Link-Local
address [RFC3927]. But it doesn't know for sure that it won't get any
DHCPOFFERS, before the dual-stack host can know that for sure, it needs to
wait long enough to have received all possible ROUTER ADVERTISEMENTS and
make sure all ROUTER ADVERTISEMENTS have this flag set.

If the dual-stack host receives any DHCPOFFERS, it SHOULD accept one of
them regardless of the setting of the flag. Again the lack of DHCPOFFERS is
the primary signal, not this flag. Only after the dual-stack host has
received all ROUTER ADVERTISEMENTS and they all have this flag set is it
safe for a dual-stack host to assume it can cease sending DHCPDISCOVERS.
Further if at any time, a dual-stack host receives a ROUTER ADVERTISEMENT
with this flag cleared, it should continue sending DHCPDISCOVERS
periodically.

Making the lack of DHCPOFFERS the primary signal and this flag a secondary
signal mitigates almost all the risks associated with this flag. So, this
flag is not saying turn off IPv4, this flag is saying assume that the lack
of any DHCPOFFERS is an intentional act and don't auto-configured an IPv4
Link-Local address or perform any IPv4 service discovery with an IPv4
link-local address. Further, if you see only ROUTER ADVERTISEMENTS with
this flag set, you can fairly quickly stop sending DHCPDISCOVERS at all,
they are not going to get answered.

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