httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: Subject: IPv6 patch from Jun-ichiro itojun Hagino San
Date Fri, 06 Aug 1999 14:09:54 GMT


On Fri, 6 Aug 1999 itojun@iijlab.net wrote:

> >Something still on our plate, which somehow either dropped
> >off, or I missed us taking a deceision on this: IPv6
> >    * Jun-ichiro itojun Hagino's [PATCH] IPv6 enable patch
> >        ftp://ftp.kame.net/pub/kame/misc/apache-134-v6-19990118.diff.gz
> >        Message-ID: <18586.916662926@coconut.itojun.org>
> >        Status: Lars +1 (on concept) Dirkx +1 (tested)
> 
> 	Hello, happy to hear from you again,
> 	I have more recent patch for 1.3.6 in the same directory
> 	as above.  Several bugs are eliminated so please be sure to 
> 	grab the latest one.

Ah, I see, yes I see what you mean. My compliments.

Well, someone (me?) will have to re-work it for apache 2.0 (see
dev.apache.org) so that we can look into the issues you address.
 
> 	There are several issues (or headaches) right now:
> 	- API changes.  there are places where IPv4 addresses are put into
> 	  u_long, or struct in_addr.  For IPv6 support (it really is to make
> 	  the code independent of address family) we need to use
> 	  struct sockaddr and its variants throughout the structures.
> 	  I've fixed them but it made some of visible structs incompatible
> 	  with non-IPv6 apache.

As with Apache 2.0 we are going to break all compatibility with existing
1.x modules; do you have any suggestions as to what would be the perfect
approach ? Any Radical Ideas ?

> 	- Portability on build process.  Since IPv6 is now being deployed,
> 	  There are too many posibilities for header file/library file
> 	  locations.  Some of them put those in /usr/local/lib/libinet6.a,
> 	  our KAME patchkit put them in /usr/local/v6/lib/libinet6.a,
> 	  and integrated ones put those in /usr/lib/libc.a.
> 	  We have GNU autoconf code for guessing IPv6 platforms (and link
> 	  proper files as necessary).  I have no chance to check apache 2.x
> 	  so I dunno if it is useful or not.

This is something I am not that worried about right now; The people
rolling out IPv6 know what they are doing; and can fiddle with makefiles
where needed. It is only in half a year or a year time at the earliest
that we have to start thinking of how to deal with the masses.

> 	- Multithread issues.  Some of IPv6-ready name resolution libraries
> 	  are not thread safe, though specs suggest to implement them
> 	  in thread-safe mannar.

I've been following the mailing list here, and I am not worried at all,
this will slowly solve itself soonish, and the current IPv6 users are
informed enough.
 
> 	Other than that, my patch works just fine - I use the code on serious
> 	commercial web servers (yes, commercial web servers on IPv6 network,
> 	I'm serious :-P) as well.
 
It sure does, though I have to admit that I only once have installed a web
server at an large ISP in a commercial production service on IPv6. And
quite a boring one at that, just static content about... IPv6 rollout :-) 
All my other testing was in a more artificial lab environment. 

> 	I'm very happy to help 2.x integration.

Great ! That is truly good news given your expertize. Have a look at
apache 2.0; you can always pull a tarball from  

	http://dev.apache.org/from-cvs/apache-2.0/

or use cvs/cvssup. You've noticed the last document on how to express IPv6
in URL's. 

http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-url-literal-0?.txt

that is something we need to fold in as well. I've a gut feeling that that
is going to take a bit of care and quite a few changes. Esp. if we want to
keep configuration syntax friendly.

Dw.




Mime
View raw message