BEHAVE                                                      G. Camarillo
Internet-Draft                                                   O. Novo
Expires: September 1, 2006                                      Ericsson
                                                       February 28, 2006


  Traversal Using Relay NAT (TURN) Extension for IPv4/IPv6 transition
                   draft-ietf-behave-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 September 1, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 September 1, 2006               [Page 1]


Internet-Draft   TURN Extension for IPv4/IPv6 transition   February 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.  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 September 1, 2006               [Page 2]


Internet-Draft   TURN Extension for IPv4/IPv6 transition   February 2006


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 September 1, 2006               [Page 3]


Internet-Draft   TURN Extension for IPv4/IPv6 transition   February 2006


   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 0x0017.  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 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 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 September 1, 2006               [Page 4]


Internet-Draft   TURN Extension for IPv4/IPv6 transition   February 2006


    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 variable length value representing the IP
   address.




Camarillo & Novo        Expires September 1, 2006               [Page 5]


Internet-Draft   TURN Extension for IPv4/IPv6 transition   February 2006


      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 16 bytes (128 bits) long for
   the IPv6 address.  The fact that the length of this type of address
   is 16 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 September 1, 2006               [Page 6]


Internet-Draft   TURN Extension for IPv4/IPv6 transition   February 2006


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 September 1, 2006               [Page 7]


Internet-Draft   TURN Extension for IPv4/IPv6 transition   February 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 September 1, 2006               [Page 8]


Internet-Draft   TURN Extension for IPv4/IPv6 transition   February 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 September 1, 2006               [Page 9]