Andree Toonk Blog

Skip to end of sidebar Go to start of sidebar
Access Google services over IPv6

Many big content providers are quite reluctant to enable their services over IPv6. The reason for this is that in many cases IPv6 connectivity does not yet have the same production level quality as IPv4 has. If for example amazon, ebay, google, etc would add AAAA records (IPv6 AAAA = IPv4 A record) for their websites, there's a possibility that some of your users will try to access your website over IPv6. In some cases the clients ISP network is not "really" IPv6 ready, IPv6 will only work to some parts of the Internet. The result is that these companies (Google, Amazon, Ebay, etc) will loose custommers and thus revenue. This is a real concern for these companies and for the global IPv6 deployment.

Google already made their search engine reachable over IPv6 using and has said to be commited to full IPv6 deployment. They are now taking it one step further. All there services will be accessible over IPv6, once they determined your ISP is IPv6 ready, i.e. meets certain quality requirments!  Depending on that the Google DNS server will either return a AAAA (ipv6) or A (IPv4) record. A ingenius system to control wether you will access google over IPv4 or IPv6!

Network not IPv6 ready

Ipv6 ready ISP

Google describes the requirements like this:

To qualify for Google over IPv6, your network must have good IPv6 connectivity to Google. Multiple direct interconnections are preferred, but a direct peering with multiple backup routes through transit or multiple reliable transit connections may be acceptable. Your network must provide and support production-quality IPv6 networking and provide access to a substantial number of IPv6 users.

If you think  your network meets the IPv6 requirements and you'd like to receive Google over IPv6, you can contact google at Also see:

Investing in a Modern Communications Infrastructure

Since President-elect Obama has announced he's planning to invest heavily in information technology, all kinds of organizations and industry sectors are preparing there proposals. IBM's CEO proposed this week that investing 30 billion dollars in ICT infrastructure will result in 1 million jobs.
Research network south of our border are also working on their proposals and the USTelecom Association is making their pitch in a youtube Video, Broadband Now: Yes We Can!
Explaining how investing in broadband will add $200 billion annually to the GDP and create many new jobs. Promoting Telecommuting, cheaper and improved education and much more. Watch the video here:

Are there readers who think that the Canadian goverment will (should?) follow this example?

Hacking routers

Attacks on the Internet infrastructure, such as router and control plane protocols seem to get more attention lately. Not surprisingly because of the huge possible impact. Last week at the Chaos Communication Congress in Berlin it was demonstrated that exploits for compromising heavily used Cisco routers are no longer a myth. A researcher has discovered a way to reliably exploit a known security vulnerability in a wide class of Cisco System routers, a finding that for the first time allows attackers to hijack millions of devices with a single piece of code attacking the ROMon.
The current code works on any Cisco device that is equipped with a PowerPC processor, such as the widely used 2600 and 17000 routers. According to the researched he's also close to doing the same on Cisco routers with MIPS microprocessors.
or checkout his presentation

Could consumers own their internet connections?

Interesting article in the cbc website, about fiber to the home and buying services at local exchanges such as the BCNET transit exchanges.

"Under the "homes with tails" model, customers would purchase a fibre wire connection to their home that would provide speeds far in excess of what is generally available in North America today. The fibre would be connected to existing open exchange buildings where a large number of telecommunications pipeline providers have equipment that forms the backbone of the internet."

read the whole story at:

An open market for IPv4 addresses

With IPv4 addresses in short supply, they could become increasingly interesting and it's not unthinkable that they will become marketable goods. And although RIR's are claiming that addresses are not property and cannot be sold or transferred. Most of the Regional Internet Registries (RIR) such as ARIN, RIPE and APNIC are now recognizing that some kind of address market may very well be inevitable and decided to work on a transfer policy. This is to make sure that the RIR's keep at least some form of control so whatever may happen the registration of addresses will be done correctly and uniqueness can be guaranteed.
The basic motivation of these transfer policy proposals is that once the allocation supply has exhausted, the only other source of supply to meet continuing demand (and the demand will be there!) will come from already allocated addresses. As a result the traditional function of allocation by RIR's will be replaced by the operation of transfers.

Interesting times are ahead of us when the unallocated IPv4 address pools are empty. There will still strong demand for further IPv4 addresses, so what is a "fair" way of meeting that demand?
It's not uncommon to assume that demand lies in poorer developing economies while unused holdings may tend to sit in the richer parts of the world such as here in Canada. Should the poor be forced to buy from the rich? What is fair? Is the monetisation of addresses and the emergence of a market a fair outcome in an environment of a global communications system?

Read more regarding this on Geoff Huston's Blog:

