Subject: RE: [Iotops] Automatically connecting to stub networks...

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Dec 2020 20:49:28 +0000

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, December 07, 2020 12:28 PM
To: Templin (US), Fred L <[email-masked]>
Cc: STARK, BARBARA H <[email-masked]>; Michael Richardson <[email-masked]>; Ole Trøan <[email-masked]>; 6MAN <[email-masked]>; [email-masked]
Subject: Re: [Iotops] Automatically connecting to stub networks...

Ted, it surprises me that I don’t seem to be reaching you on this, so maybe we are
talking about different things? My model for a mobile node is a mobile router with
a downstream-attached network where one might find an attached “Internet of
Things” – a simplest example would be a small router with a “northbound” wireless
interface and a “southbound” Ethernet interface attached to a switch to which a
small number of hosts are connected. The mobile router needs to get a “Mobile
Network Prefix (MNP)” from the network via its “northbound” interface, so it sends
an RS with a piggybacked DHCPv6 Solicit on board. The Access Router in the
network gets the RS, extracts the DHCPv6-PD Solicit and sends it to the DHCPv6
Server, gets back the DHCPv6-PD Reply, then crafts an RA with the DHCPv6 Reply
on board and sends it back to the mobile router. The mobile router then turns around
and advertises the delegated prefix over the “southbound” interface, and the attached
IoT devices are happy. Is this not the kind of scenario you are interested in when you
talk about stub networks?

Fred

On Dec 7, 2020, at 3:21 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Ted, there is a need to reduce the number of messages especially on low end
wireless links like those used for aviation. So, if a terse DHCPv6 PD exchange
can be piggybacked on-board the RS/RA exchange that already needs to be
there in any case then there is a tangible savings on messages over the air.
This is good for more than just aviation, too, and applicable for mobile use
cases such as intelligent transportation systems and urban air mobility; maybe
even for pedestrians too.

I still can’t think of a case where this applies to stub networks. E.g., if you decide to support stub networks on an airplane, you’re going to need a prefix to allocate stub network prefixes from. That’s one transaction over the satellite link to get that prefix, plus some maintenance. If your satellite link is so slow that this is a problem, it’s not going to be usable, so we don’t need to address that use case.

If you are thinking that the airplane’s public WiFi network is itself a stub network, I think that would be out of scope for stub networks—the whole point of stub networks is to be able to automatically connect without an operator’s intervention, which doesn’t match your use case. Additionally, I would consider a home network connection to also be out of scope for stub networks, and that’s somewhat analogous to the airplane use case.

If you mean the airplane’s automation network, the same objection applies.

So I really don’t see where there’s overlap here.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Dec 2020 16:00:16 -0500

On Dec 7, 2020, at 3:49 PM, Templin (US), Fred L <[email-masked]> wrote:
> talking about different things? My model for a mobile node

Stub routers aren’t mobile nodes in any meaningful sense. The use case where a “mobile” node might act as a stub router is when it currently tethers, and now needs to provide continuity of service for tethered devices when it has WiFi access. The mobile case is out of scope, and indeed we’ve had a discussion here about issues that come up when tethering with IPv6-only on a mobile device. This is not that discussion.