Hi,
unreliable flooding of control/routing packets is a long standing
problem in the MANET working group [1]. Recently the MANET working group
formed a design team that will tackle this problem among others that arise
when extending OSPF for wireless media. AFAIK, their design will be
IP-v4/IP-v6 agnostic.
There have been several reliable multicast mechanisms discussed on MANET,
but none have been written up as an Internet Draft yet. If the IP-v6 ND
requirements were well defined, one could pick one of them as the reliable
IP-v6 link-local multicast mechanism.
hth,
George
[1] refer to the April 8th 2004 MANET working group thread with the
Subject line entitled: " Comments on "Problem Statement for OSPF
Extensions ..." for more background.
On Tue, 8 Jun 2004, Pekka Savola wrote:
> Tailed down mailing lists to just IPv6 WG list..
>
> On Tue, 8 Jun 2004, Masataka Ohta wrote:
> > Mohacsi Janos wrote:
> > ND is wrong, because it was designed to be applicable to all the
> > link types.
> >
> > ND deployed multicast only because some ATM guy said NBMA was
> > capable of not broadcast but multicast, which is totaly denied
> > by the current ND RFC stating that ND may not be applicable to
> > NBMA.
>
> I agree that using multicast for ND was probably not one of the wisest
> choices in the long run, and we're suffering from it today (e.g., as
> many WLAN APs working as bridges don't forward IPv6 neighbor discovery
> frames because they are multicast). There is only marginal value in
> ND using multicast (compared to broadcast), as the typical number of
> nodes per link is so low that broadcast storms are not a real problem.
>
> However, that doesn't change your original argument about CSMA/CA,
> because broadcast suffers from the same issues as well.
>
> > The solution has been never bother to have standard way of
> > address resolution.
>
> I have to disagree here. Just because broadcast/multicast (ND) isn't
> optimized for WLAN (or CSMA/CA in general, I guess), that doesn't
> nullify the usefulness of ND for all the other media for which this is
> not a problem.
>
> The right fix appears to be specifying an IPv6 over WLAN document (or
> the like) which specifies a possible way to optimize the situation for
> WLAN media.
>
> But while IPv6 over WLAN may not be fully optimal, as it requires
> link-layer acknowledgements of multicast packets, I think many already
> deem it to work to a *sufficient* degree .. and I'm not sure whether
> there would be consensus for specifying e.g. the changes you
> suggested. Data (simulations, measurements, etc.) about the
> performance, latency, etc. increases might help.
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
