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

Versions: 00 01

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]


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