Re: mboned: RE: [magma] suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDEmode

On Jun 8, 2006, at 6:39 PM, Hitoshi Asaeda wrote:

>> But, as I said, I'm not necessarily seeing implementations follow
>> those rules.
>
> IGMPv3/MLDv2 host-side implementations included in KAME support all
> conditions (INCLUDE/EXCLUDE and all state tranditions) mentioned in
> these specs.
> I'm sure it is easy to support only INCLUDE mode, though.
> --
> Hitoshi Asaeda

FWIW:

WRT to trying to simplify IGMPv3...

IMHO, considering that the same information is in all of the types,
it would seem to me that supporting MODE-IS-INCLUDE and MODE-IS- 
EXCLUDE -only-
should be "good enough".  Looking at the latest kernel  
implementations I can find
there is a lot of stuff that doesn't work quite right.  From a router  
perspective
one either adds or deletes the (S,G) from the IGMP caches and that  
means you do
the same thing when MODE-IS-INCLUDE ALLOW-NEW-SOURCES CHANGE-TO- 
INCLUDE, and
visa versa for EXCLUDE.  (despite what A.1 says, host implementations  
aren't
reliable enough to take advantage of the supposed savings -- 2cents)

So... my experience...
(and for those who would tell me I'm using the wrong OS version, it  
hasn't
exactly been easy finding out which ones work.)

When and application joins a new (S,G) one expects to see two  
(robustness variable)
(if the querier is configured for default) IGMP packets with
at least one record.  If one carefully reads the spec para 4.2.12
it would appear that this record should be a CHANGE-TO-INCLUDE-MODE.
After that, the host should respond to IGMP general queries with MODE- 
IS-INCLUDE
records.  I would argue that one only uses ALLOW-NEW-SOURCES when  
you've already
sent a report to join a specific group.  (NOT that I really care that  
much, but
its the only way I can justify to myself the CHANGE-TO- modes).

Linux 2.6.9-11 sends the initial IGMPv3 report for a new (S,G) it sends
two (2) packets which each include two records that more or less do the
same thing.  The first record is ALLOW-NEW-SOURCES (5) followed by a
CHANGE-TO-INCLUDE-MODE (3)

Linux 2.6.9-11 though fails to respond to a IGMPv3 general query so
the IGMP cache will timeout on the router.  I've been told that I need
to upgrade to 2.6.12.  Still 9-11 is only about a year old, so my  
point would
be despite the best efforts of many, IGMPv3 isn't getting deployed very
quickly.

When FreeBSD 5.4 sends the initial IGMP report for a new (S,G) it sends
only one (1) packet with a single record which is ALLOW-NEW-SOURCES.

FreeBSD 5.4 responds to IGMPv3 general query with one (1) packets with
one record MODE-IS-INCLUDE

And finally it appears that windows XP doesn't support BLOCK-OLD-SOURCES

LINUX 2.6, startup report:
11:33:15.506961 IP (tos 0xc0, ttl   1, id 0, offset 0, flags [DF],  
proto 2, length: 56, optlength: 4 ( RA )) 50.2.2.11 > IGMP.MCAST.NET:  
igmp v3 report, 2 group record(s) [gaddr 232.100.100.100 allow  
{ wbar1.sjo1-4-4-004-004.sjo1.dsl-verizon.net }] [gaddr  
232.100.100.100 to_in { wbar1.sjo1-4-4-004-004.sjo1.dsl-verizon.net }]
	0x0000:  46c0 0038 0000 4000 0102 cfdc 3202 020b  [email protected]...
	0x0010:  e000 0016 9404 0000 2200 2c59 0000 0002  ........".,Y....
	0x0020:  0500 0001 e864 6464 0404 0404 0300 0001  .....ddd........
	0x0030:  e864 6464 0404 0404                      .ddd....

FreeBSD 5.4-RELEASE startup report:
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size  
200 bytes
12:50:23.623864 IP (tos 0xc0, ttl   1, id 53904, offset 0, flags  
[none], length: 44, optlength: 4 ( RA )) 10.1.1.2 > IGMP.MCAST.NET:  
igmp v3 report, 1 group record(s) [gaddr 232.12.12.12 allow  
{ wbar1.sjo1-4-4-004-004.sjo1.dsl-verizon.net }]
	0x0000:  46c0 002c d290 0000 0102 6662 0a01 0102  F..,......fb....
	0x0010:  e000 0016 9404 0000 2200 dcdc 0000 0001  ........".......
	0x0020:  0500 0001 e80c 0c0c 0404 0404            ............
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/