Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Function to calculate subnet block number #23

Open
alonbg opened this issue Oct 27, 2021 · 1 comment
Open

Function to calculate subnet block number #23

alonbg opened this issue Oct 27, 2021 · 1 comment

Comments

@alonbg
Copy link

alonbg commented Oct 27, 2021

Hi @apparentlymart
Well, that's not really an issue.
it would be very helpful to have a function returning the subnet position (block number) within a super-net.
func SubnetNumber(base *net.IPNet, subnet *net.IPNet) (int, error)
That's kind of a reverse to func Subnet(base *net.IPNet, newBits int, num int) (*net.IPNet, error)

@apparentlymart
Copy link
Owner

Hi @alonbg! Thanks for sharing this use-case.

To make sure I understand what you mean, I think this would be an example (using a pseudo-code syntax):

SubnetNumber("10.1.0.0/16", "10.1.2.0/24")2

Does that match your intuition for what you're requesting here?

If so, I think this seems like a reasonable idea in principle but I think there are some questions to consider first:

  • If we're working with IPv6 subnets instead of IPv4 subnets then the subnet number might not fit in an int. Making that oversight originally is what led to us having both Subnet and SubnetBig.

    After learning from that mistake, I wonder whether to just start with SubnetNumber returning *big.Int as the only function, or whether it's better to be symmetrical and have SubnetNumber which returns an error when the prefix lengths are too far apart for int and SubnetNumberBig which always returns *big.Int. Do you think the use-case you have in mind would benefit from one of those designs in particular, or is that decision irrelevant to you?

  • I wonder about the signature being SubnetNumber(base *net.IPNet, newBits int) (int, error) instead, such that the second argument is just the subnet's prefix length and not the prefix itself. That would then make it a true opposite and avoid one of the potential error conditions, because there would be no case where the subnet argument lacks a common prefix with base. Would that alternative signature work for your purposes?

  • Or, as another alternative signature, it could potentially be a true inverse of Subnet and be SubnetNumber(base *net.IPNet, subnet *net.IPNet) (newBits int, num int, err error) where the newBits return value is the difference in the prefix length between base and subnet.

🤔

This library is already meeting my needs so I want to be up front that I'm unlikely to spend time implementing this myself, but if we can agree on some answers to the above questions, hopefully with a rationale behind those decisions rather than just arbitrarily choosing, then I'd be happy to review and merge a pull request based on the outcome of the design discussion.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants