Category: Other

This one’s for you, Chris.

I’ve read countless articles, comments, posts about IPv6 and ‘that there are x IPv6 addresses for every human/square meter/grain of sand… on earth’. Okay, but let’s go hypothetical now, make some assumptions, and try to predict when the IPv6 address pool will be depleted. It’s just for fun, don’t expect any educational value in this article.

I’m going to use powers of ten to keep it somewhat imaginable. The total number of possible combinations with 128 bits is 3.40*10^38.  However, some ranges are unusable for internet routable traffic, and reserved by IETF:

  • FE80::/10 – Link local addresses.
  • FC00::/7 – Unique local packets, somewhat resembling RFC 1918 addresses for IPv4.
  • FF00::/8 – Multicast addresses.
  • 2002::/16 – 6to4 addresses, which are more of a transition mechanism and not really host addresses.

Currently, only the 2000::/3 range is global unicast, but other ranges can be assigned so in the future. The currently assigned range alone gives 4.25*10^37 addresses. For simplicity, I’m going to assume that eventually the entire address range will be used, except 2002::/16 and the entire F000::/4 block. That should cover all current and future reserved assignments. That’s still 3.19*10^38 addresses.

It should be clear by now we will run out of useable MAC addresses much sooner than IPv6 addresses, but let’s leave that out of the equation here. Let’s continue with our 39-digit number. But, even if we assume that in the near future every mobile device has an IP address, and we assume that the number of mobile devices doubles (e.g. one smartphone, one tablet), then we have about 10 billion devices, according to Wikipedia. That’s 10^10, which is nothing next to 10^38. Even multiplying that number by 1000, to cover all servers, point-to-point links, multiple home computers, household devices with an IP (refrigerators, ovens, photo frames, you name it), the total number of cars,… It will ‘only’ count up to 10^13, which doesn’t even scratch the surface of the entire available address pool.

The answer doesn’t lie in counting the number of devices that could possibly have an IP address. But, so far, I have been assuming perfectly filled subnets, no wasted addresses. That’s certainly not going to happen in IPv6: the EUI-64 mechanism for stateless autoconfiguration of IPv6 addresses requires a subnet to have 64 bits. This means most, if not all subnets (except point-to-point links), will have a size of /64 in the future. Highly inefficient for the conservation of addresses. Using the values I assumed earlier, that gives me 1.73*10^19 subnets. So from a 39-digit number, we now have a more realistic 20-digit number.
Let’s try to deplete that by, for example, giving one /56 per house (recommended, but that’s not likely to happen, as described in detail already by network instructor Chris Welsh), and one /48 per company. I haven’t found any definitive numbers, but I think it’s a conservative assumption that there are about 3 people on average sharing one home in the world, with fewer in the Western world (about 2.5 on average) and more in other parts of the world. As far as companies go, I’ve only found one quote saying there were 56 million companies worldwide in 2004, without anything to back it up, but it’s the best I have.

Assuming 60 million companies in 2012 with a /48, and 7.2 billion people, with an average of three per household, for a total of 2.4 billion households with a /56, I can calculate:

  • A /56 is 8 bits, 256 subnets times 2.4 billion makes 614.4 billion.
  • A /48 is 16 bits, 65536 subnets times 60 million makes 3.93*10^12
  • Together, that’s 4.55*10^12 subnets used.

That still doesn’t touch the 10^19 value. However, we now have a number that represents the used number of subnets versus the whole population (and assuming the whole world has access to IPv6 technology and needs it, but hey, we’re making assumptions for the future, and I’m hoping the best for humanity). Dividing our number of used subnets by the population, we get roughly 632 of /64 subnets used per human on this planet.
1.73*10^19 total subnets, divided by 632 subnets per human, gives 27,37*10^15 humans on the planet before the subnets are depleted. That’s 27 million billion. At this point, I was going to take a chart about human population growth, but none of them make predictions past 20 billion.

Conclusion: unless we reach for the stars and spread our IPv6 address space over the entire galaxy (even our solar system wouldn’t do), or finally perfect nanotechnology and decide to give each nanobot his own IPv6 address, we will not run out of IPv6 addresses. Even with large error margins, there are simply too many addresses and too few things to give it to. ISPs, hand out those /56 already!


I’ve described in an earlier post how routing works in a hub-and-spoke Frame Relay network. The idea is that you have to get layer 3 services (routing) to work in an environment where no direct layer 2 contact is possible. You do this by using the hub router as a relay for all data.

In this post, I’m going to attempt to do the same in an Ethernet network. Normally, an Ethernet is a broadcast network, but Private VLANs form an exception to this rule: any data, even broadcasts, sent from an isolated port will not be received on other isolated ports. This is very similar to the hub-and-spoke Frame Relay, where spokes can’t communicate directly with each other.

I’m using the following setup:

After configuring the PVLANs on the switch (for details about this, see an earlier blog post), I configure all routers with EIGRP. Just a simple setup:

Router(config)#hostname Rx
Rx(config)#router eigrp 1
Rx(config)#interface Loopback 0
Rx(config-int)#ip address 10.0.1.x
Rx(config)#interface Ethernet0/0
Rx(config-if)#ip address 10.0.0.x
Rx(config-if)#no shutdown

