Re: IPv6 STATUS - Detailed RFC's...

Some notes to clarify
From RFC-4038. MYNOTEs are of my own:

      +-------------------+
      | appv4 | (appv4 - IPv4-only applications)
      +-------------------+
      | TCP / UDP / others| (transport protocols - TCP, UDP,
      +-------------------+ SCTP, DCCP, etc.)
      | IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
      +-------------------+
 
      Case 1. IPv4 applications in a dual-stack node.

MYNOTE: squid-2.5 is ALREADY on case 1, since most popular OS implements IPv6
(linux, solaris,*bsd,...)(irix?,hp-ux?)
 
      +-------------------+ (appv4 - IPv4-only applications)
      | appv4 | appv6 | (appv6 - IPv6-only applications)
      +-------------------+
      | TCP / UDP / others| (transport protocols - TCP, UDP,
      +-------------------+ SCTP, DCCP, etc.)
      | IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
      +-------------------+
 
      Case 2. IPv4-only applications and IPv6-only applications
              in a dual-stack node.

MYNOTE; The squid3/squid3-ipv6 as it is NOWADAYS (date 04/November/2005) is on
case 2.
 
      +-------------------+
      | appv4/v6 | (appv4/v6 - applications supporting
      +-------------------+ both IPv4 and IPv6)
      | TCP / UDP / others| (transport protocols - TCP, UDP,
      +-------------------+ SCTP, DCCP, etc.)
      | IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
      +-------------------+
 
      Case 3. Applications supporting both IPv4 and IPv6
              in a dual-stack node.

MYNOTE: The target on long term for release Squid-3.X
 
      +-------------------+
      | appv4/v6 | (appv4/v6 - applications supporting
      +-------------------+ both IPv4 and IPv6)
      | TCP / UDP / others| (transport protocols - TCP, UDP,
      +-------------------+ SCTP, DCCP, etc.)
      | IPv4 | (IP protocols supported/enabled in the OS)
      +-------------------+
 
      Case 4. Applications supporting both IPv4 and IPv6
              in an IPv4-only node.

MYNOTE: Two subcases of my own:
        4a. IPv6 supported bust disabled (Same code as previous, just configure
--disable-IPv6)
        4b. IPv6 unsupported and disabled. ( It seems very hard to keep this with
the same code...)
 
         Figure 1. Overview of Application Transition

rfc4038 concerns Application Transition scenario.
rfc2133 conerns Basic Socket IPv6 scenario.

Clearly 2133 is deprecated, though functional. 2553 and 3493 obsolete it.

TODO ROADMAP:
-------------------------
Just now: Tagging the private-branch with Sticky tag "rfc4038-case2-2133"

Short term: to reach rfc4038-3case-rfc2133 ( Almost done, now testing)

Our medium term is to get rfc4038-3case-rfc2553

long term rfc4038-3case-rfc3493 (Remember that this implies "refactoring"
design)

> > 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...
>
> Yes, as long as the compile environment supports IPv6, and the resulting
> code can also run on an IPv4 only host without an IPv6 kernel.
>

To become precise, "with an IPv6 kernel supported but disabled", to fit 4a.
If the compile environment supports IPv6, the kernel should implement it...

> But imho we still need to support IPv4 only environments, including where
> the compile environment is not capable of compiling IPv6 specific code.
> But it's not a hard opinion.
>
Then, the code will result duplicated, one for IPv4 and other for IPv4-IPv6...

> Regards
> Henrik
Received on Fri Nov 04 2005 - 01:40:55 MST