You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When adding an IPv6 address to an existing prefix, the 'all-zeroes' host address seems to be considered available, and is filled in the input box, even if other IPs in the subnet are allocated, so the default is never sensible.
The all-zeroes address is reserved by RFC4291 2.6.1 as the subnet-router anycast address. Its manual assignment only makes sense on /127s, where RFC6164 asserts that the subnet-anycast mechanism MUST be disabled. At the very least, it isn't a sensible default, as operationally it should never be used for unicast, and many devices will block its usage.
Furthermore, the ipam/prefixes/<id>/available-ips endpoint appears to sort of 'do the right thing' and consider the 1st address to be the first available rather than the 0th. However, on /127s, it asserts that 0 IPs are available.
So:
When adding an IPv6 address, the default form-filled value should be the first available IP that is not all-zeros in the host portion, except when the mask length is /127
The ipam/prefixes/<id>/available-ips should be consistent with the /127 exception
The text was updated successfully, but these errors were encountered:
jeremystretch
added
type: bug
A confirmed report of unexpected behavior in the application
and removed
type: bug
A confirmed report of unexpected behavior in the application
labels
Nov 2, 2017
The same thing happens with IPv4. NetBox is just prepopulating the network. It's not automatically choosing the first available IP because IMO it's not fair to assume that's what the user wants to add.
I see... this doesn't seem like very useful behaviour, as you're never going to want to assign the network address to something. But I don't really use the 'Add IP Address' button.
Where I actually noticed the discrepancy was on the IP Addresses tab, which changes the flavour of this bug slightly. In IPv6, the 0th address seems to be considered 'available' even when it's not a pool. It adds a '1 IP available' row, and is the default when clicking 'Many IPs available' or any other free block that starts at the bottom of the subnet.
Issue type
[ ] Feature request
[x] Bug report
[ ] Documentation
Environment
Description
When adding an IPv6 address to an existing prefix, the 'all-zeroes' host address seems to be considered available, and is filled in the input box, even if other IPs in the subnet are allocated, so the default is never sensible.
The all-zeroes address is reserved by RFC4291 2.6.1 as the subnet-router anycast address. Its manual assignment only makes sense on /127s, where RFC6164 asserts that the subnet-anycast mechanism MUST be disabled. At the very least, it isn't a sensible default, as operationally it should never be used for unicast, and many devices will block its usage.
Furthermore, the
ipam/prefixes/<id>/available-ips
endpoint appears to sort of 'do the right thing' and consider the 1st address to be the first available rather than the 0th. However, on /127s, it asserts that 0 IPs are available.So:
ipam/prefixes/<id>/available-ips
should be consistent with the /127 exceptionThe text was updated successfully, but these errors were encountered: