MALLOC Working Group                                        B. Haberman
   Internet Draft                                          Nortel Networks
   draft-ietf-malloc-ipv6-guide-02.txt
   April 2001
   Expires October 2001


                     Dynamic Allocation Guidelines
                      for IPv6 Multicast Addresses


Status of this Memo

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

   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 document specifies guidelines to be used when allocating IPv6
   multicast addresses.  The purpose of these guidelines is to reduce
   the probability of IPv6 multicast address collision, not only at the
   IPv6 layer, but also at the MAC layer of media that utilizes IEEE
   802 addressing.


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


2. Introduction

   This document specifies guidelines to be used when allocating IPv6
   multicast addresses.  The purpose of these guidelines is to reduce

Haberman                                                             1



Internet Draft    IPv6 Multicast Address Guidelines         July 2000

   the probability of IPv6 multicast address collision, not only at the
   IPv6 layer, but also at the MAC layer of media that utilizes IEEE
   802 addressing.

   With the current IPv6 multicast address architecture [RFC 2373] and
   the proposed extension to that architecture specified in [NEW ARCH],
   a set of guidelines is needed for multicast address allocation
   servers [RFC 2908] to use in assigning IPv6 multicast addresses.

   These guidelines specify how the lowest 32 bits of the IPv6
   multicast address are chosen and assigned.  The guidelines specify
   several mechanisms that can be used to determine the lowest 32 bits
   of the multicast address.  By supporting several mechanisms, these
   guidelines can accommodate the varying capabilities of multicast
   address allocation servers.

3. Assignment of New IPv6 Multicast Addresses

   The current approach [RFC 2464] to map IPv6 multicast addresses into
   IEEE 802 MAC addresses takes the low order 32 bits of the IPv6
   multicast address and uses it to create a MAC address.  Group IDs
   less than or equal to 32 bits long will generate unique MAC
   addresses within a given multicast scope.

   The goal of this document is to present several mechanisms
   implementers and operators can use to select the group ID portion of
   the address so that the possibility of collisions at the IP layer
   and at the IEEE 802 layer is reduced.  The following section
   presents several different mechanisms of varying complexity that can
   be used to select an appropriate group ID.


4. Group ID Selection Guidelines

   The following guidelines assume that the upper 96 bits of the IPv6
   multicast address have been initialized according to [RFC 2373] and
   [NEW ARCH].

   The T flag of each dynamically allocated multicast address MUST be
   set to '1'.  Permanent addresses MUST NOT be allocated using the
   multicast address allocation architecture.

   The group ID portion of the address is set using either a pseudo-
   random 32-bit number or a 32-bit number created using the guidelines
   in [RFC 1750].  Possible approaches to creating a pseudo-random
   number include using an MD5 message-digest [RFC 1321] or portions of
   an NTP [RFC 1305] timestamp.

   The high-order bit of the Group ID MUST be set to '1'.  This will
   distinguish the dynamically allocated addresses from the permanently


Haberman                                                             2



Internet Draft    IPv6 Multicast Address Guidelines         July 2000

   assigned multicast addresses defined in [RFC 2375] at the MAC layer
   on any media that utilizes IEEE 802 addressing.

   A request for multiple multicast addresses SHOULD be handled
   atomically.  One possible approach is to use the initial group ID,
   created using the guidelines above, as the base address in a
   contiguous block of multicast addresses.  Another approach is to
   create multiple group IDs and generate the appropriate multicast
   addresses.


5. Multicast Address Lifetime

   The lifetime of the assignment of unicast prefix-based multicast
   addresses MUST be less than or equal to the Valid Lifetime field in
   the Prefix Information option contained in the Neighbor Discovery
   Router Advertisement message [RFC 2461].


6. Security Considerations

   This document does not have any known impact on Internet
   infrastructure security.


7. Acknowledgements

   The author would like to thank Dave Thaler and Steve Deering for
   their thorough review of this document.


8. References

   [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [NEW ARCH] Haberman, B., Thaler, D., "Unicast Prefix-based IPv6
              Multicast Addresses", Work in Progress, January 2001.

   [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

   [RFC 2908] Thaler, D., Handley, M., and Estrin, D., "The Internet
              Multicast Address Allocation Architecture",
              RFC 2908, September 2000.

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

   [RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

Haberman                                                             3



Internet Draft    IPv6 Multicast Address Guidelines         July 2000


   [RFC 1305] Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

   [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC 1750] Eastlake, D., Crocker, S., Schiller, J., "Randomness
              Recommendations for Security", RFC 1750, December 1994.

   [RFC 2375] Hinden, R., Deering, S., "IPv6 Multicast Address
              Assignments", RFC 2375, July 1998.

   [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.





































Haberman                                                             4





AuthorÆs Address

   Brian Haberman
   Nortel Networks
   4309 Emperor Blvd.
   Suite 200
   Durham, NC  27703
   1-919-992-4439
   Email : haberman@nortelnetworks.com












































Haberman                                                             5