8.8.8.0/24 is the prefix that serves one of Google’s Open DNS servers, which is available at 8.8.8.8.
A few hours ago 8.8.8.0/24 was announced by AS30890 (EVOLVA Evolva Telecom s.r.l.), a provider from Romania.

This ‘Hijack’ lasted for about 7 minutes, and was detected by 14 RIS peers in 4 unique countries. The majority of these networks learned this announcement through AS6939.

This is the second time in a month that Google is affected by a hijack. Last month on July 9th, AS42473 (ANEXIA) a provider from Austria announced a more specific of one of Google’s prefixes.
The prefix 74.125.127.0/24 was announced by AS42473. This is a more specific of 74.125.126.0/23, a prefix that hosts many of Google’s public services.
This announcement was later identified as a copy paste mistake, and quickly resolved after the engineers of AS42473 detected the mistake.

This is yet another example of how easy it is to ‘accidentally’ mess with the reachability of prefixes. There’s not a lot we can do about this today, except for strict filtering on the edges and monitoring using services such as BGPmon.net.
Luckily there’s some good progress being made on the Resource Certificate Public Key Infrastructure (RPKI) initiative.
Hopefully RPKI related tools will become available soon, so that it will be easy for operators to deploy this. And although this will not be a full proof mechanism for preventing BGP hijacks, it will prevent us from most of the ‘fat finger’ incidents we see on regular basis.

====================================================================
New prefix for AS271 (Code: 60)
====================================================================
Detected new prefix:  f006:9000::/24
Update time:          2010-06-11 19:18 (UTC)
Detected by #peers:   4
Announced by:         AS271 (BCNET-AS - BCnet)
Upstream AS:          AS13768 (PEER1 - Peer 1 Network Inc.)
ASpath:               1280 174 3257 13768 271
Alert details:        http://bgpmon.net/alerts.php?details&alert_id=9019544
Add to my prefixes:   http://bgpmon.net/fp.php?aid=9019544

Looking at this message it seemed odd, although the prefix was very strange, the ASpaths seemed to make perfect sense. After some more digging I noticed that many other BGPmon.net users had also received an alert like this.

BGPmon.net keeps a list of bogon announcements, in this list you can seen many of the detected bogon announcements of yesterdat.
This list can be found here:
http://www.bgpmon.net/showbogons.php?inet=6

Looking at the large number of AS numbers, I found it hard to believe that all these ASn’s are actually announcing these prefixes. This would mean that about 100 networks at the same time decided to announce a bogon prefix, this is very unlikely so there must be something else.

Assuming that these prefixes are not originated by what seems to be the origin AS (based on ASpath), this would mean that the announcements are originated by another AS, which seems to spoof (AS prepends) the ASpath with these AS numbers.

More details
From what I can quickly see these ‘strange’ announcements are seen with at least about 100 different origin ASn’s.

Initially I though this was an issue with the BGPmon.net software, but after reviewing the data at the RIPE RIS website I see the same results.

These are some of examples of observed bogon prefixes:
0:1f00::/24
2800::/8
4000::/8
4800::/8
5810::/12
And many more

The announcements are detected by the following RIS peers at the AMS-IX – Amsterdam, Netherlands, MIX – Milan Internet Exchange and the PAIX – Palo Alto, United States.

Who announced this?
As the administrator of one these ASns I don’t believe these announcement really come from origin the AS as defined in the ASpath, i.e. the AS on the right hand side of the ASpath.
Looking more closely at all the ASpaths of all these bogon announcements, they all have 2 ASns in common,

174 3257 

Which are Cogent (174) & Tiscali (3257), so we should probably focus on those two.

Spoofed ASpath

All of these RIS peers above have a IPv6 relationship with Tiscali AS3257. It’s fair to assume that they also have an IPv6 peering with AS174 (Cogent) as that’s how they learned these announcements.

Because the RIS peers that detected this have a peering with both Cogent as well as Tiscali, it’s surprising that non of them reported a shorter path directly via AS3257. Instead the paths went through AS174 and then to AS3257.

Another observation is that AS3257 is a RIS peer, and as a result one of the peers that BGPmon.net uses to analyze data. However non of the bogon updates we’re detected by AS3257 (or more specifically, non were sent to the RIS collecter from AS3257).

Assuming that AS3257 never saw these updates, that would indicate that that is part of the spoofed AS path and makes 174 the source of these announcements.

Another possibly useful clue is that updates contain two AS174 communities.
174:21100 which according the the whois data means: peer route learned in EU
174:22005 no explanation available

What does this mean
Please note that the above are assumptions, as I have not had contact with either Tiscali or Cogent I can only report on the observations described earlier.
I have no idea what the purpose of these announcements were. In the past we’ve see ‘spoofed’ AS paths as part of a research project. But they have also been used in BGP man in the middle attacks.
Maybe one of you have an idea?

Although it seems they have leaked a whole table, only about 10% of these prefixes propagated outside of the Chinese network. These include prefixes for popular websites such as dell.com, cnn.com, www.amazon.de, www.rapidshare.com and www.geocities.jp.
A large number of networks impacted this morning were actually Chinese networks. These include some popular Chinese website such as
www.joy.cn , www.pconline.com.cn , www.huanqiu.com, www.tianya.cn and www.chinaz.com
A list of all prefixes that were announced/hijacked can be found here

The event has been detected globally by peers in The Netherland, UK, Rusia, Italy, Sweded USA, Japan and Brazil. However not all individual prefix ‘hijacks’ were detected globally, many only by a few peers, in one or 2 countries, but some by more.

Some details
All announcement had part of the AS path in common. The common part in the ASpath is (note the prepend).
4134 23724 23724

Which are:
AS4134 CHINANET-BACKBONE No.31,Jin-rong Street
AS23724 CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation

ASns peering with AS4134 seem to have picked this up and propagated that to their customers.
Some of these ASns include:
AS9002 RETN-AS ReTN.net Autonomous System
AS12956 TELEFONICA Telefonica Backbone Autonomous System
AS209 ASN-QWEST – Qwest Communications Company, LLC
AS3320 DTAG Deutsche Telekom AG
AS3356 LEVEL3 Level 3 Communications
AS7018 ATT-INTERNET4 – AT&T WorldNet Services

All RIS peers that detected this where behind (transit/peer) one of those ANS’s.

AS2914 NTT-COMMUNICATIONS-2914 – NTT America, Inc. customers
Looking at more routing information it seems that AS2914 saw more then just the 10% mentioned above. So the impact for NTT America customers might have been bigger.

Impact
28% of the RIS collectors used by BGPmon.net have detected these events. This means that quite a number of networks were impacted by this. The first announcement was detected at 2010-04-08 17:54:31 (UTC), the last ‘hijack’ announcement was at 2010-04-08 18:10:14.
Most ‘alerts’ have now been cleared, they typically lasted a few minutes.

Probably more then the 51 peers mention above would have detected the prefix, but not have chosen this as the best path. Most likely due to the ASpath length or other policies. I believe it’s fair to assume that the impact in China and probably Asia was far bigger then the rest of the world.

Possible Cause
I have not spoken with engineers from AS23724, so I can only speculate. Given the large number of prefixes and short interval I don’t believe this is an intentional hijack.
Most likely it’s because of configuration issue, i.e. fat fingers. But again, this is just speculation.

Prefix distribution
Most prefixes impacted by this were prefixes from the US and China. Below you’ll find the top countries impacted:

Country => number of prefixes hijacked by AS23724
US => 10547
CN => 10298
KR => 2857
AU => 1650
MX => 885
IN => 719
JP => 604
BR => 592
FR => 508
RU => 471
CA => 425
TH => 372
ID => 369
IT => 338
CO => 328
GB => 322
CL => 302
SE => 281
HK => 276
EC => 272
DE => 227

Example alert message

====================================================================
Possible Prefix Hijack (Code: 10)
====================================================================
Your prefix: 203.190.56.0/21:
Prefix Description: www.infoseek.co.jp
Update time: 2010-04-08 16:09 (UTC)
Detected by #peers: 4
Detected prefix: 203.190.56.0/21
Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation)
Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street)
ASpath: 8331 9002 9002 4134 23724 23724
Alert details: http://bgpmon.net/alerts.php?details&alert_id=6617721
Mark as false alert: http://bgpmon.net/fp.php?aid=6617721

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.

I’ve been using this feature for a few weeks now and found it very useful.
The things it will report on is differences in announced prefixes, including a breakdown of which prefixes are reachable via which upstream / peer AS. This will help you detect if a prefix is no longer reachable via one or all peers or upstreams.
The routing report will also report on upstream and downstream ASns. At the end of this blog post you’ll find an example report. Please note that each report also contains a summary report of your AS, comparable to the cidr report.

This routing report feature can be enabled/disabled on a per AS basis in the ‘my ASn’ page.
Update January 12, 2010
The routing report feature is disabled by default. If you would like to use this feature you will need to enable it.

New Prefix alert (code60)
If you recently started to announce a new prefix, then you most likely received a BGPmon email with a New Prefix (code60) alert. These notifications are send out as soon as your AS starts to originate a new prefix.
This feature could only be enabled / disabled globally via the settings menu. If you’re using BGPmon.net for multiple ASns chances are that for some ASns you would like to have this feature enabled and for some disabled. As of this week this is possible and you should now be able to configure this on a per ASn basis.

Adding your AS to My ASn
All the ASns your are currently monitoring should have been added to ‘My ASn’ automatically. If you add a new prefix and ASn to my prefixes, remember to also add your AS to ‘My ASn’. Otherwise the ‘routing report’ and ‘New Prefix alert’ will not work, as your ASn needs to be added manually.

As always if you have any questions please leave a comment on this blog or send me an email.

From: BGPmon Alert < info@bgpmon.net >
To: you@gmail.com
Subject: BGPmon Routing report
Date: Sun, 10 Jan 2010 02:53:27 +0100 (CET)

Your routing table report for AS271 (BCNET-AS - BCnet)

================================== Changes: ====================================
RIB file used:
RRC01 -- LINX, London
RRC03 -- AMS-IX / NL-IX / GN-IX, Amsterdam
RRC11 -- NYIIX, New York
RRC12 -- DE-CIX, Frankfurt
RRC13 -- MSK-IX, Moscow
RRC15 -- PTTMetro, Sao Paulo

------ AS Adjacency report ------
New Downstream / Customer AS:
	+ AS25689 (NRCNET-AS - National Research Council of Canada)

------ Prefixes report ------
Lost prefixes for AS271
 - 207.23.245.0/24  	(Sky Research Inc.)
 - 209.87.17.0/24  	(UBC Commercial Client)

------ Prefixes reachable via peers report ------
 + 134.87.113.0/24 via AS6939	(BCNET IPv6 awareness day) now reachable via HURRICANE - Hurricane Electric, Inc.
 + 2607:f8f0:690::/48 via AS6939	(No valid route object!) now reachable via HURRICANE - Hurricane Electric, Inc.

 - 209.87.17.0/24 via AS6509	(UBC Commercial Client) no longer reachable via CANARIE-NTN - Canarie Inc
 - 207.23.245.0/24 via AS6509	(Sky Research Inc.) no longer reachable via CANARIE-NTN - Canarie Inc
 - 209.87.17.0/24 via AS6939	(UBC Commercial Client) no longer reachable via HURRICANE - Hurricane Electric, Inc.
 - 207.23.245.0/24 via AS6939	(Sky Research Inc.) no longer reachable via HURRICANE - Hurricane Electric, Inc.

================ AS271 Summary report 01/09/10 23:59:58: ====================

Upstream Adjacent AS list:
	*AS852  	 ASN852 - Telus Advanced Communications)
	*AS6327  	 SHAW - Shaw Communications Inc.)
	*AS6509  	 CANARIE-NTN - Canarie Inc)
	*AS6939  	 HURRICANE - Hurricane Electric, Inc.)
	*AS13768  	 PEER1 - Peer 1 Network Inc.) 

Downstream Adjacent AS list:
	*AS3633  	 BC-SYSTEMS - Province of British Columbia)
	*AS11105  	 SFU-AS - Simon Fraser University)
	*AS16462  	 UVIC-AS - University of Victoria)
	*AS25689  	 NRCNET-AS - National Research Council of Canada)
	*AS25722  	 GATEWAY-OPERATIONS - Payment Processing Inc.)
	*AS32956  	 ZED-RADIO3 - Canadian Broadcasting Corporation)
	*AS36000  	 NHA-ASN1 - Northern Health Authority)
	*AS36391  	 TRIUMF - TRIUMF (Tri-University Meson Facility))
	*AS25689         NRCNET-AS - National Research Council of Canada

Announced IPv6 prefixes:
	*2607:f8f0:670::/48  	 (No valid route object!)
	*2607:f8f0:680::/48  	 (No valid route object!)
	*2607:f8f0:690::/48  	 (No valid route object!)
	*2607:f8f0::/32  	 (No valid route object!) 

Announced IPv4 prefixes:
	*128.189.0.0/16  	 (BCNet Class B network)
	*128.189.0.0/17  	 (BCNet  network)
	*128.189.128.0/18  	 (UBC RESnet network)
	*128.189.192.0/18  	 (UBC wireless network)
	*128.189.4.0/24  	 (No valid route object!)
	*128.189.64.0/19  	 (No valid route object!)
	*128.189.96.0/19  	 (No valid route object!)
	*134.87.0.0/16  	 (BCNET-2)
	*134.87.112.0/24  	 (BCnet gigapop servers - News,DNS)
	*134.87.113.0/24  	 (BCNET IPv6 awareness day)
	*134.87.114.0/23  	 (BCNET conference 2009 (DUAL stack))
	*134.87.2.0/24  	 (BCnet gigapop C3 interconnect links)
	*134.87.3.0/24  	 (UBC_TRU DR  project)
	*134.87.4.0/24  	 (BC Genome Sequence Centre)
	*134.87.58.0/24  	 (BCnet gigapop C3 interconnect links)
	*137.82.0.0/16  	 (UBC)
	*142.103.0.0/16  	 (University of British Columbia (UBC1))
	*142.207.0.0/16  	 (NET-UNBC)
	*142.231.0.0/16  	 (BCNET3)
	*142.231.1.0/24  	 (BCnet gigapop C3 interconnect links)
	*142.231.110.0/24  	 (BCNET VANTX interconnects)
	*142.231.112.0/24  	 (BCnet gigapop servers - News,IRR)
	*142.231.113.0/24  	 (BCnet gigapop servers - RealServer, Video Server)
	*142.231.142.0/24  	 (BCnet gigapop connections)
	*142.231.2.0/24  	 (No valid route object!)
	*142.231.20.0/24  	 (UBC MedSchool AV Network)
	*142.231.3.0/24  	 (BCIT Internet Engineering Lab)
	*142.231.4.0/24  	 (UBC MedSchool AV Network)
	*142.231.5.0/24  	 (UBC MedSchool AV Network)
	*142.231.64.0/19  	 (University of British Columbia (UBC) Okanagan)
	*142.232.0.0/16  	 (BCITNET2)
	*142.90.0.0/16  	 (TRIUMF)
	*192.139.193.0/24  	 (DPIC)
	*192.146.156.0/24  	 (Thompson Rivers University)
	*192.219.32.0/19  	 (Open Learning Agency)
	*192.68.67.0/24  	 (British Coulmbia Institute of Technology (NET-192-68-67-0-2))
	*192.68.68.0/24  	 (British Coulmbia Institute of Technology (NET-192-68-68-0-1))
	*192.68.69.0/24  	 (British Coulmbia Institute of Technology (NET-192-68-69-0-1))
	*192.68.72.0/24  	 (British Columbia Institute of Technology (BCIT))
	*192.68.73.0/24  	 (BCIT Internet Engineering Lab)
	*192.73.5.0/24  	 (University of British Columbia (CDNnet))
	*198.162.20.0/22  	 (BCNET-AGG-13)
	*198.162.32.0/19  	 (University of British Columbia (UBC-CS))
	*198.162.67.0/24  	 (Forintek)
	*199.175.163.0/24  	 (SPINNAKER)
	*199.60.119.0/24  	 (Emily Carr Institute of Art and Design)
	*199.60.120.0/24  	 (Emily Carr Institute of Art and Design)
	*199.60.226.0/23  	 (Emily Carr Institute of Art and Design)
	*204.239.83.0/24  	 (NETBLK-UNBC-DMZ)
	*206.12.0.0/16  	 (NETBLK-BR-COL-6)
	*206.12.0.0/24  	 (BCNET ORAN interconnect links)
	*206.12.10.0/24  	 (Great Northen Way Digital Arts)
	*206.12.104.0/22  	 (University of British Columbia (UBC) Vancouver BCWARN BC Amateur Radio Network)
	*206.12.11.0/24  	 (E-Learning Conference)
	*206.12.12.0/24  	 (UBC Commercial Clients)
	*206.12.14.0/24  	 (CANFOR)
	*206.12.18.0/24  	 (UBC Commercial Clients)
	*206.12.19.0/24  	 (UBC Commercial Clients Debian Project)
	*206.12.2.0/24  	 (No valid route object!)
	*206.12.24.0/22  	 (WestGrid project)
	*206.12.24.0/24  	 (WestGrid)
	*206.12.28.0/24  	 (UBC Commercial)
	*206.12.52.0/22  	 (UBC eduroam wireless)
	*206.12.8.0/24  	 (WestGrid project inter-router links)
	*206.123.160.0/19        (Thompson Rivers University)
	*206.87.0.0/16  	 (BCNET (Non-portable address space))
	*206.87.0.0/18  	 (University of British Columbia (UBC) Okanagan)
	*206.87.128.0/19  	 (University of British Columbia (UBC) Vancouver wireless)
	*206.87.96.0/19  	 (University of British Columbia (UBC) Vancouver wireless)
	*207.23.0.0/16  	 (BR-COL-8)
	*207.23.128.0/19  	 (BC Childrens and Womens Hospital)
	*207.23.240.0/24  	 (BCnet gigapop interconnects (BCNET-4))
	*207.23.241.0/24  	 (BCNET VICTX interconnects)
	*207.23.242.0/24  	 (BCNET PGTX interconnects)
	*207.23.243.0/24  	 (BC Research - UBC Commercial Client)
	*207.23.249.0/24  	 (UBC Commercial Client)
	*207.23.252.0/24  	 (UBC Commercial Client)
	*207.23.254.0/24  	 (BCNET KELTX interconnects)
	*207.23.255.0/24  	 (BCNET KAMTX interconnects)
	*207.23.78.0/24  	 (UBC Research Enterprises Inc.)
	*207.23.8.0/21  	 (University College of the Cariboo)
	*207.23.94.0/24  	 (BCnet gigapop C3 interconnect links)
	*207.23.95.0/24  	 (BCnet gigapop C3 interconnect links)
	*207.23.96.0/20  	 (Royal Roads University (RRU))
	*209.87.0.0/18  	 (BCNET-5)
	*209.87.18.0/24  	 (Prince George Public Library)
	*65.39.232.0/22  	 (Farleigh Dickinson University Vancouver campus) 

 * The upstream / downstream categorisation in this report is strictly a description relative topology,
 and should not be confused with provider / customer / peer inter-AS relationships.

Web Services
The BGPmon.net API  provide a number of Web services  for developers. It allows you to query our database and let’s you integrate this in your own software.
As we are using SOAP  as the web services protocol. All the web services are described in a WSDL file, which can be found here.
Currently the following functions are available:

1. getIPInfo()
2. GetAlerts()
3. GetAlertDetails()
4. GetASname()
5. GetASPrefixes()
6. GetCountry()

More information about these function can be found here

Integrating BGPmon.net with your software
SOAP is a programming language independent protocol and is supported by all popular languages.  It allows you to access the BGPmon API over HTTP.
Some of the functions are specific for your BGPmon.net account and thus allow you to authenticate, others are currently publicly accessible.

Let’s get started with two examples
On the BGPmon.net API page you will find two examples of SOAP clients that use the the BGPmon.net SOAP API, a perl and a php example.
The examples are for BGPmon.net users to use, as well as to learn from in case you want to write your own application using our API.

Perl Nagios plugin example
The nagios plugin is written in perl and allows you to monitor your prefixes in Nagios by utilizing the BGPmon.net API.
The script expects a number of arguments, these allow you to filter on the type of alerts that will be returned.
The source code for this plugin example can be found here.

PHP RSS feed example
This is an example of utilizing the BGPmon.net SOAP API in PHP. The PHP RSS example retrieves all the alarms and represents the results in a RSS feed.
You will need to edit the PHP script and change the email and password variable to your own BGPmon email and password.
You can then call the php script using your browser or any other RSS reader. Optionally you can change the days, maxalert and active aruguments,
An example using the demo account can be found here:
http://www.bgpmon.net/rssclient.php?days=100&active=0&maxcode=100
The source code can be found here

Developing your own programs
Should you decide that you want to write your own program and you have any questions please leave a comment on this blog.
Also if you have created your own program and are willing to share this, please sent it to me so I can add it the the examples page.

Keep in mind that the Web Services API is a new feature, if you find any bugs please let me know and I will try to solve them asap.
Happy programming!

Now the time has come to release some more new features. Some of these features have been ready for quite a while but I wanted to wait for the new hardware to be installed first. You can expect announcement for these exciting new features soon.

