| < draft-ietf-magma-snoop-11.txt | draft-ietf-magma-snoop-12.txt > | |||
|---|---|---|---|---|
| Network Working Group M. Christensen | Network Working Group M. Christensen | |||
| Internet Draft Thrane & Thrane | Internet Draft Thrane & Thrane | |||
| Expiration Date: November 2004 K. Kimball | Expiration Date: August 2005 K. Kimball | |||
| Category: Informational Hewlett-Packard | Category: Informational Hewlett-Packard | |||
| F. Solensky | F. Solensky | |||
| West Ridge Networks | Calix Networks | |||
| May 2004 | February 2005 | |||
| Considerations for IGMP and MLD Snooping Switches | Considerations for IGMP and MLD Snooping Switches | |||
| <draft-ietf-magma-snoop-11.txt> | <draft-ietf-magma-snoop-12.txt> | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
| all provisions of Section 10 of RFC2026 [RFC2026]. | all provisions of Section 10 of RFC2026 [RFC2026]. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 1, line 36 ¶ | skipping to change at page 1, line 36 ¶ | |||
| documents at any time. It is inappropriate to use Internet-Drafts | documents at any time. It is inappropriate to use Internet-Drafts | |||
| as reference material or to cite them other than as "work in | as reference material or to cite them other than as "work in | |||
| progress." | progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| By submitting this Internet-Draft, we certify that any applicable | ||||
| patent or other IPR claims of which we are aware have been | ||||
| disclosed, or will be disclosed, and any of which we become aware | ||||
| will be disclosed, in accordance with RFC 3668 [IPR]. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2005). All rights reserved. | |||
| Abstract | Abstract | |||
| This memo describes the recommendations for IGMP- and MLD-snooping | This memo describes the recommendations for IGMP- and MLD-snooping | |||
| switches. These are based on best current practices for IGMPv2, | switches. These are based on best current practices for IGMPv2, | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| with further considerations for IGMPv3- and MLDv2-snooping. | with further considerations for IGMPv3- and MLDv2-snooping. | |||
| Additional areas of relevance, such as link layer topology changes | Additional areas of relevance, such as link layer topology changes | |||
| and Ethernet-specific encapsulation issues, are also considered. | and Ethernet-specific encapsulation issues, are also considered. | |||
| MLD Snooping Switches | ||||
| 1. Introduction | 1. Introduction | |||
| The IEEE bridge standard [BRIDGE] specifies how LAN packets are | The IEEE bridge standard [BRIDGE] specifies how LAN packets are | |||
| 'bridged', or as is more commonly used today, switched between LAN | 'bridged', or as is more commonly used today, switched between LAN | |||
| segments. The operation of a switch with respect to multicast | segments. The operation of a switch with respect to multicast | |||
| packets can be summarized as follows. When processing a packet | packets can be summarized as follows. When processing a packet | |||
| whose destination MAC address is a multicast address, the switch | whose destination MAC address is a multicast address, the switch | |||
| will forward a copy of the packet into each of the remaining | will forward a copy of the packet into each of the remaining | |||
| network interfaces that are in the forwarding state in accordance | network interfaces that are in the forwarding state in accordance | |||
| with [BRIDGE]. The spanning tree algorithm ensures that the | with [BRIDGE]. The spanning tree algorithm ensures that the | |||
| skipping to change at page 1, line 93 ¶ | skipping to change at page 1, line 100 ¶ | |||
| the transport protocol's header before allowing a packet to be | the transport protocol's header before allowing a packet to be | |||
| forwarded to its destination address. | forwarded to its destination address. | |||
| In the case of IP multicast traffic, an IGMP snooping switch | In the case of IP multicast traffic, an IGMP snooping switch | |||
| provides the benefit of conserving bandwidth on those segments of | provides the benefit of conserving bandwidth on those segments of | |||
| the network where no node has expressed interest in receiving | the network where no node has expressed interest in receiving | |||
| packets addressed to the group address. This is in contrast to | packets addressed to the group address. This is in contrast to | |||
| normal switch behavior where multicast traffic is typically | normal switch behavior where multicast traffic is typically | |||
| forwarded on all interfaces. | forwarded on all interfaces. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| Many switch datasheets state support for IGMP snooping, but no | Many switch datasheets state support for IGMP snooping, but no | |||
| recommendations for this exist today. It is the authors' hope that | recommendations for this exist today. It is the authors' hope that | |||
| the information presented in this draft will supply this | the information presented in this draft will supply this | |||
| foundation. | foundation. | |||
| MLD Snooping Switches | ||||
| The recommendations presented here are based on the following | The recommendations presented here are based on the following | |||
| information sources: The IGMP specifications [RFC1112], [RFC2236] | information sources: The IGMP specifications [RFC1112], [RFC2236] | |||
| and [IGMPv3], vendor-supplied technical documents [CISCO], bug | and [IGMPv3], vendor-supplied technical documents [CISCO], bug | |||
| reports [MSOFT], discussions with people involved in the design of | reports [MSOFT], discussions with people involved in the design of | |||
| IGMP snooping switches, MAGMA mailing list discussions, and on | IGMP snooping switches, MAGMA mailing list discussions, and on | |||
| replies by switch vendors to an implementation questionnaire. | replies by switch vendors to an implementation questionnaire. | |||
| Interoperability issues that arise between different versions of | Interoperability issues that arise between different versions of | |||
| IGMP are not the focus of this document. Interested readers are | IGMP are not the focus of this document. Interested readers are | |||
| directed to [IGMPv3] for a thorough description of problem areas. | directed to [IGMPv3] for a thorough description of problem areas. | |||
| skipping to change at page 1, line 141 ¶ | skipping to change at page 1, line 149 ¶ | |||
| snooping switch. The recommendation is stated and is supplemented | snooping switch. The recommendation is stated and is supplemented | |||
| by a description of a possible implementation approach. All | by a description of a possible implementation approach. All | |||
| implementation discussions are examples only and there may well be | implementation discussions are examples only and there may well be | |||
| other ways to achieve the same functionality. | other ways to achieve the same functionality. | |||
| 2.1. Forwarding rules | 2.1. Forwarding rules | |||
| The IGMP snooping functionality is separated into a control section | The IGMP snooping functionality is separated into a control section | |||
| (IGMP forwarding) and a data section (Data forwarding). | (IGMP forwarding) and a data section (Data forwarding). | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| 2.1.1. IGMP Forwarding Rules | 2.1.1. IGMP Forwarding Rules | |||
| 1) A snooping switch should forward IGMP Membership Reports only | 1) A snooping switch should forward IGMP Membership Reports only | |||
| to those ports where multicast routers are attached. | to those ports where multicast routers are attached. | |||
| MLD Snooping Switches | ||||
| Alternatively stated: a snooping switch should not forward IGMP | Alternatively stated: a snooping switch should not forward IGMP | |||
| Membership Reports to ports on which only hosts are attached. | Membership Reports to ports on which only hosts are attached. | |||
| An administrative control may be provided to override this | An administrative control may be provided to override this | |||
| restriction, allowing the report messages to be flooded to | restriction, allowing the report messages to be flooded to | |||
| other ports. | other ports. | |||
| This is the main IGMP snooping functionality for the control | This is the main IGMP snooping functionality for the control | |||
| path. | path. | |||
| Sending membership reports to other hosts can result, for | Sending membership reports to other hosts can result, for | |||
| skipping to change at page 1, line 192 ¶ | skipping to change at page 1, line 200 ¶ | |||
| Multicast Router Solicitation messages as described in IGMP | Multicast Router Solicitation messages as described in IGMP | |||
| Multicast Router Discovery [MRDISC]. It may also snoop | Multicast Router Discovery [MRDISC]. It may also snoop | |||
| Multicast Router Advertisement messages sent by and to | Multicast Router Advertisement messages sent by and to | |||
| other nodes. | other nodes. | |||
| b) The arrival port for IGMP Queries (sent by multicast | b) The arrival port for IGMP Queries (sent by multicast | |||
| routers) where the source address is not 0.0.0.0. | routers) where the source address is not 0.0.0.0. | |||
| The 0.0.0.0 address represents a special case where the | The 0.0.0.0 address represents a special case where the | |||
| switch is proxying IGMP Queries for faster network | switch is proxying IGMP Queries for faster network | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| convergence, but is not itself the Querier. The switch | convergence, but is not itself the Querier. The switch | |||
| does not use its own IP address (even if it has one), | does not use its own IP address (even if it has one), | |||
| because this would cause the Queries to be seen as coming | because this would cause the Queries to be seen as coming | |||
| from a newly elected Querier. The 0.0.0.0 address is used | from a newly elected Querier. The 0.0.0.0 address is used | |||
| MLD Snooping Switches | ||||
| to indicate that the Query packets are NOT from a multicast | to indicate that the Query packets are NOT from a multicast | |||
| router. | router. | |||
| c) Ports explicitly configured by management to be IGMP- | c) Ports explicitly configured by management to be IGMP- | |||
| forwarding ports, in addition to or instead of any of the | forwarding ports, in addition to or instead of any of the | |||
| above methods to detect router ports. | above methods to detect router ports. | |||
| 2) IGMP networks may include devices which implement "proxy- | 2) IGMP networks may include devices which implement "proxy- | |||
| reporting", in which reports received from downstream hosts are | reporting", in which reports received from downstream hosts are | |||
| summarized and used to build internal membership states. Such | summarized and used to build internal membership states. Such | |||
| skipping to change at page 1, line 241 ¶ | skipping to change at page 1, line 251 ¶ | |||
| The reason to worry about these trivialities is that IGMPv3 | The reason to worry about these trivialities is that IGMPv3 | |||
| overloads the old IGMP query message using the same type number | overloads the old IGMP query message using the same type number | |||
| (0x11) but with an extended header. Therefore there is a risk | (0x11) but with an extended header. Therefore there is a risk | |||
| that IGMPv3 queries may be interpreted as older version queries | that IGMPv3 queries may be interpreted as older version queries | |||
| by, for example, IGMPv2 snooping switches. This has already | by, for example, IGMPv2 snooping switches. This has already | |||
| been reported [IETF56] and is discussed in section 2.2. | been reported [IETF56] and is discussed in section 2.2. | |||
| 4) An IGMP snooping switch should be aware of link layer topology | 4) An IGMP snooping switch should be aware of link layer topology | |||
| changes caused by Spanning Tree operation. When a port is | changes caused by Spanning Tree operation. When a port is | |||
| enabled or disabled by Spanning Tree, a General Query may be | enabled or disabled by Spanning Tree, a General Query may be | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| sent on all active non-router ports in order to reduce network | sent on all active non-router ports in order to reduce network | |||
| convergence time. Non-Querier switches should be aware of | convergence time. Non-Querier switches should be aware of | |||
| whether the Querier is in IGMPv3 mode. If so, the switch should | whether the Querier is in IGMPv3 mode. If so, the switch should | |||
| not spoof any General Queries unless it is able to send an | not spoof any General Queries unless it is able to send an | |||
| MLD Snooping Switches | ||||
| IGMPv3 Query that adheres to the most recent information sent | IGMPv3 Query that adheres to the most recent information sent | |||
| by the true Querier. In no case should a switch introduce a | by the true Querier. In no case should a switch introduce a | |||
| spoofed IGMPv2 Query into an IGMPv3 network, as this may create | spoofed IGMPv2 Query into an IGMPv3 network, as this may create | |||
| excessive network disruption. | excessive network disruption. | |||
| If the switch is not the Querier, it should use the 'all-zeros' | If the switch is not the Querier, it should use the 'all-zeros' | |||
| IP Source Address in these proxy queries (even though some | IP Source Address in these proxy queries (even though some | |||
| hosts may elect to not process queries with a 0.0.0.0 IP Source | hosts may elect to not process queries with a 0.0.0.0 IP Source | |||
| Address). When such proxy queries are received, they must not | Address). When such proxy queries are received, they must not | |||
| be included in the Querier election process. | be included in the Querier election process. | |||
| skipping to change at page 1, line 290 ¶ | skipping to change at page 1, line 302 ¶ | |||
| This is the main IGMP snooping functionality for the data path. | This is the main IGMP snooping functionality for the data path. | |||
| One approach that an implementation could take would be to | One approach that an implementation could take would be to | |||
| maintain separate membership and multicast router tables in | maintain separate membership and multicast router tables in | |||
| software and then "merge" these tables into a forwarding cache. | software and then "merge" these tables into a forwarding cache. | |||
| 2) Packets with a destination IP (DIP) address in the 224.0.0.X | 2) Packets with a destination IP (DIP) address in the 224.0.0.X | |||
| range which are not IGMP must be forwarded on all ports. | range which are not IGMP must be forwarded on all ports. | |||
| This recommendation is based on fact that many host systems do | This recommendation is based on fact that many host systems do | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| not send Join IP multicast addresses in this range before | not send Join IP multicast addresses in this range before | |||
| sending or listening to IP multicast packets. Furthermore, | sending or listening to IP multicast packets. Furthermore, | |||
| since the 224.0.0.X address range is defined as link-local (not | since the 224.0.0.X address range is defined as link-local (not | |||
| to be routed) it seems unnecessary to keep state for each | to be routed) it seems unnecessary to keep state for each | |||
| MLD Snooping Switches | ||||
| address in this range. Additionally, some routers operate in | address in this range. Additionally, some routers operate in | |||
| the 224.0.0.X address range without issuing IGMP Joins, and | the 224.0.0.X address range without issuing IGMP Joins, and | |||
| these applications would break if the switch were to prune them | these applications would break if the switch were to prune them | |||
| due to not having seen a Join Group message from the router. | due to not having seen a Join Group message from the router. | |||
| 3) An unregistered packet is defined as an IPv4 multicast packet | 3) An unregistered packet is defined as an IPv4 multicast packet | |||
| with a destination address which does not match any of the | with a destination address which does not match any of the | |||
| groups announced in earlier IGMP Membership Reports. | groups announced in earlier IGMP Membership Reports. | |||
| If a switch receives an unregistered packet, it must forward | If a switch receives an unregistered packet, it must forward | |||
| skipping to change at page 1, line 340 ¶ | skipping to change at page 1, line 354 ¶ | |||
| previously been joined as IGMPv2 (because the data stream is | previously been joined as IGMPv2 (because the data stream is | |||
| seen as already having been registered). | seen as already having been registered). | |||
| 4) All non-IPv4 multicast packets should continue to be flooded | 4) All non-IPv4 multicast packets should continue to be flooded | |||
| out all remaining ports in the forwarding state as per normal | out all remaining ports in the forwarding state as per normal | |||
| IEEE bridging operations. | IEEE bridging operations. | |||
| This recommendation is a result of the fact that groups made up | This recommendation is a result of the fact that groups made up | |||
| of IPv4 hosts and IPv6 hosts are completely separate and | of IPv4 hosts and IPv6 hosts are completely separate and | |||
| distinct groups. As a result, information gleaned from the | distinct groups. As a result, information gleaned from the | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| topology between members of an IPv4 group would not be | topology between members of an IPv4 group would not be | |||
| applicable when forming the topology between members of an IPv6 | applicable when forming the topology between members of an IPv6 | |||
| group. | group. | |||
| MLD Snooping Switches | ||||
| 5) IGMP snooping switches may maintain forwarding tables based on | 5) IGMP snooping switches may maintain forwarding tables based on | |||
| either MAC addresses or IP addresses. If a switch supports | either MAC addresses or IP addresses. If a switch supports | |||
| both types of forwarding tables then the default behavior | both types of forwarding tables then the default behavior | |||
| should be to use IP addresses. IP address based forwarding is | should be to use IP addresses. IP address based forwarding is | |||
| preferred because the mapping between IP multicast addresses | preferred because the mapping between IP multicast addresses | |||
| and link-layer multicast addresses is ambiguous. In the case | and link-layer multicast addresses is ambiguous. In the case | |||
| of Ethernet, there is a multiplicity of 1 Ethernet address to | of Ethernet, there is a multiplicity of 1 Ethernet address to | |||
| 32 IP addresses [RFC1112]. | 32 IP addresses [RFC1112]. | |||
| 6) Switches which rely on information in the IP header should | 6) Switches which rely on information in the IP header should | |||
| skipping to change at page 1, line 388 ¶ | skipping to change at page 1, line 404 ¶ | |||
| 2.2. IGMP snooping-related problems | 2.2. IGMP snooping-related problems | |||
| A special problem arises in networks consisting of IGMPv3 routers | A special problem arises in networks consisting of IGMPv3 routers | |||
| as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 | as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 | |||
| snooping switch as recently reported [IETF56]. The router will | snooping switch as recently reported [IETF56]. The router will | |||
| continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, | continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, | |||
| and thus the network will not converge on IGMPv2. But it is likely | and thus the network will not converge on IGMPv2. But it is likely | |||
| that the IGMPv2 snooping switch will not recognize or process the | that the IGMPv2 snooping switch will not recognize or process the | |||
| IGMPv3 membership reports. Groups for these unrecognized reports | IGMPv3 membership reports. Groups for these unrecognized reports | |||
| will then either be flooded (with all of the problems that may | will then either be flooded (with all of the problems that may | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| create for hosts in a network with a heavy multicast load) or | create for hosts in a network with a heavy multicast load) or | |||
| pruned by the snooping switch. | pruned by the snooping switch. | |||
| Therefore, it is recommended that in such a network, the multicast | Therefore, it is recommended that in such a network, the multicast | |||
| MLD Snooping Switches | ||||
| router be configured to use IGMPv2. If this is not possible, and if | router be configured to use IGMPv2. If this is not possible, and if | |||
| the snooping switch cannot recognize and process the IGMPv3 | the snooping switch cannot recognize and process the IGMPv3 | |||
| membership reports, it is instead recommended that the switch's | membership reports, it is instead recommended that the switch's | |||
| IGMP snooping functionality be disabled, as there is no clear | IGMP snooping functionality be disabled, as there is no clear | |||
| solution to this problem. | solution to this problem. | |||
| 3. IPv6 Considerations | 3. IPv6 Considerations | |||
| In order to avoid confusion, the previous discussions have been | In order to avoid confusion, the previous discussions have been | |||
| based on the IGMP protocol which only applies to IPv4 multicast. | based on the IGMP protocol which only applies to IPv4 multicast. | |||
| skipping to change at page 1, line 437 ¶ | skipping to change at page 1, line 455 ¶ | |||
| snooping switch because of an unspecified IP source address (::). | snooping switch because of an unspecified IP source address (::). | |||
| Additionally, if a non-Querier switch spoofs any General Queries | Additionally, if a non-Querier switch spoofs any General Queries | |||
| (as addressed in Section 2.1 above, for Spanning Tree topology | (as addressed in Section 2.1 above, for Spanning Tree topology | |||
| changes), the switch should use the null IP source address (::) | changes), the switch should use the null IP source address (::) | |||
| when sending said queries. When such proxy queries are received, | when sending said queries. When such proxy queries are received, | |||
| they must not be included in the Querier election process. | they must not be included in the Querier election process. | |||
| The three major differences between IPv4 and IPv6 in relation to | The three major differences between IPv4 and IPv6 in relation to | |||
| multicast are: | multicast are: | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| - The IPv6 protocol for multicast group maintenance is called | - The IPv6 protocol for multicast group maintenance is called | |||
| Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message | Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message | |||
| types instead of IGMP message types. | types instead of IGMP message types. | |||
| MLD Snooping Switches | ||||
| - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 | - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 | |||
| bit DIP address are used to form the 48 bit DMAC addresses for | bit DIP address are used to form the 48 bit DMAC addresses for | |||
| multicast groups, while [IPV6-TOKEN] describes the mapping for | multicast groups, while [IPV6-TOKEN] describes the mapping for | |||
| token ring DMAC addresses by using three low-order bits. The | token ring DMAC addresses by using three low-order bits. The | |||
| specification [IPV6-1394] makes use of a 6 bit channel number. | specification [IPV6-1394] makes use of a 6 bit channel number. | |||
| - Multicast router discovery is accomplished using Neighbor | - Multicast router discovery is accomplished using Neighbor | |||
| Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message | Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message | |||
| types. | types. | |||
| skipping to change at page 1, line 488 ¶ | skipping to change at page 1, line 507 ¶ | |||
| types is inflexible for the introduction of new message types. The | types is inflexible for the introduction of new message types. The | |||
| second solution introduces the risk that new protocols which use | second solution introduces the risk that new protocols which use | |||
| ICMPv6 and multicast DMAC addresses could be incorrectly identified | ICMPv6 and multicast DMAC addresses could be incorrectly identified | |||
| as MLD. It is suggested that solution one is preferred when the | as MLD. It is suggested that solution one is preferred when the | |||
| configuration option is provided. If this is not the case, then | configuration option is provided. If this is not the case, then | |||
| the implementor should seriously consider making it available since | the implementor should seriously consider making it available since | |||
| Neighbor Discovery messages would be among those that fall into | Neighbor Discovery messages would be among those that fall into | |||
| this false positive case and are vital for the operational | this false positive case and are vital for the operational | |||
| integrity of IPv6 networks. | integrity of IPv6 networks. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| The mapping from IP multicast addresses to multicast DMAC addresses | The mapping from IP multicast addresses to multicast DMAC addresses | |||
| introduces a potentially enormous overlap. The structure of an | introduces a potentially enormous overlap. The structure of an | |||
| IPv6 multicast address is shown in the figure below. As a result, | IPv6 multicast address is shown in the figure below. As a result, | |||
| MLD Snooping Switches | ||||
| there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses | there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses | |||
| which map into a single DMAC address in Ethernet and FDDI. This | which map into a single DMAC address in Ethernet and FDDI. This | |||
| should be compared to 2**5 in the case of IPv4. | should be compared to 2**5 in the case of IPv4. | |||
| Initial allocation of IPv6 multicast addresses as described in | Initial allocation of IPv6 multicast addresses as described in | |||
| [RFC3307], however, cover only the lower 32 bits of group ID. | [RFC3307], however, cover only the lower 32 bits of group ID. | |||
| While this reduces the problem of address ambiguity to group IDs | While this reduces the problem of address ambiguity to group IDs | |||
| with different flag and scope values for now, it should be noted | with different flag and scope values for now, it should be noted | |||
| that the allocation policy may change in the future. Because of | that the allocation policy may change in the future. Because of | |||
| the potential overlap it is recommended that IPv6 address based | the potential overlap it is recommended that IPv6 address based | |||
| skipping to change at page 1, line 538 ¶ | skipping to change at page 1, line 558 ¶ | |||
| Q3 Is it possible to forward multicast datagrams based on IP | Q3 Is it possible to forward multicast datagrams based on IP | |||
| addresses (not routed)? In other words, could 224.1.2.3 and | addresses (not routed)? In other words, could 224.1.2.3 and | |||
| 239.129.2.3 be forwarded on different port-groups with | 239.129.2.3 be forwarded on different port-groups with | |||
| unaltered TTL? | unaltered TTL? | |||
| Q4 Are multicast datagrams within the range 224.0.0.1 to | Q4 Are multicast datagrams within the range 224.0.0.1 to | |||
| 224.0.0.255 forwarded on all ports whether or not IGMP Joins | 224.0.0.255 forwarded on all ports whether or not IGMP Joins | |||
| have been sent? | have been sent? | |||
| Q5 Are multicast frames within the MAC address range | RFC DRAFT Considerations for IGMP and February 2005 | |||
| 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports | ||||
| MLD Snooping Switches | MLD Snooping Switches | |||
| Q5 Are multicast frames within the MAC address range | ||||
| 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports | ||||
| whether or not IGMP joins have been sent? | whether or not IGMP joins have been sent? | |||
| Q6 Does your switch support forwarding to ports on which IP | Q6 Does your switch support forwarding to ports on which IP | |||
| multicast routers are attached in addition to the ports where | multicast routers are attached in addition to the ports where | |||
| IGMP Joins have been received? | IGMP Joins have been received? | |||
| Q7 Is your IGMP snooping functionality fully implemented in | Q7 Is your IGMP snooping functionality fully implemented in | |||
| hardware? | hardware? | |||
| Q8 Is your IGMP snooping functionality partly software | Q8 Is your IGMP snooping functionality partly software | |||
| skipping to change at page 1, line 585 ¶ | skipping to change at page 1, line 606 ¶ | |||
| ---------------------------+---+---+---+---+---+---+ | ---------------------------+---+---+---+---+---+---+ | |||
| x Means that the answer was Yes. | x Means that the answer was Yes. | |||
| (1) In some products (typically high-end) Yes; in others No. | (1) In some products (typically high-end) Yes; in others No. | |||
| (2) Not at the time that the questionnaire was received | (2) Not at the time that the questionnaire was received | |||
| but expected in the near future. | but expected in the near future. | |||
| Revision History | Revision History | |||
| [To RFC Editor: This section is to be removed at publication time] | [To RFC Editor: This section is to be removed at publication time] | |||
| This section, while incomplete, is provided as a convenience to the | RFC DRAFT Considerations for IGMP and February 2005 | |||
| working group members. It will be removed when the document is | ||||
| MLD Snooping Switches | MLD Snooping Switches | |||
| This section, while incomplete, is provided as a convenience to the | ||||
| working group members. It will be removed when the document is | ||||
| released in its final form. | released in its final form. | |||
| draft-ietf-magma-snoop-12.txt: January 2005 | ||||
| Editorial changes only: | ||||
| Update document references and author address; IPR and | ||||
| disclaimer statements to adhere to RFC3668 requirements. | ||||
| draft-ietf-magma-snoop-11.txt: April 2004 | draft-ietf-magma-snoop-11.txt: April 2004 | |||
| Editorial changes only: | Editorial changes only: | |||
| Remove reference to IGMP/MLD Proxy (draft-ietf-magma- | Remove reference to IGMP/MLD Proxy (draft-ietf-magma- | |||
| proxy-06.txt) to avoid perception of content dependency. | proxy-06.txt) to avoid perception of content dependency. | |||
| Updated references to reflect current revisions, author | Updated references to reflect current revisions, author | |||
| address. | address. | |||
| skipping to change at page 1, line 629 ¶ | skipping to change at page 1, line 658 ¶ | |||
| Substantial comments | Substantial comments | |||
| There were no substantial technical comments, but a list | There were no substantial technical comments, but a list | |||
| of suggested wordings and clarifications to improve the | of suggested wordings and clarifications to improve the | |||
| readability and RFC conformance of the draft. | readability and RFC conformance of the draft. | |||
| Reference in Abstract removed. Improved wording in | Reference in Abstract removed. Improved wording in | |||
| Introduction. | Introduction. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| Improved wording in recommendations section, clarified | Improved wording in recommendations section, clarified | |||
| integrity checking for IPv6, removed security issues | integrity checking for IPv6, removed security issues | |||
| which were really IGMP/MLD security issues. | which were really IGMP/MLD security issues. | |||
| Editorial Changes | Editorial Changes | |||
| Author information changes, TOC added, fixed a wrong | Author information changes, TOC added, fixed a wrong | |||
| indentation following section 5. | indentation following section 5. | |||
| MLD Snooping Switches | ||||
| draft-ietf-magma-snoop-08.txt: June 2003 | draft-ietf-magma-snoop-08.txt: June 2003 | |||
| The changes in this version are the result of the WG chair | The changes in this version are the result of the WG chair | |||
| review following the second WG last call. The last call itself | review following the second WG last call. The last call itself | |||
| did not result in further comments. | did not result in further comments. | |||
| Substantial comments | Substantial comments | |||
| Requirements have now been replaced with Recommendations | Requirements have now been replaced with Recommendations | |||
| throughout the draft, which is more appropriate for an | throughout the draft, which is more appropriate for an | |||
| skipping to change at page 1, line 679 ¶ | skipping to change at page 1, line 709 ¶ | |||
| Moved reference to RFC2375 to the Informative section. | Moved reference to RFC2375 to the Informative section. | |||
| draft-ietf-magma-snoop-07.txt: May 2003 | draft-ietf-magma-snoop-07.txt: May 2003 | |||
| The current version reflects comments made at the 56'th IETF | The current version reflects comments made at the 56'th IETF | |||
| meeting and from the previous WG last call. The majority of | meeting and from the previous WG last call. The majority of | |||
| changes appear in sections 2.1 and 2.2, and even the changes | changes appear in sections 2.1 and 2.2, and even the changes | |||
| here are in reality not substantial. | here are in reality not substantial. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| Substantial comments | Substantial comments | |||
| Section 2.1.1.(4): Changed wording for IGMP forwarding | Section 2.1.1.(4): Changed wording for IGMP forwarding | |||
| section on when spoofing of General Queries should occur. | section on when spoofing of General Queries should occur. | |||
| Added description of how to avoid IGMP version | Added description of how to avoid IGMP version | |||
| incompatibility problems when doing said spoofing. | incompatibility problems when doing said spoofing. | |||
| Section 2.1.2.(3): Clarification of incompatibility | Section 2.1.2.(3): Clarification of incompatibility | |||
| problems in mixed IGMPv2 and IGMPv3 networks. Added | problems in mixed IGMPv2 and IGMPv3 networks. Added | |||
| MLD Snooping Switches | ||||
| recommendation for switches to implement some level of | recommendation for switches to implement some level of | |||
| IGMPv3 Join recognition to reduce these problems. | IGMPv3 Join recognition to reduce these problems. | |||
| Section 2.2: Advice following the briefing [IETF56], that | Section 2.2: Advice following the briefing [IETF56], that | |||
| in some cases disabling IGMP snooping functionality is | in some cases disabling IGMP snooping functionality is | |||
| the only 'solution' | the only 'solution' | |||
| Section 6, IPv6 Considerations: added descriptions of | Section 6, IPv6 Considerations: added descriptions of | |||
| behavior involving the IPv6 version of the null IP Source | behavior involving the IPv6 version of the null IP Source | |||
| Address (to parallel the IPv4 behaviors). | Address (to parallel the IPv4 behaviors). | |||
| skipping to change at page 1, line 730 ¶ | skipping to change at page 1, line 761 ¶ | |||
| Section 2.1.1.(4): Allow the router port to be excluded | Section 2.1.1.(4): Allow the router port to be excluded | |||
| from the General Query messages | from the General Query messages | |||
| Section 2.1.1.(6): Replace description of timing out | Section 2.1.1.(6): Replace description of timing out | |||
| older entries with a reference to IGMP/MLD Proxying. | older entries with a reference to IGMP/MLD Proxying. | |||
| Section 2.1.2.(3): Replaced description of timeout | Section 2.1.2.(3): Replaced description of timeout | |||
| mechanism with a reference to IGMP/MLD. | mechanism with a reference to IGMP/MLD. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| Section 2.1.2.(4) Expanded rationale to discourage | Section 2.1.2.(4) Expanded rationale to discourage | |||
| leaking info between IPv4 and IPv6 groups. | leaking info between IPv4 and IPv6 groups. | |||
| Section 3: more strongly encourage the use of a | Section 3: more strongly encourage the use of a | |||
| configuration option for selection of ICMPv6 message | configuration option for selection of ICMPv6 message | |||
| types. | types. | |||
| Editorial comments. | Editorial comments. | |||
| MLD Snooping Switches | ||||
| Hyphenation problem resolved for groff by setting then ms | Hyphenation problem resolved for groff by setting then ms | |||
| HY register to zero, disabling all forms for the entire | HY register to zero, disabling all forms for the entire | |||
| document | document | |||
| (".hy 0" and ".nr" worked only as far as the following | (".hy 0" and ".nr" worked only as far as the following | |||
| ms macro). | ms macro). | |||
| Sections moved around - again - to comply with | Sections moved around - again - to comply with | |||
| rfc2223bis-03 draft. Added copyright notice after memo | rfc2223bis-03 draft. Added copyright notice after memo | |||
| status. Removed table of contents as the draft is fairly | status. Removed table of contents as the draft is fairly | |||
| short. Corrected a reference typo. | short. Corrected a reference typo. | |||
| skipping to change at page 1, line 780 ¶ | skipping to change at page 1, line 812 ¶ | |||
| References splitted in normative and informative sections, | References splitted in normative and informative sections, | |||
| other related references added. | other related references added. | |||
| Abstract shortened. | Abstract shortened. | |||
| Changed all occurances of MUST, MAY etc. to lowercase to | Changed all occurances of MUST, MAY etc. to lowercase to | |||
| reflect that this is not a standards track document. | reflect that this is not a standards track document. | |||
| Sections moved around so they appear in the required order. | Sections moved around so they appear in the required order. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| draft-ietf-magma-snoop-04.txt: November 2002 | draft-ietf-magma-snoop-04.txt: November 2002 | |||
| Editorial changes only. | Editorial changes only. | |||
| draft-ietf-magma-snoop-03.txt: October 2002 | draft-ietf-magma-snoop-03.txt: October 2002 | |||
| IGMP Forwarding rules: | IGMP Forwarding rules: | |||
| Add references to and become consistant with the current | Add references to and become consistant with the current | |||
| IGMP proxy draft, | IGMP proxy draft, | |||
| MLD Snooping Switches | ||||
| Unrecognized IGMP packets should not be ignored because | Unrecognized IGMP packets should not be ignored because | |||
| "mbz" fields are not zero since packets from future | "mbz" fields are not zero since packets from future | |||
| versions are expected to maintain consistency. | versions are expected to maintain consistency. | |||
| Corrections related to IGMP Querier election process. | Corrections related to IGMP Querier election process. | |||
| Add clarification to how lists of router ports may be | Add clarification to how lists of router ports may be | |||
| assembled. | assembled. | |||
| skipping to change at page 1, line 829 ¶ | skipping to change at page 1, line 863 ¶ | |||
| IPv6 Considerations: | IPv6 Considerations: | |||
| Clarifications regarding address ranges FF00::, FF01:: | Clarifications regarding address ranges FF00::, FF01:: | |||
| and all hosts FF02::1 in relation to data forwarding. | and all hosts FF02::1 in relation to data forwarding. | |||
| draft-ietf-magma-snoop-02.txt: June 2002 | draft-ietf-magma-snoop-02.txt: June 2002 | |||
| Status section removes document history; moved into this | Status section removes document history; moved into this | |||
| section instead. | section instead. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| Introduction restores text from the -00 revision that | Introduction restores text from the -00 revision that | |||
| describes snooping and its goals | describes snooping and its goals | |||
| IGMP flooding rules eased, allowing management option to | IGMP flooding rules eased, allowing management option to | |||
| broaden beyond "routers only". | broaden beyond "routers only". | |||
| Removed a should/MAY inconsistancy between IPv4 Forwarding and | Removed a should/MAY inconsistancy between IPv4 Forwarding and | |||
| IPv6 processing of checksums. | IPv6 processing of checksums. | |||
| MLD Snooping Switches | ||||
| IGMP Forwarding Rules: clarify text describing processing of | IGMP Forwarding Rules: clarify text describing processing of | |||
| non-zero reserved fields. | non-zero reserved fields. | |||
| Data Forwarding Rules, item 3 is changed from "MUST forward to | Data Forwarding Rules, item 3 is changed from "MUST forward to | |||
| all ports" to "MAY"; item 4 default changes from "MUST" to | all ports" to "MAY"; item 4 default changes from "MUST" to | |||
| "should use network addresses". | "should use network addresses". | |||
| Added two sets of additional responses to the questionnaire | Added two sets of additional responses to the questionnaire | |||
| and text indicating that responses don't cover all products. | and text indicating that responses don't cover all products. | |||
| skipping to change at page 1, line 877 ¶ | skipping to change at page 1, line 912 ¶ | |||
| 5. References | 5. References | |||
| 5.1. Normative References | 5.1. Normative References | |||
| [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" | [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" | |||
| [IGMPv3] Cain, B., "Internet Group Management Protocol, Version | [IGMPv3] Cain, B., "Internet Group Management Protocol, Version | |||
| 3", RFC3376, October 2002. | 3", RFC3376, October 2002. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 | [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 | |||
| Packets over IEEE 1394 Networks", RFC3146, October | Packets over IEEE 1394 Networks", RFC3146, October | |||
| 2001. | 2001. | |||
| [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over | [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over | |||
| Ethernet Networks", RFC2464, December 1998. | Ethernet Networks", RFC2464, December 1998. | |||
| MLD Snooping Switches | ||||
| [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI | [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI | |||
| Networks", RFC2467, December 1998. | Networks", RFC2467, December 1998. | |||
| [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission | [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission | |||
| of IPv6 Packets over Token Ring Networks", RFC2470, | of IPv6 Packets over Token Ring Networks", RFC2470, | |||
| December 1998. | December 1998. | |||
| [MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast | [MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast | |||
| Listener Discovery (MLD) for IPv6", RFC2710, October | Listener Discovery (MLD) for IPv6", RFC2710, October | |||
| 1999. | 1999. | |||
| [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery | [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery | |||
| Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-08.txt, | Version 2 (MLDv2) for IPv6", RFC3810, June 2004. | |||
| December 2003. | ||||
| [MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast | [MRDISC] Haberman, B. and Martin, J. "Multicast Router | |||
| Router Discovery", draft-ietf-magma-mrdisc-00.txt, | Discovery", draft-ietf-magma-mrdisc-03.txt, September | |||
| February 2004. | 2004. | |||
| [NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor | [NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor | |||
| Discovery for IP Version 6 {IPv6)", RFC2461, December | Discovery for IP Version 6 {IPv6)", RFC2461, December | |||
| 1998. | 1998. | |||
| [RFC1112] Deering, S., "Host Extensions for IP Multicasting", | [RFC1112] Deering, S., "Host Extensions for IP Multicasting", | |||
| RFC1112, August 1989. | RFC1112, August 1989. | |||
| [RFC2026] Bradner, S. "The Internet Standards Process -- | ||||
| Revision 3", RFC2026, October 1996. | ||||
| [RFC2236] Fenner, W., "Internet Group Management Protocol, | [RFC2236] Fenner, W., "Internet Group Management Protocol, | |||
| Version 2", RFC2236, November 1997. | Version 2", RFC2236, November 1997. | |||
| [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 | [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 | |||
| Multicast Addresses", RFC3307, August 2002. | Multicast Addresses", RFC3307, August 2002. | |||
| [RFC3668] Bradner, S., "Intellectual Property Rights in IETF | ||||
| Technology", RFC3668, February 2004. | ||||
| 5.2. Informative References | 5.2. Informative References | |||
| [CISCO] | [CISCO] | |||
| Cisco Tech Notes, "Multicast In a Campus Network: CGMP and | Cisco Tech Notes, "Multicast In a Campus Network: CGMP and | |||
| IGMP snooping", http://www.cisco.com/warp/public/473/22.html | IGMP snooping", http://www.cisco.com/warp/public/473/22.html | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| [IANA] Internet Assigned Numbers Authority, "Internet | [IANA] Internet Assigned Numbers Authority, "Internet | |||
| Multicast Addresses", | Multicast Addresses", | |||
| http://www.iana.org/assignments/multicast-addresses | http://www.iana.org/assignments/multicast-addresses | |||
| MLD Snooping Switches | ||||
| [IETF56] Briefing by Dave Thaler, Microsoft, presented to the | [IETF56] Briefing by Dave Thaler, Microsoft, presented to the | |||
| MAGMA WG at the 56'th IETF meeting in San Francisco, | MAGMA WG at the 56'th IETF meeting in San Francisco, | |||
| http://www.ietf.org/proceedings/03mar/index.html | http://www.ietf.org/proceedings/03mar/index.html | |||
| [MSOFT] Microsoft support article Q223136, "Some LAN Switches | [MSOFT] Microsoft support article Q223136, "Some LAN Switches | |||
| with IGMP Snooping Stop Forwarding Multicast Packets | with IGMP Snooping Stop Forwarding Multicast Packets | |||
| on RRAS Startup", | on RRAS Startup", | |||
| http://support.microsoft.com/support/articles/Q223/1/36.ASP | ||||
| http://support.microsoft.com/support/articles/Q223/1/36.ASP | ||||
| 6. Security Considerations | 6. Security Considerations | |||
| Under normal network operation, the snooping switch is expected to | Under normal network operation, the snooping switch is expected to | |||
| improve overall network performance by limiting the scope of | improve overall network performance by limiting the scope of | |||
| multicast flooding to a smaller portion of the local network. In | multicast flooding to a smaller portion of the local network. In | |||
| the event of forged IGMP messages, the benefits of using a snooping | the event of forged IGMP messages, the benefits of using a snooping | |||
| switch might be reduced or eliminated. | switch might be reduced or eliminated. | |||
| Security considerations for IGMPv3 at the network layer of the | Security considerations for IGMPv3 at the network layer of the | |||
| skipping to change at page 1, line 974 ¶ | skipping to change at page 1, line 1010 ¶ | |||
| should be sent to all multicast routers as well as the current | should be sent to all multicast routers as well as the current | |||
| Querier. | Querier. | |||
| - It is possible for a host on the local network to generate | - It is possible for a host on the local network to generate | |||
| Current-State Report Messages that would cause the switch to | Current-State Report Messages that would cause the switch to | |||
| incorrectly believe that there is a multicast listener on the | incorrectly believe that there is a multicast listener on the | |||
| same network segment as the originator of the forged message. | same network segment as the originator of the forged message. | |||
| This will cause unrequested multicast packets to be forwarded | This will cause unrequested multicast packets to be forwarded | |||
| into the network segments between the source and the router. | into the network segments between the source and the router. | |||
| If the router requires that all Multicast Report messages be | If the router requires that all Multicast Report messages be | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| authenticated as described in section 9.4 of [IGMPv3], it will | authenticated as described in section 9.4 of [IGMPv3], it will | |||
| discard the forged Report message from the host inside the | discard the forged Report message from the host inside the | |||
| network in the same way that it would discard one which | network in the same way that it would discard one which | |||
| originates from a remote location. It is worth noting that if | originates from a remote location. It is worth noting that if | |||
| MLD Snooping Switches | ||||
| the router accepts unauthenticated Report messages by virtue of | the router accepts unauthenticated Report messages by virtue of | |||
| them having arrived over a network interface associated with | them having arrived over a network interface associated with | |||
| the internal network, investigating the affected network | the internal network, investigating the affected network | |||
| segments will quickly narrow the search for the source of the | segments will quickly narrow the search for the source of the | |||
| forged messages. | forged messages. | |||
| - As noted in [IGMPv3], there is little motivation for an | - As noted in [IGMPv3], there is little motivation for an | |||
| attacker to forge a Membership report message since joining a | attacker to forge a Membership report message since joining a | |||
| group is generally an unprivileged operation. The sender of | group is generally an unprivileged operation. The sender of | |||
| the forged Membership report will be the only recipient of the | the forged Membership report will be the only recipient of the | |||
| skipping to change at page 1, line 1015 ¶ | skipping to change at page 1, line 1053 ¶ | |||
| Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka | Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka | |||
| Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret | Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret | |||
| Wasserman for comments and suggestions on this document. | Wasserman for comments and suggestions on this document. | |||
| Furthermore, the following companies are acknowledged for their | Furthermore, the following companies are acknowledged for their | |||
| contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, | contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, | |||
| Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane | Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane | |||
| The ordering of these names do not necessarily correspond to the | The ordering of these names do not necessarily correspond to the | |||
| column numbers in the response table. | column numbers in the response table. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | MLD Snooping Switches | |||
| 8. Authors' Addresses | 8. Authors' Addresses | |||
| Morten Jagd Christensen | Morten Jagd Christensen | |||
| Thrane & Thrane | Thrane & Thrane | |||
| Lundtoftegaardsvej 93 D | Lundtoftegaardsvej 93 D | |||
| 2800 Lyngby | 2800 Lyngby | |||
| DENMARK | DENMARK | |||
| email: mjc@tt.dk | email: mjc@tt.dk | |||
| Karen Kimball | Karen Kimball | |||
| Hewlett-Packard | Hewlett-Packard | |||
| 8000 Foothills Blvd. | 8000 Foothills Blvd. | |||
| Roseville, CA 95747 | Roseville, CA 95747 | |||
| USA | USA | |||
| email: karen.kimball@hp.com | email: karen.kimball@hp.com | |||
| Frank Solensky | Frank Solensky | |||
| West Ridge Networks | Calix Networks | |||
| 25 Porter Rd. | 43 Nanog Park | |||
| Littleton, MA 01460 | Acton, MA 01720 | |||
| USA | USA | |||
| email: fsolensky@WestRidgeNetworks.com | email: frank.solensky@calix.com | |||
| 9. IETF IPR Statement | 9. IETF IPR Statement | |||
| "The IETF takes no position regarding the validity or scope of any | "The IETF takes no position regarding the validity or scope of any | |||
| intellectual property or other rights that might be claimed to | intellectual property or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
| might or might not be available; neither does it represent that it | might or might not be available; neither does it represent that it | |||
| has made any effort to identify any such rights. Information on | has made any effort to identify any such rights. Information on | |||
| the IETF's procedures with respect to rights in standards-track and | the IETF's procedures with respect to rights in standards-track and | |||
| standards-related documentation can be found in [RFC-2026]. Copies | standards-related documentation can be found in [RFC-2026]. Copies | |||
| of claims of rights made available for publication and any | of claims of rights made available for publication and any | |||
| assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
| attempt made to obtain a general license or permission for the use | attempt made to obtain a general license or permission for the use | |||
| of such proprietary rights by implementors or users of this | of such proprietary rights by implementors or users of this | |||
| specification can be obtained from the IETF Secretariat." | specification can be obtained from the IETF Secretariat." | |||
| 10. Full Copyright Statement | 10. Full Copyright Statement | |||
| Copyright (C) The Internet Society (2003). All Rights Reserved. | Copyright (C) The Internet Society (2005). 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. | ||||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | ||||
| This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
| others, and derivative works that comment on or otherwise explain | others, and derivative works that comment on or otherwise explain | |||
| it or assist in its implementation may be prepared, copied, | it or assist in its implementation may be prepared, copied, | |||
| MLD Snooping Switches | ||||
| published and distributed, in whole or in part, without restriction | published and distributed, in whole or in part, without restriction | |||
| of any kind, provided that the above copyright notice and this | of any kind, provided that the above copyright notice and this | |||
| paragraph are included on all such copies and derivative works. | paragraph are included on all such copies and derivative works. | |||
| However, this document itself may not be modified in any way, such | However, this document itself may not be modified in any way, such | |||
| as by removing the copyright notice or references to the Internet | as by removing the copyright notice or references to the Internet | |||
| Society or other Internet organizations, except as needed for the | Society or other Internet organizations, except as needed for the | |||
| purpose of developing Internet standards in which case the | purpose of developing Internet standards in which case the | |||
| procedures for copyrights defined in the Internet Standards process | procedures for copyrights defined in the Internet Standards process | |||
| must be followed, or as required to translate it into languages | must be followed, or as required to translate it into languages | |||
| other than English. | other than English. | |||
| The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
| revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assigns. | |||
| This document and the information contained herein is provided on | This document and the information contained herein are provided on | |||
| an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
| ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | |||
| IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | |||
| THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | |||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR | |||
| ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | ||||
| PARTICULAR PURPOSE. | ||||
| Acknowledgement: | Acknowledgement: | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | Internet Society. | |||
| RFC DRAFT Considerations for IGMP and February 2005 | ||||
| MLD Snooping Switches | MLD Snooping Switches | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3 | 2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3 | |||
| 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3 | 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 4 | |||
| 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6 | 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6 | |||
| 2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 8 | 2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 8 | |||
| 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9 | 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9 | |||
| 4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11 | 4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 4. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 | 4. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 | 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 | |||
| 5.2. Informative References . . . . . . . . . . . . . . . . . . 19 | 5.2. Informative References . . . . . . . . . . . . . . . . . . 19 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . 20 | 6. Security Considerations . . . . . . . . . . . . . . . . . . 20 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| End of changes. 59 change blocks. | ||||
| 68 lines changed or deleted | 114 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||