RE: [EXTERNAL] Comments on presentation of draft-lemon-stub-networks-ps-00

["Templin (US), Fred L" <[e-mail]>]

Ø  I think we are talking past each other. This technology is not present on the networks

Ø  I want to attach my stub network to. That’s pretty much the end of the story.

Not at all; you need to look at the drafts in conjunction with one another and then realize that
they already establish a framework for stub networks that has been in the public eye for years
now. If you want to introduce new access methods they could go as new sub-sections of the
existing documents. Note that we have also been investigating RIOs in the public domain for
a long time:

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/
https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/
https://datatracker.ietf.org/doc/draft-templin-6man-rio-redirect/

Contrary to popular belief, just because I wrote these documents does not make
them invalid.

Fred

From: ipv6 [mailto:[e-mail]] On Behalf Of Ted Lemon
Sent: Tuesday, July 28, 2020 10:13 AM
To: IPv6 <[e-mail]>
Subject: Re: [EXTERNAL] Comments on presentation of draft-lemon-stub-networks-ps-00




On Jul 28, 2020, at 11:14 AM, Templin (US), Fred L <[e-mail]<mailto:[e-mail]>> wrote:
Ted, please take a look at the document – in particular its structure and diagrams. There
is nothing complicated being proposed there, but certainly establishes the framework
for stub networks.

I think we are talking past each other. This technology is not present on the networks I want to attach my stub network to. That’s pretty much the end of the story.

On Jul 28, 2020, at 10:41 AM, [e-mail]<mailto:[e-mail]> wrote:
1) HNCP / Homenet

This technology is not present on any network I care about. If router vendors (ahem!) want to start pushing it, great, but until then it doesn’t help me.


2) Multilink subnet routing with proxy ND (RFC4903)

This sounds simple, but is actually really complicated.


3) Hierarchical PD (e.g. draft-gmann-homenet-relay-autoconf-00)

I think it’s unfortunate that we didn’t do this, although IIRC the details at the time weren’t quite right. The working group didn’t adopt the proposal, so we never got to fix that. What I’m suggesting actually does something similar.


4) L2 bridging

Can’t work for constrained networks.

5) 64share (RFC7278)

This is really just a more detailed description of the IPv6 portion of RFC 4903, if I’m reading it right. It could certainly be made to work, but seems unnecessarily complicated.


6) NPT66/NAT66

This is probably easier than 64share, but I think we’d prefer not to have NAT if possible.


7) Evolution of ILNP

This is really heavyweight. Why would we want to do this when IPv6 routing will do just fine?


8) PMIP6?

Really complicated


9) Multi-link subnet routing - shared /64 + host routes

Really complicated


10) Backbone router (draft-ietf-6lo-backbone-router etc)

This works, but requires that every stub router have a complete list of hosts on the stub network.  Depending on the stub network technology, this isn’t actually a viable solution. E.g., if the stub network is a mesh, keeping all of that data centralized is a lot of extra work. It’s equivalently complicated to options 7, 8 and 9.


These solutions vary with:
- the level of "permissionlessness"
- support for arbitrary topology
  (or essentially end up with implementing a spanning tree protocol with ND or DHCP)
- multiple sources of information
- deployment and implementation considerations

Yup.

Perhaps I should have said at the start, the point of this exercise is to figure out the minimal solution that solves the very simple stub network problem, not a general solution to the problem of automatically configuring arbitrary subnet topologies. The motivation for this is that the stub network problem turns out to be a very common use case (e.g., it’s the problem that the 6lo backbone router draft solves). A simple solution that works on an unmodified network is therefore worthwhile.

So what I’ve prototyped pretty much relies solely on RIO and PIO in a non-default router, uses ULAs for addressing on the stub network, and uses ULA if no IPv6 is present on the infrastructure network, otherwise uses what the infrastructure provides. This allows hosts on the stub network and infrastructure network to communicate transparently with no administrator intervention. There is no centralized device inventory, and hence none of the problems that come with maintaining such an inventory.

There isn’t actually any new protocol to write for this in 6man—it works using existing RA functionality.  However, there are some issues that come up when doing this, and that’s really what impacts 6man. For example, “routers” aren’t supposed to listen to RAs. But a stub router has to, or it won’t see the PIO that’s already present on the infrastructure network. Is that an okay thing to do? Is there a reason why that’s not allowed?

Separately, a lot of the suggestions you mention above try really hard to preserve stability of IP addresses on end-nodes. For some end-nodes, this is quite important: you don’t want your servers changing IP addresses all the time. For devices on home networks, this kind of stability is not all that useful, particularly for portable devices. This is not to say that stability is not good, but it’s not that important that my iPhone have the same exact IP address every time it connects, for example. So protocols that try to keep stable IP addresses are doing work that I don’t need done for my iPhone. This is why I say that things like ILNP and PMIP6 are “really complicated.” If you want to solve the problem they solve, they are no more complicated than needed. But this isn’t a problem that really needs to be solved for a lot of use cases, so it’s added cost that adds no value.