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