My book: 'Running IPv6' by Iljitsch van Beijnum BGPexpert My book: 'BGP' by Iljitsch van Beijnum

Home · BGP Expert Test · What is BGP? · BGP Vendors · Links · Archives · Books · My BGP Book

BGP (advertisement)

Table of contents (for this page):

BGP and IPv6 routing courses

Several times a year I teach two training courses, one about BGP and one about IPv6. The BGP course is half theory and half hands-on practice, and so is the new IPv6 routing course. Previously, we did an IPv6 course without a hands-on part.

The courses consists of a theory part in the morning and a practical part in the afternoon where the participants implement several assignments on a Cisco router (in groups of two participants per router).

The next dates are February 2 for the BGP course in Dutch and February 3 for the IPv6 routing course in Dutch. (There will be dates for the courses in English later in 2015.) Go to the NL-ix website to find more information and sign up. The location will be The Hague, Netherlands.

Interdomain Routing & IPv6 News

  • Search for: in news only
  • IPv6 as seen by Google doubled from 2.75 to 5.5% in 2014 (posted 2015-01-15) article 157

    Google has been measuring how many of its users have working IPv6 for some years now. At the beginning of 2014, this number was 2.75%; higher during weekends, lower on weekdays. We ended the year close to 6%, but then when we all went back to work in 2015, we dipped right back down below 5%!

    The IPv6 adoption of the top 15 IPv4-using countries on January 15, 2015:

    • US: 13.46%
    • China: 1.42%
    • Japan: 6.16%
    • UK: 0.28%
    • Germany: 12.8%
    • Korea: 0.31%
    • France: 5.32%
    • Brazil: 0.13%
    • Canada: 0.56%
    • Italy: 0.03%
    • Australia: 1.08%
    • Netherlands: 2.08%
    • Russia: 0.6%
    • India: 0.41%
    • Taiwan: 0.67%

    But Belgium is still world leader at 30.02%.

    So, 11% a year from now?

  • IPv6 addresses and AS numbers in 2014 (posted 2015-01-09) article 156

    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.

  • 2014 in IPv4 addresses: closing the books on IPv4 (posted 2015-01-08) article 155

    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.

    Read the whole article

  • Apparently, SSL generates IPv4 "too bigs" (posted 2014-12-19) article 153

    Yesterday, I wrote:

    ❝In almost a week, I received zero IPv4 "too big" messages.

    So it seems in the IPv4 world, path MTU discovery is dead.❞

    However, Joćo Taveira Araśjo told me that he sees a good number of IPv4 ICMP "too big" messages. Those seem to result from SSL traffic. At first, that seemed strange, as SSL is just payload for TCP so TCP MSS clamping should work on SSL sessions the same as on non-SSL sessions.

    But then I realized that this traffic could be SSL VPNs. If a VPN gateway takes an IPv4 packet and encapsulates that in SSL in a single TCP segment, then the size of those TCP segments isn't influenced by MSS clamping, so too big messages will be generated if the path MTU is smaller than the MTUs of the endpoints of the SSL connection. I wonder if those SSL VPN implementations handle path MTU discovery properly, though. Archives of all articles - RSS feed

My Books: "BGP" and "Running IPv6"

On this page you can find more information about my book "BGP". Or you can jump immediately to chapter 6, "Traffic Engineering", (approx. 150kB) that O'Reilly has put online as a sample chapter. Information about the Japanese translation can be found here.

More information about my second book, "Running IPv6", is available here. Apress, my new publisher, also has a sample chapter available: Chapter 5, The DNS.

"no synchronization"

When you run BGP on two or more routers, you need to configure internal BGP (iBGP) between all of them. If those routers are Cisco routers, they won't work very well unless you configure them with no synchronization.

The no synchronization configuration command tells the routers that you don't want them to "synchronize" iBGP and the internal routing protocol such as OSPF. The idea behind synchronizing is that when you have two iBGP speaking routers with another router in between that doesn't speak BGP, the non-BGP router in the middle needs to have the same routing information as the BGP routers, or there could be routing loops. The way to make sure that the non-BGP router is aware of the routing information in BGP, is to redistribute the BGP routing information into the internal routing protocol.

By default, Cisco routers expect you to do this, and wait for the BGP routing information to show up in an internal routing protocol before they'll use any routes learned through iBGP. However, these days redistributing full BGP routing into another protocol isn't really done any more, because it's easier to simply run BGP on any routers in the middle.

