|
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 <lorenzo@xxxxxxxxxx>
On Wed, Jun 24, 2020 at 1:36 AM Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> wrote:
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. |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
