Hi Markku,

I'm not sure if this is just fuel for the fire,
or another idea you haven't seen.


Markku Savela wrote:
>>From: Francis Dupont <[EMAIL PROTECTED]>
> 
> 
>>   - there is no reason for using MLD for link local multicast groups
>>     as far IPv6 (layer-3) is concerned.
>>   
>>=> there is a very well known reason: snooping by layer-2 switches.
> 
> 
> ...and which totally bogus, as such switch cannot utilize the
> information in any significant way. Remember, I'm talking about LINK
> LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY. And, as
> linklocal all-nodes is ALREADY excempted from the MLD, what is left is
> *ONLY* the solicited node multicast. I vote that, it too is exempted.
> 
> When is this joined? ONLY when node configures a NEW id for address,
> so what we are seeing on link, is two back-to-back messages:
> 
>   1) join solicited node group (MLD), followed by
>   2) ND DAD probe
> 
> I just can't see any significant use for the (1), even for layer-2
> snooper. The probe alone carries exactly the same information as the
> useless MLD join. And whats worse, the switch will increase the
> probability of DAD "failing to do its suff"... (if it decides not to
> forward the DAD to all links based on some stale soft state -- it
> definetly cannot start querying at this point).

The draft I've written attempts to make some use of the
(possibly illogical) requirement that IPv6 nodes do MLD
on Solicited Nodes Multicast in order to do DAD.

here's the URL:
http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt

It allows an MLD router (the querier) to watch listener
state on the network and respond to a report if that
solicited nodes multicast address is not in use.
(indicating that DAD is successful and the address is unique).

It's not pretty, but it may be a the nearest thing to a
significant use for this requirement.

> Additionally, when ND is protected by IPSEC, the switch needs to do
> the IPSEC also.
> 
> 
>>   - at least it should be optional for link local multicast groups used
>>     in Neighbor discovery
>>   
>>=> I can't see how it can be optional: either it is useful so is
>>recommended/required, or it is not useful so is not
>>recommended/required.
> 
> 
> Right, I'm requesting it to be at least optional. I don't think it
> (MLD for link local ND groups) is useful for anything.

As far as I can see, Optional doesn't really help, if there
are some nodes doing MLD for DAD and others aren't there will
never be applications which can rely on it (so the situation
is self perpetuating...;)

> 
>>   - illogical definition: you cannot join solicited nodes multicast
>>     group before you have address,
>>
>>=> I don't understand: I can send a join message.
> 
> 
> Yes, with "::" source address. Kinky.. :)
> 

I don't really see why you can't send from a tentative address
in this case. There are no responses being sent to unicast L3
addresses (and none off link).  using "::" means that anyone
else listening to your MLD report (existing nodes/routers)
will ignore it.

[cut section about l2snooping]
> 
> Where did I say "multicast sucks". I definitely like multicast, I'm
> just talking about these link local groups here, and specifically
> about ND discovery part of it.

If you can get MLD for link-scope multicast addresses removed,
please do it entirely.

It doesn't help anyone to have half a standard.

Greg Daley


--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to