A fter the transition to Internet Protocol Version 6 (IPv6), hosts will often be behind IPv6 firewalls. But before the transition, mobile wireless devices will want to reduce their keepalive messages, and hosts of all sorts will share IPv4 addresses using a variety of address-sharing technologies. To meet these needs, the IETF formed the Port Control Protocol Working Group in August 2010 to define a new protocol for hosts to communicate with such devices. The initial output of this Working Group is the Port Control Protocol (PCP). Interoperability between two independently developed implementations of PCP was demonstrated at the IETF meeting in July 2011, highlighting the importance of this protocol to the industry. After it becomes a standard, PCP is expected to be deployed in various operating systems, IPv6 home gateways, IPv4 home gateways (Network Address Translators [NATs]), mobile third- and fourth-generation (3G and 4G, respectively) gateways (Gateway GPRS Support Nodes [GGSNs]), and Carrier-Grade NATs (CGNs).
Introduction to PCP
PCP performs two major functions: It allows packets to be received from the Internet to a host (such as to operate a server), and allows a host to reduce keepalive traffic of connections to a server. PCP can be extended in two ways: with new OpCodes or with new Options. The base PCP specification defines two OpCodes: map and peer , and defines several Options that can be carried with those OpCodes.
To operate a server, packets are sent from a host on the Internet to a server. The IP model expects devices to be connected to a network and be able to exchange packets with each other. However, few deployed networks actually permit hosts to receive packets from the Internet because of business needs (for example, to protect wireless spectrum from malicious or accidental packets originated on the Internet) or because of technology restrictions (for example, IPv4 address-sharing devices such as Network Address and Port Translators [NAPT]). To operate a server, a host uses the map OpCode.
To reduce keepalives, a host needs to send traffic before a middlebox will destroy an idle connection. Many middleboxes, such as firewalls or NATs, maintain state and will destroy mappings if the connection has been idle. Today, in order to prevent destruction of mappings, hosts send keepalive traffic to keep those mappings alive. The keepalive traffic has several disadvantages, including reduction of battery lifetime, network chatter, and server scalability (servers have to discard the keepalive traffic). PCP allows a host to determine how aggressively a middlebox will destroy an idle connection, allowing the host to reduce its keepalive traffic with the PEER OpCode.
PCP is encoded in binary and carried over the User Datagram Protocol (UDP), which eases implementation on clients and servers. The client is responsible for retransmitting messages, and all messages are idempotent. The PCP client can be part of the operating system (much like a Dynamic Host Configuration Protocol [DHCP] client or a Universal Plug and Play [UPnP] Internet Gateway Device Protocol [IGD] client) or the PCP client can be coded entirely in an application (much like any other application-level protocol such as the Network Time Protocol [NTP]). A major feature of PCP is its flexibility and simple messaging, so it can be implemented easily in a variety of systems and at high scale.
With both IPv4 NAPT and RFC 6092 IPv6 routers, outgoing traffic from a host creates a mapping that then allows bidirectional traffic to a specific (Transmission Control Protocol [TCP] or UDP) port on the internal host, meaning when a host sends a TCP SYN, a SYN ACK can be returned to the host. Neither IPv4 NAPT devices nor RFC 6092 IPv6 routers have to do any additional filtering of that mapping, and after that mapping is created will allow traffic from any host on the Internet to reach the internal host—not just traffic from that particular host. This lack of filtering is necessary for certain applications
to function.
PCP was built with a security model similar to that deployed on home networks. With PCP, a host can send a PCP packet requesting a mapping so that any host on the Internet can now initiate communications with the internal host. Similarly, without PCP, a host could send a TCP SYN from a specific port (for example, port 80), thereby creating a mapping nearly identical to a PCP mapping. As with sending a TCP SYN, PCP allows a host to open mappings only for itself, unless the network administrator has taken the extra step to enable the PCP THIRD_PARTY option.
You may wish to have additional restrictions for some networks. PCP is extensible to support authorization, and there is ongoing work to support authentication and authorization within PCP.
PCP is extensible and there are already several proposed extensions to the protocol, including a way to control which IP address pool is assigned to a mapping, bulk port allocation to optimize acquiring a large set of ports, and rapid recovery after NAT failure or network renumbering.
Introduction to PCP
PCP performs two major functions: It allows packets to be received from the Internet to a host (such as to operate a server), and allows a host to reduce keepalive traffic of connections to a server. PCP can be extended in two ways: with new OpCodes or with new Options. The base PCP specification defines two OpCodes: map and peer , and defines several Options that can be carried with those OpCodes.
To operate a server, packets are sent from a host on the Internet to a server. The IP model expects devices to be connected to a network and be able to exchange packets with each other. However, few deployed networks actually permit hosts to receive packets from the Internet because of business needs (for example, to protect wireless spectrum from malicious or accidental packets originated on the Internet) or because of technology restrictions (for example, IPv4 address-sharing devices such as Network Address and Port Translators [NAPT]). To operate a server, a host uses the map OpCode.
To reduce keepalives, a host needs to send traffic before a middlebox will destroy an idle connection. Many middleboxes, such as firewalls or NATs, maintain state and will destroy mappings if the connection has been idle. Today, in order to prevent destruction of mappings, hosts send keepalive traffic to keep those mappings alive. The keepalive traffic has several disadvantages, including reduction of battery lifetime, network chatter, and server scalability (servers have to discard the keepalive traffic). PCP allows a host to determine how aggressively a middlebox will destroy an idle connection, allowing the host to reduce its keepalive traffic with the PEER OpCode.
PCP is encoded in binary and carried over the User Datagram Protocol (UDP), which eases implementation on clients and servers. The client is responsible for retransmitting messages, and all messages are idempotent. The PCP client can be part of the operating system (much like a Dynamic Host Configuration Protocol [DHCP] client or a Universal Plug and Play [UPnP] Internet Gateway Device Protocol [IGD] client) or the PCP client can be coded entirely in an application (much like any other application-level protocol such as the Network Time Protocol [NTP]). A major feature of PCP is its flexibility and simple messaging, so it can be implemented easily in a variety of systems and at high scale.
 |
