Subject: [dhcwg] I-D Action:draft-ietf-dhc-option-guidelines-01.txt

From: [email-masked]
Date: Thu, 21 Aug 2008 16:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : Guidelines for Creating New DHCP Options
	Author(s)       : D. Hankins
	Filename        : draft-ietf-dhc-option-guidelines-01.txt
	Pages           : 17
	Date            : 2008-08-21

This document seeks to provide guidance to prospective DHCP Option
authors, to help them in producing option formats that are easily
adoptable.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 21 Aug 2008 16:20:00 -0700

> http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-01.txt

Sorry this draft expired, but I'm going to resurrect it.  I have made
some minor edits in this version, several mispellings I noticed, and
one small clarification to the text about choosing ONE format when
multiple formats suggest themselves (ip/dns/url example).

If anyone has any memory of any discussions they've had with DHCP
Option authors which I've failed to include, please let me (re)know.
I'll spend some time thinking about the space a bit, and see if I can
find any suggestions I missed due to the time lapse in my mail
records, but if none of us have anything new to add we may as well
last call it.  Can always obsolete it later.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bud Millwood <[email-masked]>
Date: Thu, 21 Aug 2008 23:02:31 +0200

> > http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-01.t

Well written. Nice to see the "black magic" of DHCP options clarified for 
once.

I just read it again and had these points:

"Providing multiple different formats of the same configuration information, 
such as an IP address, name, or URL, which are all intended to provide the 
same location information, is undesirable."

-- The wording is a little confusing. Maybe something like: It is undesirable 
to provide multiple formats, such as IP address, name or URL for the same 
configuration information.

"So it is still best advice to design options to a ~500 byte payload 
limitation."

--  Where did the 500 come from?

"In both DHCP protocols, there exists as part of the protocol definition an 
option whose purpose is twofold - to inform the server..."

-- param-req-list option is introduced in the next paragraph without having 
been defined, so maybe you could define it in this paragraph like "In both 
DHCP protocols, there exists as part of the protocol definition an option, 
the parameter request list option, whose purpose is twofold:"

- Bud

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 22 Aug 2008 10:01:15 -0700

> configuration information.

That's an excellent point, I went a slightly different way with it;

  <t>Options are said to be aliases of each other if they provide input to
    the same configuration parameter.  A commonly proposed example is to
    configure the location of some new service ("my foo server") using a
    binary IP address, a domain name field, and a URL.  This kind of
    aliasing is undesirable, and is best avoided.</t>

I'm mostly trying to keep the conclusion at the end of the paragraph,
as it reinforces the ordering of the arguments and conclusion in the
following section.

> --  Where did the 500 come from?

That's a good question.  For other readers, in context this is in
regards to DHCPv6, which ostensibly happily handles 64KB packets and
fragmentation thanks to link-local addresses.

I think I planned to write down a vague number and fill in a real one
later after some discussion.  At the same time, I don't want this
phrase to become the new thing people will quote to prove DHCPv6
options are "limited to 500 bytes".  I'm just trying to say 'don't
waste space gratuitously', which actually sounds pointlessly obvious
now that I say it.

Maybe I should just remove this last sentence on that paragraph?

> the parameter request list option, whose purpose is twofold:"

I think like in your first example, this starts getting too clause-y.

So I went a different way with this again;

  <t>The <xref target="RFC2132">DHCPv4 Parameter Request List</xref>, and
    the <xref target="RFC3315">DHCPv6 Option Request Option
    (OPTION_ORO)</xref>, are both optoins that serve two purposes - to
    inform the server what option(s) the client supports and is willing to
    digest, and in what order of priority the client places those option
    contents (in the event that they will not fit in the packet, later
    options are to be dropped).</t>

I'm also thinking of adding a paragraph to the end of this section
that says;

  <t>Under only the most dire of circumstances should a new option
    definition require special ordering of options either in the relevant
    request option, or in the order of packets returned on the server's
    reply.  Although the request option does display a preferred priority,
    which implies an order, a server may shuffle options around in a DHCPv4
    packet in order to make them fit, and server software may sort DHCPv6
    options into strange orders.  There is not one universal approach.</t>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Aug 2008 13:28:06 -0400

>fragmentation thanks to link-local addresses.
 
The MTU (minimum transmission unit) for IPv6 is 1280 bytes (the value is
576 for IPv4).

RFC 3315 states in several places: "The server must be aware of the
recommendations on packet sizes and the use of fragmentation in section
5 of RFC 2460."

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Friday, August 22, 2008 1:01 PM
To: DHC WG
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-option-guidelines-01.txt

  <t>Options are said to be aliases of each other if they provide input
to

  <t>The <xref target="RFC2132">DHCPv4 Parameter Request List</xref>,
and
    the <xref target="RFC3315">DHCPv6 Option Request Option
    (OPTION_ORO)</xref>, are both optoins that serve two purposes - to
    inform the server what option(s) the client supports and is willing
to
    digest, and in what order of priority the client places those option
    contents (in the event that they will not fit in the packet, later
    options are to be dropped).</t>

  <t>Under only the most dire of circumstances should a new option
    definition require special ordering of options either in the
relevant
    request option, or in the order of packets returned on the server's
    reply.  Although the request option does display a preferred
priority,
    which implies an order, a server may shuffle options around in a
DHCPv4
    packet in order to make them fit, and server software may sort
DHCPv6
    options into strange orders.  There is not one universal
approach.</t>

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 25 Aug 2008 10:57:31 -0700

> recommendations on packet sizes and the use of fragmentation in section

I'm less concerned about server capabilities than client capabilities.

I think it's safe to say the client will perform fragment reassembly,
but I'm not sold that all clients will put away 64KB for DHCP-level
software packet buffer...particularly those in phones or such.

Anyway, I think we're both in line for just removing that sentence.  I
don't think we know what clients are going to do until after they do
it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Aug 2008 14:03:24 -0400

OK.

BTW: That statement in the server section isn't there to prevent issues
with transmission by the server, but RECEIPTION by the client. So, it is
concerned with what you are.

I think a safe assumption is that clients *SHOULD* [MUST?] accept at
least a 1280 sized MTU packet (of course, you have to subtract the IPv6
+ UDP headers from that). Anything larger is uncertain (either because
of fragmentation/reassembly failures or lack of buffer space on the
client).

Perhaps one of these days we need to consider a maximum packet size
option for v6 :(.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Monday, August 25, 2008 1:58 PM
To: DHC WG
Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-option-guidelines-01.txt

---

From: Bud Millwood <[email-masked]>
Date: Mon, 25 Aug 2008 17:37:26 +0200

> of fragmentation/reassembly failures or lack of buffer space on the

Under what circumstances could that be a SHOULD? If a server delivers a packet 
that comes in at 1280, the client is not compliant with IPv6 if it can't 
handle it, right?

- Bud

> > The MTU (minimum transmission unit) for IPv6 is 1280 bytes (the value
>
> is
>
> > 576 for IPv4).
> >
> > recommendations on packet sizes and the use of fragmentation in
>
> section
>
> > 5 of RFC 2460."
>

-- 
"The threat of madness is the price of reason" - Susanne Langer
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Aug 2008 11:10:17 -0700

>From: Bernie Volz (volz) [mailto:[email-masked]] 
>Sent: Monday, August 25, 2008 11:03 AM
>To: David W. Hankins; DHC WG

RFC2460, Section 5 says that reassembly of up to 1500 octets
is a certainty, but reassembly of anything larger is not.

Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Aug 2008 13:04:31 -0700

> software packet buffer...particularly those in phones or such.

At the same time, it's not unreasonable to expect that a properly- 
implemented client would try to read the entire packet, one way or  
another.   It's not exactly rocket science.   Not that we should  
encourage mobygrams, but neither should we encourage non-robust  
implementations by assuring implementors that packets will be small.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Aug 2008 13:06:37 -0700

> is a certainty, but reassembly of anything larger is not.

I think it's perfectly reasonable then to assert that all clients MUST  
accept at least 1500 octets (less packet headers, I guess).   The  
bizarrely small default packet size of DHCP has been a significant  
impediment on several occasions.

---

From: "H. Peter Anvin" <[email-masked]>
Date: Mon, 25 Aug 2008 15:28:08 -0700

> impediment on several occasions.

Well, it's a direct consequence of the minimum 576 datagram size of 
IPv4.  It's too small, definitely, and most implementations support 
1500.  The "too-smallness" is acerbated by the fact that DHCP is used to 
carry all kinds of network configuration information, instead of just 
enough information to connect to a network configuration server, 
presumably via TCP.

	-hpa

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 25 Aug 2008 16:14:24 -0700

On Mon, Aug 25, 2008 at 01:04:31PM -0700, Ted Lemon wrote:
> At the same time, it's not unreasonable to expect that a 
> properly-implemented client would try to read the entire packet, one way or 
> another.   It's not exactly rocket science.   Not that we should encourage 
> mobygrams, but neither should we encourage non-robust implementations by 
> assuring implementors that packets will be small.

I think in v6's case, packet size isn't the thing we should maybe be
discussing.  Which makes me wonder if I should talk about the v4 and
v6 limitations separately.

Whereas with v4 we have an obvious upper limit, which makes it even
more imperative to stick to small options, with v6 it's a much hazier
notion; "too big".  Surely anything approaching 64KB is too big.
There has to be room for some number of relay-forward encapsulations,
and space for other options.  Restricting implementations to the same
small option sizes as we do in DHCPv4 seems overzealous.

Really what we're trying to say is that if you're going to load a
whole config file, which could be arbitrarily large if the operator
forgets to stop typing, then you should use a second stage config
system and just pass a location reference.

Well, I've taken a stab at cleaning this up a bit and not writing a
different section for v6.  Here's the new paragraph replacing the
one in question (I'll post a -02 at the end of the week in case there
are more comments):

  <t><xref target="RFC3315">DHCPv6</xref> is much better off.  First,
    through its use of link-local addresses, it steps aside many of the
    deployment problems that plague DHCPv4, and looks a great deal more
    like any other UDP based application; oblivious to packet sizes up
    to 64KB.  Second, RFC3315 explicitly refers readers to RFC2460 Section
    5, which describes an MTU of 1280 octets and a minimum fragment
    reassembly of 1500 octets.  It's much more feasible to suggest that
    DHCPv6 is capable of having larger options deployed over it, and at
    least no common upper limit is yet known to have been encoded by its
    implementors.  It is impossible to describe any fixed limit that
    cleanly divides those too big from the workable.</t>

This segues into a very slightly reworded existing paragraph
describing how to prefer small option payloads when the benefit is the
same, and the use of external configuration locators.