Subject: mboned: IPv6 multicast address assignment using the DHCPv6 protocol

From: Jerome Durand <[email-masked]>
Date: Thu, 17 Jun 2004 11:56:54 +0200

Hi,

I would really like to have your comments on the document attached:
http://www.ietf.org/internet-drafts/draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00.txt

This I-D provides a simple solution to solve IPv6 multicast address 
assignment problem using the DHCPv6 protocol. I will present it at next 
IETF but I would like to know first your comments. I received already 
good contributions and comments and there are already interesting open 
questions.

Thanks a lot!

Jerome

Network Working Group                                          J. Durand
Internet-Draft                                               GIP RENATER
Expires: December 2, 2004                                   June 3, 2004

             IPv6 multicast address assignment with DHCPv6
           draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   This Internet-Draft will expire on December 2, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document provides a simple solution to solve IPv6 multicast
   address assignment problem using the DHCPv6 protocol.

Durand                  Expires December 2, 2004                [Page 1]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  SSM considerations . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Session announcement considerations  . . . . . . . . . . . . .  3
   5.  Review of existing assignment protocols  . . . . . . . . . . .  3
     5.1   MADCAP . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     5.2   SAP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     5.3   GLOP . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     5.4   Random assignment  . . . . . . . . . . . . . . . . . . . .  5
     5.5   ZMAAP - Zeroconf Multicast Address Allocation Protocol . .  5
   6.  Assignment with DHCPv6 . . . . . . . . . . . . . . . . . . . .  6
     6.1   New DHCPv6 options . . . . . . . . . . . . . . . . . . . .  6
       6.1.1   IA_MA option for IPv6 Multicast Addresses  . . . . . .  6
       6.1.2   Scope Option for IPv6 multicast address  . . . . . . .  8
     6.2   Address timers . . . . . . . . . . . . . . . . . . . . . .  8
     6.3   Client and server behavior . . . . . . . . . . . . . . . .  9
   7.  Group-ID consideration . . . . . . . . . . . . . . . . . . . . 10
   8.  Impact on the IPv6 multicast model . . . . . . . . . . . . . . 10
     8.1   Impact on the multicast protocols  . . . . . . . . . . . . 10
     8.2   Impact on the multicast session  . . . . . . . . . . . . . 10
   9.  Deployment scenarios - Case studies  . . . . . . . . . . . . . 11
     9.1   Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.2   Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.3   Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . 11
   10.   Security considerations  . . . . . . . . . . . . . . . . . . 12
   11.   Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . 12
   12.   Open issues / Discussions  . . . . . . . . . . . . . . . . . 12
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
   13.1  Normative references . . . . . . . . . . . . . . . . . . . . 13
   13.2  Informative references . . . . . . . . . . . . . . . . . . . 14
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15

Durand                  Expires December 2, 2004                [Page 2]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

1.  Introduction

   In the european IST project 6NET, the deliverable  D3.4.3 [10] "IPv6
   multicast address allocation study" was written after 18 months of
   practical experience with IPv6 multicast.

   This deliverable brought a complete analysis of the solutions
   existing for IPv6 multicast address assignment and highlighted the
   fact that no solution exists, matching the usual constraints:
   scalability, ease of use, deployment and configuration and
   availability of implementations. From the analysis of existing
   protocols, D3.4.3 [10] finally proposes, without details, mechanisms
   for IPv6 multicast address assignment. One of the proposal is to use
   the DHCPv6 protocol for IPv6 multicast address assignment.

   This document details how to assign IPv6 multicast addresses using
   the DHCPv6 protocol [8].

2.  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 RFC 2119 [1].

3.  SSM considerations

   The main need today for an assignment mechanism is address uniqueness
   in a defined part of a network. In the SSM model, as the channel is
   defined by the tuple (source address , group address), a collision
   can only occur if a host would like to be a sender for 2 different
   groups having the same address. Therefore, it is sufficient for a
   sender to choose different addresses for different channels, this is
   a decision local to the host. This document only considers the ASM
   model which is a bit more complex.

