One document matched: draft-tsou-pcp-natcoord-00.txt
Internet Engineering Task Force T. Tsou
Internet-Draft C. Zhou
Intended status: Standards Track Huawei Technologies
Expires: September 5, 2011 Q. Sun
China Telecom Beijing Research
Institute
T. Taylor
Huawei Technologies
March 4, 2011
Using PCP To Coordinate Between the CGN and Home Gateway Via Port
Allocation
draft-tsou-pcp-natcoord-00
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.
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 5, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Tsou, et al. Expires September 5, 2011 [Page 1]
Internet-Draft NAT Coordination Using Port Allocation March 2011
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 Ranges . . . . . . . . . . . . . . . . . 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 Options . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Tsou, et al. Expires September 5, 2011 [Page 2]
Internet-Draft NAT Coordination Using Port Allocation March 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 Ranges
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.]
Tsou, et al. Expires September 5, 2011 [Page 3]
Internet-Draft NAT Coordination Using Port Allocation March 2011
Home Gateway CG-NAT
| |
| |
|------(1)Pinhole Request---->|
| |
| +----+----+
| | Create |
| |NAT entry|
| +----+----+
| |
|<-----(2)Pinhole 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 range.
Tsou, et al. Expires September 5, 2011 [Page 4]
Internet-Draft NAT Coordination Using Port Allocation March 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 PIN opcodes:
PORT_SET_REQUESTED.
option number: to be allocated
is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66
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 PIN 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 PIN
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 PIN 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.
Tsou, et al. Expires September 5, 2011 [Page 5]
Internet-Draft NAT Coordination Using Port Allocation March 2011
3. Port Range Options
The Port Range option is used to specify one range 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. This section provides
only one method to request the port range values. Other ways and
Optcode can be proposed in later versions.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting point 1 | Number of delegated ports 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting point n | Number of delegated ports n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Port_Range_Option
These fields are described as below:
o Starting Port: A 16 bit value used as an input to the specified
function.
o Number of delegated ports: A 16 bit value specifying the number of
ports delegated to the client for use as source port values.
o The value "n" indicates that the port range is not contiguous.
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].
5. IANA Considerations
Will register the new option if this draft goes through as a
standalone document rather than being incorporated into the base
protocol.
Tsou, et al. Expires September 5, 2011 [Page 6]
Internet-Draft NAT Coordination Using Port Allocation March 2011
6. References
6.1. Normative References
[ID.port-control-protocol]
Wing, D., "Port Control Protocol (PCP)", January 2011.
6.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.
Authors' Addresses
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: tena@huawei.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathyzhou@huawei.com
Qiong Sun
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie
Beijing, xicheng District 100035
China
Phone: +86 10 58552923
Email: sunqiong@ctbri.com.cn
Tsou, et al. Expires September 5, 2011 [Page 7]
Internet-Draft NAT Coordination Using Port Allocation March 2011
Tom Taylor
Huawei Technologies
1852 Lorraine Ave.t
Ottawa, Ontario K1H 6Z8
Canada
Phone:
Email: tom111.taylor@bell.net
Tsou, et al. Expires September 5, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 14:49:45 |