But if you don't redistribute BGP into internal routing, the router will still wait for the BGP routes to show up in an internal routing protocol, which will never happen, so the iBGP routes are never used.

The "no synchronization" configuration command tells the routers they shouldn't wait for this synchronization, but just go ahead and use the iBGP routes.

BGP Security

BGP has some security holes. This sounds very bad, and of course it isn't good, but don't be overly alarmed. There are basically two problems: sessions can be hijacked, and it is possible to inject incorrect information into the BGP tables for someone who can either hijack a session or someone who has a legitimate BGP session.

Session hijacking is hard to do for someone who can't see the TCP sequence number for the TCP session the BGP protocol runs over, and if there are good anti-spoofing filters it is even impossible. And of course using the TCP MD5 password option (RFC 2385) makes all of this nearly impossible even for someone who can sniff the BGP traffic.

Nearly all ISPs filter BGP information from customers, so in most cases it isn't possible to successfully inject false information. However, filtering on peering sessions between ISPs isn't as widespread, although some networks do this. A rogue ISP could do some real damage here.

There are now two efforts underway to better secure BGP:

  • Secure BGP (S-BGP) is developed by Bolt, Beranek and Newman (BBN). It has been around for several years and there is a proof-of-concept implementation. S-BGP tries to secure all aspects of the BGP protocol, and subsequently needs several signature checks for each BGP update, making the protocol relatively heavy-weight. You can see my earlier rants on S-BGP at the top of this page. Note that I'm not as anti-S-BGP as I used to be any more, although I still think implementing the protocol will be expensive because routers will need lots of extra memory (up to four times as much) and CPU power (possibly dedicated crypto hardware) and this aspect deserves some serious attention.

    Secure BGP (S-BGP) index at BBN.

  • Secure Origin BGP (soBGP) has surfaced fairly recently and hails from Cisco. There are no implementations so far. soBGP mainly focusses on securing the relationship between prefixes and the source AS number, and doesn't need as many computationally expensive checks as S-BGP. However, the protocol can easily be expanded to perform more checks.

    draft-ng-sobgp-bgp-extensions-00.txt (main soBGP draft)
    draft-white-sobgp-bgp-extensions-00.txt (deployment considerations)

    (If the links don't work, the drafts have expired; you'll have to use a search engine to find them.)

There is now also a different approach to increasing BGP security using an "Interdomain Routing Validation" service that works independent from the BGP protocol itself. See what I wrote about this in interdomain routing news on this site, or jump immediately to the Working Around BGP: An Incremental Approach to Improving Security and Accuracy of Interdomain Routing paper.

The IETF RPSEC (routing protocol security) working group is active in this area.


BGPexpert is available over IPv6 as well as IPv4. has both an IPv4 and an IPv6 address. You can see which one you're connected to at the bottom of the page. Alternatively, you can click on to see if you can connect over IPv6. This URL only has an IPv6 address.

What is is a website dedicated to Internet routing issues. What we want is for packets to find their way from one end of the globe to another, and make the jobs of the people that make this happen a little easier.

Your host is Iljitsch van Beijnum. Feedback, comments, link requests... everything is welcome. You can read more about me here or email me at iljitsch@bgpexpert. or follow iljitsch on Twitter.

Ok, but what is BGP?

Have a look at the "what is BGP" page. There is also a list of BGP and interdomain routing terms on this page.

BGP and Multihoming

If you are not an ISP, your main reason to be interested in BGP will probably be to multihome. By connecting to two or more ISPs at the same time, you are "multihomed" and you no longer have to depend on a single ISP for your network connectivity.

This sounds simple enough, but as always, there is a catch. For regular customers, it's the Internet Service Provider who makes sure the rest of the Internet knows where packets have to be sent to reach their customer. If you are multihomed, you can't let your ISP do this, because then you would have to depend on a single ISP again. This is where the BGP protocol comes in: this is the protocol used to carry this information from ISP to ISP. By announcing reachability information for your network to two ISPs, you can make sure everybody still knows how to reach you if one of those ISPs has an outage.

Want to know more? Read A Look at Multihoming and BGP, an article about multihoming I wrote for the O'Reilly Network.

For those of you interested in multihoming in IPv6 (which is pretty much impossible at the moment), have a look at the "IPv6 multihoming solutions" page.

Are you a BGP expert? Take the test to find out!

These questions are somewhat Cisco-centric. We now also have another set of questions and answers for self-study purposes.

You are visiting over IPv4. Your address is