Carsten's question at the end is important. Do we need to do DAD?
My answer has been and still is NO.
geoff
On Tue, 2009-11-10 at 10:50 +0900, Carsten Bormann wrote:
> On Nov 10, 2009, at 10:29, Kris Pister wrote:
>
> >
> > Carsten Bormann wrote:
> >>
> >> Please do show me the mesh that has an efficient mostly-reliable
> >> subnet-wide multicast.
> >>
> > Carsten - how do you define efficient and mostly-reliable? With
> > 15.4E you get something north of 98% reliable subnet-wide multicast
> > with a single transmission from each routing node. Is that good
> > enough, or is the very act of flooding the subnet objectionable?
>
> I don't know whether it is objectionable, but it may not be very
> efficient to send all DAD messages to every node.
> (It certainly limits scalability.)
>
> >>> that DAD is necessary,
> >>
> >> Ah, good, let's discuss that! If we don't need DAD, we don't need
> >> half of ND.
> >> Leaving things out is always the best way to design things.
> >> However, we wanted to be functionally compatible with ND.
> >>
> >> [...]
> > I didn't understand the reasons presented why we need DAD. The last
> > I remember was "there might be counterfeit nodes that have the same
> > MAC EUID". That particular argument doesn't make any sense to me,
> > but I may have missed others that make more sense.
>
> That depends.
>
> When we still said that the IPv6 address was hardwired to the EUI-64,
> the only concern was duplicate EUI-64s.
> How do these happen?
> 1) manufacturing errors. This has happened often enough in Ethernet
> space that DAD was made mandatory in 4861.
> 2) counterfeiting. Counterfeiters have a strong interest to make
> their products look a lot like the real thing, and for that very
> reason can't coordinate EUI-64 space usage with the real vendor, so it
> is quite likely that they will hit the same EUI-64s. Is that a
> problem? In the network element space, counterfeiting of expensive
> equipment (e.g., made by Cisco) is a very real one.
>
> Since -07, we now explicitly allow non-EUI-64-based addresses, so
> these definitely need DAD (currently both groups are treated
> identically).
>
> Again, entirely getting rid of a function is always the best
> optimization.
> Can we do that for DAD?
>
> Gruesse, Carsten
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
