<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-opsawg-add-encrypted-dns-12" number="9445" ipr="trust200902" updates="4014" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>

    <title abbrev="RADIUS DHCP Options">RADIUS Extensions for DHCP-Configured
    Services</title>
    <seriesInfo name="RFC" value="9445"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>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>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>FreeRADIUS</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <phone/>
        <email>aland@freeradius.org</email>
        <uri/>
      </address>
    </author>
    <date year="2023" month="August"/>
    <area>ops</area>
    <workgroup>opsawg</workgroup>
    <keyword>redirection</keyword>
    <keyword>subscriber policies</keyword>
    <keyword>differentiated service</keyword>
    <keyword>DNS</keyword>
    <keyword>DoH</keyword>
    <keyword>DoT</keyword>
    <keyword>DoQ</keyword>
    <keyword>QUIC</keyword>
    <keyword>Encryption</keyword>
    <keyword>Service delivery</keyword>
    <keyword>Service provisioning</keyword>
    <keyword>service activation</keyword>
    <keyword>policies</keyword>
    <keyword>connectivity</keyword>

    <abstract>
      <t>This document specifies two new Remote Authentication Dial-In User
      Service (RADIUS) attributes that carry DHCP options. The specification
      is generic and can be applicable to any service that relies upon DHCP.
      Both DHCPv4- and DHCPv6-configured services are covered.
      </t>
      <t>Also, this document updates RFC 4014 by relaxing a constraint on
      permitted RADIUS attributes in the RADIUS Attributes DHCP suboption.
      </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>In the context of broadband services, Internet Service Providers
      (ISPs) usually provide DNS resolvers to their customers. To that aim,
      ISPs deploy dedicated mechanisms (e.g., DHCP <xref target="RFC2132"
      format="default"/> <xref target="RFC8415" format="default"/> and IPv6
      Router Advertisement <xref target="RFC4861" format="default"/>) to
      advertise a list of DNS recursive servers to their customers. Typically,
      the information used to populate DHCP messages and/or IPv6 Router
      Advertisements relies upon specific Remote Authentication Dial-In User
      Service (RADIUS) <xref target="RFC2865" format="default"/> attributes,
      such as the DNS-Server-IPv6-Address Attribute specified in <xref
      target="RFC6911" format="default"/>.</t>
      <t>With the advent of encrypted DNS (e.g., DNS over HTTPS
      (DoH) <xref target="RFC8484" format="default"/>, DNS over TLS (DoT)
      <xref target="RFC7858" format="default"/>, or DNS over QUIC (DoQ) <xref
      target="RFC9250" format="default"/>), 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"/> 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"/>. The
      same concern is likely to be encountered for future services that are
      configured using DHCP.</t>
      <t>This document specifies two new RADIUS attributes: DHCPv6-Options
      (<xref target="v6" format="default"/>) and DHCPv4-Options (<xref
      target="v4" format="default"/>). 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"/>) and the "DHCP Options Permitted
   in the RADIUS DHCPv4-Options Attribute" registry (<xref
      format="default" target="drv4-reg"/>). These two attributes are specified
      in order to accommodate both IPv4 and IPv6 deployment contexts while
      taking into account the constraints in <xref section="3.4"
      target="RFC6158" format="default"/>.</t>
      <t>The mechanism specified in this document is a generic mechanism and
      might be employed in network scenarios where the DHCP server and the
      RADIUS client are located in the same device. The new attributes can
      also be used in deployments that rely upon the mechanisms defined in
      <xref target="RFC4014" format="default"/> or <xref target="RFC7037" format="default"/>, which
      allow a DHCP relay agent that is collocated with a RADIUS client to pass
      attributes obtained from a RADIUS server to a DHCP server. However, an
      update to <xref target="RFC4014" format="default"/> is required so that a DHCP
      relay agent can pass the DHCPv4-Options Attribute obtained from a RADIUS
      server to a DHCP server (<xref target="RAD" format="default"/>).</t>
      <t>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>This document adheres to <xref target="RFC8044" format="default"/> for defining
      the new attributes.</t>
      <t>A sample deployment usage of the RADIUS DHCPv6-Options and DHCPv4-Options
      Attributes is described in <xref target="sample" format="default"/>.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      <t>This document makes use of the terms defined in <xref target="RFC2865" format="default"/>, <xref target="RFC8415" format="default"/>, and <xref target="RFC8499" format="default"/>. The following additional terms are used: </t>
      <dl newline="false" spacing="normal">
        <dt>DHCP:</dt>
        <dd>refers to both DHCPv4 <xref target="RFC2132" format="default"/>
        and DHCPv6 <xref target="RFC8415" format="default"/>.</dd>
        <dt>Encrypted DNS:</dt>
        <dd>refers to a scheme where DNS exchanges are transported over an
        encrypted channel. Examples of encrypted DNS are DoT, DoH, and
        DoQ.</dd>
        <dt>Encrypted DNS resolver:</dt>
        <dd>refers to a resolver (<xref section="6" target="RFC8499"
        format="default"/>) that supports encrypted DNS.</dd>
        <dt>DHCP*-Options:</dt>
        <dd>refers to the DHCPv4-Options and DHCPv6-Options Attributes (<xref
        target="att" format="default"/>).</dd>
      </dl>
    </section>

    <section anchor="att" numbered="true" toc="default">
      <name>RADIUS DHCP Options Attributes</name>
      <t>This section specifies two new RADIUS attributes for RADIUS clients
      and servers to exchange DHCP-encoded data. This data is then used to
      feed the DHCP procedure between a DHCP client and a DHCP server.</t>
      <t>Both the DHCPv4-Options and DHCPv6-Options Attributes use the "Long
      Extended Type" format (<xref section="2.2" target="RFC6929" format="default"/>).
      The description of the fields is provided in Sections <xref format="counter" target="v6"/> and <xref format="counter" target="v4"/>.</t>

      <t>These attributes use the "Long Extended Type" format in order to
      permit the transport of attributes encapsulating more than 253 octets of
      data. DHCP options that can be included in the RADIUS DHCP*-Options 
      Attributes are limited by the maximum packet size of 4096 bytes (<xref section="3" target="RFC2865" format="default"/>). 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"/>
      or <xref target="RFC7930" format="default"/>).</t>
      <t>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"/>.</t>
      <t>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>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>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"/>. Invalid attributes are handled as per <xref target="RFC6929" section="2.8" sectionFormat="of"/>.</t>
      <section anchor="v6" numbered="true" toc="default">
        <name>DHCPv6-Options Attribute</name>
        <t>This attribute is of type "string" as defined in <xref section="3.5" target="RFC8044" format="default"/>.</t>
        <t>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>The DHCPv6-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS CoA-Request
        packet.</t>
        <t>The DHCPv6-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS
        Accounting-Request packet.</t>
        <t>The DHCPv6-Options Attribute <bcp14>MUST NOT</bcp14> appear in any other RADIUS
        packet.</t>
        <t>The DHCPv6-Options Attribute is structured as follows:</t>
	   <dl newline="true" spacing="normal">
             <dt>Type</dt>
	     <dd><t>245</t></dd>
             <dt>Length</dt>
             <dd>This field indicates the total length, in octets, of all
             fields of this attribute, including the Type, Length,
             Extended-Type, and Value fields.</dd>
             <dt>Extended-Type</dt>
             <dd>3 (see <xref target="IANA-Att" format="default"/>)</dd>
             <dt>Value</dt>
             <dd><t>This field contains a list of DHCPv6 options (<xref
             target="RFC8415" section="21" sectionFormat="of"/>). 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"/>,
             this document does not impose any option order when multiple
             options are present.</t>
             <t>The permitted DHCPv6 options are
             listed in the "DHCPv6 Options Permitted
   in the RADIUS DHCPv6-Options Attribute" registry (<xref
             format="default" target="drv6-reg"/>).</t></dd>
           </dl>
        <t>The DHCPv6-Options Attribute is associated with the following
        identifier: 245.3.</t>
      </section>
      <section anchor="v4" numbered="true" toc="default">
        <name>DHCPv4-Options Attribute</name>
        <t>This attribute is of type "string" as defined in <xref section="3.5" target="RFC8044" format="default"/>.</t>
        <t>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>The DHCPv4-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS CoA-Request
        packet.</t>
        <t>The DHCPv4-Options Attribute <bcp14>MAY</bcp14> appear in a RADIUS
        Accounting-Request packet.</t>
        <t>The DHCPv4-Options Attribute <bcp14>MUST NOT</bcp14> appear in any other RADIUS
        packet.</t>
        <t>The DHCPv4-Options Attribute is structured as follows:</t>
	<dl newline="true" spacing="normal">
          <dt>Type</dt>
	  <dd>245</dd>
          <dt>Length</dt>
          <dd>This field indicates the total length, in octets, of all fields
          of this attribute, including the Type, Length, Extended-Type, and
          Value fields.</dd>
          <dt>Extended-Type</dt>
          <dd>4 (see <xref target="IANA-Att" format="default"/>)</dd>
          <dt>Value</dt>
          <dd><t>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"/> <bcp14>MUST</bcp14> be
          used for splitting and concatenating the instances of a
          concatenation-requiring option.</t>
          <t>The permitted DHCPv4 options are
          listed in the "DHCP Options Permitted
   in the RADIUS DHCPv4-Options Attribute" registry (<xref format="default"
          target="drv4-reg"/>).</t></dd>
        </dl>
	
        <t>The DHCPv4-Options Attribute is associated with the following
        identifier: 245.4.</t>
      </section>
    </section>
    <section anchor="RAD" numbered="true" toc="default">
      <name>Passing RADIUS DHCP Options Attributes by DHCP Relay Agents to DHCP Servers</name>
      <section numbered="true" toc="default">
        <name>Context</name>
        <t>The RADIUS Attributes DHCP suboption <xref target="RFC4014"
        format="default"/> enables a DHCPv4 relay agent to pass identification
        and authorization attributes received during RADIUS authentication to
        a DHCPv4 server.  However, <xref target="RFC4014" format="default"/>
        defines a frozen set of RADIUS attributes that can be included in such
        a suboption. This limitation is suboptimal in contexts where new
        services are deployed (e.g., support of encrypted DNS <xref
        target="I-D.ietf-add-dnr" format="default"/>).</t>

        <t><xref target="update" format="default"/> updates <xref
        target="RFC4014" format="default"/> 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"/>).
	</t>
      </section>
      <section anchor="update" numbered="true" toc="default">
        <name>Updates to RFC 4014</name>
        <t/>
        <section anchor="update1" numbered="true" toc="default">
          <name>Section 3 of RFC 4014</name>
          <t>This document updates <xref target="RFC4014" section="3" sectionFormat="of"/>
          as follows:</t>

            <t>OLD:</t>
              <blockquote><t>To avoid dependencies between the address
              allocation and other state information between the RADIUS server
              and the DHCP server, the DHCP relay 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=""><![CDATA[
           #   Attribute
         ---   ---------
           1   User-Name (RFC 2865 [3])
           6   Service-Type (RFC 2865)
          26   Vendor-Specific (RFC 2865)
          27   Session-Timeout (RFC 2865)
          88   Framed-Pool (RFC 2869)
         100   Framed-IPv6-Pool (RFC 3162 [7])
	      ]]></artwork>
	      </blockquote>

            <t>NEW:</t>
            <blockquote><t>To avoid dependencies between the address
            allocation and other state information between the RADIUS server
            and the DHCP server, the DHCP relay 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"/> 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="default">
          <name>Section 4 of RFC 4014</name>
          <t>This document updates <xref target="RFC4014" section="4" sectionFormat="of"/>
          as follows:</t>

            <t>OLD:</t>
            <blockquote><t>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>NEW:</t>
            <blockquote><t>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"/> 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="default">
      <name>An Example: Applicability to Encrypted DNS Provisioning</name>
      <t>Typical deployment scenarios are similar to those described, for
      instance, in <xref section="2" target="RFC6911" format="default"/>. For
      illustration purposes, <xref target="ex" format="default"/> shows an example where
      a Customer Premises Equipment (CPE) is provided with an encrypted DNS
      resolver. This example assumes that the Network Access Server (NAS)
      embeds both RADIUS client and DHCPv6 server capabilities.</t>
      <figure anchor="ex">
        <name>An Example of RADIUS IPv6 Encrypted DNS Exchange</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+           +-------------+             +-------+
