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

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.

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

Methodology
Using Geo IP libraries we are able to determine a country for each prefix. For each country it was determined how many unique Autonomous Systems (ASns) are announcing an IPv4 prefix. The same was done for IPv6 prefixes. Based on these two numbers we came up with a percentage indicating the how many organizations (ASns) have started to deploy IPv6.
Let’s for example take a look at the global statistics, there are currently 31.844 unique  ASns  announcing at least 1 IPv4 prefix.  There are 1.393 unique ASns announcing at least one IPv6 prefix. Resulting in a global deployment percentage of 4.4%.
The same analysis can be done on a per country basis, by only looking at prefixes that are registered to a specific country.  Let’s for example take a look at Canada. There are currently 818 autonomous systems announcing at least 1 Canadian prefix. As compared to IPv6, there are currently 36 unique autonomous systems announcing a Canadian IPv6 prefix, resulting in a deployment percentage of 4.4%.

The results
The analysis as explained above was done for all countries. Ideally each AS currently announcing an IPv4 prefix should eventually also announce a IPv6 prefix. So in a few years from now the IPv6 deployment ratio should be around 100%.
Below you’ll find the countries that had a deployment score higher than 10%. Country’s with more then 10 IPv4 ASN’s are indicated in bold. Results for all countries can be found here: http://bgpmon.net/IPv6_deployment_statistics.txt

One of the first things to notice is that there are quite a few of the smaller (in Internet terms that is) countries that have a high score.  For example The Vatican, has one ASn doing business for them (AS8978), that same ASn is also advertising an IPv6 prefix, hence the restults is 100%.   For the larger countries it’s much harder to get a good score.

Mapping the score

Global IPv6 deployment

If we visualize the score on the world map, it becomes clear that some parts of the world have a much better score then others.  Especially Europe and the East Asia seem to score high.  Another interesting observation is that parts of Africa scored particularly high.

And the winner is…
As could be seen in the result overview, the country with the highest score is  the Vatican. If we look at the (from a networking perspective) bigger countries, with at least 10 ASNs, Uruguay in Latin America is the winner. There are currently 26 ASN’s originating an IPv4 prefix that is used in Uruguay. As compared to 9 ASN that have IPv6 prefixes, resulting in a score of 35%. When we look at both the relative number as well as the absolute number we see that countries such as Japan,  New Zealand, Czech Republic, and The Netherlands are the leaders.

One of the ‘losers’ is the leader in the IPv4 world, The Unites States. The US has the highest number of Origin ASns in the IPv4 world as well as in the IPv6 world. However the percentage (316./ 13280) of 2% is well below the global average.

Are we on the right track?
Considering that the ideal score would be around ~100%,  and the global score is 4%, we still have quite some work to do.  Never the less, it’s promising to see that some individual countries such as Egypt and Uruguay score surprisingly high. And also Europe and parts of Asia seem to be on the right track.

I’ve created a list of Autonomous systems that are announcing the 6to4 (IPv4 192.88.99.0/24 and IPv6 2002::/16) anycast prefix. The same is done for autonomous systems that announce the teredo relay prefix (2001::/32). This list is dynamically generated by analyzing all BGP announcements and scanning for the relevant tunnel prefixes.  The data available on this website contains data that goes back to 2001 (using RIB snapshots) and will be updated continuously.

So if you’re interested in a list of current or historically autonomous systems that operate a 6to4 routers or teredo relays please take a look here:

• 6to4  Operators   (http://www.bgpmon.net/6to4.php?week=4)

• Teredo relay operators    (http://www.bgpmon.net/teredo.php?week=4)

One last tip, the week interval in the url limits the result to active entries. So in case of week=4, you will only see relays that have been seen in the last 4 weeks. For example, If you would like to go back in time and also see the 6to4 or teredo relays in January 2005 you would use a week interval of 210 http://www.bgpmon.net/6to4.php?week=210

IPv6 is also fully supported in the auto discovery feature for both prefix discovery as well as the regular expression generator.

I hope you, BGPmon users, are happy with this new functionality and will use it. As always if you have any feedback please let me know

Monitoring IPv6 prefix with BGPmon

.

As you will probably see, there’s quite a few strange IPv6 prefixes out there, looking like: a3c7:8800::/21 and a51e::/16 and many more. I’m not sure what this is, it’s not a bug in the BGPmon.net software as the same updates are seen by RIS (see here).  The announcements are very short, typically an announcement for these prefixes is followed by a withdraw just 1 second later. The (same) bogon prefixes are actually being announced by a number of origin AS’s looking a bit further shows that the one common thing is the rest of the AS path. So it could mean that somewhere in the transit path a faulty router is the cause of this. But that’s all guessing and if we go there we shouldn’t eliminate a bug in the RIS software. If anyone has any information about this, please leave a comment on this blog or sent me an email.

a few  weeks ago an interesting IPv6 prefix which caused my parser to start complaining. At first I thought it was a parser bug, but it’s not.  The prefix in question is 339:752f:14::/48  and is  seen by 35 RIS peers thus  seems to propagate fairly far.  Looking back in some old RIB files, it turns out that this prefix has been around for a while already, the first time somewhere in February, then it wasn’t visible for a while showing up in July/August again.  According to this IANA document, 0200::/7 used to be available for those who needed to map OSI NSAP to IPv6 [RFC4548]. However this is now obsoleted and declared historic.

This is probably is good moment to remember to check your IPv6 filters. And ask yourself, do I filter IPv6 announcements? Did you know that Gert Doering publishes some great resources for IPv6 filters? Please see: http://www.space.net/~gert/RIPE/ipv6-filters.html for IPv6 filter list recommendations.