<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-opsawg-add-encrypted-dns-12" number="9445" ipr="trust200902"updates="4014">updates="4014" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="RADIUSDHCP-Options">RADIUSDHCP Options">RADIUS Extensions forDHCP ConfiguredDHCP-Configured Services</title> <seriesInfo name="RFC" value="9445"/> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <postal><street></street><street/> <city>Rennes</city><region></region><region/> <code>35000</code> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="TirumaleswarReddy"Reddy.K" initials="T."surname="Reddy">surname="Reddy.K"> <organization>Nokia</organization> <address> <postal><street></street> <city></city> <region></region> <code></code><street/> <city/> <region/> <code/> <country>India</country> </postal> <email>kondtir@gmail.com</email> </address> </author> <author fullname="Alan DeKok" initials="A." surname="DeKok"> <organization>FreeRADIUS</organization> <address> <postal><street></street> <city></city> <region></region> <code></code> <country></country><street/> <city/> <region/> <code/> <country/> </postal><phone></phone> <facsimile></facsimile><phone/> <email>aland@freeradius.org</email><uri></uri><uri/> </address> </author> <date/>year="2023" month="August"/> <area>ops</area> <workgroup>opsawg</workgroup> <keyword>redirection</keyword> <keyword>subscriber policies</keyword> <keyword>differentiated service</keyword> <keyword>DNS</keyword> <keyword>DoH</keyword> <keyword>DoT</keyword> <keyword>DoQ</keyword> <keyword>QUIC</keyword> <keyword>Encryption</keyword> <keyword>Service delivery</keyword> <keyword>Service provisioning</keyword> <keyword>service activation</keyword> <keyword>policies</keyword> <keyword>connectivity</keyword> <abstract> <t>This 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. BothDHCPv4DHCPv4- andDHCPv6 configuredDHCPv6-configured services arecovered.</t>covered. </t> <t>Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUSAttributesattributes in the RADIUS Attributes DHCPsuboption.<!-- --></t>suboption. </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>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 <xreftarget="RFC2132"></xref>target="RFC2132" format="default"/> <xreftarget="RFC8415"></xref>,target="RFC8415" format="default"/> and IPv6 Router Advertisement <xreftarget="RFC4861"></xref>)target="RFC4861" format="default"/>) 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) <xreftarget="RFC2865"></xref>target="RFC2865" format="default"/> attributes, such as the DNS-Server-IPv6-Address Attribute specified in <xreftarget="RFC6911"></xref>.</t>target="RFC6911" format="default"/>.</t> <t>With the advent of encrypted DNS (e.g.,DNS-over-HTTPSDNS over HTTPS (DoH) <xreftarget="RFC8484"></xref>, DNS-over-TLStarget="RFC8484" format="default"/>, DNS over TLS (DoT) <xreftarget="RFC7858"></xref>,target="RFC7858" format="default"/>, orDNS-over-QUICDNS over QUIC (DoQ) <xreftarget="RFC9250"></xref>),target="RFC9250" format="default"/>), additional means are required to provision hosts with network-designated encrypted DNS. To fill that void, <xreftarget="I-D.ietf-add-dnr"></xref>target="I-D.ietf-add-dnr" format="default"/> 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 <xreftarget="I-D.ietf-add-dnr"></xref>.target="I-D.ietf-add-dnr" format="default"/>. The same concern is likely to be encountered for future services that are configured using DHCP.</t> <t>This document specifies two new RADIUS attributes: DHCPv6-Options (<xreftarget="v6"></xref>)target="v6" format="default"/>) and DHCPv4-Options (<xreftarget="v4"></xref>) Attributes.target="v4" format="default"/>). These attributes can include DHCP options that are listedunderin theIANA registries that are created"DHCPv6 Options Permitted inSections <xref format="counter" target="drv6-reg"></xref>the RADIUS DHCPv6-Options Attribute" registry (<xref format="default" target="drv6-reg"/>) and<xref format="counter" target="drv4-reg"></xref>.the "DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute" registry (<xref format="default" target="drv4-reg"/>). These two attributes are specified in order to accommodate both IPv4 and IPv6 deployment contexts while taking into account the constraints in <xref section="3.4"target="RFC6158"></xref>.</t>target="RFC6158" format="default"/>.</t> <t>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 <xreftarget="RFC4014"></xref>target="RFC4014" format="default"/> or <xreftarget="RFC7037"></xref>,target="RFC7037" format="default"/>, 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 <xreftarget="RFC4014"></xref>target="RFC4014" format="default"/> is required so that a DHCP relay agent can pass the DHCPv4-Options Attribute obtained from a RADIUS server to a DHCP server (<xreftarget="RAD"></xref>).</t>target="RAD" format="default"/>).</t> <t>DHCP options that are included in the new RADIUS attributes can be controlled by adeployment specificdeployment-specific policy. Discussing such a policy is out of scope.</t> <t>This document adheres to <xreftarget="RFC8044"></xref>target="RFC8044" format="default"/> for defining the new attributes.</t> <t>A sample deployment usage of the RADIUS DHCPv6-Options and DHCPv4-OptionsRADIUS attributesAttributes is described in <xreftarget="sample"></xref>.</t>target="sample" format="default"/>.</t> </section> <sectiontitle="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>This document makes use of the terms defined in <xreftarget="RFC2865"></xref>,target="RFC2865" format="default"/>, <xreftarget="RFC8415"></xref>,target="RFC8415" format="default"/>, and <xreftarget="RFC8499"></xref>.target="RFC8499" format="default"/>. The following additional terms are used:<list style="hanging"> <t hangText="DHCP:">refers</t> <dl newline="false" spacing="normal"> <dt>DHCP:</dt> <dd>refers to both DHCPv4 <xreftarget="RFC2132"></xref>target="RFC2132" format="default"/> and DHCPv6 <xreftarget="RFC8415"></xref>.</t> <t hangText="Encrypted DNS:">referstarget="RFC8415" format="default"/>.</dd> <dt>Encrypted DNS:</dt> <dd>refers to a scheme where DNS exchanges are transported over an encrypted channel. Examples of encrypted DNS are DoT, DoH, andDoQ.</t> <t hangText="EncryptedDoQ.</dd> <dt>Encrypted DNSresolver:">refersresolver:</dt> <dd>refers to a resolver (<xref section="6"target="RFC8499"></xref>)target="RFC8499" format="default"/>) that supports encryptedDNS.</t> <t hangText="DHCP*-Options:">refersDNS.</dd> <dt>DHCP*-Options:</dt> <dd>refers to the DHCPv4-Options and DHCPv6-Options Attributes (<xreftarget="att"></xref>).</t> </list></t>target="att" format="default"/>).</dd> </dl> </section> <section anchor="att"title="DHCPnumbered="true" toc="default"> <name>RADIUS DHCP OptionsRADIUS Attributes">Attributes</name> <t>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.</t> <t>Both the DHCPv4-Options and DHCPv6-Options Attributes use the "Long Extended Type" format (<xref section="2.2"target="RFC6929"></xref>).target="RFC6929" format="default"/>). The description of the fields is provided in Sections <xref format="counter"target="v6"></xref>target="v6"/> and <xref format="counter"target="v4"></xref>.</t>target="v4"/>.</t> <t>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 theDHCP*-OptionsRADIUSattributesDHCP*-Options Attributes are limited by the maximum packet size of 4096 bytes (<xref section="3"target="RFC2865"></xref>).target="RFC2865" format="default"/>). In order to accommodate deployments with large DHCP options, RADIUS implementations areRECOMMENDED<bcp14>RECOMMENDED</bcp14> 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 byteslimit(e.g., the mechanisms described in <xreftarget="RFC7499"></xref>target="RFC7499" format="default"/> or <xreftarget="RFC7930"></xref>).</t>target="RFC7930" format="default"/>).</t> <t>ThevalueValue fields of the DHCP*-Options Attributes are encoded in the clear and not encryptedas,like, for example, the Tunnel-Password Attribute <xreftarget="RFC2868"></xref>.</t>target="RFC2868" format="default"/>.</t> <t>RADIUS implementations may support a configuration parameter to control the DHCP options that can be included in aDHCP*-OptionsRADIUSattribute.DHCP*-Options Attribute. Likewise, DHCP server implementations may support a configuration parameter to control the permitted DHCP options in aDHCP*-OptionsRADIUSattribute.DHCP*-Options Attribute. Absent explicit configuration, RADIUS implementations and DHCP server implementationsSHOULD<bcp14>SHOULD</bcp14> ignore non-permitted DHCP options received in aDHCP*-OptionsRADIUSattribute.</t> <t>RADIUS suppliedDHCP*-Options Attribute.</t> <t>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 suppliedRADIUS-supplied data by means of the DHCP*-Options Attributes take precedence over any local configuration.</t> <t>These attributes are defined with globally unique names. The naming of the attributes follows the guidelines inSection 2.7.1 of<xreftarget="RFC6929"></xref>.target="RFC6929" section="2.7.1" sectionFormat="of"/>. Invalid attributes are handled as perSection 2.8 of<xreftarget="RFC6929"></xref>.</t>target="RFC6929" section="2.8" sectionFormat="of"/>.</t> <section anchor="v6"title="DHCPv6-Options Attribute">numbered="true" toc="default"> <name>DHCPv6-Options Attribute</name> <t>This attribute is of type "string" as defined in <xref section="3.5"target="RFC8044"></xref>.</t>target="RFC8044" format="default"/>.</t> <t>The DHCPv6-Options AttributeMAY<bcp14>MAY</bcp14> appear in a RADIUS Access-Accept packet. ItMAY<bcp14>MAY</bcp14> 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.</t> <t>The DHCPv6-Options AttributeMAY<bcp14>MAY</bcp14> appear in a RADIUS CoA-Request packet.</t> <t>The DHCPv6-Options AttributeMAY<bcp14>MAY</bcp14> appear in a RADIUS Accounting-Request packet.</t> <t>The DHCPv6-Options AttributeMUST NOT<bcp14>MUST NOT</bcp14> appear in any other RADIUS packet.</t> <t>The DHCPv6-Options Attribute is structured as follows:</t><t>Type<list style="empty"> <t>245</t> </list></t> <t>Length<list style="empty"> <t>This<dl newline="true" spacing="normal"> <dt>Type</dt> <dd><t>245</t></dd> <dt>Length</dt> <dd>This field indicates the total length, in octets, of all fields of this attribute, including the Type, Length, Extended-Type, and"Value".</t> </list></t> <t>Extended-Type<list style="empty"> <t>TBA1Value fields.</dd> <dt>Extended-Type</dt> <dd>3 (see <xreftarget="IANA-Att"></xref>).</t> </list></t> <t>Value<list style="empty"> <t>Thistarget="IANA-Att" format="default"/>)</dd> <dt>Value</dt> <dd><t>This field contains a list of DHCPv6 options(Section 21 of <xref target="RFC8415"></xref>).(<xref target="RFC8415" section="21" sectionFormat="of"/>). Multiple instances of the same DHCPv6 optionMAY<bcp14>MAY</bcp14> be included. If an option appears multiple times, each instance is consideredseparateseparate, and the data areas of the optionsMUST NOT<bcp14>MUST NOT</bcp14> be concatenated or otherwise combined. Consistent withSection 17 of<xreftarget="RFC7227"></xref>,target="RFC7227" section="17" sectionFormat="of"/>, this document does not impose any option order when multiple options are present.</t><t><vspace blankLines="1" /></t> <t>Permitted<t>The permitted DHCPv6 options are listed in theDHCPv6-Options Attribute are maintained by IANA"DHCPv6 Options Permitted in the RADIUS DHCPv6-Options Attribute" registrycreated in <xref(<xref format="default"target="drv6-reg"></xref>.</t> </list></t>target="drv6-reg"/>).</t></dd> </dl> <t>The DHCPv6-Options Attribute is associated with the following identifier:245.TBA1.</t>245.3.</t> </section> <section anchor="v4"title="DHCPv4-Options Attribute">numbered="true" toc="default"> <name>DHCPv4-Options Attribute</name> <t>This attribute is of type "string" as defined in <xref section="3.5"target="RFC8044"></xref>.</t>target="RFC8044" format="default"/>.</t> <t>The DHCPv4-Options AttributeMAY<bcp14>MAY</bcp14> appear in a RADIUS Access-Accept packet. ItMAY<bcp14>MAY</bcp14> 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.</t> <t>The DHCPv4-Options AttributeMAY<bcp14>MAY</bcp14> appear in a RADIUS CoA-Request packet.</t> <t>The DHCPv4-Options AttributeMAY<bcp14>MAY</bcp14> appear in a RADIUS Accounting-Request packet.</t> <t>The DHCPv4-Options AttributeMUST NOT<bcp14>MUST NOT</bcp14> appear in any other RADIUS packet.</t> <t>The DHCPv4-Options Attribute is structured as follows:</t><t>Type<list style="empty"> <t>245</t> </list></t> <t>Length<list style="empty"> <t>This<dl newline="true" spacing="normal"> <dt>Type</dt> <dd>245</dd> <dt>Length</dt> <dd>This field indicates the total length, in octets, of all fields of this attribute, including the Type, Length, Extended-Type, and"Value".</t> </list></t> <t>Extended-Type<list style="empty"> <t>TBA2Value fields.</dd> <dt>Extended-Type</dt> <dd>4 (see <xreftarget="IANA-Att"></xref>).</t> </list></t> <t>Value<list style="empty"> <t>Thistarget="IANA-Att" format="default"/>)</dd> <dt>Value</dt> <dd><t>This field contains a list of DHCPv4 options. Multiple instances of the same DHCPv4 optionMAY<bcp14>MAY</bcp14> be included, especially for concatenation-requiring options that exceed the maximum DHCPv4 option size of 255 octets. The mechanism specified in <xreftarget="RFC3396"></xref> MUSTtarget="RFC3396" format="default"/> <bcp14>MUST</bcp14> be used for splitting and concatenating the instances of a concatenation-requiring option.</t><t><vspace blankLines="1" />Permitted<t>The permitted DHCPv4 options are listed in theDHCPv4-Options Attribute are maintained by IANA"DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute" registrycreated in <xref(<xref format="default"target="drv4-reg"></xref>.</t> </list></t>target="drv4-reg"/>).</t></dd> </dl> <t>The DHCPv4-Options Attribute is associated with the following identifier:245.TBA2.</t>245.4.</t> </section> </section> <section anchor="RAD"title="Passingnumbered="true" toc="default"> <name>Passing RADIUS DHCP OptionsRADIUSAttributes by DHCP Relay Agents to DHCPServers">Servers</name> <sectiontitle="Context">numbered="true" toc="default"> <name>Context</name> <t>The RADIUS Attributes DHCP suboption <xreftarget="RFC4014"></xref>target="RFC4014" format="default"/> enables a DHCPv4 relay agent to pass identification and authorization attributes received during RADIUS authentication to a DHCPv4 server. However, <xreftarget="RFC4014"></xref>target="RFC4014" format="default"/> 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 <xreftarget="I-D.ietf-add-dnr"></xref>).</t>target="I-D.ietf-add-dnr" format="default"/>).</t> <t><xreftarget="update"></xref>target="update" format="default"/> updates <xreftarget="RFC4014"></xref>target="RFC4014" format="default"/> by relaxing that constraint and allowingto tagadditional RADIUS attributes to be tagged as permitted in the RADIUS Attributes DHCP suboption.<xref target="IANA-RAD"></xref> creates a new IANA registry to maintain the set ofThe permitted attributes are registered in the new "RADIUS Attributes Permitted in RADIUS Attributes DHCPsuboption.</t>Suboption" registry (<xref target="IANA-RAD" format="default"/>). </t> </section> <section anchor="update"title="Updatesnumbered="true" toc="default"> <name>Updates to RFC4014"> <t></t>4014</name> <t/> <section anchor="update1"title="Sectionnumbered="true" toc="default"> <name>Section 3 of RFC4014">4014</name> <t>This document updatesSection 3 of<xreftarget="RFC4014"></xref>target="RFC4014" section="3" sectionFormat="of"/> asfollows:<list style="hanging"> <t hangText="OLD:"><vspace blankLines="1" />Tofollows:</t> <t>OLD:</t> <blockquote><t>To avoid dependencies between the address allocation and other state information between the RADIUS server and the DHCP server, the DHCP relay agentSHOULD<bcp14>SHOULD</bcp14> 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 thatMAY<bcp14>MAY</bcp14> beincluded:<vspace blankLines="1" /><figure> <artwork><![CDATA[included:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ # 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]) ]]></artwork></figure></t> <t hangText="NEW:"><vspace blankLines="1" />To</blockquote> <t>NEW:</t> <blockquote><t>To avoid dependencies between the address allocation and other state information between the RADIUS server and the DHCP server, the DHCP relay agentSHOULD include<bcp14>SHOULD</bcp14> only include the attributes in theIANA-maintained"RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption" registry (<xreftarget="IANA-RAD"></xref>target="IANA-RAD" format="default"/> of[This-Document])[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 Attributessuboption.</t> </list></t>DHCP suboption.</t></blockquote> </section> <section anchor="update2"title="Sectionnumbered="true" toc="default"> <name>Section 4 of RFC4014">4014</name> <t>This document updatesSection 4 of<xreftarget="RFC4014"></xref>target="RFC4014" section="4" sectionFormat="of"/> asfollows:<list style="hanging"> <t hangText="OLD:"><vspace blankLines="1" />Iffollows:</t> <t>OLD:</t> <blockquote><t>If the relay agent relays RADIUS attributes not included in the table in Section 4, the DHCP serverSHOULD<bcp14>SHOULD</bcp14> ignorethem.</t> <t hangText="NEW:"><vspace blankLines="1" />Ifthem.</t></blockquote> <t>NEW:</t> <blockquote><t>If the relay agent relays RADIUS attributes not included in theIANA-maintained"RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption" registry (<xreftarget="IANA-RAD"></xref>target="IANA-RAD" format="default"/> of[This-Document]),[RFC9445]) andabsentexplicitconfiguration,configuration is absent, the DHCP serverSHOULD<bcp14>SHOULD</bcp14> ignorethem.</t> </list></t>them.</t></blockquote> </section> </section> </section> <section anchor="sample"title="Annumbered="true" toc="default"> <name>An Example: Applicability to Encrypted DNSProvisioning">Provisioning</name> <t>Typical deployment scenarios are similar to those described, for instance, in <xref section="2"target="RFC6911"></xref>.target="RFC6911" format="default"/>. For illustration purposes, <xreftarget="ex"></xref>target="ex" format="default"/> 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.</t><t><figure align="center" anchor="ex" title="An<figure anchor="ex"> <name>An Example of RADIUS IPv6 Encrypted DNSExchange"> <artwork><![CDATA[+-------------+Exchange</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-------------+ +-------------+ +-------+ | CPE | | NAS | | AAA | |DHCPv6client|Client| |DHCPv6server|Server| |Server | | | |RADIUSclient|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) | | | | | DHCPv6RADIUS]]></artwork> </figure></t>RADIUS ]]></artwork> </figure> <t>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,andwhichincludeincludes the encrypted DNS information. Suchaninformation is encoded as OPTION_V6_DNR (144) instances(<xref target="I-D.ietf-add-dnr"></xref>)<xref target="I-D.ietf-add-dnr" format="default"/> in theDHCPv6-OptionsRADIUSattribute.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 <xreftarget="I-D.ietf-add-dnr"></xref>target="I-D.ietf-add-dnr" format="default"/> is then followed between the DHCPv6 client and the DHCPv6 server.</t> <t>Should any encrypted DNS-related information (e.g., Authentication Domain Name(ADN),(ADN) and IPv6 address) change, the RADIUS server sends a RADIUS Change-of-Authorization (CoA) message <xreftarget="RFC5176"></xref>target="RFC5176" format="default"/> 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 Reconfiguremessagemessage, which leads the DHCPv6 client to initiate a Renew/Reply message exchange with the DHCPv6 server.</t> <t>In deployments where the NAS behaves as a DHCPv6 relay agent, the procedure discussed in <xref section="3"target="RFC7037"></xref>target="RFC7037" format="default"/> can be followed. To that aim,<xref target="urd"></xref> updatesthe "RADIUS Attributes Permitted in DHCPv6 RADIUS Option" registry has been updated (<xreftarget="DHCP-RADIUS"></xref>).target="urd" format="default"/>). CoA-Requests can be used following the procedure specified in <xreftarget="RFC6977"></xref>.</t>target="RFC6977" format="default"/>.</t> <t><xreftarget="ex2"></xref>target="ex2" format="default"/> shows another example where a CPE is provided with an encrypted DNS resolver, but the CPE uses DHCPv4 to retrieve its encrypted DNS resolver.</t><t><figure align="center" anchor="ex2" title="An<figure anchor="ex2"> <name>An Example of RADIUS IPv4 Encrypted DNSExchange"> <artwork><![CDATA[+-------------+Exchange</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-------------+ +-------------+ +-------+ | CPE | | NAS | | AAA | |DHCPv4client|Client| |DHCPv4server|Server| |Server | | | |RADIUSclient|Client| | | +------+------+ +------+------+ +---+---+ | | | o------DHCPDISCOVER------>| | | o----Access-Request ---->| | | | | |<----Access-Accept------o | |DHCPv4_OptionsDHCPv4-Options | |<-----DHCPOFFER----------o (OPTION_V4_DNR) | | (OPTION_V4_DNR) | | | | | o-----DHCPREQUEST-------->| | | (OPTION_V4_DNR) | | | | | |<-------DHCPACK----------o | | (OPTION_V4_DNR) | | | | | DHCPv4RADIUS]]></artwork> </figure></t>RADIUS ]]></artwork> </figure> <t>Other deployment scenarios can be envisaged, such as returning customized service parameters (e.g., different DoH URI Templates) as a function of theservice/policies/preferencesservice, policies, and preferences that are set by a network administrator. How an administrator indicates itsservice/policies/preferencesservice, policies, and preferences to an AAA server is out of scope.</t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>RADIUS-related security considerations are discussed in <xreftarget="RFC2865"></xref>.</t>target="RFC2865" format="default"/>.</t> <t>DHCPv6-related security issues are discussed in <xref section="22"target="RFC8415"></xref>,target="RFC8415" format="default"/>, while DHCPv4-related security issues are discussed in <xref section="7"target="RFC2131"></xref>.target="RFC2131" format="default"/>. 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 <xref section="7"target="I-D.ietf-add-dnr"></xref>.</t>target="I-D.ietf-add-dnr" format="default"/>.</t> <t>RADIUS servers have conventionally tolerated the input of arbitrary data via the "string" data type (<xref section="3.5"target="RFC8044"></xref>).target="RFC8044" format="default"/>). This practice allows RADIUS servers to support newer standards without software upgrades, by allowing administrators to manually create complex attribute contentand, then, toand then pass that content to a RADIUS server as opaque strings. While this practice is useful, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that RADIUS servers that implement the present specification are updated to understand the format and encoding of DHCP options. Administratorscan, thus,can thus enter the DHCP options as options instead ofmanually-encodedmanually encoded opaque strings. This recommendation increases security and interoperability by ensuring that the options are encoded correctly. It also increases usability for administrators.</t> <t>The considerations discussed inSection 7 of<xreftarget="RFC4014"></xref>target="RFC4014" section="7" sectionFormat="of"/> andSection 8 of<xreftarget="RFC7037"></xref>target="RFC7037" section="8" sectionFormat="of"/> 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 <xref section="9"target="RFC6977"></xref>.</t>target="RFC6977" format="default"/>.</t> </section> <sectiontitle="Tablenumbered="true" toc="default"> <name>Table ofAttributes">Attributes</name> <t>The following table provides a guide as to what type of RADIUS packetsthatmay contain theseattributes,attributes and in what quantity.</t><t><figure> <artwork><![CDATA[Access- Access- Access- Challenge Acct. # Attribute Request Accept Reject Request 0+ 0+ 0 0 0+ 245.TBA1 DHCPv6-Options 0+ 0+ 0 0 0+ 245.TBA2 DHCPv4-Options CoA-Request CoA-ACK CoA-NACK # Attribute 0+ 0 0 245.TBA1 DHCPv6-Options 0+ 0 0 245.TBA2 DHCPv4-Options ]]></artwork> </figure></t> <t>The following table defines the meaning of the above table entries:<figure> <artwork><![CDATA[ 0 This<table align="left" anchor="attributes-table"> <name>Table of Attributes</name> <thead> <tr> <th>Access-Request</th> <th>Access-Accept</th> <th>Access-Reject</th> <th>Challenge</th> <th>#</th> <th>Attribute</th> </tr> </thead> <tbody> <tr> <td>0+</td> <td>0+</td> <td>0</td> <td>0</td> <td>245.3</td> <td>DHCPv6-Options</td> </tr> <tr> <td>0+</td> <td>0+</td> <td>0</td> <td>0</td> <td>245.4</td> <td>DHCPv4-Options</td> </tr> <tr> <th>Accounting-Request</th> <th>CoA-Request</th> <th>CoA-ACK</th> <th>CoA-NACK</th> <th>#</th> <th>Attribute</th> </tr> <tr> <td>0+</td> <td>0+</td> <td>0</td> <td>0</td> <td>245.3</td> <td>DHCPv6-Options</td> </tr> <tr> <td>0+</td> <td>0+</td> <td>0</td> <td>0</td> <td>245.4</td> <td>DHCPv4-Options</td> </tr> </tbody> </table> <t>Notation for <xref target="attributes-table"/>:</t> <dl newline="false" spacing="normal" indent="4"> <dt>0</dt><dd>This attributeMUST NOT<bcp14>MUST NOT</bcp14> be present inpacket. 0+ Zeropacket.</dd> <dt>0+</dt><dd>Zero or more instances of this attributeMAY<bcp14>MAY</bcp14> be present inpacket. ]]></artwork> </figure></t>packet.</dd> </dl> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="IANA-Att"title="Newnumbered="true" toc="default"> <name>New RADIUSAttributes">Attributes</name> <t>IANAis requested to assignhas assigned two new RADIUS attribute typesfromin theIANA registry"Radius Attribute Types" <xreftarget="RADIUS-Types"></xref>:</t> <texttabletarget="RADIUS-Types" format="default"/> registry:</t> <table anchor="ra"style="headers" title="Newalign="center"> <name>New RADIUSAttributes"> <ttcol>Value</ttcol> <ttcol>Description</ttcol> <ttcol>Data Type</ttcol> <ttcol>Reference</ttcol> <c>245.TBA1</c> <c>DHCPv6-Options</c> <c>string</c> <c>This-Document</c> <c>245.TBA2</c> <c>DHCPv4-Options</c> <c>string</c> <c>This-Document</c> </texttable> <t></t>Attributes</name> <thead> <tr> <th align="left">Value</th> <th align="left">Description</th> <th align="left">Data Type</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">245.3</td> <td align="left">DHCPv6-Options</td> <td align="left">string</td> <td align="left">RFC 9445</td> </tr> <tr> <td align="left">245.4</td> <td align="left">DHCPv4-Options</td> <td align="left">string</td> <td align="left">RFC 9445</td> </tr> </tbody> </table> <t/> </section> <section anchor="urd"title="Newnumbered="true" toc="default"> <name>New RADIUS Attribute Permitted in DHCPv6 RADIUSOption">Option</name> <t>IANAis requested to addhas added the following entry to the "RADIUS Attributes Permitted in DHCPv6 RADIUS Option" subregistry in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry <xreftarget="DHCP-RADIUS"></xref>:</t> <texttabletarget="DHCPv6" format="default"/>:</t> <table anchor="rd"style="headers" title="Newalign="center"> <name>New RADIUS Attribute Permitted in DHCPv6 RADIUSOption"> <ttcol>Type Code</ttcol> <ttcol>Attribute</ttcol> <ttcol>Reference</ttcol> <c>245.TBA1</c> <c>DHCPv6-Options</c> <c>This-Document</c> </texttable> <t></t>Option</name> <thead> <tr> <th align="left">Type Code</th> <th align="left">Attribute</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">245.3</td> <td align="left">DHCPv6-Options</td> <td align="left">RFC 9445</td> </tr> </tbody> </table> <t/> </section> <section anchor="IANA-RAD"title="RADIUSnumbered="true" toc="default"> <name>RADIUS Attributes Permitted in RADIUS Attributes DHCPSub-option">Suboption</name> <t>IANAis requested to createhas created a newsub-registrysubregistry entitled "RADIUS Attributes Permitted in RADIUS AttributesSub-option"DHCP Suboption" in the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters" registry <xreftarget="BOOTP"></xref>.</t>target="BOOTP" format="default"/>.</t> <t>The allocation policy of this newsub-registrysubregistry isExpert Review (Section 4.5 of <xref target="RFC8126"></xref>)."Expert Review" (<xref target="RFC8126" section="4.5" sectionFormat="of"/>). Designated experts should carefully consider the security implications of allowingthea relay agent to include new RADIUS attributestoin thisregistry.subregistry. Additional considerations are provided in <xreftarget="reg"></xref>.</t>target="reg" format="default"/>.</t> <t>The initialcontentcontents of thissub-registry issubregistry are listed in <xreftarget="rad-new"></xref>.target="rad-new" format="default"/>. Thereference may includeReference field includes the document that registers or specifies theAttribute.</t> <texttableattribute.</t> <table anchor="rad-new"style="headers" title="RADIUSalign="center"> <name>Initial Contents of RADIUS Attributes Permitted in RADIUS Attributes DHCPSuboption"> <ttcol>Type Code</ttcol> <ttcol>Attribute</ttcol> <ttcol>Reference</ttcol> <c>1</c> <c>User-Name</c> <c>[RFC2865]</c> <c>6</c> <c>Service-Type</c> <c>[RFC2865]</c> <c>26</c> <c>Vendor-Specific</c> <c>[RFC2865]</c> <c>27</c> <c>Session-Timeout</c> <c>[RFC2865]</c> <c>88</c> <c>Framed-Pool</c> <c>[RFC2869]</c> <c>100</c> <c>Framed-IPv6-Pool</c> <c>[RFC3162]</c> <c>245.TBA2</c> <c>DHCPv4-Options</c> <c>This-Document</c> </texttable> <t></t> </section> <section title="DHCPSuboption Registry</name> <thead> <tr> <th align="left">Type Code</th> <th align="left">Attribute</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">1</td> <td align="left">User-Name</td> <td align="left"><xref target="RFC2865" format="default"/></td> </tr> <tr> <td align="left">6</td> <td align="left">Service-Type</td> <td align="left"><xref target="RFC2865" format="default"/></td> </tr> <tr> <td align="left">26</td> <td align="left">Vendor-Specific</td> <td align="left"><xref target="RFC2865" format="default"/></td> </tr> <tr> <td align="left">27</td> <td align="left">Session-Timeout</td> <td align="left"><xref target="RFC2865" format="default"/></td> </tr> <tr> <td align="left">88</td> <td align="left">Framed-Pool</td> <td align="left"><xref target="RFC2869" format="default"/></td> </tr> <tr> <td align="left">100</td> <td align="left">Framed-IPv6-Pool</td> <td align="left"><xref target="RFC3162" format="default"/></td> </tr> <tr> <td align="left">245.4</td> <td align="left">DHCPv4-Options</td> <td align="left">RFC 9445</td> </tr> </tbody> </table> <t/> </section> <section numbered="true" toc="default"> <name>DHCP Options Permitted in the RADIUS DHCP*-OptionsAttribute"> <t></t>Attributes</name> <t/> <section anchor="drv6-reg"title="DHCPv6">numbered="true" toc="default"> <name>DHCPv6</name> <t>IANAis requested to createhas created a newsub-registrysubregistry entitled "DHCPv6 Options Permitted in the RADIUS DHCPv6-Options Attribute" in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry <xreftarget="DHCP-RADIUS"></xref>.</t>target="DHCPv6" format="default"/>.</t> <t>The registration policy for this newsub-registrysubregistry isExpert Review (Section 4.5 of <xref target="RFC8126"></xref>)."Expert Review" (<xref target="RFC8126" section="4.5" sectionFormat="of"/>). See more details in <xreftarget="reg"></xref>.</t>target="reg" format="default"/>.</t> <t>The initial content of thissub-registrysubregistry is listed in <xreftarget="drv6"></xref>.target="drv6" format="default"/>. The Value and Description fields echo those in the "Option Codes" subregistry of <xreftarget="DHCPv6"></xref>.target="DHCPv6" format="default"/>. Thereference may includeReference field includes the document that registersthe optionorthe document thatspecifies the option.</t><texttable<table anchor="drv6"style="headers" title="Initialalign="center"> <name>Initial Content of DHCPv6 Options Permitted in the RADIUS DHCPv6-OptionsAttribute"> <ttcol>Value</ttcol> <ttcol>Description</ttcol> <ttcol>Reference</ttcol> <c>144</c> <c>OPTION_V6_DNR</c> <c>This-Document</c> </texttable> <t></t>Attribute Registry</name> <thead> <tr> <th align="left">Value</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">144</td> <td align="left">OPTION_V6_DNR</td> <td align="left">RFC 9445</td> </tr> </tbody> </table> <t/> </section> <section anchor="drv4-reg"title="DHCPv4">numbered="true" toc="default"> <name>DHCPv4</name> <t>IANAis requested to createhas created a newsub-registrysubregistry entitled "DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute" in the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters" registry <xreftarget="BOOTP"></xref>.</t>target="BOOTP" format="default"/>.</t> <t>The registration policy for this newsub-registrysubregistry is Expert Review(Section 4.5 of <xref target="RFC8126"></xref>).(<xref target="RFC8126" section="4.5" sectionFormat="of"/>). See more details in <xreftarget="reg"></xref>.</t>target="reg" format="default"/>.</t> <t>The initial content of thissub-registrysubregistry is listed in <xreftarget="drv4"></xref>.target="drv4" format="default"/>. The Tag and Name fields echo those in the "BOOTP Vendor Extensions and DHCP Options" subregistry of <xreftarget="BOOTP"></xref>.target="BOOTP" format="default"/>. Thereference may includeReference field includes the document that registersthe optionorthe document thatspecifies the option.</t><texttable<table anchor="drv4"style="headers" title="Initialalign="center"> <name>Initial Content of DHCPv4 Options Permitted in the RADIUS DHCPv4-OptionsAttribute"> <ttcol>Tag</ttcol> <ttcol>Name</ttcol> <ttcol>Reference</ttcol> <c>162</c> <c>OPTION_V4_DNR</c> <c>This-Document</c> </texttable> <t></t>Attribute Registry</name> <thead> <tr> <th align="left">Tag</th> <th align="left">Name</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">162</td> <td align="left">OPTION_V4_DNR</td> <td align="left">RFC 9445</td> </tr> </tbody> </table> <t/> </section> <section anchor="reg"title="Guidelinesnumbered="true" toc="default"> <name>Guidelines for the DesignatedExperts">Experts</name> <t>It is suggested that multiple designated experts be appointed for registry change requests.</t> <t>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.</t> <t>Registration requests are to be sent toradius-dhcp-review@ietf.org<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.</t> </section> </section> </section><section anchor="Acknowledgements" title="Acknowledgements"> <t>Thanks to Christian Jacquenet, Neil Cook, Joe Clarke, Qin Wu, Dirk von-Hugo, Tom Petch, and Chongfeng Xie for the review and suggestions.</t> <t>Thanks to Ben Schwartz and Bernie Volz for the comments.</t> <t>Thanks to Rob Wilton for the careful AD review.</t> <t>Thanks to Ralf Weber for the dnsdir reviews, Robert Sparks for genart review, and Tatuya Jinmei</middle> <back> <displayreference target="I-D.ietf-add-dnr" to="DNR"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6158.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8044.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6929.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4014.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3396.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6911.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5176.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2868.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2869.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3162.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2132.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7037.xml"/> <!-- [I-D.ietf-add-dnr] IESG state RFC Ed Queue. Updated to long version because missing editor role forthe int-dir review.</t> <t>Thanks to Eric Vyncke, Paul Wouters,Boucadair --> <reference anchor="I-D.ietf-add-dnr" target="https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-16"> <front> <title>DHCP andWarren KumariRouter Advertisement Options for theIESG review.</t> </section> </middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include='reference.RFC.2865'?> <?rfc include='reference.RFC.6158'?> <?rfc include='reference.RFC.8044'?> <?rfc include='reference.RFC.8174'?> <?rfc include='reference.RFC.6929'?> <?rfc include='reference.RFC.8415'?> <?rfc include='reference.RFC.8126'?> <?rfc include='reference.RFC.4014'?> <?rfc include='reference.RFC.3396'?> </references> <references title="Informative References"> <?rfc include='reference.RFC.8499'?> <?rfc include='reference.RFC.6911'?> <?rfc include='reference.RFC.5176'?> <?rfc include='reference.RFC.8484'?> <?rfc include='reference.RFC.7858'?> <?rfc include='reference.RFC.9250'?> <?rfc include='reference.RFC.2868'?> <?rfc include='reference.RFC.2869'?> <?rfc include='reference.RFC.3162'?> <?rfc include='reference.RFC.4861'?> <?rfc include='reference.RFC.2132'?> <?rfc include='reference.RFC.2131'?> <?rfc include='reference.RFC.7037'?> <?rfc include='reference.I-D.ietf-add-dnr'?> <?rfc include='reference.RFC.7227'?> <?rfc include='reference.RFC.7930'?> <?rfc include='reference.RFC.7499'?> <?rfc include='reference.RFC.6977'?>Discovery of Network-designated Resolvers (DNR)</title> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" role="editor"> <organization>Orange</organization> </author> <author initials="T." surname="Reddy.K" fullname="Tirumaleswar Reddy.K" role="editor"> <organization>Nokia</organization> </author> <author initials="D." surname="Wing" fullname="Dan Wing"> <organization>Citrix Systems, Inc.</organization> </author> <author initials="N." surname="Cook" fullname="Neil Cook"> <organization>Open-Xchange</organization> </author> <author initials="T." surname="Jensen" fullname="Tommy Jensen"> <organization>Microsoft</organization> </author> <date month="April" day="27" year="2023"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-add-dnr-16"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7227.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7930.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7499.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6977.xml"/> <reference anchor="RADIUS-Types" target="http://www.iana.org/assignments/radius-types"> <front> <title>RADIUS Types</title> <author> <organization>IANA</organization> </author><date /><date/> </front> </reference> <referenceanchor="DHCP-RADIUS" target="https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml">anchor="DHCPv6" target="https://www.iana.org/assignments/dhcpv6-parameters"> <front> <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title> <author> <organization>IANA</organization> </author><date /><date/> </front> </reference> <reference anchor="BOOTP"target="https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml">target="https://www.iana.org/assignments/bootp-dhcp-parameters"> <front> <title>Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters</title> <author> <organization>IANA</organization> </author><date /> </front> </reference> <reference anchor="DHCPv6" target="https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2"> <front> <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Option Codes</title> <author> <organization>IANA</organization> </author> <date /><date/> </front> </reference> </references> </references> <section anchor="Acknowledgements" numbered="false" toc="default"> <name>Acknowledgements</name> <t>Thanks to <contact fullname="Christian Jacquenet"/>, <contact fullname="Neil Cook"/>, <contact fullname="Joe Clarke"/>, <contact fullname="Qin Wu"/>, <contact fullname="Dirk von-Hugo"/>, <contact fullname="Tom Petch"/>, and <contact fullname="Chongfeng Xie"/> for the review and suggestions.</t> <t>Thanks to <contact fullname="Ben Schwartz"/> and <contact fullname="Bernie Volz"/> for the comments.</t> <t>Thanks to <contact fullname="Rob Wilton"/> for the careful AD review.</t> <t>Thanks to <contact fullname="Ralf Weber"/> for the dnsdir reviews, <contact fullname="Robert Sparks"/> for the genart review, and <contact fullname="Tatuya Jinmei"/> for the intdir review.</t> <t>Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Paul Wouters"/>, and <contact fullname="Warren Kumari"/> for the IESG review.</t> </section> </back> </rfc>