Table of contents (for this page):
BGP and IPv6 routing coursesSeveral 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
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:
But Belgium is still world leader at 30.02%.
So, 11% a year from now?
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.
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.
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.
Yesterday, I wrote:
❝In almost a week, I received zero IPv4 "too big" messages.
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.
"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.
BGP SecurityBGP 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:
The IETF RPSEC (routing protocol security) working group is active in this area.
IPv6BGPexpert is available over IPv6 as well as IPv4. www.bgpexpert.com 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 www.ipv6.bgpexpert.com to see if you can connect over IPv6. This URL only has an IPv6 address.
What is BGPexpert.com?BGPexpert.com 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.
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 MultihomingIf 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.
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 bgpexpert.com over IPv4. Your address is 18.104.22.168.