Tunneling IPv6 Packets Over Existing IPv4 Networks

This section explains the rationale of tunneling data over the network. Then it describes how IPv6 packets are tunneled over IPv4 networks. Finally, it presents protocols and mechanisms standardized by the IETF to establish and deploy IPv6-over-IPv4 tunnels between dual-stack nodes.

Why Tunneling?

Tunnels are generally used on the network to carry incompatible protocols or specific data over an existing network. For example, Distance Vector Multicast Routing Protocol (DVMRP) tunnels carry multicast datagrams over unicast networks. IPSec in tunnel mode, Layer 2 Tunneling Protocol (L2TP), and other Virtual Private Network (VPN) mechanisms transfer sensitive data over public IP networks using secure tunneling protocols.

For the deployment of IPv6 in the context of existing IPv4 infrastructure everywhere on the Internet, the tunneling approach provides a basic way for IPv6 hosts or islands made of IPv6 hosts, servers, and routers to reach other IPv6 islands and IPv6 networks using IPv4 routing domains as the transport layer. As illustrated in Figure 5-6, a tunnel is deployed between two islands made up of IPv6 nodes over an IPv4-only network such as the Internet. Edge routers at the border of the IPv6 islands and the Internet can handle the tunneling of IPv6 packets in IPv4.

However, any networks, links, and infrastructure made of native IPv6 connectivity should be preferred before any transition and coexistence strategies such as tunneling mechanisms. In fact, the tunneling of IPv6 packets over IPv4 infrastructure should be considered as an alternative only when it is impossible to get native IPv6 connectivity on networks, links, and infrastructure.

How Does Tunneling IPv6 Packets in IPv4 Work?

When IPv6 packets are tunneled in IPv4, their original header and payload are not modified. One IPv4 header is inserted before the IPv6 packet. Therefore, the inner header contains the source and destination IPv6 addresses of the end-to-end IPv6 session, and the outer header contains the source and destination IPv4 addresses of the tunnel's endpoints. At each side of the tunnel, encapsulation and decapsulation of IPv6 packets are performed. Devices at each side of the tunnel must support both IPv4 and IPv6 protocols (dual stack) to encapsulate and decapsulate IPv6 packets in IPv4.

As shown in Figure 5-7, IPv6 host A, which knows the destination IPv6 address of IPv6 host B, wants to establish an end-to-end IPv6 session to host B. Both IPv6 networks are isolated, but they are connected using an IPv4 network. A tunnel to carry IPv6 packets in IPv4 is deployed between Routers R1 and R2. To initiate the end-to-end session, host A sends the first IPv6 packet, made up of an IPv6 header and a payload, to host B's IPv6 address as the destination address. Because the destination IPv6 host is on a different IPv6 routing domain, the packet is delivered over IPv6 to the border Router R1, acting as the tunnel's entry point. Therefore, Router R1 encapsulates the IPv6 packet in an IPv4 packet by inserting an IPv4 header. Then it sends the IPv4 packet to Router R2 over the IPv4 network. After receiving the IPv4 packet, Router R2, acting as the tunnel's exit point, performs the decapsulation. Then it forwards the IPv6 packet over IPv6 to the destination, host B. You can see that the IPv6 packet's header and payload are not modified during these steps.

Figure 5-7. IPv6 Packets Delivered Through a Tunnel Over IPv4

[View full size image]

As described in RFC 2893, IPv6 Transition Mechanisms, the protocol number assigned to the encapsulation of IPv6 packets in IPv4 is 41. This value is used in the IPv4 header's Protocol Number field to specify the encapsulation of an IPv6 packet in an IPv4 packet.

Like any other tunneling technique, such as IPv4-in-IPv4, minimal encapsulation, and generic routing encapsulation (GRE), the encapsulation of IPv6 packets in IPv4 raises some issues:

• Tunnel Maximum Transmission Unit (MTU) and fragmentation— Because one IPv4 header of 20 octets is inserted before the IPv6 packet, IPv6's effective MTU is decreased by 20 octets. The minimum MTU for any link layer in IPv6, including any tunnel interface, is 1280 octets. Depending on the MTU values configured on IPv6 and IPv4 link layers, fragmentation at the IPv4 layer might occur. This fragmentation affects performance and requires additional processing in the tunnel's endpoints.

• Handling IPv4 Internet Control Message Protocol (ICMPv4) Errors— Many older IPv4 routers return only eight octets of data beyond the packet's IPv4 header in case of error. However, if there is a problem, the IPv6 source node needs to know the address fields of the IPv6 packet in error.

• Filtering Protocol 41— If firewalls and routers with access control lists (ACLs) on IPv4 networks are well-configured, these devices should normally block all IPv4 packets from using protocol 41. This issue is more related to network management, but it affects the deployment of IPv6-over-IPv4 tunnels.

• Network Address Translation (NAT)— Like other tunneling protocols, it is not possible to establish IPv6 in IPv4 tunnels through NAT when it is enabled in the dynamic port translation and port redirection modes. However, this is possible if the tunnel through NAT is enabled in static mode. The issue of dynamic NAT and tunneling IPv6 packets in IPv4 is currently under discussion at the IETF. See the later section “Teredo Tunneling Mechanism.”

