Internet Protocol version 6 (IPv6) has become an important factor to consider as the pool of IPv4 addresses becomes exhausted. You may need to plan to meet organizational mandates for compliance with IPv6. SteelHead can accelerate TCP over IPv6 using autodiscovery and fixed-target rules. The benefit of autodiscovery and fixed-target rules is that you can provide both application streamlining for select protocols and transport streamlining, in addition to data streamlining. Packet mode acceleration is still an alternative for data streamlining of IPv6 traffic.

IPv6 is the next revision of the Internet Protocol. IPv6 has become a critical enabler as more devices are being connected to the internet. The main purpose of IPv6 is to help service providers and companies manage the exhaustion of IPv4 addresses without relying on other techniques such as network address translation (NAT), which hide and manipulate the source IP address when connecting across organizational boundaries. IPv6 was designed to overcome the limitation in IPv4 by using a 128-bit address instead of a 32-bit address, thereby supporting up to 3.4 x 10^38 addresses; IPv4 supports up to 4.3 billion only.

The use of private IPv4 address space has created challenges for applications, security, and performance because the source and destination addresses can change through the connection. RiOS supports IPv6 traffic with packet mode acceleration and supports autodiscovery and fixed target rules. RiOS supports support autodiscovery with IPv6 for the accelerated connection over the WAN. By using autodiscovery or fixed target rules, RiOS can apply transport and application streamlining techniques (similarly as it does for TCP connections over IPv4) to improve the user experience as the transition to IPv6 continues.

The following RiOS features are compatible with IPv6:

IPv6 addresses share many characteristics with their IPv4 counterparts. Each version separates the address into a network identifier and host identifier. Depending on the type of address, IPv6 specifies certain bit ranges for specific purposes.

In many ways, this is similar to how IPv4 uses address classes. It is important to note that IPv6 addresses use hexadecimal digits instead of a dotted-decimal format. Also, an interface on a device has multiple IPv6 addresses (instead of a single IPv4 address) that it uses to communicate. For example, each interface always has a link-local address and can have one or multiple global unicast addresses.

There are several types of IPv6 addresses. We recommend that you verify with the IPv6 address registry, because new IPv6 transition mechanisms or address blocks are reserved. The types of addresses are as follows:

RiOS supports a single-system, generated link-local address and a user-assigned IPv6 address for each interface (primary, auxiliary, and in-path). The link-local address is automatically assigned as the network identifier using FE80 in the first 64 bits and a modified EUI-64 identifier for the host bits following RFC 4291. This address is automatically assigned by the system and cannot be changed.

The link-local address is used as part of IPv6 neighbor discovery, which is analogous to address resolution protocol for IPv4. You must manually configure the user-assigned IPv6 address—it cannot be derived from stateless automatic configuration or dynamic host communication protocol for IPv6. There are two address types, depending on whether you need to natively communicate outside of an organizational boundary—in much the same way a public or private IPv4 address is selected. For SteelHeads, choose one of the following IPv6 addresses:

The IPv6 gateway is also user assigned, and you can link it to the local address of the router or the address on the same subnet as the manually assigned address. RiOS does not support receiving router advertisements as a means to discover the IPv6 gateway. Configure the link-local address for a virtual router in circumstances in which you use a first hop redundancy protocol: for example, HSRPv6.

You can intercept TCP-over-IPv6 traffic and perform acceleration by performing transport streamlining on the connection instead of performing data reduction on a packet-by-packet basis. The SteelHeads perform their roles in the connection by establishing three separate connections:

The key difference between packet mode acceleration and IPv6-based acceleration is that IPv6 supports autodiscovery and fixed-target rules. Packet mode performs data reduction on each packet, and TCP-over-IPv6 supports application, data, and transport streamlining by inserting the SteelHeads into the connection.

