Subject: [Anima] Anima and renumbering

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2016 08:44:35 +1200

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.

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?

Regards
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 24 May 2016 11:45:50 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 23 May 2016 22:45
> To: Anima WG <[email-masked]>
> Subject: [Anima] Anima and renumbering
> 
> 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.
> 
> 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?

Hmmm... I'm not an IPv6 expert, so please bear with me. 

https://tools.ietf.org/html/rfc4862#section-5.3 states explicitly that "A link-local address has an infinite preferred and valid lifetime; it is never timed out."

https://tools.ietf.org/html/rfc4941#section-3.3 implies that the procedure applies only to global scope addresses: 
   "This document extends [ADDRCONF] as
   follows.  When processing a Router Advertisement with a Prefix
   Information option carrying a global scope prefix for the purposes of
   address autoconfiguration (i.e., the A bit is set), the node MUST
   perform the following steps:"

Therefore, link local addresses, in my reading, do not use temporary addresses a la RFC 4941. Correct so far? 

I would further claim that addressing inside the ACP does not require temporary addresses, since the ACP is a secured overlay network. 

Therefore, if GRASP runs on link local addressing in the data plane, and if we use static, greater-than-link-local scope only inside the ACP (which is my assumption), we should be fine, right?

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 May 2016 08:27:30 +1200

Hi Michael,

> https://tools.ietf.org/html/rfc4862#section-5.3 states explicitly that "A link-local address has an infinite preferred and valid lifetime; it is never timed out."

Correct, although there is one corner case. If you build your link local
address using the MAC address, and you are running with randomized MAC
addresses, I suppose the link local address could become invalid.

> Therefore, link local addresses, in my reading, do not use temporary addresses a la RFC 4941. Correct so far? 

Correct.

> I would further claim that addressing inside the ACP does not require temporary addresses, since the ACP is a secured overlay network.

I believe that's correct, but probably it should be stated explicitly in
the addressing specification, since stable vs temporary addresses is a very
hot topic in 6man at the moment.

> Therefore, if GRASP runs on link local addressing in the data plane, and if we use static, greater-than-link-local scope only inside the ACP (which is my assumption), we should be fine, right?

Yes. But in the case that people deploy AN components without an ACP, which we have
always said would be possible but not recommended, I think the issue could arise.
Acually the possibility of data plane renumbering is a very strong argument for
the ACP approach with ULA addressing, since it allows stable addresses for the ANI
whatever happens in the data plane.

So maybe this is something for the next rev of the reference model.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 May 2016 20:03:17 -0400

Brian E Carpenter <[email-masked]> wrote:
    > 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?

    > 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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 May 2016 13:22:43 +1200

Hi Michael,
> 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.

> 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.

> 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".)

> 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