address, meaning that the router will ignore MLDv2 source specific
state messages. This can cause traffic to flow from unwanted sources
for up to [Multicast Address Listener Interval]. This can be solved
by providing routers with a configuration switch to ignore Version 1
messages completely. This breaks automatic compatibility with
Version 1 hosts, so it should only be used in situations where source
filtering is critical.
10.3. State Change Report messages
A forged State Change Report message will cause the Querier to send
out Multicast Address Specific or Multicast Address and Source
Specific Queries for the multicast address in question. This causes
extra processing on each router and on each listener of the multicast
address, but cannot cause loss of desired traffic.
11. IANA Considerations
IANA has assigned the IPv6 link-local multicast address
FF02:0:0:0:0:0:0:16, called "all MLDv2-capable routers", as described
in section 5.2.14. Version 2 Multicast Listener Reports will be sent
to this special address.
In addition, IANA has assigned the ICMPv6 message type value of 143
for Version 2 Multicast Listener Report messages, as specified in
section 4.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option," RFC 2711, October 1999.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture, RFC 3513, April 2003.
12.2. Informative References
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source- Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678,
January 2004.
13. Acknowledgments
We would like to thank Hitoshi Asaeda, Randy Bush, Francis Dupont,
Ted Hardie, Russ Housley, Konstantin Kabassanov, Erik Nordmark,
Shinsuke Suzuki, Margaret Wasserman, Bert Wijnen, and Remi Zara for
their valuable comments and suggestions on this document.
APPENDIX A. Design Rationale
A.1. The Need for State Change Messages
MLDv2 specifies two types of Multicast Listener Reports: Current
State and State Change. This section describes the rationale for the
need for both these types of Reports.
Routers need to distinguish Multicast Listener Reports that were sent
in response to Queries from those that were sent as a result of a
change in the per-interface state. Multicast Listener Reports that
are sent in response to Multicast Address Listener Queries are used
mainly to refresh the existing state at the router; they typically do
not cause transitions in state at the router. Multicast Listener
Reports that are sent in response to changes in the per-interface
state require the router to take some action in response to the
received report (see Section 7.4.).
The inability to distinguish between the two types of reports would
force a router to treat all Multicast Listener Reports as potential
changes in state and could result in increased processing at the
router as well as an increase in MLD traffic on the link.
A.2. Host Suppression
In MLDv1, a host would not send a pending multicast listener report
if a similar report was sent by another listener on the link. In
MLDv2, the suppression of multicast listener reports has been
removed. The following points explain this decision.
1. Routers may want to track per-host multicast listener status on an
interface. This would allow routers to implement fast leaves
(e.g., for layered multicast congestion control schemes), as well
as track listener status for possible security or accounting
purposes. The present specification does not require routers to
implement per-host tracking. Nevertheless, the lack of host
suppression in MLDv2 makes possible to implement either
proprietary or future standard behavior of multicast routers that
would support per-host tracking, while being fully interoperable
with MLDv2 listeners and routers that implement the exact behavior
described in this specification.
2. Multicast Listener Report suppression does not work well on
bridged LANs. Many bridges and Layer2/Layer3 switches that
implement MLD snooping do not forward MLD messages across LAN
segments in order to prevent multicast listener report
suppression.
3. By eliminating multicast listener report suppression, hosts have
fewer messages to process; this leads to a simpler state machine
implementation.
4. In MLDv2, a single multicast listener report now bundles multiple
multicast address records to decrease the number of packets sent.
In comparison, the previous version of MLD required that each
multicast address be reported in a separate message.
A.3. Switching router filter modes from EXCLUDE to INCLUDE
If on a link there are nodes in both EXCLUDE and INCLUDE modes for a
single multicast address, the router must be in EXCLUDE mode as well
(see section 7.2.1). In EXCLUDE mode, a router forwards traffic from
all sources except those in the Exclude List. If all nodes in
EXCLUDE mode cease to exist or to listen, it would be desirable for
the router to switch back to INCLUDE mode seamlessly, without
interrupting the flow of traffic to existing listeners.
One of the ways to accomplish this is for routers to keep track of
all sources that nodes that are in INCLUDE mode listen to, even
though the router itself is in EXCLUDE mode. If the Filter Timer for
a multicast address expires, it implies that there are no nodes in
EXCLUDE mode on the link (otherwise a multicast listener report from
that node would have refreshed the Filter Timer). The router can
then switch to INCLUDE mode seamlessly; sources from the Requested
List are moved to the Include List, while sources from the Exclude
List are deleted.
APPENDIX B. Summary of Changes from MLDv1
The following is a summary of changes from MLDv1, specified in RFC
2710.
o MLDv2 introduces source filtering.
o The IP service interface of MLDv2 nodes is modified accordingly.
It enables the specification of a filter mode and a source list.
o An MLDv2 node keeps per-socket and per-interface multicast
listening states that include a filter mode and a source list for
each multicast address. This enables packet filtering based on a
socket’s multicast reception state.
o MLDv2 state kept on routers includes a filter mode and a list of
sources and source timers for each multicast address that has
listeners on the link. MLDv1 routers kept only the list of
multicast addresses.
o Queries include additional fields (section 5.1).
o The S flag (Suppress Router-Side Processing) is included in
queries in order to fix robustness issues.
o The Querier’s Robustness Variable and Query Interval Code are
included in Queries in order to synchronize all MLDv2 routers
connected to the same link.
o A new Query type (Multicast Address and Source Specific Query) is
introduced.
o The Maximum Response Delay is not directly included in the Query
anymore. Instead, an exponential algorithm is used to calculate
its value, based on the Maximum Response Code included in the
Query. The maximum value is increased from 65535 milliseconds to
about 140 minutes.
o Reports include Multicast Address Records. Information on the
listening state for several different multicast addresses can be
included in the same Report message.
o Reports are sent to the "all MLDv2-capable multicast routers"
address, instead of the multicast address the host listens to, as
in MLDv1. This facilitates the operation of layer-2 snooping
switches.
o There is no "host suppression", as in MLDv1. All nodes send
Report messages.
o Unsolicited Reports, announcing changes in receiver listening
state, are sent [Robustness Variable] times. RFC 2710 is less
explicit.
o There are no Done messages.
o Interoperability with MLDv1 systems is achieved by MLDv2 state
operations.
o In order to ensure interoperability, hosts maintain a Host
Compatibility Mode variable and an Older Version Querier Present
timer per interface. Routers maintain a Multicast Address
Compatibility Mode variable and an Older Version Host Present
timer per multicast address.
Editors’ Contact Information
Rolland Vida
LIP6, Universite Pierre et Marie Curie
8, rue du Capitaine Scott
75015 Paris, France
Phone: +33-1.44.27.30.58
EMail: Rolland.Vida@lip6.fr
Luis Henrique Maciel Kosmalski Costa
LIP6, Universite Pierre et Marie Curie
8, rue du Capitaine Scott
75015 Paris, France
Phone: +33-1.44.27.30.58
EMail: Luis.Costa@lip6.fr
Authors’ Addresses
This document was written by:
Rolland Vida, LIP6
EMail: Rolland.Vida@lip6.fr
Luis Henrique Maciel Kosmalski Costa, LIP6
EMail: Luis.Costa@lip6.fr
Serge Fdida, LIP6
EMail: Serge.Fdida@lip6.fr
Steve Deering, Cisco Systems, Inc.
EMail: deering@cisco.com
Bill Fenner, AT&T Labs - Research
EMail: fenner@research.att.com
Isidor Kouvelas, Cisco Systems, Inc.
EMail: kouvelas@cisco.com
Brian Haberman, Caspian Networks
EMail: brian@innovationslab.net
This document is the translation of [RFC3376] for IPv6 semantics. It
was elaborated based on the translation of (RFC 2236) into [RFC2710].
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 currently provided by the
Internet Society.