RADIUS Extensions for DHCP-Configured ServicesOrangeRennes35000Francemohamed.boucadair@orange.comNokiaIndiakondtir@gmail.comFreeRADIUSaland@freeradius.org
ops
opsawgredirectionsubscriber policiesdifferentiated serviceDNSDoHDoTDoQQUICEncryptionService deliveryService provisioningservice activationpoliciesconnectivityThis document specifies two new Remote Authentication Dial-In User
Service (RADIUS) attributes that carry DHCP options. The specification
is generic and can be applicable to any service that relies upon 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
.
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
() 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
. Introduction
. Terminology
. RADIUS DHCP Options Attributes
. DHCPv6-Options Attribute
. DHCPv4-Options Attribute
. Passing RADIUS DHCP Options Attributes by DHCP Relay Agents to DHCP Servers
. Context
. Updates to RFC 4014
. Section 3 of RFC 4014
. Section 4 of RFC 4014
. An Example: Applicability to Encrypted DNS Provisioning
. Security Considerations
. Table of Attributes
. IANA Considerations
. New RADIUS Attributes
. New RADIUS Attribute Permitted in DHCPv6 RADIUS Option
. RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption
. DHCP Options Permitted in the RADIUS DHCP*-Options Attributes
. DHCPv6
. DHCPv4
. Guidelines for the Designated Experts
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionIn the context of broadband services, Internet Service Providers
(ISPs) usually provide DNS resolvers to their customers. To that aim,
ISPs deploy dedicated mechanisms (e.g., DHCP and IPv6
Router Advertisement ) to
advertise a list of DNS recursive servers to their customers. Typically,
the information used to populate DHCP messages and/or IPv6 Router
Advertisements relies upon specific Remote Authentication Dial-In User
Service (RADIUS) attributes,
such as the DNS-Server-IPv6-Address Attribute specified in .With the advent of encrypted DNS (e.g., DNS over HTTPS
(DoH) , DNS over TLS (DoT)
, or DNS over QUIC (DoQ) ), additional means are required to
provision hosts with network-designated encrypted DNS. To fill that
void, leverages
existing protocols such as DHCP to provide hosts with the required
information to connect to an encrypted DNS resolver. However, there are
no RADIUS attributes that can be used to populate the discovery messages
discussed in . The
same concern is likely to be encountered for future services that are
configured using DHCP.This document specifies two new RADIUS attributes: DHCPv6-Options
() and DHCPv4-Options (). These attributes can include
DHCP options that are listed in the "DHCPv6 Options Permitted
in the RADIUS DHCPv6-Options Attribute" registry () and the "DHCP Options Permitted
in the RADIUS DHCPv4-Options Attribute" registry (). These two attributes are specified
in order to accommodate both IPv4 and IPv6 deployment contexts while
taking into account the constraints in .The mechanism specified in this document is a generic mechanism and
might be employed in network scenarios where the DHCP server and the
RADIUS client are located in the same device. The new attributes can
also be used in deployments that rely upon the mechanisms defined in
or , which
allow a DHCP relay agent that is collocated with a RADIUS client to pass
attributes obtained from a RADIUS server to a DHCP server. However, an
update to is required so that a DHCP
relay agent can pass the DHCPv4-Options Attribute obtained from a RADIUS
server to a DHCP server ().DHCP options that are included in the new RADIUS attributes can be
controlled by a deployment-specific policy. Discussing such a policy is
out of scope.This document adheres to for defining
the new attributes.A sample deployment usage of the RADIUS DHCPv6-Options and DHCPv4-Options
Attributes is described in .Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
This document makes use of the terms defined in , , and . The following additional terms are used:
DHCP:
refers to both DHCPv4
and DHCPv6 .
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 () that supports encrypted DNS.
DHCP*-Options:
refers to the DHCPv4-Options and DHCPv6-Options Attributes ().
RADIUS DHCP Options AttributesThis section specifies two new RADIUS attributes for RADIUS clients
and servers to exchange DHCP-encoded data. This data is then used to
feed 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 ().
The description of the fields is provided in Sections and .These attributes use the "Long Extended Type" format in order to
permit the transport of 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 (). In order to accommodate
deployments with large DHCP options, RADIUS implementations are
RECOMMENDED to support a packet size up to 65535 bytes. Such a
recommendation can be met if RADIUS implementations support a mechanism
that relaxes the limit of 4096 bytes (e.g., the mechanisms described in
or ).The Value fields of the DHCP*-Options Attributes are encoded in the clear and
not encrypted like, for example, the Tunnel-Password Attribute .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. As such,
absent any explicit configuration on the DHCP server, RADIUS-supplied
data by means of the DHCP*-Options Attributes take precedence over any local
configuration.These attributes are defined with globally unique names. The naming
of the attributes follows the guidelines in . Invalid attributes are handled as per .DHCPv6-Options AttributeThis attribute is of type "string" as defined in .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
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
3 (see )
Value
This field contains a list of DHCPv6 options (). 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 ,
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 ().
The DHCPv6-Options Attribute is associated with the following
identifier: 245.3.DHCPv4-Options AttributeThis attribute is of type "string" as defined in .The DHCPv4-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 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.The DHCPv4-Options Attribute is structured as follows:
Type
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
4 (see )
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
MUST be
used for splitting and concatenating the instances of a
concatenation-requiring option.The permitted DHCPv4 options are
listed in the "DHCP Options Permitted
in the RADIUS DHCPv4-Options Attribute" registry ().
The DHCPv4-Options Attribute is associated with the following
identifier: 245.4.Passing RADIUS DHCP Options Attributes by DHCP Relay Agents to DHCP ServersContextThe RADIUS Attributes DHCP suboption enables a DHCPv4 relay agent to pass identification
and authorization attributes received during RADIUS authentication to
a DHCPv4 server. However,
defines a frozen set of RADIUS attributes that can be included in such
a suboption. This limitation is suboptimal in contexts where new
services are deployed (e.g., support of encrypted DNS ). updates by relaxing that constraint and
allowing additional RADIUS attributes to 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 ().
Updates to RFC 4014Section 3 of RFC 4014This document updates
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 ( 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.
Section 4 of RFC 4014This document updates
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 ( of [RFC9445]) and explicit
configuration is absent, the DHCP server SHOULD ignore
them.
An Example: Applicability to Encrypted DNS ProvisioningTypical deployment scenarios are similar to those described, for
instance, in . For
illustration purposes, shows an example where
a Customer Premises Equipment (CPE) is provided with an encrypted DNS
resolver. This example assumes that the Network Access Server (NAS)
embeds both RADIUS client and DHCPv6 server capabilities.An Example of RADIUS IPv6 Encrypted DNS Exchange
+-------------+ +-------------+ +-------+
| 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
Upon receipt of the DHCPv6 Solicit message from a CPE, the NAS sends
a RADIUS Access-Request message to the Authentication, Authorization,
and Accounting (AAA) server. Once the AAA server receives the request,
it replies with an Access-Accept message (possibly after having sent a
RADIUS Access-Challenge message and assuming the CPE is entitled to
connect to the network) that carries a list of parameters to be used for
this session, which includes the encrypted DNS information. Such
information is encoded as OPTION_V6_DNR (144) instances in the RADIUS DHCPv6-Options
Attribute. These instances are then used by the NAS to complete
the DHCPv6 procedure that the CPE initiated to retrieve information
about the encrypted DNS service to use. The Discovery of
Network-designated Resolvers (DNR) procedure defined in is then followed between
the DHCPv6 client and the DHCPv6 server.Should any encrypted DNS-related information (e.g., Authentication
Domain Name (ADN) and IPv6 address) change, the RADIUS server sends a
RADIUS Change-of-Authorization (CoA) message that carries the DHCPv6-Options Attribute with
the updated OPTION_V6_DNR information to the NAS. Once that message is
received and validated by the NAS, it replies with a RADIUS CoA ACK
message. The NAS replaces the old encrypted DNS resolver information
with the new one and sends a DHCPv6 Reconfigure message, which leads the
DHCPv6 client to initiate a Renew/Reply message exchange with the DHCPv6
server.In deployments where the NAS behaves as a DHCPv6 relay agent, the
procedure discussed in can be followed.
To that aim, the "RADIUS Attributes Permitted in DHCPv6
RADIUS Option" registry has been updated (). CoA-Requests can be used following the procedure
specified in . shows another example where a CPE is
provided with an encrypted DNS resolver, but the CPE uses DHCPv4 to
retrieve its encrypted DNS resolver.An Example of RADIUS IPv4 Encrypted DNS Exchange
+-------------+ +-------------+ +-------+
| 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
Other deployment scenarios can be envisaged, such as returning
customized service parameters (e.g., different DoH URI Templates) as a
function of the service, policies, and preferences that are set by a
network administrator. How an administrator indicates its service,
policies, and preferences to a AAA server is out of scope.Security ConsiderationsRADIUS-related security considerations are discussed in .DHCPv6-related security issues are discussed in , while DHCPv4-related security issues are
discussed in . Security
considerations specific to the DHCP options that are carried in RADIUS
are discussed in relevant documents that specify these options. For
example, security considerations (including traffic theft) are discussed
in .RADIUS servers have conventionally tolerated the input of arbitrary
data via the "string" data type (). This practice allows RADIUS servers to support
newer standards without software upgrades, by allowing administrators to
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 thus 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 increases usability for administrators.The considerations discussed in and
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 .Table of AttributesThe following table provides a guide as to what type of RADIUS packets
may contain these attributes and in what quantity.
Table of Attributes
Access-Request
Access-Accept
Access-Reject
Challenge
#
Attribute
0+
0+
0
0
245.3
DHCPv6-Options
0+
0+
0
0
245.4
DHCPv4-Options
Accounting-Request
CoA-Request
CoA-ACK
CoA-NACK
#
Attribute
0+
0+
0
0
245.3
DHCPv6-Options
0+
0+
0
0
245.4
DHCPv4-Options
Notation for :
0
This attribute MUST NOT be present in
packet.
0+
Zero or more instances of this attribute MAY
be present in packet.
IANA ConsiderationsNew RADIUS AttributesIANA has assigned two new RADIUS attribute types in the
"Radius Attribute Types" registry:
New RADIUS Attributes
Value
Description
Data Type
Reference
245.3
DHCPv6-Options
string
RFC 9445
245.4
DHCPv4-Options
string
RFC 9445
New RADIUS Attribute Permitted in DHCPv6 RADIUS OptionIANA has added the following entry to the "RADIUS
Attributes Permitted in DHCPv6 RADIUS Option" subregistry in the
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry :
New RADIUS Attribute Permitted in DHCPv6 RADIUS Option
Type Code
Attribute
Reference
245.3
DHCPv6-Options
RFC 9445
RADIUS Attributes Permitted in RADIUS Attributes DHCP SuboptionIANA has created a new subregistry entitled "RADIUS
Attributes Permitted in RADIUS Attributes DHCP Suboption" in the "Dynamic
Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP)
Parameters" registry .The allocation policy of this new subregistry is "Expert Review"
(). Designated experts should carefully consider
the security implications of allowing a relay agent to include new
RADIUS attributes in this subregistry. Additional considerations are
provided in .The initial contents of this subregistry are listed in . The Reference field includes the document that
registers or specifies the attribute.
Initial Contents of RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption Registry
Type Code
Attribute
Reference
1
User-Name
6
Service-Type
26
Vendor-Specific
27
Session-Timeout
88
Framed-Pool
100
Framed-IPv6-Pool
245.4
DHCPv4-Options
RFC 9445
DHCP Options Permitted in the RADIUS DHCP*-Options AttributesDHCPv6IANA has created a new subregistry entitled "DHCPv6
Options Permitted in the RADIUS DHCPv6-Options Attribute" in the
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry
.The registration policy for this new subregistry is "Expert
Review" (). See more details in .The initial content of this subregistry is listed in . The Value and Description fields
echo those in the "Option Codes" subregistry of . The Reference field includes the
document that registers or specifies the option.
Initial Content of DHCPv6 Options Permitted in the RADIUS DHCPv6-Options Attribute Registry
Value
Description
Reference
144
OPTION_V6_DNR
RFC 9445
DHCPv4IANA has created a new subregistry entitled "DHCP
Options Permitted in the RADIUS DHCPv4-Options Attribute" in the
"Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol
(BOOTP) Parameters" registry .The registration policy for this new subregistry is Expert
Review (). See more
details in .The initial content of this subregistry is listed in . The Tag and Name fields echo those
in the "BOOTP Vendor Extensions and DHCP Options" subregistry of
. The Reference field
includes the document that registers or specifies the option.
Initial Content of DHCPv4 Options Permitted in the RADIUS DHCPv4-Options Attribute Registry
Tag
Name
Reference
162
OPTION_V4_DNR
RFC 9445
Guidelines for the Designated ExpertsIt is suggested that multiple designated experts be appointed for
registry change requests.Criteria that should be applied by the designated experts include
determining whether the proposed registration duplicates existing
entries and whether the registration description is clear and fits
the purpose of this registry.Registration requests are to be sent to
<radius-dhcp-review@ietf.org> and are evaluated within a three-week
review period on the advice of one or more designated experts.
Within the review period, the designated experts will either approve
or deny the registration request, communicating this decision to the
review list and IANA. Denials should include an explanation and, if
applicable, suggestions as to how to make the request
successful.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Remote Authentication Dial In User Service (RADIUS)This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information OptionThe RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS-TRACK]RADIUS Design GuidelinesThis document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). This memo documents an Internet Best Current Practice.Remote Authentication Dial In User Service (RADIUS) Protocol ExtensionsThe Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.Data Types in RADIUSRADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Dynamic Host Configuration Protocol for IPv6 (DHCPv6)This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.Informative ReferencesDynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) ParametersIANADynamic Host Configuration Protocol for IPv6 (DHCPv6)IANADHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)OrangeNokiaCitrix Systems, Inc.Open-XchangeMicrosoftWork in ProgressRADIUS TypesIANADynamic Host Configuration ProtocolThe Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]DHCP Options and BOOTP Vendor ExtensionsThis document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]RADIUS Attributes for Tunnel Protocol SupportThis document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.RADIUS ExtensionsThis document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community.RADIUS and IPv6This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS-TRACK]Neighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.RADIUS Attributes for IPv6 Access NetworksThis document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.Triggering DHCPv6 Reconfiguration from Relay AgentsThis document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.RADIUS Option for the DHCPv6 Relay AgentThe DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the Network Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. The DHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests.Guidelines for Creating New DHCPv6 OptionsThis document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.Support of Fragmentation of RADIUS PacketsThe Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.Specification for DNS over Transport Layer Security (TLS)This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.Larger Packets for RADIUS over TCPThe RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.DNS Queries over HTTPS (DoH)This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.DNS TerminologyThe Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.This document obsoletes RFC 7719 and updates RFC 2308.DNS over Dedicated QUIC ConnectionsThis document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.AcknowledgementsThanks to , , , , , , and for the
review and suggestions.Thanks to and for the comments.Thanks to for the careful AD
review.Thanks to for the dnsdir reviews,
for the genart review, and for the intdir review.Thanks to , , and for the IESG
review.Authors' AddressesOrangeRennes35000Francemohamed.boucadair@orange.comNokiaIndiakondtir@gmail.comFreeRADIUSaland@freeradius.org