I have Windows 7, Mac OS X (Snow Leopard) and Ubuntu 10.10, as IPv6 hosts. I have two public IPv4 addresses currently from my ISP, one for my Cisco ASA running 8.2(4), and one for my Cisco 871 router running 12.4(24)T4 advanced IP services. As my ISP doesn’t provide native IPv6 connectivity, I have to rely on tunnel brokers to connect to the IPv6 Internetz. I have used both SixXS and Hurricane Electric, without any issues. However, I can only use my IOS router to create the IPv6 over IPv4 tunnel, as the ASA doesn’t support it at the moment. So, with the tunnels up and my very own /48 space from HE, I should be all set in the world of IPv6 autoconfiguration ‘n all. All good, EXCEPT, the hosts on the inside. Doh! First of all, hats off to Ubuntu for coming up without a hitch – worked right off the bat. Windows 7, on the other hand, was quite the opposite. Manual configuration works perfectly, but one of the major selling points of IPv6 was autoconfiguration. For some reason, it just doesn’t work as well as I would expect it to, on Windows 7, unless I’m doing something wrong and Ubuntu corrects for idiots. I had to mess around with a bunch of IPv6 parameters through the netsh cli, but could only get v6 working partially, where it would work for around 10 minutes, after which the address would go into a “Deprecated” state, never to recover again. Modifying an IPv6 parameter through netsh would fix the problem but again, only temporarily. I even tried DHCPv6, which did help the addressing situation somewhat, by keeping the addresses in the “Preferred” state, but for whatever reason, Win7 would not pick up the default gateway. No default gateway, no Internetz. Eventually, after trying numerous options, I gave up and went back to static addressing. For me, IPv6 on Windows 7… Fail.

Mac OS X had a similar issue, but this time the host was behind the ASA. Autoconfiguration just doesn’t work; not even partially; and DHCPv6 is not an option on the version of code I’m running on the ASA. Router Advertisements are received as evidenced by tcpdump, but no autoconfiguration takes place for the global address. And yes, I did change the sysctl accept_raadv variable to 1. Next step will be to test with IOS, to see if the problem is with the RAs being sent by the ASA, or if it’s OS X itself.

Conclusion: Ubuntu is the clear winner; two button clicks to enable IPv6; zoom zoom. I {heart} Ubuntu!

On your SSH Client, generate the private and public keys by issuing the following command:

my-ssh-client% ssh-keygen
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/id_dsa.
Your public key has been saved in .ssh/id_dsa.pub.
The key fingerprint is:
f6:XX:aa:XX:84:XX:b3:...:aa:b1 user@host1.abc.com
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| |
| o S |
| = +. . . |
| @Eo. o |
| o.B+. o |
| .+===+. |
+-----------------+
The above generates two files:

1. Private Key: By default this is stored as .ssh/id_dsa
2. Public Key: By default this is stored as .ssh/id_dsa.pub

The public key, for good reason, is the key that you can distribute. As such, you want to copy the contents of that file and paste it into the .ssh/authorized_keys file in the home directory of the server you are logging into.

Next time when you SSH to the server from your machine, you will be prompted for the passphrase that you entered when generating the keys on your client. Make sure you have your SSH client save this passphrase (“Add to Keychain” on Mac OS X); this will ensure you are not prompted for it when you try to login again.