Internet DRAFT - draft-camarillo-midcom-turn-ipv6
draft-camarillo-midcom-turn-ipv6
MIDCOM G. Camarillo
Internet-Draft O. Novo
Expires: April 15, 2006 Ericsson
October 12, 2005
Traversal Using Relay NAT (TURN) Extension for IPv4/IPv6 transition
draft-camarillo-midcom-turn-ipv6-00.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 April 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines the Traversal Using Relay NAT (TURN) REQUESTED-
ADDRESS-TYPE attribute, 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). This
document also registers the IPv6 address type.
Camarillo & Novo Expires April 15, 2006 [Page 1]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Allocating a Binding . . . . . . . . . . . . . . . . . . . 4
4.2. Refreshing a Binding . . . . . . . . . . . . . . . . . . . 5
5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Allocate Request . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Camarillo & Novo Expires April 15, 2006 [Page 2]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2005
1. Introduction
Traversal Using Relay NAT (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 registers the IPv6 address type, which is
initially intended to be used in MAPPED-ADDRESS and in REQUESTED-
ADDRESS-TYPE attributes.
2. Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, HALL
NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are o be
interpreted as described in RFC RFC-2119 [1] and indicate requirement
levels for compliant TURN implementations.
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 MAPPED-ADDRESS attribute
indicating the mapped IP address and port that the server assigned to
the client.
4. Client Behavior
The client behavior specified here affects the transport processing
Camarillo & Novo Expires April 15, 2006 [Page 3]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2005
defined in Section 8 of TURN [2].
4.1. Allocating a Binding
A client that wishes to obtain a transport address of a specific
address type includes the REQUESTED-ADDRESS-TYPE attribute in the
Allocate Request that sends to the TURN server. The mechanisms to
formulate an Allocate Request are described in Section 8.3 of [2].
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 attributes in TURN 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the type of the REQUESTED-ADDRESS-TYPE mandatory-to-understand
attribute is 0x0016. As it is explained in [3], a server cannot
process a message with a mandatory-to-understand attributes unless it
understands the mandatory 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: 0x01 for IPv4
addresses and 0x02 for IPv6 addresses.
Reserved: at this point, the 16 bits in the reserved field SHOULD be
set to zero by the client and MUST be ignored by the server.
Table 1 indicates in which TURN messages can be present the REQUEST-
ADDRESS-TYPE attribute. An O indicates that inclusion of the
attribute in the message is optional and N/A means that the attribute
is not applicable to that message type.
Binding Shared Shared Shared
Binding Binding Error Secret Secret Secret
Att. Req. Resp. Resp. Req. Resp. Error
Resp.
__________________________________________________________________
Camarillo & Novo Expires April 15, 2006 [Page 4]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2005
REQUESTED-ADDRESS-TYPE O N/A N/A N/A N/A N/A
Table 1: Summary of the REQUESTED-ADDRESS-TYPE Attribute
4.2. Refreshing a Binding
To perform a binding refresh, the client generates an Allocate
Request as described in the previous section. 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
indicating a 430 response, it means that the binding has expired at
the server. Other response codes do not imply that the binding has
been expired, just that the refresh has failed.
5. Server Behavior
The server behavior specified here affects the transport processing
defined in Section 7.2 of TURN [2].
5.1. Allocate Request
Assuming the request is authenticated and has not been tampered with,
the TURN server processes the request. If the server does not
understand the REQUESTED-ADDRESS-TYPE attribute, it MUST generate an
Allocate Error Response, and it MUST include an ERROR-CODE attribute
with response code 420 (Unknown Attribute). This response MUST
contain an UNKNOWN-ATTRIBUTE attribute listing the unknown REQUESTED-
ADDRESS-TYPE attribute.
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 is explained in [2], the Allocate Response contains the same
transaction ID contained in the Allocate Request. The server adds a
MAPPED-ADDRESS attribute to the Allocate Response and sets it to the
allocated transport address.
The MAPPED-ADDRESS attribute indicates the mapped IP address and
port. It consists of an eight bit address family, and a sixteen bit
port, followed by a fixed length value representing the IP address.
Camarillo & Novo Expires April 15, 2006 [Page 5]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STUN [3] defines the 0x01 family type address value for the MAPPED-
ADDRESS attribute. The first 8 bits of the MAPPED-ADDRESS are
ignored, for the purposes of aligning parameters on natural
boundaries. The value of the Address field is 4 bytes (32 bits) long
for the IPv4 family type address.
This document defines the IPv6 family type address with the value
0x02. The value of the Address field is 32 bytes (128 bits) long for
the IPv6 address. The fact that the length of this type of address
is 32 bytes guarantees the alignment of the attribute on word
boundaries.
6. IANA Considerations
This document defines the REQUESTED-ADDRESS-TYPE attribute, which the
IANA has added to the TURN attribute registry defined in TURN [2].
Editor's note: the TURN spec does not create this registry yet. It
needs to create it.
This document also defines the address family tag "0x002" which IANA
has added to the registry defined in STUN [3].
Editor's note: the specs of STUN and TURN do not create any registry
for this yet.
7. Acknowledgements
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Camarillo & Novo Expires April 15, 2006 [Page 6]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2005
8.2. Informative References
[2] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-08 (work in progress),
September 2005.
[3] Rosenberg, J., "Simple Traversal of UDP Through Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 (work
in progress), July 2005.
Camarillo & Novo Expires April 15, 2006 [Page 7]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2005
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 April 15, 2006 [Page 8]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Camarillo & Novo Expires April 15, 2006 [Page 9]