|     CPE     |           |     NAS     |             |  AAA  |
|DHCPv6 Client|           |DHCPv6 Server|             |Server |
|             |           |RADIUS Client|             |       |
+------+------+           +------+------+             +---+---+
       |                         |                        |
       o-----DHCPv6 Solicit----->|                        |
       |                         o----Access-Request ---->|
       |                         |                        |
       |                         |<----Access-Accept------o
       |                         |     DHCPv6-Options     |
       |<----DHCPv6 Advertise----o    (OPTION_V6_DNR)     |
       |     (OPTION_V6_DNR)     |                        |
       |                         |                        |
       o-----DHCPv6 Request----->|                        |
       |                         |                        |
       |<------DHCPv6 Reply------o                        |
       |     (OPTION_V6_DNR)     |                        |
       |                         |                        |

                DHCPv6                     RADIUS
]]></artwork>
      </figure>


      <t>Upon receipt of the DHCPv6 Solicit message from a CPE, the NAS sends
      a RADIUS Access-Request message to the Authentication, Authorization,
      and Accounting (AAA) server. Once the AAA server receives the request,
      it replies with an Access-Accept message (possibly after having sent a
      RADIUS Access-Challenge message and assuming the CPE is entitled to
      connect to the network) that carries a list of parameters to be used for
      this session, 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"/> 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"/> is then followed between
      the DHCPv6 client and the DHCPv6 server.</t>
      <t>Should any encrypted DNS-related information (e.g., Authentication
      Domain Name (ADN) and IPv6 address) change, the RADIUS server sends a
      RADIUS Change-of-Authorization (CoA) message <xref target="RFC5176" format="default"/> that carries the DHCPv6-Options Attribute with
      the updated OPTION_V6_DNR information to the NAS. Once that message is
      received and validated by the NAS, it replies with a RADIUS CoA ACK
      message. The NAS replaces the old encrypted DNS resolver information
      with the new one and sends a DHCPv6 Reconfigure message, which leads the
      DHCPv6 client to initiate a Renew/Reply message exchange with the DHCPv6
      server.</t>
      <t>In deployments where the NAS behaves as a DHCPv6 relay agent, the
      procedure discussed in <xref section="3" target="RFC7037"
      format="default"/> can be followed. 

