Subject: [dhcwg] RFC2131 - option multiple times - which ones ?

From: Grubmair Peter <[email-masked]>
Date: Fri, 11 Mar 2005 10:12:15 +0100

Hi,
Thank you for your replies.
My question was much simpler:
 RFC2131 says:

   The values to be passed in an 'option' tag may be too long to fit in
   the 255 octets available to a single option (e.g., a list of routers
   in a 'router' option [21]).  Options may appear only once, unless
   otherwise specified in the options document.  The client concatenates
   the values of multiple instances of the same option into a single
   parameter list for configuration.

I interpreted it like this:
  The rule is, that a specific option may appear only once in
  a dhcp message.
  The exception from this rule is, that the option document (RFC2132 or
other)
  tells , that the option may appear multiple times.
  Then the multiple instances of the option have to be concatenated into
  one instance before interpretation.

  So I am missing in RFC2131 hints, which option may appear multiple times
and
  therefore have to be concatenated during reception(e.g. router option ?)

  I think all options using charackter strings or lists (of ip addresses)
may
  be split during send and have to be concatenated during reception
 , but RFC2132 tells nothing about this.

Best regards
  Peter

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 11 Mar 2005 11:33:02 -0500

Don't forget RFC 3396:

Abstract

   This document specifies the processing rules for Dynamic Host
   Configuration Protocol (DHCPv4) options that appear multiple times in
   the same message.  Multiple instances of the same option are
   generated when an option exceeds 255 octets in size (the maximum size
   of a single option) or when an option needs to be split apart in
   order to take advantage of DHCP option overloading.  When multiple
   instances of the same option appear in the options, file and/or sname
   fields in a DHCP packet, the contents of these options are
   concatenated together to form a single option prior to processing.

There are no hints in 2131/2 about which options may or may not be "split".

The bottom line is avoid splitting options unless you have an explicit need,
such as outlined above in the 3396 abstract.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Grubmair Peter
> Sent: Friday, March 11, 2005 4:12 AM
> To: Dhcwg ([email-masked])
> Subject: [dhcwg] RFC2131 - option multiple times - which ones ?
> 
>  Hi,

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 11 Mar 2005 16:49:10 +0000

>   one instance before interpretation.

That is a perfectly reasonable interpretation considering the poor choice of
words in that section of the RFC, but not what I judge to be the intent.

Here's the way I wish it read:

	Any option MUST only appear once after processing.  During
	processing, if multiple instances of an option are encountered,
	they MUST be concatenated to form one option data block before
	the option's contents are evaluated.

>  , but RFC2132 tells nothing about this.

The content of the option is unimportant at this layer of processing.  Any
option with a length greater than one MAY be split up.  Realistically
clients and servers only do this if option data is longer than 255 bytes,
or if they need to perform option overloading.

-- 
David W. Hankins		"If you don't do it right the first time,
Operations Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Mar 2005 16:54:57 -0600

> Here's the way I wish it read:

RFC3396 updates RFC2131/2132, so you can in fact read it the way you 
describe.   However, you can't count on all implementations being 
compliant with that reading.