On Mon, 2016-03-21 at 10:23 +0000, Tim Coote wrote:
On 20 Mar 2016, at 10:56, Tim Coote <tim+gnome org coote org> wrote: Is it intended that NetworkManager will conform to /support / exploit the Homenet network name and address assignment and routeing protocols (http://bit.ly/1LyAE7H), either to provide end to end connectivity or to provide a monitoring layer so that the actual state of the network topologies can be understood? Home or small networks seem to be getting quite complex quickly and way beyond what consumers can be expected to understand/configure/troubleshoot/optimise, with one or two ISP’s per person (via mobile phone + wifi connectivity) + an ISP for the premises; and wildly differing network segment performance characteristics and requirements (e.g. media streaming vs home automation). tcWell that went well. fwiw, my question arose from experience with building consumer facing IoT systems where I was seeing a lot of devices inside homes (200+) with multiple routes in (hence many IP addresses per device and challenges on how to route between them) and the definition of the scope of a ‘home’ was too inexact to be useful. NAT was making controlling devices too unpredictably slow (up to 30 seconds to turn on a camera, if at all), CGNAT and other cascading approaches were becoming visible; and the networks were almost instantly too complex not to be automatically configured. Layered on top of this are issues to do with the silly small area network protocols, the need for different layer 2 characteristics (price performance trade-offs for automation vs video streaming), different naming scopes, device and application level security that have to be delivered to low knowledge consumers (to get the scale needed for the economics to work). afaict, Homenet is the *only* initiative that’s taking this challenge seriously and looking at the problem from a sufficiently general point of view. And I think that they’ve made some great strides in a largely design free space, even in just articulating some of the challenges - including some that I think even Bart’s missed - (I recommend RFC 7368). The solution designs looks reasonable to me - although they tend to miss too much context to be widely understood. The implementations actually seem to work, even though they are aimed at Linux based routers (many of the WG members work for vendors of networking hardware) and require some effort to get working on more mainstream distros: in my specific case, I dropped babel on the rh based routers in my house and it did pull out the topology and routing correctly and distribute sane routes beyond the individual subnets. It shouldn’t be necessary for everyone to understand how IPv6 works in detail. We should be moving from the analogous days when motor car drivers had to be able to strip down a carburettor to where the EMS tells the service station what will need attention at the next service. If Bart’s view is typical, I guess that the answer to my original question is ‘No’. That’s a shame as further separation of the various Linux models (embedded, networking, phone, tablet, desktop, server, cloud), is, imo, unhelpful. But at least it gives me a steer.
Hi Tim, Until now, I only skimmed over the (large number of) documents. For example, regaring IPv6 we would like to implement IPv6 connection sharing, maybe some prefix-delegation or v6-NAT (NAT being necessary, if you only get one IPv6 address say from your mobile provider). It's still unclear how to do that in detail (because of the many possibilities). At this point, those RFCs become very relevant. While it's good to have those documents as the overall comprehensive design, it's not clear to me what NetworkManager should do specifically at this point. In general, we definitely want to improve NetworkManager and support standards/RFCs and setups that make sense. So the answer to your question is: yes, NM wants to follow reasonable standards. But we could need some guidance about the details, about what is missing and what to do. Oh, and we also don't want to abolish IPv6 :) best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part