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

From: <[email-masked]>
Date: Wed, 19 Mar 2014 10:26:48 +0100

Hi Bernie,

Thanks for the comments.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Bernie Volz (volz) [mailto:[email-masked]]
>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:[email-masked]] 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 19 Mar 2014 11:39:19 +0000

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, "[email-masked]" <[email-masked]> wrote:
> 
> Hi Bernie,
> 
> Thanks for the comments.
> 
> Please see inline.
> 
> Cheers,
> Med
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 19 Mar 2014 13:35:17 +0000

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:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, March 19, 2014 7:39 AM
To: [email-masked]
Cc: DHC WG; Ted Lemon
Subject: Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

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)

>> De : Bernie Volz (volz) [mailto:[email-masked]] 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.
>> 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.
>> 
>> 
>> (I would hope the PCP WG has a sufficiently strong motivation for 
>> needing these multiple PCP server instances.)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Mar 2014 10:46:39 -0400

> 	     IPv4 address(es) based on PCP server n

This seems like a better option than the current proposal, although if it's done this way it's still essentially defining a new fragment type, isn't it?   Do we have existing examples of this?   I would define it as "option code, length of option, address count, addresses, address count, addresses..." instead of using byte lengths, but I suppose that's a detail.

If this does define a new fragment type, that should be done in a DHC wg document.   Should be pretty simple to do.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 19 Mar 2014 15:06:23 +0000

The precedent for this is RFC 3925 (though there we have enterprise-ids).

I think the address count is a bad idea, as we've used length everywhere else so best to continue that practice.

The option-guidelines document is primarily for DHCPv6, though of course the basic concepts should apply to DHCPv4 as well.

- Bernie

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Mar 2014 11:19:32 -0400

> 	     IPv4 address(es) based on PCP server n

As far as I can tell, there's no way to define this as a custom option
on ISC DHCP, whether using lengths or address counts. Just a data point.

Basically we would want this:

option pcp-server code xxx = array of array of ip-address;

