Draft ietf magma snoop 11 txt

In the case of multi- cast packets, however, this approach could lead to less efficient use of network bandwidth, particularly when the packet is intended for only a small number of nodes. Packets will be flooded into network segments where no node has any interest in receiving the packet. While nodes will rarely incur any processing overhead to filter packets addressed to unrequested group addresses, they are unable to transmit new packets onto the shared media for the period of time that the multicast packet is flooded.

In general, signifi- cant bandwidth can be wasted by flooding. In recent years, a number of commercial vendors have introduced products described as "IGMP snooping switches" to the market.

These devices do not adhere to the conceptual model that provides the strict separation of functionality between different communica- tions layers in the ISO model, and instead utilize information in the upper- level protocol headers as factors to be considered in the processing at the lower levels.

This is analogous to the man- ner in which a router can act as a firewall by looking into the transport protocol's header before allowing a packet to be for- warded to its destination address. In the case of multicast traffic, an IGMP snooping switch provides the benefit of conserving bandwidth on those segments of the net- work where no node has expressed interest in receiving packets addressed to the group address. This is in contrast to normal switch behavior where multicast traffic is typically forwarded on all interfaces.

Many switch datasheets state support for IGMP snooping, but no requirements for this exist today. It is the authors' hope that the information presented in this draft will supply this founda- tion. Instead, we point out the few cases where there are differences from IGMP. Other multicast packets, such as IPv6, might be suppressed by IGMP snooping if additional care is not taken in the implementa- tion. It is desired not to restrict the flow of non-IPv4 multi- casts other than to the degree which would happen as a result of regular bridging functions.

The requirement is stated and is supplemented by a discus- sion. All implementation discussions are examples only and there may well be other ways to achieve the same functionality. Alterna- tively stated: a snooping switch should not forward IGMP Mem- bership Reports to ports on which only hosts are attached. An administrative control may be provided to override this restriction, allowing the report messages to be flooded to other ports. This is the main IGMP snooping functionality.

Sending member- ship reports as described in IGMP versions 1 and 2 to other hosts can result in unintentionally preventing a host from joining a specific multicast group.

This is not a problem in Christensen, et al. The administrative control allows IGMP Membership Report mes- sages to be processed by network monitoring equipment such as packet analyzers or port replicators.

The switch supporting IGMP snooping must maintain a list of multicast routers and the ports on which they are attached. It may also snoop Multicast Router Advertisement messages sent by and to other nodes. The IGMP proxy-reporting switch would then report its own state in response to upstream queriers. If the switch does not already have an IP address assigned to it, the source address for these reports should be set to all-zeros.

An IGMP proxy-reporting switch may act as Querier for the down- stream hosts while proxy reporting to the 'real' upstream queriers. It should be noted that there may be multiple IGMP proxy- reporting switches in the network all using the 0.

In this case the switches can be uniquely identi- fied through their link layer source MAC address. In addition, earlier versions of IGMP should interpret IGMP fields as defined for their versions and must not alter these fields when forwarding the message. When generating new mes- sages, a given IGMP version should set fields to the appropri- ate values for its own version. If any fields are reserved or otherwise undefined for a given IGMP version, the fields should be ignored when parsing the message and must be set to zeroes when new messages are generated by implementations of that IGMP version.

Following a topology change the switch should initi- ate the transmission of a General Query on all ports in order to reduce network convergence time. If the switch is not the Querier, it should use the 'all-zeros' IP Source Address in these proxy queries. When such proxy queries are received, they must not be included in the Querier election process.

The switch should not flood such packets but if it does, it should take some note of the event i. The snooping switch should imple- ment a membership timeout feature to ensure unneeded forwarding table entries will be appropriately removed if downstream mem- bers silently leave the group or become unavailable for any reason.

If the switch implements this timeout behavior, it must have a feature to override it if the switch is also configured to forward unregistered multicast packets on all ports.

These variables may be learned dynami- cally but IGMP snooping switches implementing timeout should have a configuration option that allows these variables to be set manually. Christensen, et al. X range which are not IGMP must be forwarded on all ports. This requirement is based on fact that many hosts exist today which do not Join IP multicast addresses in this range before sending or listening to IP multicasts.

Furthermore since the Eventually, the packet is made accessible to all nodes connected to the network. This approach works well for broadcast packets that are intended to be seen or processed by all connected nodes. In the case of multi- cast packets, however, this approach could lead to less efficient use of network bandwidth, particularly when the packet is intended for only a small number of nodes. Packets will be flooded into network segments where no node has any interest in receiving the packet.

While nodes will rarely incur any processing overhead to filter packets addressed to unrequested group addresses, they are unable to transmit new packets onto the shared media for the period of time that the multicast packet is flooded. In general, signifi- cant bandwidth can be wasted by flooding. In recent years, a number of commercial vendors have introduced products described as "IGMP snooping switches" to the market. These devices do not adhere to the conceptual model that provides the strict separation of functionality between different communica- tions layers in the ISO model, and instead utilize information in the upper- level protocol headers as factors to be considered in the processing at the lower levels.

This is analogous to the man- ner in which a router can act as a firewall by looking into the transport protocol's header before allowing a packet to be for- warded to its destination address. In the case of multicast traffic, an IGMP snooping switch provides the benefit of conserving bandwidth on those segments of the net- work where no node has expressed interest in receiving packets addressed to the group address. Many switch datasheets state support for IGMP snooping, but no requirements for this exist today.

It is the authors' hope that the information presented in this draft will supply this foundation. Instead we point out the few cases where there is a difference compared to IGMP. The requirement is stated and is supplemented by a discus- sion. All implementation discussions are examples only and there may well be other ways to achieve the same functionality.

An administrative control MAY be provided to override this restriction, allowing the report messages to be flooded to other ports. This is the main IGMP snooping functionality. The administrative control allows IGMP Membership Report mes- sages to be processed by network monitoring equipment such as packet analyzers or port replicators. The IGMP proxy-reporting switch would then report its own state in response to upstream queriers.

An IGMP proxy-reporting switch may act as Querier for the down- stream hosts while proxy reporting to the 'real' upstream queriers. It should be noted that there may be multiple IGMP proxy- reporting switches in the network all using the 0.

In this case the switches can be uniquely identi- fied through their link layer source MAC address. When generating new mes- sages, a given IGMP version should set fields to the appropri- ate values for its own version. The reason for this is that changes in the local topology may cause the snooping switch to fall off the path between the router and recipient system. As a result, the switch cannot be assured of seeing an annoucement message asso- ciated with the recipient leaving the group.

This requirement is based on fact that many hosts exist today which do not Join IP multicast addresses in this range before sending or listening to IP multicasts. Furthermore since the Additionally, some vendors' applications, which are not IGMP, use this X address range, and these applications would break if the switch were to prune them due to not seeing a Join.

This is the core IGMP snooping requirement for the data path. Discussion: An implementation could maintain separate member- ship and multicast router tables in software and then "merge" these tables into a current forwarding cache. A switch MAY forward an unregistered packet only on router ports, but the switch MUST have a configuration option that suppresses this restrictive operation and forces flooding of unregistered packets on all ports.

In environments with v3 hosts where the snooping switch does not support v3, failure to flood unregistered streams could prevent v3 hosts from receiving their traffic. X address range, and these applications would break if the switch were to prune them due to not seeing a Join. This is the core IGMP snooping requirement for the data path. Discussion: An implementation could maintain separate member- ship and multicast router tables in software and then "merge" these tables into a current forwarding cache.

A switch MAY forward an unregistered packet only on router ports, but the switch MUST have a configuration option that suppresses this restrictive operation and forces flooding of unregistered packets on all ports. In environments with v3 hosts where the snooping switch does not support v3, failure to flood unregistered streams could prevent v3 hosts from receiving their traffic. Alterna- tively, in environments where the snooping switch supports all of the IGMP versions that are present, flooding unregistered streams may cause IGMP hosts to be overwhelmed by multicast traffic, even to the point of not receiving Queries and failing to issue new membership reports for their own groups.

On shared segments, if one host has registered to receive a multicast data stream but has used the "include source" or "exclude source" option, any additional hosts that later request membership for that same multicast group must accept the restrictions issued in the first host's request.

Groups for these unrecognized reports will then either be flooded with all of the problems that may create for hosts in a network with a heavy multicast load or pruned by the snooping switch. Therefore it is recommended that in such a network, the multicast router be configured to use IGMPv2. In the case of IPv6 most of the above discussions are still valid with a few exceptions which we will describe here.

This means that the basic functionality of intercepting MLD packets, building member- ship lists and multicast router lists is the same as for IGMP. In IPv6, the data forwarding rules are more straight forward because MLD is mandated for addresses with scope 2 link-scope or greater.

The only exception is the address FF which is the all hosts link-scope address for which MLD messages are never sent. Packets with the all hosts link-scope address should be forwarded on all ports. The IPv6 packet header does not include a checksum field. Discussion: If an implementation was software based, wrongly iden- tifying non-MLD packets as candidates for MLD snooping, would potentially fill the CPU queue with irellevant packets thus pre- venting the snooping functionality.

Furthermore, ICMPv6 packets destined for other hosts would not reach their destinations. A solution is either to require that the snooping switch looks fur- ther into the packets, or to be able to detect a multicast DMAC address in conjunction with ICMPv6. The first solution is desir- able only if it is configurable which message types should trigger a CPU redirect and which should not. The reason is that a hardcod- ing of message types is unflexible for the introduction of new mes- sage types.

It is suggested that solution one is the preferred if the switch is capable of triggering CPU redirects on individual ICMPv6 message types. If this is not the case, then use solution two. The structure of an IPv6 multicast address is shown in the figure below. Initial allocation of IPv6 multicast addresses, however, uses only the lower 32 bits of group ID. This eliminates the address ambigu- ity for the time being, but it should be noted that the allocation policy may change in the future.

Because of the potential overlap it is recommended that IPv6 address based forwarding is preferred to MAC address based forwarding. The exclude source failure which could cause traffic from sources that are 'black listed' to reach hosts that have requested other- wise.

This can also occur in certain network topologies without IGMP snooping. It is possible to generate packets which make the switch wrongly believe that there is a multicast router on the segment on which the source is attached.

This will potentially lead to excessive flooding on that segment. The authentication methods discussed in [ IGMPv3 ] will also provide protection in this case.

IGMP snooping switches which rely on the IP header of a packet for their operation and which do not validate the header checksum potentially will forward packets on the wrong ports. Even though the IP headers are protected by the ethernet checksum this is a potential vulnerability. Generally though, it is worth it to stress that IP multicast must so far be considered insecure until the work of for example the suggested Multicast Security MSEC working group or similar is completed or at least has matured.