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

Change BGP_ASN_MIN value from 1 to 0 (to allow for modeling of RPKI ROAs using the "0"-ASN while using a foreign-key relationship between ROAs and the IPAM ASN table) #10432

New Issue
Closed
opened 2025-12-29 21:31:23 +01:00 by adam · 11 comments
adam commented 2025-12-29 21:31:23 +01:00
Owner
Copy Link

Originally created by @menckend on GitHub (Nov 4, 2024).

NetBox version

v4.1.6

Feature type

Change to existing functionality

Triage priority

I volunteer to perform this work (if approved)

Proposed functionality

I'd like to have the BGP_ASN_MIN value in https://github.com/netbox-community/netbox/blob/develop/netbox/ipam/fields.py changed from "1" to "0".

Use case

"0" is defined as a "reserved" value, and should never be included in any BGP updates, but ASNs are used in RPKI ROAs as well, where the reserved value of "0" for an AS number is used to signify that no ASN is authorized to originate a given prefix. I'd like to see this value changed from 1 to 0, so that we can accurately model the semantics of RPKI ROAs for both ROAs referring to registered ASNSs as well as those referring to the reserved/"0" ASN. (Using a foreign-key relationship between the ASN and the RIR that has allocated it to a specific organization.)

Directly applicable to the netbox_rpki plugin I'm writing.

Database changes

I don't believe that this change has any impacts beyond changing the variable BGP_ASN_MIN from 1 to 0.

External dependencies

None.

Originally created by @menckend on GitHub (Nov 4, 2024). ### NetBox version v4.1.6 ### Feature type Change to existing functionality ### Triage priority I volunteer to perform this work (if approved) ### Proposed functionality I'd like to have the BGP_ASN_MIN value in https://github.com/netbox-community/netbox/blob/develop/netbox/ipam/fields.py changed from "1" to "0". ### Use case "0" *is* defined as a "reserved" value, and *should* never be included in any BGP updates, but [ASNs are used in RPKI ROAs as well, where the reserved value of "0" for an AS number is used to signify that *no* ASN is authorized to originate a given prefix](https://www.rfc-editor.org/rfc/rfc7607.html). I'd like to see this value changed from 1 to 0, so that we can accurately model the semantics of RPKI ROAs for both ROAs referring to _registered_ ASNSs as well as those referring to the reserved/"0" ASN. (Using a foreign-key relationship between the ASN and the RIR that has allocated it to a specific organization.) Directly applicable to the [netbox_rpki](https://menckend.github.io/netbox_rpki/) plugin I'm writing. ### Database changes I don't believe that this change has any impacts beyond changing the variable BGP_ASN_MIN from 1 to 0. ### External dependencies None.
adam added the type: featurecomplexity: low labels 2025-12-29 21:31:23 +01:00
adam closed this issue 2025-12-29 21:31:23 +01:00
adam commented 2025-12-29 21:31:24 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Nov 7, 2024):

Sounds good to me, sounds localized and low-impact.

@bctiemann commented on GitHub (Nov 7, 2024): Sounds good to me, sounds localized and low-impact.
adam commented 2025-12-29 21:31:24 +01:00
Author
Owner
Copy Link

@menckend commented on GitHub (Nov 7, 2024):

New here / learning the norms. I submitted a pull request implementing this change and referencing this issue. Apologies if that was premature.

@menckend commented on GitHub (Nov 7, 2024): New here / learning the norms. I submitted a [pull request](https://github.com/netbox-community/netbox/pull/17961) implementing this change and referencing this issue. Apologies if that was premature.
adam commented 2025-12-29 21:31:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 8, 2024):

I'd like to see this value changed from 1 to 0, so that we can accurately model the semantics of RPKI ROAs for both ROAs referring to registered ASNSs as well as those referring to the reserved/"0" ASN. (Using a foreign-key relationship between the ASN and the RIR that has allocated it to a specific organization.)

This doesn't make sense to me. What would be the purpose of created an ASN object in NetBox with an expressly disallowed value? Why would the ROA object not use a null value for the ASN in this scenario? This seems like an unsupportable change.

