MALLOC Working Group                                         B. Haberman
        Internet Draft                                           Nortel Networks
        draft-haberman-malloc-ipv6-prefix-01.txt
        March 2000
        Expires September 2000
     
     
                          Dynamic Allocation Guidelines for
                    Network Prefix-based 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
     
        With the current multicast address architecture and the proposed
        multicast address architecture, a set of guidelines is needed for
        multicast address allocation servers to use in assigning IPv6 multicast
        addresses.  The purpose of these rules is to reduce the possibility of
        address collision not only at layer 3, but also on devices at layer 2.
     
     
     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
     
        With the current multicast address architecture [RFC 2373] and the
        multicast address architecture proposed in [NEW ARCH], a set of
        guidelines is needed for multicast address allocation servers [MALLOC]
        to use in assigning IPv6 multicast addresses.  The purpose of these
        rules is to reduce the possibility of address collision not only at
        layer 3, but also on devices at layer 2.
     
        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
     
     
     Haberman                                                             1
     
     
     
     Internet Draft   IPv6 Multicast Address Architecture        March 2000
     
        multicast address.  By having several mechanisms of varying complexity,
        implementers and operators have the flexibility to choose a mechanism
        that is appropriate for their application.
     
     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 ID's less
        than or equal to 32 bits long will generate unique MAC addresses.
     
        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
        mechanism 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 set up.  For unicast network prefix-based
        multicast addresses, the set up of those bits is done in the following
        manner:
     
                o  An IPv6 multicast address prefix is initialized with the
                   appropriate flags and scope fields
                o  The IPv6 Network Prefix is inserted into the address and the
                   plen field is set.  The Network Prefix is obtained from the
                   periodic Router Advertisements.
                o  The reserved field in the IPv6 multicast address is set to
                   zero
     
        With the multicast address architecture in [RFC 2373], the set up of
        those bits is done in the following manner:
     
                o  An IPv6 multicast address prefix is initialized with the
                   appropriate flags and scope fields
                o  The reserved field in the IPv6 multicast address is set to
                   zero
     
        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 are to
        use an MD5 message-digest [RFC 1321] or portions of an NTP [RFC 1305]
        timestamp.
     
        Requests for more than one multicast address 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. Security Considerations
     
        This document does not have any direct impact on Internet
        infrastructure security.
     
     
     Haberman                                                             2
     
     
     
     Internet Draft   IPv6 Multicast Address Architecture        March 2000
     
     
     
     6. References
     
        [RFC 2026] S. Bradner, "The Internet Standards Process -- Revision 3",
                   BCP 9, RFC 2026, October 1996.
     
        [NEW ARCH] B. Haberman, "IP Version 6 Multicast Addressing
                   Architecture", draft haberman
                                       -        -ipngwg-mcast-arch-00.txt,
                   December 1999.
     
        [RFC 2373] R. Hinden, S. Deering, "IP Version 6 Addressing
                   Architecture", RFC 2373, July 1998.
     
        [MALLOC]   D. Thaler, M. Handley, and D. Estrin, "The Internet
                   Multicast Address Allocation Architecture",
                   draft-ietf-malloc-arch-04.txt, January 2000.
     
        [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
                   Requirement Levels", RFC 2119, BCP14, March 1999.
     
        [RFC 2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet
                   Networks", RFC 2464, December 1998.
     
        [RFC 1305] D. Mills, "Network Time Protocol (Version 3) Specification,
                   Implementation", RFC 1305, March 1992.
     
        [RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
                   April 1992.
     
        [RFC 1750] D. Eastlake, S. Crocker, J. Schiller, "Randomness
                   Recommendations for Security", RFC 1750, December 1994.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Haberman                                                             3
     
     
     
     
     
     Author's Address
     
        Brian Haberman
        Nortel Networks
        4309 Emperor Blvd.
        Suite 200
        Durham, NC  27703
        1-919-992-4439
        Email : haberman@nortelnetworks.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Haberman                                                             4