Tsunemasa Hayashi, NTT 
   Internet Draft                          Haixiang He, Nortel Networks 
   Document: draft-hayashi-mlda-02.txt              Akihiro Tanabe, NTT 
   Expires: October 2004                             Hiroaki Satou, NTT 
                                                 Teruki Niki, Panasonic 
                                                                        
                                                             April 2004 
    
    
    
        Multicast Listener Discovery Authentication protocol (MLDA) 
                        <draft-hayashi-mlda-02.txt> 
    
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 except that the right to 
   produce derivative works is not granted. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts. 
    
   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." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
   Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   This memo documents a multicast CDN (Content Delivery Network) issues, 
   and describes requirement and discussion points when we solve them. 
   Here, we need a method of precise user accounting (logging) of a user 
   activity to a multicast group and of user access control to a 
   multicast group to protect to subscribe from an illegal access. In 
   this case, it is needed to authorize a user access to a multicast 
   group on the CDN, and to get information of user action (Join/Leave) 
   to a multicast group. The key is how a control process of group 
   membership synchronizes with an AAA process (authentication, 
   authorization and accounting), because we can get a user access 
   information at an AAA server. This depends on the network model of 
   the multicast CDN service. Last of all, we introduce an example of 
   solution MLDA (Multicast Listener Discovery Authentication protocol). 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 1] 
 
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   MLDA provides MLD's protocol framework between hosts and their first-
   hop routers, with AAA information.  MLDA can be divided into two 
   parts: One is the header part which specifies IP layer information, 
   and another part is the data part which can transfer information for 
   AAA operation. The function of transferring AAA information enables a 
   provider to control the distribution of the multicast traffic as well 
   as to collect real time user access log (accounting) information at 
   the last-hop access networks. In this mechanism, we can protect to 
   subscribe a multicast data from an illegal user. MLDA just transfers 
   information for AAA besides of multicast access control, and has 
   framework that any method of authentication and accounting can be 
   used with MLDA between a client and AAA server. MLDA also use same 
   ICMPv6 [ICMPv6] (IP Protocol 58) message types, rather than IGMP (IP 
   Protocol 2) message types as same as that of IGMP. 
    
    
1. Terminology 
    
 Accounting 
   The act of collecting information on resource usage for the purpose 
   of trend analysis, auditing, billing, or cost allocation. 
    
 Administrative Domain 
   An internet, or a collection of networks, computers, and databases 
   under a common administration.  Computer entities operating in a 
   common administration may be assumed to 
   share administratively created security associations. 
    
 Attendant  
   A node designed to provide the service interface between a client and 
   the local domain. 
    
 Authentication 
   The act of verifying a claimed identity, in the form of a pre-
   existing label from a mutually known name space, as the originator of 
   a message (message authentication) or as the end-point of a channel 
   (entity authentication). 
    
 Authorization 
   The act of determining if a particular right, such as access to some 
   resource, can be granted to the presenter of a particular credential. 
    
 Billing 
   The act of preparing an invoice. 
    
 Broker 
   A Broker is an entity that is in a different administrative domain 
   from both the home AAA server and the local ISP, and which provides 
   services, such as facilitating payments  between the local ISP and 

    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 2] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   home administrative entities. There are two different types of 
   brokers; proxy and routing. 
    
 Client  
   A node wishing to obtain service from an attendant within an 
   administrative domain. 
    
 Real-time Accounting 
   Real-time accounting involves the processing of information on 
   resource usage within a defined time window.  Time constraints are 
   typically imposed in order to limit financial risk. 
    
    
2. Requirements summery 
    
   The multicast CDN model and requirement to group management protocol 
   for real-time accounting of client activity to a multicast group are 
   summarized below. 
    
    
2.1 Requirements of Multicast CDN model 
    
   The basic CDN network model consists of three different types of 
   players. The first player is content service provider (CSP) who 
   provides its content. The second one is network service provider 
   (NSP) which controls network resources and delivers the content to an 
   end user client. The last player is end user client who subscribes 
   the content. Generally, CSP(s) are different administrative domains 
   (business entities) from NSP. Each content is transferred on a 
   multicast (S,G) from CSP to a client through NSP. Each provider 
   manages own data base of its customer (client) and keep it itself. 
    
     +-------------+  +-------------+  +-------------+ 
     | CSP         |  | CSP         |  | CSP         | 
     |          #1 |  |          #2 |  |          #3 | 
     | +---------+ |  | +---------+ |  | +---------+ | 
     | | content | |  | | content | |  | | content | | 
     | | server  | |  | | server  | |  | | server  | | 
     | +-------+-+ |  | +----+----+ |  | +-+-------+ | 
     +----------\--+  +------|------+  +--/----------+ 
                 \           |           / 
                  \          |          /  <- network/network interface 
                   \         |         / 
     +------------- \ ------ | ------ / ----+ 
     |               \       |       /      | 
     |   NSP         +-+-----+-----+-+      | 
     |               | Provider Edge |      | 
     |               +-------+-------+      | 
     |                       |              | 
     |               \       |              | 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 3] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
     |             +--+------+---+          | 
     |             | User Edge   |          | 
     |             +--+---+---+--+          | 
     |               /    |    \            | 
     +------------- / --- | --- \ ----------+ 
                   /      |      \ 
                  /       |       \ <- user/network interface 
                 /        |        \ 
      +---------++  +-----+----+   ++---------+ 
      |client #a |  |client #b |   |client #c | 
      +----------+  +----------+   +----------+ 
      End user A    End user B     End user C 
    
    
   There are two important things when we consider this model: The first 
   one is that basically CSP judges an access request from a client to a 
   multicast group, and that both CSP and NSP need to correctly account 
   a user access to a multicast group (a user access log by a group, by 
   when, by user). Another is that we need to protect network resources 
   from the illegal client (what we deliver a multicast data to just a 
   not-granted client).  
    
   A user accesses a multicast group on this CDN anywhere, and the user 
   does not have a restriction of location and client terminal (devices). 
   NSP needs to support plural network services (e.g. VoIP, Internet 
   connection) besides of the CDN delivering service at the same time. 
   Many different CSP may deliver their content to the multicast CDN. 
   CSP can not directory control the NSP resources (routers and network 
   switches). 
    
   This CDN model supports the case when NSP includes every CSPs. 
    
    
2.2 Accounting Requirements 
    
   CSP needs to correctly account a user access to their content 
   (multicast group), and authenticate before a user access to a (S,G). 
   In many cases, we need to operate the accounting in real-time. Each 
   CSP keeps a user information for authentication itself, and the 
   information is different from that NSP has. In multicast network, 
   just NSP can get user access information: When does a user 
   starts/stop to access?  Which multicast group?  NSP can transfer the 
   information to a CSP.  An end user wants to access CDN from anywhere. 
    
   The NSP-CSP model represents multi-domain AAA environment. There are 
   plural cases of the model depending on trust relationship between NSP 
   and CSP, and additional service requirement such as QoS for NSP or 
   ubiquitous for users. 
    

    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 4] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   We need a mechanism that CSP and NSP can affirm a user access log to 
   a multicast independently. 
    
    
2.3 Authentication Requirements 
    
   When NSP supports plural network services at the same time, we can 
   not use an authentication mechanism of physical layer like an 802.1X. 
   Because NSP needs to independently operate (authenticate) each 
   service. NSP authenticate a user request to multicast network 
   resources, and CSPs independently authenticate a user request to 
   their content (multicast group). Each provider (NSP and CSP) has own 
   AAA server. Then we need a synchronization mechanism between 
   authorization and group management. 
    
   Each provider (NSP and CSPs) may have own authentication server. NSP 
   authenticate a client access to use a network resource, and a CSP 
   authenticate a client request to access to a multicast group. 
    
    
2.4 Authorization Requirements 
    
   QoS control, e.g. priority control or admission control, is important 
   for multicast CDN because there is no-reliability to keep a 
   transferring quality. Especially for video streaming, video quality 
   is sensitive to a packet loss. Function to protect network resources 
   from misuse of network resources is needed there.  When NSP controls 
   QoS, userĀ²s access request has to be authorized by NSP after 
   aforementioned authentication.   
    
    
3. MLDA protocol 
    
   MLDA is derived from MLDv2. MLDA adds authentication steps to each 
   group membership state transition in order to control the user access 
   and collect real-time accounting information. This is accomplished 
   via the user using IGAP to offer credentials (e.g. user id and 
   password) to the first hop multicast router as part of group 
   membership requests.  
 
   MLDA assumes a subscription model between the user and the multicast 
   group owner. How the user obtains the appropriate credentials is out 
   of scope of this memo. 
    
    
4. MLDA Message Formats 
    
   MLDA is a sub-protocol of ICMPv6, that is, MLDA message types are a 
   subset of the set of ICMPv6 messages, and MLDA messages are 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 5] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   identified in IPv6 packets by a preceding Next Header value of 58.  
   All MLDA messages described in this document are sent with a link-
   local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 
   Router Alert option [RTR-ALERT] in a Hop-by-Hop Options header. (The 
   Router Alert option is necessary to cause routers to examine MLDA 
   messages sent to multicast addresses in which the routers themselves 
   have no interest.) 
    
   All MLDA message packets have the following format. The fields from 
   Type to Source Address [N] consist of the same fields as MLDv2 
   [MLDv2]. An Auxiliary Data is following. 
    
   There are three types of MLDA messages. 
    
        0x96 = MLDA Listener Query  (MLDA Query) 
    
        0x97 = MLDA Listener Acknowledgement  (MLDA ACK) 
    
        0x98 = MLDA Listener Report (MLDA Report) 
    
   All multicast groups should categorized into one of MLD access 
   control and MLDA's. Unrecognized message types to a multicast group 
   for MLDA should be silently ignored. Other message types may be used 
   by newer versions or extensions of MLD, by multicast routing 
   protocols, or for other uses. 
    
    
4.1 Multicast Listener Query Message 
    
   Multicast Listener Queries are sent by multicast routers to query the 
   multicast listening state of neighboring interfaces Query have the 
   following format: 
    
       0                   1                   2                   3 
       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(bit) 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Type      |     Code      |           Checksum            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Maximum Response Delay    |          Reserved-1           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      +                                                               + 
      |                                                               | 
      +                       Multicast Address                       + 
      |                                                               | 
      +                                                               + 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     | 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 6] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      *                       Source Address [1]                      * 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      +-                                                             -+ 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      *                       Source Address [2]                      * 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      +-                              .                              -+ 
      .                               .                               . 
      .                               .                               . 
      +-                                                             -+ 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      *                       Source Address [N]                      * 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    Subtype   | # of Aux (N)  | Challenge ID  |   Reserved-2   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |   Auxiliary Data Records 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 
    
    
   where each Auxiliary Data Record has the following format: 
    
    
      0                   1 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 
      |   Aux Type    | Aux Data Len  |    Aux Data (variable) 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 
    
    
4.1.1. Type 
    
        0x96 = MLDA Listener Query  (MLDA Query) 
        0x97 = MLDA Listener Acknowledgement  (MLDA ACK) 
    
    
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 7] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
4.1.2. Code 
    
   The meaning and the usage of Code are the same as those of the MLD 
   messages as described in draft-vida-mld-v2-XX [MLDv2]. 
    
    
4.1.3. Checksum 
    
   Checksum covers the MLDA message (covering fields are same as those 
   of the MLD message as described in [MLDv2]. 
    
    
4.1.4. Maximum Response Delay 
    
   The meaning and the usage of Maximum Response Delay are the same as 
   those of the MLD messages as described in [MLDv2]. 
    
    
4.1.5. Reserved-1 
    
   This field should be set to zero. It is ignored when received. 
    
    
4.1.6. Multicast Address 
    
   For a General Query, the Multicast Address field is set to zero. For 
   a User-Specific Query, it is set to the multicast address being 
   queried. For a MLDA ACK message, the Multicast Address field holds 
   the IP multicast address of interest. 
    
    
4.1.7. Resv 
    
   The meaning and the usage of Resv are the same as those of the MLD 
   messages as described in draft-vida-mld-v2-XX [MLDv2]. 
    
    
4.1.8. S 
    
   The meaning and the usage of S are the same as those of the MLD 
   messages as described in draft-vida-mld-v2-XX [MLDv2]. 
    
    
4.1.9. QQIC 
    
   The meaning and the usage of QQIC are the same as those of the MLD 
   messages as described in draft-vida-mld-v2-XX [MLDv2]. 
    
    

    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 8] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
