Subject: [pcp] Review of pcp-base-3

From: Reinaldo Penno <[email-masked]>
Date: Mon, 7 Feb 2011 15:33:05 -0500

Hi,

Some comments and questions on base-03.

A)

"2.3.  Single-homed Customer Premise Network"

What about the scenario (which we discussed) where there is a single route
to the Internet but other interfaces/routes to VoD/IPTV, VoIP, etc?

Is this in or out of scope? AFAIK this is quite common in broadband networks
with setup boxes, integrated CPEs and others.

B)

"5.1.  Request Header"

The 'reserve' field seems to serve more as padding to get 16-bit aligned.

I wonder if we can move 'reserve' to end of the 16-bit boundary and
therefore have a 52-bit contiguous field which can be sliced and diced in
different ways in the future.

C)

"   OpCode:  8 reserved bits, MUST be sent as 0, MUST be ignored when
      received."

s/OpCode/Reserved

D)

" If several Options are
   included in a PCP request or response, they can be encoded in any
   order by the PCP client. "

Are we positive we do not want to recommend some ordering to facilitate
parsing and sanity checking much like IPv6 extension headers, SDP, etc?

E)

I think some clarification is needed below. Since I'm not sure the original
intention, I will just ask some questions inline.

"   If the "P" bit in the OpCode is set,

   o  the PCP server MUST only generate a positive PCP response if it
      can successfully process the PCP request and this Option."

[Reinaldo] What if there are other options in the request? For example, if
PCP server processes options 1 and 2 but finds out it can not process 3, it
needs to rollback 1 and 2 in order to send back a negative response.

Alternatively, PCP server needs to scan request for options with 'P' bit
set, try to satisfy those. Still, if there is more than one, and, say, the
second one fails, it needs to rollback the first one and send a negative
response?

"   o  if the PCP server does not implement this Option, it MUST generate
      a failure response without including this Option in the response.

[Reinaldo] Same comments as above

   o  If the PCP server does implement this Option, but cannot perform
      the function indicated by this Option, it MUST generate a failure
      response and include this Option (and its arguments) in the
      response."

[Reinaldo] Same comments above. I'm confused by all possible scenarios. If
options are interdependent, then it would be extra confusing.

F)

"   A host operating a server (e.g., a web server) listens for traffic on
   a port (but never sends traffic from that port."

Typo, need to remove parenthesis '(but'.

Also, maybe rephrase to '.. But never initiates outbound connections from
that port'

G)

"   PIN66=3:  create a forwarding pinhole between an internal IPv6
             address and public IPv6 address (e.g., NPTv6 or firewall)"

NPTv6? Is it something new or it is supposed to be NAT66?

H)

"   A PCP client can request the explicit deletion of all UDP or TCP
   mappings by sending a PCP request with a PIN OpCode with external
   port, internal port, and lifetime set to 0. "

Does this mean that is the client is dual-stack, it should send up to 4
messages to make sure there are no stale mappings? OpCode PIN44-TCP,
PIN66-TCP, PIN44-UDP, PIN66-UDP.

If it supports SCCT and DCCP, then 8 messages?

I)

"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]."

What about static port forwarding mappings? Do such static mappings also
mandate that PCP use the external port forwarding IP configured? The client
has no way of knowing until it requests the first mapping, after that it
could use the same external IP.

Furthermore, should dynamic mappings use the external IP configured in a
port forwarding mapping as well? Since dynamic mappings influence how PCP
selects external IP addresses, and static port forwarding influences dynamic
mappings, then port forwarding also influence PCP?

J)

"8.4.3.  Pinhole Deletion

   A pinhole MUST be deleted by the PCP Server upon the expiry of its
   lifetime, or upon request from the PCP client.

   In order to prevent another subscriber from receiving unwanted
   traffic, the PCP server SHOULD NOT assign that same external port to
   another host for 120 seconds (MSL, [RFC0793])."

In the case of connect-then-lifetime how this could not be enforced?

K)

"8.5.1.  REMOTE_PEER_FILTER"

Can a network prefix be specified? Specifying each IP address individually
seems a non-starter

L)

"   To delete all pinholes for all hosts associated with this subscriber,
   an all-zero internal IP address is used."

If a server can not delete all pinholes, what should it send on the
response? Should such deletions be atomic - all or nothing?

M)

