Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines

[Sheng Jiang <[e-mail]>]

Hi, David,

See your new version that had incorporated my comments. Thanks. Some of them are only my personal understanding, your explanation of your intending in the mail are good enough for me.

Still two points below.

Sheng> 1. Separating DHCPv4 and DHCPv6 would make the discussion more explicitly and targeting right readers. Say, one who is designing a new DHCPv6 option would not care how this may relevant to a DHCPv4 option.

David> I agree, but I don't really have the time to separate the draft. :(

If you also prefer separated documents. I can help. :)

Sheng> 12. That the address is better than FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 address in many recent DHCPv6 option design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and may benefit in load-balance scenarios.

David> I don't agree.  The FQDN has been selected in recent work despite that it is technically inferior. The entirely non-technical motivations for those decisions will continue to over-rule any guidelines we set here.

I won't say FQDN is always better than address. But it does have some technical advantages: better for load balancing, single failure, redundancy, etc, although its better readability may not important in machine world.

Best regards,

Sheng


From: David Hankins [mailto:[e-mail]]
Sent: Sunday, October 02, 2011 12:46 PM
To: Sheng Jiang
Cc: dhc WG
Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines

I'm finally getting time to work on this again...

On Thu, Aug 11, 2011 at 1:16 AM, Jiangsheng <[e-mail]<mailto:[e-mail]>> wrote:
As agreed in the IETF 81 meeting, I have reviewed draft-ietf-dhc-option-guidelines and have below comments.

Overall, this guideline is very useful. If it was published, it should be recommended in DHC WG charter page.

1. The very first and maybe the most important comment is: it is better to separate DHCPv4 and DHCPv6. It means we should have two dedicated drafts for DHCPv4 and DHCPv6. DHCPv4 and DHCPv6 are similar, but two different protocols. Some of discussions may be common between them, some of discussion may have very different base. Combining this discussion may harmful. Section 9, "option size" is an example. The option size requirements for DHCPv4 and DHCPv6 are different.

Separating them would make the discussion more explicitly and targeting right readers. Say, one who is designing a new DHCPv6 option would not care how this may relevant to a DHCPv4 option.

Furthermore, if DHCPv4 option space has freeze or will freeze, guidelines for new DHCPv4 option may be meaningless.

I agree, but I don't really have the time to separate the draft. :(

2. In the introduction section, this draft mentioned support for unknown options. It is unclear for me, at least from the draft contents, how this can happen? It may be possible to add new option at the server side, how the client support it?

The ISC DHCP client and server share the same mechanism described in the Appendix.

My understanding of the Windows DHCP client is that it stores a copy of anything it receives in the registry and applications that require or support a new option will fetch it there.  Unfortunately, my memory is that there isn't a way to add the option to the PRL.  The dhcpinform-clarify draft documents for example the behavior of the Industry Updater ("Windows Updates"), which tickles the DHCP client to send a new set of DHCPINFORMs requesting option 252 - an option not supported (or not requested) by the base DHCP client, but desired by the Industry Updater.

The Solaris client, if memory serves, has an extensive configuration in /etc/dhcp.  Operators can manipulate the parameter request list, and have it request new options.  Again these are stored in a place with a consistent format so the operator's tools can fetch values.

More frequently however this feature is most useful to the DHCP Server operator, as you have indicated.

3. The section 2, "when to use DHCP" does not mentioned "IP address configuration", which is the most important usage of DHCP. Unless this text is dedicate for new DHCP option (the current text does not claim so), IP address configuration should be added.

Well, the section was intended to help with the situation where you have a specified problem, and you are asking if DHCP should be used in the solution.  Certainly, IP addressing is already handled, but so too should it be appropriate to resolve new addressing problems with DHCP.

I tried to provide the generic answer to that question - "any knob, dial, or slider", and only list some examples.  It isn't meant to be a complete list.  I certainly think "my IP address" counts as host configuration.

Do you think the current text is acceptable?

4. Disagree on the order of "when to use DHCP". The current text suggests using DHCP is first because client want information. But, in my understanding, network administration want to push/enforce some configuration is the most important requirements.

The order isn't intended to convey importance...but I think they are of equal importance actually.

It's certainly true that in some cases clients only have a knob because administrators want to be able to set it.  But I don't think for most new options that that is always the case; usually some new protocol or client feature needs a conveyance for configuration state.

