On 15/07/2017 01:09, Michael Richardson wrote:
>
> Eliot Lear <[email protected]> wrote:
> > On 7/6/17 9:09 AM, Toerless Eckert wrote:
> >> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote:
> >>> It used to be, but the recommendation today is a pseudo-random
> >>> value (RFC7217). In any case it's a software choice.
>
> >> brand new recommendations do not equate to be expected
> >> standard practice in products. Would be very good to have
> >> folks with practical insight into various products to
> >> provide more information.
>
> > On this point, I think it's quite likely that we will see a good number
> > of devices fielded that will do a lousy job of PRNG, and so it would be
> > inadvisable for them to implement RFC7217, lest they test their DAD code
> > in ways not really intended. I'm not thinking about iPhones here, but
> > energy harvesting devices like some light switches, and a bunch of,
> > well,... crap.
>
> > The question is whether you should design for these devices. IMHO "no"
> > is a perfectly valid answer, but I'm still a bit skeptical about the
> > value of 7217 for these class of devices in any event.
>
> 1) Constrained devices are out of scope for ANIMA.
True, but let's not use that as an excuse, because our stuff
might just get used more widely.
> 2) even if they were in scope, kinetic powered light switches are not
> good candidates for join proxies. Light bulbs, however.
But On 14/07/2017 18:13, Eliot Lear wrote:
...
> I made my comment in the context of a possible interface collision in
> your diagram. Those had to do with the autonomic nodes, not the
> proxies, as I understand things. To avoid those sorts of collisions, it
> seems like using the h/w address remains sensible. A collision in those
> circumstances would be extremely unlikely, whereas relying on poor PRNG
> almost assures it of happening. These devices are likely to have very
> little entropy available to them.
And they may well be BRSKI pledges, just not using GRASP for discovery.
So Eliot's point seems valid (but not an issue for ANIMA alone).
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
