44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

> First thought would be that BGP is too difficult for 90% of the HAM operators. Setting up BGP on a MikroTik is much much much easier than getting IPIP mesh to run on anything! Rob

3 3

AMPRNet Address Sale
by ARDC Board of Directors 21 Jul '19

21 Jul '19

Amateur Radio Digital Communications [ARDC] is a United States charitable 501(c)(3) nonprofit public benefit corporation that has long owned and managed the Internet address space known as the AMPRNet. Nearly 40 years ago, early in the evolution of the Internet, this address allocation was acquired to be used for the mutual benefit of Amateur Radio and digital communications technology. Amateur Radio operators ("hams") use the global radio spectrum set aside for them by international treaty in non-commercial ways to improve engineering, research, experimentation, training, education, and emergency communications. Having the AMPRNet available over the past four decades has facilitated integration of the Internet with radio-based technologies long used by hams. This long term interaction has been key to development of now ubiquitous wireless technology such as WiFi and the ability to browse the Internet or to stream various media to your mobile phone. Over those past decades, a portion of the AMPRNet IPv4 address space has rarely been used, and recent utilization surveys show that it is not likely to ever be needed by hams. Initially free, IPv4 Internet addresses are now highly valuable, and there is an international marketplace in which to sell them. ARDC has sold some of its unused and unneeded address space, but retains a more than ample supply of IPv4 addresses for current and future use by the many Amateur Radio operators worldwide. The sale amounts to some millions of dollars, which will be used in the furtherance of ARDC's continuing public benefit purpose. Before the sale, the AMPRNet consisted of the addresses 44.0.0.0 through 44.255.255.255 (in Internet notation, 44.0.0.0/8). Post-sale, it consists of addresses 44.0.0.0 through 44.191.255.255 (44.0.0.0/9 plus 44.128.0.0/10). The uppermost 1/4 of the former AMPRNet address space (44.192.0.0/10) has been withdrawn from ham radio use and sold to another owner, however over 12 million IPv4 addresses remain for amateur radio use. ARDC will use the proceeds of this address sale to further its mission to support, promote, and enhance Amateur Radio, digital communications, and broader communication science and technology by funding grants and scholarships for scientific research, experimentation, education, open access, and innovation in information and communications technology, with an emphasis on benefiting the international Amateur Radio service. For further information, please see <https://www.ampr.org/amprnet/>. Best wishes and 73, The ARDC Board of Directors

19 30

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

> The IPIP mesh may be non-standard, but it is distributed, without any single point of failure. To get between two points, the two gateways have to have IP connectivity to each other. That's it. The two end-points can troubleshoot directly. > But every proposal I've seen on this list involves adding at least two other ham points of failure. For example, I would presumably connect to some other ham's BGP node and the other end of the connection would do the same. Why? Mainly because it makes it an "outgoing" connection for most people. That means it is not affected by NAT, CGNAT, dynamic addresses, inflexible router firewalls, etc. Getting IPIP to work bidirectionally often requires to setup the internal system as "DMZ" (which in home router speak means that it will receive all incoming traffic not matched by the NAT engine). This can only be done for a single system, and even then it often does not work correctly (e.g. it receives only TCP/UDP and not other protocols). You should not under-estimate the difficulty that IPIP is causing for more and more people. As an example, I am currently trying to migrate my physical colocation server to a VM. The service offered by the hosting company uses Apache Cloudstack. While the VM itself works fine and can load the ipip module, it turns out that Cloudstack cannot allow IPIP ingress in its firewall settings. So I will have to look for another hosting option... By putting VPN servers in datacenters and having the users connect to them, you avoid those problems. Also, using the topology I propose, there is no requirement that the entire network runs a single tunneling protocol or a single topology. Only the peers need to support the same protocol. And it can be a symmetric protocol like IPIP or GRE when you like that better. Also, there is no requirement that there only be a single connection! You can setup crosslinks to wherever you like. There will rarely be traffic to all IPIP mesh peers. There are more than 500 gateways in the list, and when I look in our stats I see we have had traffic to only 23 of them in the past day. Most active gateways can probably point out at most 5 peers to which they have regular traffic. You can setup crosslinks to those. And this system is not dependent on a central RIP sender! Every node is active in distributing its own subnets and receiving the others. There is no need for a portal that registers the subnets, they only need to be configured in the gateway routers. A portal could still be useful as a management system for VPN accounts. Especially at the major hubs, the users need to have a VPN account that assigns them a point-to-point address, and the BGP on that router needs to be configured with the AS number on that address. This could be done using some form of portal and a program that configures the router using its API. That is not mandatory. On our gateway the addition of new users still is done manually. I once have added a large number of skeleton BGP peers and VPN accounts, and when a new user requests a connection I find an available one, enter the username (callsign), a random password, and enable it. In the BGP peer I enter the AS number and enbale it. Done. There always will be some dependencies, but they do not need to be single-point and with some money available they do not need to be only relying on volunteers and unclear situations where some company hosts a service only because a worker there has arranged it. I think it has big advantages over the system we have now. Rob

2 1

Re: [44net] Time to restructure the network?
by Rob Janssen 20 Jul '19

20 Jul '19

