Subject: [pcp] About PCP Client

From: Tina TSOU <[email-masked]>
Date: Thu, 19 Jan 2012 00:41:09 +0000

Hi,
In http://tools.ietf.org/html/draft-ietf-pcp-base-04#page-19
8.4.1.  Maintaining Same External IP Address

   If there are active mappings associated with a given subscriber (see
   Section 10.5) -- created via dynamic assignment, by PCP or any other
   means -- subsequent PCP mapping requests belonging to the same
   subscriber MUST use the same external IP address.  This follows the
   intent of REQ-1 of [I-D.ietf-behave-lsn-requirements].

In http://tools.ietf.org/html/draft-ietf-pcp-base-05, there is only behavior description about server, not client. 
10.1.  Maintaining Same External IP Address

   It is REQUIRED that the PCP-controlled device assign the same
   external IP address PCP-created explicit dynamic mappings and to
   implicit dynamic mappings.  It is RECOMMENDED that static mappings
   (e.g., those created by a command language interface on the PCP
   server or PCP-controlled device) also be assigned to the same IP
   address.

>From the point of view of the client, you don't want to depend exclusively on the CGN to ensure that you always get the same external address. You want to signal it explicitly in the PCP messages to be even more certain that you get the same external address.

New proposed texts are below.

(from the client point of view) If there are active mappings associated with a given subscriber created via dynamic assignment, e.g. by PCP, subsequent PCP mapping requests belonging to the same subscriber SHOULD use the same external IP address.

Best Regards,
Tina TSOU

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Jan 2012 22:02:44 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tina TSOU
> Sent: Wednesday, January 18, 2012 4:41 PM
> To: [email-masked]
> Subject: [pcp] About PCP Client
> 
> Hi,
> In http://tools.ietf.org/html/draft-ietf-pcp-base-05, there is only
> behavior description about server, not client.
> From the point of view of the client, you don't want to depend
> exclusively on the CGN to ensure that you always get the same external
> address. You want to signal it explicitly in the PCP messages to be
> even more certain that you get the same external address.
>
> (from the client point of view) If there are active mappings associated
> with a given subscriber created via dynamic assignment, e.g. by PCP,
> subsequent PCP mapping requests belonging to the same subscriber SHOULD
> use the same external IP address.

http://tools.ietf.org/html/draft-ietf-pcp-base-22#section-10.2 (and
several previous versions) already says:

   The request MAY contain values in the Suggested External Port and
   Suggested External IP Address fields.  This allows the PCP client to
   attempt to rebuild lost state on the PCP server, which improves the
   chances of existing connections surviving, and helps the PCP client
   avoid having to change information maintained at its rendezvous
   server.  Of course, due to other activity on the network (e.g., by
   other users or network renumbering), the PCP server may not be able
   to grant the suggested External IP Address and Port, and in that case
   it will assign a different External IP Address and Port.

is there an interoperability problem that would be fixed/improved by
adjusting that text to encourage providing the same Suggested External
Address as existing mappings?

-d

> 
> 
> Best Regards,
> Tina TSOU
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Tina TSOU <[email-masked]>
Date: Thu, 19 Jan 2012 07:36:34 +0000

Tina

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, January 18, 2012 10:03 PM
> To: Tina TSOU; [email-masked]
> Subject: RE: [pcp] About PCP Client
> 
When client and CGN state get out of sync for an unknown reason, it helps.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jan 2012 09:24:37 -0800

> From: Tina TSOU [mailto:[email-masked]]
> Sent: Wednesday, January 18, 2012 11:37 PM
> To: Dan Wing; [email-masked]

Ok, so let's imagine they are out of sync.  Perhaps the NAT crashed,
for example, and lost all its state.

PCP Rapid Recovery, if present, will immediately inform the PCP 
client of the crash.  The PCP client will then ask the NAT (in-home
NAT or CGN works the same way) to re-create the mappings and
request the same public IP address and public port.

