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.
Huh? NAT64 can involves no host changes at all (other than not having IPv4 to
succeed in network attachment, and as Lorenzo said, IPv4 literals in some ancient protocols).
> What if some of your hosts are doing native IPv4 and some NAT64, that makes
> troubleshooting even worse.
Yes, what if.
You'll know which hosts are doing native IPv4 (native, to me, btw, means
public IPv4. I think you mean NAT44. Some hosts do NAT44 and some do NAT64 to
reach IPv4 addresses)
But, hosts that support being IPv6-only will set the flag, and older hosts
will not. So over time, all the hosts are IPv6-only.
The alternative is that lots of hosts are dual-stack.
> 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?
Mostly, "hosts" do not implement NAT64, they run IPv6 and avoid IPv4.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
