Today's ARIN estimated depletion date:


Txv6TF Winter Summit Nov 19-20 in Richardson, TX

2012-09-29

Posted by ipv4depletion  |  47 Comments »

The Texas IPv6 Task Force (TXv6TF) announces its Winter 2012 IPv6 Summit in Richardson, Texas. This event will occur November 19-20, 2012 on the campus of The University of Texas at Dallas. This event is free, but pre-registration is required. Come back to register starting October 1, 2012.

More info about the event can be found here.

RIPE in Europe runs dry…

2012-09-15

Posted by ipv4depletion  |  6 Comments »

On 14 September 2012, the RIPE NCC essentially ran out of IPv4 addresses. They began to allocate IPv4 address space from the last /8 of IPv4 address with a very restrictive policy. Next in turn is ARIN. ARIN’s supply of IPv4 addresses is expected to last about 1 year.

Read RIPE’s announcement here

DNS when turning on IPv6

2012-07-09

Posted by ipv4depletion  |  13 Comments »

I did some interesting IPv6 and DNS testing the other day with a customer. I decided to put a little blog post together on my findings. You can read the post at the Secure64 blog about DNS

 

 

Texas and the IPv6 map

2012-06-16

Posted by ipv4depletion  |  No Comments »

How ready are the counties in Texas for the new IPv6 Internet protocol? Not so much. Only two counties are using IPv6 for their Web and Mail system. The picture looks somewhat better for DNS servers but there is a long way to go.

Kudos to Angelina and Kerr county. Those two counties have given their residents the possibility to reach critical information over both the old IPv4 protocol as well as over the new IPv6. They are ready for the new Internet.

The site below tracks the progress of counties Ipv6 readiness in Texas. We still have some time before the lack of Ipv6 is getting critical, but we are getting closer to the depletion point each day.

http://maps.txv6tf.org/maps.php#tabs-2

The map is updated daily and tracks both IPv6 as well as DNSSEC readiness. Thanks to my friend in Sweden, Torbjorn Eklov that put the map together.

Thanks, Stephan

 

IPv4 / IPv6 and TCAM memory

2012-05-24

Posted by ipv4depletion  |  6 Comments »

When I met Mack McBride at the Rocky Mountain IPv6 Conference about a month ago, he brought to my attention an upcoming depletion issue with router memory that I thought I would write a few words about.

Introduction
For small companies and home user, a default route is used to route all traffic off the network into the service provider’s network for further transportation to the destination. Default routing is not an option for service providers. The they peer with multiple other providers and wants to route packets to the path with the lowest cost (fewest hops). Instead of default routing, they share the routing table via BGP. However, with more and more networks connecting to the internet, this table is growing rapidly. This post examines one of the future problems that the internet is facing due to this growth and due to deployment of IPv6.

Background
The routing table in routers is using a specialized memory called TCAM. This memory is very fast so that the next hop destination for each packet can be found quickly. The TCAM is limited to 1 million entries in the Cisco 7600 (Catalyst 6500) routers. This type of router is very commonly used by service providers. An issue in such router will affect most, if not all service providers around the world. The amount of TCAM memory has been the same for several years. Even if you buy one of those routers today, you will not get more than 1 million TCAM entries.

The TCAM is designed in such way that IPv4 takes up one entry and IPv6 takes up two (that might sounds strange since IPv6 addresses are 4 times larger than IPv4 addresses, but that is the way it is). The default configuration is to allocate 512k entries to each of the protocol resulting in 512k possible IPv4 routes and 256k possible IPv6 routes.

