IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 03 December 2020 18:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970553A0475; Thu, 3 Dec 2020 10:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIreh9p86rIJ; Thu, 3 Dec 2020 10:52:01 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA283A03FC; Thu, 3 Dec 2020 10:52:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 20CA7389CD; Thu, 3 Dec 2020 13:53:53 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3cP2K0LXr_Y3; Thu, 3 Dec 2020 13:53:52 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A30DE389CC; Thu, 3 Dec 2020 13:53:52 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9C2221FB; Thu, 3 Dec 2020 13:51:59 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Toerless Eckert <tte@cs.fau.de>, Ted Lemon <mellon@fugue.com>, 6MAN <6man@ietf.org>, iotops@ietf.org
Subject: Re: [Iotops] Automatically connecting to stub networks...
In-Reply-To: <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de>
References: <695953.1606952552@dooku> <B989299A-ED3C-4205-A4E2-DA080F574B33@fugue.com> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 03 Dec 2020 13:51:59 -0500
Message-ID: <3988.1607021519@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-Nc89r0J7CBsaM1S_c_28m-sJBY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 18:52:04 -0000

Toerless Eckert <tte@cs.fau.de> wrote:
    > - For example: Why not simply start with DHCP-PD ? IMHO, every home router getting
    > a prefix via DHCP-PD from a service provider is a provider of such a stub network.
    > Of course, service discovery as you expect does usually not work in that environment,
    > so that would need to be added.

While there is a CableLabs spec that argues for stacked DHCPv6-PD (and it was
presented in Homenet a few years back), to date, I'm aware of no deployed
home routers that operate a DHCPv6-PD server on their southbound interface.

Conceptually it's simple to implement.
Architecturally there are some who thinks it is gross, and some who think
it's brilliant.   I'm still sitting on the fence myself.

But, fundamentally, the issue Ted is trying to address is enabling
communications within the Home between layer-2s that can not, or should not,
be bridged.

I agree with your other suggestions for re-organization.
I have some ideas about how I would write this document.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email