One document matched: draft-ietf-behave-turn-ipv6-07.xml

<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-behave-turn-ipv6-07">

<front>
<title abbrev="TURN Extension for IPv4/IPv6 transition">
Traversal Using Relays around NAT (TURN) Extension for IPv6
</title> 

<author initials="S." surname="Perreault" fullname="Simon Perreault"
  role="editor">
  <organization>Viagénie</organization>
  <address>
    <postal>
      <street>2600 boul. Laurier, suite 625</street>
      <city>Québec</city>
      <region>QC</region>
      <code>G1V 4W1</code>
      <country>Canada</country>
    </postal>
    <phone>+1 418 656 9254</phone>
    <email>simon.perreault@viagenie.ca</email>
    <uri>http://www.viagenie.ca</uri>
  </address>
</author>

<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
  <organization>Ericsson</organization>
  <address>
    <postal>
      <street>Hirsalantie 11</street>
      <code>02420</code> 
      <city>Jorvas</city> 
      <country>Finland</country>
    </postal>
    <email>Gonzalo.Camarillo@ericsson.com</email>
  </address>
</author>

<author initials="O." surname="Novo" fullname="Oscar Novo">
  <organization>Ericsson</organization>
  <address>
    <postal>
      <street>Hirsalantie 11</street>
      <code>02420</code> 
      <city>Jorvas</city> 
      <country>Finland</country>
    </postal>
    <email>Oscar.Novo@ericsson.com</email>
  </address>
</author>

<date year="2009" />

<area>Transport</area>
<workgroup>BEHAVE</workgroup>
<keyword>STUN, TURN, IPv6</keyword>

