Subject: Re: Comments on presentation of draft-lemon-stub-networks-ps-00

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 28 Jul 2020 13:46:43 +0000

Hi, I also have a comment – I think there may be significant overlap between this
document and “IPv6 Prefix Delegation and Multi-Addressing Models”:

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

That document evolved over the course of many years with working group input,
and I think could be used as a starting basis for what is trying to be done here.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, July 28, 2020 6:06 AM
To: Alexandre Petrescu <[email-masked]>
Cc: IPv6 <[email-masked]>
Subject: Re: Comments on presentation of draft-lemon-stub-networks-ps-00

On Jul 28, 2020, at 8:58 AM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:
- targetting an IPv4 setting: it would be difficult to work on that.  I mean, one could formulate a problem that says 'IPv4' among other things, but then when solution time arrives... write an I-D with a solution in IPv4 space at IETF?

Maybe formulate it as an 'IP' problem could be considered.

It’s a matter of practicality, whether it’s documented in the IETF or not. We know how to do NAT64, so one way to solve the “cloud-over-IPv4-infrastructure” problem is with NAT64. I don’t think this is unreasonable to document, and I’m certainly not suggesting that it be the primary answer. But practically speaking, if it’s not documented, it will just be done differently in each implementation.

- more clearly defining a stub network might be necessary.  The slide showed a 'stub router' and a 'stub host' but I am not sure a stub network is made of a stub router and a stub host.  At the same time, it might be that a stub network connecting to another stub network renders this latter just a network (not a stub network).

I would definitely appreciate comments on the document. :)

This could make think that a stub network might be made of only one subnet(?)

Yes, that’s explicit in the document—sorry for not explaining it.

- in the slide overviewing the solution space, an additional thing could be mentioned: that of using SLAAC with a non-64 prefix length.

How would this help?  Do you mean something like the 6lo backbone router proposal?  How does subdividing the prefix help with that?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2020 10:18:08 -0400

> document and “IPv6 Prefix Delegation and Multi-Addressing Models”:

This is quite a bit more complicated than what I am proposing. The ability to inject the delegated prefix into the routing infrastructure is definitely one of the issues to be addressed, though. RA works for next-hop, but if you want to go beyond that you need something more. I think that the usual way that PDs are currently handled would work, but I think we still have kind of a gap there—the DHC working group has looked at this more than once, but I the discussions never turned into an RFC.

---

From: [email-masked]
Date: Tue, 28 Jul 2020 16:41:08 +0200

Ted, et al,

Thanks for taking on this work.

I believe we have been around this track a few times before.

The solution space:

1) HNCP / Homenet
2) Multilink subnet routing with proxy ND (RFC4903)
3) Hierarchical PD (e.g. draft-gmann-homenet-relay-autoconf-00)
4) L2 bridging
5) 64share (RFC7278)
6) NPT66/NAT66
7) Evolution of ILNP
8) PMIP6?
9) Multi-link subnet routing - shared /64 + host routes
10) Backbone router (draft-ietf-6lo-backbone-router etc)

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

I would be surprised if you after considering all the requirements, and some of the failure cases of the other solutions, that you will not again end up with HNCP as the solution.
At least from a time to market perspective you would imagine that to be a lot quicker than defining something new.

If new, I have some hope for combinations of 9 with perhaps some ideas from 10, but that's only my personal preference.
It's unlikely we will ever become as permissionless as IPv4 with NAT is. Which might be a showstopper for some.

Best regards,
Ole

> On 28 Jul 2020, at 16:18, Ted Lemon <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 28 Jul 2020 15:14:19 +0000

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.

Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, July 28, 2020 7:18 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; IPv6 <[email-masked]>
Subject: Re: Comments on presentation of draft-lemon-stub-networks-ps-00

On Jul 28, 2020, at 9:46 AM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi, I also have a comment – I think there may be significant overlap between this
document and “IPv6 Prefix Delegation and Multi-Addressing Models”:

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2020 13:12:53 -0400

> is nothing complicated being proposed there, but certainly establishes the framework

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.

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

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 28 Jul 2020 17:48:27 +0000

Ø  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:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, July 28, 2020 10:13 AM
To: IPv6 <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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.

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

4) L2 bridging

5) 64share (RFC7278)

6) NPT66/NAT66

7) Evolution of ILNP

8) PMIP6?

Really complicated

Really complicated

Yup.