Traversal Using Relays around NAT (TURN) Extension for IPv6
draft-ietf-behave-turn-ipv6-11
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6156.
|
|
|---|---|---|---|
| Authors | Gonzalo Camarillo , Simon Perreault , Oscar Novo | ||
| Last updated | 2015-10-14 (Latest revision 2010-07-08) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6156 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | David Harrington | ||
| IESG note | |||
| Send notices to | (None) |
draft-ietf-behave-turn-ipv6-11
BEHAVE G. Camarillo
Internet-Draft O. Novo
Intended status: Standards Track Ericsson
Expires: January 9, 2011 S. Perreault, Ed.
Viagenie
July 8, 2010
Traversal Using Relays around NAT (TURN) Extension for IPv6
draft-ietf-behave-turn-ipv6-11
Abstract
This document adds IPv6 support to Traversal Using Relays around NAT
(TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6,
and IPv6-to-IPv4 relaying. This document defines the REQUESTED-
ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY
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).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 9, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Camarillo, et al. Expires January 9, 2011 [Page 1]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
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-FAMILY Attribute . . . . . . . . 4
4.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5
4.2.1. Unsupported Address Family . . . . . . . . . . . . . . 6
4.3. Receiving an Allocate Error Response . . . . . . . . . . . 6
5. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 6
5.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6
5.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6
6. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Sending a CreatePermission Request . . . . . . . . . . . . 7
6.2. Receiving a CreatePermission request . . . . . . . . . . . 7
6.2.1. Peer Address Family Mismatch . . . . . . . . . . . . . 7
7. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 7
7.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 7
8. Packet Translations . . . . . . . . . . . . . . . . . . . . . 7
8.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . . 8
8.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . . 9
8.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Tunnel Amplification Attack . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. New STUN Attribute . . . . . . . . . . . . . . . . . . . . 13
10.2. New STUN Error Codes . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Camarillo, et al. Expires January 9, 2011 [Page 2]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
1. Introduction
Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] is a
protocol that allows for an element behind a NAT to receive incoming
data over UDP or TCP. It is most useful for elements behind NATs
without Endpoint-Independent Mapping [RFC4787] that wish to be on the
receiving end of a connection to a single peer.
The base specification of TURN [I-D.ietf-behave-turn] only defines
IPv4-to-IPv4 relaying. This document adds IPv6 support to TURN,
which includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying.
This document defines the REQUESTED-ADDRESS-FAMILY 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 new error response codes.
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-FAMILY attribute. TURN can run over UDP and TCP,
and it allows for a client to request address/port pairs for
receiving both UDP and TCP.
After the request has been successfully authenticated, the TURN
server allocates a transport address of the type indicated in the
REQUESTED-ADDRESS-FAMILY attribute. This address is called the
relayed transport address.
The TURN server returns the relayed transport address in the response
to the Allocate Request. This response contains a XOR-RELAYED-
ADDRESS attribute indicating the IP address and port that the server
allocated for the client.
TURN servers allocate a single relayed transport address per
allocation request. Therefore, Allocate Requests cannot carry more
than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client
that wishes to allocate more than one relayed transport address at a
TURN server (e.g., an IPv4 and an IPv6 address) needs to perform
Camarillo, et al. Expires January 9, 2011 [Page 3]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
several allocation requests (one allocation request per relayed
transport address).
A TURN server that supports a set of address families is assumed to
be able to relay packets between them. If a server does not support
the address family requested by a client, the server returns a 440
(Address Family not Supported) error response.
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 relayed transport address of a
specific address type includes a REQUESTED-ADDRESS-FAMILY attribute,
which is defined in Section 4.1.1, in the Allocate Request that it
sends to the TURN server. Clients MUST NOT include more than one
REQUESTED-ADDRESS-FAMILY attribute in an Allocate Request. The
mechanisms to formulate an Allocate Request are described in Section
6.1 of [I-D.ietf-behave-turn].
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an
Allocate request that contains a RESERVATION-TOKEN attribute.
4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute
The REQUESTED-ADDRESS-FAMILY 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-FAMILY 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-FAMILY Attribute
Camarillo, et al. Expires January 9, 2011 [Page 4]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017.
As specified in [RFC5389], 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
[RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6
addresses.
Reserved: at this point, the 24 bits in the reserved field MUST 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
Once a server has verified that the request is authenticated and has
not been tampered with, the TURN server processes the Allocate
request. If it contains both a RESERVATION-TOKEN and a REQUESTED-
ADDRESS-FAMILY, the server replies with a 400 (Bad Request) Allocate
Error Response. Following the rules in [RFC5389], if the server does
not understand the REQUESTED-ADDRESS-FAMILY 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-FAMILY attribute.
If the server can successfully process the request, it allocates a
transport address for the TURN client, called the relayed 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 XOR-RELAYED-ADDRESS attribute is set to the relayed transport
address.
The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address
and port. It is encoded in the same way as the XOR-MAPPED-ADDRESS
[RFC5389].
If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST
allocate an IPv4 relayed transport address for the TURN client. If
allocation of IPv4 addresses is disabled by local policy, the server
Camarillo, et al. Expires January 9, 2011 [Page 5]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
returns a a 440 (Address Family not Supported) Allocate Error
Response.
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 440 (Address Family not
Supported) response code, which is defined in Section 4.2.1.
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.
4.3. Receiving an Allocate Error Response
If the client receives an Allocate error response with the 440
(Unsupported Address Family) error code, the client MUST NOT retry
its request.
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 an allocation 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-FAMILY attribute in its
Refresh Request.
5.2. Receiving a Refresh Request
If a server receives a Refresh Request with a REQUESTED-ADDRESS-
FAMILY attribute, and the attribute's value doesn't match the address
family of the allocation, the server MUST reply with a 443 (Peer
Address Family Mismatch) Refresh Error Response.
6. CreatePermission
The behavior specified here affects the processing defined in Section
9 of [I-D.ietf-behave-turn].
Camarillo, et al. Expires January 9, 2011 [Page 6]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
6.1. Sending a CreatePermission Request
The client MUST only include XOR-PEER-ADDRESS attributes with
addresses of the same address family as the relayed transport address
for the allocation.
6.2. Receiving a CreatePermission request
If an XOR-PEER-ADDRESS attribute contains an address of an address
family different than the relayed transport address for the
allocation, the server MUST generate an error response with the 443
(Peer Address Family Mismatch) response code, which is defined in
Section 6.2.1.
6.2.1. Peer Address Family Mismatch
This document defines the following new error response code:
443 (Peer Address Family Mismatch): A peer address was of a
different address family than the relayed transport address of the
allocation.
7. Channels
The behavior specified here affects the processing defined in Section
11 of [I-D.ietf-behave-turn].
7.1. Sending a ChannelBind Request
The client MUST only include a XOR-PEER-ADDRESS attribute with an
address of the same address family as the relayed transport address
for the allocation.
7.2. Receiving a ChannelBind Request
If the XOR-PEER-ADDRESS attribute contains an address of an address
family different than the relayed transport address for the
allocation, the server MUST generate an error response with the 443
(Peer Address Family Mismatch) response code, which is defined in
Section 6.2.1.
8. 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
Camarillo, et al. Expires January 9, 2011 [Page 7]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
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]. The
following sections specify how to translate other header fields.
As discussed in Section 2.6 of [I-D.ietf-behave-turn], translations
in TURN are designed so that a TURN server can be implemented as an
application that runs in userland under commonly available operating
systems and that does not require special privileges. The
translations specified in the following sections follow this
principle.
The descriptions below have two parts: a preferred behavior and an
alternate behavior. The server SHOULD implement the preferred
behavior. Otherwise, the server MUST implement the alternate
behavior and MUST NOT do anything else.
8.1. IPv4-to-IPv6 Translations
Traffic Class
Preferred behavior: as specified in Section 3 of
[I-D.ietf-behave-v6v4-xlate].
Alternate behavior: the relay sets the Traffic Class to the
default value for outgoing packets.
Flow Label
Preferred behavior: The relay sets the Flow label to 0. The relay
can choose to set the Flow label to a different value if it
supports [RFC3697].
Alternate behavior: the relay sets the Flow label to the default
value for outgoing packets.
Hop Limit
Camarillo, et al. Expires January 9, 2011 [Page 8]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
Preferred behavior: as specified in Section 3 of
[I-D.ietf-behave-v6v4-xlate].
Alternate behavior: the relay sets the Hop Limit to the default
value for outgoing packets.
Fragmentation
Preferred behavior: as specified in Section 3 of
[I-D.ietf-behave-v6v4-xlate].
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute ([I-D.ietf-behave-turn], Section 14.8) MUST be ignored
by the server.
Extension Headers
Preferred behavior: the relay sends outgoing packet without any
IPv6 extension headers, with the exception of the Fragmentation
header as described above.
Alternate behavior: same as preferred.
8.2. IPv6-to-IPv6 Translations
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.
Preferred behavior: The relay sets the Flow label to 0. The relay
can choose to set the Flow label to a different value if it
supports [RFC3697].
Alternate behavior: the relay sets the Flow label to the default
value for outgoing packets.
Hop Limit
Camarillo, et al. Expires January 9, 2011 [Page 9]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
Preferred behavior: the relay acts as a regular router with
respect to decrementing the Hop Limit and generating an ICMPv6
error if it reaches zero.
Alternate behavior: the relay sets the Hop Limit to the default
value for outgoing packets.
Fragmentation
Preferred behavior: 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 sends 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 relay
drops 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 reduces 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 sends the outgoing packet with a
Fragment header. The relay sets 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 sets the fields of the Fragment header as
appropriate for a packet originating from the server.
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server.
Extension Headers
Preferred behavior: the relay sends outgoing packet without any
IPv6 extension headers, with the exception of the Fragmentation
header as described above.
Camarillo, et al. Expires January 9, 2011 [Page 10]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
Alternate behavior: same as preferred.
8.3. IPv6-to-IPv4 Translations
Type of Service and Precedence
Preferred behavior: as specified in Section 4 of
[I-D.ietf-behave-v6v4-xlate].
Alternate behavior: the relay sets the Type of Service and
Precedence to the default value for outgoing packets.
Time to Live
Preferred behavior: as specified in Section 4 of
[I-D.ietf-behave-v6v4-xlate].
Alternate behavior: the relay sets the Time to Live to the default
value for outgoing packets.
Fragmentation
Preferred behavior: as specified in Section 4 of
[I-D.ietf-behave-v6v4-xlate]. 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) 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.
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server.
9. Security Considerations
Translation between IPv4 and IPv6 creates a new way for clients to
obtain IPv4 or IPv6 access which they did not have before. For
example, an IPv4-only client having access to a TURN server
implementing this specification is now able to access the IPv6
internet. This needs to be considered when establishing security and
Camarillo, et al. Expires January 9, 2011 [Page 11]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
monitoring policies.
The loop attack described in [I-D.ietf-behave-turn] Section 17.1.7
may be more easily done in cases where address spoofing is easier to
accomplish over IPv6. Mitigation of this attack over IPv6 is the
same as for IPv4.
All the security considerations applicable to STUN [RFC5389] and TURN
[I-D.ietf-behave-turn] are applicable to this document as well.
9.1. Tunnel Amplification Attack
An attacker might attempt to cause data packets to loop numerous
times between a TURN server and a tunnel between IPv4 and IPv6. The
attack goes as follows.
Suppose an attacker knows that a tunnel endpoint will forward
encapsulated packets from a given IPv6 address (this doesn't
necessarily need to be the tunnel endpoint's address). Suppose he
then spoofs two packets from this address:
1. An allocate request asking for a v4 address, and
2. A ChannelBind request establishing a channel to the IPv4 address
of the tunnel endpoint
Then he has set up an amplification attack:
o The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it
to the tunnel endpoint
o The tunnel endpoint will decapsulate packets from the v4 interface
and send them to v6
So if the attacker sends a packet of the following form...
IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP: <ports>
TURN: <channel id>
IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP: <ports>
TURN: <channel id>
IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP: <ports>
TURN: <channel id>
...
Then the TURN relay and the tunnel endpoint will send it back and
forth until the last TURN header is consumed, at which point the TURN
relay will send an empty packet, which the tunnel endpoint will drop.
The amplification potential here is limited by the MTU, so it's not
Camarillo, et al. Expires January 9, 2011 [Page 12]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
huge: IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one
amplification out of a 1500-byte packet. But the attacker could
still increase traffic volume by sending multiple packets or by
establishing multiple channels spoofed from different addresses
behind the same tunnel endpoint.
The attack is mitigated as follows. It is RECOMMENDED that TURN
relays not accept allocation or channel binding requests from
addresses known to be tunneled, and that they not forward data to
such addresses. In particular, a TURN relay MUST NOT accept Teredo
or 6to4 addresses in these requests.
10. IANA Considerations
The IANA is requested to register the following values under the STUN
Attributes registry and under the STUN Error Codes registry.
10.1. New STUN Attribute
0x0017: REQUESTED-ADDRESS-FAMILY
10.2. New STUN Error Codes
440 Address Family not Supported
443 Peer Address Family Mismatch
11. Acknowledgements
The authors would like to thank Alfred E. Heggestad, Dan Wing, Magnus
Westerlund, Marc Petit-Huguenin, Philip Matthews, and Remi Denis-
Courmont for their feedback on this document.
12. References
12.1. Normative References
[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-16 (work in progress), July 2009.
[I-D.ietf-behave-v6v4-xlate]
Camarillo, et al. Expires January 9, 2011 [Page 13]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-10 (work in
progress), February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
12.2. Informative References
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
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, et al. Expires January 9, 2011 [Page 14]
Internet-Draft TURN Extension for IPv4/IPv6 transition July 2010
Simon Perreault (editor)
Viagenie
2600 boul. Laurier, suite 625
Quebec, QC G1V 4W1
Canada
Phone: +1 418 656 9254
Email: simon.perreault@viagenie.ca
URI: http://www.viagenie.ca
Camarillo, et al. Expires January 9, 2011 [Page 15]