Here is what I can think of at the moment.

APR:

  resolver functions need reviewing closely; are we using
  getaddrinfo() and getnameinfo() properly?  

  Shouldn't apr_getnameinfo() use a different field (like canon_name) for
  the hostname?  Shouldn't it check some field before calling gethostbyaddr()
  in case we've done the lookup already?

  portability:

    AIX getaddrinfo() is broken for numeric port strings but we don't 
    need to use the aspect which is broken :)  In fact, to avoid the 
    broken issue makes our code go faster.  I'll fix it to work on AIX 
    when I get a chance (waiting for apr-util on cvs.sourcery.org to 
    do anything on AIX)

    another AIX issue: If host is found in /etc/hosts, getaddrinfo()
    doesn't fill in sa_family; maybe we should punt AIX for a while?

    beta test will show other issues :)

Apache core:

  do_double_reverse() could stand to be tested :)

  ap_get_local_host() (server/util.c) doesn't work if we get an IPv6 
  address for our host name because it calls gethostbyname.  I don't
  know how to fix this completely because getaddrinfo() doesn't return 
  aliases and this code can look through the aliases.

  Heck, just look for APR_INET everywhere.  There isn't much to look at.

  testing/reviewing my patch:

    I don't completely understand the _default_/_default4_/_default6_ 
    stuff, some of which is from base Apache and some of which is from 
    the KAME patch.  One of the key hurdles for me is to understand that 
    stuff and see if the variants added by the KAME patch are needed.

    I now prefer a config directive (DefaultFamily) for selecting the
    default address family.  Scratch the command-line parsing crap.
    Use Ryan's idea for EXEC_ON_READ and everything works okay.

Apache support programs:

  logresolve: look at the KAME patch; hmmm... looks like we need to APR-ize
              logresolve enough to use apr_getaddrinfo() and 
              apr_getnameinfo(); it isn't too pretty to put conditional 
              IPv6 support in logresolve; that is a job for APR; we'll have
              to be careful with pools though

Apache documentation:

  Update Listen, NameVirtualHost, and VirtualHost doc to describe how to 
  specify an IPv6 address.

  Update sample configuration files to describe how to specify an IPv6
  address.

Apache modules:

  (I'm not terribly interested in this stuff.  Once the Apache core handles
  IPv6 then we should get as many of the 6bone folks as possible to
  try to use it, and then we will have the real users available to do
  some of this work.  The 6bone folks are early adopters and
  relatively astute technically, so this doesn't seem too far-fetched.)

  this includes:

    mod_log_config (probably nothing, but somebody needs to look at the KAME patch)
    mod_access
    mod_proxy
    mod_unique_id - Ryan suggests using apr_uuid_t's

  get mod_access working with IPv6 addresses; this seems pretty
  straightforward and KAME has it working

  look for who else plays with socket addresses; mod_proxy is a biggie
  and KAME did some work there, but I don't know what we can/should
  hope for in the short term (by 2.0 release) for mod_proxy; I get the
  feeling that it may not be stable yet for IPv4

Tools to use:

Note that the latest 2.8.4dev versions of Lynx handle IPv6 fairly well; I don't k
now how to give it IPv6 numeric address  strings on the command-line though;
my favorite perl script is no good at the moment because my perl was built without 
IPv6 support and I don't want to mess with with the perl build or hack up the perl 
script;

--------------------------
My order of operations:

2) go through the current patch, find anything that is resonable to
   commit by itself, test it in detail, commit

3) goto step 2