Re: [homenet] Support for RFC 7084 on shipping devices...

Ted Lemon <mellon@fugue.com> Fri, 04 October 2019 15:59 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE361208AF for <homenet@ietfa.amsl.com>; Fri, 4 Oct 2019 08:59:21 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 wBc2qJCxK0cQ for <homenet@ietfa.amsl.com>; Fri, 4 Oct 2019 08:59:16 -0700 (PDT)
Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF81120103 for <homenet@ietf.org>; Fri, 4 Oct 2019 08:59:16 -0700 (PDT)
Received: by mail-pf1-x444.google.com with SMTP id h195so4163651pfe.5 for <homenet@ietf.org>; Fri, 04 Oct 2019 08:59:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yHN4gYfAdMpPDROCS1a0+OUuWVSstvzO6ONyo5746A8=; b=dcC26l7dkC4yckbX/jFq2LEcJ50i8TPoU+4whXlpD1aGquiws8PNN4ow2AEBB4wO3w QLkMtSXTZR3CoEKmHMkeLlrfrHBY7k0hulUjbGmWUjwPpSF1OxkcVRR0Gk5jw2b46x01 Rax6nP/1Lcqec8RRrKIH76d2ibzkN+5dgcozB9mYrjJ/N2Sdu4WzkuU4gJMDUxC+cawX koGwGtGfeyndvkOsRfq6q2vktiw9QJt8etQY9ZNwIh227X1bnb8Oq5VAD+5IH6rcFduK CURxAG4u7UdQFf4cFjJRQu8/kwQOy5vFPW6qHqYZQt5PVNQa2sr43WgOgqJ4nlrlG5nd 9V+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yHN4gYfAdMpPDROCS1a0+OUuWVSstvzO6ONyo5746A8=; b=HLR7xAoKxT5Nd1gf5g7kOwb6cG0M/ipM07E/7IPdxkBlubysOzTpsjeDOInrb2q5dP CsvWfC5JG/Huer3BAMKkckVBTmfFOBMYKBniPa7ryS4vi1L6+ejWNDdsSoX+9Mu23pey R1ItbypxDRpALEzINqyeO4ix6+vNK8Nu9SBzVAKzgP92J5dDX698+rT9X4LylTy/OeP2 ytPassuHCmddfrsL4UtBwKqfQ6YzajVY6Ihq0IMkBd4D0GHGnIfNGdnit7kWCJMjBZ51 jpUL8VolrhUPIqBk3ixZqS9+Dix6epAmEtA5fPd3rhTvNbxppcw1Nkaed17IPtHjzWe9 eO5A==
X-Gm-Message-State: APjAAAVFp8BV8zymklck2oDGXdJA3MUnkj9yN+cuq1WJssf+fE1PY5Yv AndbH7tbSsoZkC8EvhDuYha2FA==
X-Google-Smtp-Source: APXvYqzj8+1MxuJTLXQgs0M1MKcizp12LFWylGO9qb00gvoZv3tg6qjkIYjAVpXOl8C5Lwi27biZkA==
X-Received: by 2002:a63:6c81:: with SMTP id h123mr16215834pgc.132.1570204756043; Fri, 04 Oct 2019 08:59:16 -0700 (PDT)
Received: from [17.192.138.229] ([17.192.138.229]) by smtp.gmail.com with ESMTPSA id f15sm6880417pfd.141.2019.10.04.08.59.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Oct 2019 08:59:11 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <60B2C15B-E126-4F86-AA9A-9EB9A6C0EB2D@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4F7795AF-2784-4A63-ABE8-E783D6200BB6"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3599.1\))
Date: Fri, 04 Oct 2019 08:59:09 -0700
In-Reply-To: <E50D25C7-8EF1-4685-9442-021F019F7F62@employees.org>
Cc: Markus Stenberg <homenet@ietf.org>, 6MAN <6man@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <otroan@employees.org>
References: <56255ECF-9002-4440-BA0D-665EFC4BA9C6@fugue.com> <F638F635-9A1C-409E-BDB8-C00DF00A64C8@employees.org> <alpine.DEB.2.20.1910040752050.968@uplift.swm.pp.se> <A52F076F-817D-4807-8CD6-280C2040AEBF@employees.org> <5F0D2E3D-BE20-4421-8A37-E81E6B93B3A5@fugue.com> <E50D25C7-8EF1-4685-9442-021F019F7F62@employees.org>
X-Mailer: Apple Mail (2.3599.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/3BYicAR_TbuEPyB6q3Wlb6Xqf7I>
Subject: Re: [homenet] Support for RFC 7084 on shipping devices...
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Oct 2019 15:59:22 -0000

On Oct 4, 2019, at 6:28 AM, Ole Troan <otroan@employees.org> wrote:
>>> Homenet has solved the problem of self-configuring networks in arbitrary topologies.
>> 
>> If that were true, I wouldn’t be asking this question.  We’re still chugging along, but we don’t have something that nay router vender could even consider shipping right now. There isn’t enough participation in homenet anymore for us to really iron out the kinks.  Certainly if I could count o homenet being present in routers in the home, we wouldn’t be having this conversation! :)
> 
> Since this was sent to an IETF list I assumed you were focused on standards. (And presumably also running code). :-)

It’s the running code that’s the problem.  What I’m hunting around for is whether there are some things we need to do that we haven’t yet done.   I wish I could say “just turn on Homenet and everything will be fine,” but we aren’t in a position to say that yet.   If people are feeling satisfied that homenet is “done,” we (the IETF, and the Internet community in general) have a problem.

We’d been tempted to punt on this because there are perfectly good commercial solutions that solve this problem with L2 bridging, but those don’t work when you need to route between WiFi and e.g. 6lowpan networks.

>>> - single router and bridging (7084)
>> 
>> If it doesn’t filter RA, and I control the second router, I’m okay, right?
> 
> Well, yes it isn't a router at that point, it's a bridge.

The reason I mentioned this particular problem is that I’ve heard reports of 7084 routers implementing RA guard, which sort of makes sense, but it totally breaks this use case.

>>> - arbitrary topology plug and play (homenet)
>> 
>> Yes, that’s homenet.   It would really help if folks who think homenet is done would try to deploy it in their home using OpenWRT and see how it goes.   Seriously.   This is not a solved problem.   We’re maybe 50-60% of the way there at this point.   I’ve been trying to make progress on this ever since HNCP was declared done, and occasionally get collaboration, and indeed we may be begining to make progress agan, but we could definitely use more participation if there are folks in 6man who want this to work and imagine that it already does.
> 
> The notion of "permissionless extensions of the network" is still somewhat unresolved. HNCP allows for that, but as we know it's not well supported/deployed. I had some hopes for multi-link subnet routing (implemented how it was originally intended, not as spanning tree in ND). But I have never gotten around to flesh that out in detail. Pascal has done various stuff in this space for lowpan, which may be something to build on.
> 
> The MLSR idea is basically a /64 shared across all links. Hosts register with routers using ARO (or DHCP). Routers advertise host routes in a routing protocol between themselves. The tricky parts are of course detecting when hosts go away, detecting movement and so on.

I’ve seen this.   It’s how the 6lowpan folks seem to have defined their “routing."   But scalability is horrible, and when I’ve looked at doing an implementation, it’s obviously ridiculously harder than just publishing an RA.   And it’s particularly hard if there’s no IPv6 on North Network.    So if there’s a way to get IPv6 to work in this case, that seems like a better option.

> A side meeting in Singapore perhaps?

I’m not going to be in Singapore—I just can’t justify the carbon footprint.   I do think we ought to have a deeper discussion about this, though.   Maybe a “virtual interim”?   If there’s interest, I’d be happy to organize this.   I’d also be happy to attend a side meeting in Singapore remotely, but our experience with that thus far has been pessimal, and I don’t think a fix is planned for Singapore (unless I just haven’t heard about it).