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

[Mark Smith <[e-mail]>]

On Fri, 10 May 2019 at 01:22, David Farmer <[e-mail]> wrote:
>
> 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.
>

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.


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