One document matched: draft-yeh-radext-ext-dual-stack-access-00.xml


<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC2866 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2866.xml">
<!ENTITY RFC2869 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2869.xml">
<!ENTITY RFC3162 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3162.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC4818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4818.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), please see ttp://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes"?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" docName="draft-yeh-radext-ext-dual-stack-access-00" ipr="trust200902">

<!-- category values: std, bcp, info, exp, and historic ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902, or pre5378Trust200902 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" -->


<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->

  <title abbrev="RADIUS Dual Stack">  RADIUS Extension for Dual Stack Access</title>

    <author fullname="Leaf Y. Yeh" initials="L." surname="Yeh">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region>Shenzhen</region>
          <code></code>
          <country>P.R.China</country>
        </postal>
        <email>leaf.y.yeh@huawei.com</email>
      </address>
    </author>   
               
    <date year="2012"/>
    
    <!-- Meta-data Declarations -->
    <area>Ops&Mgmt</area>
    <workgroup>Radext Working Group</workgroup>
    <keyword>RADIUS Attributes</keyword>
    <keyword>Dual Stack</keyword>


<abstract>
<t>This document specifies the additional RADIUS attribute for IPv4 and IPv6 dual stack access, which are used in the AAA processes for NAS to employ the right mechanism and to allocate the proper configuration or resources for the users.</t>
</abstract>

</front>

<!-- ***** MIDDLE MATTER ***** -->

<middle>

  	
<section anchor="s1" title="Introduction">

<t>Subscriber IP sessions can be either IPv4/IPv6 dual-stack, IPv6-only, or the legacy IPv4-only in the typical PPPoE based <xref target="BBF TR-187"/> or IPoE based <xref target="BBF TR-177"/> deployment scenarios. The user in these IP sessions can be a host or a Customer Edge router (CE router, routed Residential Gateway, routed-RG, Customer Premise Equipment or routed-CPE). In the IPv6 part of these session, the broadband Network Access Server (NAS) acting as the Provider Edge router (PE router) and RADIUS client simultaneously, usually employ DHCPv6-PD <xref target="RFC3633"/><xref target="RFC4818"/> to delegate IPv6 prefix to CE router for its customer network. In the meantime, the WAN (NAS-facing) interface of CE router can be numbered or unnumbered (Section 2.3 of <xref target="BBF TR-177"/>). The NAS can employ SLAAC <xref target="RFC4862"/> to assign a IPv6 prefix or employ DHCPv6 <xref target="RFC3315"/> to assign a IPv6 address to the CE router for its WAN interface. Therefore, there are at least the following access types of user that the NAS and the centralized AAA server are served for:</t>

<figure><artwork>
   PPPoE-IPv4-only-host or CE

   PPPoE-IPv6-only-host (Numbered by SLAAC)
   PPPoE-IPv6-only-host (Numbered by DHCPv6)
   PPPoE-IPv6-only-CE (Unnumbered)
   PPPoE-IPv6-only-CE (Numbered by SLAAC)
   PPPoE-IPv6-only-CE (Numbered by DHCPv6)

   PPPoE-dual-stack-host (IPv6-Numbered by SLAAC)
   PPPoE-dual-stack-host (IPv6-Numbered by DHCPv6)
   PPPoE-dual-stack-CE (IPv6-Unnumbered)
   PPPoE-dual-stack-CE (IPv6-Numbered by SLAAC)
   PPPoE-dual-stack-CE (IPv6-Numbered by DHCPv6)
   
   IPoE-IPv4-only-host or CE

   IPoE-IPv6-only-host (Numbered by SLAAC)
   IPoE-IPv6-only-host (Numbered by DHCPv6)
   IPoE-IPv6-only-CE (Unnumbered)
   IPoE-IPv6-only-CE (Numbered by SLAAC)
   IPoE-IPv6-only-CE (Numbered by DHCPv6)
   
   IPoE-dual-stack-host (IPv6-Numbered by SLAAC)
   IPoE-dual-stack-host (IPv6-Numbered by DHCPv6)
   IPoE-dual-stack-CE (IPv6-Unnumbered)
   IPoE-dual-stack-CE (IPv6-Numbered by SLAAC)
   IPoE-dual-stack-CE (IPv6-Numbered by DHCPv6)
