Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence

[Alexandre Petrescu <[e-mail]>]

Le 23/09/2017 à 00:50, Brian E Carpenter a écrit :
> 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

Maybe RFC1671 page 3 bullet "C" is a BCP.

> But we're apparently stuck with it [tunn/translate/DNS transitioning
> mechanisms].

Yet a common denominator among Current Practices of transitioninig is:
double stack.

A smartphone runs ok native IPv4 and native IPv6 simultaneously, without
needing translations nor encapsulations nor DNS v6-v4 mappings.

Is double stack BCP?

A few RFCs mentioning "dual stack" seem to be on StdsTrack (not BCP).
They seem all to involve some tunnelling or translation.

But double stack, understood as coexisting simultaneous use of IPv4 and
IPv6 independently, on the same Computer, without tunnelling, nor
translation, nor DNSv46 - could very well be a BCP.

Alex