5 ms·

Close second: http://1.1 http://1.1

derefr 4y ago
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?
- eesmith 4y ago
  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>
  - cyral 4y ago
    That is because their http:// http:// site redirects to https:// https://
    - eesmith 4y ago
      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/ 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>
      - A321321 4y ago
        Curl wasn’t able to normalise ip adresses till this commit [0] [0] https://github.com/curl/curl/commit/56a037cc0ad1b2a770d0c08d3d09dee1ce600f0f https://github.com/curl/curl/commit/56a037cc0ad1b2a770d0c08d...
        judge2020 4y ago
        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-setup/ https://developers.cloudflare.com/dns/zone-setups/partial-se...
  - A321321 4y ago
    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-addresses/ https://daniel.haxx.se/blog/2021/04/19/curl-those-funny-ipv4...
    - eesmith 4y ago
      That's the answer I was hoping for. Thanks!
  - gdavisson 4y ago
    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/ http://01.00.00.01/"
- duskwuff 4y ago
  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/ https://blog.dave.tf/post/ip-addr-parsing/
  - derefr 4y ago
    Aha. I had thought I recalled the two-dot case being 16+16, rather than 8+24.
    - duskwuff 4y ago
      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...
- oarmstrong 4y ago
  https://en.m.wikipedia.org/wiki/IPv4#Addressing 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.
  - geraldcombs 4y ago
    Was it inet_aton? https://www.freebsd.org/cgi/man.cgi?query=inet_aton&sektion=3&manpath=freebsd-release-ports https://www.freebsd.org/cgi/man.cgi?query=inet_aton&sektion=...
    - oarmstrong 4y ago
      Bingo!
  - lelandfe 4y ago
    > 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 http://127.65530 TIL
    - zhte415 4y ago
      This was a thing in late 90s spam.
- profile53 4y ago
  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).
  - jodrellblank 4y ago
    Ending in 0 is valid; you can have 1.0.1.0/23 as an IP. https://stackoverflow.com/a/14915309/ https://stackoverflow.com/a/14915309/ https://jodies.de/ipcalc?host=1.0.1.0&mask1=23&mask2= https://jodies.de/ipcalc?host=1.0.1.0&mask1=23&mask2=
  - simonjgreen 4y ago
    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.
    - WarOnPrivacy 4y ago
      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.
      - deleted 4y ago
        [deleted]
    - schoen 4y ago
      We're also arguing that it ought to become usable even in a /24: https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ 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/ http://ec2-reachability.amazonaws.com/

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?

eesmith 4y ago
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>
- cyral 4y ago
  That is because their http:// http:// site redirects to https:// https://
  - eesmith 4y ago
    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/ 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>
    - A321321 4y ago
      Curl wasn’t able to normalise ip adresses till this commit [0] [0] https://github.com/curl/curl/commit/56a037cc0ad1b2a770d0c08d3d09dee1ce600f0f https://github.com/curl/curl/commit/56a037cc0ad1b2a770d0c08d...
      - judge2020 4y ago
        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-setup/ https://developers.cloudflare.com/dns/zone-setups/partial-se...
- A321321 4y ago
  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-addresses/ https://daniel.haxx.se/blog/2021/04/19/curl-those-funny-ipv4...
  - eesmith 4y ago
    That's the answer I was hoping for. Thanks!
- gdavisson 4y ago
  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/ http://01.00.00.01/"
duskwuff 4y ago
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/ https://blog.dave.tf/post/ip-addr-parsing/
- derefr 4y ago
  Aha. I had thought I recalled the two-dot case being 16+16, rather than 8+24.
  - duskwuff 4y ago
    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...
oarmstrong 4y ago
https://en.m.wikipedia.org/wiki/IPv4#Addressing 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.
- geraldcombs 4y ago
  Was it inet_aton? https://www.freebsd.org/cgi/man.cgi?query=inet_aton&sektion=3&manpath=freebsd-release-ports https://www.freebsd.org/cgi/man.cgi?query=inet_aton&sektion=...
  - oarmstrong 4y ago
    Bingo!
- lelandfe 4y ago
  > 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 http://127.65530 TIL
  - zhte415 4y ago
    This was a thing in late 90s spam.
profile53 4y ago
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).
- jodrellblank 4y ago
  Ending in 0 is valid; you can have 1.0.1.0/23 as an IP. https://stackoverflow.com/a/14915309/ https://stackoverflow.com/a/14915309/ https://jodies.de/ipcalc?host=1.0.1.0&mask1=23&mask2= https://jodies.de/ipcalc?host=1.0.1.0&mask1=23&mask2=
- simonjgreen 4y ago
  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.
  - WarOnPrivacy 4y ago
    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.
    - deleted 4y ago
      [deleted]
  - schoen 4y ago
    We're also arguing that it ought to become usable even in a /24: https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ 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/ http://ec2-reachability.amazonaws.com/