Network Working Group B. Lourdelet Internet-Draft Cisco Systems, Inc. Obsoletes: 3162 (if approved) G. Zorn Intended status: Standards Track Network Zen Expires: May 6, 2009 November 2, 2008 RADIUS Attributes for IPv6 Support draft-lourdelet-radext-rfc3162bis-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 6, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. Lourdelet & Zorn Expires May 6, 2009 [Page 1]
Internet-Draft RADIUS and IPv6 November 2008 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. NAS-IPv6-Address . . . . . . . . . . . . . . . . . . . . . 3 3.2. Framed-Interface-Id . . . . . . . . . . . . . . . . . . . 4 3.3. Framed-IPv6-Prefix . . . . . . . . . . . . . . . . . . . . 5 3.4. Login-IPv6-Host . . . . . . . . . . . . . . . . . . . . . 6 3.5. Framed-IPv6-Route . . . . . . . . . . . . . . . . . . . . 7 3.6. Framed-IPv6-Pool . . . . . . . . . . . . . . . . . . . . . 8 3.7. IPv6-Address Attribute . . . . . . . . . . . . . . . . . . 9 3.8. IPv6-DNS-Server-Address . . . . . . . . . . . . . . . . . 10 3.9. Table of attributes . . . . . . . . . . . . . . . . . . . 10 4. Diameter Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Lourdelet & Zorn Expires May 6, 2009 [Page 2]
Internet-Draft RADIUS and IPv6 November 2008 1. 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 [RFC2119]. 2. Introduction This document specifies the operation of RADIUS [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869] over IPv6 [RFC2460] as well as the RADIUS attributes used to support IPv6 network access. Note that a NAS sending a RADIUS Access-Request may not know a-priori whether the host will be using IPv4, IPv6, or both. For example, within PPP, IPv6CP [RFC5072], [RFC5172] occurs after LCP, so that address assignment will not occur until after RADIUS authentication and authorization has completed. Similarly, the DHCP exchange occurs after PPP is fully setup. Therefore it is presumed that the IPv6 attributes described in this document MAY be sent along with IPv4-related attributes within the same RADIUS message and that the NAS will decide which attributes to use. The NAS SHOULD only allocate addresses and prefixes that the client can actually use, however. For example, there is no need for the NAS to reserve use of an IPv4 address for a host that only supports IPv6; similarly, a host only using IPv4 or 6to4 [RFC3056] does not require allocation of an IPv6 prefix. The NAS can provide IPv6 access natively, or alternatively, via other methods such as IPv6 within IPv4 tunnels [RFC4213] or 6over4 [RFC2529]. The choice of method for providing IPv6 access has no effect on RADIUS usage per se, although if it is desired that an IPv6 within IPv4 tunnel be opened to a particular location, then tunnel attributes should be utilized, as described in [RFC2867], [RFC2868]. 3. Attributes 3.1. NAS-IPv6-Address This Attribute indicates the identifying IPv6 Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. The NAS-IPv6- Address Attribute is only used in Access-Request packets. The NAS- IPv6-Address and/or NAS-IP-Address MAY be present in an Access- Request packet; however, if neither attribute is present then NAS- Identifier MUST be present. Lourdelet & Zorn Expires May 6, 2009 [Page 3]
Internet-Draft RADIUS and IPv6 November 2008 A summary of the NAS-IPv6-Address Attribute format is shown below. The fields are transmitted from left to right. 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 95 for NAS-IPv6-Address length 18 Address The Address field is 16 octets in length and contains the IPv6 address of the NAS. 3.2. Framed-Interface-Id This Attribute indicates the IPv6 interface identifier to be configured for the user. It MAY be used in Access-Accept packets. If the Interface-Identifier IPv6CP option [RFC2472] has been successfully negotiated, this Attribute MUST be included in an Access-Request packet as a hint by the NAS to the server that it would prefer that value. It is recommended, but not required, that the server honor the hint. A summary of the Framed-Interface-Id Attribute format is shown below. The fields are transmitted from left to right. Lourdelet & Zorn Expires May 6, 2009 [Page 4]
Internet-Draft RADIUS and IPv6 November 2008 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 | Interface-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface-Id (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface-Id (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 96 for Framed-Interface-Id Length 10 Interface-Id The Interface-Id field is 8 octets in length anf contains the Interface-Id negotiated during IPv6CP. 3.3. Framed-IPv6-Prefix This Attribute indicates an IPv6 prefix (and corresponding route) to be configured for the user. 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 prefix(es), but the server is not required to honor the hint. Since it is assumed that the NAS will plumb a route corresponding to the prefix, it is not necessary for the server to also send a Framed- IPv6-Route attribute for the same prefix. A summary of the Framed-IPv6-Prefix Attribute format is shown below. The fields are transmitted from left to right. Lourdelet & Zorn Expires May 6, 2009 [Page 5]
Internet-Draft RADIUS and IPv6 November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 97 for Framed-IPv6-Prefix Length At least 4 and no larger than 20. Reserved This field, which is reserved and MUST be present, is always set to zero. Prefix-Length The length of the prefix, in bits; at least 0 and no more than 128. Prefix The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, must be zero. 3.4. Login-IPv6-Host This Attribute indicates the system with which to connect the user, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY be used in an Access- Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint. A summary of the Login-IPv6-Host Attribute format is shown below. The fields are transmitted from left to right. Lourdelet & Zorn Expires May 6, 2009 [Page 6]
Internet-Draft RADIUS and IPv6 November 2008 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 98 for Login-IPv6-Host Length 18 Address The Address field is 16 octets in length. The value 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD allow the user to select an address or name to be connected to. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address to which the NAS SHOULD connect the user. 3.5. Framed-IPv6-Route This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times. A summary of the Framed-IPv6-Route Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-- | Type | Length | Text... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Lourdelet & Zorn Expires May 6, 2009 [Page 7]
Internet-Draft RADIUS and IPv6 November 2008 Type 99 for Framed-IPv6-Route Length >= 3 Text The Text field is one or more octets, and its contents are implementation dependent. The field is not NUL (hex 00) terminated. It is intended to be human readable and MUST NOT affect operation of the protocol. For IPv6 routes, it SHOULD contain a destination prefix optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address, a space, and one or more metrics (encoded in decimal) separated by spaces. Prefixes and addresses are formatted as described in [RFC2373]. For example, "2001:db8: 0:106::/64 2001:db8:106:a00:20ff:fe99:a998 1". Whenever the gateway address is the IPv6 unspecified address the IP address of the user SHOULD be used as the gateway address. The unspecified address can be expressed in any of the acceptable formats described in [RFC2373]. For example, "2001:db8:0:106::/64 :: 1". 3.6. Framed-IPv6-Pool This Attribute contains the name of an assigned pool that SHOULD be used to assign an IPv6 prefix for the user. If a NAS does not support multiple prefix pools, the NAS MUST ignore this Attribute. A summary of the Framed-IPv6-Pool Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 100 for Framed-IPv6-Pool Lourdelet & Zorn Expires May 6, 2009 [Page 8]
Internet-Draft RADIUS and IPv6 November 2008 Length >= 3 String The string field contains the name of an assigned IPv6 prefix pool configured on the NAS. The field is not NUL (hex 00) terminated. 3.7. IPv6-Address Attribute This Attribute indicates an IPv6 Address that is assigned to the uplink 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. A summary of the IPv6-Address Attribute format is shown below. The fields are transmitted from left to right. 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 x for IPv6-Address Length 18 Lourdelet & Zorn Expires May 6, 2009 [Page 9]
Internet-Draft RADIUS and IPv6 November 2008 Address The Address field contains a 128-bit IPv6 address. 3.8. IPv6-DNS-Server-Address The IPv6-DNS-Server-Address Attribute contains the IPv6 address of a DNS server. This attribute MAY be included multiple times in both Access-Accept and Accounting-Request packets. A summary of the IPv6-DNS-Server-Address Attribute format is given below. The fields are transmitted left to right. 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 y for IPv6-DNS-Server-Address Length 18 Address The 128-bit IPv6 address of a DNS server. 3.9. Table of attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Lourdelet & Zorn Expires May 6, 2009 [Page 10]
Internet-Draft RADIUS and IPv6 November 2008 Request Accept Reject Challenge Acct-Req # Attribute 0-1 0 0 0 0-1 95 NAS-IPv6-Address 0-1 0-1 0 0 0-1 96 Framed-Interface-Id 0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix 0+ 0+ 0 0 0+ 98 Login-IPv6-Host 0 0+ 0 0 0+ 99 Framed-IPv6-Route 0 0-1 0 0 0-1 100 Framed-IPv6-Pool 0+ 0+ 0 0 0+ x IPv6-Address 0+ 0+ 0 0 0+ y IPv6-DNS-Server-Address 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 TBD 6. IANA Considerations This document requires the assignment of two new RADIUS attribute numbers for the following attributes: o IPv6-Address o IPv6-DNS-Server-Address IANA should allocate these numbers from the standard RADIUS Attributes space using the "IETF Review" policy [RFC5226]. 7. References 7.1. Normative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Lourdelet & Zorn Expires May 6, 2009 [Page 11]
Internet-Draft RADIUS and IPv6 November 2008 7.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC5072] S.Varada, Haskin, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. [RFC5172] Varada, S., "Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol", RFC 5172, March 2008. Lourdelet & Zorn Expires May 6, 2009 [Page 12]
Internet-Draft RADIUS and IPv6 November 2008 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 Glen Zorn Network Zen 1310 East Thomas Street Seattle, WA US Email: gwz@net-zen.net Lourdelet & Zorn Expires May 6, 2009 [Page 13]
Internet-Draft RADIUS and IPv6 November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lourdelet & Zorn Expires May 6, 2009 [Page 14]