Subject: Automatically connecting to stub networks...

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jul 2020 02:25:25 -0400

I mentioned prior to IETF 107 that I wanted to start a conversation about this problem, but didn’t have time to write a draft.  I’ve written one, which I think describes my view of the problem pretty well; I’d like to know if what I’ve written here makes sense to others.  This is semi-related to the Homenet problem, but doesn’t try to do as much, which makes the problem a bit more tractable, and addresses at least one fairly important use case.

A new version of I-D, draft-lemon-stub-networks-ps-00.txt
has been successfully submitted by Ted Lemon and posted to the
IETF repository.

Name:		draft-lemon-stub-networks-ps
Revision:	00
Title:		Self-configuring Stub Networks: Problem Statement
Document date:	2020-07-08
Group:		Individual Submission
Pages:		15
URL:            https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt <https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt>
Status:         https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/ <https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/>
Htmlized:       https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00 <https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lemon-stub-networks-ps <https://datatracker.ietf.org/doc/html/draft-lemon-stub-networks-ps>

Abstract:
  IETF currently provides protocols for automatically connecting single
  hosts to existing network infrastructure.  This document describes a
  related problem: the problem of connecting a stub network (a
  collection of hosts behind a router) automatically to existing
  network infrastructure in the same manner.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.

The IETF Secretariat

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Jul 2020 11:12:18 +0200

as titled I think the draft makes sense.

In the requirements section, the requirements which talk about Prefix 
Delegation, I think it makes sense to think about a new requirement: 
that of automatically forming sub-prefixes.

This is a potentially very simple operation, so simple that it might get 
unnoticed when implemented.  Yet some implementations do differ in the 
way they form sub-prefixes.

I mean, in this text:
> 2.3.4.  Requirements
> 
>    o  Infrastructure network must support prefix allocation using DHCPv6
>       prefix delegation.
> 
>    o  Infrastructure network must install routes to prefixes provided
>       using DHCPv6 prefix delegation.
> 
>    o  In the case of multiple stub routers, stub routers must cooperate
>       both in acquiring and renewing prefixes acquired using prefix
>       delegation.  Stub routers must communicate complete routing
>       information to the DHCPv6 prefix delegation server so that it can
>       install routes.

Suggested additional requirement: A stub router should be able to 
automatically form at least one /65 out of the /64 received from the 
DHCPv6 Prefix Delegation Server.

Something like that.

There are several potential rules that can be written down in a 
programmatic manner.  These rules might express how many sub-prefixes to 
form, of which length.

This formation of sub-prefixes out of a received prefix should not be 
hardcoded.  The immediate rule that comes to mind is to form /65s out of 
a /64.   But it is not the only rule, and as such it should not be 
hardcoded.

