Tunneling, the second method of integrating IPv6 and IPv4 networks, entails encapsulating the IPv6 packets or datagrams and sending them over IPv4 networks. In order to support the different tunneling mechanisms that will be described in this section, edge Cisco IOS routers must have a dual-stack implementation which allows the IPv6 packets to be encapsulated in IPv4 packets and then de-encapsulated at the terminating router. It should be noted that intermediate routers do not need to run IPv6. In other words, these routers would simply be IPv4-only routers. Figure 9-1 illustrates a typical tunneling implementation:
Referencing Figure 9-1, assuming that IPv6 Host # 1 is sending datagrams to IPv6 Host # 2, the following sequence of events occur as those packets transit the network:
- IPv6 Host # 1 sends the IPv6 packets destined to IPv6 Host # 2 to its default gateway, which is router R4. These are native IPv6 packets with IPv6 source and destination addresses included in the header
- Router R4 is a dual-stack router. The LAN interface has been enabled for IPv6, while the WAN interface has been enabled for IPv4. R4 has a tunnel configured between its WAN interface and the WAN interface of router R1, which is also a dual-stack router. Upon receiving the IPv6 packets, R4 encapsulates them in IPv4 packets and forwards them to R2. The destination address for these packets is set to router R1 and the router sets the value of the IPv4 header to 41 to indicate encapsulation of IPv6 packets in IPv4 packets
- R2 receives the IPv4 packets and simply routes or forwards them towards their final destination using the destination address specified in the IPv4 header
- R3 receives the IPv4 packets from R2 and simply forwards them towards their final destination using the destination address specified in the IPv4 packet header
- Router R5, the terminating router and exist point for the tunnel, receives the native IPv4 packets and de-encapsulates them leaving only the IPv6 datagrams. The router then forwards the IPv6 packets to Host # 2.
The encapsulation and de-encapsulation process is transparent to the two hosts as well as to the intermediate routers between the tunnel endpoints. There are several methods that can be used to tunnel IPv6 packets in IPv4 packets. These, which will be described in detail in the following sections, include the following:
- Static (Manually Configured) IPv6 Tunneling
- 6to4 Tunneling
- Automatic IPv4-compatible Tunneling
- ISATAP Tunneling
- Generic Routing Encapsulation Tunneling
Static (Manually Configured) IPv6 Tunneling
Static IPv6-in-IPv4 tunneling requires the static configuration of tunnels on dual-stack devices in order to allow IPv6 packets to be tunneled across the IPv4 network. While the tunnel is assigned an IPv6 address, the tunnel source and destination addresses are configured using the IPv4 addresses of the two end-point routers. The tunnel destination address is the address that in included in the IPv4 packet header, which allows other intermediate devices that are only running IPv4 to know where to send these packets.
Following the configuration of static tunnels, static or dynamic routing protocols can be used to provide reachability to remote IPv6 subnets across the tunnel(s). All the routing protocols described in the previous chapter can be enabled on tunnel interfaces. Similarly, static IPv6 routes can also be configured to point out of tunnel interfaces.
The configuration of static tunnels in Cisco IOS software is a straightforward process. The following section goes through the configuration steps required to create static or manually configured tunnels for encapsulating IPv6 packets within IPv4 packets:
- Configure a static tunnel interface using the interface tunnel [number] global configuration command. The number range will vary depending on the version of Cisco IOS software that the router on which the tunnel is being configured is running
- Assign the static tunnel interface an IPv6 address using the ipv6 address interface configuration command. You can use site local or global Unicast address ranges
- Configure a tunnel source for the static tunnel using the tunnel source [IPv4 address | interface]interface configuration command. This is used as the tunnel source address. All packets sent across this tunnel will have this IPv4 address as the source address included in the IPv4 packet header. This is typically a Loopback interface but can be any interface with a globally routable IPv6 address
- Configure a tunnel destination for the static tunnel using the tunnel destination [IPv4 address] interface configuration command. This is the IPv4 address of the tunnel endpoint, i.e. the far-end side of the tunnel. This address should be the same as the tunnel source address for the tunnel endpoint
- Specify IPv6 as the passenger protocol and IPv4 as both the encapsulation and transport protocol for the manual IPv6 tunnel using the tunnel mode ipv6ip interface configuration command
- Configure either static routes to remote IPv6 subnets across the tunnel interface using the ipv6 route <prefix/length> tunnel <number> global configuration command or enable a dynamic IPv6-capable routing protocol across the static tunnel
The network topology in Figure 9-2 will be used to illustrate the configuration of the different tunneling mechanisms that will be described in this section.
NOTE: The IP addresses of the intermediate routers in this topology are irrelevant. All that is required is IP connectivity between the Loopback0 interfaces of routers R1 and R4
NOTE: Prior to beginning the implementation of manually configured tunnels, a simple ping test should be used to validate Loopback-to-Loopback connectivity between R1 and R4. The ping test, initiated from R1 verifies end to end connectivity between the 2 Loopback interfaces:
| R1#ping 4.4.4.4 source 1.1.1.1 repeat 10Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 4/4/8 ms |
Continuing with the configuration of static or manually configured IPv6 tunneling, and going through the steps described previously, router R1 is configured as follows:
| R1(config)#ipv6 unicast-routing R1(config)#interface tunnel 0 R1(config-if)#ipv6 address fec0:abcd:1234:1::1/64 R1(config-if)#ipv6 enable R1(config-if)#tunnel source loopback 0 R1(config-if)#tunnel destination 4.4.4.4 R1(config-if)#tunnel mode ipv6ip R1(config-if)#exit R1(config)#interface fastethernet 0/0 R1(config-if)#ipv6 address 3fff:abcd:1234:1::1/64 R1(config-if)#ipv6 enable R1(config-if)#exit R1(config)#ipv6 route 3fff:abcd:1234:4::/64 tunnel 0 |
Following the same sequence of steps, router R4 is configured as follows:
| R4(config)#ipv6 unicast-routing R4(config)#interface tunnel 0 R4(config-if)#ipv6 address fec0:abcd:1234:1::4/64 R4(config-if)#ipv6 enable R4(config-if)#tunnel source loopback 0 R4(config-if)#tunnel destination 1.1.1.1 R4(config-if)#tunnel mode ipv6ip R4(config-if)#exit R4(config)#interface fastethernet 0/0 R4(config-if)#ipv6 address 3fff:abcd:1234:4::1/64 R4(config-if)#ipv6 enable R4(config-if)#exit R4(config)#ipv6 route 3fff:abcd:1234:1::/64 tunnel 0 |
Following the configuration of the tunnels, the show interfaces command can be used to verify the status of the tunnel. The output of this command shows the following on R4:
| R4#show interfaces tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 4.4.4.4 (Loopback0), destination 1.1.1.1 Tunnel protocol/transport IPv6/IP Tunnel TTL 255 Fast tunneling enabled Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps)[Truncated Output] |
The output of the show interfaces command prints out the configured tunnel parameters, which include the tunnel source and destination IPv4 addresses as well as encapsulation mode. In addition to this, additional information, such as tunnel bandwidth and MTU is also provided. However, it should be noted that while a value of 1514 is shown for the tunnel MTU, the default MTU value for manually configured tunnels in Cisco IOS software is 1480 bytes. This can be validated using the show ip interfaces command for tunnels configured with an IPv4 address or the show ipv6 interfaces command for those with an IPv6 address. Given that only an IPv6 address is configured on the tunnel interfaces in this example, the show ipv6 interfaces command is used and it shows the following information:
| R4#show ipv6 interface tunnel 0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::404:404 Global unicast address(es): FEC0:ABCD:1234:1::4, subnet is FEC0:ABCD:1234:1::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:4 FF02::1:FF04:404 MTU is 1480 bytes[Truncated Output] |
To verify the operation of the tunnel, you can use a simple ping sourced from the LAN subnet of either router to LAN subnet of the other router as illustrated in the following output:
| R4#ping 3fff:abcd:1234:1::1 source 3fff:abcd:1234:4::4 repeat 10Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 3FFF:ABCD:1234:1::1, timeout is 2 seconds: Packet sent with a source address of 3FFF:ABCD:1234:4::4 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 4/4/8 ms |
6to4 Tunneling
6to4 tunnels are defined in RFC 3056 and are designed to allow IPv6 end sites to access the IPv6 backbone commonly referred to as the 6bone, by tunneling across the IPv4 Internet. The 6bone is simply a worldwide information collaborative IPv6 test bed that is an outgrowth of the IETF IP Next Generation (IPng) project. The IPng designed and created the IPv6 protocol. Unlike static tunnel configuration, 6to4 tunneling has three main characteristics, which make it unique from static tunnel implementation. These characteristics are:
- Automatic or Dynamic Tunneling
- Automatic Prefix Assignment
- There is no IPv6 Route Propagation
6to4 automatic tunneling provides a dynamic method to deploy tunnels between IPv6 sites over IPv4 networks. Unlike with manually configured tunnels, there is no need to manually configure tunnel source and destination addresses to establish the tunnels. Instead, the tunneling of IPv6 packets between 6to4 sites is performed dynamically based on the destination IPv6 address of the packets originated by IPv6 hosts. These packets are then encapsulated in IPv4 and IPv4 routing protocols are used to transport the packets between the source and destination hosts.
Automatic prefix assignment provides a global aggregatable IPv6 prefix to each 6to4 site. This prefix is based on the 2002::/16 prefix assigned by IANA for 6to4 sites. As stated earlier in this section, the tunnel endpoint, or destination is determined by the globally unique IPv4 address embedded in a 6to4 address. This address must be an address that is globally routable. In other words, RFC 191 (private IP addresses) cannot be used for 6to4 tunnels because they are not unique. This 32-bit IPv4 address is converted to Hexadecimal and the final representation is a 48-bit prefix. For example, if the IP address 1.1.1.1 was embedded into the IPv6 6to4 prefix, the final representation would be 2002:0101:0101::/48.
And finally, 6to4 tunneling uses special addresses which are a combination of the unique IPv6 routing prefix 2002::/16 and a globally unique 32-bit IPv4 address. With 6to4 tunneling, the tunnel endpoint (destination) is determined by the globally unique IPv4 address embedded in the 6to4 address. Because 6to4 prefixes are based on unique IPv4 address, the 48-bit IPv6 routes do not need to be propagated between 6to4 sites.
NOTE: It is important to note that these special addresses used in 6to4 tunneling are not the same as the IPv4-compatible IPv6 addresses described in the previous chapter. The IPv4-compatible IPv6 addresses cannot be used for Automatic 6to4 Tunnels.
Because 6to4 tunneling may seem somewhat confusing at first glance, Figure 9-3 will be used to illustrate how this tunneling mechanism works:
Referencing Figure 9-3, and assuming that Host 1 in Site 1 is sending packets to Host 2 in Site 2, the 6to4 tunneling mechanism works in the following manner:
- Host 1 sends an IPv6 packet to Host 2 using an IPv6 source address of 2002:0101.0101::1 and an IPv6 destination address of 2002:0202.0202::2
- The packet is received by router R1, which is the default gateway for Host 1. R1 looks at the packet and extracts the embedded IPv4 address of 02.02.02.02, or simply 2.2.2.2. By doing this, router R1 knows that this packet should be forwarded to router R2. R1 then encapsulates the IPv6 packet(s) in IPv4 packets that contain a source address of 1.1.1.1, which is router R1s unique global IPv4 address and a destination address of 2.2.2.2, which is router R2s unique global IPv4 address. During this process, it is important to know that the source and destination fields in the IPv6 packet(s) remain unchanged. The packet is forwarded to router R2 by intermediate routers
- R2 receives the packet and de-encapsulates it. The IPv6 packet shows a destination address of 2002:0202.0202::2 and so R2 forwards the native IPv6 packet to Host 2
The entire process is transparent to Host 1 and Host 2 and allows the two hosts to establish an end-to-end IPv6 session. Before we discuss the sequence of configuration steps required to implement 6to4 tunneling in Cisco IOS software, it is important to first know the restrictions and considerations to be mindful of when implementing 6to4 tunneling. These include:
- Using Private IP Addresses
- Prefix Renumbering
- Traffic and Protocol Filtering
Because 6to4 tunneling uses globally unique IPv4 addresses, you cannot use RFC 1918 address space or any other subnets, e.g. Martians, which are not permitted on the Internet. Given that the site prefix for 6to4 tunneling is based on the unique global IPv4 address of the edge router, if the edge router IP address is changed, the entire site must be renumbered using the new unique edge router global IP address. And finally, prior to enabling 6to4 tunneling, make sure that protocol and traffic filtering allows protocol 41. Additionally, it should be noted that filtering on inbound source addresses can also break 6to4 tunneling. Consideration should therefore be given to alternative methods of network security if traffic and protocol filtering are not implemented so that 6to4 tunneling works.
The configuration of 6to4 tunneling in Cisco IOS software is somewhat similar to that of static tunnels with the exception that no static tunnel destinations are configured. The following sequence of configuration steps is required to implement 6to4 tunneling in Cisco IOS software:
- Configure an IPv6 address on the internal (inside) 6to4 site interface. This is typically the LAN interface to which IPv6 hosts are connected. This is configured using the ipv6 address [address/prefix-length]interface configuration command. When you configure the site prefix, it must come from the 2002::/16 range
- Configure a static tunnel interface using the interface tunnel [number] global configuration command. The number range will vary depending on the version of Cisco IOS software that the router on which the tunnel is being configured is running
- Configure a tunnel source for the static tunnel using the tunnel source [IPv4 address | interface]interface configuration command. This is used as the tunnel source address. All packets sent across this tunnel will have this IPv4 address as the source address included in the IPv4 packet header. This is typically a Loopback interface but can be any interface with a globally routable IPv4 address
- Configure the tunnel interface as an unnumbered interface that will use the IPv6 address of the inside (internal) 6to4 site interface using the ipv6 unnumbered [interface name] interface configuration command
- Specify IPv6 as the passenger protocol and IPv4 as both the encapsulation and transport protocol for the dynamic IPv6 tunnel and specify 6to4 operation using the tunnel mode ipv6ip 6to4 interface configuration command
- Configure a static route to remote 6to4 IPv6 subnets across the tunnel interface using the ipv6 route <prefix/length> tunnel <number> global configuration command
The same topology used in Figure 9-2, which is shown again below in Figure 9-4 for ease of reading, will be used to illustrate the configuration of 6to4 tunneling in Cisco IOS software between Site 1 (R1) and Site 4 (R4):
Following the sequence of steps described in the previous section, R1 is configured as follows:
| R1(config)#ipv6 unicast-routing R1(config)#interface loopback 0 R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config-if)#exit R1(config)#interface fastethernet 0/0 R1(config-if)#ipv6 address 2002:0101:0101:1111::1/64 R1(config-if)#ipv6 enable R1(config-if)#exit R1(config)#interface tunnel 0 R1(config-if)#ipv6 unnumbered fastethernet 0/0 R1(config-if)#tunnel source loopback 0 R1(config-if)#tunnel mode ipv6ip 6to4 R1(config-if)#exit R1(config)#ipv6 route 2002::/16 tunnel 0 |
Following the same sequence of commands, router R4 is configured as follows:
| R4(config)#ipv6 unicast-routing R4(config)#interface loopback 0 R4(config-if)#ip address 4.4.4.4 255.255.255.255 R4(config-if)#exit R4(config)#interface fastethernet 0/0 R4(config-if)#ipv6 address 2002:0404:0404:4444::4/64 R4(config-if)#ipv6 enable R4(config-if)#exit R4(config)#interface tunnel 0 R4(config-if)#ipv6 unnumbered fastethernet 0/0 R4(config-if)#tunnel source loopback 0 R4(config-if)#tunnel mode ipv6ip 6to4 R4(config-if)#exit R4(config)#ipv6 route 2002::/16 tunnel 0 |
Again, following this configuration, it would be prudent to validate the tunnel state using the show interfacescommand as was shown in the previous configuration example. Additionally, the show ipv6 interfaces command can also be used to verify IPv6 address configuration and other default interface parameters, such as the 1480-byte MTU. However, because the output will be similar to that in the previous example, this verification will be omitted in this section. To verify the operation of the 6to4 tunnel, a simple ping can be used to send LAN-to-LAN packets between the two routers as illustrated in the following output:
| R4#ping 2002:0101:0101:1111::1 source 2002:0404:0404:4444::4 repeat 10Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 2002:101:101:1111::1, timeout is 2 seconds: Packet sent with a source address of 2002:404:404:4444::4 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 4/4/8 ms |
Automatic IPv4-compatible Tunneling
Automatic IPv4-compatible tunnels enable IPv6 hosts to automatically enable tunnels to other IPv6 hosts across an IPv4 network infrastructure. Unlike 6to4 tunneling, automatic IPv4-compatible tunneling does use the IPv4-compatible IPv6 addresses. Automatic IPv4-compatible tunnels use the IPv6 prefix ::/96. To complete the 128-bit IPv6 address, the low order 32-bits are derived from the IPv4 address. These low-order 32-bits of the source and destination IPv6 addresses represent the source and destination IPv4 addresses of the tunnel endpoints in the same manner as the 6to4 tunnels which were described in the previous section. Therefore, with automatic IPv4-compatible tunneling, the host or router at each end of an IPv4-compatible tunnel must support both the IPv4 and IPv6 protocol stacks.
IPv4-compatible tunnels can be configured between border routers or between a border router and a host. While using IPv4-compatible tunnels is an easy method to create tunnels for IPv6 over IPv4, the technique does not scale well for large networks. Automatic IPv4-compatible tunnels are similar to manual IPv6 tunnels with the exception that there is no destination address for the configured Tunnel interface. Instead, the tunnel interface destination address is dynamically assigned from the IPv6 next-hop address of the IPv6 route. This functionality is enabled by using the tunnel mode ipv6ip auto-tunnel interface configuration command on the tunnel interface, as will be illustrated later in this section.
In addition to this, in order to use automatic IPv4-compatible tunneling, you need to specify the next-hop of the IPv6 address by using either an explicit BGP neighbor address for MP-BGP, or an IPv6 static route. While static routes are supported, the recommended method when implementing this tunneling mechanism is to use MP-BGP which was described in the previous chapter and will be used in the following configuration example.
Automatic IPv4-compatible tunneling is considered obsolete, and while still supported in Cisco IOS software, is being deprecated. For this reason, while the explicit tasks required to implement this type of tunneling are excluded from this chapter, the following example shows configurations on two routers that are configured for automatic IPv4-compatible tunneling:
| R1(config-if)#interface fastethernet 0/0 R1(config-if)#ipv6 address 3fff:abcd:1234:1::1/64 R1(config-if)#ipv6 enable R1(config-if)#exit R1(config-if)#interface serial 0/0 R1(config-if)#ip address 111.1.1.1 255.255.255.0 R1(config-if)#exit R1(config)#interface tunnel 0 R1(config-if)#tunnel source serial 0/0 R1(config-if)#tunnel mode ipv6ip auto-tunnel R1(config-if)#exit R1(config)#router bgp 1 R1(config-router)#bgp router-id 1.1.1.1 R1(config-router)#no bgp default ipv4-unicast R1(config-router)#neighbor ::222.2.2.2 remote-as 2 R1(config-router)#address-family ipv6 unicast R1(config-router-af)#neighbor ::222.2.2.2 activate R1(config-router-af)#neighbor ::222.2.2.2 next-hop-self R1(config-router-af)#network 3ffe:abcd:1234:1::/64 R1(config-router-af)#exit R1(config-router)#exit R1(config)#exit |
In a similar manner, the automatic IPv4-compatible tunnel configuration is implemented on router R4 in the following manner:
| R2(config)#interface fastethernet 0/0 R2(config-if)#ipv6 address 3fff:abcd:5678:1::2/64 R2(config-if)#ipv6 enable R2(config-if)#exit R2(config)#interface serial 0/0 R2(config-if)#ip address 222.2.2.2 255.255.255.0 R2(config-if)#ipv6 enable R2(config-if)#exit R2(config)#interface tunnel 0 R2(config-if)#tunnel source serial 0/0 R2(config-if)#tunnel mode ipv6ip auto-tunnel R2(config-if)#exit R2(config)#router bgp 2 R2(config-router)#bgp router-id 2.2.2.2 R2(config-router)#no bgp default ipv4-unicast R2(config-router)#neighbor ::111.1.1.1 remote-as 1 R2(config-router)#address-family ipv6 R2(config-router-af)#neighbor ::111.1.1.1 activate R2(config-router-af)#neighbor ::111.1.1.1 next-hop-self R2(config-router-af)#network 3fff:abcd:5678:1::/64 R2(config-router-af)#exit R2(config-router)#exit R2(config)#exit |
Following the configuration, you can verify the received MP-BGP prefixes by looking at the BGP RIB on the local router using the show bgp ipv6 unicast command as follows:
| R1#show bgp ipv6 unicast 3fff:abcd:5678:1::/64 BGP routing table entry for 3FFF:ABCD:5678:1::/64, version 6 Paths: (1 available, best #1, table Global-IPv6-Table) Not advertised to any peer 2 ::222.2.2.2 from ::222.2.2.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, external, best |
And finally, this configuration can be validated using a simple LAN-to-LAN ping as follows:
| R1#ping 3fff:abcd:5678:1::2 source 3fff:abcd:1234:1::1 repeat 10Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 3FFF:ABCD:5678:1::2, timeout is 2 seconds: Packet sent with a source address of 3FFF:ABCD:1234:1::1 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 4/4/8 ms |
ISATAP Tunneling
Intra-Site Automatic Tunnel Addressing Protocol, or ISATAP, is an automatic overlay tunneling mechanism that uses the underlying IPv4 network as an NBMA Link Layer for IPv6. As the name suggests, ISATAP is designed for transporting IPv6 packets within a site where a native IPv6 infrastructure is not yet available. ISATAP tunnels allow individual IPv4 or IPv6 dual-stack hosts within a site to communicate with other such hosts on the same virtual link, creating a virtual IPv6 network using the IPv4 infrastructure. The main functionalities and components of ISATAP are automatic tunneling; the ISATAP address format, prefixes, the interface ID and ISATAP prefix advertisement.
ISATAP tunnels are established between ISATAP hosts or between an ISATAP host and an ISATAP router. These tunnels are created automatically because there is no need to apply any manual configuration on hosts when ISATAP support is enabled. However, for ISATAP tunnels between ISATAP hosts and ISATAP routers, the ISATAP host must initially find the IP address of an ISATAP router from the Potential Router List. The Potential Router List is simply a list that contains the IPv4 addresses of all the ISATAP routers within a site.
ISATAP addresses assigned to ISATAP routers and hosts are created using the concatenation of a global Unicast IPv6 address dedicated to the ISATAP operation and the special format of the interface ID. The ISATAP prefix represents the high-order 64-bit of the IPv6 address. A single ISATAP address is enabled on the ISATAP host using the Link-Local prefix FE80::/10 and another global or Site-Local 64-bit prefix is assigned for ISATAP operation within the site. This prefix is then received by ISATAP hosts from router advertisement messages sent by ISATAP routers through the ISATAP tunnels established over the IPv4 infrastructure.
The interface ID used in ISATAP represents the low-order 64-bit of the IPv6 address assigned to the ISATAP host. ISATAP embeds IPv4 addresses in IPv6 addresses, in the same manner used in 6to4 tunneling. This interface ID is created by appending the 32-bit IPv4 address to the high-order 32-bit value 0000:5EFE. This value has been reserved by IANA exclusively for ISATAP use. Undoubtedly, this all sounds very confusing. Therefore, to simplify the ISATAP addressing concept, Figure 9-5 illustrates ISATAP address assignment for an ISATAP host and router:
Referencing Figure 9-5, after being enabled, the ISATAP host with the IPv4 address 1.1.1.1 will derive its Link-Local address by appending the 32-bit IPv4 address to the high-order 32-bit value 0000:5EFE resulting in the Link-Local address FE80:: 5EFE:0101:0101. Once the Link-Local address has been derived, the host sends out a Route Solicitation message to the ISATAP router using an ISATAP tunnel. The ISATAP router responds with a Router Advertisement message specifying the prefix defined within the site, which is 3FFF:ABCD:1234:1::/64. Once the ISATAP host receives this prefix, it will automatically configure a global IPv6 address using ISATAP format based on this prefix. This global address is derived by appending the same low-order 64-bit that is used in the Link-Local address. The global address would therefore be 3FFF:ABCD:1234:1:0:5EFE:0101:0101. The ISATAP host then configures the Link-Local address of the router as its default gateway. And finally, when the ISATAP host has to send IPv6 packets to the ISATAP router, the hosts interface will automatically encapsulate the IPv6 packets in IPv4 packets and send them across the IPv4 infrastructure. These IPv4 packets will use 1.1.1.1 as the source address and 2.2.2.2 as the destination address within the IPv4 header.
ISATAP router functionality is supported in Cisco IOS software; however, there is no support for ISATAP host functionality. Therefore, while understand ISATAP host-to-router operation helps with the general understanding of the standard, greater emphasis should be placed on understanding router-to-router communication when ISATAP tunnels are implemented. As an example, consider the topology illustrated in Figure 9-6:
In the topology illustrated in Figure 9-6, four routers are connected across a WAN. Each router has an IPv6 subnet assigned to its local LAN interface, to which IPv6 hosts are connected. ISATAP tunnels are configured on all routers. The global prefix used for these address is the 3FFF:ABCD:1234:A::/64 prefix. The tunnel source for these tunnels is the local Loopback 0 interface on each router. From this address, each router derives the IPv6 address by appending the 32-bit IPv4 address to the high-order 32-bit value 0000:5EFE. For example, the address for the tunnel interface on router R1 would be 3FFF:ABCD:1234:A:0:5EFE:0101:0101, while for router R2 it would be 3FFF:ABCD:1234:A:0:5EFE:0101:010, and so forth for the remaining two routers. Each router would then be configured with static routes to the remote subnets that point to the ISATAP address of the remote router. Alternatively, BGP could also be used to dynamically advertise prefixes.
Given this, and assuming static route configuration, if, for example, router R1 received a packet from host 3FFF:ABCD:1234:1::1 that was destined to host 3FFF:ABCD:1234:4::1, the packets would match the static route to the 3FFF:ABCD:1234:4::/64 subnet that pointed to the next hop IPv6 address of 3FFF:ABCD:1234:A:0:5EFE:0101:0101. From this address, the router would use the low-order 32-bits to determine the tunnels destination IPv4 address, which would be 4.4.4.4. The router would subsequently encapsulate the IPv6 packets and send them to router R4.
The configuration of ISATAP tunnels in Cisco IOS software is somewhat similar to configuring other automatic tunneling mechanisms in that you do not specify a tunnel destination. However, there are some differences that are unique to the configuration of ISATAP tunneling. The following section describes the sequence of steps required to implement ISATAP tunnels:
- Configure an interface and assign it an IPv4 address using the ip address interface configuration command. While any interface can be used, it is recommended that a Loopback interface be used as it is the most resilient interface on the router. You should also ensure that this is address advertised to the rest of the network
- Configure a tunnel interface using the interface tunnel [number] global configuration command. The number range will vary depending on the version of Cisco IOS software that the router on which the tunnel is being configured is running
- Configure a tunnel source for the static tunnel using the tunnel source [IPv4 address | interface]interface configuration command. This is used as the tunnel source address. All packets sent across this tunnel will have this IPv4 address as the source address included in the IPv4 packet header
- Specify IPv6 as the passenger protocol and IPv4 as both the encapsulation and transport protocol and specify that this is an ISATAP tunnel using the tunnel mode ipv6ip isatap interface configuration command
- Assign the tunnel interface an IPv6 address using the ipv6 address [prefix / length eui-64 interface configuration command. You can use site local or global Unicast address ranges
- Enable ICMP Router Advertisement messages on the tunnel interface using the no ipv6 nd suppress-rainterface configuration command
- Configure static IPv6 routes to one or more remote destinations using the ipv6 route global configuration command. Alternatively, you can also use MP-BGP to dynamically advertise the subnets
To reinforce what has been described in this section, the topology illustrated in Figure 9-7 will be used to illustrate the configuration and verification of ISATAP tunnels:
Following the sequence of configuration steps described previously, R1 is configured as follows:
| R1(config)#ipv6 unicast-routing R1(config)#interface fastethernet 0/0 R1(config-if)#ipv6 address 3fff:abcd:1234:1::1/64 R1(config-if)#ipv6 enable R1(config-if)#exit R1(config)#interface loopback 0 R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config-if)#exit R1(config)#interface tunnel 0 R1(config-if)#tunnel source loopback 0 R1(config-if)#tunnel mode ipv6ip isatap R1(config-if)#ipv6 address fec0:abcd:1234:1::/64 eui-64 R1(config-if)#no ipv6 nd suppress-ra R1(config-if)#exit R1(config)#ipv rout 3fff:abcd:1234:4::/64 fec0:abcd:1234:1:0:5efe:0404:0404 R1(config)#exit |
If you are wondering how I was able to determine the next hop IPv6 address for the subnet that is connected to R4 before even configuring the router, it was simply by following the logic of ISATAP addressing. Given the prefix, the last 64-bit of the address would be 5EFE:0404:0404 based on the IP address that will be configured as specified in the topology. The same logic is applicable to R1 and can be validated using the show ipv6 interfacecommand as follows:
| R1#show ipv6 interface tunnel 0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::5EFE:101:101 Global unicast address(es): FEC0:ABCD:1234:1:0:5EFE:101:101, subnet is FEC0:ABCD:1234:1::/64 [EUI] Joined group address(es): FF02::1 FF02::2 FF02::1:FF01:101 MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is not supported ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses. |
Continuing with the configuration example, router R4 is configured as follows:
| R4(config)#ipv6 unicast-routing R4(config)#interface fastethernet 0/0 R4(config-if)#ipv6 address 3fff:abcd:1234:4::4/64 R4(config-if)#ipv6 enable R4(config-if)#exit R4(config)#interface loopback 0 R4(config-if)#ip address 4.4.4.4 255.255.255.255 R4(config-if)#exit R4(config)#interface tunnel 0 R4(config-if)#tunnel source loopback 0 R4(config-if)#tunnel mode ipv6ip isatap R4(config-if)#ipv6 address fec0:abcd:1234:1::/64 eui-64 R4(config-if)#no ipv6 nd suppress-ra R4(config-if)#exit R4(config)#ipv rout 3fff:abcd:1234:1::/64 fec0:abcd:1234:1:0:5efe:0101:0101 R4(config)#exit |
Again, the show ipv6 interface command can be used to validate ISATAP addressing for the tunnel interface configured on R4 as follows:
| R4#show ipv6 interface tunnel 0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::5EFE:404:404 Global unicast address(es): FEC0:ABCD:1234:1:0:5EFE:404:404, subnet is FEC0:ABCD:1234:1::/64 [EUI] Joined group address(es): FF02::1 FF02::2 FF02::1:FF04:404 MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is not supported ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses. |
As in previous examples, the show interfaces command can be used to verify the tunnel encapsulation, default tunnel values and the state of the tunnel interface as follows:
| R4#show interfaces tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 4.4.4.4 (Loopback0), destination UNKNOWN Tunnel protocol/transport IPv6 ISATAP |
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
And finally, as in the previous examples, a simple LAN-to-LAN ping can be used to validate the ISATAP configuration as follows:
| R4#ping 3fff:abcd:1234:1::1 source 3fff:abcd:1234:4::4 repeat 10 |
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 3FFF:ABCD:1234:1::1, timeout is 2 seconds:
Packet sent with a source address of 3FFF:ABCD:1234:4::4
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 4/5/8 ms
Generic Routing Encapsulation Tunneling
Generic Routing Encapsulation (GRE) is a tunnel encapsulation protocol that is used to tunnel protocols over an internetwork. GRE is the default encapsulation protocol used on tunnel interfaces in Cisco IOS software if one is not explicitly configured. GRE supports multiple protocols and can be used to encapsulate and transport protocols such as IPX, AppleTalk and IPv6 in IPv4 packets. This capability allows GRE to provide greater flexibility than other tunneling mechanisms.
In a manner similar to manually configured IPv6-in-IPv4 tunnels, GRE tunnels are configured statically between two routers to allow for the transport of IPv6 packets over an IPv4 infrastructure. The only notable difference is that while IPv6-in-IPv4 tunnels use a tunnel mode of ipv6ip, GRE tunnels use a tunnel mode of gre ip to tunnel IPv6 packets over the IPv4 infrastructure using GRE encapsulation.
NOTE: If you configure a tunnel with IPv6 source and destination addresses, the tunnel mode gre ipv6 command would be used to specify IPv6 as the transport protocol. An example of when this might be used would be when encapsulating IPv4 packets in IPv6.
Given that the configuration steps required to configure GRE tunnels for IPv6 are the same as those used to configure IPv6-in-IPv4 tunnels, with the only difference being the tunnel mode, we will not be going into detail on this configuration of GRE. However, the following configuration example shows the use of the different tunnel mode when GRE for IPv6 is used. This configuration example is based on the same topology used in previous examples:
| R4(config)#ipv6 unicast-routing R4(config)#interface fastethernet 0/0 R4(config-if)#ipv6 address 3fff:abcd:1234:4::4/64 R4(config-if)#ipv6 enable R4(config-if)#exit R4(config)#interface loopback 0 R4(config-if)#ip address 4.4.4.4 255.255.255.255 R4(config-if)#exit R4(config)#interface tunnel 0 R4(config-if)#ipv6 address 2001:abcd:1234:1::4/64 R4(config-if)#tunnel source loopback 0 R4(config-if)#tunnel destination 1.1.1.1 R4(config-if)#tunnel mode gre R4(config-if)#exit R4(config)#ipv6 route 3fff:abcd:1234:1::/64 tunnel 0 R4(config)#exit |
Following the same sequence of steps, the remote router, R1, is configured as follows:
| R1(config)#ipv6 unicast-routing R1(config)#interface fastethernet 0/0 R1(config-if)#ipv6 address 3fff:abcd:1234:1::1/64 R1(config-if)#ipv6 enable R1(config-if)#exit R1(config)#interface loopback 0 R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config-if)#exit R1(config)#interface tunnel 0 R1(config-if)#ipv6 address 2001:abcd:1234:1::1/64 R1(config-if)#tunnel source loopback 0 R1(config-if)#tunnel destination 4.4.4.4 R1(config-if)#tunnel mode gre ipv6 R1(config-if)#exit R1(config)#ipv6 route 3fff:abcd:1234:4::/64 tunnel 0 R1(config)#exit |
Following this configuration, a simple LAN-to-LAN ping can be used to verify connectivity:
| R1#ping 3fff:abcd:1234:4::4 source 3fff:abcd:1234:1::1 repeat 10 |
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 3FFF:ABCD:1234:4::4, timeout is 2 seconds:
Packet sent with a source address of 3FFF:ABCD:1234:1::1
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 4/6/8 ms
While GRE and manual IPv6 tunnels are similar in many ways, there are a few differences that you should be aware of between the two methods of manually configured tunnels:
- The first difference between GRE and statically configured static IPv6-in-IPv4 tunnels is the MTU value for the tunnel interface. GRE tunnels have a default MTU value of 1476 bytes while static IPv6-in-IPv4 tunnels have a default MTU value of 1480 bytes
- The second difference between GRE and statically configured static IPv6-in-IPv4 tunnels is the formation of the Link-Local address. For GRE tunnels, the Link-Local address is derived via the EIU-64 method using the lowest numbered MAC address of all operational interfaces. For the other tunneling mechanisms, the Link-Local address. For static IPv6-in-IPv4 tunnels, the Link-Local address is derived from the FE80::/96 prefix plus the 32-bit address of the tunnel source.
To validate these statements, the following output shows the default MTU and Link-Local address for a GRE tunnel:
| R1#show ipv6 interface tunnel 0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::20C:CEFF:FEA7:F3A0 Global unicast address(es): 2001:ABCD:1234:1::1, subnet is 2001:ABCD:1234:1::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:1 FF02::1:FFA7:F3A0 MTU is 1476 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. |
Next, the following output shows the default MTU and Link-Local address for a static IPv6-in-IPv4 tunnel:
| R1#show ipv6 interface tunnel 0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::101:101 Global unicast address(es): 2001:ABCD:1234:1::1, subnet is 2001:ABCD:1234:1::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:1 FF02::1:FF01:101 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. |
NOTE: From the output above, we can determine that the tunnel source is an interface with the IPv4 address 1.1.1.1 based on the last 32-bits included in the Link-Local address.
- And finally, as was described earlier in this section, the third difference between the two is that while GRE supports multiple protocols, static IPv6-in-IPv4 tunnels only support the encapsulation of IPv6 in IPv4 packets. GRE is therefore a more flexible option if the same tunnel will be used to support additional protocols.
Having gone through the various tunneling mechanisms supported in Cisco IOS software, it is also important to understand the implications of using these tunneling mechanisms. Although tunneling is one of the most common methods used to transport IPv6 packets over IPv4 networks, there are some factors that should be taken into consideration when implementing tunneling. These factors include:
- Maximum Transmission Unit issues
- ICMPv4 Error Messages
- Protocol Filtering
- Network Address Translation
Maximum Transmission Unit (MTU) refers to the size (in bytes) of the largest protocol data unit that a given layer of a communications protocol can pass onwards. MTU has been described in great detail in previous chapters in this guide. When IPv6 packets are tunneled over IPv4 networks, the 20-byte IPv4 header is inserted before the IPv6 packet. This means that the IPv6 packet size is effectively reduced by 20 bytes.
The minimum MTU for any link in IPv6 networks is 1280 bytes. While the MTU on tunnel interfaces is sufficient to allow most IP packets, the size of the packet when IPv6 is encapsulated in IPv4 may exceed this value which means that the packets will need to be fragmented by IPv4. This will lead to additional processing on routers, as packets must be reassembled at the other end, which may adversely affect router and network performance.
In many older IPv4 routers, only 8 bytes of data beyond the packet’s IPv4 header are returned in the event of an error during the transmission of the packet. This presents a potential issue in that if there is a problem, the IPv6 host (which is sending the packets being tunneled in IPv4) will not know the address fields of the IPv6 packet that is in error.
In typical IPv4 networks, protocol 41 (IPv6) is filtered or blocked by firewalls, given that there is no need for it. While this is good practice, it does affect the deployment of IPv6-over-IPv4 tunnels. Consideration for IPv6 must be given when ACLs and Firewalls are implemented.
As is the case with any other tunneling protocol, it is not possible to establish IPv6-over-IPv4 tunnels when dynamic NAT or port redirection using NAT is configured within the network. However, if static NAT is used, it is possible to establish IPv6-over-IPv4 tunnels.