idnits 2.17.1 draft-lourdelet-radext-ipv6-access-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 17, 2009) is 5237 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2868' is defined on line 373, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Lourdelet, Ed. 3 Internet-Draft W. Dec, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: June 20, 2010 B. Sarikaya 6 Huawei USA 7 G. Zorn 8 Network Zen 9 D. Miles 10 Alcatel-Lucent 11 December 17, 2009 13 RADIUS attributes for IPv6 Access Networks 14 draft-lourdelet-radext-ipv6-access-02.txt 16 Abstract 18 IPv6 nodes can have configuration information provided to them using 19 DHCPv6 and/or Router Advertisements. This document specifies RADIUS 20 attributes that complement RFC3162 for use with DHCPv6 and/or Router 21 Advertisements (SLAAC) for use in network access scenarios. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 20, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 3 78 3.1. IPv6 Address Assignment . . . . . . . . . . . . . . . . . . 3 79 3.2. Recursive DNS Servers . . . . . . . . . . . . . . . . . . . 3 80 3.3. IPv6 Route Information . . . . . . . . . . . . . . . . . . 4 81 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 4.1. Framed-IPv6-Address . . . . . . . . . . . . . . . . . . . . 4 83 4.2. IPv6-DNS-Server-Address . . . . . . . . . . . . . . . . . . 5 84 4.3. IPv6-Route-Information . . . . . . . . . . . . . . . . . . 6 85 4.4. Table of attributes . . . . . . . . . . . . . . . . . . . . 7 86 5. Diameter Considerations . . . . . . . . . . . . . . . . . . . . 8 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 95 1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 This document specifies new IPv6 RADIUS attributes used to support 104 IPv6 network access. As IPv6 specifies two configuration mechanisms 105 (DHCP and SLAAC) the attributes defined in this document may apply to 106 DHCPv6, SLAAC or both with the new attributes are targeted at both 107 protocols when it makes sense. The RADIUS attributes defined in 108 [RFC3162]and [RFC4818] do not define methods for assignment of IPv6 109 addresses to hosts (via DHCPv6) or IPv6 recursive DNS servers (via 110 DHCPv6 or [[RFC5006]), nor the passing of route prefix info (via 111 [RFC4191]. The Radius options to do so are the subject of this 112 draft. 114 3. Deployment Scenarios 116 3.1. IPv6 Address Assignment 118 DHCPv6 [RFC3315] provides a mechanism to assign one or more or non- 119 temporary IPv6 addresses to nodes. In IPv6, both SLAAC and DHCPv6 120 can be used for address assignment. While SLAAC provides a host with 121 a /64 IPv6 prefix from which to construct its address, the host is 122 free to construct a 64-bit Interface ID that when concatenated with 123 the /64 prefix provides a unique address. By providing a host only a 124 /64 network operators are unaware of the exact IP addresses in use by 125 a device. To contrast SLAAC, DHCPv6 requires a host explicitly 126 request non-temporary addresses from a DHCPv6 server permitting an 127 operator control over address assignment. This document specifies a 128 new RADIUS attribute for the assignment of non-temporary IPv6 129 addresses to a host via DHCPv6. Other DHCPv6 parameters such as 130 preferred and valid address lifetimes are provided for by the NAS and 131 not through RADIUS attributes. As a DHCPv6 client may request an 132 address at any time, a RADIUS server may be required to service 133 additional RADIUS Access-Requests for a single network access 134 session. 136 3.2. Recursive DNS Servers 138 DHCPv6 provides an option for recursive DNS servers to hosts, as does 139 a Router Advertisement supporting the experimental [RFC5006]. 140 Existing DHCPv4 options only convey DNS as 32-bit IPv4 addresses and 141 cannot support a 128-bit IPv6 address. In the current RADIUS 142 specifications there are no IETF/IANA defined attributes for 143 recursive DNS and many NAS implement vendor specific attributes 144 (e.g.: Ascend-Primary-DNS). In some operator environments a network 145 access session may be configured with a specific set of one or more 146 recursive DNS. This document specifies a new RADIUS attribute to 147 convey a list of IPv6 addresses that can be used for a host for 148 domain name service. Best current practice is to configure hosts 149 with more than one recursive domain name server, this is achieved in 150 the RADIUS environment by returning multiple IPv6-DNS-Server-Address 151 options within an Access-Accept. The NAS shall use the addresses 152 returned in the RADIUS IPv6-DNS-Server-Address attribute for the 153 DHCPv6 DNS-Servers option [RFC3646], the Router Advertisement 154 Recursive DNS Server Option [RFC5006], or both. 156 3.3. IPv6 Route Information 158 In scenarios where Stateless Address Autoconfiguration (SLAAC) 159 [RFC4862] is used for address assignment, a Router Advertisement is 160 multicast with one or more Prefix Information Options with the 161 autonomous-bit set to true. A Prefix Information Option, when used 162 for SLAAC, is a /64 prefix to which a host appends its locally- 163 generated Interface Id to create a unique 128-bit IPv6 address. 164 [RFC3162] currently defines a Framed-IPv6-Prefix which can be used by 165 a NAS to advertise on-link prefixes in a Router Advertisement Prefix 166 Information Option [RFC4861]. The IPv6 Route Information attribute 167 is almost the inverse; it is intended to be used to instruct a host 168 connected to the NAS that a specific route is reachable via the NAS/ 169 router. [RFC4191] defines an ICMPv6 Route Information Option for 170 this purpose, ie to convey route information from a router to a host. 171 The Route Information Option is used in environments where multiple 172 advertising routers are present. It directs a host to which router 173 each specific route should be the next-hop to. For each IPv6-Prefix- 174 Information attribute, the NAS may advertise a unique [RFC4191] Route 175 Information Option. 177 4. Attributes 179 The fields shown in the diagrams below are transmitted from left to 180 right. 182 4.1. Framed-IPv6-Address 184 This Attribute indicates an IPv6 Address that is assigned to the 185 uplink NAS-facing interface of the user equipment. It MAY be used in 186 Access-Accept packets, and can appear multiple times. It MAY be used 187 in an Access-Request packet as a hint by the NAS to the server that 188 it would prefer these IPv6 address(es), but the server is not 189 required to honor the hint. Since it is assumed that the NAS, when 190 necessary, will add a route corresponding to the address it is not 191 necessary for the server to also send a host Framed-IPv6-Route 192 attribute for the same address. 194 This Attribute can be used by DHCPv6 to offer a unique IPv6 address 195 or can be used for a-posteriori validation or announcment of an 196 autoconfigured address. 198 A summary of the Framed-IPv6-Address Attribute format is shown below. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type | Length | Address 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Address (cont) 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Address (cont) 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Address (cont) 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Address (cont.) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Type 216 TBA1 for Framed-IPv6-Address 218 Length 220 18 222 Address 224 The Address field contains a 128-bit IPv6 address. 226 4.2. IPv6-DNS-Server-Address 228 The IPv6-DNS-Server-Address Attribute contains the IPv6 address of a 229 DNS server. This attribute MAY be included multiple times in Access- 230 Accept packets. 232 The content of this attribute can be inserted in a Router 233 Advertisement as specified in [RFC5006] or mapped to the matching 234 DHCPv6 option. 236 A summary of the IPv6-DNS-Server-Address Attribute format is given 237 below. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | Address 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Address (cont) 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Address (cont) 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Address (cont) 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Address (cont.) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Type 255 TBA2 for IPv6-DNS-Server-Address 257 Length 259 18 261 Address 263 The 128-bit IPv6 address of a DNS server. 265 4.3. IPv6-Route-Information 267 This Attribute specifies a prefix (and corresponding route) to be 268 authorized for announcement towards the user by the NAS, with the 269 reachable by means of routing towards the NAS. It is used in the 270 Access-Accept packet and can appear multiple times. It may also be 271 used in the Access-Request packet. 273 A summary of the IPv6-Route-Information attribute format is shown 274 below. The route information option defined in [RFC4191] is captured 275 in this and following two attributes. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Length | Reserved | Prefix-Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 . Prefix (variable) . 284 . . 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Type 290 TBA3 for IPv6-Route-Information 292 Length 294 Length in bytes. At least 4 and no larger than 20; typically 12 295 or less. 297 Prefix Length 299 The length of the prefix, in bits; at least 0 and no more than 300 128; typically 64 or less. 302 Prefix 304 Variable-length field containing an IP prefix. The Prefix Length 305 field contains the number of valid leading bits in the prefix. 306 The bits in the prefix after the prefix length (if any) up to the 307 byte boundary are reserved and MUST be initialized to zero by the 308 sender and ignored by the receiver. 310 4.4. Table of attributes 312 The following table provides a guide to which attributes may be found 313 in which kinds of packets, and in what quantity. 315 Request Accept Reject Challenge Accounting # Attribute 316 Request 317 0+ 0+ 0 0 0+ TBA1 Framed-IPv6-Address 318 0+ 0+ 0 0 0+ TBA2 IPv6-DNS-Server-Address 319 0 0+ 0 0 0+ TBA3 IPv6-Route-Information 321 5. Diameter Considerations 323 Since the Attributes defined in this document are allocated from the 324 standard RADIUS type space (see Section 7), no special handling is 325 required by Diameter entities. 327 6. Security Considerations 329 This document describes the use of RADIUS for the purposes of 330 authentication, authorization and accounting in IPv6-enabled 331 networks. In such networks, the RADIUS protocol may run either over 332 IPv4 or over IPv6. Known security vulnerabilities of the RADIUS 333 protocol apply to the attributes defined in this document. Since 334 IPSEC is natively defined for IPv6, it is expected that running 335 RADIUS implementations supporting IPv6 may want to run over IPSEC. 336 Where RADIUS is run over IPSEC and where certificates are used for 337 authentication, it may be desirable to avoid management of RADIUS 338 shared secrets, so as to leverage the improved scalability of public 339 key infrastructure. 341 7. IANA Considerations 343 This document requires the assignment of three new RADIUS Attribute 344 Types in the "Radius Types" registry (currently located at 345 http://www.iana.org/assignments/radius-types for the following 346 attributes: 348 o Framed-IPv6-Address 350 o IPv6-DNS-Server-Address 352 o IPv6-Prefix-Information 354 IANA should allocate these numbers from the standard RADIUS 355 Attributes space using the "IETF Review" policy [RFC5226]. 357 8. Acknowledgements 359 The authors would like to thank Alfred Hines for his contributions 360 and comments to this document. 362 9. References 363 9.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 369 Address Autoconfiguration", RFC 4862, September 2007. 371 9.2. Informative References 373 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 374 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 375 Support", RFC 2868, June 2000. 377 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 378 RFC 3162, August 2001. 380 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 381 and M. Carney, "Dynamic Host Configuration Protocol for 382 IPv6 (DHCPv6)", RFC 3315, July 2003. 384 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 385 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 386 December 2003. 388 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 389 More-Specific Routes", RFC 4191, November 2005. 391 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 392 Attribute", RFC 4818, April 2007. 394 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 395 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 396 September 2007. 398 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 399 "IPv6 Router Advertisement Option for DNS Configuration", 400 RFC 5006, September 2007. 402 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 403 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 404 May 2008. 406 Authors' Addresses 408 Benoit Lourdelet (editor) 409 Cisco Systems, Inc. 410 Village ent. GreenSide, Bat T3, 411 400, Av de Roumanille, 412 06410 BIOT - Sophia-Antipolis Cedex 413 France 415 Phone: +33 4 97 23 26 23 416 Email: blourdel@cisco.com 418 Wojciech Dec (editor) 419 Cisco Systems, Inc. 420 Haarlerbergweg 13-19 421 Amsterdam , NOORD-HOLLAND 1101 CH 422 Netherlands 424 Email: wdec@cisco.com 426 Behcet Sarikaya 427 Huawei USA 428 1700 Alma Dr. Suite 500 429 Plano, TX 430 US 432 Phone: +1 972-509-5599 433 Email: sarikaya@ieee.org 435 Glen Zorn 436 Network Zen 437 1310 East Thomas Street 438 Seattle, WA 439 US 441 Email: gwz@net-zen.net 442 David Miles 443 Alcatel-Lucent 444 L3 / 215 Spring St 445 Melbourne, Victoria 3000, 446 Australia 448 Phone: 449 Fax: 450 Email: David.Miles@alcatel-lucent.com 451 URI: