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

[Simon Perreault <[e-mail]>]

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:

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

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

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

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

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.

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.

Simon