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, <mel...@fugue.com> wrote: > On Oct 6, 2019, at 10:58 AM, Ole Troan <otr...@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 > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
