Re: [pcp] WG last call on draft-ietf-pcp-base-16.txt

[Stuart Cheshire <[e-mail]>]

On 21 Oct 2011, at 12:34 PM, Alain Durand wrote:

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

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 <[e-mail]>
* 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>