Re: integrating husni's ipv6 patch into squid-2

> I've been looking at husni's IPv6 patch, and although the implementation
> is not as clean as amos' stuff, it seems to be relatively straightforward.
>
> The changes are roughly as follows:
>
> Stuff which can happen with minimal impact to the v4-ness of Squid-2:
>
> * in_addr and sockaddr_in -> struct sockaddr_storage
> * inet_ntoa -> sockaddr_ntoa
> * he hard-codes assignments (via memcpy) and some port lookups rather than
> properly abstacting that stuff out; which should be done and should be
> relatively painless.
> * he also hardcodes the sockaddr_storage assembly (ie, v4 or v6) and this
> should
> be abstacted out too.
>
> Stuff to support v6-ness in the core code, but not actually support v6
> requests:
>
> * the dns changes
> * comm* modifications to create v6 tcp/udp sockets
>
> The harder stuff:
>
> * the ACL changes!
>
> And the stuff that enables ipv6 support:
>
> * flags in fwdState to indicate -v4 or -v6
> * url parsing changes
> * fqdncache changes
> * forward.c logic changes to handle trying v6 and/or v4 as appropriate.
>
> Unfortunately quite a bit has changed since he put this work together and
> I'm
> having a bugger of a time merging it into Squid-2.HEAD. Gah, makes me wish
> we had actually merged his stuff into 2.6. Anyway.
>
> I think it'd be a good exercise to do something similar to Amos' work, and
> stage the integration of v6 into Squid-2. I suggest starting with the
> first
> chunk - migrating in_addr and sockaddr_in to sockaddr_storage, and tidying
> up all the code that breaks on that. We can still throw v4 around
> everywhere,
> but at least its in a future-extensible format. It doesn't have to lead
> immediately to more IPv6 related code, but making the stand that all
> future
> -2 changes should be (somewhat) v6 ready would be a good move.
>
> Thoughts?
>

You begin to see why I threw out all the initial attempts at IPv6 C-styles.

Xuan and Rafael spent 4 months on trying squid-3 C-style and never got far
beyond the step-1 you are suggesting starting at.

You don't mention the SNMP extension issues, external helper issues,
transparency and v6-port TOC issues, bridging issues, pooling issues
(which 3 still has!), FTP extensions, v4-mapped-v6 issues in v4-only
components. There are a LOT of things IPv6 needs to match IPv4 support in
squid.

You could poach many of them from -3 I suppose, but to back-port it to
sockaddr castings would be more work than it took me to write in the first
place.

Amos
Received on Mon Feb 04 2008 - 20:43:22 MST