Although there are important issues related to the tunneling of IPv6 packets in IPv4, the deployment of the 6bone is proof that tunneling IPv6 packets over the IPv4 infrastructure is acceptable and scalable, provides basic efficiency, and has minimal impacts on network management.

For the transition of IPv4 networks to IPv6, different scenarios exist in which the tunneling of IPv6 packets in IPv4 can be used:

• Host to host— Isolated hosts with a dual stack on an IPv4 network can establish a tunnel to another dual-stack host. This architecture allows only the establishment of end-to-end IPv6 sessions between hosts.

• Host to router— Isolated hosts with a dual stack on an IPv4 network can establish a tunnel to the dual-stack router. The router may have native connectivity on another interface. This architecture allows the establishment of end-to-end IPv6 sessions between any destination IPv6 hosts through the router.

• Router to router— Routers with a dual stack on an IPv4 network can establish a tunnel to another dual-stack router. Routers can be used to interconnect islands of IPv6 hosts. Therefore, any host can establish end-to-end IPv6 sessions between hosts.

In Figure 5-8, example A shows a tunnel deployed between two dual-stack hosts. Example B illustrates a tunnel established between a dual-stack host and a dual-stack router; in this example, the dual-stack router is connected to a native IPv6 network. Finally, example C presents a tunnel established between two dual-stack routers; each dual-stack router is connected to a native IPv6 network.

Deploying Tunnels

The preceding section showed you how tunnels can carry IPv6 packets over an existing IPv4 network when native IPv6 networks or links are unavailable. However, the mechanism used to deploy tunnels between dual-stack nodes is a fundamental functionality that allows a smooth transition from IPv4 networks to IPv6 networks. The IETF defined protocols and techniques for establishing tunnels between dual-stack nodes, especially for the IPv6 protocol. The following is a list of protocols and techniques that are designed for the establishment of tunnels:

• Configured tunnel

• Tunnel broker

• Tunnel server

• 6to4

• GRE tunnel

• ISATAP (Intrasite Automatic Tunnel Addressing Protocol)

• Automatic IPv4-compatible tunnel

This section is organized such that protocols and techniques are presented from the most-prominent to the least-prominent.

Deploying the Configured Tunnel

Configured tunnels are enabled and configured statically on dual-stack nodes. Because the configured tunnel was one of the first transition mechanisms supported by IPv6, it is mostly supported by all IPv6 implementations available today, including the Cisco IOS Software.

On each side of a configured tunnel, IPv4 and IPv6 addresses must be assigned manually to configure the tunnel interface. The following addresses are assigned to the tunnel interface:

• Local IPv4 address— An IPv4 address by which the local dual-stack node can be reached over the IPv4 network. The local IPv4 address is used as the source IPv4 address for outbound traffic.

• Far-end IPv4 address— An IPv4 address by which the far-end dual-stack node can be reached over the IPv4 network. The far-end IPv4 address is used as the destination IPv4 for outbound traffic.

• Local IPv6 address— The IPv6 address is assigned locally to the tunnel interface.

As shown in Figure 5-9, IPv6 network A, represented by the aggregatable global unicast prefix 3ffe:b00:ffff::/48, and IPv6 network B, using the address space 2001:420:ffff::/48, are connected through a configured tunnel. The IPv4 address assigned to the configured tunnel interface on Router R1 is 206.123.31.200, and the IPv6 address assigned to the same interface on this router is 3ffe:b00:ffff:2::1/64. Router R2 uses 132.214.1.10 as the IPv4 address assigned to its configured tunnel interface, and 3ffe:b00:ffff:2::2/64 is the IPv6 address applied. The IPv6 addresses assigned to both ends of the configured tunnel are within the same subnet (the same /64 prefix).

Figure 5-9. Addresses Assigned to a Configured Tunnel Interface

[View full size image]

After all the addresses of the configured tunnel interface are assigned, the IPv6 routing must be configured properly to enable the forwarding of IPv6 packets between the two IPv6 networks. However, the configured tunnel can be used only after the configuration is fully applied on both sides. Note that the configured tunnel is of interest to organizations that require strict control over the establishment of tunnels, for the following reasons:

• Because the source and destination IPv4 addresses of each configured tunnel are well-known, security rules in firewalls or ACLs in routers may be enabled. However, for some tunneling mechanisms, such as the 6to4 tunnel (discussed later in this chapter), tunnel control is restrictive.

• When multiple configured tunnels are deployed, the network staff may disable a configured tunnel at any time just by shutting down a tunnel interface. This action affects only the traffic on that tunnel interface.

Enabling Configured Tunnels on Cisco

Table 5-1 presents the steps and parameters required to enable a configured tunnel on a Cisco router.

Examples 5-2 and 5-3 are related to Figure 5-9. They show the commands and parameters used on Routers R1 and R2 to establish a configured tunnel.

Example 5-2. Enabling a Configured Tunnel on Router R1

RouterR1#configure terminal
RouterR1(config)#int tunnel0
RouterR1(config-if)#ipv6 address 3ffe:b00:ffff:2::1/64
RouterR1(config-if)#tunnel source 206.123.31.200
RouterR1(config-if)#tunnel destination 132.214.1.10
RouterR1(config-if)#tunnel mode ipv6ip
RouterR2(config-if)#exit
RouterR2(config)#ipv6 route 2001:420:ffff::/48 tunnel0
								

