Common Problems When Deploying IPv6

This section describes issues and problems that you might encounter while planning and deploying IPv6 at your site. For actual planning tasks, refer to Chapter 4, Planning an IPv6 Network (Tasks).

IPv4 Router Cannot Be Upgraded to IPv6

If your existing equipment cannot be upgraded, you might have to purchase IPv6-ready equipment. Check the manufacturers' documentation for any equipment-specific procedures you might have to perform to support IPv6.

Certain IPv4 routers cannot be upgraded for IPv6 support. If this situation applies to your topology, physically wire an IPv6 router next to the IPv4 router. Then, you can tunnel from the IPv6 router over the IPv4 router. For tasks for configuring tunnels, refer to Tasks for Configuring Tunnels for IPv6 Support (Task Map).

Problems After Upgrading Services to IPv6

You might encounter the following situations when preparing services for IPv6 support:

Certain applications, even after they are ported to IPv6, do not turn on IPv6 support by default. You might have to configure these applications to turn on IPv6.
A server that runs multiple services, some of which are IPv4 only, and others that are both IPv4 and IPv6, can experience problems. Some clients might need to use both types of services, which leads to confusion on the server side.

Current ISP Does Not Support IPv6

If you want to deploy IPv6 but your current ISP does not offer IPv6 addressing, consider the following alternatives to changing ISPs:

Hire an ISP to provide a second line for IPv6 communications from your site. This solution is expensive.
Get a virtual ISP. A virtual ISP provides your site with IPv6 connectivity but no link. Instead, you create a tunnel from your site, over your IPv4 ISP, to the virtual ISP.
Use a 6to4 tunnel over your ISP to other IPv6 sites. For an address, use the registered IPv4 address of the 6to4 router as the public topology part of the IPv6 address.

Security Issues When Tunneling to a 6to4 Relay Router

By nature, a tunnel between a 6to4 router and a 6to4 relay router is insecure. Security problems, such as the following, are inherent in such a tunnel:

Though 6to4 relay routers do encapsulate and decapsulate packets, these routers do not check the data that is contained within the packets.
Address spoofing is a major issue on tunnels to a 6to4 relay router. For incoming traffic, the 6to4 router is unable to match the IPv4 address of the relay router with the IPv6 address of the source. Therefore, the address of the IPv6 host can easily be spoofed. The address of the 6to4 relay router can also be spoofed.
By default, no trust mechanism exists between 6to4 routers and 6to4 relay routers. Thus, a 6to4 router cannot identify whether the 6to4 relay router is to be trusted, or even if it is a legitimate 6to4 relay router. A trust relationship between the 6to4 site and the IPv6 destination must exist, or both sites leave themselves open to possible attacks.

These problems and other security issues that are inherent with 6to4 relay routers are explained in the Internet Draft, Security Considerations for 6to4. Generally, you should consider enabling support for 6to4 relay routers for the following reasons only:

Your 6to4 site intends to communicate with a private, trusted IPv6 network. For example, you might enable 6to4 relay router support on a campus network that consists of isolated 6to4 sites and native IPv6 sites.
Your 6to4 site has a compelling business reason to communicate with certain native IPv6 hosts.
You have implemented the checks and trust models that are suggested in the Internet Draft, Security Considerations for 6to4.

Known Issues With a 6to4 Router

The following known bugs affect 6to4 configuration:

4709338 – Need a RIPng implementation which recognizes static routes
4152864 – Configuring two tunnels with the same tsrc/tdst pair works

Implementing Static Routes at the 6to4 Site (Bug ID 4709338)

The following issue occurs on 6to4 sites with routers that are internal to the 6to4 boundary router. When you configure the 6to4 pseudo-interface, the static route 2002::/16 is automatically added to the routing table on the 6to4 router. Bug 4709338 describes a limitation in the Solaris RIPng routing protocol that prevents this static route from being advertised to the 6to4 site.

Either of the following workarounds are available for Bug 4709338.

Add the 2002::/16static route to the routing tables of all intrasite routers within the 6to4 site.
Use a routing protocol other than RIPng on the 6to4 site's internal router.

Configuring Tunnels with the Same Source Address (Bug ID 4152864)

Bug ID 4152864 describes problems that occur when two tunnels are configured with the same tunnel source address, which is a serious issue for 6to4 tunnels.

Caution - Do not configure a 6to4 tunnel and an automatic tunnel (atun) with the same tunnel source address. For information about automatics and the atun command, refer to the tun(7M) man page.