Subject: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101

From: Fred Baker <[email-masked]>
Date: Sat, 28 Apr 2018 21:41:15 -0700

At IETF 101, Fred Templin presented draft-templin-v6ops-pdhost. The draft is at https://tools.ietf.org/html/draft-templin-v6ops-pdhost, and his presentation deck is at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-ipv6-prefix-delegation-models-00.

I would like to invite discussion.

In the deck, he asks three questions:
1. Do we want to remain prefix delegation service agnostic, or focus on one specific service (e.g., DHCPv6-PD)?
2. What do we call end systems that receive a prefix delegation? Host? Router? Node?
3. Does the answer to 2. depend on the weak-host, strong-host distinction?

You are welcome, of course, to also raise any other questions or concerns.

---

From: Fred Baker <[email-masked]>
Date: Sun, 29 Apr 2018 17:09:17 -0700

> 3. Does the answer to 2. depend on the weak-host, strong-host distinction?

Speaking for myself, and hats off, I think the weak-host/strong-host distinction isn't currently an accurate depiction of how hosts or routers work in 2018, and isn't an obvious choice for a virtualized system. I refer to RFC 1122, section 3.3.4.2,  Multihoming Requirements, which has to do with the choice of source address from a host with more than one interface.

The rules given are that (1) if the packet is being sent in response to a packet received, it MUST use the destination address in that packet as its source address, (2) it MUST be possible for the application to specify the source address, and (3) if neither (1) nor (2) apply, the communication layers below the application MUST (as in, "are forced to") select a source address. As additional considerations, (A) a host MAY discard a packet received on a physical interface other than that which its destination address is used on, and (B) a host MAY restrict itself to sending datagrams from the interface configured with whatever source address it uses.

The document then continues with "discussion", which to my thinking is the most interesting part of RFC 1122, 1123, and 1812, which has to do with "why". The "Weak ES model" and the "Strong ES model" are found in that discussion, and are explicitly non-normative.

In the Strong ES model,
                      The Strong ES (End System, i.e., host) model
                      emphasizes the host/gateway (ES/IS) distinction,
                      and would therefore substitute MUST for MAY in
                      issues (A) and (B) above.  It tends to model a
                      multihomed host as a set of logical hosts within
                      the same physical host.

In other words, (A) a host MUST discard a packet received on a physical interface other than that which its destination address is used on, and (B) a host MUST restrict itself to sending datagrams from the interface configured with whatever source address it uses.

                      Note that this model logically requires that in
                      general there be at least one default gateway, and
                      preferably multiple defaults, for each IP source
                      address.

The Weak ES Model
                      de-emphasizes the ES/IS distinction, and
                      would therefore substitute MUST NOT for MAY in
                      issues (A) and (B).  This model may be the more
                      natural one for hosts that wiretap gateway routing
                      protocols, and is necessary for hosts that have
                      embedded gateway functionality.

In other words, (A) a host MUST NOT discard a packet received on a physical interface other than that which its destination address is used on, and (B) a host MUST NOT restrict itself to sending datagrams from the interface configured with whatever source address it uses.

The question Fred is asking has to do with "end systems that receive a prefix delegation", and whether we would call such a one a host, a router, a node, or something else.

From my perspective, if a prefix is assigned to a chassis for use in addressing its applications, containers, virtual hosts, or whatever, it is not assigned to an interface per se. It is best thought of as having been assigned to a network that in some sense lies "behind" a router, comparable to having been assigned to a home or other network through the CPE that connects to the upstream network. So any discussion of the prefix being "on an interface" isn't visible to that upstream network. There is an address there, of course, which may be only a link-local address, and in the upstream router is primarily used as the next hop in the route toward the prefix in question. Whether it as available for network management purposes is not specified; if it is a global address, it might be used for network management purposes, and if it is link-local, the network management application would have to be on the same LAN for that to work. I would expect, rather, that network management is done via some application in the same chassis, perhaps in a container or virtual host. Yes, that address would be used in network management messages on the interface in question; if the chassis had multiple physical interfaces, it might also be used on them.

In other words, the weak and strong ES models are inadequate to describe a chassis allocated a prefix. It is a case not discussed in currently-published RFCs.

What do we call such a chassis? I call it a chassis. It would be valid to call it a node, although from a networking perspective it contains multiple virtualized nodes. It is not, in my view, exactly a host (a system with an address on one or more interfaces and responding only packets sent to one of those addresses), nor is it exactly a router (a system that receives messages sent to an address not configured on one of its interfaces and forwarding it toward another system, the indicated host); it is a third category. That category is a set of systems that contain one or more identifiable routers and MAY contain one or more identifiable hosts, in some virtualized sense.

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Apr 2018 12:03:01 -0400

> Speaking for myself, and hats off, I think the weak-host/strong-host distinction isn't currently an accurate depiction of how hosts or routers work in 2018, and isn't an obvious choice for a virtua…

IMO, Internet nodes are inherently weak-host at the IP layer and
strong-host at the link layer. 

The weak-host part is validated, as you note, by RFC 1122. 

The strong-host part is validate, AFAICT, by ARP and neighbor discovery.

