ietf-corpus

rfc-3942

Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options

B. Volz
date2004-11 streamIETF areaint wgdhc statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc3942 doi10.17487/RFC3942 errataview
This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]

updates

Extracted elements (13)

design-rationale §3.1

The 16-bit option code approach (using options 126 and 127 or a new magic cookie) was rejected because it penalizes the first option assigned, requires significant changes to clients/servers/relay agents, could adversely impact existing implementations, and forces clients to send multiple DHCPDISCOVER messages.

registry

design-rationale §3

The publicly defined DHCPv4 options space (1-127) is nearly exhausted. Rather than using 16-bit option codes or a new magic cookie format (both of which impose significant implementation costs), the DHC WG chose to reclassify the largely-unused site-specific range (128-223) as publicly defined options, as the impact is minimal.

ldap, registry

design-rationale §3.2

The site-specific option range (128-254) was large (127 options) but little used for its original purpose. Many DHCP client implementations also lacked well-documented means to request or extract site-specific options, making the range a candidate for reclassification.

registry

interoperability-note §4

If a site needs more than 31 site-specific options after reclassification, it must switch to using suboptions (as done for the Relay Agent Information Option, RFC 3046) rather than using newly available publicly defined option codes for private purposes.

registry

interoperability-note §3.2

Vendors that used site-specific option codes 128-223 in a non-site-specific manner risk conflicts if multiple vendors chose the same codes. Sites deploying such vendor products may face option numbering collisions with existing local usage.

registry

normative-requirement §6 MUST NOT

IANA MUST NOT assign options 128-223 to any publicly defined options while they are listed as 'Unavailable'. These options are placed in the Unavailable state upon publication of this RFC.

registry

normative-requirement §4 MUST

If multiple vendors claim the same option number and can demonstrate reasonably wide use, none of the vendors will be allowed to keep that option number and they MUST go through the normal publicly assigned option process per RFC 2939.

registry

normative-requirement §4 SHOULD

Sites presently using site-specific option codes within the reclassified range (128-223) SHOULD take steps to renumber these options to values within the remaining site-specific range (224-254).

registry

normative-requirement §4 SHOULD

Vendors currently using reclassified options 128-223 have 6 months from this RFC's publication date to notify the DHC WG and IANA of their usage and agree to document it in an RFC; IANA will then list those options as 'Tentatively Assigned'.

registry

protocol-element §4

The DHCPv4 option space (0-255) is divided as follows after this reclassification: options 1-223 are publicly defined, options 224-254 are site-specific, option 0 is pad, and option 255 is end.

registry

registry §6

IANA is directed to expand the publicly defined DHCPv4 options space from 1-127 to 1-223. Options 128-223 are reclassified from site-specific to publicly defined and managed under the RFC 2939 assignment process. The remaining site-specific range is reduced to options 224-254 (31 options).

registry

security-consideration §5

This document in and by itself provides no security, nor does it impact existing DHCP security as described in RFC 2131. The reclassification of option codes is an administrative action with no direct security implications.

security

state-machine §4

Reclassified options (128-223) progress through states: initially 'Unavailable' (IANA-managed, not assignable); after vendor notification within 6 months, move to 'Tentatively Assigned'; after 6 months with no vendor claim, move to 'Unassigned' (available for new assignments); after Internet-Draft published and RFC approved, move to 'Assigned'.

registry