Subject: RE: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Dec 2005 13:38:42 -0800 (PST)

>From my own selfish point of view, I prefer 1.

This stuff is already complex enough. I believe 1 makes it simpler. 2
and 3 
makes it more complex.

I'm putting a higher premium on simplicity than backward compatibility
which
a draft (TURN is not an RFC: in fact, it wasn't even a working group
draft).

Cheers.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jonathan Rosenberg
> Sent: Monday, December 05, 2005 07:57
> To: Behave
> Subject: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification
> 
> 
> As I mentioned during the IETF meeting, I am working on a revision of 
> STUN that structures the protocol into a "framework" layer (though we 
> agreed not to call it that per se), and various "usages" that 
> can define 
> extensions, define what messages and attributes get used, and define 
> various security considerations. The plan is for TURN to 
> become a STUn 
> usage rather than a separate protocol. I think this is a good thing, 
> since TURN repeats a lot of stun, and its relationship with 
> it is unclear.
> 
> One of the things I mentioned as a side benefit of this 
> unification is 
> that the TURN Allocate request could perform a stun check as a side 
> effect. The Allocate response can include the source IP/port of the 
> Allocate request (equivalent to the MAPPED-ADDRESS in the 
> STUn Binding 
> Response). This way, an ICE endpoint, for example, can issue just a 
> single Allocate request to a turn server, and get back its 
> stun-derived 
> AND turn-derived addresses in one operation. This will reduce the 
> overhead of ICE and simplify things. There seemed to be good 
> support for 
> doing this when I proposed it in the meeting last month.
> 
> So, whats the issue? Syntax, unfortunately.
> 
> The IDEAL solution for doing this is that the MAPPED-ADDRESS 
> attribute 
> always indicate the source IP/port as seen by the server in 
> the request, 
> and that it be usable with the existing STUN Binding Response and the 
> TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, 
> and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the 
> address allocated by the TURN server itself.
> 
> So, there are several options:
> 
> 1. break backwards compatibility with TURN, and define 
> MAPPED-ADDRESS to 
>   be the source IP/port of the request. Define a new attribute, say 
> RELAY-ADDRESS, that contains the allocated address on the 
> TURN server, 
> and use that in the Allocate response.
> 
> 2. retain backwards compatibility with TURN, and define a new 
> attribute, 
> ALLOC-SOURCE-ADDR, which indicates the source IP/port of the Allocate 
> request. Thus, we'd have two attributes with the same definition, and 
> you'd need to use one of them with one request type 
> (MAPPED-ADDRESS with 
> Binding Request) and the other with the other request type 
> (ALLOC-SOURCE-ADDR with Allocate Request).
> 
> 3. Do (1), but only if the client indicates it supports this 
> capability. 
> If not, MAPPED-ADDRESS retains its current meaning and there 
> is no way 
> to get the source IP/port from the Allocate request.
> 
> 
> 
> Technically speaking, in a greenfield environment, #1 is clearly the 
> right solution. The problem is, there are now several deployments of 
> TURN, some of them large in fact, and I want to be sensitive to 
> backwards compatibility issues.
> 
> So, I'd like to hear from folks on this, especially ones with 
> implementations or deployments.
> 
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Jason Fischl <[email-masked]>
Date: Mon, 5 Dec 2005 18:01:12 -0800 (PST)

> a draft (TURN is not an RFC: in fact, it wasn't even a working group

I agree with option 1.

---

From: Diego B <[email-masked]>
Date: Mon, 5 Dec 2005 23:23:45 -0800 (PST)

I vote for 1;
We also have some large deployments using the old drafts, but if
you really wants to turn STUn into a framework and
TURN to be an application of that framework, I think is better
"breaking" backwards compatibility now that TURN is still in draft
and putting a strong requirements on future extencions ( or applications )
than let other applications to redefine agaian the "base" attributes.
Regards
Diego B
-----Original Message-----

Thanks,
Jonathan R.

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave