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

[Michael Richardson <[e-mail]>]

Philip Homburg <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-