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

Link Between IPv4 Prefix And IPv6 Prefix #4540

New Issue
Closed
opened 2025-12-29 18:37:06 +01:00 by adam · 18 comments
adam commented 2025-12-29 18:37:06 +01:00
Owner
Copy Link

Originally created by @rabin-io on GitHub (Feb 8, 2021).

Environment

  • Python version: Python 3.6.8 (CentOS 8 Stream)
  • NetBox version: v2.9.10

Proposed Functionality

An option to link an IPv4 prefix to IPv6 prefix.

Use Case

In PHP-IPAM we had this option to link between IPv4 and IPv6 prefixes,
as we started using more IPv6 in our networks, and we run in dual-stack
(meaning the hosts and services are accessible by IPv4 and IPv6 address),
So we had to keep track which IPv6 prefix we assigned to which IPv4 prefix (you can see an example pictures below)

Database Changes

Not sure.

External Dependencies

Not sure.

Originally created by @rabin-io on GitHub (Feb 8, 2021). ### Environment * Python version: Python 3.6.8 (CentOS 8 Stream) * NetBox version: v2.9.10 ### Proposed Functionality An option to link an IPv4 prefix to IPv6 prefix. ### Use Case In PHP-IPAM we had this option to link between IPv4 and IPv6 prefixes, as we started using more IPv6 in our networks, and we run in dual-stack (meaning the hosts and services are accessible by IPv4 and IPv6 address), So we had to keep track which IPv6 prefix we assigned to which IPv4 prefix (you can see an example pictures below) ### Database Changes Not sure. ### External Dependencies Not sure.
adam added the type: featurepending closurestatus: under review labels 2025-12-29 18:37:06 +01:00
adam closed this issue 2025-12-29 18:37:06 +01:00
adam commented 2025-12-29 18:37:07 +01:00
Author
Owner
Copy Link

@ypid commented on GitHub (Feb 8, 2021):

Aren’t both prefixes assigned to the same VLAN in reality which implicitly links them?

@ypid commented on GitHub (Feb 8, 2021): Aren’t both prefixes assigned to the same VLAN in reality which implicitly links them?
adam commented 2025-12-29 18:37:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 8, 2021):

An option to link IPv4 prefix to IPv6 prefix.

This needs much more detail to be worthy of discussion. Please extend your issue to elaborate on what specific changes you are proposing.

@jeremystretch commented on GitHub (Feb 8, 2021): > An option to link IPv4 prefix to IPv6 prefix. This needs _much_ more detail to be worthy of discussion. Please extend your issue to elaborate on what specific changes you are proposing.
adam commented 2025-12-29 18:37:07 +01:00
Author
Owner
Copy Link

@rabin-io commented on GitHub (Feb 10, 2021):

This is an option we have with phpIPAM and it is very simple but very helpful in my opinion. You can link one subnet to another, it's nothing fancy just a pointer to another subnet id, but it gives you a better view of which address are used on each segment.

As you can see in the screen shot

2021-02-10_00-30

2021-02-10_00-37

@ypid , I didn't check the VLAN option, not sure it's the same

@rabin-io commented on GitHub (Feb 10, 2021): This is an option we have with [phpIPAM](https://phpipam.net/) and it is very simple but very helpful in my opinion. You can link one subnet to another, it's nothing fancy just a pointer to another subnet id, but it gives you a better view of which address are used on each segment. As you can see in the screen shot ![2021-02-10_00-30](https://user-images.githubusercontent.com/5116363/107437229-55b17a80-6b37-11eb-88f7-dabef23b38a8.png) ![2021-02-10_00-37](https://user-images.githubusercontent.com/5116363/107437771-264f3d80-6b38-11eb-90fc-a5b116e27563.png) @ypid , I didn't check the VLAN option, not sure it's the same
adam commented 2025-12-29 18:37:07 +01:00
Author
Owner
Copy Link

@ypid commented on GitHub (Feb 10, 2021):

@ypid , I didn't check the VLAN option, not sure it's the same

Not the same but it can solve your issue. Check it out :)

@ypid commented on GitHub (Feb 10, 2021): > @ypid , I didn't check the VLAN option, not sure it's the same Not the same but it can solve your issue. Check it out :)
adam commented 2025-12-29 18:37:07 +01:00
Author
Owner
Copy Link

@rabin-io commented on GitHub (Feb 10, 2021):

Not the same but it can solve your issue. Check it out :)

I see, not the same but usable I guess :)

Currently I do not use VLAN's on these networks, So I do not know if I want to solve the problem this way, Because it means I'm declaring something that does not exist, And I'm afraid it might come back and bite me in the ass in the future 😅

@rabin-io commented on GitHub (Feb 10, 2021): > Not the same but it can solve your issue. Check it out :) I see, not the same but usable I guess :) Currently I do not use VLAN's on these networks, So I do not know if I want to solve the problem this way, Because it means I'm declaring something that does not exist, And I'm afraid it might come back and bite me in the ass in the future 😅
adam commented 2025-12-29 18:37:08 +01:00
Author
Owner
Copy Link

