introduces a potentially enormous overlap. The structure of an IPv6
multicast address is shown in the figure below. As a result, there
are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses which
map into a single DMAC address in Ethernet and FDDI. This should be
compared to 2**5 in the case of IPv4.
Initial allocation of IPv6 multicast addresses, as described in
[RFC3307], however, cover only the lower 32 bits of group ID. While
this reduces the problem of address ambiguity to group IDs with
different flag and scope values for now, it should be noted that the
allocation policy may change in the future. Because of the potential
overlap it is recommended that IPv6 address based forwarding is
preferred to MAC address based forwarding.
| 8 | 4 | 4 | 112 bits |
+--------+----+----+---------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------+
4. IGMP Questionnaire
As part of this work, the following questions were asked on the MAGMA
discussion list and were sent to known switch vendors implementing
IGMP snooping. The individual contributions have been anonymized
upon request and do not necessarily apply to all of the vendors’
products.
The questions were:
Q1 Do your switches perform IGMP Join aggregation? In other
words, are IGMP joins intercepted, absorbed by the
hardware/software so that only one Join is forwarded to the
querier?
Q2 Is multicast forwarding based on MAC addresses? Would
datagrams addressed to multicast IP addresses 224.1.2.3 and
239.129.2.3 be forwarded on the same ports-groups?
Q3 Is it possible to forward multicast datagrams based on IP
addresses (not routed)? In other words, could 224.1.2.3 and
239.129.2.3 be forwarded on different port-groups with
unaltered TTL?
Q4 Are multicast datagrams within the range 224.0.0.1 to
224.0.0.255 forwarded on all ports whether or not IGMP Joins
have been sent?
Q5 Are multicast frames within the MAC address range
01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports
whether or not IGMP joins have been sent?
Q6 Does your switch support forwarding to ports on which IP
multicast routers are attached in addition to the ports where
IGMP Joins have been received?
Q7 Is your IGMP snooping functionality fully implemented in
hardware?
Q8 Is your IGMP snooping functionality partly software
implemented?
Q9 Can topology changes (for example spanning tree configuration
changes) be detected by the IGMP snooping functionality so
that for example new queries can be sent or tables can be
updated to ensure robustness?
The answers were:
---------------------------+-----------------------+
| Switch Vendor |
---------------------------+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 |
---------------------------+---+---+---+---+---+---+
Q1 Join aggregation | x | x | x | | x | x |
Q2 Layer-2 forwarding | x | x | x | x |(1)| |
Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x |
Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x |
Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x |
Q6 Mcast router list | x | x | x | x | x | x |
Q7 Hardware implemented | | | | | | |
Q8 Software assisted | x | x | x | x | x | x |
Q9 Topology change aware | x | x | x | x | |(2)|
---------------------------+---+---+---+---+---+---+
x Means that the answer was Yes.
(1) In some products (typically high-end) Yes; in others No.
(2) Not at the time that the questionnaire was received
but expected in the near future.
5. References
5.1. Normative References
[BRIDGE] IEEE Std. 802.1D-2004 IEEE Standard for Local and
metropolitan area networks, Media Access Control (MAC)
Bridges
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[IPV6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", RFC 3146, October 2001.
[IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC 2467, December 1998.
[IPV6-TOKEN] Crawford, M., Narten, T., and S. Thomas, "Transmission
of IPv6 Packets over Token Ring Networks", RFC 2470,
December 1998.
[MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MRDISC] Haberman, B. and J. Martin, "Multicast Router
Discovery", RFC 4286, December 2005.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD
5, RFC 1112, August 1989.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
5.2. Informative References
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP
and IGMP snooping",
http://www.cisco.com/warp/public/473/22.html
[IETF56] Briefing by Dave Thaler, Microsoft, presented to the
MAGMA WG at the 56’th IETF meeting in San Francisco,
http://www.ietf.org/proceedings/03mar/index.html
[MSOFT] Microsoft support article Q223136, "Some LAN Switches
with IGMP Snooping Stop Forwarding Multicast Packets on
RRAS Startup", http://support.microsoft.com/
support/articles/Q223/1/36.ASP
6. Security Considerations
Under normal network operation, the snooping switch is expected to
improve overall network performance by limiting the scope of
multicast flooding to a smaller portion of the local network. In the
event of forged IGMP messages, the benefits of using a snooping
switch might be reduced or eliminated.
Security considerations for IGMPv3 at the network layer of the
protocol stack are described in [IGMPv3]. The introduction of IGMP
snooping functionality does not alter the handling of multicast
packets by the router as it does not make use of link layer
information.
There are, however, changes in the way that the IGMP snooping switch
handles multicast packets within the local network. In particular:
- A Query message with a forged source address which is less than
that of the current Querier could cause snooping switches to
forward subsequent Membership reports to the wrong network
interface. It is for this reason that IGMP Membership Reports
should be sent to all multicast routers as well as the current
Querier.
- It is possible for a host on the local network to generate
Current-State Report Messages that would cause the switch to
incorrectly believe that there is a multicast listener on the same
network segment as the originator of the forged message. This
will cause unrequested multicast packets to be forwarded into the
network segments between the source and the router. If the router
requires that all Multicast Report messages be authenticated as
described in section 9.4 of [IGMPv3], it will discard the forged
Report message from the host inside the network in the same way
that it would discard one which originates from a remote location.
It is worth noting that if the router accepts unauthenticated
Report messages by virtue of them having arrived over a network
interface associated with the internal network, investigating the
affected network segments will quickly narrow the search for the
source of the forged messages.
- As noted in [IGMPv3], there is little motivation for an attacker
to forge a Membership report message since joining a group is
generally an unprivileged operation. The sender of the forged
Membership report will be the only recipient of the multicast
traffic to that group. This is in contrast to a shared LAN
segment (HUB) or network without snooping switches, where all
other hosts on the same segment would be unable to transmit when
the network segment is flooding the unwanted traffic.
The worst case result for each attack would remove the performance
improvements that the snooping functionality would otherwise provide.
It would, however, be no worse than that experienced on a network
with switches that do not perform multicast snooping.
7. Acknowledgements
We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter,
Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward
Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka
Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret
Wasserman for comments and suggestions on this document.
Furthermore, the following companies are acknowledged for their
contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks,
Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane.
The ordering of these names do not necessarily correspond to the
column numbers in the response table.
Authors’ Addresses
Morten Jagd Christensen
Thrane & Thrane
Lundtoftegaardsvej 93 D
2800 Lyngby
DENMARK
EMail: mjc@tt.dk
Karen Kimball
Hewlett-Packard
8000 Foothills Blvd.
Roseville, CA 95747
USA
EMail: karen.kimball@hp.com
Frank Solensky
Calix
43 Nanog Park
Acton, MA 01720
USA
EMail: frank.solensky@calix.com
Full 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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).