OpenBGPD

▼ As part of my BGP training course, I explain to the participants that they can get BGP either by buying a router from the likes of Cisco or Juniper, or by running routing software such as Zebra, Quagga or OpenBGPD on a Unix (-like) operating system. Then I always mention that I haven't tried OpenBGPD yet, but I really should.

There's no time like the present, so I decided to take the plunge today.

OpenBGPD is a daemon implementing the BGP protocol that was developed for OpenBSD. So I first tried installing an OpenBSD 5.6 VM, which was pretty painless. Unfortunately, I couldn't get the OpenBSD package manager to install OpenBGPD for me. So I went to www.openbgpd.org (where I borrowed the image above). The latest version of OpenBGPD is 4.6, which is five years old—and it wouldn't compile. I never know whether it's my mediocre Unix skills or an actual show stopping issue in these cases. Update: the mediocre skills. As @tvlooy points out: OpenBGPD is included in the OpenBSD base install.

I then installed a FreeBSD 10 VM, which is also relatively painless but requires a bit more configuration during the installation process. However, FreeBSD has OpenBGPD in its ports system, and it installed from there without issue.

So now for the interesting part: configuring OpenBGPD.

It's really interesting to see a more Unix-like take on running BGP. The de facto standard way to configure and run BGP is the one invented by Cisco: you type configuration commands which are immediately applied to the active configuration. Zebra/Quagga uses the same model, even letting you interact with the daemon using telnet. Juniper, on the other hand, uses a very different model, where you use commands to modify the configuration and then "commit" that configuration (or roll back if necessary, very old school DBMS style).

With OpenBGPD, you simply edit the /usr/local/etc/bgpd.conf file after reading the man page. When you're done, you tell the bgpd to reload the configuration. I like this a lot. Monitoring the state of BGP sessions and the BGP table is done using the bgpctl utility, which lets you run clear and show commands that aren't entirely unfamiliar.

I plan on doing the BGP training course exercises using OpenBGPD myself next week, and see how well everything works in practice. The filtering/policy system seems to be inspired by the PF firewall with its insane "the last match is the one that counts" system, and the link between a filter rule and a neighbor is much less direct than with other systems. But I'm trying to keep an open mind.

OpenBGPD looks fairly mature from what I've seen so far, with one small but annoying omission: although you can configure 32-bit AS numbers in both ASDOT and ASPLAIN formats in the configuration file, bgpctl only shows them in ASDOT format. That means that if you have a BGP session with DE-CIX which has AS 196610, bgpctl will show that session as being towards AS 3.2. I.e., ASDOT notation is two 16-bit numbers separated by a dot (3.2) while ASPLAIN is simply a 32-bit number in decimal (196610). ASDOT was in vogue for a while when 32-bit AS numbers were introduced, but quickly fell out of favor as people realized that making regular expressions that match AS numbers with a dot in them would be very annoying. There's even a three-page RFC explaining all of this.

Permalink - posted 2015-01-31

IPv6 addresses and AS numbers in 2014

▼ After yesterday's final yearly IPv4 address report, I thought that today, I'd look at the other numbers the five Regional Internet Registries give out: IPv6 addresses and autonomous system (AS) numbers.

I have pages that show the latest numbers for these based on the most recently imported RIR data: IPv6 and AS numbers.

On January first, 2015, the total number of IPv6 addresses given out was 12626804692343330164921678734295040. The number of IPv6 addresses that are currently set aside for regular "global unicast" use is 42535295865117307932921825928971026432, so 0.0296% of the IPv6 address space has been used up so far. (And we can increase the global unicast space by at least a factor six if we need to.)

Of course the number of individual IPv6 addresses is rather meaningless, as each Ethernet or Wi-Fi network uses up 18446744073709551616 of those, even if there's only a single IPv6 system connected to that network. A more meaningful number is the number of /32s given out. A /32 is the size of the address block given to small-to-mediumsize ISPs. The equivalent of 159,372.68 /32s had been given out on January first, 17,916.90 of which in 2014. That number varies a bit from year to year, as some large ISPs or government entities happen to get particularly large blocks of addresses. However, the number of IPv6 address blocks has been growing fairly steadily from 2510 in 2010 to 4536 in 2014, with a total of 22,118 given out on January first. (For IPv4 the total is 145,917, which is 9039 higher than the total on January first, 2014.) Split out per RIR region:

              2014              Totals
RIR      Blocks   In /32s   Blocks   In /32s
 
AfriNIC     62      51.00     449    4617.00
APNIC      528    2663.00    3730   46210.15
ARIN       512    5232.68    4193   41465.94
LACNIC    1208    1363.20    3370    7989.54
RIPENCC   2226    8607.00   10376   59090.03

As every BGP expert knows, in order to advertise those IPv4 and IPv6 address blocks into the global routing system, you need an autonomous system number. Originally, those were 16 bits, allowing for 64512 usable AS numbers. 58,800 of those had been given out by January first, 2015, with the yearly rate being between 3500 and 4000 in recent years and 3056 in 2014.

However, BGP has been modified to work with 32-bit AS numbers. 9475 of those have been given out; 2052 in 2011, 1706 in 2012, 1577 in 2013 and 2988 in 2014. So the total number of AS numbers given out went pas 6000 for the first time last year. The mix is rather different at the different RIRs (ASNs given out in 2014):

RIR        16+32      32    % 32
 
AfriNIC      141     114     81%
APNIC       1299     722     56%
ARIN        1587     421     27%
LACNIC       964     570     59%
RIPENCC     2053    1161     57%

Unlike with the transition from IPv4 to IPv6, where you need to adopt IPv6 in order to talk to other IPv6 users, existing 16-bit AS numbers can be used to talk to routers that have a 32-bit AS number, making for a much easier transition.

Permalink - posted 2015-01-09

2014 in IPv4 addresses: closing the books on IPv4

▼ Ten years ago, I published my first "IPv4 address use report" over 2005. After that, I did 2006, 2007, 2008, 2009, and 2010. Today, I'm going back to the well one last time and provide an overview of what happened with the IPv4 addresses the past decade, which will close the book on the IPv4 address space as far as I'm concerned.

At the end of 2005, 2056.30 million of the 3706.65 usable IPv4 addresses had been given out: 55%. Today, it's 3592.99 million, which is 97%. Can you imagine driving a car with a tank filled to 3%? Or work on a computer with a drive that's 97% full?

All the numbers I present here are based on those published on the FTP servers of the five Regional Internet Registries that give out IP addresses. So an address is "in use" if an RIR has given it to an ISP or directly to an end-user organization. Whether that ISP or that organization actually uses the address is something we can't tell from these numbers.

Let me first explain the 3706.65 million number. IP addresses are 32 bits long, which means there's 2³² = 4,294,967,296 of them: 0.0.0.0 to 255.255.255.255, or 256 blocks of 16,777,216 addresses that start with the same number. We call one of those a "/8" in the business. 0/8 (or 0.0.0.0/8, which is 0.0.0.0 - 0.255.255.255) and 127/8 can't be used because they each contain one special address. 224/4 (everything starting with 224 to 239) is used for multicast and 224/4 (240 - 255) is "reserved for future use". This prompted some programmers who are a bit too fond of input validation to reject those addresses. As a result, those addresses can't be used on many systems, some of which are no longer updated, but still used. So 268 million perfectly good IPv4 addresses will probably remain unused forever. Last but not least, there's the 17,891,328 addresses set aside for private use: 10/8,172.16/12 and 192.168/16. So the total usable IPv4 address space is 222 × 16,777,216 - 17,891,328 = 3,706,650,624.

By downloading the old address delegation records from the RIR FTP servers it's possible to see how many addresses were given out at the end of each year. (Looking at just the latest files gives different results because addresses that have been returned in the meantime aren't listed in those.) This is the number of IPv4 addresses given out as of the end of the last ten years:

This is the net difference between each year and the previous year:

In this graph, the year 2014 looks strange, as two old class A blocks (16.78 million addresses each) that are used in Europe now fall under the RIPE NCC, while they were previously listed in the ARIN statistics. If we exclude all the "legacy" /8 blocks, the trend makes more sense:

