Subject: [pcp] -06 review: nits

From: Paul Selkirk <[email-masked]>
Date: Tue, 08 Mar 2011 05:31:00 +0000

This contains a large number of spelling, wording, and other editorial
changes, with a few substantive changes thrown in for good measure.

1.  Introduction
   PCP can be used in various deployment scenarios, including:
   ...

I would remove all the uses of "and;", and treat this as bullet list,
rather than as a strangely-formatted run-on sentence.

I would also reorder the list to start with the simpler scenarios,
e.g. Basic NAT, NAPT, CGN, DS-Lite, L2NAT, firewall.

2.2.  Supported Transport Protocols
   Transport protocols that do not use a port number
   (e.g., IPsec ESP), and the ability to use PCP to forward all traffic
   to a single default host (often nicknamed "DMZ"), are beyond the
   scope of this document.

I would split this into two sentences, to make it clearer, e.g.
   Transport protocols that do not use a port number (e.g., IPsec ESP)
   are out of scope for this document.  By extension, the ability to
   use PCP to forward all traffic to a single default host (often
   nicknamed "DMZ") is also beyond the scope of this document.

3.  Terminology
      served by a NAT gateway, the Remote Address my in fact be the

s/my/may/

3.  Terminology
   Port Forwarding, Port Mapping:

This section is rambling, and redundant to other sections (e.g. spends
several sentences describing port translation, which is already
covered under Mapping.)  It also fails to concisely nail the essential
point: a port mapping is created to allow incoming connections.

We need a Terminology entry for Proxy as well as IWF.

5.2.  Response Header
Figure 3 should have the same same format as Figure 2 (request),
i.e. 3 lines for options.

5.3.  Options
   It is anticipated that Options will include
   information which are associated with the normal function of an
   OpCode.

s/are/is/

6.1.  General PCP Client: Generating a Request
   2.  if DHCP indicates the PCP server(s), the address(es) of the
       indicated PCP server(s) are used as the the list of PCP
       server(s), else;

This should make a normative reference to the DHCP PCP option draft.

6.4.  Multi-Interface Issues
   IPv6 addresses with global reachability scope SHOULD be used as the
   source interface when generating a PCP request.  IPv6 addresses with
   limited scope (e.g., ULA [RFC4193]), SHOULD NOT be used as the source
   interface when generating a PCP request.

s/interface/address/g

6.4.  Multi-Interface Issues
   Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope
   (e.g., [RFC1918]) MAY be used as the source interface when generating
   a PCP request.

See previous comment, also it's an expectation/requirement for DS-Lite.

6.5.  Epoch
   or loses the state of its explicit dynamic Mappings

s/M/m/

7.1.  For Operating a Server
   As normal, the application needs to begin listening to a port, and to
   ensure that it can get exclusive use of that port it needs to choose
   a port that is not in the operating system's ephemeral port range.

This is entirely up to the app and the OS, and is entirely out of
scope for this document.

8.  MAP OpCodes
   This section defines four OpCodes which control forwarding from a NAT
   (or firewall) to an internal target host.

s/four/two/

8.1.  OpCode Packet Formats
   Protocol:  indicates protocol associated with this OpCode.  Values
      are taken from the IANA protocol registry [proto_numbers].  For
      example, this field contains 6 (TCP) if the opcode is intended to
      create a TCP mapping.  The value 0 means "all protocols"
      (supported by the PCP server), which is useful to create mappings
      for all protocols with a Basic NAT [RFC3022] or a firewall, and
      used to delete mappings for all protocols.

I read section 2.2 as meaning PCP doesn't support "all protocols".

8.1.  OpCode Packet Formats
   Internal port:  Internal port for the mapping.  The value 0 MUST NOT
      be sent.

Except to delete all mappings for a host.

8.1.  OpCode Packet Formats
      If the NAT gateway cannot allocate the
      requested external port but can allocate some other port, it MUST
      do so and return the allocated port in the response.

Except in the presence of the PREFER_FAILURE option.

8.2.  OpCode-Specific Result Codes
   following additional result codes may be returned as a result of the
   four MAP OpCodes received by the PCP server.

s/four/two/

8.3.  OpCode-Specific Client: Generating a Request
   An existing mapping can have its lifetime extended by the PCP client.
   To do this, the PCP client sends a new MAP request indicating the
   internal IP address and port(s).

This is passive voice, grammatically dubious, and incomplete to boot.
Replace with something like this:

   To renew an existing mapping, the PCP client sends a MAP request
   with the current information (protocol, external address, external
   port, internal port, internal address in the case of a third-party
   mapping) and the desired lifetime extension.

8.4.  OpCode-Specific Server: Processing a Request
   If the request contains internal-port=0, the server MUST generate a
   MALFORMED_REQUEST error.

Except to delete all mappings for a host.

8.4.  OpCode-Specific Server: Processing a Request
   If the requested lifetime is not zero, it indicates a request to
   create a mapping or extend the lifetime of an existing mapping.

   Processing of the lifetime is described in Section 8.6.

Remove the blank line.

8.4.  OpCode-Specific Server: Processing a Request
   If an Option with value greater than 128 exists but that option does
   not make sense (e.g., the PREFER_FAILURE option is included in a
   request with lifetime=0), the request is invalid and generates a
   MALFORMED_OPTION error.

s/greater/less/

8.5.  OpCode-Specific Client: Processing a Response
   If a successful response, the PCP client can use the external IP

This clause no verb.  "If the response indicates success..."

8.5.  OpCode-Specific Client: Processing a Response
   When this is received, if the
   PCP client still wants to establish a mapping, the PCP client MUST
   choose a different internal port...

