Non-pool IPv6 prefixes think the 0th address is available

[ktims]

Environment

• Python version: 3.6.7
• NetBox version: 2.7.7

Steps to Reproduce

1. Create an IPv6 prefix (tested /64) that is not configured as a pool
2. Add an address to the prefix (::1 is the simplest test case)
3. Visit the ip-addresses view for this prefix

Expected Behavior

The count of available IPs 'below' the first allocated IP should not include the 0th address, unless the prefix is configured as a pool (not sure address pools make sense in IPv6 context at all, tbh) or is a /127.

Observed Behavior

The 0th IP is counted as 'available' in the address list. For example, allocating the ::1 address shows a list entry with '1 IP Available' below the ::1 address. The count will be off-by-one for other cases where there are actually available IPs. See screenshot.

Clicking 'Add an IP address' chooses ::2 as the default as expected, and the available-ips API call also correctly does not include the 0th address.

[hSaria]

The all 0's address is indeed available in IPv6. Same goes for the all 1's address. From RFC 4291 (at the end of section 2):

In IPv6, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain, or end with, zero-valued fields.

[ktims]

The all 0's address is indeed available in IPv6. Same goes for the all 1's address. From RFC 4291 (at the end of section 2):

In IPv6, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain, or end with, zero-valued fields.

It's a valid address, but it is reserved for Subnet-Router anycast (see section 2.6.1), so I don't think it makes sense for it to be assignable within Netbox.

Though if there's opposition to this, I suppose that the API behaviour should probably be consistent.

[stale]

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.

[stale]

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.

[sc68cal]

I'm re-opening this issue because I am having this issue when sending an API request to NetBox, requesting NetBox to hand out available IP addresses within an IPv6 prefix. (names and prefixes have been sanitized to protect the innocent)

changed: [switch.example.com] => (item=2001:DB8:50::/80) => {"ansible_loop_var": "item", "changed": true, "ip_address": {"address": "2001:DB8:50::/80", "assigned_object": 192293, "assigned_object_id": 192293, "assigned_object_type": "dcim.interface", "created": "2022-04-11", "custom_fields": {}, "description": "", "display": "2001:DB8:50::/80", "dns_name": "", "family": 6, "id": 31556, "last_updated": "2022-04-11T15:04:10.275113Z", "nat_inside": null, "nat_outside": null, "role": null, "status": "active", "tags": [], "tenant": null, "url": "https://netbox.example.com/api/ipam/ip-addresses/31556/", "vrf": null}, "item": "2001:DB8:50::/80", "msg": "ip_address 2001:DB8:50::/80 created"}

#switch.example.com(conf-if-lo-0)# ipv6 address 2001:DB8:50::/128
% Error: Invalid IPV6 address used as global unicast address

[sc68cal]

I also agree with @ktims assessment that the ::0'th IP address is reserved for subnet-router anycast

[sc68cal]

I believe the culprit is the logic at https://github.com/netbox-community/netbox/blob/develop/netbox/ipam/models/ip.py#L510-L512