Although there can be addresses assigned to a "node" rather than an
interface, the distinction is philosophical at best; as you point out,
all addresses are effectively virtual interfaces anyway - and those
interfaces are defined in the context of the network over which they
reach other interfaces. 

Joe

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Apr 2018 20:06:12 +0000

Hi Joe/Fred,

A comment on one point that was made:

>Although there can be addresses assigned to a "node" rather than an interface,

I always understood that addresses were assigned to an interface,
even if only a loopback or other internal virtual interface. An
address (or prefix) can be delegated to the node, but until the
node assigns the addresses to an interface they are unreachable.
And, if the node receives packets with destination addresses that
are unassigned it can either send a Destination Unreachable, or
just let it black hole. Do I have this right?

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Monday, April 30, 2018 9:03 AM
To: Fred Baker <[email-masked]>
Cc: V6 Ops List <[email-masked]>
Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101

On 2018-04-29 20:09, Fred Baker wrote:
On Apr 28, 2018, at 9:41 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
3. Does the answer to 2. depend on the weak-host, strong-host distinction?

IMO, Internet nodes are inherently weak-host at the IP layer and strong-host at the link layer.

Although there can be addresses assigned to a "node" rather than an interface, the distinction is philosophical at best; as you point out, all addresses are effectively virtual interfaces anyway - and those interfaces are defined in the context of the network over which they reach other interfaces.

Joe

---

From: Ole Troan <[email-masked]>
Date: Mon, 30 Apr 2018 22:16:25 +0200

Fred,

Yes. IPv6 addresses are assigned to interfaces. 

Cheers,
Ole

> On 30 Apr 2018, at 22:06, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Joe/Fred,
>  
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Apr 2018 16:58:58 -0400

On 2018-04-30 16:06, Templin (US), Fred L wrote:

> even if only a loopback or other internal virtual interface.

They strictly don't need to be assigned to an interface at all, except
as an artifact of how certain OSes are designed. 

I.e., you can assign one to "the node" that is not assigned to an
interface, so that it would be used as a source address only when
explicitly indicated by the application or as a reply to that address
(and never, e.g., as a side effect of 1122 forwarding lookup). 

> An 

They may be unreachable from L2 packets received on an addressed LAN,
but they would be reachable from unnumbered pt-pt interfaces or via
decapsulation (again, depending on how the OS implements tunnels). 

Yes, it's simpler in most current OSes do assign these to an interface
(at least a virtual interface), but it isn't strictly required. 

For IPv6, this would require a way to assign an address that was NOT a
direct effect of receiving an RA message, but that's permitted. 

Joe 

> Thanks - Fred 
> 
> FROM: v6ops [mailto:[email-masked]] ON BEHALF OF Joe Touch
> SENT: Monday, April 30, 2018 9:03 AM
> TO: Fred Baker <[email-masked]>
> CC: V6 Ops List <[email-masked]>
> SUBJECT: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 
> 

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 May 2018 09:51:01 +1200

> as an artifact of how certain OSes are designed.

But they are *defined* in IPv6 thus [RFC4291]:

"IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces
... Unicast:   An identifier for a single interface.
... Anycast:   An identifier for a set of interfaces (typically
    belonging to different nodes)
... Multicast: An identifier for a set of interfaces (typically
    belonging to different nodes)."
> (and never, e.g., as a side effect of 1122 forwarding lookup).

Not really. Because of the above quote, an IPv6 address is always
assigned to an interface. Sometimes it's assigned to a virtual
interface quaintly known as the "loopback" interface.

It's murkily different than IPv4.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Apr 2018 18:16:18 -0700

> On Apr 30, 2018, at 2:51 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> .... Unicast:   An identifier for a single interface.
> .... Anycast:   An identifier for a set of interfaces (typically
> .... Multicast: An identifier for a set of interfaces (typically
>    belonging to different nodes).”

It’s even more direct in 2.1:
"IPv6 addresses of all types are assigned to interfaces, not nodes.”

Sadly, neither case uses normative language nor explains why this needs to be the case. Further, the definition of “interface” points to RFC2460, which defines it as attaching to a link, somewhat undermining the idea that they can even be assigned to virtual interfaces that don’t associate with a link at all.

So if you need to do the mental calisthenics to say “or assigned to a virtual link not associated with a physical link” vs. “associated with the node”, sure - do so. I don’t see the difference at all, except as an implementation detail.

> It's murkily different than IPv4.

IMO, it’s murky all around…

YMMV.

Joe

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Apr 2018 21:27:47 -0400

> On Apr 30, 2018, at 4:06 PM, Templin (US), Fred L <[email-masked]> wrote:
> 

Ole and Joe already replied. I'd be interested in comments from people that have deployed the allocation of a prefix to a node. My understanding is that the address is assigned to a virtual interface used by a container or whatever. When people talk about assigning one to an application (which I have also heard), I tend to think they are using it as a combination of an address (get the packet to the destination node) and a port (deliver the packet to a transport session or application). At that point, it diverges a bit from the historic "address on an interface" model in the sense that the interface isn't completely obvious.