Re: [Iot-directorate] Iotdir last call review of draft-ietf-dhc-v6only-03

[Lorenzo Colitti <[e-mail]>]

On Wed, Jun 24, 2020 at 1:36 AM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Now, if you have an escape strategy for that day like this other option
> and you can prove there’s no place for backward compatibility problem at
> that time, then fine with me. Also fine with me is if that draft is only
> for NAT64, in which case you could even have NAT64 in the name of the
> option to make things clearer.
>

I think the escape strategy here is to define a new DHCPv4 option, yes.

As for putting NAT64 in the name of the option, I'm not sure that's
particularly useful. The only case in which this would make a difference is
if a new transition technology becomes widely deployed - otherwise it
doesn't matter what the name is. If the new technology is mostly
transparent to hosts just like NAT64 is, then we would want to continue to
use the same option. If we put NAT64 in the name of the option we might not
be able to do that easily. So that argues against making the option more
"NAT64 specific" than it already is.

I think the only case for making the option more "NAT64 specific" is if a
new transition technology becomes widely deployed which is *not*
transparent to hosts (i.e., it requires hosts to do work to support IPv4),
and the technology is successful enough (and enough time has passed) that
all hosts of interest support that option, and no longer support NAT64. In
that case, the option currently being defined in this draft would no longer
be useful.

Like I said, this all seems pretty unlikely to me. In particular it seems
unlikely that a transition technology would become widely deployed if it
requires hosts to do work - there doesn't seem to be much of an incentive
for that to happen given that NAT64 is widely deployed (and thus
deployable) and requires zero work for hosts. Additionally, as IPv6-only
networks become more deployed and IPv4-only apps age out, the incentive to
do that work reduces, and it seems likely that any new transition
technology that is defined will be transparent to hosts because things like
IPv4 literals and IPv6-only apps are a thing of the past.

Further, any new technology that we expect to be used on hosts will need to
consider the impact on legacy NAT64-capable hosts, and there will be an
incentive to make those hosts work. So at that time, we might find a better
migration strategy than to define a new option and we can update this
document with the result.

>