Hi Thomas[snip] Hi Tim, Until now, I only skimmed over the (large number of) documents.
There is a lot. And most assume too much on the part of the reader. There’s very little that puts the context at all, or presents any top down view.
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.
I agree. I think that it may be possible to take the reference implementations and drop them in with a bit of visibility added over the top. Additionally, iirc, there’s a design principle that would preclude sharing a /128, but to declare a fault. I can see value in the principle: software means that you could do what you wanted, but that doesn’t mean that you should. The approach that I remember is to declare a failure and point at the delegating end. The main reason for not getting a reasonable subnet would be the commercial positioning of the telco. It’s easier to work with them (or their competitors) rather than against.
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.
I was being selfish. My preference would be to use mainstream distros to get the experience with how the protocols work: the masochism of trying to squeeze the code into too small a computer for the sake of a dollar or so of BoM costs makes sense when evolving h/w devices in small increments, but there’s a lot to get better understood here and better instrumentation and visibility of what’s going on is vital in these early stages when the early market would accept higher cost h/w components in any case. Learning faster would drive revenue faster and increase profit more than profitability for early product.
afaict, NM can get in the way of the reference implementations as it has a different view of what the routes and IP addresses should be. I read a (possibly out of date comment) that NM was mangling some router and host parts of the protocols - can dig out more info if it helps. Personally, I think that it’s healthy for computers to be both hosts and routers, but the designs do need to be kept separate (I think that’s why the current protocols could drop in to solve the link sharing usecase that you mention above.
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.
There is going to be a battle to provide decent tooling for the consumer market to ensure that home and adjacent networks are working correctly. In my mind, the best initial products will need very simple UIs (think the big green / red display on the CD pipeline, or the ignition lights for a car). I think that understanding the homenet protocols could be a quick route to getting some of that landgrab. However, it’s not where NM is at the moment. And it may imply significant separation of components to avoid clutter.
otoh, it looks to me like there’s quite a bit of cash that Cisco’s putting into the effort so it may be possible to get some funding for a specific project. I can see possible strains with such an approach ;-)
Is there any mechanism for helping without having to get into the guts of NM? Oh, and we also don't want to abolish IPv6 :)
That would be a sisyphean task. Unfortunately for Linux folk, much IPv4 experience will become redundant suddenly over the next few years.
best,
Thomas
|
