Re: [v6ops] reclassify 464XLAT as standard instead of info

[Erik Kline <[e-mail]>]

> I'd argue it is a "way to do it".  Good is not a adjective I'd apply
> to it as it has lots of side effects that impact others that are
> NOT using it the same way as NAT impacts every developer that uses
> IPv4.
>
> Because 464XLAT is almost always deployed with DNS64 (there are
> potentially other ways to learn the address mappings):
>
> YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING
> TERMINATED ON A IPV6 NODE.  This restricts what you can do with
> that connection.  This impacts on EVERY developer.

This is a good point.  Apps that connect to an IPv4-only destination
via DNS64/NAT64 won't know that they cannot, for example, pass an IPv6
address as a useful reference/token.  If they could discover/be told
the DNS64 prefix then app could figure this out for themselves, but
that is indeed unwanted complexity.

Note that with 464xlat/clat in theory this problem could be avoided in
the case where IPv4 literals are used (without a getaddrinfo trick
that returns AAAAs for IPv4 literals, of course ;-).  Nevertheless,
this isn't all that helpful.

> DNS64/NAT64 and 464XLAT needs to die and the earth needs to be
> salted where they are buried.  They are not like NAT44 where there
> no other viable alternative.  There are plenty of alternatives.

We'll see if folks (specifically mobile operators--the bulk of
NAT64/DNS64 deployment) deploy DS-Lite or MAP-E...