Netwok Working Group Aijun. Wang Internet Draft China Telecom Intended status: Standard Track July 3,2014 Expires: December 2015 PCP BIND Operation draft-wang-pcp-bind-operation-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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 3, 2009. Copyright Notice Copyright (c) 2014 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 Wang Expires January 3, 2015 [Page 1] Internet-Draft PCP BIND Operation July 2014 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Port Control Protocol[PCP, RFC6887] describes two opcodes between PCP client and PCP server: PCP map opcode and PCP peer opcode. These two opcodes are used mainly for the establishment of map table in NAT devices, to let the incoming packet pass through the NAT devices, reach to the server behind it (map opcode); or build the required map table explicitly in NAT devices (peer opcode). These opcodes are enough for the client-server communication model in general NAT environment, but for client-client communication model, especially that in symmetric NAT environment or in situation that two communication hosts are in different address family, there must exists one relay device, which act the same as PCP server, to forward the communication data. To control the behavior of relay device (similar as PCP server), build the communication channel between two ends via it and open its data forward capability to the third-party partner, it is needed to define one new opcode for PCP protocol. The PCP BIND opcode will bind two communication channels which are ended at PCP server together and make the communication between two hosts behind the symmetric NAT environment, or that between two hosts belong to different address family possible. Such solution is simpler than the current procedures used by TURN. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document ............................ 4 3. Terminology ................................................. 4 4. Communication Scenario ....................................... 4 4.1. Communication Scenario in Symmetric NAT environment ...... 4 4.2. Communication Scenario in different address family ....... 5 5. General Solution ............................................ 6 6. BIND Request ............................................... 10 6.1. BIND Opcode ........................................... 10 6.2. BIND Operation Packet Formats .......................... 11 Fig.6-1: BIND Opcode Request/Response Format ................... 12 7. Security Considerations ..................................... 13 8. IANA Considerations ........................................ 13 9. Conclusions ................................................ 14 10. References ................................................ 14 10.1. Normative References .................................. 14 Expires January 3, 2015 [Page 2] Internet-Draft PCP BIND Operation July 2014 10.2. Informative References ................................ 15 11. Acknowledgments ........................................... 15 1. Introduction With the depletion of public IPv4 address and the deployment of more NAT devices in real network, the communication between the two hosts that located behind NAT devices is becoming even difficult. The introduce of IPv6 technology and the coexist of IPv4 and IPv6 hosts within one network exacerbate this situation. TURN[RFC 5766] technology is aim to solve these problems, but currently its deployment is very limited and most of application provider user their own platform to transfer the data between two hosts that behind NAT environment and to translate the communication packets between two hosts in different address family. The data relay device deployed centrally by various application providers often lead to the inefficiency of data transfer between two hosts. The relay device must deal with complex network layered problems with which the application providers are not familiar. On the other hand, service provider deploys many CGN devices (can act as PCP server) in distributed manner within their networks. The PCP protocol can be used to control these CGN devices/PCP servers, to let the incoming upstream packet pass through the NAT devices, and let the outgoing packets converted as previously allocated by PCP peer opcode. If the service provider can use these CGN devices as the relay devices for communication between two hosts behind the symmetric NAT or that from different address family, open their data translate/forward capability to the application provider, the host to host communication will be more easily and more efficient, the adoption of IPv6 technology will also be accelerated. This draft gives one general solution for host-to-host communication in complex network environment, especially the devices are behind the symmetric NAT gateway, or the devices belong to different address family. The solution is simpler than the current TURN technology, and requires one new "BIND" opcode to be defined to the PCP protocol. Expires January 3, 2015 [Page 3] Internet-Draft PCP BIND Operation July 2014 2. Conventions used in this document 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 RFC-2119 [RFC2119]. 3. Terminology TBD 4. Communication Scenario 4.1. Communication Scenario in Symmetric NAT environment With the advent of smart devices and the development of mobile technology, the remote control requirements become more popular. In these situations, one often needs to find and access the remote devices via his/her smart phone, send the control signal or transfer the required large bulk of data(for example, remote file sharing or video monitor). The two communication devices are often located behind different NAT environment, which is illustrated in Fig4-1. Based on the requirements of specific application type, the underlying protocol layer should provide TCP communication channel for reliable data delivery or UDP communication channel for fast but unreliable data transfer. This requires every application provider to solve the TCP/UDP NAT punching problem, adopts STUN/TURN technology and deploy related server by themselves. Besides the technology barrier led by the STUN/TURN solution, the centralized deployment of relay device by each specific application provider for devices communication under symmetric NAT environment often lead to the inefficiency of data transfer, lower the user experiences of remote device control. On the other hand, service providers are in deploying more CGN devices within their network. The PCP protocol is used by these CGN devices, to allow the PCP client to control the behavior of CGN devices. From the standpoint of technology, the data process procedure for relay device and CGN device is similar: they all need to translate the original packet sending to them to other transformed packet originating from them. If the service provider can utilize the CGN devices to provide the data relay function as required by host to host communication in Expires January 3, 2015 [Page 4] Internet-Draft PCP BIND Operation July 2014 symmetric NAT environment, solve the network/transport layer problem and provide interfaces to application provider to use the data relay capabilities, it certainly will alleviate the burden of application provider to deploy distributed relay devices and to tackle the STUN/TURN technology problem. +----------------------+ +---------------------+ | Relay Device | | Relay Device | | (Application Provider 1) | | (Application Provider 2)| +---------+------------+- -+---------+-----------+ | ----- | | ---- --- | | --- --- | +--------+-------+- --+----+-----+ | NAT Device | |NAT Device| |(Symmetric Type)| +----+-----+ +--------+-------+ | | | | | | | +---+----+ +---+---+ | Host A | | Host B| +--------+ +-------+ Fig. 4-1 Communication Scenario between two hosts behind symmetric NAT device 4.2. Communication Scenario in different address family With the adoption of IPv6 technology by various operation systems, many hosts are now in dual stack mode or in IPv6 only mode. There Expires January 3, 2015 [Page 5] Internet-Draft PCP BIND Operation July 2014 are many proposals and transition technologies to solve the client- to-server communication requirements, such as IPv6-only client to access the IPv4-only server or IPv4-only client to access the IPv6- only server, but there are few solutions to consider the IPv4-only client to communicate with the IPv6-only client and vice versa. TURN related technology [RFC 6156] mentions one solution based on TURN protocol, it requires the relay device (TURN server) to allocate and use unique relay transport address to relay the data between one pair of hosts in different address family. When one host is located behind symmetric NAT environment, it will require additional signal procedure (NAT punching) to let packet originating from the newly assigned relay transport address pass through NAT device. This must be solved by the application layer and results also in the reluctance for application provider to adopt IPv6 technology. The communication between two hosts in different address family must be done via one relay device. The relay device act mainly as one dual-role node: act as one IPv4-only device that represents the IPv6-only host and act as one IPv6-only device that represents the IPv4-only host. The IPv4-only and IPv6-only host should not know that the other communication end is in different address family. The solution should be same to upper application for different NAT environments, whether it is in non-symmetric mode or symmetric mode. 5. General Solution Based on the above two scenarios, this draft gives one general solution to meet the requirements of host to host communication in symmetric NAT environment and that in different address family. It proposes to open interfaces of CGN devices to application provider, to use the network translation and data relay capability of these devices, hide the complex of network/transport layer problem and increase the data transfer efficiency via the distributed CGN devices. +----------------------+ +----------------------+ |Application Provider 1+---+----+Application Provider 2| +----------------------+ | +----------------------+ |PCP BIND(new) Expires January 3, 2015 [Page 6] Internet-Draft PCP BIND Operation July 2014 +-----+----+ |CGN Device| +-----+----+-- + / | ----- / | ----- +---------------------* | +---------------+ |NAT Device(Symmetric)| | | NAT Device | +---------------------+ | |(Non-Symmetric)| | | +--------+------+ | | | +------+-----+ +-----+------+ +------+-----+ |Host A(IPv4)| |Host B(IPv6)| |Host C(IPv4)| +------------+ +------------+ +------------+ AP1 Client AP2 Client AP1 Client AP2 Client Fig.5-1 General Solution for host-to-host communication in symmetric NAT environment or between two hosts in different address family As illustrated in Fig.5-1, there are three Hosts within the network: Host A, Host B, Host C. Host A is an IPv4-only device and located behind one symmetric NAT device, Host B is an IPv6-only device directed to the CGN device, Host C is an IPv4-only device that located behind one non-symmetric NAT device. AP1 Client(client of Application Provider 1) and AP2 Client(client of Application Provider 2) are running on Host A; Only AP2 Client is running on Host B and AP1 Client is running on Host C. The CGN device has one well-known public IPv4 address/port and one well-known public IPv6 address/port; these two addresses will be Expires January 3, 2015 [Page 7] Internet-Draft PCP BIND Operation July 2014 used as the IPv4 relay address/port and IPv6 relay address/port. All of clients in one address family will use the same relay address/port to communicate with each other, which is different from the current solution of TURN protocol. The following is the detail process of the general solution to the host to host communication in symmetric NAT environment and that in different address family: 1. Process for hosts in symmetric NAT environment: a) If AP1 clients that located in Host A and Host C want to communicate with each other, they should send one STUN-like message to the well-known public IPv4 relay address/port, get their reflex public address to this relay address. b) AP1 clients that is located in Host A and Host C should report their reflex address to Application Provider 1 c) Application Provider 1 will use the mapped address of Host A and Host C to formulate one BIND message to the CGN device, let the CGN device to build one BIND table for Host A and Host C d) Host A will send the AP1 application data to the well-known public IPv4 relay address/port of the CGN device. e) CGN device will look up the BIND items that formulated in the step c), get the reflex IPv4 address of Host C. It then will change the source address of the packet to the well-known public IPv4 relay address of CGN device, the destination address of this packet to the IPv4 reflex address of Host C. f) The translated packet will be forwarded to the Host C, processed by the AP1 client located on it. g) The return traffic will also be sent to the well-known IPv4 relay address/port of CGN device, converted by the CGN device, and sent back to the Host A. 2. Process for hosts that located in different address family: a) If AP2 clients that are located in Host A and Host B want to communicate with each other, they should also first send one STUN-like message to the well-known public address/port(later refer to relay address, ) of CGN device, get their reflex public address related to this relay address. Expires January 3, 2015 [Page 8] Internet-Draft PCP BIND Operation July 2014 b) Host A will send message to the well-known IPv4 address/port of CGN device; Host B will send message to the well-known IPv6 address/port c) The reflex address for Host A is one public IPv4 address and the reflex address for Host B is one public IPv6 address, normally same as the IPv6 source address of Host B. d) AP2 Clients that are located in Host A and Host B should report their reflex addresses to Application Provider 2. e) Application Provider 2 will use the reflex address of Host A and Host B to formulate one BIND message to the CGN device, let the CGN device to build one BIND table for Host A and Host B. f) Host A will send the AP2 application data to the well-known public IPv4 relay address/port of CGN device; g) CGN device will look up the BIND items that formulated in step e), get the reflex IPv6 address of Host B. It then will change the source address of the packet to the IPv6 relay address of CGN device, the destination address of this packet to the IPv6 reflex address of Host B. h) The translated packet will be forwarded to the Host B, processed by the AP2 client located on it. i) The return traffic will be sent to the well-known IPv6 relay address/port of CGN device, converted by the CGN device, and sent back to the Host A in the IPv4 packet format. j) The AP2 client in Host A and Host B will not notice the other end is located in different address family. The CGN device finishes all the network/transport layer related translation work. The main difference of the above detailed process is the content of the BIND command. All other steps are similar for the CGN device Application Provider and AP clients. The process is same for hosts' communication in TCP/UDP protocol, for that in symmetric NAT/non- symmetric NAT environment and for that in different address family. Based on these characteristics, such general-purpose solution that is simpler than TURN and can be adopt and accessed by various Application Providers. Expires January 3, 2015 [Page 9] Internet-Draft PCP BIND Operation July 2014 6. BIND Request In order to let the CGN device to build one BIND item upon the request of Application Provider, it is needed to define one general BIND message to transfer the related information. Because the BIND table mentioned in section 5 is similar with the NAT table, the behavior of relay device is same as the normal NAT device; it is suitable to extend the PCP protocol to control the formation of NAT table. Based on the PCP protocol architecture, the Application Provider will act as the PCP client, the CGN device will act as the PCP server. The newly defined BIND opcode and its detail format is described in following paragraph. 6.1. BIND Opcode The action of BIND request is different from that of current MAP and PEER opcode. It defines the relationship between two half- connections, the translation rule that converts both the source address and destination address of pass through packet in both directions, not like MAP/PEER opcode that deals with only the source address for output packet and destination address for return packet. BIND Opcode: It defines how to bind two half-connections that ends at the PCP sever together. Each of the half-connection is from the client and terminates at the same well known IP address/port of PCP server. When PCP server receives the BIND request, it will create one map table item that includes the reflex IP address/port of both hosts that lies behind one NAT device and the protocol that the host will use to communicate. When the PCP server 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 well-known PCP server/port and converts the destination address/port of this packet to the address/port that results from the map table lookup action. The converted packet will be routed to NAT side of the other host, NATed by the NAT device and then to the other host. The return packet will be delivered to the well-known IP address/port of PCP server and be converted in reverse accordingly. Expires January 3, 2015 [Page 10] Internet-Draft PCP BIND Operation July 2014 6.2. BIND Operation Packet Formats The BIND Opcode allows a PCP client to create a new explicit bind mapping table on the PCP sever, instructs the PCP server to accomplish the related translation work. The following diagram shows the Opcode layout for the BIND Opcode request/response format. 0 7 15 23 31 +---------------------------------------+ | | | BINDing Nonce(96 bits) | | | | | +--------+----------+----------+--------+ |Subtype | Protocol | AF_Type_A| Resv | +--------+----------+----------+--------+ | | | | | IP_Address_A(32 or 128 bits | | | | | +--------------------+---------+--------+ | Port_A |AF_Type_B| Resv. | +--------------------+---------+--------+ | | Expires January 3, 2015 [Page 11] Internet-Draft PCP BIND Operation July 2014 | | | IP_Address_B(32 or 128 bits) | | | | | +--------------------+---------+--------+ | Port_B | Action | Resv | +--------------------+---------+--------+ Fig.6-1: BIND Opcode Request/Response Format The related fields are described below: BINDing Nonce: 12 Bytes(96 bits). Random value chosen by the PCP client. It is similar with the Mapping Nonce in MAP Opcode Request. Subtype: 1 Byte. This field will differentiate the BIND Request/Response packet. For BIND Request packet, this value will be 0x01 For BIND Response packet, its value will be 0x02. Protocol: 2 Bytes. Upper-layer protocol associated with this Opcode. Values are taken from the IANA protocol registry [proto_numbers]. For example, this field contains 6 (TCP) if the Opcode is intended to create a TCP mapping. This field contains 17 (UDP) if the Opcode is intended to create a UDP mapping. The value 0 has a special meaning for 'all protocols'. AF_Type_A: 1 Byte. The reflex address family of host A. It will be 4 when the host's reflex address is IPv4 and will be 16 when the host's reflex address is IPv6. It actually represents the length of following 'IP_Address_A' field. IP_Address_A: 4 Bytes or 16 Bytes. This field is the value of host A's reflex address. Specially, in symmetric NAT environment, the reflex address is related to the well-known IP address/port of PCP server. For IPv6 host, the reflex address is often same as the local IPv6 address of host A. Port_A: 2 Bytes. This field is the value of host A's reflex port. Specially, in symmetric NAT environment, the reflex address is related to the well-known IP address/port of PCP server. Expires January 3, 2015 [Page 12] Internet-Draft PCP BIND Operation July 2014 AF_Type_B: 1 Byte. The reflex address family of host B. It will be 4 when the host's reflex address is IPv4 and will be 16 when the host's reflex address is IPv6. It actually represents the length of following 'IP_Address_B' field. IP_Address_B: 4 Bytes or 16 Bytes. This field is the value of host B's reflex address. Specially, in symmetric NAT environment, the reflex address is related to the well-known IP address/port of PCP server. For IPv6 host, the reflex address is often same as the local IPv6 address of host B. Port_B: 2 Bytes. This field is the value of host B's reflex port. Specially, in symmetric NAT environment, the reflex address is related to the well-known IP address/port of PCP server. Action 1 Byte. It will be equal to 1 when the PCP client wants to add one mapping item to the PCP server. It will be equal to 0 when the PCP client wants to delete one mapping item to the PCP server. This field is only valid when the subtype value is 0x01. Reserved: Reserved byte, MUST be sent as 0 and MUST be ignored when received. 7. Security Considerations The risk of this opcode to the PCP server is same as that of the MAP/PEER Opcode analyzed in RFC 6887[PCP]. There is no more additional risk to the PCP server. The BIND opcode does not require the PCP server to allocate new IP address/port for every new session, as that required by the solution of TURN solution. 8. IANA Considerations According to RFC 6887[PCP], IANA has created a new protocol registry for PCP Opcodes, numbered 0-127, initially populated with the values: Value Opcode ----- ------------------------- 0 ANNOUNCE 1 MAP 2 PEER 3-31 Standards Action [RFC5226] Expires January 3, 2015 [Page 13] Internet-Draft PCP BIND Operation July 2014 32-63 Specification Required [RFC5226] 96-126 Reserved for Private Use [RFC5226] 127 Reserved, Standards Action [RFC5226] This draft proposes IANA to allocate value 3 to the BIND opcode, as below: Value Opcode ----- ------------------------- 0 ANNOUNCE 1 MAP 2 PEER 3 BIND 4-31 Standards Action [RFC5226] 32-63 Specification Required [RFC5226] 96-126 Reserved for Private Use [RFC5226] 127 Reserved, Standards Action [RFC5226] 9. 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 family needs also be considered. By newly define one PCP BIND Opcode, 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 PCP server that deployed by service provider to the third party(CP/SP), make the host-to-host communication more easily. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5389] J. Rosenberg, R. Mahy, P. Matthews, D. Wing," Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008 Expires January 3, 2015 [Page 14] Internet-Draft PCP BIND Operation July 2014 [RFC5766] R. Mahy, P. Matthews, J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)" RFC5766, April 2010 [RFC6156] G. Camarillo, O. Novo, S. Perreault, Ed. "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011 [RFC6062] S. Perreault, Ed., J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010 [RFC6887] D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk," Port Control Protocol (PCP)" RFC 6887, April 2013 10.2. Informative References [I-D Draft] D.Wing, P.Patil, T.Reddy, P.Martinsen " Mobility with TURN ", draft-wing-tram-turn-mobility-00, June 2014. 11. Acknowledgments TBD This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Aijun Wang China Telecom Coporation Limited Beijing Research Institute No.118,Xizhimenneidajie,Xicheng District,Beijing, 100035,China Phone: 86-10-58552347 Email: wangaj@ctbri.com.cn Expires January 3, 2015 [Page 15] Internet-Draft PCP BIND Operation July 2014
Phone: Email: Expires January 3, 2015 [Page 16]