@ypid commented on GitHub (Feb 10, 2021):

Ah, so IaaS or similar I assume. Then maybe don’t fake the VLAN because NetBox is meant to replicate the real world. I thought you might actually use VLANs. Then consider using tags.

Also, you really should update your initial comment. More details are needed.

@ypid commented on GitHub (Feb 10, 2021): Ah, so IaaS or similar I assume. Then maybe don’t fake the VLAN because NetBox is meant to replicate the real world. I thought you might actually use VLANs. Then consider using tags. Also, you really should update your initial comment. More details are needed.
adam commented 2025-12-29 18:37:08 +01:00
Author
Owner
Copy Link

@rabin-io commented on GitHub (Feb 10, 2021):

Hopefully yes, but tagging is defiantly not the right way ;)

@rabin-io commented on GitHub (Feb 10, 2021): Hopefully yes, but tagging is defiantly not the right way ;)
adam commented 2025-12-29 18:37:08 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 11, 2021):

I can see what you want here. You basically want a way of grouping IP subnets (IPv4 & IPv6) into one "network" (example could be vlans or a point-to-point network on a layer 3 interface).

We already have the vlan piece in place, we could just add a "related subnets" field in the UI to show the related subnets within the vlan. However this falls down when you use a strictly L3 connection between two devices or any other use case. Perhaps a "IP Group" option might be needed or similar.

Another alternative would be using sites to link like subnets together. However the blast radius is pretty large on that (you could have multiple prefixes within a site).

Currently the tools are that could be used to model this are:

  • VLAN
  • Site
  • Role

Please re-adjust your FR to propose a solution that suits your needs as well as include detailed use-cases where you can't replicate the functionality with existing tools or use the existing tools listed above to get the desired results (example, when a prefix is in the same site and has the same role, "link" them together as related prefixes).

@DanSheps commented on GitHub (Feb 11, 2021): I can see what you want here. You basically want a way of grouping IP subnets (IPv4 & IPv6) into one "network" (example could be vlans or a point-to-point network on a layer 3 interface). We already have the vlan piece in place, we could just add a "related subnets" field in the UI to show the related subnets within the vlan. However this falls down when you use a strictly L3 connection between two devices or any other use case. Perhaps a "IP Group" option might be needed or similar. Another alternative would be using sites to link like subnets together. However the blast radius is pretty large on that (you could have multiple prefixes within a site). Currently the tools are that could be used to model this are: * VLAN * Site * Role Please re-adjust your FR to propose a solution that suits your needs as well as include detailed use-cases where you can't replicate the functionality with existing tools or use the existing tools listed above to get the desired results (example, when a prefix is in the same site and has the same role, "link" them together as related prefixes).
adam commented 2025-12-29 18:37:08 +01:00
Author
Owner
Copy Link

@rabin-io commented on GitHub (Feb 16, 2021):

I guess since I got the option in the previous software, And the application was sufficient for that time (mainly documentation and allocation management), I did not think about it too much.

