Internet Engineering Task Force C. Zhou
Internet-Draft Huawei Technologies
Intended status: Standards Track T. Tsou
Expires: January 9, 2012 Huawei Technologies (USA)
X. Deng
M. Boucadair
France Telecom
Q. Sun
China Telecom
July 8, 2011
Using PCP To Coordinate Between the CGN and Home Gateway Via Port
Allocation
draft-tsou-pcp-natcoord-03
Abstract
Consider a situation where a subscriber's packets are subject to two
levels of NAT, with both NATs operating under the control of the ISP.
An example of this would be a NATing Home Gateway forwarding packets
to a Large Scale NAT. This memo proposes that advantage be taken of
the presence of the second NAT, to offload the burden on the Large
Scale NAT by delegation to the Home Gateway. Enhancements to the
Port Control Protocol are specified to achieve this. The proposed
solution applies also for DS-Lite where the AFTR offloads it NAT to
the B4 element.
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 January 9, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Zhou, et al. Expires January 9, 2012 [Page 1]
Internet-Draft NAT Coordination Using Port Allocation July 2011
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.
Table of Contents
1. Application Scenario . . . . . . . . . . . . . . . . . . . . . 3
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Delegation of Port Sets . . . . . . . . . . . . . . . . . 3
2.2. Packet Processing At the Home Gateway and LSN . . . . . . 4
2.3. Proposed Enhancements To and Usage Of the Port Control
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Port Range Option . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Additional Author . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Additional Author . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. NAT By-pass PCP . . . . . . . . . . . . . . . . . . . 7
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7
A.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
A.1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . 8
A.2. NAT Bypass PCP Option . . . . . . . . . . . . . . . . . . 8
A.3. Port Set Option . . . . . . . . . . . . . . . . . . . . . 10
A.4. External Port Set . . . . . . . . . . . . . . . . . . . . 11
A.5. External Non-Contiguous Port Set . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Zhou, et al. Expires January 9, 2012 [Page 2]
Internet-Draft NAT Coordination Using Port Allocation July 2011
1. Application Scenario
A Large Scale NAT (LSN) is responsible for translating source
addresses and ports for packets passing into and out of the provider
network. Especially for large scale service providers, one LSN may
need to support at least tens of thousands of customers, resulting in
heavy processing requirements for the LSN.
In some broadband scenarios an additional NAT is present at the edge
of the customer network. For convenience we will call this the Home
Gateway. The load on the LSN could be reduced if address and port
translation were actually done at the Home Gateway. Achieving such
an outcome would require coordination between the two devices. This
memo makes a detailed proposal for the required coordination
mechanism.
2. Proposed Solution
2.1. Delegation of Port Sets
The basic proposal made in this memo is to provide the means for the
Home Gateway to request that the LSN delegate to it a set of ports
and optionally an external address that will be associated with those
ports. It is proposed to use the Port Control Protocol (PCP)
[ID.port-control-protocol] to achieve this. The procedure is
illustrated in Figure 1.
The LSN allocation of port sets MAY take into account the advice
given in [ID.behave-natx4-log-reduction].
[Open Issue: if we want to make the port sets discontinuous, we
must either allow negotiation of the algorithm or parameters of
that algorithm for determining the complete set from a given
starting point, or specify it here. Specifying it all here is
probably counter-productive, given that this is a security measure
to make port guessing harder.]
Zhou, et al. Expires January 9, 2012 [Page 3]
Internet-Draft NAT Coordination Using Port Allocation July 2011
Home Gateway LSN
| |
| |
|------(1)PCP Request-------->|
| |
| +----+----+
| | Create |
| |NAT entry|
| +----+----+
| |
|<-----(2)PCP Response-----|
| (Port Set) |
| |
Figure 1: Acquiring a Delegated Port Set
If the Home Gateway allocates all of the ports that have been
delegated to it for a given protocol, it MAY send a request to the
LSN for another delegated set of ports. If the LSN satisfies that
request, the Home Gateway MUST release the additional set as soon as
possible. To achieve this, the Home Gateway May follow a policy for
allocation of additional ports to flows, that has the same effect as
searching for "free" ports in the port sets in the order in which
they were delegated to the Home Gateway. A port SHOULD be considered
"free" if no traffic has been observed through it for the timeout
interval specified for the protocol concerned, as discussed in
[ID.behave-natx4-log-reduction], or if the Home Gateway knows through
other means (e.g., host reboot) that it is no longer in use.
2.2. Packet Processing At the Home Gateway and LSN
The Home Gateway maps outgoing flows to the delegated ports. If an
external address was received it uses that for the source address;
otherwise it retains the private address of the Home Gateway as the
source address.
The procedures are more complicated, of course, if the IP version
running externally to the LSN is different from the IP version
running between the Home Gateway and the LSN, since the
destination address also has to be translated. The details depend
on the particular transition mechanism in use, and are left as an
exercise for the reader.
If the private address is retained, the LSN recognizes it from the
original delegation request and changes the source address but not
the port before forwarding the packet. If the external public
address was used, the LSN is not useful and another device may be
needed to allocate the port set.
Zhou, et al. Expires January 9, 2012 [Page 4]
Internet-Draft NAT Coordination Using Port Allocation July 2011
In the reverse direction, the LSN recognizes the public destination
address and port of an incoming packet as belonging to a delegated
set for the Home Gateway. It translates the destination address, if
necessary, leaving the destination port unchanged. The Home Gateway
translates the destination port and address to the corresponding
values in the customer network and forwards the packet in turn.
2.3. Proposed Enhancements To and Usage Of the Port Control Protocol
This document proposes the following new option for MAP opcodes:
PORT_SET_REQUESTED.
option number: to be allocated
is valid for OpCodes: MAP44, MAP64, MAP46, or MAP66
is included in responses: MUST
has length: 0 in requests, 4 in successful responses. [As
mentioned above, if non-consecutive sets of ports are allocated,
we may want to add parameters of the algorithm for deriving the
complete set from the initial value provided in the "assigned
external port" field of the response.]
may appear more than once: no
When constructing a PCP request with the PORT_SET_REQUESTED option,
the client MUST set the "internal port" field of the request to zero.
If requesting a new set of delegated ports, the client MAY set the
"requested external port" field to a non-zero value. If releasing a
set of delegated ports (i.e., by setting the "Requested lifetime"
field to zero), the client MUST set the "requested external port"
field to the value of the "assigned external port" field of the
earlier response from the server. The remaining fields of the PCP
request MUST be set as directed by [ID.port-control-protocol]
[Open issue: for a release, should the PORT_SET_REQUESTED option have
the same contents as it had in the earlier response?]
Upon receiving a PCP request with the PORT_SET_REQUESTED option, the
server MAY reject it using return codes 151 - NOT_AUTHORIZED, or 152
- USER_EX_QUOTA. In this case, the PORT_SET_REQUESTED option in the
response MUST have zero length (no data). If the server chooses to
honour the request, it MUST place the value of the first port in the
assigned set in the "assigned external port" field of the response.
It MUST set the length of the PORT_SET_REQUESTED option in the
response to 4, and MUST provide the number of ports in the delegated
set as the value of the option.
Zhou, et al. Expires January 9, 2012 [Page 5]
Internet-Draft NAT Coordination Using Port Allocation July 2011
3. Port Range Option
The Port_Range option is used to specify one set of ports (contiguous
or not contiguous) pertaining to a given IP address. The starting
point of the ports and the number of delegated ports are used to
infer a set of allowed port values.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting point 1 | Number of delegated ports 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting point n | Number of delegated ports n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Port_Range_Option
This option:
o name: Port range option
o number: TBA
o purpose: A PCP Client inserts this option in a PCP request to
specify one set of ports (contiguous or not contiguous) pertaining
to a given IP address.
o is valid for OpCodes:all.
o length:The length MUST be set to 0.
o may appear in:request
o maximum occurrences:none
4. Security Considerations
Will do later. Trust issues between the client and server, plus the
port randomization issues discussed in
[ID.behave-natx4-log-reduction] and [ID.zhou-softwire-b4-nat].
Zhou, et al. Expires January 9, 2012 [Page 6]
Internet-Draft NAT Coordination Using Port Allocation July 2011
5. Additional Author
Xiaohong Deng <xiaohong.deng@orange-ftgroup.com> joined the list of
authors for version -03 of this draft.
6. IANA Considerations
Will register the new option if this draft goes through as a
standalone document rather than being incorporated into the base
protocol.
7. Additional Author
Gabor Bajko
Nokia
Email: gabor.bajko@nokia.com
8. References
8.1. Normative References
[ID.port-control-protocol]
Wing, D., "Port Control Protocol (PCP)", January 2011.
8.2. informative References
[ID.behave-natx4-log-reduction]
Tsou, T., Li, W., and T. Taylor, "Port Management To
Reduce Logging In Large-Scale NATs", September 2010.
[ID.zhou-softwire-b4-nat]
Deng, X., Zhou, C., Boucadair, M., Bajko, G., and T. Tsou,
"DS-Lite AFTR NAT Bypass: Co-located B4 and NAT Model",
June 2011.
Appendix A. NAT By-pass PCP
A.1. Introduction
This section defines a new PCP option denoted NAT by-pass option.
The purpose of this option is to instruct a PCP- controlled device to
not envoke NAT operation on a set of flows destined to a given device
Zhou, et al. Expires January 9, 2012 [Page 7]
Internet-Draft NAT Coordination Using Port Allocation July 2011
located behind the PCP-controlled device.
A.1.1. Use Cases
PCP can be used to control an upstream device to achieve the
following goals:
1. A plain (i.e., a non-shared) IP address can be assigned to a
given subscriber because the subscriber subscribed to a service
which uses a protocol that don't embed a transport number or
because the NAT is the only deployed platform to manage IP
addresses.
2. An application (e.g., sensor) does not need to listen to a whole
range of ports available on a given IP address. Only a limited
set of ports are used to bind its running services. For such
devices, the external port(s) and IP address can be delegated to
that application and therefore avoid enforcing NAT in the network
side for its associated flows. The NAT in the PCP- controlled
device should be bypassed.
3. A device able to restrict its source ports can be delegated an
external port restricted IP address. The PCP- controlled device
should be instructed to by-pass the NAT when handling flows
destined/issued to that device.
A.1.2. Scope
As currently defined in PCP Base document, PCP is unable to instruct
a PCP-controlled device to de-activate the NAT for a given customer,
given flows, etc.
This document defines new PCP options which are meant to instruct a
PCP-controlled device to by-pass the NAT function whenever required.
A.2. NAT Bypass PCP Option
This option (Figure 3) is used by a PCP Client to indicate to the PCP
Server to not apply any NAT operation to a corresponding binding.
Zhou, et al. Expires January 9, 2012 [Page 8]
Internet-Draft NAT Coordination Using Port Allocation July 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA | Reserved | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NAT Bypass option
This option:
o name: NAT Bypass option
o number: TBA
o purpose: A PCP Client inserts this option in a PCP request to
indicate to the PCP Server to not apply the NAT function. The NAT
is then by-passed in the PCP-controlled device.
o is valid for OpCodes:all.
o length:The length MUST be set to 0.
o may appear in:request
o maximum occurrences:none
A PCP Client inserts this option in a PCP request to indicate to the
PCP Server to not apply the NAT function. The NAT is then by-passed
in the PCP-controlled device.
A PCP Server which supports the NAT by-pass feature MUST include this
option in its response to the requesting PCP Client. In particular,
when the PCP Server does not include this option in its response, the
PCP Client should deduce that the NAT will be enforced in the PCP-
controlled device; a NAT will be then enforced in the PCP-controlled
device.
The NAT bypass feature can be associated with a plain IP address. In
such case, a full external IP address is returned to the requesting
PCP Client. The client is then able to use all ports associated with
that IP address (i.e., without any restriction). Furthermore, this
"full" address can be used to access services which do not rely on
protocols embedding a port number (e.g., some IPsec modes).
In some cases, the PCP Client can request the by-pass of the NAT but
without requiring a full IP address (e.g., for the use cases
described in bullet 2 and 3 of Appendix A.1.1). In such scenario, in
Zhou, et al. Expires January 9, 2012 [Page 9]
Internet-Draft NAT Coordination Using Port Allocation July 2011
addition to the NAT by-pass option, the PCP Client includes in its
PCP request a Port Set Option (Appendix A.3). More information about
this option is provided hereafter.
The requested lifetime in the PCP MAP request is set to the available
lifetime of the port set. If the lifetime is set to zero, it means
that the requested port set should be deleted. Internal port,
external port and the external address are all invalid.
A.3. Port Set Option
This option (Figure 4) is used to indicate a request for a contiguous
port set. This option conveys the length of the requested ports set.
It is up to the PCP Server to decide whether the request will be
satisfied or not. In particular, the PCP Server may discard the
request or accept to assign a port range with a length distinct than
the one requested by the PCP Client. The PCP Server can assign a
bigger or shorter ports set compared to is actually requested by a
PCP Client.
If the PCP Server supports the ability to delegate a set of ports to
a requesting PCP Client, it should include in its PCP response the
external port set option described in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA | Reserved | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Port Set Length|
+-+-+-+-+-+-+-+-+
Figure 4: Port Set Option
This option:
o name: Port Set Length option
o number: TBA
o purpose: This option is used to indicate a request for a
contiguous port set. This option indicates the length of the
requested ports set.
o is valid for OpCodes:all.
Zhou, et al. Expires January 9, 2012 [Page 10]
Internet-Draft NAT Coordination Using Port Allocation July 2011
o length:The length MUST be set to 1.
o may appear in:request
o maximum occurrences:none
If the PCP Server is configured to assign port ranges, it should use
the External Port Set option (Appendix A.4) in its response to convey
a range of port to a requesting PCP Client.
A.4. External Port Set
This option is used to enclose contiguous ports set in a PCP message
sent by the PCP Server to a requesting Client. This option may be
included in a PCP response to delegate a set of ports associated with
the same external IP address.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA | Reserved | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: External Ports Set
This option:
o name: External Ports Set option
o number: TBA
o purpose: This option is used to enclose contiguous ports set in a
PCP message sent by the PCP Server to a requesting Client.
o is valid for OpCodes:all.
o length:The length MUST be set to 4.
o may appear in:response
o maximum occurrences:none
The data part of this option indicate the bounds of the assigned
Zhou, et al. Expires January 9, 2012 [Page 11]
Internet-Draft NAT Coordination Using Port Allocation July 2011
ports range.
A PCP Client which receives this option from a PCP Server is
delegated all the port numbers within that range.
A.5. External Non-Contiguous Port Set
This option is used to enclose non-contiguous ports set in a PCP
message sent by the PCP Server to a requesting Client. This option
may be included in a PCP response to delegate non-overlapping sets of
non-contiguous ports associated with the same external IP address to
different PCP Client.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA | Reserved | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subscriber ID Pattern | Subscriber ID Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: External Non-Contiguous Ports Set
This option:
o name: External Non-Contiguous Ports Set
o number: TBA
o purpose: This option is used to enclose non-contiguous ports set
in a PCP message sent by the PCP Server to a requesting Client.
o is valid for OpCodes:all.
o length:The length MUST be set to 4.
o may appear in:response
o maximum occurrences:none
As described in [ID.ietf-intarea-shared-addressing-issues] , a bulk
of incoming ports can be reserved as a centralized resource shared by
all subscribers using a given restricted IPv4 address. In order to
distribute incoming ports as scattered as possible among subscribers
sharing the same restricted IPv4 address, other than allocating a
continuous range of ports to per subscriber, a solution to distribute
Zhou, et al. Expires January 9, 2012 [Page 12]
Internet-Draft NAT Coordination Using Port Allocation July 2011
bulks of non-continuous ports among subscribers, which also takes
port randomization of CPE NAT into account, because port
randomization is one protection among others against blind attacks,
is elaborated thereby.
On every restricted IPv4 address, according to port set size N,
log2(N)bits are randomly chose as subscribers identification bits(s
bit) among 1st and 16th bits. Take a sharing ration 1:32 for
example, Figure 4 shows an example of 5bits (2nd, 5th, 7th, 9th,
11th) being chose as s bit.
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 0 | s | 0 | 0 | s | 0 | s | 0 |
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| s | 0 | s | 0 | 0 | 0 | 0 | 0 |
+----+----+----+----+----+----+----+----+
Figure 7: An s bit selection example (on a sharing ration 1:32
address).
Subscriber ID pattern is then formed by setting all the s bits to 1
and other trivial bits to 0. Figure 5 illustrates an example of
subscriber ID pattern which follows the s bit selection of figure 4.
Note that the subscriber ID pattern can be different, ensured by the
random s bit selection, per restricted IP address no matter whether
the sharing ratio varies.
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 |
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
+----+----+----+----+----+----+----+----+
Figure 8: A subscriber ID pattern example (on a sharing ration 1:32
address).
Subscribers ID value is then assigned by setting subscriber ID
pattern bits (s bits shown in figure 4) to a unique customer value
and setting other trivial bits to 1. An example of subscriber ID
value, having a subscriber ID pattern shown in the figure 5 and a
Zhou, et al. Expires January 9, 2012 [Page 13]
Internet-Draft NAT Coordination Using Port Allocation July 2011
customer value 0, is shown in the figure 6.
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 1 | 0 | 1 | 1 | 0 | 1 | 0 | 1 |
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1 |
+----+----+----+----+----+----+----+----+
Figure 9: A subscriber ID value example (customer value: 0).
Subscriber ID pattern and subscriber ID value together uniquely
defines a restricted port set (Non-contiguous port sets or a
contiguous port range, depends on Subscriber ID pattern and
subscriber ID value) on a restricted IP address.
Pseudo-code shown in the figure 7 describes how to use subscriber ID
pattern and subscriber ID value to implement a random ephemeral port
selection function within the defined restricted port sets on a
customer NAT.
do{
restricted_next_ephemeral = (random()|subscriber_ID_pattern)
& subscriber_ID_value;
if(five-tuple is unique)
return restricted_next_ephemeral;
}
Figure 10: Random ephemeral port selection within the restricted port
set.
Authors' Addresses
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathyzhou@huawei.com
Zhou, et al. Expires January 9, 2012 [Page 14]
Internet-Draft NAT Coordination Using Port Allocation July 2011
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tena@huawei.com
Xiaohong Deng
France Telecom
Email: xiaohong.deng@orange-ftgroup.com
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Qiong Sun
China Telecom
P.R.China
Phone: 86 10 58552936
Email: sunqiong@ctbri.com.cn
Zhou, et al. Expires January 9, 2012 [Page 15]