4.1.10. Number of Sources (N) 
    
   The Number of Sources (N) field specifies how many source addresses 
   are present in the Query. This number is zero in a General Query. For 
   User-Specific Query, the value is non-zero. The meaning and the usage 
   of this value for MLD are the same as those of the MLD messages as 
   described in draft-vida-mld-v2-XX [MLDv2], but we must care the 
   Auxiliary field not to exceed an MTU of the link. 
    
    
4.1.11.  Source Address [i] 
    
   The Source Address [i] fields are a vector of n unicast addresses, 
   where n is the value in the Number of Sources (N) field. The meaning 
   and the usage of this value are the same as those of the MLD messages 
   as described in draft-vida-mld-v2-XX [MLDv2]. 
    
    
4.1.12. Subtype 
    
   This field indicates the subtype of message transferred within the 
   MLDA packet. Usage of this field is described later. 
    
   In Type 0x96 (MLDA Query), there are three Subtypes as follows. 
    
        0x01 : General Query 
        0x02 : User-Specific Query for Re-authentication (User Query) 
        0x11 : Challenge-Response Mechanism Challenge (Challenge) 
    
    
   In Type 0x97 (MLDA ACK), there are three Aux Types as follows. 
    
        0x21 : Authentication Message 
        0x22 : Accounting Message 
        0x23 : Notification Message 
    
    
4.1.13. # of Aux (N) 
    
   This field indicates the number of Auxiliary Data Record stored in a 
   MLDA packet. 
    
    
4.1.14 Challenge ID 
    
   This field is meaningful only when Challenge-Response authentication 
   mechanism is used. The value is set according to the Challenge-
   Response protocol. If this field is not used, it is set to the 
   default value of zero. 
    
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                           [Page 9] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
    
4.1.15. Reserved-2 
    
   This field should be set to zero. It is ignored when received. 
    
    
4.1.16. Auxiliary Data Records 
    
   An MLDA packet can contain zero or more numbers of Auxiliary Data 
   Records. The Aux Type field is 1 byte long and specifies the type of 
   the Auxiliary Data Record. The Aux Data Len field is 1 byte long and 
   specifies the length of the auxiliary data in units of bytes. The Aux 
   Data field contains the appropriate data. This document only 
   specifies the following Auxiliary Data Records. 
    
    
4.1.16.1. Aux Type 
    
        0x01 = User Account 
        0x02 = User Password 
        0x03 = Message 
        0x10 = Challenge-Response ID (Challenge ID) 
        0xA0 ~ 0xBF = Vendor specific data 
    
    
4.1.16.2. Aux Data Len 
    
   This field indicates the Aux Data Len specifies the length of the 
   Auxiliary Data. 
    
    
4.2. MLDA Multicast Listener Report Message 
    
   MLDA Multicast Listener Report are sent by MLDA hosts to report the 
   current multicast listening state, or changes in the multicast 
   listening state, of their interfaces. Report have the following 
   format: 
    
       0                   1                   2                   3 
       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(bit) 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Type = 0x98  |     Code      |           Checksum            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           Reserved            |Nr of Mcast Address Records (M)| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      .                                                               . 
      .                  Multicast Address Record [1]                 . 
      .                                                               . 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 10] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      .                                                               . 
      .                  Multicast Address Record [2]                 . 
      .                                                               . 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                               .                               | 
      .                               .                               . 
      |                               .                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      .                                                               . 
      .                  Multicast Address Record [M]                 . 
      .                                                               . 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    Subtype   | # of Aux (N)  | Challenge ID  |   Reserved-2   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |   Auxiliary Data Records 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 
    
    
      Each Multicast Address Record has the following internal format: 
    
    
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Record Type  |   Not Used    |     Number of Sources (N)     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      *                       Multicast Address                       * 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      *                       Source Address [1]                      * 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      +-                                                             -+ 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      *                       Source Address [2]                      * 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 11] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
      |                                                               | 
      *                                                               * 
      |                                                               | 
      +-                                                             -+ 
      .                               .                               . 
      .                               .                               . 
      .                               .                               . 
      +-                                                             -+ 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      *                       Source Address [N]                      * 
      |                                                               | 
      *                                                               * 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
4.2.1. Code 
    
   The meaning and the usage of Code are the same as those of the MLD 
   messages as described in draft-vida-mld-v2-XX [MLDv2]. 
    
    
4.2.2. Checksum 
    
   Checksum covers the MLDA message (covering fields are same as those 
   of the MLD message as described in [MLDv2]. 
    
    
4.2.3. Nr of Mcast Address Records (M) 
    
   The meaning and the usage of Nr of Mcast Address Records (M) are the 
   same as those of the MLD messages as described in [MLDv2]. 
    
    
4.2.4. Multicast Address Record (M) 
    
   The Nr of Mcast Address Records (M) field specifies how many 
   Multicast Address Records are present in this Report. This fields is 
   specified in [MLDv2]. 
    
    
4.2.5. Subtype 
    
   This field indicates the subtype of message transferred within the 
   MLDA packet. Usage of this field is described later. 
    
   In Type 0x98 (MLDA Report), there are four Subtypes as follows. 
    
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 12] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
        0x31 : Password Mechanism Report (Password Report) 
        0x32 : Challenge-Response Mechanism Report Challenge Request 
                (Challenge-Response Report Request) 
        0x33 : Challenge-Response Mechanism Report Response 
                (Challenge-Response Report Response) 
        0x34 : Basic Report 
    
    
