Posts Tagged ‘ipv6’

Calling on DJB

Friday, December 18th, 2009

Perhaps you’ve used his software before. Perhaps you know it’s a little “funky” in design, because DJB does things his way. But this is not to say that his software is faulty. Unfortunately, though, he is not known as one who updates his software to fix bugs or add new functionality to them.

I’ve been using Qmail for over a decade now. For most of this time, I’ve been using netqmail, which is the last release of Qmail that DJB did (1.03 I believe is the version number) with something ilke 25-35 patches on top of it. Some of those are trivial, such as the #include patch. Others are much more involved.

I have come upon something else now that could use a little love. I use daemontools and ucspi-tcp to launch a number of my network services on my linux systems. I prefer this method as it’s a non-obtrusive and low resource method to make sure that if a service controlling daemon or other program crashes, that it gets relaunched automatically within 5 seconds.

Just the other day, a friend of mine from the FreeSWITCH community was complaining about troubles he has with NAT. I too hate NAT, especially when it comes to working with VoIP, and needed a little excuse to roll out ipv6 on my network. So I, taking a little break from writing C code and SQL stored procedures, decided to re-establish my ipv6 tunnel connection to Hurricane Electric. After working out the routing, radvd, and firewalling with ip6tables (which, I must say, is WAAAAY easier when you don’t have to muck around with NAT), I noticed that there is no ipv6 support in ucspi-tcp 0.88. I cannot say that I am surprised, given how long ago it was since 0.88 was initially released. And despite that DJB granted a less restrictive license (possibly it was straight to public domain? I don’t remember.), he still hosts the source and documentation on his website. It therefore seems that he still claims ownership over the source code in the sense that it was his effort that created them. Now a little Google searching reveals some patches out there for ucspi-tcp to add ipv6 support. But I prefer to get these patches from recognized sources, especially DJB himself. So this is a call out to DJB to ask that he incorporate this and other patches that people have provided over the years for this and his other software (where it makes sense that is). There are forks now of his software, but I am a little apprehensive about grabbing one of these forked projects instead of the DJB one.

Perhaps what I am asking here is unrealistic. Perhaps DJB gave the projects to the public domain because he has no intention to continue to support them. Perhaps I didn’t get that memo. I guess only he could tell us for sure.

A Few Random Thoughts

Monday, December 14th, 2009

I’m up later than I probably should be tonight, but as I’m trying to wind down to go to sleep, some thoughts have been running through my mind. On the heels of this article, I am once again reminded about the issue of Net Neutrality. While I am completely for the concept of Net Neutrality in the sense that I think it should be illegal for the pipeline provider to reclassify your packets, there is one single edge case that comes to my mind that is not like the others. This issue is about emergency services calls over VoIP (or whatever the defacto technology is at any point in time in the future). In this one case the providers should be allowed, in fact even required, to grant higher priority to calls, as it could very well be a matter of life and death.

That brings me to another issue. The FCC is starting to take preliminary comments about an eventual switchover from the current TDM phone network that we all know to a packet voice network (in this case, specifically VoIP). Now there is at least one major kink in handling routing of emergency services calls. If I were managing a service provider (i.e. an ITSP), I would not want to rely on the consumer to keep all records up to date, and what of the case where somebody is running their own PBX and has multiple users from multiple geographic locations? As we are all waiting to see if the USA in general will join the 1990’s by finally starting to roll out IPv6 natively on the wire on a grand scale, there *might* be a solution to that built into IPv6. Another member of the FreeSWITCH community suggested that the IPv6 mobility extensions might hold the key to this problem. His understanding is that information about the geographical location of the system using the IP address gets (or can get) encoded into the packets with the mobility extensions. I myself have not yet read up on IPv6 mobility extensions, so if any of you have and have some input on this, I’d love to hear about it.