44net July 2019

44net@mailman.ampr.org

86 participants
91 discussions

Re: [44net] IPv6 adoption (was: address sale)
by Rob Janssen 21 Jul '19

21 Jul '19

W.r.t. the issue of /64 or smaller addresses, my plan is as follows: - we have a /16 network within AMPRnet (44.137.0.0/16) - it is very easy to get a /48 network in IPv6 (every home customer at my ISP gets one of them, I have one as well. it would be easy to get a /48 assigned to our gateway where 44.137.0.0/16 is BGP routed now - I want to make a 1:1 mapping of every assigned address in our IPv4 subnet to a /16 network within that /48 space. E.g. when we get 1234:5678:abcd::/48 from our ISP, I would map 44.137.0.1 to 1234:5678:abcd:0001::/64, up to 44.137.255.255 mapped to 1234:5678:abcd:ffff::/64 - This means every single address allocated in IPv4 gets a /64 subnet in IPv6, any /28 in IPv4 (common subnet size for hams) gets a /60 subnet, etc. This way, standard practices for using IPv6 addresss can be used, and the proposal of Daniel EA4GPZ can be followed to encode the callsign and service in the lower 64 address bits as desired (for convenience only). We would "just" have to add IPv6 addresses to all routers in our network, but it can be done in an almost automated way because the IPv6 addresses and subnets can be calculated from the IPv4 addresses already configured using a simple tool. Of course it still requires quite some work, and causes double maintenance on things like firewalls and routing filters, so I have not done it yet. But it sure would be possible. Rob

6 7

Re: [44net] IPv6 adoption (was: address sale)
by Rob Janssen 21 Jul '19

21 Jul '19

> > - I want to make a 1:1 mapping of every assigned address in our IPv4 > > subnet to a /16 network within that /48 space. > > E.g. when we get 1234:5678:abcd::/48 from our ISP, I would map > > 44.137.0.1 to 1234:5678:abcd:0001::/64, up to 44.137.255.255 mapped > > to 1234:5678:abcd:ffff::/64 > I'm a bit lost at what you're suggesting, and the practical way it would > be implemented. At first glance, this looks like a recipe for > suboptimal routing to the outside world. The above is an idea how to add IPv6 addresses to the 44.137.0.0/16 network that is BGP connected in a datacenter and where users are connected via VPN and radio paths. The added IPv6 addresses would be from the datacenter space and would be routed along the same paths as the 44.137 traffic. Of course that is suboptimal, but it works for users that do not have IPv6 themselves. > I have 2 AMPRnet IPv4 allocations - one BGP connected, one IPIP > connected. Both sites have IPv6 available. Here, where the IPIP mesh > terminates has a /56. I currently have a /64 on the VPS, but as there's > only one host, it wouldn't be difficult to carve that into AMPRnet and > non AMPRnet parts, because IPs are assigned by hand and are all on the > same interface. In my opinion it is not a good idea to deploy a system based on splitting a /64 net in smaller subnets. You could do that locally, but you would not want to give other local users an IPv6 network that is smaller than a /64. This is going to cause all kinds of difficulties. That is why my intention is to give every user at least a /64. Rob

2 1

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

21 Jul '19

> > Setting up BGP on a MikroTik is much much much easier than getting > > IPIP mesh to run on anything! > I see an opportunity here to learn BGP. I'm for this idea. I posted an example configuration above. Of course this is not the same as "learn BGP", but I think many users of the current IPIP mesh also did not "learn IPIP" and "learn RIP" but only copied an example configuration and fiddled with it until it worked. Of course when you want to setup a regional VPN server you need some configuration for that as well, but when such a system would be deployed of course examples for that can be given as well. BGP for such a small closed network is not that complicated. Basically every system maintains a TCP connection (port 179) with all its peers, and it sends the networks that it can route. It receives the same information from the other side, and fills the route table. The active route is selected on a couple of criteria, where the least number of hops is usually preferred. It is possible to send tags along each route (called bgp-communities) that can be used to prefer certain routes over others, e.g. to prefer routes over radio when both a radio and a VPN path exist. There are some issues with BGP, e.g. the total lack of security in the protocol. Anyone can claim that they have a subnet and all the others will happily route all traffic for that subnet to them. The routing filters are an attempt to work around the most severe problems, but as can be seen on the internet (which also uses BGP) it is difficult to make it completely failsafe. Also, in our world it is a bit of a nuisance that there is no way to incorporate some form of dynamically determined link quality in the routing decision. Links are either up or down. But for this proposed use (replacement of the IPIP mesh) that is not a problem, it mainly affects the use of BGP on the radio links in our network. Rob

2 1

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 21 Jul '19

21 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 20 Jul '19

20 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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net July 2019