In line Thanks
Sent from my iPhone > On Oct 6, 2019, at 6:46 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > >> On 07-Oct-19 11:34, Mark Smith wrote: >> Perhaps ANIMA is an alternative? It has seemed to me that home networks >> might be just a more specific case of autonomic networks. > > ...for professionally managed networks. So there would be new work to do, if > we wanted to expand the scope. > >> >> 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 > > Which is plastered with warnings that it's not fit for real-life usage, as a > prototype written in Python. > > Brian > >> >> On Mon, 7 Oct 2019, 08:41 Ted Lemon, <mel...@fugue.com >> <mailto:mel...@fugue.com>> wrote: >> >> On Oct 6, 2019, at 10:58 AM, Ole Troan <otr...@employees.org >> <mailto: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. >> [Gyan] Good 6man question related to polling of what as far has home net HNCP RFC 7788 has been deployed. Reading through both RFC 7788 and 7084 there does seem to be gaps and clarity as far as auto provisioning of IPv6. I think both documents really need to be updated to be helpful and also have concrete solution as to how the IPv6 auto provisioning is going to work. For IPv4 in general across the board all broadband routers openWrt or otherwise pnp setup have a dhcp wan IP and LAN side is RFC 1918 192.xx and nat overload is done from inside to outside. Pretty basic and it works well. For IPv6 we have the option of hiding the internal space doing a ULA on the lan side but only caveat that would require NAT64 DNS64 as well added complexity but that would work. The other option is PD on the wan side get a GUA /56 from the SP allocated dynamically to the home broadband router and then a /64 is doled our to lan interface via PD and all hosts in the home network sit on the GUA /64 and get a slaac address. The later I thin is the easiest as no nat requirement. You could build in some python or ansible automation scripts to build out the pnp config to make it cookie cutter for any deployment so the routers would ship with the script and get auto provisioned. CIsco has NSO product for programmability for enterprises and service providers for auto provisioning day 1 configurations and deployment which would be perfect for this use case for broadband home net deployments. If everyone agrees that those RFCs need to be updated for home net per what I mentioned I could take the lead on that for 6man. Gyan >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org <mailto: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 >> > > -------------------------------------------------------------------- > 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
