ircDDBGateway

The Importance of IPv6 in Amateur Radio

What most of us call an IP address, in the form 1.2.3.4, is really an IP Version 4 (IPv4) address. IPv4 has a serious limitation. The largest number that can be respresented in the 32 bit binary value of an IPv4 address is 2 ^ 32 (4,294,967,296). Believe it or not, these addresses are in short supply.

IPv6 was created as a solution almost 23 years ago. An important specification document was published in December 1998. IPv6 World Launch Day was 10 years ago! IPv6 is not new. IPv6 provides 2 ^ 128 (340 trillion trillion trillion) addresses. So why aren’t we all using IPv6 now?

Aside from a bounty of address space, there are other reasons to adopt IPv6. Large network providers have built new and optimized infrastructure with IPv6 in mind. Here’s an example of how this can work to your advantage.

The 020 Digital Multiprotocol system has bridge to the Brandmeister DMR (BM) system. Low network latency is of critical importance in delivering high quality voice connections. Any network latency created issues are amplified when voice transmissions are passed through multiple applications and protocol transcoding hops.

Using the IPv4 network, ping time between our end of the bridge and BM is about 8 ms. That is actually pretty good. IPv6 blows that away, with about 1.5 ms ping times. That reason was good enough for me to get my hands dirty and modify some Python code to be IPv6 capable.

IPv6 also helps with the problem of NAT and port forwarding on residential routers. Simply put, NAT can be thrown into the trash bin of computing history. Instead of just one address, the minimum network assignment under IPv6 is 64 bits. That is 2 ^ 64 addresses!

Several ham software authors and volunteers are working on updating their software to be IPv6 capable. My amateur radio wishlist for full IPv6 capability includes xlxd, DMRGateway and ircDDBGateway. HBlink will be there once my pull request is merged. That is the Python code I referred to that links the 020 world to Brandmeister.

N7TAE has a functional QnetGateway using IPv6. I could not get it to work with my DVAPs and will need to followup up with Tom, but he has provided a wide range of hardware support including MMDVM devices.

There are a lot of bits and pieces that will be involved with updating amateur radio software, much of it ancient, to IPv6. So let’s start now. This will take time. And, if you’re a ham working on some new software for the amateur radio world, please make sure that it supports IPv6 out of the box.

73 de K2IE

Net 44 and Icom Terminal Mode

Since before the days of the commercial internet, amateur radio operators have had their own Class A block of IPv4 addresses. Net 44 or AMPRNet is a non-routeable amateur radio experimentation network and access is only available to licensed radio amateurs around the world.

While hams have been experimenting with Net 44 since the early days of packet radio, interconnecting RF and wired networks via AX.25, I’m a relative newcomer. A couple members of the 020 Team are up and running on the AMPRNet and looking at potential use cases.

My driving use case is the to get around the limitation of one ircddbgateway behind a single network address translation (NAT). This limitation prevented me from running an ircddbgateway to service my Pi-Star hotspots and to use Icom Terminal Mode on my IC-9700 at the same time. What is the limitation? UDP port 40000, used by the ircddb protocol, must be forwarded to the destination system. As the Highlander said, “There can be only one.”

By establishing a Net 44 subnet behind my firewall and assigning a Net 44 address to the Icom, I get around the single IP NAT limitation. There’s a bit more to this, but a Net 44 gateway can be run on a spare Raspberry Pi or your internet gateway router (or any Linux based host). This article is not, however, meant to be an implementation guide but more of a starting point for thought.

It is also an announcement that XLX020 is now available on the AMPRNet for use by those with Icom Terminal Mode radios. Our gateway address on the AMPRNet is 44.64.12.57 and you can connect to any module using a To Call of /XLX020m (replace m with your module of choice). If you’re on Net 44, feel free to connect.

73 de K2IE

Connect to XLX as XLX!

Yes, you can connect to an XLX reflector with D-Star without having to use an XRF or DCS connect string! This is a supported feature of ircDDBGateway (which is leveraged by the Pi-Star distribution).

If you’re running a recent version of ircDDBGateway (such as the one in Pi-Star 4.1 releases), you can connect via an XLXnnnmL type command.

In this case nnn is the 3 digit reflector number and m is the module letter.

For example:

XLX020AL

