Live data from Hacker News

Fun with IP address parsing

blog.dave.tf

101–110 of 150 posts

Re: Fun with IP address parsing

#101
post #55

Can confirm that visiting http://127.1 on ipad indeed works and redirects to http://127.0.0.1 . This is very surprising and, at least for me, humbling. I think I will quote this article any time I see someone using regex to validate or parse IPs.

This is one of the reasons why I appreciate the geekiness of Cloudflare with their DNS service IP addresses, particularly:

1.1 which to me is the shortest useful IP address I am aware of.

Re: Fun with IP address parsing

#102
post #81

> It does not process Class A/B notation, or hex or octal notation. I got to find that notation useful once , to make a shorter one-liner... without even knowing that there were different classes of IPv4 address, and that I was looking at one of them. It's a tiny function that gives me the IP address of my machine in the LAN, for either Linux and Mac: # Get main local IP address from the default external route (Inter…

Oh no, that's another shorthand that's different from all the others. A single number should be interpreted as a big-endian uint32, and so "1" should be "0.0.0.1". However, I can confirm that `ip` interprets it as "1.0.0.0", even though you should have to write "1.0" for that. Ugh.

macOS here:

% ping 1 PING 1 (0.0.0.1): 56 data bytes

% ping 1.0 PING 1.0 (1.0.0.0): 56 data bytes

Re: Fun with IP address parsing

#103

I spent hours debugging an issue that boiled down to an IPV4 parser that treated leading zeroes as octal. Connections to 192.168.123.100 worked as expected. Connections to 192.168.123.034 went to 192.168.123.28. I thought sure it was an issue in my TCP client code, which was handling connections to hundreds of different devices. Guilty party was Poco::Net library if I recall correctly. I can maybe see this making sen…

That’s correct behaviour fwiw - there are many ways to write valid IPv4 addresses which aren’t necessarily intuitive

Re: Fun with IP address parsing

#105

Earlier quoted context omitted.

NAT was meant to work around IP exhaustion issues, not act as a security layer. By accident, it often happens to provide some additional security. By keep in mind those "internal" IP addresses may be routable in some cases, due to either accidental or deliberate mis-configuration. IPv6, with end-to-end connectivity, is how the Internet is supposed to work. It's how it did work in the early 90's, even with IPv4. If yo…

> IPv6, ..., is how the Internet is supposed to work No, the way the Internet is supposed to work is that you have one routable address space. If you need to expand it, the previous address space is imported as a subset of the new one. https://cr.yp.to/djbdns/ipv6mess.html I will never forgive the IPv6 for not making the 32-bit IPv4 space a subrange of the 128-bit IPv6 space. Years after winning the IPng wars they ad…

Maybe I'm misunderstanding you, but one of the points of the article in that you can represent IPv4 addresses in IPv6. In other words, IPv4 is a subset of IPv6.

If I'm on an ipv6-only host and blast UDP at ::ffff:1.2.3.4, they should get delivered to 1.2.3.4, no?

The actual, real-world problem with 4 being a subrange of 6 is that 4-only hosts are blissfully unaware that the super-range exists, so have no mechanism to send packets there. This is of course where you're right about NAT64 and the state requirements.

Re: Fun with IP address parsing

#107
post #98

> 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 . This was the source of one of my favorite “bugs” ever. I was working on multiple mobile apps for a company, and they had a deep link setup th…

maybe it was more appropriate to use a urn instead of a uri. something like urn:namespace:id:scheme:number https://tools.ietf.org/html/rfc8141

[deleted]

Re: Fun with IP address parsing

#108

> 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 . This was the source of one of my favorite “bugs” ever. I was working on multiple mobile apps for a company, and they had a deep link setup th…

Funny bug :) I often prefix integers with a char, e.g. maybe "u12345" here, in places where I'm using integers as id to force a string conversion and avoid any code accidentally doing math on it.

Huh, I'm gonna try to remember this. You'd be surprised how lazy people get, even when money's involved.

Re: Fun with IP address parsing

#110
post #105

Earlier quoted context omitted.

> IPv6, ..., is how the Internet is supposed to work No, the way the Internet is supposed to work is that you have one routable address space. If you need to expand it, the previous address space is imported as a subset of the new one. https://cr.yp.to/djbdns/ipv6mess.html I will never forgive the IPv6 for not making the 32-bit IPv4 space a subrange of the 128-bit IPv6 space. Years after winning the IPng wars they ad…

Maybe I'm misunderstanding you, but one of the points of the article in that you can represent IPv4 addresses in IPv6. In other words, IPv4 is a subset of IPv6. If I'm on an ipv6-only host and blast UDP at ::ffff:1.2.3.4, they should get delivered to 1.2.3.4, no? The actual, real-world problem with 4 being a subrange of 6 is that 4-only hosts are blissfully unaware that the super-range exists, so have no mechanism to…

> If I'm on an ipv6-only host and blast UDP at ::ffff:1.2.3.4, they should get delivered to 1.2.3.4, no?

No, it won't necessarily! That's precisely the problem. Until NAT64 was introduced it was in fact impossible for an IPv6 router to deliver your packet to the IPv4 host 1.2.3.4. NAT64 still isn't mandatory (and likely never will be), so if you're writing software you can't assume those packets will get through even if you have an IPv6 network connection with a default route.

NAT64 didn't come about until long after IPv6 was finalized, and NAT64 support from default-route IPv6 routers is still is not mandatory. That's why we have this mess with dual-stack hosts: you cannot safely assume that your IPv6 router is willing to deal with the IPv4 world on your behalf.

The ::ffff:1.2.3.4 address space does, in fact, date back to the early days of IPv6 (it came from RFC 2765, about one year after IPv6 was finalized), but it was not meant for letting IPv6 clients share a single IPv4 address -- it was only for servers which for some reason had their own IPv4 address but couldn't speak IPv4. Yeah, back in the early 2000s people thought this problem might happen.

The IPv6 committee was viciously hostile to NATs. The way they saw it, NATs were the problem that made IPv6 necessary, so no way were they going to allow any NATs to pollute their precious IPv6. If that meant that the whole world had to run two separate internets (IPv4 and IPv6) for the rest of eternity just to keep the IPv6 network puritanically NAT-free, then so be it!

It took them more than a decade to realize how stupid this mindset was.

Post reply on HN