"I don’t gain anything whit implementing IPv6, it only increases costs"

This argument is related to the (lack of a) IPv6 business case. It is assumed that the introduction of IPv6 will require extra investments. This will in most cases be true: at least someone has to determine the impact of the introduction of IPv6. But the costs can often be minimized by doing IPv6 investments concurrently with the introduction of new network devices and service platforms. As far as revenues are concerned: not be able to deliver IPv6 on time, may lead to missed opportunities, missing potential revenues.

"Is there a roadmap/guideline for that?"

The difficulty of the migration depends on the complexity of ICT infrastructure that needs to be migrated. Basically, a company does not need to know how to deal with the migration, but it should acknowledge the need for a roadmap and know where to look for it. The first step in IPv6 migration is not the migration itself but the decision to start making a roadmap for the migration. A company may choose to either educate their own people or hire external architects and engineers. It is expected that over time migration will become easier.

"When I implement IPv6 in a customer’s network, the network might fail more often than my regular IPv4 implementations. Why should I get myself into these troubles?"

While it is true that there is still far less experience with running IPv6 networks, and IPv6 functionality of network devices might be less mature than IPv4, the assumption that IPv6 networks are less reliable than IPv4 networks is not proven. Timing is very important here, as is knowledge of which products and migration strategies are reliable and which are not.

"I hear people say that Network Address Translation (NAT, RFC 2663) will do the trick. In that case I can keep my current addresses and network infrastructure."

Is NAT cascading, or Carrier Grade NAT (CGN), an alternative for IPv6? NAT does prolong the lifetime of current IPv4 networks, but has issues with accessibility (the end-to-end principle) and scalability (the number of concurrent sessions is limited).  CGN will provide a short-term solution for ISPs who are not IPv6-ready on time. However their total amount of investments will increase, since they will have to move towards IPv6 anyway later on.

"In IPv6 there is no NAT; therefore an IPv6-network will never be as secure as my IPv4 network. I don’t want my security risk to increase!"

NAT hides the network topology behind the device to the global network. In some cases this indeed contributes to security, but NAT was never intended to be a security measure. The idea of NAT as a security measure is fed by the issue that NAT devices are often running a firewall. Just using firewalls - without NAT – is possible in IPv6 as well as in IPv4. It should be noted that NAT causes many problems with protocols that have IP addresses embedded in their traffic (e.g. FTP) and this may even complicate security-management.

"So I will hold out with my current IPv4 with NAT until a better solution is available."

This bottleneck is based on the belief that IPv6 is not the right solution. This is not a common opinion but the opinion of some corner-visionaries. IPv6 is not always seen as the “ultimate solution”, but is seen as one of the steps that will happen or is needed. It should be pointed out that society will be running out of IPv4 addresses in a few years already, and a new solution other than IPv6 cannot be designed, built and deployed in such a short time frame.

"So it is too early to adopt IPv6."

This argument is correct as far as translation is concerned. However, translation is not the only transition technology available, and translation will probably only be necessary when your IPv4 addresses actually have run out. So translation technology is not needed yet, and this is not a valid argument for not moving towards IPv6. However, if standardization of translation technology does not move on quickly, it may become a bottleneck for IPv6 transition in one or two years.

Many customers/companies depend on their ISP for Internet connectivity. This is a serious argument. Of course one option may be to switch to another ISP, but that is not always favoured, e.g. when the contract limits the possibilities, or switching to another ISP requires renumbering of the network. It would be good if ISPs would publish their IPv6 roadmaps. Companies would then be able to line up their IPv6 migration plans against that roadmap.

"Typing IPv6 addresses is much more error-prone than entering IPv4 addresses. This will lead to configuration mistakes and vulnerabilities in routing and security policies."

This argument seems to be a minor issue and probably does not really hold back the introduction of IPv6. But it is a hurdle that has to be taken. The introduction of IPv6 will surely be accelerated when better tools for entering and manipulating IPv6 addresses come available for network configuration and management. This would also eliminate the perception that “IPv6 is difficult and error prone”. As a comparison, difficult security keys have not stopped the introduction of Wifi, and IPv4 addresses themselves are prone to error also.

This argument seems valid when the company’s network has no shortage in IPv4 addresses. However, this may change if the number of users in the network increases or new services need to be implemented. Also, other services (from potential business partners) might be reachable only by IPv6. Depending on the specific case, this may or may not be an immediate problem for someone running an IPv4-only network. But at some point the IPv6 usage will reach a critical point and IPv6 connectivity will become a must.

"With IPv6 it will be much easier to encrypt traffic, which disables legal intercept."

This bottleneck addresses the property of the IPv6 standard that IPSec should always be part of an IPv6-compliant implementation. Theoretically, a user can enable encryption with just a single mouse-click. The question is whether this will indeed lead to more traffic being encrypted. IPSec can also be used with IPv4 and if a user wants to hide his communications there are other means of encrypting.

"How will my IPv6 network then communicate with IPv4 devices?"