4.2.6. # of Aux (N) 
    
   This field indicates the number of Auxiliary Data Record stored in a 
   MLDA packet. 
    
    
4.2.7 Challenge ID 
    
   This field is meaningful only when Challenge-Response authentication 
   mechanism is used. The value is set according to the Challenge-
   Response protocol. If this field is not used, it is set to the 
   default value of zero. 
    
    
4.2.8. Reserved-2 
    
   This field should be set to zero. It is ignored when received. 
    
    
4.2.9. Auxiliary Data Records 
    
   An MLDA packet can contain zero or more numbers of Auxiliary Data 
   Records. The Aux Type field is 1 byte long and specifies the type of 
   the Auxiliary Data Record. The Aux Data Len field is 1 byte long and 
   specifies the length of the auxiliary data in units of bytes. The Aux 
   Data field contains the appropriate data. This document only 
   specifies the following Auxiliary Data Records. 
    
    
4.2.9.1. Aux Type 
    
        0x01 = User Account 
        0x02 = User Password 
        0x03 = Message 
        0x10 = Challenge-Response ID (Challenge ID) 
        0xA0 ~ 0xBF = Vendor specific data 
    
    
4.2.9.2. Aux Data Len 
    
   This field indicates the Aux Data Len specifies the length of the 
   Auxiliary Data. 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 13] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
    
    
4.2.10.  Record Type 
    
   It specifies the type of the Multicast Address Record. [MLDv2] 
    
    
4.2.11. Not Used 
    
   This field should be fill by null. In MLDA, the field is not used. 
    
    
4.2.12.  Aux Data Len 
    
   The Aux Data Len field contains the length of the Auxiliary Data 
   Field in this Multicast Address Record, in units of 8-bit words. It 
   may contain zero, to indicate the absence of any auxiliary data. 
    
    
4.2.13.  Number of Sources (N) 
    
   The Number of Sources (N) field specifies how many source addresses 
   are present in this Multicast Address Record. 
    
    
4.2.14. Multicast Address 
    
   The Multicast Address field contains the multicast address to which 
   this Multicast Address Record pertains. 
    
    
4.2.15.  Source Address [i] 
    
   The Source Address [i] fields are a vector of n unicast addresses, 
   where n is the value in this record's Number of Sources (N) field. 
    
    
4.2.16.  Multicast Address Record Types 
    
   It specifies the type of the Multicast Address Record. [MLDv2] 
    
    
5. Protocol Description 
    
   MLDA is used for controlled or managed multicast services. MLD is not 
   useded for the same group address for MLDA. An MLDA router should 
   handle a multicast group if it is for MLDA or MLD. MLDA message can 
   be differentiated from MLDA messages by the values of the "type" 
   fields specified above. 
    
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 14] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   MLDA tracks an individual host's multicast listener information, in 
   order to implement "fast leave" feature. In other words, MLDA does 
   not implement Multicast-Address-Specific (or Multicast-Address and 
   Source-Specific) Query feature of MLDv2. When a MLDA router receives 
   a MLDA report message to cease lintening, it deletes the 
   corresponding state information instead of sending an Multicast-
   Address-Specific Query of MLDv2. To facilitate tracking information 
   of individual host's listening IP-multicast, MLDA does not support 
   the Host suppression feature of MLD. 
    
   MLDA is used for controlled or managed multicast services. A user 
   must use MLDA to access such multicast services. 
    
   MLDA specifies different behaviors for MLDA hosts and for MLDA 
   routers. If an MLDA router needs to listen some IP multicast address, 
   it can perform both parts of the protocol. 
    
    
5.1 User Authentication Mechanisms 
    
   Currently MLDA supports two user authentication mechanisms for Report 
   operation: simple and basic password authentication mechanism [PAP], 
   and more advanced challenge-response authentication mechanism [CHAP]. 
   These mechanisms are not used at the same time. Only one mechanism 
   may be configured for use in a specific network. An MLDA 
   implementation must support the password authentication mechanism, 
   while the Challenge-response authentication mechanism is optional. 
   Any encrypted user information can be transferred on the password 
   mechanism between a MLDA host and a AAA server, where MLDA transfers 
   the encrypted date on a Report message. 
    
   MLDA is intended for use with standard AAA servers such as RADIUS 
   [RADIUS] servers, which, with necessary extensions, can be used to 
   achieve the authentication, authorization and accounting functions 
   described in this document. However, MLDA is not limited to use with 
   standard AAA servers. It can be used with any back-end 
   Authentication, Authorization, and Accounting functions or 
   mechanisms. These functions or mechanisms can be located in different 
   servers, within one server, or even within the MLDA routers. In this 
   document, we use AAA servers as an example for these functions or 
   mechanisms. 
    
   MLDA router must support to transfer any Auxiliary Data Record of a 
   Vendor specific data (0x20, 0xA0~ 0xBF) on MLDA packet to an 
   attribute data for Authentication or Accounting process between AAA 
   server. The rule depends on a network service. For example, when the 
   encrypted data as a user information is transfered to a MLDA router, 
   the client may use User Encrypted Information as an Auxiliary Type, 
   and the information may be transfered to a AAA server with a vendor 
   specific attribute. 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 15] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
    
    
5.2 MLDA Host Protocol Description 
    
   This section describes the MLDA host behavior. Based on the 
   configured authentication mechanism, an MLDA host behaves 
   differently. 
    
    
