Internet Protocol version 6 (IPv6) has become an important factor to consider as the pool of IPv4 addresses becomes exhausted. You must also plan to meet the organizational mandates for compliance with IPv6. This chapter describes how to configure SteelHeads running RiOS 8.5 for optimization of 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 optimization is still an alternative for data streamlining of IPv6 traffic. This chapter includes the following sections:

This section provides an overview of various aspects of IPv6. This section includes the following topics:

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 extended support for IPv6 traffic with packet mode optimization, and RiOS 8.5 or later further enhanced its IPv6 capabilities by supporting autodiscovery and fixed target rules. 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 8.5 features are compatible with IPv6.

The following features are not IPv6 compatible:

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. Riverbed recommends 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.

RiOS 8.5 introduces the ability to intercept TCP-over-IPv6 traffic and perform optimization 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 optimization and IPv6-based optimization 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. The SteelHeads set up an inner channel using IPv4 addresses that requires the intervening network to be IPv6- and IPv4-capable or dual-stack.

For more information about packet mode optimization, see Packet Mode Optimization. For more information about WAN visibility modes and correct addressing, see WAN Visibility Modes.

The alternative to using autodiscovery is to use a fixed-target rule. A fixed-target rule enables you to optimize traffic end-to-end using IPv6 addresses. The inner channel between SteelHeads forms a TCP connection using the manually assigned IPv6 address. This 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 optimization 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. 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. This section includes the following topics:

Considerations for the deployment type are the same as the considerations for optimizing 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 optimization 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 optimization 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. The in-path management interface cannot be assigned an IPv6 address to manage the SteelHead.

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.

For information about simplified routing, see Overview of Simplified Routing.

Figure: In-Path SteelHead Configuration Using IPv6 shows an example deployment with IPv6 address from the globally assigned address range manually assigned to the primary and inpath0_0 interface. 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.

Figure: Serial Cluster SteelHead Configuration Using IPv6 shows an example deployment with an IPv6 addresses in a SteelHead serial cluster deployment. You can deploy SteelHeads in a serial cluster and optimize TCP-over-IPv6 traffic. Set the peering rule to match the peer IPv4 address, because SteelHeads insert the IPv4 address in the autodiscovery probe to identify themselves in the autodiscovery process. Setting the peering rule for serial cluster deployments correctly is important because Riverbed does not recommend that you optimize connections between locally connected SteelHeads.

For information about serial cluster deployments, see In-Path Redundancy and Clustering Examples.

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 optimize TCP-over-IPv6 traffic. You must use RiOS 8.5 or later and 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 optimized, asymmetric traffic is redirected through NAT, destined to the peer in-path interface IPv6 address. You can optimize TCP-over-IPv4 and TCP-over-IPv6 traffic concurrently and the NAT entries are resynchronized between peers, even if a peer has its optimization service restarted or is disconnected.

For information about connection forwarding, see Connection Forwarding.

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) in RiOS 8.5 or later. 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).

For information about PBR, see Policy-Based Routing Virtual In-Path Deployments.

Figure: Fixed-Target Rule SteelHead Configuration Using IPv6 shows an example deployment of a SteelHead using a fixed-target rule in an IPv6 environment. You can use fixed-target rules for end-to-end optimization 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.

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.

For information about SSOOP, see Out-of-Path Deployments.

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

For more information about protocol support, see the SteelHead Deployment Guide - Protocols and the Riverbed Command-Line Interface Reference Manual.

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 SteelHead 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:

Figure: Connection Report shows a connection report in which the status of an IPv6 connection is optimized by the SteelHead.