Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-05.txt

[Simon Perreault <[e-mail]>]

Le 2015-09-16 11:08, Ari Keränen a écrit :
> 
>> On 14 Sep 2015, at 16:01, Simon Perreault <[e-mail]> wrote:
>>
>> Le 2015-09-13 08:11, Ari Keränen a écrit :
>>>> - Remove the reference to DNS64. It does not matter if DNS64 is used
>>>> or not.
>>>
>>> It's the DNS64 that would generate the NAT64'd address for you when you
>>> discover IPv4-only STUN/TURN server from DNS, right?
>>
>> Yes, that's one scenario that is likely to happen. But an ICE agent
>> could be provisioned with, or discover, STUN server addresses any other way.
> 
> True. Perhaps a sentence or two on this would be good. I'd keep the DNS64 as one way it can happen. (see below)

Yup.

>>>> Therefore, my proposal:
>>>>
>>>> If an agent is in a network that translates between IPv4 and IPv6
>>>> [RFC6145], it may gather server-reflexive candidates whose address
>>>> family will be different from that of the address used to talk to the
>>>> STUN server.  Such candidates are prioritized according to their own
>>>> address family, not the one used to gather them.
>>>>
>>>> For example, in a network that utilizes NAT64 [RFC6146], an IPv4
>>>> server-reflexive candidate will be gathered using IPv6 to talk to the
>>>> STUN server. That candidate will be prioritized like a regular IPv4
>>>> server-reflexive candidate.
>>>
>>> But only if the STUN server does not have IPv6 address / DNS record.
>>
>> No. Imagine a dual-stack STUN server. From the point of view of an agent
>> behind a NAT64, there are two IPv6 addresses that can be used to talk to
>> it: the plain IPv6 one and the one using NAT64. If the agent uses DNS64
>> then it will automatically use the plain IPv6 address. But the agent
>> could be provisioned with STUN server addresses any other way. If I just
>> go and hard-code the address that uses NAT64 into my agent, it still
>> needs to do the right thing.
> 
> To make that more clear I'd suggest we discuss the prefix discovery and other methods before, or right after, this paragraph. Something along the lines of:
> 
> The agent can learn server-reflexive NAT64 candidate from IPv4 STUN/TURN server discovered using DNS64 [RFC6147], by static configuration, (what else?).

I guess any discovery method from draft-ietf-tram-turn-server-discovery
could apply?

>> As a side note, some DNS64 servers always generate synthetic AAAA
>> records even when a AAAA record is already present. They do that for
>> various reasons, none of which would be considered "good" in an IETF
>> discussion. ;)
> 
> Huh. It's a scary world out there :)
> 
>>>> In order for the ICE agent to be able to use the resulting candidate it
>>>> will be necessary for it to know the address mapping parameters. When
>>>> such knowledge is not otherwise available to the agent, IPv6 prefix
>>>> discovery [RFC7050] SHOULD be attempted to discover the IPv6 prefix used
>>>> by NAT64.
>>>
>>> Is it always necessary to know the address mapping parameters? If the
>>> mapping is endpoint-independent, it should just work?
>>
>> The mapping I was referring to is the one between IPv6 addresses and
>> IPv4 addresses. This shows that my text needs to be even more explicit!
>>
>> Suggestion: "In order for the ICE agent to be able to use the resulting
>> candidate it will be necessary for it to know the parameters of the
>> mapping between IPv4 and IPv6 addresses (i.e, which IPv6 address
>> corresponds to a given IPv4 address, and vice-versa)."
> 
> That's more clear. Thanks! And agent could also generate new candidates on the fly from the prefix, right? Especially if it didn't have suitable STUN server. Should that be added to the list of mechanisms?

Hmmm, yes, I guess it could if the translation is stateless. Good catch!

Simon