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

[David Hankins <[e-mail]>]

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

On Thu, Aug 11, 2011 at 1:16 AM, Jiangsheng <[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.