Subject: [pcp] Should we do more on "10.6 Address Change Events"

From: GangChen <[email-masked]>
Date: Wed, 21 Dec 2011 15:43:21 +0800

Dear authors,

Current text has clear problem description. That is actually a real
case we faced today, i.e. "traffic forwarded to the host's previous
address might be delivered to another host which now has that
address."

I'm just wondering to know should we do more on this case other than
just installing new mappings for its new IP address.

I think it could be useful to delete the old mapping as well to
mitigate the affects for new-joined host.

Many thanks

Gang

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Dec 2011 15:03:39 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> GangChen
> Sent: Tuesday, December 20, 2011 11:43 PM
> To: [email-masked]
> Subject: [pcp] Should we do more on "10.6 Address Change Events"
> 
> Dear authors,
> 

> mitigate the affects for new-joined host.

That could only work if the host is connected to the same
network, but for some (odd) reason was given a different IP
address.  This doesn't happen too often; DHCP servers try
to reassign the same IP address to the same host.

And Section 10.5 encourages a host joining a new network to clear
old mappings for its IP address,

http://tools.ietf.org/html/draft-ietf-pcp-base-19#section-10.5

   ...
   PCP provides some protections against such port
   consumption: When a PCP client first acquires a new IP address (e.g.,
   reboots or joins a new network), it SHOULD remove mappings that may
   already be instantiated for that new Internal Address.  To do this,
   the PCP client sends a MAP request with protocol, internal port, and
   lifetime set to 0.  Some port mapping APIs (e.g., the
   "DNSServiceNATPortMappingCreate" API provided by Apple's Bonjour on
   Mac OS X, iOS, Windows, Linux [Bonjour]) automatically monitor for
   process exit (including application crashes) and automatically send
   port mapping deletion requests if the process that requested them
   goes away without explicitly relinquishing them.
   ...

-d

> Many thanks
> 
> Gang
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: GangChen <[email-masked]>
Date: Thu, 22 Dec 2011 21:43:48 +0800

> to reassign the same IP address to the same host.

That is not a rare case actually. It is happened so often every day in
mobile network, where there is a fierce competition on IPv4
assignment. When a host quits accidentally, the address would be
assigned to another.

> old mappings for its IP address,

Thanks for pointing me to this paragraph. The text seems have two-fold
meaning. Please correct me if I'm wrong.

>    lifetime set to 0.

That is new joined host clear old mapping for its new IP/port.

>    Some port mapping APIs (e.g., the

That seems host clear the mapping for its released/old port.
.
Gang

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Dec 2011 11:12:45 -0800

> From: GangChen [mailto:[email-masked]]
> Sent: Thursday, December 22, 2011 5:44 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] Should we do more on "10.6 Address Change Events"
> 
> assignment.

If the addresses are NATted, as I am sure they are, I don't see 
why someone would design such a tiny IPv4 address pool to cause
fierce competition of IPv4 addresses.  But, stranger things
have happened.

> When a host quits accidentally, the address would be
> assigned to another.

Another way to fix that when the network infrastructure decides
an IP address is on the 'available' list, it issues a PCP request
with THIRD_PARTY to clear the mappings for that address.  That
way, when the address is re-assigned, its PCP-created mappings 
have already been cleared.
  
> That is new joined host clear old mapping for its new IP/port.

Correct.

> That seems host clear the mapping for its released/old port.

No, it just handles the case where an application requests a port 
mapping and gets a port mapping, but then the application crashes.
The host continues to run and the host's IP address doesn't change.

-d

---

From: GangChen <[email-masked]>
Date: Fri, 23 Dec 2011 09:53:27 +0800

> fierce competition of IPv4 addresses.  But, stranger things

It is unavoidable, because RFC1918 only provide 16 million address and
users under a GGSN would far exceed the numbers.

> have already been cleared.

Great.
That is also a solution in my mind. For now, I see two approaches to
resolve the problem
1) New joined host proactively clear potential old mapping, like Section-10.5.
2) Using THIRD_PARTY to clear a specific mapping avoiding negative impacts

BRs

Gang