One document matched: draft-martinsen-tram-ssoda-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml">
<!ENTITY rfc6156 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6156.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<?rfc needLines="yes" ?>
<rfc category="std" docName="draft-martinsen-tram-ssoda-01" ipr="trust200902">
<front>
<title abbrev="SSODA">Single SOcket Dual Allocation with TURN</title>
<author fullname="Paal-Erik Martinsen" initials="P.E" surname="Martinsen">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Philip Pedersens vei 20</street>
<city>Lysaker</city>
<region>Akershus</region>
<code>1366</code>
<country>Norway</country>
</postal>
<email>palmarti@cisco.com</email>
</address>
</author>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization>Google</organization>
<address>
<postal>
<street></street>
<city>Kirkland</city>
<region>WA</region>
<code></code>
<country>USA</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<author fullname="Oleg Moskalenko" initials="O."
surname="Moskalenko">
<organization>Unaffiliated</organization>
<address>
<postal>
<street></street>
<city>Walnut Creek</city>
<region>CA</region>
<code></code>
<country>USA</country>
</postal>
<email>mom040267@gmail.com</email>
<uri>https://code.google.com/p/coturn/</uri>
</address>
</author>
<date/>
<workgroup>TRAM</workgroup>
<abstract>
<t>
This draft describes a simple method for allocating one IPv4
and one IPv6 relay address from a single ALLOCATE request to
the TURN server. This saves local ports on the client, reduces
the number of candidates gathered by the client, and reduces
the number of messages sent between the client and the TURN
server.
</t>
</abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
The main motivation for this draft is to reduce the number of
local ports on the client, reduce the number of candidates
gathered during the discovery process, and reduce the number
of messages that need to be exchanged to allocate the relay
addresses needed for ICE.
</t>
<t>
Reducing the number of local ports is important as it saves
resources at three places in the network. First, the number of
open ports on the client is reduced, leading to fewer host
candidates. Secondly, with fewer local host ports there will
be fewer NAT bindings for the NAT to keep track of, and fewer
server reflexive candidates. Lastly, with a single 5-tuple in
use, it reduces the number of open ports the TURN server needs
to open on the interface towards the client (Private side). As
ports are a scarce resource (16-bit number) preserving them on
the NAT and a the TURN server can make large scale deployments
easier.
</t>
</section>
<section title="Creating an Allocation">
<t>
The behavior specified here affects the processing defined in
Section 6 of <xref target="RFC5766" /> and Section 4 of <xref
target="RFC6156" />.
</t>
<section title="Sending an Allocate Request" anchor="create_allocation">
<t>
A client that wishes to obtain one IPv6 and one IPv4 by
sending one Allocate request MUST include two
REQUESTED-ADDRESS-FAMILY attributes, one for each address
family, in the Allocate request that it sends to the TURN
server. The order of the REQUESTED-ADDRESS-FAMILY is
arbitrary, because the server either understands SSODA (then
the order does not matter) or the server does not understand
SSODA (then the server behavior is undefined - it may return
a 400 error, or it may take the first attribute, or it may
take the last attribute). Multiple candidates of the same
family are not supported; the client MUST NOT include more
than one REQUESTED-ADDRESS-FAMILY attribute for a given
address family. The mechanism to formulate an Allocate
request is described in Section 6.1 of <xref
target="RFC5766" />.
</t>
<t>
The SSODA mechanism is not available when using the odd/
even port allocation scheme. Clients MUST NOT include a
REQUESTED-ADDRESS-FAMILY attribute in an Allocate request
that contains a RESERVATION-TOKEN attribute. Clients MUST
NOT include a second REQUESTED-ADDRESS-FAMILY attribute in
an Allocate request that contains an EVEN-PORT attribute.
</t>
</section>
<section title="Receiving an Allocate Request">
<t>
Once a server has verified that the request is authenticated
and has not been tampered with, the TURN server processes
the Allocate request following the rules in <xref
target="RFC5766" /> and <xref target="RFC6156"/>.. Only one
REQUESTED-ADDRESS-FAMILY attribute with the same family
value is allowed in the request. If two attributes with the
same family value exist the server MUST return 400 Bad
Request error.
</t>
<t>
If no REQUESTED-ADDRESS-FAMILY attributes are present, the
server MUST treat this as if the request contained a single
REQUESTED-ADDRESS-FAMILY specifying the IPv4 address family.
</t>
<t>
If the server can successfully process the request, it
allocates a relay address for each of the
REQUESTED-ADDRESS-FAMILY attributes present in the Allocate
request. The allocated relay addresses are returned in
separate XOR-RELAYED-ADDRESS attributes in the Allocate
response message. The ordering of the XOR-RELAYED-ADDRESS
attributes in the response is arbitrary.
</t>
<t>
If the server cannot satisfy the request at all, because
none of the specified address families are supported, the
server MUST return a 440 error code, as indicated in <xref
target="RFC6156"/>.
</t>
<t>
If the server cannot satisfy the request at all, because the
server could not allocate any of the specified addresses,
the server MUST return a 508 (Insufficient Capacity) error
code as indicated in <xref target="RFC5766"/>.
</t>
<t>
If some of the requested address could be allocated, but
some could not, either because the requested address family
is not supported, or the server currently lacks capacity,
the server MUST indicate this partial success by returning
an Allocate Success Response that contains
XOR-RELAYED-ADDRESS attributes for the addresses that were
successfully allocated, as well as XOR-RELAYED-ADDRESS with
ANY addresses (that is, IPv4 address 0.0.0.0:0 or IPv6
address [::0]:0) corresponding to the address families that
could not be allocated. This will notify the client that the
desired REQUESTED-ADDRESS-FAMILY was understood, but could
not be allocated. A success response with ANY addresses MUST
NOT be returned if all allocation requests cannot be
satisfied; instead, an error response should be returned, as
indicated above.
</t>
<t>
This somewhat unusual pattern of partial success is used to
avoid the need for an additional round-trip when the client
just wants whatever address families the TURN server
supports.
</t>
<t>
Note that while allocating multiple address families at the
same time is supported, doing this sequentially is not. The
server MUST reject any attempt to "add" an address family to
an existing allocation with a 437 (Allocation Mismatch)
error code.
</t>
<t>
[OPEN ISSUE 1: do we need to include
REQUESTED-ADDRESS-FAMILY attribute(s) with failed address
family (or families) to help the client to recognize whether
this is an "old" non-SSODA server or a "new"
SSODA-supporting server ?]
</t>
<t>
[OPEN ISSUE 2: do we have to consider a particular ordering of
REQUESTED-ADDRESS-FAMILY and REQUESTED-ADDRESS-FAMILY
attributes in the ALLOCATE request and response ? Can
attribute ordering provide some benefits in this case ?]
</t>
</section>
<section title="Receiving an Allocate Success Response">
<t>
This section describes how the client must react on
receiving a response to the dual allocation request. If the
client is not using dual allocation, then the behavior is
the same as the rules in <xref target="RFC5766" /> and in
<xref target="RFC6156" />.
</t>
<t>
If the client receives an Allocate Success Response
containing a non-ANY (ANY as defined above)
XOR-RELAYED-ADDRESS attribute for each of the
REQUESTED-ADDRESS-FAMILY attributes in the Allocate request
sent by the client, the client knows that the TURN server
supports multiple address family allocation over a single
socket. All relay addresses can now be used by the client.
</t>
<t>
If the Allocate response contains both usable
XOR-RELAYED-ADDRESS attributes as well as ANY
XOR-RELAYED-ADDRESS attributes, then the client knows that
the TURN server "understands" dual allocation SSODA request,
but the server either does not support one of the requested
address families or cannot currently allocate an address of
that family. The allocated non-ANY address can be used, but
the client SHOULD NOT try to allocate any of the unsupported
families on a different 5-tuple.
</t>
<t>
If the Allocate Response contains only one
XOR-RELAYED-ADDRESS attribute, then the client knows that
the TURN server does not support SSODA. The client can retry
the missing address family allocations on new 5-tuples, if
desired. Subsequent Allocate requests towards the same TURN
server SHOULD NOT include multiple REQUESTED-ADDRESS-FAMILY
attributes.
</t>
</section>
<section title="Receiving an Allocate Error Response">
<t>
When doing dual allocation, if the client receives an
Allocate error response with the 440 (Unsupported Address
Family) error code, then the client knows that the TURN
server does not support any of the desired address families,
or might be a non-SSODA server that misinterpreted the
included REQUESTED-ADDRESS-FAMILY attributes in the Allocate
request. The client SHOULD retry its IPv4 request on the
same 5-tuple, with no REQUESTED-ADDRESS-FAMILY attribute,
and MAY retry other address families on different local
ports, by sending an Allocate request with only one
REQUESTED-ADDRESS-FAMILY attribute.
</t>
</section>
</section>
<section title="Refreshing an Allocation">
<t>
The behavior specified here affects the processing defined in
Section 7 of <xref target="RFC5766"/> and Section 5 of <xref
target="RFC6156" />. This section MUST only be used if the
client has verified that the TURN server supports SSODA during
the allocation creation described in <xref target =
"create_allocation" />. Otherwise, revert back to RFC 5766 or
RFC 6156 behavior.
</t>
<section title="Sending a Refresh Request">
<t>
To perform an allocation refresh, the client generates a
Refresh Request as described in Section 7.1 of <xref
target="RFC5766"/>. When refreshing a dual allocation, the
client SHOULD include one or more REQUESTED-ADDRESS-FAMILY
attributes describing the the family types that should be
refreshed; the client MUST only include family types that it
previously allocated and has not yet deleted. When
refreshing a (single) allocation on a server that does not
not support SSODA, REQUESTED-ADDRESS-FAMILY should be
omitted, for backwards compatibility.
</t>
<t>
This process can also be used to delete an allocation of a
specific address type, by setting the lifetime of that
refresh request to 0. It is possible to delete one or more
allocations depending on how many REQUESTED-ADDRESS-FAMILY
attributes are included. Deleting a single allocation
destroys any permissions or channels associated with that
particular allocation; it MUST NOT affect any permissions or
channels associated with allocations for other address
families.
</t>
</section>
<section title="Receiving a Refresh Request">
<t>
The server refreshes the allocated address families that
match the supplied REQUESTED-ADDRESS-FAMILY values. If any
of the values in the request do not match a currently
allocated address, the server MUST respond with a 437
(Allocation Mismatch) error. [OPEN ISSUE: discuss whether
this is the right error code for the situation]
If no REQUESTED-ADDRESS-FAMILY is present, the request should be
treated as applying to all current allocations, for backward
compatibility.
</t>
<t>
The server MUST then refresh or delete the specified
allocations, and return a Refresh Success Response.
</t>
</section>
<section title="CreatePermission">
<t>
The behavior specified here affects the processing defined
in Section 9 of <xref target="RFC5766"/> and Section 6 of
<xref target="RFC6156" />
</t>
<section title="Sending a CreatePermission Request">
<t>
The client MUST only include XOR-PEER-ADDRESS attributes
with addresses that match an address family of one of the
currently allocated addresses.
</t>
</section>
<section title="Receiving a CreatePermission Request">
<t>
If an XOR-PEER-ADDRESS attribute contains an address of an
address family different than that any of the relayed
transport addresses allocated, the server MUST generate an
error response with the 443 (Peer Address Family Mismatch)
response code, which is defined in Section 6.2.1 of <xref
target="RFC6156" />.
</t>
</section>
</section>
</section>
<section title="Channels">
<t>
The session channels setup process follows the same rules as
in <xref target="RFC5766"/> and in <xref target="RFC6156" />;
the client is allowed to set up multiple channels within the
same 5-tuple session. However, when using SSODA and dual
allocation, the peer addresses of those channels may be of
different families. Thus, a single 5-tuple session may create
several IPv4 channels and several IPv6 channels.
</t>
</section>
<section title="Implementation Status">
<t>
[Note to RFC Editor: Please remove this section and reference
to <xref target="RFC6982"></xref> prior to publication.]
</t>
<t>
This section records the status of known implementations of
the protocol defined by this specification at the time of
posting of this Internet-Draft, and is based on a proposal
described in <xref target="RFC6982"></xref>. The description
of implementations in this section is intended to assist the
IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF
contributors. This is not intended as, and must not be
construed to be, a catalog of available implementations or
their features. Readers are advised to note that other
implementations may exist.
</t>
<t>
According to <xref target="RFC6982"></xref>, "this will allow
reviewers and working groups to assign due consideration to
documents that have the benefit of running code, which may
serve as evidence of valuable experimentation and feedback
that have made the implemented protocols more mature. It is up
to the individual working groups to use this information as
they see fit".
</t>
<section title="open-sys">
<t>
<list style="hanging">
<t hangText="Organization: ">
This is a public project, the full list of authors and
contributors here:
http://turnserver.open-sys.org/downloads/AUTHORS</t>
<t hangText="Description: ">
A mature open-source TURN server specs implementation
(RFC 5766, RFC 6062, RFC 6156, etc) designed for
high-performance applications, especially geared for
WebRTC.
</t>
<t hangText="Implementation:">
http://code.google.com/p/coturn/
</t>
<t hangText="Level of maturity: ">
The TURN SSODA extension implementation can be qualified
as "production" - it is well tested and fully
implemented, but not widely used, yet..
</t>
<t hangText="Coverage: ">
Fully implements SSODA this draft.
</t>
<t hangText="Licensing: ">
BSD: http://turnserver.open-sys.org/downloads/LICENSE
</t>
<t hangText="Implementation experience: ">
Few changes to existing code
</t>
<t hangText="Contact: ">
Oleg Moskalenko
<mom040267@gmail.com>.
</t>
</list>
</t>
</section>
<section title="NATTools">
<t>
<list style="hanging">
<t hangText="Organization: ">
Cisco
</t>
<t hangText="Description: ">
NATTools is a set of client side focused ICE/TURN/STUN libraries.
</t>
<t hangText="Implementation: ">
https://github.com/cisco/NATTools
</t>
<t hangText="Level of maturity: ">
Running test code works well. Not tested in any released products.
</t>
<t hangText="Coverage: ">
Implement this draft.
</t>
<t hangText="Licensing: ">
BSD
</t>
<t hangText="Implementation experience: ">
Simple, few changes to the client.
</t>
<t hangText="Contact: ">
Paal-Erik Martinsen
<palmarti@gmail.com>.
</t>
</list></t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
As the client can ask for two allocations for each allocation
request sent, the TURN server can be DOS attacked with fewer
messages. However this problem is minimal as the messages
needs to be authenticated first as described in <xref
target="RFC5766">RFC 5766</xref>.
</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>
Authors would like to thank Simon Perreault for providing
ideas direction and insight. Jonathan Lennox provided excellent
feedback on the mailing list.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.RFC.6156"?>
<?rfc include="reference.RFC.6982"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:23 |