Re: [rtcweb] draft-ietf-rtcweb-transports-01 TURN/IPV6 RFC 6156.

["cb.list6" <[e-mail]>]

On Mon, Sep 9, 2013 at 10:01 AM, Bernard Aboba
<[e-mail]> wrote:
>> I would specifically state that much of the challenges with NATs are
>> resolved by preferring IPv6.
>
> [BA] That isn't what we've seen in practice, since IPv6 addresses
> (particularly tunnel addresses) may not be routable.
> So in practice, things seem to work better if IPv4 addresses are preferred
> and in fact, government profiles such as DISA UCR 2008 require the ability
> to configure an IPv4 preference.
>

Is there a citation for this data point about IPv6 not working as well
in production?  I see the DISA thing as not particularly relevant to
the Internet.  That's one way to run  a private network, with knobs to
adjust.

There used to be an issue with 6to4 and maybe Teredo, but i believe
the data shows that this issue has largely been resolved
http://www.google.com/intl/en/ipv6/statistics.html via host treatment
of those tunnels as well as happy-eyeballs in browsers.

I believe happy-eyeballs / RFC6555 would apply to WebRTC interactions
equally well, since the signalling is over the standard HTTP/HTTPS
calls.

Maybe RFC6555 needs to be mentioned in the transport draft as well
since it can be leveraged to mitigate the use of broken IPv6
connections.

CB


>> I would also cover the use case of using TURN to bridge IPv6-only
>> clients to communicate with IPv4 clients.
>
> [BA] Yes, this is an important use case (and one that some ICE
> implementations don't support very well).
>
>> It would also be wise to reference RFC6540 to underscore that IPv6 use
>> is a BCP of the IETF.