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

Mark Smith <markzzzsmith@gmail.com> Sun, 06 October 2019 22:34 UTC

Return-Path: <markzzzsmith@gmail.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 15FC0120125; Sun, 6 Oct 2019 15:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zl1Nl88JXGul; Sun, 6 Oct 2019 15:34:28 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 E69AB1200D8; Sun, 6 Oct 2019 15:34:27 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id 83so10121328oii.1; Sun, 06 Oct 2019 15:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1aFaPPKJPnON2oYufqB2BHrp8Ivycd0N0aVyuD3V3TU=; b=fXXDjjB5v9UE578MvKCNlzVcECtyrwaxDhu9Mh91W7j0qz5x7O7o1jHD0znqkCj64R bgkkbBfdo9GcT3nLw1d3wHsnu1xbpcshCtnqH4yHXO9VhBz+GECgACHt6XHfrKMCeiR8 FNOkCmnmPqz7BTqjL8ymWXHvUANalobwvYfPaJJETFDEuHNhQyx1Y1c7E9U5+MYGReKW suvBd68Fvalv7HHz2ap+MhJi07D/I3xfPF6aQIdfb4WULjH8A1HNt2UBeEPCh1zTggBP CjuEiyi8UAxquxOgycaZfoDmnCsUyU6BcBPMf+xSh2hqll8A4e5sFR29B3dmFdxy/LKp il+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1aFaPPKJPnON2oYufqB2BHrp8Ivycd0N0aVyuD3V3TU=; b=gZ9iNDTNkblKe3hG5ug+GJU2bQoblVDXXbmRaUHyZ/NPXXnWl58dLVDWUhUBr35LzB B0gOUbZBY3vrQI+z8B5x+LEX9quO7dhbElBuf7C2wyS+A0FfaZuLb1sstrm2rpC142fx zDL06BN2fwgtqUxLQVzRQbrsNmNqV3lDo7tfjt7FNR6mMhTj9qLcvsqYj0dClYii3/3F 81URyYS0RlVpEQ2XwAFLvmMUB8ySPRXiULbXKjHEQh1p1dMZziZtfz8580kdPaMaWRq5 FFoMd+Tdol8HXJmj/fE2533GYMz1ApLXsoZ3KdjCbF56DkRSa907i17djbVCrCNEUbuG fB6g==
X-Gm-Message-State: APjAAAUIabv6PpilKPYUHBmWqbGWv7TfugXqzX+ZJFcTBOiSwU4AsiE1 aBqhg2rDHFJ4MmEZyU++xdadAwbkB9IdO2In6yU=
X-Google-Smtp-Source: APXvYqyHVBWPWtoscaMOlrY4yAwCqL7okMa8dK2vml8Uw5fqoROOwzRYYkIbbS2CllyPJI+r3LbHOmPpL50ux7HT0O4=
X-Received: by 2002:aca:4e87:: with SMTP id c129mr15991636oib.7.1570401267240; Sun, 06 Oct 2019 15:34:27 -0700 (PDT)
MIME-Version: 1.0
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> <A5D12082-3D6A-4540-9AFB-2530D4FA6A32@fugue.com>
In-Reply-To: <A5D12082-3D6A-4540-9AFB-2530D4FA6A32@fugue.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 7 Oct 2019 09:34:14 +1100
Message-ID: <CAO42Z2yOdxkfMWJEBWK-J=UWPQ5CyPJ3j0b+HarwXWV4GkK87g@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Ole Troan <otroan@employees.org>, Markus Stenberg <homenet@ietf.org>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b053aa0594458903"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/4a4Bcwn-Ha9LNup8CQuAttPeqTQ>
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 22:34:30 -0000

Perhaps ANIMA is an alternative? It has seemed to me that home networks
might be just a more specific case of autonomic networks.

For example, they've been defining a Generic Autonomic Signalling Protocol
(GRASP).

https://tools.ietf.org/wg/anima/

Brian Carpenter has been working on an implementation.

https://github.com/becarpenter/graspy

On Mon, 7 Oct 2019, 08:41 Ted Lemon, <mellon@fugue.com> wrote:

> 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.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>