[PATCH RFC v2 0/3] dhclient: add --prefix-len option
sar at isc.org
Wed Dec 2 22:12:04 UTC 2015
> On Dec 2, 2015, at 2:00 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> On 12/02/2015 01:53 PM, Shawn Routhier wrote:
>>> On Dec 2, 2015, at 1:46 PM, H. Peter Anvin <hpa at zytor.com> wrote:
>>> On 12/02/2015 12:47 PM, Shawn Routhier wrote:
>>>> I merged them last night (my time - US PT) so it would depend on when you
>>>> did the pull. I haven’t reviewed your changes yet so it’s possible that there
>>>> aren’t issues, but given the quick look I did on the first patch I think you would
>>>> have noticed.
>>> Yes, in fact looks like we implemented several similar things although
>>> in slightly different ways. Unfortunate timing. I will try to update
>>> the patchset as soon as possible.
>> We are about half way through a release cycle. I’m not sure if we
>> would get your patch into the next release or not. We would definitely
>> put it into our bug system so it wouldn’t get lost.
> For what it's worth, I have run the original version of this patch
> (before I did the refactoring) for almost three years on a Comcast
> network, so it is at least not *completely* bogus :)
>>> RFC 7550 seems to imply that unsatisfied prefix requests should be
>>> repeated in at least a REBIND message, possibly a REQUEST message too?
>> yes, my patch should do that.
> Sure, but if we get an IA_PD delegation for 2001:db8:1234:5678::/64 when
> what we want is a /56, I believe we should include the ::/56 request
> again in those messages, too, in addition to repeating the
> 2001:db8:1234:5678::/64 prefix. My patch currently would drop the
> too-narrow /64 prefix from a SOLICIT message, however.
>> there is also a change to the scoring algorithm to choose leases
>> from different servers (if you actually have two or more dhcp servers
>> to choose from). The new scoring prefers more bindings over more
>> addresses. So a lease with an IA_NA and IA_PD with one address (prefix)
>> each is preferred over a lease with an IA_NA with two addresses.
> We should also penalize the scoring of an IA_PD with a longer prefix
> than we asked for, so if one server offers us a /60 and one a /64 when
> we wanted a /56, we would pick the /60.
Both of these are good ideas and we’ll need to see what we can do with
them. Penalizing the scoring wouldn’t be the right way to go as it could
drop the lease below the minimum required value. Adding a bonus to
a proper sized PD would probably be the right thing but we would need
to figure out the proper values to use.
I’m not sure how much of an issue different PD lengths really is though.
I imagine that most clients are only talking to a single server at a time.
(At home you go to your ISP, at work you go to the work server at the
coffee shop to their server etc) and putting a lot of effort into being able
to choose the “right” pd when you really only get a choice of 1 might not
be the best use of time. (And note that I’d be interested in hearing that
my assumptions about a single server are incorrect. That seems like
the most normal case but maybe there are lots of times it isn’t.)
More information about the dhcp-workers