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?



Adrian

Reply via email to