Core to edge is the approach you will probably choose if you have the time. It has several advantages. In this approach, you start deploying IPv6 where it is easiest. The equipment you use in the core has the longest history of implementation and deployment, so the IPv6 stacks are more mature and you can usually deploy with the least upgrade effort. The complexity of IPv6 integration increases when you move to the edge. Stacks are less mature, implementations are either not available or are in an early, buggy stage, and application compatibility and interoperability can be an issue. Vendor support may be in its early stages too. So while you work on the core, you’ll build all your experience; and by the time you get to the edge, hopefully the market has matured and you’ve had the time to resolve the edge issues in your labs.

Another important advantage of this approach is that while you work on deployment in the core, your critical user or customer traffic still flows over the IPv4 infrastructure, so you can deploy IPv6 with no risk or pressure. You can also implement management and security, and then test everything carefully before you allow user and customer traffic. This approach helps you train your people, get experience in managing the new infrastructure, and build your support teams, such as help desk and second-level support.

Edge to core is the approach to choose when you need to roll out IPv6 to customers or clients quickly. This may be the case when you run out of IPv4 addresses and can’t cover the demand for growth anymore, when a new service requires a lot more addresses than you have or when a new application is needed, that requires IPv6.

The project risks rise significantly when you choose this approach, so you may want to avoid this situation by planning while there is time. Besides the fact that urgency is always a critical factor when you’re introducing new technologies, the risks and costs are high because you’re starting where the complexity is highest, you’ll face project delays due to interoperability issues and unexpected bugs, and—most importantly—you’ll have to enable user and customer traffic over your infrastructure before you’ve had the time to carefully build and test it. Your engineers and support organization will have to manage the infrastructure even though they haven’t had time to develop the experience necessary to support it efficiently. Service outages are much more likely to happen with this approach.

IPv6 islands are the approach you can use when you must deploy IPv6 to specific applications, customers, or parts of the network as a first step. Tunnels may be used to carry IPv6 traffic over IPv4 subnets to interconnect the IPv6 islands.

Economic considerations may be one of the main reasons to choose this approach. It also reduces the project scope for deployment and the number of systems that have to be changed. It allows you to deploy IPv6 where it is most needed first. So, for instance, if you choose to upgrade your DMZ first in order to be publicly reachable over IPv6, you’re using an island approach. Or if you choose to deploy a new service as IPv6-only right from the beginning, this would be another island approach. Islands can also be used for trials to have a controlled environment and limit the impact and the risks.

Organizations that use external services, such as web hosting, can work with the service provider to enable IPv6. This method takes advantage of any IPv6 implementation experience the service provider may already have.

You must carefully evaluate whether the island approach makes sense at large scale. You have to weigh the advantages against the complexity of managing a heterogenous network, which always increases operational cost and carries a higher risk of misconfiguration and errors.

Every long journey starts with a first step; after that, things become much clearer. But what is the first step to planning for IPv6? The complexity of an IPv6 project comes from the fact that we are adding a transport layer protocol, which means that all networking components are affected. It also means that all networking and application teams and IT groups have to collaborate to make the integration work.

To get started, you need an idea of where you want to go. This is the objective of a high-level design. Before you can actually define your goal, you need to take the preparatory steps outlined in the following sections.

For a successful project, you must develop a well-structured IPv6 integration project team. Because IPv6 integration touches every component and department in your IT environment, everybody has to be involved, including key business stakeholders. Managing this task in a large organization can be a challenge. A good approach to coordinate all activities efficiently is to have one or two people lead the project as IPv6 program managers. The program managers organize all activities with the project leaders of each individual group (such as security, routing, applications, etc).

For the design of a high-level implementation plan every department that deals with the network and its services must be included. Before the team can start discussing a high-level implementation plan, however, all the team members must be thoroughly trained and understand both the obvious and the more subtle differences between IPv6 and IPv4. In the initial phase, this training includes executives, architects, planners, the security and routing team, server and client teams, and application groups—all the groups that should also be included in the planning and design. The team needs a good and thorough understanding of the entire IPv6 protocol and all its new features and possibilities. In this first phase, it is also very important to launch awareness campaigns at the top executive level and include all stakeholders.

