IPv4 addresses come sorted before IPv6 ones if you ask libc in teredo environment.

Yes, this is intentional behaviour, teredo addresses have lower reliability than native v6 mechanisms and in general lower than ipv4, so it makes sense to give them lower priority too.

It's the same issue with 6to4 tunnel as well. I was wondering why my applications don't use ipv6 and I also found that getaddinfo() is returning ipv4 addresses before ipv6. So my 6to4 tunnel is useless because applications don't use ipv6 unless I explicitly instruct them to do so (eg. use ssh -6 or hostnames like www.ipv6.sixxs.net). If I added a native ipv6 address (for test purposes) getaddrinfo() started returning ipv6 address before ipv4. Last year (when I still used debian unstable) this wasn't the case, all applications were using ipv6 even though I had 6to4 tunnel. Is this a ubuntu specific modification or a new feature in glibc?

I don't really understand the reasoning here. Native ipv6 connections can be unreliable just like 6to4 tunnels are, it just depends how good the network administrators are. For example, my 6to4 anycast address goes to a gateway provided by Funet (Finnish University and Research Network) and is of very good quality. I don't recall having any problems with the tunnel or the gateway during all those years I have been using them (which must be over five years), all the ipv6 problems have been elsewhere in the ipv6 network.

In my opinion, if a user has gone all the trouble of creating an ipv6 tunnel, be it 6to4 or teredo, libc should honour that and prefer ipv6.

I got the authoritative answer from glibc team and unfortunately we have to treat such a behavior as "feature" rather than a "bug".

I did some research and found bug #555210 which changed to the behaviour reported here. Here's a workaround:

https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/555210/comments/10