Re: trunk ipv6 split-stack configure test issues

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Sat, 15 May 2010 10:42:38 +0200

lör 2010-05-15 klockan 17:56 +1200 skrev Amos Jeffries:

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

Accepting requests should work already in 3.1, but user need to
configure two http_port one for ipv6 and one for ipv4.

But yes, forwarding would not work well. To do that right we need the
connection setup done in a sensible manner, i.e. what you are working
on. But at least you can accept requests from IPv6 and forward to IPv4
reasonably reliably by setting tcp_outgoing_address to your IPv4
address. And with the dual tcp_outgoing_address option selected by ipv6
dst acl you may even be able to make it work for ipv6 destinations.

> 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.

Hmm.. so why is it only the IPV6_V6ONLY test that fails?

Do they perhaps differ in autoconf cache? The IPV6_V6ONLY test is not
cached, which it probably should be.

But I honestly do not see why we need to configure run test for any of
this, other than that we can compile. A Squid compiled with IPv6 support
will now run just fine even if the IPv6 stack is not there at runtime,
and the only use of IPV6_V6ONLY in 3.1 is to enable mapped mode in case
it's not the default. Having run test in configure should be avoided as
much as possible as it makes it more or less impossible to
cross-compile.

> 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.

Yes, and have a number of issues as already discussed.

> 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.

Agreed. Trying to fix this in 3.1 would be messy and quite likely
fragile.

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

That probably marks the v4 addresses as bad now, but depends on what
error the stack returns when using IPv6 stack to connect to IPv4.

Regards
Henrik
Received on Sat May 15 2010 - 08:42:42 MDT

This archive was generated by hypermail 2.2.0 : Sat May 15 2010 - 12:00:09 MDT