But arrays of arrays seem to not be supported. :(

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Mar 2014 13:29:47 -0400

> But arrays of arrays seem to not be supported. :(

It's a simple matter of programming... :)

(Seriously, it wouldn't be very hard to get it working.)

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Mar 2014 13:43:52 -0400

> (Seriously, it wouldn't be very hard to get it working.)

Sure. As I said, just a data point. Everything else being equal, it
would be nice if no programming was necessary.

Simon

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 19 Mar 2014 17:47:41 +0000

Does ISC support you configuring multiple instances of the same option as was the original document's plan? And, will it put all of these instances into the packet?

I know there are servers that DON'T support this because there was never a requirement for it.

So, I think this argument/data point is useless *if* this requirement for multiple "instances" exists. Likely if this was a string and used some special string syntax (comma separated addresses with some other delimiter between instances) then it could be supported. But IN *NO* WAY am I suggesting that.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Wednesday, March 19, 2014 1:44 PM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

> (Seriously, it wouldn't be very hard to get it working.)

Sure. As I said, just a data point. Everything else being equal, it would be nice if no programming was necessary.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Mar 2014 13:50:42 -0400

> would be nice if no programming was necessary.

Given that no standard currently recommends similar behavior, it seems like a bad idea to define a new DHCP feature just because it happens to work in some code base (if, indeed, it does).   It would be better to decide what the right design is and make the minor code changes to support it if necessary.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Mar 2014 13:55:41 -0400

> Given that no standard currently recommends similar behavior, it seems like a bad idea to define a new DHCP feature just because it happens to work in some code base (if, indeed, it does).   It wou…

Fully agreed.

I'll try to be even clearer: *everything else being equal*, it's nice
when no programming is needed. If nobody can come up with a clever
solution that allows us to have our cake and eat it too, then that's the
end of the story. I'm not asking that we restrict ourselves to what is
doable without programming.

It was just a data point... *sigh*

Simon

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Mar 2014 14:06:49 -0400

> It was just a data point... *sigh*

Of course, sorry if the response seemed harsh.   That wasn't my intention.   I am curious whether the code in fact does work as advertised, though—back when I implemented RFC 3396 in the ISC code base, it definitely didn't, but I didn't do the DHCPv6 implementation, so perhaps that does work as you suggest.

It's perhaps important to point out that 3396 didn't change the status quo from one defined state to another; what it did was to change the status quo from an undefined state to a defined state.   Prior to 3396, we simply hadn't specified how multiple options of the same type would be handled, so it was left up to the implementation. 

The ISC implementation never supported sending multiple options of the same type, nor processing them—there was only one place in the data structure for each option type.  (This is based on a ten-year-old recollection, so it's possible I'm mistaken).

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Mar 2014 14:32:09 -0400

> The ISC implementation never supported sending multiple options of the same type, nor processing them—there was only one place in the data structure for each option type.  (This is based on a ten-y…

Ah, I got your point now. Thanks for insisting.

The dhcp-options man page says: "Whereas in DHCPv4 multiple options
would be concatenated to form one option, in DHCPv6 they are expected to
be individual instantiations."

So it seems we are contemplating two alternatives that would not be
doable today on ISC without at least some programming.

Still, Bernie's suggestion appears to require substantially less
programming: implementing an "array of arrays of addresses" option value
type could be much simpler than changing the server's option
concatenation behaviour.

Simon

---

From: <[email-masked]>
Date: Thu, 20 Mar 2014 07:50:26 +0100

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

>Envoyé : mercredi 19 mars 2014 14:35
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : DHC WG; Ted Lemon
>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.
>
>> [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.
>>
>>>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Mar 2014 07:33:56 -0400

> 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. 

It just doesn't help, because RFC2131 doesn't forbid the behavior described in RFC 3396, nor recommend the behavior that this draft depends on.   So you are assuming a feature is present in DHCP servers and clients that was never present except possibly by accident.

I apologize for not catching this sooner—I've read the draft a number of times and didn't register this until the AD review, which is why I asked the DHC working group to look at it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Mar 2014 12:05:44 +0000

I would not like to go that route for v4. I think you should use a 3369 friendly encoding.

- Bernie (from iPad)

> On Mar 20, 2014, at 2:50 AM, "[email-masked]" <[email-masked]> wrote:
> 
> Hi Bernie,
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Mar 2014 13:29:38 +0000

FYI - Adding back dhcwg as I think this is important to keep there.

The only issue with DHCPv6 multiple options is the ordering - if ordering is important, you should not use them. In the PCP case, I don't see that ordering matters as the draft requires using each of them.

DHCPv6 clients and servers already have to deal with multiple instances of the same option so I don't think there are any significant issues here. (Whereas in DHCPv4, that has not been the case to date, so that's why there is more significant concern.)

The guidelines are:

   DHCPv6 does allow for multiple instances of a given option, and they
   are treated as distinct values following the defined format, however
   this feature is generally preferred to be restricted to protocol
   class features (such as the IA_* series of options).  In such cases,
   it is better to define an option as an array if it is possible.  It
   is recommended to clarify (with normative language) whether a given
   DHCPv6 option may appear once or multiple times.  The default
   assumption is only once.

...

16.  Singleton options

   Although [RFC3315] states that each option type MAY appear more than
   once, the original idea was that multiple instances are reserved for
   stateful options, like IA_NA or IA_PD.  For most other options it is
   usually expected that they will appear at most once.  Such options
   are called singleton options.  Sadly, RFCs have often failed to
   clearly specify whether a given option can appear more than once or
   not.

   Documents that define new options SHOULD state whether these options
   are singletons or not.  Unless otherwise specified, newly defined
   options are considered to be singletons.  If multiple instances are
   allowed, the document MUST explain how to use them.  Care should be
   taken to not assume the they will be processed in the order they
   appear in the message.  See Section 17 for more details.

(There's more in section 17.)

I don't really care that much which we go as I think either will require code changes in some (or most) clients and servers (servers may readily support configuring multiple instances of the options and probably don't support the <sub-length><address(es)> encoding either).

Personally, I don't see a problem with multiple instances of the options as that is the way DHCPv6 was designed. Again, the only issue is ordering (since this would require specialized handling on the server configuration to allow you to define the order). For clients, order might also be an issues in how they store the data (i.e., if lists are maintained, is a new instances inserted at start or end of list).

I WOULD like to see multiple instances of options used in the way PCP proposed - i.e., where there really are more than one thing a client needs to do RATHER than alternative values (i.e., list of addresses to contact for an instance). This is in keeping how we currently handle things like the DNS server address list and domain search list.

While we could encode this as proposed for DHCPv4, I also see no need to encode it that way for this particular usage.

I guess we need to get some rough consensus here as to what the DHC WG would prefer as this will set a precedence. So it would be great for others to chime in. (Note that my comments on this entire thread are to be taken as an individual with WG co-chair hat off.)

Again, my feeling is that when order is required or when there are a list of 'equal' values (i.e., try one or more of these addresses to reach a service), we should use a single option. When there are possibly multiple items that ALL must be used (simultaneously and there is no order importance), multiple options would be fine. This is exactly how IA_* and IAADDR/IAPREFIX and the multiple vendor options instances all work.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, March 20, 2014 9:07 AM
To: [email-masked]
Cc: Bernie Volz (volz)
Subject: Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

On Mar 20, 2014, at 8:49 AM, <[email-masked]> <[email-masked]> wrote:
> Changing the format of the dhcpv4 option to be complaint with 3396 would lead to a dhcpv4 option and a dhcpv6 option that are not similar. Are you fine with that? Should we update only the dhcpv4 part of the document?

FWIW, I don't really see much value in the semantics of multiple options, and would rather see the DHCPv6 and DHCPv4 options done the same way.   It's not something that would stop me approving the document, but we did discuss this when the option guidelines draft was done, and it seemed that there was strong skepticism, which I _think_ was expressed in the draft, about giving semantic meaning to the presence of multiple options.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Mar 2014 13:52:28 +0000

BTW: One nice thing to consider for the DHCPv6 multiple option instances design is that at least for the single PCP instance case, it would work immediately (on all DHCPv6 clients and servers).

I don't know how common it will be for there to be multiple PCP servers that clients need to contact.

(The downside with this is of course that few may implement the multiple PCP servers support unless it is widely required?)

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Thursday, March 20, 2014 9:30 AM
To: 'Ted Lemon'; [email-masked]
Cc: [email-masked]
Subject: RE: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

The guidelines are:

...

16.  Singleton options

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Mar 2014 10:19:06 -0400

Thanks for doing the research and reasoning it through, Bernie.   I can live with the solution you've proposed, and I do see your point about code changes.