To that aim, the "RADIUS Attributes Permitted in DHCPv6
      RADIUS Option" registry has been updated (<xref target="urd"
      format="default"/>). CoA-Requests can be used following the procedure
      specified in <xref target="RFC6977" format="default"/>.</t>
      <t><xref target="ex2" format="default"/> shows another example where a CPE is
      provided with an encrypted DNS resolver, but the CPE uses DHCPv4 to
      retrieve its encrypted DNS resolver.</t>
      <figure anchor="ex2">
        <name>An Example of RADIUS IPv4 Encrypted DNS Exchange</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+           +-------------+             +-------+
|     CPE     |           |     NAS     |             |  AAA  |
|DHCPv4 Client|           |DHCPv4 Server|             |Server |
|             |           |RADIUS Client|             |       |
+------+------+           +------+------+             +---+---+
       |                         |                        |
       o------DHCPDISCOVER------>|                        |
       |                         o----Access-Request ---->|
       |                         |                        |
       |                         |<----Access-Accept------o
       |                         |     DHCPv4-Options     |
       |<-----DHCPOFFER----------o    (OPTION_V4_DNR)     |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |
       o-----DHCPREQUEST-------->|                        |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |
       |<-------DHCPACK----------o                        |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |

               DHCPv4                      RADIUS
]]></artwork>
      </figure>

      <t>Other deployment scenarios can be envisaged, such as returning
      customized service parameters (e.g., different DoH URI Templates) as a
      function of 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="default">
      <name>Security Considerations</name>
      <t>RADIUS-related security considerations are discussed in <xref target="RFC2865" format="default"/>.</t>
      <t>DHCPv6-related security issues are discussed in <xref section="22" target="RFC8415" format="default"/>, while DHCPv4-related security issues are
      discussed in <xref section="7" target="RFC2131" format="default"/>. Security
      considerations specific to the DHCP options that are carried in RADIUS
      are discussed in relevant documents that specify these options. For
      example, security considerations (including traffic theft) are discussed
      in <xref section="7" target="I-D.ietf-add-dnr" format="default"/>.</t>
      <t>RADIUS servers have conventionally tolerated the input of arbitrary
      data via the "string" data type (<xref section="3.5" target="RFC8044"
      format="default"/>). 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>The considerations discussed in <xref target="RFC4014" section="7" sectionFormat="of"/> and <xref target="RFC7037" section="8" sectionFormat="of"/>
      should be taken into account in deployments where DHCP relay agents pass
      the DHCP*-Options Attributes to DHCP servers. Additional considerations
      specific to the use of Reconfigure messages are discussed in <xref section="9" target="RFC6977" format="default"/>.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Table of Attributes</name>
      <t>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">
  <name>Table of Attributes</name>
	<thead>
	  <tr>
	  <th>Access-Request</th>
	  <th>Access-Accept</th>
	  <th>Access-Reject</th>
	  <th>Challenge</th>
	  <th>#</th>
	  <th>Attribute</th>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td>0+</td>
	    <td>0+</td>
	    <td>0</td>
	    <td>0</td>
	    <td>245.3</td>
	    <td>DHCPv6-Options</td>
	  </tr>
	  <tr>
	    <td>0+</td>
	    <td>0+</td>
	    <td>0</td>
	    <td>0</td>
	    <td>245.4</td>
	    <td>DHCPv4-Options</td>
	  </tr>
	  <tr>
	  <th>Accounting-Request</th>
	  <th>CoA-Request</th>
	  <th>CoA-ACK</th>
	  <th>CoA-NACK</th>
	  <th>#</th>
	  <th>Attribute</th>
	  </tr>
	  <tr>
            <td>0+</td>
	    <td>0+</td>
	    <td>0</td>
	    <td>0</td>
	    <td>245.3</td>
	    <td>DHCPv6-Options</td>
	  </tr>
	  <tr>
            <td>0+</td>
	    <td>0+</td>
	    <td>0</td>
	    <td>0</td>
	    <td>245.4</td>
	    <td>DHCPv4-Options</td>
	  </tr>
	</tbody>
      </table>

      <t>Notation for <xref target="attributes-table"/>:</t>

