Issues with allocating from 1.0.0.0/8

Posted by Andree Toonk - January 24, 2010 - bogons - 7 Comments
This week it was announced that IANA has allocated 1.0.0.0/8 to APNIC. This prefix must look familiar to many as we see it often in examples and documentation. And let’s be honest haven’t you used 1.1.1.1 on one of your test routers to quickly test something? Receiving a prefix from this range might result in some issues in regards to duplicate announcements and duplicate address usages. Duplicate announcements If multiple networks announce the same prefix it might result in traffic being routed to the wrong network. This problem becomes even worse if someone else starts to announce a more specific of this network. Normally these ‘hijacks’ are not all that common, but with prefixes from this range it might be a bigger issue due to the nature of this prefix. To try to quantify this I decided to take a look in the BGPmon.net database in which we have a complete collection of bogon announcements since May 2009. Any announcement in the 1.0.0.0/8 range in the last 9 months is recorded in this database. In this 9 month period we detected 364 unique announcements for in prefix in the 1.0.0.0/8 range. If we group those announcements by origin AS and announced prefix we see 23 unique announcements.
+----------------+----------+-----------------------------------------------------------------------------+
| prefix         | OriginAS | AS_name                                                                     |
+----------------+----------+-----------------------------------------------------------------------------+
| 1.0.0.0/9      | AS24785  | JOINTTRANSIT-AS Open Peering BV trading as Joint Transit                    | 
| 1.1.0.0/16     | AS47377  | KPNBE T2 Belgium NV                                                         | 
| 1.1.0.0/24     | AS3549   | GBLX Global Crossing Ltd.                                                   | 
| 1.1.1.0/24     | AS8300   | Test-AS --  Swisscom Ltd                                                    | 
| 1.1.1.0/24     | AS30733  | GLOBUS-AS GLOBUS-TELECOM Autonomous System                                  | 
| 1.1.1.0/24     | AS6503   | Axtel, S.A.B. de C. V.                                                      | 
| 1.1.1.0/24     | AS34695  | E4A-AS E4A Primary AS                                                       | 
| 1.1.1.0/24     | AS8218   | NEO-ASN AS Confederation of Neotelecoms, euNetworks AG and Upstreamnet gmbh | 
| 1.1.1.0/24     | AS3549   | GBLX Global Crossing Ltd.                                                   | 
| 1.1.1.0/24     | AS45899  | VNPT-AS-VN VNPT Corp                                                        | 
| 1.1.1.0/24     | AS16735  | Companhia de Telecomunicacoes do Brasil Central                             | 
| 1.1.1.0/30     | AS38091  | HELLONET-AS-KR CJ-CABLENET                                                  | 
| 1.1.1.0/31     | AS8359   | COMSTAR COMSTAR-Direct global network                                       | 
| 1.1.1.1/32     | AS45400  | NICNET Korea Telecom-PUBNET                                                 | 
| 1.1.1.10/31    | AS8359   | COMSTAR COMSTAR-Direct global network                                       | 
| 1.1.2.0/30     | AS3313   | INET-AS I.NET S.p.A.                                                        | 
| 1.1.88.0/24    | AS4645   | ASN-HKNET-AP HKNet Co. Ltd                                                  | 
| 1.1.88.0/24    | AS39386  | STC-IGW-AS Saudi Telecom Company                                            | 
| 1.120.0.0/13   | AS23148  | TERREMARK Terremark                                                         | 
| 1.2.3.0/24     | AS19151  | WVFIBER-1 - WV FIBER                                                        | 
| 1.20.23.178/32 | AS26592  | Dominio BR Consultoria em Informatica Ltda                                  | 
| 1.40.0.0/13    | AS23148  | TERREMARK Terremark                                                         | 
| 1.80.0.0/13    | AS23148  | TERREMARK Terremark                                                         | 
+----------------+----------+-----------------------------------------------------------------------------+
A complete list of bogon announcements can be found here: As you can see the 1.1.1.0/24 prefix is the most popular prefix, so we can only hope APNIC won’t allocate this prefix. Except maybe for a nice honeynet project. Duplicate address usage Duplicate announcements are not the only thing networks in the 1.0.0.0/8 prefix have to worry about. As it turns out a number of organizations have used this prefix as an alternative for the RFC1918 prefixes. With the reasoning that many people already use 192.168.0.0, 10.0.0.0 or 172.16.0.0 , so chances of collisions are reasonable. So these bright minds came up with the idea of using a unallocated prefix as an alternative, such as for example 1.0.0.0/8 AnoNet AnoNet is a private friend-to-friend network built using VPNs and software BGP routers. anoNet works by making it difficult to learn the identities of others on the network allowing them to anonymously host content and IPv4 services. Also see http://en.wikipedia.org/wiki/AnoNet The prefix they use for this network is 1.0.0.0/8. Apparently AnoNet is planning to do the same for their IPv6 initiative, as according to their website: “Services are gradually being migrated to dual-stack. It is all in the de00::/8 range” de00::/8 is a unallocated range, just as 1.0.0.0/8 used to be.... WIANA Wiana is The Wireless Internet Assigned Numbers Authority, provides IP addresses for wireless devices from the 1.0.0.0/8 prefix. Ironical WIANA claims to have been formed to meet the that need network policies are upheld. According to their FAQ the reason for this prefix is that several protocols used already utilize the 10.x.x.x network for unregistered addresses during handshaking. Another class A network was required. Unfortunately for WIANA (and the future legitimate holder of this prefix) soon, the prefix they choose will no longer be unqiue. Receiving a prefix from the 1/8 range The role of the RIRS is to make sure prefixes are allocated to one organization only and as a result should be unique. With prefixes from the 1.0.0.0/8 prefixes this can no longer be guaranteed. Not because of multiple allocations by the RIR, but in this case by other organizations that thought it would a smart idea to choose a random unallocated prefix. In order to prevent issue’s with BGP announcements, looking at the bogon announcements it’s probably a good idea to (at least not yet) allocate prefixes in the 1.1.0.0/16 range as these seem to be leaked the most. As Alain Durand mentioned on Nanog: “Who said the water at the bottom of the barrel of IPv4 addresses will be very pure? We ARE running out and the global pain is increasing.

7 comments

Leave a Reply

Your email address will not be published. Required fields are marked *