4.  Session announcement considerations

   This document does not address the session announcement problem. It
   only answers the question of large scale address assignemnt of IPv6
   multicast addresses. Announcement of the sessions can still be done
   using web pages, emails, directories, SAP, etc.

5.  Review of existing assignment protocols

5.1  MADCAP

   MADCAP [2] is a client-server protocol for IP multicast address
   assignment. MADCAP is part of a complete address allocation

Durand                  Expires December 2, 2004                [Page 3]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   architecture that includes MASC (to allocate blocks of multicast
   addresses to domains), and AAP (to allocate sub blocks to MADCAP
   servers) protocols.

   RFC 3306 [6] and Embedded-RP [11] make it possible to segment the
   IPv6 multicast address space without the need of any protocol. Using
   RFC 3306 [6], a site can derive IPv6 multicast addresses from its
   IPv6 unicast prefix. Embedded-RP [11] follows the same idea and the
   IPv6 multicast addresses depend on the RP address. These protocols
   avoid the need for MASC and AAP mentioned above.

   MADCAP could then handle the assignment of IPv6 multicast addresses
   on its own. Nevertheless, there have been no deployments of MADCAP
   for IPv4 and IPv6 since the release of the protocol's standard and
   the management of the client and MADCAP servers is too complex.
   However, it appears in contrast that DHCPv6 will be widely
   implemented and deployed (as DHCP for IPv4). Therefore, assigning
   IPv6 multicast addresses using DHCPv6 is a unique opportunity to
   solve the IPv6 multicast address assignment problem.

5.2  SAP

   SAP [4] is not per se an assignment mechanism. It was designed to
   announce multicast sessions. It is widely used to announce sessions
   and to assign multicast addresses in the IPv4 world. The SAP client
   fetches all the sessions advertised and chooses an address which is
   not yet assigned. This process means that:

   o  Few sessions are advertised

   o  All the sessions using addresses in the SAP assignment range are
      announced. Otherwise, a client could be assigned an address which
      is already used for another session. This is problematic as
      sessions are not always announced.

   o  An RP is deployed for FF0X::/16 as SAP announcements are done on
      the address FF0X::2:7FFE. This is not compatible with Embedded-RP
      [11]

   It appears that SAP assignment can be done in a limited scope (site,
   ISP...) but not in the whole global IPv6 multicast network as SAP
   does not scale if millions of multicast addresses are being used.

5.3  GLOP

   GLOP is defined for IPv4 in RFC 3180 [5]. GLOP makes it possible to
   embed the AS number in the IPv4 multicast address. It is then
   possible in IPv4 to derive addresses from a specific AS (256 IPv4

Durand                  Expires December 2, 2004                [Page 4]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   multicast addresses per AS).

   GLOP is not really an assignment mechanism. It makes it possible to
   segment the multicast address space into chunks that can be then
   assigned locally.

   IPv6 would make it possible to have many more addresses per AS, given
   the length of the address. Nevertheless, there is no interest in GLOP
   when having the possibility to derive IPv6 multicast addresses from
   an IPv6 prefix (RFC 3306, see section below). Therefore we can
   consider that GLOP is irrelevant in the IPv6 world.

5.4  Random assignment

   A calculation that was made in D3.4.3 [10] shows that for a 32 bits
   group-ID, the probability that at least 2 hosts choose the same
   address is above 0.3% if there are 5000 hosts requiring an address.

   From this we can conclude that:

   o  A random assignment could be used with IPv6 multicast addresses
      derived from /64 prefixes (RFC 3306). The chance that more than
      5000 multicast addresses are needed on the same link can be
      considered as rare

   o  This random assignment could also be used with embedded RP
      addresses if the RP is managing a few number of groups

   o  Random assignments could be used for scoped addresses if the
      number of the groups needed in the zone is low

   o  This form of assignment cannot be used in general for temporary
      addresses with a global scope as it would not be possible to
      assign more than 5000 IPv6 multicast addresses while keeping the
      probability of an address collision low

