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

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

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