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

From: David Hankins <[email-masked]>
Date: Sat, 1 Oct 2011 21:45:44 -0700

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

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

---

From: David Hankins <[email-masked]>
Date: Sat, 1 Oct 2011 22:08:42 -0700

> same option spaces.  "Anywhere in the packet" is nice and simple, but very

I tell a lie, the "Clients Request their Options" section gives advice not
to rely on any ordering unless in the most dire of circumstance.

The discussion does go along with ORO/PRL, since there can be an expectation
that the ORO/PRL order leads to packet ordering.

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

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 08 Oct 2011 07:16:53 +0000

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:[email-masked]]
Sent: Sunday, October 02, 2011 12:46 PM
To: Sheng Jiang
Cc: dhc WG
Subject: Re: [dhcwg] Review of draft-ietf-dhc-option-guidelines

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

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.

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.

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.

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.

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

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?

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.

---

From: Tomasz Mrugalski <[email-masked]>
Date: Sat, 08 Oct 2011 09:36:52 +0200

> Still two points below.
Just a small comment about one of them.
> 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.
In RFC6334 we decided to go with FQDN after very lengthy discussion. See
various posts about this on Softwire list if you are insterested in
details. Both approaches has their merits and drawbacks. Generalizing
this as "always prefer FQDN" or "always prefer address" would not be
appropriate. I would recommend something like "prefer address, unless
FQDN benefits are really needed".

Also, where did read that draft-ietf-mif-dhcpv6-route-option suggest
FQDN? All options defined there contain only addresses. Is there any
text that suggest otherwise? If that is so, please point it out and I'll
clarify the text.

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

Cheers,
Tomek

---

From: David Hankins <[email-masked]>
Date: Mon, 10 Oct 2011 17:53:41 -0700

I believe the only text that refers to the preference of FQDN or binary IP
address is in Section 9 ("Option Size"):

   So in either protocol, it is advantageous to prefer option formats
   which contain the desired information in the smallest form factor
   that solves the requirements.  One example is to use a 4-octet IPv4
   address rather than a fully qualified domain name, because many DHCP
   servers will perform DNS resolution on configured FQDN's (so the DNS
   recursive lookup is performed anyway).  There may be motivations to
   use the fully qualified domain name anyway, such as if the intended
   RRSET is not an address, or if the client must refresh the name more
   frequently than common lease renewal periods.

If anyone thinks this is overzealously leaning towards FQDN over binary
addresses, or could use different exceptional examples, please suggest text.
 I considered, but was unable to find a language that seemed polite (not
condescending) to cover the recent use-cases of FQDN in DHCPv6 we have seen;
namely, to use DNS as a protocol to negotiate configuration between separate
administrative domains.

There is a very hard limit on DHCPv4 option space available.  Pointing out
the level of protocol waste that would be required to support the use of DNS
as a administrative-domain-bridge is hopefully poignant and helpful to those
embroiled in such debates.  With DHCPv6, I feel like there's not much more
to say than "Try for the best."

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