Subject: [magma] IGMP/MLD snooping -02 comments

From: Pekka Savola <[email-masked]>
Date: Sat, 19 Oct 2002 15:32:22 +0300 (EEST)

Hello,

A few comments on the IGMP/MLD snooping draft, from a first time reader.  
As a background, if not already familiar, I'd suggest looking at:

http://www.ietf.org/internet-drafts/draft-savola-v6ops-multicast-issues-00.txt

In particular, section 3 and maybe 4.  Some implementations are currently
in a *very* broken state (and I don't mean flooding multicasts (relatively
minor annoyance) but dropping them even): this must be fixed ASAP.

The biggest issues:

1) This draft should really be split, or have separate 
objectives, well, separate:

  1) How to implement IGMPv1/IGMPv2 snooping properly?
     (ie. "How Current Implementations Should Have Been Done")
  2) How to add IGMPv3 to the stew?
  3) How to implement MLD snooping properly?
     (there may not be need for MLDv1/MLDv2 separation, but that's an 
option)

In particular, how to implement 1)/2) _in such a way_ that it works
without any problems with IPv6 multicast (ie. no snooping for them, but no
blocking either), without the switch having to know anything about IPv6 
should be pretty much spelled out.

The first priority should be documenting how to fix the breakage currently
in IGMP snooping.  Adding support for MLD/IGMPv3 is a secondary objective,
IMO.

2) There must be some considerations how IPv6 multicast is supposed to 
work with non-MLD (but IGMP-) aware switches.  The information is probably 
already there, but should be summarized at least.

Substantial comments:

     The problem of wasting bandwidth is even worse when the LAN segment
     is not shared, for example in Full Duplex links.  Full Duplex is   
     standard today for most switches operating at 1Gbps or above.  In  
     this case the bandwidth that is wasted is proportional to the num¡ 
     ber of attached nodes.

==> Bandwidth is equally wasted on shared segment.  I don't think nobody 
cares about the details:  In both cases, there is X amount of less 
bandwidth available for a node.

     2)  IGMP snooping switches MAY implement "proxy-reporting" in which
	    reports received from downstream hosts are summarized and used
	 to build internal membership states as described in [PROXY].   
	    An IGMP proxy-reporting switch would then report its own state
         in response to upstream queriers.  If the switch does not
	 alreay have an IP address it SHOULD use the address 0.0.0.0 as
         source in these reports.

==> The last sentence.  I believe this might have to be re-thought (or
-worded)  considering many switches do have an IP address, but not in the 
VLAN where reports are used.  Should the IP address still be used, though 
topologically incorrect?  Is there an implication of the increased use of 
0.0.0.0 if not?

	 IGMP membership reports MUST NOT be rejected because of a
         source IP address of 0.0.0.0; however, these messages MUST NOT
	 be included the election process so that a snooping switch does
	 not elected over an active router.

==> Is this a new requirement for designated routers?   An extremely 
important issue, IMO, is analysing the required changes (if any) to third 
party devices (in this case routers, hosts, switches not implementing 
snooping).

     3)  The switch that supports IGMP snooping MUST flood all unrecog¡ 
 	 nized IGMP messages to all other ports and MUST NOT attempt to
         make use of any information beyond the end of the network layer
	 header.  In particular, messages where any reserved fields in
	 the IGMP header are non-zero MUST NOT be subject to "normal"
         snooping since this could indicate an incompatible change to  
         the IGMP message format.

==> This appears to be a no-op except for IGMPv1 because there seem to be 
no reserved fields in 

 	4)  IGMP snooping switches MAY maintain forwarding tables based on 
         either MAC addresses or IP addresses.  If a switch supports  
	 both types of forwarding tables then the default behavior
	 SHOULD be to use IP addresses.

 	    Discussion: Forwarding based on MAC addresses is subject to the
         problem associated with the 32-fold IP address to 1 MAC address
	 mapping.

==> I believe this recommandation may have to revisited.  Using IP 
addresses may be highly counter-productive for IPv6 multicast unless IPv6 
snooping is implemented.

     A special problem arise in the network consisting of IGMPv3 routers
	as well as IGMPv2 and IGMPv3 hosts interconnected by a IGMPv2  
     snooping switch.  IGMPv3 has a mechanism to fall back to IGMPv2
     when receiving IGMPv2 membership reports. This means that the net¡ 
	work will converged on IGMPv2 eventually. However, the convergence
     time will lead to supression of v3 Hosts for several minutes.

 	Therefore it is recommended that in such a network, the multicast
     router is configured to use IGMPv2.

==> This would appear to be in conflict with 2.1.1 item 3), that is, if 
any reserved fields are non-zero, the packet MUST BE flooded everywhere; 
spell out that IGMPv2 has no reserved fields so that doesn't help here.  
Should there be some additional checks?

     The three main differences between IGMPv3 and MLDv2 are:

     -  MLDv2 uses ICMPv6 message types instead of IGMP message types.

	-  The ethernet encapsulation is a mapping of 32 bits of the 128
	bit DIP addresses into 48 bit DMAC addresses [IPENCAPS].

	-  Multicast router discovery is done using Neighbor Discovery Pro¡
	tocol (NDP) for IPv6. NDP uses ICMPv6 message types.

==> The last bullet appears to require more clarification.  There is no
multicast router discovery with NDP.  I assume the draft means listening
to Router Advertisement messages and marking ports where such are received
as routers.  This has two problems: 1) not all of routers are necessarily
multicast routers, and 2) this does not work if the subnet is fully 
manually configured.  There may not be need to care about these cases, but 
at least the assumptions should be mentioned..

     The fact that MLDv2 is using ICMPv6 adds new requirements to a
     snooping switch because ICMPv6 has multiple uses aside from MLD.
     This means that it is no longer sufficient to detect that the next-
     header field of the IP header is ICMPv6 in order to redirect pack¡ 
     ets to the CPU. [...]

==> Aren't we getting a bit implementation specific here?  Why is an ICMP 
automatically redirected to CPU, it doesn't have to be..

 	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?

==> perhaps similar questions regarding MAC addresses IPv6 Neighbor 
Discovery uses should have been made?

         Removed (commented out) description of IPR issues: IESG is
	  aware of them.

==> I object: there should be some section, even if not necessarily 
complete.  At the very least, the regular "IPR boilerplate" could be 
added.

Editorial:

2H2.H.1H1.H.2H2.H.  DHDaHatHtaHa FHFoHorHrwHwaHarHrdHdiHinHngHg RHRuHulHleHesHs

==> The headers are written as bold which should not be done.

	 if it does, it SHOULD take some note of the event (i.e.: incre¡
         ment a counter).  These errors and their processing are further

==> wrong character for '-' is used; also, words should not be split (if I 
recall correctly) in I-D's.
	
         b)  The arrival port for IGMP Queries (sent by multicast
             routers) where the source where the address is not 0.0.0.0.

==> s/where the address/address/

	 alreay have an IP address it SHOULD use the address 0.0.0.0 as
         source in these reports.

==> s/alreay/already/

	 This requirement is based on fact that many hosts exist today,
 	 which does not Join IP multicast addresses in this range before
 
==> s/does/do/

     A special problem arise in the network consisting of IGMPv3 routers

==> s/arise/arises/

     addresses in the forseable future.

==> s/forseable/foreseeable/
-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma