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

Michael Richardson <> Wed, 02 December 2020 21:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE74E3A1802; Wed, 2 Dec 2020 13:18:13 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2_y1-iqsGSDX; Wed, 2 Dec 2020 13:18:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD5FF3A1913; Wed, 2 Dec 2020 13:16:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 295971F45D; Wed, 2 Dec 2020 21:16:45 +0000 (UTC)
Received: by (Postfix, from userid 179) id 232081A02BA; Wed, 2 Dec 2020 16:16:00 -0500 (EST)
Received: from dooku (localhost []) by (Postfix) with ESMTP id 202CB1A026C; Wed, 2 Dec 2020 16:16:00 -0500 (EST)
From: Michael Richardson <>
To: Ted Lemon <>, 6MAN <>,
In-reply-to: <>
References: <>
Comments: In-reply-to Ted Lemon <> message dated "Fri, 10 Jul 2020 02:25:25 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 02 Dec 2020 16:16:00 -0500
Message-ID: <689918.1606943760@dooku>
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 21:18:21 -0000

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

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.

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.

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.

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