Hello Rob, thanks for your e-mail! Please find my replies inline.
On 28 Jul 2021, at 11:33, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:
On 7/28/21 12:31 AM, Antonios Chariton (daknob) via 44Net wrote:
Fellow radio amateurs, I am writing to you on behalf of the ARDC TAC, which I represent.
Those of you that were on our Community Call last Saturday may remember that I promised you we would share our first proposal with the community. A few days after that, I am happy to send that to you for your review, feedback, comments, questions, and information!
You can find our 5-page PDF here:
Well, I see a couple of issues with that, which I will detail here:
Even with higher-speed radios, amateur radio-based networks typically will have limited bandwidth and higher latency than the public Internet. For instance, HAMNET is an active network deployed as a mix of a static, dynamic, and mesh routed network. There can be many hops over radio nodes to get to the destination. Each node will add latency and most links will have less than 100Mb/s of bandwidth. Considering these conditions, these networks should not be used for high bandwidth applications such as consumer video streaming (eg. Netflix, Hulu).
I think this is an issue that has to be managed locally, not by ARDC. Each local region has to decide how much bandwidth they make available in links, and what usage they determine to be appropriate. This has to be communicated to the local users. An amateur viewing Netflix via AMPRnet is likely not something we would want to see, but I don't think that making the AMPRnet an island is the way to achieve that.
You are correct that this is something that should be managed locally and not by ARDC. It was brought up as an example and the TAC has no intention of setting a policy at this level. This can be seen from our resolution that does not mention anything related. I apologize for the confusion.
Routing to amateur radio-based networks needs to be easy to implement and can be supported by low-cost routers
Users and operators of amateur radio-based networks typically will have routers that are connected to both the radio-based network and the Internet and will want to pass traffic to the respective networks. This creates a challenge for these users: how to tell the routers which network connection should be used, based on the packet destination. If dynamic routing protocols such as BGP were used, this would lock out almost all operators as consumer-grade routers do not support these protocols. Dynamic routing protocols also require much more memory and CPU power than these routers support.
Well, I think that is an issue that we were going to handle with the new backbone network! Simple end-users would connect to a PoP and send all the AMPRnet traffic they cannot route locally (i.e. to their LAN or to a radio link) towards the PoP and have all the dynamic routing done in the new backbone network. That includes routing towards other regions on AMPRnet, and optionally also routing towards internet. The backbone network would be internet-connected in several places and find the optimal place to route that traffic towards internet, there is no need for the end-user to bother with that. They only need to make sure they route only their AMPRnet traffic there, and not all their normal household internet traffic. But that is something that a consumer-grade router cannot do anyway, so they would often need a more suitable router "behind" the ISP provided router when they would want to route AMPRnet traffic to internet. Those users that see AMPRnet as an island can just route 44.0.0.0/9 and 44.128.0.0/10 to the PoP and the rest to their ISP, and the typical ISP router can do that. When you really want to do all AMPRnet routing on an ISP router, you only need to make sure that your PoP can handle a VPN type that the typical ISP router can setup.
Also I do not understand why this is now brought up as an issue, at the moment where we have many different types of routers available in the 50euro/$60 price range that can do the policy routing and BGP routing. I would not want to advocate making network policy decisions based on "it should be usable with static routing" at THIS moment. Maybe 20 years ago, but not now. We need to look at the current and future situation and it looks bright w.r.t. dynamic routing.
We currently have a large number of users that have reached out that have an ISP-provided router that they do not want to change, regardless of cost, as it’s simple and it just works. These users have a radio on their roof that connects to an Intranet like HAMNET. They want a single prefix they can point as a static route to this radio, and the remaining of it to be caught by the default route they have to their commercial ISP. The equipment their ISPs typically give them does not support any kind of VPN or tunnel. Moreover, if they install e.g. a Raspberry Pi to do the VPN, then they still have the issue of “what prefix do I need for the static route”. The 44 address space that is "Direct BGP" made the conscious decision of being available on the Internet, which means that these users should reach them via their commercial ISPs. Some other operators want to only be reached over the Intranet. This proposal gives a way for all these users to finally connect to the Intranet that they want to join without forcing them to massively complicate their network with more equipment, VPNs, dynamic routing protocols, etc.
We therefore believe that it massively decreases the barrier to enter in both cost, knowledge, complexity, and time. For the current TAC, lowering the barrier to entry is something we need to address now, and not in 20 years. We do not like to exclude people and tell them to come back in 20 years because they’re not as knowledgeable or willing to spend the time, money, and effort right now. Instead, we try to serve them today, and help them join the 44 Net.
The TAC analyzed the current allocations within 44.0/9 (USA) and 44.128/10 (RoW). Based on the existing use-cases within both ranges and the necessary effort to renumber, the TAC proposes to use 44.128/10 as the prefix for the radio-based network.
Please show us that analysis, because I arrive at a different conclusion. I regularly download the advertised ranges from http://thyme.rand.apnic.net/current/data-add-ARIN and save the AMPRnet portion of that, and at the moment it appears that 182 subnets are advertised from 44.0.0.0/9 and 152 subnets are advertised from 44.128.0.0/10. Considering that the first network is twice the size, the number is comparable or is less for the first than the second.
However, when looking at the number of advertised IP addresses rather than the number of networks, the outcome is: 190720 addresses are directly advertised from 44.0.0.0/9 and 587008 addresses are advertised from 44.128.0.0/10, that is three times as much. So, there is much more effort to renumber when moving those advertised networks in 44.128.0.0/10 towards 44.0.0.0/9 than when doing it the other way around.
It is true that there are more advertised IPv4 addresses in 44.128/10 on the Internet. However, according to the study that we did, and is linked in the original post, there is a *massive* discrepancy between advertised space on BGP and actual usage. We see large parts being advertised (entire /16’s) yet only 2-3 users with < 20 hosts within them. Although we looked at the allocation plan, we identified that it’s more helpful to either look at it in more depth (e.g. end-user allocations) or also rely on the ICMP checks we did, where possible.
These checks showed us that about 75% of the IPv4 addresses that respond to ping are available on a large Intranet and the vast majority of that is in 44.128/10. That said, if we did not use 44.128/10 for the Intranet part, we would cause around 75% of the global users (in terms of IPv4 addresses responding to ping) to renumber.
To sum up, I agree that 44.128/10 has more advertisements on the Internet, but in our detailed look, the vast majority of hosts within it are Intranet-exclusive. Therefore, we decided that this should be the Intranet prefix.
Furthermore, the use of the 44.190.0.0/15 network is currently specificially for networks that are part of AMPRnet but are advertised as internet services. This was done as an earlier method to solve the "problem" that this proposal appears to try to solve, and when now doing it in the way of this new proposal that would all have to be reversed again.
This proposal aims to make it as simple as possible for the users to join the network. This can be achieved with a single static route in their ISP-provided equipment, for 44.128/10. The users don’t want to have to create multiple entries (some equipment limits to 8 static routes) or have to update them regularly every time we allocate something, and until everyone changes their static route to have network splits or reachability problems. If this passes, they can add a single static route (to a radio or a VPN server) and never have to worry about changes again.
Therefore we believe that this is a holistically better option than what 44.190/15 was.
Finally, I am not in favor of any changes that are geared towards making the AMPRnet space a "private, isolated" space. We have the 44.x allocations because they can be routed to internet, when people do not want that they can use a 10.x allocation and be perfectly isolated from the internet. There is no need to have publicly routable space for that (and then declare it to be not routed by policy).
Using any RFC1918 prefix for the Intranet has been considered by the TAC. Unfortunately, it comes with a set of problems that don’t occur in the currently proposed scheme: because everyone can use these networks, by definition, there *will* be collisions, and there will be no central coordination and guarantee of non-overlapping spaces. Nobody can prevent two “Intranets” from using the same address space, a lot of users already have a 10/8 network on their homes, that will most likely have overlaps with the Intranet, etc. By using 44.128/10 that is centrally managed and coordinated by ARDC, we guarantee that each user can enjoy a globally unique allocation that is guaranteed to not overlap with existing network infrastructure or with other networks they want to interconnect with.
The TAC sees no problem in using “publicly routable space” for the Intranet as it’s the only type of space that can currently guarantee this property of no overlaps and global uniqueness. Furthermore, ARDC has currently a very very large number of IPv4 addresses, and depending on how you count, the usage by end-users is less than 1-5%. I think that even if you count by /16’s on the Internet, the usage is still less than 5%, despite them being empty.
As you mention, a lot of TAC members did not like the idea as well as it was a waste, but since we could not find a better solution, we arrived at a tradeoff: we could either support many more users and make it much easier for someone to join at the cost of IPv4 space, or we could make it harder to join, require special equipment, etc. but conserve IPv4 space. This was an easy decision: we want a lot of users, we want to make it easy for them, we want them to enjoy being part of the network, and we have way more than enough IPv4 space that we need. And this is why we decided that this approach is better.
With the numbers provided above, we can give every current user an allocation in 44.0/10 and one in 44.128/10 and we would still have less than 10% usage of the overall address space, which means that we could still support over 8 times as many people and their networks. And this is a “worst case”: we take the highest usage percentage and we assume that all users want IPs in both spaces. With conversations we had with some users, we believe this is far from the truth. We have at least 2x/15 in Germany that only want to be on the Intranet part.
The proposal seems to consider two disjoint use cases, one is "the radio network" and the other is "the internet connected network". That is also reflected in the 44.190 allocation, and likely is behind many of the current /24 allocations where the user simply wants to play with servers on internet, hopefully for a use case related to amateur radio, and is not making a radio network at all. However, what we have here in the Netherlands is a combination of the two. It is a radio network, with additional internet tunnels to join areas without radio links between them (at least as an interim measure), but also it is internet routed and announced as a /16. We do not want to become an intranet! I think that use case has to remain, and has to be detailed more in the proposal.
We want to be able to accommodate for every use case with our proposal, so we don’t want to leave any user or community behind. Perhaps it’s better to think of the two spaces as “Internet” and “Intranet”. The first use allows communication of hosts to and from the entire Internet, 0/0. The second use case is a private network that only ham radio operators can access. This can be connected with radio links, satellites, VPNs over the Internet, etc. We do not want to force you to use a specific technology. We just want to make sure that we provide a network for both use cases.
Your users in The Netherlands may want to remain connected to HAMNET in Germany and the rest of Europe. They may also want to have Internet access with publicly routable addresses. Both these use cases are fine and perfectly acceptable.
If you determine that you need to be connected to both networks, and connection to the Intranet is not simply enough, you can request a matching allocation (I think /17?) in 44.0/10, and then set up a “netmap”. This is an iptables target (also available in RouterOS) that replaces the first bits of an IPv4 address. With this, you can leave all the IPs intact so you can communicate with Germany, and on the single point that you connect to the Internet you can advertise the new prefix, and perform “netmap” of the entire old /17 to the entire new /17. So the Internet will see you as 44.0/10 and the “radio network” / Intranet will see you as 44.128/10.
This is something that is supported by design and we hope it addresses your use case and provides you with the necessary flexibility to join the network without compromises.
Thanks, Antonis