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

Ted Lemon <mellon@fugue.com> Sun, 06 October 2019 21:41 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 DB58B1200B5 for <homenet@ietfa.amsl.com>; Sun, 6 Oct 2019 14:41:12 -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 ozU5KeBCoEgG for <homenet@ietfa.amsl.com>; Sun, 6 Oct 2019 14:41:10 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 83E9C12003E for <homenet@ietf.org>; Sun, 6 Oct 2019 14:41:10 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id 21so9364716otj.11 for <homenet@ietf.org>; Sun, 06 Oct 2019 14:41:10 -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=jInElTV9f9FE2McSjW3r/VcJozRCOhtLuLq96zwMaT4=; b=wc1Ex5QSwJojOJlppgNc3Y+Ym9+p3ILH4CbFfzJscjFB1VyXKCknpRovqP5RbfzWnk dO9gKFuVEvkQsJnZxbZAsJh8WCEqrHeh5q/0kHu0aJ8vK1SxlnWQUUDk7DlOk2+uFMQO GFzYWZKRcGrYyPCS+vW80qf6b6BWM/rxy7NEVwiSuDLIyirfX/Ohhn4cJDxt3d0yDzsO 5Yw5Ajb5dYivyXTXOplUTlA+kblNn/slFFaS/mIFITFykNXH8xzKJ6BJFRac9gzsEqUk u2rCiQ5HyDtKAmlcIEDl/Rkyb1jU8eisnGomZVrth/mCcohUQuB2qsIzCNfAlvtoi1sh m5UA==
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=jInElTV9f9FE2McSjW3r/VcJozRCOhtLuLq96zwMaT4=; b=qvr6RApGnJGS0hZPDkHwZOGXvMy1CzYL9kRVHO+HejDiAadVjvmdEoFhY/XmyimW1d scflzEtuFSjVRzyb4goMETVC6VGa8HgP0Fbo0IlZM0aeUuDXGR0Ia9CDLR9JKT0SnMoV zPen5BWs8Xz2N3Vldfa4iD3/GwEV2t+Y4U5wVgbkNtL4HPvipVTpNGBqT5L9EnHuTfAX Mi40/420a3VRA5ArEDnAW5+hVeNPo6FVtppNsjsfBQkTjA4YRBrg+rI42qaMExBSn2Ri O8JYiiE0ni0EF54uoa8L5ff/5yX+83nyGWD/OYCeqOMSWWn2Ch194aFMbcBx0rVxMbWQ 6jEw==
X-Gm-Message-State: APjAAAUuPGPh78D9cEztCnc7Z51WTEH+1291LNykDRFrYshosNA+euss aDU/5v651Z8WEuvraQ4+wNI9bw==
X-Google-Smtp-Source: APXvYqykh7oRwpw+Oe8nTB5HF2ua1ZM54QfszwbEsgilNyFjGOSeTTpHqkDNcFBf15xi17qxixLBXQ==
X-Received: by 2002:a9d:37a1:: with SMTP id x30mr17367195otb.45.1570398069760; Sun, 06 Oct 2019 14:41:09 -0700 (PDT)
Received: from [10.10.9.60] (cpe-24-243-152-218.rgv.res.rr.com. [24.243.152.218]) by smtp.gmail.com with ESMTPSA id a9sm3868218otc.75.2019.10.06.14.41.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Oct 2019 14:41:08 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <A5D12082-3D6A-4540-9AFB-2530D4FA6A32@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B4309D4C-D425-49B6-B1E0-0A71AE59A30E"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\))
Date: Sun, 06 Oct 2019 14:41:06 -0700
In-Reply-To: <FBCD2C32-9CBE-4499-A3E9-0FF4991E34DF@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> <60B2C15B-E126-4F86-AA9A-9EB9A6C0EB2D@fugue.com> <FBCD2C32-9CBE-4499-A3E9-0FF4991E34DF@employees.org>
X-Mailer: Apple Mail (2.3600)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/QLFndTQSppWHAM98ZQqejPGARyc>
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: Sun, 06 Oct 2019 21:41:13 -0000

On Oct 6, 2019, at 10:58 AM, Ole Troan <otroan@employees.org> wrote:
> Are you saying there might be gaps in HNCP? Or things we could do to make it more deployable?
> If it's just a matter of running code missing, I'm not sure defining anything else new in the IETF would help that problem.

There are definitely missing features from the protocol that I’d like to add.   But I think the fact that the protocol isn’t deployed on a _single_ commercially available router, and is not really usable on OpenWRT by a non-expert, is an indication that there is substantial remaining work to do.   Operations work is not out of scope for IETF; maybe I should have asked this on v6ops.   We have historically said “not our problem,” but I don’t agree that that’s the right answer.   If HNCP had really convincingly solved the problem, we would not be seeing what we are seeing.

> I know why I haven't implemented HNCP on software I work on... and I also know that there aren't any very realistic alternatives either.

Can you say why that is?

> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing and routers. I.e. what happens at the network layer.

You mean at the “internet layer,” I assume?

> If you are talking about what happens at the often integrated bridge CE devices have, then sure, they could implement RA Guard.
> But having your additional router sending RAs across the homenet might not be a particularly good idea anyway.

Why not?   What would be a better idea?   I don’t mean to say that using RAs in this way is ideal, but what’s the alternative that doesn’t involve the vast complexity of per-host routing?

> Sounds like you need to set it up as a NAT.

I really hope you are just making a funny joke here.   But it’s not very funny.   What I want is something that’s operationally simple, not something with lots of moving parts that have to be kept track of.   NATs in particular suck for any UDP-based protocol.

> I wasn't thinking of doing it exactly like the 6lowpan does it.
> Regardless I don't see why scaling should be problematic, are you planning to have millions of rapidly moving hosts on your shared /64 network?

If you have N devices on a single link on the other side of the router, then when using either RA or a routing protocol, the amount of information you need to propagate to get things working is very small: just a prefix and a router.   If you can’t do that, then the amount of information you need to propagate is at a minimum N units, and possibly K*N, for some not insignificant factor K.

To be clear, the reason I’m concerned about this is that I’ve looked at implementing it on OpenWRT, and it’s at least roughly doubling the complexity of the work required, even if you can depend on using IPv6.   If you have to use IPv4 on one side, then it’s even more complexity.   And it’s utterly stupid complexity—it adds no value over subnetting.   Why add that to the network?

This is why I’m asking people if they have knowledge of what is actually deployed.   I think this is the right place to ask, but if you disagree, I’m open to suggestions.