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

[Simon Perreault <[e-mail]>]

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.

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

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

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

> If you don't have IPv4-only STUN/TURN server, then you need the prefix
> discovery, right?

The kinds of addresses with which the server is provisioned is of no
consequence. What matters is the address that the agent ends up using to
talk to it. And we can't presume that the mere presence of a DNS64
implies that the agent will adopt DNS64-like behaviour.

Simon