Subject: Loopback interface terminology issue

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Oct 2017 14:11:54 +1300

Hi,

This come rather late in the day, but it results from some wordsmithing
difficulties in a draft in another WG:

The IPv6 specs are very clear that an address is assigned to an interface,
not to a node, but they don't say anywhere that non-loopback addresses may
be assigned to the loopback interface. However, sometimes as a practical
matter, it's necessary to assign a routeable address (GUA or ULA) that
is not created via a specific IPv6 interface. Conventionally, that is
done by assigning it to the loopback interface.

However, the only place I have found that defines 'loopback interface' for
IPv6 is in the addressing architecture: 'a virtual interface (typically
called the "loopback interface") to an imaginary link that goes nowhere.'
(RFC 4291, section 2.5.3). The text only mentions the loopback address ::1.

Do people agree with something like the following?

'Note that other forms of unicast IPv6 address may be assigned to the
loopback interface, in cases where an address is assigned to the node
without being assigned to the interface to a specific link.'

This is after all common practice in various operating systems; we
just never documented it, as far as I know.

Regards
   Brian Carpenter

---

From: Karl Auer <[email-masked]>
Date: Sat, 14 Oct 2017 12:41:13 +1100

> (RFC 4291, section 2.5.3). The text only mentions the loopback

Need to stay clear on the difference between a loopback interface and
the concept of localhost.

::1 is the localhost address; use it, and you are talking to "this host
right here". It doesn't have to be on a loopback interface, but it
generally makes sense for it to be, because a device may have no real
network interfaces at all, but you still want to be able to talk to
services running on it.

And similarly, loopback interfaces do not necessarily have to have a
localhost address on them. You can have lots of loopback interfaces on
a host, and they present variations of "this host right here" e.g. by
participating in different routing schemes or having particular
services on them. The interface is not the canonical identity of the
host, the localhost address is. That is ::1 in IPv6.

Things have become confused over the years because of the very strong
convention that "the" localhost address is on a loopback interface.

The fact that there is only one (1) localhost address in IPv6 vs the
entire /8 reserved in IPv4 is, I always thought, specifically to make
the distinction clear.

Or maybe it's just me.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C 6A3A
Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B

---

From: David Farmer <[email-masked]>
Date: Fri, 13 Oct 2017 20:52:03 -0500

> On Oct 13, 2017, at 20:11, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

This makes sense for a router participating in a routing protocol, so other routers know how to reach the address, and the hosts they route for. I’m not sure it necessarily makes sense on typical hosts which do not normally participate in any routing protocols, even multi-homed hosts for that matter.  A typical host with an address other that ::1 on a loopback interface would need static route on a router connected to at least one real interface of the host to successfully forward traffic to the address from anywhere other than the host itself.

It might also be good to say that such an address on a loopback interface commonly has a /128 prefix length.

> just never documented it, as far as I know.

I’d say common practice on routers, not so common on hosts.

> Regards
>   Brian Carpenter
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Oct 2017 15:22:49 +1300

> It might also be good to say that such an address on a loopback interface commonly has a /128 prefix length.

Not always, though. BCP198 applies at all times ;-)

> I’d say common practice on routers, not so common on hosts.

Well, yes, but that includes hosts with one or two explicit routes added
by hand, at which point they become de facto routers. So I think it's safe
to say 'node'.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Oct 2017 15:24:07 +1300

> entire /8 reserved in IPv4 is, I always thought, specifically to make

No, I think you're right. ::1 is not really at issue here.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 15 Oct 2017 03:36:39 +0200

Thanks Brian, for bringing this up

I think 4291bis should indeed have an actual definition of a loopback
interface. "virtual interface to an imaginary link that goes nowhere"
really sucks as a non-definition.

IMHO: A loopback interface is an attachment to a node internal 
"loopback link". If other addresses beside "loopback addresses" are
assigned to such a link, then this implies that the interface
is configured to forward non-self-destined packets.

That second sentence is the key functionality IMHO to define
architecturally what efverybody has been doing on routers for decades.

Not sure where to best write this into. IMHO its a refinement/update
to 8200, but could vbe put into 4291bis (claiming 8200 update).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sun, 15 Oct 2017 12:53:18 +1100

> is configured to forward non-self-destined packets.

No.  Whether such addresses are forwarded by default or not depends on
the weak/strong host model in use.
 
> to 8200, but could vbe put into 4291bis (claiming 8200 update).

Loopback interfaces are also used for test networks wholely constrained
to the node.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 15 Oct 2017 04:41:29 +0200

> the weak/strong host model in use.

