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...@attglobal.net> on 2002/09/05 17:43:52 UTC

IPv6 capability and name lookup cost

(this discussion assumes Apache has IPv6 capability)

There are some situations during normal web server operation where
resolver calls are made to find addresses associated with names and we
have no clue whether or not the name has an IPv6 address associated with
it.  Forward proxy is a good example of this.  apr_sockaddr_info_get()
will return all addresses associated with the name, and some existing
resolvers first do IPv4 name lookup followed by IPv6 name lookup in
order to implement this.  The lack of overlap results in higher elapsed
time; the inability to bundle the queries in a single flow results in
higher kernel/library CPU.  A resolver cache can help with this.

In most cases, there is no IPv6 address.  In some cases where there is
an IPv6 address, using the IPv4 address would be sufficient.

A useful performance improvement can be achieved by allowing the
administrator to select the following algorithm:

  lookup IPv4
  if at least one IPv4 address was found, we're done
  lookup IPv6

The benefit is clear.  The drawback is that if IPv4 addresses were found
but those addresses are not usable (e.g., IPv4 addresses disabled on
that machine but admin didn't remove from DNS), we wouldn't then be able
to try the IPv6 addresses (without much more work).  (But the admin
chose the behavior so what do I care :) )

The bulk of the implementation would be in APR (new flag to
apr_sockaddr_info_get()), but Apache would have a configuration
mechanism to allow the administrator to turn on the flag.  Up for
discussion would be if there is an Apache-wide preference or whether
different components/modules (core, mod_proxy_foo, etc.) should have
separate
knobs.  Personally I'd prefer an Apache-wide preference which would be
respected by core and by any modules
distributed by us.  Any 3rd-party modules could/should respect the
configuration too.

Comments?

(If APR has no IPv6 capability, the new processing flag would be ignored
since we're only going to do the IPv4
lookup anyway.)

-- 
Jeff Trawick

Re: IPv6 capability and name lookup cost

Posted by David Reid <dr...@jetnet.co.uk>.
+1 for this and apache wide config flag.

david

> (this discussion assumes Apache has IPv6 capability)
> 
> There are some situations during normal web server operation where
> resolver calls are made to find addresses associated with names and we
> have no clue whether or not the name has an IPv6 address associated with
> it.  Forward proxy is a good example of this.  apr_sockaddr_info_get()
> will return all addresses associated with the name, and some existing
> resolvers first do IPv4 name lookup followed by IPv6 name lookup in
> order to implement this.  The lack of overlap results in higher elapsed
> time; the inability to bundle the queries in a single flow results in
> higher kernel/library CPU.  A resolver cache can help with this.
> 
> In most cases, there is no IPv6 address.  In some cases where there is
> an IPv6 address, using the IPv4 address would be sufficient.
> 
> A useful performance improvement can be achieved by allowing the
> administrator to select the following algorithm:
> 
>   lookup IPv4
>   if at least one IPv4 address was found, we're done
>   lookup IPv6
> 
> The benefit is clear.  The drawback is that if IPv4 addresses were found
> but those addresses are not usable (e.g., IPv4 addresses disabled on
> that machine but admin didn't remove from DNS), we wouldn't then be able
> to try the IPv6 addresses (without much more work).  (But the admin
> chose the behavior so what do I care :) )
> 
> The bulk of the implementation would be in APR (new flag to
> apr_sockaddr_info_get()), but Apache would have a configuration
> mechanism to allow the administrator to turn on the flag.  Up for
> discussion would be if there is an Apache-wide preference or whether
> different components/modules (core, mod_proxy_foo, etc.) should have
> separate
> knobs.  Personally I'd prefer an Apache-wide preference which would be
> respected by core and by any modules
> distributed by us.  Any 3rd-party modules could/should respect the
> configuration too.
> 
> Comments?
> 
> (If APR has no IPv6 capability, the new processing flag would be ignored
> since we're only going to do the IPv4
> lookup anyway.)
> 
> -- 
> Jeff Trawick
> 


Re: IPv6 capability and name lookup cost

Posted by Jeff Trawick <tr...@attglobal.net>.
Ian Holsman <ia...@apache.org> writes:

> > A useful performance improvement can be achieved by allowing the
> > administrator to select the following algorithm:
> >   lookup IPv4
> >   if at least one IPv4 address was found, we're done
> >   lookup IPv6
> >
> I know this sounds stupid, but it is usefull to have a option to do it
> the other way.
> lookup ipv6
> if it's there then use it (we're done)
> lookup ipv4

that's a natural expansion :)

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: IPv6 capability and name lookup cost

Posted by Ian Holsman <ia...@apache.org>.
Jeff Trawick wrote:
> (this discussion assumes Apache has IPv6 capability)
> 
> There are some situations during normal web server operation where
> resolver calls are made to find addresses associated with names and we
> have no clue whether or not the name has an IPv6 address associated with
> it.  Forward proxy is a good example of this.  apr_sockaddr_info_get()
> will return all addresses associated with the name, and some existing
> resolvers first do IPv4 name lookup followed by IPv6 name lookup in
> order to implement this.  The lack of overlap results in higher elapsed
> time; the inability to bundle the queries in a single flow results in
> higher kernel/library CPU.  A resolver cache can help with this.
> 
> In most cases, there is no IPv6 address.  In some cases where there is
> an IPv6 address, using the IPv4 address would be sufficient.
> 
> A useful performance improvement can be achieved by allowing the
> administrator to select the following algorithm:
> 
>   lookup IPv4
>   if at least one IPv4 address was found, we're done
>   lookup IPv6
> 
I know this sounds stupid, but it is usefull to have a option to do it 
the other way.
lookup ipv6
if it's there then use it (we're done)
lookup ipv4

