|
Sure it would, Lorenzo.
As you point out, NAT64 is a wide enough scope to justify the introduction of option. So if you drink from that cup, we’re all set.
My initial suggestion was along those lines, naming the option based on its scope of applicability, the scope being a network that does NAT64. The alternative to define transparent etc… was in the case you wished to allow the option in a context that is not NAT64 and not known by a legacy stack that uses the option.
In that case you effectively enter the complex game of describing what works and what works not and limit the DHCP server sending the option in the what works case. I agree that’s more complex than useful for the foreseeable future. I figured you wanted that
at some point when you and Michael reacted against placing NAT64 in the name of the option.
Take care, Pascal From: Lorenzo Colitti <lorenzo@xxxxxxxxxx>
So, to come back to the original reason for this thread: after thinking about Pascal's suggestion, I'm not sure that we can come up with a definition of "transparent" that we
can confidently state will match as-yet-undefined transition mechanisms for which this option would be appropriate. The first part of Pascal's definition ("accessing IPv4 services via a fully transparent mapping system such as NAT64") seems easy to understand/define. But the implementation
of the second part ("translating or tunneling IPv4 traffic to traverse the v6-only network such as 464XLAT") is, if you think about it, actually very specific to NAT64 and 464xlat. If we introduce a new 4underover6 transition mechanism that is transparent,
but is not compatible with implementations that do IPv4 using 464xlat, then is the option appropriate or not? I don't think it's easy to make that determination today because we don't know how 4underover6 works. But when we do define 4overunder6, and know
how it works, it will be easy to decide whether this option is appropriate. And in fact, 4underover6 might even be intentionally designed to work well with this option. At that time, it will be easy to update this RFC saying whether networks that use 4underover6
can use the option and under which circumstances. So I think I would still prefer to leave this option as being NAT64-specific. And I really don't think there's much of a downside, because, well... YAGNI. I really don't see another
transition technology becoming widely deployed at this point, given that NAT64 is already basically free for hosts to implement. We could update the document to say that NAT64 is widely deployed, and at the present time, the wide deployment in hosts of a new transition technology seems very unlikely given
that on IPv6-only networks IPv4 is a legacy service, and given that NAT64 already provides good compatibility with little to no implementation required on the host. We could say that if this is not the case, then a new DHCP option may need to be defined for
that new transition mechanism, unless that new transition mechanism is such that legacy hosts that only implement NAT64 and 464xlat can use it.
On Wed, Jun 24, 2020 at 4:57 PM Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> wrote:
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