Learning from other research networks

The eighth annual TERENA Compendium of National Research and Education Networks in Europe has been published. The 2008 edition includes data from more than 40 countries across Europe and surrounding regions. I found it interesting to read and learn what other research networks are doing. The range of topics surveyed has been wide ranging including  service development, the increasing use of fibre optics, staffing and funding, and general information regarding the NRENs. The 2008 edition also gives a more in-depth analysis and interpretation of NREN traffic figures than in past years. The report can be found here:

The time for IPv6 is now!

As many of you know, we are running out of IPv4 addresses, 800 days is what is left for IANA's global pool of available IPv4 addresses. It's not the question if we will going to run out, it's more a matter of when is it going to happen in 2010 or 2011?  This  is not to far away from now, so it is time to think about the consequences? At a first glance it doesn't seem to impact us, BC universities or BCNET much. We have more than enough IPv4 addresses left, so what's the problem here?
Obviously there's an immediate problem for new Internet users like startup companies who need address space for their products.  And let's not forget about developing countries that  are in high demand of IP addresses.  Also think about future developments such as every cell phone with an IP address, that would greatly increase the demand for IP addresses. So yes there's a real problem for those cases, the only 'real' solution for them is to use IPv6, basically because they have no other choice.

Now just think one step further. What does that mean if the new youtube can't get IPv4 addresses? yes it will probably use IPv6 addresses. And guess what, our students of course want to be able to reach this "new youtube", but they can't because we (universities in BC)  only provide IPv4 access because we thought we didn't have a problem with IPv4 addresses.  And all of a sudden we do need IPv6 access! Not because we have a shortage of addresses, but because other parts of the world do have a shortage and we want to be able to communicate with all hosts on the Internet.  Imagine a future student for example in china or japan wants to visit the UBC website for information about our programs. But guess what, they can't reach our IPv4 website, because they only have IPv6 access from home or new Iphone.  Just a few examples of the need for IPv6 support also in parts of the Internet where we have enough addresses for future use.

What would you answer your CTO if he/she asks you what your IPv6 plans are? "Eeh plan??, I thought that was something for researchers only?"  No, IPv6 is no longer a research project and we shouldn't look at it like that.  We don't start upgrading our networks to 10gbs when the links are congested, we plan ahead, so that this doesn't happen. They same should be the case for IPv6. We shouldn't wait till the problem presents its self and forcing us to come up with a solution. It's exactly the same for IPv6, we should carefully plan this and gradually roll out IPv6 support and the time to do that is now.

Some of you might have heard translation mechanism. I wouldn't want to  bet on IPv4 -IPv6 translation mechanisms (comparable to NAT) which are currently being standardized. If circumstances allow you you really want to go for native (dualstack) connectivity. BCNET is IPv6 ready and we can connect  your universities today!  Today is the day to start testing, experimenting so that next year you'll be ready to serve your costumers with IPv6 connectivity.  Remember that IPv6 is not an extra fancy feature like multicast, it's going to be basic functionality soon, very soon!

BGPmon receives community credits

There's been quite a lot of talk yesterday and today on NANOG and elsewhere about AS16735 (Companhia de Telecomunicacoes do Brasil Central) "Hijacking" prefixes, including all of BCNET's (customers) prefixes.  Many network other operators are now using BGPmon to monitor their prefixes and were quickly notified of this issue. Many BCNET costumer can rest assured that we are monitoring majority of your prefixes to detect problems like this as soon as possible and try minimize the impact of this. Of course BCNET costumer NOC's can also create their own account, UBC for example is one of the Universities that is monitoring their prefix.   Different blog sites have published articles about this event, many writing very positive about For example the renesys blog site:
and the tao security blog:
Overall the feedback and reviews on those blog sites as well as the Nanog list are very positive for BGPmon! This is good motivation for further development, such as IPv6 support!
Quote from renesys :

"None of this should detract from the really significant benefits that BGPMon and similar services provide the internet service provider community..."

For those interested, below a short summary of the events, also see here:
Between 01:55  UTC  and 02:15  267947 distinct prefixes were originated from AS16735 (Companhia de Telecomunicacoes do Brasil Central), hence a full table 'leak'.  After that more updates were detected. The last hijack update originated by AS16735 was received at 03:07 UTC. So the 'hijack' was there for about 75 minutes.
Although  AS16735 hijacked most of the address space on earth, at least from the perspective of their providers' customers in Brazil. The actual impact was only felt locally in Brazil, as many of their upstreams were filtering correctly.

For the last  weeks I've been working on a project i call  BGPmon monitors BGP updates and if the update is different then a predefined filter it will generate an alarm.
It will help network administrators to monitor their prefixes. This work is inspired by some recent incidents. The first one happened in February, when was hijacked by Pakistan Telecom.
And a few weeks ago it was demonstrated at a security conference, Defcon, how you could use this kind of attack to setup a Men in The Middle Attack.

So how does this work? Well I'm going to assume you're a techie and have some basic knowledge about Routing with BGP. In February Pakistan Telecom by accident started to announce a more specific route for the youtube prefix.
As a result, all traffic destined for youtube was directed to Pakistan Telecom. There it was Null routed, i.e. dropped and this caused youtube to become unreachable for several hours.
Last month a similar but slightly more elegant version if the above event was presented at Defcon. It was demonstrated that you could start an attack like the youtube hijack without dropping the packets. The result was a man in the middle attack.
The researchers showed that by announcing a more specific, all traffic was routed to their router/server. After analyzing this data for "Interesting" data it was then forwarded to the original destination. This was possible because the had prepended the
ASptah with the orignal Origin AS and upstream AS's. Causing those AS's not to accepts this more specific and as a result this path could be used as a path to the actual destination.
So what the researchers had demonstrated was a fairly elegant way to setup a man in the attack by using routing protocols, which affected the "whole" Internet. Although the concept isn't new, it was shown that it could actually work in a simple demo.