5. The draft states, in section 2, "the client still reserves the right to ignore values received via DHCP". That's right. But this may be at their own risk to be rejected by network administration. This kind of observation should also mentioned. Otherwise, the above next may be misleading: client can ignore DHCP configuration without any effect.

This section is specifically trying to answer the question of whether it's appropriate to use DHCP for a particular problem statement.  I don't want to get encumbered in the minutiae of protocol implementation...

The specific problem we've had with objection to using DHCP in a few cases is "we don't want to use DHCP for new protocol X, because I (an IETF attendee) want to be able to configure my laptop myself."

If the protocol workers are quite happy being configured by the network administrator, that is already a solved problem.

6. At the end of section 4, there are some rules how to organize values in the option. There should be more, such as the order of fixed size values, the order of multiple variable sized values.

I don't think there are any current best practices.  We don't sweat micro alignment for particular integer lengths (and it'll be ruined by other options in the payload anyway).

However I think the language is a bit stilted for variable length options.  In DHCPv4 the main variable length options would simply use the rest of the option data.  In DHCPv6 there are some variable length formats.

So there are a few things we've seen that we're trying to avoid.

The first is defining 6 options for one protocol (which is hard on DHCPv4), where the client would request all 6 all the time.

The second was an option I recall that wanted to use a NVT ascii string, followed by a zero byte (NULL value), followed by various fixed length values.  The NULL in this case wastes an octet, purely because of ordering, and complicates client parsing (there's no support for such a thing in most software).

7. section 5, using the conclusion as title can be more explicit: "avoid conditional formatting". This also looks like the title of section 6.

Done.

8. the title of section 6 has a typo: avoid alciasing/aliasing

I don't know if I already fixed this, but it's fixed in my xml copy.

9. "in the case where the server is configured with all formats, DHCP option space is wasted on option contents that are redundant". This is not necessary true - usage of sub-option can reduce the dhcp option type to be only 1. Although the usage of sub-option is not recommended in the next section. The readers may have question here. Suggest to add one sentence for sub-option and refer to next section.

So, here I think we are talking about an unfortunately overloaded terminology.

The "options space" in the DHCPv4 packet (the area after the BOOTP header) is here referred to as the options space.

The text isn't referring to the DHCPv4 option code space. :(

10. Title of section 7 is misleading. It looks like it will introduce several new formats in this section. Suggest to change as "consideration on creating new formats".

Good point, it's now "Considerations for Creating New Formats".

11. in Section 9, the discussion regarding to DHCPv6 cannot draw the conclusion "prefer option formats...in the SMALLEST form factor". Be clear, I do agree the conclusion, but not the analysis.

Do you think it is possible to describe a specific upper fixed limit for DHCPv6 in all deployments?

I don't see how the conclusion isn't supported by the evidence.

12. That the address is better than FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 address in many recent DHCPv6 option design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and may benefit in load-balance scenarios.

I don't agree.  The FQDN has been selected in recent work despite that it is technically inferior.

The entirely non-technical motivations for those decisions will continue to over-rule any guidelines we set here.

13. This draft says nothing about option orders, which is also important. The principle should be not give any specific order when design a new DHCP option. The option should be allowed to appear any place in the DHCP message. The only exception is security option(s). They need to perform algorithm over all other options. They may be allowed to located at the end.

It gets very hard to write concise language here, since the DHCPv6 style of options is for options to contain options whose codes are taken from the same option spaces.  "Anywhere in the packet" is nice and simple, but very wrong in DHCPv6.

14. draft-ietf-dhc-secure-dhcpv6 should be mentioned in the security consideration section. If it deployed, some threats, like man-in-middle can be prevented since it introduced an data integrity protection for DHCPv6 messages.

Are option contents authors going to format their options differently from this information?

Mostly, I'd prefer not to gate publication of the draft on the publication of another draft.

15. The text regarding to fixed/variable length options in security consideration section looks mis-located for me. They are not security relevant.

Buffer overflows are security problems, especially since most DHCP client software is run by the system's super-user (or in simple firmware, having no user separation).  An author of a DHCP option draft would do well to try to think about how they can word the presentation of their option to enhance an implementor's wariness of buffer overruns.

--
David W. Hankins
SRE - Systems Engineer
Google, Inc.