SteelHead™ Deployment Guide : IPv6 : Overview of IPv6
  
Overview of IPv6
This section provides an overview of various aspects of IPv6. This section includes the following topics:
  • RiOS RFC Compliance and Feature Compatibility
  • IPv6 Addressing
  • Traffic Interception
  • 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 v8.5 or later further enhanced its IPv6 capabilities by supporting auto-discovery and fixed target rules. By using auto-discovery 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.
    RiOS RFC Compliance and Feature Compatibility
    The following RiOS v8.5 features are compatible with IPv6.
     
    RiOS IPv6 Support Includes
    RiOS Version
    Notes
    Conformance with Request for Comments (RFCs) 1981, 2460, 2464, 2710, 3590, 4007, 4291, 4443, 4861, 4862, 4943, 5095, and 5156.
    v8.5 and later
     
    TCP IPv6 traffic interception between source and destination, bandwidth optimization.
    v8.5 and later
     
    Auto-discovery of Steelhead appliances.
    v8.5 and later
    TCP inner connections between the peer Steelhead appliances is strictly IPv4.
    Ability to automatically discover fixed-target and pass-through in-path rules, along with ability to deny and reject IPv6 TCP traffic as configured in the in-path rules.
     
    v8.5 and later
    RiOS does not support the neural framing modes Always, TCP Hints, and Dynamic.
    RiOS does not support the Oracle forms and Oracle forms over SSL preoptimization policies.
    HTTP and HTTPS latency optimization for IPv6 TCP traffic.
    v8.5 and later
     
    Ability to configure serial clusters.
    v8.5 and later
     
    Interception of IPv6 traffic for in-path, virtual in-path, and server-side out-of-path configurations.
    v8.5 and later
    WCCPv6 support is not available. Virtual in-path support is PBR only.
    Interceptor is not supported.
    Intercepting and passing through IPv4 and/or IPv6 traffic, depending on the in-path rules.
    v8.5 and later
     
    Ability to detect asymmetric routes for IPv6 TCP traffic; enables connection forwarding of IPv6 TCP traffic in asymmetric conditions.
    v8.5 and later
    The connection-forwarding control channel between the neighbors is strictly IPv4. You must configure IPv4 addresses on the Steelhead appliances when using a connection-forwarding control channel.
    Ability to configure IPv4 and IPv6 addresses on every in-path interface and intercepting and optimizing IPv4 and IPv6 traffic.
    v8.5 and later
     
    Ability to configure one IPv6 address configuration for every in-path interface.
    RiOS intercepts and optimizes traffic matching the scope of the IPv6 address configured on the in-path interface. Not applicable for a link-local address configured on the in-path interface.
    v8.5 and later
    RiOS passes through IPv6 TCP traffic not matching the scope of the IPv6 address configured on the in-path interface.
    Ability to configure IPv6 addresses on any in-path interface.
    IPv6 TCP inner connections only in fixed-target cases.
    v8.5 and later
    This IPv6-only mode requires configuring only fixed-target in-path rules.
    Enhanced autodiscovery of Steelhead appliances for IPv6 TCP traffic.
    v8.5 and later
    TCP inner connections between the peer Steelhead appliances is IPv4 only.
    Simplified routing for IPv6 TCP traffic.
    v8.5 and later
     
    Connection forwarding for IPv6 traffic in multi-interface mode.
    v8.5 and later
    The control connection between neighbors is still IPv4 only.
    When multiple interface support in the Networking > Network Integration: Connection Forwarding page is not enabled, IPv6 traffic is passed through.
    Ability to configure peering rules for IPv6 traffic.
    v8.5
    The peer client-side Steelhead appliance IP address is IPv4 only.
    Ability to configure IPv6 addresses in Single Ended Interception (SEI) rules under Optimization > Network Services: Transport Settings.
    v8.5 and later
     
    Global and automatic kickoff for pass-through TCP IPv6 traffic.
    v8.5 and later
     
    Ability to configure asymmetric VLANs for IPv6 TCP traffic.
    v8.5 and later
     
    Latency optimization of signed-SMB, CIFS/SMB1, SMB2, and SMB3 using IPv6 endpoint addressing.
    v8.5.2 and later
    The authentication stack continues to require IPv4 endpoint addressing.
    Encrypted Outlook Anywhere latency optimization.
    v8.6 and later
     
    MAPI, eMAPI latency optimization
    v8.6 and later
    Authentication is over IPv4.
    Authentication over IPv6.
    v8.6 and later
     
     
    Features Not Supported with IPv6
    The following features are not IPv6 compatible:
  • Management In-Path (MIP) Interface
  • Transparency
  • NetFlow
  • RSP
  • Path selection
  • QoS
  • Host labels
  • IPSec
  • Automatic address assignment through DHCPv6
  • Multicast listener discovery
  • IPv6 stateless address autoconfiguration
  • WCCP using anything other than IPv4 outer connections
  • IPv6 Addressing
    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:
  • Global unicast--2000::/3
  • 2002::/16 reserved for 6to4
  • 2001:0000::/32 reserved for TEREDO
  • ::ffff:0:0/96 reserved for IPv4-mapped address
  • Unique local--fc00::/7
  • Link local--fe80::/10
  • Multicast--ff00::/8
  • Loopback--::1/128 reserved for loopback address
  • Unspecified--::/128 reserved for unspecified address
  • Source: http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml (April 2013)
    The types of IPv6 addresses are subject to change.
    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:
  • An aggregatable global unicast address for the SteelHead to communicate with devices not directly connected to the interface.
  • A unique local unicast address, which is the updated address range to replace site local addresses.
  • The intent of a unique local unicast address is for a private IPv6 address range.
    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.
    Traffic Interception
    RiOS v8.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:
  • Outer channel from the client to the client-side SteelHead
  • Outer channel from the server to the server-side SteelHead
  • Inner channel between SteelHeads
  • The key difference between packet mode optimization and IPv6-based optimization is that IPv6 supports auto-discovery 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 auto-discovery of TCP-over-IPv6 traffic is limited to correct addressing. Identical to IPv4 auto-discovery, IPv6 auto-discovery 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. Note that the SteelHeads set up an inner channel using IPv4 addresses. This 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.
    Figure 13‑1. Auto-Discovery with IPv6
    The alternative to using auto-discovery 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. Note that 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.
    Figure 13‑2. Fixed-Target Rule with IPv6