Created attachment 595408 [details] mixed -P -N mode support for dhclient 4.2.4 Description of problem: dhclient -P -N <interface> (or -P -T) attempts to allocate both a delegated prefix and an client address from the DHCP server, but during the "REBOOT-INIT" phase, the prefix delegation converts the client state to REBIND (required by RFC 3633 when confirming a prefix), and the address confirm is also converted to a rebind, resulting in the dhclient-script never assigning the address to the interface since a BOUND6 state never occurs (just a REBIND6 with old=new addresses). Version-Release number of selected component (if applicable): dhclient-4.2.4-2 How reproducible: Whenever rebooting with dhclient -P -N with an existing prefix delegation (ia_pd) and client address (ia_na) lease. Steps to Reproduce: 1. Configure dhclient for ipv6 with both -P and -N options. 2. Run dhclient to obtain leases for both ia_pd and ia_na. 3. Stop dhclient 4. Restart dhclient... which attempts a rebind for the ia_pd, and also a rebind (not a confirm) for the ia_na. Actual results: dhclient-script is called for the PD and NA with a reason of REBIND6, and old_ip6_address=new_ip6_address on the NA REBIND6 results in no address assigned to the interface. Expected results: A PD REBIND6 for the prefix delegation, and a NA BOUND6 for the NA. Additional info: Since the client_state is shared for the default interface configuration, to obtain the correct behavior, a pseudo-interface must be used in the case of mixing -P and -N or -T options. This separation allows the ia_pd assignment to progress independently of the ia_na assignment (as described in RFC3633, Section 7 ("Prefix delegation with DHCP is independent of address assignment with DHCP.") To achieve this, I've created a patch to dhcp-4.2.4 that allows a specifically named pseudo-interface ("pd-handler") to processes prefix delegation independently of address assignment, but behave exactly as currently coded (which is in my option broken) if the pseudo interface is not defined (ie. no change to current installations). Ideally, I believe dhclient should create a pseudo interface automatically in the case of both -P and either -N or -T being requested, so that the out-of-box behavior results in a working client (I could code this, but I'm not sure if any existing installations for some reason rely on the current, broken behavior). I've also updated the dhclient man page to document the configuration requirement for correct behavior. In addition, I've updated dhclient-script so that it can be used by the pseudo-interface without the having to be replaced by a special script that doesn't control the interface state (flush addresses or bring it up/down). If does this by special casing behavior based on the variable "${client}".
(In reply to comment #0) > To achieve this, I've created a patch to dhcp-4.2.4 that allows a > specifically named pseudo-interface ("pd-handler") to processes prefix > delegation independently of address assignment, but behave exactly as > currently coded (which is in my option broken) if the pseudo interface is > not defined (ie. no change to current installations). Please send your patch&description also to dhcp-suggest or dhcp-bugs > Ideally, I believe dhclient should create a pseudo interface automatically > in the case of both -P and either -N or -T being requested, so that the > out-of-box behavior results in a working client (I could code this, but I'm > not sure if any existing installations for some reason rely on the current, > broken behavior). How does one create such a pseudo-interface ? > I've also updated the dhclient man page to document the configuration > requirement for correct behavior. Doesn't your patch make the following part of dhclient(8) obsolete ? "Note: it is not recommended to mix queries of different types together or even to share the lease file between them." And what about the note that -P "... also disables the normal address query" ?
(In reply to comment #1) > Please send your patch&description also to > dhcp-suggest or dhcp-bugs Will do, although I guess I'll have to create a working patch against the mainline source... :) > > How does one create such a pseudo-interface ? > In dhclient.conf, eg: interface "eth0" { send dhcp-client-identifier "test"; } pseudo "pd-handler" "eth0" { send dhcp-client-identifier "test-pd"; } Internally, it creates two state machines (clients) which handle their addresses/prefixes or whatever independently of each other (all the pseudo interfaces call the dhclient-script with their name in $client) > > I've also updated the dhclient man page to document the configuration > > requirement for correct behavior. > > Doesn't your patch make the following part of dhclient(8) obsolete ? > "Note: it is not recommended to mix queries of different types together or > even to share the lease file between them." If you mix prefix and regular addresses together in the default interface, odd things happen (because the state machines are really not compatible). With a pseudo-interface handling the prefix, they can safely share a lease file (although I had to include in the patch code to write the missing "name" parameter in the lease, which was only set in the ipv4 leases in mainline). Since I'm not creating an automatic pseudo interface (which I'd like to, but I'd need to discuss with the maintainers if that would be acceptable), the default -P -N behavior is still "not recommended", but with the named pseudo interface, it works great. > And what about the note that -P "... also disables the normal address query" > ? -P disables normal addresses query, -N adds it back (which is documented in mainline). I might get on the dhcp list and suggest the automatic pseudo interface and see what the feedback is. In the case of my cable upstream, querying both a prefix for the home network, and a single address for the public interface is the only way to follow RFC3633, section 12.1: "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router." ... so mixing -P -N and having it work is the only way to accomplish that :)
OK, I created a patch against upstream, and sent it with the description above to dhcp-bugs.
(In reply to comment #2) > In dhclient.conf, eg: > interface "eth0" { > send dhcp-client-identifier "test"; > } > pseudo "pd-handler" "eth0" { > send dhcp-client-identifier "test-pd"; > } > Internally, it creates two state machines (clients) which handle their > addresses/prefixes or whatever independently of each other (all the pseudo > interfaces call the dhclient-script with their name in $client) Oh, I haven't known about that. Good. > Since I'm not creating an automatic pseudo interface (which I'd like to, but > I'd need to discuss with the maintainers if that would be acceptable), ... The need of client identifier could be a problem here. The protocol requires that client identifiers are unique on any given network segment. If two or more clients use the same identifier, a collision can occur and the DHCP server treats the clients as if they are the same. RFC 2132 recommends that the DHCP client identifier consist of a network hardware type and the client’s link-layer address but permits it to have any value. See bug #560361 for ways how to create client-identifier. But as I stated in bug #560361, comment #9 I actually don't like the idea of default (or automatically created) dhclient.conf. > ... so mixing -P -N and having it work is the only way to accomplish that :) OK, I got it. (In reply to comment #3) > OK, I created a patch against upstream, and sent it with the description > above to dhcp-bugs. Great. What's the assigned ID ?
(In reply to comment #4) > The need of client identifier could be a problem here. > The protocol requires that client identifiers are unique on any given > network segment. If two or more clients use the same identifier, a collision > can occur and the DHCP server treats the clients as if they are the same. > RFC 2132 recommends that the DHCP client identifier consist of a network > hardware type and the client’s link-layer address but permits it to have any > value. See bug #560361 for ways how to create client-identifier. > But as I stated in bug #560361, comment #9 I actually don't like the idea of > default (or automatically created) dhclient.conf. > Actually, a read of rfc4361 shows that conforming client identifier includes both the IAID and DUID (Section 6.1), and since the IAID's are different between NAs and PDs, using different client identifiers for the two state machines should be conforming. ... from looking at the code, it appears dhclient isn't using rfc4361 identifiers though, it just uses the DUID -- so I can see why the man pages says pseudo interfaces need unique client identifiers. OK, just sniffed the network, and my client-ids are the same for both clients (which appears to work, but isn't ideal). I should have used the following dhclient.conf: pseudo "pd-handler" "eth0" { send dhcp6.client-id "test-pd"; } (in this case the default interface client-id is just the DUID, which is fine). > (In reply to comment #3) > > OK, I created a patch against upstream, and sent it with the description > > above to dhcp-bugs. > > Great. What's the assigned ID ? Assigned ID is ISC-Bugs #30090
I found a bug in my patch (was returning in the dhclient-script with not in a function), so I've updated the patch. Also, note on testing, for the pseudo handler to work, you still need a regular interface definition, so dhclient.conf should be: interface "eth0" { } pseudo "pd-handler" "eth0" { send dhcp6.client-id "test-pd"; } ... otherwise only a single state machine for "pd-handler" is used.
Created attachment 596115 [details] mixed -P -N mode support for dhclient 4.2.4 Updated patch with fix for dhclient-script
Any update on this? Are you waiting for something from me?
I think I have all the info from you I need. It's just that there are things with higher priority atm and also I'm not quite fond of the need of user (I don't want to do this automatically) creating the pseudo interface in dhclient.conf.
Well, I could rework the patch... but I don't quite follow what you'd prefer. * If you don't want the user-created pseudo interface, then the alternative is to create one automatically... * But you don't want this done automatically, so... ? Basically, the "-P -N" option combo is currently broken out of the box, so I would think an automatic pseudo-interface (which is logged/doc'd, in case someone wants to customize it) would make the client work without requiring someone crawling through the man pages/code. My goal was minimal impact (don't change current behavior), but honestly the current behavior is so broken that anything is probably better than nothing. Perhaps in the case of the automatic interface, I could copy settings from the main interface's config (less the client-id etc), and create/append something as it's config name and it's client-id... so the automatic client would "inherit" as much of the main config as possible. Sound like a plan?
(In reply to comment #10) > Well, I could rework the patch... but I don't quite follow what you'd prefer. I know, I know. > * If you don't want the user-created pseudo interface, then ... Well, I just don't like it. I like out-of-the-box solutions, you know :-) Don't get me wrong - you've done a lot of work (on the patch and explaining it to me) and I appreciate it. It's just that if I have to maintain another patch, I'd rather want it to just work. > * But you don't want this done automatically, so... ? Yes, I definitely don't want to automatically change/create the config file behind users back. > My goal was minimal impact (don't change current behavior), but honestly the > current behavior is so broken that anything is probably better than nothing. I'll try to look at it more when I find some time. One more thing: Have you already explained why you can't run 2 dhclient instances ? One for address assignment and one for prefix delegation ?
(In reply to comment #11) > (In reply to comment #10) > > * But you don't want this done automatically, so... ? > > Yes, I definitely don't want to automatically > change/create the config file behind users back. > Well, I wasn't planning that; my "automatic" solution would create a new pseudo-interface (with it's own client state) internally -- it wouldn't change/create the config file! (which SELinux wouldn't allow anyway :) > I'll try to look at it more when I find some time. > One more thing: > Have you already explained why you can't run 2 dhclient instances ? > One for address assignment and one for prefix delegation ? That was my first approach, but between needing to add more hook functions to ifup/down, create separate config/state/pid files, and probably have the whole thing fail reusing the same UDP port or rejected by the server if not on the reserved port (and associated routing/firewall issues) -- it was becoming the mother of all hacks, and would probably need to be re-worked once I can make the transition to NetworkManager (once it's server-ready). In short, it was way fewer lines of code to just fix dhclient :) Not to mention, the man pages says you can just use both flags ("-P -N") to get address+prefix... it just doesn't work!
With regards to the following: Doesn't your patch make the following part of dhclient(8) obsolete ? "Note: it is not recommended to mix queries of different types together or even to share the lease file between them." I have experimented, and found that dhclient does not work correctly with multiple instances running against the same upstream. It correctly acquires the leases, but is unable to renew them since the responses to renew requests all end up at any one random dhclient, instead of the dhclient which is trying to renew. As a result, after a lease expiration time, the lease is lost.
(In reply to comment #12) > (In reply to comment #11) > > > > Yes, I definitely don't want to automatically > > change/create the config file behind users back. > > > > Well, I wasn't planning that; my "automatic" solution would create a new > pseudo-interface (with it's own client state) internally -- it wouldn't > change/create the config file! (which SELinux wouldn't allow anyway :) I'm not sure I understand (starting to feel stupid now :). When I had asked you in comment #1 'How does one create such a pseudo-interface ?' you replied that in dhclient.conf with the "pseudo" statement.
(sorry for delay, it's summer :) Difference between my "conservative" implementation, and my "ideal" solution: 1) the "automatic" solution (NOTE the patch), is to create a pseudo-interface when BOTH -P and -N are supplied 2) the patch only creates the pseudo-interface is it's in the config file (so the default *BROKEN* behavior is preserved) Since -P -N (combined) doesn't work "out of the box," it's probably OK if I just fix it to work by adding a pseudo-interface even if it's not configured. I'm more than happy to submit this as a solution, because it's the way I'd expect it to work anyway (based on the RFC).
NOTE in (1) above is "NOT"...
Created attachment 617803 [details] mixed -P -N mode support for dhclient 4.2.4-P2 Updated for P2
This still does not provide any way to set the requested prefix size, though, correct?
The prefix size issue sounds like a different bug... I might take a look at it if you log one :)
I have logged the prefix issue as bug 876791.
Created attachment 665807 [details] Update dhcp rpm patch for patchlevel 16
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
From https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues This document describes a number of problems encountered with multiple IA option types into DHCP and recommended changes to the DHCPv6 protocol specifications. The intention of this work is to modify the DHCP protocol specification to support multiple IA option types within a single DHCP session. This problem can also be solved by implementing a separate DHCP session (separate client state machine) per IA option type. This latter approach has a number of issues: additional DHCP protocol traffic, 'collisions' between stateless options also included with the IA options, divergence in that each IA option type specification specifies its 'own' version of the DHCP protocol.
Yes, these problems do exist. However, there are also ISPs *today* which require the current protocol to get service.
(In reply to H. Peter Anvin from comment #24) > Yes, these problems do exist. However, there are also ISPs *today* which > require the current protocol to get service. It is my understanding that those ISPs recommend wide-dhcpv6. see https://bugzilla.redhat.com/show_bug.cgi?id=956147 Review Request: wide-dhcpv6 - DHCPv6 Prefix Delegation client
Comcast have mentioned Dibbler to me.
Well, in any case, Fedora needs a solution that the average person can use. I find it sad that the only answer for getting an IPv6 network assignment from Comcast is to either hack the code or by a home router/nat-box. Why is there so much foot dragging on this bugzilla?
(In reply to H. Peter Anvin from comment #26) > Comcast have mentioned Dibbler to me. Comcast does work with wide-dhcpv6 for BSD and Ubuntu. wide-dhcpv6 was not available for fedora, until I repackaged it. I might consider maintaining dibbler package as well if required.
Just realized my patches above somehow lack the meat of the patch (the code that actually fixes dhclient, oops!). I'll see if I can update the patch for the current release and re-post them.
Created attachment 850306 [details] Patch just for dhcp code to add support for pseudo interface for PD Here's an independent patch for dhclient to support a psuedo interface for requesting IA_PD in parallel to IA_NA. As before, this requires the user to add a stanza to dhclient.conf to specifically request this behavior (so -P -N just requests IA_NA as documented).
Created attachment 850307 [details] Patch so dhclient-script can cope with pseudo interfaces Here's also a patch to the redhat dhclient-script so that it correctly handles pseudo interfaces... and yes I should probably file a separate bug for this, as it's an different problem (of course, same goes for the lease file writer fix in dhclient.c patch)
A blog post (http://blog.dan.drown.org/fedora-based-router-with-dhcpv6-pd-support/) brought me here, as I was also looking into setting up Fedora to do DHCPv6 PD as my ISP supports this now. However, this bug seems to be a showstopper. In a few months its going to be 5 years since this has been reported. It would be good if this can get picked up again and finally be fixed, so that we don't need to jump through hoops to get this working properly.
Can at least the work of Scott Shambarger be merged so we have a workable situation in the meantime? Thanks.
There seemed to be a general unwillingness to add patches for this in Fedora, and my upstream bug/patch has basically been ignored by ISC; so I wrote some NetworkManager dispatcher scripts that use dhclient's discrete prefix state machine to acquire the prefix, and then performs delegation to LAN interfaces (and even DDNS). I've used these scripts for years without problems, so you might find luck with them -- they're on github: https://github.com/sshambar/nmutils The README has basic install instructions, and the scripts themselves fully document all their configuration options (they are _very_ flexible). Let me know if you have any problems using that until someone here is willing to include support in the dhclient/NetworkManager directly. :)
Hi Scott, thank you very much for that, I will take a look at the scripts and try it out. At first glance this looks awesome already, I love flexibility. It's baffling that there is unwillingness to fix this, because in my opinion this is a kind bug that becomes increasingly more important to fix as time passes by and IPv6 gets deployed around ISP networks around the world.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to David Beveridge from comment #28) > (In reply to H. Peter Anvin from comment #26) > > Comcast have mentioned Dibbler to me. > > Comcast does work with wide-dhcpv6 for BSD and Ubuntu. > wide-dhcpv6 was not available for fedora, until I repackaged it. > > I might consider maintaining dibbler package as well if required. What will it take for RedHat to lean on ISC and get them to DOCUMENT how their client actually handles the usage of a PD request? This is beyond stupid, I've been running RedHat (aka CentOS) servers since 1995 but this is really the first time that I've not only considered switching over to Ubuntu for my firewall boxes but actually done it due to a lack of UNDERSTANDABLE DOCUMENTATION!!!
This is also a problem in CentOS 7, if it wasn't already evident.
This has been fixed upstream in dhcp-4.4.x. Can we please get the Fedora package updated accordingly.
(In reply to H. Peter Anvin from comment #39) > This has been fixed upstream in dhcp-4.4.x. Can we please get the Fedora > package updated accordingly. dhcp-4.4.1 is in rawhide. can you please check if it solves the problem?
After a lot of pain involving a scratch reinstall I got fc30 up and running on my gateway host, and installed dhcp-client-4.4.1-9.fc30.x86_64 from koji. It works like a charm.
Thank you for testing. Closing