idnits 2.17.1 draft-hu-softwire-multicast-radius-ext-08.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 27 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 3, 2015) is 3243 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) == Outdated reference: A later version (-18) exists of draft-ietf-softwire-dslite-multicast-09 == Outdated reference: A later version (-15) exists of draft-ietf-softwire-multicast-prefix-option-08 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 5176 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG Q. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track W. Meng 5 Expires: December 5, 2015 C. Wang 6 ZTE Corporation 7 M. Boucadair 8 France Telecom 9 June 3, 2015 11 RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixes 12 draft-hu-softwire-multicast-radius-ext-08 14 Abstract 16 This document specifies a new Remote Authentication Dial-In User 17 Service (RADIUS) attribute to carry the Multicast-Prefixes-64 18 information, aiming to delivery the Multicast and Unicast IPv6 19 Prefixes to be used to build multicast and unicast IPv4-Embedded IPv6 20 addresses. this RADIUS attribute is defined based on the equivalent 21 DHCPv6 OPTION_v6_PREFIX64 option. 23 Status of this Memo 25 This Internet-Draft is submitted 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on December 5, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 59 3. Multicast-Prefixes-64 Configuration with RADIUS and DHCPv6 . . 5 60 4. RADIUS Attribute . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1. Multicast-Prefixes-64 . . . . . . . . . . . . . . . . . . 8 62 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 11 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 66 9. Normative References . . . . . . . . . . . . . . . . . . . . . 15 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 69 1. Introduction 71 The solution specified in [I-D.ietf-softwire-dslite-multicast] relies 72 on stateless functions to graft part of the IPv6 multicast 73 distribution tree and IPv4 multicast distribution tree, also uses 74 IPv4-in-IPv6 encapsulation scheme to deliver IPv4 multicast traffic 75 over an IPv6 multicast-enabled network to IPv4 receivers. 77 To inform the mB4 element of the PREFIX64,a PREFIX64 option may be 78 used. [I-D.ietf-softwire-multicast-prefix-option] defines a DHCPv6 79 PREFIX64 option to convey the IPv6 prefixes to be used for 80 constructing IPv4-embedded IPv6 addresses. 82 In broadband environments, a customer profile may be managed by 83 Authentication, Authorization, and Accounting (AAA) servers, together 84 with AAA for users. The Remote Authentication Dial-In User Service 85 (RADIUS) protocol [RFC2865] is usually used by AAA servers to 86 communicate with network elements. Since the Multicast-Prefixes-64 87 information can be stored in AAA servers and the client configuration 88 is mainly provided through DHCP running between the NAS and the 89 requesting clients, a new RADIUS attribute is needed to send 90 Multicast-Prefixes-64 information from the AAA server to the NAS. 92 This document defines a new RADIUS attribute to be used for carrying 93 the Multicast-Prefixes-64, based on the equivalent DHCPv6 option 94 already specified in [I-D.ietf-softwire-multicast-prefix-option]. 96 This document makes use of the same terminology defined in 97 [I-D.ietf-softwire-dslite-multicast]. 99 This attribute can be in particular used in the context of DS-Lite 100 Mulitcast, MAP-E Multicast and other IPv4-IPv6 Multicast techniques. 101 However it is not limited to DS-Lite Multicast. 103 DS-Lite unicast RADIUS extentions are defined in [RFC6519] . 105 2. Convention and Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 The terms DS-Lite multicast Basic Bridging BroadBand element (mB4) 112 and the DS-Lite multicast Address Family Transition Router element 113 (mAFTR) are defined in [I-D.ietf-softwire-dslite-multicast] 115 3. Multicast-Prefixes-64 Configuration with RADIUS and DHCPv6 117 Figure 1 illustrates in DS-Lite scenario how the RADIUS protocol and 118 DHCPv6 work together to accomplish Multicast-Prefixes-64 119 configuration on the mB4 element for multicast service when an IP 120 session is used to provide connectivity to the user. 122 mB4 NAS AAA 123 | | Server 124 |------ DHCPv6 Solicit ---------> | | 125 | | | 126 | |----Access-Request ---->| 127 | | | 128 | |<---Access-Accept-------| 129 | |(Multicast-Prefixes-64) | 130 | | | 131 |<------- DHCPv6 Advertise ------| | 132 | (DHCPv6 OPTION_V6_PREFIX64 ) | | 133 | | | 134 |------- DHCPv6 Request -------->| | 135 | | | 136 | | | 137 |<----- DHCPv6 Reply ------------- | | 138 | (DHCPv6 OPTION_V6_PREFIX64 ) | | 140 DHCPv6 RADIUS 142 Figure 1: RADIUS and DHCPv6 Message Flow for an IP Session 144 The NAS operates as a client of RADIUS and as a DHCP Server/Relay for 145 mB4. When the mB4 sends a DHCPv6 Solicit message to NAS(DHCP Server/ 146 Relay). The NAS sends a RADIUS Access-Request message to the RADIUS 147 server, requesting authentication. Once the RADIUS server receives 148 the request, it validates the sending client, and if the request is 149 approved, the AAA server replies with an Access-Accept message 150 including a list of attribute-value pairs that describe the 151 parameters to be used for this session. This list MAY contain the 152 Multicast-Prefixes-64 attribute (asm-length,ASM_PREFIX64,ssm-length, 153 SSM_PREFIX64,unicast-length,U_PREFIX64). Then, when the NAS receives 154 the DHCPv6 Request message containing the OPTION_V6_PREFIX64 option 155 in its Option Request option,the NAS SHALL use the prefixes returned 156 in the RADIUS Multicast-Prefixes-64 attribute to populate the DHCPv6 157 OPTION_V6_PREFIX64 option in the DHCPv6 reply message. 159 NAS MAY be configured to return the configured Multicast-Prefixes-64 160 by the AAA Server to any requesting client without relaying each 161 received request to the AAA Server. 163 Figure 2 describes another scenario, which accomplish DS-Lite 164 Multicast-Prefixes-64 configuration on the mB4 element for multicast 165 service when a PPP session is used to provide connectivity to the 166 user. Once the NAS obtains the Multicast-Prefixes-64 attribute from 167 the AAA server through the RADIUS protocol, the NAS MUST store the 168 received Multicast-Prefixes-64 locally. When a user is online and 169 sends a DHCPv6 Request message containing the OPTION_V6_PREFIX64 170 option in its Option Request option, the NAS retrieves the previously 171 stored Multicast-Prefixes-64 and uses it as OPTION_V6_PREFIX64 option 172 in DHCPv6 Reply message. 174 mB4 NAS AAA 175 | | Server 176 | | | 177 |----PPP LCP Config-Request------> | | 178 | | | 179 | |----Access-Request ---->| 180 | | | 181 | |<---- Access-Accept-----| 182 | | (Multicast-Prefixes-64)| 183 |<-----PPP LCP Config-ACK ------- | | 184 | | | 185 | | | 186 |--- PPP IPv6CP Config-Request --->| | 187 | | | 188 |<----- PPP IPv6CP Config-ACK -----| | 189 | | | 190 |------- DHCPv6 Solicit -------->| | 191 | | | 192 |<------- DHCPv6 Advertise -----| | 193 | (DHCPv6 OPTION_V6_PREFIX64 ) | | 194 | | | 195 |------- DHCPv6 Request -------->| | 196 | | | 197 | | | 198 |<-------- DHCPv6 Reply ---------- | | 199 | (DHCPv6 OPTION_V6_PREFIX64) | | 201 DHCPv6 RADIUS 203 Figure 2: RADIUS and DHCPv6 Message Flow for a PPP Session 205 According to [RFC3315], after receiving the Multicast-Prefixes-64 206 attribute in the initial Access-Accept packet, the NAS MUST store the 207 received V6_PREFIX64 locally. When the mB4 sends a DHCPv6 Renew 208 message to request an extension of the lifetimes for the assigned 209 address or prefix, the NAS does not have to initiate a new Access- 210 Request packet towards the AAA server to request the Multicast- 211 Prefixes-64. The NAS retrieves the previously stored Multicast- 212 Prefixes-64 and uses it in its reply. 214 Also, if the DHCPv6 server to which the DHCPv6 Renew message was sent 215 at time T1 has not responded, the DHCPv6 client initiates a Rebind/ 216 Reply message exchange with any available server. In this scenario, 217 the NAS receiving the DHCPv6 Rebind message MUST initiate a new 218 Access-Request message towards the AAA server. The NAS MAY include 219 the Multicast-Prefixes-64 attribute in its Access-Request message. 221 4. RADIUS Attribute 223 This section specifies the format of the new RADIUS attribute. 225 4.1. Multicast-Prefixes-64 227 The Multicast-Prefixes-64 attribute conveys the IPv6 prefixes to be 228 used in [I-D.ietf-softwire-dslite-multicast] to synthesize IPv4- 229 embedded IPv6 addresses. The NAS SHALL use the IPv6 prefixes 230 returned in the RADIUS Multicast-Prefixes-64 attribute to populate 231 the DHCPv6 PREFIX64 Option 232 [I-D.ietf-softwire-multicast-prefix-option] . 234 This attribute MAY be used in Access-Request packets as a hint to the 235 RADIUS server, for example, if the NAS is pre-configured with 236 Multicast-Prefixes-64, these prefixes MAY be inserted in the 237 attribute. The RADIUS server MAY ignore the hint sent by the NAS, 238 and it MAY assign a different Multicast-Prefixes-64 attribute. 240 If the NAS includes the Multicast-Prefixes-64 attribute, but the AAA 241 server does not recognize this attribute, this attribute MUST be 242 ignored by the AAA server. 244 NAS MAY be configured with both ASM_PREFIX64 and SSM_PREFIX64 or only 245 one of them. Concretely, AAA server MAY return ASM_PREFIX64 or 246 SSM_PREFIX64 based on the user profile and service policies. AAA MAY 247 return both ASM_PREFIX64 and SSM_PREFIX64. When SSM_PREFIX64 is 248 returned by the AAA server, U_PREFIX64 MUST also be returned by the 249 AAA server. 251 If the NAS does not receive the Multicast-Prefixes-64 attribute in 252 the Access-Accept message, it MAY fall back to a pre-configured 253 default Multicast-Prefixes-64, if any. If the NAS does not have any 254 pre-configured, the delivery of multicast traffic is not supported. 256 If the NAS is pre-provisioned with a default Multicast-Prefixes-64 257 and the Multicast-Prefixes-64 received in the Access-Accept message 258 are different from the configured default, then the Multicast- 259 Prefixes-64 attribute received in the Access-Accept message MUST be 260 used for the session. 262 A summary of the Multicast-Prefixes-64 RADIUS attribute format is 263 shown Figure 3. The fields are transmitted from left to right. 265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | asm-length | | 270 +-+-+-+-+-+-+-+-+ : 271 : ASM_PREFIX64 (variable) : 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | ssm-length | | 274 +-+-+-+-+-+-+-+-+ : 275 : SSM_PREFIX64 (variable) : 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | unicast-length| | 278 +-+-+-+-+-+-+-+-+ : 279 : U_PREFIX64 (variable) : 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 3: RADIUS attribute format for Multicast-Prefixes-64 284 Type: 286 145 for Multicast-Prefixes-64 288 Length: 290 This field indicates the total length in octets of this attribute 291 including the Type and Length fields, and the length in octets of all 292 PREFIX fields. 294 asm-length: 296 the prefix-length for the ASM IPv4-embedded prefix, as an 8-bit 297 unsigned integer (0 to 128). This field represents the number of 298 valid leading bits in the prefix. 300 ASM_PREFIX64: 302 this field identifies the IPv6 multicast prefix to be used to 303 synthesize the IPv4-embedded IPv6 addresses of the multicast groups 304 in the ASM mode. It is a variable size field with the length of the 305 field defined by the asm-length field and is rounded up to the 306 nearest octet boundary. In such case any additional padding bits 307 must be zeroed. The conveyed multicast IPv6 prefix MUST belong to 308 the ASM range. This prefix is likely to be a /96. 310 ssm-length: 312 the prefix-length for the SSM IPv4-embedded prefix, as an 8-bit 313 unsigned integer (0 to 128). This field represents the number of 314 valid leading bits in the prefix. 316 SSM_PREFIX64: 318 this field identifies the IPv6 multicast prefix to be used to 319 synthesize the IPv4-embedded IPv6 addresses of the multicast groups 320 in the SSM mode. It is a variable size field with the length of the 321 field defined by the ssm-length field and is rounded up to the 322 nearest octet boundary. In such case any additional padding bits 323 must be zeroed. The conveyed multicast IPv6 prefix MUST belong to 324 the SSM range. This prefix is likely to be a /96. 326 unicast-length: 328 the prefix-length for the IPv6 unicast prefix to be used to 329 synthesize the IPv4-embedded IPv6 addresses of the multicast sources, 330 as an 8-bit unsigned integer (0 to 128). This field represents the 331 number of valid leading bits in the prefix. 333 U_PREFIX64: 335 this field identifies the IPv6 unicast prefix to be used in SSM 336 mode for constructing the IPv4-embedded IPv6 addresses representing 337 the IPv4 multicast sources in the IPv6 domain. U_PREFIX64 may also 338 be used to extract the IPv4 address from the received multicast data 339 flows. It is a variable size field with the length of the field 340 defined by the unicast-length field and is rounded up to the nearest 341 octet boundary. In such case any additional padding bits must be 342 zeroed. The address mapping MUST follow the guidelines documented in 343 [RFC6052]. 345 5. Table of Attributes 347 The following tables provide a guide to which attributes may be found 348 in which kinds of packets, and in what quantity. 350 The following table defines the meaning of the above table entries. 352 Access- Access- Access- Challenge Accounting- # Attribute 353 Request Accept Reject Request 354 0-1 0-1 0 0 0-1 145 Multicast-Prefixes-64 356 CoA- CoA- CoA- # Attribute 357 Request ACK NACK 358 0-1 0 0 145 Multicast-Prefixes-64 360 0 This attribute MUST NOT be present in the packet. 361 0+ Zero or more instances of this attribute MAY be present in the 362 packet. 363 0-1 Zero or one instances of this attribute MAY be present in the 364 packet. 365 1 Exactly one instances of this attribute MAY be present in the 366 packet. 368 6. Security Considerations 370 This document has no additional security considerations beyond those 371 already identified in [RFC2865] for the RADIUS protocol and in 372 [RFC5176] for CoA messages. 374 The security considerations documented in [RFC3315] and [RFC6052] are 375 to be considered. 377 7. IANA Considerations 379 Per this document, IANA has allocated a new RADIUS attribute type 380 from the IANA registry "Radius Attribute Types" located at 381 http://www.iana.org/assignments/radius-types. 383 Multicast-Prefixes-64 - 145 385 8. Acknowledgments 387 The authors would like to thank Ian Farrer, Chongfen Xie, Qi Sun, 388 Linhui Sun and Hao Wang for their contributions to this work. 390 9. Normative References 392 [I-D.ietf-softwire-dslite-multicast] 393 Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. 394 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 395 over an IPv6 Multicast Network", 396 draft-ietf-softwire-dslite-multicast-09 (work in 397 progress), March 2015. 399 [I-D.ietf-softwire-multicast-prefix-option] 400 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 401 Option for IPv4-Embedded Multicast and Unicast IPv6 402 Prefixes", draft-ietf-softwire-multicast-prefix-option-08 403 (work in progress), March 2015. 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 409 "Remote Authentication Dial In User Service (RADIUS)", 410 RFC 2865, June 2000. 412 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 413 and M. Carney, "Dynamic Host Configuration Protocol for 414 IPv6 (DHCPv6)", RFC 3315, July 2003. 416 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 417 Aboba, "Dynamic Authorization Extensions to Remote 418 Authentication Dial In User Service (RADIUS)", RFC 5176, 419 January 2008. 421 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 422 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 423 October 2010. 425 [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 426 Stack Lite", RFC 6519, February 2012. 428 Authors' Addresses 430 Qian Wang 431 China Telecom 432 No.118, Xizhimennei 433 Beijing 100035 434 China 436 Email: wangqian@ctbri.com.cn 438 Wei Meng 439 ZTE Corporation 440 No.50 Software Avenue, Yuhuatai District 441 Nanjing 442 China 444 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com 446 Cui Wang 447 ZTE Corporation 448 No.50 Software Avenue, Yuhuatai District 449 Nanjing 450 China 452 Email: wang.cui1@zte.com.cn 454 Mohamed Boucadair 455 France Telecom 456 Rennes, 35000 457 France 459 Email: mohamed.boucadair@orange.com