Support for WAN visibility modes with autodiscovery of TCP-over-IPv6 traffic is limited to correct addressing. Identical to IPv4 autodiscovery, IPv6 autodiscovery uses the same TCP options present in the TCP header of the connection setup packets to discover a remote SteelHead on the path between the end systems. However, beginning in RiOS 9.5, the SteelHead appliances can be configured to use autodiscovery to learn the IPv6 address of the remote peer. The SteelHead appliances insert their IPv6 address in an IPv6 header option; the specific header option is the destination option.

More information on other IPv6 header options is available at the following link:

http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

IPv6 autodiscovery is disabled by default and must be enabled on the peering rules page.

RiOS 9.5 and later support autodiscovery for IPv6 single-stack networks. For earlier versions, you can use a fixed-target rule for single-stack networks that enables you to accelerate traffic end-to-end using IPv6 addresses. The inner channel between SteelHeads forms a TCPv6 connection using the discovered IPv6 address of the peer in the IPv6 destination option or the manually assigned IPv6 address in the fixed target rule. Starting with RiOS 9.7, port and full transparency modes are supported for IPv6, and inner channels that use IPv6 can be addressed in a similar way as inner channels that use IPv4.

The latter method is similar to an IPv4 fixed-target rule, and you configure it the same way. Although you can use IPv6 addresses end-to-end in the connection, the SteelHead in-path interface continues to require an IPv4 address for the acceleration service to start.

The default rule was previously all-IPv4 but is now all-IP. All-IP includes all IPv4 and all IPv6 traffic. The default rule for TCP traffic, either IPv4 or IPv6, attempts autodiscovery with correct addressing as the WAN visibility mode. IPv6 autodiscovery for single-stack networks only uses correct addressing. Starting with RiOS 9.7, port and full transparency modes are supported for IPv6, and inner channels that use IPv6 can be addressed in a similar way as inner channels that use IPv4.

A fixed-target rule with an IPv6 target appliance address requires the source and destination address type to be an IPv6 address. You must change the use of all-IP to all-IPv6. If you do not change to all-IPv6, use specific source addresses or destination addresses or both.

You can configure SteelHeads for in-path or virtual in-path deployment for TCP-over-IPv6 traffic. Riverbed also supports server-side out-of-path deployments.

Considerations for the deployment type are the same as the considerations for accelerating of IPv4 connections. Network integration features such as fail-to-wire, link state propagation, parallel deployments, firewalls, and so on continue to be relevant for acceleration of TCP-over-IPv6 traffic. IPv4 connections can coexist with TCP-over-IPv6 traffic.

The following list can help you simplify the choice of deployment options:

The in-path deployment for acceleration of TCP over IPv6 traffic is similar to an in-path deployment for IPv4 connections. You deploy the SteelHead physically in-path using an IPv6 address on the SteelHead in-path interface. Optionally, for IPv6 management, you can configure an IPv6 address on the primary interface.

In addition to using the primary interface, you can also use the auxiliary (AUX) interface for management. The AUX interface must be on a different subnet than the primary interface. Likewise, the management in-path interface can be used and it also must be on a different subnet.

The in-path interface has its own IPv6 routing table. You can add destinations to the table and select an appropriate next hop. You can also add simplified routing to reduce the burden of administering IPv6 routes.

Figure: In-path SteelHead configuration using IPv6 shows an example deployment with IPv6 addresses from the globally assigned address range manually assigned to the primary and inpath0_0 interfaces. The primary interface is assigned 2001:aaaa::100 with a prefix length of 64 bits. The inpath0_0 interface is assigned 2001:aaaa::10 with a prefix length of 64 bits. The primary interface has the global unicast address of Router 1 configured as its IPv6 gateway, but you could use a link-local address.

In this example, the link-local address of the HSRPv6 virtual gateway is used as the default route for the in-path interface and the global unicast address is used for the primary interface. Normally, the same default route is used. The in-path interface is configured to use the HSRPv6 virtual gateway link local address for its IPv6 gateway. This link-local address is always on the same network as the SteelHead in-path interface automatically assigned link-local address according to the IPv6 standards.

Connect to the SteelHead CLI and enter the following commands:

Figure: Serial cluster SteelHead configuration using IPv6 shows an example deployment with IPv6 addresses in a SteelHead serial cluster deployment. You can deploy SteelHeads in a serial cluster and accelerate TCP-over-IPv6 traffic. In dual-stack networks, set the peering rule to match the local peer IPv4 address, because SteelHeads insert the IPv4 address in the autodiscovery probe to identify themselves in the autodiscovery process. In single-stack networks, set the peering rule to match the local peer IPv6 address. Setting the peering rule for serial cluster deployments correctly is important because we do not recommend that you accelerate connections between locally connected SteelHeads.

Figure: Connection forwarding and SteelHead using IPv6 shows an example deployment of connection forwarding for TCP-over-IPv6 traffic. You can deploy SteelHeads in a parallel topology using connection forwarding to accelerate TCP-over-IPv6 traffic. You must configure your SteelHead to communicate using multi-interface. In addition, each in-path interface requires an IPv4 and an IPv6 address.

Connection forwarding uses the IPv4 addresses (TCP port 7850 connection) and redirects the connection setup packets through GRE encapsulation between the IPv4 addresses. When the connection is established and accelerated, asymmetric traffic is redirected through NAT, destined to the peer in-path interface IPv6 address. You can accelerate TCP-over-IPv4 and TCP-over-IPv6 traffic concurrently and the NAT entries are resynchronized between peers, even if a peer has its acceleration service restarted or is disconnected.

Figure: Virtual in-path SteelHead configuration using IPv6 shows an example deployment of a virtual in-path SteelHead using IPv6. Virtual in-path support for TCP-over-IPv6 traffic is limited to policy-based routing (PBR). You configure a SteelHead virtually in-path similarly to an IPv4 PBR deployment.

WCCPv6 is not supported. The Layer-3 device redirecting traffic must support PBR for IPv6 traffic. Cisco provides a list of software in which the PBR for IPv6 feature was introduced (12.2(30)S, 12.2(33)SXI4, 12.3(7)T, 12.4, and 12.4(2)T).

As of RiOS 9.5, fixed-target rules are not required for single-stack networks when accelerating TCP-over-IPv6 connections. But fixed-target rules are still helpful in some scenarios such as testing or server-side out-of-path configurations. Figure: Fixed-target rule SteelHead configuration using IPv6 shows an example deployment of a SteelHead using a fixed-target rule in an IPv6 environment. For SteelHeads running earlier versions, you can use fixed-target rules for end-to-end acceleration using an IPv6 address when you have SteelHeads in an all-IPv6 network or when peer SteelHeads communicate using their in-path interface IPv6 addresses. RiOS 9.5 and later support IPv6 inner paths for enhanced autodiscovery.

The fixed-target rule operates similarly to IPv4 traffic, by replacing the IPv4 header and sending a directed connection setup packet to the target appliance IPv6 address. A fixed-target rule also works for server-side out-of-path (SSOOP) deployments. In a SSOOP deployment, the outer channel between the server-side SteelHead and server uses the primary interface IPv6 address in the same way it operates for SSOOP on IPv4 traffic.

Connect to the SteelHead CLI and enter the following commands:

Acceleration for TCP-over-IPv6 traffic supports data reduction for any connection. In addition to data reduction, the following protocols have application streamlining support:

There are three ways to verify and troubleshoot your IPv6 deployments:

Make sure that the SteelHead can reach the end system (client or server). You can use a utility ping at the SteelHead CLI and in the Management Console. Using the ping6 utility, you must specify the interface IPv6 address instead of the interface name. The following example shows how to send an ICMPv6 echo request using the IPv6 address of 2001:aaaa::10 to reach 2001:aaaa::2:

Traceroute for IPv6 has also been included for verifying the path from the SteelHead to an IPv6 device or verifying the path between SteelHeads using a fixed-target rule.