Re: I-D Action:draft-denis-v6ops-nat-addrsel-00.txt

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Cutting to the chase:

> What I'm seeing on the systems that do _not_ do this (mostly Linux and BSD), 
> is that users are learning to disable IPv6 altogether.
> 
> Somehow I do not think that is what IETF wanted.

No. But neither do we want to prevent use of v6 auto-tunnelled solutions
when they work more or less as well as v4 NAT. So we should recommend
a configurable switch for this (prefer auto-tunnel vs prefer NAT)
rather than a solid preference.

   Brian

On 2009-03-16 21:37, Rémi Denis-Courmont wrote:
> On Saturday 14 March 2009 02:02:34 ext Brian E Carpenter wrote:
>> I am not sure about this statement in your draft:
>>>    Thus, the transitional (IPv6) address will be used instead of the
>>>    native (IPv4) address, even though that should have been avoided.
>> As I recall, the intention was always that IPv6 should be preferred
>> to IPv4, when both are available. The statement you quote earlier
>>
>>>    [RFC3484] states that "the use of transitional addresses when native
>>>    addresses are available [should be avoided]".
>> was in my memory intended to refer to IPv6 versus IPv6, and not to
>> IPv6 versus IPv4.
>>
>> On that view, the current behaviour is not a mistake. The mistake may
>> be elsewhere: a black hole in the transitional IPv6 connectivity.
> 
> One might argue that 6to4-6to4 and Teredo-Teredo is better than NAT'ed IPv4. 
> But going through one relay: 6to4-native, Teredo-native, or worse, two relays: 
> 6to4-Teredo, is always going to -for lack of a better word- "suck".
> 
>> You suggest:
>>>    Several operating system vendors appear to work around this issue by
>>>    assigning a global scope to IPv4 address.  Thus, rule 2 is no longer
>>>    discriminating against the IPv4 address pair.
>> True, but that is against the intention of discriminating in favour
>> of IPv6. So while some vendors may have chosen this approach, it isn't
>> what we wanted.
> 
> What I'm seeing on the systems that do _not_ do this (mostly Linux and BSD), 
> is that users are learning to disable IPv6 altogether.
> 
> Somehow I do not think that is what IETF wanted.
> 
>> I don't see why we'd fix an operational problem of black holes
>> by discriminating in favour of IPv4 NAT. That would just serve to
>> reduce the incentive to fix the black holes.
> 
> Those black holes are an unavoidable problem with relays. By design, relays 
> are going to suffer from bandwidth constraints, and be less reliable that 
> either native IPv4 or native IPv6, since they depend on both of them.
> 
> The only advantage of using relayed IPv6 connectivity lies in not being 
> NAT'ed. There are applications that do suffer from NAT'ing. There it makes 
> sense to favor IPv6. As it happens, RFC3484 is typically _not_ used by those 
> apps. Those apps mostly cannot use getaddrinfo() - their protocols convey list 
> of addresses directly (look at ICE for instance).
> 
> Applications that do use RFC3484 -those that typically use DNS- seldom care 
> about being NAT'ed. But, sure, some do (e.g. active FTP). That's why I was 
> suggesting a new source address selection flag in section 5.2 of the draft.
> 
>>> 6.  IPv6 Address Translation
>>>
>>>    The implications of IPv6 Address Translation and protocol translation
>>>    are left beyond the scope of this document.  However, it can only be
>>>    recommended that RFC3484 be taken into account when designing such
>>>    translation systems.
>> Since ULAs are defined to have global scope, I think there will
>> be no problem.
> 
> If ULA are chosen, then I agree there should be no _such_ problem. I wouldn't 
> bet my hand that there would be no problems - at all - though ;)
>