Subject: [pcp] -06 review: delete

From: Paul Selkirk <[email-masked]>
Date: Mon, 07 Mar 2011 22:15:27 +0000

Organizationally, I would like to see the deletion portions of 8.4 and
8.6 consolidated into one section.

I would also like to see the deletion signalling spelled out more fully.
>From a close reading of the text, I think this is how it works:
    delete single mapping:
        lifetime = 0 (8.6)
    delete all mappings for a protocol:
        internal port = lifetime = 0 (unstated, could be implied in 8.6)
    delete all mappings for a host:
        protocol = internal port = lifetime = 0 (8.1, 8.6)
    delete all mappings for a subscriber:
        internal addr = lifetime = 0 (10, requires THIRD_PARTY option)

8.4.  OpCode-Specific Server: Processing a Request
(tearing apart the deletion paragraph sentence by sentence)

   PCP MAP requests only control
   mappings created by MAP requests.

This sounds dangerously close to tautology.
(http://www.xkcd.com/703/)

It might be better phrased as something like "PCP MAP can't delete
mappings created by non-PCP means."

   On a deletion request, the requested external
   port field is ignored by the server.  So, if the PCP client attempts to
   delete a static mapping (i.e., a mapping created outside of PCP
   itself), the PCP server deletes all of the PCP-created mappings but
   MUST respond with UNABLE_TO_DELETE_ALL result code, with the other
   fields encoded as described above.

This reads weirdly (apparent subject/object quantity disagreement in
the second sentence).  Plus, if the PCP client tries to delete ALL
mappings, the server should delete the PCP-created mappings and return
success; OTOH if the PCP client tries to delete a single mapping
created by other means, the server should fail with some other code
than UNABLE_TO_DELETE_ALL, like NOT_AUTHORIZED.  In fact, I'm
not sure there's a real use case for UNABLE_TO_DELETE_ALL.

On reflection, I think the intended meaning is that a protocol/
internal addr/internal port 3-tuple can match multiple mappings if the
NAT is not EIM, the server should delete the matching PCP mappings (at
most one?), and return an indication that there is still a mapping
that matches.  I'm still not convinced that UNABLE_TO_DELETE_ALL is a
useful result code, since a) it doesn't confirm that the server deleted
all the matching mappings that it controlled, and b) it informs the
client that there's a matching mapping that it has not control over.

   If the PCP client attempts to
   delete a mapping that does not exist, the success response code is
   returned.

Okay, this is the idempotent principle of section 6 intro, but it's
worth mentioning explicitly for the principle of least surprise.

   If the PCP client is not authorized to delete this
   mapping, NOT_AUTHORIZED is returned.

Okay, this would be mappings created by other means (static, implicit
dynamic).

   If the deletion request was
   properly formatted, a positive response is generated with lifetime of
   0 and the server copies the protocol and internal port number from
   the request into the response; this positive response is generated
   even if there is no mapping (because the mapping could have been
   already deleted by a previous PCP transaction).

This seems to be a restatement of "If the PCP client attempts to
delete a mapping that does not exist, the success response code is
returned."

8.6.  Mapping Lifetime and Deletion
   When a PCP client first acquires a new IP address, it may want to
   remove mappings that may have been instantiated for a previous host.
   To do this, the PCP client sends a MAP request with protocol,
   external port, internal port, and lifetime set to 0.

8.4 says "On a deletion request, the requested external port field is
ignored by the server."  So either "external port" can be dropped from
this list, or the 8.4 restriction should be dropped.

On the whole, I think I'd rather remove the 8.4 restriction, so that a
client could delete a single targeted mapping, without having to worry
about other mappings that it has no control over.

10.  THIRD_PARTY Option for MAP and PEER OpCodes
   If authorized to do so, a PCP client can delete all the PCP-created
   dynamic explicit mappings (i.e., those created by PCP) for all hosts
   belonging to the same subscriber.

s/dynamic explicit/explicit dynamic/

				paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Mar 2011 18:22:51 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Selkirk
> Sent: Monday, March 07, 2011 2:15 PM
> To: [email-masked]
> Subject: [pcp] -06 review: delete
> 

Moved 8.4's discussion to 8.6 ("Mapping Lifetime and Duration").

>         internal addr = lifetime = 0 (10, requires THIRD_PARTY option)

Clarified with the following, which also integrates a suggestion you have
below for requested-external-port being non-zero:

	"If the requested lifetime is 0 and internal port is non-zero and
protocol is non-zero, it indicates a request to delete the indicated mapping
immediately. If  the requested lifetime, internal port, and requested
external port are all 0, it indicates a request to delete all ports for the
indicated protocol. If the requested lifetime, protocol, and requested
external port are all 0, it indicates a request to delete all ports for all
protocols. If the external port is non-zero, it indicates only a mapping
with that external port should be deleted; if the external port is 0, it
means the client doesn't care about the external port.

and with:

  "The following table summarizes the sentinel values when deleting a
   mapping using lifetime=0:

   all ports, all protocols, all hosts belonging to a subscriber:
      internal address=0, via the THIRD_PARTY option

   all ports, all protocols:  internal port=0, protocol=0

   all ports, specific protocol:  internal port=0, protocol={protocol
      value} (e.g., protocol=6 for TCP)

   one port, specific protocol:  internal port={port number},
      protocol={protocol value} (e.g., port=12345, protocol=6 for TCP)"

> mappings created by non-PCP means."

fixed.  Thanks.

> client that there's a matching mapping that it has not control over.

I created ticket #43 to track this idea,
http://trac.tools.ietf.org/wg/pcp/trac/ticket/43

But I'm not sure what you are proposing as a resolution.  That is,
should the PCP server just be silent about mappings it cannot
delete and return SUCCESS if all of the mappings created with
MAP were deleted, and also SUCCESS if they weren't (which is
necessary to retain idempotentcy)?  The MAP request also cannot 
delete implicit dynamic mappings (those created with a TCP 
SYN), as they were not created with MAP, either.

> worth mentioning explicitly for the principle of least surprise.

added.

> Okay, this would be mappings created by other means (static, implicit

Or UNABLE_TO_DELETE_ALL, because that's the order of processing.  Let's
figure out if we keep/discard UNABLE_TO_DELETE_ALL.

In the meantime, I added a For Example for that.

> delete a mapping that does not exist, the success response code is

Removed the text after the ";".

> this list, or the 8.4 restriction should be dropped.

done.

> about other mappings that it has no control over.

Ok, I changed processing rules so requested-external-port can be
meaningful and, if non-zero, has to match the mapping.

> s/dynamic explicit/explicit dynamic/

Thanks.

-d