One document matched: draft-martinsen-tram-ssoda-00.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-00" 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>public project rfc5766-turn-server</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/rfc5766-turn-server/</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 bahavior 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>
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY
attribute in an Allocate request that contains a
RESERVATION-TOKEN or an EVEN-PORT attributes. The SSODA
mechanism is not available when using the odd/even port
allocation scheme.
</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 roundtrip 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 behaviour.
</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 anchor="ack" title="Acknowledgements">
<t>
Authors would like to thank Simon Perreault for providing ideas
direction and insight.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.RFC.6156"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:41 |