<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc6911 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6911.xml">
<!ENTITY rfc6929 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6929.xml">
]>
<rfc category="std" docName="draft-klammorrissette-radext-very-common-vsas-00"
     ipr="trust200902">
  <front>
    <title abbrev="Common RADIUS attributes">RADIUS attributes commonly used
    in fixed networks</title>

    <author fullname="Devasena Morrissette" initials="D."
            surname="Morrissette">
      <organization>Verizon</organization>

      <address>
        <postal>
          <street>555 Elm St, Manchester, NH ,</street>

          <city>Manchester</city>

          <code>03101</code>

          <country>USA</country>
        </postal>

        <email>devasena.morrissette@verizon.com</email>
      </address>
    </author>

    <author fullname="Frederic Klamm" initials="F." surname="Klamm">
      <organization>Orange</organization>

      <address>
        <postal>
          <street>4, rue du Clos Courtel, BP 91226</street>

          <city>Cesson-Sevigne</city>

          <code>35512</code>

          <country>France</country>
        </postal>

        <email>frederic.klamm@orange.com</email>
      </address>
    </author>

    <author fullname="Lionel Morand" initials="L." surname="Morand">
      <organization>Orange</organization>

      <address>
        <postal>
          <street>38-40 rue du General Leclerc</street>

          <city>Issy-Les-Moulineaux</city>

          <code>92130</code>

          <country>France</country>
        </postal>

        <email>lionel.morand@orange.com</email>
      </address>
    </author>

    <date month="July" year="2015"/>

    <area>Ops</area>

    <workgroup>RADEXT WG</workgroup>

    <!--                 Abstract                   -->

    <abstract>
      <t>There is a set of Remote Authentication Dial-In User Service
      attributes which have been widely used in different types of fixed
      networks though they don't appear as standard attributes. Each of these
      attributes has for long been part of many vendor dictionnaries, thus
      presented in different approaches and different syntaxes. This document
      try to solve this in an effort to present them in a standard, common
      way, based on approaches found in multiple dictionnaries.</t>
    </abstract>
  </front>

  <middle>
    <!--              Introduction                  -->

    <section title="Introduction">
      <t>This document describes a set of Remote Authentication Dial-In User
      Service (RADIUS) <xref target="RFC2865"/> attributes which have been
      widely used in different fixed network contexts (residential access,
      business services...). Since those attributes have been for long part of
      many vendor dictionnaries, they were presented in different syntax and
      semantic approaches. This document is as far as possible an effort to
      present them in a common way.</t>
    </section>

    <!--  SECTION 2: CONVENTIONS & TERMINOLOGY                                      -->

    <section anchor="sec:conventions_terminology"
             title="Conventions and Terminology">
      <!--vspace blankLines="1" /-->

      <!--  SECTION 2.1: CONVENTIONS                                                 -->

      <section anchor="sec:conventions" title="Conventions">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119"/>.</t>
      </section>

      <!-- conventions -->

      <!--  SECTION 2.2: TERMINOLOGY			                               -->

      <section anchor="sec:terminology" title="Terminology">
        <t>xxx</t>
      </section>

      <!-- 2.2. Terminology -->
    </section>

    <!-- 2. Conventions & Terminology -->

    <!--  SECTION 3:  RADIUS attributes -->

    <section title="Deployment Scenarios">
      <t>TO be added. Example below:</t>

      <t>
      deployment scenarios is intended to cover a wide range of access networks
       The main purpose is to standardise common vendor specific attributes.
      The extensions in this document are intended to be applicable across
      a wide variety of network access scenarios in which RADIUS is involved. 
      The involved protocols include but are not limited to DHCP, PPP, L2TP 
      and protocols related to multicast or QoS.</t> 
      <t>One such typical network scenario is illustrated in Figure 1. It is
      composed of an IP Routing Residential Gateway (RG) or host; a Layer 2
      Access Node (AN), e.g., a Digital Subscriber Line Access Multiplexer
      (DSLAM); an IP Network Access Server (NAS) (incorporating an
      Authentication, Authorization, and Accounting (AAA) client); and a AAA
      server.</t>

      <t><figure>
          <artwork><![CDATA[
                                                       +-----+
                                                       | AAA |
                                                       |     |
                                                       +--+--+
                                                          ^
                                                          .
                                                          .(RADIUS)
                                                          .
                                                          v
                        +------+                      +---+---+
         +------+       |      |                      |       |
         |  RG/ +-------|  AN  +-----------+----------+  NAS  |
         | host |       |      |                      |       |
         +------+ (DSL) +------+      (Ethernet)      +-------+

                                  Figure 1
]]></artwork>
        </figure> In the depicted scenario, the NAS may utilize an IP address
      configuration protocol (e.g., DHCPv6) to handle address assignment to
      RGs/hosts. The RADIUS server authenticates each RG/host and returns the
      Attributes used for authorization and accounting. These Attributes can
      include attributes related to routing context, policies and QoS, walled
      garden services, DNS servers, multicast service, PPP and L2TP
      configurations. The following sections defines these specific
      attributes. </t>
    </section>

    <section anchor="attributes" title="RADIUS attributes">
      <t>The new attributes described in this section are defined as short
      extended attributes, as defined in <xref target="RFC6929"/>.</t>

      <t>Each attribute is described following the suggestions given in
      section 4 of <xref target="draft-dekok-radext-datatypes"/>. Please refer
      to this specification to find further details on the data types used for
      the different attributes.</t>

      <!--  SECTION 3.1 -->

      <section anchor="routing-context-sect"
               title="Attributes for Routing Context ">
        <t>[To Be Completed]</t>

        <!--  SECTION 3.1.1 -->

        <section anchor="vrf-sect" title="Virtual-Router-Id">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Virtual-Router-Id attribute contains an identifier that
              identifies exactly one virtual router when multiple, independent
              virtual routers co-exist on the same physical routing platform.
              This attribute MAY be included in Access-Accept or Change of
              Authorization (CoA) Request. When returned in the RADIUS
              Access-Accept, this attribute defines the virtual router to
              which a user session is assigned. If the Virtual Router ID
              returned by the RADIUS server does not exist, the Network Access
              Server (NAS) MUST NOT permit the user to access the network. If
              the RADIUS server does not return any Virtual Router Id, the
              user session MAY be assigned to a default routing context or to
              any available virtual router.</t>

              <t hangText="Type"/>

              <t>241.x01</t>

              <t hangText="Length"/>

              <t>&gt;= 4</t>

              <t hangText="Ext-Data"/>

              <t>string</t>

              <t hangText="Value"/>

              <t>The "Value" field is one or more octets and contains the
              virtual router ID that the user is assigned. A robust
              implementation SHOULD support the field as undistinguished
              octets.</t>
            </list></t>
        </section>

        <!-- 3.1.1-->

        <!--  SECTION 3.1.2 -->

        <!-- 3.1.2-->
      </section>

      <!--  SECTION 3.2 -->

      <section anchor="policy-qos-sect" title="Policies and QoS Attributes">
        <t>[To Be Completed]</t>

        <!--  SECTION 3.2.1 -->

        <section anchor="pol-sect" title="Policy-Name">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Policy-Name attribute contains a name that identifies the
              policy to apply on the user session for the egress or ingress
              direction. The policy definition itself resides locally in the
              NAS. This attribute MAY be included in Access-Accept and
              CoA-Request. If the policy name provided in the RADIUS message
              does not exist, the Network Access Server (NAS) MAY assign a
              default policy the user if one exists on the NAS itself.</t>

              <t hangText="Type"/>

              <t>241.x03</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>string</t>

              <t hangText="Value"/>

              <t>The "Value" field is one or more octets, specifying the name
              of the policy to apply on the user session in the ingress or
              egress direction. A robust implementation SHOULD support the
              field as undistinguished octets.</t>
            </list></t>
        </section>

        <!-- 3.2.1-->

        <!--  SECTION 3.2.2 -->

        <section anchor="qos-sect" title="QoS-Profile-Name">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The QoS-Profile-Name attribute contains a name that identify
              the QoS profile to apply on the user session. The QoS profile
              definition itself resides locally in the NAS. This attribute MAY
              be included in Access-Accept and CoA-Request. If the value of
              the QoS profile name provided in the RADIUS message does not
              exist, the Network Access Server (NAS) MAY apply a default QoS
              profile to the user session if one exists on the NAS itself.</t>

              <t hangText="Type"/>

              <t>241.x04</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>string</t>

              <t hangText="Value"/>

              <t>The "Value" field is one or more octets, specifying the QoS
              profile name to apply on the user session. A robust
              implementation SHOULD support the field as undistinguished
              octets.</t>
            </list></t>
        </section>

        <!-- 3.2.9-->
      </section>

      <!--3.2-->

      <!--  SECTION 3.3 -->

      <section anchor="walled-gard-sect"
               title="Attributes for walled garden services">
        <t>[To Be Completed]</t>

        <!--  SECTION 3.3.1 -->

        <section anchor="redir-url-sect" title="HTTP-Redirect-URI">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The HTTP-Redirect-URI attribute contains an HTTP uniform
              resource Identifier (URI) to which user originating HTTP
              requests are redirected by the NAS. This attibute MAY be
              includeded in Access-Accept, CoA Request and
              Accounting-Request.</t>

              <t hangText="Type"/>

              <t>241.x05</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>string</t>

              <t hangText="Value"/>

              <t>The "Value" field is one or more octets, containing an HTTP
              URI as specified in <xref target="RFC7230"/>. A robust
              implementation SHOULD support the field as undistinguished
              octets.</t>
            </list></t>
        </section>

        <!-- 3.3.1-->

        <!--  SECTION 3.3.2 -->

        <section anchor="redir-profile-sect"
                 title="HTTP-Redirect-Profile-Name">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The HTTP-Redirect-Profile-Name attribute contains the name of
              an HTTP redirect profile to apply on the user session. This
              attribute MAY be included in Access-Accept, in CoA-Request and
              Accounting-Request.</t>

              <t hangText="Type"/>

              <t>241.x06</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>sext</t>

              <t hangText="Value"/>

              <t>The "Value" is one or more octets, containing the name of an
              HTTP redirect profile to apply on the user's originating HTTP
              traffic. A robust implementation SHOULD support the field as
              undistinguished octets.</t>
            </list></t>
        </section>

        <!-- 3.3.2-->
      </section>

      <!-- 3.3-->

      <!--  SECTION 3.4 -->

      <section anchor="dns-sect" title="DNS">
        <t>This section only defines DNS server for IPv4. DNS servers for IPv6
        can be found in <xref target="RFC6911"/>.</t>

        <!--  SECTION 3.4.1 -->

        <section anchor="prim-dns-sect" title="Primary-DNS-Server-Address">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Primary-DNS-Server-Address attribute contains the IPv4
              address (in network byte order) of the primary DNS server
              negotiated during IPCP. This attibute MAY be included in
              Access-Accept and Accounting-Request.</t>

              <t hangText="Type"/>

              <t>241.x07</t>

              <t hangText="Length"/>

              <t>6</t>

              <t hangText="Ext-Data"/>

              <t>ipv4addr</t>

              <t hangText="Value"/>

              <t>The "Value" field contains the IPv4 address (in network byte
              order) of the primary DNS server.</t>
            </list></t>
        </section>

        <!-- 3.4.1-->

        <!--  SECTION 3.4.2 -->

        <section anchor="sec-dns-sect" title="Secundary-DNS-Server-Address">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Secondary-DNS-Server attribute contains the IPv4 address
              (in network byte order) of the secondary DNS server if
              negotiated during IPCP. This attribute MAY be included in
              Access-Accept and Accounting-Request.</t>

              <t hangText="Type"/>

              <t>241.x08</t>

              <t hangText="Length"/>

              <t>6</t>

              <t hangText="Ext-Data"/>

              <t>ipv4addr</t>

              <t hangText="Value"/>

              <t>The "Value" field contains the IPv4 address (in network byte
              order) of the secondary DNS server.</t>
            </list></t>
        </section>

        <!-- 3.4.2-->
      </section>

      <!-- 3.4-->

      <!--  SECTION 3.5 -->

      <section anchor="igmp-sect" title="Multicast attributes">
        <t>[To Be Completed]</t>

        <!--  SECTION 3.5.1 -->

        <section anchor="igmp-enab-sect" title="IGMP-Enable">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The IGMP-Enable contains an enumerated value that indicates
              whether the MLD protocol is enabled or disabled on the user
              interface upon connection establishment. This attribute MAY be
              included in Access-Accept and CoA-Request.</t>

              <t hangText="Type"/>

              <t>241.x09</t>

              <t hangText="Length"/>

              <t>6</t>

              <t hangText="Ext-Data"/>

              <t>enum</t>

              <t hangText="Value"/>

              <t>The "Value" field is an enumerated value that indicates
              whether IGMP is enabled or disabled. The valid set of enumerated
              values are:</t>

              <t>0 = Disable</t>

              <t>1 = Enable</t>
            </list></t>
        </section>

        <!-- 3.5.1-->

        <!--  SECTION 3.5.2 -->

        <section anchor="igmp-profile-sect" title="IGMP-Profile-Name">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The IGMP-Profile-Name attribute contains the name of the IGMP
              service profile configured on the NAS and to apply on the user
              session. This attribute MAY be included in Access-Accept,
              CoA-Request and Accounting-Request.</t>

              <t hangText="Type"/>

              <t>241.x10</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>sext</t>

              <t hangText="Value"/>

              <t>The "Value" field contains the IGMP profile name that is
              assigned to the user session. A robust implementation SHOULD
              support the field as undistinguished octets.</t>
            </list></t>
        </section>

        <!-- 3.5.2-->

        <!--  SECTION 3.5.3 -->

        <section anchor="mls-enab-sect" title="MLD-Enable">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The MLD-Enable attribute contains an enumerated value that
              indicates whether the MLD protocol is enabled or disabled on the
              user interface upon connection establishment. This attribute MAY
              be included in Access-Accept and CoA-Request.</t>

              <t hangText="Type"/>

              <t>241.x11</t>

              <t hangText="Length"/>

              <t>6</t>

              <t hangText="Ext-Data"/>

              <t>enum</t>

              <t hangText="Value"/>

              <t>The "Value" field is an enumerated value that indicates
              whether the MLD protocol is enabled or disabled on the user
              interface upon connection establishment. The valid set of
              enumerated values are:</t>

              <t>0 = Disable</t>

              <t>1 = Enable</t>
            </list></t>
        </section>

        <!-- 3.5.3-->

        <!--  SECTION 3.5.4 -->

        <section anchor="mld-prof-sect" title="MLD-Profile-Name">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The MLD-Profile-Name attribute contains the identifier of the
              IGMP service profile configured on the NAS and applied to the
              user session. This attribute MAY be included in Access-Accept,
              CoA-Request and Accounting-Request. If the value of the IGMP
              Profile in the RADIUS message sent by the RADIUS server does not
              exist, the Network Access Server (NAS) MAY assign a default IGMP
              Profile the user if one exists on the NAS itself.</t>

              <t hangText="Type"/>

              <t>241.x12</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>String</t>

              <t hangText="Value"/>

              <t>The "Value" field is one or more octets, specifying the MLD
              profile name that is assigned to the subscriber session. A
              robust implementation SHOULD support the field as
              undistinguished octets.</t>
            </list></t>
        </section>

        <!-- 3.5.4-->
      </section>

      <!-- 3.5-->

      <!--  SECTION 3.6 -->

      <section anchor="tnl-sect" title="Tunnel attributes">
        <t>[To Be Completed]</t>

        <!--  SECTION 3.6.1 -->

        <section anchor="tnl-vrouter-sect" title="Tunnel-Virtual-Router">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Tunnel-Virtual-Router attribute identifies the virtual
              router name such as the VPN instance of the tunnel context.</t>
              <t>When returned in the RADIUS Access-Accept, this attribute 
              defines the virtual routing context to which a tunnel is assigned.</t>

              <t hangText="Type"/>

              <t>241.x13</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>sext</t>

              <t hangText="Value"/>

              <t>The "Value" field is one or more octets, specifying the Tunnel virtual 
              router name that is assigned to the tunnel. A robust implementation SHOULD 
              support the field as undistinguished octets.</t>

            </list></t>
        </section>

        <!-- 3.6.1-->

        <!--  SECTION 3.6.2 -->

        <section anchor="tnl-max-sess-sect" title="Tunnel-Max-Sessions">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Tunnel-Max-Sessions attribute specifies the maximum number of sessions 
              that are allowed in a given tunnel. A session must be denied once the value tied 
              to this attribute is exceeded.</t>
              <t>The Tunnel-Max-Sessions attribute may be returned in Access-Accept.</t>

              <t hangText="Type"/>

              <t>241.x14</t>

              <t hangText="Length"/>

              <t>6</t>

              <t hangText="Ext-Data"/>

              <t>enum</t>

              <t hangText="Value"/>

              <t>The "Value" field is an enumerated value that indicates the maximum 
              number of sessions that can be brought up in a tunnel.</t>
            </list></t>
        </section>

        <!-- 3.6.2-->

        <!--  SECTION 3.6.3 -->

        <section anchor="tnl-pfl-name-sect" title="Tunnel-Profile-Name">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Tunnel-Profile-Name attribute contains a name that identifies 
              the profile that defines the tunnel to which the subscriber session 
              is tied. The Tunnel profile definition itself that comprises various 
              tunnel specific parameters resides locally in the NAS.</t>
              <t>This attribute MAY be included in Access-Accept. If the value of 
              the tunnel profile name provided in the RADIUS message does not exist, 
              the Network Access Server (NAS) MAY apply a default Tunnel profile to 
              the subscriber session if one exists on the NAS itself.</t>

              <t hangText="Type"/>

              <t>241.x15</t>

              <t hangText="Length"/>

              <t>&gt;=1</t>

              <t hangText="Ext-Data"/>

              <t>string</t>

              <t hangText="Value"/>

              <t>The "Value" field is one or more octets, specifying the Tunnel profile 
              name to apply on the user session. A robust implementation SHOULD support 
              the field as undistinguished octets.</t>

            </list></t>
        </section>

        <!-- 3.6.3-->

        <!--  SECTION 3.6.4 -->

        <section anchor="tnl-term-cause-sect" title="Tunnel-Terminate-Cause">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Tunnel-Terminate-Cause attribute specifies the disconnect cause 
              when a tunneled subscriber is disconnected, for example when the 
              termination is initiated by the L2TP layer in the case of LNS.</t>
              <t>The Tunnel-Terminate-Cause attribute may be included in Accounting-Stop message.</t>

              <t hangText="Type"/>

              <t>241.x16</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>enum</t>

              <t hangText="Value"/>

              <t>The "Value" field is an enumerated value containing an integer 
              specifying the cause of session termination</t>
            </list></t>
        </section>

        <!-- 3.6.4-->
      </section>

      <!-- 3.6-->
      


      <!--  SECTION 3.7 -->

      <section anchor="srv-sect" title="Service attributes">
        <t>[To Be Completed]</t>

        <!--  SECTION 3.7.1 -->

        <section anchor="srv-name-sect" title="Service-Name">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Service-Name attribute specifies the name of the service to be activated for 
              a given subscriber session. The Service-Name attribute may be present in Access-Accept,
              CoA request and CoA response RADIUS messages. The Service-Name attribute may be tagged 
              supporting multiple tags.</t>

              <t hangText="Type"/>

              <t>241.x17</t>

              <t hangText="Length"/>

              <t>&gt;=4</t>

              <t hangText="Ext-Data"/>

              <t>sext</t>

              <t hangText="Value"/>

              <t>The "Value" field contains the Service name that is assigned to the subscriber session.
              A robust implementation SHOULD support the field as undistinguished octets.</t>

            </list></t>
        </section>

        <!-- 3.7.1-->

        <!--  SECTION 3.7.2 -->

        <section anchor="srv-deact-sect" title="Deactivat-Service-Name">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Deactivate-Service-Name attribute specifies the name of the service to be 
              de-activated for a given subscriber session.</t>
              <t>The Decativate-Service-Name attribute may be present in Access-Accept and 
              CoA request RADIUS messages.</t>

              <t hangText="Type"/>

              <t>241.x18</t>

              <t hangText="Length"/>

              <t>6</t>

              <t hangText="Ext-Data"/>

              <t>enum</t>

              <t hangText="Value"/>

              <t>The "Value" field contains the Service name that is to be de-activated for a given
              subscriber session. A robust implementation SHOULD support the field as undistinguished octets.</t>
            </list></t>
        </section>

        <!-- 3.7.2-->

        <!--  SECTION 3.7.3 -->

        <section anchor="srv-acct-sect" title="Service-Accounting">
          <t><list style="hanging">
              <t hangText="Description"/>

              <t>The Service-Accounting attribute specifies whether accounting for a given service
              tied to a subscriber session is enabled or disabled.</t>
              <t>This attribute MAY be included in Access-Accept and CoA Request. Implementations may support
              sub-options for Service-Accounting such as time and/or volume based accounting statistics collection.
              The Service-Accounting attribute may support tags.</t>

              <t hangText="Type"/>

              <t>241.x19</t>

              <t hangText="Length"/>

              <t>&gt;=1</t>

              <t hangText="Ext-Data"/>

              <t>string</t>

              <t hangText="Value"/>

              <t>The "Value" field is an enumerated value that indicates whether the Service-Accounting is enabled
              or disabled for the service tied to a subscriber session. The valid set of enumerated values are:</t>

              <t>0 = Disable</t>

              <t>1 = Enable</t>
            </list></t>
        </section>

        <!-- 3.7.3-->


      </section>

      <!-- 3.7-->
      
    </section>

    <!-- section 3 -->

    <!--  SECTION :  IANA Considerations   		-->

    <section title="Table of Attributes">
      <t>The following table provides a guide to which attributes may be found
      in which kinds of packets and in what quantity.</t>

      <t><figure>
          <artwork><![CDATA[ Access-  Access-  Access-  Access-
 Request  Accept   Reject   Chall    #      Attribute
 0        0-1      0        0     241.x01   Virtual-Router-Id
 0        0-1      0        0     241.x02   Redirect-Virtual-Router-Id
 0        0-1      0        0     241.x03   Policy-Name
 0        0-1      0        0     241.x04   QoS-Policy-Name
 0        0-1      0        0     241.x05   HTTP-Redirect-URI
 0        0-1      0        0     241.x06   HTTP-Redirect-Profile-Name
 0        0-1      0        0     241.x07   Primary-DNS-Server-Address
 0        0-1      0        0     241.x08   Secundary-DNS-Server-Address
 0        0-1      0        0     241.x09   IGMP-Enable
 0        0-1      0        0     241.x10   IGMP-profile-Name
 0        0-1      0        0     241.x11   MLD-Enable
 0        0-1      0        0     241.x12   MLD-Profile-Name
 0        0-1      0        0     241.x13   Tunnel-Virtual-Router
 0        0-1      0        0     241.x14   Tunnel-Max-Session
 0        0-1      0        0     241.x15   Tunnel-Profile-Name
 0        0        0        0     241.x16   Tunnel-Terminate-Cause
 0        0-1      0        0     241.x17   Service-Name
 0        0-1      0        0     241.x18   Service-Deactivate
 0        0-1      0        0     241.x19   Service-Accounting
   ]]></artwork>
        </figure></t>

      <t><figure>
          <artwork><![CDATA[   CoA-     Dis-     Acct-    
   Request  Request  Request     #      Attribute
   0-1      0        0        241.x01   Virtual-Router-Id
   0-1      0        0        241.x02   Redirect-Virtual-Router-Id
   0-1      0        0        241.x03   Policy-Name
   0-1      0        0        241.x04   QoS-Policy-Name
   0-1      0        0-1      241.x05   HTTP-Redirect-URI
   0-1      0        0-1      241.x06   HTTP-Redirect-Profile-Name
   0-1      0        0-1      241.x07   Primary-DNS-Server-Address
   0-1      0        0-1      241.x08   Secundary-DNS-Server-Address
   0-1      0        0        241.x09   IGMP-Enable
   0-1      0        0-1      241.x10   IGMP-profile-Name
   0-1      0        0        241.x11   MLD-Enable
   0-1      0        0-1      241.x12   MLD-Profile-Name
   0-1      0        0        241.x13   Tunnel-Virtual-Router
   0-1      0        0        241.x14   Tunnel-Max-Session   
   0-1      0        0        241.x15   Tunnel-Profile-Name
   0        0        0-1      241.x16   Tunnel-Terminate-Cause 
   0-1      0        0        241.x17   Service-Name
   0-1      0        0        241.x18   Service-Deactivate
   0-1      0        0        241.x19   Service-Accounting
]]></artwork>
        </figure></t>

      <t>The following table defines the above table entries.</t>

      <t hangText="Value"><list style="hanging">
          <t hangText="0">This attribute MUST NOT be present in packet.</t>

          <t hangText="0+">Zero or more instances of this attribute MAY be
          present in the packet.</t>

          <t hangText="0-1">Zero or one instance of this attribute MAY be
          present in the packet.</t>
        </list></t>
    </section>

    <section anchor="sec:iana" title="IANA Considerations">
      <t>This document requires the following IANA action:</t>

      <t><figure>
          <artwork><![CDATA[   Attribute                        Type
   =========                        ====
   Virtual-Router-Id                241.x01
   Redirect-Virtual-Router-Id       241.x02
   Policy-Name                      241.x03
   QoS-Policy-Name                  241.x04
   HTTP-Redirect-URI                241.x05
   HTTP-Redirect-Profile-Name       241.x06
   Primary-DNS-Server-Address       241.x07
   Secundary-DNS-Server-Address     241.x08
   IGMP-Enable                      241.x09
   IGMP-profile-Name                241.x10
   MLD-Enable                       241.x11
   MLD-Profile-Name                 241.x12
   Tunnel-Virtual-Router            241.x13
   Tunnel-Max-Session               241.x14   
   Tunnel-Profile-Name              241.x15
   Tunnel-Terminate-Cause           241.x16   
   Service-Name                     241.x17 
   Service-Deactivate               241.x18    
   Service-Accounting               241.x19    
   ]]></artwork>
        </figure></t>
    </section>

    <!--  SECTION :  Security Considerations   	-->

    <section anchor="Security" title="Security Considerations">
      <t>This document specifies additional RADIUS Attributes useful in
      residential broadband network deployments. In such networks, the RADIUS
      protocol may run either over IPv4 or over IPv6, and known security
      vulnerabilities of the RADIUS protocol apply to the Attributes defined
      in this document. A trust relationship between a NAS and RADIUS server
      is expected to be in place, with communication optionally secured by
      IPsec <xref target="RFC4301"/>or Transport Layer Security (TLS) <xref
      target="RFC5246"/>. This document does not introduce any new security
      issue compared to those identified in <xref target="RFC2865"/>. </t>
    </section>

    <!--  SECTION:  Acknowledgements   		-->

    <section anchor="sec_ack" title="Acknowledgements">
      <t>The author would like to thank Sri Gundavelli and Gaetan Feige for
      having shared thoughts on concepts exposed in this document.</t>
    </section>
  </middle>

  <back>
    <!--  SECTION : References	                -->

    <!--  SECTION .1:  Normative References		-->

    <references title="Normative References">
      &rfc2119;

      &rfc6929;

      &rfc6911;

      <reference anchor="RFC2865">
        <front>
          <title>Remote Authentication Dial In User Service (RADIUS)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC7230">
        <front>
          <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and
          Routing</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>

    <!--  SECTION:  Informative References		-->

    <references title="Informative References">
      
      <reference anchor="draft-dekok-radext-datatypes">
        <front>
          <title>Data Types in the Remote Authentication Dial-In User Service
          Protocol (RADIUS)</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC4301">
        <front>
          <title>Security Architecture for the Internet Protocol</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC5246">
        <front>
          <title>The Transport Layer Security (TLS) Protocol</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
