Internet DRAFT - draft-pashby-magma-simplify-mld-snooping
draft-pashby-magma-simplify-mld-snooping
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]
