idnits 2.17.1 draft-yeh-radext-ext-dual-stack-access-00.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 == Line 309 has weird spacing: '... uest ept ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 9, 2012) is 4302 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) == Missing Reference: 'RFC6158' is mentioned on line 203, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Downref: Normative reference to an Informational RFC: RFC 2869 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Radext Working Group L. Yeh 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track July 9, 2012 5 Expires: January 10, 2013 7 RADIUS Extension for Dual Stack Access 8 draft-yeh-radext-ext-dual-stack-access-00 10 Abstract 12 This document specifies the additional RADIUS attribute for IPv4 and 13 IPv6 dual stack access, which are used in the AAA processes for NAS 14 to employ the right mechanism and to allocate the proper 15 configuration or resources for the users. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 10, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and Conventions . . . . . . . . . . . . . . . . . . 4 53 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 54 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Access-Type . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . . 8 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 59 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 Subscriber IP sessions can be either IPv4/IPv6 dual-stack, IPv6-only, 68 or the legacy IPv4-only in the typical PPPoE based [BBF TR-187] or 69 IPoE based [BBF TR-177] deployment scenarios. The user in these IP 70 sessions can be a host or a Customer Edge router (CE router, routed 71 Residential Gateway, routed-RG, Customer Premise Equipment or routed- 72 CPE). In the IPv6 part of these session, the broadband Network 73 Access Server (NAS) acting as the Provider Edge router (PE router) 74 and RADIUS client simultaneously, usually employ DHCPv6-PD 75 [RFC3633][RFC4818] to delegate IPv6 prefix to CE router for its 76 customer network. In the meantime, the WAN (NAS-facing) interface of 77 CE router can be numbered or unnumbered (Section 2.3 of [BBF 78 TR-177]). The NAS can employ SLAAC [RFC4862] to assign a IPv6 prefix 79 or employ DHCPv6 [RFC3315] to assign a IPv6 address to the CE router 80 for its WAN interface. Therefore, there are at least the following 81 access types of user that the NAS and the centralized AAA server are 82 served for: 84 PPPoE-IPv4-only-host or CE 86 PPPoE-IPv6-only-host (Numbered by SLAAC) 87 PPPoE-IPv6-only-host (Numbered by DHCPv6) 88 PPPoE-IPv6-only-CE (Unnumbered) 89 PPPoE-IPv6-only-CE (Numbered by SLAAC) 90 PPPoE-IPv6-only-CE (Numbered by DHCPv6) 92 PPPoE-dual-stack-host (IPv6-Numbered by SLAAC) 93 PPPoE-dual-stack-host (IPv6-Numbered by DHCPv6) 94 PPPoE-dual-stack-CE (IPv6-Unnumbered) 95 PPPoE-dual-stack-CE (IPv6-Numbered by SLAAC) 96 PPPoE-dual-stack-CE (IPv6-Numbered by DHCPv6) 98 IPoE-IPv4-only-host or CE 100 IPoE-IPv6-only-host (Numbered by SLAAC) 101 IPoE-IPv6-only-host (Numbered by DHCPv6) 102 IPoE-IPv6-only-CE (Unnumbered) 103 IPoE-IPv6-only-CE (Numbered by SLAAC) 104 IPoE-IPv6-only-CE (Numbered by DHCPv6) 106 IPoE-dual-stack-host (IPv6-Numbered by SLAAC) 107 IPoE-dual-stack-host (IPv6-Numbered by DHCPv6) 108 IPoE-dual-stack-CE (IPv6-Unnumbered) 109 IPoE-dual-stack-CE (IPv6-Numbered by SLAAC) 110 IPoE-dual-stack-CE (IPv6-Numbered by DHCPv6) 112 The different access type of users need the NAS (Broadband Network 113 Gateway or BNG) employ different mechanism and allocate different 114 resource for the associated processes. The addresses assigned and 115 the prefixes delegated to the customer hosts or CE can be explicitly 116 got from the AAA server through attributes in the Access-Accept 117 packets ([RFC2865], [RFC3162] and [RFC4818]), or be dynamically get 118 from the local address or prefix pool configured on the NAS 119 ([RFC2869], [RFC3162] and [ietf-radext-ipv6-access-09]). When the 120 NAS dynamically assign address or delegate prefix to the customer 121 hosts or CE from the pools, it can use the default or preconfigured 122 pools on the NAS or alternatively use the indicated pools in the 123 attributes of the Access-Accept. 125 This document defines the additional RADIUS attributes to specify the 126 access type of users for the simplified and proper authorization and 127 accounting in RADIUS processes. 129 2. Terminology and Conventions 131 This document describes the additional RADIUS attribute and the 132 associated usage on NAS and AAA server. This document should be read 133 in conjunction with the relevant RADIUS specifications, including 134 [RFC2865], [RFC2866], [RFC2869], [RFC3162] and [RFC4818] for a 135 complete mechanism. Definitions for terms and acronyms not 136 specifically defined in this document are defined in RFC2865, 137 RFC2866, RFC2869, RFC3162 and RFC4818. 139 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 140 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 141 document, are to be interpreted as described in BCP 14, [RFC2119]. 143 3. Deployment Scenarios 145 +----------+ +----------+ +----------+ 146 | Host | PPPoE | | RADIUS | AAA | 147 | or | -------------- | NAS | -------------- | Server | 148 |CE router | IPoE | | Access-Type | | 149 +----------+ +----------+ +----------+ 150 Dual-Stack Local Address Pool 151 IPv6-only Local Prefix Pool 153 Figure 1: Deployment Scenario for various access types of the users 155 In the above depicted scenario, the NAS acting as PE router may 156 configure local address or prefix pools, use the mechanism of PPPoE 157 NCP, IPv6 SLAAC or DHCPv6 protocols to handle IPv4 address, IPv6 158 address and IPv6 prefix assignment to hosts or CEs. The AAA server 159 authenticates each host or CE, and returns the attributes used for 160 authorization and accounting. 162 The attribute of Access-Type can be used to indicate the right 163 configuration on the NAS for the users, or to report the right access 164 type of the users to the accounting server. When the attribute of 165 Access-Type is included, the address and prefix pools of the default 166 configuration on the NAS are not always necessary to be indicated in 167 the Access-Accept packet for the users' authorization. 169 4. Attributes 171 The fields shown in the diagrams below are transmitted from left to 172 right. 174 4.1. Access-Type 176 Description 178 The attribute indicates the access type of the user requested in 179 the Access-Request packet, authorized in the Access-Accept packet 180 or recorded in the Accounting-Request packet. 182 The format of the Access-Type is: 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type | Length | Value | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Value (cont.) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Type 194 TBA1 (by IANA) 196 Length 198 6 200 Value 202 Enumerated Data Type in 4-Octet unsigned integer defined in 203 [RFC6158]. The beginning 3 Octets are reserved for future use, 204 and are set to 0x00 now. The decimal value of the last octet is 205 defined as follows: 207 When PPPoE is used for the access method, the Access-Type of the 208 user get the following 'Value': 210 1 PPPoE-IPv4-only-host (or CE) 211 2 PPPoE-IPv6-only-host (Numbered by SLAAC) 212 3 PPPoE-IPv6-only-host (Numbered by DHCPv6) 213 4 PPPoE-IPv6-only-CE (Unnumbered) 214 5 PPPoE-IPv6-only-CE (Numbered by SLAAC) 215 6 PPPoE-IPv6-only-CE (Numbered by DHCPv6) 216 7 PPPoE-dual-stack-host (IPv6-Numbered by SLAAC) 217 8 PPPoE-dual-stack-host (IPv6-Numbered by DHCPv6) 218 9 PPPoE-dual-stack-CE (IPv6-Unnumbered) 219 10 PPPoE-dual-stack-CE (IPv6-Numbered by SLAAC) 220 11 PPPoE-dual-stack-CE (IPv6-Numbered by DHCPv6) 222 When IPoE is used for the access method, the Access-Type of user 223 gets the following 'Value': 225 12 IPoE-IPv4-only-host (or CE) 226 13 IPoE-IPv6-only-host (Numbered by SLAAC) 227 14 IPoE-IPv6-only-host (Numbered by DHCPv6) 228 15 IPoE-IPv6-only-CE (Unnumbered) 229 16 IPoE-IPv6-only-CE (Numbered by SLAAC) 230 17 IPoE-IPv6-only-CE (Numbered by DHCPv6) 231 18 IPoE-dual-stack-host (IPv6-Numbered by SLAAC) 232 19 IPoE-dual-stack-host (IPv6-Numbered by DHCPv6) 233 20 IPoE-dual-stack-CE (IPv6-Unnumbered) 234 21 IPoE-dual-stack-CE (IPv6-Numbered by SLAAC) 235 22 IPoE-dual-stack-CE (IPv6-Numbered by DHCPv6) 237 o For the user access type of IPv4-only host (or CE), NAS needs to 238 report Access-Type and Framed-IP-Address (8) in the accounting- 239 request packets for the assigned IPv4 address; 241 o For the user access type of IPv6-only host (Numbered by SLAAC), 242 NAS needs to report Access-Type and Framed-IPv6-Prefix (97) in the 243 accounting-request packets; 245 o For the user access type of IPv6-only host (Numbered by DHCPv6), 246 NAS needs to report Access-Type and Framed-IPv6-address in the 247 accounting-request packets; 249 o For the user access type of IPv6-only CE (Unnumbered), NAS needs 250 to report Access-Type and Delegated-IPv6-Prefix (123) in the 251 accounting-request packets; 253 o For the user access type of IPv6-only CE (Numbered by SLAAC), NAS 254 needs to report Access-Type, Framed-IPv6-Prefix (97) and 255 Delegated-IPv6-Prefix (123) in the accounting-request packets; 257 o For the user access type of IPv6-only CE (Numbered by DHCPv6), NAS 258 needs to report Access-Type, Framed-IPv6-address and Delegated- 259 IPv6-Prefix (123) in the accounting-request packets; 261 o For the user access type of dual-stack host (IPv6-Numbered by 262 SLAAC), NAS needs to report Access-Type, Framed-IP-Address (8) and 263 Framed-IPv6-Prefix (97) in the accounting-request packets; 265 o For the user access type of dual-stack host (IPv6-Numbered by 266 DHCPv6), NAS needs to report Access-Type, Framed-IP-Address (8) 267 and Framed-IPv6-address in the accounting-request packets; 269 o For the user access type of dual-stack CE (IPv6-Unnumbered), NAS 270 needs to report Access-Type, Framed-IP-Address (8) and Delegated- 271 IPv6-Prefix (123) in the accounting-request packets; 273 o For the user access type of dual-Stack CE (IPv6-Numbered by 274 SLAAC), NAS needs to report Access-Type, Framed-IP-Address (8), 275 Framed-IPv6-Prefix (97) and Delegated-IPv6-Prefix (123) in the 276 accounting-request packets; 278 o For the user access type of dual-Stack CE (IPv6-Numbered by 279 DHCPv6), NAS needs to report Access-Type, Framed-IP-Address (8), 280 Framed-IPv6-address and Delegated-IPv6-Prefix (123) in the 281 accounting-request packets. 283 Discussion: 285 The alternative attribute design could separate the access type of 286 the users into several dimensions. 288 Access-Method: Enumerated Data Type 289 0 for PPPoE; 1 for IPoE 290 Stack-Type: Enumerated Data Type 291 0 for dual stack; 1 for IPv4-only; 2 for IPv6-only 292 Node-Type: Enumerated Data Type 293 0 for host; 1 for CE 294 WAN-Interface-Numbering-Type: Enumerated Data Type 295 0 for Unnumbered; 1 for numbered 296 WAN-Interface-Address-Assignment-Type: Enumerated Data Type 297 0 for SLAAC; 1 for DHCPv6 299 Though the combination of the attributes sounds clearer in the 300 semantics, and not all of attributes defined are needed for every 301 user, but it still looks too complicated in some use cases. 303 5. Table of Attributes 305 The following table provides a guide to which attributes may be found 306 in which kinds of packets, and in what quantity. 308 Req- Acc- Rej- Chall Accounting # Attribute 309 uest ept ect -enge Request 310 0-1 0-1 0 0 0-1 TBA1 Access-Type 312 The meaning of the above table entries is as follows: 314 0 This attribute MUST NOT be present. 315 0+ Zero or more instances of this attribute MAY be present. 316 0-1 Zero or one instance of this attribute MAY be present. 317 1 Exactly one instance of this attribute MUST be present. 318 1+ One or more of these attributes MUST be present. 320 6. Security Considerations 322 Security issues related RADIUS are described in section 8 of RFC2865 323 and section 5 of RFC3162. 325 7. IANA Considerations 327 The authors of this document request to assign new Radius type code 328 for Access-Type. IANA should allocate the new code from the standard 329 RADIUS Attributes space using the "IETF Review" policy [RFC5226]. 331 8. Acknowledgements 333 Thanks to David B. Nelson for his valuable comments in the mailing 334 list of Radext. 336 9. References 338 9.1. Normative References 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 344 "Remote Authentication Dial In User Service (RADIUS)", 345 RFC 2865, June 2000. 347 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 349 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 350 Extensions", RFC 2869, June 2000. 352 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 353 RFC 3162, August 2001. 355 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 356 and M. Carney, "Dynamic Host Configuration Protocol for 357 IPv6 (DHCPv6)", RFC 3315, July 2003. 359 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 360 Host Configuration Protocol (DHCP) version 6", RFC 3633, 361 December 2003. 363 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 364 Attribute", RFC 4818, April 2007. 366 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 367 Address Autoconfiguration", RFC 4862, September 2007. 369 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 370 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 371 May 2008. 373 9.2. Informative References 375 [BBF TR-177] 376 Broadband Forum, "IPv6 in the context of TR-101, Issue 1", 377 November 2010. 379 [BBF TR-187] 380 Broadband Forum, "IPv6 for PPP Broadband Access, Issue 1", 381 May 2010. 383 [ietf-radext-ipv6-access-09] 384 Lourdelet, B., Dec, W., Sarikaya, B., Zorn, G., and D. 385 Miles, "RADIUS attributes for IPv6 Access Networks", 386 January 2011. 388 Author's Address 390 Leaf Y. Yeh 391 Huawei Technologies 392 Shenzhen 393 P.R.China 395 Email: leaf.y.yeh@huawei.com