GNOME Bugzilla – Bug 593815
[RFE] sharing: IPv6 connection sharing (ipv6.method=shared)
Last modified: 2016-11-09 17:09:31 UTC
The IPv6 tab in the connection editor does not support "Shared" like the IPv4 tab does. This ought to be simpler than the IPv4 case, since you don't need to create a new subnet and run NAT and DHCP and all that. But it's a little more complicated than just copying packets back and forth because you need to make the neighbor discovery work right, etc. I haven't figured this out in detail. We might need to run radvd.
You do need to have a subnet routed to you, though. In IPv4, N-M uses NAT, which means upstream routers do not need to be configured. In IPv6, because of the absence of NAT, there is no way to avoid configuring upstream routers to configure this additional subnet to you.
Right, this probably requires DHCP-PD (Prefix Delegation). The upstream router would have to support DHCP-PD, and NetworkManager would have to have a DHCP-PD client.
That certainly sounds like the way to go, especially when compared to something like RIPng or OSPFv4. Unfortunately, there no free DHCPv6-PD server implementations around that I’m aware of. Dibbler and WIDE-DHCPv6 support DHCPv6-PD as a consumer, though. Certainly no consumer hardware yet (and probably never will) support any form of serving PD, despite supporting PD as a consumer. However, some ISPs (like Internode, my ISP) can and do serve DHCPv6-PD, so I presume they have specialised hardware to do the job. With the absence of good DHCPv6-PD server implementations out there, it’s going to be extraordinarily difficult to develop this feature. One interesting thing about this is that it requires N-M to interact with an interface other than the one you set the sharing mode on. Sometimes, you might have two external interfaces, one of which is capable of receiving DHCPv6-PD, and one which is not. Or both could be capable — which to choose from? I should also note that there are two very different, and yet technically similar use cases here: (1) receiving DHCPv6-PD directly from your ISP via a DSL connection (2) sharing a non-PPPoE (i.e. ethernet or wireless) connection to clients on another wired/wireless interface Use case (2) is what I addressed with regards to no free DHCPv6-PD server implementations being out that I’m aware of. However, if we were to dismiss use case (2), then use case (1) *can* actually be solved with existing software, but does require the developer to have access to an ISP that does serve DHCPv6-PD. And once we also dismiss use case (2) as being infeasible from the perspective of routing, given that it addresses connecting between two ethernet interfaces, there is a real possibility of solving this a different way — bridging is what I had in mind. Along with normal kernel bridging, which will have its own challenges, there is bittwistb, which is a user-level pcap-based ethernet bridge. I have no idea whether it works with wireless or not, but this is what I feel is not such a bad alternative.
ISC DHCP 4.1.0 and later supports DHCPv6-PD. 4.2.0 is the latest production release. https://www.isc.org/software/dhcp/new-features http://ftp.isc.org/isc/dhcp/dhcp-4.1.1-P1-RELNOTES https://www.isc.org/files/release-notes/DHCP4.2.0.txt
Confirming. We could use DHCP client and DHCP server for *managed* connection sharing. But this is not really the same as IPv4 connection sharing through NAT.
If the upstream network is an ethernet network doing SLAAC, then we can just bridge the inner network to the upstream network and we're done. That's what I was suggesting in comment 0 (except I didn't realize all of the restrictions on it). Connection sharing is a feature you are most likely to use on networks that you have absolutely no control over, so requiring support for DHCPv6-PD doesn't seem like a good plan (unless it became very widely supported by routers). NATv6 is probably the way to go here. (Ugh!)
No, please no NAT66. DHCPv6-PD is the supported the solution moving forward. The IETF v6ops working group has published RFC 6204 on required IPv6 CPE router functionality: http://tools.ietf.org/html/rfc6204 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation requesting router behavior as specified in [RFC3633] (IA_PD option).
(In reply to comment #7) > WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation > requesting router behavior as specified in [RFC3633] (IA_PD > option). That's a WAN-side requirement; the router must be able to use PD to request prefixes from its upstream. There is no mention of responding to PD requests from the LAN side. > No, please no NAT66. My point was that we don't get to choose. If we're going to implement the feature, we have to implement it in a way that will actually work on random hotel/airport/3G/WiMAX/etc networks that in all likelihood don't want you doing that anyway and so aren't going to be configured in ways that would make it simple and pretty.
From the discussion on IRC, we have the following possibilities (you can add yours): 1) DHCP-PD The standard. This is good for the specific use case of acquiring a network prefix in a network that supports it. You can't expect networks to support DHCP-PD. 2) NDP Magic It is possible to fake the whole processing of RS, RA, ND, NA and proxy everything to make it work. 3) Use bridging instead NM will hopefully support bridging soon. This method would work in most cases but not all. But because it's on the link level, it will have to be used for both IPv4 and IPv6. 4) IPv6 masquerade Religion aside. IPv6 masquerade is the direct application of IPv4 masquerade so it may seem this method is usable. But there is one big difference. While IPv4 masquerade has become a majority, you cannot expect IPv6 masquerade even to become a large minority. That means software won't be well tested for IPv6 masquerade. You could just use proxy then. 5) Teredo-like tunneling with relays No comment.
In 3GPP mobile networks, the host will get an entire /64 routed to it. This /64 (or a part of it) may very well be assigned to internal "LAN" interface and be shared. There's a draft that describes the model already: http://tools.ietf.org/html/draft-byrne-v6ops-64share-03
NM bugzilla reorganization. Sorry for the bug spam.
I have just contributed a patch which might go some way to solving this problem, although not universally. see https://bugzilla.redhat.com/show_bug.cgi?id=626514 The patch changes the dhclient-script such that when it receives a prefix from the WAN interface, it can configure the LAN interfaces with /64 subnets from the delegated prefix and then set up the remainder of the prefix for further redelegation downstream. radvd may then be used to advertise the subnets on the LAN interfaces. I calculate that a /48 will allow 5 levels of (re)delegation. A problem still remains which is the routing of the delegated prefixes. DHCP servers like ISC do not see routing to be a part of their job. This is especially true in large networks with many DHCP relays. They expect a routing protocol such as ospfv3 or ripng to do this. This would appear to be at odds with RFC6204 mentioned above which states WPD-8: By default, an IPv6 CE router MUST NOT initiate any dynamic routing protocol on its WAN interface.
(In reply to comment #10) > In 3GPP mobile networks, the host will get an entire /64 routed to it. This /64 > (or a part of it) may very well be assigned to internal "LAN" interface and be > shared. > > There's a draft that describes the model already: > > http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 Later versions of radvd have a config statement Base6Interface which allows the address on an interface to be used as a base to configure prefixes on other interfaces.
Now that Comcast has rolled-out IPv6 networking in the US, this bug will effect many more people. As it is now, effectively, NM fails to fully configure an IPv6 interface, by not accepting the available Prefix Delegation, albeit, in the sense of "sharing" the interface. Comcast will provide a /60 prefix. RFC6204 also has 4.2. WAN-Side Configuration Address assignment requirements: WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client behavior. WAA-6: If the IPv6 CE router receives a Router Advertisement message (described in [RFC4861]) with the M flag set to 1, the IPv6 CE router MUST do DHCPv6 address assignment (request an IA_NA option). WAA-8: If the IPv6 CE router does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, then it MUST create global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network interfaces. 4.3. LAN-Side Configuration LAN requirements: L-2: The IPv6 CE router MUST assign a separate /64 from its delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) for each of its LAN interfaces. Regardless of if the prefix is a /60 or a /64, or if the address space is unmanaged, NM "should do the right thing". I don't get that Prefix Delegation is "optional". If the up-stream router sets the "managed" flag and assigns a subnet prefix for the LAN, then that Prefix Delegation gets used, or there is no "LAN". And then, either NM "makes magic happen", or we're back to doing things manually, and no thanks to NM. So, it would be nice if, after four years of this bug report being open, the priority of this bug got raised.
(In reply to comment #14) > Now that Comcast has rolled-out IPv6 networking in the US, this bug will effect > many more people. Only those who want to use a machine NetworkManager as their router. > As it is now, Are you referring to the current master (or release), or to David's patches? > effectively, NM fails to fully configure an IPv6 interface, > by not accepting the available Prefix Delegation, That claim is not backed by the standards. A host connected to the network is not expected to accept prefix delegations. > Comcast will provide a /60 prefix. Won't they also provide IPv6 CE routers for their customers? > Regardless of if the prefix is a /60 or a /64, or if the address space is > unmanaged, NM "should do the right thing". To my knowledge, nobody claims that NetworkManager is a CE router implementation. Also, to my knowledge, this bug report was about connection sharing and not specifically about DHCPv6 PD and even less about CE router requirements compliance. > So, it would be nice if, after four years of this bug report being open, the > priority of this bug got raised. Unfortunately, even if you really wanted to use NetworkManager as a CE router, a raised priority won't provide the patches for you. It might be nice to revisit David's patches, though, if someone has time for that.
(In reply to comment #15) > (In reply to comment #14) > > Now that Comcast has rolled-out IPv6 networking in the US, > > this bug will affect many more people. > > Only those who want to use a machine NetworkManager as their router. I have libvirt on my laptop and it has a number of virtual networks. The only way to have IPv6 in my Virtual Machine Manager is static. I would like to use DHCPv6 PD to get routable prefix on those networks as I move around from site to site with my laptop. I can convince Network Managers DSL Connection to do IPv6 negotiation by slipping the "ipv6 ," into /etc/ppp/options I can of course use the adsl-setup (rp-pppoe) to create the link, instead of NetworkManager. The main difference I have found is that NetworkManager does not properly call /etc/ppp/ipv6-down when the link comes down, whereas the rp-pppoe does do that. > > > As it is now, > > Are you referring to the current master (or release), or to David's patches? > > > effectively, NM fails to fully configure an IPv6 interface, > > by not accepting the available Prefix Delegation, > If you insert the "ipv6 ," into /etc/ppp/options, then you do get a PPP link that supports IPv6. You can then run dhclient and have it add the prefix onto your internal interfaces with my patches. Of course it would be nice if NetworkManager could do this for us. > That claim is not backed by the standards. A host connected to the network is > not expected to accept prefix delegations. Correct, a host (or more correctly a router) must request a delegated prefix. > > > Comcast will provide a /60 prefix. > > Won't they also provide IPv6 CE routers for their customers? > > > Regardless of if the prefix is a /60 or a /64, or if the address space is > > unmanaged, NM "should do the right thing". > > To my knowledge, nobody claims that NetworkManager is a CE router > implementation. Also, to my knowledge, this bug report was about connection > sharing and not specifically about DHCPv6 PD and even less about CE router > requirements compliance. My example above of Virtual Machines on a Host does require something eg NetworkManager to act as a router inside the virtual environment. This is an area I am currently investigating, as the virtual environment use dnsmasq to provide DHCPv4 serving and NAT. All my previous testing was done with RADVD for router advertisements on inside LAN. Recent enhancements to dnsmasq enable it to advertise an IPv6 prefix. Apparently dnsmasq also does some nice things integrating with DNS, which make it a more favourable option than using radvd. > > > So, it would be nice if, after four years of this bug report being open, the > > priority of this bug got raised. > > Unfortunately, even if you really wanted to use NetworkManager as a CE router, > a raised priority won't provide the patches for you. It might be nice to > revisit David's patches, though, if someone has time for that. I think what has to happen, 1. find out why /etc/ppp/ipv6-down is not called when using NM, and fix it. This would IMHO make NetworkManager usable with DSL. 2. The connection sharing option should not be in the IPv4 protocol, but rather moved to be a more general option, that happens to work on the enabled protocols. 3. Give some thought to the Cable Modem scenario where PPP is not used. There are problems with this because cable modem providers like to route the delegated prefix to a public address. eg request ia_pd and ia_na, and the ia_pd block is routed via the ia_na address. PS: I have a new version of the dhclient-script and ipv6-up that plays better with NM.
(In reply to comment #9) > From the discussion on IRC, we have the following possibilities (you can add > yours): > > 1) DHCP-PD > 2) NDP Magic > 3) Use bridging instead > 4) IPv6 masquerade > 5) Teredo-like tunneling with relays 6) OSPFv3 Auto Configure http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-autoconfig-05 OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring.
> Only those who want to use a machine NetworkManager as their router. Quite. > Are you referring to the current master (or release), or to David's patches? Ha! The "current release", here, Arch version 0.9.8.8-1. > Won't they also provide IPv6 CE routers for their customers? Not that I am aware, and assuming you want to pay continually for an "equipment lease". Currently, for IPv6, Comcast recommends "modem only" boxes for IPv6 - http://mydeviceinfo.comcast.net/ - and a separate set of third-party routers - http://mydeviceinfo.comcast.net/?homegateway - two of which have some "wrt" support - the Asus RT-N66U/RT-N66R and the D-Link DIR-825. So yes, it is possible to rely upon some external hardware for routing, instead of using NM. > To my knowledge, nobody claims that NetworkManager is a CE router > implementation. We expect so much... > Also, to my knowledge, this bug report was about connection > sharing and not specifically about DHCPv6 PD and even less about CE router > requirements compliance. It seems to me, reading the RFC, that "sharing" necessarily requires DHCPv6 PD and implies CE router compliance. This bug report is about _IPv6_ connection sharing. IPv6 is the point of it. > a raised priority won't provide the patches for you. Ha! Fair enough. But I can plead, and I can dream... Now that I finally have access to native IPv6, I'm on the learning curve, and a bit surprised that this seems to still be an open problem. I have been finding references to "dnsmasq" and "wide-dhcpv6" for IPv6, but the traditional DHCP servers just don't have full IPv6 functionality. In all fairness, RFC6204 is dated April, 2011, and this bug was opened in 2009. It is all quite new. Basic Requirements for IPv6 Customer Edge Routers Abstract This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. Nonetheless, even "kicking and screaming", we will all transition to IPv6 routing, and better to have equipment that plays nicely together. > It might be nice to revisit David's patches, though, if someone has time for > that. I was just looking over his link, https://bugzilla.redhat.com/show_bug.cgi?id=626514 and see that there has been some activity this month. I am casting-about on Google, and can add a comment when I finally come up with something to route IPv6.
(In reply to comment #18) > Ha! Fair enough. But I can plead, and I can dream... > > Now that I finally have access to native IPv6, I'm on the learning curve, and a > bit surprised that this seems to still be an open problem. I have been finding > references to "dnsmasq" and "wide-dhcpv6" for IPv6, but the traditional DHCP > servers just don't have full IPv6 functionality. > Review Request: wide-dhcpv6 - DHCPv6 Prefix Delegation client that works on PPP https://bugzilla.redhat.com/show_bug.cgi?id=956147 https://github.com/bevhost/wide-dhcpv6
(In reply to comment #18) > It seems to me, reading the RFC, that "sharing" necessarily requires DHCPv6 PD > and implies CE router compliance. Nope. There are many ways to do network sharing or routing. This bug report was originally about adding a matching functionality to IPv4 NAT based sharing, which unfortunately cannot be provided by DHCPv6 PD, which has a specific requirement of prefix delegation set up in the network. I agree that right now the DHCPv6 PD based sharing method would be useful for a good number of users, though. > Now that I finally have access to native IPv6, I'm on the learning curve, and a > bit surprised that this seems to still be an open problem. I've been on native IPv6 since I think 2009. There are still many issues that are *much* more serious than connection sharing with NetworkManager, to be honest. > I have been finding > references to "dnsmasq" and "wide-dhcpv6" for IPv6, but the traditional DHCP > servers just don't have full IPv6 functionality. If you have reference setups that work without NetworkManager, please include links to those in the bug report. It helps a lot. > In all fairness, RFC6204 is dated April, 2011, and this bug was opened in 2009. That doesn't mean much. IPv6 is there since 1996 and at that time I didn't yet have an internet connection at home. And for another ~10 years I had an IPv4-only one. The years are a nice historical remark but not valid arguments for this bug report. > Basic Requirements for IPv6 Customer Edge Routers That's not valid either as there's AFAIK no mention of Customer Edge Routers in any NetworkManager release notes. I suspect you are trying to present this *feature request* as a bug (which it certainly isn't) in hope that it will make someone work on it. Please avoid doing that. > Nonetheless, even "kicking and screaming", we will all transition to IPv6 > routing, and better to have equipment that plays nicely together. +1 With the information about Comcast, this feature (using DHCPv6 PD) would indeed be now interesting for a larger group of people than before. But we should also think about internet connectivity sharing with mobile devices in networks that don't explicitly support that (i.e. don't send out DHCPv6 PDs).
> I've been on native IPv6 since I think 2009. There are still many issues that > are *much* more serious than connection sharing with NetworkManager, to be > honest. Sorry, I'm so new to IPv6 that I don't know what those issues would be. I think it useful to articulate a list of issues here, a "things to do". > The years are a nice historical remark but not valid arguments > for this bug report. Trolling Google, reading forum posts - many of which fail to appreciate the difference between the words "depreciated" and "deprecated" - and reading RFCs, that's not what I get. IPv6 routing looks like a moving target to me, or at least appears that way to many people, as their understanding of IPv6 routing evolves. This is new stuff, in practical terms, since native IPv6 networks have not been a commodity product until recently. Before that, it was all an academic exercise. > I suspect you are trying to present this *feature request* as a bug (which it > certainly isn't) in hope that it will make someone work on it. Please avoid > doing that. "Bug"/"Feature" - yeah, I'm starting to see that, so that's true. Ha! Though, it's not _my_ "bug" report. Ha! Either way, it's on my priority list, at the moment. I'm sure other people have solved IPv6 connection sharing and other IPv6 issues, but the solutions are not obvious or simple enough to have migrated easily into NM - yet. NM is shocking when it "just works" correctly, and a bit of a "crutch" when I don't know what's going-on in the background. Many people probably don't want to know what makes NM work though, as long as it "just works". Still, when NM does _not_ "just work", I hesitate to let it muck-about with my network configuration at all - all or nothing. And that's saying nothing about NM interactions with systemd! I'm still exploring what "should" be going on in the background, automatically setting-up an IPv6 router with a delegated subnet address space on a linux box. Here is my "short list" so far. There is an article, at PennState, last edited 2013 August 27, referencing different DHCPv6 software, "This is the home page for the IPv6 space. It is a resource for IPv6 deployment at Penn State." https://wikispaces.psu.edu/display/ipv6/Home "DHCPv6" https://wikispaces.psu.edu/display/ipv6/DHCPv6 The list includes ISC DHCP 4.1, Dibbler, and WIDE DHCP6s, among some other proprietary or obsolete programs, and focusing mostly on WIDE-DHCPv6. ISC DHCP is currently at version 4.2.5-P1, released 2013 January. Dibbler is currently at 1.0.0 Release Candidate 1, released 2013 July 30. WIDE-DHCPv6 at SourceForge was last modified 2008 June 15. While WIDE-DHCPv6 seems to be one of the longest available DHCPv6 solutions, started in 1998 or so, I hesitate to rely upon something that has not been updated in five years, especially considering that some of the pertinent RFCs are newer than that. WIDE-DHCPv6 also seems to have no online documentation. Still, OpenWRT uses it. ISC DHCP is not know for it's documentation - or rather, is know for its lack of documentation. Dibbler has a chatty web site, a user's guide, a developer's guide, and seems to be in active development. Dibbler sources are written in C/C++. There is a Dibbler Feature List, http://klub.com.pl/dhcpv6/#FEATURE SourceForge has a link to the GPLv3/commercial dual licensed Java based "Jagornet DHCPv6", which currently has a version 2.0 Release Candidate, dated 2013 September 08. Jagornet also has its comparison matrix, with ISC, WIDE, and Dibbler, http://www.jagornet.com/products/dhcpv6-server/competitive-matrix though this is probably not current against the 2013 releases. For instance, Dibbler claims to now have Dynamic DNS for DHCPv6/v4 support - RFC 4703, RFC 4704 - though Jagornet does not show this. I found this amusing, from ISC DHCP, https://www.isc.org/blogs/isc-dhcp-and-ipv6-the-dhcpv6-story/ ISC was approached by Comcast in 2006 to implement DHCPv6, as they were looking for an open source DHCPv6 server to test IPv6 functionality on DOCSIS 3.0 modems. ISC released ISC DHCP 4.0 in December 2007, which included a DHCPv6 server, client, and relay. ISC continues to release new versions of ISC DHCP, which include additional functionality and other improvements to DHCPv6. ISC is actively participating in DHCP and DHCPv6 standardization efforts within the IETF. ISC DHCP is often the first protocol implementation that offers new capabilities and is often used as a reference implementation by other vendors. Presumably, then, ISC DHCPv6 is going to work on the Comcast network. Ha! Dibbler, on the web site, seems to be a one-man operation, which suggests that, if NM were to use Dibbler, there might be some very personalized attention and support. And yet, looking at the Linkedin page for Tomasz Mrugalski, the Dibbler developer, we see http://www.linkedin.com/in/tomaszmrugalski DHC co-chair Internet Engineering Task Force March 2013 – Present (9 months) I'm DHC WG (Dynamic Host Configuration Working Group) co-chair at IETF. I'm also still an active participant of the WG and several other related WGs that happen to do DHCP related work. Senior Software Engineer Internet Systems Consortium Nonprofit; 51-200 employees; Internet industry February 2011 – Present (2 years 10 months) My primary responsibilities will be to develop ISC DHCP implementation, resolve submitted bugs, design and implement new features. I will also continue to participate in standards development, mainly focused on DHCPv6. This work will be conducted within IETF. So, it's not like Tomasz is some "lone wolf". Instead, he actually works on ISC DHCPv6 and sits on the DHC Working Group! But, I have to wonder, then, why does he also develop Dibbler? I've sent an email... Well, now I have to try-out some of these DHCPv6 implementations and see what is what.
(In reply to comment #21) > Sorry, I'm so new to IPv6 that I don't know what those issues would be. I > think it useful to articulate a list of issues here, a "things to do". It's a huge number of unrelated things, not all of them could be solved by NetworkManager. Some of those are written at the following page, many others aren't... https://fedoraproject.org/wiki/Networking/Bugs > This is new stuff, in practical terms, since native IPv6 networks > have not been a commodity product until recently. Before that, it was all an > academic exercise. Exactly. > Either way, it's on my priority list, at the moment. Good to know :). > The list includes ISC DHCP 4.1, Dibbler, and WIDE DHCP6s, among some other > proprietary or obsolete programs, and focusing mostly on WIDE-DHCPv6. Both connman and the new systemd-networkd are going to use a common client DHCP library. That might be an option for NetworkManager as well, per bug #711635. If that happens, that would render all talks about ISC dhclient, dibbler and wide-dhcp purely academic. > WIDE-DHCPv6 also seems to have no online documentation. > Still, OpenWRT uses it. OpenWRT doesn't seem to be a good source of information, here. > ISC DHCP is not know for it's documentation - or rather, is know for its lack > of documentation. I think the documentation of ISC DHCP is pretty good and it's the current solution used by NetworkManager anyway. > http://www.jagornet.com/products/dhcpv6-server/competitive-matrix This resource seems to provide just one useless table. > Well, now I have to try-out some of these DHCPv6 implementations and see what > is what. That's all nice, I just wonder how writing your story to the bugzilla helps the development (which is the sole reason for the bugzilla to exist). Maybe if you could use more links, less citations and less story telling.
ISC DHCP 4.3 will be coming out soon and has enhanced IPv6 support, but I'm not sure how much of that enhancement is on the client side of things.
> That's all nice, I just wonder how writing your story to the bugzilla helps > the development (which is the sole reason for the bugzilla to exist). Maybe > if you could use more links, less citations and less story telling. For me, context is important. Maybe you think you already know of all the possible options and solutions, but this issue has been open for four years, and I am not hearing about so much as a definite plan. It's hardly like IPv6 was a sudden surprise. So, a little perspective seems in order. > This resource seems to provide just one useless table. Yes - that is the point. _Nobody_ has a plan. And that article is just recently updated. > Both connman and the new systemd-networkd are going to use a common client > DHCP library. That might be an option for NetworkManager as well, per bug > #711635. If that happens, that would render all talks about ISC dhclient, > dibbler and wide-dhcp purely academic. Along those lines, Tomasz had this to say: ... I'm lead developer for Kea, a new DHCP implementation that ISC is working on. ... there's an alternative that you may consider. Take a look at Kea: http://kea.isc.org. For Dibbler, I'm spending like 3-4 hours a week, often much less. On Kea, I'm working 40-50 hours a week and there are 3 other developers working on it full time. Kea has a library called libdhcp++. It is what the name states: a library for sending/receiving DHCP (both v4 and v6) packets, interface management, parsing incoming packets, sending responses, parsing/creating options etc. It is written in pure C++ and there are very simple dependencies (only boost headers) for that library. What you'd need is a simple logic layer on top of it. This is something that ISC has on our roadmap, but is currently very distant. If you think this is something appealing, I could point you to people in ISC who may be interested in this project. "This project" referring to NM automatic network configuration and Dibbler, about which I also asked. Tomasz calls Dibbler his "hobby project", but also said that "Both ISC DHCP and Dibbler are much more capable than that", referring to some automatic network sharing. I suppose one obvious purpose to having a DHCPv6 "hobby project", when you are setting DHCP standards and co-chair the DHC Working Group, is to better appreciate the practical issues involved in making it all actually work in the field. From the Kea web site, KEA DHCP Server KEA is a new open source DHCPv4/DHCPv6 server being developed by Internet Systems Consortium. The objective of this project is to provide a very high-performance, extensible DHCP server engine for use by enterprises and service providers either as is or with extensions and modifications. DHCP Standardization efforts The lead developer on KEA is co-chair of the Dynamic Host Configuration working group in the IETF. We are committed to providing a standards-compliant implementation and are closely tracking developments in this working group and evaluating them for inclusion in KEA. Current Status Status Update #1, November 2013 The server is usable today in a non-critical application or test environment. The code is posted and is freely available for download and use today. The following major features are working. DHCPv4 and DHCPv6 support: assigning, renewing and releasing leases for IPv4 or IPv6 clients either directly or via a relay. Most DHCPv4 and DHCPv6 options. Incomplete support for DOCSIS3.0. It is possible to define custom options. IPv6 prefix delegation SQL back-end support Applications api is available and documented Linux operating system support. Support for other UNIX systems is planned but not yet available. Run-time configuration and control, allowing system settings to be changed without restarting the system, taking effect instantly. ... Collaboration We are looking for a small group (up to 6 total) of key collaborators at this point. Contact us via Kea mailing list if you think you might be interested in working on KEA and sharing that work with the community. The primary things we need are: Test coverage in different environments, with a variety of clients Applications based on the Kea API, to validate the API and to demonstrate the potential for DHCP applications. So then, perhaps connman and systemd-networkd and NM could use the more heavily developed Kea libdhcp++, along with having the ear of the library developers, and devote their attention to building the logic to go on top of this. What do you think of that? And could you say some more about the possible future relationship of NM and systemd-networkd? Does systemd-networkd replaces NM?
(In reply to comment #24) > And could you say some more about the possible future relationship of NM and > systemd-networkd? Does systemd-networkd replaces NM? I don't have a crystal ball, unfortunately.
I've come across this bug after indications that Fedora (currently my server choice) and NetworkManager seem a ways from implementing prefix delegation or supporting wide-dhcpv6. For reference, I solved part of the problem by writing a patch to dhclient so that it can retrieve both IA_NA and IA_PD simultaneously (same process, same port). See: https://bugzilla.redhat.com/show_bug.cgi?id=836702 However, the redhat maintainers aren't sure my approach is something they want to support as a patch, and my submission to upstream has gone unanswered (ISC-Bug #30090) I'm also looking at the problem of supplying a prefix size "hint" on dhclient (seems to be required on Comcast to get a /60 w/o tech support getting involved)... looks like I may need to add a new option to dhclient (hacking the lease doesn't work), see: https://bugzilla.redhat.com/show_bug.cgi?id=876791 In the meantime, I created some scripts that hook into NM's dispatcher system that spawns dhclient to acquire a prefix, and assigns an address to the WAN and prefix to the LAN... if there's interest, I could post them someplace (although they aren't a real solution for shipping with NM, but they do include DDNS updates :). I could take a look at integrating prefix delegation into NM, but it would require new configuration options, and so probably should be discussed with the NM maintainers to flesh out how it could be best done.
(In reply to comment #26) > I've come across this bug after indications that Fedora (currently my server > choice) and NetworkManager seem a ways from implementing prefix delegation or > supporting wide-dhcpv6. I'm not sure about the relevancy of wide-dhcpv6. I would rather discuss with you a broader view of a solution. I can try to help you from the Fedora and Red Hat side (and partially also for other distributions), just post me links to the relevant resources and/or contact me on IRC freenode. I'm most often dwelling at #nm. > For reference, I solved part of the problem by writing a patch to dhclient so > that it can retrieve both IA_NA and IA_PD simultaneously (same process, same > port). See: > > https://bugzilla.redhat.com/show_bug.cgi?id=836702 That's certainly a nice start but AFAIK you're changing the dhclient's action script which is not used with most other tools including NetworkManager. Another reason to look for broader consequences. For example, you might end up with a patch that doesn't help your NetworkManager enabled installation at all. > However, the redhat maintainers aren't sure my approach is something they want > to support as a patch, and my submission to upstream has gone unanswered > (ISC-Bug #30090) While it's worth trying, don't expect the ISC upstream to respond, it doesn't happen very often. > I'm also looking at the problem of supplying a prefix size "hint" on dhclient > (seems to be required on Comcast to get a /60 w/o tech support getting > involved)... looks like I may need to add a new option to dhclient (hacking the > lease doesn't work), see: > > https://bugzilla.redhat.com/show_bug.cgi?id=876791 Sounds reasonable. > In the meantime, I created some scripts that hook into NM's dispatcher system > that spawns dhclient to acquire a prefix, and assigns an address to the WAN and > prefix to the LAN... Sounds interesting. > if there's interest, I could post them someplace (although > they aren't a real solution for shipping with NM, but they do include DDNS > updates :). Please attach them. > I could take a look at integrating prefix delegation into NM, but it would > require new configuration options, and so probably should be discussed with the > NM maintainers to flesh out how it could be best done. It certainly should but that doesn't we can't have patches to test before the NM maintainers decide. I would be more than happy to perform some testing on my testing network at home. Also, please remember that dhclient and wide-dhcpv6 aren't the only possible implementations and some people (including me) would like to see a library solution and one is emerging from the connman project, see: https://bugzilla.gnome.org/show_bug.cgi?id=711635 Any chance you would be at FOSDEM?
(In reply to comment #27) > (In reply to comment #26) > > For reference, I solved part of the problem by writing a patch to dhclient so > > that it can retrieve both IA_NA and IA_PD simultaneously (same process, same > > port). See: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=836702 > > That's certainly a nice start but AFAIK you're changing the dhclient's action > script which is not used with most other tools including NetworkManager. > Another reason to look for broader consequences. For example, you might end up > with a patch that doesn't help your NetworkManager enabled installation at all. Actually, just noticed that my patch in 836702 doesn't show the fixes in the "diff" view (I posted a patch to the SRPM, and it doesn't show the patch inside the patch). You can see the "real" patch if you download the attachment though. I'll have to repost it... The trick here is to get dhclient to supply the correct lease to NM, and then we can enhance NM to do something interesting with it automatically (rather than just requiring custom dispatcher scripts). This goes to the heart of "click share connection" and it just works. > > if there's interest, I could post them someplace (although > > they aren't a real solution for shipping with NM, but they do include DDNS > > updates :). > > Please attach them. I'll put something together later today :) > Also, please remember that dhclient and wide-dhcpv6 aren't the only possible > implementations and some people (including me) would like to see a library > solution and one is emerging from the connman project, see: > > https://bugzilla.gnome.org/show_bug.cgi?id=711635 Sounds interesting, but I wonder how long it'll take to mature -- and will it still allow the flexibility of (for example) supplying a local dhclient.conf with overrides that are integrated into the one NM creates. > Any chance you would be at FOSDEM? Always love an excuse to travel, but sadly I'm stuck skiing that week :)
Created attachment 266316 [details] NetworkManager scripts to request IA_PD and assign to LAN Here are the dispatcher scripts I currently use to request a prefix with dhclient, assign it to the LAN, and also assign addresses to both the LAN and the WAN (as currently I am only offered a single /64 from comcast). There's also code in there for DDNS as I have hooks for that (didn't include the script for ipv4 ddns though). If I ever get a smaller prefix, I may adapt the scripts :)
Scott, I can't promise to get to it soon but I'll be happy to test out what you have posted. Looks interesting.
FYI, I've completely rewritten the NM scripts so the prefix delegation is automatically distributed to all configured LAN interface... the new scripts even support multiple WAN prefix delegations, and independent DNS updates for each interface. If there's still interest, I'll see if I can throw them up on github or something (let me know).
Comment on attachment 266316 [details] NetworkManager scripts to request IA_PD and assign to LAN (clearing the patch flag since this is not a patch to NetworkManager itself)
OK, I'm just writing the README file now for the updated scripts (don't use the patch ones above, they're very limited). I'll post a link to github as soon as I have the scripts pushed there if that's acceptable.
Finally pushed my Prefix Delegation and DDNS scripts to github: https://github.com/sshambar/nmutils Basic setup is very simple (one line in a config file), but you can customize everything about sub-prefix assignment. The Dynamic DNS script is also quite useful and ties in nicely with the prefix assignment. Let me know what you think...
Visiting this issue again - here is "a" solution, conceptually. Realizing that prefix delegation is simply an "additional layer" to the router configuration, there is only this one "layer" to add to the NetworkManager action. Each "layer" consists of: a) a request on the WAN interface by the dhcp client running on the WAN interface to set-up addresses and optional services, b) some communication channel from the dhcp client at the WAN interface to the dhcp server at the LAN interface, for instance to communicate DNS information, and c) IP addresses and optional services on the LAN interface set-up by the dhcp server running on the LAN interface. The "layers", which are each optional and user selected for activation, are: 1) IPv4, a set of IPv4 addresses and services on the WAN and LAN interfaces, 2) IPv6, a set of IPv6 addresses and services on the WAN and LAN interfaces, and additionally, 3) a Prefix Delegation request at the WAN interface, conveying that prefix delegation in some way as to set-up the LAN interface, and running Router Advertisement and/or DHCPv6 services on the LAN interface. Note that the IPv6 address assigned to the WAN interface in "layer 2" has nothing to do with the delegated prefix in "layer 3". They are completely independent actions, as far as the "requesting router" is concerned. Currently, NetworkManager uses ISC dhclient as the dhcp client, and Simon Kelley's dnsmasq as the dhcp server. Now, one thing about dnsmasq, it is already able to provide both IPv4 and IPv6 services, and, perhaps most importantly, it is able to discover an IPv6 Prefix Delegation automatically, by simply noticing an IPv6 address prefix at the LAN interface, without requiring any other kind of communication channel. And, something about dhclient, it may be run as a distinct process - though it seems that also it _must_ be run as a distinct process - to fetch a Prefix Delegation. So, the changes needed for NetworkManager to run IPv6 connection sharing may be minor, or even trivial. Consider what would be required to be done manually to make this work while NetworkManager is already running: 1) sudo dhclient -P -v <WAN interface> Scott's scripts do something like this. [I notice that using "-d", "--no-daemon", which "implies -v", instead of "-v", does not succeed here, but that's not important.] This simplistic invocation is sufficient to generate a /64 prefix, which can be read on standard-output, and also write the file "/var/lib/dhclient/dhclient6.leases", including a line with "iaprefix <IPv6 prefix>::/64". 2) ip addr add <IPv6 prefix>::<1 or some ID>/64 dev <LAN interface> There needs to be some action provided here by NetworkManager, if this is not to be done manually. I didn't notice if Scott's scripts provide for this. 3) NetworkManager seems to hardcode the invocation of dnsmasq in /usr/bin/NetworkManager, and does not allow any additional configuration file to be read, explicitly using the "--conf-file <nothing>" switch, so that nothing can be done here without changing the NetworkManager source code. Otherwise, though, the simple addition of something like "enable-ra dhcp-range=::<first ID>,::<last ID>,constructor:<LAN interface>,64,60m" to the dnsmasq command line is sufficient to enable DHCPv6 services at the LAN interface. I didn't see anything in Scott's scripts which dealt with this. That's it - not including "house keeping". This includes enabling IPv6 "forwarding" in the kernel - but NetworkManager has already done that. The simplest thing to change in NetworkManager, to configure dnsmasq, is to allow a user-provided configuration file. That would be a trivial update to NetworkManager, and would allow the user to decide upon all the many combinations of IPv6 configuration variations in dnsmasq - "slaac", "ra-stateless", "ra-only", "ra-names". It is easy enough to have a simplistic NetworkManager default for this configuration file, which, of course, is the empty file - though better to include "--enable-ra --dhcp-range=::,constructor:<LAN interface>". And, even doing _just_ that would be enough to allow someone to _manually_ apply IPv6 LAN connection sharing _with_ NetworkManager running. The only thing to decide is the pathname for that dnsmasq configuration file. There are only two other actions required from NetworkManager: A) start "dhclient -P <WAN interface>", and B) configure an IPv6 address on the LAN interface, using that prefix. I'm pretty sure NetworkManager already has mechanisms for each of those actions. Isn't this just "more of the same"? Really, it's just one more dhclient invocation. Certainly, Scott's scripts deal with running dhclient, but they seem somehow unnecessarily complicated and "indirect" for such a very simple result, and NetworkManager already does this _twice_, for IPv4 and IPv6 WAN interface addresses. More complex prefix delegation from dhclient - prefix length or multiple prefix delegation - does not have to be handled by NetworkManager. For that matter DNS describing the LAN is an unnecessary "nicety" and does not have to be provided here, though dnsmasq already deals with that. Thoughts? Scott? James
Interesting suggestion... however, there are lots of edge cases that may need to be handled, and my scripts attempt to deal with. First, steps NetworkManager needs to handle (which my scripts currently substitute for), referring to your list above: 1) Run dhclient. Easy enough, trick here of course is ensuring you get the delegated prefix once assigned. 2) Assign address to LAN. This is where things get complicated. There are really two branches here: 2a) /64 assigned prefix. This was Comcast's default in my case, and I had to use a modified version of dhclient to get a larger /60 prefix (see redhat bug 876791) 2a-1) assign /64 prefix to WAN? 2a-2) assign /64 prefix to some LAN, optionally assign single address from prefix to WAN? (NOTE: The scripts handle this case, by default assigning prefix to LAN if specified, w/ single host address on WAN, or prefix on WAN if no LAN specified - all with config overrides if desired). 2b) Larger prefix assigned. Now we can assign /64 prefixes to WAN/LANs, but possibly need to allow overrides to assign to specific WAN/LANs, and if the prefix pool is limited (NOTE: Scripts handle this too, assigning /64 prefixes to LANs in order specified until prefix pool exhausted, and optionally including the WAN, all with overrides). 3) Configure dhcp. This probably needs to be done independently for each LAN. If dnsmasq can handle the assigned prefix automatically, that makes it as simple as notifying it of an interface change (if it doesn't monitor this directly, I'm not very familiar with dnsmasq as I use dhcpd :) -- radvd with the new DNS extensions basically make dnsmasq unnecessary for LAN host configs I think... (NOTE: scripts currently assume radvd will advertise the prefix using the ::/64 interface "special case" -- the scripts also deal with any DNS updates, not sure if dnsmasq has hooks of that or not.) I'd love for all this logic to be builtin to NM, but allowing for all the edge cases above may mean that configuration hooks could be complicated... something as simple as decided which LAN interfaces should get prefixes from the dhclient interface may cause user confusion if it's not handled correctly. I've tried with my scripts to make it as simple as possible as a "proof of concept" but found I couldn't quite do it all automatically unless I had some knowledge of what was WAN and what was LAN :) I guess if NM included some logic to intelligently guess at WAN/LAN setups basic on where dhclient was running and where dnsmasq/radvd was running, this could be automated to some degree... It's not impossible, but I'd like to be right >90% of the time :) BTW, the scripts are complicated as they need to handle the case where the LAN interfaces bounce or come up after the WAN interface, or vice-verse - so they need to keep prefix assignment state, which probably would be easier if NM tracked such state internally!
Check out odhcpd in CeroWrt for a working implementation of DHCPv6 Prefix Delegation. I'm using this at home with Comcast and everything Just Works(TM), delegating the Comcast provided /60 to multiple /64 LAN interfaces. Maybe it could be integrated with NM?
Created attachment 276392 [details] [review] NetworkManager patch to allow a config file for dnsmasq patch applied against NetworkManager-0.9.8.10
Here is a working solution to providing automatic IPv6 "connection sharing", with Prefix Delegation or SLAAC, using Network Manager. This solution uses systemd to run "dhclient -P -pf <pid-file> <wan>" before NetworkManager is started, creating a lease file which includes the delegated prefix, and then runs a script to configure the LAN interface with an IPv6 address using that prefix. From there, I have provided a patch to NetworkManager that allows a user-provided configuration file to be accessed by dnsmasq, which enables dnsmasq to automatically deduce the delegated prefix from the LAN interface address and run a DHCPv6 server on that interface, configured as specified in that configuration file. This approach, relying upon the ISC DHCPv6 client for Prefix Delegation, makes difficult specifying a prefix length "hint" in the delegation request from the WAN DHCPv6 client, simply because dhclient makes this very difficult, if not impossible. I think Scott might have a patch to dhclient to fix this - Scott? Regardless, it should be possible to request multiple "/64" prefixes, if they are needed, though, again, ISC dhclient does not seem to support that either. Alternatively, some other DHCPv6 client might be used for Prefix Delegation. I have not tried Dibbler, partly because it seems not to support DHCP for IPv4, and partly because NetworkManager is not supporting it. Though dhcpcd is supported by NetworkManager, I was not able to get dhcpcd to actually configure any kind of IPv6 address. This may have been fixed in a recent commit, but in any case, the NetworkManager log reports "<warn> the dhcpcd backend does not support IPv6." I also tried Connection Manager, connman, but it seemed capricious and unpredictable, setting up a 6to4 tunnel interface, instead of configuring a native IPv6 interface address. WIDE-DHCPv6 seems to work for people, but the most recent version is dated from 2008. If it works, that's a win, but I have not tried it. Onward. In addition to the patch to NetworkManager, there is a systemd service file for dhclient that goes into /etc/systemd/system/, some modification to the NetworkManager service file in /usr/lib/systemd/system/, and a short script and EnvironmentFile used by the dhclient service file and the dnsmasq config file, the three of which I am putting into /etc/NetworkManager/. That's all. The patch hard-codes the dnsmasq config file to "NMCONFDIR/nmdnsmasq.conf", which usually will be "/etc/NetworkManager/nmdnsmasq.conf". The dnsmasq config file is optional, with NetworkManager defaulting to the old behaviour of no config file if the dnsmasq config file does not exist. "nm-dnsmasq-manager.c" is the file changed. Incorporating "NMCONFDIR" required an update to the associated "Makefile.am" and "Makefile.in". I did not use the existing directory "/etc/Networkmanager/dnsmasq.d" because it seemed to be used for setting VPNs, but I didn't trace all the way through the code. The section in "dns-manager/nm-dns-dnsmasq.c" begins "Kill the old dnsmasq;", so there may be some additional changes needed to also read the user dnsmasq config file when this happens, perhaps under the section at "And any other random configs". The essential content of my "nmdnsmasq.conf" is: dhcp-range=::33,::63,constructor:<my-lan-interface>,64,60m enable-ra interface=<my-lan-interface> The interface line is very important to have working IPv6 services, since the NetworkManager default configuration specifies the IPv4 _address_ only, "--listen-address=10.42.0.1". By specifying the lan interface in the config file, the IPv6 addresses are added to dnsmasq's list of managed addresses, which otherwise would be ignored. My configuration provides stateful DHCPv6. If you prefer SLAAC, add the line "slaac" to the config file, and generally read "man dnsmasq" at "--dhcp-range". Of course, now you can add other goodies to the config file, if you like, such as "domain-needed" and "bogus-priv". I am using a systemd service file for "dhclient -P" because it is easier than "reinventing the wheel", and writing dispatcher files for "/etc/NetworkManager/dispatcher.d". On my machine, when NetworkManager would normally start, the ethernet device has not been fully configured - _despite_ setting the NetworkManager dependency "After=network.target". systemd has a very "loose" concept of "network.target". I am making NetworkManager conditional upon "dhclient -P" with "Requires=dhclient6-pd.service". This also requires an explicit "-pf /var/run/dhclient6-pd.pid" to "dhclient -P", and a matching "PIDFile=/var/run/dhclient6-pd.pid" in the service file, or systemd will not recognize when dhclient is finally running. What happens, then, is "dhclient -P" fails to start the first three tries, on my machine, when setting a two second wait and a restart - "Restart=on-failure", "RestartSec=2" - while my ethernet device gets configured. NetworkManager waits for "dhclient -P". After the ethernet device is ready, everything proceeds. The file "/etc/systemd/system/dhclient6-pd.service" contains: [Unit] Description=Dynamic Host Configuration Protocol for Prefix Delegation - DHCPv6 After=network.target Requires=network.target Before=NetworkManager.service [Service] Type=forking PIDFile=/var/run/dhclient6-pd.pid EnvironmentFile=/etc/NetworkManager/startpd.conf ExecStart=/usr/bin/dhclient -P -pf /var/run/dhclient6-pd.pid $wan ExecStartPost=-/etc/NetworkManager/startpd ExecStop=/usr/bin/dhclient -r $wan ExecStopPost=/usr/bin/rm /var/lib/dhclient/dhclient6.leases Restart=on-failure RestartSec=2 [Install] WantedBy=multi-user.target Note that ExecStopPost removes the old lease file, in case any new lease file has a different prefix delegated, which will be applied by the ExecStartPost script "/etc/NetworkManager/startpd". Also, the "dhclient6-pd" service does not have to be "enabled" and will be started automatically by NetworkManager. This file simply needs to be recognized by systemd, at boot, or with a "sudo systemd daemon-reload". The EnvironmentFile at /etc/NetworkManager/startpd.conf contains only the WAN and LAN interfaces: wan=<wan interface> lan=<lan interface> Some distributions might want to put this file elsewhere, like /etc/default/startpd or such. The script at /etc/NetworkManager/startpd is to select the delegated prefix from the just-written lease file and then configure the LAN interface with an address from that delegated prefix range. That script contains: #!/bin/bash . /etc/NetworkManager/startpd.conf until [ -f /var/lib/dhclient/dhclient6.leases ] do sleep 1 done ip6=`sed -n '/iaprefix /h;${g;s~.*iaprefix \(.*\)/\([0-9]\+\) .*~\11/\2~;p}'\ /var/lib/dhclient/dhclient6.leases` /usr/bin/ip addr add $ip6 dev $lan Prefix Delegation has now been done, and dnsmasq will be able to run IPv6 services on the LAN interface. dnsmasq is tolerant of the prefix address being configured after it has started, when using "--bind-interfaces". The NetworkManager systemd service file has the only other changes. I suggest three changes. The unified diff is: --- /usr/lib/systemd/system/NetworkManager.service.orig 2014-05-12 12:16:23.653849785 -0600 +++ /usr/lib/systemd/system/NetworkManager.service 2014-05-12 12:09:52.357755437 -0600 @@ -1,7 +1,8 @@ [Unit] Description=Network Manager Wants=network.target -Before=network.target +Requires=dhclient6-pd.service +After=network.target dhclient6-pd.service [Service] Type=dbus @@ -12,7 +13,7 @@ # syslog by default, which results in logging each message twice. StandardError=null # NM doesn't want systemd to kill its children for it -KillMode=process +# KillMode=process [Install] WantedBy=multi-user.target There is "Requires=dhclient6-pd.service" to start the Prefix Delegation and then "camp-out" on the lease for when it expires. "After" instead of "Before", of course. Not that "network.target" is quite what is wanted, but there is no kind of "networking-devices.target" available in systemd. Yet? And remove "KillMode=process" because I don't like that "stopping" NetworkManager otherwise leaves behind a host of running processes - dnsmasq and _three_ versions of dhclient. Let systemd do this. The revised NetworkManager service file is: [Unit] Description=Network Manager Wants=network.target Requires=dhclient6-pd.service After=network.target dhclient6-pd.service [Service] Type=dbus BusName=org.freedesktop.NetworkManager ExecStart=/usr/bin/NetworkManager --no-daemon # Suppress stderr to eliminate duplicated messages in syslog. NM calls openlog() # with LOG_PERROR when run in foreground. But systemd redirects stderr to # syslog by default, which results in logging each message twice. StandardError=null # NM doesn't want systemd to kill its children for it # KillMode=process [Install] WantedBy=multi-user.target Alias=dbus-org.freedesktop.NetworkManager.service Also=NetworkManager-dispatcher.service Works for me, with Comcast. I get a /128 in the WAN and a /64 on the LAN, plus the link-local addresses, plus the IPv4 address, plus DHCP v4 and DHCPv6 client and server on the WAN and LAN, plus specialized DNS on the local network, and, best of all, NetworkManager configures iptables for IPv4 NAT without having to think about it. Check it out, eh? BTW, dhclient seems to need at least a link-local address on the WAN, or it will not start. Seriously?! I think the kernel initially configures the link local addresses, but, if they get "flushed", they have to be re-configured manually, "/usr/bin/ip addr add $wanll scope link dev $wan", usually with the "Modified EUI-64" addresses. James
Comment on attachment 266316 [details] NetworkManager scripts to request IA_PD and assign to LAN Replaced with scripts at https://github.com/sshambar/nmutils/
The dhclient "hint" patch is in: https://bugzilla.redhat.com/show_bug.cgi?id=876791 You can also work around the problem of dispatcher killing it's children by moving them into the main NM control group... I added this to my "daemonize" function in the nmutils scripts, but it can be done with (assuming BASH): # fork, add to NM cgroup ( cgrp=/sys/fs/cgroup/systemd/system.slice/NetworkManager.service/tasks [ -w "$cgrp" ] && echo $BASHPID > "$cgrp" exec </dev/null &>/dev/null "$@" ) & I had the same problem with dhclient needing a link-local address (actually the problem was the address assigned was still tentative). I worked around the problem in my nmutils scripts by waiting on the link-local address before spawning dhclient, see ipv6_spawn_dhclient() in https://github.com/sshambar/nmutils/blob/master/sbin/dhclient-ipv6-prefix... you could also use something like: idx=0 while [ -n "$(ip addr show dev $interface scope link tentative)" ]; do ((++idx)) sleep 0.1 # 2.5 sec max (or NM will kill us) [ $idx -ge 25 ] && echo 1>&2 "Timed out waiting for link address" && exit 1 done or similar in your spawn script.
After some more thought, consider: using that dhclient6-pd.service file - which runs "dhclient -P" with "Restart=on-failure" and "RestartSec=2" - is anyway a very "fragile" work-around on NetworkManager. So, it makes more sense to _not_ have "Requires=dhclient6-pd.service" and "After=dhclient6-pd.service" in the "/usr/lib/systemd/system/NetworkManager.service" file, but to instead be able to "sudo systemctl enable dhclient6-pd" and "sudo systemctl disable dhclient6-pd" _manually_, so it runs only when it is needed. NetworkManager is suppose to provide dynamic network configuration, and the only time this "dhclient6-pd.service" is needed is when NetworkManager is suppose to be configuring an IPv6 subnet. So, maybe when you go to the coffee shop, you do _not_ want "dhclient -P" running and failing every two seconds, because there is no active network device. But when you bring your laptop computer back home, you want your laptop to be an IPv6 router. Ok, maybe not; your LAN router is probably in a more "static" situation. But when circumstances change, you might want to simply turn-off "dhclient -P". Either way, the "Requires=dhclient6-pd.service" and "After=dhclient6-pd.service" lines probably should _not_ be in "/usr/lib/systemd/system/NetworkManager.service", and "dhclient6-pd.service" should be enabled manually. Then also, the [Unit] section of "/etc/systemd/system/dhclient6-pd.service" should have "After=dnsmasq.service", removing the "Before=NetworkManager.service". BTW - typo above - should be "sudo systemctl daemon-reload", not ""sudo systemd daemon-reload". On another point - I have set-up WIDE-DHCPv6 and dhcp6c, the DHCPv6 client. Even though this project has not had an "official" update since 2008, Debian, at least, maintains a current patch set for this package, and there are a couple of others at the sourceforge web site. So it would perhaps be inaccurate to consider WIDE-DHCPv6 "unsupported". To my surprise, I found dhcp6c to be simple and effective, with the following caveat: dhcp6c seems to need to run as root to bind the WAN interface and seems to bind to the LAN interface, even after specifying only the WAN interface on the command line. I suspect that this is a minor bug in dhcp6c. At the same time, dnsmasq needs to bind the LAN interface, and it seems that it cannot unless it also runs as root. Arch Linux, and maybe others, run dnsmasq as a non-root user, and then dnsmasq cannot bind the LAN interface. That would be a minor bug in Arch. So check for that if you see problems. I had to modify my dnsmasq.service file, which had "--user=dnsmasq" on the ExecStart command line. Running WIDE-DHCPv6 dhcp6c instead of ISC dhclient allows running one program instead of two, and avoids the "hack" of a special instance of "dhclient -P". dhcp6c also provides simple configuration for Prefix Delegation request, site-level aggregator - SLA - id specification, SLA length/Prefix length request, LAN interface address specification within the Prefix, Non-temporary Address request, various other DHCPv6 requests, and router authentication, if required. I would strongly suggest that NetworkManager consider using dhcp6c instead of "dhclient -6" and "dhclient -P", even with my "dhclient6-pd.service" hack. On another point - supposing the distinction of "the pre-systemd world" and "the post-systemd world", what is the future of NetworkManager? It seems to me that most, or all, of the low-level network interface configuration can now be provided by some bit of systemd service file configuration, so that NetworkManager should not be "hard coding" commands to run various programs. Instead, NetworkManager provides a _dynamic_ and _automatic_ network configuration service, so that network configuration "just works", especially for a mobile device. So then, NetworkManager could be re-built on top of systemd services. Consider what configuration is required for a network now: 1) network device interface configuration. This can now be had by writing some /etc/systemd/network/ "<interface>.network" files and enabling "systemd-networkd". In particular, suppose you want a private network address on the WAN to be able to talk to the cable modem, and you want a private network address on the LAN to talk to the wireless access point. You can configure these as static addresses. And then you can also configure automatic DHCP for IPv4. You end-up with the static addresses, the IPv4 DHCP address, the private routes, the IPv4 default route, the IPv6 link local addresses, and additional options are available. There is also then an implicit "systemd-networkd" state which can be tested to trigger subsequent configuration. To make sure this "just works", let's assume that Predictable Network Interface Names are being used, http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ 2) Any number of services would re-write /etc/resolv.conf. Let us suppose that resolv.conf is static, substituting Google's name servers for the ones provided by the ISP, and possibly a local name server on the localhost address. 3) The linux kernel is doing mysterious network things in the background. For "Network Sharing", running a router, this can be managed with the sysctl interface in systemd by writing something like "/etc/sysctl.d/30-ipforward.conf", with, for instance, net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 net.ipv6.conf.<WAN interface>.accept_ra=2 and enabling "systemd-sysctl". The line "net.ipv6.conf.<WAN interface>.accept_ra=2" is needed for a static IPv6 address on a WAN interface that is also forwarding IPv6 packets. There is a short discussion at: "Linux ignores IPv6 router advertisements when forwarding is enabled", http://www.mattb.net.nz/blog/2011/05/12/linux-ignores-ipv6-router-advertisements-when-forwarding-is-enabled/ 4) IPv4 NAT will require some iptables configuration, and perhaps in the future some nftables configuration instead. NetworkManager NAT rules can be put into /etc/iptables/iptables.rules, and installed by enabling "systemd-sysctl". 5) IPv6 DHCPv6 Client Services on the WAN interface can be provided by WIDE-DHCPv6 dhcp6c, by writing "/etc/wide-dhcpv6/dhcp6c.conf" and enabling "dhcp6c". 6) Finally, IPv4 DHCP, IPv6 DHCPv6, IPv6 Router Advertisements, and localized DNS services can be provided on the LAN interface by dnsmasq. I'm surprised this works so well, since some would claim it is not "the Unix Way", though, to me, it makes perfect sense that these DHCP services are all "part of the same cloth". Again there is just "/etc/dnsmasq.conf" and enabling "dnsmasq". So, should NetworkManager be built on top of systemd, and just install the associated configuration files and then twiddle "enable" and "disable" as the network changes? James
>> I have been finding >> references to "dnsmasq" and "wide-dhcpv6" for IPv6, but the traditional DHCP >> servers just don't have full IPv6 functionality. > If you have reference setups that work without NetworkManager, please include > links to those in the bug report. It helps a lot. Pavel, BTW, the description above, under "what configuration is required for a network now", is an actual _working_ no-NM dual-stack IPv4 with NAT and IPv6 router/"connection sharing" configuration with Non-temporary IPv6 Address on the WAN, and Prefix Delegation IPv6 Address on the LAN with DHCPv6 and RA services - though still no Prefix Delegation Server on the LAN with dnsmasq. Despite Jeremy's early comment - albeit from 2009 - I see that "man 5 dhcp6s.conf" for the WIDE-DHCPv6 Server has: Host statement ... host name { substatements }; ... prefix ipv6-prefix pltime [vltime]; This statement specifies an IPv6 prefix to be delegated to the client. Also, "man 5 dhcpd.conf" has: ADDRESS POOLS ... In addition to the range6 statement it allows the prefix6 statement to be included. So I suppose that dhcp6s and ISC dhcpd could be used instead of dnsmasq, for anyone who needs a configurable IPv6 Prefix Delegation server on the LAN. I have not tried these. It is not clear that the prefixes discovered by the WAN client can be automatically re-delegated and configured in the LAN DHCPv6 server, without re-writing the server configuration files with a script and then restarting the servers. It might be easier to plead with Simon Kelley to add this feature to dnsmasq. James
*** Bug 773484 has been marked as a duplicate of this bug. ***
see downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1256822
I'm now closing this, since IPv6 connection sharing (in form of prefix delegations) has been merged to master ecc6040cd8ecce37685c8433810be16ff35096da. Everyone is encouraged to try it out. Please file separate bugs if anything works differently than you'd expect. Thank you!