]> Microsoft

tojens.ietf@gmail.com

Microsoft

milanjustel@microsoft.com

INT dhc concatenation DHCP 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 . 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.

Introduction 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 , (as a MAY), , , , and . However, the way that 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 to clarify how option concatenation works in practice along with why it needs to differ from the previous standard.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Previous Definition of Concatenation 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."

Implementation Challenges 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 . For example, if a DHCP server sends two instances of an option type with fixed length, such as Option 51 (IP Address Lease Time) , 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.

What Concatenation Intends to Achieve 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.

Changes to How Options are Split To support the intention of option concatenation without causing the challenges described in , this document updates 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.

Changes to How Options are Concatenated When DHCP agents receive messages with split options that are concatenation- required options, they MUST concatenate the duplicate concatenation-required options as described in . 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).

Duplicates of Options with Defined Concatenation Behavior 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.

Duplicates of Fixed-length Options 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.

Duplicates of Multiple-of-fixed-length Options 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.

Duplicates of Arbitrary-length Options Arbitrary-length options are options that may have any non-zero octent length, such as Option 114 Captive-Portal . 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.

Security Considerations 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.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK] A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. [STANDARDS-TRACK] This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document. This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. This document specifies mechanisms to configure DDoS Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS signal channel Call Home. It can be useful to know the appropriate DOTS server for a given location in order to engage mitigation actions. This is true even in cases where the DOTS client cannot localize the attack: cases where it only knows that some resources are under attack and that help is needed. This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions. This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document. This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679.

Acknowledgments Thank you to Dieter Siegmund, Stuart Cheshire, and Ted Lemon for their comments and suggestions.