Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-01.txt

From: <[email-masked]>
Date: Thu, 1 Dec 2011 10:15:38 +0100

Dear Dave,

Below the text I added to the draft. Please review it:

(1) added a new section:

5.  IP Address Selection

   Resolving the Name conveyed in DHCP PCP Name options may return a
   list of IP addresses.  This section specifies the behavior to be
   followed by the PCP Client to contact its PCP Server.

   1.  If only one PCP Name option is returned in DHCP: the PCP Client
       follows the procedure specified in Section 5.1 if a list of IP
       addresses are returned as a result of resolving the name conveyed
       in the PCP Name DHCP option.
   2.  If several PCP Name options are returned in DHCP: the PCP Client
       contacts in parallel all PCP Servers as defined in Section 5.2.
       For each PCP Name option occurrence, the PCP Client resolves the
       conveyed name; if more than one IP address are returned, the PCP
       Client follows the procedure specified in Section 5.1.

5.1.  Serial Queries

   The PCP Client initializes its retransmission timer, RETRY_TIMER, to
   2 seconds.  The PCP Client sends its PCP message to the PCP Server
   and waits 2 seconds for a response.  If no response is received, it
   doubles the value of RETRY_TIMER, sends another (identical) PCP
   message and waits 2*RETRY_TIMER.  This procedure is repeated three
   (3) times, doubling the value of RETRY_TIMER each time.  If no
   response is received after four (4) attempts, the PCP Client tries
   with the next IP address in its list of PCP Servers.  If it has
   exhausted its list, the procedure is repeated every fifteen minutes
   until the PCP request is successfully answered.  If, when sending PCP
   requests the PCP Client receives an ICMP error (e.g., port
   unreachable, network unreachable) it SHOULD immediately try the next
   IP address in the list.  Once the PCP Client has successfully
   received a response from a PCP Server on that interface, it sends
   subsequent PCP requests to that same server until that PCP Server
   becomes non-responsive, which causes the PCP client to attempt to re-
   iterate the procedure starting with the first PCP Server on its list.

5.2.  Parallel Queries

   The PCP Client contacts in parallel all the PCP Servers in the IP
   addresses list.  For each IP address in the list, the PCP Client
   follows the procedure specified in Section 7.1 of
   [I-D.ietf-pcp-base].

(2) I tweaked the Client text behavior:

NEW:

   To discover a PCP Server [I-D.ietf-pcp-base], the DHCPv6 client MUST
   include an Option Request Option (ORO) requesting the DHCPv6 PCP
   Server Name option as described in Section 22.7 of [RFC3315] (i.e.,
   include OPTION_PCP_SERVER on its OPTION_ORO).  A client MAY also
   include the OPTION_DNS_SERVERS option on its OPTION_ORO to retrieve a
   DNS servers list.

   If the DHCPv6 client receives more than one OPTION_PCP_SERVER option
   from the DHCPv6 server, it extracts the Name conveyed in each
   OPTION_PCP_SERVER option and proceeds to validating it.  If more than
   one Name is included in a OPTION_PCP_SERVER option occurrence, only
   the first instance MUST be used.  Then, The DHCPv6 client MUST verify
   that the option length does not exceed 255 octets [RFC1035]).  The
   DHCPv6 client MUST verify the name is properly encoded as detailed in
   Section 8 of [RFC3315].

   Once the name conveyed in each OPTION_PCP_SERVER option is validated,
   the included Name is passed to the name resolution library (e.g.,
   Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the
   corresponding IP address(es) (IPv4 or IPv6).

   Then, the PCP Client follows the procedure specified in Section 5 to
   contact its PCP Server(s).

   It is RECOMMENDED to associate a TTL with any address resulting from
   resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv6 option when
   stored in a local cache.  Considerations on how to flush out a local
   cache are out of the scope of this document.

   A host may have multiple network interfaces (e.g, 3G, WiFi, etc.);
   each configured differently.  Each PCP Server learned MUST be
   associated with the interface via which it was learned.  When an
   application issues a PCP request to a PCP Server, the source address
   of the request MUST be among those assigned on the interface to which
   the destination PCP Server is bound.  Means to bind a PCP Name
   configuration to a given interface in a multiple-interface host are
   out of scope of this document.

OLD:

   To discover a PCP Server [I-D.ietf-pcp-base], the DHCPv6 client MUST
   include an Option Request Option (ORO) requesting the DHCPv6 PCP
   Server Name option as described in Section 22.7 of [RFC3315] (i.e.,
   include OPTION_PCP_SERVER on its OPTION_ORO).  A client MAY also
   include the OPTION_DNS_SERVERS option on its OPTION_ORO to retrieve a
   DNS servers list.

   If the DHCPv6 client receives more than one OPTION_PCP_SERVER option
   from the DHCPv6 server, only the first instance of that option MUST
   be used.

   Upon receipt of an OPTION_PCP_SERVER option, the DHCPv6 client MUST
   verify that the option length does not exceed 255 octets [RFC1035]).
   The DHCPv6 client MUST verify the name is properly encoded as
   detailed in Section 8 of [RFC3315].

   Once the name conveyed in a OPTION_PCP_SERVER option is validated,
   the included Name is passed to the name resolution library (e.g.,
   Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the
   corresponding IP address (IPv4 or IPv6).  If more than one IPv6/IPv4
   address are retrieved, the PCP Client MUST use the procedure defined
   in Section 5.1 for address selection.

   It is RECOMMENDED to associate a TTL with any address resulting from
   resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv6 option when
   stored in a local cache.  Considerations on how to flush out a local
   cache are out of the scope of this document.

   A host may have multiple network interfaces (e.g, 3G, WiFi, etc.);
   each configured differently.  Each PCP Server learned MUST be
   associated with the interface via which it was learned.  When an
   application issues a PCP request to a PCP Server, the source address
   of the request MUST be among those assigned on the interface to which
   the destination PCP Server is bound.  Means to bind a PCP Name
   configuration to a given interface in a multiple-interface host are
   out of scope of this document.

> -----Message d'origine-----
> De : Dave Thaler [mailto:[email-masked]] 
> Envoyé : mercredi 30 novembre 2011 19:22
> À : BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : [email-masked]
> Objet : RE: Comments on draft-ietf-pcp-dhcp-01.txt
> 
> > I don't see much difference between PEER and MAP for the PCP Server
> > discovery. As I said earlier, we have cases where you need 
> to try all servers
> > (e.g., FW, NAT64, NPTv6); this is orthogonal to MAP or PEER.
> 
> I don't follow.   PEER is with respect to a specific 
> connection (5-tuple).
> 
> I'm having trouble finding which message you refer to as 
> "said earlier",
> so would be good if you could repeat when you'd want to send a PEER
> for a single 5-tuple to all servers.
> 
> (And proposing text to be added in the document would be even 
> better...)
> 
> -Dave
> 
>