Radext WG Q. WangInternet-Draft China TelecomIntended status: Standards Track W. MengExpires: June 4, 2016 C. Wang ZTE Corporation M. Boucadair France Telecom December 2, 2015RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixesdraft-wang-radext-multicast-radius-ext-00Abstract This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Multicast-Prefixes-64 information, aiming to delivery the Multicast and Unicast IPv6 Prefixes to be used to build multicast and unicast IPv4-Embedded IPv6 addresses. this RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_v6_PREFIX64 option.Status of this Memo This Internet-Draft is submitted in full conformance with the provisions ofBCP 78 andBCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is athttp://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 4, 2016.Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documentsWang, et al. Expires June 4, 2016 [Page 1]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 2015 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .32. Convention and Terminology . . . . . . . . . . . . . . . . . .43. Multicast-Prefixes-64 Configuration with RADIUS and DHCPv6 . .54. RADIUS Attribute . . . . . . . . . . . . . . . . . . . . . . .84.1. Multicast-Prefixes-64 . . . . . . . . . . . . . . . . . .85. Table of Attributes . . . . . . . . . . . . . . . . . . . . .116. Security Considerations . . . . . . . . . . . . . . . . . . .127. IANA Considerations . . . . . . . . . . . . . . . . . . . . .138. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .149. Normative References . . . . . . . . . . . . . . . . . . . . .15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .16Wang, et al. Expires June 4, 2016 [Page 2]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20151. Introduction The solution specified in [I-D.ietf-softwire-dslite-multicast] relies on stateless functions to graft part of the IPv6 multicast distribution tree and IPv4 multicast distribution tree, also uses IPv4-in-IPv6 encapsulation scheme to deliver IPv4 multicast traffic over an IPv6 multicast-enabled network to IPv4 receivers. To inform the mB4 element of the PREFIX64,a PREFIX64 option may be used. [I-D.ietf-softwire-multicast-prefix-option] defines a DHCPv6 PREFIX64 option to convey the IPv6 prefixes to be used for constructing IPv4-embedded IPv6 addresses. In broadband environments, a customer profile may be managed by Authentication, Authorization, and Accounting (AAA) servers, together with AAA for users. The Remote Authentication Dial-In User Service (RADIUS) protocol [RFC2865] is usually used by AAA servers to communicate with network elements. Since the Multicast-Prefixes-64 information can be stored in AAA servers and the client configuration is mainly provided through DHCP running between the NAS and the requesting clients, a new RADIUS attribute is needed to send Multicast-Prefixes-64 information from the AAA server to the NAS. This document defines a new RADIUS attribute to be used for carrying the Multicast-Prefixes-64, based on the equivalent DHCPv6 option already specified in [I-D.ietf-softwire-multicast-prefix-option]. This document makes use of the same terminology defined in [I-D.ietf-softwire-dslite-multicast]. This attribute can be in particular used in the context of DS-Lite Mulitcast, MAP-E Multicast and other IPv4-IPv6 Multicast techniques. However it is not limited to DS-Lite Multicast. DS-Lite unicast RADIUS extentions are defined in [RFC6519] .Wang, et al. Expires June 4, 2016 [Page 3]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20152. Convention and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms DS-Lite multicast Basic Bridging BroadBand element (mB4) and the DS-Lite multicast Address Family Transition Router element (mAFTR) are defined in [I-D.ietf-softwire-dslite-multicast]Wang, et al. Expires June 4, 2016 [Page 4]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20153. Multicast-Prefixes-64 Configuration with RADIUS and DHCPv6 Figure 1 illustrates in DS-Lite scenario how the RADIUS protocol and DHCPv6 work together to accomplish Multicast-Prefixes-64 configuration on the mB4 element for multicast service when an IP session is used to provide connectivity to the user. mB4 NAS AAA | | Server |------ DHCPv6 Solicit ---------> | | | | | | |----Access-Request ---->| | | | | |<---Access-Accept-------| | |(Multicast-Prefixes-64) | | | | |<------- DHCPv6 Advertise ------| | | (DHCPv6 OPTION_V6_PREFIX64 ) | | | | | |------- DHCPv6 Request -------->| | | | | | | | |<----- DHCPv6 Reply ------------- | | | (DHCPv6 OPTION_V6_PREFIX64 ) | | DHCPv6 RADIUS Figure 1: RADIUS and DHCPv6 Message Flow for an IP Session The NAS operates as a client of RADIUS and as a DHCP Server/Relay for mB4. When the mB4 sends a DHCPv6 Solicit message to NAS(DHCP Server/ Relay). The NAS sends a RADIUS Access-Request message to the RADIUS server, requesting authentication. Once the RADIUS server receives the request, it validates the sending client, and if the request is approved, the AAA server replies with an Access-Accept message including a list of attribute-value pairs that describe the parameters to be used for this session. This list MAY contain the Multicast-Prefixes-64 attribute (asm-length,ASM_PREFIX64,ssm-length, SSM_PREFIX64,unicast-length,U_PREFIX64). Then, when the NAS receives the DHCPv6 Request message containing the OPTION_V6_PREFIX64 option in its Option Request option,the NAS SHALL use the prefixes returned in the RADIUS Multicast-Prefixes-64 attribute to populate the DHCPv6 OPTION_V6_PREFIX64 option in the DHCPv6 reply message. NAS MAY be configured to return the configured Multicast-Prefixes-64 by the AAA Server to any requesting client without relaying each received request to the AAA Server.Wang, et al. Expires June 4, 2016 [Page 5]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 2015 Figure 2 describes another scenario, which accomplish DS-Lite Multicast-Prefixes-64 configuration on the mB4 element for multicast service when a PPP session is used to provide connectivity to the user. Once the NAS obtains the Multicast-Prefixes-64 attribute from the AAA server through the RADIUS protocol, the NAS MUST store the received Multicast-Prefixes-64 locally. When a user is online and sends a DHCPv6 Request message containing the OPTION_V6_PREFIX64 option in its Option Request option, the NAS retrieves the previously stored Multicast-Prefixes-64 and uses it as OPTION_V6_PREFIX64 option in DHCPv6 Reply message. mB4 NAS AAA | | Server | | | |----PPP LCP Config-Request------> | | | | | | |----Access-Request ---->| | | | | |<---- Access-Accept-----| | | (Multicast-Prefixes-64)| |<-----PPP LCP Config-ACK ------- | | | | | | | | |--- PPP IPv6CP Config-Request --->| | | | | |<----- PPP IPv6CP Config-ACK -----| | | | | |------- DHCPv6 Solicit -------->| | | | | |<------- DHCPv6 Advertise -----| | | (DHCPv6 OPTION_V6_PREFIX64 ) | | | | | |------- DHCPv6 Request -------->| | | | | | | | |<-------- DHCPv6 Reply ---------- | | | (DHCPv6 OPTION_V6_PREFIX64) | | DHCPv6 RADIUS Figure 2: RADIUS and DHCPv6 Message Flow for a PPP Session According to [RFC3315], after receiving the Multicast-Prefixes-64 attribute in the initial Access-Accept packet, the NAS MUST store the received V6_PREFIX64 locally. When the mB4 sends a DHCPv6 Renew message to request an extension of the lifetimes for the assigned address or prefix, the NAS does not have to initiate a new Access-Wang, et al. Expires June 4, 2016 [Page 6]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 2015 Request packet towards the AAA server to request the Multicast- Prefixes-64. The NAS retrieves the previously stored Multicast- Prefixes-64 and uses it in its reply. Also, if the DHCPv6 server to which the DHCPv6 Renew message was sent at time T1 has not responded, the DHCPv6 client initiates a Rebind/ Reply message exchange with any available server. In this scenario, the NAS receiving the DHCPv6 Rebind message MUST initiate a new Access-Request message towards the AAA server. The NAS MAY include the Multicast-Prefixes-64 attribute in its Access-Request message.Wang, et al. Expires June 4, 2016 [Page 7]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20154. RADIUS Attribute This section specifies the format of the new RADIUS attribute.4.1. Multicast-Prefixes-64 The Multicast-Prefixes-64 attribute conveys the IPv6 prefixes to be used in [I-D.ietf-softwire-dslite-multicast] to synthesize IPv4- embedded IPv6 addresses. The NAS SHALL use the IPv6 prefixes returned in the RADIUS Multicast-Prefixes-64 attribute to populate the DHCPv6 PREFIX64 Option [I-D.ietf-softwire-multicast-prefix-option] . This attribute MAY be used in Access-Request packets as a hint to the RADIUS server, for example, if the NAS is pre-configured with Multicast-Prefixes-64, these prefixes MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS, and it MAY assign a different Multicast-Prefixes-64 attribute. If the NAS includes the Multicast-Prefixes-64 attribute, but the AAA server does not recognize this attribute, this attribute MUST be ignored by the AAA server. NAS MAY be configured with both ASM_PREFIX64 and SSM_PREFIX64 or only one of them. Concretely, AAA server MAY return ASM_PREFIX64 or SSM_PREFIX64 based on the user profile and service policies. AAA MAY return both ASM_PREFIX64 and SSM_PREFIX64. When SSM_PREFIX64 is returned by the AAA server, U_PREFIX64 MUST also be returned by the AAA server. If the NAS does not receive the Multicast-Prefixes-64 attribute in the Access-Accept message, it MAY fall back to a pre-configured default Multicast-Prefixes-64, if any. If the NAS does not have any pre-configured, the delivery of multicast traffic is not supported. If the NAS is pre-provisioned with a default Multicast-Prefixes-64 and the Multicast-Prefixes-64 received in the Access-Accept message are different from the configured default, then the Multicast- Prefixes-64 attribute received in the Access-Accept message MUST be used for the session. A summary of the Multicast-Prefixes-64 RADIUS attribute format is shown Figure 3. The fields are transmitted from left to right.Wang, et al. Expires June 4, 2016 [Page 8]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 2015 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | asm-length | | +-+-+-+-+-+-+-+-+ : : ASM_PREFIX64 (variable) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ssm-length | | +-+-+-+-+-+-+-+-+ : : SSM_PREFIX64 (variable) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unicast-length| | +-+-+-+-+-+-+-+-+ : : U_PREFIX64 (variable) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: RADIUS attribute format for Multicast-Prefixes-64 Type: 145 for Multicast-Prefixes-64 Length: This field indicates the total length in octets of this attribute including the Type and Length fields, and the length in octets of all PREFIX fields. asm-length: the prefix-length for the ASM IPv4-embedded prefix, as an 8-bit unsigned integer (0 to 128). This field represents the number of valid leading bits in the prefix. ASM_PREFIX64: this field identifies the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the ASM mode. It is a variable size field with the length of the field defined by the asm-length field and is rounded up to the nearest octet boundary. In such case any additional padding bits must be zeroed. The conveyed multicast IPv6 prefix MUST belong to the ASM range. This prefix is likely to be a /96. ssm-length:Wang, et al. Expires June 4, 2016 [Page 9]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 2015 the prefix-length for the SSM IPv4-embedded prefix, as an 8-bit unsigned integer (0 to 128). This field represents the number of valid leading bits in the prefix. SSM_PREFIX64: this field identifies the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the SSM mode. It is a variable size field with the length of the field defined by the ssm-length field and is rounded up to the nearest octet boundary. In such case any additional padding bits must be zeroed. The conveyed multicast IPv6 prefix MUST belong to the SSM range. This prefix is likely to be a /96. unicast-length: the prefix-length for the IPv6 unicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast sources, as an 8-bit unsigned integer (0 to 128). This field represents the number of valid leading bits in the prefix. U_PREFIX64: this field identifies the IPv6 unicast prefix to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. U_PREFIX64 may also be used to extract the IPv4 address from the received multicast data flows. It is a variable size field with the length of the field defined by the unicast-length field and is rounded up to the nearest octet boundary. In such case any additional padding bits must be zeroed. The address mapping MUST follow the guidelines documented in [RFC6052].Wang, et al. Expires June 4, 2016 [Page 10]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20155. Table of Attributes The following tables provide a guide to which attributes may be found in which kinds of packets, and in what quantity. The following table defines the meaning of the above table entries. Access- Access- Access- Challenge Accounting- # Attribute Request Accept Reject Request 0-1 0-1 0 0 0-1 145 Multicast-Prefixes-64 CoA- CoA- CoA- # Attribute Request ACK NACK 0-1 0 0 145 Multicast-Prefixes-64 0 This attribute MUST NOT be present in the packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instances of this attribute MAY be present in the packet. 1 Exactly one instances of this attribute MAY be present in the packet.Wang, et al. Expires June 4, 2016 [Page 11]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20156. Security Considerations This document has no additional security considerations beyond those already identified in [RFC2865] for the RADIUS protocol and in [RFC5176] for CoA messages. The security considerations documented in [RFC3315] and [RFC6052] are to be considered.Wang, et al. Expires June 4, 2016 [Page 12]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20157. IANA Considerations Per this document, IANA has allocated a new RADIUS attribute type from the IANA registry "Radius Attribute Types" located athttp://www.iana.org/assignments/radius-types. Multicast-Prefixes-64 - 145Wang, et al. Expires June 4, 2016 [Page 13]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20158. Acknowledgments The authors would like to thank Ian Farrer, Chongfen Xie, Qi Sun, Linhui Sun and Hao Wang for their contributions to this work.Wang, et al. Expires June 4, 2016 [Page 14]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 20159. Normative References [I-D.ietf-softwire-dslite-multicast] Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network",draft-ietf-softwire-dslite-multicast-10 (work in progress), August 2015. [I-D.ietf-softwire-multicast-prefix-option] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes",draft-ietf-softwire-multicast-prefix-option-09 (work in progress), August 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)",RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)",RFC 5176, DOI 10.17487/RFC5176, January 2008, <http://www.rfc-editor.org/info/rfc5176>. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators",RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>. [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- Stack Lite",RFC 6519, DOI 10.17487/RFC6519, February 2012, <http://www.rfc-editor.org/info/rfc6519>.Wang, et al. Expires June 4, 2016 [Page 15]
Internet-Draft RADIUS Extensions for Multicast Prefixes December 2015Authors' Addresses Qian Wang China Telecom No.118, Xizhimennei Beijing 100035 China Email: wangqian@ctbri.com.cn Wei Meng ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: meng.wei2@zte.com.cn,vally.meng@gmail.com Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: wang.cui1@zte.com.cn Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange.comWang, et al. Expires June 4, 2016 [Page 16] draft-wang-radext-multicast-radius-ext-00
Expired Internet-Draft (individual)
| Document | Document type | Expired Internet-Draft (individual) Expired & archived This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process. | |
|---|---|---|---|
| Select version | |||
| Authors | Qian Wang,Wei Meng,Cui Wang,Mohamed Boucadair Email authors | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Other formats |