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

[Ted Lemon <[e-mail]>]

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.