[bugfix]: Fix IPv6 validation #1150
Conversation
|
An alternative would be to whitelist the allocated ranges from https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml instead. |
daenney
force-pushed
the
ipv6-allowed
branch
from
76ff009
to
aad3ace
Compare
The current code considers ff00::/8 valid, but contrary to the comment that's not the global unicast range. ff-prefixes in IPv6 denote multicast. This adapts the code to take the same approach as IPv4, explicitly blacklisting reserved internal/private ranges.
daenney
force-pushed
the
ipv6-allowed
branch
from
aad3ace
to
ec4fd30
Compare
|
If I'm reading the code right and seeing how this is always used through Sanitize on outgoing requests, then I think most outgoing communication with IPv6-enabled instances might be failing (assuming your own instance is reachable over IPv6 in the first place). |
|
I will defer to @NyaaaWhatsUpDoc on this one since she authored the sanitize code :) |
|
I double-checked this in the Go Playground with an IPv6 address of one of my boxes: https://go.dev/play/p/X-VMfnKuQkT. That results in |
|
Yes that is very much an oops on my behalf :') |
|
Thanks for checking and merging this so fast! |
The current code considers ff00::/8 valid, but contrary to the comment that's not the global unicast range. ff-prefixes in IPv6 denote multicast.
This adapts the code to take the same approach as IPv4, explicitly blacklisting reserved internal/private ranges.