"   PEER6=5:  Set or query lifetime for flow from IPv6 address to a
           remote peer's IPv6 address."

PEER6=6?

N)

 "  2.  Hosts behind the B4 element with either include a PCP client or
       UPnP IGD client."

s/with/will

O)

"10.1.2.  Encapsulation Mode

10.1.3.  Plain IPv6 Mode"

These modes are not mutually exclusive. A home can have IPv6 and IPv4
clients. PCP requests from IPv4 clients can go through the DS-Lite and plain
IPv6 requests (whether for NAT66 or NAT64) can go natively.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Feb 2011 14:52:50 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno
> Sent: Monday, February 07, 2011 12:33 PM
> To: [email-masked]
> Subject: [pcp] Review of pcp-base-3
> 
> Hi,
> 
> Is this in or out of scope? AFAIK this is quite common in broadband
> networks with setup boxes, integrated CPEs and others.

I don't see how to make this work.  Do you have ideas?

> therefore have a 52-bit contiguous field which can be sliced and diced
> in different ways in the future.

So, you are suggesting change from:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|Ver=0|reserve|R|   OpCode    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      Reserved (48 bits)       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

to

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|Ver=0|R|   OpCode    |                                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+              Reserved (52 bits)       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

that seems reasonable to me.  I'll make that change in -04.

> parsing and sanity checking much like IPv6 extension headers, SDP, etc?

If we define such a rule (e.g., lowest valued to highest valued), then
we need to explain what happens when they are in a different order 
(return an error, or Be Liberal In What You Receive?).

If it's valuable, please propose a straw man.

> needs to rollback 1 and 2 in order to send back a negative response.

The intent which I am hoping to convey is that all of the 
mandatory-to-process options have to be processed successfully
to get a SUCCESS.  Failure to process any mandatory-to-process
option causes a failure response.

Clarified to now read:

    If the "P" bit in an OpCode is set, <list style="symbols">
    * the PCP server MUST only generate a positive PCP response 
      if it can successfully process the PCP request, and this 
      Option, and other Options with the "P" bit set.

> second one fails, it needs to rollback the first one and send a
> negative response?

I don't know what you mean by 'rollback to the first one'.

> [Reinaldo] Same comments above. I'm confused by all possible scenarios.
> If options are interdependent, then it would be extra confusing.

I would encourage the community to not define such options.  

> Also, maybe rephrase to '.. But never initiates outbound connections

That section is now cleaner in -04.

> NPTv6? Is it something new or it is supposed to be NAT66?

It's been renamed to "Network Prefix Translation IPv6", see the 
title abbreviation at the top of each page of
http://tools.ietf.org/html/draft-mrw-nat66-07.

However, I removed references to NAT66 / NPTv6 from -04.

> PIN66-TCP, PIN44-UDP, PIN66-UDP.

In -04, I have collapsed the PIN44, PIN64, PIN46, and PIN66 messages
to simply PIN4 and PIN6.

With that change, if the PCP client has an interface, and wants to 
delete mappings to that interface, it needs to send one message
for each protocol (TCP, UDP, etc.).

It doesn't matter if the client is dual-stack or not.  Consider, for 
example, a client with both a wired IPv4 Ethernet interface and 
an IPv4 WiFi interface.  That client would need to send two messages
on both interfaces.

> If it supports SCCT and DCCP, then 8 messages?

8 with the PINxy messages.  But in -04, that would now be 4 messages.

I believe, from your question, you are implying this is too many
messages to send, and you want this optimized?

This is related to Francis's recent emails to PCP, I believe, where
PCP is currently insufficient in allowing "any" protocol to be
mapped to an internal host.  If we add that, we can easily add
the ability to delete "any" mapping.

> What about static port forwarding mappings?

That is covered by the "any other means" phrase in the quoted paragraph.

> Do such static mappings
> also

They all need to be the same.

If this is a problem for an implementation (and I can certainly see
how it can be a problem), we need to understand if this might
break an application.  It seems safest to require them all use
the same public IP address, of course.

> In the case of connect-then-lifetime how this could not be enforced?

Connect-then-lifetime uses the PEER OpCodes and does not create a 
pinhole (pinholes are created with the PIN OpCodes).  The intent of
the PEER opcodes is that they don't change the NAT's existing behavior
(whatever that behavior might be).

> Can a network prefix be specified? Specifying each IP address
> individually seems a non-starter