Simply applying your IPv4 concepts to the IPv6 network will carry over IPv4’s limitations to your IPv6 network. By building an IPv6 network, you have the opportunity to build a next-generation network that is capable of supporting the applications and services of the future. Without a thorough understanding of the new features, you waste this opportunity.

In a later stage of the project, all groups will need more in-depth training and the possibility to build and run labs to get a feeling for the protocol and create more refined concepts for each area of the network. In this stage, you also need to include other groups such as support staff, help desk, customer contact groups, and sales and marketing people. The list of groups to be trained at this stage may vary depending on the business and the type of organization.

If your organization develops applications for internal use or for the market, make sure you train the developers in IPv6 with a specific focus on developing IP-version-agnostic applications that behave well in both IPv4 and IPv6 networks, but also in dual-stacked networks.

A note on consulting: there are various degrees of engagement with consultants. You can try to do the entire integration with your own resources, or you can choose to fully outsource the project. I do not recommend trying to do it all with internal resources. While you create new concepts for all the parts of your network, it is a good idea to get external perspectives to broaden the scope as much as possible. This is your opportunity to redesign your network, so at least get second opinions before you deploy. At the same time, it is important to involve all your teams in the design phase, because they are familiar with the internal procedures and policies and they are the ones who will have to operate the network. So a combined approach is usually the most efficient for everyone. With this approach, your staff can learn and profit from external perspectives and experience, and will not have to reinvent the wheel. Bringing in experienced consultants to work with your teams can be considered (and budgeted as) on-the-job education.

The biggest and most costly mistake is to assume that IPv6 is not that different from IPv4 after all, and that with all your IPv4 experience, it will be pretty easy to create concepts for IPv6. While that approach may work at first glance, it means you squander all the options and possibilities the new protocol offers. For instance, if you create an address plan with the limited cell-engrained mindset you’ve developed from 15 years of operating IPv4 networks—where the highest priority has always been to preserve address space—it’s a safe bet that the address concept will be like a straitjacket for the future and that in five years you’ll be saying, “if only I could start all over again...” Creating concepts like this is way more expensive than giving IPv6 enough attention right from the beginning.

One important ingredient of the high-level design is going through all the designs that exist in your environment right now, reevaluating them, and asking yourself what components have stood the test of time and what you would do differently if you could start over. Take what you’ve learned from operating an IPv4 network and integrate it into your IPv6 concept (obviously, don’t copy whatever you did to conserve address space), combining it with the new features and possibilities IPv6 offers.

The high-level concept answers the questions: what is our long-term goal—where do we want to be in 5–10 years? What will our network look like, what will our services probably be like, should we plan for going IPv6-only as soon as possible (and if yes, in what areas of the network?), or should we plan for a long-term dual-stack strategy? Do we have enough IPv4 addresses to go dual-stack long term? What will our security and routing designs look like? How do we manage the coexistence of IPv4 with IPv6 and a dual-stacked network?

In many cases, the network will predominantly be IPv4 for a long time, with growing elements of IPv6. At some point in the future, it may be a mainly dual-stacked network with decreasing IPv4 support while slowly moving toward a predominantly IPv6 network. Over these different periods, you may use different mechanisms to support it. Even for many years to come, we may have to support some single IPv4-only applications. In the early days of deployment, we support them by running dual-stack if possible, but in the future we may choose to turn off IPv4 in the network and find other mechanisms to support these IPv4 applications.

As part of the high-level design, you will create an IPv6 address plan, a routing and a security design. At this point, you need to involve upper management, if you haven’t already done so, although it’s usually not yet possible to know how much IPv6 deployment will cost. You can answer the cost question only after you’ve assessed the network based on the IPv6 requirements outlined in the upcoming section, “Network Assessment.”

Most applications simply rely on the host operating system for network operations and services for handling IPv4 or IPv6 traffic. However, some applications may exhibit different or undesirable behavior when end-to-end IPv6 is enabled. Key things to look for are applications that log the IP addresses of network traffic or include control/configuration files containing IP addresses instead of a URL and DNS for name-address resolution. Particularly, any applications that make direct calls to the IP layer will probably have to be adjusted to work well in a dual-stack world.

Based on your high-level implementation plan, you can start to define IPv6 requirements for all the devices, operating systems, and applications in your network. The requirements have to be very specific (you won’t get around quoting RFC numbers) and will vary depending on the device. It is not specific enough to require an IPv6 function—in some cases, you will also have to specify suboptions or message types.

For example, DHCPv6 supports many options (you can find all the options in the DHC working group at http://datatracker.ietf.org/wg/dhc), but you may not need all of them for your purposes. Or if you require your new firewall to be able to filter on extension headers, you may want to list specific headers, such as the routing header type 2 defined for Mobile IPv6. You also want to make sure your firewall doesn’t pass packets with illegal extension headers, deals accurately with the deprecated routing header type 0, and inspects the content of tunneled packets.

The requirements specification serves four purposes:

Now that you have your IPv6 requirements specification, you can start assessing all your network devices and services. This assessment is used to categorize all the devices, operating systems, and products for their level of IPv6 capability.

The assessment must cover the following:

All items can then be categorized as follows:

This assessment clarifies the scope of your IPv6 deployment project. You may find that you need to adjust the roadmap that you created in your high-level design. And now you can estimate costs for each step in your roadmap, because the assessment has helped you identify what investments and how much effort will be necessary for the deployment. Some of your findings may also have an impact on integration mechanisms you’ve chosen; for instance, you may find that a service that you assumed could be upgraded to work in a dual-stacked environment has to be replaced but has no alternative available.

In general, IPv6 compatibility in your applications probably has a bigger impact on your integration plan than equipment support. And the more custom-developed or highly customized in-house applications you use, the higher the chance they won’t work with IPv6 and may not even be upgradable. So make sure you allow for enough time in the planning and testing stages to find solutions to these challenges.

This is a perfect time to reassess your vendor portfolio. Whether a device, service, or application has the required IPv6 support may not be the only criterion. You may want to find out what your vendor’s roadmap looks like to determine whether he will be up to date in following development and offering state-of-the-art products. Obviously, the importance of this step varies for different devices and products. Specifically, for core network devices and services that usually have a long life cycle—such as core routers, firewalls, management and monitoring tools, and DDI (DNS, DHCP & IPAM) solutions—it is crucial to have a vendor who guarantees high performance products, professional support and a good future development roadmap.

When it comes to your ISP, it is not sufficient to ask for basic IPv6 connectivity. You want to know what kind of connectivity you will get; whether it will be tunneled or native has an impact on performance and scalability. You also want to know what the ISP’s peering connections to the IPv6 Internet are.

Labs are probably your most important playground on your way to becoming an IPv6 expert and reducing deployment risks. The lab serves many different purposes. First and foremost, it’s a place for experimenting, learning, and gathering experience, and then you take that knowledge back to the planning process to be integrated in deployment concepts. You may have several options in your high-level strategy—such as the choice of a routing protocol, different solutions or designs, or various vendors and products—where you need to evaluate which selection best suits your requirements or performs better in a given environment, and to test compatibility of different products. You should always evaluate and test your design choices and deployment steps in a lab before finalizing the deployment plan to reduce risks and project delays.

The ideal scenario is having a completely separate lab that mirrors your production environment as closely as possible. You use the lab to test your deployment strategy, fix bugs, and learn how to troubleshoot IPv6. It is also the perfect playground to train your support staff for operating an IPv6 network. You can use it to document your deployment plan, implementation, and configuration, and to create functional specifications. Finally, you can perform quality assurance and conformance tests in the lab.

During the different stages of deployment, the lab will probably change. So, if you choose a core to edge approach, you will first want to test all backbone functionality including addressing, routing, and security and how the components interact. Next, you’ll test network services such as address management, DNS design, and behavior in combination with services and applications and so on. You probably also want to do performance and load tests for your chosen scenarios to find out ahead of time if your network can deal with the additional traffic and the mechanisms that you have chosen, and to determine whether core systems (routers, switches, firewalls, and other security devices) perform under load. Every step you test may deliver findings that make you refine your deployment plan.

Once you have evaluated your vendor candidates, you’ll need to use the lab to test their products for conformance to the project’s standards and requirements and to find possible bugs. You have to be prepared for the fact that many IPv6 implementations are early versions, and therefore may be immature and have more bugs in the beginning than you are used to from their current IPv4 counterparts. Allow enough time in the lab to test this, because it may save you a lot of headaches during later stages of the project. Finding unexpected bugs usually delays projects, as it requires you to solve the issues with the vendor and wait for patches before you can move on. In general, whatever you test in your lab—be it verification of concepts, stacks, devices, or applications—the earlier you find any issues, incompatibilities, and bugs, the easier and less expensive it is to find new solutions or fix code.

Once you have verified your high-level strategy, know the state of your IPv6 readiness, and have tested all your options and vendor products, you can refine your high-level concept and develop detailed, low-level deployment plans for each specific network and service area. You should place these plans on a meaningful timeline and account for all interdependencies.

At this point, you will also perform a risk assessment and develop a risk-mitigation strategy. The results of this assessment may affect your integration and security strategy, and they also provide the foundation for a fallback plan.

Each low-level implementation plan will have detailed descriptions of implementation procedures (including setups and configurations for all components or applications), schedules and timelines, backout plans, acceptance criteria, and tests to be performed. Before you implement IPv6 in production, you will probably want to thoroughly test the implementation plan in your lab.

In the long term, for the operational phase of a dual-stack network, you will need to ensure that all management and change processes are fully synchronized so you can keep the same level of functionality and security for both protocols. Changing configurations should be a single coordinated process for both protocols.

Here’s a summary of the golden rules of IPv6 integration:

With IPv6’s extended address space, having a good address design is more important than with IPv4. The address length offers new options for a hierarchical addressing structure, which in the future might be more based on geographical aspects at the upper levels to support efficient aggregation.

In general, routing and forwarding principles are no different in an IPv6 network. We have some features to optimize forwarding efficiency, such as a fixed-length IPv6 header, extension headers (which are inserted only if options are needed), and the fact that IPv6 routers do not fragment anymore. We can use the flow label to optimize data flows.

The original plan for IPv6 was to not allocate provider-independent (PI) addresses at all. An early design goal for IPv6 was to not only solve the address situation, but also the problem with overflowing Internet routing tables. Just like with IPv4, the IANA distributes the IPv6 address space to the RIRs (regional Internet registries), but mainly based on geography in order to keep the root routing tables as small as possible. It turned out that the zero PI space wasn’t a sustainable policy in the real world. So we are back to having PI space, which partially breaks the hierarchical model based on geography and thereby creates more entries in global routing tables. An example: PI space means that a company headquartered in Switzerland with a global network may get PI address space from RIPE, the RIR for Europe. For the US locations of that company, the US-based ISPs will have to announce the route to this RIPE prefix.

Also, in the future IPv6 routing tables will not contain 32-bit address entries, but rather 128-bit address entries. And during the transition time in dual-stack networks, routers will maintain two routing tables, one for IPv4 and one for IPv6. The vendors will have to make sure that forwarding is efficient, done in hardware, and that the routers use resources efficiently so the routing tables take up the minimum possible memory.

There are two different types of routing protocols. An IGP (interior gateway protocol) is used within an AS (autonomous system), which represents an administrative domain. Different autonomous systems are connected through EGPs (exterior gateway protocols).

The address plan is a challenge for most. We have all been well trained to conserve addresses, and the training has been so efficient that this rule is stored in our brain and body cells. We have to overcome this reflex action before we can create a useful IPv6 address concept for 128-bit addresses. So what are the rules, how can address concepts be designed for IPv6?

Before we start, though, let’s go over something that may help you to slowly overcome your address-conservation reflex and free your mind from its limited thinking. Use this as your daily mantra while you work on an address concept.

Consider the numbers of IPv6 address allocation. By January 2011, approximately 145,000 /32s have been allocated^[5]. In 2010, 5,800 /32s were given out, and in 2009 the number was 1,000 /32s. Now note that one single /32 provides more subnets than the entire IPv4 address space provides addresses. This is because the IPv4 address has 32 bits for the whole address, including host IDs, while a /32 provides 32 prefix bits and each subnet has 64 interface ID bits.

So this means that by 2011, we have allocated 145,000 more IPv6 address space than we ever had with IPv4. Is that a lot? When we calculate how much of the currently defined address space that is, we see it represents a mere 0.027%! And the currently used global space is only a fraction of what we really have—only 2000::/3. With 145,000 /32s, 9.5 billion customers can receive a /48. And each customer can create 65,536 subnets, with each subnet having 64 interface ID bits. Go figure—it will suffice for some years. OK, now shake your cells and read on.

An efficient address plan should group address ranges logically in order to:

Location first:       2001:db8:1:LLLLSSSS FFFFFFFF::/64
Service type first:   2001:db8:1:SSSSLLLL FFFFFFFF::/64

Having a strong security design is very important for managing a dual-stacked network. As soon as you introduce IPv6 into your network, you have an additional entry point.

So, as a first step of protection before you deploy IPv6, make sure you filter all IPv6 traffic coming into and leaving your network. This includes native IPv6 traffic and tunneled traffic. In addition, it might be wise to monitor and audit IPv6 traffic—specifically ND messages such as router or neighbor advertisements that could be used to configure your clients with incorrect gateway or DNS server information.

Your future security design will have to secure both protocols: you still have your IPv4 security design, and you will have to define an IPv6 security design. If your IPv4 security concept is well designed, it is advisable to align your IPv6 security concept with it. You will have to add protection from attacks that use IPv6-specific mechanisms, such as extension headers, multicast addresses or neighbor discovery messages, SLAAC, and specifically tunnels.

Your steps to define a new security design may look like this:

The basics of DNS (Domain Name System) have not changed. For IPv6 DNS services, you need the following:

When a dual-stacked host queries a DNS server for a service name—for instance, when a user enters a URL in the browser—the client will send out two DNS requests: one for an A record and another for a AAAA record. The DNS server may respond with either an A record or a AAAA record, or with both, depending on how it is configured. If the client receives two addresses, it will—based on the default address selection rules (RFC 3484)—prefer native IPv6 over IPv4.

Which transport is used for resolving a name with DNS is independent of the connection that is built. So, for example, Windows XP cannot resolve DNS names over IPv6. A Windows XP client always needs a DNS server that it can reach over IPv4. But when the client is dual-stacked and the DNS server responds with a AAAA record, the Windows XP client can initiate a session over IPv6.

A problem can arise when a client gets a AAAA record but does not have an IPv6 connection or has a very poor one. Because IPv6 stacks are configured to prefer IPv6 over IPv4 by default, the client will try to connect with IPv6. But because it does not have connectivity, there is a long delay until the client eventually reverts to using IPv4 (which it can only do if it got an A record for the same service). In most cases, the user won’t understand why it takes so long to access that website and will probably blame the website owner for it.

This “IPv6 brokenness” of clients/browsers is the reason why large dual-stacked websites such as Google and Facebook don’t give out AAAA records for their main domain. If you want to access Google or Facebook over IPv6 today, you have to use a v6-specific domain name such as http://ipv6.google.com. These large sites cannot accept performance hits due to users on networks with bad IPv6 Internet connectivity. If such a user experiences long timeouts while accessing Google, he will think that Google is responsible for the poor performance, when in fact the timeout stems from the client not being able to connect over IPv6 and waiting to connect over IPv4. Google and other large sites often use DNS whitelisting for ISPs with good IPv6 performance, so they can be sure that users coming from that ISP will have no problems accessing the website over IPv6. Only if you are connected from such a provider will you get a AAAA record for http://www.google.com. This was the motivation behind World IPv6 Day, which took place on June 8, 2011. On this date, all major websites enabled the AAAA record for their main domain for 24 hours in order to test what happened, analyze the results, and determine what it takes to improve the situation so they can eventually enable AAAA records for the main domain permanently. To find more information on World IPv6 Day, go to http://isoc.org/wp/worldipv6day. The testday was almost uneventful, in that no major problems were encountered. For most users, Internet performance was as usual. Analysis showed that IPv6 brokenness is a declining concern, mainly due to new features in browsers. On that day content available over IPv6 has clearly increased and so has IPv6 Internet traffic over IPv6 increased in general. Many websites that enabled IPv6 for the test day and found no issues decided to leave IPv6 turned on permanently. This accounts for more than 60% of the participating websites. Hopefully we can soon move to an Internet where regular domains can also have AAAA records with no restrictions.

With regard to DNS design, one important point to be aware of is namespace fragmentation. When a resolver tries to resolve a name, it will start at the root and follow referrals until it reaches an authoritative name server for the name. If the resolver encounters a name server that is reachable only over a protocol that the resolver can’t use, the name cannot be resolved—the DNS query is unsuccessful.

As IPv6 starts being deployed more and more in the Internet, the namespace may get fragmented because there will still be name servers that can be reached only over IPv4, as well as more and more name servers that can be reached only over IPv6. So we need mechanisms to avoid the situation where the resolver chain breaks due to two name servers in the resolution process that do not speak the same “language” (IP version); here are the DNS recommendations (excerpted from RFC 3901) on this topic:

For your integration of IPv6, it is probably a good idea to plan for dual-stacked DNS services, as this offers the best and most flexible protection from fragmentation. With BIND9, you can also configure a dual-stack server. When a recursor needs to look up data in a zone served only by a name server that doesn’t speak the same language, it can forward a recursive query to the dual-stack server.

Make sure that you configure AAAA records only when the services are fully reachable over IPv6; otherwise, your clients may experience long timeouts or not reach the service at all. We also have to move away from entering host names only in DNS. A host may be dual-stacked (and have two DNS entries), while some services running on that host may be either IPv4 or IPv6 services. In a large enterprise, it could be prudent for administrative reasons to avoid mixing IPv4 services and IPv6 services on dual-stacked hosts, but rather to place IPv4 services on IPv4 hosts and IPv6 services on IPv6 hosts. At the same time, you have to make sure that all clients that get AAAA records for IPv6-only services can connect over IPv6 to the network where the service resides. If a service is available on both protocols, make sure the IPv6 service gets precedence over the IPv4 service so your traffic can shift to using IPv6 more and more whenever it is available.

There is already a good amount of experience with IPv6 DNS available. Here is a list of RFCs you should check before you spend a lot of time troubleshooting DNS. Your issues may already have been documented:

The procedures in this area are the same as outlined previously in the section Security Design, and apply to any other subproject:

A management system may well understand and manage IPv6 while still communicating over IPv4. In fact, many management systems today don’t support IPv6 transport. For example, SNMP may carry information about an IPv6 network element, but the SNMP message may be transported over IPv4. Make sure to test for this behavior and evaluate accordingly. Depending on your situation, you may be doing well with an IPv4-communicating management system as long as you operate in a dual-stack network.

With IPv6, you have three options for configuring devices for an IP address. Option one is using SLAAC, in which interfaces autoconfigure an address either based on its MAC identifier (EUI-64) or by using the privacy option, where the interface ID is randomly generated and changed in regular intervals. This interface ID is then combined with routing prefixes learned from router advertisements. The second option is to use DHCPv6, which is very similar to DHCPv4. What is new in DHCPv6 is that it includes an authentication framework. You can also combine these first two configuration options by having interfaces use SLAAC for the address configuration and then sending out DHCP inform requests to get additional configuration from a DHCP server. Or another combination is that clients can use SLAAC to configure an address for one prefix and then go to a DHCPv6 server to get an address for another prefix. The third option is to manually configure interfaces for an IPv6 address. You may want to use this option for servers and routers to make sure you have control over the address.

If you want to populate DNS with the device entries, in the case of SLAAC you will have the clients update DNS (Dynamic DNS). If you are using DHCPv6, you probably want the DHCP server to update DNS. It may be a good idea to secure DNS (DNSsec).

SLAAC is a great and easy way to configure your devices for an IP address if you have a smaller company or if you need to configure networks with frequently changing users, such as public ad-hoc networks (mobile and wireless networks) or areas in your corporate network where you have guests and partners connecting temporarily. SLAAC is also very useful for the configuration of sensors.

In the enterprise area, most customers choose DHCPv6. The reasons are that DHCPv6 offers you more control and stateful configuration, which means that you always know which device used which address at a certain time (for security and policy reasons). Servers, routers, switches, firewalls, and similar devices should be statically configured.

Many enterprises use an IPAM suite, or DDI as it is called nowadays. DDI stands for DNS, DHCP, and IPAM. As of early 2011, there aren’t too many production DHCPv6 servers out there. Most vendors have announced their DHCPv6 server for sometime in 2011. Many suites already offer different levels of address management options. It is advisable to work closely with your vendor and find out what his level of IPv6 support is and what his roadmap looks like. Managing a dual-stacked network is quite complex, and you need tools that offer the greatest flexibility and present a clear view on your network devices from different perspectives. You probably want to be able to see which IP addresses are assigned to a specific MAC address, or which IP addresses relate to a specific DNS name, or from a device perspective (how many interfaces, what DNS names, and IP addresses for each). You will need to experiment in your lab to find out which address management product best suits your needs.

In the 90s, NAT was developed because the IPv4 address space became scarce and IPv6 wasn’t ready yet. In other words, NAT was created as a temporary solution to the address problem. But then we got used to it and found many additional advantages in the technology, and in fact, this is what delayed the introduction of IPv6 once it was ready. Here are some of the reasons why people use NATs:

As we all know, the firewalling properties of NAT are weak and very easy to replace with a state-of-the-art stateful firewall. NAT was not designed to serve as a firewall, after all. Address amplification is no longer an issue with IPv6, since it was developed to do just that. To keep the internal address space stable, we don’t have to use NAT; we can use ULAs (RFC 4193 and RFC 4864).

IPv6 was developed to restore the end-to-end connectivity in the Internet, and the IPv6 world should not use NATs anymore. Avoiding NATs will solve many current issues with applications that require end-to-end connectivity and security (IPsec, Voice over IP, and many others). The percentage of our IT costs that we use to maintain, extend, bypass, and troubleshoot NATs is very high, and if we create NAT-free IPv6 networks, our administrative overhead will significantly decrease, and it will be much easier to create mobile and secure networks.

However, one reason why we will not completely get around using some type of NATs is that it took far too long to introduce IPv6. Originally, the developers planned for IPv6 to be integrated while we still had enough IPv4 address space. This would have allowed for the easy-to-implement dual-stacked approach in most cases.

Now, since the IANA pool is definitely empty and the RIR pools will be exhausted over the course of 2011, all Internet growth will be over IPv6. There are two ways of doing this: a) carriers may use large-scale NAT (LSN) to provide IPv4 access to more and more users and b) use some form of translation to provide IPv4 access to IPv6-only users. The downside of the LSN approach is, that once the NAT moves from the edge (home user) to the carrier, many users/organizations will hide behind one IP address, which is not only a performance hit, but maybe even more importantly a security threat (an attack on that IP address will affect a large number of users) and prevent the use of IP-based access control lists, to for instance block addresses that are known to send SPAM. At the same time it is also a limitation to customized marketing and personalized website content display, because all these users coming from one ISP NAT will appear to be coming from one IP address, so all statistical and analytical tools cannot provide more specific information on user behavior. The positive effect of this situation is that for all these users with translation and sitting behind LSN, native IPv6 Internet access will be performing much better, which may be an incentive for content providers to move their content to IPv6.

For a more detailed discussion of NAT, refer to Chapter 3.

The introduction of IPv6 will cost money. The evolution of our networks always created cost, cost that returns in the form of enabling successful business, efficient communication practices and state-of-the-art applications. This chapter outlined the requirements for a successful planning process. Planning with care and taking the time to tackle all these complex questions is a lot of initial work but it is an important long term gain, because it will create many opportunities to redesign our networks and save a lot of operational cost in the future by enabling an efficient infrastructure.