Subject: [v6ops] Coexistence: Is there a need for an Informational RFC on Common Integration Pitfalls in a Dual Stack Environment

From: Ray Hunter <[email-masked]>
Date: Fri, 13 May 2011 10:25:37 +0200

I have a specific example of where a number of IPv4 and IPv6 components 
were performing correctly, but where the overall integrated system was 
failing.

As we move towards a dual stacked World in many environments, is there a 
need for an Informational RFC on Common Integration Pitfalls in a Dual 
Stack Environment and how to avoid them?

The specific example I have come across was a "minor annoyance" whilst 
testing an upgrade of some recent host software. I guess it could have 
been worse, and I haven't seen this class of problem mentioned anywhere, 
even though it might be "obvious" to everyone here, which is why I 
thought I'd post to the list.

The issue is that host to enterprise VPN clients traditionally have 
allowed network administrators to "control" access of home and traveling 
users to the Internet to either force traffic down the VPN link, or to 
prevent traffic passing directly to the Internet. These features are 
commonly known by various manufacturers as "split tunneling", "limited 
split tunneling", "forced tunneling", "inverse split tunneling", 
"reverse split tunneling" & "disabled split tunneling."

I won't go into the pros and cons of prevention of "split tunneling" or 
whether "forced tunneling" is desirable, suffice it to say that it is a 
requirement of a number of organizations' current security policies.

What was happening was that a new version of the VPN client had been 
requested from the manufacturer for use on a new version of well-known 
and popular desktop operating system to cover some upgrade and 
installation issues. The previous VPN client and concentrator were 
clearly IPv4 only, but the current version of the desktop operating 
system now ships with IPv6 enabled by default. The resulting code from 
the manufacturer was qualified by the manufacturer and passed to the VPN 
service supplier, before being sent to the desktop integrator, and was 
then sent for integration test and approval before being implemented in 
production. It failed at integration testing.

Enforcement of the "split tunneling" features in this particular product 
relies on the manipulation of the standard host IPv4 routing table. 
There are of course other ways to achieve this effect, so there is no 
direct read across to other manufacturer's products and solutions, and 
this may be just be a one off implementation issue.

Anyway, since this particular VPN client was completely unaware of the 
IPv6 routing table on the host, it did not manipulate the IPv6 part of 
the host routing table at all. So regardless of the settings on the 
central control console, the users on the VPN client hosts could access 
the Internet directly without passing through any enterprise managed 
systems, even though the centrally defined policy was set to prohibit 
this. No warning messages or other indications were given.

The manufacturer has stated that this system is "end of life" and will 
not be implementing any upgrade or fix.

Other manufacturers may of course already be aware of this issue and may 
have taken appropriate action in their products.

One reason that this turned out not to be more serious in this 
particular case was that the central VPN concentrator itself is very 
conservative about which packets it will accept over the IPSec VPN 
tunnel connection (limited to packets with an IPv4 source address of the 
endpoint of the IPSec VPN tunnel). Another reason is that the enterprise 
was prepared to consider alternative technical solutions for 
implementing certain requirements by deploying equipment from another 
manufacturer, and making amendments to their security policies for 
others. The potentially more serious general issue is that a network 
security manager may think that "split tunneling" is still controlled, 
even though it might not be, and that this may have slipped through 
their test and acceptance processes if they weren't as thorough as in 
the example.

I checked RFC 4942 and RFC 6169 and conducted a more general search but 
I could not locate any mention of older software manipulating the IPv4 
routing table, but failing to be aware of the IPv6 portion of the table. 
I could of course missed one or more important references in my 
admittedly rather cursory search.

Just thought that "forewarned is forearmed."

So should this sort of risk at the integration level be addressed by 
v6ops at all?

Are there more examples of these integration risks that "everyone knows 
about" but clearly some out there either don't know or don't communicate?

Is there a recommended test methodology equivalent of the "time travel" 
regression testing used in Millennium?

Is this something that the v6ops WG can act upon to produce an 
educational/ informational RFC of common pitfalls in transitioning to 
dual stack environments and how to avoid them?

Or is this just "operational noise", or "too vague," or is best kept off 
the list and discussed elsewhere, or taken on a case by case basis?

Your thoughts.....

Regards,
RayH