Jun 302011
 

Some have looked at my bicycle, with the HF regalia and have commented on how extreme the setup there is.

However, it is worth pointing out, my station only covers the bands between 80m and 70cm (3.5 ~ 450MHz).  The radio can do 160m, however my license doesn’t permit me to go there, and 80m really stretches the friendship of the autotuner as it is.

For true DC-to-daylight though, or very close to it, have a squiz at the portable/field day station setup Roy VK4ZQ has come up with.  This is as close as most will ever get to DC-to-daylight… covering all bands from 80m through to 3cm.  Nicely done.

Jun 232011
 

It was interesting when I posted a news article to the WIA regarding IPv6, how quickly it got shot down by “experts”.

A recent addition to our network was a 2008-model Apple MacBook, which I have dual-booting Gentoo and MacOS X 10.6.7 nicely.  One quirk of this particular laptop though, is that it will, when running its native OS, intermittently drop off the IPv4-only network.

The first tip-off to this is usually things like Skype ceasing to work.  Then I’ll notice DNS isn’t resolving (DNS is IPv6-accessible, but not many systems support RDNSS).

As a work-around to the problem, and also for my own self-education, I decided I’d have a crack at getting NAT64 and DNS64 to work.  What are they exactly?

NAT64 as the name suggests, is a variant of NAT that translates IPv6 to IPv4.  In doing so, allowing my MacBook that’s just disappeared from the face of the IPv4-only world, to still access the IPv4-part of the Internet.

DNS64 is a service that synthesizes AAAA records for host names that do not provide one.

The two work together to provide Internet access to an IPv6 only host.

What you will need to know

Make sure you have the following information on-hand.  I’ll use the following examples:

  • Your server’s IPv4 address on the local network: e.g. 192.168.0.1/24
  • IPv4 NAT address pool: This must not overlap with your existing networks.
    Examples use 192.168.255.0/24, I used 172.16.24.0/24
  • TAYGA’s tunnel IPv4 address: This will be the first address in the above subnet (i.e. 172.16.24.1)
  • Your network’s IPv6 subnet: e.g. 2001:dead:beef:1200::/56
  • IPv6 NAT address pool: This needs to be a non-overlapping portion of your address space.  In my case, I’m borrowing a /56 from AARNet, and I used a /64 for this, setting the lower 8-bits of the prefix to 0x64.  It only needs to be /96 in size.
    Example used: 2001:dead:beef:1264::/96

NAT64 setup

To get NAT64 working; start by installing TAYGA.  This is a userspace daemon uses the TUN device to route between IPv4 and IPv6.  On Gentoo, begin by running emerge tayga.  (You may need to keyword it.)

This installs the binary, but crucially, it comes with no init scripts.  You will need to create one yourself like this:

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-libs/gpm/files/gpm.rc6,v 1.12 2004/07/15 01:02:02 agriffis Exp $

depend() {
    need gw6c net.nat64
}

start() {
    ebegin "Starting tayga"
    start-stop-daemon --start --quiet -p /var/run/tayga.pid \
        --exec /usr/sbin/tayga -- \
        -u nobody -g nogroup \
        --pidfile /var/run/tayga.pid
    eend ${?}
}

stop() {
    ebegin "Stopping tayga"
    start-stop-daemon --stop --quiet --pidfile /var/run/tayga.pid
    eend ${?}
}

Now, edit /etc/tayga.conf, using /etc/tayga.conf.example as a guide.  There are comments provided.  The following are the settings I used (with the above addresses):

