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

From: [email-masked]
Date: Thu, 10 Sep 2015 15:50:05 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
        Authors         : Ari Keranen
                          Jonathan Rosenberg
	Filename        : draft-ietf-mmusic-rfc5245bis-05.txt
	Pages           : 91
	Date            : 2015-09-10

Abstract:
   This document describes a protocol for Network Address Translator
   (NAT) traversal for UDP-based multimedia.  This protocol is called
   Interactive Connectivity Establishment (ICE).  ICE makes use of the
   Session Traversal Utilities for NAT (STUN) protocol and its
   extension, Traversal Using Relay NAT (TURN).

   This document obsoletes RFC 5245.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc5245bis-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ari Keränen <[email-masked]>
Date: Fri, 11 Sep 2015 02:00:08 +0300

This update includes recommendations about NAT64 server reflexive 
candidates as discussed in the Prague meeting and at the list during the 
meeting. Also the abstract and intro are now less focused on 
offer/answer (thanks for the text contribution Suhas).

Going forward, we may want to consider updating the offer/answer text 
also in other parts of the document. Pål-Erik started a thread earlier 
on the topic (see "Re: [MMUSIC] ICE offer/answer terminology"). If you 
have opinions, please let us know.

Thanks,
Ari

On 11/09/15 01:50, [email-masked] wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 11 Sep 2015 09:14:42 -0400

Le 2015-09-10 19:00, Ari Keränen a écrit :
> 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

---

From: Ari Keränen <[email-masked]>
Date: Sun, 13 Sep 2015 15:11:06 +0300

>>   	   like IPv4 server reflexive candidates.

Thanks Simon! Comments inline.

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

> doesn't matter if the translation is stateful or not.

Good point.

> simple fact that the address families are different.

Makes sense.

> is already possible to gather an IPvX relayed candidate using IPvY to

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

> server-reflexive candidate.

But only if the STUN server does not have IPv6 address / DNS record.

> discovery [RFC7050] SHOULD be attempted to discover the IPv6 prefix used

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Sep 2015 09:01:00 -0400

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

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

> 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

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

---

From: Ari Keränen <[email-masked]>
Date: Wed, 16 Sep 2015 15:08:07 +0000

> On 14 Sep 2015, at 16:01, Simon Perreault <[email-masked]> wrote:
> 

True. Perhaps a sentence or two on this would be good. I'd keep the DNS64 as one way it can happen. (see below)

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

> various reasons, none of which would be considered "good" in an IETF

Huh. It's a scary world out there :)

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

Cheers,
Ari

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Sep 2015 11:16:37 -0400

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

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

> 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 mec…

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

Simon

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 16 Sep 2015 15:18:56 +0000

> On Sep 16, 2015, at 11:08 AM, Ari Keränen <[email-masked]> wrote:
>> 

The prefix doesn’t let the agent generate new local candidates — it provides a way to send from local IPv6 candidates to remote IPv4 candidates.  It needs the prefix to do this whether or not it has a STUN server. (Having a STUN server just gives a hint as to whether or not it’s worthwhile to try to do this.)