Internet Engineering Task Force J. Tan Internet-Draft G. Yang Intended status: Standards Track China Telecom Expires: January 5, 2012 C. Zhou Huawei Technologies July 4, 2011 AAA for broadband access in IPv6 transition draft-tan-v6ops-fast6-aaa-00 Abstract This document provides access scenarios for FAST6 and analyzes the authentication, authorization and accounting operations in IPv4 access network, IPv6 access network and dual stack network separately for PPPoE case. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Tan, et al. Expires January 5, 2012 [Page 1] Internet-Draft AAA for BB access in IPv6 transition July 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Access Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. IPv4 access . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. IPv6 access . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Dual Stack Access . . . . . . . . . . . . . . . . . . . . 4 4. Authentication and Authorization . . . . . . . . . . . . . . . 5 4.1. User type differentiation . . . . . . . . . . . . . . . . 5 4.2. IPv4 Authentication . . . . . . . . . . . . . . . . . . . 6 4.3. IPv6 Authentication . . . . . . . . . . . . . . . . . . . 6 4.3.1. Bridged mode CPE access . . . . . . . . . . . . . . . 6 4.3.2. Routing mode CPE access . . . . . . . . . . . . . . . 7 4.4. Dual Stack Authentication . . . . . . . . . . . . . . . . 7 5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. IPv4 accounting . . . . . . . . . . . . . . . . . . . . . 7 5.2. IPv6 accounting . . . . . . . . . . . . . . . . . . . . . 7 5.3. Dual Stack Accounting . . . . . . . . . . . . . . . . . . 8 6. Illustration of access scenarios . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Tan, et al. Expires January 5, 2012 [Page 2] Internet-Draft AAA for BB access in IPv6 transition July 2011 1. Introduction In the FAST6 architecture, there are various access types. The user may be allocated with public IPv4 address, private IPv4 address, IPv6 address or both IPv4 and IPv6 address. In addition, the user may access to the network via CPE in bridged mode or routing mode. This document introduces access scenarios for FAST6 and analyzes the authentication, authorization and accounting operations in IPv4 access network, IPv6 access network and dual stack network separately for PPPoE case. The document focuses on the problems and possible solutions in the last two access scenarios. Besides FAST6 architecture, the solution described in this document also applies to the IPv6 smooth transition of most ISPs who uses PPPoE as access technology. 2. Terminology BRAS: Broadband Remote Access Server, BRAS, is the aggregation point for the subscriber traffic. It provides aggregation capabilities between the Access Network and the Metro Area Network. Beyond aggregation, it is also the injection point for access authentication, policy management and IP QoS. CPE: Customer Premises Equipment, CPE, is the edge of Customer Premises Network. In this document, there are two types of CPEs, which are in Routed mode and in Bridged mode. Subscriber: The client that is purchasing the DSL circuit from the Service Provider and is receiving the billing. 3. Access Scenarios This section describes various access scenarios and basic flows in FAST6 architecture and operations of related elements, e.g., BRAS, CPE and Host. 3.1. IPv4 access This scenario describes the case when allocating IPv4 address for the user. In the bridged mode CPE case, the host acquires IPv4 address directly Tan, et al. Expires January 5, 2012 [Page 3] Internet-Draft AAA for BB access in IPv6 transition July 2011 from BRAS via PPP LCP negotiation ([RFC1332]). In the routing mode CPE case, CPE acquires IPv4 address from BRAS via PPP IPCP negotiation and then allocates the private IPv4 address to the host via DHCP. The IPv4 address CPE retrieves from BRAS is the WAN side address of CPE. BRAS may allocate public IPv4 address or private IPv4 address for the host/CPE based on the user type. When private address is allocated, double level NAT (at both CPE and CGN) is needed for the host to access Internet. We strongly suggest the addresses allocated to the host and CPE use different address segments. 3.2. IPv6 access This scenario describes the IPv6 address allocation procedure. In the bridged mode CPE case, the host acquires the IPv6 address from BRAS directly. After PPP LCP negotiation with BRAS, the host gets the interface ID via IPv6CP process and generates Link Local IPv6 address. The host acquires IPv6 prefix via Router Advertisement or DHCPv6 and generates global IPv6 address ([RFC5072]). In this case, BRAS must determine the IPv6 prefix allocated to the host. It is recommended that each host have different prefix. In the routing mode CPE case, CPE acquires IPv6 prefix from BRAS and allocates addresses to the host. After PPP LCP negotiation with BRAS, CPE gets the interface ID via IPv6CP process and generates Link Local IPv6 address for the WAN side. The CPE acquires IPv6 prefix via Router Advertisement or DHCPv6 and generates global IPv6 address for the WAN side (the operator manages CPE through this address). The LAN side IPv6 prefix of CPE is retrieved via DHCP-PD ([RFC4861]). The host acquires IPv6 prefix via Router Advertisement messages and generates global IPv6 address finally. In this case, BRAS should determine the IPv6 prefix separately allocated to the WAN interface and LAN interface of CPE. The prefix should be different for two interfaces. 3.3. Dual Stack Access In the Dual Stack case, IPv4 and IPv6 connection should be both carried in one PPP session which can be taken as combining IPv4 and IPv6 access procedures. The process of IPv4 access is consistent with section 3.1, while IPv6 access is consistent with section 3.2. The host/CPE initiates IPCP, IPv6CP and ND-RA procedures by sequence after PPP LCP negotiation with BRAS to allocate IPv4 and IPv6 addresses. Tan, et al. Expires January 5, 2012 [Page 4] Internet-Draft AAA for BB access in IPv6 transition July 2011 4. Authentication and Authorization This section describes the authentication and authorization procedure how BRAS acquires the user parameters, e.g., access type and address/ prefix, via interaction with RADIUS server. 4.1. User type differentiation In the FAST6 architecture, RADIUS server should identify the user type and send corresponding access parameters. For example, the RADIUS server should send private address pool attribute to the user if private IPv4 address is needed. The user types are defined as below: o Public IPv4GBPoallocates public IPv4 address to the user. o Private IPv4GBPoallocates private IPv4 address to the user. o IPv6 OnlyGBPoallocates IPv6 address to the user. o Dual stack with Public IPv4GBPoallocates public IPv4 address and IPv6 address to the user. o Dual stack with Private IPv4GBPoallocates private IPv4 address and IPv6 address to the user. BRAS know the user type based on the "User-Type" attribute carried in the RADIUS Access Accept packet. "User-Type" attribute is a non- standardized attribute and can be used as a private attribute before it becomes a standard. BRAS allocates corresponding IP addresses based on the user type, e.g., allocates private IPv4 address for the Private IPv4 user and allocates IPv6 address for the IPv6 Only user. BRAS may also determine the user type based on other attributes carried in the Access Accept packet. For example, when Framed-IP- Pool attribute is received only and the value is set to "public IPv4 address pool", the user can be taken as Public IPv4 user. When user receives Framed-IPv6-Pool attribute only, the user type is IPv6 Only. "User-Type" attribute can simplify the way how BRAS determines the user type. In addition, BRAS can allocate appropriate IP addresses for the user even without the address pool attribute sent by RADIUS serve, if default address pool is defined by BRAS. Therefore, using "User-Type" attribute is the better way to get the user type. BRAS can configure defaulted user type, that is to say, when there is no "User-Type" or other attributes related to address allocation in the access accept packet, the user type can be taken as a specific Tan, et al. Expires January 5, 2012 [Page 5] Internet-Draft AAA for BB access in IPv6 transition July 2011 one, e.g., configuring public IPv4 address as default. In this case, BRAS can allocate address to the user from the defaulted public IPv4 address pool even there is no attribute received from RADIUS server in the authentication procedure. 4.2. IPv4 Authentication This section describes the attributes RADIUS server sent in the IPv4 authentication procedure. For the user who does not need fixed IPv4 address, RADIUS server will send User-Type and Framed-IP-Pool ([RFC2865]) in the Access Accept packet and BRAS will allocate address to the user from the address pool. For the user who needs fixed IPv4 address, RADIUS server will send User-Type and Framed-IP-Address in the Access Accept message and BRAS will allocate this address to the user. BRAS may configure default public IPv4 address and private IPv4 address pool. When there is no address pool attribute is received from RADIUS server, BRAS can allocate address to the user from the defaulted address pool. 4.3. IPv6 Authentication This section describes the attributes RADIUS server sent in the IPv6 authentication procedure. When routing mode CPE is used, the IPv6 prefix allocated to the WAN and LAN interfaces should be different. BRAS should be able to configure IPv6 address pool separately for the WAN and LAN interfaces. BRAS should negotiate with RADIUS server in advance to identify which pool is for WAN interface and which pool is for LAN interface. BRAS can also configure default pool for WAN and LAN interface and use the default pool when no IPv6 address pool attribute is returned by RADIUS server. IPv6 authorization operations will be described separately for bridged mode CPE and routing mode CPE. 4.3.1. Bridged mode CPE access For the user who does not need fixed IPv6 prefix, RADIUS server will send User-Type and two Framed-IPv6-Pool ([RFC3162]) attributes in the Access Accept message. One is for WAN interface, and the other is for LAN interface. BRAS allocate IPv6 prefix to the user from the WAN address pool. LAN address pool is not used in this case. Tan, et al. Expires January 5, 2012 [Page 6] Internet-Draft AAA for BB access in IPv6 transition July 2011 For the user who needs fixed IPv6 prefix, RADIUS server will send user-type and Framed-IPv6-Prefix attributes in the Access Accept message and BRAS will allocate this prefix to the user. 4.3.2. Routing mode CPE access For the user who does not need fixed IPv6 prefix, RADIUS server will send User-Type and two Framed-IPv6-Pool attributes in the Access Accept message. One is for WAN interface, and the other is for LAN interface. BRAS allocate IPv6 prefix for the WAN interface from the WAN address pool. When DHCP-PD request is initiated by CPE, BRAS allocates IPv6 prefix for the LAN interface from the LAN address pool. For the user who needs fixed IPv6 prefix, RADIUS server will send User-Type, Framed-IPv6-Prefix and Delegated-IPv6-Prefix ([RFC4818]) attributes in the Access Accept message and BRAS will allocate the value of Framed-IPv6-Prefix to the WAN interface. When DHCP-PD request is initiated by CPE, BRAS allocates the value of Delegated- IPv6-Prefix to the LAN interface. 4.4. Dual Stack Authentication When the user type is dual stack, RADIUS server will send User-Type attribute (the value is Dual stack with Public IPv4 or Dual stack with Private IPv4) and related IPv4 and IPv6 attributes in the Access Accept message. The detailed attribute usage is described in section 4.3 and section 4.4. 5. Accounting This section describes RADIUS accounting procedure and attributes transmitted in various access scenarios. 5.1. IPv4 accounting BRAS send Accounting start message to the RADIUS server after completing IPCP process with host/CPE and send Accounting stop message when LCP link is disconnected. The information reported includes User-Name, Framed-IP-Address, Acct-Session-Time and the attributes related to traffic ([RFC2866],[RFC2869]). 5.2. IPv6 accounting BRAS set time-up mechanism after sending Router Advertisement messages to the host/CPE. BRAS will send Accounting start to the RADIUS server when receiving DHCP-PD request from CPE and replying Tan, et al. Expires January 5, 2012 [Page 7] Internet-Draft AAA for BB access in IPv6 transition July 2011 with Delegated IPv6 Prefix before time up. Otherwise, BRAS need to send Accounting start after time-up. The reason is that BRAS has no idea of the CPE mode and whether DHCP-PD request is sent by the user. BRAS will send Accounting stop message when LCP link is disconnected. The accounting attributes BRAS report include User-Name, Framed- Interface-Id (Interface ID of the host or CPE WAN side), Framed-IPv6- Prefix (IPv6 prefix of the host or CPE WAN side), Acct-Session-Time and the attributes related to traffic. If the user is accessed via routing mode CPE, the attributes should also include Delegated-IPv6- Prefix (IPv6 prefix of CPE LAN side, that is IPv6 prefix of the host). 5.3. Dual Stack Accounting There are already existing documents describing RADIUS attributes for IPv4 and IPv6 accounting. However, there may be some problems for the accounting when dual stack traffic is carried in one PPP link. The existing RADIUS attribute could not identify which traffic attributes are for IPv4 and which are for IPv6 in one accounting packet. To identify IPv4 and IPv6 traffic, two separate accounting packets may be used to transmit individual accounting information. For IPv4, BRAS will send Accounting start, Accounting update and Accounting stop to transmit IPv4 accounting information (refer to section 5.1). For IPv6, BRAS will send another group of Accounting start, Accounting update and Accounting stop to transmit IPv6 accounting information (refer to section 5.2). RADIUS server determines IPv4 and IPv6 accounting packet based on the Frame-IP-Address and Frame- IPv6-Prefix or Delegated-IPv6-Prefix in the packet. These two group of accounting packets can use the same session ID since IPv4 and IPv6 are carried in one PPP session and have the same Acct-Session-Id attributes. The advantage of this dual stack accounting is to achieve IPv4 and IPv6 separately without new RADIUS attributes. While the disadvantage is that two groups of accounting messages are needed for one PPP session which adds burden for BRAS, RADIUS server and the network. 6. Illustration of access scenarios This section is one example of routing mode CPE. Tan, et al. Expires January 5, 2012 [Page 8] Internet-Draft AAA for BB access in IPv6 transition July 2011 +-----+ +-----+ +-----+ +-------+ |Host | | CPE | |BRAS | |RADIUS | +--+--+ +--+--+ +--+--+ +---+---+ | | LCP Negotiation | | | |<----------------->| | | |PPP Authen Request | | | |------------------>| | | | | Access Request | | | |-------------------->| | | |Access Accept(v4 | | | |and/or v6 Attribute) | | |PPP Authen Resonse |<--------------------| | |<------------------| | | | | | | |<-----IPCPv4------>| | | | | | | |<-----IPCPv6------>| | | | | | | |<-----ND-RA------->| | | | | | | |<----DHCP-PD------>| | |<--ND-RA--->| |Accounting Start(v4) | | | |<------------------->| | | |Accounting Start(v6) | | Data|Transfer |<------------------->| |------------|-------------------| | | | |Accounting Stop(v4) | | | |<------------------->| | | |Accounting Stop(v6) | | | |<------------------->| Figure 1: Access and accounting procedures The detailed procedures are as below: 1. CPE initiates LCP procedure with BRAS. 2. CPE sends PPP authentication request to BRAS. 3. BRAS will send authentication to RADIUS after receiving user authentication request. 4. RADIUS returns Access Accept message with IPv4 and IPv6 attributes, after authentication is accepted. In this example, the user is dual stack. Tan, et al. Expires January 5, 2012 [Page 9] Internet-Draft AAA for BB access in IPv6 transition July 2011 5. BRAS send authentication confirmation to the CPE after receiving message from RADIUS. 6. CPE acquires IPv4 address in the IPCP negotiation with BRAS. 7. CPE acquires Link Local IPv6 address in the IPv6CP process with BRAS 8. CPE gets IPv6 prefix of WAN interface via Neighbor Discovery and generates Global IPv6 address of WAN interface; CPE may also get IPv6 prefix from BRAS via DHCP. 9. CPE retrieves IPv6 prefix of LAN interface via DHCP-PD. 10. The host acquires IPv6 prefix via Neighbor Discovery and generates Global IPv6 address. 11. BRAS initiates IPv4 Accounting Start message, including user name and IPv4 address. 12. BRAS initiates IPv6 Accounting Start message, including user name and IPv6 prefix of host and CPE. 13. The host is connected to IPv4 and IPv6 network. 14. BRAS send IPv4 Accounting Stop message to the RADIUS server, which includes user name, IPv4 address, traffic and lifetime. 15. BRAS send IPv6 Accounting Stop message to the RADIUS server, which includes user name, IPv6 prefix of the host and CPE, traffic and lifetime. 7. Security Considerations None. 8. IANA Considerations This memo makes no request of IANA. 9. Normative References [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. Tan, et al. Expires January 5, 2012 [Page 10] Internet-Draft AAA for BB access in IPv6 transition July 2011 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. Authors' Addresses Jinhua Tan China Telecom 109, Zhongshan Ave. West Guangzhou 510630 P.R. China Phone: Email: tanjh@gsta.com Guoliang Yang China Telecom 109, Zhongshan Ave. West Guangzhou 510630 P.R. China Phone: Email: yanggl@gsta.com Tan, et al. Expires January 5, 2012 [Page 11] Internet-Draft AAA for BB access in IPv6 transition July 2011 Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathyzhou@huawei.com Tan, et al. Expires January 5, 2012 [Page 12]