RFC4605 日本語訳
4605 Internet Group Management Protocol (IGMP) / Multicast ListenerDiscovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"). B.Fenner, H. He, B. Haberman, H. Sandick. August 2006. (Format: TXT=25558 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
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")
Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
Status of This Memo
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.
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 Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
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.
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
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.
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
Fenner, et al. Standards Track [Page 1] RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
1.1. Motivation
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.
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.
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.
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
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.
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.
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
Fenner, et al. Standards Track [Page 2] RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
1.3. Conventions
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].
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.
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. Definitions
2.1. Upstream Interface
2.1. Upstream Interface
A proxy device's interface in the direction of the root of the tree. Also called the "Host interface".
A proxy device's interface in the direction of the root of the tree. Also called the "Host interface".
2.2. Downstream 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".
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
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 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.
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
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.
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
Fenner, et al. Standards Track [Page 3] RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
2.5. Membership Database
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:
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)
(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.
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
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.
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 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.
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).
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
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
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.
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:
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 --------------------------------------
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.
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:
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 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.
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
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:
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 --------------------------------------
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.
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
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.
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
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.
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.
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
Fenner, et al. Standards Track [Page 6] RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
4. Proxy Device Behavior
4. Proxy Device Behavior
This section describes an IGMP/MLD-based multicast forwarding device's actions in more detail.
This section describes an IGMP/MLD-based multicast forwarding device's actions in more detail.
4.1. Membership Database
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 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 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:
The membership database is a set of membership records of the form:
(multicast-address, filter-mode, source-list)
(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).
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.
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
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.
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
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.
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
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.
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.
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
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.
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
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.
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.
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.
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
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.
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
Fenner, et al. Standards Track [Page 9] RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
7. Normative References
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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.
[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.
[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.
[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.
[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.
[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
8. Informative References
[MCAST] Deering, S., "Multicast Routing in a Datagram
Internetwork", Ph.D. Thesis, Stanford University, December
1991.
[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.
[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
Fenner, et al. Standards Track [Page 10] RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
Authors' Addresses
Authors' Addresses
Bill Fenner AT&T Labs - Research 1 River Oaks Place San Jose, CA 95134
Bill Fenner AT&T Labs - Research 1 River Oaks Place San Jose, CA 95134
Phone: +1 408 493-8505 EMail: fenner@research.att.com
Phone: +1 408 493-8505 EMail: fenner@research.att.com
Haixiang He Nortel 600 Technology Park Drive Billerica, MA 01821
Haixiang He Nortel 600 Technology Park Drive Billerica, MA 01821
EMail: haixiang@nortel.com
EMail: haixiang@nortel.com
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099
EMail: brian@innovationslab.net
EMail: brian@innovationslab.net
Hal Sandick Little River Elementary School 2315 Snow Hill Road Durham, NC 27712
Hal Sandick Little River Elementary School 2315 Snow Hill Road Durham, NC 27712
EMail: sandick@nc.rr.com
EMail: sandick@nc.rr.com
Fenner, et al. Standards Track [Page 11] RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
Fenner, et al. Standards Track [Page 11] RFC 4605 IGMP/MLD-Based Multicast Forwarding August 2006
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.
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
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.
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Fenner, et al. Standards Track [Page 12]
フェナー、他 標準化過程[12ページ]
一覧
スポンサーリンク