5.2.1 Password Authentication Mechanism 
    
   When an MLDA host starts listening to a multicast address on an 
   interface, it should immediately transmit an unsolicited MLDA Report 
   that has a Subtype field of 0x31 (Password Report) to the 
   corresponding address. The Report must have two auxiliary data of 
   User Account (Aux Type of 0x01), and User Password (Aux Type of 0x02) 
   or Message (Aux Type of 0x03) at least. The Aux Data field of User 
   Account is filled with the user account (user ID) while the Aux Data 
   Len field is set to the length of the user account. The Aux Data 
   field of User Password is filled with the user password while the Aux 
   Data Len field is set to the length of the password. The Aux Data 
   field of Message is filled with a authentication information 
   substitute for the password. 
    
   When a host receives an MLDA Query of Query that has a Subtype field 
   of 0x01 or 0x02, it sets delay timers as described in [MLDv2]. If a 
   timer for the multicast address is already running, it is reset to 
   the random value only if the requested Maximum Response Delay is less 
   than the remaining value of the running timer. When a multicast 
   address's timer expires, the host sends a Password Report that has a 
   Subtype field of 0x31. This message must have an auxiliary data of 
   User Account at least for General Query that has a Subtype field of 
   0x01. On the other hand, this message must have an auxiliary data of 
   User Account and User password at least for User-Specific Query for 
   Re-authentication that has a Subtype field of 0x02. The Aux Data 
   field is filled with the user account (user ID) while the Account 
   Size field is set to the length of the user account. When the MLDA 
   Query is User-Specific Query for Re-authentication that has a Subtype 
   field of 0x02, the host must send a Password Report with auxiliary 
   data of both User Account and Password. 
    
   When an MLDA host ceases to listen to a multicast address, it sends 
   an MLDA message to the all-routers multicast address which will be 
   specified in [MLDv2]. The maner of message format should be followed 
   [MLDv2]. The Report has a auxiliary data of User Account at least. 
   The Aux Data field is filled with the user account (user ID) while 
   the Aux Data Len field is set to the length of the user account. In 
   scenarios where authentication is required, an MLDA host can send the 
   Report message that has a Subtype field of 0x31 (Password Report) for 
   any ceasing operation. The Password Report must have two auxiliary 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 16] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   data of User Account and Account Size at least. The Aux Data of User 
   Account is set to the values as in Basic Report. The Aux Data of User 
   Password field is filled with the user password while the Aux Data 
   Len field is set to the length of the password. 
    
    
5.2.2 Challenge-Response Authentication Mechanism 
    
   When an MLDA host starts listening to a multicast address, it sends a 
   Challenge-Request Report Request that has a Subtype field of 0x32 
   (Challenge-Response Mechanism Report Challenge Request) to the 
   corresponding multicast address. The Request must have a auxiliary 
   data of User Account at least. The Aux Data field is filled with the 
   user account (user ID) while the Aux Data Len field is set to the 
   length of the user account. 
    
   When the MLDA host receives a Challenge that has a Subtype of 0x11 
   (Challenge-Response Mechanism Challenge) as a response to the, the 
   MLDA client sends a Challenge-Response Report Response that has a 
   Subtype of 0x33 (Challenge-Response Mechanism Report Response). The 
   Report Response must have three auxiliary data of User Account, User 
   Password, and Challenge ID. The Aux Data field of Challenge ID is set 
   to the same value of Challenge ID on the Challenge. The Aux Data 
   field of User Account is filled with the user account (user ID) while 
   the Aux Data Len field is set to the length of the user account. The 
   Aux Data field of User Password is set the results of MD5 calculation. 
   The Aux Data Len field is set to 0x10. 
    
   When a host receives an MLDA Query, it follows the behavior described 
   above to set the delay timer. When a address's timer expires, the 
   host sends a MLDA Report that has a Subtype field of 0x32. This 
   message must have a auxiliary data of User Account at least. The Aux 
   Data field is filled with the user account (user ID) while the Aux 
   Data Len field is set to the length of the user account. 
    
   When an MLDA host ceases to listen to a multicast address, it sends 
   an MLDA Report message to the all-routers multicast address which 
   will be specified in [MLDv2]. Normally an MLDA host sends a Basic 
   Report message for ceasing to listen as described above. The detail 
   manner of message format should be follow [MLDv2]. In scenarios where 
   the Report message authentication is required, an MLDA host can send 
   a Report message that has a Subtype field of 0x32 (Challenge-Response 
   Mechanism Report Challenge Request). The message must have a 
   auxiliary data of User Account at least. The Aux Data field is filled 
   with the user account (user ID) while the Aux Data Len field is set 
   to the length of the user account. When the MLDA host receives a 
   Challenge that has a Subtype of 0x11 (Challenge-Response Mechanism 
   Challenge) as a response to the Challenge-Response Report Request, it 
   sends a Report message that has a Subtype field of 0x43 (Challenge-
   Response Mechanism Report Response) with a Multicast Address Record 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 17] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   for ceasing to listen. The message must have three auxiliary data of 
   User Account, User Password, and Challenge ID at least. The Aux Data 
   field of User Password is set to the results of MD5 calculation. The 
   Aux Data Len field is set to 0x10. 
    
   An MLDA implementation must support Basic Report. Challenge-Response 
   Authentication Mechanism Report is optional. 
    
    
5.3 MLDA Router Protocol Description 
    
   MLDA routers use MLDA to learn which multicast address have listeners 
   on each of their interfaces. They can be physical interfaces or 
   virtual interfaces such as VLANs. Same as MLD, an MLDA router keeps a 
   listener list of multicast address for each attached network, and a 
   timer for each address. Each address state has the conceptual 
   following format: 
    
        (socket, interface, IPv6 multicast address, filter mode, source 
        list, user-id, client IP address, timer(s)) 
    
   MLDA routers periodically [Query Interval] send an MLDA Query on each 
   attached network to solicit listener information. On startup, a 
   router SHOULD send [Startup Query Count] MLDA Queries spaced closely 
   together [Startup Query Interval] in order to quickly and reliably 
   determine listener information. [Query Interval], [Startup Query 
   Count] and [Startup Query Interval] are same as [MLDv2]. 
    
   An General Query is addressed to the all-systems multicast address 
   (FF02::1), has a Multicast Address field of Zero, has a Maximum 
   Response Delay of [Query Response Interval], and has a MLDA Type 
   field of 0x01 (General-Query). [Query Response Interval] is same as 
   [MLDv2]. 
    
   An User Query is addressed to the unicast IP address of the client 
   host, has a Multicast Address field of the multicast address the 
   client listen, and has a MLDA Type field of 0x02 (User-Specific Query 
   for Re-authentication). A Maximum Response Delay of [Query Response 
   Interval] is same to that of General Query. [Query Response Interval] 
   is same as [MLDv2]. 
    
    
