-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
net: apply ICANN/IANA-managed semantics to IP.IsGlobalUnicast #11772
Comments
/cc @mikioh |
Go 1.5 includes the fix for #11585, for the case of IPv4 limited broadcast address. |
False positive for |
The IsGlobalUnicast method of IP struct simply follows RFC 4291 when the IP is an IPv6 address. That means that the method just uses address type identification of https://tools.ietf.org/html/rfc4291#section-2.5.4 because it's hard to identify various IPv6 addresses without context; for example, in the case of constructing sort of IPv4-IPv6 translator applications using addresses defined in RFC 6052. There are a few options: a) just updating documentation like "it just follows RFC 4291", b) making IsGlobalUnicast on unique local IPv6 unicast addresses return false, c) adding IsUniqueLocalUnicast method to IP, though I have no strong opinion about the latter two. |
To be honest, I'd like to see some package that provides both IPv4 and IPv6 address identification using IETF addressing architectures, IANA registries and application context as an external package. |
net.IP.IsGlobalUnicast() applies incorrect address semantics. The current implementation returns True if the address is not Unspecified, Loopback, LinkLocal, or Multicast. However, a Global Unicast address, by definition, excludes more than just those categories. Class E space is to be excluded, as is all of RFC1918 & RFC6598.
This manifests in a few significant ways:
net.ParseIP("255.255.255.255").IsGlobalUnicast() currently returns True
net.ParseIP("10.1.2.3").IsGlobalUnicast() currently returns True
I would propose the following changes:
Ideally, it would be even better to extend both further using the tables in RFC6890 as a guideline.
The text was updated successfully, but these errors were encountered: