IPv6 literal addresses on command line
camccuk at yahoo.com
Fri Nov 28 03:28:44 EST 2003
--- Paul Slootman <paul at debian.org> wrote:
> On Thu 27 Nov 2003, cam wrote:
> > [root at thing]# host -t AAAA doodah.ipv6.ournet.co.uk
> > doodah.ipv6.ournet.co.uk has AAAA address 3ffe:501:420:120::2
> > [root at thing]# rsync -Cav -6 doodah:home/cam/dev/pcapture .
> > doodah: Unknown host
> Of course, here you're doing two different things: with and without a
> fully qualified name.
Indeed. The packet trace indicates that the A record query is for the FQDN - I
should have mentioned this. Using the FQDN in the command doesn't help. While
dig requires the FQDN, all other apps that I've tested (ftp, ssh, ping6 etc)
don't require it - assuming the appropriate search clause in /etc/resolv.conf
> "That guy" would be me...
I'm well aware that it was you you that responded Paul.. you may remember that
I accidentally replied offlist. I was just respecting your privacy.
> I'm Debian's rsync maintainer, so all Debian
> users (well, "testing" users at least) are also in the happy situation
> that their rsync supports IPv6.
> In the configure output, there's this line:
> checking ipv6 stack type... linux-glibc
> This implies to me that the standard glibc supports IPv6. I have no
> libinet6 or such on my system. rsync is linked with -lresolv, if that
> helps any...
I wonder if debian has included more of the USAGI patches that aren't applied
to the 'vanilla' kernel from kernel.org? Various comments in the rsync TODO
file suggest that different systems/distros handle address resolution
" The KAME IPv6 patch is nice in theory but has proved a bit of a
nightmare in practice. The basic idea of their patch is that rsync
is rewritten to use the new getaddrinfo()/getnameinfo() interface,
rather than gethostbyname()/gethostbyaddr() as in rsync 2.4.6.
Systems that don't have the new interface are handled by providing
our own implementation in lib/, which is selectively linked in.
The problem with this is that it is really hard to get right on
platforms that have a half-working implementation, so redefining
these functions clashes with system headers, and leaving them out
breaks. This affects at least OSF/1, RedHat 5, and Cobalt, which
are moderately improtant.(sic)"
I assume that a similar situation holds for USAGI since, to my knowledge, the
KAME patch doesn't apply to RedHats of any version number, being a patch for
Thanks for the response. I shall summarise any resolution to this that I find
but for the moment I am looking into IPv6-4 translation.
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
More information about the rsync