Ask HN: What is China doing with 1.1.1.1? | Hacker News Reader

Ask HN: What is China doing with 1.1.1.1?

47 pointsMonotoko17 comments

So I'm currently in Shanghai and tried to ping 1.1.1.1, and surprisingly I got a response!

* 64 bytes from 1.1.1.1: icmp_seq=1 ttl=250 time=3.46 ms

* I get a 19ms response from my 4G mobile network

* I get no response from a server in Hong Kong.

I looked it up and apparently it's a APNIC research prefix, so I decided to do a traceroute and got this:

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets 1 gateway (172.20.0.1) 0.370 ms 0.204 ms 0.443 ms 2 27.115.97.209 (27.115.97.209) 1.166 ms 1.157 ms 1.150 ms 3 112.64.249.197 (112.64.249.197) 3.351 ms 3.350 ms 3.343 ms 4 58.247.223.18 (58.247.223.18) 4.203 ms 4.204 ms 4.197 ms 5 1.1.1.1 (1.1.1.1) 5.927 ms 5.926 ms 5.919 ms

My question is why on earth have they routed 1.1.1.1? If I go to 1.1.1.2 it goes beyond the city and fails somewhere upstream.

View on HN

1/8 was reserved for a long time and various entities improperly used it as a private address. It was eventually given to APNIC for assignment use but a few ultra-commonly-used ranges and addresses like 1.1.1/24 and 1.2.3/something were never assigned because they get so much noise traffic and would break so many things.

It's improper for anything to use these unassigned in-theory-globally-routable addresses but there are no real hosts there and lots of local networks use them for random internal purposes. At least one commercial Wi-Fi hotspot uses 1.1.1.1 as a captive portal address.

Here's an incredibly detailed report on the situation on the 1-network: http://www.potaroo.net/studies/1slash8/1slash8.html

So 1.1.1.0/24 doesn't seem to be in the global table from North American carrier perspectives. It's certainly not a routed prefix for any of my machines in North America. The closest prefix I can see an announcement for on a global basis is 1.1.3.0/24 (CHINANET FUJIAN PROVINCE NETWORK).

Like bcoates said, there's a bunch of dumb stuff out there designed by people who barely understood TCP/IP and used non-RFC1918 ranges for customer equipment. Occasionally they leak indirectly into a table that's being redistributed into some mom and pop ISP's BGP announcements, and this happens. The backbone carriers of the Internet all (well, maybe not tata) have much stronger filters than Honest Achmed's used car sales and Internet transit, so they tend to leak only within a country or region.

Occasionally its some ISP internal services and it's done deliberately to have easy to remember IP addresses for techs working on the network. I mean, do you want to have to remember to point SNMP traps to 216.31.49.167 or would you rather only have to remember 1.1.1.1 instead? Then the prefix hits the border bogon filter and remains entirely with that ISP's network.

Now that I think about it, scanning ISPs for known unannounced prefixes in the global table would be kind of a fun project to discover all the little internal services ISPs might have squirreled away throughout their network.

Nothing from Shenzhen. From the responses here I think you can rephrase the title "What are (some random provider in Shanghai) doing with 1.1.1.1?" which is borderline irrelevant to everyone, though bcoates' response was informative. :)

Could you guys please stop ping my router?

my guess is that mobile networks do something with it, or some mobile network equipment do something wierd.

I'm in Norway and it seem that a telenor (Norwegian telco) box respons to it:

# ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=246 time=67.3 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=246 time=57.9 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=246 time=77.4 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=246 time=76.1 ms

# traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets 1 gateway (192.168.1.1) 1.738 ms 1.746 ms 2.259 ms 2 77.16.1.146.tmi.telenormobil.no (77.16.1.146) 58.505 ms 64.686 ms 64.701 ms 3 10.72.52.250 (10.72.52.250) 64.703 ms 64.684 ms 64.718 ms 4 ti0001a401-ae14-21.ti.telenor.net (193.212.40.13) 71.297 ms 71.320 ms 71.316 ms 5 ti0300c360-ae49-0.ti.telenor.net (146.172.98.241) 87.921 ms 87.927 ms 87.921 ms 6 ti3163c360-ae8-0.ti.telenor.net (146.172.101.194) 87.751 ms 44.302 ms 56.143 ms 7 ti3153c400-ae5-0.ti.telenor.net (146.172.101.221) 56.130 ms 56.133 ms 56.112 ms 8 ti3153d400-ae3-0.ti.telenor.net (146.172.100.82) 62.571 ms 69.241 ms 69.198 ms 9 * * * 10 ti3171a210-xe3-11.ti.telenor.net (146.172.81.102) 68.961 ms *

I'm also in Shanghai, on a China Telecom hardline, I get nothing from 1.1.1.1:
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
--- 1.1.1.1 ping statistics --- 80 packets transmitted, 0 received, 100% packet loss, time 79915ms
What mobile network are you using?

China Unicom (I think) my work also has a Unicom line.

I am getting response from 1.1.1.1 from Brazil.
33 packets transmitted, 33 received, 0% packet loss, time 32051 Ms
rtt min/avg/max/mdev = 30.104/37.650/229.784/33.997 ms

In the U.S., near AWS East, and 1.1.1.1 times out.

That's funny.
I use 1.0.0.0/24 for my home network. Perhaps they're doing something similar.

You are part of the reason we have these problems :(
While that's probably never getting allocated at this point, that's also what everyone thought 10-20+ years ago about 1.0.0.0/8 and yet here we are.
When my organisation was allocated from 110.0.0.0/8 a few years back we were constantly seeking out others to remove us from their "bogon" filters blocking unallocated ranges that were static and not being maintained. Including big organisations like Commonwealth Bank of Australia. It was a real pain. Meanwhile the security advantage of this behaviour is highly dubious in my view - just as easy to steal an otherwise valid but un-used (or even used) prefix.
Thanks for reading my rant this far if you did, I'll return you to your regularly scheduled more insightful comments....... now.

I worked for a company once where each department had a public IP space, like 97.0.0.x or 98.0.0.x. When I told the network guy this wasn't proper and we should be using 192.168.x.x or 10.x.x.x he laughed and said "it really doesn't matter, nobody cares". To make all of these networks talk, share, etc they had to use a punch of equipment to tie each one in and then out via a Time Warner Road Runner circuit. This was about 1999 :-)

It seems as though the conventional wisdom has changed, because in my large org every device is assigned a public IP and access is controlled by our border firewall.
It's weird how much NAT has changed the thinking about network organization -- if you have the addresses you should get into the IPv6 state of mind -- publicly address all the things!
Now if your org picked 97/98 arbitrarily without actually owning the addresses relying on the fact that you wouldn't actually get routed any public traffic then that's a different story.

I too have worked at organizations that have been configured like this. I speculate that pressure on the limited IPv4 allocations has caused many places that had previously been configured with large public IP blocks, to sell sub-allocations, for profit. NAT certainly does enable this practice but isn't the root cause. Sell those IPv4 blocks for $$$ -- who needs their laptop getting a public IPv4 address anyway?

Be legit and use 10.0.0.0/24, or even 10.0.0.0/8 instead.

Or a subnet of 172.16.0.0/12 if you want to be a hipster. :) (Or if you need to interact with other networks that use the other RFC1918 subnets -- hardly anyone uses 172.16.)

I deal with lots of devices we put on customers networks. The problem is that 172.16.0.0/12, 10.0.0.0/8 and 192.168.0.0/16 are all used by customer networks. It's a pain when setting up VPN addressing. Thus I chose 11.0.0.0/16 (sadly not possible to use IPv6). My devices will never need to reach DoD, so that's very convenient.

Reply on news.ycombinator.com