Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

[<[e-mail]>]

Hi Bernie,

Thanks for the comments.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Bernie Volz (volz) [mailto:[e-mail]]
>Envoyé : mardi 18 mars 2014 23:12
>À : Ted Lemon; DHC WG
>Cc : BOUCADAIR Mohamed IMT/OLN; Reinaldo Penno (repenno); Dan Wing (dwing)
>Objet : RE: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section
>5.
>
>Hi:
>
>If we are to allow this (multiple instances of the same option), I think it
>would be prudent to clarify that RFC 3396 does NOT apply for this option
>for DHCPv4.
I think this is the first option we have that cannot use this?
[Med] This is not new, RFC3925 allows to send multiple instances of the same option.

>(I'm not sure 3396 was even prepared for this situation, but I could be
>wrong.)
[Med] RFC3396 says the following: 

"   This specification also applies in any case where a DHCP protocol
   agent has received a DHCP packet that contains more than one instance
   of an option of a given type.  In this case, the agent MUST
   concatenate these separate instances of the same option in the way
   that we specify here."

I guess this text covers the case of this draft. No?

If my interpretation is correct, then the following text can be added to the draft:

  " The OPTION_PCP_SERVER DHCPv4 option is a concatenation-requiring
   option.  As such, the mechanism specified in [RFC3396] MUST be used
   if the OPTION_PCP_SERVER option exceeds the maximum DHCPv4 option size
   of 255 octets."

>
>This will place special requirements on both servers and clients (servers
>not to split, clients not to combine).
>
>Note that http://www.arkko.com/tools/allstats/citations-rfc3396.html is
>useful to see which options are defined to be concatenation-requiring
>options.
>
>
>For DHCPv6, this is less of an issue but certainly again an unusual (the
>first?) case - excepting IA_*, IAADDR/IAPREFIX, and vendor options.
>
>(I would hope the PCP WG has a sufficiently strong motivation for needing
>these multiple PCP server instances.)
[Med] The context is the following: multiple PCP servers can be configured to a PCP client; each of these server can have one or multiple IP addresses. The indication whether the set of addresses belong to the same pcp server or distinct one is import for the PCP server selection procedure.

>
>For DHCPv6, it is also a bit odd to have:
>
>   If an IPv4 address is retrieved by
>   the DHCPv6 server, the corresponding IPv4-mapped IPv6 address is
>   included in the OPTION_PCP_SERVER DHPCv6 option.
>
>(BTW: Note the typo here - DHPCv6?)
[Med] It is DHCPv6 indeed. The motivation text is provided in the draft:

     " Discussion: The motivation for this design is to accommodate
      deployment cases where an IPv4 connectivity service is provided
      while only DHPCv6 is in use (e.g., an IPv4-only PCP server in a
      DS-Lite context [RFC6333])."

>
>- Bernie
>
>-----Original Message-----
>From: dhcwg [mailto:[e-mail]] On Behalf Of Ted Lemon
>Sent: Tuesday, March 18, 2014 12:06 PM
>To: DHC WG
>Subject: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.
>
>I've requested an IETF Last call on this document, so now's the time for
>any last tweaks.   I mention section 5 because the way it uses distinct
>options of the same type seems innovative and possibly not ideal.
>
>https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/
>
>Thanks!
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg