IPV6 support for MySQL

« previous entry | next entry »
Nov. 27th, 2007 | 10:23 pm

Today I finally had some time to go back and work on refactoring the patch Milos did for his Google Summer of Code project for MySQL. I started doing this about a month ago but hit a snag with my time and wasn't able to get back to it.

Well...

[brian@zim client]$ ./mysql --protocol=tcp --host=::1 --user=root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 5.2.6-alpha-debug-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

So now it is just a matter of a few more cleanups to make it work. I fixed the localhost hack to handle issues with ipv6 having a different scheme for 127.0.01.
I've dropped a source tarball here:
http://download.tangent.org/mysql/mysql-6.1.0-feature-preview.tar.gz

You will need to do a --with-ipv6 and this is a build from source (for some reason our "make dist" is not generating a proper configure file right now...)

Let me be clear about this though, this is a bit of code I am testing. It is working for me, but I know that others (including the driver writers) have an interest in this. There is no support of this, and no promise of when this will go into the main tree. I would love feedback on ipv6 related issues found, but this is not an opportunity for other bugs. Do not even think of putting this into production.

This is also a bit of an experiment for me. I'd like to see if I get any feedback at all. If so I will consider doing stuff like this from time to time. Getting feedback on ongoing code is something I love to have, and I am hoping this turns out well.

Link | Leave a comment
| Share

Comments {13}

(no subject)

from: omnifarious
date: Nov. 28th, 2007 06:24 am (UTC)
Link

I'm not in a position to test it at this time, but I'm always pleased to see more IPv6 support in things. :-)

Reply | Thread

Looks like very bad IPv6 support :-(

from: arekm
date: Nov. 28th, 2007 06:12 pm (UTC)
Link

I'm looking at these changes (it's hard to look at these in form of tarball - patch would be MUCH better).

I'm sorry to tell you but you went to the worse possible approach in converting mysql to IPv6 support. You are simply changing ipv4 only application into ipv6 only one (compile time option is not enough).

The good approach is to make application family independent in a way that single binary can be run on a ipv4 only, ipv6 only or ipv4+ipv6 capable host.

Please read about struct sockaddr_storage (which is big enough to keep ipv4, ipv6 and some other families in it) - use it instead of struct sockaddr_in or struct sockaddr_in6. in_addr and in6_addr also should be not used.

Don't use inet_ntop(). Well, sometimes it's usefull but there are better and nicer functions like these below.

Read about getaddrinfo() and getnameinfo(). These along with sockaddr_storage three most important things in IPv6 world. Every serious application should use these for IPv4+IPv6 support. It's everywhere [1].

1. http://udrepper.livejournal.com/16116.html

Reply | Thread

Re: Looks like very bad IPv6 support :-(

from: krow
date: Nov. 28th, 2007 11:58 pm (UTC)
Link

Thank you for your comments. One of my ongoing thoughts is over older platform support (and oddball platform support). When you write software which has to cover many platforms, not just a few, you have to take in account lowest common denominator.

IPV6 is not everywhere, and making a conscious decision to ignore all platforms, even if they are old, is a very serious issue.

That may be the way it goes in the end though. I do like the number ifdef that was required to make this patch work.

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: arekm
date: Nov. 29th, 2007 06:31 am (UTC)
Link

I didn't suggest to ignore old platforms. Take a look how it's done in openssh. getaddrinfo, getnameinfo have sane fallbacks there to old functions. Defining own sockaddr_storage when system doesn't have it is also very easy. That approach works nicely in all possible ipv4/ipv6 combinations with _single_ binary.

Your approach will end with mostly useless IPv6 support in mysqld. Seen that once - in IrcNet irc daemon. You need two separate binaries of it just because someone wanted to go with easy way and made binaries IPv4 OR IPv6.

Anyway if you only play with that for fun, that's ok. But if this is going into mainline then someone at mysql.com is shooting own foot 8-)

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: krow
date: Nov. 29th, 2007 08:18 am (UTC)
Link

getaddrinfo() looks pretty crummy in Linux. Reading the man page it looks like it is not thread safe and there is no alternative offered (and why someone would write a non-thread safe routine now a days is a bit beyond me).

I can see putting our own sockaddr_storage in MySQL, but I am wondering why.

Every time I approach IPV6 I get the impression that it was done in a pretty half assed manner. We have not bothered to support it, and no one has demanded it at this point. I know that getaddrinfo is supposed to be thread safe but when I read man pages that say it is not... I am left wondering whether or not we should not skip ipv6 for a few more years. Wait till everyone has gotten it right.

We sit behind firewalls, and there I suspect ipv4 will rule for sometime.

If the approach I am taking looks a little tepid, from the view of someone who has to create an application which is more or less ubiquitous, a conservative approach is the only way to go.

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: arekm
date: Nov. 29th, 2007 08:42 am (UTC)
Link

My Linux man page (man-pages-2.68) says at beginning "The thread-safe getaddrinfo(3) function creates one or more socket address structures that can be used by the bind(2) and connect(2) system calls to create a client or a server socket.".

RFC349 explictly states "Functions getaddrinfo() and freeaddrinfo() must be thread-safe."

I'm curious what's written in your man page ? :-)