<abstract>
<t>
This document adds IPv6 support to Traversal Using Relays around NAT
(TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and
IPv6-to-IPv4 relaying. This document defines the
REQUESTED-ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY
attribute allows a client to explicitly request the address type the
TURN server will allocate (e.g., an IPv4-only node may request the
TURN server to allocate an IPv6 address).
</t>
</abstract>

</front>

<middle>

<section title="Introduction">
<t>
Traversal Using Relays around NAT (TURN) <xref
target="I-D.ietf-behave-turn"/> is a protocol that allows for an
element behind a NAT to receive incoming data over UDP or TCP. It is
most useful for elements behind symmetric NATs that wish to be on the
receiving end of a connection to a single peer.
</t>
<t>
The base specification of TURN <xref target="I-D.ietf-behave-turn"/>
only defines IPv4-to-IPv4 relaying. This document adds IPv6 support to
TURN, which includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4
relaying. This document defines the REQUESTED-ADDRESS-FAMILY attribute,
which is an extension to TURN that allows a client to explicitly
request the address type the TURN server will allocate (e.g., an
IPv4-only node may request the TURN server to allocate an IPv6
address). This document also defines and registers a new error
response code with the value 440 (Address Family not Supported).
</t>
</section>

<section title="Terminology">
<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"/>.
</t>
</section>

<section title="Overview of Operation">
<t>
When a user wishes a TURN server to allocate an address of a specific
type, it sends an Allocate Request to the TURN server with a
REQUESTED-ADDRESS-FAMILY attribute. TURN can run over UDP and TCP, as it
allows for a client to request address/port pairs for receiving both
UDP and TCP.
</t>
<t>
Assuming the request is authenticated and has not been tampered with,
the TURN server allocates a transport address of the type indicated in
the REQUESTED-ADDRESS-FAMILY attribute. This address is called the
allocated transport address.
</t>
<t>
The TURN server returns the allocated address in the response to the
Allocate Request. This response contains a XOR-RELAYED-ADDRESS
attribute indicating the IP address and port that the server allocated
for the client.
</t>
<t>
TURN servers allocate a single relayed-transport-address per
allocation request. Therefore, Allocate Requests cannot carry more
than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client that
wishes to allocate more than one address at a TURN server (e.g., an
IPv4 and an IPv6 address) needs to perform several allocation requests
(one allocation request per address).
</t>
<t>
A TURN server that supports a set of address families is assumed to be
able to relay packets between them. If a server does not support the
address family requested by a client, the server returns a 440
(Address Family not Supported) error response.
</t>

</section>

<section title="Creating an Allocation">
<t>
The behavior specified here affects the processing defined in Section
6 of <xref target="I-D.ietf-behave-turn"/>.
</t>

<section title="Sending an Allocate Request">
<t>
A client that wishes to obtain a transport address of a specific
address type includes a REQUESTED-ADDRESS-FAMILY attribute, which is
defined in <xref target="sec-attribute"/>, in the Allocate Request
that it sends to the TURN server. Clients MUST NOT include more than one
REQUESTED-ADDRESS-FAMILY attribute in an Allocate Request. The
mechanisms to formulate an Allocate Request are described in Section
6.1 of <xref target="I-D.ietf-behave-turn"/>.
</t>
<t>
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an
Allocate request that contains a RESERVATION-TOKEN attribute.
</t>

<section title="The REQUESTED-ADDRESS-FAMILY Attribute"
anchor="sec-attribute">
<t>
The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request the
allocation of a specific address type from a server. The following is
the format of the REQUESTED-ADDRESS-FAMILY attribute. Note that
TURN attributes are TLV (Type-Length-Value) encoded, with a 16 bit
type, a 16 bit length, and a variable-length value.
</t>
<figure title="Format of REQUESTED-ADDRESS-FAMILY Attribute"
anchor="fig-arch">
<artwork><![CDATA[ 


  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type                  |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Family    |            Reserved                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
</figure>
<t>
Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017.  As
specified in <xref target="RFC5389"/>, attributes
with values between 0x0000 and 0x7FFF are comprehension-required, 
which means that the client or server cannot successfully process the
message unless it understands the attribute.
</t>
<t>
Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes.
</t>
<t>
Family: there are two values defined for this field and specified in 
<xref target="RFC5389"/>: 0x01 for IPv4
addresses and 0x02 for IPv6 addresses.
</t>
<t>
Reserved: at this point, the 24 bits in the reserved field MUST be
set to zero by the client and MUST be ignored by the server.
</t>
<t>
The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
Requests.
</t>
</section>

</section>

<section title="Receiving an Allocate Request">
<t>
Assuming the request is authenticated and has not been tampered with,
the TURN server processes the Allocate request. Following the rules in
<xref target="RFC5389"/>, if the server does not
understand the REQUESTED-ADDRESS-FAMILY attribute, it generates an
Allocate Error Response, which includes an ERROR-CODE attribute with
response code 420 (Unknown Attribute). This response will contain an
UNKNOWN-ATTRIBUTE attribute listing the unknown REQUESTED-ADDRESS-FAMILY
attribute.
</t>
<t>
If the server can successfully process the request, it allocates a
transport address to the TURN client, called the allocated transport
address, and returns it in the response to the Allocate Request.
</t>
<t>
As specified in <xref target="I-D.ietf-behave-turn"/>, the Allocate
Response contains the same transaction ID contained in the Allocate
Request and the XOR-RELAYED-ADDRESS attribute that sets it to the
allocated transport address.
</t>
<t>
The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address
and port.  It is encoded in the same way as the XOR-MAPPED-ADDRESS
<xref target="RFC5389"/>.
</t>
<t>
If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST
allocate an IPv4 transport address to the TURN client.
</t>
<t>
If the server does not support the address family requested by the client, 
it MUST generate an Allocate Error Response, and it MUST include an 
ERROR-CODE attribute with the 440 (Address Family not Supported)
response code, which is defined in <xref target="sec-440"/>.
</t>


<section title="Unsupported Address Family"
anchor="sec-440">
<t>
This document defines the following new error response code:
</t>
<t>
<list style="hanging">
<t hangText="440 (Address Family not Supported):"> The server did not
support the address family requested by the client. 
</t>
</list>
</t>
</section>

</section>


<section title="Receiving an Allocate Error Response">
<t>
If the client receives an Allocate error response with the 440
(Unsupported Address Family) error code, the client SHOULD NOT retry
its request.
</t>
</section>

</section>

<section title="Refreshing an Allocation">
<t>
The behavior specified here affects the processing defined in Section
7 of <xref target="I-D.ietf-behave-turn"/>.
</t>

<section title="Sending a Refresh Request">
<t>
To perform a binding refresh, the client generates a Refresh Request
as described in Section 7.1 of <xref target="I-D.ietf-behave-turn"/>.
The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in
its Refresh Request.
</t>
</section>

<section title="Receiving a Refresh Request">
<t>
If a server receives a Refresh Request with a REQUESTED-ADDRESS-FAMILY
attribute, it MUST ignore the attribute and process the request as if
the attribute was not there.
</t>
</section>

</section>


<section title="CreatePermission">
<t>
The behavior specified here affects the processing defined in Section
9 of <xref target="I-D.ietf-behave-turn"/>.
</t>

<section title="Sending a CreatePermission Request">
<t>
The client MUST only include XOR-PEER-ADDRESS attributes with
addresses of the same address family as the relayed transport address
for the allocation.
</t>
</section>

<section title="Receiving a CreatePermission request">
<t>
If an XOR-PEER-ADDRESS attribute contains an address of an address
family different than the relayed transport address for the
allocation, the server MUST generate an error response with the
443 (Peer Address Family Mismatch) response code, which is defined in
<xref target="sec-443"/>.
</t>

<section title="Peer Address Family Mismatch"
anchor="sec-443">
<t>
This document defines the following new error response code:
</t>
<t>
<list style="hanging">
<t hangText="443 (Peer Address Family Mismatch):"> A peer address was
of a different address family than the relayed transport address of
the allocation.
</t>
</list>
</t>

</section>

</section>

</section>



<section title="Channels">
<t>
The behavior specified here affects the processing defined in Section
11 of <xref target="I-D.ietf-behave-turn"/>.
</t>

<section title="Sending a ChannelBind Request">
<t>
The client MUST only include a XOR-PEER-ADDRESS attribute with
an address of the same address family as the relayed transport address
for the allocation.
</t>
</section>

<section title="Receiving a ChannelBind Request">
<t>
If the XOR-PEER-ADDRESS attribute contains an address of an address
family different than the relayed transport address for the
allocation, the server MUST generate an error response with the
443 (Peer Address Family Mismatch) response code, which is defined in
<xref target="sec-443"/>.
</t>
</section>

</section>


<section title="Packet Translations">
<t>
The TURN specification <xref target="I-D.ietf-behave-turn"/> describes
how TURN relays should relay traffic consisting of IPv4 packets (i.e.,
IPv4-to-IPv4 translations). The relay translates the IP addresses and
port numbers of the packets based on the allocation's state data. How
to translate other header fields is also specified in <xref
target="I-D.ietf-behave-turn"/>. This document addresses IPv4-to-IPv6,
IPv6-to-IPv4, and IPv6-to-IPv6 translations.
</t>
<t>
TURN relays performing any translation MUST translate the IP addresses
and port numbers of the packets based on the allocation's state
information as specified in <xref
target="I-D.ietf-behave-turn"/>. The following sections specify how to
translate other header fields.
</t>
<t>
As discussed in Section 2.6 of <xref target="I-D.ietf-behave-turn"/>,
translations in TURN are designed so that a TURN server can be
implemented as an application that runs in userland under commonly
available operating systems and that does not require special
privileges. The translations specified in the following sections
follow this principle.
</t>
<t>
The descriptions below have two parts: a preferred behavior and an
alternate behavior.  The server SHOULD implement the preferred
behavior. However, if that is not possible for a particular field,
then the server SHOULD implement the alternative behavior.
</t>
<t>
<list style="hanging">
<t>
Note that the use of the behaviors specified in the following sections
is at the "should" level. Having its use at the "should" level instead
of at the "must" level makes it possible to use different translation
algorithms that may be developed in the future.
</t>
</list>

</t>

<section title="IPv4-to-IPv6 Translations">
<t>
Flow Label
</t>
<t>
<list>
<t></t>
<t> 
Preferred behavior: The relay sets the Flow label to 0. The relay can
choose to set the Flow label to a different value if it supports <xref
target="RFC3697"/>.
</t>
<t></t>
<t>
Alternative behavior: the relay sets the Flow label to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Hop Limit
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: as specified in Section 3.1 of <xref
target="RFC2765"/>.
</t>
<t></t>
<t>
Alternative behavior: the relay sets the Hop Limit to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Fragmentation
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: as specified in Section 3.1 of <xref
target="RFC2765"/>.
</t>
<t></t>
<t>
Alternative behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
</t>
<t></t>
<t>If present, the DONT-FRAGMENT attribute MUST be ignored by the server.</t>
</list>
</t>

<t>
Extension Headers
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: the relay sends outgoing packet without any IPv6
extension headers, with the exception of the Fragmentation header as
described above.
</t>
<t></t>
<t>
Alternative behavior: same as preferred.
</t>
</list>
</t>

</section>

<section title="IPv6-to-IPv6 Translations">
<t>
Flow Label
</t>
<t>
The relay should consider that it is handling two different IPv6
flows. Therefore, the Flow label <xref target="RFC3697"/> SHOULD NOT
be copied as part of the translation.
</t>

<t>
<list>
<t> 
Preferred behavior: The relay sets the Flow label to 0. The relay can
choose to set the Flow label to a different value if it supports <xref
target="RFC3697"/>.
</t>
<t></t>
<t>
Alternative behavior: the relay sets the Flow label to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Hop Limit
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: the relay acts as a regular router with respect to
decrementing the Hop Limit and generating an ICMPv6 error if it
reaches zero.
</t>
<t></t>
<t>
Alternative behavior: the relay sets the Hop Limit to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Fragmentation
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: If the incoming packet did not include a Fragment
header and the outgoing packet size does not exceed the outgoing
link's MTU, the relay sends the outgoing packet without a Fragment
header.
</t>
<t></t>
<t>
If the incoming packet did not include a Fragment header and the
outgoing packet size exceeds the outgoing link's MTU, the delay drops
the outgoing packet and send an ICMP message of type 2 code 0 ("Packet
too big") to the sender of the incoming packet.  If the packet is
being sent to the peer, the relay reduces the MTU reported in the ICMP
message by 48 bytes to allow room for the overhead of a Data
indication.
</t>
<t></t>
<t>
If the incoming packet included a Fragment header and the outgoing
packet size (with a Fragment header included) does not exceed the
outgoing link's MTU, the relay sends the outgoing packet with a
Fragment header. The relay sets the fields of the Fragment header as
appropriate for a packet originating from the server.
</t>
<t></t>
<t>
If the incoming packet included a Fragment header and the outgoing
packet size exceeds the outgoing link's MTU, the relay MUST fragment
the outgoing packet into fragments of no more than 1280 bytes. The
relay sets the fields of the Fragment header as appropriate for a
packet originating from the server.
</t>
<t></t>
<t>
Alternative behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
</t>
<t></t>
<t>If present, the DONT-FRAGMENT attribute MUST be ignored by the server.</t>
</list>
</t>

<t>
Extension Headers
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: the relay sends outgoing packet without any IPv6
extension headers, with the exception of the Fragmentation header as
described above.
</t>
<t></t>
<t>
Alternative behavior: same as preferred.
</t>
</list>
</t>

</section>

<section title="IPv6-to-IPv4 Translations">

<t>
Type of Service and Precedence
</t>
<t>
<list>
<t></t>
<t> 
Preferred behavior: as specified in Section 4 of <xref
target="RFC2765"/>.
</t>
<t></t>
<t>
Alternative behavior: the relay sets the Type of Service and
Precedence to the default value for outgoing packets.
</t>
</list>
</t>

<t>
Time to Live
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: as specified in Section 4.1 of <xref
target="RFC2765"/>.
</t>
<t></t>
<t>
Alternative behavior: the relay sets the Time to Live to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Fragmentation
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: as specified in Section 4 of <xref
target="RFC2765"/>.  Additionally, when the outgoing packet's size
exceeds the outgoing link's MTU, the relay needs to generate an ICMP
error (ICMPv6 Packet Too Big) reporting the MTU size. If the packet is
being sent to the peer, the relay SHOULD reduce the MTU reported in
the ICMP message by 48 bytes to allow room for the overhead of a Data
indication.
</t>
<t></t>
<t>
Alternative behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
</t>
<t></t>
<t>If present, the DONT-FRAGMENT attribute MUST be ignored by the server.</t>
</list>
</t>

</section>

</section>


<section title="Security Considerations">
<t>
The attribute and error response code defined in this document do not
have any special security considerations beyond those for other
attributes and Error response codes. All the security considerations
applicable to STUN <xref target="RFC5389"/> and TURN
are applicable to this document as well.
</t>
</section>

<section title="IANA Considerations">
<t>
The IANA is requested to register the following values under the STUN
Attributes registry and under the STUN Response Code Registry.
</t>
<section title="New STUN Attribute Registry">
<t>
	0x0017: REQUESTED-ADDRESS-FAMILY
</t>
</section>

<section title="New STUN Response Code Registry">
<t>
	440  Address Family not Supported
</t>
</section>
</section>
<section title="Acknowledgements">
<t>
The authors would like to thank Alfred E. Heggestad, Rémi
Denis-Courmont, and Philip Matthews for their feedback on this
document.
</t>
</section>

</middle>

<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2765"?>
<?rfc include="reference.RFC.3697"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.I-D.ietf-behave-turn"?>

</references>

</back>
</rfc>