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

Versions: 00 01

Network Working Group   R. Pashby
Internet Draft  Bowhead Support
Document: draft-pashby-magma-simplify-mld-snooping-00.txt       July 2005
Expires: January 2006

Simplifying IPv6 MLD Snooping Switches
<draft-pashby-magma-simplify-mld-snooping-00.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 January 2006.

Abstract

The purpose of this draft is to simplify the design of MLD Snooping
switches and provide a method for sending Solicited Node multicast
addresses to be send to every port to improve network security 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 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 and discovering security breaches
as discussed in [spoof]. Similarly the same allowance could be made
for Local Network Control Block (LNCB) addresses.

Table of Contents:

1.      Introduction
2.      Applicability
3.      MLD Snooping Switch Multicast Forwarding Rules
4.      Security Considerations
5.      Acknowledgments
6.      References
7.      Author's Information

1. Introduction

The purpose of this draft is to simplify the design of MLD Snooping
switches and provide a method for sending Solicited Node multicast
addresses to be send to every port to improve network security 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 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 and discovering security breaches
as discussed in [spoof].

[mldsnoop] 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 was required for IPv4.

Current layer IGMP snooping switches were designed with the
criteria of 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 releases of OS' that support IPv6 do not send MLD
joins for the Solicited Node Address. This fact means that if MLD
snooping layer 2.5 switch is introduced into a network, large
numbers of IPv6 networks would fail to work. Similarly, many OS' in
network servers and services also do not send MLD joins for Local
Network Control groups.

There is another document [spoof], that recommends that Neighbor
Discovery Advertisements and Host Redirects be sent to the nodes
Solicited Node Address instead of the nodes Unicast Address and
require that nodes may silently ignore those packets if they are
received not addressed to the Solicited Node Address. That proposal
along with this proposal would allow a security device to detect
when these security holes are breached.

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 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. Applicability

This document does not preclude MLD snooping switches to base there
multicast forwarding decisions on the full IPv6 address, but does
allow for switches to be designed with possibly significant less
hardware requirements.

This document does not relax the requirement for hosts to send MLD
joins for the Solicited Node Address, however does relax the
requirement that an MLD snooping switch does not require 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:

-       Forward packets addressed to LNCB addresses to all ports. This
includes the All Hosts Multicast address.

-       Forward packets addressed to the DALS addresses to all ports.

- Track MLD joins and leaves for forwarding all other multicast
groups per [snoop].

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 contained to
only 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 more than that of
a non-MLD snooping switch. Also, there currently is a mechanism
that would forward packets to all ports by addressing them to the
All Hosts Multicast address.

There should be access controls to deny all packets addressed to
Dynamically Assigned Link-Local Scoped Addresses from being
forwarded onto a link.

5. Acknowledgments

Brain Haberman, John Hopkins University
Karen O'Donoghue, US Department of Navy

6. References

[spoof] Pashby, R., "Detection of IPv6 Neighbor Discovery and
Host Redirection Spoofing", draft-pashby-ipv6-detecting-
spoofing-00.txt, July 2005
[mldsnoop]      Christensen, M., Kimball, K., Solensky, F.,
"Considerations for IGMP and MLD Snooping Switches,
draft-ietf-magma-snoop-12.txt, February 2005
[scopedmc]      Pashby R., "Multicast Scoped Address Assignment
Guidance", draft-pashby-mboned-mc-scoped-addr-00.txt,
July 2005
[RFC2375]       Hinden, R., Deering, S., "IPv6 Multicast Address
Assignments", RFC2375, July 1998

7. Author's Information

Ronald Pashby
Bowhead Support Services
Ronald.Pashby.ctr@navy.mil
(540) 653-6070


Copyright (C) The Internet Society (2005)

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.

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.


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