One document matched: draft-wing-pcp-base-00.txt
PCP working group D. Wing
Internet-Draft Cisco
Intended status: Standards Track October 18, 2010
Expires: April 21, 2011
Pinhole Control Protocol (PCP)
draft-wing-pcp-base-00
Abstract
Pinhole Control Protocol is an address-family independent mechanism
to control how incoming packets are forwarded by upstream devices
such as IPv4 NAT devices, NAT64 devices, and IPv6 firewalls.
Document Quality
** NOTE: due to a variety of reasons, this document's quality is low.
This will be improved by the next Internet Draft cutoff date.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 April 21, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wing Expires April 21, 2011 [Page 1]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4
1.2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Supported Transport Protocols . . . . . . . . . . . . . . 4
2.2. Single-homed CP Routers . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Port Forwarding . . . . . . . . . . . . . . . . . . . . . 5
3.2. PCP Client . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. PCP Server . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Interworking with UPnP IGD . . . . . . . . . . . . . . . . 6
3.4.1. Creating a mapping . . . . . . . . . . . . . . . . . . 7
3.4.2. Adjacent ports . . . . . . . . . . . . . . . . . . . . 8
3.4.3. Lifetime Maintenance . . . . . . . . . . . . . . . . . 9
4. PCP Server Discovery . . . . . . . . . . . . . . . . . . . . . 9
5. Request and Response Packet Format . . . . . . . . . . . . . . 9
5.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Information Elements . . . . . . . . . . . . . . . . . . . 13
5.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 14
6. Nested NATs . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. PCP Mapping State Maintenance . . . . . . . . . . . . . . . . 15
7.1. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Recreating Mappings On NAT Gateway Reboot . . . . . . . . 15
8. NAT-PMP Backwards Compatibility . . . . . . . . . . . . . . . 17
9. Processing Pinhole Requests and Responses . . . . . . . . . . 18
9.1. Generating and Sending a Request . . . . . . . . . . . . . 18
9.2. Processing a Request and Generating the Response . . . . . 19
9.3. Processing a Response . . . . . . . . . . . . . . . . . . 21
10. PCP Client Operation . . . . . . . . . . . . . . . . . . . . . 21
10.1. Pinhole Lifetime Extension . . . . . . . . . . . . . . . . 21
10.2. Pinhole Deletion . . . . . . . . . . . . . . . . . . . . . 21
10.3. Multi-interface Issues . . . . . . . . . . . . . . . . . . 21
10.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 22
11. PCP Server Operation . . . . . . . . . . . . . . . . . . . . . 22
Wing Expires April 21, 2011 [Page 2]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
11.1. Pinhole Lifetime . . . . . . . . . . . . . . . . . . . . . 22
11.2. Pinhole deletion . . . . . . . . . . . . . . . . . . . . . 23
11.3. Subscriber Identification . . . . . . . . . . . . . . . . 23
11.4. External IP Address . . . . . . . . . . . . . . . . . . . 24
11.5. Policy Configuration . . . . . . . . . . . . . . . . . . . 24
12. Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Host Reboot/PCP Client Failure . . . . . . . . . . . . . . 25
12.2. PCP Proxy/PCP Interworking Function . . . . . . . . . . . 26
13. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 26
13.1. Dual Stack-Lite . . . . . . . . . . . . . . . . . . . . . 26
13.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 26
13.1.2. Encapsulation Mode . . . . . . . . . . . . . . . . . . 27
13.1.3. Plain IPv6 Mode . . . . . . . . . . . . . . . . . . . 27
13.2. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.3. NAT44 . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.4. IPv6 Firewall . . . . . . . . . . . . . . . . . . . . . . 28
14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
15.1. PCP IP address . . . . . . . . . . . . . . . . . . . . . . 28
15.2. PCP Port Number . . . . . . . . . . . . . . . . . . . . . 28
15.3. PCP OpCodes . . . . . . . . . . . . . . . . . . . . . . . 28
15.4. PCP Error Codes . . . . . . . . . . . . . . . . . . . . . 29
15.5. PCP Information Elements . . . . . . . . . . . . . . . . . 29
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
17.1. Normative References . . . . . . . . . . . . . . . . . . . 29
17.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Analysis of Techniques to Discover PCP Server . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
Wing Expires April 21, 2011 [Page 3]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
1. Introduction
** NOTE: due to a variety of reasons, this document's quality is
low. This will be improved by the next Internet Draft cutoff
date.
1.1. Protocol Overview
Pinhole Control Protocol (PCP) provides a mechanism to control how
incoming packets are forwarded by upstream devices such as NATs and
firewalls. PCP is primarily designed to be implemented in the
context of large scale NAT deployments. Especially, it offers the
ability to configure a port forwarding capability in Service Provider
NATs. Therefore, similar service features as per current CP
(Customer Premises) router model can be offered to Customers who are
serviced behind a Provider NAT.
PCP allows applications to create pinholes from an external IP
address to an internal IP address and port. If the PCP-controlled
device is a NAT, a mapping is created; if the PCP-controlled device
is a firewall, a pinhole is created in the firewall. These pinholes
are required for successful inbound communications destined to
machines located behind a NAT.
1.2. Deployment Scenarios
PCP can be used in various deployment scenarios, including:
o DS-Lite AFTR [I-D.ietf-softwire-dual-stack-lite]
o Stateful NAT64 [I-D.ietf-behave-v6v4-xlate-stateful]
o Stateless NAT64 [I-D.ietf-behave-v6v4-xlate]
o Large-Scale NAT44 [I-D.nishitani-cgn]
o Layer-2 aware NAT [I-D.miles-behave-l2nat]
o IPv6 firewall control [I-D.ietf-v6ops-cpe-simple-security]
2. Scope
2.1. Supported Transport Protocols
PCP is designed to support transport protocols that uses a port
number (e.g., TCP, UDP, SCTP, DCCP). Transport protocols that do not
use a port number (e.g., IPsec ESP) can be wildcarded (allowing any
Wing Expires April 21, 2011 [Page 4]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
traffic with that protocol to pass), provided of course the upstream
device being controlled by PCP supports that functionality, or new
PCP OpCodes can be defined to support those protocols.
In this document, only TCP and UDP are defined.
2.2. Single-homed CP Routers
The PCP machinery assumes a single-homed subscriber model. That is,
for a given IP version, only one default route exists to reach the
Internet, much as there is only one default route for a TCP SYN
towards the Internet. This restriction exists because otherwise
there would need to be one PCP servers for each egress, because the
host could not reliably determine which egress path packets would
take.
3. Terminology
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.1. Port Forwarding
Port forwarding allows a host to receive traffic sent to a specific
IP address and port.
In the context of a NAT with internal and external IP addresses, if
an internal host is listening to connections on a specific port (that
is, operating as a server), the external IP address and port number
need to be port forwarded (also called "mapped") to the internal IP
address and port number. The internal and external IP addresses are
different, and a key point is that the internal and external
transport destination port numbers could be different. For example,
a webcam might be listening on port 80 on its internal address
192.168.1.1, while its publicly-accessible external address is
192.0.2.1 and port is 12345. The NAT does 'port forwarding' of one
to the other.
In the context of a firewall, the internal and external IP addresses
(and ports) are not changed.
3.2. PCP Client
The network element that sends PCP requests to the PCP Server. This
network element could be an application running on a host, embedded
in the host's OS or libraries, or running on a network device (such
Wing Expires April 21, 2011 [Page 5]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
as a customer premise router).
3.3. PCP Server
A network element which receives and processes PCP requests from a
PCP Client. This element might be the same as the device embedding
the controlled NAT (as shown in Figure 1) or might be a different
element in the network which interacts with the NAT (e.g., using out-
of-band XML, as shown in Figure 2).
+-----------------+
+------------+ | NAT or firewall |
| PCP Client |-<network>-+ +---<Internet>
+------------+ | with embedded |
| PCP server |
+-----------------+
Figure 1: device with Embedded PCP Server
+-----------------+
+--+ NAT or firewall +---<Internet>
/ +-----------------+
+------------+ / ^
| PCP Client +-<network> | Interaction (e.g., using XML)
+------------+ \ v
\ +------------+
+--+ PCP Server |
+------------+
Figure 2: NAT with Separate PCP Server
3.4. Interworking with UPnP IGD
In UPnP IGD, a 'control point' can request a specific port or can
request a wildcard port, and there is no concept of a mapping
lifetime. This model does not work well with NATs, especially large
scale NATs.
Wing Expires April 21, 2011 [Page 6]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
+-------------+
| IGD Control |
| Point |-----+
+-------------+ | +-----+ +--------+
+---| IGD-| |Provider|
| PCP |-------| NAT |--<Internet>
+---| IWF | | |
+-------------+ | +-----+ +--------+
| Local Host |-----+
+-------------+
LAN Side External Side
<======UPnP IGD==========><======PCP=====>
Figure 3: UPnP IGD to PCP Interworking Function
3.4.1. Creating a mapping
[Ed. Note: this section needs revision.]
[Ed. Note: discuss three types of mapping: dynamic (TCP SYN), PCP,
and static configured (e.g., CLI or web page) -- all three are the
same and create a mapping entry.
To interwork from UPnP IGD to PCP, our recommendation is that every
UPnP request be forwarded to the PCP server. This works if the UPnP
control point is incrementing the source port number, and also works
if the UPnP control point is randomly choosing the source port
number, and also works if it chooses 'any'. The UPnP IGD/PCP
interworking function would request very short leases (e.g., 5
seconds) in order to avoid the chatter of a DELETE message
(lifetime=0). Once a port can be allocated, its lifetime is
extended. When interworking with UPnP IGD, the in-home CPE limits
itself to sending one PCP message a second, which ensures there are
only 5 outstanding PCP reserverations at a time; this avoids
consuming all of that subscriber's NAT mappings while trying to find
an available port via the UPnP IGD->PCP interworking function).
Note: for this to work successfully, the PCP server (large NAT)
needs to honor the requested-external-port field in the PCP
request. Which is the purpose of that field, of course.
Wing Expires April 21, 2011 [Page 7]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
Message flow would be similar to this:
UPnP CP in-home CPE PCP server
| | |
|-UPnP:give me port 80->| |
| |-PCP:request port 80------>|
| | with lease=5 seconds |
| |<-PCP:here is port 51389---|
|<-UPnP: unavailable----| |
| | |
|-UPnP:give me port 81->| |
| |-PCP:request port 81------>|
| | with lease=5 seconds |
| |<-PCP:here is port 23831---|
|<-UPnP: unavailable----| |
| | |
... ... ... ...
| | |
|-UPnP:give me port 85->| |
| |-PCP:request port 85------>|
| | with lease=5 seconds |
| |<-PCP:here is port 85------|
| | |
| |-PCP:extend lease,port=85->|
| |<-PCP:ok-------------------|
| | |
|<-UPnP: ok, port 85----| |
| | |
Figure 4: Message Flow for UPnP to PCP Interworking
3.4.2. Adjacent ports
RTP and RTCP have historically run on adjacent ports, and some older
equipment still expects them to be on adjacent ports. To accomodate
that, a procedure can be used rather than adding complexity to the
protocol or to the server implementation.
The procedure is for the PCP client to request port 0 (indicating it
will accept any port from the server) for a short duration (e.g., 5
seconds), and receive the response indicating it now has port N. The
PCP client then sends a request for port N-1 and port N+1, attempting
to get a port on either side of the initial port. If it obtains
adjacent ports it extends the lease of the two ports. If it doesn't
obtain adjacent ports it repeats the procedure, asking for port 0
with a short lease again.
Wing Expires April 21, 2011 [Page 8]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
3.4.3. Lifetime Maintenance
UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP
interworking function is responsible for extending the lifetime of
mappings that are still interesting to the UPnP IGD device.
Note: It can be an implementation advantage, where possible, for
the UPnP IGD/PCP interworking function to request a port mapping
lifetime only while that client is active and connected. For
example, creating a PCP mapping that is equal to the client's
remaining DHCP lifetime is one useful approach. The UPnP IGD/PCP
interworking function is responsible for renewing the PCP lifetime
as necessary. As long as client renews its DHCP lease, the PCP
lifetime should also be extended. For clients not using DHCP,
other mechanisms to check on the client host's liveliness can also
be useful (e.g., ping, ARP, or WiFi association) can be used to
discern liveliness of the UPnP IGD control point. However, it is
NOT RECOMMENDED to attempt to connect to the TCP or UDP port
opened on the control point to determine if the host still wants
to receive packets; the server could be temporarily down when
tested, causing a false negative.
4. PCP Server Discovery
After considering several discovery mechanisms (Appendix A) we
propose two mechanisms for the PCP client to discover its PCP server:
o sending the PCP message to the default router
o a fixed IPv4 and a fixed IPv6 address, to be assigned by IANA.
[Ed. Note: More discussion is necessary on this topic.]
5. Request and Response Packet Format
The request and response packet formats take the same space and
layout. It is intended to be backwards compatible with NAT-PMP, so
that if a PCP message is sent to a NAT-PMP server it will be rejected
with an error code we can parse. The PCP request uses Version=1,
which if processed by a NAT-PMP server will cause a version conflict
(the NAT-PMP server will see this as NAT-PMP version 16) and an error
returned in the same place we're looking for it (last couple of bits
of the 4th byte).
Wing Expires April 21, 2011 [Page 9]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
5.1. Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=1 |reserve| OpCode | Protocol | PCPC Src Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCP Client IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pinhole Internal IP address (32 or 128) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Requested external IP address (32 or 128) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | requested external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Informational Elements :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Request Packet Format
These fields are described below:
Ver Version is 1
reserve 4 reserved bits, MUST be sent as 0, MUST be ignored when
received.
OpCode defined in Figure 6.
Protocol indicates protocol associated with this opcode. For
example, indicates TCP if the opcode is intended to create a TCP
mapping. Values are taken from the IANA protocol registry
[proto_numbers].
PCPC Src Port PCP client's source port for this PCP message.
PCP Client IP address PCP client's source IPv4 address for this PCP
message. This field and the preceeding field are used to
determine if there is a NAT between the PCP client and its PCP
server.
Wing Expires April 21, 2011 [Page 10]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
Pinhole Internal IP address Internal IPv4 or IPv6 address for the
mapping. IPv4 or IPv6 address is indicated by the OpCode.
Requested external IP address Requested external IPv4 or IPv6
address for the pinhole. IPv4 or IPv6 address is indicated by the
OpCode
Requested Lifetime Lifetime for this mapping, in seconds
internal port Internal port for the pinhole
requested external port requested external port for the mapping.
IPv4 or IPv6 address is indicated by the OpCode
Informational Element optional Informational Elements. See section
Section 5.3.
the Opcode has the following format:
+-+-+-+-+-+-+-+-+
| OpCode |
+-+-+-+-+-+-+-+-+
The following OpCodes are defined:
0 = IPv4 address to IPv4 address (NAT44 or IPv4 firewall)
1 = IPv4 address to IPv6 address (NAT46)
2 = IPv6 address to IPv4 address (NAT64)
3 = IPv6 address to IPv6 address (NAT66 or IPv6 firewall)
If the internal-ip-address and internal-port matches
(requested) external-ip-address and (requested) external-port,
the (request or) response pertains to a firewall; otherwise
it pertains to a NAT.
Figure 6: OpCode format
Wing Expires April 21, 2011 [Page 11]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
5.2. Response
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=1 |reserve| Opcode+128 | Protocol | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pinhole Internal IP address (32 or 128) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Assigned external IP address (32 or 128) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | assigned external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Informational Elements :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Response Packet Format
These fields are described below:
Ver Version is 1
reserve 4 reserved bits, MUST be sent as 0, MUST be ignored when
received.
OpCode defined in Figure 6
Protocol echoed from the Protocol field of the request.
Result Code See Section 5.4.
Epoch Server's epoch value
Pinhole Internal IP address Copied from request. IPv4 or IPv6
address is indicated by the OpCode.
Wing Expires April 21, 2011 [Page 12]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
Assigned external IP address Assigned external IPv4 or IPv6 address
for the pinhole. IPv4 or IPv6 address is indicated by the OpCode
Assigned Lifetime Lifetime for this mapping, in seconds
internal port Internal port for the pinhole, copied from request.
Assigned external port requested external port for the mapping.
IPv4 or IPv6 address is indicated by the OpCode
Informational Element optional Informational Elements. See section
Section 5.3.
5.3. Information Elements
The Informational Elements (IE) allow extending PCP, without defining
a new PCP version and without consuming additional opcodes. They can
be used in requests and responses, and are defined in documents
specific to each IE. IEs are useful in a request when additional
information is being specified in the request. Examples that have
been discussed, which might be standardized in the future, include
mapping DSCP bits, indicating which interface is requested for a
mapping on a multi-interface NAT (e.g., internal corporate network
address versus an Internet-facing address). IEs will use a Type-
Length-Value format. IEs that aren't understood by the server are
ignored.
Information Elements (IE) MAY appear in requests and are associated
with the request being sent. If a PCP request contains several IEs,
they MAY be encoded in any order in the request and MUST be encoded
in the same order in the response. If a PCP client or PCP server
receives an IE it does not understand, or is malformed, it simply
ignores the IE (as if that IE was not present); note this can cause a
response to contain fewer IEs than the request if the PCP server does
not understand an IE.
The "M" bit indicates this IE is mandatory to process. If this bit
is set, server MUST only attempt to process the PCP request if it
understands the associated IE; otherwise, the server MUST return
error code UNSUPPORTED_MANDATORY_IE.
Wing Expires April 21, 2011 [Page 13]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|Information-Element-Code | IE-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (data) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Informational Element header
When a new IE is defined, it MUST cause the PCP server to generate an
indication the IE was processed by the PCP server (e.g., by including
an IE in the response). For example, if the PCP server supported a
newly-defined IE which provides descriptive text for a port mapping
("webcam on 4th floor"), the mapping would be created and the PCP
server would respond with an IE indicating it included that
descriptive text in the mapping. New IEs MUST be registered with
IANA following the procedure described in Section 15.5.
5.4. Result Codes
... [Ed. Note: more error codes need to be defined]
The following response codes are defined:
Currently defined result codes:
0 - Success
1 - Unsupported Version
2 - Not Authorized/Refused
(e.g. box supports mapping, but user has turned feature off)
3 - Network Failure
(e.g. NAT box itself has not obtained a DHCP lease)
4 - Out of resources
(NAT box cannot create any more mappings at this time)
5 - Unsupported opcode
6 - UNSUPPORTED_MANDATORY_IE
6. Nested NATs
PCP can detect nested NATs. Server compares the PCPC Src Port and
PCP Client IP Address fields the source IP address and UDP port of
the incoming packet. If they don't match, error code NAT_ON_PATH is
returned.
[Ed. Note: this should probably also support detecting on-path NAT
for IPv6?]
Wing Expires April 21, 2011 [Page 14]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
7. PCP Mapping State Maintenance
[Ed. Note: This section needs worthsmithin.]
[Ed. Note: Discuss PCP servers and NATs that never lose their
mapping state. Discuss those that lose their mapping state (home
NATs)
7.1. Epoch
[Ed. Note: This section needs wordsmithing.]
Every packet sent by the NAT gateway includes a "Seconds since start
of epoch" field (SSSOE). If the NAT gateway resets or loses the
state of its port mapping table, due to reboot, power failure, or any
other reason, it MUST reset its epoch time and begin counting SSSOE
from 0 again. Whenever a client receives any packet from the NAT
gateway, either gratuitously or in response to a client request, the
client computes its own conservative estimate of the expected SSSOE
value by taking the SSSOE value in the last packet it received from
the gateway and adding 7/8 (87.5%) of the time elapsed since that
packet was received. If the SSSOE in the newly received packet is
less than the client's conservative estimate by more than one second,
then the client concludes that the NAT gateway has undergone a reboot
or other loss of port mapping state, and the client MUST immediately
renew all its active port mapping leases as described in Section 7.2.
7.2. Recreating Mappings On NAT Gateway Reboot
[Ed. Note: This section needs wordsmithing.]
The NAT gateway MAY store mappings in persistent storage so when it
is powered off or rebooted, it remembers the port mapping state of
the network.
However, maintaining this state is not essential for correct
operation. When the NAT gateway powers on or clears its port mapping
state as the result of a configuration change, it MUST reset the
epoch time and re-announce its IP address as described in Section
3.2.1 "Announcing Address Changes". Reception of this packet where
time has apparently gone backwards serves as a hint to clients on the
network that they SHOULD immediately send renewal packets (to
immediately recreate their mappings) instead of waiting until the
originally scheduled time for those renewals. Clients who miss
receiving those gateway announcement packets for any reason will
still renew their mappings at the originally scheduled time and cause
their mappings to be recreated; it will just take a little longer for
these clients.
Wing Expires April 21, 2011 [Page 15]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
A mapping renewal packet is formatted identically to an original
mapping request; from the point of view of the client it is a renewal
of an existing mapping, but from the point of view of the freshly-
rebooted NAT gateway it appears as a new mapping request.
This self-healing property of the protocol is very important.
The remarkable reliability of the Internet as a whole derives in
large part from the fact that important state is held in the
endpoints, not in the network itself [ETEAISD]. Power-cycling an
Ethernet switch results only in a brief interruption in the flow of
packets; established TCP connections through that switch are not
broken, merely delayed for a few seconds. Indeed, an old Ethernet
switch can even be replaced with a new one, and as long as the cables
are transferred over reasonably quickly, after the upgrade all the
TCP connections that were previously going though the old switch will
be unbroken and now going through the new one. The same is true of
IP routers, wireless base stations, etc. The one exception is NAT
gateways. Because the port mapping state is required for the NAT
gateway to know where to forward inbound packets, loss of that state
breaks connectivity through the NAT gateway. By allowing clients to
detect when this loss of NAT gateway state has occurred, and recreate
it on demand, we turn hard state in the network into soft state, and
allow it to be recovered automatically when needed.
Without this automatic recreation of soft state in the NAT gateway,
reliable long-term networking would not be achieved. As mentioned
above, the reliability of the Internet does not come from trying to
build a perfect network in which errors never happen, but from
accepting that in any sufficiently large system there will always be
some component somewhere that's failing, and designing mechanisms
that can handle those failures and recover. To illustrate this point
with an example, consider the following scenario: Imagine a network
security camera that has a web interface and accepts incoming
connections from web browser clients. Imagine this network security
camera uses NAT-PMP or a similar protocol to set up an inbound port
mapping in the NAT gateway so that it can receive incoming
connections from clients the other side of the NAT gateway. Now,
this camera may well operate for weeks, months, or even years.
During that time it's possible that the NAT gateway could experience
a power failure or be rebooted. The user could upgrade the NAT
gateway's firmware, or even replace the entire NAT gateway device
with a newer model. The general point is that if the camera operates
for a long enough period of time, some kind of disruption to the NAT
gateway becomes inevitable. The question is not whether the NAT
gateway will lose its port mappings, but when, and how often. If the
network camera and devices like it on the network can detect when the
NAT gateway has lost its port mappings, and recreate them
Wing Expires April 21, 2011 [Page 16]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
automatically, then these disruptions are self-correcting and largely
invisible to the end user. If, on the other hand, the disruptions
are not self-correcting, and after a NAT gateway reboot the user has
to manually reset or reboot all the other devices on the network too,
then these disruptions are *very* visible to the end user. This
aspect of the design is what makes the difference between a protocol
that keeps on working indefinitely over a time scale of months or
years, and a protocol that works in brief testing, but in the real
world is continually failing and requiring manual intervention to get
it going again.
When a client renews its port mappings as the result of receiving a
packet where the "Seconds since start of epoch" field (SSSOE)
indicates that a reboot or similar loss of state has occurred, the
client MUST first delay by a random amount of time selected with
uniform random distribution in the range 0 to 5 seconds, and then
send its first port mapping request. After that request is
acknowledged by the gateway, the client may then send its second
request, and so on, as rapidly as the gateway allows. The requests
SHOULD be issued serially, one at a time; the client SHOULD NOT issue
multiple requests simultaneously in parallel.
The discussion in this section focusses on recreating inbound port
mappings after loss of NAT gateway state, because that is the more
serious problem. Losing port mappings for outgoing connections
destroys those currently active connections, but does not prevent
clients from establishing new outgoing connections. In contrast,
losing inbound port mappings not only destroys all existing inbound
connections, but also prevents the reception of any new inbound
connections until the port mapping is recreated. Accordingly, we
consider recovery of inbound port mappings the more important
priority. However, clients that want outgoing connections to survive
a NAT gateway reboot can also achieve that using NAT-PMP. After
initiating an outbound TCP connection (which will cause the NAT
gateway to establish an implicit port mapping) the client should send
the NAT gateway a port mapping request for the source port of its TCP
connection, which will cause the NAT gateway to send a response
giving the external port it allocated for that mapping. The client
can then store this information, and use later to recreate the
mapping if it determines that the NAT gateway has lost its mapping
state.
8. NAT-PMP Backwards Compatibility
Because NAT-PMP and PCP share the same port, it is important that a
NAT-PMP client receive a NAT-PMP error message. This is done by
examining the version number of the incoming PCP message; if it is
Wing Expires April 21, 2011 [Page 17]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
zero, the message is from a NAT-PMP client. A valid NAT-PMP response
(rather than a PCP response) is necessary, shown below.
A server which supports both NAT-PMP and PCP would be able to process
both NAT-PMP and PCP requests normally, and (if necessary) proxy
between the protocols.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | OP = 128 + x | Response Code=1 (unsupp. ver.)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 0 (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: NAT-PMP response
[Ed. Note: More discussion is necessary on NAT-PMP backward
compatibility.]
9. Processing Pinhole Requests and Responses
PCP messages MUST be sent over UDP, and the PCP Server MUST listen
for PCP requests on the PCP-PORT port number (Section 15.2).
Every PCP request generates a response, so PCP does not need to run
over a reliable transport protocol.
9.1. Generating and Sending a Request
To create a pinhole, the PCP client generates a PCP request for the
appropriate address family of the internal host and the desired
public mapping. The PCP request contains a PCP header, PCP OpCode,
and optional Information Elements. Each of these elements contain a
length and their own encoding.
The PCP Client MAY request an external port matching the internal
port.
Once a PCP client has discovered its PCP Server (Section 4), and has
prepared a PCP Request message for its PCP server, it tries
communicating with the first PCP server on its list. It initializes
its retransmission timer, RETRY_TIMER, to the round trip time between
the PCP client and PCP server. If this value is unknown, 250ms is
RECOMMENDED. The PCP Client sends its PCP message to the server and
Wing Expires April 21, 2011 [Page 18]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
waits RETRY_TIMER for a response. If no response is received, it
doubles the value of RETRY_TIMER, sends another (identical) PCP
message with the same Transaction-ID, and waits again. This
procedure is repeated three times, doubling the value of RETRY_TIMER
each time. If no response is received, the PCP client tries with the
next IP address in its list of PCP servers. If it has exhausted its
list, it SHOULD abort the procedure. If, when sending PCP requests
the PCP Client receives an ICMP error (e.g., port unreachable,
network unreachable) it SHOULD immediately abort the procedure. Once
a PCP client has successfully communicated with a PCP server, it
continues communicating with that PCP server until that PCP server
becomes non-responsive, which causes the PCP client to attempt to re-
iterate the procedure starting with the first PCP server on its list.
9.2. Processing a Request and Generating the Response
[Ed. Note: this section needs updating.]
Upon receiving a PCP request message, it is parsed. A valid request
has the "S" bit cleared, contains a valid PCP header, one valid PCP
Opcode, and optional Informational Elements (which the server might
or might not comprehend). If an error is encountered during
processing, an error response is generated and sent back to the PCP
client. This error response SHOULD include those IEs from the
request that are understood by the server.
After successful parsing of the message, the PCP server validates
that the internal IP address in the PCP request belongs to that
subscriber. This validation depends on the deployment scenario; see
Section 11.3. If the internal IP address in the PCP request does not
belong to the subscriber, an error response MUST be generated with
error-code=2.
If the requested lifetime is 0, it indicates the pinhole described by
the internal IP address (and internal ports, if W is cleared) should
be deleted; the requested external port is ignored by the server. If
such a pinhole exists, it is deleted and a positive response MUST be
generated, echoing the information in the request. If the "W" bit is
set, it indicates all pinholes for the indicated internal IP address
are to be deleted. If the internal IP address is all zeros, it
indicates that all pinholes for all hosts belonging to the subscriber
are to be deleted for all protocols (if "W" is set) or the indicated
protocol (if "W" is cleared). For all cases with lifetime is 0, if
such a pinhole does not exist, it could be because the pinhole was
already deleted and the response was lost, so the same positive
response (as described above) MUST be generated.
If the requested lifetime is not 0, but a pinhole already exists for
Wing Expires April 21, 2011 [Page 19]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
the indicated internal IP address (and port(s)), the PCP server
replies with a successful response, as if this was a newly-created
pinhole. This can occur because the PCP client is either asking for
a renewal of their lifetime, because the original response was lost,
or because the PCP client has forgotten about its mapping (e.g.,
application crashed) and it is requesting a mapping for the same
internal IP address and internal port.
If any of the requested external port number(s) is not available, and
the "M" bit is set, the PCP-controlled device MUST NOT create any
pinholes and MUST return an error code=13.
If any of the requested external port number is not available, the
PCP-controlled device MUST return an available external port number
or, if no ports are available or the user has exhausted their port
limit, return an error response. If several ports were requested,
but not all could be mapped, the PCP server MUST NOT map any of them,
and MUST return an error code=7.
The PCP-controlled device MAY reduce the lifetime that was requested
by the PCP Client. The PCP-controlled device SHOULD NOT offer a
lease lifetime greater than that requested by the PCP Client. The
RECOMMENDED lifetime assigned by the server is 3600 seconds (i.e.,
one hour).
By default, a PCP-controlled device MUST NOT create mappings for a
protocol not indicated in the request; that is, if the request was
for a TCP mapping, a UDP mapping MUST NOT be created. Nevertheless,
a configurable feature MAY be supported by the PCP-controlled device,
which MAY reserve the companion port so the same PCP Client can map
it in the future.
If all of the proceeding operations were successful (did not generate
an error response), then the requested pinholes are created as
described in the request and a positive response is built. This
positive response contains the same OpCode and Transaction-ID as the
request, sets the "S" bit, and uses the PIN-RESPONSE. If multiple
ports were in the request, they are all included in the response, in
the same order, with their associated assigned external port numbers.
If there were Informational Elements in the request, which the server
understood and processed (as described by the documents that define
those IEs), the necessary IE responses are included. If there were
IEs in the request, which the server did not understand, they are
simply ignored as if they were not present.
Wing Expires April 21, 2011 [Page 20]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
9.3. Processing a Response
The PCP client receives the response and checks that the
Transaction-ID matches one of its outstanding transactions. If it is
an error response, the PCP client knows that none of the requested
pinholes were created, and can attempt to resolve the problem based
on the error code and error subcode.
If it is an positive response, the PCP client knows the transaction
was entirely successful and can use the external IP address and
port(s) as desired. Typically the PCP client will communicate the
external IP address and port(s) to another host on the Internet using
an application-specific mechanism.
10. PCP Client Operation
This section details operation specific to a PCP client.
10.1. Pinhole Lifetime Extension
An existing mapping can have its lifetime extended by the PCP client.
To do this, the PCP client sends a new PCP map request to the server
indicating the internal IP address and port(s).
The PCP Client SHOULD renew the mapping before its expiry time,
otherwise it will be removed by the PCP Server (see Section 11.2).
In order to prevent excessive PCP chatter, it is RECOMMENDED to renew
only 60 seconds before expiration time (to account for
retransmissions that might be necessary due to packet loss, clock
synchronization between PCP client and PCP server, and so on).
10.2. Pinhole Deletion
A PCP Client MAY delete a pinhole prior to its natural expiration by
sending a PCP Map Request with a lifetime of 0. The PCP server
responds by returning a PCP Map Response with a lifetime of 0.
To delete all pinholes for all ports, the "W" (wildcard) bit is set,
and no internal port/external port is included in the PCP request.
To delete all pinholes for all hosts associated with this subscriber,
an all-zero internal IP address is used.
10.3. Multi-interface Issues
Hosts which desire a PCP mapping might be multi-interfaced (i.e., own
several logical/physical interfaces). Indeed, a host can be dual-
Wing Expires April 21, 2011 [Page 21]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
stack or be configured with several IP addresses. These IP addresses
may have distinct reachability scopes (e.g., if IPv6 they might have
global reachability scope as for GUA (Global Unicast Address) or
limited scope such as ULA (Unique Local Address, [RFC4193])).
IPv6 addresses with global reachability scope SHOULD be used as
internal IP address when instructing a PCP mapping in a PCP-
controlled device. IPv6 addresses with limited scope (e.g., ULA),
SHOULD NOT be indicated as internal IP address in a PCP message.
As mentioned in Section 2.2, only mono-homed CP routers are in scope.
Therefore, there is no viable scenario where a host located behind a
CP router is assigned with two GUA addresses belonging to the same
global IPv6 prefix.
10.4. Renumbering
The CP router might obtain a new IPv6 prefix, either due to a reboot,
power outage, DHCPv6 lease expiry, or other action. If this occurs,
the ports reserved using PCP might be delivered to another customer.
This same problem can occur if an IP address is re-assigned today,
without PCP. The solution is the same as today: don't re-assign IP
addresses.
11. PCP Server Operation
This section details operation specific to a PCP server.
11.1. Pinhole Lifetime
Once a PCP server has responded positively to a pinhole request for a
certain lifetime, the PCP-controlled device (e.g., NAT, firewall)
MUST keep that pinhole open for the duration of the lifetime that was
indicated in the PCP response. This is very much akin to how DHCP
works today, in that an IP address assigned via DHCP can be used for
the duration of the DHCP lease, but this is different from how other
protocols (e.g., NAT-PMP) function where the NAT device is permitted
to reboot and lose its pinholes. This is by design, because the
service provider-operated PCP server and PCP-controlled device are
expected to have persistent storage so that pinholes are not
forgotten upon failure of the PCP server or failure of the PCP-
controlled device (e.g., NAT or firewall).
It is NOT RECOMMENDED that the server allow long lifetimes (exceeding
24 hours), because they will consume ports even if the internal host
is no longer interested in receiving the traffic (e.g., due to crash
or power failure of the PCP client). Other mechanisms, such as a web
Wing Expires April 21, 2011 [Page 22]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
portal or even a publicly-routed IP address, are probably more
appropriate for such long-duration mappings.
The PCP server SHOULD be configurable for permitted minimum and
maximum lifetime, and the RECOMMENDED values are 120 seconds for the
minimum value and 24 hours for the maximum.
11.2. Pinhole deletion
A pinhole MUST be deleted by the PCP Server upon the expiry of its
lifetime, or upon request from the PCP client.
In order to prevent another subscriber from receiving unwanted
traffic, the PCP server SHOULD NOT assign that same external port to
another host for 120 seconds (MSL, [RFC0793]). [Ed. Note: it should
(MUST?) allow the same host to re-acquire the same port, though.]
11.3. Subscriber Identification
[Ed. Note: This belongs in the section describing each deployment
model]
A PCP Client can instruct mappings in a PCP-controlled device on
behalf of a third party device (e.g., webcam). In order to prevent a
PCP Client to ask for mappings on behalf of a device belonging to
another subscriber, the following rules are to be followed depending
on the PCP-controlled device:
o If the PCP-controlled device is a NAT64: the internal IP address
indicated in the PCP message and the source IPv6 address of
received PCP request MUST belong to the same IPv6 prefix. The
length of the IPv6 prefix is the same as the length assigned to
each subscriber on that particular network.
o If the PCP-controlled device is a DS-Lite AFTR: DS-Lite (Section
11 of [I-D.ietf-softwire-dual-stack-lite]) already requires the
tunnel transport source address be validated, and that same
address is used by PCP to assign the tunnel-ID to the requested
mapping (see Section 13.1.2 and Section 13.1.3). Thus, PCP
acquires the same security properties as DS-Lite. If address
validation is implemented correctly, the PCP Client can not
instruct mappings on behalf of devices of another subscriber.
PCP-controlled devices can be a DS-Lite AFTR or an IPv4-IPv6
interconnection node such as NAT46 or NAT64. These nodes are
deployed by Service Providers to deliver global connectivity service
to their customers. Appropriate functions to restrict the use of
these resources (e.g., CGN facility) to only subscribed users should
Wing Expires April 21, 2011 [Page 23]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
be supported by these devices. Access control can be implicit or
explicit:
o It is said to be explicit if an authorisation procedure is
required for a user to be granted access to such resources. For
such variant of PCP-controlled device, a subscriber can be
identified by an IPv6 address, an IPv4 address, a MAC address, or
any other information.
o For other scenarios, such as plain IPv4-in-IPv6 encapsulation for
a DS-Lite architecture, the access to the service is based on the
source IPv6 prefix. No per-user polices is pre-configured in the
PCP-controlled device.
Subscribers identification is required for several reasons such as
the following:
o Allow access to the network resources;
o Configure service profiles such as a bandwidth and/or port usage
quotas for fairness service usage among all subscribers;
o Blacklist a subscriber because of abuse or non-payment of service
fee, etc.
o Legal requirements such as legal intercept or legal storage;
o Etc.
11.4. External IP Address
If there are active mappings for a particular PCP Client -- created
via dynamic assignment or created by PCP -- subsequent mapping
requests from that same PCP Client MUST use the same external IP
address. This is necessary because some protocols require using the
same IP address for several ports.
11.5. Policy Configuration
A PCP Server MAY be configured with various policies such as:
o Supported transport protocols;
o Ports to be excluded from the allocation process;
o Behaviour when a well-known port is requested: [[Note: A specific
configuration: what to do when a PCP Client asks for a WKP but
this port associated with the assigned external IP address (for
Wing Expires April 21, 2011 [Page 24]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
dynamic mapping and not for configured mappings) is used but this
port is available in other addresses. This flexibility in the
decision-making process of the PCP Server mitigates some of the
limitations of sharing IP addresses.]]
o Maximum number of ports be assigned to that subscriber;
o Enable/disable port preservation; that means the PCP Server always
assign the requested port number when that port is in not in use
for the corresponding external IP address and transport protocol;
o Enable/disable port randomization;
o Enable/disable port range allocation policy;
o Enable/disable port parity preservation;
o Enable/disable port contiguity;
o Enable/disable DSCP re-marking;
o Enable/disable DSCP filtering;
o Enable/disable restricting remote IP address;
o Logging of PCP-mapped ports.
PCP Server MUST be aware of the configured IPv4 address pool(s),
ports in use, etc. It is outside this document to specify how this
information is known to the PCP Server. This is implementation-
specific.
12. Failure Scenarios
In the following sub-sections we discuss PCP failure scenarios.
12.1. Host Reboot/PCP Client Failure
From a PCP Client perspective, several failure scenarios can be
experienced by the host embedding that PCP Client (e.g., manual
reboot, crashes, power outage, etc.).
[[To be completed. PCP client can request removal of its mappings
(if any) and establish new mappings.]]
If the PCP Client has instructed a PCP Server to create mappings on
behalf of a third party (e.g., webcam device), any connectivity
Wing Expires April 21, 2011 [Page 25]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
change occurred in that third party device requires updating its
associated mappings. Concretely, if a new IP address is assigned to
that device: this change can be notified to the PCP Client by other
means (e.g., the PCP Client is embedded in the same DHCP server which
assigns IP addresses to internal hosts, administration GUI, etc.).
In such case, the PCP Client MUST update the mapping with the new
assigned internal IP address.
12.2. PCP Proxy/PCP Interworking Function
[[Editor's note: remove this section?]]
A failure/reboot of a device embedding a PCP Proxy or a PCP
Interworking Function may lead to a change of the IP address of the
external interface of that device and/or the loss of the mappings.
The PCP Proxy or PCP Interworking Function behaves as follows
according to its ability to recover locally installed mappings:
o Persistent storage of the mappings:
* Change of the IP address of the external interface of the PCP
Proxy/PCP Interworking Function: the PCP Proxy/PCP Interworking
Function MUST update all its associated mappings in the PCP
Server (see Section 10.1);
* The same IP address is assigned to the external interface of
the PCP Proxy/PCP Interworking Function: No action is to be
undertaken by the PCP Proxy/PCP Interworking Function.
o Non-persistent storage of the mappings:
* The PCP Proxy MUST delete all pinholes to the subscriber.
13. Deployment Scenarios
13.1. Dual Stack-Lite
13.1.1. Overview
Various PCP deployment scenarios can be considered to control an
AFTR.
1. UPnP IGD and NAT-PMP are used in the LAN: an interworking
function is required to be embedded in the CP router to ensure
interworking between the protocol used in the LAN and PCP. UPnP
IGD-PCP Interworking Function is described in Section 3.4.
Wing Expires April 21, 2011 [Page 26]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
2. Hosts behind the CP router embed a PCP Client, and communicate
directly with the PCP server. No interworking function is
required to be embedded in the CP router. In the LAN, the IP
address to reach an external PCP Server or a local PCP Proxy is
advertised to PCP Clients owing to one of the recommended methods
in Section 4.
3. The CP router embeds a PCP Client invoked for HTTP-based
configuration (as is common today). The internal-IP-address in
the PCP payload would be the internal host used in the port
forwarding configuration and the destination IPv4 address is
provisioned owing to the one of the recommended methods in
Section 4. The UDP destination port number MUST be set to the
IANA allocated destination port for PCP.
Two modes are identified to forward PCP packets to a PCP Server
controlling the provisioned AFTR as described in the following sub-
sections.
13.1.2. Encapsulation Mode
[Ed. Note: This section needs changes.]
In this mode, CP router (B4) does no processing at all of the PCP
messages, and forwards them as any other UDP traffic. With DS-Lite,
this means that PCP messages issued by internal PCP Clients are
encapsulated in IPv6 packets and sent to the AFTR as for any other
IPv4 packets. The AFTR de-encapsulates the IPv4 packets and
processes the PCP requests (because the destination IPv4 address
points to the PCP Server embedded in the AFTR).
Like for any other IPv4 packet received by the AFTR in the softwire
tunnel, the source IPv6 address of the received IPv4-in-IPv6 PCP
packet is stored by the PCP Server.
13.1.3. Plain IPv6 Mode
[Ed. Note: This section needs changes.]
Another alternative for deployment of PCP in a DS-Lite context is to
rely on a PCP Proxy in the CP router. Protocol exchanges between the
PCP Proxy and the PCP Server are conveyed using plain IPv6 (no
tunnelling is used). Nevertheless, the IPv6 address used as source
address by the PCP Proxy MUST be the same as the one used by the B4
element. This IPv6 address is maintained by the PCP Server in its
PCP mapping table.
Wing Expires April 21, 2011 [Page 27]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
13.2. NAT64
[Ed. Note: This section needs changes.]
Hosts behind a NAT64 device can make use of PCP in order to perform
port reservation (to get a publicly routable IPv4 port).
If the IANA-assigned IP address is used for the discovery of the PCP
Server, that IPv4 address can be placed into the IPv6 destination
address following that particular network's well-known prefix or
network-specific prefix, per [I-D.ietf-behave-address-format].
13.3. NAT44
[Ed. Note: This section needs changes.]
13.4. IPv6 Firewall
[Ed. Note: This section needs changes.]
14. Security Considerations
[Ed. Note: to be completed.]
15. IANA Considerations
IANA is requested to perform the following actions:
15.1. PCP IP address
Assign an IPv4 and an IPv6 address for PCP discovery. This is
denoted as PCP-IPV4 and PCP-IPV6 in this document. [[RFC-Editor:
please update occurrences with the IANA-assigned value.]]
15.2. PCP Port Number
Re-use NAT-PMP port number.
15.3. PCP OpCodes
Create a new protocol registry for PCP OpCodes populated with the
values in Figure 6.
New OpCodes can be created via Standards Action [RFC2434].
Wing Expires April 21, 2011 [Page 28]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
15.4. PCP Error Codes
IANA shall create a new registry for PCP error codes, numbered 0-255,
initially populated with the error codes XX.YY.
New Error Codes can be created via Specification Required [RFC2434].
15.5. PCP Information Elements
IANA shall create a new registry for PCP Information Elements,
numbered 0-65535 with associated mnemonic.
New information elements in the range 0-32768 can be created via
Standards Action [RFC2434], new information elements in the range
32769-64511 can be created with Expert Review [RFC2434], and the
range 64512-65535 is for Private Use [RFC2434].
16. Acknowledgments
Thanks to Francis Dupont, Alain Durand, and Christian Jacquenet for
their comments and review.
17. References
17.1. Normative References
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
progress), September 2010.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress), July 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Wing Expires April 21, 2011 [Page 29]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[proto_numbers]
IANA, "Protocol Numbers", 2010, <http://www.iana.org/
assignments/protocol-numbers/protocol-numbers.xml>.
17.2. Informative References
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-10 (work in progress),
August 2010.
[I-D.ietf-v6ops-cpe-simple-security]
Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment for Providing Residential IPv6
Internet Service", draft-ietf-v6ops-cpe-simple-security-15
(work in progress), October 2010.
[I-D.miles-behave-l2nat]
Miles, D. and M. Townsley, "Layer2-Aware NAT",
draft-miles-behave-l2nat-00 (work in progress),
March 2009.
[I-D.nishitani-cgn]
Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida,
"Common requirements for IP address sharing schemes",
draft-nishitani-cgn-05 (work in progress), July 2010.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
Appendix A. Analysis of Techniques to Discover PCP Server
[[Note: This Appendix will be removed in a later version of this
document. It is included here for reference and discussion
purposes.]]
Wing Expires April 21, 2011 [Page 30]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
Several mechanisms for discovering the PCP Server can be envisaged as
listed below:
1. A special-purpose IPv4 or IPv6 address, assigned by IANA, which
is routed normally until it hits a PCP Server, which responds.
Analysis: This solution can be deployed in the context of DS-
Lite architecture. Concretely, a well-known IPv4 address can
be used to reach a PCP Server embedded in the device that
embeds the AFTR capabilities. Since all IPv4 messages issued
by a DS-Lite CP router will be encapsulated in IPv6, no state
synchronisation issues will be experienced because PCP
messages will be handled by the appropriate PCP Server.
In some deployment scenarios (e.g., deployment of several
stateful NAT64/NAT46 in the same domain), the use of this
address is not recommended since PCP messages, issued by a
given host, may be handled by a PCP Server embedded in a NAT
node which is not involved to handle IP packets issued from
that host. The use of this special-purpose IP address may
induce session failures and therefore the customer may
experience troubles when accessing its services.
Consequently, the use of a special-purpose IPv4 address is
suitable for DS-Lite NAT44. As for NAT46/NAT64, this is left
to the Service Providers according to their deployment
configuration.
The special-use address MUST NOT be advertised in the global
routing table. Packets with that destination address SHOULD
be filtered so they are not transmitted on the Internet.
2. Assume the default router is a PCP Server, and send PCP packets
to the IP address of the default router.
Analysis: This solution is not suitable for DS-Lite NAT44 nor
for all variants of NAT64/NAT46.
In the context of DS-Lite: There is no default IPv4 router
configured in the CP router. All outgoing IPv4 traffic is
encapsulated in IPv6 and then forwarded to a pre-configured
DS-Lite AFTR device. Furthermore, if IPv6 is used to reach
the PCP Server, the first router may not be the one which
embeds the AFTR.
For NAT64/NAT46 scenarios: The NAT function is not embedded
in the first router, therefore this solution candidate does
not allow to discover a valid PCP Server.
Wing Expires April 21, 2011 [Page 31]
Internet-Draft Pinhole Control Protocol (PCP) October 2010
Therefore, this alternative is not recommended.
3. Service Location Protocol (SLP [RFC2608]).
Analysis: This solution is not suitable in scenarios where
multicast is not enabled. SLP is a chatty protocol. This
alternative is not recommended.
4. NAPTR. The host would issue a DNS query for a NAPTR record,
formed from some bits of the host's IPv4 or IPv6 address. For
example, a host with the IPv6 address 2001:db8:1:2:3:4:567:89ab
would first send an NAPTR query for
3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (20 elements,
representing a /64 network prefix), which returns the PCP
Server's IPv6 address. A similar scheme can be used with IPv4
using, for example, the first 24 bits of the IPv4 address.
Analysis: This solution candidate requires more configuration
effort by the Service Provider so as to redirect a given
client to the appropriate PCP Server. Any change of the
engineering policies (e.g., introduce new CGN device, load-
based dimensioning, load-balancing, etc.) would require to
update the zone configuration. This would be a hurdle for the
flexibility of the operational networks. Adherence to DNS is
not encouraged and means which allows for more flexibility are
to be promoted.
Therefore, this mechanism is not recommended.
5. New DHCPv6/DHCP option and/or a RA option to convey an FQDN of a
PCP Server.
Analysis: Since DS-Lite and NAT64/NAT46 are likely to be
deployed in provider-provisioned environments, DHCP (both
DHCPv6 and IPv4 DHCP) is convenient to provision the address/
FQDN of the PCP Server.
Author's Address
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Wing Expires April 21, 2011 [Page 32]
| PAFTECH AB 2003-2026 | 2026-04-24 09:01:04 |