The Solaris operating system includes 6to4 as a preferred interim method for making the transition from IPv4 to IPv6 addressing. 6to4 enables isolated IPv6 sites to communicate across an automatic tunnel over an IPv4 network that does not support IPv6. To use 6to4 tunnels, you must configure a boundary router on your IPv6 network as one endpoint of the 6to4 automatic tunnel. Thereafter, the 6to4 router can participate in a tunnel to another 6to4 site, or, if required, to a native IPv6, non-6to4 site.
This section provides reference materials on the following 6to4 subjects:
Topology of the 6to4 tunnel
6to4 addressing, including the format of the advertisement
Description of packet flow across a 6to4 tunnel
Topology of a tunnel between a 6to4 router and 6to4 relay router
Points to consider before you configure 6to4 relay router support.
More information about 6to4 routing is available from the following sources.
Task or Detail |
For Information |
---|---|
Overview of 6to4 routing | |
Tasks for configuring a 6to4 site | |
6to4 related RFC, “Connection of IPv6 Domains via IPv4 Clouds” | |
Detailed information about the 6to4relay command, which enables support for tunnels to a 6to4 relay router |
6to4relay(1M) man page |
6to4 security issues Internet Draft, “Security Considerations for 6to4” |
The following figure shows a 6to4 tunnel between two 6to4 sites.
The figure depicts two isolated 6to4 networks, Site A and Site B. Each site has configured a router with an external connection to an IPv4 network. In the figure, a 6to4 tunnel across the IPv4 network connects the 6to4 sites.
Before an IPv6 site can become a 6to4 site, you must configure at least one router interface for 6to4 support. This interface must provide the external connection to the IPv4 network. The address that you configure on qfe0 must be globally unique. In the previous figure, boundary Router A's interface qfe0 connects Site A to the IPv4 network. Interface qfe0 must already be configured with an IPv4 address before you can configure qfe0 as a 6to4 pseudo-interface.
In the figure, 6to4 Site A is composed of two subnets, which are connected to interfaces hme0 and hme1 on Router A. All IPv6 hosts on either subnet of Site A automatically reconfigure with 6to4–derived addresses on receipt of the advertisement from Router A.
Site B is the opposite endpoint of the tunnel from Site A. To correctly receive traffic from Site A, a boundary router on Site B must be configured for 6to4 support. Otherwise, packets that the router receives from Site A are not recognized and dropped.
As with native IPv6 routers, you must advertise the subnet prefixes derived from the site 6to4 prefix in /etc/inet/ndpd.conf. The next figure shows the parts of a prefix for a 6to4 site, as described in 6to4 Prefix Format and 6to4 Advertisement Example.
The next figure shows the parts of a subnet prefix for a 6to4 site, such as you would include in the ndpd.conf file.
The format line in the previous figure contains the following parts.
Part |
Length |
Definition |
---|---|---|
Prefix |
16 bits |
6to4 prefix 2002 (0x2002). |
IPv4 address |
32 bits |
Unique IPv4 address that is already configured on the 6to4 interface. For the advertisement, you specify the hexadecimal representation of the IPv4 address, rather than the IPv4 dotted–decimal representation. |
Subnet ID |
16 bits |
Subnet ID, which must be a value that is unique for the link at your 6to4 site. |
The example in the previous figure has the following values.
Advertisement Part |
Corresponding Value |
---|---|
6to4 prefix |
2002 |
IPv4 address |
8192:56bb, which corresponds to IPv4 address 129.146.87.188 |
Subnet ID |
1 |
/64 |
Length of prefix |
When an IPv6 host receives the 6to4–derived prefix by way of a router advertisement, the host automatically reconfigures a 6to4–derived address on an interface. The address has the following form.
prefix:IPv4 address:subnet ID:host ID/64 |
The results of ifconfig –a on a host with a 6to4 interface might resemble the following:
qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 7 inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 |
The 6to4–derived address follows inet6 in the output from ifconfig.
Address Part |
Corresponding Value |
---|---|
Prefix |
2002, which is the 6to4 prefix |
IPv4 value |
8192:56bb, which is the IPv4 address, in hexadecimal notation, for the 6to4 pseudo-interface that is configured on the 6to4 router |
subnet ID |
9258, which is the address of the subnet of which this host is a member |
MAC address |
a00:20ff:fea9:4521, which is the link layer address of the host interface that is now configured for 6to4 |
This section describes the path of packets from a host at one 6to4 site to a host in a remote 6to4 site. The next scenario uses the topology that is shown in Figure 4–3 as its example. Moreover, the scenario assumes that the 6to4 routers and 6to4 hosts are already configured.
A host on Subnet 1 of 6to4 Site A sends a transmission, with a host at 6to4 Site B as the destination. Each packet header in the flow has a source 6to4–derived address and destination 6to4– derived address.
6to4 Router A receives the outgoing packets and creates a tunnel over an IPv4 network to 6to4 Site B.
Site A's router encapsulates each 6to4 packet into an IPv4 header. Then the router uses standard IPv4 routing procedures to forward the packet over the IPv4 network.
Any IPv4 routers that the packets encounter use the packets' destination IPv4 address for forwarding. This address is the globally unique IPv4 address of the interface on Router B, which also serves as the 6to4 pseudo-interface.
Packets from Site A arrive at Router B, which decapsulates the IPv6 packets from the IPv4 header.
Router B then uses the destination address in the IPv6 packet to forward the packets to the recipient host at Site B.
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.
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.
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.
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.
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.
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.
The physically closest anycast 6to4 relay router to Site A retrieves the packets that are destined for the 192.88.99.1 anycast group.
The relay router decapsulates the IPv4 header from the 6to4 packets, revealing the native IPv6 destination address.
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.
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.
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
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.
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.
Do not configure a 6to4 tunnel and an automatic tunnel with the same tunnel source address.