5.3.1 Password Authentication Mechanism 
    
   When an MLDA router receives a Password Mechanism Report (an MLDA 
   Report that has a Subtype field of 0x31), if the router already has 
   the corresponding listener state of a multicast address, it refreshes 
   the associated timer. 
    

    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 18] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   If the router does not have listener state of the multicast address, 
   it forwards the user's listener Response request as well as its user 
   authentication information, including its user account and password, 
   to the back-end AAA server. Based on the AAA server's authentication 
   and authorization results, the MLDA router grants or denies the 
   user's access request. When the MLDA router grants the request, it 
   adds the multicast being reported to the listener list of a multicast 
   address on the interface on which it received the Report and sets the 
   timer for the address to the [Multicast Listener Interval]. 
    
   When an MLDA router receives an MLDA Report message to cease 
   listening a multicast group that has listeners on the reception 
   interface, it deletes the corresponding multicast address state. 
    
   If an authentication is required in the ceasing operation, an MLDA 
   Report must have a Subtype field of 0x31, and includes a user 
   authentication information which is same to a user authentication on 
   Password Report, and the router forwards the user's cease information 
   as well as the user authentication information to the back-end AAA 
   server. If the cease request is authenticated and authorized, the 
   router deletes the corresponding listener state of a multicast 
   address. Otherwise, the cease request is ignored. 
    
    
   5.3.2 Challenge-Response Authentication Mechanism 
    
   When an MLDA router receives a Challenge-Response Report Request has 
   a Subtype field of 0x32, the router tries to establish Challenge-
   Response communication for a Report process, then the router sends a 
   Challenge-Response Mechanism Challenge (a Challenge that has a Type 
   field of 0x96, a Subtype field of 0x11). The Challenge must have 
   three auxiliary data of User Account, User Password, and Challenge ID. 
   The Aux Data field of User Account is set to the same user ID in the 
   Challenge-Response Report Request, the Aux Data field of User 
   Password set to a Challenge value [CHAP], and the Aux Data field of 
   Challenge ID set to an ID [CHAP]. 
    
   When the MLDA router receives a Challenge-Response Report Response 
   that has a Subtype field of 0x33), if the router already has the 
   corresponding multicast address listener state, it refreshes the 
   associate timer. 
    
   If the router does not have the listener state of a multicast address, 
   it forwards the user's listen request information as well as its user 
   authentication information including its user account and password to 
   the back-end AAA server. Based on the AAA server's results of 
   authentication and authorization processes, the MLDA router grants or 
   denies the user's access request. When the MLDA router grants the 
   request, it adds the multicast address being reported to the listener 
   list of multicast address on the interface on which it received the 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 19] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   Report and sets the timer for the listener to the [Multicast Listener 
   Interval]. 
    
   When an MLDA router receives an MLDA Report message to cease 
   listening to a multicast address that has multicast listeners on the 
   reception interface, it deletes the corresponding multicast listener 
   state. 
    
   If an authentication is required in the ceasing operation, a host 
   oriented Challenge-Response communication is establish between a host 
   and the MLDA router. When a MLDA router receives an Challenge-
   Response Report Request to cease listening a multicast group that has 
   a Subtype field of 0x32, the router sends a Challenge-Response 
   Mechanism Challenge (a Challenge that has a Type field of 0x96, a 
   Subtype field of 0x11, a Challenge ID field of an ID [CHAP], a User 
   Account set to a user ID in the Challenge-Request-Report, and a 
   Message set to a Challenge value [CHAP]). 
    
   When the MLDA router receives a Challenge-Response Report Response to 
   cease listening to the multicast address that has a Subtype field of 
   0x33. The message must have three auxiliary data of User Account, 
   User Password, and Challenge ID at least. Both Aux Data fields of 
   User Account and User Password are the same. The Aux Data field of 
   User Password is set to the results of MD5 calculation. The Aux Data 
   Len field of User Password is set to 0x10, and the router forwards 
   the user's multicast address cease information as well as the user 
   authentication information to the back-end AAA server. If the address 
   cease request is authenticated and authorized, the router deletes the 
   corresponding multicast listener state. Otherwise, the cease request 
   is ignored. 
    
    
5.4 Status Notifications 
    
   In controlled or managed multicast environments, it is very important 
   to notify a user of its service statuses. MLDA supports the following 
   status notifications. 
    
    
5.4.1 Authentication Result Notification 
    
   When an MLDA router receives the authentication result from the 
   back-end AAA server, it notifies the user of the result by unicasting 
   an Authentication message to the client. 
    
   The Authentication message has a Type field of 0x97 (MLDA ACK) and a 
   Subtype field of 0x21. The Multicast Address field contains the 
   corresponding multicast address for authentication. The Maximum 
   Response Delay field is not used and is ignored by MLDA clients. It 
   can be set to any value. The message has two auxiliary data of User  
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 20] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   Account and Message at least. The Aux Data field of User Account 
   contains the user account (user ID) for authentication and the Aux 
   Data Len field is set the length of the user account. 
    
   The Aux Data field of Message has the following values at least: 
    
        0x11: Authentication success. 
        0x21: Authentication failure. 
    
   The Message Size field is set to the length of the Aux Data. An MLDA 
   implementation must support the above mandatory values. It supports 
   the any other vendor specific values. Appropriate value is chosen to 
   reflect the result from the AAA server as well as other vendor 
   specific processes. The process adopted by the MLDA clients upon 
   receiving this packet type is up to implementation. However, it must 
   not affect other MLDA process. 
    
    
