Network Working Group B. Lourdelet Internet-Draft W. Dec, Ed. Intended status: Standards Track Cisco Systems, Inc. Expires: October 31, 2010 B. Sarikaya Huawei USA G. Zorn Network Zen D. Miles Alcatel-Lucent April 29, 2010 RADIUS attributes for IPv6 Access Networks draft-ietf-radext-ipv6-access-01.txt Abstract IPv6 nodes can have configuration information provided to them using DHCPv6 and/or Router Advertisements. This document specifies RADIUS attributes that complement RFC3162 for use with DHCPv6 and/or Router Advertisements (RAs) and their application in broadband network access. Requirements Language 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 RFC 2119 [RFC2119]. 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 October 31, 2010. Copyright Notice Lourdelet, et al. Expires October 31, 2010 [Page 1] Internet-Draft RADIUS IPv6 Access April 2010 Copyright (c) 2010 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 described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Lourdelet, et al. Expires October 31, 2010 [Page 2] Internet-Draft RADIUS IPv6 Access April 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 2.1. IPv6 Address Assignment . . . . . . . . . . . . . . . . . 5 2.2. Recursive DNS Servers . . . . . . . . . . . . . . . . . . 5 2.3. IPv6 Route Information . . . . . . . . . . . . . . . . . . 6 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Framed-IPv6-Address . . . . . . . . . . . . . . . . . . . 6 3.2. DNS-Server-IPv6-Address . . . . . . . . . . . . . . . . . 7 3.3. Route-IPv6-Information . . . . . . . . . . . . . . . . . . 8 3.4. Table of attributes . . . . . . . . . . . . . . . . . . . 9 3.5. RFC3162 Attribute coexistance . . . . . . . . . . . . . . 9 4. Diameter Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Lourdelet, et al. Expires October 31, 2010 [Page 3] Internet-Draft RADIUS IPv6 Access April 2010 1. Introduction This document specifies new IPv6 RADIUS attributes used to support AAA functions of an IPv6 network access. The IPv6 RADIUS attributes already defined in [RFC3162] and [RFC4818] do not define methods for assignment of IPv6 addresses to hosts (via DHCPv6) or IPv6 recursive DNS servers (via DHCPv6 or [RFC5006]), nor the passing of route prefix info (via [RFC4191]. Such Radius attributes are the subject of this draft. 2. Deployment Scenarios A common fixed line broadband network scenario is illustrated in Figure 1, and is composed of a IP Routing Residential Gateway (RG) hosts, a Layer 2 Access-Node (e.g. a DSLAM), one or more Broadband Network Gateways (BNG) that are the effectively IP Network Access Servers (NASes), and an AAA server. The RG host is expected to have direct connectivity at Layer 2 to both BNGs, with one of the devices typically being intended for providing access to a specific operator service (e.g. IP TV) that can be characterized by a known IP subnet. +-----+ (Radius) | AAA | ...........>| | . +--+--+ v ^ +---+---+ . | BNG | .(Radius) | | . +---+---+ v +------+ | +---+---+ +------+ | AN | | | BNG | | RG +-------| +-----------+----------+ | +------+ (DSL) +------+ (Ethernet) +-------+ Figure 1 In illustrated deployment scenario the BNGs are assumed to embed a DHCPv6 server function that allows them to locally handle any DHCPv6 requests issued by RG hosts. This scenario is particularly useful in illustrating the possible interaction between RADIUS and DHCPv6, however the options defined in this document are not restricted to be used only in the presence of such embedded functionality. The BNGs interface to the AAA server by means of the RADIUS protocol. The AAA server is expected to authenticate each RG that typically connects by means of PPPoE and to return to the BNG per host Lourdelet, et al. Expires October 31, 2010 [Page 4] Internet-Draft RADIUS IPv6 Access April 2010 authorization and network configuration information which, among other information, can comprise of: One or more IP addresses Recursive DNS servers intended to be used by the host; specific IP routes corresponding to service subnets that are then expected to assist the RG in selecting the appropriate BNG; an explicit IP address that is to be state fully assigned to a given RG host. The method by which the BNG can communicate this information to each host is explained in each of the following sub-sections. 2.1. IPv6 Address Assignment DHCPv6 [RFC3315] provides a mechanism to assign one or more or non- temporary IPv6 addresses to nodes. In IPv6, both SLAAC and DHCPv6 can be used for address assignment. While SLAAC provides a host with a /64 IPv6 prefix from which to construct its address, the host is free to construct a 64-bit Interface ID that when concatenated with the /64 prefix provides a unique address. By providing a host only a /64 network operators are unaware of the exact IP addresses in use by a device. To contrast SLAAC, DHCPv6 requires a host explicitly request non-temporary addresses from a DHCPv6 server permitting an operator control over address assignment. This document specifies a new RADIUS attribute for the assignment of non-temporary IPv6 addresses to a host via DHCPv6. Other DHCPv6 parameters such as preferred and valid address lifetimes are provided for by the NAS and not through RADIUS attributes. As a DHCPv6 client may request an address at any time, a RADIUS server may be required to service additional RADIUS Access-Requests for a single network access session. 2.2. Recursive DNS Servers DHCPv6 provides an option for recursive DNS servers to hosts, as does a Router Advertisement supporting the experimental [RFC5006]. Existing DHCPv4 options only convey DNS as 32-bit IPv4 addresses and cannot support a 128-bit IPv6 address. In the current RADIUS specifications there are no IETF/IANA defined attributes for recursive DNS and many NAS implement vendor specific attributes (e.g.: Ascend-Primary-DNS). In some operator environments a network access session may be configured with a specific set of one or more recursive DNS. This document specifies a new RADIUS attribute to convey a list of IPv6 addresses that can be used for a host for domain name service. Best current practice is to configure hosts with more than one recursive domain name server, this is achieved in the RADIUS environment by returning multiple DNS-Server-IPv6-Address options within an Access-Accept. The NAS shall use the addresses returned in the RADIUS DNS-Server-IPv6-Address attribute for the DHCPv6 DNS-Servers option [RFC3646], the Router Advertisement Recursive DNS Server Option [RFC5006], or both. Lourdelet, et al. Expires October 31, 2010 [Page 5] Internet-Draft RADIUS IPv6 Access April 2010 2.3. IPv6 Route Information In scenarios where Stateless Address Autoconfiguration (SLAAC) [RFC4862] is used for address assignment, a Router Advertisement is multicast with one or more Prefix Information Options with the autonomous-bit set to true. A Prefix Information Option, when used for SLAAC, is a /64 prefix to which a host appends its locally- generated Interface Id to create a unique 128-bit IPv6 address. [RFC3162] currently defines a Framed-IPv6-Prefix which can be used by a NAS to advertise on-link prefixes in a Router Advertisement Prefix Information Option [RFC4861]. The IPv6 Route Information attribute is almost the inverse; it is intended to be used to instruct a host connected to the NAS that a specific route is reachable via the NAS/ router. [RFC4191] defines an ICMPv6 Route Information Option for this purpose, i.e. to convey route information from a router to a host. The Route Information Option is used in environments where multiple advertising routers are present. It directs a host to which router each specific route should be the next-hop to. For each IPv6- Prefix-Information attribute, the NAS may advertise a unique [RFC4191] Route Information Option. 3. Attributes The fields shown in the diagrams below are transmitted from left to right. 3.1. Framed-IPv6-Address This Attribute indicates an IPv6 Address that is assigned to the uplink NAS-facing interface of the user equipment. It MAY be used in Access-Accept packets, and can appear multiple times. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer these IPv6 address(es), but the server is not required to honor the hint. Since it is assumed that the NAS, when necessary, will add a route corresponding to the address it is not necessary for the server to also send a host Framed-IPv6-Route attribute for the same address. This Attribute can be used by DHCPv6 to offer a unique IPv6 address or can be used for a-posteriori validation or announcement of an autoconfigured address. A summary of the Framed-IPv6-Address Attribute format is shown below. Lourdelet, et al. Expires October 31, 2010 [Page 6] Internet-Draft RADIUS IPv6 Access April 2010 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA1 for Framed-IPv6-Address Length 18 Address The Address field contains a 128-bit IPv6 address. 3.2. DNS-Server-IPv6-Address The DNS-Server-IPv6-Address Attribute contains the IPv6 address of a DNS server. This attribute MAY be included multiple times in Access- Accept packets. The content of this attribute can be inserted in a Router Advertisement as specified in [RFC5006] or mapped to the matching DHCPv6 option. A summary of the DNS-Server-IPv6-Address Attribute format is given below. Lourdelet, et al. Expires October 31, 2010 [Page 7] Internet-Draft RADIUS IPv6 Access April 2010 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 | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA2 for DNS-Server-IPv6-Address Length 18 Address The 128-bit IPv6 address of a DNS server. 3.3. Route-IPv6-Information This Attribute specifies a prefix (and corresponding route) to be authorized for announcement towards the user by the NAS, with the reachable by means of routing towards the NAS. It is used in the Access-Accept packet and can appear multiple times. It may also be used in the Access-Request packet. A summary of the Route-IPv6-Information attribute format is shown below. The route information option defined in [RFC4191] is captured in this and following two attributes. 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 | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Prefix (variable) . . . | | Lourdelet, et al. Expires October 31, 2010 [Page 8] Internet-Draft RADIUS IPv6 Access April 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 for Route-IPv6-Information Length Length in bytes. At least 4 and no larger than 20; typically 12 or less. Prefix Length The length of the prefix, in bits; at least 0 and no more than 128; typically 64 or less. Prefix Variable-length field containing an IP prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) up to the byte boundary are reserved and MUST be initialized to zero by the sender and ignored by the receiver. 3.4. Table of attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Accounting # Attribute Request 0+ 0+ 0 0 0+ TBA1 Framed-IPv6-Address 0+ 0+ 0 0 0+ TBA2 DNS-Server-IPv6-Address 0 0+ 0 0 0+ TBA3 Route-IPv6-Information 3.5. RFC3162 Attribute coexistance Syntactically, the Framed-IPv6-Address and the [RFC3162] Framed-IPv6- Prefix attributes are identical. In terms of their intended semantics, however as described by this draft the former represents a statefully assigned IPv6 address while the latter a prefix intended for application on a target NAS interface. These attributes are envisaged to co-exist in Radius messages and thus it is recommended that each attribute be used for its intended semantical purpose only. A functional substitution of one attribute for the other may however be an optional configuration feature of a Radius client and server. Lourdelet, et al. Expires October 31, 2010 [Page 9] Internet-Draft RADIUS IPv6 Access April 2010 4. Diameter Considerations Since the Attributes defined in this document are allocated from the standard RADIUS type space (see Section 6), no special handling is required by Diameter entities. 5. Security Considerations This document describes the use of RADIUS for the purposes of authentication, authorization and accounting in IPv6-enabled networks. In such networks, the RADIUS protocol may run either over IPv4 or over IPv6. Known security vulnerabilities of the RADIUS protocol apply to the attributes defined in this document. Since IPSEC is natively defined for IPv6, it is expected that running RADIUS implementations supporting IPv6 may want to run over IPSEC. Where RADIUS is run over IPSEC and where certificates are used for authentication, it may be desirable to avoid management of RADIUS shared secrets, so as to leverage the improved scalability of public key infrastructure. 6. IANA Considerations This document requires the assignment of three new RADIUS Attribute Types in the "Radius Types" registry (currently located at http://www.iana.org/assignments/radius-types for the following attributes: o Framed-IPv6-Address o DNS-Server-IPv6-Address o Route-IPv6-Information IANA should allocate these numbers from the standard RADIUS Attributes space using the "IETF Review" policy [RFC5226]. 7. Acknowledgements The authors would like to thank Alfred Hines, Alan DeKok and Peter Deacon for their help in reviewing this document. 8. References Lourdelet, et al. Expires October 31, 2010 [Page 10] Internet-Draft RADIUS IPv6 Access April 2010 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 8.2. Informative References [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [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. [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Lourdelet, et al. Expires October 31, 2010 [Page 11] Internet-Draft RADIUS IPv6 Access April 2010 Authors' Addresses Benoit Lourdelet Cisco Systems, Inc. Village ent. GreenSide, Bat T3, 400, Av de Roumanille, 06410 BIOT - Sophia-Antipolis Cedex France Phone: +33 4 97 23 26 23 Email: blourdel@cisco.com Wojciech Dec (editor) Cisco Systems, Inc. Haarlerbergweg 13-19 Amsterdam , NOORD-HOLLAND 1101 CH Netherlands Email: wdec@cisco.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX US Phone: +1 972-509-5599 Email: sarikaya@ieee.org Glen Zorn Network Zen 1310 East Thomas Street Seattle, WA US Email: gwz@net-zen.net Lourdelet, et al. Expires October 31, 2010 [Page 12] Internet-Draft RADIUS IPv6 Access April 2010 David Miles Alcatel-Lucent L3 / 215 Spring St Melbourne, Victoria 3000, Australia Phone: Fax: Email: David.Miles@alcatel-lucent.com URI: Lourdelet, et al. Expires October 31, 2010 [Page 13]