Added to -04.  Thanks.

> response? Should such deletions be atomic - all or nothing?

Section 8.4 says:

   If
   the PCP server is unable to delete a port mapping, for example,
   because the mapping was manually configured by a configuration tool,
   the PCP server MUST still delete as many port mappings as possible,
   and respond with the result code UNABLE_TO_DELETE_ALL.

> IPv6 requests (whether for NAT66 or NAT64) can go natively.

So, you're saying Issue #13 http://trac.tools.ietf.org/wg/pcp/trac/ticket/13

is wrong -- that is, we don't need to decide Issue #13.  Rather, for
DS-Lite, both encapsulation modes have to always be supported?

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Feb 2011 00:11:30 +0100

In your previous mail you wrote:

   L)

   
=> this shows again that we need a GET/GETNEXT operation to recover
partial multiple deletes. Note we have the same issue with UPnP IGD 2.0
DeletePortMappingRange()...

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Feb 2011 00:44:06 +0100

to

   
=> It doesn't seen a good idea to me: please keep the OpCode on a 8 bit
boundary!

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Feb 2011 00:51:00 +0100

=> Why not support protocol=0 to delete all mappings?

   
=> you mean 256 messages in fact...

=> note it was about any protocol with any port, i.e., any IP packet.
But of course I am strongly in favor of this for deletion, per protocol
delete all is silly (the only reason to still provide it is for IWF).
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Feb 2011 00:59:10 +0100

=> no, Reinaldo put the Encapsulation vs Plain Mode outside
the DS-Lite context and concluded they are not exclusive.
IMHO he was wrong because DS-Lite uses PIN44 only but with the base-04
changes I haven't yet read perhaps a door is open now...
BTW Encapsulation Mode is still different from anything else because
messages are encapsulated so are different from PIN44 over IPv6 UDP.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Feb 2011 16:27:34 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 07, 2011 3:44 PM
> To: Dan Wing
> Cc: 'Reinaldo Penno'; [email-masked]
> Subject: Re: [pcp] Review of pcp-base-3
...
> => It doesn't seen a good idea to me: please keep the OpCode on a 8 bit

Good point.  I'll back out that change for -05.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 7 Feb 2011 21:48:57 -0500

The Opcode today is 7bits and not 8-bit aligned in the response. If that is
a concern, let me suggest growing the Opcode 4 more bits and get rid of the
first reserve field.  This will make the Opcode response header 16-bit
aligned and make the header easier with just one reserved field.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Feb 2011 13:39:46 +0100

=> agreed

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Feb 2011 09:07:51 -0800

>    aligned and make the header easier with just one reserved field.

I don't see a future that would exceed today's 2^7 OpCodes.  Today
there are only 6 OpCodes that anyone has defined (PIN4, PIN6, PEER4,
PEER6, GET, GETNEXT).  It seems risky to consume bits with OpCode 
space when we may need to use the reserved bits in the response
header.

How about the following, which provides 8-bit alignment of OpCode
and Result Code, and keeps all the reserved space together:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1|Ver=0|       Reserved        |  Result Code  |R|   OpCode    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Feb 2011 13:14:38 +0100

I don't see a future that would exceed today's 2^7 OpCodes.

=> if you believe this why not go to one octet including the first bit
for the version and one octet including the response bit for the OpCode?

     0                   1                   2                   3
   
=> I don't understand the gratuitous shuffle of fields...

[email-masked] (very disappointed by base-04)

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Feb 2011 15:44:51 -0800

> Sent: Wednesday, February 09, 2011 4:15 AM
> To: Dan Wing
> Subject: Re: PCP packet layout [was RE: [pcp] Review of pcp-base-3]
> 
> 

Reinaldo suggested having two sections of 'reserved' bits could
be reduced to have one section of 'reserved' bits.  

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 09:58:51 +0100

=> this doesn't explain the swap between Result Code and OpCode.
   
Regards

PS: to lower the level of changes and to get one reserved field,
I propose:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1| Version = 0 |R|   OpCode    |   Reserved    |  Result Code  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Feb 2011 15:52:28 -0800

> Sent: Thursday, February 10, 2011 12:59 AM
> To: Dan Wing

There are only a few weeks to get this specification done, and
proposals like this are helpful to keep the specification moving
forward quickly.  

Thanks.  I'll put this into -05.

-d