Well, I think there are enough examples of how to do it (also already doing it within AMPRnet), lots of people who can contribute knowledge and will volunteer to help, the only thing we lack here in this group is someone (with the appropriate authority) who says "Lets' do that!" and gets everyone moving. That is why these discussions usually go on for a couple of days here, then die out, and nothing ever changes. We are still running the same system as 25 years ago, with only the addition of RIP auto route distribution. This gets worse over time, as those who would like to change things see this and leave, and in the end we only have a number of old hats left who don't change anything. That does not improve our reputation... sometimes newcomers ask "why do we use that method when it is so difficult to implement and it can all be done so much easier", and the only response can be "don't ask...". Rob

4 3

ipset matching
by Rob Janssen 20 Jul '19

20 Jul '19

Because of the current changes, people want to change firewall entries that check an address to be "within AMPRnet". This of course used to be simple, like "-s 44.0.0.0/8" as a matcher in Linux iptables. I already read remarks like "well I just need to split those rules in two, one for 44.0.0.0/9 and another for 44.128.0.0/10". This is not really required. And it is not so easy when the match was in a "not" context, like: ! -s 44.0.0.0/8. Also it makes the firewall rule list longer and maybe less intuitive. Maybe not everyone knows how ipset can be used to match more than one address in the same rule. The ipset program creates "address sets" that can be lists of addresses, networks, portnumbers etc that can then be referenced in a match. For example, create an address set that contains the new AMPRnet ranges: ipset create AMPRnet hash:net ipset add AMPRnet 44.0.0.0/8 ipset add AMPRnet 44.128.0.0/10 ipset add AMPRnet 44.224.0.0/15 (the last one of course has to go, but I kept it there to give our German friends some time to renumber) Now instead of "-s 44.0.0.0/8" you can use: -m set --match-set AMPRnet src Instead of "-d 44.0.0.0/8" it would be: -m set --match-set AMPRnet dst And instead of "! -s 44.0.0.0/8" you still can use the form: -m set ! --match-set AMPRnet (src or dst), so there is no need to change the structure of the rules to work around the problem of not having a "not" operator. Of course you need to arrange for the above commands to be run before the iptables rules are loaded. No problem for me as I have always done that in an own shellscript not using distributor's solutions that use iptables-save or similar. (I prefer to have the possibility to have comments, use variables holding certain addresses and networks, etc) In MikroTik RouterOS the same feature is available as "Address list" in the firewall. You can create an address list and load those subnet values: /ip firewall address-list add address=44.0.0.0/9 list=amprnet add address=44.128.0.0/10 list=amprnet and then use that in filter rules by using Src.Address List instead of Src.Address for the match. Rob

1 0

CIDR Syntax Reminder! 44.192/10 != 44.192.0.0/10
by Jeremy Cooper 19 Jul '19

19 Jul '19

Hey everyone, if you are like me and you’re working to update your firewall rules to carve out the recent subnetwork sale, I’d like to remind you that the proper way to refer to the portion of the network that has been sold is this: 44.192.0.0/10 The converse, “44.192/10” actually expands to "44.0.0.192/10” in some software, and this is probably not what you want! -Jeremy

1 0

Re: [44net] AMPRNet Address Sale
by Rob Janssen 19 Jul '19

19 Jul '19

> But hey, if you'd really like to go back to only one ACL entry, we could > also sell 44.128/10. Then you'd only need 44/9. <-- (note smiley) Actually there would be plenty of space with just the /9 when it had not been all allocated to the US in the beginning. OTOH, had that been the case, we probably had been tempted (or forced) to sell it off (or just release it) much earlier. Rob

2 1

Re: [44net] AMPRNet Address Sale
by Phil Karn 19 Jul '19

19 Jul '19

Let me propose you an idea although it's an off-topic in this list. We have a serious problem in amateur radio regarding digital development. It is software quality, platform independence and openness. I fully agree. If I have any say in this, *all* hardware and software development funded by our grants must be open sourced and made freely available. If you want to keep it proprietary, don't do it with our money. Some of you may have heard of FCC RM-11831, which would effectively ban any air interface on the ham bands that isn't publicly documented. I filed comments stating that while I am personally sympathetic to the principle that all amateur air interfaces should be open, trying to enforce that now with a legal rule would have serious unintended consequences. All three VHF/UHF digital voice modes (D*Star, DMR and Fusion) would be banned because they all use unpublished voice codecs proprietary to Digital Voice Systems Inc. I argue that a much better way to deal with proprietary air interfaces on the ham bands is to beat them at their own game: develop superior open source alternatives and persuade hams to adopt them. This has already been done for low-bit-rate voice coding: VK5DGR has developed the excellent Codec2 and made it freely available. So here is our chance to seriously pursue development of advanced, 21st century digital communication systems that, from the beginning, will be free and open. 73, Phil

2 1

Re: [44net] amprhosts update
by Rob Janssen 19 Jul '19

19 Jul '19

> Seems that mails to ampraddr at ucsd.edu <https://mailman.ampr.org/mailman/listinfo/44net> requesting IN A is not answering. > Or something changed ? Please help Long ago it has been changed to ampraddr(a)gw.ampr.org Rob

2 1

Re: [44net] A few thoughts on recent developments
by Rob Janssen 19 Jul '19

19 Jul '19

> i) Of note: Brian did ask for donations to offset these expenses which > were largely ignored. At that time I actually attempted to make a donation but it got stranded in the payment process. (I did not want to open an account at a US banking company for it, and I did not understand the peculiarities of their banking system. Here, you would simply ask the receiver for their bank account number and transfer the money to it, but there the account number apparently is something you need to keep secret so Brian would not give it to me. Not something particular to ARDC, with AMSAT it went the same way...) Rob

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net