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 13‑3 shows an example deployment with an 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 13‑4 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 auto-discovery probe to identify themselves in the auto-discovery 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 13‑5 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 v8.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 13‑6 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 v8.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 13‑7 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.