Hacker News Reader

Comment by derefr | Hacker News Reader

Why does 1.1 resolve to 1.0.0.1? I don't recall this being in any of the documents about CIDRs. Are browsers implicitly mapping IPv4 addresses temporarily into IPv6 addresses during parsing, such that "1.1" becomes "1::1", and then gets IPv6 abbreviated-form expansion applied to it?

View on HN

https://en.m.wikipedia.org/wiki/IPv4#Addressing

> IPv4 addresses may be represented in any notation expressing a 32-bit integer value.

I remember reading a man page that explained this really succinctly but I cannot remember which one it was. A tool like ping I believe.

Was it inet_aton?

https://www.freebsd.org/cgi/man.cgi?query=inet_aton&sektion=...

Bingo!

> When fewer than four numbers are specified in the address in dotted notation, the last value is treated as an integer of as many bytes as are required to fill out the address to four octets. Thus, the address 127.65530 is equivalent to 127.0.255.250

Wow, it actually works: http://127.65530

TIL

This was a thing in late 90s spam.

There's some weird legacy parsing for IPv4 addresses with less than four components. 1.2.3.4 can be represented equivalently as 1.2.772, 1.131844, or 16909060. (Note that 772 = 0x0304, 131844 = 0x020304, and 16909060 = 0x01020304.)

TL;DR: the second "1" in "1.1" is treated as a 24-bit integer.

Longer explanation: https://blog.dave.tf/post/ip-addr-parsing/

Aha. I had thought I recalled the two-dot case being 16+16, rather than 8+24.

It was for compatibility with classful networks. If you have a class A (/8) network, you could (in principle) treat it as a single network and number all the machines on it sequentially from 12.1 to 12.16777215.

Of course, nobody actually does that anymore. But the parser behavior is still out there because there's the possibility that someone is still using it...

I'm also curious. Especially since curl 7.64.1 (Release-Date: 2019-03-27, on macOS) says:

  % curl 'http://1.1/'
  error code: 1003

while curl 7.85.0 (Release-Date: 2022-08-31, on FreeBSD) says:

  % curl 'http://1.1/'
  <html>
  <head><title>301 Moved Permanently</title></head>
  <body>
  <center><h1>301 Moved Permanently</h1></center>
  <hr><center>cloudflare</center>
  </body>
  </html>

That is because their http:// site redirects to https://

Sure, but why do the two different versions of curl give different results? With 7.64.1:

  % curl --dump-header /dev/tty 'http://1.1/'
  HTTP/1.1 403 Forbidden
  Date: Sun, 11 Sep 2022 19:01:53 GMT
  Content-Type: text/plain; charset=UTF-8
  Content-Length: 16
  Connection: close
  X-Frame-Options: SAMEORIGIN
  Referrer-Policy: same-origin
  Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
  Expires: Thu, 01 Jan 1970 00:00:01 GMT
  Server: cloudflare
  CF-RAY: 7492a7924b2bd895-CPH

  error code: 1003

(Note that curl 'https://1.0.0.1/' works just fine, so it's not like curl is blocked by the server on general principle.)

With 7.85.0:

  % curl --dump-header /dev/tty 'http://1.1/'
  HTTP/1.1 301 Moved Permanently
  Server: cloudflare
  Date: Sun, 11 Sep 2022 19:03:09 GMT
  Content-Type: text/html
  Content-Length: 167
  Connection: keep-alive
  Location: https://1.0.0.1/
  CF-RAY: 7492a96a181df18a-PIT

  <html>
  <head><title>301 Moved Permanently</title></head>
  <body>
  <center><h1>301 Moved Permanently</h1></center>
  <hr><center>cloudflare</center>
  </body>
  </html>

Curl wasn’t able to normalise ip adresses till this commit [0]

[0] https://github.com/curl/curl/commit/56a037cc0ad1b2a770d0c08d...

Indeed - so while it's hitting Cloudflare, the 1.1.1.1 IPs are all technically vhosts for `cloudflare-dns.com`, so a good `host` header in the request is required to reach it.

For this reason, you could use a CNAME setup[0] and instead of using CNAMEs for proxied subdomains, you input 1.1.1.1 A records in your authoritative dns, and everything on Cloudflare's side will still see your hostname in the host header / SNI, and your website will load.

0: https://developers.cloudflare.com/dns/zone-setups/partial-se...

Yeah, that was a bug in curl till 7.77.

If you want to full details, see [0]

[0] https://daniel.haxx.se/blog/2021/04/19/curl-those-funny-ipv4...

That's the answer I was hoping for. Thanks!

Interesting. If you use curl -v, you can see that the difference is that the newer version of curl canonicalizes(?) the Host: header to "1.0.0.1", which the server recognizes and responds to with a redirect. The older version sends "1.1" as the Host: header, which the server doesn't recognize, so you get a "403 Forbidden" response with the cryptic "error code: 1003" in the body.

I get the same behavior from other nonstandard ways of specifying 1.0.0.1, like "curl http://01.00.00.01/"

I suspect it gets mapped to 1.0.0.1 because no other resolution is possible. Any other locations for the two zeros results in an invalid IP (either starting or ending in 0).

Ending in 0 is valid; you can have 1.0.1.0/23 as an IP.

https://stackoverflow.com/a/14915309/

https://jodies.de/ipcalc?host=1.0.1.0&mask1=23&mask2=

Absolutely nothing wrong with ending with a .0.

I suspect you are confused by n.n.n.0/24 being a network address in a /24 network which is obviously very common. However there are way more networks of other sizes that have .0 addresses in them.

We're also arguing that it ought to become usable even in a /24: https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...

It only requires changes within the LAN to accomplish this, since distant hosts are already not supposed to assume anything about how networks are or are not subnetted. (For instance, they don't know whether you're on a /24 or not.)

You can find some addresses ending a lot of zeroes that already work within

http://ec2-reachability.amazonaws.com/

I still don't understand why, instead of doing something like this, not just switch to IPv6.

If you're operating a public site and you switch to IPv6-only, you'll no longer be reachable by the majority of the current Internet. That's a pretty big sacrifice for most people.

If you're operating a public site and you don't switch to IPv6-only, for example by doing dual-stack, you'll still need IPv4 addresses.

The challenge is that "just switch to IPv6" isn't something that you can do unilaterally if you need to talk to the rest of the Internet.

I once had my ISP (BHN) assign me a public IP that ended in .0 That turned out to be a neat experiment. I regularly hit webpages and other services that would deny my connection. I guess they considered me multicast traffic or some sort of bogon.

Huh, and today I learned something new. Thanks!

Reply on news.ycombinator.com