</artwork></figure>

<t>The different access type of users need the NAS (Broadband Network Gateway or BNG) employ different mechanism and allocate different resource for the associated processes. The addresses assigned and the prefixes delegated to the customer hosts or CE can be explicitly got from the AAA server through attributes in the Access-Accept packets (<xref target="RFC2865"/>, <xref target="RFC3162"/> and <xref target="RFC4818"/>), or be dynamically get from the local address or prefix pool configured on the NAS (<xref target="RFC2869"/>, <xref target="RFC3162"/> and <xref target="ietf-radext-ipv6-access-09"/>). When the NAS dynamically assign address or delegate prefix to the customer hosts or CE from the pools, it can use the default or preconfigured pools on the NAS or alternatively use the indicated pools in the attributes of the Access-Accept.</t>  

<t>This document defines the additional RADIUS attributes to specify the access type of users for the simplified and proper authorization and accounting in RADIUS processes.</t>

</section>


<section anchor="s2" title="Terminology and Conventions">

<t>This document describes the additional RADIUS attribute and the associated usage on NAS and AAA server. This document should be read in conjunction with the relevant RADIUS specifications, including <xref target="RFC2865"/>, <xref target="RFC2866"/>, <xref target="RFC2869"/>, <xref target="RFC3162"/> and <xref target="RFC4818"/> for a complete mechanism. Definitions for terms and acronyms not specifically defined in this document are defined in RFC2865, RFC2866, RFC2869, RFC3162 and RFC4818.</t>

<t>The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, <xref target="RFC2119"/>.</t>

</section>


<section anchor="s3" title="Deployment Scenarios">

<figure anchor="f1" title="Deployment Scenario for various access types of the users">
<artwork>
 +----------+                +----------+                +----------+
 |  Host    |      PPPoE     |          |     RADIUS     |   AAA    |
 |   or     | -------------- |   NAS    | -------------- |  Server  |
 |CE router |      IPoE      |          |   Access-Type  |          |
 +----------+                +----------+                +----------+
  Dual-Stack              Local Address Pool
  IPv6-only               Local Prefix Pool
</artwork>
</figure>

<t>In the above depicted scenario, the NAS acting as PE router may configure local address or prefix pools, use the mechanism of PPPoE NCP, IPv6 SLAAC or DHCPv6 protocols to handle IPv4 address, IPv6 address and IPv6 prefix assignment to hosts or CEs. The AAA server authenticates each host or CE, and returns the attributes used for authorization and accounting.</t>

<t>The attribute of Access-Type can be used to indicate the right configuration on the NAS for the users, or to report the right access type of the users to the accounting server. When the attribute of Access-Type is included, the address and prefix pools of the default configuration on the NAS are not always necessary to be indicated in the Access-Accept packet for the users' authorization.</t>
</section>


<section anchor="s4" title="Attributes">

<t>The fields shown in the diagrams below are transmitted from left to right.</t>

<section anchor="s4.1" title="Access-Type">

<t>Description
<list style="empty">
<t>The attribute indicates the access type of the user requested in the Access-Request packet, authorized in the Access-Accept packet or recorded in the Accounting-Request packet.</t>
<t>The format of the Access-Type is:</t>
</list></t>

<figure><artwork>
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |              Value            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Value (cont.)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>


<t>Type
<list style="empty">
<t>TBA1 (by IANA)</t>
</list></t>

<t>Length
<list style="empty">
<t>6</t>
</list></t>

<t>Value
<list style="empty">
<t>Enumerated Data Type in 4-Octet unsigned integer defined in [RFC6158]. The beginning 3 Octets are reserved for future use, and are set to 0x00 now. The decimal value of the last octet is defined as follows:</t>
<t>When PPPoE is used for the access method, the Access-Type of the user get the following 'Value':</t>
</list></t>
<figure><artwork>
   1   PPPoE-IPv4-only-host (or CE)
   2   PPPoE-IPv6-only-host (Numbered by SLAAC)
   3   PPPoE-IPv6-only-host (Numbered by DHCPv6)
   4   PPPoE-IPv6-only-CE (Unnumbered)
   5   PPPoE-IPv6-only-CE (Numbered by SLAAC)
   6   PPPoE-IPv6-only-CE (Numbered by DHCPv6)
   7   PPPoE-dual-stack-host (IPv6-Numbered by SLAAC)
   8   PPPoE-dual-stack-host (IPv6-Numbered by DHCPv6)
   9   PPPoE-dual-stack-CE (IPv6-Unnumbered)
   10  PPPoE-dual-stack-CE (IPv6-Numbered by SLAAC)
   11  PPPoE-dual-stack-CE (IPv6-Numbered by DHCPv6)
</artwork></figure>
<t>
<list style="empty">
<t>When IPoE is used for the access method, the Access-Type of user gets the following 'Value':</t>
</list></t>
<figure><artwork>
   12  IPoE-IPv4-only-host (or CE)
   13  IPoE-IPv6-only-host (Numbered by SLAAC)
   14  IPoE-IPv6-only-host (Numbered by DHCPv6)
   15  IPoE-IPv6-only-CE (Unnumbered)
   16  IPoE-IPv6-only-CE (Numbered by SLAAC)
   17  IPoE-IPv6-only-CE (Numbered by DHCPv6)
   18  IPoE-dual-stack-host (IPv6-Numbered by SLAAC)
   19  IPoE-dual-stack-host (IPv6-Numbered by DHCPv6)
   20  IPoE-dual-stack-CE (IPv6-Unnumbered)
   21  IPoE-dual-stack-CE (IPv6-Numbered by SLAAC)
   22  IPoE-dual-stack-CE (IPv6-Numbered by DHCPv6)
</artwork></figure>
<t>
<list style="symbols">
<t>For the user access type of IPv4-only host (or CE), NAS needs to report Access-Type and Framed-IP-Address (8) in the accounting-request packets for the assigned IPv4 address;</t>
<t>For the user access type of IPv6-only host (Numbered by SLAAC), NAS needs to report Access-Type and Framed-IPv6-Prefix (97) in the accounting-request packets;</t>
<t>For the user access type of IPv6-only host (Numbered by DHCPv6), NAS needs to report Access-Type and Framed-IPv6-address in the accounting-request packets;</t>
<t>For the user access type of IPv6-only CE (Unnumbered), NAS needs to report Access-Type and Delegated-IPv6-Prefix (123) in the accounting-request packets;</t>
<t>For the user access type of IPv6-only CE (Numbered by SLAAC), NAS needs to report Access-Type, Framed-IPv6-Prefix (97) and Delegated-IPv6-Prefix (123) in the accounting-request packets;</t>
<t>For the user access type of IPv6-only CE (Numbered by DHCPv6), NAS needs to report Access-Type, Framed-IPv6-address and Delegated-IPv6-Prefix (123) in the accounting-request packets;</t>
<t>For the user access type of dual-stack host (IPv6-Numbered by SLAAC), NAS needs to report Access-Type, Framed-IP-Address (8) and Framed-IPv6-Prefix (97) in the accounting-request packets;</t>
<t>For the user access type of dual-stack host (IPv6-Numbered by DHCPv6), NAS needs to report Access-Type, Framed-IP-Address (8) and Framed-IPv6-address in the accounting-request packets;</t>
<t>For the user access type of dual-stack CE (IPv6-Unnumbered), NAS needs to report Access-Type, Framed-IP-Address (8) and Delegated-IPv6-Prefix (123) in the accounting-request packets;</t>
<t>For the user access type of dual-Stack CE (IPv6-Numbered by SLAAC), NAS needs to report Access-Type, Framed-IP-Address (8), Framed-IPv6-Prefix (97) and Delegated-IPv6-Prefix (123) in the accounting-request packets;</t>
<t>For the user access type of dual-Stack CE (IPv6-Numbered by DHCPv6), NAS needs to report Access-Type, Framed-IP-Address (8), Framed-IPv6-address and Delegated-IPv6-Prefix (123) in the accounting-request packets.</t>
</list></t>