Not really. If the transport stack (a) logically attaches to the loopback
interface then the loopback source address is the source address corresponding
to the interface. The difference between strong and weak model would only
come in if a transport socket (b) binds to a physical interface and tries
to send/receive packets for the loopback address.

I think the stacks i know logically do (a), althogh i am not sure how
cleanly it's implemented. If its 100% clean then the TTL of the sent packet
should be decremented by 1 before output on the physcial interface. Not
sure which stacks this is done in.

> Loopback interfaces are also used for test networks wholely constrained

Ok. How about:

If other addresses beside "loopback addresses" are assigned to such a link,
then the interface needs to be configured to forward non-self-destined
packets originated from the loopback interface (see rfc8200, section 2). 

Cheers
    Toerless

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 Oct 2017 12:32:27 +1100

On 15 Oct. 2017 13:41, "Toerless Eckert" <[email-masked]> wrote:

interface then the loopback source address is the source address
corresponding

Ok. How about:

This draft might help.

In IPv4, there are different forwarding rules for hosts and routers over
the loopback interface for the 127/8 prefix.

This draft proposes a larger IPv6 prefix for loopback, and mirrors those
differences.

https://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-04

Cheers
    Toerless

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 16 Oct 2017 13:23:17 +0000

> done by assigning it to the loopback interface.

When crafting the language for WAA-7 in rfc7084 (If ... then [the CE router] MUST create a global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network interfaces...), several router vendors explained to me they preferred this phrase "internal virtual network interface" over "loopback interface" because they didn't always assign the address to the loopback interface and didn't want the requirement to constrain the implementation. They said they sometimes use an interface associated with an internal switch. They said the more complex CE routers could have a variety of internal interfaces suitable for this purpose. 
Barbara

> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Tw4-hGqTflOaLUSMFh5CaOIeUpOoPzuLdwe1pZhF1tY&s=YpenyjKvrrjtyVbBXgY6t7UxFL6uv69mIR4st4L6fWY&e=

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Oct 2017 16:32:26 +0200

> When crafting the language for WAA-7 in rfc7084 (If ... then [the CE router] MUST create a global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual n…

It was to avoid confusion with how typical UNIX systems use a loopback interface. On most router implementations a loopback interface does not have the loopback address assigned to them / it.

Cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Oct 2017 15:22:36 +0000

Hi Brian,

'draft-templin-v6ops-pdhost' discusses the assignment of IPv6 addresses
to internal virtual interfaces such as loopbacks. Also about assignment of
delegated prefixes to the virtual interface.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, October 13, 2017 6:12 PM
> To: 6man <[email-masked]>
> Subject: Loopback interface terminology issue
> 
> Hi,
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 16 Oct 2017 10:00:11 -0700

At Sun, 15 Oct 2017 04:41:29 +0200,

> to send/receive packets for the loopback address.

I don't understand what this means, but in any case I agree with Mark
that IMO this is more about the weak/strong host model than
forwarding/non-forwarding.

> sure which stacks this is done in.

In BSD implementations it's perfectly fine to assign non-loopback IPv6
addresses to a loopback interface (it's typically 'lo0').  Since BSDs
use the weak host model, when for whatever reason that non-loopback
address is chosen as the source address for an outgoing packet,
there's no problem in sending the packet out to any interface (either
loopback or other 'physical' interface) with that address.  It doesn't
have to enable the 'ip6.forwarding' system switch to do so, and it
doesn't decrement the hop limit (btw there's no "TTL" in the IPv6
layer) when sending out the packet.

--
JINMEI, Tatuya

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 16 Oct 2017 20:14:42 +0200

---etherB---
      host --etherA-- rtr
                         ---etherB---
      |   host/rtr     |

Think of a host with an etherA connecting to a router that also has
etherB, etherC. Now we just integrate this router into the host and etherthernetA
becomes an internal interface, but the apps can still use this interface,
and so it is permissible for both strong and weak host models to use the IP
address on etherA, whatever exernal ethernetB/ethernetC the packets are
sent/received through.

The main difference between an internal ethernet and loopback in this modelling
is that when you send into a loopback interface, it does not need to run ND to
find the link-local address of the router interface and forward the packet to it,
but instead the packet is immediately processed by the router forwarding code.

> layer) when sending out the packet.

Sure, i just said it does not depend on it.

If you already need to participate in a routing protocol (for the reachability of
the address on the loopback interface) i always find it easier to model behavior
as a simple host stack and a co-ocated router. In IPv6 thats a lot more
attractive IMHO because its a lot more natural not to have those unnecessary
global reachable external interface addresses but only link-locals.

