CDRouter IPv6 User Guide 6.3/Possible Problems
From QA Cafe Support Wiki
Possible Problems
IPv6 Conflict Between CDRouter and the Linux Kernel
We recommend that IPv6 be disabled within the Linux operating system to avoid potential addressing conflicts when using CDRouter IPv6. Please see this Knowledge Base article for more information on disabling IPv6 within your Linux operating system.
CDRouter IPv6 will automatically detect if any of the allocated test interfaces have IPv6 addresses that were assigned by the Linux kernel. If pre-existing IPv6 addresses are detected, CDRouter will produce a warning message and abort the test run. Please see the above Knowledge Base article for information on disabling IPv6 within your Linux operating system.
It is also possible to skip CDRouter’s IPv6 address check. Please see this Knowledge Base article for more information.
6to4 Tunnel Not Being Created by DUT
The 6to4 mechanism defined in RFC 3056 relies on translating globally routable 32-bit IPv4 addresses into a unique 48-bit IPv6 prefix. 6to4 is not designed to work with private IPv4 addresses, which should be avoided when configuring and running tests with CDRouter IPv6. Please see the example configuration provided in the Configuration section of this document for more information.
Some devices may not initiate a 6to4 tunnel on the WAN if the primary IPv4 address obtained on the WAN is not a global address. In these cases configuring CDRouter to assign a global IPv4 address to the DUT may force initiation of the 6to4 tunnel on the WAN as expected.
Inconsistent IPv6 Behavior for Different IPv4 WAN Modes
The IPv6 behavior of some devices varies significantly based on the IPv4 WAN connection mode that is used. For example, the behavior of a dual-stack CPE configured for static IPv6 and DHCP IPv4 connectivity on the WAN may be different than the results for the same basic setup but using PPPoE for IPv4 connectivity on the WAN instead. In rare cases some devices and combinations of IPv4 and IPv6 WAN connection modes essentially do not work all. Ideally, the behavior should be consistent regardless of the IPv4 connection type used. As mentioned in Section 6, a good testing exercise is to verify IPv6 functionality across all IPv4 WAN connection types supported by the DUT (DHCP, PPPoE, PPPoA, PPP/T1, PPTP, L2TP, and static IP).
No IPv6 Firewall
Many devices that include IPv6 support have no firewalling capabilities for IPv6 connections. This poses a significant threat to overall security as IPv6 connections from the WAN are simply forwarded blindly to hosts on the LAN.
Limited IPv6 Firewall Support
In IPv6 enabled devices IPv6 firewall support is often limited when compared to IPv4 firewall support. As a result, devices may handle certain applications differently over IPv4 and IPv6 connections. For example, FTP and TFTP are widely supported applications that generally work through IPv4 firewalls. However, FTP and TFTP ALG functionality for IPv6 is less common. The end result is that some applications, such as FTP and TFTP, may work properly through the device under test over IPv4 but not IPv6.
Missing or Incorrect Default Routes for IPv6
Some devices that claim support for IPv6 do not properly establish default routes for IPv6 traffic. As a result, these devices are unable to forward IPv6 traffic from LAN to WAN, resulting in restricted access clients on the LAN attempting to communicate with IPv6 resources on the WAN.
Unofficial Support for IPv6
As mentioned in the previous section, some devices that do not officially support IPv6 actually do. This is problematic because often there is no IPv6 firewall support within these devices and no mechanism for configuring or disabling IPv6 support.
Incorrect Router Advertisement Interval Configured
If the value of the testvar ipv6RAInterval does not match the actual Router Advertisement interval configured on the device under test, CDRouter may incorrectly fail test cases or fail to obtain global IPv6 addresses via stateless address autoconfiguration. If you are unsure of the Router Advertisement interval, try setting this testvar to a large value and running test case ipv6_ndp_2 to see the actual interval implemented by the DUT.
IPv6 Subnet Issues
When static IPv6 is used on the WAN, it is important that the LAN side configuration utilizes a different IPv6 network to ensure proper routing from LAN to WAN and WAN to LAN through the DUT. If both the LAN and WAN interfaces of the DUT are on the same IPv6 network, packets may not be routed properly.
IPv6 DNS Information when DHCPv6 Prefix Delegation is Enabled
Some devices may not request IPv6 DNS information when DHCPv6 is used only for prefix delegation on the WAN. This issue can be quickly identified with CDRouter by running tests using autoconf with prefix delegation as the primary IPv6 connection WAN mode.
IPv6 Routes Not Updated After Renumbering Event on WAN
When a new address or prefix is assigned by the ISP to the DUT, the DUT must update its routing table to ensure that traffic continues to flow properly from LAN to WAN and vice-versa. Some implementations fail to update their IPv6 routes following an address or prefix change on the WAN – this often results in dropped packets and a general loss of connectivity for all clients on the LAN.
Not All IPv6 Configurations Work as Expected
CDRouter makes it easy to run a baseline set of tests against a device using a wide variety of IPv6 configuration options. This is an excellent test exercise, as mentioned in the previous section, and often reveals inconsistencies in IPv6 behavior. A common example is a device that works well when a tunneling protocol, such as 6to4 is used on the WAN, but fails to set up the proper IPv6 routes when native IPv6 or DHCPv6 is used on the WAN instead. In this scenario is that the DUT fails to forward IPv6 packets for any WAN mode other than 6to4.