Re: trunk ipv6 split-stack configure test issues

Henrik Nordström wrote:
> fre 2010-05-14 klockan 18:20 +1200 skrev Amos Jeffries:
>
>> The problem is that the flag IPV6_V6ONLY is a standard define. It's
>> present on all IPv6 systems. The only way to identify the stack
>> operation, is to use it and see what error comes back.
>
> Is there stacks having this define but not allowing the setting to be
> changed? My understanding is that they all support the option just
> differing in the default setting?

WindowsXP has true split-stack. Duplicate TCP stacks non-interacting. It
is neither provided nor works AFAIK.

MacOSX and OpenBSD provide it but do not permit it to be changed in
their non-mappping dual stack's. It's defined but errors if set.

Vista, Windows7 defaults to the non-mapping dual-stack, but provides
mapping when its set manually.

Linux, FreeBSD, NetBSD, Dragonfly are the opposite of Vista.

I'm not sure of the Unix' situation. I assume they also have one of the
KAME-derived dual stacks. Though whether its mapping or not we have yet
to discover.

>
> For general operation we should just settle for one model I think, but

Currently Squid is coded for hybrid-mode due to the lower resource
usage. Less FDs and smaller internal code handling special cases in
Squid. Smaller stack size in the kernel.

But that leaves us without support for v6 on MacOSX and OpenBSD, and
WindowsXP.

> perhaps provide the option for listening ports enabling the option of
> having an IPv6 wildcard port which does not listen to IPv4.

Okay. Makes sense. Would be useful for any mode and easy to implement.

>
>> Systems with v6 disabled should not be passing the allocation of
>> PF_INET6 sockets test earlier than the mapping test.
>
> Wy? They can compile IPv6 code just fine, just not run it without also
> loading the ipv6 stack...
>

The PF_INET6 is a run-test. If it can't provide a socket it currently
blocks the other tests which probe the properties of a PF_INET6 socket.

These tests can be made run-time once the split-stack support works.
Your commReset() fixes did seem to push past the hangup I was seeing there.

  The blocker issue is now that outbound sockets FD are opened before
the destination protocol is known and thus default to IPv6. This will
happen regardless of whether using split-stack or non-mapping
dual-stacks. Only the hybrid mapping-enabled stacks can cope with it
since they provide protocol agnostic sockets. I don't see this as a
fixable problem for 3.1. The comm re-structure I'm working on now will
fix this for 3.2.

Test Case:
  Request a v4-only website from Squid built with:
   --enable-ipv6 --with-ipv6-split-stack

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.3