Entries tagged with “ipv6” from URL > Average
Reverse DNS is easy. You take the address, reverse the bit sets, and then append ".in-addr.arpa." to the domain. 10.0.0.1 maps to 1.0.0.10.in-addr.arpa.
Isn't that easy?
With IPv4, we can have up to three bytes per zone delimiter, or in regular speak, three numbers per dot.
With IPv6, every single hex digit is given a zone delimiter, instead of groups of three. This is really nice in terms of flexibility, but people whine enough about v6 address length enough as-is. This pretty effectively doubles it.
For example, 2001:470:d82b:ffff:217:31ff:fec4:919a becomes a.9.1.9.4.c.e.f.f.f.1.3.7.1.2.0. f.f.f.f.b.2.8.d.0.7.4.0.1.0.0.2.ip6.arpa. This is, to put it lightly, nasty. The slightly shortened suffix goes entirely unnoticed.
It's pretty easy to glance at a v4 address and type out the reverse DNS mapping. It is right next to impossible to do that with a full length v6 address. You mentally transpose a digit and suddenly you're trying to mess with an address billions upon billions of addresses away from the one you care about.
Quick note: dig rectifies this problem. "dig -x [ip-addr-goes-here]" will perform a reverse DNS lookup on the address (both v4 and v6), but more importantly, it prints out the address in the proper reverse DNS form.
Example:
No more pain!
Isn't that easy?
With IPv4, we can have up to three bytes per zone delimiter, or in regular speak, three numbers per dot.
With IPv6, every single hex digit is given a zone delimiter, instead of groups of three. This is really nice in terms of flexibility, but people whine enough about v6 address length enough as-is. This pretty effectively doubles it.
For example, 2001:470:d82b:ffff:217:31ff:fec4:919a becomes a.9.1.9.4.c.e.f.f.f.1.3.7.1.2.0. f.f.f.f.b.2.8.d.0.7.4.0.1.0.0.2.ip6.arpa. This is, to put it lightly, nasty. The slightly shortened suffix goes entirely unnoticed.
It's pretty easy to glance at a v4 address and type out the reverse DNS mapping. It is right next to impossible to do that with a full length v6 address. You mentally transpose a digit and suddenly you're trying to mess with an address billions upon billions of addresses away from the one you care about.
Quick note: dig rectifies this problem. "dig -x [ip-addr-goes-here]" will perform a reverse DNS lookup on the address (both v4 and v6), but more importantly, it prints out the address in the proper reverse DNS form.
Example:
dig -x 2001:470:d82b:ffff:217:31ff:fec4:919a
[...snip...]
;; QUESTION SECTION:
;a.9.1.9.4.c.e.f.f.f.1.3.7.1.2.0.f.f.f.f.b.2.8.d.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR
[...snip...]
No more pain!
My home network has "native" IPv6 through a series of tunnels that I've set up. The setup is pretty basic. A v6-in-v4 tunnel comes in through HE to my server, giving my server control over... a lot of v6. From here I segment it off a bit, and then branch the connectivity out over several other tunnels. One of these tunnels, as you could guess, heads to my home router.
When I was initially setting up the server <--> home tunnel, my firewalling rules gave me a fair bit of crap. Staring at tcpdump for quite some time didn't give me any leads concerning the proper rule to create, and I wound up whitelisting my entire home IPv4 address (that sounds a bit silly - whitelisting an 'entire v4 address' - you know, all one of them).
I finally got sick of allowing this IP full access to everything, because there were quite a number of ports "open" on the server but that I didn't want anyone outside accessing. This also caused problems with creating proper rules in the first place, because my only test bed was... from an entirely whitelisted IP. Suffice it to say some things that I thought were open were in fact not open to anyone but me, and this caused me quite the headache before I figured it out.
So how did I fix this? The answer is actually pretty simple - 42.
Wait, no. I meant 41. Sorry. Really I did. 41 is the protocol number assigned to IPv6. If this was obvious to others, well, sorry that I'm so slow. I didn't know. If I had known that I should be picking random numbers and trying them in a not exactly often used iptables command, then maybe I would have done this earlier.
Fun fact: "TCP" is 6. Note how this is ambiguous in terms of which "IP" it means, but in this case, it means IPv4. Why TCP is "6" is evidently defined in RFC 793, and why IPv6 is "41" can be found in RFC 1883 (or 1112, not exactly sure).
Note how TCP is 6, and that UDP is 17. Both TCP and UDP are commonly known as "TCP/IP" and "UDP/IP." Both of these operate quite nicely over both IPv4 and IPv6. IPv6 has an assigned number - but IPv4 does not. How you would intermix this I'm not sure. I can block IPv6 quite nicely it seems, but IPv4 is strangely absent. Does 6 imply v4? Does 17 imply v4? How can you filter UDP over 41?
I have no idea. I'm confused too. If you can make sense of the why, I'd be very interested in finding out why these protocol number seem so convoluted and inconsistent. It is pretty obvious that the protocol number for v6 was tacked on long after the base numbers for TCP and UDP were established, but whatever.
Enough rambling.
So how did I fix this firewalling issue?
... from the tunnel server. I didn't have to create a matching rule on my home router, and of course, ymmv.
For those of you familiar with iptables, the "-p 41" may look somewhat familiar to you. It should:
When I was initially setting up the server <--> home tunnel, my firewalling rules gave me a fair bit of crap. Staring at tcpdump for quite some time didn't give me any leads concerning the proper rule to create, and I wound up whitelisting my entire home IPv4 address (that sounds a bit silly - whitelisting an 'entire v4 address' - you know, all one of them).
I finally got sick of allowing this IP full access to everything, because there were quite a number of ports "open" on the server but that I didn't want anyone outside accessing. This also caused problems with creating proper rules in the first place, because my only test bed was... from an entirely whitelisted IP. Suffice it to say some things that I thought were open were in fact not open to anyone but me, and this caused me quite the headache before I figured it out.
So how did I fix this? The answer is actually pretty simple - 42.
Wait, no. I meant 41. Sorry. Really I did. 41 is the protocol number assigned to IPv6. If this was obvious to others, well, sorry that I'm so slow. I didn't know. If I had known that I should be picking random numbers and trying them in a not exactly often used iptables command, then maybe I would have done this earlier.
Fun fact: "TCP" is 6. Note how this is ambiguous in terms of which "IP" it means, but in this case, it means IPv4. Why TCP is "6" is evidently defined in RFC 793, and why IPv6 is "41" can be found in RFC 1883 (or 1112, not exactly sure).
Note how TCP is 6, and that UDP is 17. Both TCP and UDP are commonly known as "TCP/IP" and "UDP/IP." Both of these operate quite nicely over both IPv4 and IPv6. IPv6 has an assigned number - but IPv4 does not. How you would intermix this I'm not sure. I can block IPv6 quite nicely it seems, but IPv4 is strangely absent. Does 6 imply v4? Does 17 imply v4? How can you filter UDP over 41?
I have no idea. I'm confused too. If you can make sense of the why, I'd be very interested in finding out why these protocol number seem so convoluted and inconsistent. It is pretty obvious that the protocol number for v6 was tacked on long after the base numbers for TCP and UDP were established, but whatever.
Enough rambling.
So how did I fix this firewalling issue?
# iptables -I INPUT -s <v4 home address here> -p 41 -j ACCEPT
... from the tunnel server. I didn't have to create a matching rule on my home router, and of course, ymmv.
For those of you familiar with iptables, the "-p 41" may look somewhat familiar to you. It should:
# iptables -I INPUT -p tcp --dport 80 -j ACCEPTIt is just a simple protocol match. All we're doing is matching the v4 source address, the v6 data, and allowing it through. Despite the above example doing something quite different, the -p switch does the same thing: matches a protocol.
So I wrote about IPv6 a few months back. Tunneling it over IPv4, general networking with it, and even ping6'ing Google.
Been using it ever since.
Whoa now, wait a minute! People use IPv6?
For the most part, I set it up and poked with it for vanity purposes. "Hey look at me! I'm speaking a protocol that your router has no idea what to do with!" I had little actual use for it. For the most part I never had any real problems, but no real benefit either.
But it's been a few months, and I recently had my "IPv6 Epiphany." So here, have some random bits of info that I've picked up while playing with it.
The Problems
1. IPv6-in-IPv4 tunnels aren't really firewall friendly, nor are they the easiest thing to configure. I wound up whitelisting my home router's IPv4 address on my server, exempting it from all other iptables rules. This fixed a problem that cropped up when I rebooted my server, resetting my firewall rules to their saved state, and broke my ability to SSH into my server from home without specifying -4. Further, configuring a tunnel with iproute2 is pretty easy. Configuring a tunnel from CentOS to Debian using the "proper system-specific methods" really isn't. Debian I got working. CentOS I didn't, and wound up writing a pseudo-service to manage the tunnels and routes. All things considered, I probably would have wound up doing the same thing for my Debian router if it was as overloaded as my server in terms of IPv6 config.
Plus you have the increased latency. As a whole, this hasn't been a problem for me.
2. Not everyone who runs IPv6 maintains their v6 stack nearly as well as they do their v4 stack. This has proven to be a problem. For example, I was looking into H.323, and tried to open up the Open H.323 website.
The problem lies in the DNS. The OpenH323 project had a v6 DNS server. This server did not respond to queries coming over the v6 transport, breaking DNS resolution nicely for me. When I went poking with dig, it responded happily over v4. (It seems that their DNS is broken for both v4 and v6, so perhaps it was coming anyway. But the point stands. When your site works, you're content. You're not going to spend time checking that it works over both v4 and v6. This leads to problems.)
3. Application support.
From a sysadmin standpoint, nearly every computer out there has a DHCP client. Wait, sorry. Nearly every computer out there has a DHCPv4 client. This poses a problem when it comes to v6 connectivity. This is one area where Vista is quite a bit ahead of the *nix - they ship a DHCPv6 client and full stateless v6 autoconfig support by default. Their stateless autoconfig leaves a bit to be desired, as it ignores RDNSS data in the router advertisements, but they have documented how to get full DNS resolution on a stateless-only interface. It's pretty simple.
Linux, at a minimum, has a stateful DHCP client kicking around, but it isn't installed or even mentioned in most distro networking guides. It's not even available in several distros. The kernel has great stateless autoconfig, but RDNSS isn't exactly a kernel space setting either. There is a user space tool around that watches for the router adverts and adjusts /etc/resolv.conf as needed, but it's even less known than the stateful DHCP client.
There are also a couple really popular open source programs out there that don't speak v6 at all. There are two that bug me to this day: MySQL and Asterisk. MySQL is really not too huge of an issue right now, but to my knowledge they aren't even working on it. Maybe Drizzle could?
Asterisk is really the bigger issue. One of the largest roadblocks to getting VoIP with SIP to play nicely is NAT. To put it simply, it doesn't work with NAT. I can see (properly done) VoIP being a huge, monumental boost of support and a fantastic reason to get v6 working. Nearly the entire point of deploying v6 now is massively increased connectivity (with v4 connectivity dropping drastically in the near future). The current v4 (NAT) landscape is incredibly inhibiting to SIP, and while you can argue the relative merits of SIP to any other VoIP protocol, the value of having full connectivity from any one device to any other device really can't be understated.
(A note to you "but I like NAT because it's a great firewall!" people: first off, no it isn't. Second, there is a very simple rule here that both mirrors what you "get" with NAT and is arguably more secure than NAT. It happens to be called "default deny." From there, if you want to support VoIP, you can add one single rule and have great VoIP support. Have a /48 that houses both users and servers? Great - subnetting is your friend. Just open :80 to the server subnet.)
4. IPSEC. Still sucks to configure, is only going to become more important with enhanced device to device communication. Isn't supported by any mobile phone I'm aware of. Have a mobile phone that can connect to a SIP server over wifi? Great! Can it do IPSEC? Nope. Sure, TLS exists for a reason, but full-blown IPSEC has numerous advantages over TLS and it really isn't supported anywhere but the router and desktop. (Plus it still sucks to configure.)
Does your (insert handheld gaming device here) support IPSEC? No? Well sure I wasn't expecting it to, but it'll be interesting to see how this plays out over the next couple years.
5. Reverse DNS. 3.d.3.7.0.0.e.f.f.f.b.3.f.1.2.0.d.f.f.f.b.2.8.d.0.7.4.0.1.0.0.2.ip6.arpa. Do I really need to say just how much configuring reverse DNS sucks? No? Good. Is there a better solution? Probably not. I'm just glad that dig and ipv6calc are of use here, so I don't have to manually type out every full-length DNS record.
Advantages
1. Pretty much every single application I've used on linux supports it very well. Everything from HTTP to IMAP to Kerberos to SSH is operating flawlessly for me over v6. Vista has v6 CIFS, rdesktop, and RPC. I could make a full list here of what is supported in terms of services and clients across different OSs, but really, the list of what isn't properly supported is shorter at this point. And yes, for the most part, that applies to Windows too.
2. It's supported, well, by every (very?) modern OS. Vista just works with it. Linux just works with it.
There are some "gotchas" with both, but they'll be resolved over time and as more and more sysadmins come to use it. Vista actually has a default 6to4 tunnel built in, that starts up if you have a public v4 address. Even if your ISP doesn't support v6 (not that any of them do), if you can plug your Vista box in straight to the internet, you'll get v6 without any configuration or hassle.
3. NAT really sucks. The simple connectivity provided by v6 rocks. Now this leads back to how I started this entire post. First, a bit of background.
I run CentOS on my server. SSH has all password-based authentication disabled, and only supports Kerberos (GSSAPI) and pubkey auth.
I have a few RPMs that I need to rebuild to support a few extra things (namely postfix to support mysql, and kerberos to support an LDAP backend). I'd rather not keep all of the needed -devel packages installed on my server, and I'd also prefer to keep gcc and the rest of the needed buildutils not installed. The obvious solution is to rebuild them on another CentOS box, create a mini RPM repo, and then just use yum to install them. The process is simple enough.
The trick comes in actually getting those rebuilt RPMs to my server. This is also where v6 happens to make my life incredibly easy.
My CentOS "build box" is a VM running on my Vista box. This is really the best solution for me. I don't need to have a dedicated CentOS box here, and as a result of that I can click "turn off" and forget about it entirely until I need it again. This is probably the only really good use of VMs that I've found so far, but I digress.
As mentioned, you can't login to my server over SSH without an SSH key or kerberos auth. This means that I can't just scp them up to my server without either copying my existing key(s) over, or generating new keys and adding them
It was at this point I realized that my v6 setup meant that my VMs had public v6 addresses. And then a light clicked on.
I fired up rsync on the VM, copied the v6 address, and then from the server used rsync to move them over.
And it just worked. No port forwarding. No key configuration. No advanced auth config for the VM. I could have used apache+wget just as easily. I was able to start a service (on a VM that sits on a host behind NAT) and use it without any hassle, without any VPN trickery - it just worked.
If you compare the effort it would take to setup v6 on your home network and an "external" network, and compare that to the port forwarding, NAT translation/incompatibility, "hey this port is already in use, by another NAT'd device, guess that means we get to start using extensive proxies or odd ports" mess that may be involved in something as simple just getting host A to talk to host B...
... I think v6 comes out ahead in terms of what you get and the time it takes to make it work.
Been using it ever since.
Whoa now, wait a minute! People use IPv6?
For the most part, I set it up and poked with it for vanity purposes. "Hey look at me! I'm speaking a protocol that your router has no idea what to do with!" I had little actual use for it. For the most part I never had any real problems, but no real benefit either.
But it's been a few months, and I recently had my "IPv6 Epiphany." So here, have some random bits of info that I've picked up while playing with it.
The Problems
1. IPv6-in-IPv4 tunnels aren't really firewall friendly, nor are they the easiest thing to configure. I wound up whitelisting my home router's IPv4 address on my server, exempting it from all other iptables rules. This fixed a problem that cropped up when I rebooted my server, resetting my firewall rules to their saved state, and broke my ability to SSH into my server from home without specifying -4. Further, configuring a tunnel with iproute2 is pretty easy. Configuring a tunnel from CentOS to Debian using the "proper system-specific methods" really isn't. Debian I got working. CentOS I didn't, and wound up writing a pseudo-service to manage the tunnels and routes. All things considered, I probably would have wound up doing the same thing for my Debian router if it was as overloaded as my server in terms of IPv6 config.
Plus you have the increased latency. As a whole, this hasn't been a problem for me.
2. Not everyone who runs IPv6 maintains their v6 stack nearly as well as they do their v4 stack. This has proven to be a problem. For example, I was looking into H.323, and tried to open up the Open H.323 website.
The problem lies in the DNS. The OpenH323 project had a v6 DNS server. This server did not respond to queries coming over the v6 transport, breaking DNS resolution nicely for me. When I went poking with dig, it responded happily over v4. (It seems that their DNS is broken for both v4 and v6, so perhaps it was coming anyway. But the point stands. When your site works, you're content. You're not going to spend time checking that it works over both v4 and v6. This leads to problems.)
3. Application support.
From a sysadmin standpoint, nearly every computer out there has a DHCP client. Wait, sorry. Nearly every computer out there has a DHCPv4 client. This poses a problem when it comes to v6 connectivity. This is one area where Vista is quite a bit ahead of the *nix - they ship a DHCPv6 client and full stateless v6 autoconfig support by default. Their stateless autoconfig leaves a bit to be desired, as it ignores RDNSS data in the router advertisements, but they have documented how to get full DNS resolution on a stateless-only interface. It's pretty simple.
Linux, at a minimum, has a stateful DHCP client kicking around, but it isn't installed or even mentioned in most distro networking guides. It's not even available in several distros. The kernel has great stateless autoconfig, but RDNSS isn't exactly a kernel space setting either. There is a user space tool around that watches for the router adverts and adjusts /etc/resolv.conf as needed, but it's even less known than the stateful DHCP client.
There are also a couple really popular open source programs out there that don't speak v6 at all. There are two that bug me to this day: MySQL and Asterisk. MySQL is really not too huge of an issue right now, but to my knowledge they aren't even working on it. Maybe Drizzle could?
Asterisk is really the bigger issue. One of the largest roadblocks to getting VoIP with SIP to play nicely is NAT. To put it simply, it doesn't work with NAT. I can see (properly done) VoIP being a huge, monumental boost of support and a fantastic reason to get v6 working. Nearly the entire point of deploying v6 now is massively increased connectivity (with v4 connectivity dropping drastically in the near future). The current v4 (NAT) landscape is incredibly inhibiting to SIP, and while you can argue the relative merits of SIP to any other VoIP protocol, the value of having full connectivity from any one device to any other device really can't be understated.
(A note to you "but I like NAT because it's a great firewall!" people: first off, no it isn't. Second, there is a very simple rule here that both mirrors what you "get" with NAT and is arguably more secure than NAT. It happens to be called "default deny." From there, if you want to support VoIP, you can add one single rule and have great VoIP support. Have a /48 that houses both users and servers? Great - subnetting is your friend. Just open :80 to the server subnet.)
4. IPSEC. Still sucks to configure, is only going to become more important with enhanced device to device communication. Isn't supported by any mobile phone I'm aware of. Have a mobile phone that can connect to a SIP server over wifi? Great! Can it do IPSEC? Nope. Sure, TLS exists for a reason, but full-blown IPSEC has numerous advantages over TLS and it really isn't supported anywhere but the router and desktop. (Plus it still sucks to configure.)
Does your (insert handheld gaming device here) support IPSEC? No? Well sure I wasn't expecting it to, but it'll be interesting to see how this plays out over the next couple years.
5. Reverse DNS. 3.d.3.7.0.0.e.f.f.f.b.3.f.1.2.0.d.f.f.f.b.2.8.d.0.7.4.0.1.0.0.2.ip6.arpa. Do I really need to say just how much configuring reverse DNS sucks? No? Good. Is there a better solution? Probably not. I'm just glad that dig and ipv6calc are of use here, so I don't have to manually type out every full-length DNS record.
Advantages
1. Pretty much every single application I've used on linux supports it very well. Everything from HTTP to IMAP to Kerberos to SSH is operating flawlessly for me over v6. Vista has v6 CIFS, rdesktop, and RPC. I could make a full list here of what is supported in terms of services and clients across different OSs, but really, the list of what isn't properly supported is shorter at this point. And yes, for the most part, that applies to Windows too.
2. It's supported, well, by every (very?) modern OS. Vista just works with it. Linux just works with it.
There are some "gotchas" with both, but they'll be resolved over time and as more and more sysadmins come to use it. Vista actually has a default 6to4 tunnel built in, that starts up if you have a public v4 address. Even if your ISP doesn't support v6 (not that any of them do), if you can plug your Vista box in straight to the internet, you'll get v6 without any configuration or hassle.
3. NAT really sucks. The simple connectivity provided by v6 rocks. Now this leads back to how I started this entire post. First, a bit of background.
I run CentOS on my server. SSH has all password-based authentication disabled, and only supports Kerberos (GSSAPI) and pubkey auth.
I have a few RPMs that I need to rebuild to support a few extra things (namely postfix to support mysql, and kerberos to support an LDAP backend). I'd rather not keep all of the needed -devel packages installed on my server, and I'd also prefer to keep gcc and the rest of the needed buildutils not installed. The obvious solution is to rebuild them on another CentOS box, create a mini RPM repo, and then just use yum to install them. The process is simple enough.
The trick comes in actually getting those rebuilt RPMs to my server. This is also where v6 happens to make my life incredibly easy.
My CentOS "build box" is a VM running on my Vista box. This is really the best solution for me. I don't need to have a dedicated CentOS box here, and as a result of that I can click "turn off" and forget about it entirely until I need it again. This is probably the only really good use of VMs that I've found so far, but I digress.
As mentioned, you can't login to my server over SSH without an SSH key or kerberos auth. This means that I can't just scp them up to my server without either copying my existing key(s) over, or generating new keys and adding them
It was at this point I realized that my v6 setup meant that my VMs had public v6 addresses. And then a light clicked on.
I fired up rsync on the VM, copied the v6 address, and then from the server used rsync to move them over.
And it just worked. No port forwarding. No key configuration. No advanced auth config for the VM. I could have used apache+wget just as easily. I was able to start a service (on a VM that sits on a host behind NAT) and use it without any hassle, without any VPN trickery - it just worked.
If you compare the effort it would take to setup v6 on your home network and an "external" network, and compare that to the port forwarding, NAT translation/incompatibility, "hey this port is already in use, by another NAT'd device, guess that means we get to start using extensive proxies or odd ports" mess that may be involved in something as simple just getting host A to talk to host B...
... I think v6 comes out ahead in terms of what you get and the time it takes to make it work.
A protocol is nothing if never used. Well, okay, maybe it can be a joke. Maybe. Okay, so that's not really a protocol. Evil Bit jokes are still positive net karma, right?
Likewise, IPv6 is pretty much useless if it is never used. I can assign the addresses all I please but ultimately if all I do is ping my desktop that sits "behind NAT" with it then for the most part the effort was wasted.
My server runs CentOS 5.2, my desktop runs Gentoo, my laptop Debian, my router Debian, my windows desktop Vista (dual boot Server 2008), and the Vista box also has three instances of OpenBSD running within VMWare.
I've got a pretty good testbed to see just what does/doesn't support IPv6, in terms of everything general web browsing to random system daemons to whatever end user programs you have a desire to run. So, I put together a small bit of info concerning what handles IPv6 perfectly, what is kind of broken, and what just looks at it with a mystified look on its face.
So to start:
Operating Systems
Windows
As far as I know, the first IPv6 stack was available for Windows 2000 via a separate download. XP bundled it by default, but left it uninstalled. Vista has the IPv6 stack enabled by default.
Linux
Got a pretty new IPv6 stack with 2.6. Had a working stack in 2.4. I'm pretty sure 2.2 had a functional stack too, as did 2.0. Don't quote me on that.
OpenBSD
Has supported IPv6 since 2.7.
Services/Servers
Apache
Apache has support IPv6 ever since the 2.0 release. Every component of apache that I tested supported IPv6 just fine, from general web page serving to SSL to proxies. Considering how much of the web is still on 1.3, all of those hosts will have to be upgraded to 2.0+ before a much wider IPv6 web base is available.
IIS
IIS (the Microsoft webserver) has supported IPv6 from their 6.0 release, also known as Server 2003. Most places use at least 2003 on their servers, the era of Win2k webservers kind of died out with Code Red and all of those other worms.
MySQL
Just kind of sits and looks at IPv6 like it has no clue what it is. Which is actually entirely true. Boo.
PostgreSQL
Talks happily with IPv6. At least I think. I'm too lazy to start my local copy and check. Their page on the matter isn't what one would call descriptive. No clue when this support was added.
MSSQL
Supported since their 2005 release.
Oracle
Offically supported as of 2006.
Samba
Supported as of the 3.2 release, which was actually just on June 1st of this year.
Windows SMB/CIFS
Supported with XP and onward. Probably Win2000 too.
So the servers are looking pretty good. Unless you run MySQL, which is pretty much everyone. Boo.
At a minimum, we can serve any content over HTTP just fine, and we can access most database just fine too, unless your name starts with a "My" and ends with a "SQL."
End-user programs
Mozilla Suite (and Firefox, Thunderbird, Seamonkey and friends)
Native IPv6 support, ever since the year 2000. Still has some work to be done according to the meta bug, but pretty much all of those bugs are on random operating systems that don't adversely change your ability to connect to IPv6 enabled sites.
Internet Explorer
Supported IPv6 ever since 4.0, once you applied a patch from their research division. Likewise real native support was probably with 5.0, if not it was by 6.0.
Outlook
Supported as of Outlook 2007.
Kopete
Supported. The KDE project has traces of IPv6 development starting around 1999. As far as I can tell, IPv6 is natively supported in every program in 3.5.
Pidgin
Supported. Not clue as of when due to the GAIM --> Pidgin name change, and I'm far too lazy to figure that out.
MSN Messenger, AIM, ICQ and friends
Who cares? (Likely not supported, though I doubt the client is the blocker in these cases.)
PuTTY
Supported since '04.
OpenSSH(d)
Supported. Probably since forever. Go OpenSSH.
irssi
Supported!
mIRC
Not supported without loading a third-party DLL. mIRC sucks anyway.
X-Chat
Supported.... on Windows since '03, *nix and friends likely even earlier.
I could go on and on and on. I won't, because I have no desire to list hundreds of thousands of software packages and their relative IPv6 states. Plus I'm getting tired and this entire post was spontaneous. Not too bad for 30 minutes of google.
But for the most part, we've got a great picture. Every operating system, browser, and web server supports IPv6 and supports it fantastically well. Nearly every program on *nix supports IPv6 and has for quite some time, and most of the big name Windows programs support IPv6 as well.
Not mentioned here was DNS, but the protocol has had support for it since (just about) forever and now that we have AAAA records for the root servers in the public DNS, DNS is good to go with IPv6 from start to finish.
Now we just have to work on the ISPs and home grade routers...
Footnote: one of the comments I got on my initial IPv6 entry was someone reporting success in integrating their LAN with IPv6. While I'm glad to hear it, I'm even more glad that when I got the "unapproved comment has been posted" notification e-mail, the corresponding IP address was a v6 address. The second I had IPv6 up and running on my server, I threw in AAAA records for pretty much everything. If I had to guess, they didn't even know they were using IPv6 to view this blog and post the comment - which is exactly the goal.
Likewise, IPv6 is pretty much useless if it is never used. I can assign the addresses all I please but ultimately if all I do is ping my desktop that sits "behind NAT" with it then for the most part the effort was wasted.
My server runs CentOS 5.2, my desktop runs Gentoo, my laptop Debian, my router Debian, my windows desktop Vista (dual boot Server 2008), and the Vista box also has three instances of OpenBSD running within VMWare.
I've got a pretty good testbed to see just what does/doesn't support IPv6, in terms of everything general web browsing to random system daemons to whatever end user programs you have a desire to run. So, I put together a small bit of info concerning what handles IPv6 perfectly, what is kind of broken, and what just looks at it with a mystified look on its face.
So to start:
Operating Systems
Windows
As far as I know, the first IPv6 stack was available for Windows 2000 via a separate download. XP bundled it by default, but left it uninstalled. Vista has the IPv6 stack enabled by default.
Linux
Got a pretty new IPv6 stack with 2.6. Had a working stack in 2.4. I'm pretty sure 2.2 had a functional stack too, as did 2.0. Don't quote me on that.
OpenBSD
Has supported IPv6 since 2.7.
Services/Servers
Apache
Apache has support IPv6 ever since the 2.0 release. Every component of apache that I tested supported IPv6 just fine, from general web page serving to SSL to proxies. Considering how much of the web is still on 1.3, all of those hosts will have to be upgraded to 2.0+ before a much wider IPv6 web base is available.
IIS
IIS (the Microsoft webserver) has supported IPv6 from their 6.0 release, also known as Server 2003. Most places use at least 2003 on their servers, the era of Win2k webservers kind of died out with Code Red and all of those other worms.
MySQL
Just kind of sits and looks at IPv6 like it has no clue what it is. Which is actually entirely true. Boo.
PostgreSQL
Talks happily with IPv6. At least I think. I'm too lazy to start my local copy and check. Their page on the matter isn't what one would call descriptive. No clue when this support was added.
MSSQL
Supported since their 2005 release.
Oracle
Offically supported as of 2006.
Samba
Supported as of the 3.2 release, which was actually just on June 1st of this year.
Windows SMB/CIFS
Supported with XP and onward. Probably Win2000 too.
So the servers are looking pretty good. Unless you run MySQL, which is pretty much everyone. Boo.
At a minimum, we can serve any content over HTTP just fine, and we can access most database just fine too, unless your name starts with a "My" and ends with a "SQL."
End-user programs
Mozilla Suite (and Firefox, Thunderbird, Seamonkey and friends)
Native IPv6 support, ever since the year 2000. Still has some work to be done according to the meta bug, but pretty much all of those bugs are on random operating systems that don't adversely change your ability to connect to IPv6 enabled sites.
Internet Explorer
Supported IPv6 ever since 4.0, once you applied a patch from their research division. Likewise real native support was probably with 5.0, if not it was by 6.0.
Outlook
Supported as of Outlook 2007.
Kopete
Supported. The KDE project has traces of IPv6 development starting around 1999. As far as I can tell, IPv6 is natively supported in every program in 3.5.
Pidgin
Supported. Not clue as of when due to the GAIM --> Pidgin name change, and I'm far too lazy to figure that out.
MSN Messenger, AIM, ICQ and friends
Who cares? (Likely not supported, though I doubt the client is the blocker in these cases.)
PuTTY
Supported since '04.
OpenSSH(d)
Supported. Probably since forever. Go OpenSSH.
irssi
Supported!
mIRC
Not supported without loading a third-party DLL. mIRC sucks anyway.
X-Chat
Supported.... on Windows since '03, *nix and friends likely even earlier.
I could go on and on and on. I won't, because I have no desire to list hundreds of thousands of software packages and their relative IPv6 states. Plus I'm getting tired and this entire post was spontaneous. Not too bad for 30 minutes of google.
But for the most part, we've got a great picture. Every operating system, browser, and web server supports IPv6 and supports it fantastically well. Nearly every program on *nix supports IPv6 and has for quite some time, and most of the big name Windows programs support IPv6 as well.
Not mentioned here was DNS, but the protocol has had support for it since (just about) forever and now that we have AAAA records for the root servers in the public DNS, DNS is good to go with IPv6 from start to finish.
Now we just have to work on the ISPs and home grade routers...
Footnote: one of the comments I got on my initial IPv6 entry was someone reporting success in integrating their LAN with IPv6. While I'm glad to hear it, I'm even more glad that when I got the "unapproved comment has been posted" notification e-mail, the corresponding IP address was a v6 address. The second I had IPv6 up and running on my server, I threw in AAAA records for pretty much everything. If I had to guess, they didn't even know they were using IPv6 to view this blog and post the comment - which is exactly the goal.
Not too long ago, after reading yet another "the internet is dying! We're running out of address space and it's all coming by November 2010 according to Cisco!" I realized that, "hey waitaminute - that's just about two years from now. That's... soon."
So I setup IPv6 for the machines I own. I still depend on IPv4 simply due to IPv6 not being available... well, most anywhere. At least not natively.
A big part of the reason that we don't have IPv6 in more places is because... well, circular dependency here, but because it isn't around. I can't plug my laptop into any other ISP's line and use IPv6 natively, and even if I could, the chances of the average home grade router working with it is about two.
Out of thousands.
So to get around this, IPv6 in IPv4 tunnels are used. They do exactly what their name implies: tunnels IPv6 data within IPv4 packets. The downsides to IPv6 tunneling are latency/overhead and... your ability to keep your IP addresses. If you don't have native IPv6, then your current hosting provider or ISP won't be the one giving it to you - meaning you get to get the IPs from a third party company. When your hosting provider or ISP turns IPv6 on, what are the chances that you'll be able to reassign entire blocks of IPv6 address space? Probably not too great. If you've got Comcast as your home ISP, I don't think that your tunnel broker is going to happily move your address blocks over to Comcast's control - at all.
While the latter point is generally a deal breaker for a lot of people, in the long run, I don't care. IP address reassignment happens all the time. There's no rule stating that you must drop your tunnels once you get native IPv6, and there's no reason why it would be overly problematic or painful either. Simply bring up the native IPv6, change the DNS records, and drop your tunnels a few days later.
With this knowledge in hand, I went poking around the vast area known as the Internet and selected Hurricane Electric's IPv6 Tunnel Broker. What really sold me (for free, that is) on using HE for my tunnel was really twofold: one, their views on IPv6 (which boil down to "we'd really like to be in business when IPv4 is exhausted, so we're going to deploy native IPv6 everywhere, provide a tunnel broker for free for anyone and everyone, and we're going to do it three years before crunch time") and two, the fact that it was free.
In selecting HE, I also got full reverse DNS control, selection of the closest HE router to my server, full control of a /64 subnet and a /48 subnet (by request, which I requested), the possibility of adding three more /64 subnets and three more /48 subnets to my account, and full operating system support (with instructions for setup with linux-net-tools, iproute2, *BSD, OSX, Solaris, Windows XP+, and Cisco).
Not bad for $0. I'm a happy customer (and a potential customer should I ever need colocation/dedicated servers).
I setup my account with HE, logged in, and was presented with simplistic instructions on how to setup my CentOS server.
I created a new 'sit' tunnel named 'he-ipv6', with remote endpoint 209.51.161.58 - coming from 64.22.124.36 - and then turned the link up. Easy enough. Then I added my /64 allocation to the newly created tunnel, and pointed the default route through that tunnel.
Wait a minute. That's it? I'm IPv6 enabled already?
From there, I requested a /48 subnet so I could allocate a few full /64 subnets to my house (a /64 for my LAN, wifi, and secondary wifi), brought some more tunnels up, and then from my desktop...
And now my desktop is IPv6 enabled. Go ahead, ping6 2001:470:d82b:ffff::2! You'll hit my home desktop. Then ping ::3 - my Vista box. Yup, that's right! My windows box is also on the IPv6 network. :fffe::2 would be my laptop on the wifi. The entire :fffd::0/64 subnet (and corresponding wifi AP) is unused currently, but perhaps once I decide to upgrade my router's software and play with wpa_supplicant that will change.
But why did I do this? What did I gain? Well, for starters, it was really fun to use HE's Looking Glass to run a traceroute to my desktop...
But in the end, I can now access all of my computers from behind NAT, without actually using any NAT - at all. I could drop the IPv4 addresses from some computers and still retain access to them, full access. This may prove to be both a blessing and a curse, but given time, we'll see..
(And yes, I know I shouldn't be using ::1 for my routers, that'll change soon enough.)
So I setup IPv6 for the machines I own. I still depend on IPv4 simply due to IPv6 not being available... well, most anywhere. At least not natively.
A big part of the reason that we don't have IPv6 in more places is because... well, circular dependency here, but because it isn't around. I can't plug my laptop into any other ISP's line and use IPv6 natively, and even if I could, the chances of the average home grade router working with it is about two.
Out of thousands.
So to get around this, IPv6 in IPv4 tunnels are used. They do exactly what their name implies: tunnels IPv6 data within IPv4 packets. The downsides to IPv6 tunneling are latency/overhead and... your ability to keep your IP addresses. If you don't have native IPv6, then your current hosting provider or ISP won't be the one giving it to you - meaning you get to get the IPs from a third party company. When your hosting provider or ISP turns IPv6 on, what are the chances that you'll be able to reassign entire blocks of IPv6 address space? Probably not too great. If you've got Comcast as your home ISP, I don't think that your tunnel broker is going to happily move your address blocks over to Comcast's control - at all.
While the latter point is generally a deal breaker for a lot of people, in the long run, I don't care. IP address reassignment happens all the time. There's no rule stating that you must drop your tunnels once you get native IPv6, and there's no reason why it would be overly problematic or painful either. Simply bring up the native IPv6, change the DNS records, and drop your tunnels a few days later.
With this knowledge in hand, I went poking around the vast area known as the Internet and selected Hurricane Electric's IPv6 Tunnel Broker. What really sold me (for free, that is) on using HE for my tunnel was really twofold: one, their views on IPv6 (which boil down to "we'd really like to be in business when IPv4 is exhausted, so we're going to deploy native IPv6 everywhere, provide a tunnel broker for free for anyone and everyone, and we're going to do it three years before crunch time") and two, the fact that it was free.
In selecting HE, I also got full reverse DNS control, selection of the closest HE router to my server, full control of a /64 subnet and a /48 subnet (by request, which I requested), the possibility of adding three more /64 subnets and three more /48 subnets to my account, and full operating system support (with instructions for setup with linux-net-tools, iproute2, *BSD, OSX, Solaris, Windows XP+, and Cisco).
Not bad for $0. I'm a happy customer (and a potential customer should I ever need colocation/dedicated servers).
I setup my account with HE, logged in, and was presented with simplistic instructions on how to setup my CentOS server.
ip tunnel add he-ipv6 mode sit remote 209.51.161.58 local 64.22.124.36 ttl 255 ip link set he-ipv6 up ip addr add 2001:470:4:b2::2/64 dev he-ipv6 ip route add ::/0 dev he-ipv6
I created a new 'sit' tunnel named 'he-ipv6', with remote endpoint 209.51.161.58 - coming from 64.22.124.36 - and then turned the link up. Easy enough. Then I added my /64 allocation to the newly created tunnel, and pointed the default route through that tunnel.
Wait a minute. That's it? I'm IPv6 enabled already?
[kyle@averageurl ~]$ ping6 ipv6.google.com PING ipv6.google.com(2001:4860:0:1001::68) 56 data bytes 64 bytes from 2001:4860:0:1001::68: icmp_seq=0 ttl=55 time=327 msYup...
From there, I requested a /48 subnet so I could allocate a few full /64 subnets to my house (a /64 for my LAN, wifi, and secondary wifi), brought some more tunnels up, and then from my desktop...
kyle@ksb ~ $ ping6 ipv6.google.com PING ipv6.google.com(2001:4860:0:2001::68) 56 data bytes 64 bytes from 2001:4860:0:2001::68: icmp_seq=1 ttl=54 time=325 ms
And now my desktop is IPv6 enabled. Go ahead, ping6 2001:470:d82b:ffff::2! You'll hit my home desktop. Then ping ::3 - my Vista box. Yup, that's right! My windows box is also on the IPv6 network. :fffe::2 would be my laptop on the wifi. The entire :fffd::0/64 subnet (and corresponding wifi AP) is unused currently, but perhaps once I decide to upgrade my router's software and play with wpa_supplicant that will change.
But why did I do this? What did I gain? Well, for starters, it was really fun to use HE's Looking Glass to run a traceroute to my desktop...
Tracing the route to IPv6 node 2001:470:d82b:ffff::2 from 1 to 30 hops 1 2 ms <1 ms <1 ms 2001:470:0:32::2 2 76 ms 75 ms 75 ms 2001:470:0:35::2 3 103 ms 103 ms 103 ms 2001:470:0:4b::2 4 103 ms 103 ms 103 ms 2001:470:0:8c::2 5 148 ms 148 ms 148 ms 2001:470:4:b2::1 6 234 ms 236 ms 238 ms 2001:470:d82b:ffff::1 7 234 ms 233 ms 233 ms 2001:470:d82b:ffff::2... while it sits behind my IPv4 NAT router. And then my Vista computer, and then my laptop connected to the wifi. Then I got to go take a look at The KAME project and check out the dancing turtle. It turns out that Google's IPv6 site also has an animated logo.
But in the end, I can now access all of my computers from behind NAT, without actually using any NAT - at all. I could drop the IPv4 addresses from some computers and still retain access to them, full access. This may prove to be both a blessing and a curse, but given time, we'll see..
(And yes, I know I shouldn't be using ::1 for my routers, that'll change soon enough.)
Feed Subscription
If you use an RSS reader, you can subscribe to a feed of all future entries tagged “ipv6”.