--Ian
> The benefit is clear.  The drawback is that if IPv4 addresses were found
> but those addresses are not usable (e.g., IPv4 addresses disabled on
> that machine but admin didn't remove from DNS), we wouldn't then be able
> to try the IPv6 addresses (without much more work).  (But the admin
> chose the behavior so what do I care :) )
> 
> The bulk of the implementation would be in APR (new flag to
> apr_sockaddr_info_get()), but Apache would have a configuration
> mechanism to allow the administrator to turn on the flag.  Up for
> discussion would be if there is an Apache-wide preference or whether
> different components/modules (core, mod_proxy_foo, etc.) should have
> separate
> knobs.  Personally I'd prefer an Apache-wide preference which would be
> respected by core and by any modules
> distributed by us.  Any 3rd-party modules could/should respect the
> configuration too.
> 
> Comments?
> 
> (If APR has no IPv6 capability, the new processing flag would be ignored
> since we're only going to do the IPv4
> lookup anyway.)
> 



Re: IPv6 capability and name lookup cost

Posted by Jeff Trawick <tr...@attglobal.net>.
"David Reid" <dr...@jetnet.co.uk> writes:

> Looks fine to me.
> 
> What will the order of the returned matches be for All? IPv4 then IPv6 would
> be my suggestion which we should be able to do with the changes you're
> talking about I'd guess.

Alternatively, we could leave it up the the resolver as we do today :)

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: IPv6 capability and name lookup cost

Posted by Jeff Trawick <tr...@attglobal.net>.
Joshua Slive <jo...@slive.ca> writes:

> >>Jeff Trawick <tr...@attglobal.net> writes:
> 
> >>Getting more specific, I envision a directive that works like this:
> >>
> >>NameLookups All|IPv4Okay|IPv6Okay
> 
> Can I suggest "IPLookups", or something along those lines.  That makes
> it clearer that we are talking about looking up an IP address using a
> name, and it also differentiates this from HostNameLookups.

makes sense to me :)

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: IPv6 capability and name lookup cost

Posted by Joshua Slive <jo...@slive.ca>.
>>Jeff Trawick <tr...@attglobal.net> writes:

>>Getting more specific, I envision a directive that works like this:
>>
>>NameLookups All|IPv4Okay|IPv6Okay

Can I suggest "IPLookups", or something along those lines.  That makes 
it clearer that we are talking about looking up an IP address using a 
name, and it also differentiates this from HostNameLookups.

Joshua.


Re: IPv6 capability and name lookup cost

Posted by David Reid <dr...@jetnet.co.uk>.
Looks fine to me.

What will the order of the returned matches be for All? IPv4 then IPv6 would
be my suggestion which we should be able to do with the changes you're
talking about I'd guess.

david

> Jeff Trawick <tr...@attglobal.net> writes:
>
> > A useful performance improvement can be achieved by allowing the
> > administrator to select the following algorithm:
> >
> >   lookup IPv4
> >   if at least one IPv4 address was found, we're done
> >   lookup IPv6
>
> Getting more specific, I envision a directive that works like this:
>
> NameLookups All|IPv4Okay|IPv6Okay
>
> All:      current behavior -- tell resolver to find everything
>
> IPv4Okay: try IPv4 first, don't look for IPv6 unless no IPv4 addresses
found
>           note: if the host is specified in the form of an IPv6
>           numeric address string, APR will do the right thing
> IPv6Okay: try IPv6 first, don't look for IPv4 unless no IPv6 addresses
found
>           note: if the host is specified in the form of an IPv4
>           numeric address string, APR will do the right thing
>
> (potentially we could add something like this in the future, though I
> don't think that is necessary now since it is an optimization for an
> error path:
>   IPv4Only: only look for IPv4 addresses
>   IPv6Only: only look for IPv6 addresses
> )
>
> I guess core should export the information via a function like
>
>   ap_get_name_lookup_opts(apr_int32_t *opts)
>
> which will set a variable to be OR-ed with any other appropriate
> apr_sockaddr_info_get() flags to achieve the proper behavior.
>
> --
> Jeff Trawick | trawick@attglobal.net
> Born in Roswell... married an alien...
>


Re: IPv6 capability and name lookup cost

Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:

> A useful performance improvement can be achieved by allowing the
> administrator to select the following algorithm:
> 
>   lookup IPv4
>   if at least one IPv4 address was found, we're done
>   lookup IPv6

Getting more specific, I envision a directive that works like this:

NameLookups All|IPv4Okay|IPv6Okay

All:      current behavior -- tell resolver to find everything

IPv4Okay: try IPv4 first, don't look for IPv6 unless no IPv4 addresses found
          note: if the host is specified in the form of an IPv6
          numeric address string, APR will do the right thing
IPv6Okay: try IPv6 first, don't look for IPv4 unless no IPv6 addresses found
          note: if the host is specified in the form of an IPv4
          numeric address string, APR will do the right thing

(potentially we could add something like this in the future, though I
don't think that is necessary now since it is an optimization for an
error path:
  IPv4Only: only look for IPv4 addresses
  IPv6Only: only look for IPv6 addresses
)

I guess core should export the information via a function like

  ap_get_name_lookup_opts(apr_int32_t *opts)

which will set a variable to be OR-ed with any other appropriate
apr_sockaddr_info_get() flags to achieve the proper behavior.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...