Known Issues With 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 (BugID 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 work arounds are available for Bug 4709338.

• Add the 2002::/16 static route to the routing tables of all intra-site 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 (BugID 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 with the same tunnel source address.

Other Transition Mechanisms

The mechanisms that were specified previously handle interoperability between dual nodes and IPv4 nodes, if the dual nodes have an IPv4 address. The mechanisms do not handle interoperability between IPv6-only nodes and IPv4-only nodes. Also, the mechanisms do not handle interoperability between dual nodes that have no IPv4 address and IPv4-only nodes. Most implementations can be made dual. However, a dual implementation requires enough IPv4 address space to assign one address for every node that needs to interoperate with IPv4-only nodes.

Several possibilities enable you to accomplish this interoperability without requiring any new transition mechanisms.

• Use application layer gateways (ALG) that sit at the boundary between the IPv6-only nodes and the remainder of the Internet. Examples of ALGs in use today are HTTP proxies and mail relays.

• Companies are already selling network address translators (NAT) boxes for IPv4. The NAT boxes translate between the private IP addresses, for example, network 10--see RFC 1918, on the inside and other IP addresses on the outside. These companies will likely upgrade their NAT boxes to also support IPv6-to-IPv4 address translation.

Unfortunately, both ALG and NAT solutions create single points of failure. By using these solutions, the Internet becomes less effective. The IETF is working on a better solution for IPv6-only interoperability with IPv4-only nodes. One proposal is to use header translators with a way to allocate IPv4-compatible addresses on demand. Another proposal is to allocate IPv4-compatible addresses on demand and use IPv4 in IPv6 tunneling to bridge the IPv6-only routers.

The stateless header translator translates between IPv4 and IPv6 header formats if the IPv6 addresses in use can be represented as IPv4 addresses. The addresses must be IPv4-compatible. Or, the addresses must be IPv4-mapped addresses. The support for these translators has been built into the IPv6 protocol. The translation can occur without any information loss, except for encrypted packets. Rarely used features such as source routing can produce information loss.