Example 5-3. Enabling a Configured Tunnel on Router R2

RouterR2#configure terminal
RouterR2(config)#int tunnel5
RouterR2(config-if)#ipv6 address 3ffe:b00:ffff:2::2/64
RouterR2(config-if)#tunnel source 132.214.1.10
RouterR2(config-if)#tunnel destination 206.123.31.200
RouterR2(config-if)#tunnel mode ipv6ip
RouterR2(config-if)#exit
RouterR2(config)#ipv6 route 3ffe:b00:ffff::/48 tunnel5
								

Displaying the Configured Tunnel Interface

You can use the show ipv6 interface command to display information about the router's tunnel interface. Example 5-4 shows the command show ipv6 interface tunnel0 applied on Router R1. The low-order 64-bit of the link-local address is the IPv4 source address of the tunnel interface converted into hexadecimal. In the following example, CE7B:1FC8 is equivalent to the IPv4 source address 206.123.31.200 assigned to the tunnel interface. The aggregatable global unicast IPv6 address assigned is 3ffe:b00:ffff:2::1. The interface automatically joins several multicast assigned addresses such as FF02::1, FF02::2, FF02::1:FF00:1, and FF02::1:FFA8:147. Refer to Chapter 2 for detailed information about multicast assigned addresses on interfaces.

Example 5-4. Displaying the Configured Tunnel Interface Using the show ipv6 interface tunnel0 Command

RouterR1#show ipv6 interface tunnel0
Tunnel0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::CE7B:1FC8
  Global unicast address(es):
    3FFE:B00:FFFF:2::1, subnet is 3FFE:B00:FFFF:2::/64
  Joined group address(es):
    FF02::1
									FF02::2
									FF02::1:FF00:1
									FF02::1:FFA8:147
  MTU is 1480 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds
  Hosts use stateless autoconfig for addresses.

Tunnel Brokers

As you saw in the preceding section, establishing a configured tunnel between two dual-stack nodes requires manual configuration at both endpoints. Therefore, the configured tunnel mechanism is not scalable when managed statically.

To facilitate the deployment of configured tunnels over an IPv4 network, the IETF defined a mechanism called the tunnel broker. As defined in RFC 3053, IPv6 Tunnel Broker, the tunnel broker is an external system, rather than a router, that acts as a server on the IPv4 network and that receives requests for tunneling from dual-stack nodes. Basically, requests are sent over IPv4 by dual-stack nodes to the tunnel broker using HTTP. End users can fill a webpage to request a configured tunnel for their dual-stack nodes.

Then the tunnel broker sends back information over HTTP to the dual-stack nodes such as the IPv4 addresses, the IPv6 addresses, and the default IPv6 routes to apply for the establishment of a configured tunnel to a dual-stack router. A tunnel broker may optionally provide a script to the dual nodes to facilitate the configured tunnel configuration on the operating system.

Finally, the tunnel broker remotely applies commands on a dual-stack router to enable a configured tunnel. The dual-stack router must be connected to an IPv6 domain. In the tunnel broker specification, the tunnel broker and the dual-stack router use different IPv4 addresses.

As shown in Figure 5-10, a dual-stack host on an IPv4 network first, over IPv4, reaches the tunnel broker using HTTP. The end user fills a web page, and then he gets IPv4 and IPv6 addresses from the tunnel broker through HTTP. The end user applies the configuration obtained to his dual-stack host to enable a configured tunnel. Simultaneously, the tunnel broker automatically applies the far-end configuration of the configured tunnel on a dual-stack router connected to an IPv6 domain. As soon as the configuration is applied on the dual-stack host and on the dual-stack router, the configured tunnel is properly established and can be used to realize end-to-end IPv6 sessions over an IPv4 network.

Figure 5-10. Dual-Stack Host Establishing a Configured Tunnel Using a Tunnel Broker

[View full size image]

The tunnel broker model assumes that both the dual-stack router and the tunnel broker are controlled by the same authority. To be able to control the router's configuration, the tunnel broker may be physically connected to the router's console port, or it can reach the management console through protocols such as Telnet or Secure Shell (SSH). This also means that the tunnel broker must have the rights and permissions to manage the dual-stack router securely.

Tunnel Servers

The tunnel server is a simplified model of the tunnel broker. The tunnel server combines the broker and the dual-stack router in the same system rather than having two separate systems. The way to request a configured tunnel is generally the same as with the tunnel broker: HTTP over IPv4.

As illustrated in Figure 5-11, a dual-stack host on an IPv4 network first, over IPv4, reaches the tunnel server using HTTP. The end user fills a web page and then gets IPv4 and IPv6 addresses from the tunnel server. The end user applies the configuration obtained to his dual-stack host to enable a configured tunnel. Then the tunnel server locally applies the far-end configuration of the configured tunnel. Finally, as with the tunnel broker, as soon as the configuration is fully applied on the dual-stack host and on the tunnel server, the configured tunnel is properly established and can be used to realize end-to-end IPv6 sessions over an IPv4 network.

Figure 5-11. Dual-Stack Host Establishing a Configured Tunnel Using a Tunnel Server

[View full size image]

