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

IPAM: Relate an IPv4 prefix to an IPv6 prefix without a VLAN #5681

New Issue
Closed
opened 2025-12-29 19:31:25 +01:00 by adam · 13 comments
adam commented 2025-12-29 19:31:25 +01:00
Owner
Copy Link

Originally created by @netgab on GitHub (Nov 17, 2021).

NetBox version

v3.0.10

Feature type

Change to existing functionality

Proposed functionality

Currently, an IPv4 and an IPv6 prefix can be related using a VLAN in Netbox. For most network topologies, this is sufficient and a very viable approach (good job).
I propose, that an IPv4 prefix and an IPv6 prefix may be associated with each other without the need of a VLAN.

Current relationship:
prefix(IPv4) --> vlan <-- prefix(IPv6)

Maybe a possible approach is to do kind of a relationship object (like a "cable"), which can be assigned to ip-prefix objects and vlan objects:

prefix(IPv4) ---> subnet-object <--- prefix(IPv6)
|
vlan

My intent is to start a discussion whether this is a commom use case for others. Maybe there are other technical approaches to solve this.

Use case

There may be cases, where there is a dual-stack subnet with an IPv4 and IPv6 prefix without a static VLAN relationship.
One example is Cisco ACI, where one subnet (bridge domain) has an IPv4 and IPv6 prefix, but it's not mandatory to assign a VLAN for this. Even worse: Each access port within a bridge domain (EPG) may be assigned to different VLANs, because the VLAN ID is not the primary definition for a subnet.

Database changes

No response

External dependencies

No response

Originally created by @netgab on GitHub (Nov 17, 2021). ### NetBox version v3.0.10 ### Feature type Change to existing functionality ### Proposed functionality Currently, an IPv4 and an IPv6 prefix can be related using a VLAN in Netbox. For most network topologies, this is sufficient and a very viable approach (good job). I propose, that an IPv4 prefix and an IPv6 prefix may be associated with each other without the need of a VLAN. Current relationship: prefix(IPv4) --> vlan <-- prefix(IPv6) Maybe a possible approach is to do kind of a relationship object (like a "cable"), which can be assigned to ip-prefix objects and vlan objects: prefix(IPv4) ---> subnet-object <--- prefix(IPv6) | vlan My intent is to start a discussion whether this is a commom use case for others. Maybe there are other technical approaches to solve this. ### Use case There may be cases, where there is a dual-stack subnet with an IPv4 and IPv6 prefix without a static VLAN relationship. One example is Cisco ACI, where one subnet (bridge domain) has an IPv4 and IPv6 prefix, but it's not mandatory to assign a VLAN for this. Even worse: Each access port within a bridge domain (EPG) may be assigned to different VLANs, because the VLAN ID is not the primary definition for a subnet. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 19:31:25 +01:00
adam closed this issue 2025-12-29 19:31:25 +01:00
adam commented 2025-12-29 19:31:25 +01:00
Author
Owner
Copy Link

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

I believe this proposal has already been addressed under #5767. Per my comment on that issue:

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.

Your use case described above doesn't say how you would actually use the proposed relationship. In what situation do you have an IPv4 prefix and need to directly reference its associated IPv6 prefix(es) (or vice versa)?

@jeremystretch commented on GitHub (Nov 18, 2021): I believe this proposal has already been addressed under #5767. Per my [comment](https://github.com/netbox-community/netbox/issues/5767#issuecomment-839990367) on that issue: > 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. Your use case described above doesn't say how you would actually _use_ the proposed relationship. In what situation do you have an IPv4 prefix and need to directly reference its associated IPv6 prefix(es) (or vice versa)?
adam commented 2025-12-29 19:31:26 +01:00
Author
Owner
Copy Link

@netgab commented on GitHub (Nov 18, 2021):

Hi @jeremystretch ,
thank you for the reply and sorry for double posting.

For the use case:
One IP subnet in Cisco ACI (e.g. Bridge Domain) has an IPv4 and an IPv6 prefix.
=> Dual-stack