5.5  ZMAAP - Zeroconf Multicast Address Allocation Protocol

   This mechanism is very simple: when a node needs a multicast address,
   it asks its local multicast address allocation server (called the
   mini-MAAS) for an address, specifying the scope, the number of
   addresses needed and the desired lifetime. Then the mini-MAAS builds
   the IPv6 multicast addresses using a random function (at this stage
   the mini-MAAS uses addresses not assigned locally).

   Then the mini-MAAS checks that the address is not reserved by any
   other mini-MAAS in the same scope domain. The mini-MAAS does this by

Durand                  Expires December 2, 2004                [Page 5]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   sending an address claim message (ACLM), specifying the leases
   locally assigned. This message is sent to the group of the mini-MAAS,
   using transport layer UDP. The scope of this mini-MAAS group address
   is the same as the one needed for address assignment.

   Every mini-MAAS must defend any assignment locally made. When a
   mini-MAAS receives an ACLM, it must verify that the lease requested
   does not overlap with any local assignment. If there is an overlap,
   the mini-MAAS must reply with an address-in-use message (AIU). This
   message is also sent to the multicast group of the mini-MAAS.

   A mini-MAAS considers the lease assigned locally to be valid if it
   does not receive any AIU message within a certain time frame.

   ZMAAP assignment is not scalable. The problem is exactly the same as
   with the use of SAP. It is not likely that all hosts exchange address
   usages on a given group. This solution could be used only for small
   scopes (admin-local or site-local).

6.  Assignment with DHCPv6

6.1  New DHCPv6 options

   This section introduces new options for IPv6 multicast address
   assignment with DHCPv6.

6.1.1  IA_MA option for IPv6 Multicast Addresses

   RFC 3315 [8] defines the following options for Identity Associations
   (IA):

   o  IA_NA option for Non temporary Addresses

   o  IA_TA option for Temporary Addresses

   This document introduces a third option: the IA_MA option for IPv6
   Multicast Addresses. It is used to carry an IA_MA, the parameters
   associated with the IA_MA, and the addresses associated with the
   IA_MA. The format of the IA_MA option is:

Durand                  Expires December 2, 2004                [Page 6]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          OPTION_IA_MA         |          option-len           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        IAID (4octets)                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         .                         IA_MA-options                         .
         .                                                               .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code: OPTION_IA_MA (21)

   option-len: 4 + length of IA_MA-options field

   IAID: The unique identifier for this IA_MA; the IAID must be unique
      among the identifiers for all of this client's IA_MAs. The number
      space for IA_MA IAIDs is separate from the number space for IA_NA
      and IA_TA IAIDs

   IA_MA-Options: Options associated with this IA_MA

   The IA_MA-options field encapsulates those options that are specific
   to this IA_MA. For example, all of the IA Address Options carrying
   the multicast addresses associated with this IA_MA are in the
   IA_MA-options field.

   Each IA_MA carries one "set" of multicast addresses; that is, at most
   one address per session created by the client requiring an address.

   An IA_MA option may only appear in the options area of a DHCP
   message. A DHCP message may contain multiple IA_MA options. The
   status of any operations involving this IA_MA is indicated in a
   Status Code option in the IA_MA-options field.

   Note that an IA has no explicit "lifetime" or "lease length" of its
   own. When the valid lifetimes of all of the addresses in an IA_MA
   have expired, the IA can be considered as having expired.

   An IA_MA option does not include values for T1 and T2. A client MAY
   request that the lifetimes of multicast addresses be extended by
   including the addresses in a IA_MA option sent in a Renew or Rebind
   message to a server. For example, a client would request an extension
   on the lifetime of a multicast address to allow an application to
   continue a multicast session.

   The client obtains new multicast addresses by sending an IA_MA option

