We can't really criticise modern application developers for looking at this complexity, shrugging, and just using the only API available - inet_pton

In a sensible world inet_pton would be deprecated with a compiler warning and replaced with inet_pton2 that just accepted the sensible subset.

The HTTP RFCs actually do restrict the format within URIs, but modern browsers are still more liberal

https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2

One thing I've previously lamented is how IPv6 requires parens for IP:port pair string - particularly problematic if you want to be able to have a default port when the suffix is missing.

Did I inspire posting this?

https://infosec.exchange/@ryanc/114386921335051196

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?