IPv6 for Amateur radio

This text is a slight modification of a long email I posted on the 44net mailing list on October 1 2016 and a translation of a longer email I posted on the Hamnet.es mailing list on September 26 2016. These messages didn't spring a huge response from the community, so no real work in developing an IPv6 network for Amateur radio has been made since then. Still, I believe that the time for IPv6 is yet to come, so I am keeping my proposal here.


My idea for IPv6 in Amateur radio is to use some way of encoding the callsign in the IPv6 address. I am using this proposal in my systems, as it is the most complete and probably best designed that I have found. Certainly, there are several other proposals that could be used, and the system should allow for coexistence of different proposals for mapping callsigns into IPv6 addresses.

The good thing about IPv6 is that due to the large address space it's possible to make it mandatory to encode the callsign in the last 64 bits of the address. This eliminates the problem that we have in IPv4 of trying to trace back which callsign is behind an IP.

My main idea is to make some sort of whitelist of globally routable subnets that are using some way of encoding the callsign into the IPv6 (I would like to allow for the admin of a net to choose the encoding he wants to use). This whitelist can then be used in a firewall for several things: allowing access to some services to Amateurs only or deciding if a packet is fit to be routed by an RF link (for instance, one could require that the source and destination have both their callsigns encoded in their IPv6's).

I am already using these ideas in some of my systems, and these can be tested online by anyone having IPv6 access. I'm using the subnet 2001:470:6915:8000::/49 for these tests. If someone has IPv6 connectivity and wants to try, there's a mumble server and a DX cluster (telnet port 7300) at ea4gpz.destevez.net (its IPv6 has the callsign EA4GPZ-Z encoded according to the proposal mentioned above).

The long term goal would be to have something similar to the 44net but where each user is using subnets allocated directly from their ISP instead of having a large contiguous block for amateurs (like the Connectivity between different amateur subnets would run over the IPv6 internet instead of using a mesh VPN (as the IPIP mesh of 44net). The whitelist could be used to decide which IPv6's are Amateur and get "special treatment".


Here I explain the main design decisions behind this proposal and the goals I would like to achieve. A comparison is done with the present state of 44net to try to improve upon the main problems that I see in 44net.

Main differences with 44net
  1. The network is no longer a contiguous IP block devoted to Amateur radio. Instead, it will be formed by a large amount of globally routable IPv6 blocks obtained by Amateurs in diverse ways.Every Amateur is typically able to obtain an IPv6 block (such as a /48 or /56) directly from him ISP if his ISP gives him native IPv6 connectivity. This block is already large enough to include the station of the Amateur as well as any other Amateur station directly connected to his by RF and which access the Internet through his station. Alternatively, it is also possible to obtain a block from an IPv6 tunnel broker such as tunnelbroker.net.An Amateur can also borrow a smaller block from the block of another nearby Amateur, making a VPN tunnel between the networks of these two Amateurs using the IPv4 Internet.

    Large National Societies or other Amateur societies may be able to request a larger block directly from their corresponding RIR, announce this block by BGP in the Internet and use it to give access by RF or other means to the Amateurs which are interested. In this way, the Society would behave as an ISP in all respects.

  2. All IPs will encode in their last 64bits the callsign of the Amateur responsible for such station or device. This eliminates all possible ambiguities and difficulties when trying to determine which Amateur is behind a certain IP address.There are several possible methods to encode callsigns into IPv6 addresses: 1 (recommended), 2, 3, and maybe others.

  3. The network is formed by just a whitelist of which blocks belong to the IPv6 Amateur radio network, and which method to encode callsigns into IPv6 addresses each block is using. By administrative reasons, extra information is added to each block, such as the name of the network, a contact address and so on.

  4. The different blocks are interconnected through the IPv6 Internet in a native manner, without the need for VPNs or tunnels. The blocks used should be routable by the corresponding ISP.

  5. The only global coordination required is the maintenance of the whitelist. This eliminates the need to maintain a portal with the allocations and gateways for the IPIP, as it is done in 44net. It also eliminates the need to manage the domain ampr.org. Each Amateur should manage DNS as he sees convenient, obtaining delegations for the reverse DNS from his ISP in the appropriate manner.

  6. Only the packets whose source and destination belong to the whitelist are acceptable for routing through RF links, since in most countries Amateurs cannot forward third party traffic. In the cases in which third party traffic is allowed, this restriction can be removed.This does not impede using the IPs in the network to offer services to the Internet, both to the general public and to identified Amateurs using some login method, provided that these IPs are accessible directly from the Internet, without the need of routing through RF links.

  7. The whitelist can also be used to restrict the access easily to certain services, allowing the access only to Amateurs.

A brief list of interesting research ideas
  • Mobile IP
  • Using Differentiated Services to decide if the traffic should be routed by RF or through the Internet (whenever both alternatives are possible
  • Using NAT64, CLAT or SIIT to allow access to 44net.
  • Using WHOIS to store the contact data for each block
    Very brief summary (again)

    The only thing that this proposal is about is to use a method or methods for encoding callsigns into IPv6 addresses and maintaining a whitelist of globally routable blocks following the proposal.

    A criticism of the 44net

    For me, the idea of 44net has failed in several important aspects. First of all, it takes up a whole /8. This is a huge part of the global IPv4. Most of this /8 is poorly administered and wasted. Small island countries such as Curaçao get a huge /22, developing countries have blocks without any IP allocated at all, in developed countries people quarrel frequently about the IP allocations, and the ever increasing no country blocks takes all sorts of projects which do in fact come from some particular country. Also, the fact that the US takes up a /9 (i.e., half of the address space), leaving the remaining /9 for the rest of the world, can be a bit insulting.

    The ampr.org portal is an outdated closed source software which lacks functionality. People have suggested that the code be released in order to contribute functionality and bug fixes, but this has never been done. There are frequent posts in the mailing list complaining about inactivity of national or regional 44net coordinators. To me, all this means that we Amateurs have tried to administer our own contiguous block of IP addresses and have failed miserably in doing so. My proposal simplifies administrative matters by allowing (and encouraging) every Amateur to obtain his own block from his ISP. Each Amateur has full control over the administration of his own block.

    Regarding technical matters, the 44net with its IPIP mesh has become some sort of huge VPN for Amateur radio. This is caused because it is quite difficult to get your ISP to allow you to route your 44net addresses through them, as source address filtering is always implemented these days. The alternative is announcing your 44net block by BGP directly on the Internet, but this is quite complicated and not possible with many ISPs. Also, there is a huge compatibility problem now between stations on the IPIP mesh and stations directly connected by BGP on the Internet. The first kind of stations should reach the seconds through the Internet, using their (probably NAT-ed) non-44net address. This kind of defeats the purpose of a global 44net and it is non-trivial to implement in routing. My proposal solves this problem by requiring that any block you use is a globally routable block that you can indeed route to the Internet through your ISP.

    There is also a problem where 44net addresses are currently used for two very different things. First, some blocks directly connected by BGP are using the IPs to offer services to the Internet. Second, they are used as some kind of Amateur radio VPN which has some guarantee that the contents are fit for routing though an RF link. In reality, this guarantee is very weak, and 44net does not really solve any of the problems regarding third party traffic. Ideally, an IP space for Amateurs can be used for the two things, but one must regard them as very different and separate well. There are services offered on the Internet and which are routed to the internet without having to cross any RF link, and there is traffic between identified Amateurs, which is fit for routing though an RF link. My proposal caters for these two uses by allowing RF links to drop any packets whose source or destination is not in the whitelist, thus guaranteeing that every packet that crosses the RF link is between identified Amateurs. On the other hand, firewalls can be set up so that certain services are accessible from any globally routable IPv6 address.

    Details of the tests in my station

    I am using the block 2001:470:6915:8000::/49, which I obtain from my IPv6 ISP, Hurrican Electric, though a tunnel with tunnelbroker.net.

    I am using the method BASE40 described in this proposal to encode callsigns in my IPs.

    I have the following devices and callsigns:

    • Router: EA4GPZ-X (actual router.ea4gpz.es.ampr.org)
    • Server: EA4GPZ-Z (actual router.ea4gpz.es.ampr.org)
    • User access, 2.4GHz: EA4GPZ-S (actual user-2ghz.ea4gpz.es.ampr.org)
    • User access, 5GHz: EA4GPZ-C (actual user-5ghz.ea4gpz.es.ampr.org)

    Note: EA4GPZ-S and EA4GPZ-C are currently offline, but the IPs are assigned in the DNS.

    I have chosen these callsigns because -X and -Z seem suggesting for a router and server, and -S and -C refer to S band (2.4GHz) and C band (5GHz).

    I have assigned these callsigns the following EUI-48 using the method in the proposal:

    • EA4GPZ-X 42:1F:87:2E:5A:F1
    • EA4GPZ-Z 92:1F:87:2E:5A:F1
    • EA4GPZ-S 7A:1F:87:2E:5A:F0
    • EA4GPZ-C FA:1F:87:2E:5A:ED

    These EUI-48 can be used directly as Ethernet MAC addresses. This is what I have done.

    I am using the networks 2001:470:6915:8000::/64 as a Service-Network and 2001:470:6915:8001::/64 as a User-Network (following the Hamnet terminology). This means that servers run in the Service-Network and users that connect by the RF access point get IPs from the User-Network.

    I have assigned the router the IPs

    • 2001:470:6915:8000:421f:87ff:fe2e:5af1
    • 2001:470:6915:8001:421f:87ff:fe2e:5af1

    In this way, the following IP addresses are generated automatically using SLAAC:

    • EA4GPZ-Z 2001:470:6915:8000:901f:87ff:fe2e:5af1
    • EA4GPZ-S 2001:470:6915:8001:781f:87ff:fe2e:5af0
    • EA4GPZ-C 2001:470:6915:8001:f81f:87ff:fe2e:5aed

    The devices which connect through the RF access and have their MAC address properly set up with their callsign using a BASE40 derived EUI-48 also obtain automatically using SLAAC an IPv6 address which encodes their callsign.

    These IPs are published in DNS and reverse DNS using the names

    • EA4GPZ-X router.ea4gpz.destevez.net
    • EA4GPZ-Z ea4gpz.destevez.net
    • EA4GPZ-S user-2ghz.ea4gpz.destevez.net
    • EA4GPZ-C user-5ghz.ea4gpz.destevez.net

    Ping from the internet is allowed to all these IPs.Access from the Internet to the following services running in ea4gpz.destevez.net is also allowed:

    • ssh
    • mumble
    • dxspider (port 7300)

    I am also doing some tests with mobile IP using UMIP. TODO: describe these tests.


    What happens with the whitelist

    When writing the posts in the mailing lists I was thinking of maintaining the whitelist as a plaintext file in Github, together with some scripts to create ip6tables tables with the list and update the tables periodically. None of this has happened so far, since I am still waiting for other IPv6 blocks to join the proposal, but this should be easy and quick to implement.

    How should we call this thing?

    When writing the posts, I had not thought about it much. Maybe HAMNETv6 or HAMNET6. When moving this content to my webpage I have not thought about it much either, but I am now calling it "IPv6 for Amateur radio", partially to promote Google searches including IPv6 and Amateur radio.

    What else?

    To simplify the job it is necessary to program some utilities to translate IPs assigned using BASE40 to callsigns and conversely. I have not done this yet. There is already some code but I have not tested it.

    Would you like to join the IPv6 Amateur radio network?

    If you have read so far and want to start doing some tests with me, congratulations. You must follow certain steps. I explain them below depending on your case. Also, please write me an email so I can be aware of the interest in this proposal.

    1. You already have access to the IPv6 Internet and a globally routable block which is larger than a /64 that you can administer. Then you can use part of your block for your Amateur radio equipment. Probably the best idea is to use a /64 as a Service-Network and another /64 as User-Network if you want to give user access by RF. Remember to allocate a block larger than these two /64s, as you may need to give blocks to stations connected to you by RF in the future. An idea is to allocate half of the block that you have obtained from your ISP for personal/domestic use and the other half for Radio amateur use (this is what I have done).

      You have to chose a method to encode your callsign in the IPv6 addresses. I recommend the method BASE40, which is the one I am using. It is very important that all the global IPv6 addresses you use have a valid callsign associated using this method. It is also recommendable to do so for link-local addresses, but it is not necessary.

    2. You do not have access to the IPv6 but you have a static IPv4 address. Then you can obtain a /48 by at least two methods:

      • Use 6to4. This only requires some setup on your router. It also requires access to a 6to4 relay (the anycasted IPv4 address For some reason, som ISPs do not give access to a relay (Movistar, in my case, for instance). The performance depends on the 6to4 relay you access (you do not have any control about which, it depends on your ISP's routing). The /48 block you obtain depends only on your static IPv4 address.
      • Use a tunnel broker such as tunnelbroker.net. This requires you to register in the broker's webpage and set up the tunnel, as well as doing the configuration in your router. The performance depends on the other end of the tunnel (tunnelbroker.net has endpoints in the UK and France, but not in Spain). The /48 block you get is assigned by the tunnel broker from his own network.

      Depending on your ISP, these methods will give you better or worst performance regarding latency and bandwidth. It is possible to try both methods and test which gives you better performance.

    3. You have a dynamic IPv4 address. tunnelbroker.net offers a service to update the tunnel's IPv4 address. This service is compatible with dyndns' update protocol. Go read the information about tunnel brokers above.

    4. Your provider filters packets of certain kinds and 6in4 tunnels do not work. It is possible that there is a tunnel broker which offers tunnels of another type. If you know one, please contact me and I'll add it.

    5. Under very special circumstances I might offer a /60 taken from my own block and a 6in4 tunnel (which works quite similarly to the IPIP tunnels which are used in Hamnet). In general, it is much better to use the native IPv6 connectivity from your ISP or a tunnel broker if your ISP does not offer IPv6 connectivity.