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

Ted Lemon <> Fri, 04 December 2020 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8DA43A0FD7 for <>; Fri, 4 Dec 2020 13:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 t6cravDtCyUb for <>; Fri, 4 Dec 2020 13:19:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C36803A0FD8 for <>; Fri, 4 Dec 2020 13:19:41 -0800 (PST)
Received: by with SMTP id u21so5002778qtw.11 for <>; Fri, 04 Dec 2020 13:19:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T3qWtqgdYZV+Xv/1XuhVu8OdoTRZDJky3CNd57ev/kk=; b=JghT2+Spb1j13Xw8K6tukXOyd2SdVKJ0EuPx1Hv0rtNAnUZ6c1LRlTXniuxHOHmItV hXUxqsRfL86GnK/VjLv7HO00L8R9h9yglk9s0/FXE4GikGmejYQmJ9NX6k5ODpk7Xda7 2s4hBtUw4uKg5T6Ln676zbVjh4wd0wEkAXcgGkKhf0rrIQGCifaxMygOSffvhPY2YpLn jKGPJcFwnT2IhzhSquR0QHf/AJPqdSXzFZGSewT4yJxF0FT7PJ57fo9SP0vnhSza0ufS m82EXFCg4jJdZOwGJBn8d6/8b5UqfImNvk/BPybrAEn4L8EAVfGj4cQC2wunNYcRtiTD P3xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T3qWtqgdYZV+Xv/1XuhVu8OdoTRZDJky3CNd57ev/kk=; b=J2+TY1dBd2Bkakszdhb+mqHq8zRxtSZY3l9a0HkGEt92+piex52UEIhCRsSLt95Fio V7UQRPRWvw394UVgwts+MTz2Fg5/XplRgqHlwMamn7/PkTD7mjMFb82x3G0jNK0TgewS GnAH7pe1/aU1+tfAZHSfOEWfPCkgRdtSq/uPGag4f0l+13qflO5nho1waRUP9cukw0NS aOYcMqeHiXrK+xTrv/nrbTftB3Uk5TEUGai1m+Ba07JAKNwPiG7sn5E40OXEmVbCapmW 7ALXKWGFXHhd9BhOLPnPXH6XU9Ylamgd5HT3raTnJzG9uB+O5KtA4zuAj+MSi11tVQJ+ 9aCw==
X-Gm-Message-State: AOAM531UU1EA+lxXqV6AkBOU0RVgpJ7ogRxEH28u3Lv5NevoRMOQbgPZ W+MxAtduGBTtqazts6mn+qs3Aw==
X-Google-Smtp-Source: ABdhPJzrg5gtPqvk27l3cX/DOSZdtWKzalcUTAMNiMwlzxn7Qq/LpDDSYVk3AOfjBN/FBSLukYebXQ==
X-Received: by 2002:a05:622a:303:: with SMTP id q3mr11339175qtw.24.1607116780361; Fri, 04 Dec 2020 13:19:40 -0800 (PST)
Received: from mithrandir.lan ( []) by with ESMTPSA id g70sm6182144qke.8.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 13:19:39 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Fri, 04 Dec 2020 16:19:37 -0500
Cc: Toerless Eckert <>, 6MAN <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <695953.1606952552@dooku> <> <> <> <> <>
To: Ole Troan <>
X-Mailer: Apple Mail (2.3654.
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: Fri, 04 Dec 2020 21:19:44 -0000

On Dec 4, 2020, at 3:19 AM, wrote:
> Let's me see if I can dissect Ted's arguments against HNCMP in, and if restricting the problem to only allowing stub routers to be connected to a single router helps. (A topology with a single root router and a single level of branches).
> 1) HNCP only works if all routers in the AS runs it. It's a routing protocol so that's not surprising.
> Solutions would have to either participate in routing and a prefix assignment protocol.
> The degenerate case for routing is default route upstream and a static route for the assigned prefix downstream.
> All traffic to sieblings would go via root router.

HNCP is not a routing protocol. Babel is a routing protocol. HNCP is a mesh discovery protocol. It has a lot in common with routing protocols, but it’s really its own beast.

For the stub network case, HNCP simply isn’t necessary. I think the disconnect with HNCP is that it is aimed at a problem nobody wants to solve. The stub network problem is a problem that we wanted to solve enough that we spent two years working on it. HNCP was a choice we considered, but it simply wasn’t an option. I guess if you want routable IPv4, HNCP would help with that for the stub network case, but I don’t find this compelling—IPv6 works fine.

> Ted also mentions that HNCP does not deal with the case where only a /64 has been delegated to the site.
> In homenet we did a conscious choice of requiring a site to get enough addressing to get a /64 for each link.
> I do know that the implementation in OpenWRT does support a single /64 (it subnets into /80s and does DHCP address assignment).
> How to deal with a case of not enough addresses assigned is not a problem unique to HNCP though.

The point of saying that is that we need some way to do outbound connectivity in this case. Our solution to this problem is to use NAT64. Hopefully as v6only deployments happen, service providers will get real about assigning narrower prefixes.

> The degenerate case for addressing is:
> a) Split up a /64 in pools of addresses for DHCP
> b) If less than a /64 (e.g. already shared) then NAT

No point in doing NAT66 when you can do NAT64.

> 2) HNCP is too complex and does too much and is not implemented.
> Not enough details to make any arguments for or against this one.
> If one standard isn't deployed and implemented is a weak argument for inventing a new protocol and standardising that, that's neither specified, implemented nor deployed.

From my perspective, needing to ship a product that will work on real networks, and not rely on imaginary networks, the fact that there are no implementations and none coming meant that we simply couldn’t use HNCP, even though because of my time in the Homenet WG I was personally predisposed to do so and spent quite a bit of time evaluating it as a solution before abandoning it.

> Question, what are the requirements here?
> A) Stub network. Is it possible to restrict the topology to a single root/single level of leafes?
> It prohibits multi-homing. What about the case where a node is attached to the stub with a hypervisor and VMs requiring addressing?
> Is sending all traffic via the root acceptable? Instead of short-cutting between stub routers?

I see no reason to do this.

> B) Is it possible to restrict the solution to the site having been delegated enough address space?
> Or do you need to handle the cases where the site has:
> a) not received enough /64s to number all links
> b) have only been delegated a single /64
> c) have only a shared /64
> d) have only a single address

Our solution works in all of these cases except the v6-only /64-only case.

(I say our solution meaning what we did in the HomePod Mini and the open source Thread border router—we don’t have a specification yet, and didn’t actually do any protocol work.)