When requesting a DHCPv6 prefix from some ISPs, e.g. Comcast, if one needs more than one /64 one needs to request this in the DHCPv6 query. This is done by inserting a OPTION_IAPREFIX suboption containing only a prefix length and the actual prefix all zero (see RFC 3633). Right now dhclient will include an already-delegated prefix as an OPTION_IAPREFIX, but will not allow the length to be specified nor will it issue one unless a prefix has already been delegated.
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
Update: I've tried modifying the lease file to create an empty ::/60 prefix, but dhclient appears to ignore the existing prefix then. I tested wide-dhcpv6 with a prefix of "::/60" in the "id-assoc pd" section of the config file, and it includes a prefix-option (option 26) of 0::/60 in the solicit, which works (as a "hint"). Probably need to find a way to include such a option in dhclient if there are no existing leases -- a new config option perhaps?
Created attachment 850071 [details] Proof of concept patch. Probably not for production. I have used this patch against Comcast for some time with success. It is ugly as hell and probably a bit out of date, but at least it could be used as a starting point.
The idea with the patch is that if we need a specific prefix length, we will request only existing leases that are that short or shorter, or ::/len if there are none left.
FYI, tried the patch out... doesn't do anything on existing leases (different code path :), but I nuked the lease file and successfully received a /60 prefix. Looks good :)
Created attachment 850891 [details] Updated patch to include config option OK, totally untested (but compiles). Updated parameter parsing (now --max-prefix), added man page text, and added a (global|per-interface) config option, that way it can be used with systems where you can't control the parameter list (eg NetworkManager :) Option: make parameter/config max-prefix6?
Maybe this is just me, but I'd think you'd want to be able to say (for example): "I'd love a /48, but I'll take anything between that and a /64" (whereas if you don't even mention that you'd do something with a /48, you'd get a /64). Software can then decide what to do with what it gets...if there aren't enough bits to partition the network for all the downstream interfaces, then it doesn't allocate to all the interfaces it would have, but giving addresses to some is better than none (or could be).
Well, technically speaking what you send to the server is considered a "hint", and the server may indeed return something narrower. So you may very well get a /64 back if you request a /48. What I have in my personal script that distributes the prefix to downstream interfaces is that I will assign /64 prefixes until they run out. Anything beyond that would require changes to the protocol.
Ah, ok. I interpreted the proposed config setting name to imply that the client would reject/release the prefix if it wasn't short enough.
That might be a valid option to have, too. "Don't accept an offer for a prefix longer than foo", but that is definitely different from "ask for a prefix at least bar".
http://archive.mgm51.com/sources/pd-pref.html
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This feature is now supported in ISC DHCP 4.4.0, so upgrading to that upstream package will resolve this bug.
(In reply to H. Peter Anvin from comment #13) > This feature is now supported in ISC DHCP 4.4.0, so upgrading to that > upstream package will resolve this bug. https://lists.isc.org/pipermail/dhcp-users/2018-February/021164.html
dhcp-4.4.1 is in rawhide. can you please check if it solves the problem?
dhcp-4.4.1 is landed in rawhide few weeks ago. Not going to push it to stable repos. closing