On Wed, Jun 24, 2020 at 2:07 AM Philip Homburg <pch-ietf-7@xxxxxxxxxxxxxx> 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.
Another way to look at it:
I consider NAT64-to-hosts a really bad idea. Implementing 464xlat in a CPE
or other router is not that bad, but making sure that every host in your
network can properly support NAT64 or 464xlat is not something you should
want.
What if some of your hosts are doing native IPv4 and some NAT64, that makes
troubleshooting even worse.
I think these arguments apply to any host-based transition technology, and any network that mixes IPv4-capable and IPv6-only devices. So in that sense, it doesn't seem to argue either for or against supporting multiple transition mechanisms in this option.
In the unlikely case we get there, we can probably allocate a new option.
Right.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