These events made me wonder how often this was actually happening, and if it was happening  to the networks I am responsible for. So what I did was take my old BGP weathermap project, modified some code and started to monitor
BGP updates for some of my networks as well as the networks for the top150 websites (according to I recorded everything from more specifics to OriginAS changes, Upstream  AS changes as well as known AS path changes.
Although I saw some interesting changes, it was hard for me (not being the network admin for those websites) to judge if those path changes were legit or a possible hijack.

Then a few weeks ago their was an interesting discussion on the NANOG mailing list about prefix hijack systems. It was discussed what a good system should be able to do, which features, etc.
Reading the discussion I realized that most of these features were actually available in my version. Given the interest I decided to rewrite some of the code to make it accessible and usable for others as well.
I also added some extra features such as support for 4byte AS numbers and flexible email filtering

Because I was able to reuse a lot of code from my BGP weathermap project I decided to create a webinterface for my bogon monitoring project as well. This page shows you an overview of all BGP updates containing bogon IP prefixes.
I have always had a great interest in bogons and have done some project regarding this before. One of my main questions has always been, how often does this actually happen and what kind of traffic is this. I hope to be able to answer part of the first question with this new website.
A few weeks ago we (BCNET) hit a JUNOS bug, causing us to leak private AS numbers to the Internet. We were notified of this and tried to solve this ASAP. It was then that I decided that I wanted to discover leaks like this my self instead of  having to rely on others. . So I added some more lines of code and private AS number detection was implemented as well! And I am actually shocked by the number of ASn's that leak private AS's, I'm currently seeing multiple updates containing private AS number per hour.

The system has already helped us discovering an other private AS leak and this time we were able to change the configuration on very short  notice. Clearing the issue. Another feature is notification of BGP withdraw messages. Lot's of withdraw messages are an indication of prefix instability. This feature will help BCNET with determining the impact of certain incidents.

I decided to integrate my BGP weathermap project in this website as well. You'll find some statistics regarding prefixes per country and which ASn's are announcing the most prefixes.  I also visualized the growth of the IPv4 and IPv6 table, taking into account AS numbers. As well as 2byte vs. 4byte AS numbers.

The result can be found! There's also a demo account in which you can see how captured the BGP MITM  demo at Defcon and the Youtube hijack.
If you're a network administrator, and want to try it? Please go ahead and create an account, it's free

Reading Google Chrome's Fine Print (EULA)

First of all, this post is not written in Google's new Browser called Chrome. You'll understand why if read this article (wink)
If you're like every other geek, you were one of the many people who downloaded Google Chrome within minutes of it's 3:00PM EST release today. There's no doubt about it -- Chrome is ridiculously faster than Firefox and IE. But you, like virtually every computer user out there, probably didn't even bother to gloss over the Chrome Terms of Service.

11. Content license from you

11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This license is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.

11.2 You agree that this license includes a right for Google to make such Content available to other companies, organizations or individuals with whom Google has relationships for the provision of syndicated services, and to use such Content in connection with the provision of those services.

11.3 You understand that Google, in performing the required technical steps to provide the Services to our users, may (a) transmit or distribute your Content over various public networks and in various media; and (b) make such changes to your Content as are necessary to conform and adapt that Content to the technical requirements of connecting networks, devices, services or media. You agree that this license shall permit Google to take these actions.

11.4 You confirm and warrant to Google that you have all the rights, power and authority necessary to grant the above license.

In other words, by posting anything (via Chrome) to your blog(s), any forum, video site, myspace, itunes, or any other site that might happen to be supporting you, Google can use your work without paying you a dime. They can go and edit it all they want. Even further, you're claiming that you have the power to grant these rights. So the people who work for Conde Nast (Wired, Arstechnica), TechCrunch, Gawker, any of the other big web publishers, or a university where the employee is performing research probably can't agree to the Chrome ToS because these people most likely don't have the right to give a license to the intellectual property (IP) they produce.

Most likely your employee or student agreement requires that your employer/university exclusively owns all IP that you make during your time there. Many employment contracts require that the employee signs away exclusive rights to all IP they create during work hours and anything created off hours related to their employer's business. Students get their class credits and the university typically gets copyrights to any writings and exclusive patent rights to any research and inventions. In essence, many content creators (news writers, song writers, artists, copy editors, musicians, students) cannot legally agree to these ToS because they'd be in breach of their employment/student contracts. Now, this does change slightly based on jurisdiction; under German IP law, there are a number of IP rights that content creators simply cannot give up contractually.

Further, you probably can't use your company or school email with Chrome, because your company probably exclusively owns your email, and you can't give away a license to something you don't own. You also can't make representations to Google that you have the power to license this IP if you don't.

Read the whole article here:
Or check out

4Bytes AS numbers

As of January 2009, that is 3 months from now, when you go to your RIR (Ripe, Arin, Apnic. Etc) for an autonomous system number, you will receive a 4 bytes AS number. So it's very likely that in the very near future we will be connecting customers with 4bytes AS numbers to our network. Time to find out what exactly that means, what are the implications and what do we as an ISP need to do, to be able to support that.

AS numbers as we know them today are 16bits, or 2 bytes numbers and used by networks to identity them on the "Internet". As we are running out of free ASnumbers, it was time to increase the amount of AS numbers from 2bytes (0-65535) to 4 bytes (0-4294967295).

A change like this would normally require changes on all the routers which are participating in the Internet routing (DFZ) or are using BGP to connect to their ISP. This is because their software would now need to support 4 bytes numbers instead of 2 bytes. If not all them would support this the Internet routing system would be divided in 2 separate incompatible camps, a 2 bytes side and the 4 bytes side. This, of course is unacceptable and fortunately they came up with a transition mechanism that eliminates the need for a 'flag day'.

How does this transition mechanism work? Well it's probably best to explain this by looking at a real live example on our BCNET router in Vancouver. There are some ISP's that already announce a prefix with a 4 bytes ASnumber:

Here we see the IPv6 prefix 2403:2000::/32 announced by the AS 131081, this is a 4 byte AS number (because it's higher then 65535).

The output above is from a router with software support for 4 bytes AS. Now let's take a look at how this prefix looks like from a router without 4bytes AS support.

As you can see above, according to the output the same prefix is now being announced by AS23456. This is a special reserved prefix, called AS_TRANS and an important part in the transition mechanism.
I guess by now you can already kind of guess how the transition mechanism works, basically the 4 bytes ASnumber is being replaced by the special 2bytes AS, AS_TRANS  i.e. AS23456. The  AS path in the bgp packets, only show 2 bytes AS numbers, however there is a new field defined used to represent the 4bytes AS path. This is a transitive optional attribute called AS4_PATH. It's only understood by routers with 4 bytes AS support and they will use it the reconstruct the 4bytes AS path as seen in the first example. All routers that do not understand this field (which is ok, it's optional) should not alter it and sent it to the next peer (transitive).
So in the Old BGP world (2bytes) New BGP speakers (4byte capable) will be represented as AS_TRANS, I,e, AS23456. So expect to see that AS more and more in the BGP tables

So basically you don't need to be afraid to fall of the Internet if your BGP router doesn't support 4bytes AS numbers. That's good to know right!? . (Having said that, understand that it means you'll loose AS-path filtering capability, and it's harder to see which AS is actually announcing the prefix)

Direct peering between Old BGP speaker and New BGP speaker

So what happens if one of your customers has a 4bytes AS and your router only supports 2 bytes autonomous system number . In this case you would configure a direct peering between a 2bytes AS and a 4byte AS using AS_TRANS. The 4 bytes AS will detect that ISP doesn't support 4 bytes AS, because of the capability code. The only way to setup a peering between a Old BGP speaker and a New BGP speaker is to define this as a peering with AS23456 (which is 2bytes). This will work fine, also if you have multiple peerings with AS23456 and these are actually different autonomous systems. Although it will work, it probably gets confusing if you have multiple of these peerings.

Representation of 32bit AS numbers

Then there seems to be a discussion going on of how to represent the 4 bytes AS number?
Just as a plain number? Maybe as a dotted decimal?  Some people suggested to use 2 decimals separated by a colon. However that looks a lot like how we use communities nowadays, so that's to confusing. The common agreement seems to be to use the ASdot representation, this represent the current 2 bytes AS numbers (less then 65536) just the way we are used to, as a decimal, such as AS271, or AS1103. 4bytes AS numbers will be represented as for example 1.10
From [1]:
ASdot[1] refers to a syntax scheme of representing AS number values less than 65536 using asplain[1] notation and representing AS number values equal to or greater than 65536 using asdot+[1] notation. Using asdot notation, an AS number of value 65526 would be represented as the string "65526" and as AS number of value 65546 would be represented as the string "1.10".
If we look at the examples I showed in the beginning that came from our Juniper routers, it seems that Juniper doesn't implement this representation, instead it uses ASplain.

The above is a simple explanation of the implications of using 4bytes AS numbers. If you would like to know the details, about the impact for loop detection risks, aggregation, communities I suggest you'd read RFC 4893.

Vendor Support

How about vendor support? Juniper supports 4 bytes AS numbers as of release 9.1. Also see the release notes (look for: BGP support for 4-byte autonomous system numbers)
Cisco is a bit behind, but it's my understanding that at the time of writing it's supported in the current IOS-XR release as well as NX-OS (Nexus).
For those of you who use software BGP routers, there are patches available for Quaga as well as OpenBGPd.

Autonomous System numbers assignments

IANA is the organization responsible for assigning AS numbers to the RIRs. Below you'll find a list of ranges assigned to the RIR's by IANA. The nice thing is that it's really easy now by just looking at the AS number by which RIR the ASnumber was assigned:

2.0-2.1023 APNIC
3.0-3.1023 RIPE NCC
4.0-4.1023 LACNIC
5.0-5.1023 AfriNIC
6.0-6.1023 ARIN

If you'd like to read more, visit the 4-byte AS number information pages of APNIC at

[1] Canonical Textual Representation of Four-octet AS Numbers

BCNET participates in The Quilt NOC Tools Workshop Videoconference September 10th

On September 10th a  workshop about  NOC tools organized by the Quilt will be held using video conferincing. The subject of Network Operations Center Tools offers many opportunities to share best practices among the R&E NOC community as well as identify areas for collaborations among members.  BCNET is one of the participating NOC's and will give 2 presentations. The first presentation is about our experiences regarding managing and monitoring an optical network and the use of the TL1-Toolkit. The second presentation is about using the Confluence Wiki as a customer portal.  The target audience for this workshop is R&E networking business managers, NOC managers and NOC staff.

The official agenda for the workshop can be found here

The video-conference will begin at 1:00 pm ET on Wednesday, September 10th and is planned run through 5:00 pm ET
For more information please see:

CERN announces start-up date for LHC 10 September

Geneva, 7 August 2008. CERN1 has announced that the first attempt to circulate a beam in the Large Hadron Collider (LHC) will be made on 10 September. This news comes as the cool down phase of commissioning CERN's new particle accelerator reaches a successful conclusion. Television coverage of the start-up will be made available through Eurovision.

Complete press release:

Some very cool pictures that give you some idea of the sheer size of this project which may well be the most audacious scientific undertaking in human history. can be found at:

NAT may come to IPv6 after all

The Internet engineering community (IETF) working on IPv6 is considering reintroducing NAT - one of the very features that the 'upgrade' to IPv6 was meant to eliminate. NAT is considered as a bad and evil feature because it break end-to-end connectivity. Because of the large address space, IPv6 doesn't need NAT to conserve addresses, so many IPv6 proponents have been looking forward to a future without NAT. In a five-page article, however, Network Worldsuggests that the Internet Engineering Task Force discussed this week in Dublin about adding NAT to IPv6. In this case NAT is added for transition (IPv4 <> IPv6) purposes, as the IETF is trying to find a reasonable way to translate between the IPv6 and IPv4 worlds. 
Read more at:

More HDTV streams over the ORAN

For the European championship soccer the CI group at UBC connected their HD tv setup with a convertor to send it out over IP. it's available over a High-Def stream! On the picture below you'll see Toby and Andree cheering for the Dutch team! using the HD tv (life size) screen to watch the game.

Maybe we can stream the Final (with the dutch team of course (wink) ) over Multicast or IPv6 (smile)