Bug 836702 - dhclient -P -N should handle combined prefix delegation and address assignment correctly
dhclient -P -N should handle combined prefix delegation and address assignmen...
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
rawhide
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-30 00:38 EDT by Scott Shambarger
Modified: 2014-11-27 05:16 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
mixed -P -N mode support for dhclient 4.2.4 (11.27 KB, patch)
2012-06-30 00:38 EDT, Scott Shambarger
no flags Details | Diff
mixed -P -N mode support for dhclient 4.2.4 (11.27 KB, patch)
2012-07-03 19:47 EDT, Scott Shambarger
no flags Details | Diff
mixed -P -N mode support for dhclient 4.2.4-P2 (11.30 KB, patch)
2012-09-26 18:38 EDT, Scott Shambarger
no flags Details | Diff
Update dhcp rpm patch for patchlevel 16 (11.64 KB, patch)
2012-12-18 17:48 EST, Scott Shambarger
no flags Details | Diff
Patch just for dhcp code to add support for pseudo interface for PD (7.06 KB, patch)
2014-01-14 18:24 EST, Scott Shambarger
no flags Details | Diff
Patch so dhclient-script can cope with pseudo interfaces (1.75 KB, patch)
2014-01-14 18:29 EST, Scott Shambarger
no flags Details | Diff

  None (edit)
Description Scott Shambarger 2012-06-30 00:38:56 EDT
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}".
Comment 1 Jiri Popelka 2012-07-02 05:33:57 EDT
(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@isc.org or dhcp-bugs@isc.org

> 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" ?
Comment 2 Scott Shambarger 2012-07-02 14:17:50 EDT
(In reply to comment #1)
> Please send your patch&description also to
> dhcp-suggest@isc.org or dhcp-bugs@isc.org

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 :)
Comment 3 Scott Shambarger 2012-07-02 19:38:15 EDT
OK, I created a patch against upstream, and sent it with the description above to dhcp-bugs@isc.org.
Comment 4 Jiri Popelka 2012-07-03 07:26:50 EDT
(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@isc.org.

Great. What's the assigned ID ?
Comment 5 Scott Shambarger 2012-07-03 19:03:07 EDT
(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@isc.org.
> 
> Great. What's the assigned ID ?

Assigned ID is ISC-Bugs #30090
Comment 6 Scott Shambarger 2012-07-03 19:46:30 EDT
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.
Comment 7 Scott Shambarger 2012-07-03 19:47:48 EDT
Created attachment 596115 [details]
mixed -P -N mode support for dhclient 4.2.4

Updated patch with fix for dhclient-script
Comment 8 Scott Shambarger 2012-07-19 03:12:12 EDT
Any update on this?  Are you waiting for something from me?
Comment 9 Jiri Popelka 2012-07-19 06:38:59 EDT
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.
Comment 10 Scott Shambarger 2012-07-19 14:23:08 EDT
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?
Comment 11 Jiri Popelka 2012-07-20 07:01:49 EDT
(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 ?
Comment 12 Scott Shambarger 2012-07-20 14:13:27 EDT
(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!
Comment 13 H. Peter Anvin 2012-07-22 16:58:26 EDT
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.
Comment 14 Jiri Popelka 2012-07-23 08:44:02 EDT
(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.
Comment 15 Scott Shambarger 2012-07-27 00:35:02 EDT
(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).
Comment 16 Scott Shambarger 2012-07-27 00:38:24 EDT
NOTE in (1) above is "NOT"...
Comment 17 Scott Shambarger 2012-09-26 18:38:22 EDT
Created attachment 617803 [details]
mixed -P -N mode support for dhclient 4.2.4-P2

Updated for P2
Comment 18 H. Peter Anvin 2012-09-27 23:19:22 EDT
This still does not provide any way to set the requested prefix size, though, correct?
Comment 19 Scott Shambarger 2012-09-28 16:28:35 EDT
The prefix size issue sounds like a different bug... I might take a look at it if you log one :)
Comment 20 H. Peter Anvin 2012-11-15 16:18:19 EST
I have logged the prefix issue as bug 876791.
Comment 21 Scott Shambarger 2012-12-18 17:48:13 EST
Created attachment 665807 [details]
Update dhcp rpm patch for patchlevel 16
Comment 22 Fedora End Of Life 2013-04-03 15:26:12 EDT
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
Comment 23 Jiri Popelka 2013-06-05 04:49:32 EDT
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.
Comment 24 H. Peter Anvin 2013-06-05 11:42:40 EDT
Yes, these problems do exist.  However, there are also ISPs *today* which require the current protocol to get service.
Comment 25 David Beveridge 2013-06-05 17:24:15 EDT
(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
Comment 26 H. Peter Anvin 2013-06-05 17:49:52 EDT
Comcast have mentioned Dibbler to me.
Comment 27 Wolfgang Rupprecht 2013-06-05 18:00:18 EDT
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?
Comment 28 David Beveridge 2013-06-05 21:16:40 EDT
(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.
Comment 29 Scott Shambarger 2014-01-14 15:44:56 EST
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.
Comment 30 Scott Shambarger 2014-01-14 18:24:10 EST
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).
Comment 31 Scott Shambarger 2014-01-14 18:29:15 EST
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)

Note You need to log in before you can comment on or make changes to this bug.