Durand                  Expires December 2, 2004                [Page 7]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   with a new IAID to a server. The server will generate new multicast
   addresses and return them to the client. The client should request
   new multicast addresses before the lifetimes on the previously
   assigned addresses expire.

   A server MUST return the same set of multicast address for the same
   IA_MA (as identified by the IAID) as long as those addresses are
   still valid. After the lifetimes of the addresses in an IA_MA have
   expired, the IAID may be reused to identify a new IA_MA with new
   multicast addresses.

   This option MAY appear in a Confirm message if the lifetimes on the
   multicast addresses in the associated IA have not expired.

6.1.2  Scope Option for IPv6 multicast address

   The scope option for IPv6 multicast addresses is used by the clients
   to request multicast addresses with a certain scope. It is included
   in the IA address option IAaddr-options field defined in section 22.5
   of RFC 3315 [8]. A user can attach more than one scope option for
   IPv6 multicast address to an IA address option if the client does not
   know exactely the scope it wants to request but has a set of adequat
   scope values.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         OPTION_SCOPE          |          option-len           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | scope |  res  |
       +-+-+-+-+-------+

   option-code: OPTION_SCOPE (22)

   option-len: 1

   scope: The scope value for the requested IPv6 multicast address,
      according to values defined in RFC 3513 [9]

   res: This field is reserved for future use. The 4 bits of this field
      MUST be set to 0

6.2  Address timers

   The IA address option defined in RFC 3315 [8] contains the following
   32 bits fields:

Durand                  Expires December 2, 2004                [Page 8]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   o  preferred-lifetime: The preferred lifetime for the IPv6 address in
      the option, expressed in units of seconds

   o  valid-lifetime: The valid lifetime for the IPv6 address in the
      option, expressed in units of seconds

   We suggest to use these fields, usually defined for unicast
   addresses, for IPv6 multicast addresses, with the definition written
   above.

   The maximum value for these lifetimes is 2^32 seconds or 49710 days
   equivalent to 136 years. Therefore a host that wants to be assigned
   an address for a 2 days session occuring in 30 days can request an
   address with a preferred lifetime value of 32 days. According to the
   IPv6 multicast addressing space available, servers should allow this
   type of requests, or at least should permit a certain number of
   long-term assignment per host or authenticated host. The address is
   directly assigned by the DHCP server when the request is received. We
   suggest here not using the parameters minDesiredStartTime and
   maxDesiredStartTime specified in RFC 2771 [3] which bring too much
   complexity for the assignment and don't really make sense for IPv6
   where many addresses are available.

6.3  Client and server behavior

   The procedures to request an IPv6 multicast address is more or less
   the same than the ones described in RFC 3315 [8] to request a
   temporary IPv6 address. The differences are following:

   o  The client uses IA-type IA_MA described above to ask for IPv6
      multicast addresses.

   o  The client SHOULD use the Scope Option in solicit and request
      messages to tell the server the scope wanted for the IPv6
      multicast address requested. It can include more than one Scope
      Option for IPv6 multicast address per addresses requested in case
      the client does not know exactely the scope it wants to request
      but has a set of adequat scope values.

   o  The client SHOULD specify the lifetimes for every address it wants
      to be assigned in solicit, request, renew and rebind messages.

   o  The server MUST assign addresses only if it can assign an address
      matching one of the scope requested. In case the server can't
      assign an address with the requested scopes, it must include the
      Status Code Option NoAddrsAvail in the advertise and reply
      messages and should include a status message with the scopes that
      can be assigned by the server and their description.

Durand                  Expires December 2, 2004                [Page 9]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   o  If no scope option is specified by the client, the server can
      assign a multicast address with any scope. It can be a default
      scope value configured by the DHCP server administrator.