5.4.2 Accounting Status Notification 
    
   An MLDA router informs the accounting server to start accounting when 
   it starts forwarding related multicast traffic into the client's 
   network. When the MLDA client ceases to listen to the multicast 
   address (either via silent departure or an explicit leave), the 
   router informs the accounting server to stop accounting. Once it 
   receives the response from the accounting server, it notifies the 
   MLDA client by unicasting an Accounting message. 
    
   The Accounting message has a Type field of 0x97 (MLDA ACK) and a 
   Subtype field of 0x22. The Multicast Address field, the Maximum 
   Response Delay field, the User Account field, and the Account Size 
   field are the same as those in the Authentication message described 
   in section 3.4.1. 
    
   The Message field has the following values at least: 
    
        0x11: Accounting start 
        0x12: Accounting stop 
    
   The Message Size field is set to the length of the Aux Data. An MLDA 
   implementation must support the above mandatory values. It supports 
   the any other vendor specific values. The process adopted by the MLDA 
   client upon receiving this packet type is up to implementation. 
   However, it must not affect other MLDA process. 
    
    
5.5 Validity Period 
    
   For each multicast listener state, an MLDA router SHOULD maintain 
   another timer: Validity Period timer. This timer indicates the valid 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 21] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   period of an accounting to a multicast listener. When the timer is 
   expired, an MLDA router needs to re-authenticate the multicast 
   listener, then the router sends a MLDA host User-Specific Query for 
   Re-authentication besides of General Query. The value of the 
   "Validity Period" can be statically configured or dynamically set 
   based on the results from the AAA server. 
    
   When "Validity Period" is enforced, an MLDA router checks this timer 
   when it receives an MLDA Report. If the timer does not expire, the 
   MLDA router send a MLDA host a General Query, and does not ask the 
   AAA server a user authentication by a MLDA Report response. If the 
   timer expires, it follows the procedures for initial authentication 
   described above to re-authenticate the listen request. During the re-
   authentication period, an MLDA router continues forwarding the 
   multicast traffic and does not stop accounting. If the re-
   authentication succeeds, an MLDA router resets the multicast address 
   timer and the Validity Period timer. If the re-authentication fails, 
   an MLDA router stops accounting and deletes the multicast address 
   listener state. 
    
    
6. List of Timers, Counters 
    
   This section describes the parameters set in MLDA router and Host 
   when supporting MLDA processes. 
    
    
6.1. Robustness Variable 
    
   It is the same meaning as MLDv2. 
    
    
6.2. Timers and Counters for Host 
    
6.2.1. Challenge-Timer 
    
   It controls waiting time from sending Report message to receiving 
   Challenge Message. 
    
    
6.2.2. Host-Authentication-Timer 
    
   It controls waiting time from sending Response Message to receiving  
   Authentication Message (accept or reject) from MLDA router. 
    
    
6.2.3. Host-Accounting-Timer 
    
   It controls waiting time from sending Response Message to receiving 
   Accounting Message (start or stop) from MLDA router. 
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 22] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
    
    
6.2.4. Delaying-Timer 
    
   It controls waiting time from receiving Query to sending Report  
   Message to MLDA router. It is calculated from Max Resp Time. 
    
    
6.2.5. Cease-Retransmission-Counter 
    
   The Cease-Retransmission-Counter is the number of Report messages a 
   host retransmits after sending the first Report message. The default 
   value is zero. 
    
    
6.2.6.  Unsolicited-Report-Interval-Timer 
    
   It is the same meaning as MLDv2. The Unsolicited Report Interval is  
   the time between repetitions of a node's initial report of interest 
   in a multicast address.  Default: 1 second. 
    
    
6.3. Timers and Counters for MLDA router 
    
6.3.1. Response-Timer 
    
   It controls waiting time from sending Challenge Message to receiving  
   Response Message between client host. 
    
    
6.3.2. Router-Authentication-Timer 
    
   It controls waiting time from sending Authentication request to 
   receiving Authentication Response between AAA server. 
    
    
6.3.3. Router-Accounting-Timer 
    
   It controls waiting time from sending Accounting request to receiving 
   Accounting Response between AAA server. 
    
    
6.3.4. Validity-Timer 
    
   This is an integer multiple of General-Query Interval in units of 
   second, and used by MLDA router to determine whether user 
   authentication is necessary or not. 
    
    

    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 23] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
6.3.5. Query-Interval-Timer 
    
   It is the same meaning as MLDv2. The Query Interval is the interval 
   between General Queries. 
    
    
6.3.6. Query-Response-Interval-Timer 
    
   It is the same meaning and takes the same default value as MLDv2. The 
   Max Response Time inserted into the periodic General Queries. 
    
    
6.3.7. Multicast-Address-Listener-Interval-Timer 
    
   It is the same meaning as MLDv2. The Multicast Address Listener 
   Interval is the amount of time that must pass before a MLDA router 
   decides there are no more users of a multicast address on a link. 
   This value MUST be ((the Robustness Variable) times (the Query 
   Interval)) plus (one Query Response Interval). 
    
    
6.3.8. Startup-Query-Interval-Timer 
    
   It is the same meaning and takes the same default value as MLDv2. The 
   Startup Query Interval is the interval between General Queries sent 
   by a Querier on startup. 
    
    
6.3.9. Startup-Query-Count 
    
   It is the same meaning and takes the same default value as MLDv2. The 
   Startup Query Count is the number of Queries sent out on startup, 
   separated by the Startup Query Interval. 
    
    
6.3.10 Accounting-Retransmission-Counter 
    
   The Accounting-Retransmission-Counter is the number of Accounting 
   messages a router retransmits after sending the first accounting 
   message to a host. The default value is zero. 
    
    
6.3.11 Immediate-Accounting 
    
   The Immediate-Accounting indicates whether a router will start the 
   accounting immediately after a MLDA Report is authenticated and 
   authorized or start the accounting when the subscribed multicast data 
   starts being forwarded. The values are TRUE and FALSE. The default 
   value is FALSE. 
    
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 24] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
    
6.3.12 Free-Ride 
    
   When the value is true, when Router-Authentication-Timer is expired, 
   the group is free to access. This variety depends on providerĀ²s 
   service. 
    
    
6.3.13 Accounting-Anyway 
    
   When the value is true, accounting is carried out despite the 
   expiration of Router-Accounting-Timer. 
    
    
