If you have followed this blog for very long you know that I post pretty regularly (far too regularly, some might say) on the fast-approaching depletion of the remaining pool of public IPv4 addresses.
If you haven’t followed this blog before, I’ll give you the short version:
The IANA pool will run out somewhere around the end of 2010 or early 2011. The Regional Internet Registries (RIRs) will run out a little less than a year after that (based on their model of maintaining a 12-month supply of addresses).
That means that if you are a large service provider (a Local Internet Registry, or LIR) and go to your RIR for a new allocation of addresses pretty much any time after 2011, the only allocation you will be able to get is IPv6.
So I’ve been harping, nagging, wheedling, threatening, and otherwise subtly suggesting that if your business is dependent on a regular supply of IP addresses, you had better be planning for the addition of IPv6 support to your network right now. I also know that a few of service providers think they still have plenty of time. Good luck with that.
If you are a smaller service provider below the LIR level – that is, an SP that gets your address allocations from an LIR rather than from an RIR – you have a little more time. The dependency here is how long your LIR’s last allocation of IPv4 addresses will last beyond will last beyond its RIR depletion. That’s probably less than a year, so let’s say 2012.
But what about enterprise (corporate) networks? Unless you are a large enterprise network, you probably have been running private IPv4 addresses behind a NAT for many years and can comfortably continue to do so for many years to come. So do you need to be concerned about IPv6?
Yes, although on a smaller scale.
As the IPv6 user community grows, you are going to see an increase in the number of people attempting to access your public-facing services such as web and e-mail via IPv6. Are you ready for that?
It might not be as easy as you think:
· Obviously your service provider needs to be IPv6 capable first, so you need to be working with them to understand their plans and timelines.
· The server operating systems need to be evaluated, to understand whether IPv6 merely needs to be enabled or if an upgrade is required.
· Are there application issues to be resolved?
· DNS issues need to be carefully considered, to insure you have neither misdirected user packets or unwanted application delays.
· If you use hosted services, what are your hosting provider’s plans? In a subsequent post I’ll share my own adventures in this area.
The first step toward planning for IPv6 access to your public servers is answering the above questions. If you don’t already know the answers, I suggest you consider them very soon. If you do know the answers t these questions, have you begun planning for deployment?
Jeff Doyle is president of Jeff Doyle and Associates, an IP network consultancy. Jeff is the author of Routing TCP/IP, Volumes I (read an excerpt) and II and of OSPF and IS-IS: Choosing an IGP for Large-Scale Networks. He is a frequent speaker on IPv6, MPLS, and large-scale routing.
The Leader in Network Knowledge
IPv6 Ready Network
Good points Jeff . I would add that Enterprise and SP customers also need to ensure that their networks are IPv6 ready. Being “IPv6 Ready" means being able to enable IPv6 within their existing network infrastructure , and eventually transition to IPv6. I am involved with key early Enterprise and SP IPv6 adopters to define a network architecture that can enables existing network infrastructure to be "IPv6 Ready ."
Having IPv6 hardware based forwarding is mandatory followed by:
• IPv6 Application Delivery: Key features required are -
o IPv6 routing protocols (EIGRPv6, OSPFv3)
o First Hop Redundancy Protocols (FHRP) like HSRPv6/GLBPv6
o Quality of Service (QoS) & Multicast feature parity for IPv6 and IPv4
• Transition Technologies: Provide investment protection to customers as they slowly migrate from an IPv4 network to a dual stack/tunneling topology and then to a completely native IPv6 network -
o Dynamic tunnels, 6to4 tunnels, ISATAP tunnels are key solutions which will be required
• Securing IPv6 traffic:
o Need for IPv6 traffic encryption across public networks using methods like IPsec
o Network access control through access control lists (ACL)
o IPv6 Netflow for threat determination, traffic visibility and capacity planning
o IPv6 first hop security features to prevent man-in-the-middle attacks and control rogue users/devices
The Cisco IPv6 solutions based on the Catalyst switches enable ease of migration along with a rich set of IPv6 features. The Catalyst switches are scalable platforms which allow investment protection by:
• Extending the existing hardware infrastructure to support IPv6
• Scalable platforms supporting both IPv4/IPv6 simultaneously
• Richest set of existing features and a strong roadmap for future software and hardware innovations
There are some unique tested architectures posted at the link below which outline the "End to End Cisco IPv6 Campus Solution":
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/CampIPv6.html
- Muninder Singh Sambi
Product Manager (CSSTG) - Cisco Systems Inc.
Wow. Muninder from Cisco
Wow. Muninder from Cisco PLM mentioned EIGRPv6 in his commercial, umm, i mean "post". Hopefully the sheep will ignore that part of the advertisement for Catalyst switches and pick an open standards based IGP for IPv6. Gee, I wonder how those IPv6 features play out when comparing them on IOS, ION, IOS-XE, IOS-XR, and the Nexus-OS platforms.
But seriously, thanks for mentioning EIGRP. I haven't laughed that hard in a really long time.
IP v6 Enterprise...
I can't help but think that IPv6 won't be needed on the internal enterprise network anytime soon. IPv4 private IP addressing will serve most small to mid sized enterprises for decades to come. Unless there is something in the IPv6 technology that is required by future infrastructure technologies and/or solutions to problems not yet apparent.
My main reasoning is due to my perception that IPv6 is not human friendly and why implement something that is more complex simply because it's there? With networks (perhaps especially with networks) I feel it pays to keep it as simple/logical/structured as possible.
Perhaps that is the whole point about IPv6. It "is not" meant to be thought of or approached in the same way as IPv4. That it is meant to be more auto-magical and more hands-off. Somehow, though, I don't think so.
What do you think, Jeff?
About the comment regarding EIGRP. We use EIGRP for our internal network (routed from Core to Distribution) and OSPF for our WAN network. Works very well.
Post new comment