
Ask HN: What is China doing with 1.1.1.1? - Monotoko
So I&#x27;m currently in Shanghai and tried to ping 1.1.1.1, and surprisingly I got a response!<p>* 64 bytes from 1.1.1.1: icmp_seq=1 ttl=250 time=3.46 ms<p>* I get a 19ms response from my 4G mobile network<p>* I get no response from a server in Hong Kong.<p>I looked it up and apparently it&#x27;s a APNIC research prefix, so I decided to do a traceroute and got this:<p>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<p>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.
======
bcoates
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](http://www.potaroo.net/studies/1slash8/1slash8.html)

------
trelliscoded
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.

------
contingencies
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. :)

------
huxflux
Could you guys please stop ping my router?

------
eggestad
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 * _

------
microsage
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?

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

------
fefb
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

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

------
mrkrabo
That's funny.

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

~~~
lathiat
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.

~~~
jason_slack
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 :-)

~~~
Spivak
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.

~~~
corymacd
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?