7. Security Considerations 
    
   MLDA is based around an asymmetrical trust model in which the MLDA 
   router does not trust the MLDA client, but the MLDA client trusts the 
   MLDA router. Therefore, it may not be suitable for use in isolation 
   where mutual authentication is required. MLDA supports password and 
   challenge-response authentication mechanisms and inherits the 
   security concerns of each. For multicast content encryption related 
   technology, please refer to other IETF work. MLDA does not obstruct 
   snooping of multicast traffic by unauthorized client that have access 
   to media shared with multicast traffic. 
    
   Some of the security issues discussed in MLD document also apply here. 
   Please refer to MLDv2 document [MLDv2] for details. 
    
    
8. IANA Considerations 
    
   This document introduces the following new version and Types of ICMP 
   message that require allocation by IANA: 
    
        Type: 
            0x96: MLDA Listener Query  (MLDA Query) 
            0x97: MLDA Listener Acknowledgment  (MLDA ACK) 
            0x98: MLDA Listener Report (MLDA Report) 
    
    
    
    
    
Acknowledgments 
    
   Portions of this document are copied from [MLDv2]. The authors would 
   like to thank Takashi Shimizu, Hiroshi Ohta, and Yuji Chikahiro for 
   their valid advice, patience, and time to review the document and to 

    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 25] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
   provide their valuable suggestions. This document consists based on 
   an important discussion with them. 
    
    
    
    
    
Appendix 1. Example of AAA server interface using Radius authentication 
   and accounting  
    
   This section provides an example of the interface between Radius 
   server and MLDA router to transfer the information dedicated MLDA. 
   Here, these inforomation are transfered on the vender specific 
   attribute of Radius protocol, and these nay be transfered on other 
   attribute in future. The example is for illustration purposes only. 
   Implementations of the MLDA protocol are suggested but not required 
   to follow the example. However they should comply with the 
   specifications presented earlier in this document.  
    
   The below shows the attribute numbers. 
    
        Type26 (Vendor Specific Attribute) 
    
                Vendor Type90 : Accounting-multicast-group-address  
                                Multicast group address 
    
                Vendor Type91 : Auth-Info 
                                When a MLDA router gets a Report packet  
                                which has three Auxes (User Account,  
                                User Password, and Message), the  
                                Message data should be put in the "Auth  
                                Info". 
    
                Vendor Type92 : Auth-source-address 
                                Source address of Source list 
    
                Vendor Type93 : Validity-period 
    
                Vendor Type94 : change-flag-sequence-number 
                                When a MLDA router get the Change packet,  
                                the router will care two different 
                                sequences for BLOCK_OLD_SOURCES and 
                                ALLOW_NEW_SOURCES. For 
                                BLOCK_OLD_SOURCES: the MLDA router 
                                should operate an accounting stop 
                                sequence between a Radius server. And a 
                                new attributes, which is change-flag-
                                sequence-number, is transfered to the 
                                Radius server. The value of change-flag-

    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 26] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
                                sequence-number is generated at the MLDA 
                                router. 
    
                                For ALLOW_NEW_SOURCES: the MLDA router  
                                should operate an operation of 
                                authentication and accounting start with 
                                the same change-flag-sequence-numner on 
                                the BLOACK_OLD_SOURCES  in the previous 
                                operation. 
    
                Vendor Type110: User-MAC-address 
                                When a user authentication is operated  
                                with a MAC address of MLDA client, the 
                                MAC address information is transfered on 
                                the attribute of User-MAC-address. 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
References 
    
   [ICMPv6] 
        A. Conta and S. Deering, "Internet Control Message Protocol  
        (ICMPv6) for the Internet Protocol Version 6 (IPv6) 
        Specification", RFC 2463, December 1998 
    
   [RFC 2710] 
        Deering, S., Fenner, W., Haberman, B., "Multicast Listener  
        Discovery  (MLD) for IPv6", RFC 2710, November 1999. 
    
   [MLDv2] 

    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 27] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
        S. Deering, W. Fenner, and B. Haberman, "Multicast Listener 
        Discovery Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-XX. 
    
   [IPRA] 
        D. Katz, "IP Router Alert Option", RFC 2113, February 1997. 
    
   [RTR-ALERT]  C. Partridge and A. Jackson, "IPv6 Router Alert Option", 
        RFC 2711, October 1999. 
    
   [MD5] 
        R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm", RFC 
        1321, April 1992. 
    
   [RADIUS] 
        C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote 
        Authentication Dial In User Service (RADIUS)", RFC 2865, June 
        2000. 
    
    
    
    
    
    
   Author's Addresses 
    
           Tsunemasa Hayashi 
           NTT Network Innovation Laboratories 
           1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 
           Phone : +81 46 859 8790 
           Email : hayashi.tsunemasa@lab.ntt.co.jp 
    
           Haixiang He 
           Nortel Networks 
           600 Technology Park Drive 
           Billerica, MA 01801, USA 
           Phone : +1 978 288 7482 
           Email : haixiang@nortelnetworks.com 
    
           Akihiro Tanabe 
           NTT Access Network Service Systems Laboratories 
           1-6 Nakase Mihiama-ku, Chiba-shi, Chiba, 261-0023 Japan 
           Phone : +81 43 211 2115 
           Email : dandou@ansl.ntt.co.jp 
    
           Hiroaki Satou 
           NTT Network Service Systems Laboratories 
           3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 
           Phone : +81 422 59 4683 
           Email : satou.hiroaki@lab.ntt.co.jp 
    
    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 28] 
    
   Internet Draft        draft-hayashi-mlda-02         October, 2004 
    
    
           Teruki Niki 
           Matsushita Electric Industrial Co.,Ltd 
           Multimedia Systems Research-Laboratory 
           4-5-15 Higashi-Shinagawa Shinagawa-ku, Tokyo, 140-8632 Japan 
           Phone : +81 3 5460 2741 
           Email : niki.teruki@jp.panasonic.com 
 
    










































    
    
    
   Hayashi, He, Tanabe, Satou, Niki                          [Page 29]