ircddbgateway will then use DCS to make the connection to connect to module A of reflector XLX020.

For this to work properly, be certain that the following is set in your ircddbgateway config file:

xlxHostsFileUrl http://xlxapi.rlx.lu/api.php?do=GetXLXDMRMaster

You can check this in the Pi-Star expert mode configuration for ircDDBGateway.

73

You Say Protocol, I Say Reflector…

Is XLX a protocol? Is it a type of reflector? Why are we asking these questions?

There is a bit of a debate going on now in D-Star circles as to how the end user (you OM or YL) of a hotspot or repeater should connect to an XLX reflector. I’ve exchanged emails with some notable folks in amateur radio software development circles (Luc LX1IQ, Andy MW0MWZ, and Tom N7TAE) on the subject. The software developers are all in agreement. XLX is not a protocol, it is a type of reflector. On that point, they are quite correct.

To varying extents, each have indicated that the preferred way to access a reflector is via the protocol, node and module notation. Using this paradigm, to access XLX020A via DExtra protocol, you’d connect to XRF020A. But there could be an XRF020A that is not XLX020A. We’ll get to that in a couple of paragraphs.

On the other hand, Jonathan Naylor (G4KLX) has implemented the ability for ircDDBGateway to access XLX reflectors by name. Since all XLX reflectors support DCS protocol and DCS is the most modern of the three D-Star reflector protocols, ircddbgateway defaults to DCS connections. This make perfect sense to me. And it works!

Note: In case you did not know, ircDDBGateway is part of the software suite that comprises the exceedingly popular Pi-Star distribution. May of the tools provided as part of Pi-Star were developed by G4KLX.

As an end user of a hotspot or repeater, I just want to connect. There is also the problem of amgibuity. You can have an REF123, an XRF123, a DCS123, and an XLX123. They may or may not be the same destination. But XLX123 is a specific destination, as are the other three. So the best way to connect to an XLX reflector for the end user would be to allow the end user to specify that destination.

To continue to require that XLX connection requests specify a particular protocol, when there is no specific reason to do so, would be as confusing as requiring the end user of a mobile phone to specify what network the called party is connected to. Yes, the option is there, but let’s make this simple.

I’d like to see the various hotspot platforms adopt this aproach. What do you think?

73 de K2DLS

Setting up a STARnet Routing Group

Last month I wrote about callsign routing in a D-Star environment. I mentioned that it is possible to create your own Starnet routing group for you and your friends to chat on. If you’re running Pi-Star, here is how to do it.

On the Pi-Star Expert Editors menu, select ircDDBGateway. This component (written by G4KLX) of the Pi-Star distribution contains the Starnet server. Starnet uses callsign routing to set up a group which can be subscribed to by any valid user on the same network. In this case, we’re using the default network run the the QuadNet team (rr.openquad.net).

You’ll have to pick a name for your group. The ideal Starnet group name is not a valid call sign and is 6 characters long. This leaves room for a space and a subscribe/unsubscribe character. So it looks like this:

MYGRUP   -- Group name

MYGRUP A -- Subscribe to MYGRUP

MYGRUP T -- Unsubscribe to MYGRUP

In the ircDDBGateway config, you’ll need to change the following:

starNetBand1       A
starNetCallsign1   MYGRUP A
starNetLogoff1     MYGRUP T
starNetInfo1       What my group is about

You’ll see some other Starnet options but it is ok to keep the defaults for now. Once you know what you’re doing you can tinker further. You can even setup multiple groups. There is also an option to link your Starnet group to a reflector, but please do not do so without the permission of the reflector operator. But if you want to test this, you can try XRF020E, which I have reserved for experimentation.

Note: The address of XRF020 is not yet current in the Pi-Star file listings, so until it is updated you’ll have to manually edit /root/DExtra_Hosts.txt with the following:

XRF020        xrf020.k2dls.net L

Once you see your group listed in the QuadNet directory under Legacy STARNet groups, you can set your D-Star destination call (URCALL) to MYGRUP and chat away. Just remember that MYGRUP is an example only, and you’ll need to pick your own unique name that is not already in use.

You’ll also likely have to forward port 40000 (the ircDDB port) on your router to the internal address of your Pi-Star installation.

It may not be like having your own private repeater, but for many D-Star hams, it is the next best thing.