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]