(but that's disgressing into the solution space)

Alex

Alex

Le 10/07/2020 à 08:25, Ted Lemon a écrit :
> I mentioned prior to IETF 107 that I wanted to start a conversation 
> about this problem, but didn’t have time to write a draft.  I’ve written 
> one, which I think describes my view of the problem pretty well; I’d 
> like to know if what I’ve written here makes sense to others.  This is 
> semi-related to the Homenet problem, but doesn’t try to do as much, 
> which makes the problem a bit more tractable, and addresses at least one 
> fairly important use case.
> 
> Name:draft-lemon-stub-networks-ps
> Revision:00
> Title:Self-configuring Stub Networks: Problem Statement
> Document date:2020-07-08
> Group:Individual Submission
> Pages:15
> URL: 
> https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt
> Status: https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/
> Htmlized: https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00
> Htmlized: https://datatracker.ietf.org/doc/html/draft-lemon-stub-networks-ps
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org 
> <http://tools.ietf.org>.
> 
> The IETF Secretariat
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Jul 2020 11:13:26 +0200

and there should be a requirement also on 'nesting' - a stub that 
attaches to a stub that attaches to a stub...

Alex

Le 10/07/2020 à 11:12, Alexandre Petrescu a écrit :
> This is a potentially very simple operation, so simple that it might 
> get unnoticed when implemented.  Yet some implementations do differ in 
> the way they form sub-prefixes.
>
> I mean, in this text:
>> 2.3.4.  Requirements
>>
> programmatic manner.  These rules might express how many sub-prefixes 
> to form, of which length.
>
> hardcoded.  The immediate rule that comes to mind is to form /65s out 
> of a /64.   But it is not the only rule, and as such it should not be 
> hardcoded.
>
>> about this problem, but didn’t have time to write a draft.  I’ve 
>> written one, which I think describes my view of the problem pretty 
>> well; I’d like to know if what I’ve written here makes sense to 
>> others.  This is semi-related to the Homenet problem, but doesn’t try 
>> to do as much, which makes the problem a bit more tractable, and 
>> addresses at least one fairly important use case.
>>
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-lemon-stub-networks-ps
>>
>>
>> Abstract:

---

From: David Farmer <[email-masked]>
Date: Fri, 10 Jul 2020 04:35:14 -0500

Wait a minute, if you connect a stub to another stub, the previous stub
isn’t a stub any longer. Maybe you want to talk about how to promote a stub
automatically by automatically connecting a new stub to it, but the
previous stub is proving transit for the new stub and is now a backbone or
core network, but most certainly not a stub network, at least by any
definition I understand.

On Fri, Jul 10, 2020 at 04:13 Alexandre Petrescu <
[email-masked]> wrote:

> and there should be a requirement also on 'nesting' - a stub that attaches
> to a stub that attaches to a stub...
>
> Alex
> Delegation, I think it makes sense to think about a new requirement: that
> of automatically forming sub-prefixes.
>
> unnoticed when implemented.  Yet some implementations do differ in the way
> they form sub-prefixes.
>
> I mean, in this text:
>
> 2.3.4.  Requirements
>
> automatically form at least one /65 out of the /64 received from the DHCPv6
> Prefix Delegation Server.
>
> Something like that.
>
> hardcoded.  The immediate rule that comes to mind is to form /65s out of a
> /64.   But it is not the only rule, and as such it should not be hardcoded.
>
> I mentioned prior to IETF 107 that I wanted to start a conversation about
> this problem, but didn’t have time to write a draft.  I’ve written one,
> which I think describes my view of the problem pretty well; I’d like to
> know if what I’ve written here makes sense to others.  This is semi-related
> to the Homenet problem, but doesn’t try to do as much, which makes the
> problem a bit more tractable, and addresses at least one fairly important
> use case.
>
> <http://tools.ietf.org> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Jul 2020 11:43:52 +0200

I think I agree.  And the word 'nesting' was not appropriate either.

Indeed it's probably more like a stub being promoted to become part of core.

But the requirement should the there to allow the network to scale up to 
bigger.

Alex

Le 10/07/2020 à 11:35, David Farmer a écrit :
> isn’t a stub any longer. Maybe you want to talk about how to promote a 
> stub automatically by automatically connecting a new stub to it, but the 
> previous stub is proving transit for the new stub and is now a backbone 
> or core network, but most certainly not a stub network, at least by any 
> definition I understand.
> 
> On Fri, Jul 10, 2020 at 04:13 Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>     In the requirements section, the requirements which talk about
>>     Prefix Delegation, I think it makes sense to think about a new
>>     requirement: that of automatically forming sub-prefixes.
>>
>>     This is a potentially very simple operation, so simple that it
>>     might get unnoticed when implemented.  Yet some implementations do
>>     differ in the way they form sub-prefixes.
>>
>>     I mean, in this text:
>>>     2.3.4.  Requirements
>>>
>>     automatically form at least one /65 out of the /64 received from
>>     the DHCPv6 Prefix Delegation Server.
>>
>>     Something like that.
>>
>>     programmatic manner.  These rules might express how many
>>     sub-prefixes to form, of which length.
>>
>>     This formation of sub-prefixes out of a received prefix should not
>>     be hardcoded.  The immediate rule that comes to mind is to form
>>     /65s out of a /64.   But it is not the only rule, and as such it
>>     should not be hardcoded.
>>
>>>     I mentioned prior to IETF 107 that I wanted to start a
>>>     conversation about this problem, but didn’t have time to write a
>>>     draft.  I’ve written one, which I think describes my view of the
>>>     problem pretty well; I’d like to know if what I’ve written here
>>>     makes sense to others.  This is semi-related to the Homenet
>>>     problem, but doesn’t try to do as much, which makes the problem a
>>>     bit more tractable, and addresses at least one fairly important
>>>     use case.
>>>
>>>     Status:
>>>     https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/
>>>     Htmlized:
>>>     https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00
>>>     Htmlized:
>>>     until the htmlized version and diff are available at
>>>     tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>
>>>     <http://tools.ietf.org>.
>>>
>>>     The IETF Secretariat
>>>
>>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> David Farmer Email:[email-masked] <mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jul 2020 10:14:51 -0400

Who would we need the extra bit?  This is a stub router, so by definition it can only use one prefix. Unless you are thinking that a stub router might route for more than one stub network?

> On Jul 10, 2020, at 05:13, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> and there should be a requirement also on 'nesting' - a stub that attaches to a stub that attaches to a stub...
> 
> Alex
> 
>> In the requirements section, the requirements which talk about Prefix Delegation, I think it makes sense to think about a new requirement: that of automatically forming sub-prefixes. 
>> 
>> This is a potentially very simple operation, so simple that it might get unnoticed when implemented.  Yet some implementations do differ in the way they form sub-prefixes. 
>> 
>> I mean, in this text: 
>>> 2.3.4.  Requirements 
>>> 
>> Suggested additional requirement: A stub router should be able to automatically form at least one /65 out of the /64 received from the DHCPv6 Prefix Delegation Server. 
>> 
>> Something like that. 
>> 
>> There are several potential rules that can be written down in a programmatic manner.  These rules might express how many sub-prefixes to form, of which length. 
>> 
>> This formation of sub-prefixes out of a received prefix should not be hardcoded.  The immediate rule that comes to mind is to form /65s out of a /64.   But it is not the only rule, and as such it should not be hardcoded. 
>> 
>>> URL: https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt 
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>. 
>>> 
>>> The IETF Secretariat 
>>>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jul 2020 10:19:35 -0400

On Jul 10, 2020, at 05:44, Alexandre Petrescu <[email-masked]> wrote:
> But the requirement should the there to allow the network to scale up to bigger.

It’s true that there may be some use case for hierarchical, non-mesh self-forming networks, but that’s not the use case I’m trying to address here. We tried to address that use case in homenet and arguably failed.

My goal here is to describe something that can be done largely with existing technology and can be deployed in real, existing networks today.

---

From: Richard Patterson <[email-masked]>
Date: Fri, 10 Jul 2020 15:46:15 +0100

On Fri, 10 Jul 2020 at 15:15, Ted Lemon <[email-masked]> wrote:

> Who would we need the extra bit?  This is a stub router, so by definition
> it can only use one prefix. Unless you are thinking that a stub router
> might route for more than one stub network?
>

Honest question here, does the term "stub router" preclude it from being
multihomed?
i.e. it could be a stub router for multiple networks, as you suggest.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jul 2020 11:10:05 -0400

On Jul 10, 2020, at 10:46 AM, Richard Patterson <[email-masked]> wrote:
> Honest question here, does the term "stub router" preclude it from being multihomed? 

Let’s be careful with our terms here. “Multi-homed” is usually talking about connectivity to the Internet. A stub router that routes for multiple stub networks is a different use case, although equally valid.

How a stub router should handle the multi-homing problem is an interesting problem. E.g., should it advertise prefixes on both provider networks on the stub network? For a constrained network, that might not be desirable, and it’s probably not reasonable to expect constrained nodes to be able to decide appropriately which upstream to use.  I don’t actually know of a clean way to solve this problem, because as we’ve seen with the “slaac improvements” discussion, knowing For Sure what the status of a prefix is if we are just using RAs is not really possible.  Since we’re using prefix delegation, conceivably the delegating router could send a DHCP Reconfigure message, but that would be new behavior, and how it’s handled would need to vary based on whether or not the host is multi-homed.

How a stub router would handle multiple stub networks is actually pretty straightforward—for stub-to-stub routing, it’s just a normal router; for stub-to-infrastructure and back, the stub router can be treated conceptually as one stub router per stub network—it would have to acquire a prefix for each stub network, it would have to advertise routes to each stub network, and so on.  I guess we’d want to specify that all of the stub network-specific routes would be sent in a single RA.  So yeah, it’s probably worth talking about both of these problems in the document.

---

From: Simon Hobson <[email-masked]>
Date: Sun, 12 Jul 2020 10:25:12 +0100

> Who would we need the extra bit?  This is a stub router, so by definition it can only use one prefix. Unless you are thinking that a stub router might route for more than one stub network?

In my experience, "the typical home user" does not understand networking beyond "network cable with RJ45 plugs into hole where it fits". In a wired network, they'd expect to plug a network cable into a "network" socket and it'll work.
I could also see situations where someone see's a wireless network (itself generated by a stub router) and connects "stuff" to it. An analogy would be where people have used wireless extenders which advertise the repeated signal as a different name to the original WiFi SSID. If a stub router provided a WiFi downstream service, then I could see users expecting to be able to use it as a repeater (whether the upstream connection os wired or wireless) and connect stuff to it - and some of that stuff may itself be a stub network.

There's an element here of contriving a situation, but we don't know what inventive uses people might come up with. So take a large(ish) house, and because ti was convenient for the telco or developer, the phone/internet line comes into one end of the house. User gets some (say) home automation stuff, and the hub doesn't connect reliably to the main WiFi. User happens to have a repeater (which is actually a stub router, but the user doesn't know that) which is able to connect to the main WiFi and provide a signal that the HA hub can connect to. So HA hub is a stub router, with another stub router as it's upstream connection. The user, who knows nothing about routers and "technical stuff", expects it to work ...
I've seen networks with routers used as switches - with the uplink port connected to the main network, so two different networks with different IPv4 setups etc - and the user is then confused as to why they have seemingly random connection problems (as their mobile device roams from one network to the other). In one case I sorted out, they had done this, but also had Sonos gear that automatically bridges everything together using [R]STP - and that was an "interesting" network !

