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

[Ari Keränen <[e-mail]>]

On 11/09/15 16:14, Simon Perreault wrote:
> Le 2015-09-10 19:00, Ari Keränen a écrit :
>> This update includes recommendations about NAT64 server reflexive
>> candidates as discussed in the Prague meeting and at the list during the
>> meeting.
>
> The new text is:
>
>>   	   If an IPv6-only agent is in a network that utilizes NAT64 [RFC6146]	
>>   	   and DNS64 [RFC6147] technologies, it may gather also IPv4 server	
>>   	   reflexive and/or relayed candidates from IPv4-only STUN or TURN	
>>   	   servers.  IPv6-only agents SHOULD also utilize IPv6 prefix discovery	
>>   	   [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and	
>>   	   generate server reflexive candidates for each IPv6-only interface	
>>   	   accordingly.  The NAT64 server reflexive candidates are prioritized	
>>   	   like IPv4 server reflexive candidates.
>
> Some feedback:

Thanks Simon! Comments inline.

> - Remove the "IPv6-only" qualifier (two instances). A dual-stack agent
> in a network that utilizes NAT64 would need to adopt the same behavior.
> Therefore the kind of agent is irrelevant.
>
> - 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?

> - The NAT64 reference that you need is RFC6145. That is the part that
> deals with IPv4/IPv6 translation. RFC6145 is stateless and RFC6146
> augments it with statefulness. From the ICE agent's point of view, it
> doesn't matter if the translation is stateful or not.

Good point.

> - Theoretically it doesn't matter if the translation is IPv4-to-IPv6 or
> IPv6-to-IPv4. That is, the server could be IPv6-only while the agent
> could be IPv4-only. So I would reword so that the emphasis is on the
> simple fact that the address families are different.

Makes sense.

> - Relayed candidates are not concerned with NAT64. Even without NAT64 it
> is already possible to gather an IPvX relayed candidate using IPvY to
> talk to the server.

True. Which reminds me that we should add RFC6156 (TURN extension for 
IPV6) reference to ICE-bis.

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

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

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


Cheers,
Ari