Brian E Carpenter <[email protected]> wrote: > I made an unplanned experiment yesterday. Because of a discussion in > 6man, I set up my laptop to run with only temporary IPv6 addresses (RFC > 4941 addresses). And then I ran my tests of the GRASP prototype for a > while. After half an hour or so, GRASP stopped working, because the > laptop's address changed automatically, so the cached discovery results > became invalid.
I think that this is possibly a fault in OS or GRASP code :-)
Does your implemention bind(2) a socket to the address in question, or just
to ::? If it bind(2)s, then the OS can't remove the IP, even if it moves on
to use another address. I've seen bugs where it does anyway...
If it binds :: only, then it didn't latch onto an IP, and it should have
been listening for address changes if it's going to tells others how to reach
it. This isn't easy with the official APIs that we have, alas. If it had
heard the address change, then it would have sent out a new address, right?
> So, one conclusion is that my implementation should be more aggressive
> about aging out the discovery cache. But it raises a question about how
> resistant we need the Anima infrastructure to be against
> renumbering. It seems to me that an autonomic mechanism really needs to
> repair itself in that case. Any thoughts?
Again, our APIs don't tell us what the TTL on the temporary address is
either, so we can't even know when to stop announcing it.
My belief is that our ACP will be designed to essentially avoid renumbering;
doing so only when two ACPs merge due to an acquisition or something, and
then it will be very much make-before-break over a period of days to months.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
