Subject: [pcp] -06 review: renumbering

From: Paul Selkirk <[email-masked]>
Date: Tue, 08 Mar 2011 04:55:06 +0000

8.7.  Subscriber Renumbering

   The customer premises router might obtain a new IPv4 address or new
   IPv6 prefix.  This can occur because of a variety of reasons
   including a reboot, power outage, DHCP lease expiry, or other action
   by the ISP.  If this occurs, traffic forwarded to the subscriber
   might be delivered to another customer who now has that address.
   This affects both implicit dynamic mappings and explicit dynamic
   mappings.  However, this same problem occurs today when a
   subscriber's IP address is re-assigned, without PCP and without an
   ISP-operated CGN.  The solution is the same as today: the problems
   associated with subscriber renumbering are caused by subscriber
   renumbering and are eliminated if subscriber renumbering is avoided.
   PCP defined in this document does not provide machinery to reduce the
   subscriber renumbering problem.

In other words, subscriber renumbering is out of scope.

   When a new Internal Address is assigned to a host embedding a PCP
   client, the NAT (or firewall) controlled by the PCP server will
   continue to send traffic to the old IP address.  Assuming the PCP
   client wants to continue receiving traffic, it needs to install new
   mappings for its new IP address.  The requested external port field
   will not be fulfilled by the PCP server, in all likelihood, because
   it is still being forwarded to the old IP address.  Thus, a mapping
   is likely to be assigned a new external port number and/or public IP
   address.  Note that this scenario is not expected to happen routinely
   on a regular basis for most hosts, since most hosts renew their DHCP
   leases before they expire (or re-request the same address after
   reboot) and most DHCP servers honor such requests and grant the host
   the same address it was previously using before the reboot.

In other words, host renumbering is also out of scope.

Honestly, we must be able to provide some guidance.

When a host (internal host or CPE) is renumbered, it breaks all
existing mappings made by that host (for itself or on behalf of its
internal hosts).  When a PCP client goes to renew a mapping, it will
get back a different mapping.  Since the PCP server is probably
unaware of the renumbering, it can't set Epoch=0 for that client
(even if it has per-client epochs).  So the brokenness discovery will
be piecemeal, as PCP clients attempt to renew.

OTOH, if the CPE is renumbered, and it is running IWF proxies, it
will attempt to renew or re-create mappings for its internal hosts.
The IWF specs should include a way to signal internal clients that
their mappings have changed, so that they can re-advertise them.

				paul