7.  Group-ID consideration

   RFC 3307 [7] defines guidelines for the choice of IPv6 multicast
   group identifier (the last 32 bits of the IPv6 multicast address). It
   specifies that for dynamic IPv6 multicast address allocation, the
   group-ID MUST be in the range 0x80000000 to 0xFFFFFFF.

   Addresses assigned with DHCPv6 must not overlap with addresses
   assigned by another mechanism (MADCAP, multicast DAD, random
   assignment...). Therefore we propose to reserve the range from
   0x90000000 to 0x9FFFFFFF for group-IDs assigned with DHCPv6,
   understanding that no other assignment mechanism can assign group-IDs
   in this range. These values were suggested in the document 6NET
   D3.4.3 [10].

8.  Impact on the IPv6 multicast model

8.1  Impact on the multicast protocols

   There is a strong interaction between the IPv6 multicast addresses
   and the IPv6 multicast protocols, for instance the group-to-RP
   mapping. Depending on the address choosen, a set of protocols and
   resources will be used. Assigning the IPv6 multicast address with
   DHCPv6 gives a network administrator the complete control of the
   multicast resources to be used.

8.2  Impact on the multicast session

   The continuous problem of multicast address assignment is depicted by
   the following scenario: one person initiates a multicast session and
   requests an address for it. Then, other people join the session and,
   finally, the person who asked for the address leaves the group. The
   other partipants that stay online are still using an address that can
   be released by the first participant, and reassigned by the server.

   This scenario is out of the scope of this document. This means that
   there is no way to be sure that the address assigned by DHCPv6 is not
   in use by other people. It is exactly the same that for IPv6 unicast.
   If you are assigned an IPv6 unicast address with DHCPv6, it is
   possible that another person on the same link manually configured the
   same address.

   Nevertheless, we can consider the technical and privacy issues. From

Durand                  Expires December 2, 2004               [Page 10]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   a technical point of view, the consequence of IPv6 address
   overlapping in the same scoped zone is that clients will receive more
   flows, making it possible to overload links and/or CPU. From the
   privacy point of view, there is no impact at all.  As the client are
   in the same scoped zone, they could join each other's sessions
   anyhow. Privacy for IPv6 multicast sessions is established by using
   encryption mechanisms.

9.  Deployment scenarios - Case studies

   This section gives examples of DHCPv6 deployments for IPv6 multicast
   address assignment.

9.1  Scenario 1

   Consider a site having deployed a DHCPv6 server and having one RP for
   a site-local scope (scope 5). In this simple scenario, the DHCPv6
   server can assign the complete set of addresses with a site-local
   scope.

   We have the same scenario if the site deploys one RP for global scope
   with embedded-RP technology. The DHCPv6 server of the site can assign
   the complete set of addresses derived from the RP's address (see
   Embedded-RP [11]).

9.2  Scenario 2

   Consider a research center having deployed one DHCPv6 server for the
   entire site, and having several labs having each a multicast scope
   for their own usage. Every lab might have for example a scope
   admin-local (scope 4), and the global research center may have the
   scope site-local (scope 5). The problem of the DHCPv6 server is to
   assign appropriate addresses for each of the lab.

   The server can retrieve information about the location of the client
   according to the explanation given in section 11 of RFC 3315 [8]. The
   server can determine this way in which lab the client is and assign
   adequate addresses. This way a server can assign the same address
   twice to different clients in different labs.

9.3  Scenario 3

   Consider an ISP providing a global RP service to its customers. The
   ISP decided to use embedded-RP technology for this RP. Every
   customers having deployed a DHCPv6 server would like to assign IPv6
   multicast addresses based on the RP of their ISP. The problem is to
   avoid overlap between addresses assigned by every DHCPv6 servers.

Durand                  Expires December 2, 2004               [Page 11]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   In this scenario, the ISP having deployed an RP would allocate a
   range of IPv6 multicast addresses based on its RP to every customer
   having subscribed for the service (as explained in section 5.2 of
   Embedded-RP [11]). This allocation would be typically hand-off
   allocation, as it is done between ISP and big customers (not
   end-users at home) for unicast. This way, every DHCPv6 server is
   configured with a different multicast address range, all matching the
   same RP. This means that ISPs need to allocate IPv6 multicast
   addresses to their customers, as they do today for IPv6 unicast.
   Nevertheless, we can note here that any customer could deploy its own
   embedded-RP rather than using the one of its ISP, which simplifies
   this scenario.

   Another similar scenario is a big organization that has set up
   multicast across many sites with the scope 8 (organization). Every
   site of the organization has a DHCPv6 server, and it must be ensured
   that addresses assigned in the different sites for scope 8 will not
   overlap. A solution to this problem is to allocate a subset of the
   complete organizational scope address space to each site.