Anyhow: The question is what would be necessary or beneficial
to put into an IPv6 arch update RFC to allow all the common practice uses
of it.

Cheers
    Toerless

---

From: 神明達哉 <[email-masked]>
Date: Mon, 16 Oct 2017 11:49:23 -0700

At Mon, 16 Oct 2017 20:14:42 +0200,

> but instead the packet is immediately processed by the router forwarding code.

Okay, I think I now understand what you meant.  Such a model seems to
be quite a stretch convoluted or even artificial to me, but I wouldn't
necessarily deny possible existence of such implementations.  But in
any event that seems to me quite a stretch from the situation Brian
originally raised.  And, for these reasons, I personally wouldn't
support saying something in the addressing architecture that requires
a specific model of integrated host-router architecture.  More
specifically I disagree with adding to the addrarch doc:

If it also notes that it's for a host that adopts the strong host
model or the node adopting the hybrid architecture you mentioned
above, I might live with it, although I personally think it's too much
for the basic architecture document.

--
JINMEI, Tatuya

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 17 Oct 2017 00:35:37 +0200

Interesting, thanks Barbara.

I wonder if other folks would like to have a clearer architectural terminology
for "loopback interface" or "internal interface". Or what a better term for "physical"
interface is today (in the face of virtual nodes). And see a chance to get such
improved terminology into IPv6 arch updates.

E.g.: what is an "internal virtual interface" ?

Specifically in the face of "use an interface associated with an internal switch."

To me an internal interface is simply one that is not associated with a link
connecting to other nodes and is still up and running. 

I can use linux bridge interface to build an internal link in the same way
i can use a loopback inerface, but as soon as i would connect the bridge group
to other nodes, it would IMHO become an external link (from the perspective of describing
TCP/IP node behavior/terminology). 

In your RFCs example case i think one does not really care if the link is virtual
or internal. I think the requirement is really only: The CE needs a global address
reachable from SP link even if all other external links are down. However
you get that implemented. And if the CE itself consists of multiple (virtualized)
TCP/IP nodes, good for your, you've got even more options.

Cheers
     Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Oct 2017 11:45:21 +1300

> for the basic architecture document.

Yes. I think the point that is lacking in the architecture is
that unicast addresses that are not assigned to an operational
physical or tunnel interface may be assigned to a virtual
interface, which may be a loopback interface. 

All the rest is indeed implementation-dependent.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Oct 2017 23:15:55 +0000

Brian,

Here is what it says in 'draft-templin-v6ops-pdhost':

  "This document also considers the case when 'R' does not have any
   downstream interfaces, and can use 'P' solely for its own internal
   addressing purposes.  In that case, 'R' assigns 'P' to a virtual
   interface (e.g., a loopback) that fills the role of a downstream
   interface.

   'R' can then function under the weak end system (aka "weak host")
   model [RFC1122][RFC8028] by assigning addresses taken from 'P' to a
   virtual interface as shown in Figure 2:"

Internal virtual interfaces were also discussed in RFC5558.

Thanks - Fred

> Sent: Monday, October 16, 2017 3:45 PM
> To: [email-masked]
> Subject: Re: Loopback interface terminology issue
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 17 Oct 2017 01:58:15 +0200

On Mon, Oct 16, 2017 at 11:49:23AM -0700, ???????????? wrote:
> originally raised.

I don't think its that far out. In ANIMA ACP and other solutions, all
nodes are forwarders, run routing protocol, do not use external interface global
adddresses, but just those "internal" node addresses on eg.: a loopback interface.
If you look at the OS infrastructure of those nodes i think it is a lot easier
not having to bother with host stack improvements/changes if you can constrain it to
forwarder code. But of course my viewpoint may be tainted from work experience.

> And, for these reasons, I personally wouldn't
[...]

You're right. Given how it is equally well feasible to to not use forwarder
but weak host model, my proposal would constrain the options.

So, now i wonder for my ANIMA ACP draft if we should describe that the nodes
need to operate in the forwarder model i describe or in the weak host model,
or that should be left unsaid. The desired behavior definitely is not possible
with strong host model without forwarder.

> for the basic architecture document.

It certainly would be nice to have a description of how to operate
what i would call a "node address" in not a solution specific document like
our ANIMA ACP doc, but in some IPv6 arch document. Doesn't have to be
"basic". 

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Oct 2017 08:38:45 +1300

> Internal virtual interfaces were also discussed in RFC5558.

Well yes; indeed this topic is touched on in many RFCs but
nowhere is it defined as part of the basic architecture,
which is my main point. Using a concept that has no principal
definition is generally a source of confusion.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Oct 2017 19:45:15 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2017 12:39 PM
> To: Templin, Fred L <[email-masked]>; [email-masked]

I agree that it has been touched on in many earlier works, also
including 'draft-templin-aerolink' and many of my published RFCs.

But, I must say that it now also appears in RFC7934 (a BCP).

Thanks - Fred

---

From: joel jaeggli <[email-masked]>
Date: Tue, 17 Oct 2017 14:38:17 -0700

> definition is generally a source of confusion.
We tended not to define software interfaces for things which are not
required for interoperability. How you describe an address which is not
bound to a physical interface is entirely irrelevant outside the scope
of your own operating system.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Oct 2017 13:27:11 +1300

> of your own operating system.

That's not our experience in trying to be precise in saying what
we mean in draft-ietf-anima-autonomic-control-plane.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Oct 2017 12:44:08 -0400

Templin, Fred L <[email-masked]> wrote:
    >> On 17/10/2017 12:15, Templin, Fred L wrote: > Brian,
    >> >
    >> > "This document also considers the case when 'R' does not have any >
    >> downstream interfaces, and can use 'P' solely for its own internal >
    >> addressing purposes.  In that case, 'R' assigns 'P' to a virtual >
    >> interface (e.g., a loopback) that fills the role of a downstream >
    >> interface.
    >> >
    >> > 'R' can then function under the weak end system (aka "weak host") >
    >> model [RFC1122][RFC8028] by assigning addresses taken from 'P' to a >
    >> Well yes; indeed this topic is touched on in many RFCs but nowhere is
    >> it defined as part of the basic architecture, which is my main
    >> point. Using a concept that has no principal definition is generally a
    >> source of confusion.

    > But, I must say that it now also appears in RFC7934 (a BCP).

I scanned RFC7934, and it too would have benefitted from some
canonical text to explain non-loopback addresses on (virtual) loopback
interfaces.

The two questions that Brian has are, I think:

1) how can we best explain this in a way that takes what has been a
   (multi-decade old) operational BCP, and makes it clear that it's a
   standard mechanism?

2) where would we put this text, such that if we were to write a short
   document, what would we "Updates"

   I'm thinking that an update to RFC8028 would make sense, and that
   the scope/title of an 8028bis might change slightly as a result such text,
   because maybe all hosts actually live in a multi-prefix networks...

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Oct 2017 12:52:08 -0400

Brian E Carpenter <[email-masked]> wrote:
    brian> Well yes; indeed this topic is touched on in many RFCs but nowhere is
    brian> it defined as part of the basic architecture, which is my main
    brian> point. Using a concept that has no principal definition is generally
    brian> a source of confusion.

    joel> We tended not to define software interfaces for things which are not
    joel> required for interoperability. How you describe an address which is
    joel> not bound to a physical interface is entirely irrelevant outside the
    joel> scope of your own operating system.

    brian> That's not our experience in trying to be precise in saying what we
    brian> mean in draft-ietf-anima-autonomic-control-plane.

to restate Brian's point slightly differently:

The issue is not to tell people how to implement things in their software,
but rather to make it clear that we need a standard hook on which to hang our
addresses.

We'd rather not use the term "loopback interface" at all here if we had
another name defined in an RFC somewhere.

I think that there is some significant text that might need to be written
when defining this hook when in a strong-host model.

But, let me also ask a different question: are there router operating systems
where there is a way to hang an address on something which is not a
virtual/loopback interface?  If so, what do they call it?

If there are differences in software interfaces in some place that we would
be respecting by abstracting this requirement?
After 35+ years of router operating systems, has anyone actually innovated in this way?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Oct 2017 16:57:37 +0000

Hi Michael,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: Wednesday, October 18, 2017 9:44 AM
> To: [email-masked]

Non-loopback addresses that would be assigned to a loopback interface would
have to come from a delegated IPv6 prefix. Please see 'draft-templin-v6ops-pdhost'
for procedures of how to assign addresses from a delegated prefix to a loopback
or other virtual interface:

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

This document stems from my earlier works including RFC5558, RFC6179
and 'draft-templin-aerolink' which talk about assigning delegated prefixes
to internal virtual interfaces such as loopbacks. But, the 'pdhost' draft is
still open for edits - should it be made standards-track?

Thanks - Fred

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Oct 2017 22:11:35 -0400

> Hi Michael,