As you can see the the original hardware was very low-end, it was actually bought before BGPmon.net was born. It was never really intended for this purpose. However, with the new hardware I’m confident I can support the ever growing BGPmon.net user base and growing feature set.

Just a final reminder, this project is 100% funded by me. If you would like to support this project and help recover some of the costs, please consider making a donation here.

But talk is cheap and the question remains, how far are we actually with rolling out IPv6 deployment?  We tried to answer that question by looking at the Internet Routing tables.

IPv6 deployment ratio.
Each network in the global Internet has a unique Autonomous System (AS) number. An Autonomous System can be an Internet Service Provider (ISP), Enterprise network, content provider or any other sort of network. Each AS number announces one or more prefixes.  By using Geo IP libraries we are able to determine a country for each prefix. This in turn allows us to determine the unique number of networks (AS numbers) per country.   Doing this for both IPv4 as well as IPv6 will result in the IPv4/IPv6 deployment ratio.

Let’s look at for example at Canada. There are 816 Autonomous Systems that originate a prefix registered as in use in Canada.  If we look at the IPv6 routing tables we see that 50 Autonomous Systems announce a Canadian IPv6 prefix.  This results in an IPv6 deployment percentage of 6.1%. Meaning that 6.1% of the networks doing business in Canada are currently actively deploying IPv6.

Results
If we look at the global statistics, i.e. comparing all IPv4 Autonomous Systems with all IPv6 Autonomous Systems we see that the global IPv6/IPv4 deployment ratio is 5.26%. This is slightly higher than the 4.4% we measured in April 2009.

And the winner is
Jersey , a small country between England and France, is the only country scoring a 100% deployment ration.  IPv4 and IPv6 prefixes registered to Jersey are only announced by one provider, AS8681 Jersey Telecom; resulting in a 100% ratio.

Jersey is followed by Cuba (75%), Oman, Monaco, Holy See (Vatican City State) and Fiji all scoring 50%. If we look at the bigger countries, i.e countries with at least a 100 (IPv4) networks we see that Czech Republic (19%), New Zealand(18%), Japan (17%) and The Netherlands (17%) are leading.

Are we on the right track?
Ideally the IPv6 deployment percentage should be around ~100%. Globally today we score a 5% ratio. Although this is one percent higher than half a year ago it’s still very low. Never the less, it’s positive to see that some individual countries such as Tunisia and Uruguay score surprisingly high. And also Europe and parts of Asia seem to be on the right track.

Top 10%
Below an overview of all countries scoring higher than 10%.  A complete list with the results for for all countries can be found here: IPv6 deployment statistics October 2009

Many of you have received alert messages for this event, informing you of the ‘possible hijack’.  I would like to take a bit of time explaining how to interpreted these message so it’s easy to determine the impact of such an event.
The first thing to look for is the number of peers that detected this prefix. In this case the event was detected by 2 peers, this gives you an indication that this event did not have a significant widespread impact.
The next thing to do is to login to BGPmon and check the details of this alert, a direct link to this the detailed info page is now included in the email messages.
Here you’ll quickly see again the number of peers that detected this as well as the geographic location of these peers. In this case both peers were located in Italy, indicating that it’s a fairly local event.  The global impact is also visible on the world map, making it easy to determine the geographical impact.

The same detailed info page also shows the BGP messages that are relevant for this alert. This will give you some more detailed information about the exact BGP announcements. In case the alarm is cleared you will see the exact time this happened. An alarm is cleared when the peer that detected this alert saw  a new valid update for this prefix or a withdrawal. It will also display the exact duration of the event per peer.

BGPmon notification time
BGPmon alert messages are normally sent out a few minutes (<5min average) after we received the updates from the RIPE RIS collectors.
Yesterday, some of you, received the alert messages later then usual.  I apologize for this and am currently working on a solution for this in order to prevent the delay in notification in cases of ‘mass hijacks/leaks’ like we saw yesterday.  A significant part of the solution is  to upgrade some of the hardware components of the  BGPmon.net server.   If you or your company would like to support this project, please consider making a donation. For more information please see this page.

The reason that this caught my attention is that although leaks like this happen all the time in general they appear to happen by the less clueful. The DoD I think should not be considered in this category.  However this ‘leak’  has been happening for a few weeks (starting 2009-08-27).  This leads me to believe that the DoD does not monitor their own announcements…. Maybe they should open a BGPmon.net account?