This is a question typically asked by a technician in the act of planning a migration. If an IPv6-only device really needs to talk to an IPv4-only device, translation is inevitable. But often, other migration scenarios are possible (e.g. IPv4 NAT and IPv6 on the same device).

"Security devices (like firewalls, IDS, etc) for the IPv6 world are not available and/or do not offer the same capabilities as their IPv4 functionalities."

This argument addresses the shortage of IPv6-capable hardware and software in the security area. Also, it questions the quality of the IPv6 solutions that are currently available. IPv4 hardware has been around much longer than IPv6-capable hardware, so it can be expected that the IPv4-based hardware is more mature in robustness and functionality.

"IPv6 security is less mature than IPv4, and there is less experience with IPv6 security and reliability issues. So migrating to IPv6 might lower my security and reliability level."

A new technology has the drawback of lacking experience and best practices as far as operation of the technology is concerned. This is also true for IPv6, especially since the IPv6 protocol has more functionality than IPv4, and is therefore more complex. For this reason network operators and technicians need to start experimenting with IPv6 right now. In this way they will gain experience and at least circumvent currently known security pitfalls.

"Running IPv6 next to IPv4 will make my organization vulnerable to the sum of both protocol issues. Also IPv6 might be used to attack IPv4 and vice versa."

By introducing IPv6 in an IPv4 network, an organization also becomes vulnerable to weaknesses in IPv6. Actually, an organization will be more vulnerable than in a network with only IPv4 or IPv6, because one protocol might be used to attack the other. Operating systems such as Windows nowadays are provided with dual stack and IPv6 enabled by default. Therefore, organizations might actually have IPv6 running in their networks already without being aware of this. Security should then be dealt with for both protocols.

"When I access a website on its usual domain name “http://xyz.com”, I am automatically routed to the IPv4 version of the site. To approach the IPv6 version (if it exists), I need to type explicitly “http://ipv6.xyz.com”. This is too cumbersome."

Using ipv6 prefixes was happening often in the earlier days of IPv6. Occasionally those can still be found, but in general the URL of websites is the same regardless of the IP version used for connecting to the website. However, the few cases in which the ipv6 prefix is still present set a bad example for users, so this should be discouraged.

"Almost no websites can be accessed via IPv6, so if I implement IPv6 I can’t even use it to browse the Internet. Then why should I implement it right now?"

It is true that only a small fraction of websites are accessible via IPv6. Currently, about 1% of the world’s top 500 websites can be reached via IPv6 in EU countries, according to our Deployment Monitoring study. People who have ever tried to use IPv6 on their computer might have gained a negative experience with IPv6 because of this lack of content. IPv6 in their eyes performs much worse than IPv4. Extra effort will be needed to convince these people of the opposite.

"Running IPv6 affects the performance of my servers, making it up to 30% slower."

The argument comes from a publication from Gartner (138557). However, the reasoning behind it is not given, and we find this performance difference very unlikely when IPv4 and IPv6 are handled by the router in the same way. Anyway, an organization must always test whether the IPv6 performance of their servers meets the standard set by IPv4. If not, the servers may need to be upgraded or replaced.

"RFC1883 dates from 1995 and since then everybody tells 'we all have to migrate to IPv6'. But for some reason(s) it still has not happened and anno 2009 we still have IPv4 addresses. I do not think it will ever come that far. A 'standard' that after 15 years is still not widely accepted is not going to work…"

This argument addresses scepticism of people regarding the speed at which IPv6 has been introduced so far. This “general feeling” can be addressed by showing the current predictions of the dates that we will be running out of IP addresses. These predictions are scientifically sounder and therefore more reliable than any prediction in earlier times. One should also realize that the main reason why IPv6 is not commonplace today is the fact that everybody is waiting for each other to migrate. Arguments like this maintain the status quo.

"When IPv6 is deployed, an ISP must enable legal interception of IPv6 traffic because of legislation. Since this is an extra investment that may hold back massive uptake of IPv6."

This functionality must be implemented when there is a legal obligation for an ISP to offer interception of network traffic. Therefore, either the manufacturer of the equipment needs to upgrade its equipment to support interception of IPv6, or the ISP must consider using equipment from another manufacturer. This will require investments which may not lead to extra revenues. An ISP may circumvent this requirement by tunneling IPv6 traffic over IPv4.

"There is no demand for IPv6 enabled devices and software, so I don’t need to offer these products on the short term."

This argument indicates the main reasons for vendors not to deliver IPv6 capable products. In fact, both stakeholders (network owners versus vendors) are both waiting for each other to act. The ISP waits for the vendor to offer IPv6-enabled products, while the vendor waits for demand in the market.

"The market of IPv6-capable products is not transparent, so I don’t know which products will work in my situation without experimenting with them."

Many enterprises do not have the time, money or knowledge to decide by extensive experimentations how to migrate towards IPv6 and which products they should buy for this. A lack of easily available transparent information about new products increases the risk of failure of a migration towards IPv6. The market should be (self-)regulated such that it provides the necessary information, in the correct way.