IM clients and IPv6

[maestroevolution]

So, today I did something new:  I have NAT64 and DNS64 working, and my laptop is on an IPv6 only network (actually, several vlans at my office are now IPv6 only, for those brave enough to try).  No IPv4 addressing period.  Native IPv6 traffic traverses a tunnel to Hurricane Electric (of course), while Internet (and intranet) destinations without AAAA addresses are reached via NAT64 (and DNS64 doing its magic)

The good news is... almost everything works so far:  web, email, ssh, remote desktop, ftp (yes, even ftp through NAT64).

The bad news is.. it's almost everything.  I use three IM protocols:  Yahoo, MSN, and AOL (one family, one old work, one current work).  None of them would finish connecting.

After breaking out wireshark and looking at the packets... I realized that I went through a timewarp to 1985 and the protocol uses IP addresses embedded in the payload, not DNS names.  Both Yahoo and MSN definitely, as their setup is in clear text.  AOL uses SSL, so I can't decrypt it.. but I assume the same.  As my laptop has no IPv4 connectivity, it can't reach the server.   If the client passed back a DNS name, this would be too easy... as DNS64 already fixes that for me.  But, alas...  we are stuck with the ftp problem of 1985.

A 10 minute google search on Yahoo/MSN did not come up with any fixes.. such as servers with IPv6 addresses that will pass back IPv6 addresses in the payload (still a bad practice... did we not learn ANYTHING from FTP?).

So, several questions for anyone/everyone:

1) Has anyone else already tried this and found Yahoo/Aol/MSN/whatever servers that are IPv6 friendly?
2) Are there any IM clients where the protocols are IPv6 aware/friendly?  This looks like a protocol issue, not a client (as I'm running Pidgin for all three), but I will try using the official clients tomorrow on my Windows box and see if there's a difference.

I expect I could "solve" this by configuring a proxy, and letting the client have v6 connectivity to the proxy, but... this smacks of cheating.  While the IM clients may be IPv4 only, they are all smart enough to use proxies.  A proxy would not be my first choice, though, as if a proxy was "the" answer, we could skip the whole NAT64/DNS64 stuff and configure a SOCKS proxy on every box.

I may still do that.. (in fact, I could probably use a native v4 only proxy for it, again with NAT64/DNS64 magic), but looking for alternatives?  I expect that any transition would want a proxy for just such one-offs anyway... but looking for other options.

Thoughts?

Joel

[gnarlymarley]

This is not a complete solution, but you might be able to disable IPv4 on the workstation completely and use the DNS64 to convert a lookup for the IP to an IPv6 address.  This would be sort of like a DNS46 in front of your DNS64 Then have the NAT64 convert it back.

The DNS lookup would look something like
192.0.43.10.  IN  AAAA 2001:0db8::ffff:192.0.43.10

This would only work if the IM client would work on both IPv4 and IPv6 and was just connecting to the IP because it was hard-coded in the software.

[jimb]

In situations where IPv4 addresses are hard coded into application layer protocol, there's really nothing you can do in an IPv6 only situation.  You'd have either find a chat protocol which is IPv6 friendly, or run dual stack, or dual stack lite.

[maestroevolution]

I ended up using a squid proxy for my IM traffic.  Put that up at the time of the original post, and still IPv6 only today.

The hack by gnarlymarley is interesting... it is one heck of a kludge, and probably heavily dependent on the stub resolver of the OS.

If the client does try to resolve "10.20.30.40" and you can override that with a hosts file (instead of resolving to 10.20.30.40), that might get the first step to work.

Of course.. you would have to know the IP address coming back ahead of time, and it would work for only the first communication (if at all): any followup communication would be toast... unless the client (if IPv4 is completely disabled) will always try to resolve "10.20.30.40" to its DNS server.

I dont' know if IPv4 can be completely disabled in the OS, though: too much stuff assumes that 127.0.0.1 is reachable as the loopback.  It can be disabled on the physical interfaces, of course, although it looks like Linux still puts an IPv4 link local on the interface.

joel@maestro:~$ route -4
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
link-local      *               255.255.0.0     U     1000   0        0 eth0
joel@maestro:~$ route -4n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
joel@maestro:~$

[kenyon]

I was just googling the topic of AIM and IPv6 and this seems to be the only relevant result. I've also tried the IPv6-only NAT64+DNS64 setup, and AIM was the only thing that didn't work.

You asked about IM clients that are IPv6 friendly. XMPP (Jabber) is IPv6 friendly and works fine in this environment, as long as the client supports IPv6, which I think most of the major ones do now (Adium, Pidgin, bitlbee, for example).