Subject: Re: [Anima] Addressing-interface addressing

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 4 May 2015 07:12:36 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 24 April 2015 21:49
> To: [email-masked]
> Subject: Re: [Anima] Addressing-interface addressing
> 
> On 25/04/2015 04:38, Michael Richardson wrote:
> >
> > Liubing (Leo) <[email-masked]> wrote:
> >     > This is another topic regarding to autonomic addressing.
> >
> >     > For autonomic network infrastructure, is it sufficient to self-assign
> >     > the devices' interfaces link-local addresses? Do we need to assign the
> >     > interfaces ULA/GUA addresses in some scenarios?
> >
> > I think that the answer depends upon which interface you are talking
> about.
> >
> > The only way that I can see that we can use and also route link-local
> > addresses would be if we are in fact creating some kind of NBMA
> > interface for an ACP "LAN".
> >
> > I don't think that's a good idea.  I think it is better to use a ULA
> 
> I agree. Otherwise, how do nodes on different links communication
> independently of the user-visible addressing scheme?
> 
> > (and I
> > have said I favour a ULA-C approach) on a loopback interface.
> 
> IMHO we don't need -C. That would imply yet another external dependency
> (on a non-existent registry that has no funding model anyway). Vanilla ULA
> works fine.

Slightly confused. I think on the loopback interfaces we agree we need something routable, and that ULA (ignore the flavour for a second) is the right thing here. And on the interfaces to other nodes we use link local. Are we saying the same thing? 

Michael
 
> Regards
>    Brian
> 
> > I am happy to
> > use SLAAC or Stable-Private (7217) for that address.
> >
> >
> > --
> > Michael Richardson <[email-masked]>, Sandelman Software
> Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> >
> >
> > _______________________________________________
> > Anima mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/anima
> >
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 May 2015 19:44:27 +1200

Hi Michael,

> Slightly confused. I think on the loopback interfaces we agree we need something routable, and that ULA (ignore the flavour for a second) is the right thing here. And on the interfaces to other nod…

In the context of the ACP, I think we're saying the same thing. ACP addresses
are routeable within the ACP (which is to say, they are routeable among ASAs,
via their ACP virtual* interfaces). However, if for some reason we have no ACP,
the ASAs will need some other kind of routeable address, of course.

*"loopback interface" is not in my vocabulary.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 4 May 2015 14:18:19 +0000

> In the context of the ACP, I think we're saying the same thing. ACP
> addresses are routeable within the ACP (which is to say, they are routeable
> among ASAs, via their ACP virtual* interfaces). However, if for some reason
> we have no ACP, the ASAs will need some other kind of routeable address,
> of course.

Agreed. Re-phrasing: In both cases (with and without ACP) a device needs a routable address which is used by ASAs. This can be (probably: should be) a loopback address (or whatever we call it, see below). So far I think there is no contention. 

I would further contend that in both cases (with and without ACP) the autonomic infrastructure should NOT assign/negotiate/put on routable addresses on links, but use exclusively link local there. Do we also agree on that? 

And, both of the above points are independent on that the admin does in the "normal" device config. He may well choose to assign addresses to links for his normal operation. 
 
Does this map your understanding? 

> *"loopback interface" is not in my vocabulary.

OK, I heard this (to me strange) comment before, and would like to understand and settle this with the right wording. 

There are plenty of cases where this term is used in RFCs: 

RFC3330: 
"127.0.0.0/8 - This block is assigned for use as the Internet host loopback address."
RFC3513: 
"         0:0:0:0:0:0:0:1             the loopback address"
On Unix systems (for example) you have a loopback interface as well, documented as such. 

So - why is that term wrong and what is the right one? Has this already been discussed elsewhere in the IETF, and can you point to a consensus? (or is it your opinion only at this point?)  Thanks for your help! 

Michael

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 5 May 2015 03:40:58 +0000

Hi Michael,

> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Behringer (mbehring)
> Sent: Monday, May 04, 2015 10:18 PM
> To: Brian E Carpenter; [email-masked]
> > addresses are routeable within the ACP (which is to say, they are
> > routeable among ASAs, via their ACP virtual* interfaces). However, if
> > for some reason we have no ACP, the ASAs will need some other kind of
> > routeable address, of course.
> 
> Agreed. Re-phrasing: In both cases (with and without ACP) a device needs a
> routable address which is used by ASAs. This can be (probably: should be) a
> loopback address (or whatever we call it, see below). So far I think there is
> no contention.
> 
> I would further contend that in both cases (with and without ACP) the
> autonomic infrastructure should NOT assign/negotiate/put on routable
> addresses on links, but use exclusively link local there. Do we also agree on
> that?
[Bing] I think this claim has an implications: each ASA is binding to a device (the loopback interface), rather than a link interface.
I think this implication might be ok, but I don't have a 100% confidence. Can anybody point out an exception?

> And, both of the above points are independent on that the admin does in the
> "normal" device config. He may well choose to assign addresses to links for
> his normal operation.
> 
> OK, I heard this (to me strange) comment before, and would like to
> understand and settle this with the right wording.
> 
> So - why is that term wrong and what is the right one? 
[Bing] My understanding is that Brian's concern is about the definition accuracy. Although loopback interface is commonly used as representing a node in practice, it is a specific concept of loopback inside a node by definition.
So, as Brian commented before, here we are actually talking about the concept of "virtual interface" which represents a node rather than an interface on a specific link. But I also don't know whether there is a formal naming to express the "virtual interface". 
If there is no such a name, my rough suggestion would be: we can briefly explain that "loopback interface" is something we borrow to assign IP addresses for ASA communication, and this is a common way in practice to make an IP represents a node rather than an interface on a link.

Best regards,
Bing

> Has this already been
> discussed elsewhere in the IETF, and can you point to a consensus? (or is it
> your opinion only at this point?)  Thanks for your help!
> 
> Michael
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 5 May 2015 07:36:35 +0000

> > Agreed. Re-phrasing: In both cases (with and without ACP) a device
> > needs a routable address which is used by ASAs. This can be (probably:
> > should be) a loopback address (or whatever we call it, see below). So
> > far I think there is no contention.
> >
> > addresses on links, but use exclusively link local there. Do we also
> > agree on that?
> [Bing] I think this claim has an implications: each ASA is binding to a device
> (the loopback interface), rather than a link interface.

Agreed. If someone can come up with a good reason where we need to have routable interface addresses, let's do it. If not, let's use link-local only. 
 
> > And, both of the above points are independent on that the admin does
> > in the "normal" device config. He may well choose to assign addresses
> > to links for his normal operation.
> >
> [Bing] My understanding is that Brian's concern is about the definition
> accuracy. Although loopback interface is commonly used as representing a
> node in practice, it is a specific concept of loopback inside a node by
> definition.
> So, as Brian commented before, here we are actually talking about the
> concept of "virtual interface" which represents a node rather than an
> interface on a specific link. But I also don't know whether there is a formal
> naming to express the "virtual interface".
> If there is no such a name, my rough suggestion would be: we can briefly
> explain that "loopback interface" is something we borrow to assign IP
> addresses for ASA communication, and this is a common way in practice to
> make an IP represents a node rather than an interface on a link.

I guess, neither is "officially" defined. Happy to add some definition to the text. I would still tend to call it a loopback interface though (with definition). Brian, would that solve your concern? 

Michael
 
> Best regards,
> Bing
> 
> > Has this already been
> > discussed elsewhere in the IETF, and can you point to a consensus? (or
> > is it your opinion only at this point?)  Thanks for your help!
> >
> > Michael
> >

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 14:56:07 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    mcr> (and I
    mcr> have said I favour a ULA-C approach) on a loopback interface.

    brian> IMHO we don't need -C. That would imply yet another external
    brian> dependency (on a non-existent registry that has no funding model
    brian> anyway). Vanilla ULA  works fine.

    mb> Slightly confused. I think on the loopback interfaces we agree we
    mb> need something routable, and that ULA (ignore the flavour for a
    mb> second) is the right thing here. And on the interfaces to other nodes
    mb> we use link local. Are we saying the same thing?

I think we all agree that ULA is the way to number the autonomic control
plane.   Current ULA-Random has the disadvantage that, when there are routing
leaks, where they come from.  We see this today with RFC1918 address spaces,
and the AS112 project exists to deal with the resulting reverse DNS lookup
impact of those leaks.

A ULA-C had the advantage that while they are seperate from an ISP or
enterprise's GUA allocation, they are still trackable when they leak.
I think it very important that the ACP be numbered in a different space than
production.  With ULA-C, one would get reverse DNS delegated to you, etc.
cf: https://tools.ietf.org/html/draft-ietf-ipv6-ula-central-02
which is from 2007, but could be revived, I think.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 15:02:16 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > And, both of the above points are independent on that the admin does in
    > the "normal" device config. He may well choose to assign addresses to
    > links for his normal operation.

    > understand and settle this with the right wording.

What is meant by loopback interface address is that the autonomic numbering
mechanism would configure the ACP prefix (the ULA) onto a loopback interface,
and then would announce that address into the autonomic network.

The alternative is that the address is configured onto specific interfaces,
and therefore a router with a multitude of interfaces would have a multitude
of addressess.  Worse, if one has a management session up with one of those
interfaces, and the interface goes down, then the session goes down.
Had the session been up with a loopback IP, then routing fixes the path, and
the session stays up.

Configuring /128s (and /32s) onto loopback interfaces and then using OSPF to
announce that is how ISPs operate today.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 May 2015 09:04:45 +1200

> announce that is how ISPs operate today.

Can somebody explain how this term "loopback interface" came into use?
There's no loopback address involved, it's just a virtual interface.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 May 2015 09:08:16 +1200

> I would further contend that in both cases (with and without ACP) the autonomic infrastructure should NOT assign/negotiate/put on routable addresses on links, but use exclusively link local there.…

I believe so. It would be to good walk through an off-link discovery process in gory
detail to check that this is OK in all cases.

> Does this map your understanding? 

Yes.
> OK, I heard this (to me strange) comment before, and would like to understand and settle this with the right wording. 

See my reply to Michael Richardson. It's only terminology.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 22:38:33 -0400

> There's no loopback address involved, it's just a virtual interface.

It's an interface on which, when you send a packet, it is immediately
received as local.   It's always up.  Some dummy or virtual interfaces just
eat the packet...  Our *convention* is that we put 127.0.0.1 on it, (or
::1), but of course, you can put any address you like, and operators
regularly do exactly that.  For instance, here is the (slightly obscured)
ifconfig output for anycast DNS server.  The addresses are /32 announced by
BGP upstream:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0xd
        inet 127.0.0.1 netmask 0xff000000
        inet 63.263.294.1 netmask 0xffffffff
        inet 63.263.294.2 netmask 0xffffffff
        inet 63.263.294.3 netmask 0xffffffff
        inet 63.263.294.4 netmask 0xffffffff
        inet 63.263.294.5 netmask 0xffffffff
        inet 63.263.294.6 netmask 0xffffffff
        inet 63.263.294.7 netmask 0xffffffff
        inet 63.263.294.8 netmask 0xffffffff
        inet6 3123:5h0:10::1 prefixlen 128
        inet6 3123:5h0:10::2 prefixlen 128
        inet6 3123:5h0:10::3 prefixlen 128
        inet6 3123:5h0:10::4 prefixlen 128
        inet6 3123:5h0:10::5 prefixlen 128
        inet6 3123:5h0:10::6 prefixlen 128
        inet6 3123:5h0:10::7 prefixlen 128
        inet6 3123:5h0:10::8 prefixlen 128
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 6 May 2015 07:38:07 +0100

>     > There's no loopback address involved, it's just a virtual interface.

loopback as a term of art significantly predates the existence of ip
networks.

if you want to refer to a device by an address which is not associated
with any of it's interfaces that address will be bound to it's loopback
interface typically.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 May 2015 19:07:51 +1200

> loopback as a term of art significantly predates the existence of ip

Sure.

> with any of it's interfaces that address will be bound to it's loopback

Sure. Michael Richardson's example is clear enough. But in the ACP
case we are trying to send packets amongst a set of ASAs over
secure L3overSomething tunnels. That sounds like a VPN in the full
sense of the term, so the addresses in question are associated with
the virtual interfaces that terminate the VPN tunnels. So they
are *not* addresses that are not associated with any interface.
I don't see why they are any different than the addresses
on a TAP interface.

There's a degenerate case when the two ASAs that want to communicate
happen to be on the same machine. In that case there is indeed
a loopback, but it isn't the general case.

Sorry to appear obtuse but I do want our terminology to be accurate
and not linked to specific implementation techniques. If there's
an RFC that clarifies all this I'd be pleased to study it.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 May 2015 14:05:30 -0400

> I don't see why they are any different than the addresses

If we have *no* dynamic routing over the secure L3 tunnels, then we can never
have a problem, but even RPL's DODAG can change. ANIMA typically won't be
dealing exclusively with radio interfaces (important thing about radio, is
that it's multiple access, but adjacencies are not transitive: so you can
change adjancies without necessarily changing interfaces), then one can not
depend upon the end points of the tunnels being stable.
In order to not create multi-link subnets, RPL node are actually encouraged
to configure /128 addresses on their loopback, and depend upon routing to get
to "adjacent" neighbours.

    > an RFC that clarifies all this I'd be pleased to study it.

So, there isn't any difference between an address on a loopback interface
and one on a virtual interface like a TAP interface, except that TAP
interfaces generally send the packet *somewhere*, whereas loopback doesn't.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 May 2015 16:28:35 +1200

Michael, and Michael,

Let's hope we can close this off soon...

> to "adjacent" neighbours.

That's fine. That's routing, and the routing community, for whatever historical
reason, uses a trick -- parking addresses on the imaginary loopback interface --
to ensure that they aren't assigned to any physical interface.

(Just to show that this is a trick: it appears that to install a loopback
interface on Windows 8, you have to go via "Add Legacy Hardware" and add
an imaginary device called "Microsoft KM-TEST Loopback Adapter". Duh.)

What niggles me in Michael Behringer's proposal is embedding this trick
in specification language; it makes anyone who actually parses the word
"loopback" wonder what is going on. So I  have the following suggestion for
draft-behringer-anima-autonomic-addressing:

OLD
   This scheme targets exclusively loopback addresses of nodes.  We
   assume that link-local addressing is used on the interfaces of links.

NEW
   This scheme targets exclusively virtual addresses of nodes within the
   ACP.  We assume that only link-local addressing is used for ACP
   traffic on the physical interfaces of links.

     Brian