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

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
> --------------------------------------------------------------------
>