Fun with IP address parsing (2020) (opens in new tab)

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.

Did I inspire posting this?

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

Discussed at the time:

Fun with IP address parsing - https://news.ycombinator.com/item?id=25545967 - Dec 2020 (146 comments)

> Let’s use 192.168.140.255 as an example. That’s an IPv4 address that people would look at and go “yes, that sure is an IPv4 address.” How else can we write that exact same address?

> This is the same IP address: 3232271615. You get that by interpreting the 4 bytes of the IP address as a big-endian unsigned 32-bit integer, and print that. This leads to a classic parlor trick: if you try to visit http://3232271615 , Chrome will load http://192.168.140.255.

murkans have been using ten digits as phone numbers for some decades now (no country code), I'm kinda bummed there isn't some saudi royalty paying four billion for a set of matching ip address and phone number.

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.

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.

It’s also common to see ::ffff:0:0/96 IPv6 addresses with embedded IPv4, like ::ffff:127.0.0.1. These show up when you open an IPv6 socket that also accepts IPv4 packets.

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?