One document matched: draft-ietf-behave-turn-ipv6-01.txt
Differences from draft-ietf-behave-turn-ipv6-00.txt
BEHAVE G. Camarillo
Internet-Draft O. Novo
Expires: May 24, 2007 Ericsson
November 20, 2006
Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for
IPv4/IPv6 Transition
draft-ietf-behave-turn-ipv6-01.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 May 24, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 May 24, 2007 [Page 1]
Internet-Draft STUN Extension for IPv4/IPv6 transition November 2006
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. 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 . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Camarillo & Novo Expires May 24, 2007 [Page 2]
Internet-Draft STUN Extension for IPv4/IPv6 transition November 2006
1. Introduction
The relay usage of Simple Traversal Underneath NAT (STUN) [1] 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
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 [2] and indicate requirement
levels for compliant STUN relay implementations.
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.
4. Client Behavior
Client behavior for Allocate requests depends on whether the request
Camarillo & Novo Expires May 24, 2007 [Page 3]
Internet-Draft STUN Extension for IPv4/IPv6 transition November 2006
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 [1].
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 STUN relay server. The mechanisms
to formulate an Allocate Request are described in Section 9.1.2 of
[1].
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 [3], 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
bytes. The length of this attribute is 8 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 STUN relay messages can be present the
REQUEST-ADDRESS-TYPE attribute. An O indicates that inclusion of the
Camarillo & Novo Expires May 24, 2007 [Page 4]
Internet-Draft STUN Extension for IPv4/IPv6 transition November 2006
attribute in the message is optional and - 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. Indication Req. Resp. Error
Resp.
_____________________________________________________________________
REQUESTED- O - - - - - -
ADDRESS-TYPE
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
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 [1].
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
[3], 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 May 24, 2007 [Page 5]
Internet-Draft STUN Extension for IPv4/IPv6 transition November 2006
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 [1], 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 [3].
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 [3] 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
7.2. New STUN Response Code Registry
440 Address Family not Supported
8. Acknowledgements
Camarillo & Novo Expires May 24, 2007 [Page 6]
Internet-Draft STUN Extension for IPv4/IPv6 transition November 2006
9. Normative References
[1] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
of UDP Through NAT (STUN)", draft-ietf-behave-turn-01 (work in
progress), June 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J., "Simple Traversal Underneath Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04 (work
in progress), July 2006.
Camarillo & Novo Expires May 24, 2007 [Page 7]
Internet-Draft STUN Extension for IPv4/IPv6 transition November 2006
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 May 24, 2007 [Page 8]
Internet-Draft STUN Extension for IPv4/IPv6 transition November 2006
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 (2006). 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 May 24, 2007 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 11:35:03 |