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

[<[e-mail]>]

Hi Bernie,

This seems like the format described in a previous version of the draft: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-06#section-4.1 (s/name/address(es)).  

Is it problematic if we declare the design in the draft as being not compatible with RFC3369? RFC3396 indicates that specification requiring 3396 must explicit it in their specs. 

Cheers,
Med

>-----Message d'origine-----
>De : Bernie Volz (volz) [mailto:[e-mail]]
>Envoyé : mercredi 19 mars 2014 14:35
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : DHC WG; Ted Lemon
>Objet : 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:[e-mail]] On Behalf Of Bernie Volz (volz)
>Sent: Wednesday, March 19, 2014 7:39 AM
>To: [e-mail]
>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, "[e-mail]"
><[e-mail]> wrote:
>>
>> 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
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg