Date: Wed, 4 Sep 2002 14:39:08 +0300
From: Markku Savela <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I don't see where the two different protocols come from. As explained,
| membership of solicited node multicast group is implicitly indicated
| by EACH packet the node sends.
This only works if the node actually sends a packet (from that address).
For unicast, there's no problem, as if a unicast (MAC) address is unknown,
the packet can just be flooded by the switch. Usually that packet will
elicit a response, and that response will allow the relevant port to be
found, so the flooding is rare.
But that doesn't happen with multicast, there are no responses, so
"just flood" by itself would never cease (and in any case, it needs to
be able to get to multiple places).
I suppose that switches could build a bunch of extra magic, to try and
fathom where to send solicited node multicast packets (which would mean
that it would need to recognise them, which means peering into the L3
headers of every multicast packet, as the ethernet multicast addr certainly
won't tell it for certain), but it really is much simpler for the switch
to just do the same things for these multicasts as just about all others
("all nodes" is different, because by definition, that's supposed to go
everywhere - note that "all routers" isn't excluded from MLD I don't think).
The cost is the need to send a packet. That's done normally when adding
a multicast addr to an interface, so the code is there anyway (or should
be) - to not send one when the multicast addr happens to be a solicited
node addr would seem to take extra code (though of course, this kind of
thing tends to depend upon the implementation).
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