If you want to assign an IPv4 and IPv6 address for a VM or device within this bridge domain, it's hard to find out which two prefixes belong to the same Bridge Domain (BD). In case of a traditional network, I only need to know the domain (vlan group) and the VLAN ID and I can see the related IPv4 and IPv6 prefix.
The reason is, that the concept of a single VLAN = a broadcast domain (IP subnet) is not always true for ACI. VLANs are relevant for Endpoint Groups (EPGs), which are assigned to a bridge domain. This means, that multiple VLANs may be used for one bridge domain.

I'm not quite sure whether in other fabric networks, this requirements will arise as well. Basically every time a VXLAN based overlay is used, the VLAN is only relevant for the path between the switch access port and the end device (and not for the IP subnet).

Basically loose relationships may be used like same IP prefix descriptions.
Of course one tag per BD may be used or assign a "dummy VLAN" in the ACI domain.

@netgab commented on GitHub (Nov 18, 2021): Hi @jeremystretch , thank you for the reply and sorry for double posting. For the use case: One IP subnet in Cisco ACI (e.g. Bridge Domain) has an IPv4 and an IPv6 prefix. => Dual-stack If you want to assign an IPv4 and IPv6 address for a VM or device within this bridge domain, it's hard to find out which two prefixes belong to the same Bridge Domain (BD). In case of a traditional network, I only need to know the domain (vlan group) and the VLAN ID and I can see the related IPv4 and IPv6 prefix. The reason is, that the concept of a single VLAN = a broadcast domain (IP subnet) is not always true for ACI. VLANs are relevant for Endpoint Groups (EPGs), which are assigned to a bridge domain. This means, that multiple VLANs may be used for one bridge domain. I'm not quite sure whether in other fabric networks, this requirements will arise as well. Basically every time a VXLAN based overlay is used, the VLAN is only relevant for the path between the switch access port and the end device (and not for the IP subnet). Basically loose relationships may be used like same IP prefix descriptions. Of course one tag per BD may be used or assign a "dummy VLAN" in the ACI domain.
adam commented 2025-12-29 19:31:26 +01:00
Author
Owner
Copy Link

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

This sounds extremely product-specific, and probably exceeds what NetBox can currently model with regard to the proprietary concept of a bridge domain.

If you want to assign an IPv4 and IPv6 address for a VM or device within this bridge domain, it's hard to find out which two prefixes belong to the same Bridge Domain (BD).

So you're actually trying to associate prefixes with a bridge domain, not one another. I would think that however you're mapping this association for IPv4 prefixes would work for IPv6 prefixes as well.

@jeremystretch commented on GitHub (Nov 18, 2021): This sounds extremely product-specific, and probably exceeds what NetBox can currently model with regard to the proprietary concept of a bridge domain. > If you want to assign an IPv4 and IPv6 address for a VM or device within this bridge domain, it's hard to find out which two prefixes belong to the same Bridge Domain (BD). So you're actually trying to associate prefixes with a bridge domain, not one another. I would think that however you're mapping this association for IPv4 prefixes would work for IPv6 prefixes as well.
adam commented 2025-12-29 19:31:26 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 18, 2021):

@jeremystretch I know a tiny bit about ACI, and my understanding is it uses vxlan under the hood. Perhaps if/when we model vxlan we could use the vlan or the vni to correlate a ipv4 to a ipv6 in this scenario.

@DanSheps commented on GitHub (Nov 18, 2021): @jeremystretch I know a tiny bit about ACI, and my understanding is it uses vxlan under the hood. Perhaps if/when we model vxlan we could use the vlan or the vni to correlate a ipv4 to a ipv6 in this scenario.
adam commented 2025-12-29 19:31:26 +01:00
Author
Owner
Copy Link

@netgab commented on GitHub (Nov 19, 2021):

@DanSheps: Maybe a good idea using the Virtual Network ID (VNID) in VXLAN as an object.
However the problem is, that in contrast to VLANs, the VXLAN environment (depending on the solution) is very dynamic. So in a traditional network, you'll create a VLAN a and map it to switch ports and IP interfaces and so on.

Using overlay technoligies utilizing VXLAN (e.g. ACI), the VXLAN topology is there but hidden from the user in regards of a configuration aspect. So you'll never assign a VNID to anything in ACI. So it's not possible to "design" a VXLAN based overlay in Netbox in advance / before the topology is actually built.

