starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 22:03:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Enhancement for Providers: Prefix Delegations #6365

New Issue
Closed
opened 2025-12-29 19:39:53 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:39:53 +01:00
Owner
Copy Link

Originally created by @tsettle on GitHub (Apr 15, 2022).

NetBox version

v3.2.1

Feature type

New functionality

Proposed functionality

Add a new IPAM model called "Delegations" that would function identically to the IPAaddress model, allowing ISPs to document delegated prefixes and assign them to objects in much the same way that IP addresses are assigned.

Use case

Service providers typically delegate prefixes (a /56 to a residential subscriber) to their customers and route those prefixes to the customer's LLA (Link-Local Address). At this point, the delegated prefix is beyond the purview of the ISP, and we cease to care about the 4,722,366,482,869,645,213,696 addresses contained within that prefix.

As an example, if you create a Delegation pool with a /44 prefix, then specify a child prefix length of 56, you would end up with pool of 4096 atomic prefixes. No further division is necessary, nor should it be possible.

The prefixes themselves should be assignable to dcim.interface or similar models. It may require a separate FR, but it would be great if the IPADDRESS_ASSIGNMENT_MODELS constant could be expanded/redefined by a plugin. This would allow for much greater flexibility, as I'm planning a plugin for managing FreeRADIUS and need to be able to associate all these things back to a single object. Reply items, including the IPv4 address and IPv6 prefix assignments are tied to either a mac address or username.

Database changes

New model and relationships, so several, but should be self explanatory.

External dependencies

None that I'm aware of.

Originally created by @tsettle on GitHub (Apr 15, 2022). ### NetBox version v3.2.1 ### Feature type New functionality ### Proposed functionality Add a new IPAM model called "Delegations" that would function identically to the IPAaddress model, allowing ISPs to document delegated prefixes and assign them to objects in much the same way that IP addresses are assigned. ### Use case Service providers typically delegate prefixes (a /56 to a residential subscriber) to their customers and route those prefixes to the customer's LLA (Link-Local Address). At this point, the delegated prefix is beyond the purview of the ISP, and we cease to care about the 4,722,366,482,869,645,213,696 addresses contained within that prefix. As an example, if you create a Delegation pool with a /44 prefix, then specify a child prefix length of 56, you would end up with pool of 4096 atomic prefixes. No further division is necessary, nor should it be possible. The prefixes themselves should be assignable to dcim.interface or similar models. It may require a separate FR, but it would be great if the `IPADDRESS_ASSIGNMENT_MODELS` constant could be expanded/redefined by a plugin. This would allow for much greater flexibility, as I'm planning a plugin for managing FreeRADIUS and need to be able to associate all these things back to a single object. Reply items, including the IPv4 address and IPv6 prefix assignments are tied to either a mac address or username. ### Database changes New model and relationships, so several, but should be self explanatory. ### External dependencies None that I'm aware of.
adam added the type: feature label 2025-12-29 19:39:53 +01:00
adam closed this issue 2025-12-29 19:39:53 +01:00
adam commented 2025-12-29 19:39:54 +01:00
Author
Owner
Copy Link

@tsettle commented on GitHub (Apr 16, 2022):

This might be easier than I first though. Using a boolean in the IPAddress model to mark the object as a delegation would solve my issue of being able to associate the prefix to another object (interface) and, by extension, it's mac-address.

The same boolean should be able to be used to mark the prefix as being 100% utilized, but haven't gotten far enough into the code to see how difficult that would be.

@tsettle commented on GitHub (Apr 16, 2022): This might be easier than I first though. Using a boolean in the IPAddress model to mark the object as a delegation would solve my issue of being able to associate the prefix to another object (interface) and, by extension, it's mac-address. The same boolean should be able to be used to mark the prefix as being 100% utilized, but haven't gotten far enough into the code to see how difficult that would be.
adam commented 2025-12-29 19:39:54 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 16, 2022):

Why can you not create a tenant and create a sub-prefix for this instead?

@DanSheps commented on GitHub (Apr 16, 2022): Why can you not create a tenant and create a sub-prefix for this instead?
adam commented 2025-12-29 19:39:54 +01:00
Author
Owner
Copy Link

@tsettle commented on GitHub (Apr 17, 2022):

@DanSheps That's where I started, but couldn't figure out a way to bind that to an Interface (specifically, a mac-address) in a normalized fashion.

Over the weekend, I've come full circle and figured out that not only can I create the /56 subnet and assign it to the tenant, but I can also create an all-zeros IP address for it, which I absolutely can associate to the Interface, thereby binding it to the MAC address.

It would still be cool to treat larger prefixes with the same atomic logic as a /32 or /128, but may not be worth the effort.

@tsettle commented on GitHub (Apr 17, 2022): @DanSheps That's where I started, but couldn't figure out a way to bind that to an Interface (specifically, a mac-address) in a normalized fashion. Over the weekend, I've come full circle and figured out that not only can I create the /56 subnet and assign it to the tenant, but I can also create an all-zeros IP address for it, which I absolutely can associate to the Interface, thereby binding it to the MAC address. It would still be cool to treat larger prefixes with the same atomic logic as a /32 or /128, but may not be worth the effort.
adam commented 2025-12-29 19:39:55 +01:00
Author
Owner
Copy Link

@tsettle commented on GitHub (Apr 17, 2022):

Is there a "Never Mind" tag/status for this?

@tsettle commented on GitHub (Apr 17, 2022): Is there a "Never Mind" tag/status for this?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#6365
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?