#
# TAYGA's IPv4 address.  This is NOT your router's IPv4 address!  TAYGA
# requires its own address because it acts as an IPv4 and IPv6 router, and
# needs to be able to send ICMP messages.  TAYGA will also respond to ICMP
# echo requests (ping) at this address.
#
# This address can safely be located inside the dynamic-pool prefix.
#
# Mandatory.
#
ipv4-addr 172.16.24.1
# ... etc ...
#
# The NAT64 prefix.  The IPv4 address space is mapped into the IPv6 address
# space by prepending this prefix to the IPv4 address.  Using a /96 prefix is
# recommended in most situations, but all lengths specified in RFC 6052 are
# supported.
#
# This must be a prefix selected from your organization's IPv6 address space
# or the Well-Known Prefix 64:ff9b::/96.  Note that using the Well-Known
# Prefix will prohibit IPv6 hosts from contacting IPv4 hosts that have private
# (RFC1918) addresses, per RFC 6052.
#
# The NAT64 prefix need not be specified if all required address mappings are
# listed in `map' directives.  (See below.)
#
# Optional.
#
prefix 2001:dead:beef:1264::/96
#
# Dynamic pool prefix.  IPv6 hosts which send traffic through TAYGA (and do
# not correspond to a static map or an IPv4-translatable address in the NAT64
# prefix) will be assigned an IPv4 address from the dynamic pool.  Dynamic
# maps are valid for 124 minutes after the last matching packet is seen.
#
# If no unassigned addresses remain in the dynamic pool (or no dynamic pool is
# configured), packets from unknown IPv6 hosts will be rejected with an ICMP
# unreachable error.
#
# Optional.
#
dynamic-pool 172.16.24.0/24
# ... etc ...

Now, having done this… you just need to make sure the nat64 device gets created and initialised by openrc.  In /etc/conf.d/net:

# NAT64 configuration for TAYGA
config_nat64=(
   "192.168.0.1/24"
   "2001:dead:beef:1264::1/64"
)
routes_nat64=(
        "172.16.24.0/24"
        "2001:dead:beef:1264::/96"
)

preup() {
        case ${IFACE} in
                nat64)
                        /usr/sbin/tayga --mktun
                        ;;
        esac
}

Now, symlink /etc/init.d/net.lo to /etc/init.d/net.nat64, start the tayga service, and you should find that you can ping e.g. 2001:dead:beef:1264::8.8.8.8 (8.8.8.8 is Google DNS).

DNS64 setup

All good and well if you know the IP addresses, but most people don’t.  Now emerge totd.  Use /usr/share/doc/totd-VERSION/totd.conf.sample.bz2 as an example for configuring /etc/totd.conf:

; $Id: totd.conf.sample,v 1.9 2003/09/17 15:56:20 dillema Exp $
; Totd sample configuration file
; you can have multiple forwarders, totd will always prefer
; forwarders listed early and only use forwarders listed later
; if the first ones are unresponsive.
forwarder 2001:dead:beef:1234::1 port 65053
forwarder 127.0.0.1 port 65053
forwarder 8.8.8.8 port 53
forwarder 8.8.4.4 port 53

; you can have multiple prefixes or even no prefixes at all
; totd uses them in round-robin fashion
prefix 2001:dead:beef:1264::
; the port totd listens on for incoming requests
port 53
; the pidfile to use (default: /var/run/totd.pid)
pidfile /var/run/totd.pid
; interfaces totd listens on (UDP only for now and not on Linux)
; If left out totd will only open wildcard sockets.
;interfaces br0
; 6to4 reverse lookup
stf

In my case, I have a local caching name-server (BIND), which I’ve moved to port 65053. The trick-or-treat daemon now sits on port 53 where the rest of the network expects it. You can now start the totd service, point your /etc/resolv.conf files to it, and everything should Just Work.

Testing

Easiest way is to shut off IPv4, and set up /etc/resolv.conf on your client with the IPv6 address of your server running totd.  You should now be able to browse IPv4-only sites as if IPv4 were running.  I achieved this test by plugging into Ethernet, turning off wicd (it kept wanting to start-up dhcpcd), then manually bringing the interface up and configuring /etc/resolv.conf.

Jun 202011
 

To whoever were responsible for developing this new feature in the latest Portage releases…

zhouman portage # FEATURES=-test USE=-handbook\ -doc emerge -eukDN --keep-going system kde-meta vim poppler =xulrunner-2.0.1-r1 =vim-core-7.3.189 =gvim-7.3.189 gst-plugins-base vim =gst-plugins-theora-0.10.32 =firefox-4.0.1-r1
Calculating dependencies... done!

!!! One or more updates have been skipped due to a dependency conflict:

app-editors/vim-core:0

(app-editors/vim-core-7.3.219::gentoo, ebuild scheduled for merge) conflicts with
~app-editors/vim-core-7.3.189 required by (app-editors/gvim-7.3.189::gentoo, binary scheduled for merge)
(app-editors/vim-core-7.3.219::gentoo, ebuild scheduled for merge) conflicts with
=vim-core-7.3.189

