Internet DRAFT - draft-wang-pcp-bind-operation
draft-wang-pcp-bind-operation
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
<Wang> 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.
<Wang> 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
<Wang> 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
<Wang> 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)
<Wang> 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
<Wang> 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.
<Wang> 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.
<Wang> 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.
<Wang> 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. |
+--------------------+---------+--------+
| |
<Wang> 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.
<Wang> 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]
<Wang> 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
<Wang> 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
<Wang> Expires January 3, 2015 [Page 15]
Internet-Draft PCP BIND Operation July 2014
<Firstname> <Lastname>
<Affiliation>
<Address>
Phone: <optional>
Email: <Your email address>
<Wang> Expires January 3, 2015 [Page 16]
