Subject: [v6ops] draft-templin-v6ops-pdhost-15 (was: Re: Loopback interface terminology issue)

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 Oct 2017 19:11:23 +0200

[moving to v6ops where the draft is, Bcc 6man]

On Wed, Oct 18, 2017 at 04:57:37PM +0000, Templin, Fred L wrote:
> 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?

Nice draft.

a) Wrt to standardization Q: The draft does not have any MUST/SHOULD/MAY, so i am a bit
unsure what its asking to standardize. Eg: how would i verify if some implementation
claiming to support it complies with it ?

b) editorial:

b.1) I would like to see only the terms "internal/external" interfaces being
used instead of "virtual/physical" as the old IPv6 arch docs do. In the age
of node virtualization "virtual" is meaningless, and "physical" is irritating.

b.2) The introduction seems to be summarizing existing standards/practices in
the first three paragraphs and then introduce the new work of this draft. I
would suggest to consider restructuring to make this more explicit. Eg: first
three paragraphs as "background", and then the following as the main part
of the doc. Having them together in a single "introduction" is confusing.

c) Logics:

It would be nice to be more specific about what really constitutes an "internal
application". For example in the 6man thread about the meaning of loopback
addresses, i got the impression that folks would also understand a linux
bridge with one side in the hypervisor and the other in a VM as internal
interfaces, but IMHO thats just normal external interfaces:

Aka: You could start outlining how you can convert the original design
(downstream interface(s) with connected "hosts") into a "physcial internal"
solution without changing anything in the approach: replace the downstream link
with some e.g. virtual bridge and the hosts with VMs, and e-voila: internal
applications/VMs). IMHO, this solution has no "internal" interfaces because
the hypervisor and VMs are clearly different "nodes" in the IP architectuer.

Then the next step is really thinking of the implications of more lightweight
solutions. This unfortunately is where it gets tricky. Eg: Assume the
hypervisor/VM changes to a linux host with containers, and the interfaces are
veth pairs, which is popular in container-land. In the first place this
does not look much different than the hypervisor/VM case, but in fact,
there is a single TCP/IP stack/OS operating now the host and the containers,
so the question is whether this is one IP node or multiple. I would argue
that its still multiple nodes because the TCP/IP stack is virtualized into
multiple virtual nodes in a lightweight fashion, and on the IP side
the most easy recognition of this is that the interfaces used such as
the veth pairs in linux still have two interfaces on them - one on the
container, and one on the host.

So, finally you get to even more lightweight application integration, which
is where you'd use some form of loopback interfaces and for example create
for every app an individual loopback interface and make it only use that
interaface. Alas, linux does not even have a good model for this, aka:
you can not really force a linux app to only use the address(es) of this
one interface. So this IMHO ideal model is also implementation wise the
most broken one in actual implementations. But it works if you have well-behaved
apps that explicitly only bind sockets only to the address given to them.

So, IMHO this is really what i would call "internal applications", because
there is only one node = TCP/IP stack, we just manage the addresses
at socket level, and even more so, the interfaces used, e.g.: loopback
interfaces are not connected to links with multiple interfaces!!!

In any case, its some form of definition like what i tried to say in the
previous paragrph that IMHO is necessary to define what an "internal"
application is. If folks have different opions wrt. to VMs, containers
or "address" based applications being internal, then it would be good
to see if we can even create a recommended terminology.

Cheers
    Toerless

> Thanks - Fred
> 
> > --
> > Michael Richardson <[email-masked]>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> > 
> > 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 19 Oct 2017 11:11:40 -0700

> On Oct 19, 2017, at 10:11 AM, Toerless Eckert <[email-masked]> wrote:
> 

RFC 2119 is not a requirement in a standard :-)

The question would be whether the implementation implements what the document describes.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Oct 2017 18:36:41 +0000

Hello Toerless,

> -----Original Message-----
> From: Toerless Eckert [mailto:[email-masked]]
> Sent: Thursday, October 19, 2017 10:11 AM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]; Michael Richardson <[email-masked]>
> Subject: draft-templin-v6ops-pdhost-15 (was: Re: Loopback interface terminology issue)
> 

Thank you.

> claiming to support it complies with it ?

The document is currently written from an Informational/BCP standpoint,
but we could consider reclassifying it as standards track if that would make
the most sense. In that case, we could bring in RFC2119 keywords.

> of node virtualization "virtual" is meaningless, and "physical" is irritating.

Agreed (about physical -> external) and (virtual -> internal).
I will make the change.

> of the doc. Having them together in a single "introduction" is confusing.

Got it - makes sense to me. I will make the changes.

> the hypervisor and VMs are clearly different "nodes" in the IP architectuer.

Right, if I get your meaning I think this could be accommodated by including
a new figure showing the virtual bridges and hosts as internal entities that
behave like they are on external interfaces. Am I on the right track?

> container, and one on the host.

Agreed. I am definitely open to suggestions on how to accommodate
these abstractions.

> to see if we can even create a recommended terminology.

It would be very good if we could capture how a "host" that receives a
Prefix Delegation can distribute it to internal downstream networks in
the way you are describing. I quote "host" because it is really acting as
if it is a router (even if it might be something traditionally thought of
as being host-like, e.g., my cellphone).

Open to hearing more suggestions on how to proceed.

Thanks - Fred
[email-masked]