7. Pinhole Operation
7.1. OpCode Packet Format
The four PIN OpCodes (PIN44, PIN46, PIN64, PIN66) share a similar packet layout for both requests and responses. Because of this
similarity, they are shown together. For all of the PIN OpCodes, if the request's internal-ip-address and internal-port matches the
response's external-ip-address and external-port, the IP addresses and ports are not changed and thus the functionality is purely a
firewall; otherwise it pertains to a network address translator which
might also perform firewall functions.
The following diagram shows the request packet format for PIN44, PIN46, PIN64, and PIN66. This packet format is aligned with the response packet format:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : Pinhole Internal IP address (32 or 128, depending on OpCode) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : Requested external IP address (32 or 128, depending on OpCode):
: : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | requested external port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: PIN OpCode Request Packet Format These fields are described below:
Protocol: indicates protocol associated with this opcode. Values are taken from the IANA protocol registry [proto_numbers]. For example, this field contains 6 (TCP) if the opcode is intended to create a TCP mapping. If a particular OpCode does not need the field, it MUST sent as 0 and MUST be ignored when received.
Reserved: MUST be 0 on transmission and MUST be ignored on reception.
Pinhole Internal IP Address: Internal IP address of the pinhole.
This can be IPv4 or IPv6, depending on the OpCode.
Requested External IP Address: Requested external IP address. This is useful for refreshing a mapping, especially after the PCP
server loses state. If the PCP server can fulfill the request, it will do so. If the PCP client doesn't know the external address, or doesn't have a preference, it MUST use 0.
Requested lifetime: Requested lifetime of this pinhole, in seconds.
internal port: Internal port for the pinhole.
Requested external port: requested external port for the mapping.
This is useful for refreshing a mapping, especially after the PCP server loses state. If the PCP server can fulfill the request, it will do so. If the PCP client doesn't know the external port, or doesn't have a preference, it MUST use 0.
The following diagram shows the response packet format for PIN44, PIN46, PIN64, and PIN66:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : Pinhole Internal IP address (32 or 128, depending on OpCode) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : Assigned external IP address (32 or 128, depending on OpCode) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | assigned external port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: PIN OpCode Response Packet Format These fields are described below:
Protocol: Copied from the request.
Reserved: MUST be 0 on transmission, MUST be ignored on reception.
Pinhole Internal IP address: Copied from the request. IPv4 or IPv6 address is indicated by the OpCode.
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 7.2. OpCode-Specific Error Codes
In addition to the response codes described in Figure 6, the
following additional response codes may be returned as a result of the four PIN OpCodes received by the PCP server.
130 - NOT_AUTHORIZED
(e.g., PCP server supports mapping, but feature is disabled) 3 - Network Failure
(e.g., NAT device has not obtained a DHCP lease) 4 - Out of resources
(e.g., NAT device cannot create more mappings at this time) [Ed. Note: probably need an OpCode indicating that the
REMOTE_PEER option is necessary to disambiguate a connection. Do we require the PCP server to figure out there is an ambiguity (multiple connections using the same port)? Probably.]
Figure 10: Result Codes specific to PIN OpCodes
Other OpCodes are in result codes are defined following the procedure in Section 11.4.
7.3. OpCode-Specific Client Operation, Processing a Response
[Ed. Note: describe how PCP client sends a PIN* request, and might get an Invalid Opcode response, and what it does.]
This section describes the operation of a client when sending the OpCodes PIN44, PIN64, PIN46, or PIN66.
A response is matched with a request by comparing the protocol, internal IP address, internal port, remote peer address and remote peer port. Other fields are not compared, because the PCP server changes those fields to provide information about the pinhole created by the OpCode.
If a successful response, the PCP client 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 rendezvous mechanism.
If an unsucessful response code greater than or equal to 128, the PCP client SHOULD NOT re-issue the same request. If a response code less than or equal to 127, the PCP client MAY, if it wishes, resend the same message after a delay of at least 5 seconds.
7.4. OpCode-Specific Server Operation
This section describes the operation of a client when processing the OpCodes PIN44, PIN64, PIN46, or PIN66.
If the requested lifetime is 0, it indicates a Delete request. This means the pinhole described by the internal IP address should be deleted, and requested external port field is ignored by the server (that is, it isn't validated). If the deletion request was
successful, a positive response generated containing external port of 0 and lifetime of 0. If the deletion request was unsusccessful a non-zero result code is returned and the lifetime is undefined. If the client attempts to delete a port mapping which was manually assigned by some kind of configuration tool, the PCP server MUST respond with a 'Not Authorized' error (result code 2).
[Ed. Note: Should we similarly return an error if attempting to delete mappings that were created dynamically (e.g., TCP SYN)?]
[Ed. Note: Issue #15: Should ICMP messages, associated with this pinhole, be allowed by default. Consensus appears to be 'yes', because that is what dynamic mappings on NATs do. And if we don't do this, we will have PCP clients forget (or avoid) requesting an ICMP pinhole, further degrading ICMP operation on the Internet.]
[Ed. Note: The following text needs discussion. Keep it or discard it?] When a mapping is destroyed as a result of its lifetime expiring or for any other reason, if the NAT gateway's internal state indicates that there are still active TCP
connections traversing that now- defunct mapping, then the NAT gateway SHOULD send appropriately- constructed TCP RST (reset) packets both to the local client and to the remote peer on the Internet to terminate that TCP connection.
A client can request the explicit deletion of all its UDP or TCP
mappings by sending the same deletion request to the NAT gateway with external port, internal port, and lifetime set to 0. A client MAY choose to do this when it first acquires a new IP address in order to protect itself from port mappings that were performed by a previous owner of the IP address. After receiving such a deletion request, the PCP server and NAT MUST delete all the port mappings. The PCP
server responds to such a deletion request with a response as described above, with the internal port set to zero. If the PCP server is unable to delete a port mapping, for example, because the mapping was manually configured by a configuration tooll, the gateway MUST still delete as many port mappings as possible, but respond with a non-zero result code. The exact result code to return depends on the cause of the failure. If the gateway is able to successfully delete all port mappings as requested, it MUST respond with a result code of 0.
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 7200 seconds (i.e., two hours).
By default, a PCP-controlled device MUST NOT create mappings for a protocol not indicated in the request. For example, if the request was for a TCP mapping, a UDP mapping MUST NOT be created.
Nevertheless, a configurable feature MAY be supported by the controlled device, which MAY reserve (but not forward) the companion port so the same PCP Client can request 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 as the request plus 128.
7.4.1. Maintaining Same 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, and follows REQ-1 of
[I-D.ietf-behave-lsn-requirements]. Once a client has no active dynamic mappings and no PCP pinholes, a subsequent dynamic mapping or PCP request MAY be assigned to a different external IP address.
7.4.2. Pinhole Lifetime
Once a PCP server has responded positively to a pinhole request for a certain lifetime, the port forwarding is active for the duration of the lifetime unless deleted by the PCP client (or until the PCP server crashes). This has interactions with dynamically-created mappings, see Sections Section 7.6.
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 or no longer
connected to the network.
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.
7.4.3. 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.]
7.4.4. Subscriber Identification
The PIN OpCodes require subscriber identification because they
allocate resources to a subscriber. A PCP Client can create mappings in a PCP-controlled device on behalf of a third party device (e.g., a computer can create PCP mappings on behalf of a webcam). However, a PCP client cannot open pinholes for a different subscriber. The
mechanism to identify "same subscriber" depends on the sort of NAT on this network:
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 (e.g., /64), and that length must be configurable by the network operator.
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 8.1.2 and Section 8.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.
o If LSN with a routed network (NAT44), each subscriber has a known set of IPv4 address (usually one IPv4 address) and all PCP
requests MUST be sent from only one of the subscriber's IP
addresses and MUST only open pinholes towards the subscriber's own own IP address.
o If IPv6 firewall: 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 (e.g., /64), and that length must be configurable by the network operator.
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., LSN facility) to only subscribed users should 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.
7.4.5. Renumbering
The customer premise 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 who now has that (old) address. This same problem can occur if an IP address is re-assigned today, without PCP. The solution is the same as today: ISPs should not re-assign IP
addresses.
7.4.6. Disambiguating Remote Peer
When operating a UDP or TCP server, one application is listening on a port and no other application will be assigned that port by the
operating system. However, ephemeral connections (that is, outgoing connections) to different servers can share the same ephemeral port, even between applications. If a PCP request with a PIN OpCode is sent after such a dynamic connection is established (potentially by
another application), the PCP server cannot reliable distinguish if the PIN request is referring to the current connection or to a new connection. To eliminate this ambiguity, the remote peer's IP address and port can be specified in the REMOTE_PEER Option.
This Option does not create or modify filtering on the NAT (for that, use REMOTE_PEER_FILTER) and have no effect on the NAT or firewall's normal filtering which will be any combination of
Independent Filtering, Address-Dependent Filtering, or Address and Port-Dependent Filtering (these terms are originally defined and explained in [RFC4787]).
7.5. PCP Options for PIN OpCodes 7.5.1. REMOTE_PEER_FILTER
This Option indicates packet filtering is desired. The remote peer port and remote peer IP Address indicate the permitted remote peer's source IP address and port for packets from the Internet. That is, packets with a source IP address, transport, or port that do not match those fields of the PCP request are dropped by the PCP controlled NAT/firewall device. As a consequence of dropping the packet, an ICMP port unreachable error SHOULD be generated, as long as it does not violate the security policy of the NAT/firewall.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Peer Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : Remote Peer IP address (32 bits if PIN44 or PIN64, : : 1 28 bits if PIN46 or PIN66) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This Option:
value: 128
is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66 is included in responses: MUST
has length: 64 or 160
may appear more than once: no
Because of interactions with dynamic ports (Section 7.6), this Option
MUST only be used by a client that is operating a server, as this ensures that no other application will be assigned the same ephemeral port for its outgoing connection. Other use by a PCP client is NOT RECOMMENDED and will cause some UNSAF NAT traversal mechanisms
[RFC3424] to fail where they would have otherwise succeeded, breaking other applications running on this same host.
[Ed. Note: How do we want to remove a filter? Do we want to allow removing a filter at all -- is there a use-case for that or can the application just create a new mapping? If we have a case, perhaps use 0.0.0.0 as the remote IP address to remove all filters?
7.5.2. REMOTE_PEER
Due to a pre-existing dynamic mapping, a PCP server may not be able to instantiate a filter on a specific port. It is thus recommended that applications bind to the source port (to prevent other
applications from using that same source port) prior to using this PCP Option.
In those situations, the Option REMOTE_PEER is necessary to
disambiguate the mappings. This option does not change filtering behavior of the NAT or firewall.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Peer Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : Remote Peer IP address (32 bits if PIN44 or PIN64, : : 1 28 bits if PIN46 or PIN66) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This Option:
value: 129
is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66 is included in responses: MUST
has length: 64 or 160
may appear more than once: no
7.5.3. HONOR_EXTERNAL_PORT
This option indicates the PCP client needs to have the indicated requested-eternal-port allocated. If the PCP server cannot provide that port for the exclusive use of the PCP client, the PCP server MUST return an error [which code should we use?].
This option is intended for use by UPnP IGD interworking (Section 9).
This Option:
value: 6
is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66 is included in responses: MUST
has length: 0
may appear more than once: no 7.6. Interaction with Dynamic Connections
Dynamic connections are created by hosts sending a TCP or UDP packet across their NAT. PCP can be used with such dynamic connections.
There are two interesting cases: PCP before a dynamic connection, and PCP after a dynamic connection.
If two applications on the same host communicate with different destinations, it is possible for them to be allocated the same
ephemeral source port -- without either of the applications using the REUSEADDR socket option. Thus, one application's use of PCP (to
adjust the NAT or firewalls behavior) can affect an unrelated application on the same host. This is why the four PIN OpCodes
include the remote peer fields. The remote peer fields allow the PCP server to to disambiguate which mapping applies to the PIN OpCode message.
Because PCP is not intended to adjust NAT behavior for created connections, it is possible (and reasonable) for that second dynamic connection to be mapped to a different public port. Even if that occurs, the other application can issue its own PCP request (to determine the mapping lifetime) following the same procedure
described in this section.
7.7. Using PCP to Eliminate Application Keepalive Messages
Middleboxes such as NATs or firewalls need to see occasional traffic or will terminate their session state, causing application failures.
To avoid this, many applications routinely generate keepalive traffic for the primary or sole purpose of maintaining state with such
middleboxes. Applications can avoid such application keepalive traffic by using PCP.
To use PCP for this function, the applications first connects to its server, as normal. Afterwards, it issues a PCP PIN request (PIN44, PIN64, PIN46, or PIN66, as appropriate) specifying the same 5-tuple as that connection in the PCP PIN request (internal IP address and port, transport protocol, and remote peer IP address and port), with requested-external-address and requested-external-port both set to 0, and includes the REMOTE_PEER Option indicating the remote peer's IP address is from the perspective of the PCP client. The PCP response will indicate the lifetime for that session.
On many common platforms (i.e. those making use of the BSD sockets API), using PCP for purposes of application keepalives by issuing a
On many common platforms (i.e. those making use of the BSD sockets API), using PCP for purposes of application keepalives by issuing a