tram A. Wang Internet-Draft China Telecom Intended status: Standards Track B. Liu Expires: September 10, 2015 Huawei Technologies March 9, 2015 A Lightweight TURN Architecture and Specification (TURN-Lite) draft-wang-tram-turnlite-02 Abstract This document proposes a new relay-based NAT traversal architecture called TURN-Lite which could simplify the data communication process between two hosts that locates behind some non-BEHAVE compliant [RFC4787] [RFC5382] NAT devices. The key mechanism in TURN-Lite is the newly defined "Couple" operation (using STUN [RFC5389] message format) which allows the TURN-Lite servers to be easily incorporated into existing CGN devices/CDN nodes which are already deployed within the network in a distributed manner. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 10, 2015. Copyright Notice Copyright (c) 2015 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 Wang & Liu Expires September 10, 2015 [Page 1] Internet-Draft draft-wang-tram-turnlite-02 March 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Relationship with TURN . . . . . . . . . . . . . . . . . 5 2. Requirements Language and Terminology . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Reference Architecture of TURN-Lite . . . . . . . . . . . 6 3.2. Solution Rationale . . . . . . . . . . . . . . . . . . . 7 3.2.1. Relay Selector Reflection and Selection . . . . . . . 7 3.2.2. Relay Selection . . . . . . . . . . . . . . . . . . . 7 3.2.3. Forming "Couple" Command . . . . . . . . . . . . . . 8 3.2.4. Data Relay . . . . . . . . . . . . . . . . . . . . . 9 4. New STUN Method Definition . . . . . . . . . . . . . . . . . 9 4.1. Couple Operation . . . . . . . . . . . . . . . . . . . . 9 4.2. Couple Operation Packet Format . . . . . . . . . . . . . 10 5. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Procedures of Communication Traversing Symmetric NATs . . 11 5.2. Procedures of IPv4 and IPv6 Host Communication . . . . . 12 6. TURN-Lite Benefits . . . . . . . . . . . . . . . . . . . . . 13 7. TURN-Lite Deployment Considerations . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction 1.1. Motivations This document proposes a new relay-based NAT traversal architecture called TURN-Lite based on the following motivations. 1) Leverage ISPs' infrastructures Currently, the deployment of TURN [RFC5766] is very limited and most of the application providers use their own platform to transfer the data between two hosts that behind NATs and to translate the Wang & Liu Expires September 10, 2015 [Page 2] Internet-Draft draft-wang-tram-turnlite-02 March 2015 communication packets between two hosts in different address families. The relay devices deployed centrally by various application providers often lead to inefficient data transmit between two hosts. The relay devices must deal with complex network layer problems which the application providers are not familiar with. On the other hand, service providers have deployed many CGN devices/ CDN nodes in a distributed manner within their networks. If the service providers can use these CGN devices/CDN nodes as the relay devices for communication between two hosts behind NATs or that from different address family, and open their data translation/forwarding capability to the application providers, the host to host communication will be more efficient. Given most of the CGNs are capable of translating packets between IPv4 and IPv6, the adoption of IPv6 technology will also be accelerated. 2) Simplify the communication procedures TURN-Lite needs less communication procedures than TURN of which the procedures are considered very complex to be integrated into the ISPs' infrastructure, for example: o TURN solution has to closely interact with ICE Within current TURN solution, there are scenarios where the ICE or other NAT-hole punching procedures must be included for the success of communication via TURN servers. The key point is that TURN allocates different relay transport address-port pairs for different hosts. Each client must first use TURN allocation request to get their transport relay address-port pairs, and then must use ICE procedure (connectivity check) or other similar signaling to punch holes for these transport relay addresses on the alongside NAT devices. Or else the relayed UDP/TCP packet will be blocked. Even with the above procedures, there still exists some risks that the packets be rejected by TURN server due to the permission list that created by client via "CreatePermission Request" before it sending data to the peer. In order to mitigate such issues, current TURN solution requires the TURN servers only check the IP address part of the relay transport address, and ignore the port portion. But this will again introduce some attack risks because different host may share Wang & Liu Expires September 10, 2015 [Page 3] Internet-Draft draft-wang-tram-turnlite-02 March 2015 one public IP address when the CGN device is deployed within network. o IPv4/IPv6 Relay Address/Port Reservation and Allocation Another drawback of different relay transport addresses for different host is that the TURN server must reserve some IPv4/ IPv6 address block for the allocation and plan the TCP/UDP port usage for each host. When TURN servers are deployed in a distribute manner (For example when they are incorporated into the CGN devices), there will be much coordination work to do for the address/port reservation and allocation on the TURN servers. o Simultaneous TCP/UDP connections burden on TURN server Current TURN solution requires the TURN servers to open and listen on many TCP/UDP ports at the same time, and the number of sessions is proportional to the number of the hosts under one relay server.(Under TURN solution for TCP [RFC6062], each host requires two connections to the TURN server). This will increase the burden on TURN server and the complexity to incorporate them into the CGN/CDN devices. o Different procedures for TCP/UDP communication Current TURN solution adopts different procedures for the TCP and UDP communication channel. So for one TURN server to provide the TCP/UDP relay function, it must implement two different procedures. This again increases the complexity of the TURN server implementation, especially in CGN devices. o Communication complexity between two different TURN servers Current TURN solution cannot assure two hosts select the same TURN server, and then it must deal with the communication situation between two different TURN servers. This scenario has not been covered by the current TURN related drafts. The communication complexity of different TURN server arises from the communication procedures, the transfer of the relay addresses of the two TURN servers and the permission list creation etc. On the other hand, because the hosts select their own TURN server, there is no mechanism to assure the relayed path is most optimal for them. The application latency will be increased when this occurs. Wang & Liu Expires September 10, 2015 [Page 4] Internet-Draft draft-wang-tram-turnlite-02 March 2015 TURN-Lite architecture and solution will simplify the above mentioned complexity and make the TCP/UDP data relay function be easily incorporated into the existing distributed CGN devices or other kinds distributed devices i.e. the CDN nodes etc. 1.2. Relationship with TURN This document doesn't intent to replace TURN with TURN-Lite, but consider TURN-Lite as a complementary solution along with TURN for some specific scenarios. If one SP wants to open its infrastructure to accelerate their customers' (mainly regarding to application providers) client-to- client communications within the SP's domain, TURN-Lite could be a good candidate. 2. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119] key words. o Application Provider: the service providers who provide client to client communications through the Internet. E.g. VoIP service providers, instant message service providers etc. o Relay Selector: which is in charge of selecting a proper relay device (CGN or CDN nodes) for the communicating hosts behind NATs. Normally, the RS is a function located in the network's management plane and possibly a part of the NMS server o TURN-Lite: lightweight TURN architecture. The word "lightweight" is in the perspective of an application provider. o TURN-Lite Client: the TURN-Lite entity that deployed in the application providers' networks; be responsible for TURN-Lite signaling/control interactions with the TURN-Lite servers. o TURN-Lite Server: the TURN-Lite entity that deployed in the ISP's networks; be mainly responsible for the data relay between an application providers' clients. Normally, the TURN-Lite servers collated with the CGNs (Carrier Grade NATs) within the service provider. Wang & Liu Expires September 10, 2015 [Page 5] Internet-Draft draft-wang-tram-turnlite-02 March 2015 3. Solution Overview 3.1. Reference Architecture of TURN-Lite +--------------+ +--------------+ +--------------+ |App Provider 1| |App Provider 2|...|App Provider N| +--------------+ +-------+------+ +--------------+ \ | / \ | / \ | / \ | / \ | / \ | / +-----------+----------+ | RS | | (Relay Selector) | +-----------+----------+ / | \ / | \ / | \ / | \ +------------------+ +---------+--------+ +------------------+ | CGN-1 | | CGN-2 | | CGN-N | |(TURN-Lite Server)| |(TURN-Lite Server)|... |(TURN-Lite Server)| +-------------+----+ +------------------+ +----+-------------+ | | | | | | +----+----+ +----+----+ | | | | | NAT | | NAT | | | | | +----+----+ +----+----+ | | +----+---+ +---+----+ | Host 1 | | Host 2 | |(v4/v6) | |(v4/v6) | +--------+ +--------+ (TURNLite Client) (TURNLite Client) Fig. 3-1: TURN-Lite Arhitecture As depicted in above figure, the application clients that located on hosts act as the TURN-Lite clients while the CGNs act as TURN-Lite Servers. There is a Relay Selector (RS) for choosing a proper CGN to relay traffic between the two hosts. In practice, the RS could be a dedicated server or a function located in the management plane servers such as NMS server. Wang & Liu Expires September 10, 2015 [Page 6] Internet-Draft draft-wang-tram-turnlite-02 March 2015 RS has the intelligent route selection capability to choose a proper CGN for a given host pair. RS sends the data relay indication to the selected CGN devices/CDN node via the newly defined "Couple" method. BEHAVE compliant and non-BEHAVE compliant NAT traverse [RFC4787] [RFC5382] is supported in TURN-Lite. IPv6 and IPv4 host communication is also supported. 3.2. Solution Rationale The solution could be briefly described in the following sections. 3.2.1. Relay Selector Reflection and Selection Each host that wants to communicate with the other host should send STUN message to the RS (Relay Selector), and get their reflex addresses to the RS (here we refer to REFLX-RS). The application provider needs to select a suitable RS and informs it to the hosts (e.g. via application specific client-server protocol). The detailed RS selection mechanism and criteria are out of the scope of this document, but some general considerations are as the following. - If the hosts locate in the same ISP/administrative domain, then the RS selection is fairly easy since normally there is only one RS in one ISP; even there are multiple RSes in one ISP, the application provider should also be able to select a suitable RS based on the addresses of the two hosts. - If the hosts locate in two ISPs/administrative domains (assuming both of the ISPs providing TURN-Lite service to the application provider), the application provider can select one RS based on pre-defined policies (the simplest way is just arbitrarily choosing one RS in one of the ISPs). 3.2.2. Relay Selection Each host will report its REFLX-RS address to its application server. If two hosts want to communicate, the application server will send the two hosts' REFLX-RS addresses to the selected RS, to let the RS select one appropriate relay device to relay the traffic. Generally, the RS can select the appropriate relay device based solely on the REFLX-RS addresses of these two hosts, for example, select one relay device that locate in the middle of the communication path. This approach is possible since the relay Wang & Liu Expires September 10, 2015 [Page 7] Internet-Draft draft-wang-tram-turnlite-02 March 2015 behavior is within one ISP's domain that the RS could be possible to learn the knowledge of all CGNs (relays) within that domain. The selection criteria can also be expanded to include other factors, such as the privacy concern of the communication peers, the linkage usage information between the host and the relay device etc. For example, RS can select one relay device that locates far from the communication peer to hide the location of the peer. This might sacrifice the communication efficiency but increase the protection of the host privacy. Anyway, RS has more flexible control over the relay selection, upon the requirement of communication hosts, or the consideration of relay service provider. After the relay device selection, the RS will respond the IP address of the selected relay device to the communication peer, together with the well known port that used by every relay device. The combination of this relay IP address and the well-known port form the relay transport address of the communication peers, each peer will use this relay transport address to communicate. When two hosts located within one administration domain, the centralized relay point selection and control architecture can easily achieve one low latency communication path because it knows the whole network condition of its own. When two hosts located within different administration domains, the TURN-Lite solution will also work except that some end-to-end communication efficiency might be sacrificed unless there is some coordination between these two administration domains. 3.2.3. Forming "Couple" Command Each host will send again one STUN message to the selected relay transport address, get the new reflex address(here we refer to REFLX- Relay) to the selected relay device, and reports it to the RS, together with the previous reflex address to the RS (which is REFLX- RS). The RS will use the REFLX-RS addresses to find out which two peers will communicate (such communication pair information is gotten from Section 3.2.2). RS will retrieve the corresponding REFLX-Relay address of the communication peer, forms the "Couple" command based on such information, and sends the "Couple" command to the selected relay transport address. Upon receiving the "Couple" command, the relay device will add one item to its forwarding table. The forwarding table will bind the reflex addresses of the two peers, the required transport protocol and other additional information. Wang & Liu Expires September 10, 2015 [Page 8] Internet-Draft draft-wang-tram-turnlite-02 March 2015 3.2.4. Data Relay Each host will then send the data traffic directly to the unique relay transport address. The source address of this packet will be changed by the alongside NAT devices that located between the host and the relay device. When this packet arrives to the relay address, its source address will be one of the RFLEX-Relay addresses. The relay device will search the forwarding table that formed in Section 3.2.3. If the REFLX-Relay address in one item match the source address of the received packet, then the other REFLX-Relay address will be retrieved and be used as the destination address of the application packet, the packet's source address will be changed to the relay transport address. After the conversion, the packet will be sent by the relay device. This packet will be routed to the corresponding peer, according to its REFLX-Relay address. The application return packet will be sent again back to the same relay device via the relay transport address. The similar search process and convert work will be done by the relay device. The converted return packet will then be routed to the packet originator. 4. New STUN Method Definition In order to let the CGN device to build one Couple item upon the request of RS, it is needed to define one general Couple message to transfer the related information. 4.1. Couple Operation The Couple request defines the relationship between two TCP or UDP half-connections, the translation rule that converts both the source address and destination address of pass through packet in both directions. Couple Opcode: It defines how to bind two half-connections that ends at the CGN's well-known relay transport address together. When CGN device receives the Couple request, it will create one map table item that includes the reflex IP address/port [REFLX-Relay] of both hosts that lies behind the NAT device and the protocol that the host will use to communicate. When the CGN device receives the packet from one host, it will use the reflex source address/port to lookup the map table item; converts the source address/port of this packet to the relay transport address Wang & Liu Expires September 10, 2015 [Page 9] Internet-Draft draft-wang-tram-turnlite-02 March 2015 of the CGN device and converts the destination address/port of this packet to the reflex address [REFLX-Relay] that results from the map table lookup action. The converted packet will be routed to NAT side of the other host, converted by the NAT device and then to the other host. The return packet will be delivered to the relay transport address of CGN/CDN device and be converted in reverse accordingly. 4.2. Couple Operation Packet Format The Couple Opcode allows RS to create a new explicit couple table on the CGN device(TURN-Lite Server), instructs the CGN device to accomplish the related translation work. The following diagram shows the Opcode layout for the Couple Opcode request/response format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STUN Message Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transaction ID(96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | XOR-MAPPED-ADDRESS attribute | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | XOR-PEER-ADDRESS attribute | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REQUESTED-TRANSPORT attribute | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ STUN Message Type Couple method: value TBD. only request/response semantics Decouple method: value TBD. only request/response semantics Length The same definition as STUN prococol [RFC5389] Wang & Liu Expires September 10, 2015 [Page 10] Internet-Draft draft-wang-tram-turnlite-02 March 2015 Magic Cookie The same definition as STUN prococol [RFC5389] Transaction ID The same definition as STUN prococol [RFC5389] XOR-MAPPED-ADDRESS The same definition as STUN prococol [RFC5389]. The value should be the RFLX-Relay address of the host. XOR-PEER-ADDRESS The same definition as TURN prococol [RFC5766]. The value should be the RFLX-Relay address of the peer. REQUESTED-TRANSPORT The same definition as TURN prococol [RFC5766]. the value of the "protocol" fiel should be TCP or UDP. Fig.4-1: Couple Opcode Request/Response Format 5. Detailed Example 5.1. Procedures of Communication Traversing Symmetric NATs When one of the communication hosts located behind the symmetric NAT device, the host-to-host communication must via one relay device. Below are the key procedures of TURN-Lite solution, we use the Fig 3-1 to describe the example. Please note the communication procedures between the hosts and the application server are out of the scope of this document, we only focus on the key procedure proposed by this document. 1. If Host 1 and Host 2 want to communicate with each other, they will send STUN binding message to the RS IPv4 address/port, get their reflex address to RS[REFLX-RS]. 2. RS will select one CGN device to relay the packet, based on the RS addresses information of the two peers. Here we assume it select CGN-1 as the relay device. RS will notify Host 1 and Host 2 of their relay transport address, both will use the same relay IP address/port on CGN-1. 3. Host 1 and Host 2 will send STUN binding message to CGN-1, get their relay address to CGN-1[REFLX-Relay] and report them to RS, together with RS addresses gotten in step 1). Here we assume the [REFLX-Relay] address of Host 1 is 192.0.2.1:7000, and [REFLX- Relay] address of Host 2 is 192.0.2.150:32102. Wang & Liu Expires September 10, 2015 [Page 11] Internet-Draft draft-wang-tram-turnlite-02 March 2015 4. RS will form the "Couple" message, which include mainly the [REFLX-Relay] addresses of Host 1 and Host 2 and their communication protocol, here we assume they use TCP to communicate. 5. Upon receiving the "Couple" message, the CGN-1 device will form one forwarding table that look like below: +-------------------------------------------------------------+ | Reflextive transport | Reflextive transport | Transport| | address of Host1 | address of Host2 | Protocol | +-------------------------|------------------------|----------+ | 192.0.2.1:7000 | 192.0.2.150:32102 | TCP | +-------------------------------------------------------------+ Table 5-1: Couple Table Example (symmetric case) 6. Host1 will send the application data to the relay transport address in CGN-1. 7. CGN device will look up the Couple table, use the source address of received packet(192.0.2.1:7000 in this example) to get the reflex IPv4 address of Host 2. 8. It then will change the source address of the packet to the relay transport address in CGN device, the destination address of this packet to the IPv4 reflex address of Host 2. The translated packet will be forwarded to Host 2. 9. The return traffic will also be sent to the same relay transport address in CGN-1, converted by the CGN device, and sent back to Host 1. 5.2. Procedures of IPv4 and IPv6 Host Communication If Host 1 is one IPv4 node and Host 2 is one IPv6 node. The communication process are similar, except the relay address that is sent to the Host 1 is the IPv4 address of the CGN-1 and the relay address that is sent to the Host 2 is the IPv6 address of the CGN-1. Host 1 and Host 2 will not notice that they are talking to one node that in different address family. The relay device selection process is same as the above example. Here we describe the procedure from step 3. 3. Host 1 and Host 2 will send STUN binding message to CGN-1, get their relay address to CGN-1[REFLX-Relay] and report them to RS, together with RS addresses gotten in step 1). Here we assume the Wang & Liu Expires September 10, 2015 [Page 12] Internet-Draft draft-wang-tram-turnlite-02 March 2015 [REFLX-Relay] address of Host 1 is 192.0.2.1:7000, and [REFLX- Relay] address of Host 2 is 2001:c68:300:105::1[49191]. 4. RS will form the "Couple" message, which include mainly the [REFLX-Relay] addresses of Host 1 and Host 2 and their communication protocol, here we assume they use TCP to communicate. 5. Upon receiving the "Couple" message, the CGN-1 device will form one forwarding table that look like below: +-------------------------------------------------------------+ | Reflextive transport | Reflextive transport | Transport| | address of Host1 | address of Host2 | Protocol | +-------------------------------------------------------------+ | 192.0.2.1:7000 | 2001:c68:300:105::1[49191] UDP | +-------------------------------------------------------------+ Table 5-2: Couple Table Example (different address families case) 6. Host1 will send the application data to the relay transport address in CGN-1. 7. CGN device will look up the Couple table, use the source address of received packet(192.0.2.1:7000 in this example) to get the reflex IPv6 address of Host 2. 8. It then will change the source address of the packet to the relay transport IPv6 address in CGN device, the destination address of this packet to the IPv6 reflex address of Host 2. The translated packet will be forwarded to Host 2. 9. The return traffic will also be sent to the same relay transport address in CGN-1, converted by the CGN device, and sent back to Host 1. 6. TURN-Lite Benefits TURN-LiteTURN-LiteComparing to TURN, TURN-Lite could provide following benefits: o Decoupled from ICE TURN is tightly coupled with ICE. Operations like NAT punching, create permission .etc all require ICE connectivity check packets. Wang & Liu Expires September 10, 2015 [Page 13] Internet-Draft draft-wang-tram-turnlite-02 March 2015 Benefited from the couple operation, TURN-Lite doesn't necessarily need ICE interaction. o Avoid the Create Permission issues in TURN In the TURN-Lite solution, each communication pair will use the same relay server and the same relay address. The relay permission action required by TURN solution is replaced with the "Couple" command. There is no ambiguity for the relay permission because "Couple" command use the ip address and port information of the communication pair simultaneously. There are also no possible attacks due to the loose control of the current TURN permission treaments. o Less Relay Address/Port Consumption and Management TURN-LiteTURN-Lite doesn't need to allocate different address- port pair for each session initiated from the hosts. Thus, it could obviously reduce the resource consumption and the human burden for planning the resource allocation. o Simplified Procedures Theoretically, it requires only two commands to accomplish the relay function, compared with over eight commands that required by TURN solution. Due to every host communicate with the well- known relay address, there is no additional requirement for punching holes in the NAT devices, which is indispensable for the current TURN solution. +-----------+-----------------------+-------------------+ | | TURN Solution | TURN-Lite Solution| |-----------|-----------------------|-------------------| | | 1. Binding | 1. Binding | |Required | 2. Allocate | 2. Couple | |Commands | 3. Send | | | | 4. Data | | | | 5. Channel Bind | | | | 6. Connect | | | | 7. ConnectionBind | | | | 8. ConnectionAttempt| | +-----------+-----------------------+-------------------+ Table 6-1: Procedures comparison between TURN and TURN-Lite o Unified solution for TCP/UDP and IPv4(6)-IPv6(4) data relay Wang & Liu Expires September 10, 2015 [Page 14] Internet-Draft draft-wang-tram-turnlite-02 March 2015 TURN-Lite supports the data relay for the communication between two hosts, uses same mechanism for TCP and UDP transport protocol, even for the communication between different address families. o Support for optimal relay selection Because of the central deployed RS could have the whole network's routing/path knowledge, TURN-Lite is more likely to achieve an optimal relay (TURN-Lite server) selection based on various information such as the reflective transport addresses of the two communicating peers, the link usage information between two peers and the load status of the candidate TURN- Lite servers etc. With the RS's knowledge, TURN-Lite is also more likely to achieve better relay selection for some specific requirements. For example, if one peer wants to hide its ip address to protect its privacy, the RS in TURN-Lite architecture could possibly select one TURN-Lite server that located far away from the host. 7. TURN-Lite Deployment Considerations The TURN-Lite Server can be deployed in distributed manner. The most appropriate devices for incorporating this function are the CGN devices that have been deployed distributed by the service provider. Each distributed TURN-Lite Server has one unique public IPv4/IPv6 transport address. The RS can select the appropriate TURN-Lite Server based on the proximity of the TURN-Lite server with the communication hosts and can also use other criteria to influence the selection procedure, as described in Section 3. 8. Security Considerations The additional requirement of TURN-Lite is authenticating the couple operation from the RS. When the communication channel between the RS and the TURN-Lite server is secured, such security risks can be mitigated accordingly. 9. IANA Considerations This draft requires IANA to allocate following STUN methods: Couple: value TBD. Wang & Liu Expires September 10, 2015 [Page 15] Internet-Draft draft-wang-tram-turnlite-02 March 2015 Decouple: value TBD. 10. Conclusions Currently, the communication between two hosts that located behind NAT devices, especially that behind the symmetric NAT devices is emerging. With the development of IPv6 technology, the communication between two hosts that in different address families needs also be considered. Under the TURN-Lite architecture, the communication requests for IPv4/IPv4, IPv4/IPv6 scenario can be met in one general solution. Such solution can alleviate the burden of various CP/SP to deploy the TURN server by themselves, exploit and open the capabilities of CGN device that deployed by service provider to the third party(CP/SP), make the host-to-host communication more efficient. 11. Acknowledgements Many valuable comments were received from Brandon Williams, Oleg Moskalenko, Jonathan Rosenberg, and Dan Wing etc. This document was produced using the xml2rfc tool [RFC2629]. 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. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [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. 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. Wang & Liu Expires September 10, 2015 [Page 16] Internet-Draft draft-wang-tram-turnlite-02 March 2015 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010. Authors' Addresses Aijun Wang China Telecom No.118,Xizhimenneidajie,Xicheng District Beijing, 100035 P.R. China Email: wangaj@ctbri.com.cn Bing Liu Huawei Technologies Q14, Huawei Campus, No.156 Beiqing Road, Hai-Dian District Beijing, 100095 P.R. China Email: leo.liubing@huawei.com Wang & Liu Expires September 10, 2015 [Page 17]