IP address ranges

[candlerb]

Feature idea: support for explicit "IP ranges"

An IP range would have a start address and an end address attribute, a name, and a VRF. It would be independent from IP prefixes.

Use case 1: documentation of ranges within a prefix. For example, in our current dumb spreadsheet we have assigned logical ranges for user assignment

• 10.10.2.151 - 10.10.2.160 : Tester range
• 10.10.2.180 - 10.10.2.253 : Admin/Developer range

and I prefer not to lose that information when moving to Netbox.

Use case 2 (related to #761): a cleaner way of defining IP pools, rather than enumerating all addresses within a range and setting their status individually to "DHCP Pool". The current model wouldn't work very well if you wanted a large IPv6 pool. Also, generating a DHCP config from this involves iterating over all the addresses and collecting adjacent ones together to form a single range, which is messy.

Use case 2a: for redundancy you have two DHCP servers on a subnet with separate ranges, e.g. DHCP1 has pool .50-.149 and DHCP2 has pool .150-.249

Use case 3 (related to #665): be able to automatically assign the next available address from within a specific range. For example: suppose your address plan for a /24 reserves .1-.9 and .250-.254 for infrastructure. So you define a named range .10-.249 and then on demand assign the next available address from within that range. This would be particularly helpful for automatic assignment via an API.

This last case can also be handled by marking addresses unused addresses in the .1-.9 and .250-.254 ranges as status "reserved". That may be reasonable for IPv4, but might not work well for IPv6, e.g. if your plan had

• ::0 to ::fff - reserved for infrastructure
• ::1000 to ::ffff - available for assignment

It also doesn't let you assign from two or more ranges within the same prefix - e.g. going back to use case 1, "assign next Tester address" or "assign next Admin/Developer address"

[jeremystretch]

Let's assume have defined 192.0.2.100 through 192.0.2.199 (inclusive) as a DHCP pool. How would you handle a scenario where 192.0.2.123 has become statically assigned and needs to be removed from the pool?

The current model wouldn't work very well if you wanted a large IPv6 pool.

Why wouldn't it work? (I've never used DHCPv6.)

Also, generating a DHCP config from this involves iterating over all the addresses and collecting adjacent ones together to form a single range, which is messy.

The netaddr library (which NetBox uses for IP calculations) makes this super easy.

[candlerb]

Let's assume have defined 192.0.2.100 through 192.0.2.199 (inclusive) as a DHCP pool. How would you handle a scenario where 192.0.2.123 has become statically assigned and needs to be removed from the pool?

Well, I can think of two scenarios.

1. The statically assigned address is already known to the DHCP server (e.g. via a fixed MAC address to IP address mapping). In this case there is no need to shrink the pool, it can still span the assigned address [^1]

2. The statically assigned address was was someone stupidly putting a statically-assigned piece of equipment in the middle of a DHCP pool. In this case your options are:

   2a. Same as 1: tell the DHCP server about the static allocation. It should be fine to skip it.
   2b. At worst, split the pool into two pools:

   range 192.0.2.100 192.0.2.122;
   range 192.0.2.124 192.0.2.199;
   

But this doesn't mean you need to create two separate "IP Range" objects in the database.

Let's assume the worst case, and your DHCP server does not support reserving individual addresses. Then, when generating the config, you read out an IP Range object from the database, covering the range 192.0.2.100 to 192.0.2.199

You then also query the database for all Active IP objects which sit within the range. Suppose you find 192.0.2.123 and 192.0.2.150. Then you can easily output the broken-up ranges:

• 192.0.2.100 to 192.0.2.122
• 192.0.2.124 to 192.0.2.149
• 192.0.2.151 to 192.0.2.199

The only difference between this and the current model is:

• In the current model you create all addresses from 192.0.2.100 to 192.0.2.199 with status "DHCP Pool", and then change .123 and .150 to status "Active"
• In the range model, you create a range from 192.0.2.100 to 192.0.2.199, and create .123 and .150 with status "Active", or a new status like "DHCP Excluded"

The current model wouldn't work very well if you wanted a large IPv6 pool.

Why wouldn't it work? (I've never used DHCPv6.)

If you want a pool from 2001:db8::1000 to 2001:db8::1fff, you need to add 4,096 separate entries into your database. If you want a pool from 2001:db8::1000 to 2001:db8::ffff, you need to add 64,512 database records.

This is an inefficient way to represent a pool, and will badly clutter the user interface.

Also, generating a DHCP config from this involves iterating over all the addresses and collecting adjacent ones together to form a single range, which is messy.

The netaddr library (which NetBox uses for IP calculations) makes this super easy.

It still involves a large database query to read all the addresses where status = DHCP Pool.

---

[^1] At least, I'm pretty sure this works for sane DHCP servers like ISC dhcpd.

The documentation says:

Any IPv6 addresses given to hosts with fixed-address6 are excluded from the range6, as are IPv6 addresses on the server itself.

Admittedly, I can't see an equivalent statement for an ipv4 range, but I very much doubt it allocates a fixed-address to any random device. I've not tested it though. I use static mappings for DHCP all the time, but I pick addresses outside of the pool for clarity.

[candlerb]

You then also query the database for all Active IP objects which sit within the range. Suppose you find 192.0.2.123 and 192.0.2.150. Then you can easily output the broken-up ranges

Oh, and this is super-easy too :-)

>>> s = netaddr.IPSet(netaddr.IPRange('192.0.2.100','192.0.2.199'))
>>> list((s - netaddr.IPSet(['192.0.2.123','192.0.2.150'])).iter_ipranges())
[IPRange('192.0.2.100', '192.0.2.122'), IPRange('192.0.2.124', '192.0.2.149'), IPRange('192.0.2.151', '192.0.2.199')]

[jeremystretch]

Same as 1: tell the DHCP server about the static allocation.

NetBox is responsible for telling the DHCP server about the allocation. It should be possible to generate a DHCP server configuration from scratch using only the information available in NetBox (at least, that's the philosophy).

The implementation of IP ranges boils down to incurring additional processing logic at read time versus additional storage in the database. At the moment, I don't think the trade-off is worth it for IPv4 alone: It's usually going to be safer and more efficient to store discrete IPs directly, rather than storing a range, converting it to discrete IPs, and coalescing it with other ranges and/or sets of IPs. It may be worthwhile given the potentially overwhelming size of IPv6 pools, but that doesn't seem like it'd be a very common use case. Specifically, we're talking about a scenario wherein a) DHCPv6 is in use rather than SLAAC, and b) pools much larger than their IPv4 equivalents are required.

[candlerb]

a) DHCPv6 is in use rather than SLAAC

SLAAC is an operational nightmare, due to constantly-changing privacy addresses. DHCPv6 addresses stick with the client for as long as it has a lease. Hence I disable SLAAC everywhere and use DHCPv6 exclusively.

b) pools much larger than their IPv4 equivalents are required.

In a campus network, an IPv4 pool of /22 (of private IPs) is fairly reasonable for a wifi network where users are constantly walking in and out of range, and you don't want to use a ridiculously low lease time. You might have a subnet like that per building.

For IPv6, a pool from ::1000 to ::1fff is a reasonable minimum to avoid any risk of pool exhaustion.

[explody]

I'll chime in that I don't think this is purely a v4 vs v6 (i.e. quantity of IPs) issue. IMHO, it's about manageability of IPs inside of subnet boundaries.

Let's assume have defined 192.0.2.100 through 192.0.2.199 (inclusive) as a DHCP pool. How would you handle a scenario where 192.0.2.123 has become statically assigned and needs to be removed from the pool?

Tell whichever engineer not to allocate IPs from a DHCP range ;)
At some point though, one can't wholly protect a system from someone who can write to it. More realistically though, you could disallow assignment of IPs from a defined range.

The netaddr library (which NetBox uses for IP calculations) makes this super easy.

Regarding this - netaddr is great, but consider @candlerb's example of multiple assignments inside a range of IPs one is trying to build into a DHCP range - there's no beginning or end to the range, so how do you validate if the assignment is supposed to be inside the "range"? As shown, one ends up with N DHCP pools, fractured against the "rogue" assigned IPs, instead of one well-defined, construct with contiguous member IPs. Generating and managing configs from data like this is what scares me - not IP calculations. ( also, how do you know the clients are even python? ;) )

All this being said, I'm not 100% sure that we must have ranges as described, but I am certain that there isn't enough metadata about addresses, by default, to work around their absence. For example, we can derive this about an address:

• Status (includes one "DHCP" option)
• Whether it's assigned to an interface or not
• Role (not useful in this context unless it were expanded to more roles)

In our case, to at least distinguish between DHCP reservation ranges and dynamic ranges, we have modified the Status options so we can represent IPs in more states than currently available. So now, we have "DHCP dynamic" and "DHCP reservation" and I rely on trout-slapping my engineers if they hand out IPs with the wrong status - it solves one problem for our case but monkeypatching isn't a great pattern.

Ranges, in contrast, would be multifunction - they can define series of IPs that should or should not be used for any particular purpose, and could potentially affect behavior (read-only ranges) or hold more data about their member IPs without cluttering the Address model. I'd envision them as many-to-one from address to range - no nesting, no membership in multiple ranges, no range overlaps, keep the queries low and keep changes to the address model to a minimum.

For some completely different angles:,

• Tagging could_almost_ achieve the same thing while being entirely freeform, and still pushing most logic out to the consumer (e.g. "Status: DHCP Tags: Dynamic" or "Status: Reserved Tags: Infrastructure").
• Make Statuses and Roles user-extensible - perhaps combos of customizable fields would obviate needing additional constructs (and would be way faster than custom fields)

If any of these approaches are appealing, I'm happy to invest work on them.

[Wouter0100]

I'm also in search for such a feature, where I'm able to easily assign a range of IP adresses to machines without creating all of them (especially for IPv6).

For example, when a customer leases an additional IP subnet, I'd like to assign all those IP's to his interface (except the gateway) so they show up as "reserved" or "active" and count towards my utilization.

Currently I use the import feature to import a handcrafted CSV list, which adds the IPv4 addresses and links it with the interface - but for IPv6 this isn't really an option..

[sajaltiwari]

+1
We need this feature for reserving some ip for ex: broadcast ip and Network IP.
If we reserve an IP, other user can change it by mistake.