Last week was the 2013 North American IPv6 Summit conference. This was the 6th year of the IPv6 conference held in Denver, CO. One of the items that all attendees received at the registration booth was an IPv6 Buddy keypad. This got people thinking about what other changes we might expect to experience as we move into a dual-protocol Internet world.
Picture of my new little IPv6 Buddy.
This is a small USB keypad that is specially made for entering IPv6 addresses. It contains "0" through "9", "A" through "F" and special characters like ":", "::", and "/". It is intended to speed up the entering of IPv6 addresses rather than use a standard keyboard and number pad.
Organizations around the world are starting their Internet edge deployments of IPv6. This is the most logical place to dip your toe into the IPv6 Internet waters. By deploying IPv6 at your Internet perimeter organizations gain valuable knowledge of the protocol and experience using the protocol. Through setting up an IPv6-enabled Internet edge you learn about IPv6 routing protocols, dual-protocol DNS server configurations, firewall configuration, dual-protocol server operating server configuration. All of these skills are valuable as an organization starts to bring IPv6 connectivity further inside. Deploying an Internet-edge with IPv6 is like setting up a green-field network deployment. Everywhere you have an IPv4 address you will also have an IPv6 address and run both protocols in parallel.
When it comes to securing our Internet edge network infrastructures there are many things to consider before we deploy IPv6. We should consider how IPv6 will affect our firewall policies. We should determine how our E-mail server will respond to spam being delivered over IPv6 transport. We should investigate if our Web Application Firewall (WAF) support IPv6 and if this changes our PCI compliance strategy. We will also want to have defensive capabilities for IPv6 attacks and have monitoring visibility using a SIMS/SIEMS system. We will need to secure our IPv4 and IPv6 systems equally well because the attackers will try to exploit the systems that are have weaker defenses over one or the other protocol.
We operate a single-protocol environment today and it isn't always the easiest thing to maintain. Imagine if we had to maintain two side-by-side networks. That would require more effort than maintaining a single network environment. Back in the mid 1990s organizations had multiprotocol networks that used AppleTalk, IPX and IP and it wasn't too much of a burden. However, operating an IPv4 and IPv6 network in parallel will increase administrative overhead and increase operating expenses.
In a dual protocol world you have lots of tasks that will need to be performed twice; once for each protocol. Every time you need to provision a new server you need an IPv4 address and an IPv6 address from your IPAM system. Every server will need to be added to DNS with an A record and an AAAA record (and complementary PTR records). These systems will need to be secured with firewall policies for both protocols using host objects or groups. End-to-end connectivity testing will need to be performed over both transport protocols. The good news is that there will be plenty to do so job security will not be your foremost concern.
We will also need to be able to perform the, hopefully, occasional troubleshooting of the dual-protocol systems. We will need to have operational methods at-the-ready that permit us to adroitly troubleshoot a dual-protocol environment. The more rehearsed these practices the faster we will be able to troubleshoot and reduce the Mean-Time-To-Repair (MTTR) and increase the operational availability of the systems. This video presents some thoughts on the subject and there is a mini version of the video that goes with it.
The Internet of Everything:
One of the things that keeps getting mentioned over and over is how IPv6 will be able to easily support connectivity of millions of devices because of its immense address space. IPv6 pundits speak about how there will be an explosion of "sensor networks" that will take advantage of Stateless Address Auto-Configuration (SLAAC) and wireless connectivity.
Cisco has recently announced their plans for having solutions for the "Internet of Everything (IoE)". Cisco has a web page that is dedicated to their strategy and the solutions that support this initiative. Watching this video makes us realize just how much potential there is for networking technology to positively impact our lives.
The "Internet of Things (IoT)" has also become a popular topic in the last week. Geoff Mulligan with the IPSO Alliance and Proto6 gave a presentation titled "IPv6 for IoT and M2M applications" at the IPv6 Summit. In the last few days there have been several articles in Network World on the topic. "The Internet of Things: Coming to a network near you", "What is the Internet of Things?", and "Indirectly connected to The Internet of Things". However, it might be cooler to add a Mr. Fusion Flux Capacitor to your 1981 DeLorean than a SquareTag.
As the global population has now passed 7 billion and the number of mobile phones has passed 6 billion, we will certainly need more the IPv4's 32-bits or 4.2 billion addresses. The "Things" on the Internet are most likely to be people roaming the planet with their smartphones. Over time the Internet will get more and more crowded with an ever-growing globally connected community and the only way to continue to connect more devices is with IPv6. However, those users still have the expectation of connecting to the IPv4 Internet and therefore, they need dual-protocol connectivity.
The transition to IPv6 has already started in the core of the Internet and is moving rapidly to the access edge. Many organizations across the globe have already started to deploy IPv6 at their Internet edge as many more organizations are just starting to contemplate what this all means to them. Every device that connects to the Internet will eventually need to support IPv6 because the adoption of IPv6 is inevitable. However, IPv4 is going to be with us for decades to come. As we brace ourselves for this transitional period we should try to anticipate what we can expect when we are running both protocols. If we consider this prior to being in the dual-protocol situation then maybe we can come up with ways to make the transition easier to bear.