Furthermore a VNID in the VXLAN header is very flexible. Meaning it's not only intended to describe a layer-2 network. There are VNIDs, which describe a whole VRF.

So if you plan to model a VXLAN VNID (like a VLAN) in netbox, there may be multiple possible relationships:

  • VRFs
  • IP Subnets
  • Point-to-Point Tunnels?!
  • ...
@netgab commented on GitHub (Nov 19, 2021): @DanSheps: Maybe a good idea using the Virtual Network ID (VNID) in VXLAN as an object. However the problem is, that in contrast to VLANs, the VXLAN environment (depending on the solution) is very dynamic. So in a traditional network, you'll create a VLAN a and map it to switch ports and IP interfaces and so on. Using overlay technoligies utilizing VXLAN (e.g. ACI), the VXLAN topology is there but hidden from the user in regards of a configuration aspect. So you'll never assign a VNID to anything in ACI. So it's not possible to "design" a VXLAN based overlay in Netbox in advance / before the topology is actually built. Furthermore a VNID in the VXLAN header is very flexible. Meaning it's not only intended to describe a layer-2 network. There are VNIDs, which describe a whole VRF. So if you plan to model a VXLAN VNID (like a VLAN) in netbox, there may be multiple possible relationships: - VRFs - IP Subnets - Point-to-Point Tunnels?! - ...
adam commented 2025-12-29 19:31:26 +01:00
Author
Owner
Copy Link

@netgab commented on GitHub (Nov 19, 2021):

To be more generic:
Currently a VLAN represents a layer-2 domain in netbox. IP prefixes are related to a VLAN to indicate that these layer-3 networks belongs to the layer-2 domain.

However, from my point of view a VLAN is not the only technology, which describes a layer-2 domain.
For example:

  • As I said some kind of overlay network technologies (ACI / VXLAN)
  • A simple routed interface without subinterfaces with multiple IP prefixes configured on it
    ==> Could be modeled using VLAN 1 (which is technically not true)
  • Tunnel interfaces (e.g. a DMVPN cloud)
  • ...

So from my point of view the relationship object between IP prefixes is not a VLAN - it's a representation for a layer-2 domain (which could be a VLAN and other stuff). This relationship object is more or less something like a cable in network (a multipoint cable). If not explicitely configured, this object is just sequentially numbered (like the cables in netbox). Of course there is the option to name them and attach some properties like the type and other stuff.

Data model:

l2domain:
  name <string>: If not set, a sequential or random unique number is assigned
  type <enum> [vlan, vxlan, tunnel, ...]
  !! if "vlan" is selected, the vlan object may be assigned

Don't know if this makes sense ... you're the professionals :)

@netgab commented on GitHub (Nov 19, 2021): To be more generic: Currently a VLAN represents a layer-2 domain in netbox. IP prefixes are related to a VLAN to indicate that these layer-3 networks belongs to the layer-2 domain. However, from my point of view a VLAN is not the only technology, which describes a layer-2 domain. For example: - As I said some kind of overlay network technologies (ACI / VXLAN) - A simple routed interface without subinterfaces with multiple IP prefixes configured on it ==> Could be modeled using VLAN 1 (which is technically not true) - Tunnel interfaces (e.g. a DMVPN cloud) - ... So from my point of view the relationship object between IP prefixes is not a VLAN - it's a representation for a layer-2 domain (which could be a VLAN and other stuff). This relationship object is more or less something like a cable in network (a multipoint cable). If not explicitely configured, this object is just sequentially numbered (like the cables in netbox). Of course there is the option to name them and attach some properties like the type and other stuff. Data model: ``` l2domain: name <string>: If not set, a sequential or random unique number is assigned type <enum> [vlan, vxlan, tunnel, ...] !! if "vlan" is selected, the vlan object may be assigned ``` Don't know if this makes sense ... you're the professionals :)
adam commented 2025-12-29 19:31:27 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 23, 2021):

Yes, well if it is a L3 routed port, then of course the only way to relate them would be through the interface assignment, whcih could be done much in the same way as the vlan/vni/etc.