!!! The following update(s) have been skipped due to unsatisfied dependencies
!!! triggered by backtracking:

app-editors/vim:0
[binary R ] x11-proto/xf86vidmodeproto-2.3.1
[binary R ] sys-libs/zlib-1.2.5-r2
[binary R ] sys-libs/ncurses-5.9
[binary R ] x11-proto/xproto-7.0.21
[binary R ] virtual/libintl-0
[binary R *] sci-visualization/gnuplot-4.4.2-r1
[ ... ]
[ebuild N *] kde-base/kdebase-meta-4.6.4 USE="(-aqua)"
[binary R *] media-libs/mediastreamer-2.7.3-r3
[ebuild N *] kde-base/kopete-4.6.4 USE="addbookmarks autoreplace contactnotes highlight history jingle nowlistening pipes privacy sms ssl statistics texteffect translator urlpicpreview v4l2 xmpp zeroconf (-aqua) -debug -gadu -groupwise -handbook (-kdeenablefinal) -latex -meanwhile -msn -oscar -otr -qq -skype -testbed -webpresence -winpopup -yahoo"
[binary R *] media-plugins/mediastreamer-ilbc-2.0.3
[ebuild N *] kde-base/kdenetwork-meta-4.6.4 USE="(-aqua) -ppp"
[ebuild N *] kde-base/kde-meta-4.6.4 USE="accessibility nls (-aqua) -sdk -semantic-desktop"

The following keyword changes are necessary to proceed:
#required by kde-base/kdebase-runtime-meta-4.6.4, required by kde-base/kdebase-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kglobalaccel-4.6.4 **
#required by kde-base/kdemultimedia-meta-4.6.4[mplayer], required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/mplayerthumbs-4.6.4 **
#required by kde-base/kdeedu-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/rocs-4.6.4 **
#required by kde-base/kdegames-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kigo-4.6.4 **
#required by kde-base/kajongg-4.6.4, required by kde-base/kdegames-meta-4.6.4[python], required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/oxygen-icons-4.6.4 **
#required by kde-base/kdebase-runtime-meta-4.6.4, required by kde-base/kdebase-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kdebase-menu-4.6.4 **
#required by kde-base/kdeutils-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)

[...]

NOTE: This --autounmask behavior can be disabled by setting
EMERGE_DEFAULT_OPTS="--autounmask=n" in make.conf.

Use --autounmask-write to write changes to config files (honoring CONFIG_PROTECT).
zhouman portage #

THANK-YOU

You’ve just made my life trying to install and test big collections of software in Gentoo/MIPS much easier. 🙂

Jun 192011
 

Well, I’ve been meaning to get around to fixing up svxlink in Gentoo for a long time now. For those who don’t know, svxlink is a client and server for the EchoLink amateur radio linking system.

We had to stop releasing the Qtel client, as it relied on Qt3 which we no longer ship in Gentoo.  On top of this, the ebuild installed non-Gentoo init scripts, fails to build with gcc-4.6 and fails due to underlinking.  (My thanks go to Diego for pointing these flaws out.)

At the moment I’m working on the first problem, which is that the builds that were in-tree are crusty and old.  svxlink did release version 11.05 not long back, and ohh yes, they’ve changed their versioning scheme too to match Ubuntu.  However, their trunk branch is still dependent on Qt3 if you want Qtel.  There is an experimental Qt4 branch, which is what I’ve been working with.

One irritation I had was trying to make it possible to install the client component or the server component.  svxlink has its own, very custom, build system based on recursive makefiles.  (Yes, I know, considered harmful and all that.)  The build system first builds the core libraries, then it starts looking at Qtel and svxlink’s server components.  The first thing was to try and split these up.

The new ebuilds will introduce a svxlink-libs package.  This is relatively straightforward, and it just builds & installs the libasync, libechlib and liblocationinfo libraries.  The catch is when building qtel and svxlink, the build system looks for the built binaries inside the source tree.