Because the broker and the dual-stack router are within the same device (a single system), the tunnel server is considered an open model that may allow the development of new control and signaling protocols for the establishment of configured tunnels. A signaling protocol with a built-in tunnel server would provide much more flexibility than a tunnel broker for the deployment of IPv6 connectivity on a very large scale over existing IPv4 networks. For example, a signaling protocol may allow the deployment of IPv6 in IPv4 tunnels through IPv4 NAT. Deploying IPv6 in IPv4 tunnels through NAT is difficult with the tunnel broker model.

The tunnel broker and tunnel server are seen as mechanisms to automate the deployment of configured tunnels for dual-stack nodes on IPv4 routing domains without manual operation.

Deploying 6to4

Establishing, operating, managing, and supporting configured tunnels between IPv6 domains requires synchronization between at least two entities. For some organizations, it is acceptable to statically manage a few tunnels, but for others, this is troublesome and is not a recommended practice. The IETF has defined another mechanism called 6to4 to facilitate the deployment of IPv6 over IPv4 networks through tunnels.

As defined in RFC 3056, Connection of IPv6 Domains via IPv4 Clouds, here are the main characteristics of the 6to4 mechanism:

• Automatic tunneling— A dynamic method to deploy tunnels between sites made up of IPv6 nodes. You don't need to manually preset source and destination IPv4 addresses to establish tunnels. Tunneling of IPv6 packets between 6to4 sites is done dynamically according to the destination IPv6 addresses of packets originating from IPv6 nodes on 6to4 sites. Like the configured tunnel, 6to4 encapsulates IPv6 packets in IPv4 and uses the IPv4 routing domains as the transport layer.

• Enabled at the edge of the site— 6to4 should be enabled in border routers at the edge of sites. 6to4 routers must be able to reach other 6to4 sites and 6to4 routers using the IPv4 routing infrastructure.

• Automatic prefix assignment— Provides one aggregatable global unicast IPv6 prefix to each 6to4 site:

  - 6to4 prefixes are all based on the 2002::/16 address space assigned by the IANA.

  - Each 6to4 site uses at least one globally unicast IPv4 address assigned on a 6to4 router. This IPv4 32-bit address is converted into hexadecimal format and is appended to the 2002::/16 prefix. The final representation is 2002:ipv4-address::/48.

  - Each 6to4 site gets one /48 prefix based on its globally unicast IPv4 addressing. The next 16-bit of the /48 prefix is available for the subnet assignments within the IPv6 domain behind the 6to4 router. Remember that one /48 prefix contains 65,536 /64 prefixes.

• No IPv6 route propagation— Because the 6to4 prefixes are based on globally unique IPv4 addresses (IPv4 routing domains), there is no need to propagate /48 IPv6 routes between all other 6to4 sites.

Figure 5-12 shows Routers A and B enabled as 6to4 routers. Router A uses 132.214.1.10 as the globally unique IPv4 unicast address for the 6to4 mapping, and Router B uses 206.123.31.200. Therefore, the IPv6 prefix of IPv4/IPv6 site A is 2002:84d6:010a::/48, where 84d6:010a is the hexadecimal representation of 132.214.1.10. IPv4/IPv6 site B uses the prefix 2002:ce7b:1fc8::/48, which is based on the IPv4 address 206.123.31.200. The 6to4 tunnel between Router A and Router B is established only when hosts within site A send IPv6 packets to the destination network 2002:ce7b:1fc8::/48 or hosts within site B send packets to the destination network 2002:84d6:010a::/48.

Figure 5-12. IPv6 Prefixes of the 6to4 Sites Are Based on IPv4 Addresses of the 6to4 Routers

[View full size image]

Figure 5-13 illustrates an end-to-end IPv6 session established between host A using the IPv6 address 2002:84d6:010a:1::1 within site A and host B using 2002:ce7b:1fc8:2::2 within site B. Addresses assigned to hosts A and B are based on each site's 6to4 prefixes. Host A initiates the session to host B by sending an IPv6 packet using 2002:84d6:010a:1::1 as the source IPv6 address and 2002:ce7b:1fc8:2::2 as the destination IPv6 address. The IPv6 packet is delivered natively over IPv6 toward the default Router R1 on site A, which acts as the 6to4 router. Then the 6to4 Router R1 looks at the packet's destination IPv6 address and extracts the IPv4 address embedded in the destination address. Following the extraction, the 6to4 Router R1 encapsulates the IPv6 packet in an IPv4 packet using the IPv4 address extracted as the destination IPv4 address for the endpoint tunnel. This destination IPv4 address represents site B's 6to4 edge Router R2. Therefore, the IPv6 packet is encapsulated in IPv4: The packet's source IPv4 address is 132.214.1.10, and the destination IPv4 address is 206.123.31.200. During the encapsulation, the IPv6 packet remains unchanged. The 6to4 Router R2 receives the IPv4 packet and decapsulates the IPv6 packet. Then Router R2 forwards natively over IPv6 the IPv6 packet toward host B.

Figure 5-13. End-to-End IPv6 Session Between IPv6 Hosts Through 6to4 Routers

[View full size image]

As discussed in this section, the 6to4 operation is based on the IPv4 Internet addressing and routing infrastructure. Therefore, you should take the following into consideration before deploying sites using the 6to4 mechanism:

• The edge router's IPv4 address might change over time— Because a 6to4 site's IPv6 prefix is based on the edge router's globally unique IPv4 unicast address, any change of this IPv4 address forces the renumbering of the whole 6to4 site.

• Private addressing— The use of private address space such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, is forbidden for the deployment of a 6to4 router on the Internet.

• Controlling tunnel establishment— As soon as a 6to4 router is enabled on an edge router, the 6to4 router must accept encapsulated packets from any other 6to4 router on the Internet. Blocking or filtering inbound 6to4 traffic based on source IPv4 addresses breaks the 6to4 model. However, the absence of control for 6to4 tunneling represents a security issue, because malicious users might enable 6to4 sites for short periods of time.

Enabling 6to4 Router Configuration on Cisco

Table 5-2 describes the steps required to enable a 6to4 router. Steps 1 and 2 define the IPv4 address and the 6to4 prefix for the 6to4 site. Steps 3 through 7 set the commands and parameters for the configuration of a 6to4 tunnel. Step 8 enables a route for the forwarding of IPv6 packets using the 6to4 prefix as the destination.

Figure 5-14 shows a typical network topology in which Router R1 acts as the 6to4 router on the Internet. Router R1 can be reached through IPv4 using the address 132.214.1.10. It uses Tunnel1 as an interface for the 6to4 tunneling.

Example 5-5, which is based on Figure 5-14, presents the configuration applied on Router R1 to turn it into a 6to4 router.

Example 5-5. Enabling a 6to4 Router on Router R1

RouterR1#configure terminal
RouterR1(config)#int Loopback0
RouterR1(config-if)#ip address 132.214.1.10 255.255.255.0
RouterR1(config-if)#int fastethernet0/0
RouterR1(config-if)#ipv6 address 2002:84d6:010a:0001::1/64
RouterR1(config-if)#int tunnel1
RouterR1(config-if)#no ip address
RouterR1(config-if)#ipv6 unnumbered fastethernet0/0
RouterR1(config-if)#tunnel source Loopack0
RouterR1(config-if)#tunnel mode ipv6ip 6to4
RouterR1(config-if)#exit
RouterR1(config)#ipv6 route 2002::/16 Tunnel1
								

As soon as 6to4 is applied, you can verify the reachability of another 6to4 destination on the IPv4 Internet. For example, you can try to ping the 6to4 site operated by Microsoft Research at the IPv6 address 2002:836b:4179::836b:4179, as shown in Example 5-6.

Example 5-6. Verifying the Reachability of Another 6to4 Site on the IPv4 Internet

RouterR1#ping ipv6 2002:836b:4179::836b:4179
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:836B:4179::836B:4179, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 124/160/192 ms

Using 6to4 Relay

The 6to4 mechanism enabled on an edge router allows the forwarding of IPv6 packets to any destination within the 2002::/16 prefix over the existing IPv4 infrastructure. However, as seen in Chapter 2, other aggregatable global unicast prefixes are used on the IPv6 Internet such as 2001::/16 (Production IPv6 Internet) and 3ffe::/16 (the 6bone). Therefore, all these prefixes other than 2002::/16 are unreachable unless one of the 6to4 routers on the IPv4 Internet offers to act as a gateway to forward the 6to4 traffic to the IPv6 Internet. A 6to4 router providing traffic forwarding to the IPv6 Internet is called a 6to4 relay. A 6to4 relay is generally at the border of the IPv4 Internet and the IPv6 Internet. On its interface connected to the IPv6 Internet, the 6to4 router advertises the route 2002::/16 as a participant of the IPv6 unicast routing network.

Figure 5-15 shows Router B acting as a 6to4 relay. The Router B configuration is similar to a 6to4 router, except for the routing configuration. Router B gets routes from the IPv6 Internet, and it can forward IPv6 packets received from 6to4 sites (2002::/16 prefix) to the IPv6 Internet. To use a 6to4 relay, a 6to4 router must add a default route in its configuration pointing to the 6to4 relay. Therefore, all non-6to4 traffic is sent to the IPv6 Internet through the 6to4 relay.

Figure 5-15. Router Acting as a 6to4 Relay

[View full size image]

Using a 6to4 Relay in a Cisco Configuration

An additional step is necessary to force the forwarding of all non-6to4 traffic to the IPv6 Internet through a 6to4 relay. The ipv6 route ::/0 command forwards all non-6to4 packets to the IPv6 Internet through a 6to4 relay. The IPv6 address of the 6to4 relay must be specified there. The syntax of the ipv6 route ::/0 command is as follows:

Router(config)#ipv6 route ::/0
									ipv6-address-6to4-relay
								

Figure 5-16 shows Router R2 acting as a 6to4 relay on the IPv4 Internet. Router R2 can be reached on IPv4 using the destination IPv4 address 206.123.31.200, and it has the IPv6 address 2002:ce7b:1fc8:1::1 for the 6to4 relay operation. The 6to4 Router R1 can add a default IPv6 route that points to the 6to4 relay (Router R2) to forward non-6to4 traffic to the IPv6 Internet.

Figure 5-16. Router Acting as a 6to4 Relay

[View full size image]

