BEHAVE G. Camarillo
Internet-Draft O. Novo
Intended status: Standards Track Ericsson
Expires: May 2, 2009 October 29, 2008
Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6
Transition
draft-ietf-behave-turn-ipv6-05.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 2, 2009.
Abstract
This document defines the REQUESTED-ADDRESS-TYPE attribute for
Traversal Using Relays around NAT (TURN). The REQUESTED-ADDRESS-TYPE
attribute 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). Additionally, this
document also defines a new error response code with the value 440
(Address Family not Supported).
Camarillo & Novo Expires May 2, 2009 [Page 1]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 4
4.1. Sending an Allocate Request . . . . . . . . . . . . . . . 4
4.1.1. The REQUESTED-ADDRESS-TYPE Attribute . . . . . . . . . 4
4.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5
4.2.1. Unsupported Address Family . . . . . . . . . . . . . . 5
5. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 6
5.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6
5.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6
6. Packet Translations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. New STUN Attribute Registry . . . . . . . . . . . . . . . 8
8.2. New STUN Response Code Registry . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Camarillo & Novo Expires May 2, 2009 [Page 2]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
1. Introduction
Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] is a
protocol that allows for an element behind a NAT or firewall to
receive incoming data over UDP or TCP. 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 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 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 RELAY-ADDRESS attribute
indicating the mapped IP address and port that the server assigned to
the client.
TURN servers allocate a single relayed-transport-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 at a TURN server (e.g.,
an IPv4 and an IPv6 address) needs to perform several allocation
requests (one allocation request per address).
Camarillo & Novo Expires May 2, 2009 [Page 3]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
4. Creating an Allocation
The behavior specified here affects the processing defined in Section
6 of [I-D.ietf-behave-turn].
4.1. Sending an Allocate Request
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 TURN 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 6.1 of [I-D.ietf-behave-turn].
4.1.1. The REQUESTED-ADDRESS-TYPE Attribute
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 TURN attributes 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of REQUESTED-ADDRESS-TYPE Attribute
Type: the type of the REQUESTED-ADDRESS-TYPE attribute is 0x0017. As
specified in [I-D.ietf-behave-rfc3489bis], attributes with values
between 0x0000 and 0x7FFF are comprehension-required, 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 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.
Camarillo & Novo Expires May 2, 2009 [Page 4]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
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. Receiving an Allocate Request
Assuming the request is authenticated and has not been tampered with,
the TURN server processes the Allocate 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.
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 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 XOR-MAPPED-ADDRESS
[I-D.ietf-behave-rfc3489bis].
If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST
allocate an IPv4 transport address to the TURN client.
4.2.1. Unsupported Address Family
This document defines the following new error response code:
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).
Camarillo & Novo Expires May 2, 2009 [Page 5]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
5. Refreshing an Allocation
The behavior specified here affects the processing defined in Section
7 of [I-D.ietf-behave-turn].
5.1. Sending a Refresh Request
To perform a binding refresh, the client generates a Refresh Request
as described in Section 7.1 of [I-D.ietf-behave-turn]. The client
MUST NOT include any REQUESTED-ADDRESS-TYPE attribute in its Refresh
Request.
5.2. Receiving a Refresh Request
If a server receives a Refresh Request with a REQUESTED-ADDRESS-TYPE
attribute, it MUST ignore the attribute and process the request as if
the attribute was not there.
6. Packet Translations
The TURN specification [I-D.ietf-behave-turn] describes how TURN
relays should relay traffic consisting of IPv4 packets (i.e., IPv4-
to-IPv4 translations). The relay translates the IP addresses and
port numbers of the packets based on the allocation's state data.
How to translate other header fields is also specified in
[I-D.ietf-behave-turn]. This document addresses IPv4-to-IPv6, IPv6-
to-IPv4, and IPv6-to-IPv6 translations.
TURN relays performing any translation MUST translate the IP
addresses and port numbers of the packets based on the allocation's
state information as specified in [I-D.ietf-behave-turn]. TURN
relays performing an IPv4-to-IPv6 or an IPv6-to-IPv4 translations
SHOULD translate other header fields following SIIT (Stateless IP/
ICMP Translation Algorithm) as described in Sections 3 and 4 of
[RFC2765] respectively. Additionally, when the outgoing packet's
size exceeds the outgoing link's MTU, the relay needs to generate an
ICMP error (ICMPv6 Packet Too Big or ICMPv4 Destination Unreachable)
reporting the MTU size. If the packet is being sent to the peer, the
relay SHOULD reduce the MTU reported in the ICMP message by 48 bytes
to allow room for the overhead of a Data indication.
Note that the use of SIIT is at the "should" level. Having the
use of SIIT at the "should" level instead of at the "must" level
makes it possible to use different translation algorithms that may
be developed in the future.
A TURN relay performing an IPv6-to-IPv6 translation translates other
Camarillo & Novo Expires May 2, 2009 [Page 6]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
header fields per the following rules:
Flow Label: the relay should consider that it is handling two
different IPv6 flows. Therefore, the Flow label [RFC3697] SHOULD
NOT be copied as part of the translation. The relay SHOULD set
the Flow label to 0. The relay MAY choose to set the Flow label
to a different value if it supports [RFC3697].
Hop Limit: the relay MUST act as a regular router with respect to
decrementing the Hop Limit and generating an ICMPv6 error if it
reaches zero.
Fragmentation: If the incoming packet did not include a Fragment
header and the outgoing packet size does not exceed the outgoing
link's MTU, the relay MUST send the outgoing packet without a
Fragment header.
If the incoming packet did not include a Fragment header and the
outgoing packet size exceeds the outgoing link's MTU, the delay
MUST drop the outgoing packet and send an ICMP message of type 2
code 0 ("Packet too big") to the sender of the incoming packet.
If the packet is being sent to the peer, the relay MUST reduce the
MTU reported in the ICMP message by 48 bytes to allow room for the
overhead of a Data indication.
If the incoming packet included a Fragment header and the outgoing
packet size (with a Fragment header included) does not exceed the
outgoing link's MTU, the relay MUST send the outgoing packet with
a Fragment header. The relay MUST set the fields of the Fragment
header as appropriate for a packet originating from the server.
If the incoming packet included a Fragment header and the outgoing
packet size exceeds the outgoing link's MTU, the relay MUST
fragment the outgoing packet into fragments of no more than 1280
bytes. The relay MUST set the fields of the Fragment header as
appropriate for a packet originating from the server.
Extension Headers: the relay SHOULD send outgoing packet without any
IPv6 extension headers, with the exception of the Fragmentation
header as described above.
7. 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 TURN are
Camarillo & Novo Expires May 2, 2009 [Page 7]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
applicable to this document as well.
8. IANA Considerations
The IANA is requested to register the following values under the STUN
Attributes registry and under the STUN Response Code Registry.
8.1. New STUN Attribute Registry
0x0017: REQUESTED-ADDRESS-TYPE
8.2. New STUN Response Code Registry
440 Address Family not Supported
9. Acknowledgements
The authors would like to thank Alfred E. Heggestad, Remi Denis-
Courmont, and Philip Matthews for their feedback on this document.
10. Normative References
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-18 (work in progress),
July 2008.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-09 (work in progress), July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
Camarillo & Novo Expires May 2, 2009 [Page 8]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
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 2, 2009 [Page 9]
Internet-Draft TURN Extension for IPv4/IPv6 transition October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Camarillo & Novo Expires May 2, 2009 [Page 10]
