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

contains for an IPv6 prefix should not also return itself #9774

New Issue
Closed
opened 2025-12-29 21:22:26 +01:00 by adam · 7 comments
adam commented 2025-12-29 21:22:26 +01:00
Owner
Copy Link

Originally created by @ChrisHills463 on GitHub (May 31, 2024).

Deployment Type

Self-hosted

NetBox Version

v4.0.3-2.9.1 (docker.io/netboxcommunity/netbox)

Python Version

3.11

Steps to Reproduce

  1. Create a prefix 2001:16d8::/48
  2. Create a prefix 2001:16d8:0:ffff::/64
  3. Fetch GET /api/ipam/prefixes/?contains=2001:16d8:0:ffff::/64

Expected Behavior

There should be one result, 2001:16d8::/48

Observed Behavior

There are two results, 2001:16d8::/48 and 2001:16d8:0:ffff::/64.

I believe the behaviour is caused by the (searched-for) prefix being interpreted as an address rather than a prefix, but for IPv6 this does not make sense. Ideally it should be possible to directly reference the parent prefix of an IPv6 prefix, but without a suitable member (e.g. parent_prefix) it seems the only alternative is to rely on contains().

Originally created by @ChrisHills463 on GitHub (May 31, 2024). ### Deployment Type Self-hosted ### NetBox Version v4.0.3-2.9.1 (docker.io/netboxcommunity/netbox) ### Python Version 3.11 ### Steps to Reproduce 1. Create a prefix `2001:16d8::/48` 2. Create a prefix `2001:16d8:0:ffff::/64` 3. Fetch `GET /api/ipam/prefixes/?contains=2001:16d8:0:ffff::/64` ### Expected Behavior There should be one result, `2001:16d8::/48` ### Observed Behavior There are two results, `2001:16d8::/48` and `2001:16d8:0:ffff::/64`. I believe the behaviour is caused by the (searched-for) prefix being interpreted as an address rather than a prefix, but for IPv6 this does not make sense. Ideally it should be possible to directly reference the parent prefix of an IPv6 prefix, but without a suitable member (e.g. `parent_prefix`) it seems the only alternative is to rely on `contains()`.
adam added the type: bug label 2025-12-29 21:22:26 +01:00
adam closed this issue 2025-12-29 21:22:26 +01:00
adam commented 2025-12-29 21:22:27 +01:00
Author
Owner
Copy Link

@ChrisHills463 commented on GitHub (May 31, 2024):

One more thing to add, if you want to find the parent prefix for an IPv6 address, I would suggest either omitting the prefix value (e.g 2001:16d8:0:ffff::), or using /128 as the prefix value (e.g. 2001:16d8:0:ffff::/128).

@ChrisHills463 commented on GitHub (May 31, 2024): One more thing to add, if you want to find the parent prefix for an IPv6 address, I would suggest either omitting the prefix value (e.g `2001:16d8:0:ffff::`), or using `/128` as the prefix value (e.g. `2001:16d8:0:ffff::/128`).
adam commented 2025-12-29 21:22:27 +01:00
Author
Owner
Copy Link

@ChrisHills463 commented on GitHub (May 31, 2024):

Something else to watch out for, if the parent prefix also has a parent prefix, then this will also be included. It seems that there is no way to get the parent prefix for a prefix directly; the client has to work it out for themselves to some extent.

E.g. for the following hierarchy:-

  • 2001:16d8::/32
    • 2001:16d8:ffff::/48
      • 2001:16d8:0:ffff::/64

If we call GET /api/ipam/prefixes/?contains=2001:16d8:0:ffff::/64 then all three prefixes are returned.

@ChrisHills463 commented on GitHub (May 31, 2024): Something else to watch out for, if the parent prefix also has a parent prefix, then this will also be included. It seems that there is no way to get the parent prefix for a prefix directly; the client has to work it out for themselves to some extent. E.g. for the following hierarchy:- - `2001:16d8::/32` - `2001:16d8:ffff::/48` - `2001:16d8:0:ffff::/64` If we call `GET /api/ipam/prefixes/?contains=2001:16d8:0:ffff::/64` then all three prefixes are returned.
adam commented 2025-12-29 21:22:28 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jun 3, 2024):

To make the second prefix nest beneath the first, the second needs specifying as 2001:16d8:0:ffff::/48. Would you please update the issue body accordingly? Once I make that change, I do see the described problem behavior.

@jeffgdotorg commented on GitHub (Jun 3, 2024): To make the second prefix nest beneath the first, the second needs specifying as `2001:16d8:0:ffff::/48`. Would you please update the issue body accordingly? Once I make that change, I do see the described problem behavior.
adam commented 2025-12-29 21:22:28 +01:00
Author
Owner
Copy Link

@ChrisHills463 commented on GitHub (Jun 4, 2024):

To make the second prefix nest beneath the first, the second needs specifying as 2001:16d8:0:ffff::/48. Would you please update the issue body accordingly? Once I make that change, I do see the described problem behavior.

Fixed! Sorry about that.

@ChrisHills463 commented on GitHub (Jun 4, 2024): > To make the second prefix nest beneath the first, the second needs specifying as `2001:16d8:0:ffff::/48`. Would you please update the issue body accordingly? Once I make that change, I do see the described problem behavior. Fixed! Sorry about that.
adam commented 2025-12-29 21:22:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 4, 2024):

There are two results, 2001:16d8::/48 and 2001:16d8:0:ffff::/64.

This is the intended behavior: The contains filter invokes the prefix__net_contains_or_equals lookup, which returns any exact matching prefix or longer. This functionality has been in place for years and is well-established.

@jeremystretch commented on GitHub (Jun 4, 2024): > There are two results, 2001:16d8::/48 and 2001:16d8:0:ffff::/64. This is the intended behavior: The `contains` filter invokes the `prefix__net_contains_or_equals` lookup, which returns any exact matching prefix or longer. This functionality has been in place for years and is well-established.
adam commented 2025-12-29 21:22:29 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jun 4, 2024):

Thanks for weighing in, @jeremystretch. Thanks for reporting, @ChrisHills463 – I initially found the behavior confusing as well.

@jeffgdotorg commented on GitHub (Jun 4, 2024): Thanks for weighing in, @jeremystretch. Thanks for reporting, @ChrisHills463 – I initially found the behavior confusing as well.
adam commented 2025-12-29 21:22:29 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jun 4, 2024):

Behavior is as designed. Resolving as not planned.

@jeffgdotorg commented on GitHub (Jun 4, 2024): Behavior is as designed. Resolving as not planned.
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: bug
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#9774
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?