<t>Discussion:
<list style="empty">
<t>The alternative attribute design could separate the access type of the users into several dimensions.</t>
</list></t>
<figure><artwork>
   Access-Method: Enumerated Data Type
      0 for PPPoE; 1 for IPoE
   Stack-Type: Enumerated Data Type
      0 for dual stack; 1 for IPv4-only; 2 for IPv6-only
   Node-Type: Enumerated Data Type
      0 for host; 1 for CE
   WAN-Interface-Numbering-Type: Enumerated Data Type
      0 for Unnumbered; 1 for numbered
   WAN-Interface-Address-Assignment-Type: Enumerated Data Type
      0 for SLAAC; 1 for DHCPv6
</artwork></figure>
<t>
<list style="empty">
<t>Though the combination of the attributes sounds clearer in the semantics, and not all of attributes defined are needed for every user, but it still looks too complicated in some use cases.</t>
</list></t>

</section>


</section>


<section anchor="s5" 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>

<figure><artwork>
Req-  Acc-  Rej-  Chall  Accounting #      Attribute
uest  ept   ect   -enge  Request 
0-1   0-1   0     0      0-1        TBA1   Access-Type
</artwork></figure>

<t>The meaning of the above table entries is as follows:</t>

<figure><artwork>
0    This attribute MUST NOT be present.
0+   Zero or more instances of this attribute MAY be present.
0-1  Zero or one instance of this attribute MAY be present.
1    Exactly one instance of this attribute MUST be present.
1+   One or more of these attributes MUST be present.
</artwork></figure>

</section>


<section anchor="s6" title="Security Considerations">

<t>Security issues related RADIUS are described in section 8 of RFC2865 and section 5 of RFC3162.</t>

</section>


<section anchor="s7" title="IANA Considerations">

<t>The authors of this document request to assign new Radius type code for Access-Type. IANA should allocate the new code from the standard RADIUS Attributes space using the "IETF Review" policy <xref target="RFC5226"/>.</t>

</section>


<section anchor="s8" title="Acknowledgements">

<t>Thanks to David B. Nelson for his valuable comments in the mailing list of Radext.</t>

</section>


</middle>

<!-- ***** BACK MATTER ***** -->

<back>

<references title="Normative References">

  &RFC2119;
  &RFC2865;
  &RFC2866;
  &RFC2869;
  &RFC3162;
  &RFC3315;
  &RFC3633;
  &RFC4818;
  &RFC4862;
  &RFC5226;

</references>

<references title="Informative References">
  <reference anchor='BBF TR-177'>
	  <front>
	    <title>IPv6 in the context of TR-101, Issue 1</title> 
	    <author initials='' surname='Broadband Forum' fullname='' />
	    <date year='2010' month='November' />
	  </front>
  </reference>
  <reference anchor='BBF TR-187'>
	  <front>
	    <title>IPv6 for PPP Broadband Access, Issue 1</title> 
	    <author initials='' surname='Broadband Forum' fullname='' />
	    <date year='2010' month='May' />
	  </front>
  </reference>
  <reference anchor='ietf-radext-ipv6-access-09'>
	  <front>
	    <title>RADIUS attributes for IPv6 Access Networks</title> 
	    <author initials='B.' surname='Lourdelet' fullname='Benoit Lourdelet' />
	    <author initials='W.' surname='Dec' fullname='Wojciech Dec' />
	    <author initials='B.' surname='Sarikaya' fullname='Behcet Sarikaya' />
	    <author initials='G.' surname='Zorn' fullname='Glen Zorn' />
	    <author initials='D.' surname='Miles' fullname='David Miles' />
	    <date year='2011' month='January' />
	  </front>
  </reference>

</references>

</back>
</rfc>


PAFTECH AB 2003-20262026-04-24 04:20:42