idnits 2.17.1 draft-ietf-radext-ipv6-access-00.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 (March 01, 2010) is 5170 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 417, 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 3 Internet-Draft W. Dec, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: September 2, 2010 B. Sarikaya 6 Huawei USA 7 G. Zorn 8 Network Zen 9 D. Miles 10 Alcatel-Lucent 11 March 01, 2010 13 RADIUS attributes for IPv6 Access Networks 14 draft-ietf-radext-ipv6-access-00.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 broadband network access. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 2, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 This document may contain material from IETF Documents or IETF 68 Contributions published or made publicly available before November 69 10, 2008. The person(s) controlling the copyright in some of this 70 material may not have granted the IETF Trust the right to allow 71 modifications of such material outside the IETF Standards Process. 72 Without obtaining an adequate license from the person(s) controlling 73 the copyright in such materials, this document may not be modified 74 outside the IETF Standards Process, and derivative works of it may 75 not be created outside the IETF Standards Process, except to format 76 it for publication as an RFC or to translate it into languages other 77 than English. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 83 2.1. IPv6 Address Assignment . . . . . . . . . . . . . . . . . 5 84 2.2. Recursive DNS Servers . . . . . . . . . . . . . . . . . . 5 85 2.3. IPv6 Route Information . . . . . . . . . . . . . . . . . . 6 86 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 3.1. IPv6-Framed-Address . . . . . . . . . . . . . . . . . . . 6 88 3.2. IPv6-DNS-Server-Address . . . . . . . . . . . . . . . . . 7 89 3.3. IPv6-Route-Information . . . . . . . . . . . . . . . . . . 8 90 3.4. Table of attributes . . . . . . . . . . . . . . . . . . . 9 91 4. Diameter Considerations . . . . . . . . . . . . . . . . . . . 9 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 94 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 100 1. Introduction 102 This document specifies new IPv6 RADIUS attributes used to support 103 IPv6 network access. As IPv6 specifies two configuration mechanisms 104 (DHCP and SLAAC) the attributes defined in this document may apply to 105 DHCPv6, SLAAC or both with the new attributes are targeted at both 106 protocols when it makes sense. The RADIUS attributes defined in 107 [RFC3162] and [RFC4818] do not define methods for assignment of IPv6 108 addresses to hosts (via DHCPv6) or IPv6 recursive DNS servers (via 109 DHCPv6 or [RFC5006]), nor the passing of route prefix info (via 110 [RFC4191]. The Radius options to do so are the subject of this 111 draft. 113 2. Deployment Scenarios 115 A common fixed line broadband network scenario is illustrated in 116 Figure 1, and is composed of a IP Routing Residential Gateway (RG) 117 hosts, a Layer 2 Access-Node (e.g. a DSLAM), one or more Broadband 118 Network Gateways (BNG) that are the effectively IP NASes, and an AAA 119 server. The RG host is expected to have direct connectivity at Layer 120 2 to both BNGs, with one of the devices typically being intended for 121 providing access to a specific operator service (e.g. IP TV) that 122 can be characterized by a known IP subnet. 124 +----+ 125 (Radius) |AAA | 126 ...........>| | 127 . +--+-+ 128 v ^ 129 +---+---+ . 130 | BNG | .(Radius) 131 | | . 132 +---+---+ v 133 +------+ | +----+--+ 134 +------+ | AN | | | BNG | 135 | RG +-------| +-----------+---------+ | 136 +------+ (DSL) +------+ (Ethernet) +-------+ 138 Figure 1 140 In illustrated deployment scenario the BNGs are assumed to embed a 141 DHCPv6 server function that allows them to locally handle any DHCPv6 142 requests issued by RG hosts. This scenario is particularly useful in 143 illustrating the possible interaction between RADIUS and DHCPv6, 144 however the options defined in this document are not restricted to be 145 used only in the presence of such embedded functionality. 147 The BNGs interface to the AAA server by means of the RADIUS protocol. 148 The AAA server is expected to authenticate each RG that typically 149 connects by means of PPPoE and to return to the BNG per host 150 authorization and network configuration information which, among 151 other information, can comprise of: One or more IP addresses 152 Recursive DNS servers intended to be used by the host; specific IP 153 routes corresponding to service subnets that are then expected to 154 assist the RG in selecting the appropriate BNG; an explicit IP 155 address that is to be state fully assigned to a given RG host. The 156 method by which the BNG can communicate this information to each host 157 is explained in each of the following sub-sections. 159 2.1. IPv6 Address Assignment 161 DHCPv6 [RFC3315] provides a mechanism to assign one or more or non- 162 temporary IPv6 addresses to nodes. In IPv6, both SLAAC and DHCPv6 163 can be used for address assignment. While SLAAC provides a host with 164 a /64 IPv6 prefix from which to construct its address, the host is 165 free to construct a 64-bit Interface ID that when concatenated with 166 the /64 prefix provides a unique address. By providing a host only a 167 /64 network operators are unaware of the exact IP addresses in use by 168 a device. To contrast SLAAC, DHCPv6 requires a host explicitly 169 request non-temporary addresses from a DHCPv6 server permitting an 170 operator control over address assignment. This document specifies a 171 new RADIUS attribute for the assignment of non-temporary IPv6 172 addresses to a host via DHCPv6. Other DHCPv6 parameters such as 173 preferred and valid address lifetimes are provided for by the NAS and 174 not through RADIUS attributes. As a DHCPv6 client may request an 175 address at any time, a RADIUS server may be required to service 176 additional RADIUS Access-Requests for a single network access 177 session. 179 2.2. Recursive DNS Servers 181 DHCPv6 provides an option for recursive DNS servers to hosts, as does 182 a Router Advertisement supporting the experimental [RFC5006]. 183 Existing DHCPv4 options only convey DNS as 32-bit IPv4 addresses and 184 cannot support a 128-bit IPv6 address. In the current RADIUS 185 specifications there are no IETF/IANA defined attributes for 186 recursive DNS and many NAS implement vendor specific attributes 187 (e.g.: Ascend-Primary-DNS). In some operator environments a network 188 access session may be configured with a specific set of one or more 189 recursive DNS. This document specifies a new RADIUS attribute to 190 convey a list of IPv6 addresses that can be used for a host for 191 domain name service. Best current practice is to configure hosts 192 with more than one recursive domain name server, this is achieved in 193 the RADIUS environment by returning multiple IPv6-DNS-Server-Address 194 options within an Access-Accept. The NAS shall use the addresses 195 returned in the RADIUS IPv6-DNS-Server-Address attribute for the 196 DHCPv6 DNS-Servers option [RFC3646], the Router Advertisement 197 Recursive DNS Server Option [RFC5006], or both. 199 2.3. IPv6 Route Information 201 In scenarios where Stateless Address Autoconfiguration (SLAAC) 202 [RFC4862] is used for address assignment, a Router Advertisement is 203 multicast with one or more Prefix Information Options with the 204 autonomous-bit set to true. A Prefix Information Option, when used 205 for SLAAC, is a /64 prefix to which a host appends its locally- 206 generated Interface Id to create a unique 128-bit IPv6 address. 207 [RFC3162] currently defines a Framed-IPv6-Prefix which can be used by 208 a NAS to advertise on-link prefixes in a Router Advertisement Prefix 209 Information Option [RFC4861]. The IPv6 Route Information attribute 210 is almost the inverse; it is intended to be used to instruct a host 211 connected to the NAS that a specific route is reachable via the NAS/ 212 router. [RFC4191] defines an ICMPv6 Route Information Option for 213 this purpose, ie to convey route information from a router to a host. 214 The Route Information Option is used in environments where multiple 215 advertising routers are present. It directs a host to which router 216 each specific route should be the next-hop to. For each IPv6-Prefix- 217 Information attribute, the NAS may advertise a unique [RFC4191] Route 218 Information Option. 220 3. Attributes 222 The fields shown in the diagrams below are transmitted from left to 223 right. 225 3.1. IPv6-Framed-Address 227 This Attribute indicates an IPv6 Address that is assigned to the 228 uplink NAS-facing interface of the user equipment. It MAY be used in 229 Access-Accept packets, and can appear multiple times. It MAY be used 230 in an Access-Request packet as a hint by the NAS to the server that 231 it would prefer these IPv6 address(es), but the server is not 232 required to honor the hint. Since it is assumed that the NAS, when 233 necessary, will add a route corresponding to the address it is not 234 necessary for the server to also send a host Framed-IPv6-Route 235 attribute for the same address. 237 This Attribute can be used by DHCPv6 to offer a unique IPv6 address 238 or can be used for a-posteriori validation or announcement of an 239 autoconfigured address. 241 A summary of the IPv6-Framed-Address Attribute format is shown below. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | Address 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Address (cont) 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Address (cont) 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Address (cont) 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Address (cont.) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Type 259 TBA1 for IPv6-Framed-Address 261 Length 263 18 265 Address 267 The Address field contains a 128-bit IPv6 address. 269 3.2. IPv6-DNS-Server-Address 271 The IPv6-DNS-Server-Address Attribute contains the IPv6 address of a 272 DNS server. This attribute MAY be included multiple times in Access- 273 Accept packets. 275 The content of this attribute can be inserted in a Router 276 Advertisement as specified in [RFC5006] or mapped to the matching 277 DHCPv6 option. 279 A summary of the IPv6-DNS-Server-Address Attribute format is given 280 below. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | Address 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Address (cont) 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Address (cont) 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Address (cont) 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Address (cont.) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Type 298 TBA2 for IPv6-DNS-Server-Address 300 Length 302 18 304 Address 306 The 128-bit IPv6 address of a DNS server. 308 3.3. IPv6-Route-Information 310 This Attribute specifies a prefix (and corresponding route) to be 311 authorized for announcement towards the user by the NAS, with the 312 reachable by means of routing towards the NAS. It is used in the 313 Access-Accept packet and can appear multiple times. It may also be 314 used in the Access-Request packet. 316 A summary of the IPv6-Route-Information attribute format is shown 317 below. The route information option defined in [RFC4191] is captured 318 in this and following two attributes. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | Reserved | Prefix-Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 . Prefix (variable) . 327 . . 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Type 333 TBA3 for IPv6-Route-Information 335 Length 337 Length in bytes. At least 4 and no larger than 20; typically 12 338 or less. 340 Prefix Length 342 The length of the prefix, in bits; at least 0 and no more than 343 128; typically 64 or less. 345 Prefix 347 Variable-length field containing an IP prefix. The Prefix Length 348 field contains the number of valid leading bits in the prefix. 349 The bits in the prefix after the prefix length (if any) up to the 350 byte boundary are reserved and MUST be initialized to zero by the 351 sender and ignored by the receiver. 353 3.4. Table of attributes 355 The following table provides a guide to which attributes may be found 356 in which kinds of packets, and in what quantity. 358 Request Accept Reject Challenge Accounting # Attribute 359 Request 360 0+ 0+ 0 0 0+ TBA1 IPv6-FramedAddress 361 0+ 0+ 0 0 0+ TBA2 IPv6-DNS-Server-Address 362 0 0+ 0 0 0+ TBA3 IPv6-Route-Information 364 4. Diameter Considerations 366 Since the Attributes defined in this document are allocated from the 367 standard RADIUS type space (see Section 6), no special handling is 368 required by Diameter entities. 370 5. Security Considerations 372 This document describes the use of RADIUS for the purposes of 373 authentication, authorization and accounting in IPv6-enabled 374 networks. In such networks, the RADIUS protocol may run either over 375 IPv4 or over IPv6. Known security vulnerabilities of the RADIUS 376 protocol apply to the attributes defined in this document. Since 377 IPSEC is natively defined for IPv6, it is expected that running 378 RADIUS implementations supporting IPv6 may want to run over IPSEC. 379 Where RADIUS is run over IPSEC and where certificates are used for 380 authentication, it may be desirable to avoid management of RADIUS 381 shared secrets, so as to leverage the improved scalability of public 382 key infrastructure. 384 6. IANA Considerations 386 This document requires the assignment of three new RADIUS Attribute 387 Types in the "Radius Types" registry (currently located at 388 http://www.iana.org/assignments/radius-types for the following 389 attributes: 391 o IPv6-Framed-Address 393 o IPv6-DNS-Server-Address 395 o IPv6-Route-Information 397 IANA should allocate these numbers from the standard RADIUS 398 Attributes space using the "IETF Review" policy [RFC5226]. 400 7. Acknowledgements 402 The authors would like to thank Alfred Hines for his contributions 403 and comments to this document. 405 8. References 407 8.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 413 Address Autoconfiguration", RFC 4862, September 2007. 415 8.2. Informative References 417 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 418 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 419 Support", RFC 2868, June 2000. 421 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 422 RFC 3162, August 2001. 424 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 425 and M. Carney, "Dynamic Host Configuration Protocol for 426 IPv6 (DHCPv6)", RFC 3315, July 2003. 428 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 429 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 430 December 2003. 432 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 433 More-Specific Routes", RFC 4191, November 2005. 435 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 436 Attribute", RFC 4818, April 2007. 438 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 439 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 440 September 2007. 442 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 443 "IPv6 Router Advertisement Option for DNS Configuration", 444 RFC 5006, September 2007. 446 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 447 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 448 May 2008. 450 Authors' Addresses 452 Benoit Lourdelet 453 Cisco Systems, Inc. 454 Village ent. GreenSide, Bat T3, 455 400, Av de Roumanille, 456 06410 BIOT - Sophia-Antipolis Cedex 457 France 459 Phone: +33 4 97 23 26 23 460 Email: blourdel@cisco.com 461 Wojciech Dec (editor) 462 Cisco Systems, Inc. 463 Haarlerbergweg 13-19 464 Amsterdam , NOORD-HOLLAND 1101 CH 465 Netherlands 467 Email: wdec@cisco.com 469 Behcet Sarikaya 470 Huawei USA 471 1700 Alma Dr. Suite 500 472 Plano, TX 473 US 475 Phone: +1 972-509-5599 476 Email: sarikaya@ieee.org 478 Glen Zorn 479 Network Zen 480 1310 East Thomas Street 481 Seattle, WA 482 US 484 Email: gwz@net-zen.net 486 David Miles 487 Alcatel-Lucent 488 L3 / 215 Spring St 489 Melbourne, Victoria 3000, 490 Australia 492 Phone: 493 Fax: 494 Email: David.Miles@alcatel-lucent.com 495 URI: