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

Mark Smith <> Sun, 06 October 2019 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15FC0120125; Sun, 6 Oct 2019 15:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.498
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zl1Nl88JXGul; Sun, 6 Oct 2019 15:34:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E69AB1200D8; Sun, 6 Oct 2019 15:34:27 -0700 (PDT)
Received: by with SMTP id 83so10121328oii.1; Sun, 06 Oct 2019 15:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Mon, 7 Oct 2019 09:34:14 +1100
Message-ID: <>
To: Ted Lemon <>
Cc: Ole Troan <>, Markus Stenberg <>, 6MAN <>
Content-Type: multipart/alternative; boundary="000000000000b053aa0594458903"
Archived-At: <>
Subject: Re: [homenet] Support for RFC 7084 on shipping devices...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

Brian Carpenter has been working on an implementation.

On Mon, 7 Oct 2019, 08:41 Ted Lemon, <> wrote:

> On Oct 6, 2019, at 10:58 AM, Ole Troan <> 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
> Administrative Requests:
> --------------------------------------------------------------------