httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject IPv6 notes
Date Mon, 04 Dec 2000 20:39:48 GMT
Shown below is a very rough sketch of work to be done to achieve
parity with the KAME level of function in 1.3.

The main external interface changes are the first two issues
listed below.  I have had much of this working in the past and
hope to get it ready to commit in the next couple of days.  

Any concerns about the new command-line parameters and the changes to
Listen and NameVirtualHost?  Old configs still work; if you want to
code an IPv6 numeric address string you need to use two separate parms
for host and port.


Apache todos (some minor bits of code here and there omitted):

1) listen and vhost directives and internal structures need to 
   allow IPv4 or IPv6 addresses

   Listen and NameVirtualHost change from TAKE1 to TAKE12 so that
   the port can be provided as a separate parm when the host is
   an IPv6 numeric address string  (what the fsck is "fe80::1:81" 
   -- fe80::1 with port 81 or fe80::1:81 with the default port?)

2) add default family concept and -4 and -6 command-line switches
   for overriding it

   this is used for ambiguous directives (i.e., listen 8080)

   unlike with KAME, we'll default to letting APR figure out the
   family instead of simply IPv6 since on some of our platforms
   (e.g., Linux) it looks like we have IPv6 support at config time
   but it may or may not be enabled in the kernel

3) logresolve

   Support IPv6 resolution too

4) mod_access

   pretty simple changes to support IPv4 addresses/networks on 
   "allow from" and "deny from"

5) mod_unique_id

   Here are the comments from README.v6 in the KAME patch:

	Originally mod_unique_id used IPv4 address as a seed for UNIQUE_ID,
	and took IPv4 address registered onto DNS for the hostname (UNIX
	hostname taken by gethostname(3)).  Therefore, this does not work
	for IPv6-only hosts as they do not have IPv4 address for them.

	Now, UNIQUE_ID can be generated using IPv6 address.  IPv6 address can
	be used as the seed for UNIQUE_ID.
	Because of this, UNIQUE_ID will be longer than normal apache.  This
	may cause problem with some of the CGI scripts.
	The preference of the addresses is based on the order returned
	by getaddrinfo().  If your getaddrinfo() returns IPv4 address, IPv4
	adderss will be used as a seed.
	Note that some of IPv6 addresses are "scoped"; If you happened to use
	link-local or site-local address as a seed, the UNIQUE_ID may not be
	worldwide unique.

	If longer UNIQUE_ID causes a problem, define SHORT_UNIQUE_ID in
	mod_unique_id.c.  In this case, length of UNIQUE_ID will be kept the
	same.  However, for IPv6 addresses mod_unique_id.c will use the last
	32bit (not the whole 128bit) as the seed.  Therefore, there can be
	collision in UNIQUE_ID.

	The behavior should be improved in the near future; we welcome your

6) mod_proxy :(

7) we may need a --disable-ipv6 flag to be used on systems where IPv6 support
   is spotty and/or our code doesn't work correctly and nobody can fix
   it for one reason or another


APR todos:

1) apr_snprintf() and friends...  

   maybe... I don't see any code in Apache 1.3 or Apache 2.0 which uses this.  
   The KAME folks use it in their modifications to http_vhost.c.

   Change %pI to take struct sockaddr * instead of just struct 
   sockaddr_in *.

2) is David's double reverse lookup routine in APR yet?

3) work out config kinks...

   one current one: we don't find getaddrinfo() on Tru64 because they rename 
   getaddrinfo() in <netdb.h> 

   there are surely other problems on machines which APR/Apache
   developers don't use on a regular basis

4) we may need a --disable-ipv6 flag to be used on systems where IPv6 support
   is spotty and/or our code doesn't work correctly and nobody can fix
   it for one reason or another

Jeff Trawick | | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message