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

Ted Lemon <> Wed, 02 December 2020 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D05C63A0AB1 for <>; Wed, 2 Dec 2020 15:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0i9-N2PCDBQP for <>; Wed, 2 Dec 2020 15:47:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DF1F3A0AB5 for <>; Wed, 2 Dec 2020 15:47:41 -0800 (PST)
Received: by with SMTP id 62so113340qva.11 for <>; Wed, 02 Dec 2020 15:47:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=AY6sdN2A9hmCopdDnf/my9estnpsksdYOcjq+Qn9ICs=; b=q1XRd9Fbm8U4k/rZDx1Yw22zP1GJPaICwQsOGNT+rq2a/Ar+JtukvVL81PY6seZfKa QQjd5gIbpTcU2ltajdxuimKUc2Hd7an5UJpww9iaXkuHIyeYP0DN4Xw3yWotqp0ZAgbV yKqvynpO59T4w1j8xmbBWgyjurk/yJEHVhvIRFsX6JtzC4hlKuxyFScV3PqFHzSAIDLs LJCAjrWwWQ2CZUBEXoe6XDSfO0dsX6qggL/Bf1XvrIOfinDHC4pHNyRy2tAUFrYXyDoP OxV4Zrd5IAtrSzTLz4yqT5x8Ig0LzRa2mrepkxkdpyo2vBvqWxzO2nuGx/CpWt8LNua3 Rdfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=AY6sdN2A9hmCopdDnf/my9estnpsksdYOcjq+Qn9ICs=; b=QjFfoFwUgnvrrvIGPw2fq4onc/8lXOIMJvYM+g+NrlYUVo916lDZpaRIxqBjJvEjC5 v4gcyoDZdqCjGu+5ZO2XYvXfda3RasDwYmr6Qumgu2dmfS+VQQtEoijRGJoacx+eKjsW PVtOlZDl1IIjFxEpQ6KuY6Tm9COBeG7IU8QU9bsFw+BKpDUvE7AuJW0nf+9OPjMBu8k6 Vf7MclHb+T7xi0FCtZeQJ1apwf970kjj6iHqFn1hQNl99MQmdYxEdqLeZni9Savg61XB PKsla8/Y7MCUty5x0ZZCVYtfLPjYzyuwBrRn04av1EokjTH2WVIx6I9AVm1v9fRrbdGD WKgQ==
X-Gm-Message-State: AOAM5335Kfz92B37ZwZQpqgLuvbrGTaRpvyUcQGsVt4FvK0EW5SRGbRD gH5YUJ9dUTgR06GNYe18yvsZDu6crwVPYHST
X-Google-Smtp-Source: ABdhPJzIKWlgfhZpiWFYC5MRLuO/B8Jprb6bZteK0k+gx4KsUE7XntnYQRiBS5lME7zmkrEYa6orDw==
X-Received: by 2002:ad4:524d:: with SMTP id s13mr371558qvq.19.1606952859896; Wed, 02 Dec 2020 15:47:39 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e3sm494489qts.8.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 15:47:39 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <>
Mime-Version: 1.0 (1.0)
Date: Wed, 02 Dec 2020 18:47:38 -0500
Message-Id: <>
References: <695953.1606952552@dooku>
Cc: 6MAN <>
In-Reply-To: <695953.1606952552@dooku>
X-Mailer: iPhone Mail (18C62)
Archived-At: <>
Subject: Re: [Iotops] 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: Wed, 02 Dec 2020 23:47:44 -0000

“This” is what we did in the Apple thread border router. I’m nervous about anything in the IETF with IoT in the title because it will be subject to the Carsten Bormann DoS attack. 

I don’t know if we have visibility into the right part of Google to get the chrome problem fixed. Their IoT team is fairly far removed from their browser team. What’s the use case?

> On Dec 2, 2020, at 18:42, Michael Richardson <> wrote:
> Ted Lemon <> wrote:
>>> On Dec 2, 2020, at 16:16, Michael Richardson <>
>>> wrote:
>>> (trying to clean out my inbox)
>>> Ted Lemon <> wrote:
>>>> 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.
>>> Ted, I think that your work addresses a problem space that is in some
>>> ways similar to the "share64" concept.  Not the same, but similar.
>> Yes. But I think share64 on a WiFi network would require proxy ND,
>> which doesn’t scale well, particularly if you have multiple unmanaged
>> routers providing readability and transit.
> I wasn't saying that the same solution applies, but rather the problem space
> is the same.   Device-X has some IPv6 on a network "behind" it, and wants to
> share addresses on a wifi/LAN in front of it in order to enable connectivity.
> I'm unclear from reading your document if the RA's would have L=0 or L=1.
>>> I think that the use of ULA which is advertise to the "LAN" for
>>> reachability does not have to be mutually exclusive with NAT64 for
>>> "cloud" reachability.
>> Absolutely. That’s what we’re thinking for the ipv4 and dual stack
>> cases. Doesn’t work for v6-only.
> So, if the LAN is v6-only and does not have DHCPv6-PD or HNCP+Babel, then I
> think it's a fail for cloud connectivity.   In particular, in this case, it's
> hard to report the failure to anyone offsite!
> It might be worth describing how this failure case could be reported intelligently.
> This is an operational kind of thing which is in charter for IOTOPS.
>>> Since your document does not actually require any new protocol, but
>>> just explains how to do something new using existing mechanism, I
>>> think that it would fit into the current IOTOPS charter.
>> I don’t think this is IoT-specific. I would prefer to do the work in
>> intarea.
> I don't think something needs to be IoT-only to belong in IOTOPS.
>>> In answer to your question: State of the Art
>>> Currently there is one known way to accomplish what we are describing
>>> here [[Michael, does ANIMA have a second way?]].
>>> The ANIMA ACP sets up an overlay network with /128 routing via
>>> RPL(RFC6550) storing mode.
>> I don’t get a mental picture from this of how it helps.
> I'm sorry, I didn't finish the thought.  "It does not help at all"
>> FWIW, Apple is now shipping a product (HomePod Mini) that does stub
>> network routing for thread networks, and there’s also an open source
>> implementation. Right now it only does the ULA solution. I’ll be
>> writing a draft that describes this soon.
> I'm unclear what "this" is.
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]        |   ruby on rails    [