ARIN recently announced that they handed out the last /8 IPv4 address allocations (read about it here). Comcast also announced that they are doing trials of IPv6. When will we run out of IPv4 addresses? Well, it will be a little while longer before the ISPs will no longer be able to get IPv4 addresses because there are addresses remaining in a free pool at ARIN, just not in blocks as large as /8 (see IPv4 IANA Free Pool Depletion FAQ).
What does this mean to everyone in the field? Well, that answer depends on who is answering. There are a few different scenarios.
One scenario is that ISPs will start handing out IPv6 addresses instead of IPv4 addresses. I don’t think that this is very likely because it will increase the support costs as they deal with customers who have old systems that don’t support IPv6. And this ignores the requirement that the ISP’s infrastructure be configured to support IPv6. I’m assuming that all ISP infrastructure equipment is capable of supporting IPv6. Most ISPs are likely to wait to see how the early adopters handle their deployments.
Another scenario is that everyone continues to use NAT to stretch out the usability of the existing address space. Like using the few remaining addresses, this approach will have a limited lifetime. In addition, I expect to see some ISPs start to influence their customer’s use of IP addresses by charging more for each IPv4 address above the one that’s needed to connect to a customer’s network. I’m seeing hotels using private addressing and am sure that those aggregate to just a few IP addresses that connect to the ISP servicing the hotel (please post a comment if you know more).
Facebook is implementing IPv6 to IPv4 gateways and load balancers. Their servers are running v4 and via the gateways, are able to talk with clients that are running v6. So I expect that we’ll see a number of companies with similar implementations. I would not be surprised to see ISPs using v4 to v6 gateways for their customers. Use a set of 10/8 networks for their customer-facing networks, a gateway to connect them to IPv6 networks, and then rely on the remote end to provide IPv6 connectivity. We may even see the ISPs continue to use IPv4 with IPv6 tunnels as their primary interconnection protocols.
In the end, I don’t expect things to change much. There will be devices installed in networks to make the communications work. Most of the ‘glue’ devices will be in places where they are managed by smart network engineers who understand what the devices do and how to troubleshoot them. These are also likely to be choke points where network security is implemented.
NMS systems are going to have to start handling gateway tables, where the address changes from v4 to v6 and vice-versa. Netflow tools may not have the real endpoint addresses – it may only have the addresses that exist at one point in the network. Tracking a flow end-to-end across the network will be more complex. I think that we’ll see a combination of v4 and v6 addresses in our management systems, which is going to be a challenge for the NMS user interfaces. DNS, DHCP, and IPAM systems will also be more complex. The address space utilization displays that work in a v4 infrastructure won’t directly work in a v6 world. Example: are you using /64s for your P-P links (RFC 3627), or are you using /126s or /127s, as described in draft-kohno-ipv6-prefixlen-p2p-03.txt? You may want to refer to the IPv6 Link Numbering Panel presentation for more information about selecting P-P link subnets and addresses. IPv6 Subnet Calculators are discussed in Scott Hogg’s blog: IPv6 Subnet Calculators.
I recommend that everyone start a small IPv6 project, simply to learn more about it and be better prepared for the day when you actually have to implement it.
I’ve covered other topics on IPv6 in prior blog posts:
-Terry
_____________________________________________________________________________________________
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html
