NAT Is Not Security

At best, Network Address Translation is security by obscurity. In other words, NAT is not security. Where did this idea come from? Even worse, it comes up regularly when discussing IPv6, which does not have NAT, a condition that that is seen as a huge negative of IPv6.

Of course, a properly configured stateful firewall will have exactly the same effect as NAT. I suppose the problem is the "properly configured" part. People expect things to just work without requiring any knowledge or skills.

A Surfeit Of IPv6

I have only now realized just how generous Hurricane Electric's Tunnel Broker service is. I was looking at the reverse DNS options when I noticed the IP ranges it delegates is different from the IPs on the end points of the tunnel. Needless to say, I was confused. (Yeah, yeah, I know: I was more confused than usual, right?)

The tunnel end point IPs are already in a /64 (apparently this is a RFC requirement) so I assumed that I was supposed to use the other IPs from that range. It works and there's nothing technically wrong with using them, except you cannot delegate reverse DNS because HE is already doing that to provide names for the end points. If you want to delegate rDNS, you have to use the actual /64 that was assigned to you. Well duh!

But wait! There's more! If you have multiple network segments (as I do), you can request a /48 which lets you have 65536 /64 subnets! So, with this free service, you can get up to 65538 /64's (less two IPs for the tunnel end points). I'll leave calculating the actual number of IPs as an exercise for reader. My head hurts just thinking about it.

Low Priority Projects

I have a long standing IPv6 issue that I found some time to research again today. I use a free IPv6 tunnel service from Hurricane Electric which works great in most respects, except that I can't get sustained throughput for any lengthy data transfer. I've only tested it with NNTP and HTTP traffic but I assume it happens with other types as well. Since I don't depend on IPv6 for anything, solving the problem is a low priority, but I do work on it once in a while. Surprisingly, despite the slow pace, I am making progress.

Previous research has convinced me that it is an MTU issue. However, forcing the the MTU to a known value, had no effect at all. Today's research gave me a few new clues to the problem, but I just ran out of time to convert the new information into an experiment. While it was tempting to just keep hacking away at the problem, that could easily lead to several hours more work before you know it. It's always best to keep the low priority projects under control, otherwise the important stuff won't get done.

Conversion To IPv6

Will the conversion to IPv6 hurt? Yes. Yes, it will. And it is going hurt a lot. If you want all the gory details, I suggest you read this very long, detailed Arstechnica article, which is appropriately titled: There Is No Plan B.

While there may an entrepreneurial opportunity here, it will only materialize after the proverbial shit hits the fan. Most businesses are so focused on quarterly results, they simply won't care about converting to IPv6 until it causes them to lose income. Just as with with the Y2K bug, some consultants are going make a killing with the conversion to IPv6.

TekSavvy Testing IPv6

My ISP, TekSavvy Solutions, is beta testing native IPv6. I'm almost sure that they will be the first Canadian ISP to make IPv6 available to the end user. One benefit is that Bell apparently can't throttle IPv6 (yet). So, apart from the obvious PR benefits of offering IPv6, Teksavvy is giving its users yet another way of sticking it to the man. Really, do I need any other reason to want IPv6? ^_^

Java IPv6 Weirdness

A couple of weeks ago I discovered that Java applets were broken on my Debian/sid desktop system. I finally found the solution but it is just plain weird.

