Hi Michael,
On 25/05/2016 12:03, Michael Richardson wrote:
>
> 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...
You mean at the "server" end (the responder, in GRASPtalk)? It binds to ''
(in Python, which is ::). But the code needs to know the current address,
because it has to be included in discovery responses.
The bug is lazy implementation in the prototype. I would need to check
periodically if the local address had changed, and then work some magic
to kill and recreate all affected sockets, and rely on discovery cache
timeouts in other nodes. If we want to be renumbering proof, that
needs to be mentioned in the protocol spec. If not, we need a warning
that we are not renumbering proof.
> 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?
s/would/should/ ;-)
I know where to do this, because I already have some dummy code that
'watches' the ACP and in theory would switch TLS on if the ACP
went away. The same thread could watch for an address change.
> > 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.
Yep. I have a Python hack that runs on both Windows and Linux to find a valid
global address, given the lack of a good way to do it. I could use that
code to detect address changes after the fact. But it's messy.
(So is the code I have to figure out link-local details. If you care,
look in my source code for the comment including "pain-in-the-neck".)
> 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.
Agreed. I would just like GRASP to be robust when it is unfortunate enough to
run without an ACP.
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