The IPv4 routing table
The current full BGP routing table consists of about 450,000 IPv4 routes (see http://bgp.he.net/report/prefixes#_prefixes). Note that this number is from a typical backbone network and has more routes than an enterprise might see. Other sources might give a slightly smaller value. Nevertheless, a year ago that number was only about 400,000 IPv4. So when will we fill up the TCAM memory? Well, it depends on how fast the routing table will grow moving forward.

Is a linear growth of IPv4 routes realistic? Historically we have had a slight exponential growth as can be seen in this image (http://bgp.potaroo.net/). A rough estimate is that the routing table grows exponentially and that it double in size every 5 or so years. But perhaps a linear extrapolation gives us a reasonable scenario; we will hit the 512k mark for IPv4 routes in about a year. I have a hard time to see how we wouldn’t reach the 512k in less than two years even if I use a very conservative perdition.
No new IPv4 networks are available for delegation from the APNIC RIR. RIPE as well as other RIRs are soon to face the same faith. For many large IPv4 users the alternative is to use their current inventory of IPv4 address and slice it up in smaller chunks. This might make the IPv4 table to grow even faster than what we historically have seen.
Once the limit is reach, the routers will have to start to use slower memory for routing. This will create an increase in latency for packets traversing the internet. What happens is that routes that are hardware switched become software switched. This generally causes significant router issues and can even crash the router.
An option that service providers can consider is to filter smaller routes. A service provider can basically throw away routes smaller than a certain size. For example in IPv4 you can setup filters to throw away routes smaller than /24. Most providers already do this so no new routes would become unavailable nor would it save space. What is likely to happen is providers will start filtering deaggregates where a covering prefix exists, at least for some time until this problem is resolved. This might create a suboptimal path for packets resulting in an increased latency.

The IPv6 routing table
The current IPv6 routing table is only about 10,000 IPv6 routes inside of a service providers network. With IPv6 you normally get very large chunk of IPv6 space assigned to you so fragmentation of IPv6 space is not as big of an issue as fragmentation of IPv4 space. However, IPv6 is just starting to be deployed and we can expect the IPv6 routing table to grow pretty hefty in the next couple of years. But reaching the default TCAM settings of 256k IPv6 routes will probably take quite a while.
However, the full 256k routes might not be available for IPv6. It is possible to reconfigure the TCAM memory. Service providers might be forced to do so to make sure that they still fit all the IPv4 routes. Two alternative configurations are to fit 768k IPv4 routes and 128k IPv6 routes or 640k IPv4 routes and 192k IPv6 routes. The 768/128 setting will give the IPv4 routing table enough space to grow for several years. But it will on the other hand limit the IPv6 table to 128k entries. That number number scares me because I’m not sure that will be enough to fit the full IPv6 routing table when IPv6 is fully deployed. The 640/192 setting might be a better option, but might pose a limit on IPv4 instead. I’m not sure 640k IPv4 routes it will be sufficient to cover the need for that many year considering that we exponential growth and a fragmented IPv4 space due to lack of the availability of new addresses. Any of those two settings are in any case better than the default 512/256.
A ratio of 4:1 between IPv4 and IPv6 routes is in my opinion not unrealistic. That would imply that we have 128k IPv6 routes when we hit 512k IPv4 routes mark. I base this on the fact that.

  • With IPv6 fully deployed, each AS would advertize at least one IPv6 prefix. Currently about 40,000 AS numbers are being used and each AS is advertizing around 10 IPv4 prefixes each.
  • A lot of organizations are multi homed to increase redundancy. They peer with more than one provider and this creates two routing entries in the routing tables. If they are multi homed in IPv4 then we can expect them to have the same requirement for their IPv6 connections.
  • A lot of network administrators are using the old IPv4 thinking when they deploy IPv6. They use a 1 to 1 mapping between how IPv4 is deployed and how IPv6 is deployed. This might create more than necessary IPv6 routes.
  • Cisco, at some point thought that a 2:1 ratio between IPv4 and IPv6 routes was the best guess. Otherwise they wouldn’t have created this as the default setting for the TCAM memory. Shouldn’t we believe Cisco? They should know what they are talking about, right?

If you have an opinion on the ration between IPv4 and Ipv6 prefixes that is different from mine, then please post a comment.

Summary
The growth of the IPv4 routing table combined with the deployment of IPv6 has an interesting side effect in terms of router TCAM memory. The TCAM memory must be balanced in such was that both the IPv4 and the IPv6 routes fit. Routers must be reconfigured and there is a point if the future where there will be a problem fitting both tables into the available memory. Cisco is rumored to be working on a solution, they better hurry. In the mean time, please login to your router and change the TCAM settings to allow for more IPv4 routes.

Looking back at 2011

2012-01-02

Posted by ipv4depletion  |  39 Comments »

The top stories for 2010 was that some major sites and ISPs turned on IPv6. What was the top 10 IPv6 and IPv4 depletion stories for 2011? Did I miss any significant story? Please comment.


1. IANA runs out of IPv4 addresses

In February 2011, IANA runs out of addresses. This was much earlier than most people predicted. People start to realize that they must start looking into IPv6.

2. APNIC runs out of IPv4 addresses
In April, just two months after IANA runs out of IPv4 addresses it is the first RIRs turn. APNIC serving Asia Pacific and Asia is down to their last /8 and the more restricted policy stats to take effect. They can no longer allocate IPv4 addresses the conventional way.

3. IPv4 addresses for sale
Microsoft aquires a large chunk of addresses from what is left of Nortel. They pay $11.25 per address. People are scratching their heads woundering why Microsoft just didn’t go to ARIN and request the addresses.

4.World IPv6 day
On 8 June, 2011, ISP’s and content providers joined together and turned on IPv6 for a day. The event was a success and very fee issues were found. This attest that IPv6 is ready for prime time.

5. Decrease in IPv4 allocation rate
The allocation rate of IPv4 slows down after APNIC’s depletion. More restrictive policies are in place at the RIR’s and we have not seen and really large allocations in either ARIN or RIPE.

6. Godaddy enables IPv6 DNS
Godaddy enables IPv6 for their DNS servers. 25% of the domains in the world are all of the sudden accessible over IPv6. (Note, that this relates to DNS servers, the web hosting service at Godaddy is still on “Internet classic”)

7. The realization that dual stack networks brokenness is minimal
World IPv6 day and other measurement efforts around the web concludes that the worries about IPv6 brokenness are exaggerated. It can be concluded that turning on IPv6 will not cause any significant loss in website viewers for most companies.

8. Vendor support
With the depletion of IANA and APNIC a lot of vendors jump on the IPv6 bandwagon. Most Firewall, Load balancer, DNS, etc vendors are issuing press releases about how they now support IPv6. They interesting questions will be if the support is as good as they claim.

9. Lack of IPv6 strategies from some large organizations
Just like in 2010. Some large organizations still seems to lack an Ipv6 strategy. Did they read the news at all?

10. Nokia ditches Symbian
Nokia changes strategy and ditches SymbianOS. This creates problems for the Wireless Carriers with Ipv6 plans, since symbian actually had the best IPv6 support of all phone platforms.

Amount of IPv6 traffic

2011-11-24

Posted by ipv4depletion  |  7 Comments »

There are plenty of numbers floating around about the amount of IPv6 traffic that can be seen. Whenever I go to an industry event, somebody is always presenting a number. All of them are probably accurate but they are all significantly different. What are they actually are measuring and why are they so different?
First let’s look at some numbers from different industry stakeholders:

Backbone
At the Texas IPv6 Summit in September 2011, Yves Poppe from TATA communication noted that 0.061% of his traffic was IPv6. That doesn’t seem to be a lot. To simplify things, let’s round that number to 0.1%
Slides can be found here (slide 9)

Content
At IETF81 in Quebec City in July a panel of Google, Facebook, Cisco and Yahoo! noted how much IPv6 traffic they could see on the world IPv6 day. slides can be found here.
Google could see 0.33%, facebook 0.20, Yahoo! 0.29% and Cisco could see 1.11%
This sounds better, but still not great. Let’s round this number of to 1%

Clients
Also at the TXv6TF Summit in Austin, Ron Broersma from DREN presented how much traffic he can see in his fully dual stacked network. An astonishing 10% of his traffic is over IPv6. That sounds like a lot. His slides can be found here

How come these numbers are so significantly different from each other? Well, it is because the measure different things. Remember that both a v6 capable source and an IPv6 capable destination is needed for an IPv6 session to take place. The number from the IPv6 capable content providers (1%) is measuring the amount of IPv6 capable clients. The number from DREN is actually measuring the number of IPv6 capable servers (10%). The number from the backbone provider is measuring the ratio of IPv6 traffic that is the mathematical product of the IPv6 capable clients and the IPv6 capable servers. The figure below illustrates what the different measurements actually measures.

Conclusion
The two conclusions that can be drawn from this exercise is that:
1. The number of IPv6 capable content far exceeds the number of IPv6 capable clients. This is alarming as it really points to the fact that service providers are not taking IPv6 seriously (there are a few exceptions).
2. Any additional clients that are being upgraded to support IPv6 will have larger impact on the total IPv6 that the Internet backbones can see than a similar increase for the IPv6 content. For example an additional 1% of clients would bring up the total Internet traffic to 0.2% (10% * 2%) whereas a 1% increase on the content side would only bring up the total backbone traffic to 0.11% (11% * 0.1%).

Report from the TXv6TF summit

2011-09-16

Posted by ipv4depletion  |  10 Comments »

Report from the TXv6TF summit – (C) Stephan Lagerholm September 16, 2011

The Texas IPv6 Task force summit in Austin took place between September 14 and 15. Here is a brief summary of the most interesting talks and conclusions. All presentations are already online if you want to deep dive.

IPv6 capable Wireless
First of all, I recently got a new laptop and I haven’t have time yet to test IPv6 on it. AT&T generously provided a WLAN with IPv6 support. Since I’m using Windows 7 I thought it would just work and that I would get a SLAAC address. However it turned out that I didn’t get on the IPv6 internet but everybody around me did. After some troubleshooting I realized that my host firewall that is built in with my antivirus actually IS BLOCKING IPV6 BY DEFAULT. Thanks for that F-secure, you just lost my business for my next renewal.

Breakage/Happy eyeballs
About a year ago, there were a lot of talks about how enabling IPv6 and adding AAAA records for your web servers could break a small fraction of clients. Although this breakage only would be a fraction of a percent it was still too high of a number for some large content providers.
Several speakers including myself concluded that the breakage appears to not be as severe as initially thought. Unless you are on the Alexa top 100 list, I think it is safe to say that you can enable IPv6 on your web server and publishing a quad-A record in your DNS without experiencing any problem.

IPv6 day is still going on
Yves Poppes from TATA communication as well as Ron Broersma from DREN shared some statistics about the IPv6 usage. It turns out that the IPv6 traffic has grown since the IPv6 day even if some large content providers decided to turn off IPv6 after the IPv6 day concluded. Ron concluded that they had around 15% IPv6 traffic on their network normally. Sometimes the IPv6 traffic spiked to up to 30%. Since his network is fully dual stacked, this is an indication on how much IPv6 content there are out there, probably more than you expected…

IPv4 run out?
Many presenters showed new statistics about when the different RIRs will run out. I shared some data from my IPv4depletion.com site. The consensus is that we might have a little bit more time with IPv4, especially in the ARIN region. This does however not mean that you can slack off on your IPv6 deployment.
Owen Delong from HE says: “I don’t think any IPv4 prediction that goes beyond 2012 for any RIR is accurate”. My personal opinion is that ARIN might have IPv4 addresses for some years longer than that, but again that does not mean that you can slack off on your IPv6 rollout.

Router Advertisement
There were a lot of discussion about rouge Router Advertisement and the security implication. I always thought that the problem as analog to a rogue DHCP server in IPv4. However Ron Broersma brought up a good point that the problem is mostly accidental and not malicious. If you turn on connection sharing in windows then all clients on the LAN might send you traffic. This is somewhat different from what you will have to do to accomplish the same thing on IPv4 with a DHCP server. In the IPv4 case you actually would have to download and activate a DHCP server, something that you don’t do by accident (Although I have to admit that I once pissed off a network admin by accidentally just doing that)

The next TXv6TF meeting will most likely be in Houston around March of next year. We hope to see you there.

Webcast with Brocade

2011-08-12

Posted by ipv4depletion  |  No Comments »

I’m doing a webcast together with Jeff Hartley from Brocade on August 24. If you are interested in how you can deploy NAT64 and DNS64 with Brocade ServerIron ADX and Secure64 DNS, then please attend.

Register here

IPv4 addresses for sale

2011-08-08

Posted by ipv4depletion  |  7 Comments »

The email below showed up at the NANOG (North American Network Operators’ Group) email list today. It will be interesting to see if this block will get sold and if the seller manages to get as much or more money as the Nortel block that Microsoft bought earlier this year.

Subject: Corporation for Sale with IPv4 Assets
Date: August 6, 2011 6:31:04 PM EDT
To: nanog@nanog.org

North American Corporation (domiciled in Nevada) is for sale.

All non-IPv4 assets and debts (and other liabilities) have been transferred
to another related corporation.

IPv4 Assets include:
1 – ASN; and
3 – /20 networks (12,288 IP Addresses) direct allocations (non-legacy).

Multiple options available for sale/purchase.  Motivated sellers.
Please e-mail: ipv4brokers@gmail.com or call/text: (404) 532-9535.
Available on Saturday and Sunday for discussion.