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]