Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

[Lorenzo Colitti <[e-mail]>]

On Thu, Dec 5, 2019 at 11:48 PM Roy Marples <[e-mail]> wrote:

> The *something* else is probably IPv6 but I don't see why this RFC
> should mention it other than a use case.
>

There is actually a reason why the option is specific to IPv6. Here's why.
The primary reason for the existence of option is that hosts (especially
moblie hosts) don't want to wait to find out what's available before they
make networking available to applications. This is why when they connect
they initiate IPv4 and IPv6 (and whatever else they have) in parallel. The
option as written conveys two important bits of information to the host:

   1. The network would prefer the host not use IPv4 if the host has
   something else available.
   2. Something else *is available* on this network, so the host is not
   going to wait forever for it.

In the current draft, "something else" is specifically IPv6 (because not
really any other credible alternative to IPv4) and more specifically, IPv6
with NAT64 (because there is no other IPv6 transition mechanism that is
widely implemented in hosts today - all the others are implemented in the
network).

I think you're saying that this option should mean "I'd prefer you not use
IPv4 except as a last resort" option, as opposed to "I'd prefer you use
IPv6 instead". What that means is that the option will only be providing #1
and not #2. I think it's worse that what we are currently proposing. The
reasons are:

   1. If we make this an "IPv4 as last resort" option, a client that gets
   the option is not being told if there is anything else available. So, say
   that the administrator sets this option because they want hosts to prefer
   IPX (or netbeui, or appletalk, or whatever) over IPv4. What if the host
   doesn't support/use any of those protocols, but only supports IPv6, which
   is the overwhelmingly common case today? The host doesn't really have a
   clear path forward. The only thing it can do is try IPv6 "for a while", and
   then go back to DHCPREQUEST (assuming the offer is still valid, and if not
   go back to DHCPDISCOVER), and use IPv4 anyway. That seems like a bad user
   experience.
   2. If we make this an "IPv4 as a last resort option" instead of a
   "please use IPv6" option, is that hosts will simply assume that the option
   means "please use IPv6". Even though this assumption is technically
   incorrect, if enough hosts do it, from a deployment perspective it won't
   matter, because network operators won't be able to use this option code for
   anything other than IPv6-only networks. That outcome is worse than if we
   had explicitly defined this as a "please use IPv6" option, because
   well-behaved hosts will have to incur the additional complexity to build
   the technically correct implementation that can never be used in practice.

If we really don't want to make this option specific to IPv6, then we can
define an option that can convey multiple alternatives. In other words, the
option would mean "please don't use IPv4 if you support any of the
alternative protocols listed in this option". We could initially define an
alternative code only for "IPv6-only with NAT64", but if later some other
protocol comes along, or some other IPv6 transition mechanism becomes
widely deployed on hosts, we could add a code for it. Personally I don't
think this is worth the engineering complexity because I don't see any
other credible alternative than IPv6-only with NAT64, but I would much
prefer it over an option that doesn't say anything at all about what else
is available.