diff options
Diffstat (limited to 'doc/rfc/rfc6156.txt')
| -rw-r--r-- | doc/rfc/rfc6156.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc6156.txt b/doc/rfc/rfc6156.txt new file mode 100644 index 0000000..42aa9cd --- /dev/null +++ b/doc/rfc/rfc6156.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Camarillo +Request for Comments: 6156 O. Novo +Category: Standards Track Ericsson +ISSN: 2070-1721 S. Perreault, Ed. + Viagenie + April 2011 + + + Traversal Using Relays around NAT (TURN) Extension for IPv6 + +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 is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6156. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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 Simplified BSD License. + + + +Camarillo, et al. Standards Track [Page 1] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + +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 . . . . . . . . . . . . 6 + 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 . . . . . . . . . . . . . . . . 10 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9.1. Tunnel Amplification Attack . . . . . . . . . . . . . . . 11 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. New STUN Attribute . . . . . . . . . . . . . . . . . . . . 12 + 10.2. New STUN Error Codes . . . . . . . . . . . . . . . . . . . 13 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 2] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + +1. Introduction + + Traversal Using Relays around NAT (TURN) [RFC5766] 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 [RFC5766] 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 an 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 + several allocation requests (one allocation request per relayed + transport address). + + + +Camarillo, et al. Standards Track [Page 3] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + + 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 [RFC5766]. + +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 [RFC5766]. + + 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 + + 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. + + + + + +Camarillo, et al. Standards Track [Page 4] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + + 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 420 (Unknown Attribute) response code. 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 [RFC5766], 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 + returns 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. + + + + +Camarillo, et al. Standards Track [Page 5] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + +4.2.1. Unsupported Address Family + + This document defines the following new error response code: + + 440 (Address Family not Supported): The server does 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 [RFC5766]. + +5.1. Sending a Refresh Request + + To perform an allocation refresh, the client generates a Refresh + Request as described in Section 7.1 of [RFC5766]. 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 [RFC5766]. + +6.1. Sending a CreatePermission Request + + The client MUST only include XOR-PEER-ADDRESS attributes with + addresses of the same address family as that of the relayed transport + address for the allocation. + + + + + + + + + +Camarillo, et al. Standards Track [Page 6] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + +6.2. Receiving a CreatePermission Request + + If an XOR-PEER-ADDRESS attribute contains an address of an address + family different than that of 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 that of the relayed transport + address of the allocation. + +7. Channels + + The behavior specified here affects the processing defined in Section + 11 of [RFC5766]. + +7.1. Sending a ChannelBind Request + + The client MUST only include an XOR-PEER-ADDRESS attribute with an + address of the same address family as that of 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 that of 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 [RFC5766] 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 [RFC5766]. This + document addresses IPv4-to-IPv6, IPv6-to-IPv4, and IPv6-to-IPv6 + translations. + + + + + + + +Camarillo, et al. Standards Track [Page 7] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + + 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 [RFC5766]. The following sections + specify how to translate other header fields. + + As discussed in Section 2.6 of [RFC5766], translations in TURN are + designed so that a TURN server can be implemented as an application + that runs in "user-land" 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 4 of [RFC6145]. + + 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 the IPv6 Flow Label field [RFC3697]. + + Alternate behavior: the relay sets the Flow label to the default + value for outgoing packets. + + Hop Limit + + Preferred behavior: as specified in Section 4 of [RFC6145]. + + Alternate behavior: the relay sets the Hop Limit to the default + value for outgoing packets. + + Fragmentation + + Preferred behavior: as specified in Section 4 of [RFC6145]. + + Alternate behavior: the relay assembles incoming fragments. The + relay follows its default behavior to send outgoing packets. + + + + +Camarillo, et al. Standards Track [Page 8] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + + For both preferred and alternate behavior, the DONT-FRAGMENT + attribute ([RFC5766], Section 14.8) MUST be ignored by the server. + + Extension Headers + + Preferred behavior: the relay sends the outgoing packet without + any IPv6 extension headers, with the exception of the Fragment + 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 the IPv6 Flow Label field [RFC3697]. + + Alternate behavior: the relay sets the Flow label to the default + value for outgoing packets. + + Hop Limit + + 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 sends an ICMP message of Type 2, + Code 0 ("Packet too big") to the sender of the incoming packet. + + + + + +Camarillo, et al. Standards Track [Page 9] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + + 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 the outgoing packet without + any IPv6 extension headers, with the exception of the Fragment + Header as described above. + + Alternate behavior: same as preferred. + +8.3. IPv6-to-IPv4 Translations + + Type of Service and Precedence + + Preferred behavior: as specified in Section 5 of [RFC6145]. + + 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 5 of [RFC6145]. + + Alternate behavior: the relay sets the Time to Live to the default + value for outgoing packets. + + + + + + +Camarillo, et al. Standards Track [Page 10] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + + Fragmentation + + Preferred behavior: as specified in Section 5 of [RFC6145]. + 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 that 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 + monitoring policies. + + The loop attack described in [RFC5766], 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 + [RFC5766] 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 these 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 + + + +Camarillo, et al. Standards Track [Page 11] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + + 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 that the tunnel endpoint will drop. + + The amplification potential here is limited by the MTU, so it's not + 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 + + IANA registered the following values under the "STUN Attributes" + registry and under the "STUN Error Codes" registry. + +10.1. New STUN Attribute + + 0x0017: REQUESTED-ADDRESS-FAMILY + + + + + +Camarillo, et al. Standards Track [Page 12] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + +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 + + [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. + + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using + Relays around NAT (TURN): Relay Extensions to Session + Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. + + [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation + Algorithm", RFC 6145, April 2011. + +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. + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 13] + +RFC 6156 TURN Extension for IPv4/IPv6 Transition April 2011 + + +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 + + + Simon Perreault (editor) + Viagenie + 2600 boul. Laurier, suite D2-630 + Quebec, QC G1V 2M2 + Canada + + Phone: +1 418 656 9254 + EMail: simon.perreault@viagenie.ca + URI: http://www.viagenie.ca + + + + + + + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 14] + |