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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Mar 2009 13:02:34 +1300

Remi,

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.

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.

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.

> 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.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Mar 2009 16:42:52 +1300

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:
> 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:
> 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.
> 
> 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.
> 
> 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 ;)
>

---

From: Dave Thaler <[email-masked]>
Date: Sun, 22 Mar 2009 11:12:56 -0700

I just read this draft and have the same view as Brian.
The current behavior is by design.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian E Carpenter
> Sent: Friday, March 13, 2009 5:03 PM
> To: [email-masked]
> Cc: IPv6 Operations
> Subject: Re: I-D Action:draft-denis-v6ops-nat-addrsel-00.txt
>
> Remi,
>