BEHAVE G. Camarillo
Internet-Draft O. Novo
Intended status: Standards Track Ericsson
Expires: August 3, 2008 January 31, 2008
Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6
Transition
draft-ietf-behave-turn-ipv6-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines the REQUESTED-ADDRESS-TYPE attribute for the
Traversal Using Relays around NAT (TURN), which 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). Additionally, this document also defines a new error
response code with the value 440 (Address Family not Supported).
Camarillo & Novo Expires August 3, 2008 [Page 1]
Internet-Draft TURN Extension for IPv4/IPv6 transition January 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Initial Allocate Request . . . . . . . . . . . . . . . . . 4
4.2. Refresh Request . . . . . . . . . . . . . . . . . . . . . . 5
5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Allocate Response . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7.1. New STUN Attribute Registry . . . . . . . . . . . . . . . . 6
7.2. New STUN Response Code Registry . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Camarillo & Novo Expires August 3, 2008 [Page 2]
Internet-Draft TURN Extension for IPv4/IPv6 transition January 2008
1. Introduction
The Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn]
is a protocol that allows for an element behind a NAT or firewall to
receive incoming data over TCP or UDP connections. It is most useful
for elements behind symmetric NATs or firewalls that wish to be on
the receiving end of a connection to a single peer.
This document defines the REQUESTED-ADDRESS-TYPE 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).
2. Terminology
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 [RFC2119].
3. Overview of Operation
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-TYPE 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.
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-TYPE attribute. This address is called the
allocated transport address.
The TURN server returns the allocated address in the response to the
Allocate Request. This response contains a RELAY-ADDRESS attribute
indicating the mapped IP address and port that the server assigned to
the client.
For simplicity reasons, TURN servers are designed to allocate a
single address per allocation request. Therefore, Allocate Requests
cannot carry more than one REQUESTED-ADDRESS-TYPE 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).
Camarillo & Novo Expires August 3, 2008 [Page 3]
Internet-Draft TURN Extension for IPv4/IPv6 transition January 2008
4. Client Behavior
Client behavior for Allocate requests depends on whether the request
is an initial one, for the purposes of obtaining a new relayed
transport address, or a subsequent one, used for refreshing an
existing allocation.
The client behavior specified here affects the transport processing
defined in Section 6.1 of TURN [I-D.ietf-behave-turn].
4.1. Initial Allocate Request
A client that wishes to obtain a transport address of a specific
address type includes a REQUESTED-ADDRESS-TYPE attribute in the
Allocate Request that sends to the TURN server. Clients MUST NOT
include more than one REQUESTED-ADDRESS-TYPE attribute in an Allocate
Request. The mechanisms to formulate an Allocate Request are
described in Section 6.1.1 of [I-D.ietf-behave-turn].
The REQUESTED-ADDRESS-TYPE 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-TYPE 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of REQUESTED-ADDRESS-TYPE Attribute
Type: the type of the REQUESTED-ADDRESS-TYPE attribute is 0x0017. As
specified in [I-D.ietf-behave-rfc3489bis], 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.
Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes.
Family: there are two values defined for this field and specified in
Camarillo & Novo Expires August 3, 2008 [Page 4]
Internet-Draft TURN Extension for IPv4/IPv6 transition January 2008
[I-D.ietf-behave-rfc3489bis]: 0x01 for IPv4 addresses and 0x02 for
IPv6 addresses.
Reserved: at this point, the 24 bits in the reserved field SHOULD be
set to zero by the client and MUST be ignored by the server.
The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
Requests.
4.2. Refresh Request
To perform a binding refresh, the client generates a Refresh Request
as described in Section 6.1.2 of [I-D.ietf-behave-turn]. The client
includes the same REQUESTED-ADDRESS-TYPE attribute as it included in
its initial Allocate Request.
If the Allocate Response contains the same transport address as
previously obtained, the binding has been refreshed. If, however,
the response was an Allocate Error Response with an ERROR-CODE
between 500 to 599, the client MAY resend the refresh request. Any
other Allocate Error Response codes imply that the transaction has
failed.
5. Server Behavior
The server behavior specified here affects the transport processing
defined in Section 6.2 of TURN [I-D.ietf-behave-turn].
5.1. Allocate Response
Assuming the request is authenticated and has not been tampered with,
the TURN server processes the request. Following the rules in
[I-D.ietf-behave-rfc3489bis], if the server does not understand the
REQUESTED-ADDRESS-TYPE 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-TYPE
attribute.
This document defines the following new error response code:
440 (Address Family not Supported): The server did not support the
address family requested by the client. The client SHOULD not
retry.
If the server does not support the address family requested by the
client, it MUST generate an Allocate Error Response, and it MUST
Camarillo & Novo Expires August 3, 2008 [Page 5]
Internet-Draft TURN Extension for IPv4/IPv6 transition January 2008
include an ERROR-CODE attribute with the response code defined in
this draft, 440 (Address Family not Supported).
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.
As specified in [I-D.ietf-behave-turn], the Allocate Response
contains the same transaction ID contained in the Allocate Request
and the RELAY-ADDRESS attribute that sets it to the allocated
transport address.
The RELAY-ADDRESS attribute indicates the mapped IP address and port.
It is encoded in the same way as the XOR-MAPPED-ADDRESS
[I-D.ietf-behave-rfc3489bis].
If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST
allocate a IPv4 transport address to the TURN client.
6. Security Considerations
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 [I-D.ietf-behave-rfc3489bis] and TURN are
applicable to this document as well.
7. IANA Considerations
The IANA is requested to register the following values under the STUN
Attributes registry and under the STUN Response Code Registry.
7.1. New STUN Attribute Registry
0x0017: REQUESTED-ADDRESS-TYPE
7.2. New STUN Response Code Registry
440 Address Family not Supported
8. Acknowledgements
The authors would like to thank Alfred E. Heggestad and Remi Denis-
Courmont for their feedback on this document.
Camarillo & Novo Expires August 3, 2008 [Page 6]
Internet-Draft TURN Extension for IPv4/IPv6 transition January 2008
9. Normative References
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Session Traversal Utilities for (NAT)
(STUN)", draft-ietf-behave-rfc3489bis-06 (work in
progress), March 2007.
[I-D.ietf-behave-turn]
Rosenberg, J., "Obtaining Relay Addresses from Simple
Traversal Underneath NAT (STUN)",
draft-ietf-behave-turn-03 (work in progress), March 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Oscar Novo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Oscar.Novo@ericsson.com
Camarillo & Novo Expires August 3, 2008 [Page 7]
Internet-Draft TURN Extension for IPv4/IPv6 transition January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Camarillo & Novo Expires August 3, 2008 [Page 8]
