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