@DanSheps commented on GitHub (Nov 23, 2021): Yes, well if it is a L3 routed port, then of course the only way to relate them would be through the interface assignment, whcih could be done much in the same way as the vlan/vni/etc.
adam commented 2025-12-29 19:31:27 +01:00
Author
Owner
Copy Link

@netgab commented on GitHub (Nov 23, 2021):

But you cannot see this relation over the IPAM in any way. If it's a VLAN you can see the relation of the prefixes using the ipam.vlan. So there are multiple different places and classes where a relationship may be managed.
Wouldn't it be cool if there is a single view for this and make this more generic?

@netgab commented on GitHub (Nov 23, 2021): But you cannot see this relation over the IPAM in any way. If it's a VLAN you can see the relation of the prefixes using the ipam.vlan. So there are multiple different places and classes where a relationship may be managed. Wouldn't it be cool if there is a single view for this and make this more generic?
adam commented 2025-12-29 19:31:27 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 23, 2021):

Yes, it might be useful, however we aren't going to introduce a new model for it (most likely) and still will stick to the "loose" coupling we normally do, if we even decide to do this.

However, you can just as easily do this yourself right now using the API without much effort.

@DanSheps commented on GitHub (Nov 23, 2021): Yes, it might be useful, however we aren't going to introduce a new model for it (most likely) and still will stick to the "loose" coupling we normally do, if we even decide to do this. However, you can just as easily do this yourself right now using the API without much effort.
adam commented 2025-12-29 19:31:27 +01:00
Author
Owner
Copy Link

@netgab commented on GitHub (Nov 24, 2021):

Hey @DanSheps,
I understand. It was worth a try (at least from my point of view) :)

@netgab commented on GitHub (Nov 24, 2021): Hey @DanSheps, I understand. It was worth a try (at least from my point of view) :)
adam commented 2025-12-29 19:31:27 +01:00
Author
Owner
Copy Link

@pobradovic08 commented on GitHub (Nov 25, 2021):

@DanSheps did you mean there won't be a new model for bridge domains or for this mapping between IPv4 and IPv6?

Although i don't see the need to map IPv4 to IPv6 I do see the need to differentiate between VLANs and bridge domains. Also I don't think this is ACI specific (maybe the microsegmentation explanation is) as those are the characteristics of VXLAN fabrics in general (and not just VXLAN fabrics). Few things that come to mind are:

  • L2VPNs (VPLS) where we have a single bridge domain but different encapsulations (VLAN IDs) on different EFPs
  • VXLAN VN where again you have a single bridge domain but can have different encapsulations (VLAN IDs) on different VTEPs
  • VLAN translation/normalization where you have a different VLAN IDs for a single bridge domain
@pobradovic08 commented on GitHub (Nov 25, 2021): @DanSheps did you mean there won't be a new model for bridge domains or for this mapping between IPv4 and IPv6? Although i don't see the need to map IPv4 to IPv6 I do see the need to differentiate between VLANs and bridge domains. Also I don't think this is ACI specific (maybe the microsegmentation explanation is) as those are the characteristics of VXLAN fabrics in general (and not just VXLAN fabrics). Few things that come to mind are: - L2VPNs (VPLS) where we have a single bridge domain but different encapsulations (VLAN IDs) on different EFPs - VXLAN VN where again you have a single bridge domain but can have different encapsulations (VLAN IDs) on different VTEPs - VLAN translation/normalization where you have a different VLAN IDs for a single bridge domain
adam commented 2025-12-29 19:31:27 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 25, 2021):

Mapping between ipv4 and ipv6

@DanSheps commented on GitHub (Nov 25, 2021): Mapping between ipv4 and ipv6
adam commented 2025-12-29 19:31:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 1, 2021):

The original FR here was to introduce a new model for correlating IPv4 and IPv6 prefixes, which we've decided not to implement. As far as the rest of the discussion regarding VXLAN, a separate issue will need to be opened if there's interest in continuing that thread.

@jeremystretch commented on GitHub (Dec 1, 2021): The original FR here was to introduce a new model for correlating IPv4 and IPv6 prefixes, which we've decided not to implement. As far as the rest of the discussion regarding VXLAN, a separate issue will need to be opened if there's interest in continuing that thread.
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#5681
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?