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

[Tim Chown <[e-mail]>]

> On 22 Sep 2017, at 08:22, Ole Troan <[e-mail]> wrote:
> 
>>> 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.

I like that.  We could tag quite a few RFCs/protocols as WCP.  Starting with IPv4.

Tim