Example 5-7 is based on Figure 5-16. It presents the configuration applied on Router R1 to turn this router into a 6to4 router with a default IPv6 route that points to a 6to4 relay. The shaded line is the default IPv6 route that points to the 6to4 relay.

Example 5-7. Enabling a 6to4 Router on Router R1 with a Default Route to a 6to4 Relay

RouterR1#configure terminal
RouterR1(config)#int Loopback0
RouterR1(config-if)#ip address 132.214.1.10 255.255.255.0
RouterR1(config-if)#int fastethernet0/0
RouterR1(config-if)#ipv6 address 2002:84d6:010a:0001::/64 eui-64
RouterR1(config-if)#int tunnel1
RouterR1(config-if)#no ip address
RouterR1(config-if)#ipv6 unnumbered fastethernet0/0
RouterR1(config-if)#tunnel source Loopack0
RouterR1(config-if)#tunnel mode ipv6ip 6to4
RouterR1(config-if)#exit
RouterR1(config)#ipv6 route 2002::/16 Tunnel1
									RouterR1(config)#ipv6 route ::/0 2002:ce7b:1fc8:1::1
								

Finding a 6to4 Relay on the Internet

The first step before enabling a default route to the IPv6 Internet through a 6to4 relay is to find the IPv4 address of a public 6to4 relay. There are people on the Internet who maintain static lists of public 6to4 relays. Table 5-3 is a sample of some available public 6to4 relays.

As shown in Table 5-3, a publicly available 6to4 relay is a long distance from your site, resulting in poor network performance for the IPv6 traffic between your site and the IPv6 Internet.

To help 6to4 sites find an available 6to4 relay on the Internet and to add more scalability to the 6to4 mechanism, RFC 3068, An Anycast Prefix for 6to4 Relay Routers, introduces a 6to4 relay anycast prefix from which 6to4 packets are automatically routed to the nearest 6to4 relay on the IPv4 Internet.

IANA assigned the 6to4 relay anycast prefix 192.88.99.0/24 for the specific purpose of automatically routing 6to4 packets to the nearest 6to4 relay. The IPv4 address defined in this anycast prefix to reach the nearest 6to4 relay is 192.88.99.1. Therefore, the representation of this address in IPv6 is 2002:c058:6301::. In your 6to4 configuration, you can use the ipv6 route ::/0 2002:C058:6301:: command to configure the default IPv6 route. After this command is applied in your 6to4 configuration, you can try to ping any IPv6 destination within the aggregatable global unicast IPv6 space (2000::/3).

Configuring a Cisco Router to Act as a 6to4 Relay with the Anycast IPv4 Prefix

The anycast IPv4 prefix is now supported in the Cisco IOS Software technology. Thus, a Cisco router can act as a 6to4 relay with the anycast IPv4 prefix. Example 5-8 presents the configuration applied on Router R3 to make this router into a 6to4 relay. The ipv6 address 2002:c058: 6301::/128 anycast command is the new feature added for the anycast IPv4 prefix. The ip address 132.214.1.10 255.255.255.0 command defines a global unicast IPv4 address on the router for management purpose. The ipv6 address 192.88.99.1 255.255.255.0 secondary command assigns the anycast IPv4 address on the network interface.

Example 5-8. Configuring a 6to4 Relay with the Anycast IPv4 Prefix on Router R3

RouterR3#configure terminal
RouterR3(config-if)#int tunnel1
RouterR3(config-if)#no ip address
RouterR3(config-if)#ipv6 unnumbered fastethernet0/0
RouterR3(config-if)#tunnel source fastethernet0/0
									RouterR3(config-if)#ipv6 address 2002:c058:6301::/128 anycast
RouterR3(config-if)#tunnel mode ipv6ip 6to4
RouterR3(config-if)#int fastethernet0/0
									RouterR3(config-if)#ip address 132.214.1.10 255.255.255.0
									RouterR3(config-if)#ip address 192.88.99.1 255.255.255.0 secondary
RouterR3(config-if)#ipv6 address 2002:84d6:010a:0001::/64 eui-64
RouterR3(config-if)#exit
RouterR3(config)#ipv6 route 2002::/16 Tunnel1
								

Deploying IPv6 Over a GRE Tunnel

The Cisco IOS Software supports the encapsulation of IPv6 packets over GRE tunnels. A GRE tunnel is a well-known standardized tunnel technique that can ensure stable and secure point-to-point links. Like the configured tunnel, a GRE tunnel must be configured statically between routers to allow the transport of IPv6 packets over an existing IPv4 infrastructure.

However, the GRE tunnel provides an additional benefit for organizations using IS-IS for IPv6 as the routing protocol in their domain. Because the IS-IS protocol needs to send link layer messages between adjacent routers on the network, GRE tunneling is the only tunneling protocol that can carry this kind of traffic over an IP infrastructure. Therefore, the same GRE tunnel can be used simultaneously within a wide network to carry both IPv6 packets and IS-IS link layer messages between IS-IS routers.

Enabling a GRE Tunnel for IPv6 on a Cisco Router

Table 5-4 presents the steps required to enable a GRE tunnel on a Cisco router to carry IPv6 packets over IPv4. Steps 1 through 5 describe the commands and parameters used to configure a GRE tunnel for IPv6.