"this" = this result code

8.5.  OpCode-Specific Client: Processing a Response
   On an error response, clients SHOULD NOT repeat the same request to
   the same PCP server within the lifetime returned in the response.

Or 30 seconds/30 minutes, depending on the type of error.

8.6.  Mapping Lifetime and Deletion
   Some port mapping APIs (such as the
   "DNSServiceNATPortMappingCreate" API provided by Apple's Bonjour on
   Mac OS X, iOS, Windows, Linux, etc.) 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.

Interesting but irrelevant.

8.6.  Mapping Lifetime and Deletion
   In order to reduce unwanted traffic and data corruption, a port that
   was mapped using the MAP OpCode SHOULD NOT be assigned to another
   internal target, or another subscriber, for 120 seconds (MSL,
   [RFC0793]).  However, the PCP server MUST allow the same internal
   target to re-acquire the same port during that same interval.

These two requirements are incompatible.  The MUST turns the SHOULD
NOT into MUST NOT, or the SHOULD NOT turns the MUST into SHOULD.

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

s/because/for/

8.8.1.  REMOTE_PEER_FILTER
This is not something that either UPnP-IGD or NAT-PMP offer, as far as
I know.  This is needed if we're going to support client control of
firewalls, and may be useful in NAT situations as well.  OTOH, we
could rule it (and firewalls) out of scope, with no loss of relevance.
It's mandatory to process, but not mandatory to implement.

8.8.1.  REMOTE_PEER_FILTER
     :              1 28 bits if MAP6)                               :

remove a space:
s/1 28/ 128/

8.9.1.  Recreating Mappings
   As the result of receiving a packet where the Epoch field indicates
   that a reboot or similar loss of state has occurred, the client
   renews its port mappings.

s/packet/response/
because the server only sends responses

8.9.1.  Recreating Mappings
   Losing port mappings for outgoing connections
[implicit dynamic mappings]
   destroys those currently active connections, but does not prevent
   clients from establishing new outgoing connections.  In contrast,
   losing inbound port mappings
[explicit dynamic mappings]
   not only destroys all existing inbound
   connections, but also prevents the reception of any new inbound
   connections until the port mapping is recreated.

8.9.1.  Recreating Mappings
   However, clients that want outgoing connections to survive
   a NAT gateway reboot can also achieve that using PCP.  After
   initiating an outbound TCP connection (which will cause the NAT
   gateway to establish an implicit port mapping) the client should send
   the NAT gateway a port mapping request for the source port of its TCP
   connection, which will cause the NAT gateway to send a response
   giving the external port it allocated for that mapping.  The client
   can then store this information, and use it later to recreate the
   mapping if it determines that the NAT gateway has lost its mapping
   state.

Only if the NAT is EIM?  This is in the chapter on MAP opcodes, so
it's not talking about PEER (which is actually designed to deal with
implicit dynamic mappings).  While the protocol can be used this way,
I'm not sure I feel comfortable recommending (or even mentioning) this
approach.  In the world we live in today, if a NAT reboots, I lose all
my outbound connections, and I just have to restart them.  In the
words of Kurt Vonnegut, "So it goes."

8.9.2.  Maintaining Mappings
   If the PCP client has
   several mappings, the Epoch value only needs to be retrieved for one
   of them to verify the PCP server has not lost port forwarding state.

What is a client?  To the server, it's a single requestor
(source IP address of requests), since we don't have a client/app ID
(much as Francis would like one).  So a host is a single client to the
server, even if it has several "PCP software instances".  Likewise, a
proxy is a single client to the server, even if it has multiple hosts
and many PCP apps behind it.

8.9.2.  Maintaining Mappings
   If the client wishes to check the PCP server's Epoch, it sends a PCP
   request for any one of the client's mappings.  This will return the
   current Epoch value.  In that request the PCP client could extend the
   mapping lifetime (by asking for more time) or maintain the current
   lifetime (by asking for the same number of seconds that it knows are
   remaining of the lifetime).

The last sentence is true, but almost entirely irrelevant.

Nit: capitalize fields in packet format diagrams (Figures 9, 10, 11,
12, 13), e.g. "Internal Port".

9.1.  OpCode Packet Formats
   internal port:  Internal port for the of the 5-tuple.
   Remote Peer Port:  Remote peer's port of the 5-tuple.

s/5-tuple/mapping/

9.3.  OpCode-Specific Client: Generating a Request
   The PEER4 or PEER6 OpCodes MUST NOT be sent until establishing bi-
   directional communication with the remote peer.

s/until establishing/until the client has established/

11.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.

add "to":
s/address/address to/

13.1.  Denial of Service
   Thus, Section 11.3recommends

add a space:
s/11.3recommends/11.3 recommends/

13.2.  Ingress Filtering
   It is important to prevent a subscriber from creating a mapping for
   another subscriber, because this allows incoming packets from the
   Internet and consumes the other user's mapping quota.

Likewise, it is important to prevent a subscriber from deleting
mappings belonging to another subscriber.

14.2.  OpCodes
   IANA shall create a new protocol registry for PCP OpCodes, initially
   populated with the values in Section 8 and Section 9.
   New OpCodes in the range 1-95 can be created via Standards Action
   [RFC5226], and the range 96-128 is for Private Use [RFC5226].

s/1-95/4-95/ since 0-3 are already assigned to MAP[46]/PEER[46].

14.4.  Options
   New PCP option codes in the range 0-63 and 128-192 can be created via
   Standards Action [RFC5226], and the range 64-127 and 192-255 is for
   Private Use [RFC5226].

1-4 are already assigned

				paul