This may be a case of user education, if that is possible.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Jul 2020 09:38:10 -0400

On Jul 12, 2020, at 5:25 AM, Simon Hobson <[email-masked]> wrote:
> So take a large(ish) house, and because ti was convenient for the telco or developer, the phone/internet line comes into one end of the house. User gets some (say) home automation stuff, and the hub doesn't connect reliably to the main WiFi. User happens to have a repeater (which is actually a stub router, but the user doesn't know that) which is able to connect to the main WiFi and provide a signal that the HA hub can connect to. So HA hub is a stub router, with another stub router as it's upstream connection. The user, who knows nothing about routers and "technical stuff", expects it to work …

This is not a use case for stub networks. If the user does that, then the stub network doesn’t work. This is actually a better outcome than what we do today, which is to double-NAT and then have weird and unexpected behavior that doesn’t match the user’s mental model. Sure, the user might be disappointed that when they plugged these two things together, they didn’t work, but at least they didn’t sort of work.

This whole topic has been discussed at some length in the Homenet working group. Homenet came up with a solution to the problem you’re talking about. Nobody implemented it—it was too complicated, and not baked enough. Meanwhile, the market moved on: nowadays, if you want to address the use case you are talking about, you buy one of a variety of Wi-Fi mesh routers. You plug them in, and they take care of this problem. If you want to extend your network, you buy another mesh hub. Your Home Automation network plugs into whichever hub is nearest—you don’t even know or care which hub it’s talking to.

I’m not in love with the home Wi-Fi mesh solution, but the one thing I can say for it is that it got the job done. Nobody is wondering how to set up home networks in large homes anymore.  But we definitely do have a problem of what to do when we want to plug a home automation network into a Wi-Fi network, for example.

It’s quite possible that, if we decide to standardize a way to do stub networks, that later on we may want to explore building hierarchical networks. I’m on the fence about that—the reason we went with mesh in homenet rather than hierarchy was that people thought it wasn’t sufficiently general, and would fail the “mental model” test. So that’s a question the IETF has already considered and decided, and the decision did not go in the direction you’re suggesting. If we want to re-open that issue at some point, I would not object, but right now I’m trying to address just this very specific problem, which I think is a problem that we need to address in the short term, for which the market doesn’t already have a solution, and, importantly that we _can_ address in the short term.