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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Lorenzo and Michael;

I tried to digest that in my other mail to Jen; I’d be perfectly happy if the escape strategy is to define the properties of the transition mechanisms that are compatible with the option and if there’s text that tells the server not to place the option if the mechanisms in place are not compatible, see my other message.

What’s to answer is that all the below makes sense to me, and I’ll trust you on likelihood. If a condensate of that could find a way to the section 4, that would probably make the rest of the way through IESG smoother for the document.

Take care,

Pascal


From: Lorenzo Colitti <[e-mail]>
Sent: mercredi 24 juin 2020 03:43
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Iotdir last call review of draft-ietf-dhc-v6only-03

On Wed, Jun 24, 2020 at 1:36 AM Pascal Thubert (pthubert) <[e-mail]<mailto:[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.