Although the number of top 100 websites that have IPv6 enabled has stagnated since World IPv6 Launch, the number of users that have the new protocol enabled keeps growing nicely: during the weekends, now 3% of Google's users have IPv6 according to the search company's IPv6 adoption statistics. (It's a bit lower during the work week, probably because more people have IPv6 at home than at work.)
And for the first time I saw a country pushing past 10% IPv6 adoption. Which country? Belgium!
Good work, guys.
Permalink - posted 2014-02-25
Prepared for Surfnet
Permalink - posted 2014-03-14
It's official: for all intents and purposes, North America is out of IPv4 addresses. Two of the four other regions have been in that situation for some time, and Latin America will be joining North America, Europe and Asia in about a month. That leaves Africa, which still has almost 50 million IPv4 addresses, which are used up at a rate of 5 - 10 million a year.
Does this mean that if you're running a business that requires a regular infusion of new IP addresses, it's time to relocate to Africa?
Read the article - posted 2014-04-28
Yes, it's 2014. Using IPv6 sockets is no big deal.
Read the article - posted 2014-04-30
Today LACNIC, the registry that gives out IP addresses in Latin America and the Caribbean, effectively ran out of IPv4 addresses, like their colleagues in Asia, Europe and North America before them. Only AfriNIC in Africa is still providing the IPv4 addresses in the amounts ISPs request.
Read the article - posted 2014-06-10
My Ars Technica story about ARIN and LACNIC running out of IPv4 addresses.
Read the article - posted 2014-06-12
A few weeks ago, I wrote With the Americas running out of IPv4, it's official: The Internet is full for Ars Technica, where I explain where all the IPv4 addresses went.
In the comments, a reader posted a link to an interview with Vint Cerf where Cerf explains how we ended up with the limited 32-bit IPv4 address space. Well worth a listen. The 32-bit thing starts 26 minutes in. Basically, IPv4 is the test version of IP, and IPv6 is the production version!
I've been teaching BGP training courses for more than ten years now. Shortly after my BGP book came out, I teamed up with NL-ix, the operators of the neutral internet exchange, to teach the people connecting to NL-ix (and anyone else interested) about BGP. What makes our training course unique is that we don't just cover the theory, but also have people configure BGP on a Cisco router, where they have to set up peerings toward the other participants.
When we added an IPv6 training course, the content was based on my IPv6 book, which didn't really lend itself to the same approach because it covers a much wider range of topics: enabling IPv6 on various operating systems, routing, tunnels, DNS, applications, security. I was never really happy doing just theory with no hands-on part. So I decided to focus more on routing with the IPv6 training course, and include tunnel, OSPF, BGP and DHCPv6 assignments so the participants can get some hands-on experience with the new protocol. As always, there were a few surprises when participants were trying to do the assignments for the first time, but the new format was a success.
If you're interested in one of these training courses (or both), the next dates are October 6 for the BGP course and October 7 for the IPv6 routing course. The location is the NL-ix office in The Hague, and the language will be English unless all participants speak Dutch. (The next time after October the language will be Dutch.) See the NL-ix training course page for details and the sign up form.
Permalink - posted 2014-07-16
Last week a SIGCOMM paper was published with a bunch of IPv6 measurements in it, which concludes that IPv6 deployment is getting real. For instance, 0.6% of internet traffic was IPv6 at the beginning of 2014, which is 5 times more than in 2013 and that 5 times more than in 2012. Click the link to read my story about this on Ars Technica.
Read the article - posted 2014-08-28
I was updating a presentation the other day, and I found something I wanted to share here. (Looks like old presentations are good blog fodder. Who knew.) The old presentation was the one I did at the 2013 ISOC New Year's event, where I put up some slides on Google's numbers of IPv6 users (from their vantage point) in various countries. That was less than two years ago, and a lot has changed.
The global number of IPv6-capable users was 1% then (January 2013), now (September 2014) it's 4%. Some countries that were ahead of the curve extended their lead, others didn't, and a new world leader emerged out of nowhere. Click the link to see the old slides followed by the current situation. (1.4 MB PDF.)
So the good news is that a lot can happen quickly when it comes to IPv6 deployment.
Read the article - posted 2014-09-15
After some heated discussions about packet sizes on the mailinglist of the IETF v6ops working group, I decided to do some measurements to find out what maximum packet sizes are supported on today's internet...
Read the article - posted 2014-12-17
Please read yesterday's post Maximum packet sizes on the internet first. There, I looked at the maximum supported packet sizes that are included in the TCP MSS option in HTTP requests to my server. Today I'll look at the values in ICMP(v6) "too big" messages.
In almost a week, I received zero IPv4 "too big" messages.
So it seems in the IPv4 world, path MTU discovery is dead.
Read the article - posted 2014-12-18
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.
Permalink - posted 2014-12-19
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.
