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

[Ole Troan <[e-mail]>]

>> We have a problem in that people confuse "a standard" with "the standard"
>> and
>> "a best current practice" with "the best current prcatice". But in the
>> end that's
>> just a matter of wording in the Abstract and Introduction. We say: if you
>> want
>> to run a pure IPv6 network service while supporting IPv4-only clients and
>> servers,
>> and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good
>> way to do it.
> 
> 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.
> 
> 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.

From the perspective of forcing every IPv6 application to have to be able to deal with connecting to an IPv4 endpoint.
Breaking DNSSEC.
Requiring stateful devices in the network.

I would suggest this belongs in the newly invented document category: WCP - Worst Current Practice.

Ole