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

[Philip Homburg <[e-mail]>]

>    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.

NAT64 looks good from a network management point of view because a large part
of your network can unaware of IPv4. However, with this option all of your 
network needs to provide native IPv4 and you need to deal with NAT64 as well.

In the far future, it is possible that networks will stop supporting IPv4
and that some hosts connect to a IPv4 service somewhere in the internet.

So, it is likely that any other protocol would go the same route? Is there
a benefit for hosts that do not implement NAT64 to set this option?

In the unlikely case we get there, we can probably allocate a new option.