Example 5-9 shows the commands and parameters to be applied on a router to configure a GRE tunnel supporting the encapsulation of IPv6 packets.

Example 5-9. Configuring a GRE Tunnel on Router R1

RouterR1#configure terminal
RouterR1(config)#int tunnel0
RouterR1(config-if)#ipv6 address 3ffe:b00:ffff:2::1/64
RouterR1(config-if)#tunnel source 206.123.31.200
RouterR1(config-if)#tunnel destination 132.214.1.10
RouterR1(config-if)#tunnel mode gre ipv6
RouterR2(config-if)#exit
								

Deploying ISATAP Tunnels

Intrasite Automatic Tunnel Addressing Protocol (ISATAP), defined in draft-ietf-ngtrans-isatap-12.txt, is a mechanism that tunnels IPv6 packets in IPv4 within an administrative domain (such as a site) to create a virtual IPv6 network over an IPv4 network.

The main functionalities and components of ISATAP are as follows:

• Automatic tunneling— The tunneling of IPv6 packets in IPv4 is performed between ISATAP hosts or between an ISATAP host and an ISATAP router. The tunneling is automatic, meaning that there is no need to apply manual configurations on hosts when ISATAP support is enabled. However, for ISATAP host-to-ISATAP router tunneling, the ISATAP host must initially find the IPv4 address of an ISATAP router from the Potential Router List.

  NOTE

  On an ISATAP link, a Potential Router List contains IPv4 addresses representing all ISATAP routers within a site. The ISATAP draft proposes to get the Potential Router List from the naming service as a bootstrap for ISATAP host-to-ISATAP router tunneling.

  
  

• ISATAP address format— ISATAP addresses assigned to ISATAP hosts and ISATAP routers are made using the concatenation of an aggregatable global unicast IPv6 prefix dedicated to the ISATAP operation and the special format of the interface ID.

• Prefix— Represents the high-order 64-bit of the IPv6 address. One ISATAP address is enabled on the ISATAP host using the link-local prefix (FE80::/10). One aggregatable global or site-local /64 prefix must be assigned for the ISATAP operation within the site. This /64 prefix is received by the ISATAP hosts from router advertisement messages sent by ISATAP routers through ISATAP tunnels established over IPv4.

• Interface ID— Represents the low-order 64-bit of the IPv6 address assigned to the ISATAP host. Like the 6to4 mechanism, ISATAP embeds IPv4 addresses in ISATAP IPv6 addresses. The interface ID is made by appending the 32-bit of the IPv4 address to the high-order 32-bit value 0000:5EFE, which has been reserved by IANA for ISATAP operation. Because ISATAP operation is scoped to a site, IPv4 addresses used by ISATAP hosts and routers may be either public or private addressing.

As illustrated in Figure 5-17, ISATAP host A on the IPv4 network having the IPv4 address 206.123.20.100 uses the link-local address fe80::5efe:ce7b:1464. This link-local address is based on the ISATAP format. ISATAP host A also has the aggregatable global unicast IPv6 address 3ffe:b00:ffff:2::5efe:ce7b:1464 assigned. The low-order 64-bit of this aggregatable global unicast address is the same as the link-local address. ISATAP host A receives the ISATAP prefix 3ffe:b00:ffff:2::/64 from ISATAP Router R1. When ISATAP host A has to send IPv6 packets to ISATAP Router R1 at 3ffe:b00:ffff:2::5efe:ce7b:1fc8, host A's ISATAP interface automatically encapsulates IPv6 packets in IPv4. The IPv4 packets of the IPv6 encapsulated packet use 206.123.20.100 as the source IPv4 address and 206.123.31.200 as the destination IPv4 address.

• ISATAP prefix advertisement— After the ISATAP host is enabled with its link-local address using ISATAP format in the low-order 64-bit, it sends a router solicitation to an ISATAP router through an ISATAP tunnel. Then the ISATAP router replies with a router advertisement message to the ISATAP host, and it specifies the ISATAP prefix defined within the site. After receiving the ISATAP prefix, the ISATAP host configures its aggregatable global unicast IPv6 address based on this ISATAP format. The ISATAP host uses the ISATAP router's link-local address as the default IPv6 router address.

Figure 5-18 shows all the steps by which an ISATAP prefix is advertised to ISATAP hosts over the IPv4 network using the ISATAP mechanism. First, ISATAP host A, using the link-local address fe80::5efe:ce7b:1464, sends a router solicitation to ISATAP Router R1 at destination fe80::5efe:ce7b:1fc8. This IPv6 packet is encapsulated within an IPv4 packet: The source IPv4 address is 206.123.20.100 and the destination IPv4 address is 206.123.31.200. Then ISATAP Router R1 receives this router solicitation. It replies by sending a router advertisement message to ISATAP host A. This IPv6 packet is also encapsulated in an IPv4 packet: The source IPv4 address is now 206.123.31.200, and the destination IPv4 address is 206.123.20.100. The router advertisement message contains the ISATAP prefix 3ffe:b00:ffff:2::/64, which ISATAP host A uses to configure its IPv6 address.

Figure 5-18. Advertisement of the ISATAP Prefix

[View full size image]

Enabling an ISATAP Tunnel on a Cisco Router