Debian recently disabled IPv4 traffic over IPv6 connections. (I didn't even know such a thing was possible.) Under the new policy, if you need to do both types of traffic, you have to open separate connections for IPv4 and IPv6. Java apparently expects IPv4 traffic to work over IPv6 connections by default.

Because that last sentence is kind of scary, I'm going to assume that I don't really understand the problem.

IPv6 Router Complete

My IPv6 router is complete. I ignored radvd for now and just used a static setup since my network is so simple. I should probably learn to configure radvd later since it is useful for more complex network arrangements. For now, I'm just playing.

Once I decided on a static configuration, I needed a sensible way to subnet the 2⁶⁴ addresses. I quickly discovered that there are as many different ways to subnet the address space as there are addresses. Once I realized there was no magic formula, I just made up my own system.

Since I already have IPv4 subnets configured, I decided to map those into the /64 address space, so 10.x.y.z/16 became 2001:470:1c:137:xx::yyzz/80, with x, y, and z simply converted to hexadecimal. It is a bit wasteful of addresses but I can live with that. Although the mapping is logical, I will never be able to remember something that long, so the the next job is IPv6 DNS entries for the hosts on my network.

The best part is that IPv6 does not require Network Address Translation (NAT) any more. Every address is routable so you have 2⁶⁴ static IPs! NAT just sucked and I will not mourn its passing for a femtosecond.

IPv6 Setup Delayed

Yesterday was wonderfully productive. Today was the exact opposite. I felt tired all day and only picked half-heartedly at setting up IPv6 routing on the firewall. I did learn about radvd but couldn't motivated myself to actually install and configure it.

I'm totally in awe at how many IPv6 addresses my free tunnelbroker.net account gives me. 2⁶⁴ addresses is just ridiculous! And they are giving it away too. I mean, I know the number of available IPv6 addresses is huge (an understatement, if ever there was one) but it seems like giving /64 prefixes to hobbyists and experimenters like me is just overkill.

I wonder how much a permanent IPv6 /64 assignment costs and where can I get it?

New Firewall Running

I was up early this morning to finish my long outstanding project to setup a new firewall server. The server has been (mostly) ready for a while now but I've been putting off finishing the job, because I knew the final setup would require a lot messy configuration changes on all the computers on my network.

As I expected it took a few hours to get back to normal Internet access after all the minor details were cleared away. But it all works now and I'm happy with the results. I'm sure it is my imagination but web pages seem to be loading a little faster with the new firewall. The new server is slightly faster but I doubt that it would make a noticeable difference.

There is one remaining issue: IPv6. The first problem was the version of Shorewall in Debian Lenny/stable does not support IPv6, but I found a back port of the newer Shorewall on the package maintainers web site, so that obstacle has been cleared. I've never set up an IPv6 network before, so I'm sure there will be other head scratching moments.

HellaNZB, IPv6, Oh Dear!

I did some playing with hellanzb and it suits my needs exactly. My initial tests with TekSavvy's news server worked really well but past experience with Usenet is you should have at least a couple of extra news servers in case of missing articles.

This thread on the the TekSavvy forum recommended a number of free news servers for binary groups. These days "free news server" and "binary groups" are never mentioned in the same sentence. Even TekSavvy's news server is not free as you have to pay for the static IP (which costs a whopping $4!) to use the server. The catch with these "free new servers" is they are only accessible on IPv6, which explains why I setup a IPV6 tunnel previously.

But hellanzb depends on Twisted which is a Python framework for handling asynchronous I/O. Unfortunately, Twisted is not IPv6 capable so hellanzb can't access the IPv6 new servers. Frankly, this was a big suprise as Twisted is the Swiss Army knife for asynchronous I/O in the Python world. The ticket for this problem is already two years old, so it is obvious that the Twisted devs are not very interested in working on it.

The solution suggested by this hellanzb ticket is to use a utility like 6tunnel to forward IPv4 connections to the IPv6 network. It works, but it is ugly as sin and there's a performance penalty. Despite this problem I'm happy with hellanzb; the lack of IPv6 support is really Twisted's fault.

Dabbling With IPv6

I'm experimenting with IPv6 tunnels and got my first one working today. There's a reason for doing this but I'll explain that another time. To gain access to the IPv6 universe, I created an account at tunnelbroker.net and created a basic tunnel.

I added the following to /etc/network/interfaces.

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
        endpoint 216.66.38.58
        local 206.248.172.224
        ttl 255
        address 2001:470:1c:137::2
        netmask 64
        mtu 1480
        up ip route add default via 2001:470:1c:137::1 dev he-ipv6

This configuration will ensure the tunnel will be initialized when the system boots.

I also installed shorewall6 so that I can firewall the IPv6 connections. Shorewall's approach to IPv6 firewalling is to make it a completely separate system from the IPv4 firewall. Fortunately I've had lots of practice with shorewall so it didn't take too long to get a minimal configuration setup.

At this point I can ping and connect to IPv6 hosts but I cannot ping my IPv6 address using an online tool. Next step is the real reason for this experiment.