Subject: [pcp] I-D Action: draft-ietf-pcp-base-16.txt

From: [email-masked]
Date: Fri, 21 Oct 2011 12:26:47 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF.

	Title           : Port Control Protocol (PCP)
	Author(s)       : Dan Wing
                          Stuart Cheshire
                          Mohamed Boucadair
                          Reinaldo Penno
                          Paul Selkirk
	Filename        : draft-ietf-pcp-base-16.txt
	Pages           : 81
	Date            : 2011-10-21

   The Port Control Protocol allows an IPv6 or IPv4 host to control how
   incoming IPv6 or IPv4 packets are translated and forwarded by a
   network address translator (NAT) or simple firewall, and also allows
   a host to optimize its outgoing NAT keepalive messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-16.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-base-16.txt

---

From: Alain Durand <[email-masked]>
Date: Fri, 21 Oct 2011 12:34:05 -0700

The PCP wg chairs would like to issue a one week wg last call on draft-ietf-pcp-base-16.

Last call ends Friday October 28th at 5pm EST.

Alain & Dave

Sent from my iPhone

Begin forwarded message:

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: October 21, 2011 3:26:47 PM EDT
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [pcp] I-D Action: draft-ietf-pcp-base-16.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-base-16.txt
_______________________________________________
pcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pcp

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Oct 2011 01:39:57 -0700

> The PCP wg chairs would like to issue a one week wg last call on  

I have made some minor edits for readability, spelling, consistency,  
ambiguity, etc. For transparency, these are attached below.

I also have some more substantive comments, which I will try to send  
to the list tomorrow.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

Index: draft-ietf-pcp-base.xml
===================================================================
--- draft-ietf-pcp-base.xml	(revision 192)
+++ draft-ietf-pcp-base.xml	(working copy)
@@ -175,7 +175,7 @@
              <t>IPv4 and <xref target="RFC6092">IPv6 simple firewall
              control</xref></t>

-            <t><xref target="RFC6296">NPTv6</xref></t>
+            <t><xref target="RFC6296">IPv6-to-IPv6 Network Prefix  
Translation (NPTv6)</xref></t>

            </list></t>
        </section>
@@ -192,7 +192,8 @@
        <section anchor="single_homed" title="Single-homed Customer  
Premises Network">
          <t>PCP assumes a single-homed IP address model. That is,  
for a given
          IP address of a host, only one default route exists to  
reach the
-        Internet. This is important because after a PCP mapping is  
created and
+        Internet from that source IP address.
+        This is important because after a PCP mapping is created and
          an inbound packet (e.g., TCP SYN) arrives at the host, the  
outbound
          response (e.g., TCP SYNACK) has to go through the same path  
so it is
          seen by the firewall or rewritten by the NAT. This  
restriction exists
@@ -245,11 +246,8 @@
            request for that Internal Address and Port may be assigned
            yet another different External Port.  This term encompasses
            both Address-Dependent Mapping and Address and
-          Port-Dependent Mapping
-          from <xref target="RFC4787"></xref>.</t>
+          Port-Dependent Mapping <xref target="RFC4787"></xref>.</t>

-
-
            <t hangText="Remote Peer Address:"><vspace  
blankLines="0" />The
            address of a Remote Peer, as seen by the Internal Host. A  
Remote
            Address is generally a publicly routable address. In the  
case of a
@@ -277,8 +275,8 @@
            the internal IP and port, and vice versa. In the case of  
a pure
            firewall, the "Mapping" is the identity function,  
translating an
            internal IP address and port number to the same external  
IP address
-          and port number. Firewall filtering, applied to that identity
-          function, is separate from the mapping itself.</t>
+          and port number. Firewall filtering, applied in addition  
to that identity
+          mapping function, is separate from the mapping itself.</t>

            <t hangText="Mapping Types:"><vspace blankLines="0" />There
            are three different ways to create mappings: implicit
@@ -332,7 +330,7 @@

            <t hangText="Interworking Function:"><vspace  
blankLines="0" />A
            functional element responsible for translating or  
proxying another
-          protocol to PCP. For example interworking between
+          protocol to PCP. For example interworking
            <xref target="IGD">UPnP IGD</xref> with PCP.</t>

            <t hangText="Subscriber:"><vspace blankLines="0" /> The  
unit of
@@ -390,8 +388,8 @@
  deny unsolicited traffic from the Internet.  Some firewall devices  
deny
  certain unsolicited traffic from the Internet (e.g., TCP, UDP to
  most ports) but allow certain other unsolicited traffic from the