Linux glibc has even async version of it (http://people.redhat.com/drepper/asynchnl.pdf). This one isn't popular among other systems but well, it's glibc "invented" thing.

sockaddr_storage is just container, big enough to keep (more or less) all the AF_* families that are out there. No one is forcing to use it - it's just comfortable to use.

getaddrinfo() has quite nice interface and you can port your code now to use it while still provide "safe" fallbacks. That way you have modern code and you can simply force your fallback on systems who have crappy getaddrinfo implementation.

PostgreSQL supports IPv6 (even on windows), Apache web server, openssh, exim, bind, mozilla, openldap, X Window and even more (http://www.deepspace6.net/docs/ipv6_status_page_apps.html) apps also do.

Mysql is behind 8-) I'm sure that there is no demand from commercial customers. It's one of features that isn't popular and for now you can only brag at conferences, press materials and such.

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: krow
date: Nov. 29th, 2007 09:04 am (UTC)
Link

Woops... the man page comes from OSX (though from googling I see it must have existed in Linux as well):

"The implementation of getaddrinfo() is not thread-safe."

And yes, I see the RFC, but I do not think it matters if the implementations do not follow it.

If all you can do is brag at conferences about it, then is sounds pretty worthless. I've never been for features that users do not ask for (aka... spend time on the needs...).

What I put up was for users to play with. By the time I get around to actually pushing the code it is quite likely to be close to what you are suggesting. I'll probably push it into a tree that is a couple of years out though, just to buy some more time that the crappy implementations are gone.

On a different note, I will take your suggestions to heart when I update libmemcached. With it I am not worried about supporting old platforms at all.

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: arekm
date: Nov. 29th, 2007 09:19 am (UTC)
Link

Yep, IPv6 is worthless now from commercial point of view. There are some people like me who like playing with IPv6 and even use it at production (the only reason is fun actually).

I hope that bigger ISPs start providing native ipv6 conectivity in incoming years.

US Department of Defense, for example, has a ongoing plan to make its network IPv6 capable and the project target year was/is 2008. http://www.usipv6.com/

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: milosp
date: Dec. 3rd, 2007 08:11 am (UTC)
Link

While doing this part of my GSoC project I was looking at MySQL code (5.1.17) trying to find nice solution for IPv6. I've looked at lot of ifdefs in network part of the code, supporting various gethostbyname/gethostbyaddr implementations on multiple platforms that MySQL should support. There is aggregating function for resolving (with lot of ifdefs). There is vio library that is focused on io operations once you have connection/transport. There is no single library nor single nice way to support network functions, since most network functions are same (socket,bind,connect,accept) on various platforms, and are implemented long the way. (for example like APR)

This is not a bad thing - it works everywhere - it's just a footprint of forked development process, and the fact that no one was thinking that network could/should change. From architectural point of view, there is no library abstraction for network operations (like vio) except for resolving. There is no network library that mysql developers should use, so network implementation is in most cases is deep in code of MySQL.

From objective point of view, you are right - IPv6 support could be better. From point of view of what is in there and how it is organized, you'll find that network in MySQL should be reorganized in order to provide overall better modularity and better IPv6 support, and thats the main obstacle. As you've said there is no wide commercial support for IPv6 and if that is so, why/when should MySQL decide to undertake such change just to support IPv6. It's a question is there a real need to reorganize network in MySQL to be able to support IPv6. Other way it can be done, nicer in IPv6 point of view, but the code will be less readable.

Solution with sockaddr_storage is better and there are advantages that comes with it, and it's quite nice to implement it when there is predeclared typdef that cover all the source code and lower layer library, which is not the case even for existing typedefs that tried to cover source code (as I remmember my_inet_t in mynet.h).

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: mrdeviant
date: Jan. 18th, 2008 12:48 pm (UTC)
Link

The man page for getaddrinfo(3) on Mac OS X 10.5 no longer says that it's not thread-safe.

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: krow
date: Jan. 18th, 2008 01:02 pm (UTC)
Link

There are worse issues with OSX... 10.5 is a bit of a stinker.

Reply | Parent | Thread

Re: Looks like very bad IPv6 support :-(

from: mrdeviant
date: Jan. 18th, 2008 01:26 pm (UTC)
Link

Oh, I definitely agree. I've filed half-a-dozen IPv6-related bugs against 10.5. I just wanted to let you know that getaddrinfo seems to have been fixed.

Log in

IPV6 support for MySQL - Brian "Krow" Aker's Idle Thoughts

Page Summary

Links