<dl newline="false" spacing="normal" indent="4">

  <dt>0</dt><dd>This attribute <bcp14>MUST NOT</bcp14> be present in
  packet.</dd>
  <dt>0+</dt><dd>Zero or more instances of this attribute <bcp14>MAY</bcp14>
  be present in packet.</dd>
</dl>
	   
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="IANA-Att" numbered="true" toc="default">
        <name>New RADIUS Attributes</name>
        <t>IANA has assigned two new RADIUS attribute types in the
         "Radius Attribute Types" <xref target="RADIUS-Types" format="default"/> registry:</t>
        <table anchor="ra" align="center">
          <name>New RADIUS Attributes</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Description</th>
              <th align="left">Data Type</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">245.3</td>
              <td align="left">DHCPv6-Options</td>
              <td align="left">string</td>
              <td align="left">RFC 9445</td>
            </tr>
            <tr>
              <td align="left">245.4</td>
              <td align="left">DHCPv4-Options</td>
              <td align="left">string</td>
              <td align="left">RFC 9445</td>
            </tr>
          </tbody>
        </table>
        <t/>
      </section>
      <section anchor="urd" numbered="true" toc="default">
        <name>New RADIUS Attribute Permitted in DHCPv6 RADIUS Option</name>
        <t>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"/>:</t>
        <table anchor="rd" align="center">
          <name>New RADIUS Attribute Permitted in DHCPv6 RADIUS Option</name>
          <thead>
            <tr>
              <th align="left">Type Code</th>
              <th align="left">Attribute</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">245.3</td>
              <td align="left">DHCPv6-Options</td>
              <td align="left">RFC 9445</td>
            </tr>
          </tbody>
        </table>
        <t/>
      </section>
      <section anchor="IANA-RAD" numbered="true" toc="default">
        <name>RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption</name>
        <t>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"/>.</t>
        <t>The allocation policy of this new subregistry is "Expert Review"
        (<xref target="RFC8126" section="4.5"
        sectionFormat="of"/>). 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"/>.</t>
        <t>The initial contents of this subregistry are listed in <xref target="rad-new" format="default"/>. The Reference field includes the document that
        registers or specifies the attribute.</t>
        <table anchor="rad-new" align="center">
          <name>Initial Contents of RADIUS Attributes Permitted in RADIUS Attributes DHCP Suboption Registry</name>
          <thead>
            <tr>
              <th align="left">Type Code</th>
              <th align="left">Attribute</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1</td>
              <td align="left">User-Name</td>
              <td align="left"><xref target="RFC2865" format="default"/></td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">Service-Type</td>
              <td align="left"><xref target="RFC2865" format="default"/></td>
            </tr>
            <tr>
              <td align="left">26</td>
              <td align="left">Vendor-Specific</td>
              <td align="left"><xref target="RFC2865" format="default"/></td>
            </tr>
            <tr>
              <td align="left">27</td>
              <td align="left">Session-Timeout</td>
              <td align="left"><xref target="RFC2865" format="default"/></td>
            </tr>
            <tr>
              <td align="left">88</td>
              <td align="left">Framed-Pool</td>
              <td align="left"><xref target="RFC2869" format="default"/></td>
            </tr>
            <tr>
              <td align="left">100</td>
              <td align="left">Framed-IPv6-Pool</td>
              <td align="left"><xref target="RFC3162" format="default"/></td>
            </tr>
            <tr>
              <td align="left">245.4</td>
              <td align="left">DHCPv4-Options</td>
              <td align="left">RFC 9445</td>
            </tr>
          </tbody>
        </table>
        <t/>
      </section>
      <section numbered="true" toc="default">
        <name>DHCP Options Permitted in the RADIUS DHCP*-Options Attributes</name>
        <t/>
        <section anchor="drv6-reg" numbered="true" toc="default">
          <name>DHCPv6</name>
          <t>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"/>.</t>
          <t>The registration policy for this new subregistry is "Expert
          Review" (<xref target="RFC8126" section="4.5"
          sectionFormat="of"/>). See more details in <xref target="reg"
          format="default"/>.</t>
          <t>The initial content of this subregistry is listed in <xref
          target="drv6" format="default"/>. The Value and Description fields
          echo those in the "Option Codes" subregistry of <xref
          target="DHCPv6" format="default"/>. The Reference field includes the
          document that registers or specifies the option.</t>
          <table anchor="drv6" align="center">
            <name>Initial Content of DHCPv6 Options Permitted in the RADIUS DHCPv6-Options Attribute Registry</name>
            <thead>
              <tr>
                <th align="left">Value</th>
                <th align="left">Description</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">144</td>
                <td align="left">OPTION_V6_DNR</td>
                <td align="left">RFC 9445</td>
              </tr>
            </tbody>
          </table>
          <t/>
        </section>
        <section anchor="drv4-reg" numbered="true" toc="default">
          <name>DHCPv4</name>
          <t>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"/>.</t>
          <t>The registration policy for this new subregistry is Expert
          Review (<xref target="RFC8126" section="4.5" sectionFormat="of"/>). See more
          details in <xref target="reg" format="default"/>.</t>
          <t>The initial content of this subregistry is listed in <xref
          target="drv4" format="default"/>. The Tag and Name fields echo those
          in the "BOOTP Vendor Extensions and DHCP Options" subregistry of
          <xref target="BOOTP" format="default"/>. The Reference field
          includes the document that registers or specifies the option.</t>
          <table anchor="drv4" align="center">
            <name>Initial Content of DHCPv4 Options Permitted in the RADIUS DHCPv4-Options Attribute Registry</name>
            <thead>
              <tr>
                <th align="left">Tag</th>
                <th align="left">Name</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">162</td>
                <td align="left">OPTION_V4_DNR</td>
                <td align="left">RFC 9445</td>
              </tr>
            </tbody>
          </table>
          <t/>
        </section>
        <section anchor="reg" numbered="true" toc="default">
          <name>Guidelines for the Designated Experts</name>
          <t>It is suggested that multiple designated experts be appointed for
          registry change requests.</t>
          <t>Criteria that should be applied by the designated experts include
          determining whether the proposed registration duplicates existing
          entries and whether the registration description is clear and fits
          the purpose of this registry.</t>

          <t>Registration requests are to be sent 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>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6158.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8044.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6929.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4014.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3396.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6911.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5176.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2868.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2869.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3162.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2132.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7037.xml"/>