(However, now there's a spike in 2012 for ARIN as a few of these blocks changed their status.)

APNIC and the RIPE NCC have been running on fumes for the past several years: ISPs in their region can only get one last block of 1024 addresses after those two dipped below the 16.78 million address mark (a /8 block). This happened in 2011 for APNIC and in 2012 for the RIPE NCC. This year, ARIN and LACNIC also reached a similar status, although ARIN doesn't use the "one last block" policy.

As a result, organizations that need IPv4 addresses now have to buy them from others who can spare some. IPv4 address transfers were especially big in the RIPE region in 2014. In the ARIN region, the number of transfers was limited at 180 in five years, but the size of the blocks transferred tended to be large; apparently here transfers were mainly used to get larger amounts of address space than what could (then still) be obtained directly from ARIN. Inter-RIR transfers are now also possible, and happen exclusively from the ARIN region to the APNIC region. See the RIPE and ARIN transfer statistics on their websites and APNIC's on their FTP server.

This is how three kinds of numbers compare: the addresses given out with a datestamp of 2014, the net difference between the total number of IPv4 addresses given out, and the number of addresses transferred in 2014:

                   AfriNIC APNIC   ARIN    LACNIC  RIPE NCC
 
Given out 2014:    12.45    3.77   26.06   19.11    2.61
 
Intra-RIR
transfers 2014:             3.85    2.98            9.61
   
Inter-RIR
transfers 2014:             1.10   -1.10
 
Net difference
2014-01-01 -       12.72    4.62   18.82   18.74    0.27
2015-01-01:    
   

When I compiled my first statistics over 2005, this was the list of the 15 biggest IPv4 address users:

Country   Addresses
 
US      1324.93 M        United States
JP       143.00 M        Japan
EU       113.87 M        Multi-country in Europe
CN        74.39 M        China
CA        67.43 M        Canada
DE        51.13 M        Germany
FR        45.16 M        France
KR        41.91 M        Korea
UK        40.18 M        United Kingdom
GB        33.63 M        Great Britain
AU        26.87 M        Australia
IT        18.39 M        Italy
BR        17.17 M        Brazil
NL        16.40 M        Netherlands
ES        16.29 M        Spain

Nine years later, the list looks like this:

Country   Addresses
 
US       1596.02 M        United States
CN        331.99 M        China
JP        202.61 M        Japan
GB        123.75 M        United Kingdom
DE        118.91 M        Germany
KR        112.32 M        South Korea
FR         84.05 M        France
BR         81.02 M        Brazil
CA         80.41 M        Canada
IT         53.44 M        Italy
AU         48.48 M        Australia   
NL         45.94 M        Netherlands
RU         45.55 M        Russian Federation
IN         36.36 M        India
TW         35.47 M        Taiwan

Surprisingly little has changed, although the BRIC countries have claimed a bigger piece of the pie. I don't know why India has barely a tenth of the number of IPv4 addresses that China has.

So long IPv4, it's been good knowing you.

Permalink - posted 2015-01-08

iPhone 6 network speed

▼ It was only a few months ago that I first got 4G/LTE working on my iPhone 5 using a Vodafone NL prepaid SIM, and the results weren't very spectacular: at home, I got 12 Mbps down, which is actually slightly slower than the 3G I get from KPN. Up speed was respectable at 5 or 6 Mbps. In the city center I got slightly better speeds at 20/20 Mbps.

So I was very curious what the iPhone 6, which supports many more LTE frequency bands, would do on the Vodafone LTE network. So I popped in the SIM... and nothing happened. Despite my best efforts and many reboots, I was stuck on 3G for almost a day. Or even GPRS on the 2G network:

Not sure if that did the trick, but I finally got 4G after resetting my network settings. When I first popped in the SIM, I got a text message with a link to a provisioning profile, but that seems to give me the same settings that also appear automatically. However, when I later put my KPN SIM back in the phone, I couldn't get any data service until I removed the Vodafone provisioning profile.

I did some testing as I was traveling home by train, and I got various speeds, starting at about 20/20 Mbps down and up and going as high as 68/36 Mbps:

It's too bad that data plans are so limited and/or expensive, as you can burn though a gigabyte of data in two minutes at these speeds. Vodafone NL apparently doesn't support Voice over LTE yet, as I dropped down to 3G as soon as I made a voice call.

Wi-Fi has also been improved—but only on the 5 GHz band. On the 2.4 GHz band, you still get a maximum of 72 Mbps 802.11n:

The iPhone 5 and 5S did 150 Mbps 802.11n on the 5 GHz band; the iPhone 6 adds 433 Mbps 802.11ac:

These speeds are a good deal lower than what you get on a computer because computers usually have three antennas, which means they can be three times as fast if three data streams can reach the antennas independently. With only one Wi-Fi antenna, the iPhone is limited to 433 Mbps, but it'll reach that maximum more often.

Transferring files between my computer and the iPhone using iTunes, I got about 7 megabytes per second on the 2.4 GHz band, which completely saturates the channel. I got 15 to 22 Mbps on 5 GHz, which doesn't come close to saturating the channel. So if you're still using a 2.4 GHz only Wi-Fi base station or home router, you may want to consider upgrading it to something that supports at least 802.11n—preferably 802.11ac—on the 5 GHz band and you'll get better speed more consistently.

I would have loved to test Bluetooth 4.0 performance, but the iPhone doesn't support file transfers over Bluetooth. Annoying. Nokia could do this more than ten years ago. Apparently they want us to use their proprietary AirDrop system instead. I've seen this work very quickly between two Macs recently, but between my Mac and my iPhone, it takes forever for the two to "see" each other and the transfers then happen at about 5 megabytes per second.

Bottom line: the iPhone 6's networking can be very fast, but it all depends on the SIMs, Wi-Fi base stations, frequency bands and transfer protocols. So I'm glad it still comes with a USB cable, even if it's only USB 2.

Permalink - posted 2014-12-28