If PCP Rapid Recovery is not present, the PCP client won't be
aware of the NAT losing state.  There might or might not be
other activity on the same host (e.g., a TCP connection to
www.amazon.com:80).  Whenever the PCP client sends a new
request to the PCP server, the PCP client will notice the
unexpectedly-lower Epoch value.  This indicates to the PCP
client that the NAT has lost state, and the PCP client will
then re-create its mappings and request the same public IP
address and public port.  Of course, if there was already
some non-PCP activity (e.g., that TCP connection to www.amazon.com:80)
the NAT might have already assigned a different public IP
address to the PCP client.  Which means the connections
cannot be assigned to that 'old' IP address; they have to be
assigned to the new (different) IP address.

All of the above is already in the document, and seems to
cover the situation where the PCP client and the NAT/CGN
are out of sync.

If there is a problem where they get out of sync which doesn't
work, please provide the steps that occur to create the sync
problem.

-d

---

From: Tina TSOU <[email-masked]>
Date: Thu, 19 Jan 2012 17:57:40 +0000

Tina

> Sent: Thursday, January 19, 2012 9:25 AM
I think there might be two cases that client and CGN state get out of sync: 
1. Client has the mappings but CGN already delete them all for some kind of reason.
2. Client deletes all the local mappings but CGN still has the mappings.

In the 1 case, first of all, the connections of applications that have mappings will be broken, I do not see an existing solution for this problem yet, maybe we can suggest that the CGN should send a notification to the client if mappings are deleted.
In this case, if the client sends a request specifying the external address, it may fail. 
I agree this is a problem; it could be fixed together with other problems.
In the 2 case, there is no problem with client; the client can request new mappings.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jan 2012 10:13:30 -0800

...
> In the 1 case, first of all, the connections of applications that have
> mappings will be broken, I do not see an existing solution for this
> problem yet, maybe we can suggest that the CGN should send a
> notification to the client if mappings are deleted.

That's already in the document.  Please see the ANNOUNCE Opcode, 
discussed in 
http://tools.ietf.org/html/draft-ietf-pcp-base-22#section-13

> In this case, if the client sends a request specifying the external

It will only fail (return a PCP error response code) if the client
includes the PREFER_FAILURE Option.  But there isn't a good reason 
for the PCP client to include the PREFER_FAILURE Option for this 
case.  That is, normal PCP clients have no reason to use the
PREFER_FAILURE Option.

> In the 2 case, there is no problem with client; the client can request

In the case where the client has deleted mappings but the CGN
still has the mappings, that could only occur if the PCP client
has sent delete requests (a MAP request with Lifetime=0) and
not received responses.  The PCP client is supposed to continue
re-transmitting those requests (with a backoff) until it receives
a response.  Eventually, if the PCP server still never receives
those Lifetime=0 requests (e.g., due to path failure), the PCP
server will time out the mappings when the lifetime expires.

I believe both of the cases are covered by the existing document.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 19 Jan 2012 14:17:24 -0500

That is specifically allowed. Mapping updates (section 13) help when you
want to inform that 'I could repair your mappings, here are the new ones'.
If you want to inform error conditions that is also allowed.

" A PCP client SHOULD be
   prepared to receive multiple responses from the PCP Server at any
   time after a single request is sent.  This allows the PCP server to
   inform the client of mapping changes such as an update or deletion.
   For example, a PCP Server might send a SUCCESS response and, after a
   configuration change on the PCP Server, later send a NOT_AUTHORIZED
   response.
"

On 1/19/12 9:57 AM, "Tina TSOU" <[email-masked]> wrote:

> mappings will be broken, I do not see an existing solution for this problem
> yet, maybe we can suggest that the CGN should send a notification to the
> client if mappings are deleted.

---

From: Tina TSOU <[email-masked]>
Date: Sat, 21 Jan 2012 00:04:22 +0000

Reinaldo,
The main purpose of my proposed text is to make sure an application which requires multiple connections can always have the same external IP address, so I think both the client and the server should guarantee this.

Tina

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Thursday, January 19, 2012 11:17 AM
> To: Tina TSOU; Dan Wing; [email-masked]
> Subject: Re: [pcp] About PCP Client
> 
> > 1. Client has the mappings but CGN already delete them all for some kind
> of
> > reason.
> problem