BEHAVE G. Camarillo
Internet-Draft O. Novo
Intended status: Standards Track Ericsson
Expires: January 7, 2008 July 6, 2007
Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for
IPv4/IPv6 Transition
draft-ietf-behave-turn-ipv6-03.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 January 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines the REQUESTED-ADDRESS-TYPE attribute for the
Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a
client to explicitly request the address type the STUN relay server
will allocate (e.g., an IPv4-only node may request the STUN relay
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 January 7, 2008 [Page 1]
Internet-Draft STUN Extension for IPv4/IPv6 transition July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Allocating a Binding . . . . . . . . . . . . . . . . . . . 4
4.2. Refreshing a Binding . . . . . . . . . . . . . . . . . . . 5
5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Allocate Request . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7.1. New STUN Attribute Registry . . . . . . . . . . . . . . . . 6
7.2. New STUN Response Code Registry . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Camarillo & Novo Expires January 7, 2008 [Page 2]
Internet-Draft STUN Extension for IPv4/IPv6 transition July 2007
1. Introduction
The relay usage of Simple Traversal Underneath NAT (STUN)
[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 the STUN relay usage that allows a client to
explicitly request the address type the STUN relay server will
allocate (e.g., an IPv4-only node may request the STUN relay 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 STUN relay server to allocate an address of a
specific type, it sends an Allocate Request to the STUN relay server
with a REQUESTED-ADDRESS-TYPE attribute. STUN relay 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 STUN relay server allocates a transport address of the type
indicated in the REQUESTED-ADDRESS-TYPE attribute. This address is
called the allocated transport address.
The STUN relay 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, STUN relay 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
Camarillo & Novo Expires January 7, 2008 [Page 3]
Internet-Draft STUN Extension for IPv4/IPv6 transition July 2007
at a STUN relay server (e.g., an IPv4 and an IPv6 address) needs to
perform several allocation requests (one allocation request per
address).
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 9.1 of the STUN relay usage
[I-D.ietf-behave-turn].
4.1. Allocating a Binding
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 STUN relay 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 9.1.2 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 attributes in STUN relay 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 attribute is 0x0017. As
specified in [I-D.ietf-behave-rfc3489bis], Attributes with values
less than or equal to 0x7fff are mandatory to understand, 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
Camarillo & Novo Expires January 7, 2008 [Page 4]
Internet-Draft STUN Extension for IPv4/IPv6 transition July 2007
bytes. The length of this attribute is 4 bytes.
Family: there are two values defined for this field and specified in
[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. 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
expired, just that the refresh has failed.
5. Server Behavior
The server behavior specified here affects the transport processing
defined in Section 9.1.1 of STUN relay [I-D.ietf-behave-turn].
5.1. Allocate Request
Assuming the request is authenticated and has not been tampered with,
the STUN relay 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:
Camarillo & Novo Expires January 7, 2008 [Page 5]
Internet-Draft STUN Extension for IPv4/IPv6 transition July 2007
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
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 STUN relay 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 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 STUN relay 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 to its relay
usage 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
Camarillo & Novo Expires January 7, 2008 [Page 6]
Internet-Draft STUN Extension for IPv4/IPv6 transition July 2007
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.
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 January 7, 2008 [Page 7]
Internet-Draft STUN Extension for IPv4/IPv6 transition July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 January 7, 2008 [Page 8]
