MBONE Deployment (mboned) R. Pashby Internet-Draft Bowhead Expires: October 14, 2006 April 12, 2006 Simplifying IPv6 MLD Snooping Switches draft-pashby-magma-simplify-mld-snooping-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 draft is to simplify the design of MLD Snooping switches and provide a method for Solicited Node multicast addresses to be sent to every port to improve network robustment and management. IPv6 Addressing Architecture requires that all nodes must join the associated Solicited-Node multicast addresses for every unicast and anycast address it is assigned. This causes MLD snooping switches to create potentially huge multicast forwarding tables just to handle Pashby Expires October 14, 2006 [Page 1] Internet-Draft Simplifying IPv6 MLD Snooping Switches April 2006 Neighbor Discovery. A simple change to alleviate this would be to allow switches to forward a range of addresses that include the Solicited-Node multicast addresses to every port. This also could help in network discovery. Similarly the same allowance could be made for Local Network Control Block (LNCB) addresses. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. MLD Snooping Switch Multicast Forwarding Rules . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Pashby Expires October 14, 2006 [Page 2] Internet-Draft Simplifying IPv6 MLD Snooping Switches April 2006 1. Introduction The purpose of this draft is to simplify the design of MLD Snooping switches and provide a method for Solicited Node multicast addresses to be sent to every port to improve network robustment and management. IPv6 Addressing Architecture requires that all nodes must join the associated Solicited-Node multicast addresses for every unicast and anycast address they are assigned. This causes MLD snooping switches to create potentially huge multicast forwarding tables just to handle Neighbor Discovery. A simple change to alleviate this would be to allow switches to forward a range of addresses that include the Solicited-Node multicast addresses to every port. This also could help in network discovery. mldsnoop [1] states that it is preferred that the entire IPv6 address be used instead just the MAC address. This would cause a 2-2/3 increase in hardware than beyond what was required for IPv4. Current layer-2 IGMP snooping switches were designed with the criteria that the number of multicast groups that needed to be supported were determined by the number of "real" IP multicast flows (i.e. video conferences, financial ticker info, broadcast TV/radio, etc). However, with the currently defined IPv6, thousands of multicast groups need to be supported just to allow Neighbor Discovery. This also would cause a large increase in hardware to handle these groups with little real benefit. Many current Operating System releases that support IPv6 do not send MLD joins for the Solicited Node Address. This fact means that if a layer-2 MLD snooping switch were introduced into a network, large numbers of IPv6 networks would fail to work. Similarly, many Operating Systems in network servers and services also do not send MLD joins for Local Network Control groups. Since Neighbor Discovery requires the use of multicast, any failure of multicast forwarding causes significant impact on the operation of IPv6 networks. There are cases that network device failures or restarting can cause minutes of loss of multicast forwarding state in layer-2 MLD snooping switches. Reducing the reliance of multicast forwarding state for Neighbor Discovery will make the IPv6 network more resilient to temporary network outages. This document reduces the requirement that MLD snooping switches track group joins for per-host multicast groups (e.g. Solicited Node Multicast Address) and Local Network Control Block (LNCB) addresses. The proposal would define ranges of Multicast IDs that would be Pashby Expires October 14, 2006 [Page 3] Internet-Draft Simplifying IPv6 MLD Snooping Switches April 2006 forwarded to all ports and would not require tracking of MLD joins and leaves. The ranges specified are found in a corresponding document scopedmc [2]. 2. Applicability This document does not preclude MLD snooping switches from basing their multicast forwarding decisions on the full IPv6 address, but does allow for switches to be designed with possibly significantly fewer hardware resources. This document does not relax the requirement for hosts to send MLD joins for the Solicited Node Address, however it does relax the requirement that an MLD snooping switch must use them for proper operation of Neighbor Discovery. An MLD snooping switch is required to forward the Dynamically Assigned Link-Local Scoped Multicast Ids (DALS) to all ports. 3. MLD Snooping Switch Multicast Forwarding Rules The following rules must be used for MLD snooping Layer 2 switches: 1. Forward packets addressed to All-Nodes Multicast address to all ports. 2. Forward packets addressed to LNCB addresses to all ports. 3. Forward packets addressed to the DALS addresses to all ports. 4. Track MLD joins and leaves for forwarding all other multicast groups per mldsnoop [1]. Rules 2 and 3 may be administratively be turned off, but the default behavior should be on. 4. Security Considerations Forwarding traffic to all ports can cause vulnerability to Denial of Service attacks. However, there is a tradeoff between security, cost and manageability. The perceived vulnerability is confined only to devices on the link. It is almost impossible to remove Denial of Service attacks from devices connected on the physical link. This document does not increase the vulnerability over that which is present in a non-MLD snooping switch. Also, the current mechanism allows for this security breach by forwarding packets to all ports by addressing them to the All-Nodes Multicast address. There should be access controls to deny all packets addressed to Dynamically Assigned Link-Local Scoped Addresses from being forwarded Pashby Expires October 14, 2006 [Page 4] Internet-Draft Simplifying IPv6 MLD Snooping Switches April 2006 onto a link. 5. Acknowledgments Brain Haberman, John Hopkins University Karen O'Donoghue, US Department of Navy 6. Change Log 6.1. Changes from 00 to 01 1. Editorial changes 2. Removed references to [spoof] 3. Converted to XML 4. Changed forwarding rule to allow flooding of LNCB and DAL to administratively turned off 5. Added Change Log section 6. Removed reference RFC2375 7. References [1] Christensen, M., Kimball, K., and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 (work in progress), February 2005. [2] Pashby, R., "IPv6 Multicast Scoped Address Assignment", draft-pashby-ipv6-mc-scoped-addr-01.txt (work in progress). Pashby Expires October 14, 2006 [Page 5] Internet-Draft Simplifying IPv6 MLD Snooping Switches 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 6] Internet-Draft Simplifying IPv6 MLD Snooping Switches 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 7]