Re: squid-2.5 ipv6 --- dead code or WIP?

On Wed, 2003-02-05 at 16:28, Chris Wedgwood wrote:
> On Wed, Feb 05, 2003 at 02:03:20PM +1100, Robert Collins wrote:
>
> > Yep. first off, the IN_ADDR abstraction.... A local class to
> > encapsulate that abstraction, and any other related ones, may be
> > useful, and thus less ugly.
>
> IN_ADDR is part-way there already. What is really needed is something
> like hostaddr_t (better name anyone?)

class HostAddress;

:}.

> and a plethora of function to
> deal with this... such a patch it itself would be enourmous I should
> think though (we also need to audit all uses of INADDR_ANY &
> INADDR_BROADCAST as these are magical values for many things such as
> disabling functions or 'same as incoming address'). Ick.

well, can be done piecemeal:
1) introduce class HostAddress and provide a conversion operator to the
type that is used in existing IN_ADDR code (speaking generally cause I'm
too lazy right now to crack open an editor).
2) one struct at a time, change from the existing type to the
HostAddress type.
2a) merge to head after every 4-5 structs have been converted.
3) start introducing methods rather than direct data access to fields of
the the type.
3a) merge after every 3-4 source files are complete.

> There are also various users of s_addr, etc. that I really don't
> understand, for example in the delay pools code we have:
>
> host = ntohl(ch.src_addr.s_addr) & 0xff;
>
> host = ntohl(ch.src_addr.s_addr) & 0xffff;
>
> and similar. I really have no idea what the intention there is, I'm
> guessing it's some kind of implicit classful-netmask logic or
> something?

Yes. It's kindof ugly, and more clear in my recent rewrite of delay
pools. The first one gets the least significant octet of the ip address.
The second gets the two least significant octets.

...
> The crux of the issue is that where various addresses in a network are
> unique in IPv4 land, there may not be in IPv6 land.
>
> Some quick ramblings off the top of my head...
>
> * IPv4 encapsulated IPv6 addresses of the form ::ffff:a.b.c.d
> mean existing IPv4 ACLs will fail as-is

hmm, perhaps we should canonise all ip4 acl values to encapsulated
values?

> * IPv6 localhost is ::1 --- but we can also see inbound connections
> as ::ffff:127.0.0.1 ?

I think my encapsulation suggestion would handle that.

> * Hosts (other-hosts, cache clients for example) in the same subnet
> could appear as
>
> ipv6-address of other-host
> ipv4-mapped-ipv4 address of other-host
> site-local address of other-host
>
> Maybe ACLs should be abstracted so the concept of "localhost" is "all
> address that match localhost" and the concept of a network is "all
> reasonable representations of this network"? This would also means
> something like
>
> acl foo src some.host
>
> would work when some.host has multiple AAAA and/or A records to match
> *any* of them?

Yes, I like that idea.

> > Anyhoo, if you are interested, sign up on sourceforge as a
> > developer, and email me /the list your user name.
>
> My time is very limited and my original post was basically a "hey,
> this doesn't work by default but it's not hard to get it
> sorta-working, what future plans are there to fix and merge this
> stuff" sort thing.
>
> I'd really like to have suggestions on how to deal with these issues
> first and some idea of who else is prepared to work with these
> potentially nasty issues.

I don't have much in the way of ip6 infrastructure here to play with..
but I can offer the following resources:
*) Design input, and tie breaker if you are stuck on a fence :].
*) Regular review, and subsequent merging of tidy changes, to reduce the
maintenance load long term.
*) Possibly some hacking, but can't guarantee this.

There is also another hacker with what appears to me to be a similar
low-key interest in gettting ipv6 going - perhaps some collaboration
would be fruitful?

sajd (the other interested hacker) hangs out on irc (openprojects.net
channel #squiddev) fairly often.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.