<!-- [I-D.ietf-add-dnr] IESG state RFC Ed Queue. Updated to long version because missing editor role for Boucadair -->

<reference anchor="I-D.ietf-add-dnr" target="https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-16">
<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>Orange</organization>
</author>
<author initials="T." surname="Reddy.K" fullname="Tirumaleswar Reddy.K" role="editor">
<organization>Nokia</organization>
</author>
<author initials="D." surname="Wing" fullname="Dan Wing">
<organization>Citrix Systems, Inc.</organization>
</author>
<author initials="N." surname="Cook" fullname="Neil Cook">
<organization>Open-Xchange</organization>
</author>
<author initials="T." surname="Jensen" fullname="Tommy Jensen">
<organization>Microsoft</organization>
</author>
<date month="April" day="27" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-add-dnr-16"/>
</reference>


        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7227.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7930.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7499.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6977.xml"/>

        <reference anchor="RADIUS-Types" target="http://www.iana.org/assignments/radius-types">
          <front>
            <title>RADIUS Types</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

        <reference anchor="DHCPv6" target="https://www.iana.org/assignments/dhcpv6-parameters">
          <front>
            <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

        <reference anchor="BOOTP" target="https://www.iana.org/assignments/bootp-dhcp-parameters">
          <front>
            <title>Dynamic Host Configuration Protocol (DHCP) and Bootstrap
            Protocol (BOOTP) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to <contact fullname="Christian Jacquenet"/>, <contact
      fullname="Neil Cook"/>, <contact fullname="Joe Clarke"/>, <contact
      fullname="Qin Wu"/>, <contact fullname="Dirk von-Hugo"/>, <contact
      fullname="Tom Petch"/>, and <contact fullname="Chongfeng Xie"/> for the
      review and suggestions.</t>
      <t>Thanks to <contact fullname="Ben Schwartz"/> and <contact
      fullname="Bernie Volz"/> for the comments.</t>
      <t>Thanks to <contact fullname="Rob Wilton"/> for the careful AD
      review.</t>
      <t>Thanks to <contact fullname="Ralf Weber"/> for the dnsdir reviews,
      <contact fullname="Robert Sparks"/> for the genart review, and <contact
      fullname="Tatuya Jinmei"/> for the intdir review.</t>
      <t>Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Paul
      Wouters"/>, and <contact fullname="Warren Kumari"/> for the IESG
      review.</t>
    </section>

  </back>

</rfc>
