o Significant document reorganization, primarily to split base PCP operation from OpCode operation.
o packet format changed to move 'protocol' outside of PCP common header and into the PIN* opcodes
o Renamed Informational Elements (IE) to Options.
o Added REMOTE_PEER, REMOTE_PEER_FILTER, and HONOR_EXTERNAL_PORT options.
o Is NAT or router behind B4 in scope?
o PCP option MAY be included in a request, in which case it MUST appear in a response. It MUST NOT appear in a response if it wasn't in the request.
o Response code most significant bit now indicates permanent/
temporary error
o PCP Options are split into mandatory-to-process ("P" bit), and into Specification Required and Private Use.
o Epoch discussion simplified.
Appendix B. Analysis of Techniques to Discover PCP Server
[Ed. Note: This Appendix will be removed in a later version of this document. It is included here for reference and discussion purposes.]
Discussion Note: A deployment model is a non-PCP aware NAT in a home, and a PCP-aware large scale NAT (LSN) operated by the ISP.
This could work by having the host use UPnP IGD with the in-home NAT, and the host use PCP with the LSN. But this deployment model is impossible with several of the mechanisms below. Is this
deployment model important, or can we wait for PCP to be enabled on CPE?
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 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.
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 LSN device, 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: [email protected]