| Internet-Draft | DHCP Option Concatenation Considerations | October 2024 |
| Jensen & Justel | Expires 24 April 2025 | [Page] |
DHCP has a length limit of 255 on individual options because of its one-byte length field for options. To accommodate longer options, splitting option data across multiple instances of the same Option Type is defined by [RFC3396]. However, this mechanism is required to be supported for all options. This leads to real-world implementations in the years since the RFC was published to deviate from these requirements to avoid breaking basic functionality. This document updates RFC 3396 to be more flexible regarding when DHCP agents are required to concatenate options to reflect deployement experiences.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC3396] defines how DHCP agents are to split and concatenate option data within an DHCP message. This has proven to be valuable as more DHCP options are defined that require support for concatenation as their data can exceed the 255 octet limit for options. Examples include [RFC4702], [RFC6731] (as a MAY), [RFC7291], [RFC8572], [RFC8973], and [RFC9463].¶
However, the way that [RFC3396] defined concatenation is not the way it is supported by major DHCP agent implementations today. New or existing implementors of DHCP will find real-world behavior will differ from the documented standard. This document updates [RFC3396] to clarify how option concatenation works in practice along with why it needs to differ from the previous standard.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
[RFC3396] defines the terms "concatenation-requiring" and "non-concatenation-requiring" to describe DHCP Options. While at multiple points in the document it requires implementors to handle concatenation of Options defined as concatenation-requiring, it also contains the following text which effectively requires implementors to handle concatenation of either Option type:¶
"However, an implementation which supports any concatenation-requiring option MUST be capable of concatenating received options for both concatenation-requiring and non-concatenation-requiring options."¶
In combination with the only permitted use of duplicate instances of an option type in the same DHCP message being option data splitting that then requires concatenation, this means that there is no way to recover from real-world DHCP deployment mistakes that can otherwise be handled under Jon Postel's Robustness Principle [RFC791].¶
For example, if a DHCP server sends two instances of an option type with fixed length, such as Option 51 (IP Address Lease Time) [RFC2132], concatenating these into an eight-octet payload will result in a protocol violation: Option 51 has to be four octets long exactly. In common deployments of DHCP agents today, we observe that this situation is handled by choosing one of the option instances that has the correct length to accept as the Option 51 value and ignoring the other instances. If implementations decided instead to strictly adhere to always concatenating multiple instances of the same option type, this would entirely block IPv4 network connectivity for the network stack.¶
DHCP option concatenation is intended to allow option data to exceed the 255 octet limit imposed by its single-octet length field. This can also be used for splitting options across DHCP message section boundaries when the Overload Option indicates that the sname field, file field, or both also contain option data.¶
To support the intention of option concatenation without causing the challenges described in Section 4, this document updates [RFC3396] to limit concatenation to concatenation-requiring options. DHCP agents SHOULD NOT provide multiple instances of an option type unless that option type is defined as concatenation-requiring. To split non-concatenation-requiring options is out-of-spec behavior that leads to implementation-specific message processing.¶
When DHCP agents receive messages with split options that are concatenation- required options, they MUST concatenate the duplicate concatenation-required options as described in [RFC3396].¶
If DHCP agents sending messages never split non-concatenaton-requiring options, no further guidance would be needed. However, real-world deployments have seen out-of-spec behavior that clients may wish to be defensive against and liberal in parsing. Therefore, when DHCP agents receive messages with split options that are not concatenation-requiring options, they MAY make best-effort attempts to interpret the message or fail processing entirely as a protocol error. This is implementation-specific, though some reasonable suggestions are broken down in this section based on four types of situations involving non-concatenation- requiring options still being split (even though they should not be).¶
Some non-concatenation-requiring options may still define how they are to be processed when DHCP agents receive multiple instances of the option type. In this case, DHCP agents SHOULD follow the guidance defined by the option's standard.¶
Fixed-length options are options that only allow a single length value, such as Option 51 Lease Time which can only be four octets long. DHCP agents receiving messages with more than one instance of fixed-length non-concatenation-requiring options MAY choose to attempt processing one of the instances if it has the correct length.¶
Multiple-of-fixed-length options are options that are lists of fixed-length elements, such as Option 6 DNS Name servers which MUST be a multiple of four octets long. DHCP agents receiving messages with more than one instance of multiple-of-fixed-length options MAY choose to attempt processing one of the instances if it has a correct length.¶
It MAY also choose to concatenate the options if the length of the concatenated option data is a correct length (which may indicate a need to split a long list because the total length is longer than 255 octets). DHCP agents MAY choose to only do this if the length of the concatenated option data is greater than 255 octets if it wants to reduce how permissive it is.¶
Arbitrary-length options are options that may have any non-zero octent length, such as Option 114 Captive-Portal [RFC8910]. DHCP agents receiving messages with more than one instance of arbitrary-length options MAY concatenate or choose one instance to process. It MAY choose to do some validation of the content that would result from each approach, meaning if the data only makes sense in the context of the option's definition, it could use that to decide which approach to take.¶
This document changes the conditions under which a DHCP agent accepts or rejects option data. The only way this might reduce a DHCP agent's security posture would be if it would have previously refused to process data from the network that it will now process. However, this was always possible for an attacker crafting DHCP messages. Any attacker capable of creating a malformed message could instead craft a well-formed message (which would be processed in the same way before and after this document). Therefore, this document does not introduce any additional security considerations beyond the previous definitions of DHCP and option concatenation.¶
This document has no IANA actions.¶
Thank you to Dieter Siegmund, Stuart Cheshire, and Ted Lemon for their comments and suggestions.¶