MBONE Deployment R. Pashby Internet-Draft Bowhead Expires: October 14, 2006 April 12, 2006 IPv6 Multicast Scoped Address Assignment Guidance draft-pashby-ipv6-mc-scoped-addr-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 October 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The purpose of this document is to define IPv6 Multicast Id ranges that will not allow overlap between dynamically assigned global scoped addresses and dynamically assigned non-global scoped addresses, specifically dynamically assigned link-local scoped addresses. Pashby Expires October 14, 2006 [Page 1] Internet-Draft IPv6 MCast Scoped Addr April 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Justification . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Multicast Group ID Assignment Guidelines . . . . . . . . . . . 5 5. Modifications to RFC3307 . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Pashby Expires October 14, 2006 [Page 2] Internet-Draft IPv6 MCast Scoped Addr April 2006 1. Introduction The purpose of this document is to define IPv6 Multicast Id ranges that will not allow overlap between dynamically assigned global scoped addresses and dynamically assigned non-global scoped addresses, specifically dynamically assigned link-local scoped addresses. RFC3307 [1] defines IPv6 Multicast Group ID ranges for the following Permanent Addresses, Permanent Identifiers and Dynamic Addresses. However, there are certain multicast addresses that need to be assigned for closed systems that should not collide with the Group IDs used within the Internet. This document further defines the Dynamic Addresses into two ranges Dynamically Assigned Global (DAG) addresses and Dynamically Assigned Non-Global (DANG) addresses. The DANG range is further broken down to Dynamically Assigned Link-Local (DALL) addresses and the rest reserved for future. Future uses might be for Site-Local Scoped and Organization Scoped ranges. The DALL range may be used to simplify the design of MLD Snooping layer 2 switches. It is understood that there is the Scope field in the IPv6 address; however the issue here is keeping unique ranges that are guaranteed not to overlap at the link-layer. Link-layer uniqueness is critical within organizations because most of the multicast will be controlled via layer 2 switches. Given the definitions in RFC3307 [1] the new ranges should be assigned from the currently defined Dynamically Assigned Addresses, since they are not Permanently Assigned Addresses (from the Internet perspective). - Dynamically Assigned Global (DAG) Addresses - Dynamically Assigned Non-Global (DANG) Addresses - Reserved Dynamically Assigned Non-Global Addresses - Dynamically Assigned Link-Local (DALL) Addresses The Solicited Node Multicast Addresses will fall into the last range. RFC3171 [3] also defines the Local Network Control Block (LNCB) address range for IPv4. A similar range should be defined to possibly simplify the design of MLD Snooping layer 2 switches, as defined by mldsnoop [4]. This mldsnoop [4] document also recommends that the DANG and LNCB addresses be forwarded to all layer 2 ports on a MLD snooping switch. Pashby Expires October 14, 2006 [Page 3] Internet-Draft IPv6 MCast Scoped Addr April 2006 2. Applicability These guidelines are to be used in any environment in which IPv6 multicast addresses are delegated, assigned, or selected. They are critical to be used where overlap of multiple multicast flows can happen on layer 2 switches. 3. Justification If a host is flooded with high amounts of multicast traffic that is not destined to the host (but matches a layer 2 multicast group that the host has joined), then the traffic could cause the host to fail to perform its function. All hosts are required to join multicast groups associated with their assigned IPv6 addresses. Hosts may also join a multicast group based on an MD5 hash of its hostname. These multicast addresses fall into the multicast group id range 0xFF000000 - 0xFFFFFFFF. This could mean that every host joins 3 different multicast groups, i.e. link local address, global address and name queries. There is a method for creating dynamic multicast groups, which defines that, the multicast group id to be generated by a 32 bit random number and then setting the highest bit. This makes the range 0x80000000 - 0xFFFFFFFF, which overlaps the range above. Every time a new multicast group is created a new group address is created. There is a small, but definitely non-zero, probability that one host on the sub-network joining one of these dynamic multicast groups that it would cause an unsuspecting host to be flooded with the multicast traffic. One may argue that since the probability is small it should not be of concern. However, in many systems even a small probability is unacceptable, because it could have catastrophic consequences. One of the benefits of IPv6 is to create large numbers of small sensors that each has an IPv6 address. It is perceived that these sensors would not have much processing power. Thus, if one of these sensors happened to be flooded with multicast traffic that happened to match its required multicast group, it could end up not performing its required duties. The proposed solution is to reduce the range of the dynamically created multicast address to guarantee that there is no overlap with the multicast group ids that a host is required to join. The easiest way is to reduce the range from 0x80000000 - 0xFFFFFFFF to the range of 0x80000000 - 0xBFFFFFFF. This is accomplished by setting the highest 2 bits of the 32 bit random number to 0b10. Pashby Expires October 14, 2006 [Page 4] Internet-Draft IPv6 MCast Scoped Addr April 2006 The major drawback to this approach is it reduces the range but increases the probability of a collision between two groups created by this method. The original range allowed for 2,147,483,648 (2B Range) possible multicast ids. The reduced range, produces 1,073,741,824 (1B Range) possible multicast ids. This reduction does not significantly increase the probability of two groups colliding as can be seen by the following tables. Probability of Collisions +------------------+----------+----------+ | Number of Groups | 2B Range | 1B Range | +------------------+----------+----------+ | 100 | <0.001% | <0.001% | | 1000 | 0.023% | 0.047% | | 10000 | 2.3% | 4.5% | +------------------+----------+----------+ Number of Groups with Probability of Collisions +-------------+----------+----------+ | Probability | 2B Range | 1B Range | +-------------+----------+----------+ | 0.01% | 650 | 456 | | 0.1% | 2077 | 1465 | | 1% | 6572 | 4647 | +-------------+----------+----------+ Given that the probability of collisions is not significantly increased and the possibility of collision with hosts' required groups is decreased to zero, it is recommended that the dynamically created multicast id range be decreased to 0x80000000 - 0xBFFFFFFF. 4. Multicast Group ID Assignment Guidelines 4.1. Permanent Assigned Addresses The range specified for Permanent Assigned Addresses is 0x00000001 - 0x3FFFFFFF. This is the same as defined in RFC3307. 4.1.1. Local Network Control Block The range specified for Local Network Control Block is 0x00000001 - 0x000000FF. There is a related document [snoop] that recommends that this range be sent to every interface on a layer 2 switches that supports MLD snooping mldsnoop [4]. Pashby Expires October 14, 2006 [Page 5] Internet-Draft IPv6 MCast Scoped Addr April 2006 4.2. Permanent Assigned IDs The range specified for Permanent Assigned Identifiers is 0x40000000 - 0x7FFFFFFF. This is the same as defined in RFC3307. 4.3. Dynamically Assigned Addresses This range was previously defined in RFC3307 but called Dynamic IPv6 Multicast Addresses. It is broken down into the following ranges. 4.3.1. Dynamically Assigned Global Scoped Addresses This range would be used for Scope field values 9 - E. The range specified for Dynamically Assigned Global Scoped Addresses 0x80000000 - 0xBFFFFFFF. This range was selected to provide the largest range of addresses for dynamic allocation. 4.3.2. Dynamically Assigned Non-Global Addresses This range would be used for Scope field values 1 - 8. The range specified for Dynamically Assigned Non-Global Scoped Addresses 0xC0000000 - 0xFFFFFFFF. 4.3.2.1. Reserved Dynamically Assigned Non-Global Addresses This range is reserved for future use. Possible future use would be for Site-Local Scoped and Organization Scoped addresses. The range is 0xC0000000 - 0xEFFFFFFF. 4.3.2.2. Dynamically Assigned Link-Local Addresses The range for Dynamically Assigned Link-Local Scoped Addresses is 0xF0000000 - 0xFFFFFFFF. This range was chosen so that it would include the Solicited Node Multicast Addresses 0xFF000000 - 0xFFFFFFFF. There is a related document [snoop] that recommends that this range be sent to every interface on a layer 2 switches that supports MLD snooping mldsnoop [4]. 5. Modifications to RFC3307 5.1. Permanent IPv6 Multicast Addresses (section 4.1) Add the definitions of the LCNB ranges as defined above. Pashby Expires October 14, 2006 [Page 6] Internet-Draft IPv6 MCast Scoped Addr April 2006 5.2. Dynamic IPv6 Multicast Addresses (section 4.3) Add the definitions of the DAG and DANG ranges as defined above. 5.3. Server Allocation (section 4.3.1) Change the range from 0x80000000 - 0xFFFFFFFF to 0x80000000 - 0xBFFFFFFF. 5.4. Host Allocation Section (section 4.3.2) Replace the last sentence with: This can be accomplished by setting the high-order two bits of the generated number to 10 (binary). 6. Security Considerations The allocation mechanisms described in this document do not alter the security properties of either the Any Source or Source Specific multicast service models of IPv4 and IPv6. The potential to allocate large blocks of addresses can lead to Denial-of-Service attacks. A more in-depth discussion of the security issues surrounding dynamic allocation of multicast addresses can be found in RFC2908 [2]. 7. IANA Considerations This document defines the new LNCB range that IANA needs to assure that addresses assigned in this range are for Link-local Network Control. 8. Acknowledgments Brian Haberman, John Hopkins University Karen O'Donoghue, US Department of Navy 9. Change Log 9.1. Changes from 00 to 01 1. Added Justification section 2. Converted to XML Pashby Expires October 14, 2006 [Page 7] Internet-Draft IPv6 MCast Scoped Addr April 2006 10. References [1] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. [2] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000. [3] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001. [4] Pashby, R., "Simplifying IPv6 MLD Snooping Switches", draft-pashby-maga-simplify-mld-snooping-01.txt (work in progress). Pashby Expires October 14, 2006 [Page 8] Internet-Draft IPv6 MCast Scoped Addr April 2006 Author's Address Ronald Pashby Bowhead Information Technology Services Phone: +1 540 653 6070 Email: ronald.pashby.ctr@navy.mil Pashby Expires October 14, 2006 [Page 9] Internet-Draft IPv6 MCast Scoped Addr April 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pashby Expires October 14, 2006 [Page 10]