cidrsubnet doesn't work with ipv6 subnets

[arianvp]

Terraform Version

Terraform v0.12.3
+ provider.packet v2.9.0

Your version of Terraform is out of date! The latest version
is 0.12.26. You can update by downloading from www.terraform.io/downloads.html

Terraform Configuration Files

locals {
service_cidr_range = cidrsubnet("fe08::/64", 63, 0)
}

Expected Behavior

https://www.terraform.io/docs/configuration/functions/cidrsubnet.html documents cidrsubnet works for ipv6. and subnet sizes can go upto 128. So expected output here is

service_cidr_range => "fe08::/127"

Actual Behavior

Error: Error in function call

  on provision.tf line 46, in locals:
  46:   service_cidr_range = cidrsubnet("fe08::/64", 63, 0)

Call to function "cidrsubnet" failed: may not extend prefix by more than 32
bits.

Steps to Reproduce

terraform apply

Additional Context

none

References

none

[apparentlymart]

Hi @arianvp!

I think what you are seeing here is a limitation that was addressed in Terraform v0.12.9: prior to that, Terraform was using 32-bit integer arithmetic internally to calculate the new bits to add, but from v0.12.9 onwards it uses an arbitrary-sized "big integer" implementation.

Could you please give this a try in Terraform 0.12.9 or later and let me know if you still see the problem? Thanks!

[arianvp]

Just tested on 12.26 but same error

Error: Error in function call

  on provision.tf line 61, in locals:
  61:   service_cidr_range = cidrsubnet(cidrsubnet(data.packet_precreated_ip_block.addresses.cidr_notation,8,2),44,0)
    |----------------
    | data.packet_precreated_ip_block.addresses.cidr_notation is "2604:1380:2000:9d00::/56"

Call to function "cidrsubnet" failed: may not extend prefix by more than 32

[arianvp]

Current workaround is to split up cidrsubnet in chunks of /32 which is rather ugly :)

  service_cidr_range = cidrsubnet(cidrsubnet(cidrsubnet(data.packet_precreated_ip_block.addresses.cidr_notation,8,2),32,0),12,0)

[apparentlymart]

Thanks for confirming, @arianvp! Looks like that old fix wasn't as complete as I thought it was. Indeed, now I look again at
apparentlymart/go-cidr#16 I see that it was focused on the functionality that Terraform's cidrhost function depends on, and didn't change the Subnet function.

Re-reading that PR, I also remember why: the underlying library's Subnet function has the num argument typed as int, which is a 32-bit integer on 32-bit systems. That's part of the function's public interface, and so it can't be changed without a breaking change to the library. However, the Subnet function could potentially be paired with a new function SubnetBig that is typed *big.Int instead of int, and then it would be able to accept integers of any size that could fit inside an IPv6 address. It seems like Host could also benefit from having a corresponding HostBig for the same reason: the PR has ensured that Host will always calculate the result correctly on 32-bit systems, but it still can't produce a host address with the host portion greater than the current platform's int.

I reproduced what you saw on my system here, using a slightly modified configuration just because it's more convenient to use output blocks for cases like this, so we can easily see the final value once the bug is fixed:

output "cidr_subnet" {
  value = cidrsubnet("fe08::/64", 63, 0)
}

Error: Error in function call

  on cidrsubnet-ipv6.tf line 2, in output "cidr_subnet":
   2:   value = cidrsubnet("fe08::/64", 63, 0)

Call to function "cidrsubnet" failed: may not extend prefix by more than 32
bits.

The error message is actually in Terraform itself: Terraform is converting from the Terraform language representation of numbers -- essentially a wrapped big.Float -- into an int to pass to the function, and so it encounters the range error when doing so. Once the upstream library has these new functions and we update Terraform to use those instead, we can change that validation rule to require that the value is a whole number, and let the underlying cidr library detect if the number is too big to fit in newBits bits.

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.