Skip to main content

DHCP Option Concatenation Considerations
draft-tojens-dhcp-option-concat-considerations-00

Document Type Active Internet-Draft (individual)
Authors Tommy Jensen , Milan Justel
Last updated 2024-10-21
RFC stream (None)
Intended RFC status (None)
Formats
Additional resources GitHub Repository
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-tojens-dhcp-option-concat-considerations-00
dhc                                                            T. Jensen
Internet-Draft                                                 M. Justel
Updates: 3396 (if approved)                                    Microsoft
Intended status: Informational                           21 October 2024
Expires: 24 April 2025

                DHCP Option Concatenation Considerations
           draft-tojens-dhcp-option-concat-considerations-00

Abstract

   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.

Status of This Memo

   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 Notice

   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.

Jensen & Justel           Expires 24 April 2025                 [Page 1]
Internet-Draft  DHCP Option Concatenation Considerations    October 2024

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Previous Definition of Concatenation  . . . . . . . . . . . .   3
   4.  Implementation Challenges . . . . . . . . . . . . . . . . . .   3
   5.  What Concatenation Intends to Achieve . . . . . . . . . . . .   4
   6.  Changes to How Options are Split  . . . . . . . . . . . . . .   4
   7.  Changes to How Options are Concatenated . . . . . . . . . . .   4
     7.1.  Duplicates of Options with Defined Concatenation
           Behavior  . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.2.  Duplicates of Fixed-length Options  . . . . . . . . . . .   5
     7.3.  Duplicates of Multiple-of-fixed-length Options  . . . . .   5
     7.4.  Duplicates of Arbitrary-length Options  . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [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.

Jensen & Justel           Expires 24 April 2025                 [Page 2]
Internet-Draft  DHCP Option Concatenation Considerations    October 2024

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Previous Definition of Concatenation

   [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."

4.  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 [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.

Jensen & Justel           Expires 24 April 2025                 [Page 3]
Internet-Draft  DHCP Option Concatenation Considerations    October 2024

5.  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.

6.  Changes to How Options are Split

   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.

7.  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 [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).

7.1.  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.

Jensen & Justel           Expires 24 April 2025                 [Page 4]
Internet-Draft  DHCP Option Concatenation Considerations    October 2024

7.2.  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.

7.3.  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.

7.4.  Duplicates of Arbitrary-length Options

   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.

8.  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.

Jensen & Justel           Expires 24 April 2025                 [Page 5]
Internet-Draft  DHCP Option Concatenation Considerations    October 2024

9.  IANA Considerations

   This document has no IANA actions.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              DOI 10.17487/RFC3396, November 2002,
              <https://www.rfc-editor.org/rfc/rfc3396>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

10.2.  Informative References

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2132>.

   [RFC4702]  Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
              Configuration Protocol (DHCP) Client Fully Qualified
              Domain Name (FQDN) Option", RFC 4702,
              DOI 10.17487/RFC4702, October 2006,
              <https://www.rfc-editor.org/rfc/rfc4702>.

   [RFC6731]  Savolainen, T., Kato, J., and T. Lemon, "Improved
              Recursive DNS Server Selection for Multi-Interfaced
              Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
              <https://www.rfc-editor.org/rfc/rfc6731>.

   [RFC7291]  Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
              the Port Control Protocol (PCP)", RFC 7291,
              DOI 10.17487/RFC7291, July 2014,
              <https://www.rfc-editor.org/rfc/rfc7291>.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/rfc/rfc791>.

Jensen & Justel           Expires 24 April 2025                 [Page 6]
Internet-Draft  DHCP Option Concatenation Considerations    October 2024

   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
              Touch Provisioning (SZTP)", RFC 8572,
              DOI 10.17487/RFC8572, April 2019,
              <https://www.rfc-editor.org/rfc/rfc8572>.

   [RFC8910]  Kumari, W. and E. Kline, "Captive-Portal Identification in
              DHCP and Router Advertisements (RAs)", RFC 8910,
              DOI 10.17487/RFC8910, September 2020,
              <https://www.rfc-editor.org/rfc/rfc8910>.

   [RFC8973]  Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling
              (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973,
              January 2021, <https://www.rfc-editor.org/rfc/rfc8973>.

   [RFC9463]  Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
              and T. Jensen, "DHCP and Router Advertisement Options for
              the Discovery of Network-designated Resolvers (DNR)",
              RFC 9463, DOI 10.17487/RFC9463, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9463>.

Acknowledgments

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

Authors' Addresses

   Tommy Jensen
   Microsoft
   Email: tojens.ietf@gmail.com

   Milan Justel
   Microsoft
   Email: milanjustel@microsoft.com

Jensen & Justel           Expires 24 April 2025                 [Page 7]