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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E58123A15D3 for <>; Wed, 2 Dec 2020 15:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, 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 UdmVAHjdlajg for <>; Wed, 2 Dec 2020 15:24:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 157EC3A15E0 for <>; Wed, 2 Dec 2020 15:24:04 -0800 (PST)
Received: by with SMTP id ek7so102776qvb.6 for <>; Wed, 02 Dec 2020 15:24:04 -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=i+VojTx+Su0FhCmNt+OckTXVWYHrK29+lbZ7m1IdqO4=; b=cFL6Ccm3C56tHUErq5om8ROjSLtW5+o41LTN1VQZD+iruE/QKBAz82idO0FYb05Y7C Kf/Yx1p6+uD62JeFFSsHhzECFxPIwHdP6j39iGV0KlJbQ8tiJeKZ1XSJJWVncDnf9jOp NguAtwRhWD9MtBaC4JZ+FzAUE+7Lt49Lnt9A9SXIctE3g+JKbavZ3+72BxXUjOl5j0Dc yqGrE48Xwo4AYdAq3Tgq2EMR2ubcyx0MFxHMNEd8sLvXzj1UPFTu15fhfHyCqLD1CZjP md/UopPNmmNcL2D1+3ded2ka3SLzb1tPzJZXRsyspiGdW8ttdqvfZkLXLyNpMDjOf5OQ D/tA==
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=i+VojTx+Su0FhCmNt+OckTXVWYHrK29+lbZ7m1IdqO4=; b=XpfCmeRZTS7TOJOuC1r0S3hLTzGnlfSodmhHO5lA5N6n+xrgC2MRi10uI7SOE8oVfG LjzuGSKNVXvBTpZr0mifu8hT0TvQgO+isbU7bNTvl2v8HxLX5kWSBMMVm37GKZILHRCK 6+SJQitGfy7Gn1KY4bJDLlybLuADcdXROfv4+imvQqpBxIhX8Za94vX/vuUP68kMT3BU FM7SuH5QBqRycF7+4gC+2sRIHrvTo5uWVhzaT7wncD3afdfu9+Jl+WutoNdbivT4DEgE j4uVzgvJSXaHnFCbYpr/NiOC/nqz2FA4cJyjVhtgckzqahvadcGKuBw+4ahgfx81Bcb/ 1W0A==
X-Gm-Message-State: AOAM530zh/FSqyoDy/rRKhDmN+SBWFwg7Dz5qBjIUgiRo7lP7pcsrzdZ UmbbyUgqwaJ2v6ndXQ5sw2P/9w==
X-Google-Smtp-Source: ABdhPJyWYQyBe1pgwXfhibGlIVWe0cYzTCrM7AnaS7fEIvW37rfyrK7k+4jfmmfFX3EAaJT9ierxCg==
X-Received: by 2002:a05:6214:493:: with SMTP id ay19mr379819qvb.36.1606951443797; Wed, 02 Dec 2020 15:24:03 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id z186sm153832qke.100.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 15:24:02 -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:24:01 -0500
Message-Id: <>
References: <689918.1606943760@dooku>
Cc: 6MAN <>,
In-Reply-To: <689918.1606943760@dooku>
To: Michael Richardson <>
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:24:08 -0000

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 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. 

> 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. 

> 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. 

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. 

Thanks for the review and comments!

>> 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.
> Your criticism if HNCP is all true, but an important part is that it really
> only provides for allocation of prefixes; not routing.
> (I still think that the WG made a mistake not extending OSPFv3)
> HNCP is not the part that's missing: it's the routing protocol in the home
> that is what's needed to do something more complicated.
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]        |   ruby on rails    [