Subject: [pcp] draft-ietf-pcp-base-24

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Mar 2012 17:03:10 -0700

Hi, everyone.

Yesterday I submitted draft-ietf-pcp-base-24, which I believe resolves the
DISCUSS and COMMENTS from IESG members,
https://datatracker.ietf.org/doc/draft-ietf-pcp-base/ballot, as well as
reviews from TSV, SEC, and APP directorate, and comments on the PCP mailing
list.  The changes are summarized in
http://tools.ietf.org/html/draft-ietf-pcp-base-24#appendix-B.1 (and copied
below), and side-by-side differences from -23 are available at
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-24.txt

Please review the changes.  I know the list of changes is long, but few of
the changes are normative changes to the protocol itself.

One additional change, which did not make it to -24, will be clarification
of port 5350 versus port 5351 usage when the server sends unsolicited
ANNOUNCE message.  These are always sent to port 5351.  (Version -23 and -24
has conflicting text about the port when the server sends unsolicited
unicast versus multicast ANNOUNCE message).  Thanks to Ralph Droms for
catching that during his IESG review.  This change will be published in -25,
if we publish one, or will be incorporated when the RFC Editor does their
editing.

-d

-----

   o  Explained common questions regarding PCP's design, such as lack of
      transction identifiers and its request/response semantics and
      operation (Protocol Design Note (Section 6)).

   o  added MUST for all-zeros IPv6 and IPv4 address formats.

   o  included field definitions for Opcode-specific information and PCP
      options under both Figure 2 and Figure 3.

   o  adopted retransmission mechanism from DHCPv6.

   o  1024 message size limit described in PCP message restriction.

   o  Explained PCP server list, with example of host with IPv4 and IPv6
      addresses having two PCP servers (one IPv4 PCP server for IPv4
      mappings and one IPv6 PCP server for IPv6 mappings).

   o  mention PCP client needs to expect unsolicited PCP responses from
      previous incarnations of itself (on the same host) or of this host
      (using same IP address as another PCP client).

   o  eliminated overuse of 'packet format' when it was 'opcode format'.

   o  for IANA registries, added code points assignable via Standards
      Action (previously was just Specification Required).

   o  Version negotiation, added explanation that retrying after 30
      minutes makes the protocol self-healing if the PCP server is
      upgraded.

   o  Version negotiation now accomodates non-contiguous version
      numbers.

   o  Tweaked definition of VERSION field (that "1" is for this version,
      but other values could of course appear in the future).

   o  when receiving unsolicited ANNOUNCE, PCP client now waits random
      0-5 seconds.

   o  Removed 'interworking function' from list of terminology because
      we no longer use the term in this document.

   o  tightened definitions of 'PCP client' and 'PCP server'.

   o  For 'Requested Lifetime' definitions, removed text requiring its
      value be 0 for not-yet-defined opcodes.

   o  Removed some unnecessary text suggesting logging (is an
      implementation detail).

   o  Added active-mode FTP as example protocol that can break with
      mappings to different IP addresses.

   o  Clarified that if PCP request contains a Suggested External
      Address, the PCP server should try to create a mapping to that
      address even if other mappings already exist to a different
      external address.

   o  Changed "internal address and port" to "internal address,
      protocol, and port" in several places.

   o  Clarified which 96 bits are copied into error response.  Clarified
      that only error responses are copied verbatim from request.

   o  a single PCP server can control multiple NATs or multiple
      firewalls (Section 4).

   o  Clarified that sending unsolicited multicast ANNOUNCE is not
      always available on all networks.

   o  Clarified option length error example is when option length
      exceeds UDP length

   o  Explained that an on-path attacker that can spoof packets can re-
      direct traffic to a host of their choosing.

   o  Instead of saying IPv4-mapped addresses won't appear on the wire,
      say they aren't used for mappings.

   o  THIRD_PARTY is useful for management device (e.g., in a network
      operations center).

   o  Clarified PCP responses have fields updated as indicated with 'set
      by the server' from field definitions.

   o  Disallow using MAP to the PCP ports themselves and encourage
      implementations have policy control for other ports.

   o  Instead of 'idempotent', now says 'identical requests generate
      identical response'.

   o  Described which Options are included when sending Mapping Update
      (unsolicited responses), Section 14.2.

   o  Dropped [RFC2136] and [RFC3007] to informative references.

   o  Updated from 'should' to 'SHOULD' in Section 16.1.

   o  Described 'hairpin' in terminology section.