Subject: [dhcwg] Question about RFC 3396 Encoding Long Options in DHCPv4

From: VithalPrasad Gaitonde <[email-masked]>
Date: Tue, 30 Nov 2010 12:21:23 +0530

Hi,
As documented in RFC 3396, the sname and file fields of the DHCP packet can
be used for option values longer than 255 octets.
Using sname (64 octets) and file (128 octets) gets additionals 192 octets of
space in addition to 255 octets in the options field.
Is my understanding correct ?

If yes, for options such as option 119 (Domain Search Option RFC 3397),
there would be situations when the option value is longer then 447 octets
(255+ 192). Are there any solutuions to these cases - RFC 3396 does not seem
to solve this problem completely.

Thanks,
Prasad

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Nov 2010 09:33:33 -0600

On Nov 30, 2010, at 12:51 AM, VithalPrasad Gaitonde wrote:
> If yes, for options such as option 119 (Domain Search Option RFC 3397), there would be situations when the option value is longer then 447 octets (255+ 192). Are there any solutuions to these cases - RFC 3396 does not seem to solve this problem completely.

You can encode long options in the DHCP option buffer as well.   So you could for example have two Domain Search List (DSL) option of 255 bytes in the main option field of the DHCP packet, and then an additional DSL option of 126 bytes in the file field, and an additional DSL option of 62 bytes in the sname field.

The receiving agent would concatenate these four DSL options to form a single 698-byte DSL option.   The two options from the options field would come first, then the option from the file field, then the option from the sname field.

I'm sorry the text in section 5 is confusing--it was very difficult to come up with a way of explaining this that didn't involve any diagrams or animation.  :(

BTW, if you are sending DSL options containing more than perhaps 100 bytes of data, you are sending DSL options that are too long.   The DSL option is not intended as a mechanism for communicating policy.  If you use it this way, it may cause problems because you'll run out of space in the DHCP packet for *other* options.

---

From: David Hankins <[email-masked]>
Date: Tue, 30 Nov 2010 13:17:35 -0800

On Mon, Nov 29, 2010 at 10:51 PM, VithalPrasad Gaitonde
<[email-masked]>wrote:

> Using sname (64 octets) and file (128 octets) gets additionals 192 octets
> of space in addition to 255 octets in the options field.

No - option overloading doesn't specifically enable option concatenation.
 It only makes these fields available to carry options in addition to the
options space.  Single options may appear in these fields, and long options
may be divided but still contained entirely in the main options space (if
all the fragments fit).

> to solve this problem completely.

RFC 3396 does not solve this problem completely, but not for the reason you
state.  Theoretically, RFC 3396 permits any number of instances of a given
option code, so there is no strict upper limit to option content size except
that it must be able to fit within the packet.

So how big is a packet?  This is where things get confusing.  The short
version of the story is that there is a 512 octet limitation (which was
intended as a minimum in RFC 2131) on DHCPv4 packet size, and that although
clients can advertise larger capabilities by including a max-message-size
option in their requests, relay agents have no similar way to signal their
own limitations (and relay agents are the most problematic case anyway)...so
the 512 octet limitation sticks.

This means the 'options' field can be at most 248 octets (less 4 octets for
the MAGIC value).  So there are a series of 244, 128, 64 octet fields for
option storage, and your options (of whatever sizes and fragmentation) must
fit within these fields in order.  If you have a DHCPv4 option longer than
(244 + 128 + 64 - (2 + 2 + 2 + 3)) = 427 octets, then DHCPv4 cannot
practically carry it.  The 2's in the subtraction refer to the TL part of
the TLV's, the '3' refers to the TLV of the dhcp-message-type option.  If
you also needed to deliver other options, this '3' value would get
considerably larger, further reducing the available space for a maximally
sized option payload.