IPv6 STATUS - Detailed RFC's...

Hi all:

Since the first attempt on July to boot-up an Squid3-IPv6 server, I have
been studying in a deep way the IPv6 socket API and what RFC's say about a
possible mixed scenario IPv6-IPv4...

Following there are some notes on RFC's supporting Squid3-IPv6 code
porting...

1. - "Basic Socket Interface Extensions for IPv6"

It is _mandatory_ to be read by line-code programmers...

RFC2133 (1997) key:gethostbyname2( , ), res options
RFC2553 (1999) key: getiphostbyname(,)
RFC3493 (2003) key: getnameinfo(,)

Each one obsoletes previous, but it is recommended to read every RFC, to
understand actually Squid3-IPv6 status

Actually, squid3/squid3-ipv6 is implemented complying RFC2133(1997)... Why ?
Because its change was semi-mechanical and "gethostbyname2(,)" is widely
implemented on almost any Unix-box... In fact, it is about a simple (naïve)
pre-process strategy...

By the way, the scenario is IPv6-only, in the sort set by documents at point
3. Clearly this does not fit Squid3 requirements, but I could not implement
an IPv6-IPv4 approach following the procedures described at RFC2133,
because:
        - either not all features were available at a synchronized (up to
2005) GNU box, since they were deprecated and dropped...
        - I could not integrate the "C" issues into Squid3 "C++" code. An
unreadable bunch of errors were reported by the compiler

I tried to lift the code it into RFC2553(1999), also mechanical and
straightforward, but since RFC2553(1999) is deprecated, at least GNU-Linux
boxes do not implement "getiphostbyname() functions"... Only "man
getiphostbyanme" is available

So the things, I tried again lift it into RFC3493(2003), the so called
"protocol independent", but then the little chaos start...
Changes are not so syntactically straightforward, and they MAY INTERFERE to
the main line of Squid3 overall design...

RFC3493 binds all the calls "socket(),connect(), bind() and getnameinfo()"
on an execution context under a common structure "struct addr_info" ...and
Squid3 (Squid2.5 inherited), as 99% of traditional IPv4 network software,
asks for socket() in a routine, make a DNS search on another and lastly
connects or bind in another one... Hence it is not trivial to port Squid3
following RFC3493, WITHOUT refactoring the main design line of Squid3, and
clearly this aspect exceeds my capability as just a "code-porter" replacing
some routines by others...

A very interesting software already available for IPv6 is Apache... You can
take some ideas from it. The Apache Software relies on a sort of RunTime
system, providing elementary services to the server... In fact, the network
subsystem is a customized-apache-wrapper of the tradictional BSD
interface... Apache server does not call to "socket();connect()" but calling
a wrapper somewhay like "ap_connect()" ( please this is not very precise ).

2.- "Advanced Sockets Application Program Interface (API) for IPv6"

Recommended reading, but only a few parts of Squid3-Code may be intereseted
on such advanced and low-level features.

RFC2292 (1998)
RFC3542 (2003)

The latter obsoletes the former.

3.- "Application Aspects of IPv6 Transition"

RFC4038 (2005)

yes, Mars 2005 !! (note that Squid3-IPv6 tests were on July-2005)

A sort of possible transition scenarios IPv4-IPv6 is fully described....

This _document_ SHOULD be MANDATORY FOR SQUID3 MAIN LEADERS AND DESIGNERS,
say Wessels, Serassio, Nordstrom...

It's well understood that I can contribute as a modest "local code"
programmer a bit experienced with UNIX development philosophy, serving
others' strategies on the main design line. Remember last note on point 1
justifying how to get an IPv6-IPv4 compatible scenario is not so trivial as
it may seem, at least on my experience...but I cannot to start such a deep
change in order to refactoring a very important part of Squid3...

 I hope these notes to contribute to clarify the ideas about the design...By
the way, I suggest that Squid3 should be available on bosex implementing
IPv6-API, (almost everyone do).
The user will declare after if it wants to enable IPv6, because it has
connectivity, or just only IPv4. The RFC493 "protocol independent" allows
that under the same code... Hence IPv6-API implemented should be a
requirement. Not so the optional compilation mode...

Regards.
Received on Wed Oct 19 2005 - 02:30:44 MDT