I have submitted a patch upstream that remedies this.  Eventually I’ll look at how we can fix some of the other flaws in the build system.  So far I’m still battling svxlink itself, but I soon will have svxlink-libs and qtel packages available for testing in the Portage tree.  svxlink itself will also need to wait until I can set up a test node on simplex somewhere… my O2 looks like a likely possibility.

I’ll keep you all informed as this progresses.  Qtel appears to be working (although I’m battling some funnies with the sound device on the Apple MacBook)… just a matter of fixing some issues with the build system for svxlink and I should be able to have svxlink back in the tree once again.

Jun 172011
 

If you live in Australia, do not purchase or operate this headset.

This is what the offending article looks like:This headset radiates a carrier on the 2m amateur band.  Specifically around 147.000MHz.  In some parts of the world, the 2m amateur band extends from 144.000MHz to 146.000MHz.  Here in Australia however, it goes all the way up to 148MHz, meaning these headsets are effectively pirate stations smack bang in the middle of the FM portion of the 2m band.  They are probably quite legal in the country where they were originally sold, but they are not legal here.

There are a lot of repeaters that operate around 147MHz, particularly in Brisbane.  VK4RBN at Mt. Glorious is one of the most heavily used repeaters in Brisbane, and so you can guarantee there are people listening on that frequency that will hear your transmissions, and will likely complain.  We’re also getting good at direction finding.

So far the importers have gotten little more than a slap over the wrist for the illegal C-tick approval of these devices.  I think the ACMA need to grow some teeth here if we expect to get on top of this problem.  The last offenders were lucky, they got the choice of stopping the use of the headset, or copping a $400 fine … the article was not confiscated.  The importers got a $1500 fine… nowhere near enough, and the devices continue to be sold by distributors.

The end user may not have been technical enough to understand what was going on, but the importers almost certainly should have if they were slapping C-ticks on equipment.

More information:

Jun 162011
 

Well, after 9 years of solid service, the Nokia 3310 I’ve been using finally bit the dust this weekend.  And so now I’m getting my wish list together for what I’m looking for in a new device.

One thing that gives me the irrits is companies trying to tell you the customer, what one wants.

The phone I had, was bought outright (I think for something like AU$350).  It replaced an older Ericsson A1018S which had been bought a few years earlier on a pre-paid service… that phone sat in its box unused and the prepaid service expired.  When I came to use it, we bought a new ~AU$10/month service through Telstra… and I’ve been pretty much plodding along with that.

My needs are basic … I send the occasional text message, and make the odd phone call, but normally the phone will remain dormant.  I rarely go over $30/month on a phone bill.

One feature of the Nokia 3310 I thought initially was a gimmick, was the voice tags facility in the phone book.  With a hands-free kit plugged in, you pressed the answer button momentarily, then announced the names of one of the contacts in the phone book.  It would then try to match that to one of the voice tags, and on positive match, would dial that number.  This was invaluable on the bicycle, as it turned out.  I had the headset embedded in the helmet, with the PTT button on the handlebars for communicating via radio … the same rig plugged in the phone, the PTT became the answer button, and it meant that in order to dial a frequently used number, I didn’t have to take my hands off the handlebars at all.

Looks like I’ll have to learn to live without this feature.  The other thing was the older phone had a monochrome LCD screen … reflective type.  Much easier to read in broad daylight than today’s back-lit colour fancy affairs.  It was also less prone to damage than touch-screen devices.

One thorn though; the 3310 had no external antenna jack.  If you were in a bad spot, tough luck.  And there have been times I have been in such locations.  If you can plug in an external antenna, you can either get a higher gain antenna/directional antenna, or put a low-gain antenna up high, and get better performance.  A dipole may not offer much gain, but it should do considerably better than the minimal thing built into the handset, and of course it will do much better up high where the handset can only be as high as the user’s head (or their hand, if using a headset).

Now that the phone has died, I’m in the market for a new one.  The phone I am using for now is a ZTE T7.  Not overly bad, I suppose it’s taking a bit of getting used to.

Something I’d like to investigate is the possibility of being able to develop applications for these more modern phones.  While I traditionally criticised the more modern phones with all the bells and whistles, I recognise this is where industry is moving.

I don’t care for a camera on a phone.  The GPS devices on some of them are pretty minimal in functionality and are inconvenient to use – at least the T7’s one is.  The T7 GPS will only give you latitude and longitude, maybe altitude and speed, and has no track-log ability, and certainly no maps or navigation.  Plus you can’t refer to it while on a call.

