The "IPv6 with trailing IPv4"-style address is still relevant in NAT64 (and by extension, XLAT464), which are sorta widely deployed among cellular ISPs, and likely will get more and more useful as networks transition to become IPv6-mostly.
You upgrade an IPv4 address to an IPv6 address by appending it to 64:ff9b::/96, or whichever /96 prefix your ISP has chosen. For example, in an NAT64-enabled network, connecting to 64:ff9b::1.1.1.1 will get you to 1.1.1.1 as expected.
The fact that there are still octal-supporting parsers in the wild means that it is a security bug to accept 0-prefixed addresses as decimal, since they will produce a different valid value.
All the other questions are much safer since they will at worst produce a failure, but it would probably be best to be extra-strict for them too.
I wonder how many firewalls would break with some of these? I hope they would fail closed (block unexpected traffic). Their stacks probably work on the packet binary data...but the GUI?
The "IPv6 with trailing IPv4"-style address is still relevant in NAT64 (and by extension, XLAT464), which are sorta widely deployed among cellular ISPs, and likely will get more and more useful as networks transition to become IPv6-mostly.
You upgrade an IPv4 address to an IPv6 address by appending it to 64:ff9b::/96, or whichever /96 prefix your ISP has chosen. For example, in an NAT64-enabled network, connecting to 64:ff9b::1.1.1.1 will get you to 1.1.1.1 as expected.
The fact that there are still octal-supporting parsers in the wild means that it is a security bug to accept 0-prefixed addresses as decimal, since they will produce a different valid value.
All the other questions are much safer since they will at worst produce a failure, but it would probably be best to be extra-strict for them too.
I wonder how many firewalls would break with some of these? I hope they would fail closed (block unexpected traffic). Their stacks probably work on the packet binary data...but the GUI?