hi, I was beginning to think that your emails were just trolls to get us to
read your documents :-)

    mcr> I'm thinking that an update to RFC8028 would make sense, and that the
    mcr> scope/title of an 8028bis might change slightly as a result such text,
    mcr> because maybe all hosts actually live in a multi-prefix networks...

    > Non-loopback addresses that would be assigned to a loopback interface
    > would have to come from a delegated IPv6 prefix. Please see
    > 'draft-templin-v6ops-pdhost' for procedures of how to assign addresses
    > from a delegated prefix to a loopback or other virtual interface:

    > and 'draft-templin-aerolink' which talk about assigning delegated
    > prefixes to internal virtual interfaces such as loopbacks. But, the
    > 'pdhost' draft is still open for edits - should it be made
    > standards-track?

okay, so I read the document.
I got to the end of section 1, thinking I had reached the end of a nice short
document, because it seemed like the problem was described and a solution
described in the Introduction.
I was going to write: if we had a canonical document that explained how
            virtual interfaces could be used to hand addresses on, then your
            document could be even shorter.

Then I got to the other sections, where (I was reading rather quickly while
eating) you go on to explain the various ways in which these virtual
interface interact with (or do not interact with) the pieces of the IPv6
architecture.

It was only then that I understood why you felt that this document could
perhaps grow to be about loopback/virtual interfaces.  So, if we took
a small part of your Introduction, and the rest of the document, then I
agree, we might have the "Virtual Interfaces in IPv6" document that we all
want.   Then your current document would be renamed:
   "Solving the IPv6 Prefix Delegation for Hosts using Virtual Interfaces"

and would be only those nice diagrams you have in section 1.

---

From: "tom p." <[email-masked]>
Date: Fri, 20 Oct 2017 17:33:13 +0100

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 18, 2017 5:52 PM

> virtual/loopback interface?  If so, what do they call it?

When I first came to IP, I was surprised to find that L3 addresses were
assigned to interfaces, as opposed to nodes, the latter having been the
case with other networks I had used previously.  I have always seen the
creation of a virtual interface as a quirk which overcomes this absence
of a node address, or node identifier in the IP namespace.

I first encountered the term 'loopback interface' in Cisco
documentation, which talks of the ability to configure a 'virtual
interface, referred to as a loopback interface'.  So for me, 'loopback
interface' has always been the Cisco term for a virtual interface but
why it should be loopback, as opposed to virtual, I have never found
out.

Whatever the name is, it does provide an identifier for the node and
one, at least in some systems, that is always up and so provides a
stable identifiier for protocols that need one, such as a router-id in
BGP; and you can have more than one such identifier, separating
functions, perhaps by priority, to prevent DoS attacks..

Tom Petch

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Oct 2017 17:12:26 +0000

Below:

> From: ipv6 [mailto:[email-masked]] On Behalf Of tom p.
> Sent: Friday, October 20, 2017 9:33 AM
> To: Michael Richardson <[email-masked]>; [email-masked]

In IP, addresses are assigned to interfaces. So, when there is no other
alternative the address can be assigned to a loopback (or other virtual
interface).

Similarly, advertised and delegated prefixes need to be added to an
interface's prefix list. Delegated prefixes can be added to a the prefix
list of a downstream interface (i.e., even if the downstream interface
happens to be a loopback or other virtual interface).

Prefixes received in a Router Advertisement (RA) with 'L=1' in the
Prefix Information Option (PIO) are added to the prefix list of the
interface over which the RA was received and with "on-link" set.

Prefixes received in RA PIOs with 'L=0' are a bit strange, however.
RFC4861 seems to imply that the prefixes are associated with the
prefix list of the interface over which the RA was received, but
the "on-link" value is not set since 'L=0' contains no information
as to whether the prefix is on- or off-link. (If the prefix was already
in the interface's prefix list, however, the "on-link" value is not
changed.)

Thanks - Fred

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 20 Oct 2017 22:08:52 +0200

If i followed BrianC's note correctly, then the loopback interface
dates back to BSD Unix stack earlier than routers: The problem
was how to allow the use of TCP/IP if you do not even have any
external interface up and running. YOu didn't want to create/choose
yet another socket type for that case. Would have made apps very complex.

Are historic BSD 4.2 vs. 4.3 sources freely available now for some history check ? ;-))

-- 
---
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Oct 2017 16:21:29 +0000

Hi Brian,

I see the possibility for a standards-track draft that specifies how to assign
IPv6 addresses and prefixes to loopbacks and other virtual interfaces (e.g.,
an internal network of virtual machines). We also saw comments from
Toerless Eckert and Michael Richardson expressing similar sentiments.

Do you think it would be a good idea to cut a little 5-6 page draft on
this? If so, would you be interested in co-authoring, and possibly also
including Michael and Toerless?

Thanks - Fred