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

From: Stuart Cheshire <[email-masked]>
Date: Mon, 31 Oct 2011 18:12:25 -0700

I just submitted draft-ietf-pcp-base-17.

This incorporates the changes from the one-week Working Group Last Call.

I only just got it in by 5pm, and a couple of minor changes,  
described below, didn't make it. These are checked in to the  
Subversion repository but did not make it into the draft-ietf-pcp- 
base-17 submission.

The changes cued up for draft-ietf-pcp-base-18 are:

1. Clarification requested by Francis Dupont:

> 7.3.  General PCP Client: Processing a Response
>
>    The PCP client receives the response and verifies that the  
> source IP
>    address and port belong to the PCP server of an outstanding PCP
>    request.  If not, the response is silently dropped.
>
>    If the received PCP response message is less than four octets  
> long it
>    is silently dropped.
>
>    If the R bit is clear the message is silently dropped.
>
>    If the error code is UNSUPP_VERSION processing continues as  
> described
>    in Section 7.7
>
>    ...

2. Dave Thaler asked for an explanation of why Rapid Recovery uses  
port 5350:

>    Note: The reason that server-to-client restart announcements use a
>    port (5350) that's different from the client-to-server request port
>    (5351) is for pragmatic implementation reasons.  A single device  
> may
>    have multiple roles.  A multi-function home gateway may also  
> provide
>    printer sharing.  A home computer may also provide "Internet  
> Sharing"
>    (NAT) functionality.  Such devices need to act as both a PCP Server
>    and a PCP Client at the same time, and the software that implements
>    the PCP Server on the device may not be the same software component
>    that implements the PCP Client.
>
>    o  The software that implements the PCP Server needs to listen for
>       unicast client requests.
>
>    o  The software that implements the PCP Client needs to listen for
>       multicast Rapid Recovery restart announcements.
>
>    In most networking APIs is is difficult or impossible to have two
>    independent clients listening for both unicasts and multicasts  
> on the
>    same port at the same time.  For this reason it makes sense to  
> have:
>
>    o  A single PCP Server listening for unicast client requests on  
> port
>       5351, and
>
>    o  Zero, one, or more independent PCP Clients listening (using
>       SO_REUSEPORT or equivalent) for multicast restart  
> announcements on
>       port 5350.

That is all for now.

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