@jeremystretch commented on GitHub (Nov 8, 2024): > I'd like to see this value changed from 1 to 0, so that we can accurately model the semantics of RPKI ROAs for both ROAs referring to registered ASNSs as well as those referring to the reserved/"0" ASN. (Using a foreign-key relationship between the ASN and the RIR that has allocated it to a specific organization.) This doesn't make sense to me. What would be the purpose of created an ASN object in NetBox with an expressly disallowed value? Why would the ROA object not use a null value for the ASN in this scenario? This seems like an unsupportable change.
adam commented 2025-12-29 21:31:25 +01:00
Author
Owner
Copy Link

@menckend commented on GitHub (Nov 8, 2024):

I'd like to see this value changed from 1 to 0, so that we can accurately model the semantics of RPKI ROAs for both ROAs referring to registered ASNSs as well as those referring to the reserved/"0" ASN. (Using a foreign-key relationship between the ASN and the RIR that has allocated it to a specific organization.)

This doesn't make sense to me. What would be the purpose of created an ASN object in NetBox with an expressly disallowed value? Why would the ROA object not use a null value for the ASN in this scenario? This seems like an unsupportable change.

The purpose would be to accurately model ROA objects in a plugin (hopefully/eventually as part of the core data model.) There is a real-world foreign-key relationship between ROAs and ASNs. The BGP ASN value of "0" is not expresssly disallowed. It is explicitly "invalid" within the context of a BGP update. (It's formal status is "reserved".) It is also explicitly valid_ within the context of an RPKI ROA. RFC7607 addresses this directly.

I (obviously) didn't write the original RPKI RFCs, but I'm assuming that the motivation in using the reserved "0" value rather than a null value was good old fashioned design-discipline. I.E., it's standard practice to use the null value as an option of last resort to signify something. There are a lot of actual values that we can assign for a lot of different cases, but there's only one null value, and we're choosing on behalf of all posterity when we decide to use it for some specific design/use case.

Even assuming that BGP updates were the only context in which BGP ASNs were utilized, I think there's still precedent for allowing the 0 value. I think it's directly analogous to the way netbox handles IP addressing. The IPv4 address-space itself is defined as a 32-bit address space, and Netbox allows us define "prefixes" across all of it (even netblocks that we're not "allowed" to actually use.) I don't think that we should need to resort to that reasoning though, since ASN 0 is a valid value for RFC-defined use-cases.

@menckend commented on GitHub (Nov 8, 2024): > > I'd like to see this value changed from 1 to 0, so that we can accurately model the semantics of RPKI ROAs for both ROAs referring to registered ASNSs as well as those referring to the reserved/"0" ASN. (Using a foreign-key relationship between the ASN and the RIR that has allocated it to a specific organization.) > > This doesn't make sense to me. What would be the purpose of created an ASN object in NetBox with an expressly disallowed value? Why would the ROA object not use a null value for the ASN in this scenario? This seems like an unsupportable change. The purpose would be to accurately model ROA objects in a plugin (hopefully/eventually as part of the core data model.) There is a real-world foreign-key relationship between ROAs and ASNs. The BGP ASN value of "0" is _not_ expresssly disallowed. It _is_ explicitly "invalid" _within the context of a BGP update_. (It's formal status is "reserved".) It is also explicitly _**valid**__ within the context of an RPKI ROA. [RFC7607](https://www.rfc-editor.org/rfc/rfc7607.html) addresses this directly. I (obviously) didn't write the original RPKI RFCs, but I'm _assuming_ that the motivation in using the reserved "0" value rather than a null value was good old fashioned design-discipline. I.E., it's standard practice to use the null value as an option of last resort to signify something. There are a _lot_ of _actual_ values that we can assign for a _lot_ of different cases, but there's only *one* null value, and we're choosing on behalf of all posterity when we decide to use it for some _specific_ design/use case. Even assuming that BGP updates were the *only* context in which BGP ASNs were utilized, I think there's still precedent for allowing the 0 value. I think it's directly analogous to the way netbox handles IP addressing. The IPv4 address-space itself is defined as a 32-bit address space, and Netbox allows us define "prefixes" across _all_ of it (even netblocks that we're not "allowed" to actually use.) I don't think that we should need to resort to that reasoning though, since ASN 0 _is_ a valid value for RFC-defined use-cases.
adam commented 2025-12-29 21:31:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 14, 2024):

Again, outside the specific use case you cite, the use of zero as an AS identifier is not valid. Thus, NetBox should not blindly permit the creation of ASN 0. (This would be considered a bug.)

@jeremystretch commented on GitHub (Nov 14, 2024): Again, outside the specific use case you cite, the use of zero as an AS identifier is not valid. Thus, NetBox should not blindly permit the creation of ASN 0. (This would be considered a bug.)
adam commented 2025-12-29 21:31:25 +01:00
Author
Owner
Copy Link

@menckend commented on GitHub (Nov 14, 2024):

Thank you for continuing to discuss this.

I can't follow the your reasoning that creating an ASN object with a value of "0" would be a bug, but I think that's probably because I'm misunderstanding what the ASN model/table is intended to actually represent.

I've been conceptualizing it as representing the ASN address-space itself (directly analogous to the IPv4 and IPv6 address-spaces) under IANA's purview and defined by IETF RFCs. In that framework, I don't think that there's anything invalid about an ASN object with a value of "0" (or 65535, or 64496-64511, or any other "reserved" values.) This conception of the ASN model/table/object leaves room for all potential use-cases that utilize this address-space. It lets Netbox model "a thing" that very-much exists in the real-world (the address-space itself is strictly defined and managed by IETF and IANA.)

I think that you're conceptualizing the ASN model/table/objects as representing "an attribute in BGPP updates", and as such, it would be wrong to allow the creation of an ASN object with a value of "0" (because "0" should never be present in the the AS-path attribute of a BGP update?)

I don't think that concern should carry much weight though, since there's nothing more valid about the BGP AS-path attribute use-case than there is about the RPKI ROA originating-AS use-case. Equally important, the Netbox data-model doesn't currently go that deep anyway.

The netbox_bgp plugin does go that deep, introducing the "BGP session" construct which has a foreign-key relationship to the ASN model, but I suggest that it would be "better" data-modeling to _implement the "don't allow an ASN of 0" logic in the remoteAS and localAS fields of the netbox_bgp plugin's BGP Session model/table than to do so in the ASN model/table itself. I'd be happy to submit a pull request to do exactly that in the netbox_bgp plugin if that might allay your concerns?

To go back to the IPv4 address-space analogy though, Netbox has an IPv4 "Prefix" model/table/object, and it allows the creation of objects across the entire address space, without any carveouts for IP addresses/prefixes that are invalid in particular use-cases. Rather than perceiving that as a bug for any specific use-case, I see that as a boon for our ability to model a rich array of use-cases utilizing IP addresses. (E.G., nobody should ever be accepting routes for 127.0.0.0/8, but we can certainly want to refer to it in an ip prefix that gets applied in multiple contexts.)

Anyway, please let me know if you think applying the "no ASN 0" logic in the bgp plugin's bgp_session model would sway your opinion? (Assuming that the rest of my bloviating above didn't do the trick already :) )

@menckend commented on GitHub (Nov 14, 2024): Thank you for continuing to discuss this. I can't follow the your reasoning that creating an ASN object with a value of "0" would be a bug, but I think that's probably because I'm misunderstanding what the ASN model/table is intended to actually _represent_. _I've_ been conceptualizing it as representing the ASN _address-space itself_ (directly analogous to the IPv4 and IPv6 address-spaces) under IANA's purview and defined by IETF RFCs. In that framework, I don't think that there's anything _invalid_ about an ASN object with a value of "0" (or 65535, or 64496-64511, or any other "reserved" values.) This conception of the ASN model/table/object leaves room for _all_ potential use-cases that utilize this address-space. It lets Netbox model "a thing" that very-much exists in the real-world (the address-space itself is strictly defined and managed by IETF and IANA.) I _think_ that you're conceptualizing the ASN model/table/objects as representing "an attribute in BGPP updates", and as such, it would be _wrong_ to allow the creation of an ASN object with a value of "0" (because "0" should never be present in the the AS-path attribute of a BGP update?) I don't think that concern should carry much weight though, since there's nothing more valid about the BGP AS-path attribute use-case than there is about the RPKI ROA originating-AS use-case. Equally important, the Netbox data-model doesn't currently _go_ that deep anyway. The netbox_bgp plugin _does_ go that deep, introducing the "BGP session" construct which has a foreign-key relationship to the ASN model, but I suggest that it would be "better" data-modeling to _implement the "don't allow an ASN of 0" logic _in the remoteAS and localAS fields of the netbox_bgp plugin's BGP Session model/table_ than to do so in the ASN model/table itself. I'd be happy to submit a pull request to do exactly that in the netbox_bgp plugin if that might allay your concerns? To go back to the IPv4 address-space analogy though, Netbox has an IPv4 "Prefix" model/table/object, and it allows the creation of objects across the entire address space, without any carveouts for IP addresses/prefixes that are invalid in particular use-cases. Rather than perceiving that as a bug for any specific use-case, I see that as a _boon_ for our ability to model a rich array of use-cases utilizing IP addresses. (E.G., nobody should ever be accepting _routes_ for 127.0.0.0/8, but we can _certainly_ want to refer to it in an ip prefix that gets applied in multiple contexts.) Anyway, please let me know if you think applying the "no ASN 0" logic in the bgp plugin's bgp_session model would sway your opinion? (Assuming that the rest of my bloviating above didn't do the trick already :) )
adam commented 2025-12-29 21:31:26 +01:00
Author
Owner
Copy Link

@menckend commented on GitHub (Nov 15, 2024):

Purely FWIW, I have written an RPKI plugin that implements the logic I'm discussing. (Don't want you thinking that I'm splitting hairs over a pure hypothetical.)

@menckend commented on GitHub (Nov 15, 2024): Purely FWIW, I have written an [RPKI plugin](https://github.com/menckend/netbox_rpki) that implements the logic I'm discussing. (Don't want you thinking that I'm splitting hairs over a pure hypothetical.)
adam commented 2025-12-29 21:31:26 +01:00
Author
Owner
Copy Link

@menckend commented on GitHub (Nov 26, 2024):

Is this still under consideration/review, or is the last response from @jeremystretch the end of the road on this?

@menckend commented on GitHub (Nov 26, 2024): Is this still under consideration/review, or is the last response from @jeremystretch the end of the road on this?
adam commented 2025-12-29 21:31:26 +01:00
Author
Owner
Copy Link

@menckend commented on GitHub (Dec 12, 2024):

@bctiemann / @jeremystretch: Please advise as to status?

@menckend commented on GitHub (Dec 12, 2024): @bctiemann / @jeremystretch: Please advise as to status?
adam commented 2025-12-29 21:31:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 12, 2024):

I'm sorry but you've not provided sufficient justification for the change in my view, and nor has anyone else represented support for the proposed change. We're going to pass. However, as NetBox is open source, you remain free to make any desired changes in your own fork.

@jeremystretch commented on GitHub (Dec 12, 2024): I'm sorry but you've not provided sufficient justification for the change in my view, and nor has anyone else represented support for the proposed change. We're going to pass. However, as NetBox is open source, you remain free to make any desired changes in your own fork.
adam commented 2025-12-29 21:31:27 +01:00
Author
Owner
Copy Link

@menckend commented on GitHub (Dec 12, 2024):

I'm sorry but you've not provided sufficient justification for the change in my view, and nor has anyone else represented support for the proposed change. We're going to pass. However, as NetBox is open source, you remain free to make any desired changes in your own fork.

@jeremystretch: That is disappointing, but understood. Thanks for hearing me out.

@menckend commented on GitHub (Dec 12, 2024): > I'm sorry but you've not provided sufficient justification for the change in my view, and nor has anyone else represented support for the proposed change. We're going to pass. However, as NetBox is open source, you remain free to make any desired changes in your own fork. @jeremystretch: That _is_ disappointing, but understood. Thanks for hearing me out.
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 complexity: low 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#10432
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?