Network Working Group T. Lemon
Request for Comments: 3396 Nominum, Inc.
Updates: 2131 S. Cheshire
Category: Standards Track Apple Computer, Inc.
Encoding Long Options
in the Dynamic Host Configuration Protocol (DHCPv4)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
This document updates RFC 2131  by clarifying the rules for option
concatenation specified in section 4.1. It is expected that the
reader will be familiar with this portion of RFC 2131. The text in
section 4.1 that reads "Options may appear only once, unless
otherwise specified in the options document." should be considered
The DHCP protocol  specifies objects called "options" that are
encoded in the DHCPv4 packet to pass information between DHCP
protocol agents. These options are encoded as a one-byte type code,
a one-byte length, and a buffer consisting of the number of bytes
specified in the length, from zero to 255.
Lemon & Cheshire Standards Track [Page 1]RFC 3396 Encoding Long Options in DHCPv4 November 2002
However, in some cases it may be useful to send options that are
longer than 255 bytes. RFC 2131  specifies that when more than
one option with a given type code appears in the DHCP packet, all
such options should be concatenated together. It does not, however,
specify the order in which this concatenation should occur.
We specify here the ordering that MUST be used by DHCP protocol
agents when sending options with more than 255 bytes. This method
also MUST be used for splitting options that are shorter than 255
bytes, if for some reason the encoding agent needs to do so. DHCP
protocol agents MUST use this method whenever they receive a DHCP
packet containing more than one occurrence of a certain type of
Throughout this document, the acronym "DHCP" is used to refer to
the Dynamic Host Configuration Protocol as specified in RFC 2131
 and RFC 2132 .
We have used the term "DHCPv4" in the abstract for this document
to distinguish between the DHCP protocol for IPv4 as defined in
RFC 2131 and RFC 2132 and the DHCP protocol for IPv6, which, at
the time that this document was written, was still under
DHCP protocol agents
This refers to any device on the network that sends or receives
DHCP packets - any DHCP client, server or relay agent. The nature
of these devices is not important to this specification.
The DHCP protocol agent that is composing a DHCP packet to send.
The DHCP protocol agent that is processing a DHCP packet it has
DHCP options are collections of data with type codes that indicate
how the options should be used. Options can specify information
that is required for the DHCP protocol, IP stack configuration
parameters for the client, information allowing the client to
rendezvous with DHCP servers, and so on.
Lemon & Cheshire Standards Track [Page 2]RFC 3396 Encoding Long Options in DHCPv4 November 2002
The DHCP packet format is based on the BOOTP packet format defined
in RFC 951 . When used by DHCP protocol agents, BOOTP packets