RE: Loopback interface terminology issue

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

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Tuesday, October 17, 2017 12:39 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>; ipv6@ietf.org
> Subject: Re: Loopback interface terminology issue
> 
> On 17/10/2017 12:15, Templin, Fred L wrote:
> > 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.
> 
> 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
> 
> >
> > Thanks - Fred
> >
> >> -----Original Message-----
> >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> >> Sent: Monday, October 16, 2017 3:45 PM
> >> To: ipv6@ietf.org
> >> Subject: Re: Loopback interface terminology issue
> >>
> >> On 17/10/2017 07:49, 神明達哉 wrote:
> >>> At Mon, 16 Oct 2017 20:14:42 +0200,
> >>> Toerless Eckert <tte@cs.fau.de> wrote:
> >>>
> >>>>> 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.
> >>>>
> >>>>                          ---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.
> >>>
> >>> 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 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).
> >>>
> >>> 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.
> >>
> >> 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
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> 