10.  Security considerations

   The security considerations related to the DHCPv6 protocol are
   discussed in the security considerations section of [8].

   Security and pricacy considerations of the assignment of IPv6
   multicast addresses are discussed in the Section 8.2 of this
   document.

11.  Acknowledgement

   The author would like to thank Bernard Tuy, Stig Venaas, Christian
   Strauf and Pekka Savola for their good contributions to this memo.
   The author would also like to thank Ralph Droms who took time to
   consider the IPv6 multicast assignment problem and introduced the
   concept of the identity association for IPv6 multicast addresses. The
   author would also like to thank all the people having worked on the
   6NET Deliverable 3.4.3, which was the initial document that raised
   the complete problematic of IPv6 multicast assignment.

12.  Open issues / Discussions

   Here are the current discussions and questions about this document:

   o  Split in 2 different drafts: one for the DHC WG with the
      description of the DHCPv6 options and mechanismsand; the other one
      for the MBoned WG talking of the existing assignment techniques

Durand                  Expires December 2, 2004               [Page 12]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

      and consequences on the model.

   o  Maybe no need to give a range for group identifiers. We could
      leave things up to the network admin. Nevertheless, this feature
      is nice for not overlapping with protocols like "multicast DAD"
      and "random choice in a specific range for not necessary unique
      addresses". Also it is an interesting feature to see in a network
      the addresses that were assigned with DHCPv6

   o  Timers could be specified with a new DHCPv6 option rather than
      overloading the timers of the address

   o  Scope option for DHCPv6 could be mandatory so that we are sure the
      user knows what he does. Another option is that the server could
      assign an address not in the scope requested, and the client could
      then decide weither he wants to keep it or not. Problem about this
      is that a user could be given

   o  DHCPv6 usually has impacts on the kernel (IPv6 unicast address
      assignment, DNS address indication...) and the problem of
      multicast address assignment is in user space. Are there some
      problems that could be coming from this ?

13.  References

13.1  Normative references

   [1]  S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [2]  S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic
        Client Allocation Protocol (MADCAP)", RFC 2970, December 1999.

   [3]  R. Finlayson, "An Abstract API for Multicast Address
        Allocation", RFC 2771, February 2000.

   [4]  M. Handley, C. Perkins and E. Whelan, "Session Announcement
        Protocol (SAP)", RFC 2974, October 2000.

   [5]  D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", RFC 3180,
        September 2001.

   [6]  B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 Multicast
        Addresses", RFC 3306, August 2002.

   [7]  B. Haberman, "Allocation Guidelines for IPv6 Multicast
        Addresses", RFC 3307, August 2002.

Durand                  Expires December 2, 2004               [Page 13]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   [8]  R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney,
        "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC
        3315, July 2003.

   [9]  R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

13.2  Informative references

   [10]  6NET project partners, "6NET D3.4.3 - IPv6 multicast address
         allocation study", May 2003.

   [11]  P. Savola and B. Haberman, "Embedding the Rendezvous Point (RP)
         Address in an IPv6 Multicast Address", April 2004.

Author's Address

   Jerome Durand
   GIP RENATER
   151 Bd de l'Hopital
   Paris  75013
   France

   Phone: +33 1 53 94 20 30
   EMail: [email-masked]

Durand                  Expires December 2, 2004               [Page 14]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Durand                  Expires December 2, 2004               [Page 15]

Internet-Draft    IPv6 multicast address assignment with DHCPv6June 2004

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Durand                  Expires December 2, 2004               [Page 16]