-Internet (e.g., UDP port 500 and IPsec ESP as described in
-<xref target="RFC6092"></xref>).  Such default filtering (or lack
+Internet (e.g., UDP port 500 and IPsec ESP)
+<xref target="RFC6092"></xref>.  Such default filtering (or lack
  thereof) is out of scope of PCP itself.  If a device supports PCP and
  wants to receive traffic, and does not possess knowledge of such
  filtering, it SHOULD use PCP to create the necessary mappings to  
receive
@@ -418,7 +416,7 @@

        <t>When checking for an IPv4-mapped IPv6 address, all of the
        first 96 bits MUST be checked for the pattern -- it is not
-      sufficient to check for 0xFF in bits 81-96.</t>
+      sufficient to check for ones in bits 81-96.</t>

        <t>The all-zeroes IPv6 address is expressed by filling the
        fixed-size 128-bit IP address field with all zeroes (::).</t>
@@ -530,12 +528,12 @@
          </figure>

          <t>These fields are described below:<list style="hanging">
-            <t hangText="Version:">Responses MUST use version 1.</t>
+            <t hangText="Version:">Responses MUST use version 1.  
This is set by the server.</t>

              <t hangText="R:">Indicates Request (0) or Response (1).  
All
-            Responses MUST use 1.</t>
+            Responses MUST use 1. This is set by the server.</t>

-            <t hangText="Opcode:">The 7-bit Opcode value, copied  
from the
+            <t hangText="Opcode:">The 7-bit Opcode value. The server  
copies this value from the
              request.</t>

              <t hangText="Reserved:">8 reserved bits, MUST be sent  
as 0, MUST
@@ -554,13 +552,17 @@
              mapping. If future Opcodes are defined that do not have  
a lifetime
              associated with them, then in success responses for  
those Opcodes
              the Lifetime MUST be set to zero on transmission and  
MUST be
-            ignored on reception.</t>
+            ignored on reception. This is set by the server.</t>

              <t hangText="Epoch:">The server's Epoch value. See
              <xref target="epoch"></xref> for discussion. This value  
is set by the server, in both success and error responses.</t>

              <t hangText="Reserved:">96 reserved bits, MUST be sent  
as 0, MUST
-            be ignored when received. This is set by the server.</t>
+            be ignored when received. This is set by the server.
+            This padding exists so that for unrecognized requests,  
the server
+            can blindly copy an entire request message into a response
+            message and have that response make some kind of  
reasonable sense
+            to the recipient.</t>

            </list></t>
        </section>
@@ -621,18 +623,17 @@
              <t hangText="Option Length:">16 bits. Indicates the  
length of the
              enclosed data, in octets. Options with length of 0 are  
allowed.
              Options that are not a multiple of four octets long are  
followed
-            by one, two, or three octets of zeros to pad their  
effective length
+            by one, two, or three zero octets to pad their effective  
length
              in the packet to be a multiple of four octets. The  
Option Length
-            reflects the semantic length of the option, not  
including the
+            reflects the semantic length of the option, not  
including any
              padding octets.</t>

-            <t hangText="data:">Option data. The Option data MUST  
end on a
-            32-bit boundary, padded with 0's when necessary.</t>
+            <t hangText="data:">Option data.</t>
            </list></t>

          <t>The handling of an Option by the PCP client and PCP server
          MUST be specified in an appropriate document, which MUST
-        include whether the PCP Option can appear in a request and/or
+        state whether the PCP Option can appear in a request and/or
          response, whether it can appear more than once, and indicate
          what sort of Option data it conveys. If several Options are
          included in a PCP request, they MAY be encoded in any order by
@@ -643,7 +644,6 @@
          by sending messages that don't exceed 1020-4*number_of_options
          octets.</t>

-
          <t>If, while processing an Option, an error is encountered  
that causes
          a PCP error response to be generated, the PCP request MUST  
cause no
          state change in the PCP server or the PCP-controlled device  
(i.e., it
@@ -658,8 +658,8 @@
  by the PCP server, the PCP server MUST respond with
          the MALFORMED_OPTION result code; if this occurs in a  
response, the
          PCP client processes the first occurrence and MAY log an  
error.
-        If an invalid option
-        length is encountered (e.g., option length extends beyond the
+        If the PCP server encounters an invalid option
+        (e.g., option length extends beyond the
          length of the PCP Opcode itself), the error  
MALFORMED_OPTION SHOULD
          be returned (rather than MALFORMED_REQUEST), as that helps the
          client better understand how the packet was malformed.  The
@@ -684,7 +684,7 @@

          <t>PCP clients are free to ignore any or all Options  
included in
          responses, although naturally if a client explicitly  
requests an
-        Option where correct handling of that Option requires  
processing the
+        Option where correct execution of that Option requires  
processing the
          Option data in the response, that client is expected to  
implement code
          to do that.</t>

@@ -696,9 +696,9 @@
          is valid only for the MAP Opcode (for the PEER Opcode it  
would have no
          meaning).</t>

+        <?rfc needLines="9" ?>
          <t>Option definitions MUST include the information below:</t>

-        <?rfc needLines="7" ?>
          <t><list style="empty">
              <?rfc subcompact="yes"?>
              <t>Option Name: &lt;mnemonic&gt;</t>
@@ -765,7 +765,7 @@
              example, the NAT device cannot create more mappings at
              this time, is short of CPU cycles or memory, or due to
              some other temporary condition.  The same request may
-            succeed in the future.  This is a system-wide error, and
+            succeed in the future.  This is a system-wide error,
              different from USER_EX_QUOTA. This is a short lifetime
              error.  This can be used as a catch-all error, should no
              other error message be suitable.</t>
@@ -776,7 +776,7 @@
              <t hangText="10">USER_EX_QUOTA: Mapping would exceed  
user's port
              quota. This is a short lifetime error.</t>

-            <t hangText="11">CANNOT_PROVIDE_EXTERNAL: the requested
+            <t hangText="11">CANNOT_PROVIDE_EXTERNAL: the suggested
              external port and/or external address cannot be provided.
              This error MUST only be returned for PEER requests, for
              MAP requests that included the PREFER_FAILURE Option
@@ -855,7 +855,9 @@
          the timer expires, the timer is doubled (to 4 seconds) and  
the request
          is re-transmitted. If no response is received before the timer
          expires, the timer is doubled again (to 8 seconds) and the  
request is
-        re-transmitted.</t>
+        re-transmitted again, and so on, up to a maximum retransmission
+        interval of fifteen minutes, at which point the PCP request is
+        re-transmitted once every fifteen minutes until it is  
sucessfully answered.</t>

          <t>Once a PCP client has successfully received a response  
from a PCP
          server on that interface, it sends subsequent PCP requests  
to that
@@ -929,12 +931,12 @@
          code to MALFORMED_REQUEST, and zero-padding the response to a
          multiple of 4 octets if necessary.</t>

-        <t>The PCP server compares the IP address (from the
+        <t>The PCP server compares the source IP address (from the  
received
  IP header) with the field PCP Client IP Adddress.  If they do not  
match, the error ADDRESS_MISMATCH MUST be
  returned.  This is done to detect and prevent accidental use of PCP
  where a non-PCP-aware NAT exists between the PCP client and PCP
  server.  If the PCP client wants such a mapping it needs to ensure the
-PCP field matches the IP address from the perspective of the PCP  
server.</t>
+PCP field matches its apparent IP address from the perspective of  
the PCP server.</t>

          <t>Error responses have the same packet layout as success  
responses,
          with fields from the request copied into the response, and  
fields
@@ -1074,7 +1076,7 @@
          <list style="symbols">

          <t>If this is the first PCP response the client has  
received from
-        this PCP server, it is treated as necessarily valid, otherwise
+        this PCP server, the Epoch time value is treated as  
necessarily valid, otherwise

          <list style="symbols">

@@ -1085,22 +1087,22 @@

          <list style="symbols">

-        <t>The client computes the difference between the
+        <t>The client computes the difference between its
          <vspace />
-        current PCP server Epoch time value (current_server_time)  
and the
+        current local time value (current_client_time) and the
          <vspace />
-        previously received Epoch time value (previous_server_time):
+        time the previous PCP response was received from this PCP
+        server (previous_client_time):
          <vspace />
-        server_delta = current_server_time - previous_server_time;</t>
+        client_delta = current_client_time - previous_client_time;</t>

          <t>The client computes the difference between the
          <vspace />
-        current local time value (current_client_time) and the
+        current PCP server Epoch time value (current_server_time)  
and the
          <vspace />
-        time the previous PCP response was received from this PCP
-        server (previous_client_time):
+        previously received Epoch time value (previous_server_time):
          <vspace />
-        client_delta = current_client_time - previous_client_time;</t>
+        server_delta = current_server_time - previous_server_time;</t>

          <t>If client_delta+2 < server_delta - server_delta/8
          <vspace />
@@ -1116,9 +1118,9 @@

          <t>The client records the current time values for use in  
its next comparison:
          <vspace />
-        previous_server_time = current_server_time
+        previous_client_time = current_client_time
          <vspace />
-        previous_client_time = current_client_time</t>
+        previous_server_time = current_server_time</t>

          </list></t>

@@ -1138,8 +1140,10 @@
          been discussed by the PCP working group. If we were to  
require more
          accurate clocks in low-cost devices then more restrictive  
error
          tolerances could be imposed, such as "/64" or "/256".</t>
-

+        <t>Note: The calculations above are constructed to allow
+        client_delta and server_delta to be computed as unsigned  
values.</t>
+
        </section>

        <section anchor="version" title="Version Negotiation">
@@ -1168,7 +1172,7 @@
              support a contiguous range of versions -- i.e., a  
lowest version
              and a highest version and all versions in between.</t>

-            <t>The client sends first request using highest (i.e.,  
presumably
+            <t>The client sends its first request using the highest  
(i.e., presumably
              'best') version number it supports.</t>

              <t>If the server supports that version it responds  
normally.</t>
@@ -1207,8 +1211,7 @@
            response, shown in <xref target="fig_unprocessed"></ 
xref>. This
            helps with debugging interactions between the PCP client  
and PCP
            server. This Option MUST NOT appear more than once in a PCP
-          response. The unprocessed Options are listed once, and the  
Option
-          data is zero-filled to the necessary 32 bit boundary. If a  
certain
+          response. The unprocessed Options are each listed at most  
once. If a certain
            Option appeared more than once in the PCP request, that  
Option value
            MAY appear once or as many times as it occurred in the  
request. The
            order of the Options in the PCP request has no  
relationship with the
@@ -1272,9 +1275,9 @@
        its IPv6 interface), and if to send one or two MAP requests for
        each of its interfaces (e.g., if the PCP client has only an IPv4
        address but wants both IPv6 and IPv4 listeners, it sends a MAP
-      request containing the all-zeros IPv6 address in the Requested
+      request containing the all-zeros IPv6 address in the Suggested
        External Address field, and sends a second MAP request  
containing
-      the all-zeros IPv4 address in the Requested External Address  
field.
+      the all-zeros IPv4 address in the Suggested External Address  
field.
        If the PCP
        client has both an IPv4 and IPv6 address, and only wants an IPv4
        listener, it sends one MAP request from its IPv4 interface (if
@@ -1288,15 +1291,15 @@

        <t>It is REQUIRED that the PCP-controlled device assign the same
        external IP address to PCP-created explicit dynamic mappings and
-      to implicit dynamic mappings for a given Internal Host. In the
+      to implicit dynamic mappings for a given Internal Address. In the
        absence of a PCP option indicating otherwise, it is
-      REQUIRED that PCP-created explicit dynamic mappings be assigned
+      REQUIRED that all PCP-created explicit dynamic mappings be  
assigned
        the same external IP address.  It is RECOMMENDED that static
-      mappings for that Internal Host (e.g., those created by a
+      mappings for that Internal Address (e.g., those created by a
        command-line interface on the PCP server or PCP-controlled
-      device) also be assigned to the same IP address. Once all
-      internal addresses assigned to a given Internal Host have no
-      implicit dynamic mappings and have no explicit dynamic mappings
+      device) also be assigned to the same IP address. Once an
+      Internal Address has no
+      implicit dynamic mappings and no explicit dynamic mappings
        in the PCP-controlled device, a subsequent PCP request for that
        Internal Address MAY be assigned to a different External
        Address. Generally, this re-assignment would occur when a CGN
@@ -1320,7 +1323,7 @@
  address of the PCP packet itself, 'internal' is the Internal IP
  Address field of the THIRD_PARTY Option (if present) or the same as
  the source address of the PCP packet iself (if the THIRD_PARTY Option
-is not present), 'external' is the Requested External Address field of
+is not present), 'external' is the Suggested External Address field of
  the MAP or PEER request, the 'remote peer' is the Remote Peer IP
  Address of the PEER request or the FILTER option of the MAP
  request.</preamble>
@@ -1353,8 +1356,6 @@
          port. Conceptually implicit and explicit mappings are
          different "layers" in the NAT forwarding state database.</t>

-
-
        <section anchor="operating_a_server" title="For Operating a  
Server">
          <t>A host operating a server (e.g., a web server) listens  
for traffic
          on a port, but the server never initiates traffic from that  
port. For
@@ -1390,6 +1391,7 @@
       * 1. Sending the first request
       * 2. Retransmitting requests due to packet loss
       * 3. Resending a request due to impending lease expiration
+     * 4. Resending a request due to server state loss
       * The PCP packet sent is identical in all cases, apart from the
       * Suggested External Address and Port which may differ between
       * (1), (2), and (3).
@@ -1481,6 +1483,7 @@
       * 1. Sending the first request
       * 2. Retransmitting requests due to packet loss
       * 3. Resending a request due to impending lease expiration
+     * 4. Resending a request due to server state loss
       * The PCP packet sent is identical in all cases, apart from the
       * Suggested External Address and Port which may differ between
       * (1), (2), and (3).
@@ -1560,6 +1563,7 @@
       * 1. Sending the first request
       * 2. Retransmitting requests due to packet loss
       * 3. Resending a request due to impending lease expiration
+     * 4. Resending a request due to server state loss
       * The PCP packet sent is identical in all cases, apart from the
       * Suggested External Address and Port which may differ between
       * (1), (2), and (3).
@@ -1614,7 +1618,7 @@
        <t>This section defines an Opcode which controls forwarding  
from a NAT
        (or firewall) to an Internal Host.<list hangIndent="8"  
style="hanging">
            <t hangText="  MAP:">Create an explicit dynamic mapping  
between an
-          Internal Address and an External IP address.</t>
+          Internal Address + Port and an External Address + Port.</t>
          </list></t>

        <t>PCP Servers SHOULD
@@ -1654,7 +1658,7 @@
        appropriate) for the duration of the mapping's lifetime. This  
is done
        to ensure that ICMP messages can still be used by hosts, without
        application programmers or PCP client implementations needing to
-      signal PCP separately to create ICMP mappings for those  
flows.</t>
+      use PCP separately to create ICMP mappings for those flows.</t>

        <t>The operation of the MAP Opcode is described in this  
section.</t>

@@ -1747,11 +1751,16 @@
          </figure>

          <t>These fields are described below:<list style="hanging">
-            <t hangText="Lifetime (in common header):">On a success  
response,
-            this indicates the lifetime for this mapping, in  
seconds. On an
-            error response, this indicates how long clients should  
assume
-            they'll get the same error response from the PCP server  
if they
-            repeat the same request.</t>
+            <t hangText="Lifetime (in common header):">On an error
+            response, this indicates how long clients should assume
+            they'll get the same error response from the PCP server if
+            they repeat the same request. On a success response, this
+            indicates the lifetime for this mapping, in seconds.
+            The PCP client SHOULD impose an upper limit on this  
returned
+            Assigned Lifetime value, and 24 hours is RECOMMENDED. This
+            means if the PCP server returns an absurdly long Assigned
+            Lifetime (e.g., 5 years), the PCP client will behave as if
+            it received a more sane value (e.g., 24 hours).</t>

              <t hangText="Protocol:">Copied from the request.</t>

@@ -1818,12 +1827,6 @@
          requests MUST NOT be sent less than four seconds apart (a PCP
          client MUST NOT send a flood of ever-closer-together requests
          in the last few seconds before a mapping expires).</t>
-
-        <t>The PCP client SHOULD impose an upper limit on this
-        returned Assigned Lifetime value, and 24 hours is RECOMMENDED.
-        This means if the PCP server returns an absurdly long Assigned
-        Lifetime (e.g., 5 years), the PCP client will behave as if it
-        received a more sane value (e.g., 24 hours).</t>
          </section>
        </section>

@@ -1833,10 +1836,9 @@
          Opcode. Processing SHOULD be performed in the order of the  
following
          paragraphs.</t>

-        <t>The following fields from the MAP request are copied into
-        the MAP response: Protocol, Internal Port, Requested External
-        Address, and (if present and processed by the PCP server) the
-        THIRD_PARTY Option.</t>
+        <t>The Protocol and Internal Port fields from the MAP request
+        are copied into the MAP response. If present and processed  
by the PCP server
+        the THIRD_PARTY Option is also copied into the MAP  
response.</t>

          <t>If the Requested Lifetime is non-zero, it indicates a
          request to create a mapping or extend the lifetime of an
@@ -1884,7 +1886,7 @@
          External Address and Port in its response, regardless of the
          Suggested External Address and Port in the request.  If a
          mapping already exists for the requested Internal Address  
and Port
-        the request contains the PREFER_FAILURE Option, but the
+        and the request contains the PREFER_FAILURE Option, but the
          Suggested External Address and Port do not match the actual
          External Address and Port of the already existing mapping, the
          error CANNOT_PROVIDE_EXTERNAL is returned.  If an implicit
@@ -1964,8 +1966,9 @@
          receives a PCP response for the MAP Opcode.</t>

          <t>After performing common PCP response processing, the  
response is
-        further matched with an outstanding request by comparing the  
protocol,
-        internal IP address, and internal port. Other fields are not  
compared,
+        further matched with an outstanding request by comparing the  
Protocol
+        and Internal Port (and, if THIRD_PARTY, Internal IP Address).
+        Other fields are not compared,
          because the PCP server sets those fields.</t>

          <t>On a success response, the PCP client can use the  
External IP
@@ -1979,13 +1982,12 @@
          in <xref target="map-opcode_client_operation"></xref>,  
except that the
          Suggested External Address and Port SHOULD be set to the  
values
          received in the response. From the PCP server's point of  
view a MAP
-        request to renew a mapping is identical to a MAP request to  
request a
+        request to renew a mapping is identical to a MAP request to  
create a
          new mapping, and is handled identically.  Indeed, in the  
event of PCP
          server state loss, a renewal request from a PCP client will  
appear to
-        the server to be a request for a new mapping, with a particular
+        the server to be a request to create a new mapping, with a  
particular
          Suggested External Address and Port, which happens to be  
what the PCP
-        server previously assigned. See also
-        <xref target="maintaining_mappings"></xref>.</t>
+        server previously assigned. See also <xref target="reboot"></ 
xref>.</t>

          <t>On an error response, the client SHOULD NOT repeat the  
same request
          to the same PCP server within the lifetime returned in the
@@ -2022,8 +2024,13 @@
          that already exists as a static mapping, the PCP server will
          return a successful result, confirming that the requested
          mapping exists. The lifetime the PCP server returns for such a
-        static mapping SHOULD be 4294967295 (0xFFFFFFFF).  There is no
-        need for a PCP client to renew a static mapping.</t>
+        static mapping SHOULD be 4294967295 (0xFFFFFFFF). Upon  
receipt of
+        such a MAP response with an absurdly long Assigned Lifetime the
+        PCP client SHOULD behave as if it received a more sane value
+        (e.g., 24 hours), and renew the mapping accordingly, to ensure
+        that if the static mapping is removed the client will continue
+        to maintain the mapping it desires.
+        </t>

          <t>If the requested lifetime is zero then: <list  
style="symbols">
              <t>If both the internal port and protocol are non-zero, it
@@ -2092,7 +2099,7 @@
        </section>

        <section anchor="renumbering" title="Address Change Events">
-        <t>A customer premises router might obtain a new IP address,  
for a
+        <t>A customer premises router might obtain a new External IP  
address, for a
          variety of reasons including a reboot, power outage, DHCP  
lease
          expiry, or other action by the ISP. If this occurs, traffic  
forwarded
          to the host's previous address might be delivered to  
another host
@@ -2166,8 +2173,8 @@
        support if they wish.</t>

        <t>Because a mapping created or managed by PEER behaves
-      almost exactly as if an implicit dynamic mapping were created by
-      a packet sent by the host (e.g., TCP SYN sent by the host),
+      almost exactly like an implicit dynamic mapping created as a  
side-effect of
+      a packet (e.g., TCP SYN) sent by the host,
        mappings created or managed using PCP PEER requests may be
        Endpoint Independent Mappings (EIM) or Endpoint Dependent  
Mappings
        (EDM), with Endpoint Independent Filtering (EIF) or Endpoint  
Dependent
@@ -2399,10 +2406,10 @@
          arriving at the NAT gateway first, and allow PEER to be  
used to
          recreate an implicit dynamic mapping (see last paragraph of
          <xref target="reboot"></xref>).  If the requested mapping does
-        not yet exist, but Suggested External Address and Port cannot
+        not yet exist, and Suggested External Address and Port cannot
          be honored, the error CANNOT_PROVIDE_EXTERNAL is
          returned.  If the requested mapping already exists, it is
-        a request to modify that existing mapping.</t>
+        a request to modify the lifetime of that existing mapping.</t>

          <t>The PEER Opcode MAY reduce the lifetime of an existing
          implicit dynamic mapping created by PEER; this is
@@ -2455,7 +2462,7 @@

          <t>After performing common PCP response processing, the  
response is
          further matched with a request by comparing the protocol,  
internal IP
-        address, internal port, remote peer address and remote peer  
port.
+        address (if THIRD_PARTY), internal port, remote peer address  
and remote peer port.
          Other fields are not compared, because the PCP server  
changes those
          fields to provide information about the mapping created by the
          Opcode.</t>
@@ -2628,14 +2635,14 @@
              <?rfc subcompact="no"?>
          </list></t>

-        <t>The result code CANNOT_PROVIDE_EXTERNAL is returned if both
-        the Suggested External Port and Suggested External Address
+        <t>The result code CANNOT_PROVIDE_EXTERNAL is returned if
+        the Suggested External Address and Port
          cannot be mapped. This can occur because the External Port is
          already mapped to another host's implicit dynamic mapping, an
          explicit dynamic mapping, a static mapping, or the same
          Internal Address and Port has an implicit dynamic mapping
          which is mapped to a different External Port than
-        requested. This can also occur because the External Address is
+        suggested. This can also occur because the External Address is
          no longer available (e.g., due to renumbering).  The server
          MAY set the Lifetime in the response to the remaining lifetime
          of the conflicting mapping, rounded up to the next larger
@@ -2756,7 +2763,7 @@
          MALFORMED_OPTION result code.</t>

          <t>If multiple occurrences of the FILTER Option exist in the
-        same MAP request, they are processed in the same order
+        same MAP request, they are processed in the order
          received (as per normal PCP Option processing) and they MAY
          overlap the filtering requested. If an existing mapping exists
          (with or without a filter) and the server receives a MAP
@@ -2765,7 +2772,7 @@
          lifetime of 0 and contains the FILTER Option, the error
          MALFORMED_OPTION is returned.</t>

-        <t>If any of occurrences of the FILTER Option in a request  
packet are
+        <t>If any occurrences of the FILTER Option in a request  
packet are
          not successfully processed then an error is returned (e.g.,
          MALFORMED_OPTION if one of the Options was malformed) and  
as with
          other PCP errors, returning an error causes no state to be  
changed in
@@ -2792,7 +2799,7 @@

          <t>The use of the FILTER Option can be seen as a performance
          optimization. Since all software using PCP to receive incoming
-        connections also has to deal with the case where may be  
directly
+        connections also has to deal with the case where it may be  
directly
          connected to the Internet and receive unrestricted incoming  
TCP
          connections and UDP packets, if it wishes to restrict  
incoming traffic
          to a specific source address or group of source addresses such
@@ -2854,7 +2861,7 @@
          unsuccessful at temporarily reserving the next-higher port  
for this
          PCP client, the server MUST NOT include the EVEN_PLUS_ONE  
Option in
          its response. If the server receives a PCP request with the
-        EVEN_PLUS_ONE Option for an odd-numbered requested-external- 
port, it
+        EVEN_PLUS_ONE Option for an odd-numbered suggested-external- 
port, it
          MUST return an error.</t>

          <t>This Option is permitted with the following OpCodes:  
MAP44, MAP64,
@@ -2975,8 +2982,9 @@
      <section anchor="implementation_considerations"  
title="Implementation Considerations">

        <section anchor="EDM" title="Implementing MAP with EDM port- 
mapping NAT">
-      <t>This section provides non-normative guidance that may be  
useful to
-      implementors.</t>
+        <t>This section provides non-normative guidance that may be  
useful to
+        implementers.</t>
+
          <t>For implicit dynamic mappings, some existing NAT devices  
have
          endpoint-independent mapping (EIM) behavior while other NAT  
devices
          have endpoint-dependent mapping (EDM) behavior. NATs which  
have EIM
@@ -3005,8 +3013,9 @@
        </section>

        <section title="Lifetime of Explicit and Implicit Dynamic  
Mappings">
-      <t>This section provides non-normative guidance that may be  
useful to
-      implementors.</t>
+        <t>This section provides non-normative guidance that may be  
useful to
+        implementers.</t>
+
          <t>No matter if a NAT is EIM or EDM, it is possible that  
one (or more)
          implicit dynamic mappings, using the same internal port on the
          Internal Host, might be created before or after a MAP  
request. When
@@ -3021,14 +3030,16 @@
        </section>

        <section anchor="failure" title="PCP Failure Scenarios">
-      <t>This section provides non-normative guidance that may be  
useful to
-      implementors.</t>
+        <t>This section provides non-normative guidance that may be  
useful to
+        implementers.</t>
+
          <t>If an event occurs that causes the PCP server to lose  
explicit
          dynamic mapping state (such as a crash or power outage),  
the mappings
-        created by PCP are lost. Such loss of state is expected to  
be rare in a service
-        provider environment (due to redundant power, disk drives  
for storage,
-        etc.), but more common in a residential NAT device which  
does not
-        write this information to non-volatile memory. Of course,  
due to
+        created by PCP are lost. Occasional loss of state may be  
unavoidable
+        in a residential NAT device which does not write transient
+        information to non-volatile memory. Loss of state is expected
+        to be rare in a service provider environment (due to redundant
+        power, disk drives for storage, etc.). Of course, due to
          outright failure of service provider equipment (e.g., software
          malfunction), state may still be lost.</t>

@@ -3040,7 +3051,7 @@
          <t>Further analysis of PCP failure scenarios is in
          <xref target="I-D.boucadair-pcp-failure"></xref>.</t>

-        <section anchor="reboot" title="Recreating Mappings">
+        <section title="Recreating Mappings" anchor="reboot">
  <!--
            <t>The PCP server SHOULD store mappings in persistent  
storage so
            when it is powered off or rebooted, it remembers the port  
mapping
@@ -3052,10 +3063,9 @@
            <t>However, maintaining this state is not essential for  
correct
            operation.
  -->
-      <t>This section provides non-normative guidance that may be  
useful to
-      implementors.</t>
+          <t>This section provides non-normative guidance that may  
be useful to
+          implementers.</t>

-
            <t>A mapping renewal packet is formatted identically to  
an original
            mapping request; from the point of view of the client it  
is a
            renewal of an existing mapping, but from the point of  
view of a
@@ -3065,31 +3075,35 @@
            mappings.</t>

            <t>When the PCP server loses state and begins processing  
new PCP
-          messages, its Epoch is reset and begins counting again  
from zero
-          (per the procedure of <xref target="epoch"></xref>). As  
the result
-          of receiving a packet where the Epoch field is outside the
-          expected range, indicating that a reboot or similar loss of
+          messages, its Epoch time is reset and begins counting  
again. As the result
+          of receiving a packet where the Epoch time field is  
outside the
+          expected range (<xref target="epoch"></xref>), indicating  
that a reboot or similar loss of
            state has occurred, the client can renew its port mappings
            sooner, without waiting for the normal routine renewal  
time.</t>
          </section>

          <section title="Maintaining Mappings"  
anchor="maintaining_mappings">
-      <t>This section provides non-normative guidance that may be  
useful to
-      implementors.</t>
+          <t>This section provides non-normative guidance that may  
be useful to
+          implementers.</t>
+
            <t>A PCP client refreshes a mapping by sending a new PCP  
request
            containing information from the earlier PCP response. The  
PCP server
            will respond indicating the new lifetime. It is possible,  
due to
            reconfiguration or failure of the PCP server, that the  
public IP
            address and/or public port, or the PCP server itself, has  
changed
-          (due to a new route to a different PCP server). To detect  
such
-          events more quickly, the PCP client may find it beneficial  
to use
-          shorter lifetimes (so that it communicates with the PCP  
server more
-          often). If the PCP client has several mappings, the Epoch
+          (due to a new route to a different PCP server). Such  
events are
+          not an error. The PCP server will simply return a new  
External
+          Address and/or External Port to the client, and the client  
should
+          record this new External Address and Port with its  
rendezvous service.
+          To detect such events more quickly, the PCP client may  
find it
+          beneficial to use shorter lifetimes (so that it communicates
+          with the PCP server more often).</t>
+
+          <t>If the PCP client has several mappings, the Epoch
            value only needs to be retrieved for one of them to  
determine
            whether or not it appears the PCP server may have suffered a
-          catastrophic loss of state.</t>
-
-          <t>If the client wishes to check the PCP server's Epoch,  
it sends a
+          catastrophic loss of state.
+          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
@@ -3119,15 +3133,15 @@

  <t>Because an SCTP-aware NAT does not rewrite SCTP port numbers (and
  firewalls never do), a PCP MAP or PEER request for an SCTP mapping
-SHOULD provide the same Internal Port and Requested External Port.  If
-the PCP server supports SCTP, and the requested external port cannot
+SHOULD provide the same Internal Port and Suggested External Port.  If
+the PCP server supports SCTP, and the suggested external port cannot
  be provided in an explicit dynamic SCTP mapping, then the error
  CANNOT_PROVIDE_EXTERNAL is returned.</t>
  </section>
        </section>

-<section title="Source Address in PCP Header"  
anchor="implement_source_address">
-<t>All PCP requests include the PCP client's IP address
+<section title="Source Address Replicated in PCP Header"  
anchor="implement_source_address">
+<t>All PCP requests include the PCP client's IP address replicated
  in the PCP header.  This is used to detect address rewriting (NAT)
  between the PCP client and its PCP server.  On operating systems that
  support the sockets API, the following steps are RECOMMENDED for a PCP
@@ -3139,7 +3153,7 @@
              <t>Create a UDP socket.</t>
              <t>Bind the UDP socket.</t>
              <t>Call the getsockname() function to retrieve a sockaddr
-            containing the source address and port the kernel will use
+            containing the source address the kernel will use
              for UDP packets sent through this socket.</t>
              <t>If the IP address is an IPv4 address, encode the
              address into an IPv4-mapped IPv6 address.  Place the IPv6
@@ -3286,10 +3300,10 @@
          or requesting a random port. These UPnP IGD requests are  
translated to
          PCP requests and sent to the PCP server. The requests  
include the
          PREFER_FAILURE Option, which causes the PCP server to  
return an error
-        if it cannot allocate the requested port. The interworking  
function
+        if it cannot allocate the suggested port. The interworking  
function
          translates the PCP error response to a UPnP IGD error  
response. This
          repeats until the UPnP IGD client gives up or until the PCP  
server is
-        able to return the requested port.</t>
+        able to return the suggested port.</t>

          <figure align="left" anchor="message-flow-upnp-1"
                  title="Message Flow: Interworking from UPnP IGD 1.0  
AddPortMapping action to PCP">
@@ -3344,6 +3358,7 @@

  -->

+    <?rfc needLines="6" ?>
      <section title="Deployment Considerations">
        <section title="Ingress Filtering">
          <t>As with implicit dynamic mappings created by outgoing  
TCP packets,
@@ -3554,7 +3569,7 @@
            <t>An attacker, on the path between the PCP client and PCP
            server, can drop PCP requests, drop PCP responses, or  
spoof a
            PCP error, all of which will effective deny service.   
Through
-          such actions, the PCP client would not be aware the PCP  
server
+          such actions, the PCP client might not be aware the PCP  
server
            might have actually processed the PCP request.</t>
          </section>

@@ -3904,7 +3919,7 @@
  is undefined.</t>
  <t>combined SERVER_OVERLOADED and NO_RESOURCES into one error code,
  NO_RESOURCES.</t>
-<t>SCTP mappings have to use same internal and requested
+<t>SCTP mappings have to use same internal and suggested
  external ports, and have implied PREFER_FAILURE semantics.</t>
  <t>Re-instated ADDRESS_MISMATCH error, which only checks the
  client address (not its port).</t>
@@ -4012,7 +4027,7 @@
              mapping state. Moved it to a new section, as well (it  
is now
              <xref target="restoring"></xref>).</t>

-            <t>MAP errors now copy the Requested IP Address (and  
port) fields
+            <t>MAP errors now copy the Suggested IP Address (and  
port) fields
              to Assigned IP Address (and port), to allow PCP client to
              distinguish among many outstanding requests when using
              PREFER_FAILURE.</t>
@@ -4026,7 +4041,7 @@

              <t>created new Implementation Considerations section  
(<xref
              target="implementation_considerations"></xref>) which  
discusses
-            non-normative things that might be useful to  
implementors. Some
+            non-normative things that might be useful to  
implementers. Some
              new text is in here, and the Failure Scenarios text (<xref
              target="failure"></xref>) has been moved to here.</t>

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Oct 2011 13:58:49 -0700

> Last call ends Friday October 28th at 5pm EST.

Here are some of my concerns about draft-ietf-pcp-base-16.txt.

>    Mapping Types:
>       There are three different ways to create mappings: implicit
>       dynamic mappings, explicit dynamic mappings, and static  
> mappings.
>       Implicit dynamic mappings are created as a result of a TCP  
> SYN or
>       outgoing UDP packet or a PCP PEER request, and allow Internal
>       Hosts to receive replies to their outbound packets.  Explicit
>       dynamic mappings are created as a result of a PCP MAP request.

This is bizarre. Everywhere else in the document the terms explicit  
and implicit are used with their usual meanings:

An explicit mapping is explicitly made via PCP.

An implicit mapping occurs implicitly as a side effect of something  
else (e.g. TCP SYN).

And then "Terminology" redefines the word "implicit" to mean  
"explicitly made (via a PCP PEER request)."

That's bogus. Let's stick with the usual word meanings.

>    PCP Server:
>       A PCP software instance that implements the server side of  
> the PCP
>       protocol, via which PCP clients request and manage explicit
>       mappings.  This is conceptually separate from the NAT or  
> firewall
>       itself

What is that last sentence there for?

What other protocol specification says, "This protocol is  
conceptually separate from what this protocol does"?

Does the DHCP spec say, "A DHCP server is conceptually separate from  
the thing that assigns IP addresses"?

Does the NFS spec say, "An NFS server is conceptually separate from  
the thing that stores files"?

Sure, you could make a diskless NFS front end that interfaces to some  
different back end storage, and everyone knows and understands that  
already. A protocol specification doesn't also need to be an  
introductory computer science tutorial.

> 7.7.1.  UNPROCESSED Option
>
>    If the PCP server cannot process a mandatory-to-process Option, for
>    whatever reason, it includes the UNPROCESSED Option in the  
> response,
>    shown in Figure 5.
>    ...
>    This Option MUST NOT appear in a response unless
>    the associated request contained at least one mandatory-to-process
>    Option.

Why only for mandatory-to-process options? If a PCP server ignores an  
optional option (e.g. because it doesn't understand it) I can imagine  
it might be *extremely* helpful for the client to know that.

Why not use the UNPROCESSED Option for *all* options that for  
whatever reason were not processed?

>                               source  internal  external  remote peer
>                               ------  --------  -------   -----------
>                 IPv4 firewall  IPv4     IPv4      IPv4      IPv4
>                 IPv6 firewall  IPv6     IPv6      IPv6      IPv6
>                         NAT44  IPv4     IPv4      IPv4      IPv4
>        DS-Lite plain mode (1)  IPv6     IPv4      IPv4      IPv4
>            DS-Lite encap. (2)  IPv4     IPv4      IPv4      IPv4
>                     NAT64 (3)  IPv6     IPv6      IPv4      IPv6
>                         NPTv6  IPv6     IPv6      IPv6      IPv6

I find this table a little confusing and misleading.

The source address family *always* matches the internal address  
family when you're not using THIRD_PARTY, and need not match when you  
are using THIRD_PARTY. So the source/internal address family is all  
about THIRD_PARTY or not, and not about the seven scenarios listed.

>    Note that PCP requests containing the MAP or PEER Opcodes cannot
>    delete or shorten the lifetime of an existing implicit mapping for
>    the indicated internal address and port.  Conceptually implicit and
>    explicit mappings are different "layers" in the NAT forwarding  
> state
>    database.

I don't care either way about this, but lots of other places in the  
document contradict it. E.g. an implicit mapping can be "upgraded" to  
an explicit mapping, and then the explicit mapping can be deleted. We  
need to decide what we want and be consistent about it.

>    In (1) and (2), 'source' refers to the PCP messaging between the
>    Dual-Stack Lite B4 element and the AFTR element, with (1) showing
>    Dual-Stack Lite plain mode and (2) showing Dual-Stack Lite

Where is the term "plain mode" introduced?

>    If
>    the PCP server or PCP-controlled device does not support the  
> Protocol
>    or cannot create a mapping for the Protocol (e.g., because the
>    request is for a NAT mapping instead of a firewall mapping and the
>    PCP-controlled device is not a NAT or does not support NATting that
>    specific Protocol), it MUST generate an UNSUPP_PROTOCOL error.

What does that mean? What is a "firewall mapping"? What is a "NAT  
mapping"? Why does the client know or care? The whole point of PCP is  
that the client doesn't know or care -- it asks for a mapping, and  
(except when using the stupid UPnP mode) the server gives it one. End  
of story.

>    If
>    the requested Lifetime is non-zero, the Internal Port is zero, and
>    the Protocol is non-zero, it indicates a request to map all  
> incoming
>    traffic for that entire Protocol.  If this request cannot be
>    fulfilled in its entirety, the error UNSUPP_PROTOCOL MUST be
>    returned.

I think NO_RESOURCES. The UNSUPP_PROTOCOL response says "I don't know  
what you're talking about." In this case the server understands the  
request; it just doesn't currently have the ability to grant it.

>    If the requested lifetime is zero then:
>    ...
>    o  If the internal port is zero and the protocol is non-zero, or  
> the
>       internal port is non-zero and the protocol is zero, then the
>       request is invalid and the PCP Server MUST return a
>       MALFORMED_REQUEST error to the client.

What about deleting an SCTP or port wildcard mapping (allowed  
elsewhere in the document).

>      PEER: Create an implicit dynamic mapping, or set or query an
>            existing implicit dynamic mapping to a remote peer's IP
>            address and port.

No, if we're *explicitly* creating it via a PCP request, it's an  
explicit dynamic mapping, not an implicit dynamic mapping.

> 10.1.  PEER Operation Packet Formats
> ...
>    Remote Peer IP Address:  Remote peer's IP address from the
>       perspective of the PCP client, so that the PCP client does not
>       need to concern itself with NAT64 or NAT46 (which both cause the
>       client's idea of the remote peer's IP address to differ from the
>       remote peer's actual IP address).  This field allows the PCP
>       client and PCP server to disambiguate multiple connections from
>       the same port on the Internal Host to different servers, and  
> does
>       not create or adjust the filtering associated with the mapping
>       (for that, the FILTER option is used, Section 11.3).

No, the FILTER option is not allowed with PEER requests.

>    On receiving the PEER Opcode, the PCP server examines the mapping
>    table.  If the requested mapping does not yet exist, and the
>    Suggested External Address and Port can be honored, the mapping is
>    created.  By having PEER create such a mapping, we avoid a race
>    condition between the PEER request or the initial outgoing packet
>    arriving at the NAT gateway first
>
>    Note that some PCP servers and
>    some PCP-controlled devices are expected to not support this
>    functionality and will respond with the CANNOT_PROVIDE_EXTERNAL
>    error.

Why? Why are some PCP servers expected to be deficient and suffer  
from this race condition? We should remove this -- it gives the  
appearance of condoning shoddy implementation.

>    After a successful PEER response is sent, it is implementation-
>    specific if the PCP-controlled device destroys the mapping when the
>    lifetime expires, or if the PCP-controlled device's implementation
>    allows traffic to keep the mapping alive.  Thus, if the PCP client
>    wants the mapping to persist beyond the lifetime reported in the
>    response, it MUST refresh the mapping (by sending another PEER
>    message) prior to the expiration of the lifetime.
>
>    If the PCP client wishes to keep this mapping alive beyond the
>    indicated lifetime, it SHOULD issue a new PCP request prior to the
>    expiration.  That is, inside to outside traffic is not  
> sufficient to
>    ensure the mapping will continue to exist.

This is bogus. It means that a single PEER request 'poisons' a  
preexisting implicit mapping, causing it to then die even while TCP  
traffic is flowing thought it, unless subsequent PEER requests are  
used to keep it alive. A PEER request should be benign, not  
destructive. It may lengthen the life of an existing implicit  
mapping, but it should not kill it.

>    If the mapping is
>    terminated by the TCP client or server (e.g., TCP FIN or TCP RST),
>    the mapping will be destroyed normally; the mapping will not  
> persist
>    for the time indicated by Lifetime.  This means the Lifetime in a
>    PEER response indicates how long the mapping will persist in the
>    absence of a transport termination message (e.g., TCP RST).
>
>    Some transport protocols signal the end of a connection (e.g., TCP
>    FIN, TCP RST, SCTP SHUTDOWN).  After a successful PEER response is
>    sent, the receipt of such a transport-specific message MUST NOT  
> cause
>    the mapping to be destroyed.  Rather, the mapping is maintained  
> until
>    the PEER-signaled lifetime expires.

Which is it? TCP RST destroys a mapping or it does not?

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 18:21:32 +0200

In your previous mail you wrote:

   
   
=> as far as I know you are one of the authors so you should not
still have heavy concerns about the document?

   

   
   
=> the terminology was defined independently from PCP itself
(BTW I think the terminology was one of the big things the PCP work
brought so IMHO we should defend it if there is no clearly better
proposal).

I agree the fact a PEER request can create an implicit dynamic mapping
is a bit strange from the pure language point of view, now the solutions
are:
 - live with it as we have no better proposal

 - get rid of this function of PEER, i.e., make PEER requests only
  query and extend lifetime of implicit dynamic mappings

 - get rid of the PEER opcode as if it loses this function it has
  a low interest (or move it to another document)

 - rename implicit dynamic mappings, explicit dynamic mappings and
  static mappings into type one mappings, type two mappings and
  type three mappings so the document will be unreadable but
  correct

BTW the two middle solutions were already discussed (I asked for
them :-) and the WG decision seemed to be no in both cases,
so we have the choice between doing nothing and the renaming.

BTW if your intent is just to change the type managed by
the PEER opcode I'll strongly object.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 18:29:06 +0200

=> it is just without entering into details the fact the PCP server
is a control plane device when the NAT (or firewall) itself is
a forwarding plane device.
IMHO the real reason is to kill the idea there is a mandatory 1:1
binding between the PCP server (essentially a protocol engine)
and the NAT/firewall it controls, i.e., a PCP server can control
more than one device or a device can be controlled by more than
one PCP server.

=> s/does/controls/

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 18:32:18 +0200

=> in fact I have a related question: is there a known case where
an option could be optional with the current definition of optional
(i.e., the server can silently ignore it)?
If there is none we just waste the half of the option code space,
if there is at least one we have a counter example.

Regards

Francis.Dupont.fr

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 18:37:29 +0200

=> if you mean when the source and the internal addresses have a
different family there must be a THIRD_PARTY option I can't disagree.
But how is this confusing? All the 4 kinds of addresses are
defined before the table, and the internal address definition says
exactly what we want, i.e.:

   ... 'internal' is the Internal IP Address field of the
   THIRD_PARTY Option (if present) or the same as the source address of
   the PCP packet iself (if the THIRD_PARTY Option is not present),

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 18:46:55 +0200

document contradict it.

=> if you concern is about the PEER edition glitch which got back
the implementation-dependent lifetime reduction and delete I agree
but I am afraid it is not...

   E.g. an implicit mapping can be "upgraded" to  
   an explicit mapping, and then the explicit mapping can be deleted. We  
   need to decide what we want and be consistent about it.
   
=> I have no problem with this, BTW you have the same thing for static
mappings, i.e., an explicit dynamic mapping can be upgraded (and
this word was carefully chosen) into a static mapping via the Web interface
for instance. And IMHO this could be not a rare operation
(at the opposite of the implicit -> explicit which comes a should not
happen condition)

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 18:54:02 +0200

=> [I-D.dupont-pcp-dslite] aka draft-dupont-pcp-dslite-00.txt
(and soon 01.txt as I have a pending request to add a line in it
from Mohammed). I can't see a formal issue to use this kind of
terms when:
 - they are very localized (and it is the case, the two occurrences
  of 'plain mode' are in the figure and its explanation
 - the document where they are defined is immediately referenced
(BTW I put they because you have also "encapsulation mode" and
my statement is a general one).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 19:01:54 +0200

mapping"?

=> explained in section 3 about terminology.

 Why does the client know or care?

=> if a device embeds both a NAT and a firewall (s)he can really care.

   The whole point of PCP is that the client doesn't know or care --
   it asks for a mapping, and (except when using the stupid UPnP mode)
   the server gives it one. End of story.
   
=> this is your opinion but I don't share it, I know a lot of people
who don't share it, including in the PCP WG and in NAT implementors.
If you really have the power to change the world, please first make
NATs to disappear (:-).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 19:07:57 +0200

>    fulfilled in its entirety, the error UNSUPP_PROTOCOL MUST be
   
=> I have a concern about this but not the same: I believe it applies
only to protocols which have no 16-bit ports. I sent a comment
about this using as argument the internal port definition:

   Internal Port:  Internal port for the mapping.  The value 0 indicates
      "all ports", and is legal when the lifetime is zero (a delete
      request), if the Protocol does not use 16-bit port numbers, or the
      Protocol is 0 (meaning 'all protocols')

so if we add the two texts (your citation and mine) the specified error
is the right one.

=> so the question is whether the error is about ports or protocol,
BTW I believe the Editor answered so I can dig into my mails to
verify if my interpretation is the right one.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 19:18:08 +0200

>       MALFORMED_REQUEST error to the client.
   
   What about deleting an SCTP

=> it is not the right example, cf 12.3.3

   or port wildcard mapping (allowed  elsewhere in the document).

=> they are not allowed in general but I agree there is a corner case
where it is possible to create a mapping but not to delete it.
The problem is in the first part when the non-zero protocol doesn't
use 16-bit ports, for instance IPsec ESP.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 19:20:35 +0200

=> no, it is not an explicit dynamic mapping as defined in the
terminology, in particular on at least 70% of the existing NAT it
is not EIM/EIF, etc.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 19:26:38 +0200

=> it can be a wording problem: the note just says if you want
to create an EIM mapping with a specific filtering than you should
use a MAP request with a FILTER option, *and* this is deeply
different from the previous sentence which is about the *mode*
(as it can be shown by applying it to an EIM NAT: the remote peer
doesn't matter, in fact on an EIM NAT the remote peer address and
port are simply ignored by the NAT code handling PEER requests).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 19:33:38 +0200

=> what you want to remove? the text explaining there is a race
so you should do the things in the right order to avoid it,
or all the NATs which can show the race condition? or your
concern is about the last paragraph?

About the first IMHO users must understand what they do so
I object to remove it. About the others they are about NAT
implementations and if you don't like some I can say than
personally I hate NATs so I like none (:-).
To be serious NAT implementations are explicitly out of scope
by the WG charter.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 19:40:54 +0200

=> it is implementation-specific because the NAT behavior is
out of the scope by the WG charter. The remaining text is just
providing a way to avoid the dependence on the implementation
(i.e., works in all cases). I can't see a problem with this
as it is something we can't change.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Oct 2011 19:53:27 +0200

=> yes, it is self contradicting in a few lines. But the text after is
worse:

   ... If the PCP client wishes to
   terminate the mapping prior to this, it will send a PEER request with
   Lifetime set to 0, which MAY be honored by the PCP server; as stated
   earlier, that is implementation-dependent.

=> as far as I can remember we (WG in previous discussions) agreed:
 - there should be *no* implementation-dependent lifetime reductions
  (at least two arguments: it is useless if it is implementation
   dependent; it is incompatible with the query function)

 - there is no use case for the "0 deleting" so it was removed

BTW if you believe the PEER opcode should be limited to the query
and lifetime extension of existing implicit dynamic mappings,
putting creation and other dubious functions to further studies,
I'll jump on the table to support you (:-)! (*)

Regards

PS (*): BTW it seems I am the only implementor which really
want to support the PEER opcode, so if you don't receive
complains about some insane ideas about PEER, please ask why...

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 29 Oct 2011 15:54:09 -0400

But I believe the issue you brought up is not solved. What if the lifetime
is extended and a FIN/RST is received?

I have been back and forth with this. I believe the PCP Client sends a peer
message to extend the lifetime but has no way of knowing when the connection
will actually end. It could be 1s second from now due to user intervention
or server RST, or 1 day from now. Therefore it is just a educated guess from
the part of the client. Keeping the connection after TCP FIN/RST is received
might serve no purpose.

On the other hand is there such a case where a client/server terminates a
connection and expects the exact same session to be in the NAT after
sometime? I mean it might not even be able to get the same source port on
the host it is running so I wonder about it. If there is a strong use case
then the session/connection can remain for the lifetime independent of TCP
FIN/RST.

Thanks,

Reinaldo

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Oct 2011 17:08:27 +0100

=> I trust you for the language improvements but there is something
which needs discussion in your proposed changes:

   @@ -855,7 +855,9 @@

=> to summary you propose to change:

   When attempting to contact a PCP server, the PCP client initializes a
   timer to 2 seconds.  The PCP client sends a PCP message to the first
   server in its list of PCP servers.  If no response is received before
   the timer expires, the timer is doubled (to 4 seconds) and the
   request is re-transmitted.  If no response is received before the
   timer expires, the timer is doubled again (to 8 seconds) and the
   request is re-transmitted.

into:

   When attempting to contact a PCP server, the PCP client initializes a
   timer to 2 seconds.  The PCP client sends a PCP message to the first
   server in its list of PCP servers.  If no response is received before
   the timer expires, the timer is doubled (to 4 seconds) and the
   request is re-transmitted.  If no response is received before the
   timer expires, the timer is doubled again (to 8 seconds) and the
   request is re-transmitted again, and so on, up to a maximum
   retransmission interval of fifteen minutes, at which point the PCP
   request is re-transmitted once every fifteen minutes until it is
   sucessfully answered.

to summary we come from a 0s, 2s, 4s, 8s then give up scheme to a
0s, 2s, 4s, 8s, 16s, 32s, 1mn04s, 2mn08s, 4mn16s, 8mn32s, 15mn,
15mn, ..., forever scheme, putting the responsability of an optional
final failure report to the application.

This is a big change and IMHO we must discuss it first to understand
if it is want we want.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Oct 2011 17:15:12 +0100

(about the epoch checks)

=> if we add this (and I think it is a good idea) we have to add first
a requirement about the client clock which must not go backward
(and in this case IMHO one should directly consider the epoch as
invalid).

Thanks

PS: I propose to add it in the condition in:

      *  If the current PCP server Epoch time value
         (current_server_time) is less than the previously received PCP
         server Epoch time value (previous_server_time) then the client
         treats the Epoch time value as obviously invalid (time should
         not go backwards), else

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Oct 2011 17:26:03 +0100

@@ -1964,8 +1966,9 @@

=> I disagree: the Internal Address should be compared in all cases,
i.e., I am in favor to keep the original wording which is simpler.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Oct 2011 17:39:14 +0100

@@ -2022,8 +2024,13 @@
   
=> I strongly oppose to this change: we don't know what the user
wants, a priori (s)he should never ask for an explicit dynamic mapping
when a static mapping already exists first... So the right thing is to
return an easy to recognize condition with the infos, this is what is
specified here, and what to do next must be left to the user (i.e.,
(s)he can do what you suggest or something very different, anyway
you could not solve by a program a condition which requires a manual
action).

Regards

PS: there are at least two other ways to handle the condition which
are IMHO more likely than the one you want to recommend:
 - delete the static mapping and retry with PCP
 - give up on PCP as the mapping is already installed

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Oct 2011 17:41:41 +0100

@@ -2455,7 +2462,7 @@

=> for the same reason than in the MAP case IMHO we must keep
the original and simpler wording.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Oct 2011 17:51:58 +0100

=> I disagree about 'is not an error' because it depends on the
service users expect. To avoid another long and sterile discussion I
suggest to only soften the wording, for instance 'not always an error'
or 'not a priori an error', etc.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Oct 2011 17:55:17 +0100

@@ -3119,15 +3133,15 @@

=> I have a problem here as on one side the names of the fields
are *Suggested* External Address and Port, on the other side
they are not suggested but really *Requested* because of the
implicit PREFER_FAILURE semantics...

Regards

---

From: james woodyatt <[email-masked]>
Date: Mon, 31 Oct 2011 10:04:46 -0700

On Oct 30, 2011, at 9:55 AM, Francis Dupont wrote:
> 
> I have a problem here as on one side the names of the fields are *Suggested* External Address and Port, on the other side they are not suggested but really *Requested* because of the implicit PREFER_FAILURE semantics...

You're right.  Every standard transport protocol that uses 16-bit port numbers, with the singular exception of SCTP, admits network address-port translation that floats the port number.  SCTP is unique among standard transports in that it was designed with a mechanism, i.e. the verification tag, to facilitate address amplification by network address translators without requiring the port number to float.

So, yes... the implicit PREFER_FAILURE sematics also imply that, in the special case of SCTP, the fields are sematically equivalent to Internal/External Port and Suggested External Address.  That said, I fail to see how leaving this implication for the reader to infer could lead to an ambiguous interpretation of the base specification.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Oct 2011 17:09:13 +0000

Francis Dupont wrote (responding to Stuart):
> => I trust you for the language improvements but there is something which
> needs discussion in your proposed changes:
> 
>    @@ -855,7 +855,9 @@
> to summary we come from a 0s, 2s, 4s, 8s then give up scheme to a 0s, 2s, 4s,
> 8s, 16s, 32s, 1mn04s, 2mn08s, 4mn16s, 8mn32s, 15mn, 15mn, ..., forever
> scheme, putting the responsability of an optional final failure report to the
> application.
> 
> This is a big change and IMHO we must discuss it first to understand if it is want
> we want.

I agree with Stuart's proposed change (the main point of which is to keep
retrying rather than give up).

-Dave