But now we want to centralize all the documentation of the networks and infrastructure under NETBOX and build SOURCE-OF-TRUTH for automation and IaaC (NETBOX's API was the main reason for the move).

I understand that the implementation of this feature needs to be clearer, both at the WEB interface level and at the API level. But I still can not describe exactly how I want to use or consume the option.

Right now the ability to document the connection between two networks meets my needs, but I would love if we could discuss the issue in more depth and refine a more accurate requirement that could meet a number of needs. 🙏

@rabin-io commented on GitHub (Feb 16, 2021): I guess since I got the option in the previous software, And the application was sufficient for that time (mainly documentation and allocation management), I did not think about it too much. But now we want to centralize all the documentation of the networks and infrastructure under NETBOX and build SOURCE-OF-TRUTH for automation and IaaC (NETBOX's API was the main reason for the move). I understand that the implementation of this feature needs to be clearer, both at the WEB interface level and at the API level. But I still can not describe exactly how I want to use or consume the option. Right now the ability to document the connection between two networks meets my needs, but I would love if we could discuss the issue in more depth and refine a more accurate requirement that could meet a number of needs. 🙏
adam commented 2025-12-29 18:37:08 +01:00
Author
Owner
Copy Link

@991jo commented on GitHub (May 8, 2021):

I am also interested in a feature like this. My usecase is for Prefixes from which we allocate smaller prefixes or single addresses e.g. Loopbacks.
For example we have several Prefixes for VM addresses (we are running a complete L3 datacenter, every VM address is a host route). Of course everything is dual stacked. In our environment there is a mapping between IPv4 and IPv6 Prefixes, e.g. if a VMs IPv4 address is from 10.0.0.0/24 then the IPv6 address should be from 2001:db8::/64. Remembering what the associated prefix in the other protocol family was is not fun and a field would really help.

But this could also be implemented as a plugin.

@991jo commented on GitHub (May 8, 2021): I am also interested in a feature like this. My usecase is for Prefixes from which we allocate smaller prefixes or single addresses e.g. Loopbacks. For example we have several Prefixes for VM addresses (we are running a complete L3 datacenter, every VM address is a host route). Of course everything is dual stacked. In our environment there is a mapping between IPv4 and IPv6 Prefixes, e.g. if a VMs IPv4 address is from 10.0.0.0/24 then the IPv6 address should be from 2001:db8::/64. Remembering what the associated prefix in the other protocol family was is not fun and a field would really help. But this could also be implemented as a plugin.
adam commented 2025-12-29 18:37:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 12, 2021):

IMO maintaining a direct mapping of IPv4 to IPv6 prefixes is poor practice and should be discouraged: The two are entirely independent address families with different rules and design considerations. As @DanSheps points out, there are already numerous attributes by which IPv4 and IPv6 prefixes can be correlated without adding a direct relationship.

@jeremystretch commented on GitHub (May 12, 2021): IMO maintaining a direct mapping of IPv4 to IPv6 prefixes is poor practice and should be discouraged: The two are entirely independent address families with different rules and design considerations. As @DanSheps points out, there are already numerous attributes by which IPv4 and IPv6 prefixes can be correlated without adding a direct relationship.
adam commented 2025-12-29 18:37:09 +01:00
Author
Owner
Copy Link

@rabin-io commented on GitHub (May 13, 2021):

Maybe in a ideal world where IPv6 took over and IPv4 was a relic of the past, but even now (20+ years after IPv6 was introduced) we still leaning on IPv4 more then IPv6, and as one of many how have two sets of pools (IPv4 & IPv6) and would like to expose more services over IPv6, The most practical way will be to run in a Dual-Stack mode. And by having this small piece of meta data (which IPv6 prefix was assigned to which IPv4 prefix) helps (a lot).

And as I mention before, this is nothing new, other tools have this option available in them, meaning there was a need for it. And I think it will be a functionality that many more people will be happy to have.

🙏

@rabin-io commented on GitHub (May 13, 2021): Maybe in a ideal world where IPv6 took over and IPv4 was a relic of the past, but even now (20+ years after IPv6 was introduced) we still leaning on IPv4 more then IPv6, and as one of many how have two sets of pools (IPv4 & IPv6) and would like to expose more services over IPv6, The most practical way will be to run in a Dual-Stack mode. And by having this small piece of meta data (which IPv6 prefix was assigned to which IPv4 prefix) helps (a lot). And as I mention before, this is nothing new, other tools have this option available in them, meaning there was a need for it. And I think it will be a functionality that many more people will be happy to have. 🙏
adam commented 2025-12-29 18:37:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 13, 2021):

I was referring to dual-stack implementations. My point is that there is already effective correlation between the IPv4 and IPv6 prefixes, and that adding an explicit relationship is redundant.

@jeremystretch commented on GitHub (May 13, 2021): I was referring to dual-stack implementations. My point is that there is already effective correlation between the IPv4 and IPv6 prefixes, and that adding an explicit relationship is redundant.
adam commented 2025-12-29 18:37:10 +01:00
Author
Owner
Copy Link

@rabin-io commented on GitHub (May 14, 2021):

If you are referring to the use of VLAN to aggregate them, this option is not working for our use case, as we are not using vlans. And I prefer my source of truth to be as close as possible to the real state of my infrastructure.

Also there are cases where you can have the same VLAN number used in several places on the same DC/Cage/Rack, which make the use of VLAN to aggregate the prefix's not usable.

@rabin-io commented on GitHub (May 14, 2021): If you are referring to the use of VLAN to aggregate them, this option is not working for our use case, as we are not using vlans. And I prefer my source of truth to be as close as possible to the real state of my infrastructure. Also there are cases where you can have the same VLAN number used in several places on the same DC/Cage/Rack, which make the use of VLAN to aggregate the prefix's not usable.
adam commented 2025-12-29 18:37:10 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 18, 2021):

In today's maintainers' meeting, the idea was raised to simply display peer prefixes (correlated by assigned VLAN) in the prefix view. That seems like it would serve effectively the same function in most cases without needing to define an explicit relationship between prefixes.

@jeremystretch commented on GitHub (May 18, 2021): In today's maintainers' meeting, the idea was raised to simply display peer prefixes (correlated by assigned VLAN) in the prefix view. That seems like it would serve effectively the same function in most cases without needing to define an explicit relationship between prefixes.
adam commented 2025-12-29 18:37:14 +01:00
Author
Owner
Copy Link

@rabin-io commented on GitHub (May 18, 2021):

Will that require to assigned a prefix to a VLAN to make it to work ?

@rabin-io commented on GitHub (May 18, 2021): Will that require to assigned a prefix to a VLAN to make it to work ?
adam commented 2025-12-29 18:37:16 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 18, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jul 18, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:37:18 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 17, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Aug 17, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: under review 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#4540
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?