I can make up for some shortcomings in a phone if I can code applications to run on it.  With the modern smartphones, this is a possibility that didn’t exist back in 2002 when we bought the 3310.  These days, iOS, Android, Windows Phone, Maemo and the like are all the rage.  The T7 appears to have Java on it, probably J2ME… I’ll have to research this. (Update: it does… MIDP 2.0)

For me to make use of the features, I’d really need to be able to develop the applications using the (mostly Linux-based) tools I have, or can get easily.  Microsoft Visual Studio is something like AU$1000, and I really disliked WinCE 5.0 so there goes Windows Phone.  Apple iOS has all sorts of strings attached to it, and while the development kit is only $5 (if you can pay)… it’s a 4.5GB download!  No thank-you.

Android and Maemo however are quite viable for my needs.

However, the key thing for me, having a phone that can work in regional areas, and can be enhanced with an external antenna, is more important to me, than having all the software bells and whistles.  When I look at what’s on the market today, it seems one cannot purchase a ruggedised Android-based phone, which features an external antenna jack.  In fact, so far the only devices I know of available to me, look to be a small subset of the ZTE range, or one (non-Android) Samsung phone.

Pathetic.

And no, don’t even bother mentioning capacitive/inductive coupling cradles… the 6dB gain I might get from a decent antenna will be lost in the very lossy coupling.  They are a very poor workaround, they are not a solution.

As an open-source enthusiast, something which at least respects this would be in my favour.  If I can adapt what’s there to suit my needs, this makes life easier.  Calendaring, for instance, I can code up something on my web server to share a calendar with my device.  If I can make my own software, it can use any protocol I like… otherwise I have to work within its confines.  Okay, I can live with that, but only if I am told what those confines are.  If I have a specification of the synchronisation protocol used between device and phone, I can possibly do something to scratch my own itch (and possibly others’), but if it’s all in secret, I am powerless to do anything.

It seems the assumption on the part of the mobile phone manufacturers as a whole, is that if you live or work out in a regional area (or even if you only travel out there on rare occasions), you’re obviously too stupid to care.  This assumption I greatly object to.  The assumption that, because you’re a dumb user, you only know of a two-OS IT world, where anything that isn’t plastered with Windows logos, must obviously be emblazoned with a piece of fruit that has a chunk missing from it.

Wrong.

I’m still continuing to look around.  Needless to say, I’m getting pretty disgusted by the lack of choice out there.

Jun 162011
 

My Nokia 3310 died recently, and so I’ve been borrowing my father’s old ZTE T7 mobile phone.  This has had one useful side-effect in that I was able to back-up the contents of my SIM card, namely, the phonebook.

JoinME for MacOS X is quite capable of loading the data from the phone and storing it on the computer, but there is one problem… where did it go?

Turns out, after a quick fiddle with Instruments.app (part of the Xcode suite) I found them under /System/Library/MobileList/phoneBook.plist.  They’re in the standard Mac OS X plist file format, which is an XML derivative.  I have now backed this file up into a place where I know where to find it and can free up some much needed space on the SIM. 🙂

Ohh, and to ZTE: You know fellas, it’d be nice if you didn’t keep trying to hide our data on us!  The phone book on my SIM card is not your intellectual property.

Jun 142011
 
  1. The BP servo on the way to Donnybrook is bad when it comes to caravans… the one heading back to Brisbane is even worse.
  2. Horses have an aversion to orange and red coloured clothing (pity the organisers handed out red caps and orange shirts… also good thing we’re not the SES).
  3. Do not shine a torch in the eyes of a horse, especially not a 3W LED torch!
  4. Be prepared for organisers to give you information at the last possible minute, and not consider the needs of the radio communications people.
  5. Sometimes a short-cut, isn’t.
Jun 082011
 

Well… has anyone noticed anything different about the ‘net?

stuartl@atomos ~ $ host www.google.com.au
www.google.com.au is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.237.52
www.l.google.com has address 74.125.237.48
www.l.google.com has address 74.125.237.49
www.l.google.com has address 74.125.237.50
www.l.google.com has address 74.125.237.51
www.l.google.com has IPv6 address 2404:6800:4006:802::1011

