Re: [EXTERNAL] [Iotops] Automatically connecting to stub networks...

[Ted Lemon <[e-mail]>]

On Dec 7, 2020, at 3:21 PM, Templin (US), Fred L <[e-mail]> 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.