Table 5-5 presents the steps required to enable an ISATAP tunnel on a Cisco router. Steps 1 through 6 describe the commands and parameters used to configure the router as an ISATAP router.

Example 5-10 shows the commands and parameters applied on Router R1 to configure it as an ISATAP router.

Example 5-10. Configuring ISATAP on Router R1

RouterR1#configure terminal
RouterR1(config)#int fastethernet0/0
RouterR1(config-if)#ip address 206.123.31.200 255.255.255.0
RouterR1(config-if)#int tunnel0
RouterR1(config-if)#tunnel source fastethernet0/0
RouterR1(config-if)#tunnel mode ipv6ip isatap
RouterR1(config-if)#no ipv6 nd suppress-ra
RouterR1(config-if)#ipv6 address 3ffe:b00:ffff:2::/64 eui-64
RouterR2(config-if)#exit
								

Deploying an Automatic IPv4-Compatible Tunnel

This section describes the automatic IPv4-compatible tunnel as another technique used to carry IPv6 packets over IPv4 networks. However, this tunneling technique is supported less in IPv6 implementations, because it is used less and is deployed on the Internet, unlike the configured tunnel and 6to4 mechanisms.

The automatic IPv4-compatible tunnel mechanism was one of the first transition mechanisms defined by the IETF. The automatic IPv4-compatible tunnel mechanism lets automatic tunnels (no manual configuration) over IPv4 networks carry IPv6 packets between dual-stack hosts only. This mechanism allows isolated IPv6 hosts on IPv4 networks to automatically enable tunnels to other isolated IPv6 hosts on IPv4 networks. The low-order 32-bit of the source and destination IPv6 addresses represents the source and destination IPv4 addresses of the tunnel endpoints. The IPv4-compatible IPv6 prefix is ::/96 (made up of 96 0s).

Figure 5-19 shows Router R1 deploying an automatic IPv4-compatible tunnel to Router R2 over the Internet. Router R1's IPv4 address is 206.123.31.200, and its IPv6 address is ::206.123.31.200. Router R2's IPv4 address is 132.214.1.10, and its IPv6 address is ::132.214.1.10. Suppose Router R1 sends a first IPv6 packet to Router R2 using the source IPv6 address ::206.123.31.200 and the destination ::132.214.1.10. Router R1 dynamically deploys an automatic IPv4-compatible tunnel to Router R2 to carry IPv6 packets over the Internet.

Although the automatic IPv4-compatible tunnel mechanism seems to provide an easy and simple way to deploy tunnels to carry IPv6 packets over IPv4, it has several limitations:

• Homogeneousness— Communications are always realized between IPv4-compatible addresses only. Moreover, the mechanism is limited to host-to-host tunneling. A router may also act as a host for some applications, such as the establishment of a Telnet-over-IPv6 session between two routers.

• Address space limitation— Because this mechanism and tunnel establishment are only based on the hosts' IPv4 addresses, the automatic IPv4-compatible tunnel mechanism does not offer a solution to the IPv4 space shortage.

• Scalability— This mechanism requires one globally unique IPv4 address for each host to allow the deployment of IPv6 at large on the Internet.

Teredo Tunneling Mechanism

Teredo, also known as shipworm, is a new tunneling mechanism being designed at the IETF for the transition from IPv4 to IPv6. Teredo's main goal is to deliver IPv6 packets to dual-stack nodes that are behind NAT devices on IPv4-only domains, because protocol 41 (used by the configured tunnel and 6to4 mechanisms) does not work through NAT. The delivery of IPv6 connectivity through NAT devices is possible with Teredo by tunneling IPv6 packets over IPv4 UDP datagrams. By using the combination of a single IPv4 address and the UDP mappings of a NAT device, Teredo can deliver IPv6 connectivity over IPv4 UDP datagrams to several nodes that are behind the same NAT.

The following list describes the main components of the Teredo mechanism:

• Teredo server— The Teredo server is connected to the IPv4 Internet and can be reached using a single globally unicast IPv4 address. This stateless device manages signalization traffic with the Teredo clients.

• Teredo relay— The Teredo relay is the device acting as an IPv6 router. The Teredo relay is connected to the IPv6 Internet and provides IPv6 connectivity over IPv4 UDP packets to Teredo clients that are behind NAT.

• Teredo client— The Teredo client is located in an IPv4 domain behind the NAT device. In the Teredo model, the Teredo client (which is behind a NAT) must initiate the request to the Teredo server to get IPv6 connectivity over IPv4 UDP packets from the Teredo relay. However, the Teredo client must be configured with the Teredo server's IPv4 address.

Refer to the Internet-draft www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-08.txt for detailed information about this new tunneling mechanism for IPv6.

Choosing an Appropriate Tunneling Mechanism

Although several tunneling mechanisms carry IPv6 packets over the exiting IPv4 infrastructure, you should remember that configured tunnel, 6to4, and GRE tunnel probably will be used to interconnect sites. ISATAP may be used to interconnect hosts to exit routers in an IPv4 domain. Tunnel server and tunnel broker may also be used to deploy IPv6 connectivity on a large scale to isolated nodes that are on IPv4-only domains. Teredo delivers IPv6 connectivity to nodes behind NAT devices. The automatic IPv4-compatible tunnel is not used, because it is being deprecated.