Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. DHCPv6 - multiple addresses from different prefixes (Tj)
2. Re: best practice for fixed-address / reserved leases
(glenn.satch...@uniq.com.au)
3. Re: best practice for fixed-address / reserved leases
(Simon Hobson)
4. Re: DHCPv6 - multiple addresses from different prefixes
(Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Sun, 3 Jan 2021 12:08:00 +0000
From: Tj <ml.isc@elloe.vision>
To: dhcp-users@lists.isc.org
Subject: DHCPv6 - multiple addresses from different prefixes
Message-ID: <ed180c54-98bc-85c6-d0a1-1ee486d97553@elloe.vision>
Content-Type: text/plain; charset=utf-8
We've been attempting to assign multiple IPv6 addresses, each from a
different prefix, as descried in RFC8415 6.6 "Multiple Addresses and
Prefixes".
With "dhclient -6 -N -N" the clients can request multiple addresses.
However it appears there is no way to write a dhcpd6.conf to achieve
this. Multiple 'subnet6' in a 'shared-network' issues all addresses from
the first 'subnet6' (and from reading source-code and docs will do that
until the first range is exhausted).
There's a note in ./server/dhcpv6.c:
* TODO: support multiple shared_networks on each interface (this
* will allow the server to issue multiple IPv6 addresses to
* a single interface)
So we assume this was thought of but not implemented, at least via
'shared-network'.
We tried adding two 'shared-network' blocks, one for each prefix, but
only the last is acted on.
As the RFC says, one use-case is when a network is being renumbered. In
our use-case we need to issue ULAs (fd00::/8) and one or more globally
routable prefixes.
Is there a way to do this? If not is Kea currently capable of this (from
reading the docs and Wiki it looks like Kea has the same problem as dhcpd) ?
That seems to leave us with a couple of options:
1. Switch to a server than can (possibly Dhcpy6d)
2. Patch dhcpd
a. add support for multiple shared-networks (big job)
b. hack pick_v6_address() to always increment pond->last_ipv6_pool via
'i' as is done for attempts > 1 which would work if the client requests
the same number of addresses as there are 'subnet6' blocks and ranges.
Are there other options we've missed?
Tj
------------------------------
Message: 2
Date: Mon, 04 Jan 2021 11:04:47 +1100
From: glenn.satch...@uniq.com.au
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: best practice for fixed-address / reserved leases
Message-ID: <088e116dd3ef2e8fc5bbbdd6c0a16...@uniq.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Michael,
One other alternative to a reserved lease (which is essentially infinite
time) could be to set a very long lease, say a few months or 1 year -
just make it a longer than any amount of time the system might be not on
the network.
This can be done in dhcpd.conf, in this case a dynamic address from the
pool is assigned. If there were a few of these they could be put in a
group{} or a class.
host foo {
hardware ethernet aa:bb:cc:dd:ee:ff;
# 1 year in seconds
min-lease-time 31536000;
}
class "long" {
match pick-first-value (option dhcp-client-identifier, hardware);
min-lease-time 31536000;
}
subclass "long" 1:aa:bb:cc:dd:ee:ff; # repeat for more devices
The other advantage here is that if the device is permanently removed
from the network, eventually the lease will expire and be available for
re-use by other systems.
regards,
Glenn
On 2020-12-31 11:31, Michael Schnyder wrote:
> Bill, Simon: Many thanks for the answers, both: The short and the long
> version!
> I'm glad to read all that and it helps to explain why we use that
> "best practice". It's perfect to also get a better understanding of
> the difference between the ISC server and the Windows service, as
> exactly that is to be explained most of the time.
>
> PS: Good that you mentioned it, Bill: This was a really bad example
> with subnet and addresses not being part of the RFC 1918 range.
> Please: Do not copy/paste this example into your environment. I just
> wrote down some "numbers" (even with a mistake). Important to me was
> to show that the fixed-address is outside the defined range.
>
> Very much appreciated,
> Michael
>
> ?On 30.12.20, 22:22, "dhcp-users on behalf of Simon Hobson"
> <dhcp-users-boun...@lists.isc.org on behalf of dh...@thehobsons.co.uk>
> wrote:
>
> Bill Shirley <b...@c3po.polymerindustries.biz> wrote:
>
> > Fixed addresses should NOT be in any range. It's possible for
> DHCP to assign that address
> > before the device with that fixed address gets it.
>
> To expand on that a bit ...
>
> The ISC server (and I'm talking dhcpd here, not Kea which I'm not
> familiar with) is very different to the Windows service many people
> are familiar with. With the Windows service, your fixed addresses are
> part of the range (which is usually defined as the whole of the usable
> subnet with sections reserved so they aren't used). With the ISC
> server the fixed addresses are treated somewhat differently to dynamic
> clients and the server makes no attempt whatsoever to exclude them
> from the dynamic ranges - so as Bill says, it's entirely possible for
> a dynamic client to be given the address.
>
> But you may be thinking that this would be hard to do - after all,
> the fixed address device has it leased to it doesn't it ? Well no it
> doesn't - the ISC server does not track address status for fixed
> address assignments - in theory it doesn't need to. Simply put, the
> admin has said that there's a one-one mapping between that address and
> a device - so it can only ever be leased to that device, and it really
> doesn't matter about keeping lease state for it. So there is no lease
> record kept - the server just bypasses all of that.
> So when a dynamic client comes along for a lease, and according to
> whatever rules are in place (more on that later), that fixed address
> happens to be the one selected for the dynamic client - then it will
> be selected. If the fixed address devices is offline at the time OR it
> is configured to not respond to pings OR the server is configured not
> to do it's "ping before offer" check - then the address will be leased
> to the client and you now have an address collision. That "ping before
> offer" is your safety net in these cases, it defaults to on, and if
> the device is both online and replies to a ping, then the server will
> flag the dynamic lease as abandoned and it won't be offered to
> anything again (except the fixed address device) unless there really
> is nothing left to offer.
>
> Now, about that address selection policy ?
> Here is another big difference from the Windows service. From
> memory, the Windows service tends to allocate addresses from the
> bottom of the available pool - and will happily re-allocate an address
> when it's not in use. So if you have a fixed address high up in the
> range, it may be a long time (or even never) before your dynamic
> assignments get up to it. In the Windows world, a lot of what is
> supposed to happen at the server end according to the RFCs is actually
> fudged by making the clients very clingy to their previously leased
> address.
> With the ISC server, dynamic address assignment is done very
> differently, and follows these rules - always following any allow/deny
> conditions attached to a pool. The address offered will be the first
> found of :
> 1) A previously never used address - working (as an undocumented
> and not guaranteed to not change without warning implementation
> detail) top-down in a list of all addresses available to be given to
> the client.
> 2) If there are no "never used" addresses, then a free lease (i.e.
> one that's expired or been released by the client) working on a least
> recently used basis.
> Under normal operations, these will be the only cases used. By
> default, the server will ping an address before it offers it to the
> client - if it gets a reply then it will mark the lease as abandoned,
> after which it will never get selected again unless ...
> 3) If there are no free leases to be offered, but there are
> abandoned ones, then it will try one of the abandoned ones - if it
> gets no reply to a ping then it will change it to free and then offer
> it to the client as in 2) above.
>
> There's also something about leases made to bootp clients. IIRC,
> because bootp doesn't have a concept of lease time, all such leases
> are infinite and can't be re-allocated.
>
> Reading the above, you can probably see why most people have no
> problem most of the time - to the extent that I've seen some "rather
> poor" advice in the past. In one case I recall, someone offered a
> script that monitored the dhcp logs, detected when you plugged in an
> IP phone, then added a fixed-IP statement (within a host record) for
> that device to the dhcp config, and configured the IP PBX to use the
> new device. I had a discussion with the author of the script who
> declared "so ping will fix it, no problem, nothing to fix".
> IFF ping before offer is left on AND the device responds to pings
> AND it is online when it's address first gets picked for a dynamic
> clients - THEN the address will be abandoned, and IFF you never run
> out of free addresses then you won't have a problem.
> MOST of the time that will be the case, but it's not 100%
> guaranteed to work, and when it doesn't then you can get some
> "interesting" issues.
>
> So there's the detail as to why you should NEVER configure a
> fixed-address that is within a dynamic range. Stick to that rule and
> you won't have a problem with it, break it and you probably won't have
> a problem - but when you do it'll be a long time down the road and
> cause you some head scratching.
>
>
> For completeness, you may have spotted a little detail implied by
> the "bypasses the normal lease processing" bit above. That also means
> there are no DNS updates done for fixed-addresses - you'd normally
> manually configure the DNS, and you can use a DNS name in place of the
> IP address in the DHCP config. You can configure the server to do DNS
> updates for fixed-addresses - but then it will blindly do them EVERY
> time a fixed address requests or renews a lease (performance issue),
> and it will never remove them (you'll have to manually remove them).
>
>
>
>
> BTW - there is an alternative to fixed-addresses. If you create a
> skeleton lease (which must be within a range) and mark it as reserved,
> or add a line to an existing lease record, then that lease will be
> reserved to that client. In practical terms, this means the lease goes
> through the normal lease cycles including adding/removing the DNS
> records as the lease becomes active or free. The only difference is
> that when in the free state, the address cannot be re-allocated to
> another client.
> You can either manually edit the leases file while the server is
> shut down, or I believe it can be done via OMAPI.
>
> On the upside, such reserved addresses work the same way as
> dynamic addresses, just with the address being tied to a client in the
> same way as "fixed-address" does. And they can be within a dynamic
> range - making it easy to plug a device in, see what address it gets,
> and simply mark that lease as reserved.
> On the downside, they don't appear anywhere in the config - the
> only place to see them is in the leases database (or with tools that
> will parse the leases database for you).
>
> A dynamic lease configured as "reserved" is much closer in
> operation to the reserved addresses in the Windows DHCP service.
>
>
> Simon
>
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 3
Date: Mon, 4 Jan 2021 09:06:10 +0000
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: best practice for fixed-address / reserved leases
Message-ID: <11b39cb7-11d9-49ec-8baf-c386b641c...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
glenn.satch...@uniq.com.au wrote:
> One other alternative to a reserved lease (which is essentially infinite
> time) could be to set a very long lease, say a few months or 1 year - just
> make it a longer than any amount of time the system might be not on the
> network.
...
> The other advantage here is that if the device is permanently removed from
> the network, eventually the lease will expire and be available for re-use by
> other systems.
That's a neat idea, never thought of that.
But if a client releases it's lease (e.g. on shutdown), doesn't that break the
idea by setting the lease to free ? Or does it retain it's "year in the future"
end time and thus go a long way down the list of leases when it comes to
finding a free one for a new client ?
Simon
------------------------------
Message: 4
Date: Mon, 4 Jan 2021 09:23:34 +0000
From: Simon Hobson <si...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCPv6 - multiple addresses from different prefixes
Message-ID: <29d30f2c-f048-4823-9597-eabadfc74...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Tj <ml.isc@elloe.vision> wrote:
> However it appears there is no way to write a dhcpd6.conf to achieve
> this. Multiple 'subnet6' in a 'shared-network' issues all addresses from
> the first 'subnet6' (and from reading source-code and docs will do that
> until the first range is exhausted).
The only thing I can think of would be to write a script that created dummy
leases for all addresses in each prefix - interleaving them. That way, when teh
server is allocating an address, there's no "never used before" addresses, so
it will then reallocate a previously used address. As this latter stage is done
"least recently used" first, the addresses allocated would then be interleaved.
It wouldn't be a guarantee once all the addresses had been used since then it
would be pseudo-random and clients could get addresses all from one range, all
from another, or any combination depending on when they were last used.
A bit of a fudge, but it would work. And if your ranges are large enough that
you never actually use all the addresses, it would effectively work for a long
time. The danger is that you get used to it working, and ina few years time
no-one remembers why it works - and then it breaks leaving you scratching your
heads in frustration !
Simon
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 147, Issue 1
******************************************
