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

[Brian E Carpenter <[e-mail]>]

On 22/09/2017 19:22, Ole Troan 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.

How about Best Current Practice for the Worst Current Solution?

I have never advocated v4/v6 translation. I said it was a bad thing
before IPv6 was even designed: https://tools.ietf.org/html/rfc1671#page-3

But we're apparently stuck with it.

    Brian