CDRouter makes it easy to test dual-stack lite B4 CPE implementations on a functional level, and when combined with the many LAN modes of operation available, can help identify issues that are not visible by iterative conformance testing.
Dealing with IPv6 transitioning
Many IPv6 transition strategies have been provided. Some, such as 6to4, have been available to end users for years now, since ISPs have no prerequisite of IPv6 routing to support the 6to4 protocol. IPv6 traffic is simply tunneled between islands using IPv4 as a type of data link layer.
6to4 is at the mercy of relay servers running on anycast addresses (shared addresses that allow for load balancing). The closest relays may be significant distances away, or illegally misconfigured to drop foreign packets. Because of this it cannot be deemed reliable, but simply a “best effort” protocol – inadequate for many contractual agreements and service level agreements. 6to4 packets simply cannot be guaranteed for delivery.
6rd extends 6to4 by allowing ISPs to program their own IPv6 prefixes and control their own relay servers which reside within their domain. Able to provide guaranteed delivery, 6rd is a viable technology for providing business-class IPv6 to the customer’s premises over an IPv4 connection. Although 6rd can be delivered over private address space, there must still be a global IPv4 address deployed to the CPE for IPv4 Internet access. This reduces 6rd’s effectiveness since it is contingent upon global IPv4 address availability.
Providing IPv6 and IPv4 together to the CPE is known as dual stack: the CPE has access to both the IPv4 and IPv6 Internet. While this model is obvious, it too suffers from the fact that IPv4 addresses will become rare. This model will remain quite viable as long as IPv4 addresses are still freely obtainable from ISPs.
Since global IPv4 addresses will become more difficult to obtain, one reasonable transition model addresses the issue directly: deploy a global IPv6 address to the CPE, and forgo the global IPv4 altogether! This brave suggestion is actually quite reasonable when it is paired with Carrier Grade NAT (CGN) for IPv4 delivery.
If the ISP is able to perform the NAT function on outgoing customer packets, it is simply two matters for them: one of receiving the packets from the customer, and the other of storing the packet state flow in a typical NAT table. It is trivial to encapsulate an IPv4 packet in an IPv6 tunnel. This is no issue since the CPE is already configured with IPv6. The other issue the ISP has is that many customers will use the same RFC 1918 private networks as their origin addresses. This dilemma is resolved by recording an additional parameter, the customer’s IPv6 address. Recording these two addresses plus the transport layer port number are adequate for the ISP to NAT an arbitrary number of customers. Significantly fewer global IPv4 addresses are required. This technique has been formalized by the IETF as RFC 6333, and is commonly referred to as dual-stack lite or DS-Lite.
In this model we see that NAT has been moved from the CPE to the ISP. The CPE is now a Basic Bridging BroadBand element (B4), in DS-Lite terminology. The ISP end, perhaps amusingly, is named the AFTR (Address Family Transition Router). Packets with private addresses leave the B4 CPE untranslated. After decapsulation by the AFTR, they have NAT applied and are routed onto the IPv4 Internet. Users with IPv4 only devices will effectively see no changes from the current model of CPE based NAT. Media devices, LAN enabled smart phones, gaming consoles, laptops and workstations alike will continue operating with zero configuration changes. This model is desirable because it mitigates support costs to everyone: ISPs will have fewer consumer support issues, and businesses will have smaller network administration costs.
DS-Lite tunnels IPv4 packets from the customer to the AFTR, where NAT is performed.
One significant reason the B4 was chosen to bridge all of the customer’s LAN traffic directly to the ISP is the delicate issue of performing double NAT. Performing a second NAT function on a packet stream is well-known to cause significant connectivity issues. Since ISPs will inevitably require their own NAT to save addresses, allowing their CPEs to continue performing NAT would incur a significant operational difficulty. This is all solved by the B4 delivering the traffic directly.
Of course, some issues arise and are still being discussed. Perhaps the most prominent is the issue of inbound port mapping. Trivial for a customer controlling a global IPv4 address, how does a customer indicate to the ISP that a specific port should statically map to an internal address? Issues such as these continue to be discussed in various IETF working groups.
Configuration in CDRouter
DS-Lite is fully supported in the CDRouter IPv6 add-on as a new IPv4 WAN connection mode.
In addition, CDRouter also includes a dedicated test module for investigating various aspects of DS-Lite functionality. The dslite test module is part of the CDRouter IPv6 add-on.
To enable DS-Lite, set the testvar
wanMode to the value dslite:
testvar wanMode dslite
DS-Lite provides tunneled IPv4 connectivity over a native IPv6 connection only. As a result, the IPv6 WAN modes of 6to4 and 6rd are incompatible with DS-Lite.
When DS-Lite is enabled, CDRouter will automatically create a DS-Lite AFTR element on the WAN. The IPv6 address of CDRouter’s AFTR element is specified by the testvar
ipv6DsliteAftr. Note that the IPv6 address of the AFTR must reside on a different IPv6 network than the DUT’s WAN interface.
testvar ipv6DsliteAftr 3001:aaaa::1
When setting up DS-Lite, the DUT configuration must also be updated with the location of the AFTR-server. The DUT may require the IPv6 address of the AFTR element, or it may allow a domain name to be used. This can be configured in CDRouter using the
dhcpv6WanAftrName testvar. When this testvar is defined, CDRouter’s DNS servers will automatically resolve the configured domain name to the IPv6 address specified by the
testvar dhcpv6WanAftrName aftr.qacafe.com
CDRouter will also provide this domain name in DHCPv6 responses if the DUT requests it by specifying the “AFTR-Name” DHCP Option (option 64) in Solicit and Request messages. See RFC 6334 for more information about this DHCP option.
Configuration Example 1
In the DS-Lite configuration below, the DUT is configured with a static IPv6 address of
3001::2. The DS-Lite AFTR element created by CDRouter on the WAN has the address
3001:aaaa::1. The DS-Lite specification defines a new
192.0.0.1/29 subnet to identify the B4 and AFTR elements in IPv4. The AFTR is expected to use
192.0.0.1 but the B4 may select any remaining address from this pool. The testvars
wanIspAssignIp must be configured to match the AFTR address and the expected B4 address chosen by the DUT, respectively.
# -- IPv4 WAN configuration testvar wanMode dslite testvar wanIspIp 192.0.0.1 testvar wanIspAssignIp 192.0.0.2 testvar wanIspMask 255.255.255.248 # -- IPv6 WAN configuration testvar supportsIPv6 yes testvar ipv6WanMode static testvar ipv6WanIspIp 3001::1 testvar ipv6WanIspAssignIp 3001::2 testvar ipv6DsliteAftr 3001:aaaa::1 testvar dhcpv6WanAftrName aftr.qacafe.com # -- IPv6 LAN configuration testvar ipv6LanMode autoconf testvar ipv6LanIp 3001:dddd::%eui64% testvar ipv6LanPrefixLen 64 testvar ipv6DNStoLAN yes testvar ipv6RAInterval 300 # -- other IPv6 configuration options testvar ipv6RemoteHost 3001:51a:cafe::1 testvar ipv6WanDnsServer 3001:51a:cafe::2 testvar ipv6WanBackupDnsServer 3001:51a:cafe::3 testvar ipv6MaxLanClients 100 testvar ipv6FreeNetworkStart 3001:cafe:1:: testvar ipv6FreeNetworkEnd 3001:ffff:ffff:: testvar ipv6FreeNetworkPrefixLen 64
IPv4 Firewall Mode
In DS-Lite mode, the CPE will not apply NAT to outgoing IPv4 packets from the LAN to the WAN. However, the CPE should still apply a firewall mode to the outgoing IPv4 packets. The expected type of firewall mode can be now be configured using the
dsliteFirewallMode testvar. Valid options are address-restricted, port-restricted, or full-cone.
testvar dsliteFirewallMode port-restricted
Note that the
dsliteFirewallMode testvar was added in the CDRouter 7.1 release.
DS-Lite with IPv4 Exclusively on the LAN
CDRouter supports DS-Lite configurations where the DUT provides all LAN clients with connectivity via IPv4 exclusively. This is accomplished by setting the
ipv6LanMode testvar to the new mode of none:
testvar ipv6LanMode none
When the testvar
ipv6LanMode is set to “none” CDRouter will not attempt to obtain global IPv6 addresses for all LAN clients during the startup sequence.
When DS-Lite is enabled, CDRouter expects IPv4 packets received on the WAN to be untranslated packets originating from RFC 1918 address space. This implies a change in the normal IPv4 NAT model implemented in a non-DS-Lite environment. Verifying that the DUT’s IPv4 functionality continues to work as expected when running DS-Lite is a great testing exercise, and is easy to confirm by running all of the CDRouter’s existing IPv4 and IPv6 test modules that are applicable. This allows the DUT’s B4 functionality to be flexed in a variety of ways which may expose implementation issues arising from changes in the NAT model, MTU and fragmentation issues caused by the tunnel encapsulation, and even issues at the Application Layer.
Another good DS-Lite testing exercise is to verify that DS-Lite functionality and IPv4 behavior is consistent over all of the supported IPv6 WAN modes. Setting this up with CDRouter is very easy and will quickly expose any issues associated with certain IPv6 WAN configurations.