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

Ted Lemon <> Mon, 07 December 2020 20:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 288EE3A0AF8 for <>; Mon, 7 Dec 2020 12:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wvE0KKW8lwAl for <>; Mon, 7 Dec 2020 12:27:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 642A33A0B05 for <>; Mon, 7 Dec 2020 12:27:57 -0800 (PST)
Received: by with SMTP id dm12so7192223qvb.3 for <>; Mon, 07 Dec 2020 12:27:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/K0INh5F+Ce5/RewsBlQpWztEzz7rnC7rwb760onPeg=; b=PX0biWKKK04VxSV0yz/3o5J4Vs4foKSudJRmkQgb0qBSOwoIh08qKiXk4z4Z1/jOP9 fb4TmIFlIg4NRy11Otxh+Zd/AZwtT/upeM0tgPt1DBh3rdyYQIcPrOcDGgNqGSfoV0/q kC6bwRzKdB4LJu8MXhDPYEJ/RikFSjQ7fSqLQFkueofejWyIKWAH4qRt1MlIK1koMt7T FQCcu6wyp1LtMaBloxe23cowYJEIAOIK3V1D3oZ0HmwJlSUQEYrV2pzPHeOA68L2yutX ig8xJlIMf0QhVByHtPfuvlW8Bh4ePHbq9nn013h2Eb0Pv3aSF3p52/r/3YfvLlA+9E5c gtWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/K0INh5F+Ce5/RewsBlQpWztEzz7rnC7rwb760onPeg=; b=goikYiAZsl+LDbqjGgsQ436Mctv79uwD7fWSVz6eiQ5qkUdrAY+IGeBnogAZpJHohw Quwgen7ldwgn5RlQYPe3Co/HUPpyAjwf3BmXbV3DTF1zN/irkeHxKC284QDt0AoBYWmJ LvM3Lk7qWzIq2MV3SFhdSPuYcsXBA63MNnC2Lcph6WGtvOud7TVy1gwJStZ7YOJbeQeZ sq+5gugPZxuh9tb8bgXTnvv9HWr76e//g+DjeECmOZD3cSmlTmQD6XymDCg4+FFhplcG V/pINt33iMjcNwCACcwXduo5YEiOlzlv0qTXH3w+a4n4XX64S+WwIFZo2If1X0vY2xmy PI/Q==
X-Gm-Message-State: AOAM5311LbKHhidUUs277mG8IPNa4E6U+BHKKk3oz5nlS7xETebBGMnp hiebgyzgimg5sDml9ZvKgs2l0g==
X-Google-Smtp-Source: ABdhPJymPa97p8glcPyz86OyQMype41O22h53dtd7EyMjN8IYxf7Yi2NFxl2epaD7yJ/66Q2rN91wg==
X-Received: by 2002:ad4:5886:: with SMTP id dz6mr23412294qvb.10.1607372876350; Mon, 07 Dec 2020 12:27:56 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g18sm12310546qtv.79.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2020 12:27:55 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_01763A34-F5AA-4983-B897-8B1AEC8B1A89"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 07 Dec 2020 15:27:53 -0500
In-Reply-To: <>
Cc: "STARK, BARBARA H" <>, Michael Richardson <>, Ole Trøan <>, 6MAN <>, "" <>
To: "Templin (US), Fred L" <>
References: <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Iotops] [EXTERNAL] Automatically connecting to stub networks...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Dec 2020 20:27:59 -0000

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