[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Radext WG                                                        Q. Wang
Internet-Draft                                             China Telecom
Intended status: Standards Track                                 W. Meng
Expires: June 4, 2016                                            C. Wang
                                                         ZTE Corporation
                                                            M. Boucadair
                                                          France Telecom
                                                        December 2, 2015


RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixes
               draft-wang-radext-multicast-radius-ext-00

Abstract

   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 of BCP 78 and BCP 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 at http://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 to BCP 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 documents



Wang, 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 Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Convention and Terminology . . . . . . . . . . . . . . . . . .  4
   3.  Multicast-Prefixes-64 Configuration with RADIUS and DHCPv6 . .  5
   4.  RADIUS Attribute . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Multicast-Prefixes-64  . . . . . . . . . . . . . . . . . .  8
   5.  Table of Attributes  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16































Wang, et al.              Expires June 4, 2016                  [Page 2]


Internet-Draft  RADIUS Extensions for Multicast Prefixes   December 2015


1.  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 2015


2.  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 2015


3.  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 2015


4.  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 2015


5.  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 2015


6.  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 2015


7.  IANA Considerations

   Per this document, IANA has allocated a new RADIUS attribute type
   from the IANA registry "Radius Attribute Types" located at
   http://www.iana.org/assignments/radius-types.

   Multicast-Prefixes-64 - 145












































Wang, et al.              Expires June 4, 2016                 [Page 13]


Internet-Draft  RADIUS Extensions for Multicast Prefixes   December 2015


8.  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 2015


9.  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 2015


Authors' 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.com
















Wang, et al.              Expires June 4, 2016                 [Page 16]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/