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

No, RFC 3925 vendor options were carefully designed to comply with 3396. They can be split and concentenated.

For your draft you want the multiple instances NOT to be concatenated at least as I understand it. This is so you can tell there are 2 PCP servers, not just one with multiple addresses, if two PCP options are present.

For example if client receives two options:
PCP option with 10.1.1.1 and 10.1.1.2
PCP option with 10.2.2.2

You want that treated as two separate servers, not as a concatenated option of:
PCP option with 10.1.1.1, 10.1.1.2, 10.2.2.2
Which is what would happen if 3396 was applied by a client.

- Bernie (from iPad)

> On Mar 19, 2014, at 5:26 AM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:
> 
> Hi Bernie,
> 
> Thanks for the comments.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Bernie Volz (volz) [mailto:volz@cisco.com]
>> 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:dhcwg-bounces@ietf.org] 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
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg