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

To support 3396, you will likely have to encode the DHCPv4 PCP option as:

	Option Code
	Length of option
	Length of PCP server 1
	IPv4 address(es) based on length of PCP server 1
	<Repeat the following as often as needed>
	Optional length of PCP server n
	     IPv4 address(es) based on PCP server n

So, the 2 PCP servers mentioned below would be encoded as (each line is a byte unless otherwise indicated):

	<PCP Option Code>
	<Length = 1 + 4 + 4 + 1 + 4>
	8 (Length of PCP server 1)
	4 bytes address - 10.1.1.1
	4 bytes address - 10.1.1.2
	4 (Length of PCP server 2)
	4 bytes address - 10.2.2.2

This can be split and there is only ONE instance of the option, but there can be multiple sub-instances.

This would be compatible with what RFC 3925 does.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, March 19, 2014 7:39 AM
To: mohamed.boucadair@orange.com
Cc: DHC WG; Ted Lemon
Subject: 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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg