You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/12/04 21:39:48 UTC
IPv6 notes
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
inputs.
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 | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: IPv6 notes
Posted by David Reid <dr...@jetnet.co.uk>.
> > > 2) is David's double reverse lookup routine in APR yet?
> >
> > Nope.
>
> yeah; that was just a hint :)
OK hint taken (:)), but I thought it wasn't added as you had some issues
with it? Could just be all this cosmis radiation and early mornings
screwing with my memory again...
david
Re: IPv6 notes
Posted by David Reid <dr...@jetnet.co.uk>.
That looks like the one.
+1 for Greg's "we'll stick to the rfc's".
david
> Greg Stein <gs...@lyra.org> wrote:
> > Isn't there an RFC or something for using IPv6 addresses in URLs? That
spec
>
> RFC2732?
>
Re: IPv6 notes
Posted by Hiroyuki - SPIKY - Hanai <ha...@imgsrc.co.jp>.
Greg Stein <gs...@lyra.org> wrote:
> Isn't there an RFC or something for using IPv6 addresses in URLs? That spec
RFC2732?
--
hiro hanai / IMG SRC, Inc.
hanai@imgsrc.co.jp
Re: IPv6 notes
Posted by Jeff Trawick <tr...@bellsouth.net>.
"David Reid" <dr...@jetnet.co.uk> writes:
> As soon as it's working +1 for adding it ASAP.
should be today... I thought I had it done but I realized I need to
support strings like "8080" in addition to strings like
"hostname:8080" so that it can be used for the Listen directive (in
addition to ab.c, NameVirtualHost directive, and more)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: IPv6 notes
Posted by David Reid <dr...@jetnet.co.uk>.
As soon as it's working +1 for adding it ASAP.
david
> The current code (not compiled) is below. We could have such a
> function build an apr_sockaddr_t instead of separate addr and port,
> but that may lead to further confusion, with apps trying to pass it to
> apr_bind(), apr_connect(), etc.
>
> static apr_status_t apr_parse_addr_port(char **addr,
> apr_port_t *port,
> const char *str,
> apr_pool_t *p)
> {
> const char *colon;
>
> #if APR_HAVE_IPV6
> if (*str == '[') {
> const char *end_bracket = strchr(str, ']');
> char addrbuf[INET6_ADDRSTRLEN];
>
> if (!end_bracket) {
> return APR_EINVAL;
> }
> colon = strchr(end_bracket + 1, ':');
>
> *addr = apr_palloc(p, end_bracket - str + 2);
> mempcy(*addr,
> str + 1,
> end_bracket - str + 1);
> (*addr)[end_bracket - str + 1] = '\0';
> if (apr_inet_pton(AF_INET6, *addr, &ipaddr) != 1) {
> return APR_EINVAL;
> }
> }
> else
> #endif
> {
> colon = strchr(str, ':');
> *addr = apr_palloc(p, colon - str + 1);
> memcpy(*addr, str, colon - str);
> (*addr)[colon - str] = '\0';
> }
>
> if (colon) {
> *port = atoi(colon + 1);
> if (!*port) {
> return APR_EINVAL;
> }
> }
> else {
> *port = 0;
> }
> return APR_SUCCESS;
> }
Re: IPv6 notes
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> Isn't there an RFC or something for using IPv6 addresses in URLs? That spec
> would need to define how an IP/port pair is specified. I would suggest that
> we use that in preference to anything.
Yessir... the format Ryan mentioned is the RFC 2732-directed
format... I am playing with a parse routine now which will parse a
address[:port] specification and handle stuff like "[fe80::1]:1080". I put similar
code in ab recently but it did not take extra steps to make sure that
[] was used only in valid contexts (IPv6 numeric address strings).
The current code (not compiled) is below. We could have such a
function build an apr_sockaddr_t instead of separate addr and port,
but that may lead to further confusion, with apps trying to pass it to
apr_bind(), apr_connect(), etc.
static apr_status_t apr_parse_addr_port(char **addr,
apr_port_t *port,
const char *str,
apr_pool_t *p)
{
const char *colon;
#if APR_HAVE_IPV6
if (*str == '[') {
const char *end_bracket = strchr(str, ']');
char addrbuf[INET6_ADDRSTRLEN];
if (!end_bracket) {
return APR_EINVAL;
}
colon = strchr(end_bracket + 1, ':');
*addr = apr_palloc(p, end_bracket - str + 2);
mempcy(*addr,
str + 1,
end_bracket - str + 1);
(*addr)[end_bracket - str + 1] = '\0';
if (apr_inet_pton(AF_INET6, *addr, &ipaddr) != 1) {
return APR_EINVAL;
}
}
else
#endif
{
colon = strchr(str, ':');
*addr = apr_palloc(p, colon - str + 1);
memcpy(*addr, str, colon - str);
(*addr)[colon - str] = '\0';
}
if (colon) {
*port = atoi(colon + 1);
if (!*port) {
return APR_EINVAL;
}
}
else {
*port = 0;
}
return APR_SUCCESS;
}
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: IPv6 notes
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Dec 06, 2000 at 10:42:42AM -0800, rbb@covalent.net wrote:
>
> > > > 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?)
> > >
> > > I thought that about a year ago we talked about using
> > > [ip_addr]:port. That may or may not be correct, but it is an idea.
> >
> > While "[ip_addr]:port" is uglier IMHO, it seems reasonable to me to
> > use it throughout since it works in all contexts. I'll double check
> > on the KAME mailing list to see if there is any magic justification
> > for using the TAKE12 style instead.
>
> I agree it is uglier, but I think it is a bit more obvious with regard to
> just what we are doing.
Isn't there an RFC or something for using IPv6 addresses in URLs? That spec
would need to define how an IP/port pair is specified. I would suggest that
we use that in preference to anything.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: IPv6 notes
Posted by rb...@covalent.net.
> > > 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?)
> >
> > I thought that about a year ago we talked about using
> > [ip_addr]:port. That may or may not be correct, but it is an idea.
>
> While "[ip_addr]:port" is uglier IMHO, it seems reasonable to me to
> use it throughout since it works in all contexts. I'll double check
> on the KAME mailing list to see if there is any magic justification
> for using the TAKE12 style instead.
I agree it is uglier, but I think it is a bit more obvious with regard to
just what we are doing.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: IPv6 notes
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> > 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?)
>
> I thought that about a year ago we talked about using
> [ip_addr]:port. That may or may not be correct, but it is an idea.
While "[ip_addr]:port" is uglier IMHO, it seems reasonable to me to
use it throughout since it works in all contexts. I'll double check
on the KAME mailing list to see if there is any magic justification
for using the TAKE12 style instead.
> > -----------------------------------------------------------------------
> >
> > 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 *.
>
> This should change to take an apr_sockaddr_t regardless, shouldn't
> it?
that sounds reasonable
> > 2) is David's double reverse lookup routine in APR yet?
>
> Nope.
yeah; that was just a hint :)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: IPv6 notes
Posted by David Reid <dr...@jetnet.co.uk>.
> > 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 *.
>
> This should change to take an apr_sockaddr_t regardless, shouldn't it?
If we're not using this then perhaps we should just drop support for
sockaddr's from apr_snprintf and have people use the functions we provide as
part of the networking code? It might be easier and is less code to
maintain...
david
Re: IPv6 notes
Posted by rb...@covalent.net.
> 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?)
I thought that about a year ago we talked about using
[ip_addr]:port. That may or may not be correct, but it is an idea.
> 5) mod_unique_id
>
> Here are the comments from README.v6 in the KAME patch:
<snipped for brevity>
Does using apr_uuid_t's solve this problem completely?
> 6) mod_proxy :(
I would say ignore mod_proxy for now. The proxy is not working at all
after the move, and it will take some time to get it working again.
> -----------------------------------------------------------------------
>
> 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 *.
This should change to take an apr_sockaddr_t regardless, shouldn't it?
> 2) is David's double reverse lookup routine in APR yet?
Nope.
Just some thoughts I had.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------