IPv6 Address Planning (2015)
Chapter 3. Planning Your IPv6 Deployment
Creating an IPv6 address plan is one of the most critical requirements for effectively adopting IPv6. But, of course, it’s not the only one. So what else goes into a successful IPv6 deployment effort? Most organizations that succeed in adopting IPv6 take advantage of a relatively small number of reliable strategies and practices. In the following chapter, we’ll explore these approaches and help you to align them with your own efforts. We’ll discuss:
§ The IPv6 business case you already have
§ IPv6 as a cross-functional initiative
§ A phased approach to IPv6 adoption
The IPv6 Business Case You Already Have
If you ask them, IT managers and executives will likely insist that they have been looking high and low — from the very beginning of time, even — for the elusive phantom known as The Business Case for IPv6 Adoption. This Business Case demonstrates the overwhelming and undeniable benefits of adopting IPv6: better network performance and security, lowered cost for IT operations, fresher breath, and World Peace™. But they haven’t found it, so you should quit asking for a budget or additional personnel to deploy IPv6 (and please shut the door on your way out).
There are various reasons for the lack of an incontrovertible business case for IPv6 adoption. For one thing, although IT environments may utilize many common standards, hardware, software, and operational practices, it would still be difficult to prove a consistent and compelling bottom-line benefit for every company as business missions and organizational approaches are varied and not “one size fits all.”
Part of the challenge is that, up till now, the overall rate of IPv6 adoption has been slow, especially among enterprises, and especially for their internal networks (i.e., corporate LANs and data centers). With fewer IPv6 deployments, the data that might reveal cost-savings or performance or operational benefits are harder to come by. And even once a large deployment base exists, it will still take time to assess the ways in which IPv6 is benefitting the business.
But that doesn’t mean that there are no business cases at all for enterprise IPv6 adoption. It’s just that for most organizations, the most compelling business case is based on managing the risks and costs that increase over time in the absence of an IPv6 adoption initiative.
We’ve already mentioned the exhaustion of IPv4 in North America, Asia, Europe, and Latin America. Examining Asia in particular, most companies see tremendous potential in reaching markets in China and India. Internet penetration in both countries is low when compared with those in Europe and North America, but it is increasing rapidly. The ongoing explosion in the number of new mobile devices connecting to the Internet in these countries proves that mobile networks are the most efficient way to get them online.
Recent data and predictions confirm that this is a global trend: according to Cisco, 2014 will be the year that the number of mobile-connected devices exceeds the human population of the earth (with 10 billion mobile devices by 2017).
But as we’ve mentioned, in every global region (except Africa), IPv4 is exhausted. Meanwhile, hundreds of millions of potential users that remain unconnected are being aggressively marketed to by regional mobile providers. These providers have largely recognized the unprecedented operational nightmare they will face in attempting to use IPv4 private addressing and carrier-grade NAT (CGN) to scale their service to support these new users. Only IPv6 provides sufficient addressing that is also operationally scalable and manageable for the indefinite future.
This means that most new mobile users have devices configured with IPv6 addresses. These developments are changing the definition of what it means for a business to be connected to the Internet. The management of any organization is unlikely to quibble with the argument that Internet presence is a must-have in the new economy. Yet, out of necessity, millions of new subscribers are connecting to the Internet using only IPv6. What happens when they attempt to access an organization’s IPv4-only website?
In the worst case, it’s possible that they won’t be able to access that organization’s website at all. Since IPv4 and IPv6 are not directly interoperable, the session packets will have to be translated at least twice (both to and from the web server). If a company hasn’t done any planning for IPv6 and has no IPv6 web presence, this mandatory translation of the user sessions from IPv6 to IPv4 will be entirely outside of its control. Even if users pass through one or more IPv6-to-IPv4 translation points to successfully connect to the website, how much might user experience be degraded given that each translation introduces the possibility of increased session latency?
Research shows that users seem preternaturally sensitive to delays in webpage loading times. A study by Google proved that a 250-millisecond delay — the time it takes to blink your eye — was enough to drive users to competitors’ websites.
IPv6 Adoption as a Cross-Functional Initative
So let’s say you’ve gotten executive buy-in for IPv6 adoption and are proceeding with management’s approval. Or perhaps you’ve decided that you’re not going to wait around for the corner-office types to pull their heads out of their ascots: you’ve launched a rear-guard action to deploy IPv6! Either way, IPv6 adoption in larger organizations can be painfully slow. But cross-functional initiatives are quite often susceptible to this kind of inertia, and the biggest reasons for this are easier to mitigate once identified.
Let’s examine what an example of this challenge might look like in the Real World™.
Often, the IT network team gets the ball rolling with IPv6. Imagine then, that the network team at BellaLabs Corporation has successfully gotten through some initial testing of IPv6 deployed on lab gear. Now they’d like to try turning up IPv6 on a server in the DMZ to test some 6to4 tunnel connectivity using Hurricane Electric’s tunnelbroker service. (They’ve already got a DMZ segment enabled and configured with public addressing to facilitate this type of testing.) So someone from the network team opens a ticket that gets forwarded to the security team: please open IP protocol 41 to IP address 192.0.2.35 to allow us to test IPv6 6to4 tunneling.
And they wait.
Eventually, Ned from the network team follows up with the help desk and finally gets a call back:
“Hi Ned. It’s Susan from security.”
“Hi Susan. Thanks for getting back to me. Did you see my request?”
“I did Ned, and I was just trying to configure the firewall for your request, but I don’t see anywhere to add or modify IPv6 entries.”
“Well, it’s really just an IPv4 rule that needs to be modified. We just need to get IP protocol 41 opened to the public IP of a server in the DMZ.”
“Oh. OK. Let me look into it and call you back. What port and IP did you say?”
“IP protocol 41 and IP 192.0.2.35.”
“Got it. I’ll call you back in a bit.”
A little later, Ned’s desk phone rings again.
“Ned, this is Artesh from security.”
“Hi Artesh. Is my request completed?”
“Sorry, no. I’m just trying to figure out if our security policy supports this. There’s nothing in the existing policy docs about IPv6.”
“Hmm. Well, it’s IPv6 over IPv4, so at this point it’s really only IPv4 on the firewall that we’d be modifying.”
“But it’s IPv6 on the server, right?”
“OK. Well, let me check with my manager.”
A day or two elapses, and Ned calls Artesh back.
“Hi Artesh, it’s Ned. Did you get a response on our configuration request?”
“Yeah, Ned. I was just about to call you. The head of security said we can’t support IPv6 at this time. I explained that it’s really IPv4 on the firewall, but he said since IPv6 will be running on the DMZ server he can’t approve it.”
“He realizes that servers in the DMZ are using clustering that relies on IPv6 already, right?”
“Really? I didn’t know that. I’ll let him know, but for now we can’t accommodate the request. Sorry.”
Two obvious issues are at play here. The first is that security hasn’t had any IPv6 training and doesn’t have the requisite knowledge to handle what would otherwise be a simple request from the network team. The second is that the company’s security policy hasn’t been updated to include IPv6. (A related third issue is that lack of management buy-in may have made the first two issues much more likely.)
As a result, the IPv6 adoption effort is delayed. As with any cross-functional initiative, it’s critical that any business unit or silo in the organization that might impact (or be impacted by) the effort receive at least minimal notification and training.
A Phased Approach to IPv6 Adoption
Many organizations have successfully deployed IPv6 by using a phased approach. Large IT projects are often broken into phases to better manage the associated risks and costs. Since IP addressing touches every part of the network, any changes to it can impact an organization’s critical services, applications, and procedures. Unplanned network downtime is the bane of IT, and too much of it can lead to loss of productivity, lost revenue, negative brand impact, and employees throwing up their hands and heading for their cars at 2:30P.M. on a Tuesday. While a project manager with OCD could easily break up an enterprise’s IPv6 adoption project into a bazillion phases, most organizations find that three phases will generally suffice.
2. External adoption
3. Internal adoption
Phase 1: Preparation
For most enterprises, the first phase entails the least associated risk and cost while the last phase represents the most. (If your enterprise is different, feel free to shuffle the phases according to the principle at work, i.e., the phase with the lowest risk and cost should come first or next). The preparation phase usually consists of several individual steps, many of which can be accomplished in parallel. They include but are not limited to:
§ Management buy-in
§ IPv6 training
§ Creating an IPv6 task force and selecting IPv6 stakeholders
§ Verifying that your ISP supports IPv6
§ Auditing your assets for IPv6 support
§ Working with your vendors
§ Obtaining an IPv6 address allocation
And finally the most exciting task of all:
§ Creating an IPv6 address plan
Let’s examine each of these first phase tasks individually. (Creating an IPv6 Address Plan is covered explicitly in later chapters.)
Management buy-in is, at the most basic level and for the purposes of our discussion, simply approval from management to move forward with some degree of IPv6 adoption. Ideally, such approval will lead to capital and operational budget allocations, specifically for an IPv6 deployment effort. Training, additional personnel or person-hours, hardware and software are all helpful in accelerating the completion of tasks in each phase of the initiative.
IT managers have been notoriously ambivalent about IPv6 for many years. And who can blame them? On the one hand, industry media frenzies about the imminent demise of all things IPv4 and the need to deploy IPv6 immediately have occurred frequently enough in the past few years to create a sense of panic fatigue (especially as IPv4 continues to work just fine). Yet in the face of such fear-mongering, business cases touting any authentic cost savings from adopting IPv6 have been virtually nonexistent. Small wonder then that most IT managers are continuing their “wait-and-see” approach to IPv6.
Of course, this can complicate management buy-in for IPv6 deployment. While it’s often possible (or expected) to move forward with early-stage IPv6 adoption tasks, such steps are often taken with no formal project definition, additional personnel or funding, or explicit IT manager approval. In cases where it’s simply expected that IT staff will absorb the additional effort around IPv6 into existing operational cycles and budget, efforts should still be made to define IPv6 adoption as a unique project, one that requires dedicated planning and resources.
Keep in mind that, depending on the size of the organization, a minimal level of management buy-in and participation may be necessary to allow IT and any other IPv6 adoption project stakeholders to work effectively across different business units, or silos, within the enterprise. Often, such buy-in may simply be an unfunded mandate to “go figure out what we need to do about IPv6.” But even without any additional budget, management buy-in can help an IPv6 adoption initiative progress.
Remember also that the risks and costs of failing to adopt IPv6 don’t vanish just because management chooses to ignore them. It’s still possible to drive effective IPv6 deployment without management buy-in. Indeed, you or your team may be held accountable for failing to do so once management becomes aware that a lack of IPv6 adoption has compromised the company’s business agility, business continuity, or competitive advantage.
We’ve already examined how an enterprise neglecting to make its website available over IPv6 may compromise its advantage over competitors who have already done so. (Remember that potentially costly 250ms delay in page load times?) Business continuity is potentially threatened by failure to effectively manage and secure the IPv6 that is already enabled on your network today. And the ongoing evolution of business agility is heavily dependent on the integration of cloud solutions, the architectures of which are ever-more reliant on IPv6 (due to its unlimited address supply, capacity for better address management and organization, more efficient layer 3 to layer 2 and multiple interface addresses management, and the multiple operational efficiencies that result).
Any unfamiliar technology has the potential to introduce fear, uncertainty, and doubt (FUD) into IT organizations. Because network addressing changes can impact everything, this FUD can be especially keen where IPv6 is concerned. Formal training is a great way to instill confidence in IPv6. Please visit www.ipv6.works for a current list of trainers.
I probably don’t have to convince you that independent study can go a long way toward dispelling IPv6 FUD. (You’re reading this book, aren’t you?) Sources of information include other books, RFCs, blogs, and white papers. Reading recommendations appear at the end of some chapters. And if it’s in your budget, consider attending one of the many IPv6 conferences that are held around the world each year. Rubbing elbows with the folks who have adopted IPv6 early (and who have the operational scars to prove it) will boost your IPv6 knowledge and wisdom and instill confidence in your own IPv6 deployment effort.
Creating an IPv6 Task Force
Larger enterprises may have multiple IT or networking groups that will need to coordinate IPv6 deployment, especially if the cost and risk to existing operations are to be kept to a minimum. It’s also possible that other business units outside of IT could be impacted by IPv6 adoption based on custom network, application, or service requirements that are not well understood outside that silo (or even within) or effectively managed by IT.
As we discussed, some basic training on IPv6 across the organization should help identify stakeholders and generate interest in IPv6 deployment project participation, but such training is unlikely to be budgeted in most organizations. It’s much more likely that ad-hoc identification of IPv6 adoption stakeholders and allies in relevant business units will be necessary.
Ideally, an IPv6 task force would be created. It would include at least one member from every business unit or silo in the organization. Even just one meeting can be effective at establishing both basic awareness of the IPv6 adoption initiative and its backing by the executive team. This, in turn, can create accountability and an expectation of success that may help overcome what would otherwise be organizational inertia and lack of participation.
Auditing Hardware and Software for IPv6 Support
We mentioned that even though IT infrastructure among organizations is generally more similar than not, the ways in which organizations rely on the network, the resources they have at their disposal, their strategic visions, and their management philosophies can all vary widely. While this may make a one-size-fits-all project plan for IPv6 adoption less likely, there are tasks common to every deployment.
One of the first and potentially most daunting of these tasks is a complete inventory and audit of all IT assets to determine the degree to which (if any) they support IPv6. Any hardware or software that currently relies on the IPv4 network must be accounted for and then assessed (seeTable 3-1 for a list).
Table 3-1. What to audit for IPv6 support
Critical desktop and laptop apps
Transparent caching appliances
IPv6 on network management interfaces
Other authentication systems
Route server software/appliances
Geolocation database subscriptions
Kernel modules (e.g., TCP acceleration)
Web and email content filters
Stateful and stateless firewalls
Miscellaneous networking gear ACLs
Proxies, network and application level
Web server software/plug-ins
Mail transfer agents
Source control/revision control systems
Accounting, payroll, financial systems
Embedded or specialty systems
PBX and SIP/VOIP
Specialized systems with firmware-based OS/software
Card key systems
Printers and multifunction devices
It’s certainly a long list, and your organization may have additional elements not mentioned above.
A common lament heard when describing this task to IT personnel: gee, wouldn’t it be swell if there was software that could automatically discover all your IT assets, determine their level of IPv6 support, and generate a nifty report/support matrix?
Why, yes, that would be swell. But that would really only be half — pardon, one-third of the battle. Those who are far along in their IPv6 adoption efforts may attest to the fact that there are (at least) three steps to fully validating whether or not a particular IT asset effectively supports IPv6. They are:
1. Determining vendor support
2. Verifying vendor support claims
3. Testing support under load
Of course, before you can tackle the first step, you’ll need to have successfully completed the discovery of your IT assets. Once accounted for, this hardware and software will generally fall into one of three categories:
1. Determining vendor support
a. IPv6: All systems go!
b. Has known or possible upgrade path to IPv6 support
c. Permanently unsupported (i.e., exiled forever from the New Eden of 128-bit addressing)
We’ll talk about what to do with assets in the third category a bit later. Meanwhile, determining which of the first two categories a particular asset falls into will most likely require, at the least, checking with product documentation, but more ideally, verifying directly with the vendor and testing in a lab setting.
INDEPENDENT IPV6 EQUIPMENT VALIDATION
Many organizations, especially small- to medium-sized ones, may be limited to testing their equipment for basic IPv6 operational viability. While such testing can be vital to ensure the organization’s smooth rollout of IPv6, it can’t be expected to uncover and validate IPv6 protocol behavior beyond the somewhat narrow focus on the existing vendors and configurations. These are specific to the organization’s current network, and as a result, future changes to them may expose protocol components that haven’t been tested for reliable behavior and interoperability.
Fortunately, there are third-party testing laboratories that do rigourous IPv6 interoperability and standards conformance validation. For example, the University of New Hampshire InterOperability Laboratory (UNH-IOL) offers “independent, vendor-neutral testing with a focus on quality assurance.” Both the United States Government v6 (USGv6) and the IPv6 Ready Logo accreditation programs are facilitated through the UNH-IOL.
As part of the IPv6 support validation you do for your equipment, you may want to familiarize yourself with the UNH-IOL IPv6 test suites. You may also want to investigate if any or all of it is USGv6 or IPv6 Ready Logo accredited (and if not, find out why not directly from the vendor).
Depending on your relationship with a given vendor, details regarding IPv6 support may be easy or hard to come by.
You’ll likely discover that for any given asset, vendor claims of IPv6 support will be a mixed bag. Some critical features may already have support, while others may not.
WORKING WITH VENDORS
You’ve probably noticed my use of the phrase vendor claims by now. This is not to suggest that vendors are inherently untrustworthy when it comes to assessing IPv6 support. Be aware that the path to effectively supporting IPv6 is often quite difficult for them. The IETF RFCs they rely on in whatever good-faith efforts they make to implement protocols in products or features can often be vague or operationally obtuse. Then there’s the challenge of a potentially limited customer install base for IPv6 features. Even for their customers that have deployed IPv6, many of them are still in the early stages of IPv6 adoption. Their deployments may lack the kind of operational complexity or load that uncovers bugs, feature limitations, or general lack of performance.
As a result, try to get at least the following from your vendors:
§ IPv6 RFC support
§ Feature (and/or functional) parity list or matrix
§ Known IPv6 bugs and issues
§ Existing IPv6 customer deployments and references
§ IPv6 feature roadmap
Obviously, there is always a fine line between working with your vendors to introduce and improve the features you need and letting them turn your production network into an extension of their test lab. The topic of technology vendor management itself is probably worthy of an entire book (though not likely a particularly exciting one). Just be aware that you’ll need to work as closely as ever with your critical vendors as you tackle IPv6 adoption.
Regardless, once you have your list of critical features and the vendor insists that it supports IPv6, it’s time to put on your skeptic’s cap (or beret or fez or bonnet, if you prefer) and get to work testing, testing, testing (i.e., step 2). It’s usually neither practical nor very wise to test new technology on the production network. Chances are you’ll already have some methods, policies, and lab infrastructure in place for the controlled introduction of novel features.
Step three (testing support under load) may be difficult to accomplish before the levels of IPv6 production traffic on your network increase significantly (something that is unlikely to happen in the immediate term). Unless you have an established testing regime that includes specialized equipment like packet generators and protocol fuzzers, it’s unlikely you’ll be able to really put the performance of critical IPv6 features through their paces.
Even in the absence of any load testing, you should be able to deduce whether a particular vendor is ready for IPv6 primetime based on the quality and quantity of IPv6 feature support. Their timeliness in fixing bugs, improving performance, and adding features for IPv6 will let you know if you might need to find a vendor with a better IPv6 offering for a given asset. Further, any performance testing data they can provide should demonstrate that their gear performs adequately when configured the way you plan to deploy it.
INCLUDING IPV6 IN TECH REFRESH CYCLES
As mentioned, vendor support for IPv6 has substantially improved in the last few years. As a result, organizations that have regularly performed tech refresh during this time period have also improved their IT infrastructure’s IPv6 support (whether they intended to or not).
In fact, making general IPv6 support a must-have for any tech refresh cycle turns out to be an excellent way to accomplish one low-cost, low-risk goal of IPv6 adoption with little or no additional organizational effort.
Also, using regular tech refresh cycles to ensure that IPv6 is properly supported helps protect the enterprise’s investment in internal infrastructure (which, in turn, helps make the business case for IPv6 adoption).
So if IPv6 support isn’t already included in your tech refresh requirements, be sure to get it added as soon as possible.
Verifying That Your ISP Supports IPv6
The good news is that a great many ISPs currently offer IPv6 connectivity. The bad news is that they’re all over the map in terms of the level of operational support for IPv6. Just because an ISP is effectively managing their IPv4-based network and products doesn’t necessarily mean they are equally adept at providing good IPv6 services. Your first step is to verify that they support IPv6 at all. And if not today, then when? It’s not hyperbole to say that an ISP without IPv6 on their roadmap has no future, no matter how affordable or reliable they currently might be. Dual-stack connectivity over your existing IPv4 connection(s) is ideal. ISPs that are relying on tunneling over IPv4 to deliver IPv6 Internet services may not be ready for IPv6 primetime. If your ISP doesn’t support IPv6 and has no plans to, it may be time to shop around for a new provider.
Obtaining an IPv6 Address Allocation
If you’ve obtained IPv4 address space in the past, either from your ISP or from your RIR (regional Internet registry), the process is much the same in IPv6. Just like with IPv4, you’ll need some information before submitting your request. In Chapter 6, we’ll go into more detail regarding this necessary info, ISP and RIR policy, as well as what you can expect in navigating the process. For now, keep in mind that it is very common for enterprises to underestimate the amount of IPv6 space they need at the outset. If you’re getting ready to request IPv6 address space and you already have a rough idea of how much you think you’ll request, you may want to skip ahead to RIR Allocation Request to read up on the criteria for how much address space you should be asking for.
Phase 2: External Adoption
The most basic definition of external adoption means that an organization makes its primary website available over the IPv6 Internet. Since there are a number of ways such a website can be traditionally served in IPv4, this task can be as simple as checking a box on a web-hosting (or content delivery network) services portal, or as complex as provisioning the IPv6 Internet to servers in data centers around the globe.
As we suggested earlier in the chapter, by making their websites available over IPv6, organizations ensure that requests for content from IPv6 hosts are not translated to and from IPv4. While this step is no guarantee that IPv6 user experience will be improved, it eliminates the possibility of a degraded experience for those users due to translation. The organization may enjoy a competitive advantage over those organizations that keep their websites exclusively in IPv4.
So let’s examine what the most basic external IPv6 adoption configuration looks like (Figure 3-1). We’ll assume that you’re not using a CDN or web hosting service.
The diagram makes a logical distinction between the IPv4 and IPv6 Internet, given that the two protocols do not directly interoperate. Keep in mind, however, that most ISPs are relying on a dual-stack configuration in their core meaning that, although they are logically unique, the IPv4 and IPv6 networks share the same routers and switches.
The requesting hosts shown at the edge of these networks are configured accordingly: an IPv4-only host connected exclusively to the IPv4 Internet (our typical legacy configuration); an IPv6-only host connected to the IPv6 Internet; and a dual-stack host connected to both (via the same dual-stack CPE and ISP connection).
Figure 3-1. Enterprise external IPv6 adoption
An Internet border router that supports both IPv4 and IPv6 in a dual-stack configuration connects the enterprise network to both the IPv4 and IPv6 Internet. The dual-stack plumbing continues through a supporting firewall and onto a DMZ segment where a DNS and web server are connected (via dual-stack NICs). The OSes, DNS server, and web server applications support both IPv4 and IPv6.
Critically, the enterprise internal network remains IPv4-only, relying on NAT and private addressing to connect to the IPv4 Internet.
With this configuration, requests from IPv6 hosts will be responded to natively over IPv6. IPv4 requests will be served over IPv4 as they always have been (though from a dual-stack server).
What about requests from a dual-stack host? To determine whether they’ll be responded to over IPv4 or IPv6 (as well as how they’ll decide which address family to use), we’ll need to take a look at a little bit more IPv6 and Internet history.
Dual-Stack Eyeballs Are Happy Eyeballs
In the early days of IPv6, Internet engineers realized that, since no flag day was possible to transition all at once to IPv6, other more subtle mechanisms would have to be devised to help drive IPv6 adoption.
One of these mechanisms is found in RFC 3484. If a host has both IPv4 and IPv6 connectivity, it should prefer IPv6. It’s a simple and effective method to encourage the use of IPv6 on dual-stack hosts. And it worked well enough where hosts were actually connected to the IPv6 Internet. But where they weren’t, another mechanism, ostensibly designed to encourage IPv6 transition, broke things for these dual-stacked hosts: namely, that IPv6 AAAA (forward mapping) DNS records can be delivered to a host using IPv4.
For example, let’s say a residential subscriber’s cable modem is connected to the Internet using only IPv4. The ISP doesn’t yet support IPv6 services but plans to offer IPv6 connectivity within the next six months. In the meantime, the subscriber connects his laptop to the home network. The laptop is running Windows 7 and gets a private IPv4 address from the DHCP server running on the cable modem. The cable modem has a public IPv4 address it is using to NAT any internal private addresses it assigns.
But let’s also imagine that someone else in the household hooked up an additional home router to the local network (not to use as a router but merely to test out the device’s WLAN capabilities). The additional home router supports IPv6 out of the box and is sending out IPv6 ND RAs on the local network segment.
Someone then connects a laptop to the network. The laptop gets an IPv6 router advertisement from the second home router and proceeds to self-configure a Link-Local address. The laptop now believes it has both an IPv4 and IPv6 address.
When the laptop user opens a browser, a DNS query for the start page is sent. The query requests an A record for www.example.com and gets a response. Because it has an IPv6 address configured, the querier then requests and receives a AAAA record as well (see Example 3-1).
Example 3-1. Forward A and AAAA record for www.example.com
www A 192.0.2.34 ; example.com's web server
AAAA 2001:db8:667:776::34 ; same web server's dual-stack IPv6 address
Both responses are delivered over the existing IPv4 connection. Now, to get to the www.example.com website, the subscriber’s laptop has an IPv4 address and an IPv6 address to choose from. Which one will it choose?
Up until a few years ago, the default address selection policy found in RFC 3484 was the one commonly used in dual-stack implementations. This policy gave IPv6 preference over IPv4. In that instance, the laptop, having a valid IPv6 address, would make the assumption it’s connected to the IPv6 Internet. It would first attempt to connect to 2001:db8:667:776::34. But because the laptop is not actually connected to the IPv6 Internet, it wouldn’t be able to connect. After some period of time set by the OS (as long as several minutes in some cases), the attempted connection to IPv6 would time out and another connection would then be attempted over IPv4 (which, in our example, would succeed).
This was the situation prior to World IPv6 Day in June of 2011 and the reason that no major content providers had yet enabled AAAA records for their primary websites (i.e., www.google.com, www.yahoo.com, etc.). Knowing that some nontrivial number of Internet subscribers (much less than 1% of all Internet users but still likely numbering in the tens if not hundreds of thousands) had the same configuration as our hypothetical subscriber’s laptop from our previous example meant that configuring these AAAA records would result in impatient users believing that www.google.com was down (then maybe switching over to www.yahoo.com, which, not having a AAAA record configured, would come up immediately). Result: possible brand damage to content providers daring to significantly adopt IPv6 early.
World IPv6 Day was organized to test the extent of this IPv6 brokenness while avoiding exposing individual content providers to any exclusive brand damage it might do. If all the major content providers enabled AAAA records for 24 hours, users with broken configurations would have trouble getting to any of their sites (not just to those providers brave or foolhardy enough to have unilaterally configured AAAAs prior to World IPv6 Day).
At this point, you’re probably wondering why couldn’t the OS or browser just test the connection to IPv4 and IPv6 simultaneously and pick the one that works (and perhaps even performs better)? Well that’s precisely what most OSes and browsers do now, thanks to Happy Eyeballs. Following the success of World IPv6 Day, another event was planned for June of 2012. World IPv6 Launch aimed, among other goals, to have major content providers, as well as anyone else who wanted to participate, configure AAAA records for their main websites and leave them permanently enabled. Though the content providers decided that the actual levels of IPv6 brokenness were acceptably low, the rapid and significant adoption of the Happy Eyeballs approach to address selection in browsers and OSes made the issue even less of a potential concern for them.
And that’s the reason why organizations today should feel confident in configuring AAAA records, leaving them enabled, and making their primary websites permanently available over IPv6.
IPV6 CDNS AND WEB HOSTING
Many major web hosting companies and content delivery networks (CDNs) offer IPv6 support for at least some of their services. For organizations already using CDNs or hosting services, this can be the easiest way to accomplish external IPv6 adoption.
Some forward-thinking providers are even moving to an IPv6 on-by-default or opt-out posture where any newly provisioned service offers IPv6 by default unless the customer explicitly chooses not to enable it.
Regardless, as is true with these services in IPv4, the potential advantages are many and include:
§ More rapid provision of IPv6 accessibility for websites and online content
§ Dynamic scale of services over time to support increasing levels of IPv6 traffic
§ Geographical diversity to shorten distance to content (and improve performance and user experience) for requestors
§ Dual-stack or IPv4-only interfaces to make website and content management and upload easier
If you’re already using a web hosting or CDN service, you’ll need to check with them to see what level of IPv6 support they offer. You may want to find out the following:
Do you offer IPv6 everywhere you offer IPv4?
As we mentioned, a key advantage of using a web hosting service or content delivery network is geographical ubiquity and diversity of services and the improved performance that may offer. But for this performance advantage to be uniformly realized in IPv6, the provider in question would need to have IPv6 provisioned anywhere IPv4 currently is. As with provisioning these services in-house, it might be initially acceptable to have less ubiquity and diversity, especially if you are in a proof-of-concept phase for deploying IPv6. Regardless, you’ll want to know what the provider’s roadmap to full IPv6 parity is in this area.
Are your management and IPv6-content upload interfaces available in IPv4 (or IPv4-only)?
A possible advantage for companies leveraging a web hosting or CDN in order to make their websites and content available over IPv6 is that little or no in-house IPv6 infrastructure may be needed right away. You’ll want to check with the provider to make sure that you’ll be able to manage and upload content from your IPv4-only or dual-stack hosts and servers (depending on where your organization is at with overall IPv6 adoption). You’ll also want to make sure that the provider either currently offers, or has a plan for offering, content management and upload via IPv6.
Do you offer IPv6 reporting and visibility equal to what’s currently available in IPv4?
Another critical benefit of using a web hosting or content provider is the visibility into, and detailed reporting for, the services they offer. The data from these features can often be used not just to ensure performance but also to generate metrics that can improve the reach of the company into better target markets. Of course, all of this reporting and visibility needs to work for IPv6 traffic as well as IPv4, and you’ll want to make sure that the provider supports, or plans to support, all such features equally well in IPv6.
Phase 3: Internal Adoption
For most organizations, the final phase of IPv6 adoption is the deployment of IPv6 on internal networks. Traditionally, most enterprises have been slow in tackling this phase, likely due to a number of unique factors, including:
§ Reliance on NAT and private address space architecture and practice for internal networks
§ Business models and revenue streams not reliant on continually scaling network services (and the IP address supply such services require)
§ Little or no need to be seen as early adopters of transformative technologies
§ Little or no operational best practice to leverage from other enterprises due to slow overall adoption
§ Discouraging assumptions that internal adoption is more complex or expensive than other phases
Let’s examine a few of these factors individually before discussing the potential risks and costs of delaying internal IPv6 adoption. We’ll then look at steps that organizations can take to make internal IPv6 adoption more manageable.
Reliance on NAT
We’ve already discussed the pros and cons of NAT for enterprise networks.
On the plus side, NAT reduced the rate of consumption of limited public IPv4 addresses by networks and hosts that didn’t need to be directly accessible from the Internet. This delayed the inevitable arrival of IPv4 exhaustion. NAT also allowed enterprises to take advantage of the relatively larger space available with private IPv4 in planning their address architectures. It has also given enterprises much more flexibility to schedule (and frankly, delay) their internal adoption of IPv6.
Meanwhile, this flexibility has too often led to an insufficient recognition of the potential risks and costs of failing to adopt IPv6 internally.
But setting aside IPv6 altogether, IPv4 NAT’s deficiencies are often ignored or overlooked. We mentioned in Chapter 2 both the misperceptions of improved security through obscurity, as well as the operationally taxing impact of NAT on application features and performance.
IPv6 Business Case Redux
A more general business case for IPv6 adoption is perhaps easier to make for the first two phases of IPv6 adoption. Given the growth of IPv6 adoption across the Internet, it’s impossible at this point to argue that any enterprise IT organization can avoid IPv6 altogether. It would almost certainly be a form of career suicide for individual network or system administrators or engineers to studiously ignore IPv6 simply because their current company has mistakenly decided to do so. Thus, while the scope of what you’ll need to know and plan for in IPv6 might vary from organization to organization, there should be little doubt that some knowledge and planning are absolutely essential.
Since IPv6 deployment by mobile and broadband subscriber service providers is already happening at accelerating rates due to the lack of routable IPv4 (and the additional expense and operational complexity of CGN/LSN solutions), making websites and content available through external IPv6 adoption is the only way for organizations to directly reach these new subscribers.
The business case for internal enterprise IPv6 adoption is usually more general, focusing on how even modest uptake of IPv6 among internal enterprise networks will, over time, result in evolution of operational practices (and, as elaborated on below, premium costs for continued IPv4 support provided by vendors and SPs).
Considering that all modern OSes now have IPv6 enabled by default, IPv6 is already running on any network where you haven’t explicitly disabled it (not an option for reasons we’ll see next). This means that IPv6 is running essentially unmanaged. As a result, the requirements of the existing network security policy where IPv4 is concerned (as well as the security tools providing visibility and mature operational practice that go with it) are not being met for IPv6.
This lack of operational awareness and practice results in a weakened state of network and host security that threatens business continuity, whether by error or misconduct. And without the security tools and operational practice in place to effectively monitor IPv6 traffic, the security policy is either being directly and actively violated or is out-of-date with no reference to IPv6. This noncompliance will become more costly over time.
Considering that it is only a matter of time before new services will need to be enabled in an IPv6 environment, an ongoing lack of training, proper tools, and operational experience will continue to erode business continuity.
THE LATENT COSTS OF IPV4
There’s an effort at large among the hardcore IPv6 adoption community that skeptics could be perhaps excused for deriding as mere semantics: IPv6 should now simply be called IP while IPv4 should now and forever be referred to as the legacy protocol.
Before you scoff, though, keep in mind that a common effort among some organizations (both service providers and enterprises) that have widely adopted IPv6 using the preferred dual-stack approach is now trying to figure out how to decommission IPv4 sooner rather than later.
There are a few reasons for this.
It’s absolutely the case that dual-stack is a necessary intermediate step to facilitate the introduction of IPv6 into the network while simultaneously protecting the existing IPv4 production network (not to mention controlling the risks and costs associated with failing to adopt IPv6 in time). But it should be uncontroversial to point out that managing two address protocols over time (however necessary initially until IPv6 operational and architectural practice has matured) is more complex (and potentially costly) than managing one.
Service providers have seen their historical revenue sources (mere bandwidth and connectivity) commoditized out of profitability. The razor-thin margins that remain have left these providers scrabbling for any opportunities to recognize new revenue streams. As a result, they’re really looking forward to charging you an added premium for any aspect of their legacy IPv4 service, from connectivity to services to addresses. If you’re not running IPv6 and have no upgrade path, you’ll have to pay what they’re asking (or go with a bargain IPv4 provider: how retro!).
At some point in the near future, vendors will be making similar assessments as they allocate product and feature strategy resources. While continued IPv4 feature support may not directly cost more, customers may discover that vendor support and engineering are slower to resolve issues with the legacy protocol. This could result in additional operational expense (not to mention much aggravation!).
Internal Adoption and Operational Wisdom
While IPv6 deployment on the internal networks of large, multinational companies has accelerated, these organizations are generally not inclined to publicly share too many of the details of their IPv6 initiatives. This makes it difficult to derive business cases from their IPv6 adoption efforts, and it reduces any bandwagon effect among other enterprises we might otherwise see. It also reduces the operational wisdom and guidance available to enterprises.
A lack of operational guidance can cause enterprises to make unforced errors at the early stages of their internal adoption efforts.
For instance, members of the enterprise security team may learn that IPv6 is on by default and perhaps recognize that it is generating unmonitored traffic on the network. The network security monitoring tools in use may not offer IPv6 support, or unfortunately more likely, the team may lack IPv6 expertise, as well as the time and resource commitment needed to obtain it. Rather than addressing these causes, and with the best intentions for proper security, they’ll insist that IPv6 be disabled on servers and hosts.
A side effect of this step may be to weaken or break OS features like Failover Clustering in Microsoft Windows Server, which currently prefers IPv6 both in production and in vendor test environments. Other features like Microsoft Direct Access rely on IPv6 to provide end-to-end addressing (something not really possible to do with IPv4). And like many other Microsoft services, Exchange Server 2013 is considered out-of-scope for technical support when IPv6 is disabled.
Another possible error is for enterprise IT to assume that the existing architecture leveraging NAT and private addressing in IPv4 should be replicated in IPv6. This can lead to ULA being deployed internally with either NAT66 or NPTv6 at the edge. While there certainly could be network and business requirements that make this configuration desirable, the recommended architecture for nearly all enterprise networks uses global unicast addresses everywhere.
 And as we mentioned at the end of Chapter 1, large mobile and broadband service providers in North America, like Comcast and Verizon, are not merely reacting to this trend. Instead, they’re getting out in front of it with IPv6.
 The same will undoubtedly prove true of IoT networks as they increase in number and scale.
 If formal training cannot be budgeted, check with your equipment vendors and partners to see if they offer any specialized training around IPv6, which can often be had for little or no cost (and can help you identify which of your vendors and partners are serious about their IPv6 support).
 There are exceptions to this: certain IPv4/IPv6 transition technologies that rely on tunneling have historically been generally well-managed by providers like Hurricane Electric, Free Telecom (France), and Comcast.
 An IPv6 or dual-stack segment might be connected through to the DMZ in order to facilitate management and testing of the IPv6 resources located there.
 RFC 3484 has since become obsolete by RFC 6724, which includes updates to the address preferences and selection algorithm.
 Technically, PAT (or port address resolution).
 RFC 3484 (along with its replacement, RFC 6724) technically allows for alternate address selection policy and methods, such as Happy Eyeballs and Windows Network Connection Status Indicator (NCSI).