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

Add an IPv6 address defaults to 0th address #1669

Closed
ktims opened this issue Oct 31, 2017 · 3 comments
Closed

Add an IPv6 address defaults to 0th address #1669

ktims opened this issue Oct 31, 2017 · 3 comments
Labels
type: feature Introduction of new functionality to the application

Comments

@ktims
Copy link

ktims commented Oct 31, 2017

Issue type

[ ] Feature request
[x] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.3
  • NetBox version: 2.2.2

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:

  • 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
@jeremystretch 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
@jeremystretch
Copy link
Member

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.

@ktims
Copy link
Author

ktims commented Nov 2, 2017

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.

@jeremystretch jeremystretch added the type: feature Introduction of new functionality to the application label Nov 15, 2017
@jeremystretch
Copy link
Member

Guess we'll just default to the first available IP and hope people are paying attention.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

2 participants