[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 3307

   MALLOC Working Group                                        B. Haberman
   Internet Draft                                          Nortel Networks
   draft-ietf-malloc-ipv6-guide-03.txt
   June 2001
   Expires December 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 that must be implemented by any
   entity responsible for 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.


Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   1. Terminology.....................................................2
   2. Introduction....................................................2
   3. Applicability...................................................2
   4. Assignment of New IPv6 Multicast Addresses......................3
   5. Group ID Selection Guidelines...................................3
   6. Multicast Address Lifetime...........Error! Bookmark not defined.
   7. Security Considerations.........................................4
   8. IANA Considerations.............................................4

Haberman                                                             1


Internet Draft    IPv6 Multicast Address Guidelines         July 2000

   9. Acknowledgements................................................4
   10. References.....................................................4
   AuthorÆs Address...................................................6
   Full Copyright Statement...........................................6


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

   The term "group ID" throughout this document conforms to the
   definition contained in section 2.7.2 of RFC 2373 [RFC 2373], that
   is, the low-order 32 bits of the address.


2. Introduction

   This document specifies guidelines that MUST be implemented by any
   entity responsible for 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.

   With the current IPv6 address architecture [RFC 2373] and the
   proposed extension to the multicast address architecture specified
   in [NEW ARCH], a set of guidelines is needed for entities assigning
   any flavor of IPv6 multicast addresses.

   These guidelines specify how the low-order 32 bits (henceforth
   called the group ID) of the IPv6 multicast address are chosen and
   assigned.  The guidelines specify several mechanisms that can be
   used to determine the group ID of the multicast address.  By
   supporting several mechanisms, these guidelines can accommodate the
   varying capabilities of multicast address allocation schemes.


3. Applicability

   These guidelines are designed to be used in any environment in which
   IPv6 multicast addresses are delegated, assigned, or selected.
   These guidelines are not limited to use by MADCAP [RFC 2730]
   servers.  The following is a non-exhaustive list of applications of
   these guidelines:

        - Source-specific multicast application servers can generate an
           SSM group address by generating a 96 bit multicast prefix as
           defined in [NEW ARCH] and concatenating that with a group ID
           as defined in this document.


Haberman                                                             2


Internet Draft    IPv6 Multicast Address Guidelines         July 2000

        - A MADCAP server allocates IPv6 multicast addresses generated
           in the same manner as the SSM server.  This approach gives
           network administrators centralized control over multicast
           address delegation.
        - A MADCAP server allocates IPv6 multicast addresses conforming
           to section 2.7.2 of RFC 2373 [RFC 2373] with the group ID
           being created using the rules defined in this document.
        - Nodes supplying multicast services in a zeroconf environment
           generate multicast addresses without the need of centralized
           control.


4. 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 (the group ID) 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 that can
   be used to select the group ID portion of the multicast 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.


5. 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] or
   [NEW ARCH].

   The T flag of each dynamically allocated multicast address MUST be
   set to '1' [RFC 2373].

   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
   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

Haberman                                                             3


Internet Draft    IPv6 Multicast Address Guidelines         July 2000

   contiguous block of multicast addresses.  Another approach is to
   create multiple group IDs and generate the appropriate multicast
   addresses.

   Organizations wishing to reserve a permanent group ID value for use
   across multiple domains MUST direct their request to IANA.
   Permanent group IDs MUST fall in the range 0x40000000 to 0x7FFFFFFF.


6. Security Considerations

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


7. IANA Considerations

   Following the policies outlined in [RFC 2434]:

           - Permanent multicast addresses, like those defined in [RFC
              2375], are allocated with group ID's in the range of 1 to
              0x3FFFFFFF on a First Come First Served basis
           - Permanent group ID's are allocated on a First Come First
              Served basis in the range 0x40000000 to 0x7FFFFFFF
           - The range 0x80000000 to 0xFFFFFFFF is reserved for
              Private Use


8. Acknowledgements

   The author would like to thank Dave Thaler, Steve Deering, Allison
   Mankin, and Thomas Narten for their thorough review of this
   document.


9. 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 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP14, March 1999.

   [RFC 2730] Hanna, S., Patel, B., Shah, M., "Multicast Address
              Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,

Haberman                                                             4


Internet Draft    IPv6 Multicast Address Guidelines         July 2000

              December 1999.

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

   [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.





































Haberman                                                             5




AuthorÆs Address

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


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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 ore 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 assigns.

   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
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
















Haberman                                                             6


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