RADIUS Extensions for DHCP Configured
ServicesOrangeRennes35000Francemohamed.boucadair@orange.comNokiaIndiakondtir@gmail.comFreeRADIUSaland@freeradius.orgopsawgredirectionsubscriber policiesdifferentiated serviceDNSDoHDoTDoQQUICEncryptionService deliveryService provisioningservice activationpoliciesconnectivityThis document specifies two new Remote Authentication Dial-In User
Service (RADIUS) attributes that carry DHCP options. Even if the
specification was initially motivated by the configuration of encrypted
DNS resolvers, 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.In 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 , 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 and IPv6 Router Advertisement 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 () Attributes. These attributes can include DHCP
options that are listed under the IANA registries that are created in
Sections and . 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 as policy is
out of scope.This document adheres to for defining
the new attributes.A sample deployment usage of the DHCPv6-Options and DHCPv4-Options
RADIUS attributes is described in .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: refers to both DHCPv4 and DHCPv6 .refers to a scheme where DNS exchanges
are transported over an encrypted channel. Examples of encrypted DNS
are DoT, DoH, and DoQ.refers to a resolver () that supports encrypted
DNS.refers to DHCPv4-Options and
DHCPv6-Options Attributes ().This 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 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 DHCP*-Options RADIUS
attributes are limited by the maximum packet size of 4096 bytes. In
order to accommodate deployments with large options, implementations are
RECOMMENDED to support a packet size up to 65535 bytes.The value fields of DHCP*-Options Attributes are encoded in clear and
not encrypted as, for example, Tunnel-Password Attribute .RADIUS implementations may support a configuration parameter to
control the DHCP options that can be included in a DHCP*-Options RADIUS
attribute. Likewise, DHCP server implementations may support a
configuration parameter to control the permitted DHCP options in a
DHCP*-Options RADIUS attribute.For ease of administrator configuration, the RADIUS server SHOULD
expose the DHCP options and allow administrators to configure them,
instead of requiring them to be entered as opaque data.Absent any explicit configuration on the DHCP server, RADIUS supplied
data by means of 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 Section 2.7.1 of .This 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:Type245LengthThis field indicates the total length, in octets, of all fields
of this attribute, including the Type, Length, Extended-Type, and
"Value".Extended-TypeTBA1 (see ).ValueThis field contains a list of DHCPv6 options. Multiple
instances of the same DHCPv6 option MAY be included. Consistent
with Section 17 of , this document
does not impose any option order when multiple options are
present. Permitted DHCPv6 options in the DHCPv6-Options Attribute are
maintained by IANA in the registry created in .The DHCPv6-Options Attribute is associated with the following
identifier: 245.TBA1.This 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:Type245LengthThis field indicates the total length, in octets, of all fields
of this attribute, including the Type, Length, Extended-Type, and
"Value".Extended-TypeTBA2 (see ).ValueThis field contains a list of DHCPv4 options.Permitted DHCPv4 options in the DHCPv4-Options
Attribute are maintained by IANA in the registry created in .The DHCPv4-Options Attribute is associated with the following
identifier: 245.TBA2.The RADIUS Attributes 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 to
tag additional RADIUS attributes as permitted in the RADIUS Attributes
DHCP suboption. creates a new IANA
registry to maintain the set of permitted attributes in the RADIUS
Attributes DHCP suboption.This document updates Section 3 of
as follows: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: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
IANA-maintained registry ( of
[This-Document]) in an instance of the RADIUS Attributes
suboption.This document updates Section 4 of
as follows:If the relay agent
relays RADIUS attributes not included in the table in Section 4,
the DHCP server SHOULD ignore them.If the relay agent
relays RADIUS attributes not included in the IANA-maintained
registry ( of [This-Document]),
the DHCP server SHOULD ignore them.Typical 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.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, and which include the encrypted DNS information. Such an
information is encoded as OPTION_V6_DNR (144) instances () in the DHCPv6-Options RADIUS
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), 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, updates the "RADIUS
Attributes Permitted in DHCPv6 RADIUS Option" registry (). shows another example where a CPE is
provided with an encrypted DNS resolver, but the CPE uses DHCPv4 to
retrieve its encrypted DNS resolver.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/preferences that are set by a network
administrator. How an administrator indicates its
service/policies/preferences to an AAA server is out of scope.RADIUS-related security considerations are discussed in .This document targets deployments where a trusted relationship is in
place between the RADIUS client and server with communication optionally
secured by IPsec or Transport Layer Security (TLS) .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 .The considerations discussed in Section 7 of and Section 8 of
should be taken into account in deployments where DHCP relay agents pass
the DHCP*-Options Attributes to DHCP servers.The following table provides a guide as what type of RADIUS packets
that may contain these attributes, and in what quantity.The following table defines the meaning of the above table
entries:IANA is requested to assign two new RADIUS attribute types from the
IANA registry "Radius Attribute Types" :ValueDescriptionData TypeReference245.TBA1DHCPv6-OptionsstringThis-Document245.TBA2DHCPv4-OptionsstringThis-DocumentIANA is requested to add the following entry to the "RADIUS
Attributes Permitted in DHCPv6 RADIUS Option" subregistry in the
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry :Type CodeAttributeReference245.TBA1DHCPv6-OptionsThis-DocumentIANA is requested to create a new sub-registry entitled "RADIUS
Attributes Permitted in RADIUS Attributes Sub-option" in the "Dynamic
Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP)
Parameters" registry .The allocation policy of this new sub-registry is Expert Review
(Section 4.5 of ). Designated experts
should carefully consider the security implications of allowing the
relay agent to include new RADIUS attributes to this registry.
Additional considerations are provided in .The initial content of this sub-registry is listed in . The reference may include the document that
registers or specifies the Attribute.Type CodeAttributeReference1User-Name[RFC2865]6Service-Type[RFC2865]26Vendor-Specific[RFC2865]27Session-Timeout[RFC2865]88Framed-Pool[RFC2869]100Framed-IPv6-Pool[RFC3162]245.TBA2DHCPv4-OptionsThis-DocumentIANA is requested to create a new sub-registry 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 sub-registry is Expert
Review (Section 4.5 of ). See more
details in .The initial content of this sub-registry is listed in . The reference may include the document that
registers the option or the document that specifies the option.ValueDescriptionReference144OPTION_V6_DNRThis-DocumentIANA is requested to create a new sub-registry 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 sub-registry is Expert
Review (Section 4.5 of ). See more
details in .The initial content of this sub-registry is listed in . The reference may include the document that
registers the option or the document that specifies the option.TagNameReference162OPTION_V4_DNRThis-DocumentIt 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.Registration requests that are undetermined for a period longer
than 28 days can be brought to the IESG's attention for
resolution.Thanks to Christian Jacquenet, Neil Cook, Joe Clarke, Qin Wu, Dirk
von-Hugo, Tom Petch, and Chongfeng Xie for the review and
suggestions.Thanks to Ben Schwartz and Bernie Volz for the comments.RADIUS TypesIANADynamic Host Configuration Protocol for IPv6 (DHCPv6)IANADynamic Host Configuration Protocol (DHCP) and Bootstrap
Protocol (BOOTP) ParametersIANA