IPv6 Patch

Tomash Brechko tomash.brechko at gmail.com
Wed Jan 30 20:03:45 UTC 2008

On Wed, Jan 30, 2008 at 11:07:54 -0800, Brian Aker wrote:
> Drepper's paper is not wrong, it just does not think through the  
> actions of poor DNS entries.
> One thought I had this morning was perhaps toss an error if ai->next  
> shows that there are multiple binding addresses.

The DNS fear is stretched too far.  You are basically saying that one
should never ever bind to site-local address because there's a
possibility that it is visible form the outside, and is not protected
by the firewall.  But why you bind to the first address then?  As the
second Drepper's paper says, there's _no guarantee_ that the first
address is the right one, or not the site-local one.  Anyways, I can't
add more arguments here apart from citing Drepper again:

  The most important thing when using getaddrinfo is that all results
  are used in order. To stress the important words again: all and
  order. Too many (incorrect) programs only use the first result.

Hope you know what you are doing (and to be frank, hope this won't get
to memcached ;)).

> OSX 10.5 has issues with IPv6 and binding for UDP right now, which is  
> why I left it that way (but then 10.5).


> I've never found an authoritative that says you can get away with just  
> setting IPPROT and not SOCK (or vice versa).

At least on Linux, man 7 tcp begins with

  tcp_socket = socket(PF_INET, SOCK_STREAM, 0);

example.  POSIX says,

         Specifies a particular protocol to  be  used  with  the  socket.
         Specifying a protocol of 0 causes socket() to use an unspecified
         default protocol appropriate for the requested socket type.

I thought is is customary to specify zero protocol number, and let the
system choose the appropriate.  But alright, if you prefer to
hard-code it, it won't make any harm.  Not in the near future at

As everything has been said, I let the one to push the patch to decide on
one vs many address issue ;).

   Tomash Brechko

More information about the memcached mailing list