The ‘x’ represents the router number (R1, R2, R3). The loopback is configured to show that the routing protocol is working. After configuring all this, EIGRP adjacencies are formed between R1 and R2, and R1 and R3, but not between R2 and R3, as they can’t see each other because of the isolated PVLAN. A ‘show ip route’ on R2 and R3 shows the connected subnet, and one EIGRP learned route: the loopback from R1. Clearly, R2 and R3 don’t exist for each other.

But just like with the hub-and-spoke Frame Relay, this can be solved by disabling split-horizon on R1: in interface configuration mode, this is the ‘no ip split-horizon eigrp’ command. Neighbor associations are lost after this command and formed again quickly. R2 and R3 still aren’t neighbors, but their routing tables now also have routes for each other’s loopback adapters, learned by EIGRP. But they can’t reach this loopback: pings don’t work. The reason for this is of course in the PVLAN configuration, which prevents direct communication. And this is where it gets interesting: in the hub-and-spoke Frame Relay configuration, this was solved by adding static mappings to the PVCs so all frames are sent to the hub router, who then relays it to the correct spoke router. Can this be done here too?

It can: configure router R2 and R3 with static ARP information. But not with the ‘correct’ information: if you, for example, do a static arp entry on the R2 router for with the MAC address of router R3, it still won’t work, as no direct communication is possible. Just like with Frame Relay, where you use the PVC of the hub router instead of the PVC of the spoke router, you make a static arp entry on R2 for with the MAC address of R1! So, first do a ‘show interface Ethernet0/0’ on R1 to reveal the MAC address, in my case 0030.85e0.1d40. Next, on the other routers, make static arp entries:

R2(config)#arp 0030.85e0.1d40 arpa

R3(config)#arp 0030.85e0.1d40 arpa

Now all pings work! R1 relays the frames to the correct router, and adds the correct destination MAC address to the frames. I initially said ‘thought experiment’ here because it has little real-world use, but it does allow for interesting configurations, like ACL filtering on the central router (R1) in the same subnet.

Server reconfiguration.

With CCNP SWITCH passed now I can focus on networking in general again now, instead of pure layer 2 stuff. I decided this would be a good moment to reconfigure my server.

When I was gathering materials for my home lab, I had to chance to pick up an IBM xSeries 335 server very cheap. Since it comes with two gigabit NICs and I had never worked with a rack server before, I decided to go for it. I originally installed ESX 3.5, allowing me to research virtual switching and basics of iSCSI, as well as run Windows Server and Red Hat on top of it.

Since I’m familiar with these topics now and not need them directly for my further studies, I decided to install a Linux on it now, and run Dynagen to emulate Cisco routers. Hard decision for me, as I have to admit that I’ve tried a lot with Linux in the past but never could find myself comfortable with it. I downloaded Ubuntu since this would be a relatively user-friendly choice.

Strangely enough for me, things worked out quite well so far: I installed Ubuntu, configured some network settings, installed OpenSSH server and Dynagen, and after about an hour I could log in remotely using SSH and get into Dynagen. I couldn’t do anything in it yet as I need IOS images on the Ubuntu, which I will transfer in the next days, and I’m going to have to read through the Dynagen tutorial, as well as figuring out how to easily create and edit the .net files it uses.

But all in all again a small step towards more labbing options.

New switch for home lab.

I picked up my new switch yesterday, for my home lab. It’s a WS-C2970G-24T-E, and will be replacing the old Catalyst 2900 XL in my lab. I was able to bargain the price well below average eBay listings. On top of that, it’s a full gigabit switch, so I’ll be using it for my home network and/or LAN parties as well. I’m also happy to see it supports a lot more commands compared to the 2900XL, which did not support MST, QoS, and had only limited Etherchannel capabilities, for example.

I’m now completely set to test out everything I need for the CCNP SWITCH exam. I already passed ROUTE, which should boost my confidence, but apart from that it also reminded me that this is not a walk in the park, so I need to be prepared. I hope to take the SWITCH exam in about six weeks. After that, I only have to face the TSHOOT exam and I’m CCNP certified.

For now my lab meets the requirements, but if I ever really go for CCIE, I’ll need to upgrade the routers, as they don’t have enough memory to support everything I need. They’re 2611’s, but no XM’s. I’m still figuring out if I’ll replace them, just buy an extra router with more memory, or if it’s possible to upgrade their flash and RAM. Either way, it’s not needed soon.

Everytime I see private range addresses somewhere, I automatically think about Network Address Translation. But NAT and private addresses do not always need to be used together.

Take the following network:

Example network

Now suppose you have received a /22 public address range for your company, e.g., which you then split up in subnets for your users and servers. Since IPv4 addresses are limited and you have three point-to-point links in the ‘Internal’ part of the network, you’re hesistant to go waste 12 addresses (three times a /30) on them. Sure you could use /31’s and use only 6 IP’s, but if the number of links increases, so do the wasted IP’s.

But if you give these links IP’s in the ranges, and and advertise them internally with whatever IGP you’re using, things will work too. You will need to filter any packets originating from these private ranges at the WAN edge router so they don’t reach the internet. Any hosts on the internet can’t reach the IP’s on the point-to-point links as they aren’t advertised to outside the company (added security!). Internally in your network, the private ranges become part of the network, without NAT. They can be pinged perfectly. You could even set up a subnet using private ranges for servers that must only be accessed internally (very secure, though automatic updates would not be so easy, I can imagine). For remote connectivity, VPN should allow access.

All in all, a real world implementation by this design may have some flaws, but it proves a point, and adds security in some sense.