Considerations for Tunnels to a 6to4 Relay Router

6to4 relay routers function as endpoints for tunnels from 6to4 routers that need to communicate with native IPv6, non-6to4 networks. Relay routers are essentially bridges between the 6to4 site and native IPv6 sites. Because this solution is very insecure, by default the Solaris operating system does not enable 6to4 relay router support. However, if your site requires such a tunnel, you use the 6to4relay command to enable the following tunneling scenario.

Figure 4–6 Tunnel From a 6to4 Site to a 6to4 Relay Router

In Figure 4–6 , 6to4 Site A needs to communicate with a node at native IPv6 Site B. The figure shows the path of traffic from Site A onto a 6to4 tunnel over an IPv4 network. The tunnel has 6to4 Router A and a 6to4 relay router as its endpoints. Beyond the 6to4 relay router is the IPv6 network, to which IPv6 Site B is connected.

Packet Flow Between a 6to4 Site and Native IPv6 Site

This section describes the flow of packets from a 6to4 site to a native IPv6 site. The text uses the scenario that is shown in Figure 4–6 as an example.

1. A host on 6to4 Site A sends a transmission that specifies as the destination a host at native IPv6 Site B. Each packet header in the flow has a 6to4–derived address as its source address. The destination address is a standard IPv6 address.

2. 6to4 Router A receives the outgoing packets and creates a tunnel over an IPv4 network to a 6to4 relay router.

   6to4 relay routers that are part of the 6to4 relay router anycast group have the address 192.88.99.1. This anycast address is the default address for 6to4 relay routers. If you need to use a specific 6to4 relay router, you can override the default and specify that router's IPv4 address.

3. Site A's 6to4 router encapsulates each packet into a IPv4 header, which has the IPv4 address of the 6to4 relay router as its destination. The 6to4 router uses standard IPv4 routing procedures to forward the packet over the IPv4 network. Any IPv4 routers that the packets encounter forward the packets to the 6to4 relay router.

4. The physically closest anycast 6to4 relay router to Site A retrieves the packets that are destined for the 192.88.99.1 anycast group.

5. The relay router decapsulates the IPv4 header from the 6to4 packets, revealing the native IPv6 destination address.

6. The relay router then sends the now IPv6–only packets onto the IPv6 network, where the packets are ultimately retrieved by a router at Site B. The router then forwards the packets to the destination IPv6 node.

Security Issues for 6to4 Relay Router Support

By nature, a tunnel between a 6to4 router and 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 a legitimate 6to4 relay router. A trust relationship between the 6to4 site and the IPv6 destination must exist, or the both sites leave themselves open to possible attacks.

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

• 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 Internet Draft, Security Considerations for 6to4.