Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
Forwarding multicast packets with membership information alone, on a tree of proxy devices.
Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, August 2006, <https://www.rfc-editor.org/info/rfc4605>.
@misc{rfc4605,
series = {Request for Comments},
number = 4605,
howpublished = {RFC 4605},
publisher = {RFC Editor},
doi = {10.17487/RFC4605},
url = {https://www.rfc-editor.org/info/rfc4605},
author = {B. Fenner and H. He and B. Haberman and H. Sandick},
title = {{Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")}},
pagetotal = 12,
year = 2006,
month = aug,
} RFC text
Contents
Network Working Group B. Fenner
Request for Comments: 4605 AT&T Research
Category: Standards Track H. He
Nortel
B. Haberman
JHU-APL
H. Sandick
Little River Elementary School
August 2006
Internet Group Management Protocol (IGMP) /
Multicast Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In certain topologies, it is not necessary to run a multicast routing
protocol. It is sufficient for a device to learn and proxy group
membership information and simply forward multicast packets based
upon that information. This document describes a mechanism for
forwarding based solely upon Internet Group Management Protocol
(IGMP) or Multicast Listener Discovery (MLD) membership information.
1. Introduction
This document applies spanning tree multicast routing [MCAST] to an
Internet Group Management Protocol (IGMP) or Multicast Listener
Discovery (MLD)-only environment. The topology is limited to a tree,
since we specify no protocol to build a spanning tree over a more
complex topology. The root of the tree is assumed to be connected to
a wider multicast infrastructure.
1.1. Motivation
In a simple tree topology, it is not necessary to run a multicast
routing protocol. It is sufficient to learn and proxy group
membership information and simply forward multicast packets based
upon that information. One typical example of such a tree topology
can be found on an edge aggregation box such as a Digital Subscriber
Line Access Multiplexer (DSLAM). In most deployment scenarios, an
edge box has only one connection to the core network side and has
many connections to the customer side.
Using IGMP/MLD-based forwarding to replicate multicast traffic on
devices such as the edge boxes can greatly simplify the design and
implementation of those devices. By not supporting more complicated
multicast routing protocols such as Protocol Independent Multicast
(PIM) or Distance Vector Multicast Routing Protocol (DVMRP), it
reduces not only the cost of the devices but also the operational
overhead. Another advantage is that it makes the proxy devices
independent of the multicast routing protocol used by the core
network routers. Hence, proxy devices can be easily deployed in any
multicast network.
Robustness in an edge box is usually achieved by using a hot spare
connection to the core network. When the first connection fails, the
edge box fails over to the second connection. IGMP/MLD-based
forwarding can benefit from such a mechanism and use the spare
connection for its redundant or backup connection to multicast
routers. When an edge box fails over to the second connection, the
proxy upstream connection can also be updated to the new connection.
1.2. Applicability Statement
The IGMP/MLD-based forwarding only works in a simple tree topology.
The tree must be manually configured by designating upstream and
downstream interfaces on each proxy device. In addition, the IP
addressing scheme applied to the proxying tree topology SHOULD be
configured to ensure that a proxy device can win the IGMP/MLD Querier
election to be able to forward multicast traffic. There are no other
multicast routers except the proxy devices within the tree, and the
root of the tree is expected to be connected to a wider multicast
infrastructure. This protocol is limited to a single administrative
domain.
In more complicated scenarios where the topology is not a tree, a
more robust failover mechanism is desired, or more than one
administrative domain is involved, a multicast routing protocol
should be used.
1.3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document is a product of the Multicast & Anycast Group
Membership (MAGMA) working group within the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working
group's mailing list at magma@ietf.org and/or the authors.
2. Definitions
2.1. Upstream Interface
A proxy device's interface in the direction of the root of the tree.
Also called the "Host interface".
2.2. Downstream Interface
Each of a proxy device's interfaces that is not in the direction of
the root of the tree. Also called the "Router interfaces".
2.3. Group Mode
In IPv4 environments, for each multicast group, a group is in IGMP
version 1 (IGMPv1) [RFC1112] mode if an IGMPv1 report is heard. A
group is in IGMP version 2 (IGMPv2) [RFC2236] mode if an IGMPv2
report is heard but no IGMPv1 report is heard. A group is in IGMP
version 3 (IGMPv3) [RFC3376] mode if an IGMPv3 report is heard but no
IGMPv1 or IGMPv2 report is heard.
In IPv6 environments, for each multicast group, a group is in MLD
version 1 (MLDv1) [RFC2710] mode if an MLDv1 report is heard. MLDv1
is equivalent to IGMPv2. A group is in MLD version 2 (MLDv2) [MLDv2]
mode if an MLDv2 report is heard but no MLDv1 report is heard. MLDv2
is equivalent to IGMPv3.
2.4. Subscription
When a group is in IGMPv1 or IGMPv2/MLDv1 mode, the subscription is a
group membership on an interface. When a group is in IGMPv3/MLDv2
mode, the subscription is an IGMPv3/MLDv2 state entry, i.e., a
(multicast address, group timer, filter-mode, source-element list)
tuple, on an interface.
2.5. Membership Database
The database maintained at each proxy device into which the
membership information of each of its downstream interfaces is
merged. The membership database is a set of membership records of
the form:
(multicast-address, filter-mode, source-list)
Please refer to IGMPv3/MLDv2 [RFC3376, MLDv2] specifications for the
definition of the fields "filter-mode" and "source-list". The
operational behaviors of the membership database is defined in
section 4.1.
3. Abstract Protocol Definition
A proxy device performing IGMP/MLD-based forwarding has a single
upstream interface and one or more downstream interfaces. These
designations are explicitly configured; there is no protocol to
determine what type each interface is. It performs the router
portion of the IGMP [RFC1112, RFC2236, RFC3376] or MLD [RFC2710,
MLDv2] protocol on its downstream interfaces, and the host portion of
IGMP/MLD on its upstream interface. The proxy device MUST NOT
perform the router portion of IGMP/MLD on its upstream interface.
The proxy device maintains a database consisting of the merger of all
subscriptions on any downstream interface. Refer to Section 4 for
the details about the construction and maintenance of the membership
database.
The proxy device sends IGMP/MLD membership reports on the upstream
interface when queried and sends unsolicited reports or leaves when
the database changes.
When the proxy device receives a packet destined for a multicast
group (channel in Source-Specific Multicast (SSM)), it uses a list
consisting of the upstream interface and any downstream interface
that has a subscription pertaining to this packet and on which it is
the IGMP/MLD Querier. This list may be built dynamically or cached.
It removes the interface on which this packet arrived from the list
and forwards the packet to the remaining interfaces (this may include
the upstream interface).
Note that the rule that a proxy device must be the querier in order
to forward packets restricts the IP addressing scheme used; in
particular, the IGMP/MLD-based forwarding devices must be given the
lowest IP addresses of any potential IGMP/MLD Querier on the link, in
order to win the IGMP/MLD Querier election. IGMP/MLD Querier
election rule defines that the Querier that has the lowest IP address
wins the election. (The IGMP/MLD Querier election rule is defined in
IGMP/MLD specifications as part of the IGMP/MLD behavior.) So in an
IGMP/MLD-based forwarding-only environment, if non-proxy device wins
the IGMP/MLD Querier election, no packets will flow.
For example, the figure below shows an IGMP/MLD-based forwarding-only
environment:
LAN 1 --------------------------------------
Upstream | | Upstream
A(non-proxy) B(proxy)
Downstream |(lowest IP) | Downstream
LAN 2 --------------------------------------
Device A has the lowest IP address on LAN 2, but it is not a proxy
device. According to IGMP/MLD Querier election rule, A will win the
election on LAN 2 since it has the lowest IP address. Device B will
not forward traffic to LAN 2 since it is not the querier on LAN 2.
The election of a single forwarding proxy is necessary to avoid local
loops and redundant traffic for links that are considered downstream
links by multiple IGMP/MLD-based forwarders. This rule "piggy-backs"
forwarder election on IGMP/MLD Querier election. The use of the
IGMP/MLD Querier election process to choose the forwarding proxy
delivers similar functionality on the local link as the PIM Assert
mechanism. On a link with only one IGMP/MLD-based forwarding device,
this rule MAY be disabled (i.e., the device MAY be configured to
forward packets to an interface on which it is not the querier).
However, the default configuration MUST include the querier rule, for
example, for redundancy purposes, as shown in the figure below:
LAN 1 --------------------------------------
Upstream | | Upstream
A B
Downstream | | Downstream
LAN 2 --------------------------------------
LAN 2 can have two proxy devices, A and B. In such a configuration,
one proxy device must be elected to forward the packets. This
document requires that the forwarder must be the IGMP/MLD querier.
So proxy device A will forward packets to LAN 2 only if A is the
querier. In the above figure, if A is the only proxy device, A can
be configured to forward packets even though B is the querier.
Note that this does not protect against an "upstream loop". For
example, see the figure below:
LAN 1 --------------------------------------
Upstream | | Downstream
A B
Downstream | | Upstream
LAN 2 --------------------------------------
B will unconditionally forward packets from LAN 1 to LAN 2, and A
will unconditionally forward packets from LAN 2 to LAN 1. This will
cause an upstream loop. A multicast routing protocol that employs a
tree building algorithm is required to resolve loops like this.
3.1. Topology Restrictions
This specification describes a protocol that works only in a simple
tree topology. The tree must be manually configured by designating
upstream and downstream interfaces on each proxy device, and the root
of the tree is expected to be connected to a wider multicast
infrastructure.
3.2. Supporting Senders
In order for senders to send from inside the proxy tree, all traffic
is forwarded towards the root. The multicast router(s) connected to
the wider multicast infrastructure should be configured to treat all
systems inside the proxy tree as though they were directly connected;
e.g., for Protocol Independent Multicast - Sparse Mode (PIM-SM)
[PIM-SM], these routers should Register-encapsulate traffic from new
sources within the proxy tree just as they would directly-connected
sources.
This information is likely to be manually configured; IGMP/MLD-based
multicast forwarding provides no way for the routers upstream of the
proxy tree to know what networks are connected to the proxy tree. If
the proxy topology is congruent with some routing topology, this
information MAY be learned from the routing protocol running on the
topology; e.g., a router may be configured to treat multicast packets
from all prefixes learned from routing protocol X via interface Y as
though they were from a directly connected system.
4. Proxy Device Behavior
This section describes an IGMP/MLD-based multicast forwarding
device's actions in more detail.
4.1. Membership Database
The proxy device performs the router portion of the IGMP/MLD protocol
on each downstream interface. For each interface, the version of
IGMP/MLD used is explicitly configured and defaults to the highest
version supported by the system.
The output of this protocol is a set of subscriptions; this set is
maintained separately on each downstream interface. In addition, the
subscriptions on each downstream interface are merged into the
membership database.
The membership database is a set of membership records of the form:
(multicast-address, filter-mode, source-list)
Each record is the result of the merge of all subscriptions for that
record's multicast-address on downstream interfaces. If some
subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these
subscriptions are converted to IGMPv3/MLDv2 subscriptions. The
IGMPv3/MLDv2 and the converted subscriptions are first preprocessed
to remove the timers in the subscriptions and, if the filter mode is
EXCLUDE, to remove every source whose source timer > 0. Then the
preprocessed subscriptions are merged using the merging rules for
multiple memberships on a single interface (specified in Section 3.2
of the IGMPv3 specification [RFC3376] and in Section 4.2 of the MLDv2
specification [MLDv2]) to create the membership record. For example,
there are two downstream interfaces, I1 and I2, that have
subscriptions for multicast address G. I1 has an IGMPv2/MLDv1
subscription that is (G). I2 has an IGMPv3/MLDv2 subscription that
has membership information (G, INCLUDE, (S1, S2)). The I1's
subscription is converted to an IGMPv3/MLDv2 subscription that has
membership information (G, EXCLUDE, NULL). Then the subscriptions
are preprocessed and merged, and the final membership record is (G,
EXCLUDE, NULL).
The proxy device performs the host portion of the IGMP/MLD protocol
on the upstream interface. If there is an IGMPv1 or IGMPv2/MLDv1
querier on the upstream network, then the proxy device will perform
IGMPv1 or IGMPv2/MLDv1 on the upstream interface accordingly.
Otherwise, it will perform IGMPv3/MLDv2.
If the proxy device performs IGMPv3/MLDv2 on the upstream interface,
then when the composition of the membership database changes, the
change in the database is reported on the upstream interface as
though this proxy device were a host performing the action. If the
proxy device performs IGMPv1 or IGMPv2/MLDv1 on the upstream
interface, then when the membership records are created or deleted,
the changes are reported on the upstream interface. All other
changes are ignored. When the proxy device reports using IGMPv1 or
IGMPv2/MLDv1, only the multicast address field in the membership
record is used.
4.2. Forwarding Packets
A proxy device forwards packets received on its upstream interface to
each downstream interface based upon the downstream interface's
subscriptions and whether or not this proxy device is the IGMP/MLD
Querier on each interface. A proxy device forwards packets received
on any downstream interface to the upstream interface, and to each
downstream interface other than the incoming interface based upon the
downstream interfaces' subscriptions and whether or not this proxy
device is the IGMP/MLD Querier on each interface. A proxy device MAY
use a forwarding cache in order not to make this decision for each
packet, but MUST update the cache using these rules any time any of
the information used to build it changes.
4.3. SSM Considerations
To support Source-Specific Multicast (SSM), the proxy device should
be compliant with the specification about using IGMPv3 for SSM [SSM].
Note that the proxy device should be compliant with both the IGMP
Host Requirement and the IGMP Router Requirement for SSM since it
performs IGMP Host Portion on the upstream interface and IGMP Router
Portion on each downstream interface.
An interface can be configured to perform IGMPv1 or IGMPv2. In this
scenario, the SSM semantic will not be maintained for that interface.
However, a proxy device that supports this document should ignore
those IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more
importantly, the packets with source-specific addresses SHOULD NOT be
forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these
addresses.
5. Security Considerations
Since only the Querier forwards packets, the IGMP/MLD Querier
election process may lead to black holes if a non-forwarder is
elected Querier. An attacker on a downstream LAN can cause itself to
be elected Querier, and as a result, no packets would be forwarded.
However, there are some operational ways to avoid this problem. It
is fairly common for an operator to number the routers starting from
the bottom of the subnet. So an operator SHOULD assign the subnet's
lowest IP address(es) to a proxy (proxies) in order for the proxy
(proxies) to win the querier election.
IGMP/MLD-based forwarding does not provide the "upstream loop"
detection mechanism described in Section 3. Hence, to avoid the
problems caused by an "upstream loop", it MUST be administratively
assured that such loops don't exist when deploying IGMP/MLD Proxying.
The IGMP/MLD information presented by the proxy to its upstream
routers is the aggregation of all its downstream group membership
information. Any access control applied on the group membership
protocol at the upstream router cannot be performed on a single
subscriber. That is, the access control will apply equally to all
the interested hosts reachable via the proxy device.
6. Acknowledgements
The authors would like to thank Erik Nordmark, Dave Thaler, Pekka
Savola, Karen Kimball, and others for reviewing the specification and
providing their comments.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC2710] 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.
[SSM] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
8. Informative References
[MCAST] Deering, S., "Multicast Routing in a Datagram
Internetwork", Ph.D. Thesis, Stanford University, December
1991.
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
Authors' Addresses
Bill Fenner
AT&T Labs - Research
1 River Oaks Place
San Jose, CA 95134
Phone: +1 408 493-8505
EMail: fenner@research.att.com
Haixiang He
Nortel
600 Technology Park Drive
Billerica, MA 01821
EMail: haixiang@nortel.com
Brian Haberman
Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723-6099
EMail: brian@innovationslab.net
Hal Sandick
Little River Elementary School
2315 Snow Hill Road
Durham, NC 27712
EMail: sandick@nc.rr.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).
ISO Plain Language
On this page
§1.1Why Proxying Instead of Multicast Routing
This document applies spanning tree multicast routing to an environment that has only IGMP or MLD. The topology is limited to a tree, because the document specifies no protocol to build a spanning tree over a more complex topology. The root of the tree is assumed to be connected to a wider multicast infrastructure.
In a simple tree topology it is not necessary to run a multicast routing protocol at all. It is enough to learn and proxy group membership information and forward multicast packets on the strength of it. A typical example is an edge aggregation box such as a Digital Subscriber Line Access Multiplexer, which in most deployments has one connection to the core network and many connections to the customer side.
Using IGMP/MLD-based forwarding to replicate multicast traffic on such devices simplifies their design and implementation. By not supporting more complicated multicast routing protocols such as Protocol Independent Multicast (PIM) or the Distance Vector Multicast Routing Protocol (DVMRP), it reduces the cost of the devices and the operational overhead. It also makes the proxy devices independent of the multicast routing protocol used by the core network routers, so they can be deployed in any multicast network.
Robustness in an edge box is usually achieved with a hot spare connection to the core network: when the first connection fails, the edge box fails over to the second. IGMP/MLD-based forwarding benefits from that, because the proxy upstream connection can be updated to the new connection at the same time.
Some devices sit between subscribers and the rest of the network and only need to pass multicast traffic along. Running a full multicast routing protocol on them is expensive, both to build and to operate. This RFC lets them work from the group subscriptions alone.
§1.2Where This Applies
The IGMP/MLD-based forwarding only works in a simple tree topology. The tree must be manually configured by designating upstream and downstream interfaces on each proxy device. The IP addressing scheme applied to the proxying tree SHOULD also be configured so that a proxy device can win the IGMP/MLD Querier election and so be able to forward multicast traffic.
There are no other multicast routers inside the tree apart from the proxy devices, and the root of the tree is expected to be connected to a wider multicast infrastructure. The protocol is limited to a single administrative domain.
In more complicated scenarios, where the topology is not a tree, where a more robust failover mechanism is wanted, or where more than one administrative domain is involved, the RFC says a multicast routing protocol should be used instead.
The method needs a tree, configured by hand, inside one organisation. If the network is more complicated than that, or spans several organisations, use a real multicast routing protocol.
§2Terms Used in This Document
An upstream interface is a proxy device's interface in the direction of the root of the tree, also called the host interface. Each of a proxy device's other interfaces is a downstream interface, also called a router interface.
A group is said to be in a particular group mode depending on which version of the protocol the reports use. In IPv4 environments, a group is in IGMP version 1 mode if an IGMPv1 report is heard, in IGMP version 2 mode if an IGMPv2 report is heard but no IGMPv1 report is heard, and in IGMP version 3 mode if an IGMPv3 report is heard but no IGMPv1 or IGMPv2 report is heard. In IPv6 environments the same pattern applies to MLD version 1 and version 2, with MLDv1 equivalent to IGMPv2 and MLDv2 equivalent to IGMPv3.
A subscription depends on the mode. When a group is in IGMPv1 or IGMPv2/MLDv1 mode, the subscription is a group membership on an interface. When a group is in IGMPv3/MLDv2 mode, the subscription is a state entry, a tuple of multicast address, group timer, filter mode and source-element list, on an interface.
The membership database is the database kept at each proxy device into which the membership information of each of its downstream interfaces is merged. It holds membership records of the form (multicast-address, filter-mode, source-list).
Each proxy device has one interface facing the root of the tree and one or more facing the subscribers. A subscription is either a simple yes, I want this group, or, in the newest version of the protocols, a record that also says which sources are wanted.
| Group mode | The subscription is |
|---|---|
| IGMPv1, IGMPv2, MLDv1 | A group membership on an interface |
| IGMPv3, MLDv2 THIS RFC | A state entry: multicast address, group timer, filter mode and source-element list |
§3The Abstract Protocol
A proxy device performing IGMP/MLD-based forwarding has a single upstream interface and one or more downstream interfaces. These designations are explicitly configured; there is no protocol to determine what type each interface is. The device performs the router portion of IGMP or MLD on its downstream interfaces and the host portion on its upstream interface, and it MUST NOT perform the router portion on the upstream interface.
The proxy device maintains a database consisting of the merger of all subscriptions on any downstream interface. It sends IGMP/MLD membership reports on the upstream interface when queried, and sends unsolicited reports or leaves when the database changes.
When the device receives a packet destined for a multicast group, which is a channel in Source-Specific Multicast, it builds a list consisting of the upstream interface and any downstream interface that has a subscription pertaining to that packet and on which it is the IGMP/MLD Querier. The list may be built dynamically or cached. It removes the interface on which the packet arrived and forwards the packet to the remaining interfaces, which may include the upstream interface.
The rule that a proxy device must be the querier in order to forward packets restricts the addressing scheme used. The devices must be given the lowest IP addresses of any potential IGMP/MLD Querier on the link, in order to win the election, and the election rule is that the querier with the lowest IP address wins. If a non-proxy device wins the election in an IGMP/MLD-based forwarding-only environment, no packets flow.
Electing a single forwarding proxy also avoids local loops and redundant traffic on links that several forwarders consider downstream. The RFC says this rule piggy-backs forwarder election on the querier election and delivers similar functionality on the local link to the PIM Assert mechanism. On a link with only one forwarding device the rule MAY be disabled, but the default configuration MUST include the querier rule, for example for redundancy.
On each subscriber link the proxy acts like a router and asks who wants what; on the link towards the root it acts like an ordinary subscriber and reports the total demand. A packet arriving is copied to the upstream link and to the downstream links that asked for it and where the proxy won the querier election.
- Root of the tree Connected to the wider multicast infrastructure
- Proxy device One upstream interface and one or more downstream interfaces
- Downstream interface Router portion of IGMP or MLD
- Downstream interface Router portion of IGMP or MLD
- Proxy device One upstream interface and one or more downstream interfaces
- Router side downstreamIt runs the router portion of IGMP or MLD on every downstream interface.
- Host side upstreamIt runs the host portion on the upstream interface and must not run the router portion there.
- Merged databaseIt keeps one membership database merged from all downstream interfaces.
- Querier ruleIt forwards to a downstream interface only while it is the querier on that link.
§3.1Topology Restrictions and Supporting Senders
The specification describes a protocol that works only in a simple tree topology. The tree must be manually configured by designating upstream and downstream interfaces on each proxy device, and the root of the tree is expected to be connected to a wider multicast infrastructure.
The election of a single forwarding proxy avoids local loops, but it does not protect against an upstream loop. In the RFC's example, device B forwards packets unconditionally from LAN 1 to LAN 2 and device A forwards unconditionally from LAN 2 to LAN 1, which causes an upstream loop. A multicast routing protocol that employs a tree building algorithm is required to resolve loops like this.
Senders inside the proxy tree need help from above. All traffic is forwarded towards the root, so the multicast routers connected to the wider multicast infrastructure should be configured to treat all systems inside the proxy tree as though they were directly connected. For Protocol Independent Multicast in Sparse Mode, for example, those routers should Register-encapsulate traffic from new sources within the proxy tree just as they would for directly connected sources. This information is likely to be configured by hand, because IGMP/MLD-based forwarding gives the routers upstream of the proxy tree no way to learn what networks are connected to it. If the proxy topology happens to match a routing topology, the information MAY instead be learned from the routing protocol running there.
Two rules keep the tree from looping traffic back and forth on the same link, but nothing stops two devices from forwarding traffic to each other along different links. That has to be prevented by hand, and the router above the tree has to be told to treat everything behind the tree as directly connected.
§4.1The Membership Database
The proxy device performs the router portion of IGMP/MLD on each downstream interface. For each interface the version of IGMP/MLD used is explicitly configured and defaults to the highest version supported by the system. The output of that protocol is a set of subscriptions, maintained separately on each downstream interface, and the subscriptions on each downstream interface are merged into the membership database.
The membership database is a set of membership records of the form (multicast-address, filter-mode, source-list). Each record is the result of merging all subscriptions for that multicast address on the downstream interfaces. If some subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, they are converted to IGMPv3/MLDv2 subscriptions. The IGMPv3/MLDv2 subscriptions and the converted ones are first preprocessed to remove the timers, and, if the filter mode is EXCLUDE, to remove every source whose source timer is greater than zero. The preprocessed subscriptions are then merged using the merging rules for multiple memberships on a single interface from the IGMPv3 and MLDv2 specifications.
The RFC works through an example. Two downstream interfaces, I1 and I2, both have subscriptions for multicast address G. I1 has an IGMPv2/MLDv1 subscription that is (G). I2 has an IGMPv3/MLDv2 subscription with membership information (G, INCLUDE, (S1, S2)). The I1 subscription is converted to an IGMPv3/MLDv2 subscription with membership information (G, EXCLUDE, NULL), and the final membership record is (G, EXCLUDE, NULL).
On the upstream interface the proxy device performs the host portion of the protocol. If there is an IGMPv1 or IGMPv2/MLDv1 querier on the upstream network, the proxy device performs IGMPv1 or IGMPv2/MLDv1 accordingly, and otherwise it performs IGMPv3/MLDv2. When the composition of the membership database changes, the change is reported on the upstream interface as though the proxy device were a host performing the action. When the proxy device reports using IGMPv1 or IGMPv2/MLDv1, only the multicast address field in the membership record is used.
The proxy keeps one list of what the subscribers want, merged from all the subscriber links. Subscriptions from older versions of the protocol are rewritten into the newest form before merging, so the list always has the same shape.
- QUERYThe proxy is the querier on this link.
- REPORTThe subscriber joins a group.
- REPORT OR LEAVESent upstream when the merged membership database changes.
§4.2Forwarding Packets and Handling SSM
A proxy device forwards packets received on its upstream interface to each downstream interface, based on that interface's subscriptions and on whether the device is the IGMP/MLD Querier on it. It forwards packets received on any downstream interface to the upstream interface, and to each downstream interface other than the incoming one, on the same basis. It MAY use a forwarding cache instead of making this decision for each packet, but it MUST update the cache whenever any of the information used to build it changes.
To support Source-Specific Multicast (SSM), the proxy device should comply with the rules for using IGMPv3 for SSM. The RFC notes that it should comply with both the IGMP host requirement and the IGMP router requirement, because it performs the host portion on the upstream interface and the router portion on each downstream interface.
An interface can be configured to perform IGMPv1 or IGMPv2. In that case the SSM semantics are not maintained for that interface. A proxy device that supports this document should ignore IGMPv1 or IGMPv2 subscriptions sent to SSM addresses, and packets with source-specific addresses SHOULD NOT be forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for those addresses.
Each arriving multicast packet is copied to the links that asked for that group, and to the link towards the root. With source-specific multicast, where a subscriber also names the sources it wants, the proxy follows the rules in RFC 4604 and keeps source-specific traffic away from older-style subscribers.
§5Security Considerations
Since only the querier forwards packets, the querier election may lead to black holes if a non-forwarder is elected querier. An attacker on a downstream LAN can cause itself to be elected querier, and as a result no packets would be forwarded.
There are operational ways to avoid this. It is fairly common for an operator to number the routers starting from the bottom of the subnet, so an operator SHOULD assign the subnet's lowest IP addresses to a proxy, or to proxies, in order for them to win the querier election.
IGMP/MLD-based forwarding does not provide the upstream loop detection mechanism described in section 3 of the RFC. To avoid the problems caused by an upstream loop, it MUST be administratively assured that such loops do not exist when deploying IGMP/MLD proxying.
The IGMP/MLD information presented by the proxy to its upstream routers is the aggregation of all its downstream group membership information. Any access control applied on the group membership protocol at the upstream router cannot be performed on a single subscriber, because the access control applies equally to all the interested hosts reachable via the proxy device.
The risk is that a device on a subscriber link wins the querier election, and then nothing is forwarded. Give the proxy the lowest address on the subnet to make that unlikely, and check by hand that the tree has no loops, because the protocol does not detect them itself.