<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-opsawg-add-encrypted-dns-12" number="9445" ipr="trust200902" updates="4014" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2023-08-16T14:30:52" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9445" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="RADIUS DHCP Options">RADIUS Extensions for DHCP-Configured Services</title>
    <seriesInfo name="RFC" value="9445" stream="IETF"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization showOnFrontPage="true">Orange</organization>
      <address>
        <postal>
          <street/>
          <city>Rennes</city>
          <region/>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author fullname="Alan DeKok" initials="A." surname="DeKok">
      <organization showOnFrontPage="true">FreeRADIUS</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <phone/>
        <email>aland@freeradius.org</email>
        <uri/>
      </address>
    </author>
    <date month="08" year="2023"/>
    <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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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.
      Both DHCPv4- and DHCPv6-configured services are covered.
      </t>
      <t indent="0" pn="section-abstract-2">Also, this document updates RFC 4014 by relaxing a constraint on
      permitted RADIUS attributes in the RADIUS Attributes DHCP suboption.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9445" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-radius-dhcp-options-attribu">RADIUS DHCP Options Attributes</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dhcpv6-options-attribute">DHCPv6-Options Attribute</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dhcpv4-options-attribute">DHCPv4-Options Attribute</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-passing-radius-dhcp-options">Passing RADIUS DHCP Options Attributes by DHCP Relay Agents to DHCP Servers</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-context">Context</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-rfc-4014">Updates to RFC 4014</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-section-3-of-rfc-4014">Section 3 of RFC 4014</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-section-4-of-rfc-4014">Section 4 of RFC 4014</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-an-example-applicability-to">An Example: Applicability to Encrypted DNS Provisioning</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-table-of-attributes">Table of Attributes</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-radius-attributes">New RADIUS Attributes</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-radius-attribute-permit">New RADIUS Attribute Permitted in DHCPv6 RADIUS Option</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-radius-attributes-permitted">RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dhcp-options-permitted-in-t">DHCP Options Permitted in the RADIUS DHCP*-Options Attributes</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.4.2">
                  <li pn="section-toc.1-1.8.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.1.1"><xref derivedContent="8.4.1" format="counter" sectionFormat="of" target="section-8.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dhcpv6">DHCPv6</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.2.1"><xref derivedContent="8.4.2" format="counter" sectionFormat="of" target="section-8.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dhcpv4">DHCPv4</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.3.1"><xref derivedContent="8.4.3" format="counter" sectionFormat="of" target="section-8.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidelines-for-the-designat">Guidelines for the Designated Experts</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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 <xref target="RFC2132" format="default" sectionFormat="of" derivedContent="RFC2132"/> <xref target="RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/> and IPv6
      Router Advertisement <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/>) 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) <xref target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/> attributes,
      such as the DNS-Server-IPv6-Address Attribute specified in <xref target="RFC6911" format="default" sectionFormat="of" derivedContent="RFC6911"/>.</t>
      <t indent="0" pn="section-1-2">With the advent of encrypted DNS (e.g., DNS over HTTPS
      (DoH) <xref target="RFC8484" format="default" sectionFormat="of" derivedContent="RFC8484"/>, DNS over TLS (DoT)
      <xref target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC7858"/>, or DNS over QUIC (DoQ) <xref target="RFC9250" format="default" sectionFormat="of" derivedContent="RFC9250"/>), additional means are required to
      provision hosts with network-designated encrypted DNS.  To fill that
      void, <xref target="I-D.ietf-add-dnr" format="default" sectionFormat="of" derivedContent="DNR"/> 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 <xref target="I-D.ietf-add-dnr" format="default" sectionFormat="of" derivedContent="DNR"/>. The
      same concern is likely to be encountered for future services that are
      configured using DHCP.</t>
      <t indent="0" pn="section-1-3">This document specifies two new RADIUS attributes: DHCPv6-Options
      (<xref target="v6" format="default" sectionFormat="of" derivedContent="Section 3.1"/>) and DHCPv4-Options (<xref target="v4" format="default" sectionFormat="of" derivedContent="Section 3.2"/>). These attributes can include
      DHCP options that are listed in the "DHCPv6 Options Permitted
   in the RADIUS DHCPv6-Options Attribute" registry (<xref format="default" target="drv6-reg" sectionFormat="of" derivedContent="Section 8.4.1"/>) and the "DHCP Options Permitted
   in the RADIUS DHCPv4-Options Attribute" registry (<xref format="default" target="drv4-reg" sectionFormat="of" derivedContent="Section 8.4.2"/>). 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" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc6158#section-3.4" derivedContent="RFC6158"/>.</t>
      <t indent="0" pn="section-1-4">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
      <xref target="RFC4014" format="default" sectionFormat="of" derivedContent="RFC4014"/> or <xref target="RFC7037" format="default" sectionFormat="of" derivedContent="RFC7037"/>, 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 <xref target="RFC4014" format="default" sectionFormat="of" derivedContent="RFC4014"/> is required so that a DHCP
      relay agent can pass the DHCPv4-Options Attribute obtained from a RADIUS
      server to a DHCP server (<xref target="RAD" format="default" sectionFormat="of" derivedContent="Section 4"/>).</t>
      <t indent="0" pn="section-1-5">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.</t>
      <t indent="0" pn="section-1-6">This document adheres to <xref target="RFC8044" format="default" sectionFormat="of" derivedContent="RFC8044"/> for defining
      the new attributes.</t>
      <t indent="0" pn="section-1-7">A sample deployment usage of the RADIUS DHCPv6-Options and DHCPv4-Options
      Attributes is described in <xref target="sample" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-2">This document makes use of the terms defined in <xref target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/>, <xref target="RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/>, and <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>. The following additional terms are used: </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-3">
        <dt pn="section-2-3.1">DHCP:</dt>
        <dd pn="section-2-3.2">refers to both DHCPv4 <xref target="RFC2132" format="default" sectionFormat="of" derivedContent="RFC2132"/>
        and DHCPv6 <xref target="RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/>.</dd>
        <dt pn="section-2-3.3">Encrypted DNS:</dt>
        <dd pn="section-2-3.4">refers to a scheme where DNS exchanges are transported over an
        encrypted channel. Examples of encrypted DNS are DoT, DoH, and
        DoQ.</dd>
        <dt pn="section-2-3.5">Encrypted DNS resolver:</dt>
        <dd pn="section-2-3.6">refers to a resolver (<xref section="6" target="RFC8499" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8499#section-6" derivedContent="RFC8499"/>) that supports encrypted DNS.</dd>
        <dt pn="section-2-3.7">DHCP*-Options:</dt>
        <dd pn="section-2-3.8">refers to the DHCPv4-Options and DHCPv6-Options Attributes (<xref target="att" format="default" sectionFormat="of" derivedContent="Section 3"/>).</dd>
      </dl>
    </section>
    <section anchor="att" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-radius-dhcp-options-attribu">RADIUS DHCP Options Attributes</name>
      <t indent="0" pn="section-3-1">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 indent="0" pn="section-3-2">Both the DHCPv4-Options and DHCPv6-Options Attributes use the "Long
      Extended Type" format (<xref section="2.2" target="RFC6929" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc6929#section-2.2" derivedContent="RFC6929"/>).
      The description of the fields is provided in Sections <xref format="counter" target="v6" sectionFormat="of" derivedContent="3.1"/> and <xref format="counter" target="v4" sectionFormat="of" derivedContent="3.2"/>.</t>
      <t indent="0" pn="section-3-3">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 (<xref section="3" target="RFC2865" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc2865#section-3" derivedContent="RFC2865"/>). In order to accommodate
      deployments with large DHCP options, RADIUS implementations are
      <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 bytes (e.g., the mechanisms described in <xref target="RFC7499" format="default" sectionFormat="of" derivedContent="RFC7499"/>
      or <xref target="RFC7930" format="default" sectionFormat="of" derivedContent="RFC7930"/>).</t>
      <t indent="0" pn="section-3-4">The Value fields of the DHCP*-Options Attributes are encoded in the clear and
      not encrypted like, for example, the Tunnel-Password Attribute <xref target="RFC2868" format="default" sectionFormat="of" derivedContent="RFC2868"/>.</t>
      <t indent="0" pn="section-3-5">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 <bcp14>SHOULD</bcp14> ignore
      non-permitted DHCP options received in a RADIUS DHCP*-Options 
      Attribute.</t>
      <t indent="0" pn="section-3-6">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.</t>
      <t indent="0" pn="section-3-7">These attributes are defined with globally unique names. The naming
      of the attributes follows the guidelines in <xref target="RFC6929" section="2.7.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6929#section-2.7.1" derivedContent="RFC6929"/>. Invalid attributes are handled as per <xref target="RFC6929" section="2.8" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6929#section-2.8" derivedContent="RFC6929"/>.</t>
      <section anchor="v6" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-dhcpv6-options-attribute">DHCPv6-Options Attribute</name>
        <t indent="0" pn="section-3.1-1">This attribute is of type "string" as defined in <xref section="3.5" target="RFC8044" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8044#section-3.5" derivedContent="RFC8044"/>.</t>
        <t indent="0" pn="section-3.1-2">The DHCPv6-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS Access-Accept
        packet. It <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 indent="0" pn="section-3.1-3">The DHCPv6-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS CoA-Request
        packet.</t>
        <t indent="0" pn="section-3.1-4">The DHCPv6-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS
        Accounting-Request packet.</t>
        <t indent="0" pn="section-3.1-5">The DHCPv6-Options Attribute <bcp14>MUST NOT</bcp14> appear in any other RADIUS
        packet.</t>
        <t indent="0" pn="section-3.1-6">The DHCPv6-Options Attribute is structured as follows:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.1-7">
          <dt pn="section-3.1-7.1">Type</dt>
          <dd pn="section-3.1-7.2">
            <t indent="0" pn="section-3.1-7.2.1">245</t>
          </dd>
          <dt pn="section-3.1-7.3">Length</dt>
          <dd pn="section-3.1-7.4">This field indicates the total length, in octets, of all
             fields of this attribute, including the Type, Length,
             Extended-Type, and Value fields.</dd>
          <dt pn="section-3.1-7.5">Extended-Type</dt>
          <dd pn="section-3.1-7.6">3 (see <xref target="IANA-Att" format="default" sectionFormat="of" derivedContent="Section 8.1"/>)</dd>
          <dt pn="section-3.1-7.7">Value</dt>
          <dd pn="section-3.1-7.8">
            <t indent="0" pn="section-3.1-7.8.1">This field contains a list of DHCPv6 options (<xref target="RFC8415" section="21" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8415#section-21" derivedContent="RFC8415"/>). Multiple
             instances of the same DHCPv6 option <bcp14>MAY</bcp14> be
             included. If an option appears multiple times, each instance is
             considered separate, and the data areas of the options <bcp14>MUST NOT</bcp14> be concatenated or otherwise combined.  Consistent
             with <xref target="RFC7227" section="17" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7227#section-17" derivedContent="RFC7227"/>,
             this document does not impose any option order when multiple
             options are present.</t>
            <t indent="0" pn="section-3.1-7.8.2">The permitted DHCPv6 options are
             listed in the "DHCPv6 Options Permitted
   in the RADIUS DHCPv6-Options Attribute" registry (<xref format="default" target="drv6-reg" sectionFormat="of" derivedContent="Section 8.4.1"/>).</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.1-8">The DHCPv6-Options Attribute is associated with the following
        identifier: 245.3.</t>
      </section>
      <section anchor="v4" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-dhcpv4-options-attribute">DHCPv4-Options Attribute</name>
        <t indent="0" pn="section-3.2-1">This attribute is of type "string" as defined in <xref section="3.5" target="RFC8044" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8044#section-3.5" derivedContent="RFC8044"/>.</t>
        <t indent="0" pn="section-3.2-2">The DHCPv4-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS Access-Accept
        packet. It <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 indent="0" pn="section-3.2-3">The DHCPv4-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS CoA-Request
        packet.</t>
        <t indent="0" pn="section-3.2-4">The DHCPv4-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS
        Accounting-Request packet.</t>
        <t indent="0" pn="section-3.2-5">The DHCPv4-Options Attribute <bcp14>MUST NOT</bcp14> appear in any other RADIUS
        packet.</t>
        <t indent="0" pn="section-3.2-6">The DHCPv4-Options Attribute is structured as follows:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.2-7">
          <dt pn="section-3.2-7.1">Type</dt>
          <dd pn="section-3.2-7.2">245</dd>
          <dt pn="section-3.2-7.3">Length</dt>
          <dd pn="section-3.2-7.4">This field indicates the total length, in octets, of all fields
          of this attribute, including the Type, Length, Extended-Type, and
          Value fields.</dd>
          <dt pn="section-3.2-7.5">Extended-Type</dt>
          <dd pn="section-3.2-7.6">4 (see <xref target="IANA-Att" format="default" sectionFormat="of" derivedContent="Section 8.1"/>)</dd>
          <dt pn="section-3.2-7.7">Value</dt>
          <dd pn="section-3.2-7.8">
            <t indent="0" pn="section-3.2-7.8.1">This field contains a list of DHCPv4 options. Multiple
          instances of the same DHCPv4 option <bcp14>MAY</bcp14> be included,
          especially for concatenation-requiring options that exceed the
          maximum DHCPv4 option size of 255 octets. The mechanism specified in
          <xref target="RFC3396" format="default" sectionFormat="of" derivedContent="RFC3396"/> <bcp14>MUST</bcp14> be
          used for splitting and concatenating the instances of a
          concatenation-requiring option.</t>
            <t indent="0" pn="section-3.2-7.8.2">The permitted DHCPv4 options are
          listed in the "DHCP Options Permitted
   in the RADIUS DHCPv4-Options Attribute" registry (<xref format="default" target="drv4-reg" sectionFormat="of" derivedContent="Section 8.4.2"/>).</t>
          </dd>
        </dl>
        <t indent="0" pn="section-3.2-8">The DHCPv4-Options Attribute is associated with the following
        identifier: 245.4.</t>
      </section>
    </section>
    <section anchor="RAD" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-passing-radius-dhcp-options">Passing RADIUS DHCP Options Attributes by DHCP Relay Agents to DHCP Servers</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-context">Context</name>
        <t indent="0" pn="section-4.1-1">The RADIUS Attributes DHCP suboption <xref target="RFC4014" format="default" sectionFormat="of" derivedContent="RFC4014"/> enables a DHCPv4 relay agent to pass identification
        and authorization attributes received during RADIUS authentication to
        a DHCPv4 server.  However, <xref target="RFC4014" format="default" sectionFormat="of" derivedContent="RFC4014"/>
        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 <xref target="I-D.ietf-add-dnr" format="default" sectionFormat="of" derivedContent="DNR"/>).</t>
        <t indent="0" pn="section-4.1-2"><xref target="update" format="default" sectionFormat="of" derivedContent="Section 4.2"/> updates <xref target="RFC4014" format="default" sectionFormat="of" derivedContent="RFC4014"/> 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 (<xref target="IANA-RAD" format="default" sectionFormat="of" derivedContent="Section 8.3"/>).
        </t>
      </section>
      <section anchor="update" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-updates-to-rfc-4014">Updates to RFC 4014</name>
        <t indent="0" pn="section-4.2-1"/>
        <section anchor="update1" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-section-3-of-rfc-4014">Section 3 of RFC 4014</name>
          <t indent="0" pn="section-4.2.1-1">This document updates <xref target="RFC4014" section="3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4014#section-3" derivedContent="RFC4014"/>
          as follows:</t>
          <t indent="0" pn="section-4.2.1-2">OLD:</t>
          <blockquote pn="section-4.2.1-3">
            <t indent="0" pn="section-4.2.1-3.1">To avoid dependencies between the address
              allocation and other state information between the RADIUS server
              and the DHCP server, the DHCP relay agent <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 that
              <bcp14>MAY</bcp14> be included:</t>
            <artwork name="" type="" align="left" alt="" pn="section-4.2.1-3.2">
           #   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>
          </blockquote>
          <t indent="0" pn="section-4.2.1-4">NEW:</t>
          <blockquote pn="section-4.2.1-5">
            <t indent="0" pn="section-4.2.1-5.1">To avoid dependencies between the address
            allocation and other state information between the RADIUS server
            and the DHCP server, the DHCP relay agent <bcp14>SHOULD</bcp14>
            only include the attributes in the "RADIUS Attributes
   Permitted in RADIUS Attributes DHCP Suboption" registry (<xref target="IANA-RAD" format="default" sectionFormat="of" derivedContent="Section 8.3"/> of [RFC9445]) in an instance
            of the RADIUS Attributes DHCP suboption. The DHCP relay agent may
            support a configuration parameter to control the attributes in a
            RADIUS Attributes DHCP suboption.</t>
          </blockquote>
        </section>
        <section anchor="update2" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-section-4-of-rfc-4014">Section 4 of RFC 4014</name>
          <t indent="0" pn="section-4.2.2-1">This document updates <xref target="RFC4014" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4014#section-4" derivedContent="RFC4014"/>
          as follows:</t>
          <t indent="0" pn="section-4.2.2-2">OLD:</t>
          <blockquote pn="section-4.2.2-3">
            <t indent="0" pn="section-4.2.2-3.1">If the relay agent relays RADIUS attributes not
            included in the table in Section 4, the DHCP server
            <bcp14>SHOULD</bcp14> ignore them.</t>
          </blockquote>
          <t indent="0" pn="section-4.2.2-4">NEW:</t>
          <blockquote pn="section-4.2.2-5">
            <t indent="0" pn="section-4.2.2-5.1">If the relay agent relays RADIUS attributes not
            included in the "RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption" registry (<xref target="IANA-RAD" format="default" sectionFormat="of" derivedContent="Section 8.3"/> of [RFC9445]) and explicit
            configuration is absent, the DHCP server <bcp14>SHOULD</bcp14> ignore
            them.</t>
          </blockquote>
        </section>
      </section>
    </section>
    <section anchor="sample" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-an-example-applicability-to">An Example: Applicability to Encrypted DNS Provisioning</name>
      <t indent="0" pn="section-5-1">Typical deployment scenarios are similar to those described, for
      instance, in <xref section="2" target="RFC6911" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc6911#section-2" derivedContent="RFC6911"/>. For
      illustration purposes, <xref target="ex" format="default" sectionFormat="of" derivedContent="Figure 1"/> 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>
      <figure anchor="ex" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-an-example-of-radius-ipv6-e">An Example of RADIUS IPv6 Encrypted DNS Exchange</name>
        <artwork name="" type="" align="left" alt="" pn="section-5-2.1">
+-------------+           +-------------+             +-------+
|     CPE     |           |     NAS     |             |  AAA  |
|DHCPv6 Client|           |DHCPv6 Server|             |Server |
|             |           |RADIUS Client|             |       |
+------+------+           +------+------+             +---+---+
       |                         |                        |
       o-----DHCPv6 Solicit-----&gt;|                        |
       |                         o----Access-Request ----&gt;|
       |                         |                        |
       |                         |&lt;----Access-Accept------o
       |                         |     DHCPv6-Options     |
       |&lt;----DHCPv6 Advertise----o    (OPTION_V6_DNR)     |
       |     (OPTION_V6_DNR)     |                        |
       |                         |                        |
       o-----DHCPv6 Request-----&gt;|                        |
       |                         |                        |
       |&lt;------DHCPv6 Reply------o                        |
       |     (OPTION_V6_DNR)     |                        |
       |                         |                        |

                DHCPv6                     RADIUS
</artwork>
      </figure>
      <t indent="0" pn="section-5-3">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 <xref target="I-D.ietf-add-dnr" format="default" sectionFormat="of" derivedContent="DNR"/> 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 <xref target="I-D.ietf-add-dnr" format="default" sectionFormat="of" derivedContent="DNR"/> is then followed between
      the DHCPv6 client and the DHCPv6 server.</t>
      <t indent="0" pn="section-5-4">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 <xref target="RFC5176" format="default" sectionFormat="of" derivedContent="RFC5176"/> 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.</t>
      <t indent="0" pn="section-5-5">In deployments where the NAS behaves as a DHCPv6 relay agent, the
      procedure discussed in <xref section="3" target="RFC7037" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7037#section-3" derivedContent="RFC7037"/> can be followed. 

To that aim, the "RADIUS Attributes Permitted in DHCPv6
      RADIUS Option" registry has been updated (<xref target="urd" format="default" sectionFormat="of" derivedContent="Section 8.2"/>). CoA-Requests can be used following the procedure
      specified in <xref target="RFC6977" format="default" sectionFormat="of" derivedContent="RFC6977"/>.</t>
      <t indent="0" pn="section-5-6"><xref target="ex2" format="default" sectionFormat="of" derivedContent="Figure 2"/> 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>
      <figure anchor="ex2" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-an-example-of-radius-ipv4-e">An Example of RADIUS IPv4 Encrypted DNS Exchange</name>
        <artwork name="" type="" align="left" alt="" pn="section-5-7.1">
+-------------+           +-------------+             +-------+
|     CPE     |           |     NAS     |             |  AAA  |
|DHCPv4 Client|           |DHCPv4 Server|             |Server |
|             |           |RADIUS Client|             |       |
+------+------+           +------+------+             +---+---+
       |                         |                        |
       o------DHCPDISCOVER------&gt;|                        |
       |                         o----Access-Request ----&gt;|
       |                         |                        |
       |                         |&lt;----Access-Accept------o
       |                         |     DHCPv4-Options     |
       |&lt;-----DHCPOFFER----------o    (OPTION_V4_DNR)     |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |
       o-----DHCPREQUEST--------&gt;|                        |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |
       |&lt;-------DHCPACK----------o                        |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |

               DHCPv4                      RADIUS
</artwork>
      </figure>
      <t indent="0" pn="section-5-8">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.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">RADIUS-related security considerations are discussed in <xref target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/>.</t>
      <t indent="0" pn="section-6-2">DHCPv6-related security issues are discussed in <xref section="22" target="RFC8415" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8415#section-22" derivedContent="RFC8415"/>, while DHCPv4-related security issues are
      discussed in <xref section="7" target="RFC2131" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc2131#section-7" derivedContent="RFC2131"/>. 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" format="default" sectionFormat="of" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-16#section-7" derivedContent="DNR"/>.</t>
      <t indent="0" pn="section-6-3">RADIUS servers have conventionally tolerated the input of arbitrary
      data via the "string" data type (<xref section="3.5" target="RFC8044" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8044#section-3.5" derivedContent="RFC8044"/>). 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 <bcp14>RECOMMENDED</bcp14> 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.</t>
      <t indent="0" pn="section-6-4">The considerations discussed in <xref target="RFC4014" section="7" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4014#section-7" derivedContent="RFC4014"/> and <xref target="RFC7037" section="8" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7037#section-8" derivedContent="RFC7037"/>
      should be taken into account in deployments where DHCP relay agents pass
      the DHCP*-Options Attributes to DHCP servers. Additional considerations
      specific to the use of Reconfigure messages are discussed in <xref section="9" target="RFC6977" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc6977#section-9" derivedContent="RFC6977"/>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-table-of-attributes">Table of Attributes</name>
      <t indent="0" pn="section-7-1">The following table provides a guide as to what type of RADIUS packets
      may contain these attributes and in what quantity.</t>
      <table align="left" anchor="attributes-table" pn="table-1">
        <name slugifiedName="name-table-of-attributes-2">Table of Attributes</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Access-Request</th>
            <th align="left" colspan="1" rowspan="1">Access-Accept</th>
            <th align="left" colspan="1" rowspan="1">Access-Reject</th>
            <th align="left" colspan="1" rowspan="1">Challenge</th>
            <th align="left" colspan="1" rowspan="1">#</th>
            <th align="left" colspan="1" rowspan="1">Attribute</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0+</td>
            <td align="left" colspan="1" rowspan="1">0+</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">245.3</td>
            <td align="left" colspan="1" rowspan="1">DHCPv6-Options</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0+</td>
            <td align="left" colspan="1" rowspan="1">0+</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">245.4</td>
            <td align="left" colspan="1" rowspan="1">DHCPv4-Options</td>
          </tr>
          <tr>
            <th align="left" colspan="1" rowspan="1">Accounting-Request</th>
            <th align="left" colspan="1" rowspan="1">CoA-Request</th>
            <th align="left" colspan="1" rowspan="1">CoA-ACK</th>
            <th align="left" colspan="1" rowspan="1">CoA-NACK</th>
            <th align="left" colspan="1" rowspan="1">#</th>
            <th align="left" colspan="1" rowspan="1">Attribute</th>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0+</td>
            <td align="left" colspan="1" rowspan="1">0+</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">245.3</td>
            <td align="left" colspan="1" rowspan="1">DHCPv6-Options</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">0+</td>
            <td align="left" colspan="1" rowspan="1">0+</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">245.4</td>
            <td align="left" colspan="1" rowspan="1">DHCPv4-Options</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-7-3">Notation for <xref target="attributes-table" format="default" sectionFormat="of" derivedContent="Table 1"/>:</t>
      <dl newline="false" spacing="normal" indent="4" pn="section-7-4">
        <dt pn="section-7-4.1">0</dt>
        <dd pn="section-7-4.2">This attribute <bcp14>MUST NOT</bcp14> be present in
  packet.</dd>
        <dt pn="section-7-4.3">0+</dt>
        <dd pn="section-7-4.4">Zero or more instances of this attribute <bcp14>MAY</bcp14>
  be present in packet.</dd>
      </dl>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="IANA-Att" numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-new-radius-attributes">New RADIUS Attributes</name>
        <t indent="0" pn="section-8.1-1">IANA has assigned two new RADIUS attribute types in the
         "Radius Attribute Types" <xref target="RADIUS-Types" format="default" sectionFormat="of" derivedContent="RADIUS-Types"/> registry:</t>
        <table anchor="ra" align="center" pn="table-2">
          <name slugifiedName="name-new-radius-attributes-2">New RADIUS Attributes</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Data Type</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">245.3</td>
              <td align="left" colspan="1" rowspan="1">DHCPv6-Options</td>
              <td align="left" colspan="1" rowspan="1">string</td>
              <td align="left" colspan="1" rowspan="1">RFC 9445</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">245.4</td>
              <td align="left" colspan="1" rowspan="1">DHCPv4-Options</td>
              <td align="left" colspan="1" rowspan="1">string</td>
              <td align="left" colspan="1" rowspan="1">RFC 9445</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-8.1-3"/>
      </section>
      <section anchor="urd" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-new-radius-attribute-permit">New RADIUS Attribute Permitted in DHCPv6 RADIUS Option</name>
        <t indent="0" pn="section-8.2-1">IANA 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 <xref target="DHCPv6" format="default" sectionFormat="of" derivedContent="DHCPv6"/>:</t>
        <table anchor="rd" align="center" pn="table-3">
          <name slugifiedName="name-new-radius-attribute-permitt">New RADIUS Attribute Permitted in DHCPv6 RADIUS Option</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type Code</th>
              <th align="left" colspan="1" rowspan="1">Attribute</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">245.3</td>
              <td align="left" colspan="1" rowspan="1">DHCPv6-Options</td>
              <td align="left" colspan="1" rowspan="1">RFC 9445</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-8.2-3"/>
      </section>
      <section anchor="IANA-RAD" numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-radius-attributes-permitted">RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption</name>
        <t indent="0" pn="section-8.3-1">IANA 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 <xref target="BOOTP" format="default" sectionFormat="of" derivedContent="BOOTP"/>.</t>
        <t indent="0" pn="section-8.3-2">The allocation policy of this new subregistry is "Expert Review"
        (<xref target="RFC8126" section="4.5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.5" derivedContent="RFC8126"/>). 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 <xref target="reg" format="default" sectionFormat="of" derivedContent="Section 8.4.3"/>.</t>
        <t indent="0" pn="section-8.3-3">The initial contents of this subregistry are listed in <xref target="rad-new" format="default" sectionFormat="of" derivedContent="Table 4"/>. The Reference field includes the document that
        registers or specifies the attribute.</t>
        <table anchor="rad-new" align="center" pn="table-4">
          <name slugifiedName="name-initial-contents-of-radius-">Initial Contents of RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type Code</th>
              <th align="left" colspan="1" rowspan="1">Attribute</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">User-Name</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">6</td>
              <td align="left" colspan="1" rowspan="1">Service-Type</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">26</td>
              <td align="left" colspan="1" rowspan="1">Vendor-Specific</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">27</td>
              <td align="left" colspan="1" rowspan="1">Session-Timeout</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">88</td>
              <td align="left" colspan="1" rowspan="1">Framed-Pool</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC2869" format="default" sectionFormat="of" derivedContent="RFC2869"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">100</td>
              <td align="left" colspan="1" rowspan="1">Framed-IPv6-Pool</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC3162" format="default" sectionFormat="of" derivedContent="RFC3162"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">245.4</td>
              <td align="left" colspan="1" rowspan="1">DHCPv4-Options</td>
              <td align="left" colspan="1" rowspan="1">RFC 9445</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-8.3-5"/>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-8.4">
        <name slugifiedName="name-dhcp-options-permitted-in-t">DHCP Options Permitted in the RADIUS DHCP*-Options Attributes</name>
        <t indent="0" pn="section-8.4-1"/>
        <section anchor="drv6-reg" numbered="true" toc="include" removeInRFC="false" pn="section-8.4.1">
          <name slugifiedName="name-dhcpv6">DHCPv6</name>
          <t indent="0" pn="section-8.4.1-1">IANA 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
          <xref target="DHCPv6" format="default" sectionFormat="of" derivedContent="DHCPv6"/>.</t>
          <t indent="0" pn="section-8.4.1-2">The registration policy for this new subregistry is "Expert
          Review" (<xref target="RFC8126" section="4.5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.5" derivedContent="RFC8126"/>). See more details in <xref target="reg" format="default" sectionFormat="of" derivedContent="Section 8.4.3"/>.</t>
          <t indent="0" pn="section-8.4.1-3">The initial content of this subregistry is listed in <xref target="drv6" format="default" sectionFormat="of" derivedContent="Table 5"/>. The Value and Description fields
          echo those in the "Option Codes" subregistry of <xref target="DHCPv6" format="default" sectionFormat="of" derivedContent="DHCPv6"/>. The Reference field includes the
          document that registers or specifies the option.</t>
          <table anchor="drv6" align="center" pn="table-5">
            <name slugifiedName="name-initial-content-of-dhcpv6-o">Initial Content of DHCPv6 Options Permitted in the RADIUS DHCPv6-Options Attribute Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Value</th>
                <th align="left" colspan="1" rowspan="1">Description</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">144</td>
                <td align="left" colspan="1" rowspan="1">OPTION_V6_DNR</td>
                <td align="left" colspan="1" rowspan="1">RFC 9445</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-8.4.1-5"/>
        </section>
        <section anchor="drv4-reg" numbered="true" toc="include" removeInRFC="false" pn="section-8.4.2">
          <name slugifiedName="name-dhcpv4">DHCPv4</name>
          <t indent="0" pn="section-8.4.2-1">IANA 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 <xref target="BOOTP" format="default" sectionFormat="of" derivedContent="BOOTP"/>.</t>
          <t indent="0" pn="section-8.4.2-2">The registration policy for this new subregistry is Expert
          Review (<xref target="RFC8126" section="4.5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.5" derivedContent="RFC8126"/>). See more
          details in <xref target="reg" format="default" sectionFormat="of" derivedContent="Section 8.4.3"/>.</t>
          <t indent="0" pn="section-8.4.2-3">The initial content of this subregistry is listed in <xref target="drv4" format="default" sectionFormat="of" derivedContent="Table 6"/>. The Tag and Name fields echo those
          in the "BOOTP Vendor Extensions and DHCP Options" subregistry of
          <xref target="BOOTP" format="default" sectionFormat="of" derivedContent="BOOTP"/>. The Reference field
          includes the document that registers or specifies the option.</t>
          <table anchor="drv4" align="center" pn="table-6">
            <name slugifiedName="name-initial-content-of-dhcpv4-o">Initial Content of DHCPv4 Options Permitted in the RADIUS DHCPv4-Options Attribute Registry</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Tag</th>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">162</td>
                <td align="left" colspan="1" rowspan="1">OPTION_V4_DNR</td>
                <td align="left" colspan="1" rowspan="1">RFC 9445</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-8.4.2-5"/>
        </section>
        <section anchor="reg" numbered="true" toc="include" removeInRFC="false" pn="section-8.4.3">
          <name slugifiedName="name-guidelines-for-the-designat">Guidelines for the Designated Experts</name>
          <t indent="0" pn="section-8.4.3-1">It is suggested that multiple designated experts be appointed for
          registry change requests.</t>
          <t indent="0" pn="section-8.4.3-2">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 indent="0" pn="section-8.4.3-3">Registration requests are to be sent to
          &lt;radius-dhcp-review@ietf.org&gt; 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>
  </middle>
  <back>
    <displayreference target="I-D.ietf-add-dnr" to="DNR"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2865" target="https://www.rfc-editor.org/info/rfc2865" quoteTitle="true" derivedAnchor="RFC2865">
          <front>
            <title>Remote Authentication Dial In User Service (RADIUS)</title>
            <author fullname="C. Rigney" initials="C." surname="Rigney"/>
            <author fullname="S. Willens" initials="S." surname="Willens"/>
            <author fullname="A. Rubens" initials="A." surname="Rubens"/>
            <author fullname="W. Simpson" initials="W." surname="Simpson"/>
            <date month="June" year="2000"/>
            <abstract>
              <t indent="0">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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2865"/>
          <seriesInfo name="DOI" value="10.17487/RFC2865"/>
        </reference>
        <reference anchor="RFC3396" target="https://www.rfc-editor.org/info/rfc3396" quoteTitle="true" derivedAnchor="RFC3396">
          <front>
            <title>Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)</title>
            <author fullname="T. Lemon" initials="T." surname="Lemon"/>
            <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
            <date month="November" year="2002"/>
          </front>
          <seriesInfo name="RFC" value="3396"/>
          <seriesInfo name="DOI" value="10.17487/RFC3396"/>
        </reference>
        <reference anchor="RFC4014" target="https://www.rfc-editor.org/info/rfc4014" quoteTitle="true" derivedAnchor="RFC4014">
          <front>
            <title>Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option</title>
            <author fullname="R. Droms" initials="R." surname="Droms"/>
            <author fullname="J. Schnizlein" initials="J." surname="Schnizlein"/>
            <date month="February" year="2005"/>
            <abstract>
              <t indent="0">The 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4014"/>
          <seriesInfo name="DOI" value="10.17487/RFC4014"/>
        </reference>
        <reference anchor="RFC6158" target="https://www.rfc-editor.org/info/rfc6158" quoteTitle="true" derivedAnchor="RFC6158">
          <front>
            <title>RADIUS Design Guidelines</title>
            <author fullname="A. DeKok" initials="A." role="editor" surname="DeKok"/>
            <author fullname="G. Weber" initials="G." surname="Weber"/>
            <date month="March" year="2011"/>
            <abstract>
              <t indent="0">This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="158"/>
          <seriesInfo name="RFC" value="6158"/>
          <seriesInfo name="DOI" value="10.17487/RFC6158"/>
        </reference>
        <reference anchor="RFC6929" target="https://www.rfc-editor.org/info/rfc6929" quoteTitle="true" derivedAnchor="RFC6929">
          <front>
            <title>Remote Authentication Dial In User Service (RADIUS) Protocol Extensions</title>
            <author fullname="A. DeKok" initials="A." surname="DeKok"/>
            <author fullname="A. Lior" initials="A." surname="Lior"/>
            <date month="April" year="2013"/>
            <abstract>
              <t indent="0">The 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6929"/>
          <seriesInfo name="DOI" value="10.17487/RFC6929"/>
        </reference>
        <reference anchor="RFC8044" target="https://www.rfc-editor.org/info/rfc8044" quoteTitle="true" derivedAnchor="RFC8044">
          <front>
            <title>Data Types in RADIUS</title>
            <author fullname="A. DeKok" initials="A." surname="DeKok"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">RADIUS 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8044"/>
          <seriesInfo name="DOI" value="10.17487/RFC8044"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many 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).</t>
              <t indent="0">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.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8415" target="https://www.rfc-editor.org/info/rfc8415" quoteTitle="true" derivedAnchor="RFC8415">
          <front>
            <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
            <author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
            <author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
            <author fullname="B. Volz" initials="B." surname="Volz"/>
            <author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="S. Jiang" initials="S." surname="Jiang"/>
            <author fullname="T. Lemon" initials="T." surname="Lemon"/>
            <author fullname="T. Winters" initials="T." surname="Winters"/>
            <date month="November" year="2018"/>
            <abstract>
              <t indent="0">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).</t>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8415"/>
          <seriesInfo name="DOI" value="10.17487/RFC8415"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="BOOTP" target="https://www.iana.org/assignments/bootp-dhcp-parameters" quoteTitle="true" derivedAnchor="BOOTP">
          <front>
            <title>Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="DHCPv6" target="https://www.iana.org/assignments/dhcpv6-parameters" quoteTitle="true" derivedAnchor="DHCPv6">
          <front>
            <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-add-dnr" target="https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-16" quoteTitle="true" derivedAnchor="DNR">
          <front>
            <title>DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title>
            <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" role="editor">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <author initials="T." surname="Reddy.K" fullname="Tirumaleswar Reddy.K" role="editor">
              <organization showOnFrontPage="true">Nokia</organization>
            </author>
            <author initials="D." surname="Wing" fullname="Dan Wing">
              <organization showOnFrontPage="true">Citrix Systems, Inc.</organization>
            </author>
            <author initials="N." surname="Cook" fullname="Neil Cook">
              <organization showOnFrontPage="true">Open-Xchange</organization>
            </author>
            <author initials="T." surname="Jensen" fullname="Tommy Jensen">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <date month="April" day="27" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-add-dnr-16"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RADIUS-Types" target="http://www.iana.org/assignments/radius-types" quoteTitle="true" derivedAnchor="RADIUS-Types">
          <front>
            <title>RADIUS Types</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC2131" target="https://www.rfc-editor.org/info/rfc2131" quoteTitle="true" derivedAnchor="RFC2131">
          <front>
            <title>Dynamic Host Configuration Protocol</title>
            <author fullname="R. Droms" initials="R." surname="Droms"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">The 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2131"/>
          <seriesInfo name="DOI" value="10.17487/RFC2131"/>
        </reference>
        <reference anchor="RFC2132" target="https://www.rfc-editor.org/info/rfc2132" quoteTitle="true" derivedAnchor="RFC2132">
          <front>
            <title>DHCP Options and BOOTP Vendor Extensions</title>
            <author fullname="S. Alexander" initials="S." surname="Alexander"/>
            <author fullname="R. Droms" initials="R." surname="Droms"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2132"/>
          <seriesInfo name="DOI" value="10.17487/RFC2132"/>
        </reference>
        <reference anchor="RFC2868" target="https://www.rfc-editor.org/info/rfc2868" quoteTitle="true" derivedAnchor="RFC2868">
          <front>
            <title>RADIUS Attributes for Tunnel Protocol Support</title>
            <author fullname="G. Zorn" initials="G." surname="Zorn"/>
            <author fullname="D. Leifer" initials="D." surname="Leifer"/>
            <author fullname="A. Rubens" initials="A." surname="Rubens"/>
            <author fullname="J. Shriver" initials="J." surname="Shriver"/>
            <author fullname="M. Holdrege" initials="M." surname="Holdrege"/>
            <author fullname="I. Goyret" initials="I." surname="Goyret"/>
            <date month="June" year="2000"/>
            <abstract>
              <t indent="0">This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2868"/>
          <seriesInfo name="DOI" value="10.17487/RFC2868"/>
        </reference>
        <reference anchor="RFC2869" target="https://www.rfc-editor.org/info/rfc2869" quoteTitle="true" derivedAnchor="RFC2869">
          <front>
            <title>RADIUS Extensions</title>
            <author fullname="C. Rigney" initials="C." surname="Rigney"/>
            <author fullname="W. Willats" initials="W." surname="Willats"/>
            <author fullname="P. Calhoun" initials="P." surname="Calhoun"/>
            <date month="June" year="2000"/>
            <abstract>
              <t indent="0">This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2869"/>
          <seriesInfo name="DOI" value="10.17487/RFC2869"/>
        </reference>
        <reference anchor="RFC3162" target="https://www.rfc-editor.org/info/rfc3162" quoteTitle="true" derivedAnchor="RFC3162">
          <front>
            <title>RADIUS and IPv6</title>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="G. Zorn" initials="G." surname="Zorn"/>
            <author fullname="D. Mitton" initials="D." surname="Mitton"/>
            <date month="August" year="2001"/>
            <abstract>
              <t indent="0">This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3162"/>
          <seriesInfo name="DOI" value="10.17487/RFC3162"/>
        </reference>
        <reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4861" quoteTitle="true" derivedAnchor="RFC4861">
          <front>
            <title>Neighbor Discovery for IP version 6 (IPv6)</title>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
            <author fullname="W. Simpson" initials="W." surname="Simpson"/>
            <author fullname="H. Soliman" initials="H." surname="Soliman"/>
            <date month="September" year="2007"/>
            <abstract>
              <t indent="0">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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4861"/>
          <seriesInfo name="DOI" value="10.17487/RFC4861"/>
        </reference>
        <reference anchor="RFC5176" target="https://www.rfc-editor.org/info/rfc5176" quoteTitle="true" derivedAnchor="RFC5176">
          <front>
            <title>Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)</title>
            <author fullname="M. Chiba" initials="M." surname="Chiba"/>
            <author fullname="G. Dommety" initials="G." surname="Dommety"/>
            <author fullname="M. Eklund" initials="M." surname="Eklund"/>
            <author fullname="D. Mitton" initials="D." surname="Mitton"/>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <date month="January" year="2008"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5176"/>
          <seriesInfo name="DOI" value="10.17487/RFC5176"/>
        </reference>
        <reference anchor="RFC6911" target="https://www.rfc-editor.org/info/rfc6911" quoteTitle="true" derivedAnchor="RFC6911">
          <front>
            <title>RADIUS Attributes for IPv6 Access Networks</title>
            <author fullname="W. Dec" initials="W." role="editor" surname="Dec"/>
            <author fullname="B. Sarikaya" initials="B." surname="Sarikaya"/>
            <author fullname="G. Zorn" initials="G." role="editor" surname="Zorn"/>
            <author fullname="D. Miles" initials="D." surname="Miles"/>
            <author fullname="B. Lourdelet" initials="B." surname="Lourdelet"/>
            <date month="April" year="2013"/>
            <abstract>
              <t indent="0">This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6911"/>
          <seriesInfo name="DOI" value="10.17487/RFC6911"/>
        </reference>
        <reference anchor="RFC6977" target="https://www.rfc-editor.org/info/rfc6977" quoteTitle="true" derivedAnchor="RFC6977">
          <front>
            <title>Triggering DHCPv6 Reconfiguration from Relay Agents</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="X. Pougnard" initials="X." surname="Pougnard"/>
            <date month="July" year="2013"/>
            <abstract>
              <t indent="0">This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6977"/>
          <seriesInfo name="DOI" value="10.17487/RFC6977"/>
        </reference>
        <reference anchor="RFC7037" target="https://www.rfc-editor.org/info/rfc7037" quoteTitle="true" derivedAnchor="RFC7037">
          <front>
            <title>RADIUS Option for the DHCPv6 Relay Agent</title>
            <author fullname="L. Yeh" initials="L." surname="Yeh"/>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <date month="October" year="2013"/>
            <abstract>
              <t indent="0">The 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7037"/>
          <seriesInfo name="DOI" value="10.17487/RFC7037"/>
        </reference>
        <reference anchor="RFC7227" target="https://www.rfc-editor.org/info/rfc7227" quoteTitle="true" derivedAnchor="RFC7227">
          <front>
            <title>Guidelines for Creating New DHCPv6 Options</title>
            <author fullname="D. Hankins" initials="D." surname="Hankins"/>
            <author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
            <author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
            <author fullname="S. Jiang" initials="S." surname="Jiang"/>
            <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="187"/>
          <seriesInfo name="RFC" value="7227"/>
          <seriesInfo name="DOI" value="10.17487/RFC7227"/>
        </reference>
        <reference anchor="RFC7499" target="https://www.rfc-editor.org/info/rfc7499" quoteTitle="true" derivedAnchor="RFC7499">
          <front>
            <title>Support of Fragmentation of RADIUS Packets</title>
            <author fullname="A. Perez-Mendez" initials="A." role="editor" surname="Perez-Mendez"/>
            <author fullname="R. Marin-Lopez" initials="R." surname="Marin-Lopez"/>
            <author fullname="F. Pereniguez-Garcia" initials="F." surname="Pereniguez-Garcia"/>
            <author fullname="G. Lopez-Millan" initials="G." surname="Lopez-Millan"/>
            <author fullname="D. Lopez" initials="D." surname="Lopez"/>
            <author fullname="A. DeKok" initials="A." surname="DeKok"/>
            <date month="April" year="2015"/>
            <abstract>
              <t indent="0">The 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7499"/>
          <seriesInfo name="DOI" value="10.17487/RFC7499"/>
        </reference>
        <reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7858" quoteTitle="true" derivedAnchor="RFC7858">
          <front>
            <title>Specification for DNS over Transport Layer Security (TLS)</title>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <author fullname="L. Zhu" initials="L." surname="Zhu"/>
            <author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="D. Wessels" initials="D." surname="Wessels"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="May" year="2016"/>
            <abstract>
              <t indent="0">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.</t>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7858"/>
          <seriesInfo name="DOI" value="10.17487/RFC7858"/>
        </reference>
        <reference anchor="RFC7930" target="https://www.rfc-editor.org/info/rfc7930" quoteTitle="true" derivedAnchor="RFC7930">
          <front>
            <title>Larger Packets for RADIUS over TCP</title>
            <author fullname="S. Hartman" initials="S." surname="Hartman"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">The 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7930"/>
          <seriesInfo name="DOI" value="10.17487/RFC7930"/>
        </reference>
        <reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484" quoteTitle="true" derivedAnchor="RFC8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <date month="October" year="2018"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8499" quoteTitle="true" derivedAnchor="RFC8499">
          <front>
            <title>DNS Terminology</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
            <date month="January" year="2019"/>
            <abstract>
              <t indent="0">The 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.</t>
              <t indent="0">This document obsoletes RFC 7719 and updates RFC 2308.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="219"/>
          <seriesInfo name="RFC" value="8499"/>
          <seriesInfo name="DOI" value="10.17487/RFC8499"/>
        </reference>
        <reference anchor="RFC9250" target="https://www.rfc-editor.org/info/rfc9250" quoteTitle="true" derivedAnchor="RFC9250">
          <front>
            <title>DNS over Dedicated QUIC Connections</title>
            <author fullname="C. Huitema" initials="C." surname="Huitema"/>
            <author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <date month="May" year="2022"/>
            <abstract>
              <t indent="0">This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9250"/>
          <seriesInfo name="DOI" value="10.17487/RFC9250"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">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 indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Ben Schwartz"/> and <contact fullname="Bernie Volz"/> for the comments.</t>
      <t indent="0" pn="section-appendix.a-3">Thanks to <contact fullname="Rob Wilton"/> for the careful AD
      review.</t>
      <t indent="0" pn="section-appendix.a-4">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 indent="0" pn="section-appendix.a-5">Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Paul       Wouters"/>, and <contact fullname="Warren Kumari"/> for the IESG
      review.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street/>
            <city>Rennes</city>
            <region/>
            <code>35000</code>
            <country>France</country>
          </postal>
          <email>mohamed.boucadair@orange.com</email>
        </address>
      </author>
      <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>India</country>
          </postal>
          <email>kondtir@gmail.com</email>
        </address>
      </author>
      <author fullname="Alan DeKok" initials="A." surname="DeKok">
        <organization showOnFrontPage="true">FreeRADIUS</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <phone/>
          <email>aland@freeradius.org</email>
          <uri/>
        </address>
      </author>
    </section>
  </back>
</rfc>