I knew World IPv6 day was coming up, but it seems it snuck up on me and I barely noticed. Likely a testament to the fact we run a dual-stack network here, and so everything magically Just Worked™ as it should. Indeed, a lot of websites are now dual-stack, as is much of the gentoo.org infrastructure, Google (as seen above), FaceBook, and numerous other sites.

Sadly, a lot of ISPs here in Australia did the demented ostrich act when it came to IPv6. I wonder how many technical support calls they received, with users complaining about websites being slow to load up or failing to connect.

iTel, formerly “Global Info-Links”, now calling themselves “South East Community Telco“… were one of the masses that drove their RFC791-only heads in the sand and pretended that the entire Internet can be compressed into 32-bits of address space. We’ve been waiting to hear back from them on their plans for addressing since January as we’d like to upgrade the 512/128kbps ADSL link we use here. (Anyone noticed this site tends to load up a bit slow? That 128kbps figure is the reason why.)

We’ve been with this ISP since 1996. That’s quite a long innings… We’ve stayed put because until now we’ve been happy with the service. 512kbps was quite fast when we upgraded from 56kbps PSTN dialup (14.4kbps dialup when we first started… still have that modem too!). These days it plods along, but the 128kbps uplink is a notable thorn in my side with my telecommuting. So we’re looking at ADSL2+.

However, there’s one hitch. iTel is only a fairly small ISP. At the moment they do the noble thing of providing static public addresses on IPv4 for all fixed-broadband customers, but how long will that last? The last thing I want, is to sign up a contract for 12 months, then find out that in 6 months they need to move us behind CGN (Carrier grade NAT) to squeeze in some more customers. That won’t fly for us. I’d ideally like to ditch the 6-in-4 tunnel I have with AARNet and go native, or at the very least, swap it with one terminated at the ISP, but that doesn’t seem to be happening anytime soon.

At the moment there is only one ISP I know of that offers any sort of IPv6 connectivity. Internode. Kudos to them for taking the pioneering step! I’m seriously looking in their direction. I’m also hoping the NBN that we keep hearing about, is IPv6 enabled… and I’m holding out with the hope that our little suburb might soon be getting the long strands of glass laid down our street. If it’s only another year or so, it may be worth just hanging on with ADSL1 until then.

Thankfully, we do have the 6-in-4 tunnel through AARNet (and my greatest gratitude to them for providing it). There is a growing community on this newer protocol… I’m also happy to report absolutely 0 spam via IPv6… any spam or malware thus far has been via IPv4 … although I know this won’t last. The good news there is that with one unique address per computer (instead of per customer, or worse, per 100+ customers), it should be easier to track down the guilty party causing such Internet shenanigans. CGN by comparison is likely to be a spammer’s playground.

What am I doing about IPv6 deployment? Aside from my small-time tinkering with the network here… any socket programming I do today is at the very least dual-stack. One of my hobby projects is a digital mode stack for amateur radio… if I get my way it’ll be IPv6-only when used on a computer network.

One of my work projects involves interfacing some proprietary software to some power meters using RS-232 and RS-485 to Ethernet bridging devices. Even though the devices themselves are IPv4 only (and will be for the foreseeable future), I’m designing the software to handle IPv6. Doing this, future proofs the software. Surprisingly, I’m finding it easier to just design for dual-stack than it is to develop a IPv4-only application. If you’re building an application today, dual-stack IMHO must be part of the strategy if the application is going to work beyond this decade.

Some have asked about IPv6 on packet… sadly AX.25 packet does not go anywhere near fast enough to make IPv6 (or indeed, IPv4) networking a viable option on packet radio using existing TNCs… however I think IPv6 will, and should, play a much bigger part in amateur radio communications than it presently does… we can’t expect to hold on to the 44.0.0.0/8 subnet for much longer.

To the ISPs that are lagging behind, I say get moving! IPv4 is older than I am! This is especially true of the smaller ISPs… if you don’t move, you will get squeezed out of the future Internet connection market as address space gets consumed. To the nay-sayers who keep telling us that something else will replace IPv4, to you I say get moving… you haven’t got long to invent this magical silver bullet, in fact I say you’ve left it too late.