| PCP Mapping IPv6 and IPv4 |
>>Security
When installing an IPv4 NAPT on a residential network, the NAPT has a side effect: it prevents unsolicited incoming traffic from reaching hosts inside the home. Traffic that originates inside the home can traverse the NAPT toward the Internet. This function is expected by many users to such a degree that when IPv6-capable routers were first installed on residential networks, users complained that their IPv6 hosts were seeing traffic from the Internet. This visibility meant that IPv6 printers, webcams, and other hosts had to be protected from malicious traffic from the Internet. Based on this experience, IPv6 Customer Premises Equipment (CPE) routers intended for installation in the residential market filter most unsolicited incoming traffic by default. Thus, IPv6 CPE routers provide filtering similar to what users experience today with IPv4 NAPT devices.
With both IPv4 NAPT and RFC 6092 IPv6 routers, outgoing traffic from a host creates a mapping that then allows bidirectional traffic to a specific (Transmission Control Protocol [TCP] or UDP) port on the internal host, meaning when a host sends a TCP SYN, a SYN ACK can be returned to the host. Neither IPv4 NAPT devices nor RFC 6092 IPv6 routers have to do any additional filtering of that mapping, and after that mapping is created will allow traffic from any host on the Internet to reach the internal host—not just traffic from that particular host. This lack of filtering is necessary for certain applications
to function.
PCP was built with a security model similar to that deployed on home networks. With PCP, a host can send a PCP packet requesting a mapping so that any host on the Internet can now initiate communications with the internal host. Similarly, without PCP, a host could send a TCP SYN from a specific port (for example, port 80), thereby creating a mapping nearly identical to a PCP mapping. As with sending a TCP SYN, PCP allows a host to open mappings only for itself, unless the network administrator has taken the extra step to enable the PCP THIRD_PARTY option.
You may wish to have additional restrictions for some networks. PCP is extensible to support authorization, and there is ongoing work to support authentication and authorization within PCP.
PCP is extensible and there are already several proposed extensions to the protocol, including a way to control which IP address pool is assigned to a mapping, bulk port allocation to optimize acquiring a large set of ports, and rapid recovery after NAT failure or network renumbering.
No comments:
Post a Comment