My local network is both IPv4 and IPv6 enabled. I find that when I run "emerge sync" it always prefers IPv6 over IPv4 rsync mirrors. Indeed, at this time, for "rsync://rsync.namerica.gentoo.org/gentoo-portage" I get 18 A (IPv4 Address) records, and 1 AAAA (IPv6 Address). This is unfairly stressing the IPv6 mirror (rsync6.netpimpz.com - thanks guys!) Reproducible: Always Steps to Reproduce: 1. # emerge sync Actual Results: portage uses "rsync.namerica.gentoo.org" as the fqdn, which resolves to "2001:470:1f00:264::1003" at this time (rsync6.netpimpz.com) and completely ignores all the IPv4 accessible hosts. Expected Results: should be able to manually or automagically try IPv4 hosts as well as IPv6 ones. Portage 2.0.49-r10 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r1, 2.6.0-test6-mm4) ================================================================= System uname: 2.6.0-test6-mm4 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.4.3.10p1 distcc 2.11.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://www.ibiblio.org/gentoo http://adelie.polymtl.ca/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://gentoo.noved.org/" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib directfb gtkhtml alsa gdbm berkdb slang readline arts tetex aalib nas bonobo svga tcltk java guile ruby mysql X sdl gpm pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla snmp cdr scanner acpi amd apache2 ardour-ksi artswrappersuid dga dnd doc dvb dvd ethereal evo faad fbcon fbdev gb gd gnomedb gphoto2 gstreamer gtk2 imagemagick imap innodb ipv6 jack maildir mdb mozsvg odbc offensive pda pic radeon samba sasl slp sox sse usb v4l videos vim-with-x wxwindows X509 xml xosd xvid -tcpd -ldap" I have found that rsync itself can be coerced into favouring IPv4 by adding a -4 option (or conversely, favouring IPv6, using -6), but there is no easy way to introduce this parameter without editing /usr/bin/emerge itself. I have looked at GETHOSTBYNAME(3) and HOST.CONF(5) but cannot find any way to alter the resolution order system wide. Conclusion: I have thought of the following possible solutions in no particular order: 1. Make the presence of "ipv6" in USE determine whether -4 or -6 is used. Pro: This would be relatively simple to implement Con: Makes the ipv6 use flag too "magical". I don't think emerge itself is affected by other USE variables, so why this one? 2. new variable in /etc/make.conf RSYNC_PREFER="IPv4" or "IPv6" (or just "4", or "6") Pro: simple to implmement. Con: There are already too many options. 3. new variable in /etc/make.conf RSYNC_ADDTIONAL_OPTIONS="-4" or whatever you want really. Pro: very simple to implement, general purpose. Con: Difficult to validate, if you're pedantic about sanitising passed parameters. 4. Make "emerge" itself query for all the A and AAAA records, and it pick one. Pro: All mirrors are considered equal. Except for those that have IPv4 and IPv6 connectivity, but that's really difficult to determine. Pro: If a particular mirror is *really* busy, you can definatively try another mirror (the alternate A and AAAA records end up in a randomized list). Con: Probably the most complicated to implement. 5. Blame/fix rsync itself ;) Pro: This kind of change of functionality may be better if integrated into rsync itself. Con: May be considered a bit specialised - the -4 and -6 options are there for this reason. I would like some feedback upon the options above. I can probably make a patch for 1-3 fairly easily, 4 would be more work, but probably doable, Don't know about 5, would have to take the problem elsewhere :(
Just thought of another alternative: 6. Have seperate DNS round robin entries for IPv6 - e.g. "rsync6.namerica.gentoo.org" so it can be specified with SYNC in /etc/make.conf. This solution would make it an rsync mirror / DNS issue, not a portage one.
yeah, i like the idea of splitting up into diff server pools ... rsync has ipv4 compat mirrors while rsync6 has ipv6 compat mirrors ... mirros can obviously be in both or just one
I believe that the preference of ipv6 is inherent in the design of the ultradns DNS service. The thinking is that if you are making an ipv6 request, then you want ipv6 and not ipv4 (and visa-versa, when you make an ipv4 request you never get ipv6 addresses in return). Not everyone who uses ipv6 has both ipv4 and ipv6, so if it were to return a mix of ipv4 addresses along with the ipv6 addresses, those people who are ipv6-only would be stuck. The only way to help this situation would be a seperate round robin set (ala "rsync.ipv6.gentoo.org") and for now place all of the ipv6 hosts in there, leaving them out of the ipv4 rrsets, that way they can be used but lone v6 hosts would not be hammered like you've noted. Let me run this by some people...
The preference which address family to use first is not related to UltraDNS, but to the glibc (the order records are returned by getaddrinfo()). Every available libc/stack out there (Linux glibc, *BSD, Solaris, Windows) uses IPv6 first if both are available. But it is not related to UltraDNS at all, in fact the system library makes two DNS queries (first for AAAA and then one for A). IPv6 rsync is broken anyway (bug #37124) and with the current scheme it would require an upstream problem with rsync to be fixed before it can be enabled again. As soon as it gets fixed I would rather see a seperate make.conf flag which defaults to v6-first, then v4. Or rsync.<loc>.gentoo.org having both records and rsync4.<loc> and rsync6.<loc> to use only one afi. I'd just like to keep the "use IPv6 by default if available" if possible.
Ok.. With that in mind this should be re-assigned to the portage team as a feature request for the time when rsync via ipv6 is fixed again. Cheers!
Not sure if this is valid any longer. Some time ago when I was testing IPv6 with Gentoo I found that if the IPv6 link was down (I used another computer as router) beyond the gateway interface the RSync would not fall back to try IPv4.
Basically the same deal, requesting some sort of user-configurable value to use v6 over v4, or vice versa, or make portage use v6 if available, and v4 if v6 fails. *** This bug has been marked as a duplicate of 37124 ***
