RFC 9445
RADIUS Extensions for DHCP-Configured Services
RFC 9445: RADIUS Extensions for DHCP-Configured Services ✨
Okay bestie, let's start with the title block 🎀. This is RFC 9445, called RADIUS Extensions for DHCP-Configured Services. It's an IETF doc (Internet Engineering Task Force) written by M. Boucadair (Orange), T. Reddy.K (Nokia), and A. DeKok (FreeRADIUS) 💅. It's a Standards Track doc 🔥, dated August 2023 🌸, with ISSN 2070-1721. It updates RFC 4014 👑, and the header doesn't list anything it obsoletes.
Abstract 💖
Okay, so this doc specifies two new Remote Authentication Dial-In User Service (RADIUS) attributes that carry DHCP options 🦋. The whole thing is super generic, so it can apply to any service that relies on DHCP 🧚. Both DHCPv4- and DHCPv6-configured services are covered ✨.
Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUS attributes in the RADIUS Attributes DHCP suboption 💅.
Status of This Memo 🌈
This is an Internet Standards Track document.
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 Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9445.
Copyright Notice 🎀
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents 🧚
1. Introduction
2. Terminology
3. RADIUS DHCP Options Attributes
3.1. DHCPv6-Options Attribute
3.2. DHCPv4-Options Attribute
4. Passing RADIUS DHCP Options Attributes by DHCP Relay Agents to
DHCP Servers
4.1. Context
4.2. Updates to RFC 4014
4.2.1. Section 3 of RFC 4014
4.2.2. Section 4 of RFC 4014
5. An Example: Applicability to Encrypted DNS Provisioning
6. Security Considerations
7. Table of Attributes
8. IANA Considerations
8.1. New RADIUS Attributes
8.2. New RADIUS Attribute Permitted in DHCPv6 RADIUS Option
8.3. RADIUS Attributes Permitted in RADIUS Attributes DHCP
Suboption
8.4. DHCP Options Permitted in the RADIUS DHCP*-Options
Attributes
8.4.1. DHCPv6
8.4.2. DHCPv4
8.4.3. Guidelines for the Designated Experts
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌸
Okay, so in the world of broadband 🌐, Internet Service Providers (ISPs) usually hand DNS resolvers out to their customers 💅. To do that, they use dedicated mechanisms, like DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement [RFC4861], to advertise a list of DNS recursive servers 🎀. The info used to fill those DHCP messages and/or IPv6 Router Advertisements usually comes from specific Remote Authentication Dial-In User Service (RADIUS) [RFC2865] attributes, such as the DNS-Server-IPv6-Address Attribute specified in [RFC6911] ✨.
Now, encrypted DNS is the moment 🔥. We've got DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], and DNS over QUIC (DoQ) [RFC9250], and they need extra ways to provision hosts with network-designated encrypted DNS 🦋. To fill that gap, [DNR] leans on existing protocols like DHCP to give hosts the info they need to connect to an encrypted DNS resolver 🧚. The problem? There are no RADIUS attributes that can populate the discovery messages discussed in [DNR] 💀. And honestly, the same issue is likely to pop up for future services configured with DHCP 🙈.
This document specifies two new RADIUS attributes: DHCPv6-Options (Section 3.1) and DHCPv4-Options (Section 3.2) 💖. They can include DHCP options listed in the "DHCPv6 Options Permitted in the RADIUS DHCPv6-Options Attribute" registry (Section 8.4.1) and the "DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute" registry (Section 8.4.2) 🎀. Both are designed to work for IPv4 and IPv6 deployments, while taking into account the constraints in Section 3.4 of [RFC6158] ✨.
The mechanism here is generic, and it might be used in network scenarios where the DHCP server and the RADIUS client live in the same device 👑. The new attributes can also be used in deployments that rely on the mechanisms defined in [RFC4014] or [RFC7037]. Those let a DHCP relay agent that's collocated with a RADIUS client pass attributes it got from a RADIUS server over to a DHCP server 🌈. However, an update to [RFC4014] is required so a DHCP relay agent can pass the DHCPv4-Options Attribute it got from a RADIUS server to a DHCP server (Section 4) 💅.
DHCP options included in the new RADIUS attributes can be controlled by a deployment-specific policy 🧚. Discussing that policy is out of scope 🙈.
This document adheres to [RFC8044] for defining the new attributes 🦋.
A sample deployment usage of the RADIUS DHCPv6-Options and DHCPv4-Options Attributes is described in Section 5 ✨.
2. Terminology 🎀
Okay, so 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 💅.
This document makes use of the terms defined in [RFC2865], [RFC8415], and [RFC8499]. The following additional terms are used:
- DHCP: refers to both DHCPv4 [RFC2132] and DHCPv6 [RFC8415] 🌸.
- Encrypted DNS: refers to a scheme where DNS exchanges are transported over an encrypted channel. Examples of encrypted DNS are DoT, DoH, and DoQ 🔐.
- Encrypted DNS resolver: refers to a resolver (Section 6 of [RFC8499]) that supports encrypted DNS 💖.
- DHCP*-Options: refers to the DHCPv4-Options and DHCPv6-Options Attributes (Section 3) 🧚.
3. RADIUS DHCP Options Attributes 🦋
Okay, this section specifies two new RADIUS attributes that RADIUS clients and servers use to swap DHCP-encoded data ✨. That data then feeds the DHCP procedure between a DHCP client and a DHCP server 👑.
Both the DHCPv4-Options and DHCPv6-Options Attributes use the "Long Extended Type" format (Section 2.2 of [RFC6929]) 🌈. The fields are described in Sections 3.1 and 3.2 🎀.
These attributes use the "Long Extended Type" format so they can carry attributes encapsulating more than 253 octets of data 🔥. DHCP options that can be included in the RADIUS DHCP*-Options Attributes are limited by the maximum packet size of 4096 bytes (Section 3 of [RFC2865]) 💀. To accommodate deployments with large DHCP options, RADIUS implementations are RECOMMENDED to support a packet size up to 65535 bytes 🌸. That recommendation can be met if RADIUS implementations support a mechanism that relaxes the 4096-byte limit (for example, the mechanisms described in [RFC7499] or [RFC7930]) ✨.
The Value fields of the DHCP*-Options Attributes are encoded in the clear and are not encrypted, unlike, for example, the Tunnel-Password Attribute [RFC2868] 🙈.
RADIUS implementations may support a configuration parameter to control the DHCP options that can be included in a RADIUS DHCP*-Options Attribute. Likewise, DHCP server implementations may support a configuration parameter to control the permitted DHCP options in a RADIUS DHCP*-Options Attribute. Absent explicit configuration, RADIUS implementations and DHCP server implementations SHOULD ignore non-permitted DHCP options received in a RADIUS DHCP*-Options Attribute 💅.
RADIUS-supplied data is specific configuration data that is returned as a function of authentication and authorization checks. So, absent any explicit configuration on the DHCP server, RADIUS-supplied data carried by the DHCP*-Options Attributes takes precedence over any local configuration 👑.
These attributes are defined with globally unique names. Their naming follows the guidelines in Section 2.7.1 of [RFC6929], and invalid attributes are handled as per Section 2.8 of [RFC6929] 🎀.
3.1. DHCPv6-Options Attribute 🧚
This attribute is of type "string" as defined in Section 3.5 of [RFC8044] 💖.
The DHCPv6-Options Attribute MAY appear in a RADIUS Access-Accept packet. It MAY also appear in a RADIUS Access-Request packet as a hint to the RADIUS server to indicate a preference. However, the server is not required to honor such a preference 🌈.
The DHCPv6-Options Attribute MAY appear in a RADIUS CoA-Request packet 🦋.
The DHCPv6-Options Attribute MAY appear in a RADIUS Accounting-Request packet ✨.
The DHCPv6-Options Attribute MUST NOT appear in any other RADIUS packet 🔥.
The DHCPv6-Options Attribute is structured as follows 🌸:
- Type: the value is
245🎀. - Length: this field indicates the total length, in octets, of all fields of this attribute, including the Type, Length, Extended-Type, and Value fields 💅.
- Extended-Type: the value is
3(see Section 8.1) 👑. - Value: this field contains a list of DHCPv6 options (Section 21 of [RFC8415]). Multiple instances of the same DHCPv6 option MAY be included. If an option appears multiple times, each instance is considered separate, and the data areas of the options MUST NOT be concatenated or otherwise combined. Consistent with Section 17 of [RFC7227], this document does not impose any option order when multiple options are present 🧚.
The permitted DHCPv6 options are listed in the DHCPv6 Options Permitted in the RADIUS DHCPv6-Options Attribute registry (Section 8.4.1) 💖.
The DHCPv6-Options Attribute is associated with the following identifier: 245.3 ✨.
3.2. DHCPv4-Options Attribute 🎀
okay so this attribute is type "string", as defined in Section 3.5 of [RFC8044] 💅
The DHCPv4-Options Attribute MAY show up in a RADIUS Access-Accept packet. It MAY also appear in a RADIUS Access-Request packet as a hint to the RADIUS server that says "this is what I'd prefer" 🥺 However, the server is not required to honor such a preference, so it's totally up to them ✨
The DHCPv4-Options Attribute MAY appear in a RADIUS CoA-Request packet. 🦋
The DHCPv4-Options Attribute MAY appear in a RADIUS Accounting-Request packet. 📊
The DHCPv4-Options Attribute MUST NOT appear in any other RADIUS packet. Not even once, bestie 🙅♀️
Here's how it's laid out 👀
Type245
Length- This field indicates the total length, in octets, of all fields of this attribute, including the
Type,Length,Extended-Type, andValuefields. 📏
- This field indicates the total length, in octets, of all fields of this attribute, including the
Extended-Type4(see Section 8.1)
Value- This field contains a list of DHCPv4 options. Multiple instances of the same DHCPv4 option MAY be included, especially for concatenation-requiring options that exceed the maximum DHCPv4 option size of 255 octets. 🧩 The mechanism specified in [RFC3396] MUST be used for splitting and concatenating the instances of a concatenation-requiring option. No skipping this step!! 😭
- The permitted DHCPv4 options are listed in the "DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute" registry (Section 8.4.2). 📚
The DHCPv4-Options Attribute is associated with the following identifier: 245.4 🔥
4. Passing RADIUS DHCP Options Attributes by DHCP Relay Agents to DHCP Servers ✨
4.1. Context
okay context time 🧠 The RADIUS Attributes DHCP suboption [RFC4014] lets a DHCPv4 relay agent pass identification and authorization attributes that it got during RADIUS authentication over to a DHCPv4 server. The catch is that [RFC4014] defines a frozen set of RADIUS attributes that can go into that suboption, and honestly that's kinda suboptimal 🙄 It gets especially annoying when new services roll out, like support for encrypted DNS [DNR] 🔒
So Section 4.2 updates [RFC4014] by relaxing that constraint and letting additional RADIUS attributes be tagged as permitted in the RADIUS Attributes DHCP suboption. The permitted attributes are registered in the new "RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption" registry (Section 8.3) 🎉
4.2. Updates to RFC 4014
4.2.1. Section 3 of RFC 4014
This document updates Section 3 of [RFC4014] as follows:
OLD:
| To avoid dependencies between the address allocation and other
| state information between the RADIUS server and the DHCP server,
| the DHCP relay agent SHOULD include only the attributes in the
| table below in an instance of the RADIUS Attributes suboption.
| The table, based on the analysis in RFC 3580 [8], lists attributes
| that MAY be included:
|
| # Attribute
| --- ---------
| 1 User-Name (RFC 2865 [3])
| 6 Service-Type (RFC 2865)
| 26 Vendor-Specific (RFC 2865)
| 27 Session-Timeout (RFC 2865)
| 88 Framed-Pool (RFC 2869)
| 100 Framed-IPv6-Pool (RFC 3162 [7])NEW:
| To avoid dependencies between the address allocation and other
| state information between the RADIUS server and the DHCP server,
| the DHCP relay agent SHOULD only include the attributes in the
| "RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption"
| registry (Section 8.3 of [RFC9445]) in an instance of the RADIUS
| Attributes DHCP suboption. The DHCP relay agent may support a
| configuration parameter to control the attributes in a RADIUS
| Attributes DHCP suboption.4.2.2. Section 4 of RFC 4014
This document updates Section 4 of [RFC4014] as follows:
OLD:
| If the relay agent relays RADIUS attributes not included in the
| table in Section 4, the DHCP server SHOULD ignore them.NEW:
| If the relay agent relays RADIUS attributes not included in the
| "RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption"
| registry (Section 8.3 of [RFC9445]) and explicit configuration is
| absent, the DHCP server SHOULD ignore them.5. An Example: Applicability to Encrypted DNS Provisioning 🌈
Typical deployment scenarios are similar to the ones described in Section 2 of [RFC6911] 🧚 For illustration purposes, Figure 1 shows an example where a Customer Premises Equipment (CPE) gets handed an encrypted DNS resolver. This example assumes that the Network Access Server (NAS) has both RADIUS client and DHCPv6 server capabilities built in 💅
+-------------+ +-------------+ +-------+
| CPE | | NAS | | AAA |
|DHCPv6 Client| |DHCPv6 Server| |Server |
| | |RADIUS Client| | |
+------+------+ +------+------+ +---+---+
| | |
o-----DHCPv6 Solicit----->| |
| o----Access-Request ---->|
| | |
| |<----Access-Accept------o
| | DHCPv6-Options |
|<----DHCPv6 Advertise----o (OPTION_V6_DNR) |
| (OPTION_V6_DNR) | |
| | |
o-----DHCPv6 Request----->| |
| | |
|<------DHCPv6 Reply------o |
| (OPTION_V6_DNR) | |
| | |
DHCPv6 RADIUS
Figure 1: An Example of RADIUS IPv6 Encrypted DNS ExchangeSo here's the flow 👀 When the NAS gets a DHCPv6 Solicit message from a CPE, it sends a RADIUS Access-Request message to the Authentication, Authorization, and Accounting (AAA) server. Once the AAA server gets that request, it replies with an Access-Accept message (possibly after sending a RADIUS Access-Challenge message, and assuming the CPE is entitled to connect to the network) 🙌 That Access-Accept carries a list of parameters for this session, and that list includes the encrypted DNS information. That info is encoded as OPTION_V6_DNR (144) instances [DNR] in the RADIUS DHCPv6-Options Attribute. The NAS then uses these instances to finish the DHCPv6 procedure the CPE started to get info about which encrypted DNS service to use. After that, the Discovery of Network-designated Resolvers (DNR) procedure defined in [DNR] gets followed between the DHCPv6 client and the DHCPv6 server ✨
Now, should any encrypted DNS-related information change (for example, the Authentication Domain Name (ADN) or the IPv6 address), the RADIUS server sends a RADIUS Change-of-Authorization (CoA) message [RFC5176] that carries the DHCPv6-Options Attribute with the updated OPTION_V6_DNR information to the NAS 🔄 Once the NAS receives and validates that message, it replies with a RADIUS CoA ACK message. The NAS then swaps the old encrypted DNS resolver info for the new one, and sends a DHCPv6 Reconfigure message. That leads the DHCPv6 client to start a Renew/Reply message exchange with the DHCPv6 server 💖
In deployments where the NAS acts as a DHCPv6 relay agent, the procedure discussed in Section 3 of [RFC7037] can be followed. To that aim, the "RADIUS Attributes Permitted in DHCPv6 RADIUS Option" registry has been updated (Section 8.2). CoA-Requests can be used following the procedure specified in [RFC6977] 🧾
Figure 2 shows another example where a CPE is provided with an encrypted DNS resolver, but this time the CPE uses DHCPv4 to retrieve its encrypted DNS resolver 🦄
+-------------+ +-------------+ +-------+
| CPE | | NAS | | AAA |
|DHCPv4 Client| |DHCPv4 Server| |Server |
| | |RADIUS Client| | |
+------+------+ +------+------+ +---+---+
| | |
o------DHCPDISCOVER------>| |
| o----Access-Request ---->|
| | |
| |<----Access-Accept------o
| | DHCPv4-Options |
|<-----DHCPOFFER----------o (OPTION_V4_DNR) |
| (OPTION_V4_DNR) | |
| | |
o-----DHCPREQUEST-------->| |
| (OPTION_V4_DNR) | |
| | |
|<-------DHCPACK----------o |
| (OPTION_V4_DNR) | |
| | |
DHCPv4 RADIUS
Figure 2: An Example of RADIUS IPv4 Encrypted DNS ExchangeOther deployment scenarios can be envisaged too 🌸 For example, you could return customized service parameters (like different DoH URI Templates) depending on the service, policies, and preferences that a network administrator sets. How an administrator indicates its service, policies, and preferences to a AAA server is out of scope for this doc, so we're leaving that one alone 🙈
6. Security Considerations 🔐
RADIUS-related security considerations are discussed in [RFC2865] 🛡️
DHCPv6-related security issues are discussed in Section 22 of [RFC8415], while DHCPv4-related security issues are discussed in Section 7 of [RFC2131]. Security considerations specific to the DHCP options that are carried in RADIUS are discussed in the relevant documents that specify those options. For example, security considerations (including traffic theft) are discussed in Section 7 of [DNR] 😱 Traffic theft, bestie, this is serious!!
RADIUS servers have conventionally tolerated the input of arbitrary data via the "string" data type (Section 3.5 of [RFC8044]). This practice lets RADIUS servers support newer standards without software upgrades, by letting administrators manually create complex attribute content and then pass that content to a RADIUS server as opaque strings. While this practice is useful, it is RECOMMENDED that RADIUS servers that implement the present specification are updated to understand the format and encoding of DHCP options. Administrators can then enter the DHCP options as options, instead of manually encoded opaque strings 🙌 This recommendation increases security and interoperability by ensuring that the options are encoded correctly. It also makes life way easier for administrators 💜
The considerations discussed in Section 7 of [RFC4014] and Section 8 of [RFC7037] should be taken into account in deployments where DHCP relay agents pass the DHCP*-Options Attributes to DHCP servers ⚠️ Additional considerations specific to the use of Reconfigure messages are discussed in Section 9 of [RFC6977] 🫶
7. Table of Attributes 💖
okay so this table is basically the cheat sheet for which RADIUS packets are allowed to carry these attributes and how many of each 🎀 Read it like a little map and you'll be fine 🗺️✨
+=============+=======+=========+===========+=====+================+
| Access- |Access-| Access- | Challenge |# | Attribute |
| Request |Accept | Reject | | | |
+=============+=======+=========+===========+=====+================+
| 0+ |0+ | 0 | 0 |245.3| DHCPv6-Options |
+-------------+-------+---------+-----------+-----+----------------+
| 0+ |0+ | 0 | 0 |245.4| DHCPv4-Options |
+=============+=======+=========+===========+=====+================+
| Accounting- |CoA- | CoA-ACK | CoA-NACK |# | Attribute |
| Request |Request| | | | |
+=============+=======+=========+===========+=====+================+
| 0+ |0+ | 0 | 0 |245.3| DHCPv6-Options |
+-------------+-------+---------+-----------+-----+----------------+
| 0+ |0+ | 0 | 0 |245.4| DHCPv4-Options |
+-------------+-------+---------+-----------+-----+----------------+
Table 1: Table of AttributesThe notation for Table 1 is super simple 🫶
0: This attribute MUST NOT be present in packet. Hard no, bestie 🙅♀️0+: Zero or more instances of this attribute MAY be present in packet. Go wild (within reason) 🦋
8. IANA Considerations 🌈
8.1. New RADIUS Attributes
okay so IANA gave us two brand new RADIUS attribute types in the "Radius Attribute Types" [RADIUS-Types] registry, and honestly they're iconic 👑
+=======+================+===========+===========+
| Value | Description | Data Type | Reference |
+=======+================+===========+===========+
| 245.3 | DHCPv6-Options | string | RFC 9445 |
+-------+----------------+-----------+-----------+
| 245.4 | DHCPv4-Options | string | RFC 9445 |
+-------+----------------+-----------+-----------+
Table 2: New RADIUS Attributes8.2. New RADIUS Attribute Permitted in DHCPv6 RADIUS Option
so IANA added one new entry to the "RADIUS Attributes Permitted in DHCPv6 RADIUS Option" subregistry, which lives inside the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry [DHCPv6] 🍓
+===========+================+===========+
| Type Code | Attribute | Reference |
+===========+================+===========+
| 245.3 | DHCPv6-Options | RFC 9445 |
+-----------+----------------+-----------+
Table 3: New RADIUS Attribute
Permitted in DHCPv6 RADIUS Option8.3. RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption
IANA made a whole new subregistry called "RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption", tucked inside the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters" registry [BOOTP] 🧚
The allocation policy for this subregistry is "Expert Review" (Section 4.5 of [RFC8126]). ngl this is a big deal, so designated experts should carefully consider the security implications of letting a relay agent put new RADIUS attributes in here 🔥 More on that in Section 8.4.3.
The designated experts really need to think hard about security here. Letting relay agents add new RADIUS attributes is powerful stuff, so don't rubber-stamp it 🙈
The starting contents of this subregistry are in Table 4. The Reference field points to whichever document registers or specifies the attribute 📚
+===========+==================+===========+
| Type Code | Attribute | Reference |
+===========+==================+===========+
| 1 | User-Name | [RFC2865] |
+-----------+------------------+-----------+
| 6 | Service-Type | [RFC2865] |
+-----------+------------------+-----------+
| 26 | Vendor-Specific | [RFC2865] |
+-----------+------------------+-----------+
| 27 | Session-Timeout | [RFC2865] |
+-----------+------------------+-----------+
| 88 | Framed-Pool | [RFC2869] |
+-----------+------------------+-----------+
| 100 | Framed-IPv6-Pool | [RFC3162] |
+-----------+------------------+-----------+
| 245.4 | DHCPv4-Options | RFC 9445 |
+-----------+------------------+-----------+
Table 4: Initial Contents of RADIUS
Attributes Permitted in RADIUS
Attributes DHCP Suboption Registry8.4. DHCP Options Permitted in the RADIUS DHCP*-Options Attributes
8.4.1. DHCPv6
IANA made a new subregistry called "DHCPv6 Options Permitted in the RADIUS DHCPv6-Options Attribute", living in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry [DHCPv6] 💅
Registration for this one is also "Expert Review" (Section 4.5 of [RFC8126]). Check Section 8.4.3 for the juicy details ✨
The starting content is in Table 5. The Value and Description fields copy the ones in the "Option Codes" subregistry of [DHCPv6], so they match. The Reference field says which document registers or specifies the option 🎀
+=======+===============+===========+
| Value | Description | Reference |
+=======+===============+===========+
| 144 | OPTION_V6_DNR | RFC 9445 |
+-------+---------------+-----------+
Table 5: Initial Content of
DHCPv6 Options Permitted in the
RADIUS DHCPv6-Options Attribute
Registry8.4.2. DHCPv4
IANA also made a subregistry called "DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute", living in the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters" registry [BOOTP] 🦋
The registration policy is Expert Review (Section 4.5 of [RFC8126]), and again Section 8.4.3 has the details 🌸
The starting content is in Table 6. The Tag and Name fields echo the ones in the "BOOTP Vendor Extensions and DHCP Options" subregistry of [BOOTP]. The Reference field tells you which document registers or specifies the option 💜
+=====+===============+===========+
| Tag | Name | Reference |
+=====+===============+===========+
| 162 | OPTION_V4_DNR | RFC 9445 |
+-----+---------------+-----------+
Table 6: Initial Content of
DHCPv4 Options Permitted in the
RADIUS DHCPv4-Options Attribute
Registry8.4.3. Guidelines for the Designated Experts
it's suggested that you get multiple designated experts for registry change requests, so nobody's stuck doing it solo 🫶
The designated experts should check whether a proposed registration duplicates something already there, and whether the description is clear and fits what this registry is for 🔍
Registration requests go to <radius-dhcp-review@ietf.org>. They get a three-week review period, with advice from one or more designated experts. During that window, the experts either approve or deny the request and tell the review list and IANA what they decided. If something gets denied, they should explain why and, if it makes sense, suggest how to make the request work next time 🌈
9. References ⭐
9.1. Normative References
Here's the full reference list, copied exactly so nothing gets lost 📚
[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/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[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/info/rfc3396>.
[RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication Dial-
In User Service (RADIUS) Attributes Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent
Information Option", RFC 4014, DOI 10.17487/RFC4014,
February 2005, <https://www.rfc-editor.org/info/rfc4014>.
[RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011,
<https://www.rfc-editor.org/info/rfc6158>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013,
<https://www.rfc-editor.org/info/rfc6929>.
[RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044,
DOI 10.17487/RFC8044, January 2017,
<https://www.rfc-editor.org/info/rfc8044>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.9.2. Informative References 📚
Okay, these are the informative ones, bestie. They're not required reading to implement, but they're the background you'll want 🧚
- [BOOTP] IANA, "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters",
https://www.iana.org/assignments/bootp-dhcp-parameters. - [DHCPv6] IANA, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
https://www.iana.org/assignments/dhcpv6-parameters. - [DNR] 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)", Work in Progress, Internet-Draft, draft-ietf-add-dnr-16, 27 April 2023,
https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-16. - [RADIUS-Types] IANA, "RADIUS Types",
http://www.iana.org/assignments/radius-types. - [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997,
https://www.rfc-editor.org/info/rfc2131. - [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/info/rfc2132. - [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, DOI 10.17487/RFC2868, June 2000,
https://www.rfc-editor.org/info/rfc2868. - [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000,
https://www.rfc-editor.org/info/rfc2869. - [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, DOI 10.17487/RFC3162, August 2001,
https://www.rfc-editor.org/info/rfc3162. - [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007,
https://www.rfc-editor.org/info/rfc4861. - [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, January 2008,
https://www.rfc-editor.org/info/rfc5176. - [RFC6911] Dec, W., Ed., Sarikaya, B., Zorn, G., Ed., Miles, D., and B. Lourdelet, "RADIUS Attributes for IPv6 Access Networks", RFC 6911, DOI 10.17487/RFC6911, April 2013,
https://www.rfc-editor.org/info/rfc6911. - [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 Reconfiguration from Relay Agents", RFC 6977, DOI 10.17487/RFC6977, July 2013,
https://www.rfc-editor.org/info/rfc6977. - [RFC7037] Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October 2013,
https://www.rfc-editor.org/info/rfc7037. - [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
https://www.rfc-editor.org/info/rfc7227. - [RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/RFC7499, April 2015,
https://www.rfc-editor.org/info/rfc7499. - [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016,
https://www.rfc-editor.org/info/rfc7858. - [RFC7930] Hartman, S., "Larger Packets for RADIUS over TCP", RFC 7930, DOI 10.17487/RFC7930, August 2016,
https://www.rfc-editor.org/info/rfc7930. - [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
https://www.rfc-editor.org/info/rfc8484. - [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019,
https://www.rfc-editor.org/info/rfc8499. - [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022,
https://www.rfc-editor.org/info/rfc9250.
Acknowledgements 🫶
Huge thanks to Christian Jacquenet, Neil Cook, Joe Clarke, Qin Wu, Dirk von-Hugo, Tom Petch, and Chongfeng Xie for reviewing and suggesting changes. You all made this so much better 💖
Thanks to Ben Schwartz and Bernie Volz for the comments 🌸
Thanks to Rob Wilton for the careful AD review 🎀
Thanks to Ralf Weber for the dnsdir reviews, Robert Sparks for the genart review, and Tatuya Jinmei for the intdir review 💅
Thanks to Éric Vyncke, Paul Wouters, and Warren Kumari for the IESG review 👑
Authors' Addresses 💌
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K
Nokia
India
Email: kondtir@gmail.com
Alan DeKok
FreeRADIUS
Email: aland@freeradius.org📦 where this page comes from
- ietf: rfc9445 2023-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms