Date: Wed, 4 Sep 2002 17:10:11 +0300
From: Markku Savela <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Such node will then only receive linklocal multicast (or is in
| promiscuous mode) without ever sending anything. Such node doesn't
| really need address at all, it can even skip the DAD.
No, you missed the point - the node doesn't send until after it
has received. It can't receive until someone does ND for one of
its addresses. To receive the ND packet, it must receive a
multicast to the solicited node multicast address (if I have the
correct expression there). That is, multicast has to work before
packets are transmitted.
| If it snoops MLD, it has to peek into L3 and deeper (locate ICMP
| header after potential sequence of extension headers) for every
| multicast packet anyways.
Yes, but that it is already doing. That's part of the design, and
can't be avoided (while not flooding multicast packets).
But:
| Looking at IPv6 source address is trivial
| compared to this (it's always in the same fixed position).
Yes, it is easier, but it is additional. And it requires that the
packet actually be sent to be snooped. I guess you could always just require
that a node send some random packet (from every address - or at least every
one that results in a different multicast address) when it assigns the
address (joins the multicast group), but if you're going to require that,
why not just make it be a MLD packet?
| Exactly, when implementing IPv6, there was no logical reason to do MLD
| for link local groups.
But there is, you just didn't see it. That's what is being explained.
The spec is clear though, I think.
| Additional consideration: if solicited-node groups are true part of
| MLD, then one should note that MLD query with ANY group will elicit
| responce from almost every node on the link (as I assume high
| probability that the solicited node groups usually have only one or
| few hosts each). How many nodes are on the link? Will some reports be
| lost?
Who cares? Remember these particular packets are only being used, as
I understand it, for the benefit of the switches. They achieve nothing
useful at the multicast routing level. As long as your switch sees the
join (and it is the thing at the other end of the wire from you), then
it can do the right thing. I'm not sure why anyone would be sending a
query for one of those, just the join (but the multicast protocols themselves
are perhaps beyond my understanding, so I might be missing some other
potential use).
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]
--------------------------------------------------------------------
