summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4605.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4605.txt')
-rw-r--r--doc/rfc/rfc4605.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc4605.txt b/doc/rfc/rfc4605.txt
new file mode 100644
index 0000000..0febb38
--- /dev/null
+++ b/doc/rfc/rfc4605.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 1]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+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.
+
+
+
+
+Fenner, et al. Standards Track [Page 2]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 3]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+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
+
+
+
+Fenner, et al. Standards Track [Page 4]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+ 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.
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 5]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 6]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+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.
+
+
+
+
+
+Fenner, et al. Standards Track [Page 7]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+ 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.
+
+
+
+Fenner, et al. Standards Track [Page 8]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 9]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 10]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 11]
+
+RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
+
+
+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).
+
+
+
+
+
+
+
+Fenner, et al. Standards Track [Page 12]
+