idnits 2.17.1 draft-ietf-radext-ipv6-access-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (April 29, 2010) is 5108 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) -- 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: 0 errors (**), 0 flaws (~~), 2 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: October 31, 2010 B. Sarikaya 6 Huawei USA 7 G. Zorn 8 Network Zen 9 D. Miles 10 Alcatel-Lucent 11 April 29, 2010 13 RADIUS attributes for IPv6 Access Networks 14 draft-ietf-radext-ipv6-access-01.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 (RAs) and their application in broadband network 22 access. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 31, 2010. 47 Copyright Notice 48 Copyright (c) 2010 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 Simplified 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 77 2.1. IPv6 Address Assignment . . . . . . . . . . . . . . . . . 5 78 2.2. Recursive DNS Servers . . . . . . . . . . . . . . . . . . 5 79 2.3. IPv6 Route Information . . . . . . . . . . . . . . . . . . 6 80 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.1. Framed-IPv6-Address . . . . . . . . . . . . . . . . . . . 6 82 3.2. DNS-Server-IPv6-Address . . . . . . . . . . . . . . . . . 7 83 3.3. Route-IPv6-Information . . . . . . . . . . . . . . . . . . 8 84 3.4. Table of attributes . . . . . . . . . . . . . . . . . . . 9 85 3.5. RFC3162 Attribute coexistance . . . . . . . . . . . . . . 9 86 4. Diameter Considerations . . . . . . . . . . . . . . . . . . . 10 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 95 1. Introduction 97 This document specifies new IPv6 RADIUS attributes used to support 98 AAA functions of an IPv6 network access. The IPv6 RADIUS attributes 99 already defined in [RFC3162] and [RFC4818] do not define methods for 100 assignment of IPv6 addresses to hosts (via DHCPv6) or IPv6 recursive 101 DNS servers (via DHCPv6 or [RFC5006]), nor the passing of route 102 prefix info (via [RFC4191]. Such Radius attributes are the subject 103 of this draft. 105 2. Deployment Scenarios 107 A common fixed line broadband network scenario is illustrated in 108 Figure 1, and is composed of a IP Routing Residential Gateway (RG) 109 hosts, a Layer 2 Access-Node (e.g. a DSLAM), one or more Broadband 110 Network Gateways (BNG) that are the effectively IP Network Access 111 Servers (NASes), and an AAA server. The RG host is expected to have 112 direct connectivity at Layer 2 to both BNGs, with one of the devices 113 typically being intended for providing access to a specific operator 114 service (e.g. IP TV) that can be characterized by a known IP subnet. 116 +-----+ 117 (Radius) | AAA | 118 ...........>| | 119 . +--+--+ 120 v ^ 121 +---+---+ . 122 | BNG | .(Radius) 123 | | . 124 +---+---+ v 125 +------+ | +---+---+ 126 +------+ | AN | | | BNG | 127 | RG +-------| +-----------+----------+ | 128 +------+ (DSL) +------+ (Ethernet) +-------+ 130 Figure 1 132 In illustrated deployment scenario the BNGs are assumed to embed a 133 DHCPv6 server function that allows them to locally handle any DHCPv6 134 requests issued by RG hosts. This scenario is particularly useful in 135 illustrating the possible interaction between RADIUS and DHCPv6, 136 however the options defined in this document are not restricted to be 137 used only in the presence of such embedded functionality. 139 The BNGs interface to the AAA server by means of the RADIUS protocol. 140 The AAA server is expected to authenticate each RG that typically 141 connects by means of PPPoE and to return to the BNG per host 142 authorization and network configuration information which, among 143 other information, can comprise of: One or more IP addresses 144 Recursive DNS servers intended to be used by the host; specific IP 145 routes corresponding to service subnets that are then expected to 146 assist the RG in selecting the appropriate BNG; an explicit IP 147 address that is to be state fully assigned to a given RG host. The 148 method by which the BNG can communicate this information to each host 149 is explained in each of the following sub-sections. 151 2.1. IPv6 Address Assignment 153 DHCPv6 [RFC3315] provides a mechanism to assign one or more or non- 154 temporary IPv6 addresses to nodes. In IPv6, both SLAAC and DHCPv6 155 can be used for address assignment. While SLAAC provides a host with 156 a /64 IPv6 prefix from which to construct its address, the host is 157 free to construct a 64-bit Interface ID that when concatenated with 158 the /64 prefix provides a unique address. By providing a host only a 159 /64 network operators are unaware of the exact IP addresses in use by 160 a device. To contrast SLAAC, DHCPv6 requires a host explicitly 161 request non-temporary addresses from a DHCPv6 server permitting an 162 operator control over address assignment. This document specifies a 163 new RADIUS attribute for the assignment of non-temporary IPv6 164 addresses to a host via DHCPv6. Other DHCPv6 parameters such as 165 preferred and valid address lifetimes are provided for by the NAS and 166 not through RADIUS attributes. As a DHCPv6 client may request an 167 address at any time, a RADIUS server may be required to service 168 additional RADIUS Access-Requests for a single network access 169 session. 171 2.2. Recursive DNS Servers 173 DHCPv6 provides an option for recursive DNS servers to hosts, as does 174 a Router Advertisement supporting the experimental [RFC5006]. 175 Existing DHCPv4 options only convey DNS as 32-bit IPv4 addresses and 176 cannot support a 128-bit IPv6 address. In the current RADIUS 177 specifications there are no IETF/IANA defined attributes for 178 recursive DNS and many NAS implement vendor specific attributes 179 (e.g.: Ascend-Primary-DNS). In some operator environments a network 180 access session may be configured with a specific set of one or more 181 recursive DNS. This document specifies a new RADIUS attribute to 182 convey a list of IPv6 addresses that can be used for a host for 183 domain name service. Best current practice is to configure hosts 184 with more than one recursive domain name server, this is achieved in 185 the RADIUS environment by returning multiple DNS-Server-IPv6-Address 186 options within an Access-Accept. The NAS shall use the addresses 187 returned in the RADIUS DNS-Server-IPv6-Address attribute for the 188 DHCPv6 DNS-Servers option [RFC3646], the Router Advertisement 189 Recursive DNS Server Option [RFC5006], or both. 191 2.3. IPv6 Route Information 193 In scenarios where Stateless Address Autoconfiguration (SLAAC) 194 [RFC4862] is used for address assignment, a Router Advertisement is 195 multicast with one or more Prefix Information Options with the 196 autonomous-bit set to true. A Prefix Information Option, when used 197 for SLAAC, is a /64 prefix to which a host appends its locally- 198 generated Interface Id to create a unique 128-bit IPv6 address. 199 [RFC3162] currently defines a Framed-IPv6-Prefix which can be used by 200 a NAS to advertise on-link prefixes in a Router Advertisement Prefix 201 Information Option [RFC4861]. The IPv6 Route Information attribute 202 is almost the inverse; it is intended to be used to instruct a host 203 connected to the NAS that a specific route is reachable via the NAS/ 204 router. [RFC4191] defines an ICMPv6 Route Information Option for 205 this purpose, i.e. to convey route information from a router to a 206 host. The Route Information Option is used in environments where 207 multiple advertising routers are present. It directs a host to which 208 router each specific route should be the next-hop to. For each IPv6- 209 Prefix-Information attribute, the NAS may advertise a unique 210 [RFC4191] Route Information Option. 212 3. Attributes 214 The fields shown in the diagrams below are transmitted from left to 215 right. 217 3.1. Framed-IPv6-Address 219 This Attribute indicates an IPv6 Address that is assigned to the 220 uplink NAS-facing interface of the user equipment. It MAY be used in 221 Access-Accept packets, and can appear multiple times. It MAY be used 222 in an Access-Request packet as a hint by the NAS to the server that 223 it would prefer these IPv6 address(es), but the server is not 224 required to honor the hint. Since it is assumed that the NAS, when 225 necessary, will add a route corresponding to the address it is not 226 necessary for the server to also send a host Framed-IPv6-Route 227 attribute for the same address. 229 This Attribute can be used by DHCPv6 to offer a unique IPv6 address 230 or can be used for a-posteriori validation or announcement of an 231 autoconfigured address. 233 A summary of the Framed-IPv6-Address Attribute format is shown below. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type | Length | Address 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Address (cont) 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Address (cont) 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Address (cont) 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Address (cont.) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Type 251 TBA1 for Framed-IPv6-Address 253 Length 255 18 257 Address 259 The Address field contains a 128-bit IPv6 address. 261 3.2. DNS-Server-IPv6-Address 263 The DNS-Server-IPv6-Address Attribute contains the IPv6 address of a 264 DNS server. This attribute MAY be included multiple times in Access- 265 Accept packets. 267 The content of this attribute can be inserted in a Router 268 Advertisement as specified in [RFC5006] or mapped to the matching 269 DHCPv6 option. 271 A summary of the DNS-Server-IPv6-Address Attribute format is given 272 below. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type | Length | Address 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Address (cont) 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Address (cont) 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Address (cont) 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Address (cont.) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Type 290 TBA2 for DNS-Server-IPv6-Address 292 Length 294 18 296 Address 298 The 128-bit IPv6 address of a DNS server. 300 3.3. Route-IPv6-Information 302 This Attribute specifies a prefix (and corresponding route) to be 303 authorized for announcement towards the user by the NAS, with the 304 reachable by means of routing towards the NAS. It is used in the 305 Access-Accept packet and can appear multiple times. It may also be 306 used in the Access-Request packet. 308 A summary of the Route-IPv6-Information attribute format is shown 309 below. The route information option defined in [RFC4191] is captured 310 in this and following two attributes. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | Reserved | Prefix-Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 . Prefix (variable) . 319 . . 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Type 325 TBA3 for Route-IPv6-Information 327 Length 329 Length in bytes. At least 4 and no larger than 20; typically 12 330 or less. 332 Prefix Length 334 The length of the prefix, in bits; at least 0 and no more than 335 128; typically 64 or less. 337 Prefix 339 Variable-length field containing an IP prefix. The Prefix Length 340 field contains the number of valid leading bits in the prefix. 341 The bits in the prefix after the prefix length (if any) up to the 342 byte boundary are reserved and MUST be initialized to zero by the 343 sender and ignored by the receiver. 345 3.4. Table of attributes 347 The following table provides a guide to which attributes may be found 348 in which kinds of packets, and in what quantity. 350 Request Accept Reject Challenge Accounting # Attribute 351 Request 352 0+ 0+ 0 0 0+ TBA1 Framed-IPv6-Address 353 0+ 0+ 0 0 0+ TBA2 DNS-Server-IPv6-Address 354 0 0+ 0 0 0+ TBA3 Route-IPv6-Information 356 3.5. RFC3162 Attribute coexistance 358 Syntactically, the Framed-IPv6-Address and the [RFC3162] Framed-IPv6- 359 Prefix attributes are identical. In terms of their intended 360 semantics, however as described by this draft the former represents a 361 statefully assigned IPv6 address while the latter a prefix intended 362 for application on a target NAS interface. These attributes are 363 envisaged to co-exist in Radius messages and thus it is recommended 364 that each attribute be used for its intended semantical purpose only. 365 A functional substitution of one attribute for the other may however 366 be an optional configuration feature of a Radius client and server. 368 4. Diameter Considerations 370 Since the Attributes defined in this document are allocated from the 371 standard RADIUS type space (see Section 6), no special handling is 372 required by Diameter entities. 374 5. Security Considerations 376 This document describes the use of RADIUS for the purposes of 377 authentication, authorization and accounting in IPv6-enabled 378 networks. In such networks, the RADIUS protocol may run either over 379 IPv4 or over IPv6. Known security vulnerabilities of the RADIUS 380 protocol apply to the attributes defined in this document. Since 381 IPSEC is natively defined for IPv6, it is expected that running 382 RADIUS implementations supporting IPv6 may want to run over IPSEC. 383 Where RADIUS is run over IPSEC and where certificates are used for 384 authentication, it may be desirable to avoid management of RADIUS 385 shared secrets, so as to leverage the improved scalability of public 386 key infrastructure. 388 6. IANA Considerations 390 This document requires the assignment of three new RADIUS Attribute 391 Types in the "Radius Types" registry (currently located at 392 http://www.iana.org/assignments/radius-types for the following 393 attributes: 395 o Framed-IPv6-Address 397 o DNS-Server-IPv6-Address 399 o Route-IPv6-Information 401 IANA should allocate these numbers from the standard RADIUS 402 Attributes space using the "IETF Review" policy [RFC5226]. 404 7. Acknowledgements 406 The authors would like to thank Alfred Hines, Alan DeKok and Peter 407 Deacon for their help in reviewing this document. 409 8. References 410 8.1. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, March 1997. 415 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 416 Address Autoconfiguration", RFC 4862, September 2007. 418 8.2. Informative References 420 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 421 RFC 3162, August 2001. 423 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 424 and M. Carney, "Dynamic Host Configuration Protocol for 425 IPv6 (DHCPv6)", RFC 3315, July 2003. 427 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 428 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 429 December 2003. 431 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 432 More-Specific Routes", RFC 4191, November 2005. 434 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 435 Attribute", RFC 4818, April 2007. 437 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 438 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 439 September 2007. 441 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 442 "IPv6 Router Advertisement Option for DNS Configuration", 443 RFC 5006, September 2007. 445 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 446 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 447 May 2008. 449 Authors' Addresses 451 Benoit Lourdelet 452 Cisco Systems, Inc. 453 Village ent. GreenSide, Bat T3, 454 400, Av de Roumanille, 455 06410 BIOT - Sophia-Antipolis Cedex 456 France 458 Phone: +33 4 97 23 26 23 459 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 485 David Miles 486 Alcatel-Lucent 487 L3 / 215 Spring St 488 Melbourne, Victoria 3000, 489 Australia 491 Phone: 492 Fax: 493 Email: David.Miles@alcatel-lucent.com 494 URI: