RFC 7227
Guidelines for Creating New DHCPv6 Options
Part 1 of 8 🎀 more parts coming, so stay tuned bestie 🧚
Title Block 📄
RFC 7227: Guidelines for Creating New DHCPv6 Options 🌸
This one is a Best Current Practice, so it's BCP 187, published in May 2014 as part of the IETF stream. It's written by D. Hankins (Google), T. Mrugalski (ISC), M. Siodelski (ISC), S. Jiang (Huawei Technologies Co., Ltd.), and S. Krishnan (Ericsson). The ISSN is 2070-1721. It updates RFC 3315, and the title block doesn't list anything it obsoletes. 💅
Abstract ✨
okay so this doc is basically a guide for people who are about to make new DHCPv6 options 🎀 It helps them build option formats that existing DHCPv6 software can easily adopt, which is so important because nobody wants to rewrite everything 😭 It also gives expert reviewers some guidelines for judging new registrations. And yes, this document updates RFC 3315 🦋
Status of This Memo 📝
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7227 🔗
Copyright Notice ⚖️
Copyright (c) 2014 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🫶
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 5
4. General Principles . . . . . . . . . . . . . . . . . . . . . 5
5. Reusing Other Option Formats . . . . . . . . . . . . . . . . 6
5.1. Option with IPv6 Addresses . . . . . . . . . . . . . . . 7
5.2. Option with Single Flag (Boolean) . . . . . . . . . . . . 8
5.3. Option with IPv6 Prefix . . . . . . . . . . . . . . . . . 9
5.4. Option with 32-bit Integer Value . . . . . . . . . . . . 10
5.5. Option with 16-bit Integer Value . . . . . . . . . . . . 10
5.6. Option with 8-bit Integer Value . . . . . . . . . . . . . 11
5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 11
5.8. Option with Text String . . . . . . . . . . . . . . . . . 12
5.9. Option with Variable-Length Data . . . . . . . . . . . . 13
5.10. Option with DNS Wire Format Domain Name List . . . . . . 14
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 15
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 15
8. Choosing between an FQDN and an Address . . . . . . . . . . . 16
9. Encapsulated Options in DHCPv6 . . . . . . . . . . . . . . . 19
10. Additional States Considered Harmful . . . . . . . . . . . . 20
11. Configuration Changes Occur at Fixed Times . . . . . . . . . 21
12. Multiple Provisioning Domains . . . . . . . . . . . . . . . . 21
13. Chartering Requirements and Advice for Responsible Area
Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14. Considerations for Creating New Formats . . . . . . . . . . . 23
15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 23
16. Singleton Options . . . . . . . . . . . . . . . . . . . . . . 24
17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 25
18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 25
19. Clients Request Their Options . . . . . . . . . . . . . . . . 26
20. Transition Technologies . . . . . . . . . . . . . . . . . . . 26
21. Recommended Sections in the New Document . . . . . . . . . . 27
21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 28
21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 28
21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 29
22. Should the New Document Update Existing RFCs? . . . . . . . . 29
23. Security Considerations . . . . . . . . . . . . . . . . . . . 29
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
26. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
26.1. Normative References . . . . . . . . . . . . . . . . . . 31
26.2. Informative References . . . . . . . . . . . . . . . . . 321. Introduction 🌈
okay so most protocol devs obsess over "will this work?" and "will this be fast?" 🏃♀️ Those matter a LOT, but there's a sneakier question that doesn't get enough love: does the proposed protocol throw up needless roadblocks that stop deployed software from adopting it? 🙈
DHCPv6 [RFC3315] implementors don't just have to handle an option's format on the wire. The option has to survive every stage of the system, starting from the user interface where someone types in the config all the way to the machine interfaces that finally consume it. It's a whole journey, bestie 💅
Another thing that gets overlooked is whether operators need to be intimately familiar with an option's internal format just to use it. Most DHCPv6 software has a way to handle unknown options when they're published, and the operator usually has to configure that handling by hand. But if that takes extensive reading (more than you could fit in a simple FAQ, for example), adoption is dead in the water 💀
So even if a solution would work, and might even be optimal in space, time, or aesthetics, an option can still face a series of worsening challenges when it comes to adoption:
- If it doesn't fit neatly into existing configuration files.
- If it requires source code changes to be adopted and, hence, upgrades of deployed software.
- If it doesn't share its deployment fate in a general way with other options, standing alone in requiring code changes or reworking configuration file syntaxes.
- If the option would work well in the particular deployment environment the proponents currently envision, but it has equally valid uses in some other environment where the proposed option format would fail or would produce inconsistent results.
There are lots of things DHCPv6 option creators can do to avoid every pitfall on this list entirely, or, if that's not possible, to make life easier for software implementors and boost the odds of widespread adoption 🔥
This document is meant as a helper for protocol developers defining new options, and for expert reviewers who review submitted proposals. 🫶
2. Requirements Language 🔑
okay, this is the part where the key words get their official meaning 👑 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🧚
3. When to Use DHCPv6 🎀
Mainly, DHCPv6 carries configuration parameters for its clients. Any knob, dial, slider, or checkbox on the client system, like "my domain name servers", "my hostname", or even "my shutdown temperature", is a candidate for being configured by DHCPv6 🌸
Having a knob isn't enough though, because DHCPv6 also brings in the extension of an administrative domain: the operator of the network the client is currently attached to. Someone runs not just the local switching infrastructure the client plugs into (directly or wirelessly), but also the various ways of reaching the external Internet through local assist services the network has to provide, like domain name servers or routers. So even if a configuration parameter could potentially be delivered by DHCPv6, you still have to check whether it's reasonable for that parameter to be controlled by whoever administers the network the client is on at any given moment 🤔
Note that the client is not required to configure any of these values it receives via DHCPv6 (for example, because its own administrator has set those values locally). But overriding DHCPv6-provided values may get the client denied certain services on the network it has joined, so keep that in mind 👀 Having more control over client node configuration is one of the reasons DHCPv6 is preferred in enterprise networks. 💼
4. General Principles 💖
The main guiding principle for making an option more adoptable is reuse 🔁 The option should be created so that it doesn't need any new or special-case software to support it. If old software already out in the field can adopt the option through the configuration facilities it already has, then it's pretty certain that new software can adopt it easily too ✨
There are at least two classes of DHCPv6 options. The first is simple options, which are provided explicitly to carry data from one side of the DHCPv6 exchange to the other (things like name servers, domain names, or time servers). The second is a protocol class of options, which need special processing from the DHCPv6 software or get used during special processing (like the Fully Qualified Domain Name (FQDN) option [RFC4704]), and so on. These options carry data that is the result of some routine in the DHCPv6 software 🧠
The guidelines here should be applied in a relaxed way for the protocol class of options. Wherever special-case code is already required to adopt the DHCPv6 option, it's way more reasonable to format the option in a less generic fashion, as long as there are measurable benefits to doing so. 🦋
5. Reusing Other Option Formats ✨
okay so the easiest way to whip up a DHCPv6 option that's basically guaranteed to deploy is to build it out of fragments you already have 🧩. You can let a group of data elements repeat to fill whatever space is left, so you get multiple values in one option. The trick is to put all the fixed-size stuff at the start of the option and the variable or unknown-size stuff at the very end 💅
this is lowkey great because implementations can reuse code paths that were already written for other options. less code, less pain 🫶
there's a trade-off between how easy an existing option format is to adopt and what a brand-new or specialized format can offer. in general, it is usually preferable to reuse option formats that have already been used 🌸
tbh it isn't very practical to go through the huge pile of DHCPv6 options that are already allocated and figure out which ones solve a similar problem. so the list below is here as shorthand for common option format data elements. please note it is not complete in terms of covering every option format ever devised 🙈
if you need something more complex, you can treat these basic formats as primitives (or "fragment types") and build bigger formats out of them. it should be noted that it is often easier to implement two options with trivial formats than one option with a more complex format. that is not an unconditional requirement though. sometimes splitting one complex option into two or more simple options introduces inter-option dependencies that should be avoided. in that case, it is usually better to keep one complex option ✨
5.1. Option with IPv6 Addresses 🌐
this format carries one or many IPv6 addresses. sometimes the number of allowed addresses is limited (e.g., to one):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Option with IPv6 AddressesExamples of use:
- DHCPv6 Server Unicast Address [RFC3315] (a single address only)
- Session Initiation Protocol (SIP) Servers IPv6 Address List [RFC3319]
- DNS Recursive Name Servers [RFC3646]
- Network Information Service (NIS) Servers [RFC3898]
- Simple Network Time Protocol (SNTP) Servers [RFC4075]
- Broadcast and Multicast Service Controller IPv6 Address Option for DHCPv6 [RFC4280]
- Mobile IPv6 (MIPv6) Home Agent Address [RFC6610] (a single address only)
- Network Time Protocol (NTP) Server Address [RFC5908] (a single address only)
- NTP Multicast Address [RFC5908] (a single address only)
5.2. Option with Single Flag (Boolean) 🎀
sometimes you just want to pass along one flag that's either on or off 🔥 instead of making an option with 1 bit of usable data and 7 bits of padding (ew, so wasteful), it's better to define an option with no content at all. the presence or absence of the option is what carries the value. bonus perk: the absent option is the default, so an admin has to take explicit action to deploy the opposite of the default value 👑
the absence of the option represents the default value, and the presence of the option represents the other value. that does not necessarily mean that absence is "off" (or "false") and presence is "on" (or "true") though 🙃 for example, if you want the default for a bistable option to be "true"/"on", then the presence of that option would turn it off (make it false). if the option's presence signifies an off/false state, that should be reflected in the option name, e.g., OPTION_DISABLE_FOO 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Option for Conveying BooleanExamples of use:
- DHCPv6 Rapid Commit [RFC3315]
5.3. Option with IPv6 Prefix 🧁
sometimes you need to carry an IPv6 prefix 🌈 the info includes the 128-bit IPv6 prefix plus a prefix length from 0 to 128. the simplest approach would be two fixed-length fields, one for the prefix length and one for the prefix. but lots of the time you're using /64 or shorter prefixes, which means most of that fixed prefix field would be 0 bits and totally unused 😭 so to avoid carrying unused data, it is recommended to store the prefix in the variable-length data field. here's the format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix6len | ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Option with IPv6 Prefixthe way the pieces work:
option-lengthis set to 1 + length of the IPv6 prefix.prefix6lenis 1 octet long and specifies the length in bits of the IPv6 prefix. typically allowed values are 0 to 128.- the
ipv6-prefixfield is a variable-length field that specifies the IPv6 prefix. the length is(prefix6len + 7) / 8. this field is padded with 0 bits up to the nearest octet boundary whenprefix6lenis not divisible by 8.
Examples of use:
- Default Mapping Rule [MAP]
for example, the prefix 2001:db8::/60 would be encoded with an option-length of 9, prefix6-len would be set to 60, and the ipv6-prefix would be 8 octets and would contain octets 20 01 0d b8 00 00 00 00 ✨
it should be noted that the IAPREFIX option defined by [RFC3633] uses a full-length 16-octet prefix field. the concern about option length was not well understood at the time of its publication 🙈
5.4. Option with 32-bit Integer Value 🔢
this format can carry a 32-bit signed or unsigned integer value:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Option with 32-bit Integer ValueExamples of use:
- Information Refresh Time [RFC4242]
5.5. Option with 16-bit Integer Value 🍓
this format can carry 16-bit signed or unsigned integer values:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Option with 16-bit Integer ValueExamples of use:
- Elapsed Time [RFC3315]
5.6. Option with 8-bit Integer Value 🧚
this format can carry 8-bit integer values:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit-integer |
+-+-+-+-+-+-+-+-+
Figure 6: Option with 8-bit Integer ValueExamples of use:
- DHCPv6 Preference [RFC3315]
5.7. Option with URI ✨
okay so a Uniform Resource Identifier (URI) [RFC3986] is a compact sequence of characters that identifies an abstract or physical resource 🦋. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, also provide a means of locating it by describing its primary access mechanism (e.g., its network "location") 🌸. This option format can be used to carry a single URI:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Option with URI
Examples of use:
- Boot File URL [RFC5970]
An alternate encoding to support multiple URIs is available 💖. An option must be defined to use either the single URI format above or the multiple URI format below, depending on whether a single URI is always sufficient or if multiple URIs are possible 🧚.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. uri-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Option with Multiple URIs
Each instance of the uri-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-len | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+The uri-len is 2 octets long and specifies the length of the URI data 🔥. Although the URI format in theory supports up to 64 KB of data, in practice, large chunks of data may be problematic 💀. See Section 15 for details.
5.8. Option with Text String 🎀
A text string is a sequence of characters that have no semantics ✨. The encoding of the text string MUST be specified 👑. Unless otherwise specified, all text strings in newly defined options are expected to be Unicode strings that are encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. Please note that all strings containing only 7-bit ASCII characters are also valid UTF-8 Net-Unicode strings 🫶.
If a data format has semantics other than just being text, it is not a string; e.g., an FQDN is not a string, and a URI is also not a string because they have different semantics. A string must not include any terminator (such as a null byte). The null byte is treated as any other character and does not have any special meaning 🙈. This option format can be used to carry a text string:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. String .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: Option with Text String
Examples of use:
- Timezone Options for DHCPv6 [RFC4833]
An alternate encoding to support multiple text strings is available. An option must be defined to use either the single text string format above or the multiple text string format below, depending on whether a single text string is always sufficient or if multiple text strings are possible 🦋.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. text-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: Option with Multiple Text Strings
Each instance of the text-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| text-len | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+The text-len is 2 octets long and specifies the length of the string 🍓.
5.9. Option with Variable-Length Data 🌈
This option can be used to carry variable-length data of any kind 💅. Internal representation of carried data is option specific. Whenever this format is used by the new option being defined, the data encoding should be documented.
This option format provides a lot of flexibility to pass data of almost any kind. Though, whenever possible, it is highly recommended to use more specialized options, with field types better matching carried data types 💜.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. variable-length data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: Option with Variable-Length Data
Examples of use:
5.10. Option with DNS Wire Format Domain Name List 🌸
This option is used to carry 'domain search' lists or any host or domain name 🔍. It uses the same format as described in Section 5.9 but with the special data encoding, as described in Section 8 of [RFC3315]. This data encoding supports carrying multiple instances of hosts or domain names in a single option by terminating each instance with the byte value of 0 ✨.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS Wire Format Domain Name List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: Option with DNS Wire Format Domain Name List
Examples of use:
- SIP Servers Domain Name List [RFC3319] (many domains)
- NIS Domain Name [RFC3898] (many domains)
- Location-to-Service Translation (LoST) Server Domain Name [RFC5223]
- Location Information Server (LIS) Domain Name [RFC5986]
- Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) Location [RFC6334] (a single FQDN)
- Home Network Identifier [RFC6610] (a single FQDN)
- Home Agent FQDN [RFC6610] (a single FQDN)
6. Avoid Conditional Formatting 🙅♀️
Placing an octet at the start of the option that informs the software how to process the remaining octets of the option may appear simple to the casual observer 👀. But, the only conditional formatting methods that are in widespread use today are 'protocol' class options 😭. Therefore, conditional formatting requires new code to be written and complicates future interoperability should new conditional formats be added; existing code has to ignore conditional formats that it does not support 🥲.
7. Avoid Aliasing 💅
Options are said to be aliases of each other if they provide input to the same configuration parameter 🧐. A commonly proposed example is to configure the location of some new service ("my foo server") using a binary IP address, a domain name field, and a URL. This kind of aliasing is undesirable and is not recommended 🚫.
In this case, where three different formats are supposed, it more than triples the work of the software involved, requiring support for not merely one format but support to produce and digest all three 😩. Furthermore, code development and testing must cover all possible combinations of defined formats. Since clients cannot predict what values the server will provide, they must request all formats. So, in the case where the server is configured with all formats, DHCPv6 message bandwidth is wasted on option contents that are redundant. Also, the DHCPv6 option number space is wasted, as three new option codes are required rather than one 🗑️.
It also becomes unclear which types of values are mandatory and how configuring some of the options may influence the others. For example, if an operator configures the URL only, should the server synthesize a domain name and an IP address? A single configuration value on a host is probably presented to the operator (or other software on the machine) in a single field or channel. If that channel has a natural format, then any alternative formats merely make more work for intervening software in providing conversions 🤯.
So, the best advice is to choose the one method that best fulfills the requirements for simplicity (such as with an IP address and a port pair), late binding (such as with DNS), or completeness (such as with a URL) 👑✨.
8. Choosing between an FQDN and an Address ✨
okay so some parameters can be given as either an FQDN or an address 🎀 in most cases you should pick just one of them. this section goes through the pros and cons of each so you can make a good call, bestie 💅 and fr, defining both option types at the same time is strongly discouraged (see Section 7) unless you have a really solid reason 🙈
there's no one answer that works for everything 🌸 it totally depends on what the parameter is. for stuff that's network specific or describes part of the network's infrastructure, like which mobility services are available, addresses are usually the more usable choice 🦋 but for application-specific config, like SIP servers, an FQDN is usually the better move 💜
applications are often better at handling FQDN failures than address failures 👑 most operating systems let you retry an FQDN resolution if the first try fails, and a huge number of apps support that kind of recovery 🔥 but with an address, there's typically no API that lets an application reconfigure over DHCP to grab a new address if the one it got is no longer right 😭 this can usually be fixed by handing out a list of addresses instead of just one ✨ but then you need a defined procedure for how the addresses get used (all at once, round robin, try the first and fail over to the next if it fails, etc.) 🧚
an FQDN gives you a higher level of indirection and ambiguity 🌈 in lots of cases that's a benefit, but for some it's a flaw 💀 for example, one operator suggested the same name should resolve to different addresses depending on where the resolving host is attached 🍓 that's one way to do localized addressing, BUT to pull it off you have to break the DNS convention that a query for a particular name always returns the same answer (except for the ordering of the IP addresses in the response, which the name server is supposed to vary) 🙈 you can get that same locality for config info directly with DHCP, since the DHCP server has to know the network topology anyway to hand out IP address or prefix config 🫶
the other kind of ambiguity is tied to multiple provisioning domains (see Section 12) 🔮 right now the stub resolver on the DHCP client can't be assumed to make the DNS query for a DHCP-supplied FQDN on the same interface where it got its DHCP config 😳 so it might get a different answer from DNS than was intended ✨
this is especially a problem when the option's normal use makes sense with a private DNS zone (or zones), like on an enterprise network 🏢 it's also possible the client has an explicit DNS server configured and so never ends up querying the enterprise network's internal DNS server 💀
an FQDN also has to be resolved into an actual address 🌸 which raises the question of when that resolution happens 👀 there are a few possible answers: a) by the server, when it starts up, b) by the server, right before it sends an option, c) by the client, immediately after receiving an option, and d) by the client, when the content of the option is actually consumed 💅 for a), b), and possibly c), the option should really convey an address, not an FQDN 🦋 the only real reason to use an FQDN is case d) 😭 it's the only case that lets changes in the DNS get picked up by clients 🎀
if the parameter is going to be used by constrained devices (low power, battery operated, and low capability) or on very lossy networks, it may be appealing to drop the DNS resolution requirement and just use addresses 🔋 another example of a constrained device is a network-booted device, where the node is very capable once it's booted but the boot prom is pretty limited 💜
another thing to consider is how long clients take to notice config changes ⏰ say a server configures service A with an address and service B with an FQDN 👯 when an admin wants to update the config, they can change both services on the DHCP server 🌟 but if clients don't support reconfigure (which is an optional feature of RFC 3315 but is mandatory in some environments, e.g., cable modems), the new config only lands on clients after the T1 timer runs out 😬 whether that's a problem depends on the change (is it a new server joining a cluster of servers already running, or a new server replacing the only one that crashed?) 🚨 updating service B, on the other hand, can be done with a DNS record update 🌈 caching DNS servers may cache that info for up to the Time to Live (TTL) 🧚 depending on the values of T1 and TTL, one update can be faster than the other 💫 and depending on the change (a planned modification or an unexpected failure), T1 or TTL can be lowered before the change to speed up adoption of the new config 🏃♀️
simply put, protocol designers don't know what the TTL or the T1 time will be 🤷♀️ so they can't assume whether a DHCP option will get refreshed faster based on T1 or TTL 🙅♀️
addresses have the benefit of being easier to implement and handle in DHCP software 🛠️ an address option is simpler to use, its validation is trivial (a multiple of 16 counts as a valid option), it's explicit, and it doesn't allow any ambiguity 💖 it's also faster (no extra round-trip time), so it's more efficient, which matters a lot for energy-restricted devices 🔋 and it doesn't require the client to implement DNS resolution at all 🫶
an FQDN brings a bunch of extra failure modes and issues that need to be dealt with 😩
- The client must have knowledge about available DNS servers. That typically means that option DNS_SERVERS [RFC3646] is mandatory. This should be mentioned in the document that defines the new option. It is possible that the server will return the FQDN option but not the DNS server's option. There should be a brief discussion about it;
- The DNS may not be reachable;
- The DNS may be available but may not have appropriate information (e.g., no AAAA records for the specified FQDN);
- The address family must be specified (A, AAAA, or any); the information being configured may require a specific address family (e.g., IPv6), but there may be a DNS record only of another type (e.g., A only with an IPv4 address).
- What should the client do if there are multiple records available (use only the first one, use all, use one and switch to the second if the first fails for whatever reason, etc.). This may be an issue if there is an expectation that the parameter being configured will need exactly one address;
- Multihomed devices may be connected to different administrative domains with each domain providing different information in the DNS (e.g., an enterprise network exposing private domains). The client may send DNS queries to a different DNS server; and
- It should be mentioned if Internationalized Domain Names are allowed. If they are, DNS option encoding should be specified.
address options used with overly long T1 (renew timer) values end up having some characteristics of hard-coded values 🙀 that's strongly discouraged 🚫 see [RFC4085] for an in-depth discussion 📚 and if the option may appear in Information-request, its lifetime should be controlled using the information refresh time option [RFC4242] ⏳
one specific case that makes the address vs. FQDN choice not so obvious is a DNS Security (DNSSEC) bootstrap scenario 🔐 DNSSEC validation requires clock sync (accurate enough to judge signature inception and expiry times) 🕰️ which often means you need NTP configuration too ⏰
but if NTP is provided as an FQDN, there's no way to validate its DNSSEC signature 😬 ngl this is a bit of a weak argument, because providing an NTP server as an address can't be verified with DNSSEC either 🤷♀️ and if the trustworthiness of the configuration from the DHCP server is in question, DHCPv6 offers mechanisms that allow server authentication 🔒✨
9. Encapsulated Options in DHCPv6 ✨
okay so most options just hang out directly inside a DHCPv6 message 💅 there's no official normative language for them, but people call them top-level options 🌸 a lot of options can hold other options inside them, and those inner ones are called encapsulated or nested options 🎀 some people say sub-options, but that actually means something else 🙈 so please don't use sub-options to describe encapsulated ones. it's recommended to say "encapsulated", like [RFC3315] does 🫶
the difference is that encapsulated options use normal DHCPv6 option numbers, while sub-options use an option number space that belongs to one specific parent option. ngl, DHCPv6 is not short on option numbers 🦋 so almost all options share one common option space. like, option type 1 meant totally different things in DHCPv4 depending on whether it was at the top level or inside the Relay Agent Information option 💀 DHCPv6 doesn't have that confusion, with the exception of [RFC5908], which SHOULD NOT be used as a template for future DHCP option definitions 🚫
from an implementation point of view, encapsulated options are way easier than sub-options 🧚 implementors don't have to juggle separate option spaces, and they can reuse the same buffer parser in lots of places in the code. so easy 😭
the nesting isn't limited to one level either 👑 there's at least one option that's encapsulated twice: Identity Association for Prefix Delegation (IA_PD), defined in Section 9 of [RFC3633], carries the Identity Association (IA) Prefix (IAPREFIX), defined in Section 10 of [RFC3633]. a delegated prefix can also have an excluded prefix range, represented by the PD_EXCLUDE option, which is encapsulated inside IAPREFIX (PD_EXCLUDE is defined in [RFC6603]) 🌈 saying sub-sub-option or doubly encapsulated option sounds super awkward, so people just say "encapsulated option" no matter how deep it goes ✨
when you're defining a DHCP-based configuration mechanism for a protocol that needs more than a single option, you might feel tempted to group the config values using sub-options 🤔 that's something to preferably avoid, because it makes the parser more complex. parsing a big pile of options on one top-level scope is much easier, faster, and less error prone than parsing options across several scopes 💖 sub-options should be avoided as much as possible, but it's better to use sub-options than conditional formatting 🙈
also, there's currently no clear way defined for requesting sub-options 😬 most known implementations just put the top-level Option Request Option (ORO) in their requests to ask for both top-level and encapsulated options.
10. Additional States Considered Harmful 🚨
DHCP is designed for provisioning clients 🍓 less experienced protocol designers often assume it's easy to define an option that conveys a different parameter for each client in a network. those problems came up during the designs of the Mapping of Address and Port (MAP) [MAP] and IPv4 Residual Deployment (4rd) [SOLUTION-4rd] 😩 sure, it would be easier for provisioned clients to get ready-to-use per-client option values, but that requirement puts exceedingly large loads on the server side 💀 new extensions may bring new implementation complexity and extra database state on the server. so, alternatives should be considered, if possible 🫶
as an example, [MAP] was designed so that all clients get provisioned with the same set of MAP options, and then each provisioned client uses its own unique address and delegated prefix to generate client-specific information 🦋 that means the server doesn't carry any additional state, and it scales way better. iconic 👑
it's also worth noting that, unlike DHCPv4, DHCPv6 keeps several timers for renewals ⏰ each IA_NA (addresses) and IA_PD (prefixes) has T1 and T2 timers that mark when the client will start renewing. those timers only apply to their own IA containers. refreshing other parameters should be started after a time given in the information refresh time option (defined in [RFC4242]), which is carried in the Reply message and returned in response to the Information-request message 🌸 adding more timers makes deployment unnecessarily complex, and SHOULD be avoided 🙅♀️
11. Configuration Changes Occur at Fixed Times ⏳
in general, DHCPv6 clients only refresh their configuration data from the DHCP server when the T1 timer expires 😴 there is a Reconfigure mechanism that lets a DHCP server ask clients to start reconfiguring, but support for it is optional and can't be relied upon. not it 💅
even when DHCP clients do refresh their configuration info, not every consumer of DHCP-sourced config data notices the changes 👀 for instance, if a server starts up using parameters from an early DHCP transaction and never checks DHCP for updates, it may keep using the same parameter forever 💀 a few operating systems handle reconfiguring services when the client moves to a new network (for example, through mechanisms like [RFC4436], [RFC4957], or [RFC6059]). but ngl, a renew doesn't always mean the client actually picks up the new config it receives 🙈
so, when you design an option, keep in mind that your option may end up holding stale data, which only gets updated at some arbitrary time in the future 🫠 plan for it, bestie 🎀
12. Multiple Provisioning Domains 🏠
sometimes there can be more than one DHCPv6 server on a link, and each one provides a different set of parameters 🏘️ a super common example is a home network connected to two independent ISPs.
the DHCPv6 specification doesn't give clear advice on handling multiple provisioning sources 😵💫 [RFC3315] says a client that gets more than one Advertise message may respond to one or more of them, but that capability hasn't really been seen in existing implementations. existing clients just pick one server, keep going with it, and ignore all the others 🙃
also, a node acting as a DHCPv6 client might be connected to more than one physical network 🔌 in most cases, it runs a separate DHCP client state machine on each interface and gets different, possibly conflicting, info through each one. and that info isn't acquired in any synchronized way 😬
existing nodes can't be assumed to systematically separate config info based on where it came from 🤷♀️ so it's totally possible that a node gets an FQDN on one network interface but does the DNS resolution on a different interface, using different DNS servers 💀 because of that, DNS resolution done by the DHCP server is more likely to behave predictably than DNS resolution done on a multi-interface or multihomed client 🔮
this is a generic DHCP issue, so it shouldn't be dealt with inside each option separately 🙅♀️ the better fix is a protocol-level solution, and fixing it shouldn't be attempted on a per-option basis. the IETF is working on a systematic solution to this problem right now 🌈
13. Chartering Requirements and Advice for Responsible Area Directors 📋
adding a simple DHCP option is straightforward, and it's generally something any working group (WG) can do, maybe with some help from designated DHCP experts 🙌 but when new fragment types need to be devised, that needs the attention of DHCP experts, and it should not be done in a WG that doesn't have a quorum of those experts. this is true whether the new fragment type has the same structure as an existing one but with different semantics, or whether the new format has a brand-new structure 🧩
Responsible Area Directors for WGs that want to add a work item to a WG charter to define a new DHCP option should get clarity from the WG first 💁♀️ specifically, whether the new option will need a new fragment type or new semantics, or whether it's a simple DHCP option that fits existing definitions.
if a WG needs a new fragment type, it's preferable to check whether another WG exists whose members already have enough expertise to evaluate the new work 🫶 if one is available, the work should be chartered there instead. if no other WG with DHCP expertise can define the new fragment type, the responsible AD should ask known DHCP experts within the IETF for advice and frequent early review while the original WG defines the new fragment type 🤓
either way, the new option should be defined in a separate document 📄 the work should focus on a new format that generalizes well and can be reused, instead of a single-use fragment type. the WG that needs the new fragment type can define its new option by referencing the new fragment type document, and the work can generally happen in parallel, which avoids unnecessary delays. having the definition in its own document also encourages reuse of the new fragment type 🦋
the responsible AD should work with all relevant WG Chairs and DHCP experts to make sure the new fragment type document has actually been carefully reviewed by the experts and looks satisfactory ✅
Responsible Area Directors for WGs that are considering options that actually update DHCP, as opposed to simple options, should follow a process similar to the one above when figuring out where to do the work 🗺️ and under no circumstances should a WG be given a charter deliverable to define a new DHCP option and then, based on that charter item, actually make updates to DHCP 🚫 that's a big no, periodt 💅
14. Considerations for Creating New Formats 🧁
when you're defining new options, one specific thing to evaluate is whether options of a similar format would need multiple or single values encoded (whatever differs from the current option), and how that could be done in a similar format 🤔
when defining a new option, it's best to synthesize the option format using fragment types that are already in use 🧩 however, in some cases there may be no fragment type that accomplishes the intended purpose, and that's okay, just flag it 🫶
the matters of size considerations and option order are discussed further in Sections 15 and 17 🎀
15. Option Size ✨
okay so DHCPv6 [RFC3315] can handle packets up to 64 KB 😳. first, it uses link-local addresses, so it dodges a lot of the deployment drama that DHCPv4 deals with. honestly it's giving "UDP over IPv6" energy, while DHCPv4 is mostly UDP over IPv4 with some layer-2 hacks 💅. second, RFC 3315 sends you to Section 5 of [RFC2460], which says the MTU is 1280 octets and minimum fragment reassembly is 1500 octets 🧚. so it's totally reasonable to think DHCPv6 could carry bigger options, and no one has actually found a common upper limit yet 🌸. ngl there isn't a fixed number that neatly splits "workable" option sizes from "too big" 🙈
it's always better to pick the option format that carries what you need in the smallest possible form factor 🎀. common sense still applies, bestie. splitting distinct values into separate octets is way better than cooking up super complex bit-shifting to save a few bits (or even an octet or two) that get padded to the next octet boundary anyway 💀
DHCPv6 lets you have multiple instances of the same option, and each one gets treated as its own value following the defined format 🦋. however, this is generally preferred for protocol class features only (like the IA_* series of options). in those cases, it's better to define the option as an array if you can ✨. it is recommended to clarify (with normative language) whether a given DHCPv6 option may appear once or multiple times 💜. the default assumption is only once 🍓
in general, if a LOT of data needs to be configured (like, some option lengths are seriously huge), DHCPv6 may not be the best choice to deliver that config info, and it SHOULD simply be used to deliver a URI that points to where the actual configuration information lives 🌈
16. Singleton Options 👑
okay this one is a whole saga 😭. [RFC3315] says each option type MAY appear more than once, but the original idea was that multiple instances are reserved for stateful options, like IA_NA or IA_PD 🫶. for most other options, it's usually expected that they show up once at most. those are called singleton options. sadly, RFCs have often failed to clearly say whether or not a given option can appear more than once 💀
documents that define new options SHOULD state whether or not those options are singletons 🔥. unless otherwise specified, newly defined options are considered to be singletons. if multiple instances are allowed, the document MUST explain how to use them 💅. care should be taken not to assume they'll be processed in the order they appear in the message. see Section 17 for more details 🧚
when you're deciding whether single or multiple option instances are allowed in a message, think about how the content of the option will actually get used 🌸. depending on the service being configured, it may or may not make sense to have multiple values. if multiple values make sense, it's better to explicitly allow that by using an option format that allows multiple values within one option instance 🎀
allowing multiple option instances often leads to confusion, and this example is the perfect proof 😭. basic DS-Lite architecture assumes that the B4 element (DHCPv6 client) will receive the AFTR option and set up a single tunnel to the configured tunnel termination point (AFTR) ✨. during the standardization process of [RFC6334], people argued about whether multiple instances of the DS-Lite tunnel option should be allowed. this created an unfounded expectation that clients getting multiple instances would somehow know when one tunnel endpoint goes offline and fail over to the values in the other AFTR option instances 💀. others assumed that with multiple options, the client would somehow do load balancing between the provided tunnel endpoints 🙈. neither failover nor load balancing was defined for DS-Lite, so it caused a ton of confusion. it was eventually decided to allow only one instance of the AFTR option 👑
17. Option Order 🦋
okay, option order is a no-go zone 🙅♀️. whether we're talking about the order among many DHCPv6 options or the order of multiple instances of the same option, it SHOULD NOT be significant. new documents MUST NOT assume any specific option processing order 💅
since there's no explicit order for multiple instances of the same option, an option definition SHOULD instead restrict ordering by using a single option that contains ordered fields ✨
as [RFC3315] doesn't impose option order, some implementations use hash tables to store received options (which is totally conformant behavior 🫶). depending on the hash implementation, the processing order is almost always different from the order the options showed up in on the wire 😭
18. Relay Options 🧚
in DHCPv4, all relay options are organized as sub-options within the DHCP Relay Agent Information option [RFC3046] 🌸. there's also an independent number space called "DHCP Relay Agent Sub-options" that IANA maintains. but in DHCPv6 it's different: relay options are defined the same way as client/server options, and they use the same option number space as client/server options 🎀. future DHCPv6 relay options MUST be allocated from this single DHCPv6 option number space 👑
for example, the Relay-Supplied Options option [RFC6422] may also contain some DHCPv6 options as permitted, like the Extensible Authentication Protocol (EAP) Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440] 💜
19. Clients Request Their Options 💖
the DHCPv6 Option Request Option (OPTION_ORO) [RFC3315] is an option with two jobs: it tells the server which options the client supports, and which options the client is willing to consume 🫶
for some options, like the ones needed for DHCPv6 to function at all, it doesn't make sense to require that they be explicitly requested using the Option Request Option 🔥. in all other cases, it's prudent to assume that any new option must be on the relevant option request list if the client wants to receive it 🌈
it's tempting to add text that requires the client to put a new option in the Option Request Option list, something like this: "Clients MUST place the foo option code on the Option Request Option list, clients MAY include option foo in their packets as hints for the server as values the desire, and servers MUST include option foo when the client requests it (and the server has been so configured)". 😭 such text is discouraged, and there are a couple of issues with it. first, it assumes that a client implementation that supports a given option will always want to use it. that's not true 🙈. the second and more important reason is that such text basically duplicates the mechanism already defined in [RFC3315]. it's better to simply refer to the existing mechanism rather than define it again 💅. see Section 21 for proposed examples of how to do that ✨
creators of DHCPv6 options cannot assume any special ordering of options, either as they appear in the Option Request Option or as they appear within the packet 🧚. although it's reasonable to expect that options will be processed in the order they appear in ORO, server software is not required to sort DHCPv6 options into the same order in Reply messages 🎀
it should also be noted that option values are not required to be aligned within the DHCP packet. even the option code and option length may appear on odd-byte boundaries 💀
20. Transition Technologies 🌸
the transition from IPv4 to IPv6 is progressing, and lots of transition technologies have been proposed to speed it up 🚀. as a natural consequence, there are also DHCP options proposed to provision those technologies. the big question is whether the required parameters should be delivered over DHCPv4 or DHCPv6. authors often don't give it much thought and just pick DHCPv6 without realizing the consequences 😬. IPv6 is expected to stick around for many decades, and so is DHCPv6. there's no mechanism available to deprecate an option in DHCPv6, so any options defined will stay with us as long as the DHCPv6 protocol itself lasts. it seems likely that options defined to transition away from IPv4 will outlive IPv4 by many decades 💀. from that perspective, it's better to implement provisioning of the transition technologies in DHCPv4, which will be obsoleted together with IPv4 🦋
when the network infrastructure becomes IPv6 only, support for IPv4-only nodes may still be needed. in that scenario, a mechanism for providing IPv4 configuration information over IPv6-only networks may be needed. see [IPv4-CONFIG] for further details 🫶
21. Recommended Sections in the New Document 🎀
there are three major entities in DHCPv6: server, relay agent, and client. it's super helpful for implementors to include separate sections that describe operation for each of those three entities 🧚. even when a given entity doesn't participate, it's useful to have a very short section stating that it must not send a given option and must ignore it when received 💅
there's also a separate entity called the "requestor", which is a special client-like type that participates in the leasequery protocol [RFC5007] [RFC5460] 👑. a similar section for the requestor is not required, unless the new option has anything to do with the requestor (or the reader might think it does) 🙈. it should be noted that while in most deployments the requestor is co-located with the relay agent, those are two separate entities from the protocol perspective, and they may be used separately. there are stand-alone requestor implementations available 🌈
the following sections include proposed text for such sections. that text is not required to appear, but it's appropriate in most cases. additional or modified text specific to a given option is often required 💖
although the requestor is a somewhat uncommon functionality, its existence should be noted, especially when allowing or disallowing options to appear in certain messages or to be sent by certain entities 🦋. additional message types may appear in the future, besides the types defined in [RFC3315]. so authors are encouraged to get familiar with the list of currently defined DHCPv6 messages on the IANA website [IANA] ✨
typically, new options are requested by clients and assigned by the server, so there's no specific relay behavior. still, it's good to include a section for relay agent behavior that simply states there are no additional requirements for relays 🫶. the same goes for client behavior if the options are to be exchanged between the relay and server 🌸
sections that contain option definitions MUST include a formal verification procedure 🔥. often it's very simple, e.g., an option that conveys an IPv6 address must be exactly 16 bytes long, but sometimes the rules are more complex. it is recommended to refer to existing documents (e.g., Section 8 of RFC 3315 for domain name encoding) rather than trying to repeat those rules 😭💅
21.1. DHCPv6 Client Behavior Text 💖
Okay so, Clients MAY request option foo 🎀 as defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. Just so you know, clients put the codes they want into the Option Request Option. ✨
Optional text (if the client's hints make sense): The client also MAY include option foo in its Solicit, Request, Renew, Rebind, and Information-request messages as a hint for the server about preferred option values. 🧚
Optional text (if the option contains an FQDN): If the client requests an option that carries an FQDN, the contents of that option get resolved using DNS 🌸. So this text might be useful: Clients that request option foo SHOULD also request option OPTION_DNS_SERVERS as specified in [RFC3646]. 🫶
Clients MUST discard option foo if it's invalid (aka it didn't pass the validation steps defined in Section X.Y). No cap, that's a must-do 💀.
Optional text (if option foo is expected to be exchanged between relays and servers): Option foo is exchanged between relays and servers only. Clients aren't aware of option foo at all 🙈. Clients MUST ignore received option foo.
21.2. DHCPv6 Server Behavior Text 🍓
Sections 17.2.2 and 18.2 of [RFC3315] are the ones that run the show when it comes to server operation and option assignment 👑. Quick heads up: the server will send option foo only if it's configured with specific values for foo and the client asked for it.
Optional text: Option foo is a singleton, bestie. Servers MUST NOT send more than one instance of the foo option. One and done 💅.
Optional text (if the server is never supposed to receive option foo): Servers MUST ignore the incoming foo option. It's giving "not for you" energy 🙅♀️.
21.3. DHCPv6 Relay Agent Behavior Text ✨
It's never appropriate for a relay agent to add options to a message heading toward the client, and relay agents don't actually construct Relay-reply messages anyway 🦋. Not their job, periodt.
Optional text (if the foo option is exchanged between the clients and server or between requestors and servers): There are no additional requirements for relays here 🌈.
Optional text (if relays are expected to insert or consume option foo): Relay agents MAY include option foo in a Relay-forward message when they're forwarding packets from clients to the servers. Main character relay behavior 🎀.
22. Should the New Document Update Existing RFCs? 🤔
Okay, authors ask themselves this all the time, especially about RFC 3315 💭. In April 2013 there were about 80 options defined. If every document that defined one had also updated RFC 3315, understanding that whole document set would be extremely difficult 😭. Also, "extends" and "updates" are two very different verbs, bestie. If a new document defines a new option that clients request and servers provide, it just extends the current standards, so "updates RFC 3315" isn't required in the new document header 💖. But if a new document replaces or modifies existing behavior and includes clarifications or other corrections, it should be noted that it updates the other document ✨. For example, [RFC6644] clearly updates [RFC3315] because it replaces existing text with new text 🔥.
If you're in doubt, ask yourself whether an implementor reading only the base RFC (without reading the new document) could properly implement the software 🧠. If the base RFC is sufficient, the new document probably doesn't update the base RFC. But if you need to read your new document to properly implement the base RFC, then the new document most likely updates the base RFC 🫶.
23. Security Considerations 🔐
Okay, this part is serious, so let's go 😤. DHCPv6 does have an authentication mechanism [RFC3315] that lets DHCPv6 software tell authentic endpoints apart from man-in-the-middle attackers. Other authentication mechanisms may optionally be deployed. Sadly, as of 2014, the authentication in DHCPv6 is rarely used, and support for it isn't common in existing implementations 💀. Some specific deployment types make it mandatory (or parts of it do, e.g., DOCSIS3.0-compatible cable modems require reconfigure-key support), so in certain cases specific authentication aspects can be relied upon. That is not true in the generic case, though 🙈.
So, when you create a new option, it's prudent to assume that DHCPv6 packet contents are always transmitted in the clear 🚨. Actual production use of the software will probably be vulnerable at least to man-in-the-middle attacks from within the network, even where the network itself is protected from external attacks by firewalls. Especially since some DHCPv6 message exchanges go to multicast addresses that are likely broadcast anyway 📢.
If an option has a specific fixed length, it's useful to remind the implementor of the option data's full length 📏. The easy way to do this is to declare the specific value of the length tag of the option. That gently reminds implementors to validate the option length before copying it into likewise fixed-length regions of memory or stack 🧸.
If an option may be of variable size (like indeterminate length fields such as domain names or text strings), it's advisable to explicitly remind the implementor to be aware of the potential for long options 🧵. Either define a reasonable upper limit (and suggest validating it), or explicitly remind the implementor that an option may be exceptionally long, so they're prepared to handle errors rather than truncate values 🫠.
For some option contents, out-of-bound values may be used to breach security 🕵️♀️. An IP address field might be made to carry a loopback address or a local multicast address, and depending on the protocol, this may lead to undesirable results 😬. A domain name field may be filled with contrived contents that exceed the limitations placed on domain name formatting. Since this value is possibly delivered to "internal configuration" records of the system, it may be implicitly trusted without being validated 🚩.
So, authors of documents defining new DHCP options are strongly advised to explicitly define the validation measures that recipients of such options are required to perform before processing them 🛡️. However, validation measures already defined by RFC 3315 or other specifications referenced by the new option document are redundant and can introduce errors. So authors are equally strongly advised to refer to the base specification for that validation language, rather than copying it into the new specification 💅.
See also Section 24 🎀.
24. Privacy Considerations 🕶️
As discussed in Section 23, DHCPv6 packets are typically transmitted in the clear, so they're susceptible to eavesdropping 👀. This should be considered when defining options that may convey personally identifying information (PII) or any other type of sensitive data 🫣.
If sending sensitive or confidential content is required, it's still possible to secure communication between relay agents and servers 🔒. Relay agents, and servers communicating with relay agents, must support the use of IPsec Encapsulating Security Payload (ESP) with encryption in transport mode, according to Section 3.1.1 of [RFC4303] and Section 21.1 of [RFC3315] ✨. Sadly, this requirement is almost universally ignored in real deployments 😭. Even if the communication path between the relay agents and server is secured, the path between the clients and relay agents or server is not.
⚠️ Heads up, bestie: Unless the underlying transmission technology provides a secure transmission channel, the DHCPv6 options SHOULD NOT include PII or other sensitive information. If there are special circumstances that warrant sending such information over unsecured DHCPv6, the dangers MUST be clearly discussed in the security considerations. No skipping this one! 🚫
25. Acknowledgements 🫶
The authors would like to thank Simon Perreault, Bernie Volz, Ted Lemon, Bud Millwood, Ralph Droms, Barry Leiba, Benoit Claise, Brian Haberman, Richard Barnes, Stephen Farrell, and Stewart Bryant for their comments. Thank you, queens 👑💜.
26. References 📚
26.1. Normative References 🌟
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
26.2. Informative References 📚✨
okay bestie, this is the "read these too if you're curious" pile 🧚 they're not required to implement the spec, but they're the receipts for everything DHCPv6 is borrowing from. every entry stays exactly as written:
[IANA] IANA, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)",
<http://www.iana.org/assignments/dhcpv6-parameters/>.
[IPv4-CONFIG]
Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration
Over IPv6 Only Networks", Work in Progress, February 2014.
[MAP] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
configuration of Softwire Address and Port Mapped
Clients", Work in Progress, March 2014.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol
(SIP) Servers", RFC 3319, July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3898] Kalusivalingam, V., "Network Information Service (NIS)
Configuration Options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet
Addresses Considered Harmful", BCP 105, RFC 4085, June
2005.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
Configuration Protocol (DHCP) Options for Broadcast and
Multicast Control Servers", RFC 4280, November 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006.
[RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC
4833, April 2007.
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
and A. Yegin, "Link-Layer Event Notifications for
Detecting Network Attachments", RFC 4957, August 2007.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009.
[RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP)
Server Option for DHCPv6", RFC 5908, June 2010.
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", RFC 5970, September 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, September
2010.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, November
2010.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011.
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC
6422, December 2011.
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
December 2011.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012.
[RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T.
Lemon, "DHCP Options for Home Information Discovery in
Mobile IPv6 (MIPv6)", RFC 6610, May 2012.
[RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in
DHCPv6 Reconfigure Messages", RFC 6644, July 2012.
[SOLUTION-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", Work in Progress, October 2013.Authors' Addresses 💌
the squad behind this doc, with their contact info so you can slide into their inbox 🫶
David W. Hankins
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
EMail: dhankins@google.com
Tomek Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1-650-423-1345
EMail: tomasz.mrugalski@gmail.com
Marcin Siodelski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1-650-423-1431
EMail: msiodelski@gmail.com
Sheng Jiang
Huawei Technologies Co., Ltd.
Q14, Huawei Campus, No. 156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
EMail: jiangsheng@huawei.com
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
EMail: suresh.krishnan@ericsson.com📦 where this page comes from
- ietf: rfc7227 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms