On 7/28/21 12:24 PM, Antonios Chariton (daknob) via 44Net wrote:
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.
I think you are proposing a solution in search for a problem, and you inserted different "problems" in your proposal that seem fabricated at best. We need to look at the matter based on FACTS and not by setting up an entire problem sketch with fabricated reasons and evidence.
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.
About 8 months ago we had a discussion about a new backbone that would replace the IPIP mesh and that would exactly cover this. We had a lot of input, but the discussion was taken offline and the TAC would come with a proposal on how this would be designed and implemented. After that, we have heard nothing for 8 months and now we get a paper that proposes to change the network layout, rather than implement the new backbone that would make that change unnecessary. What happened to the backbone proposal? When will it be published, and when will the implementation start? Would it not be better to not make unnecessary changes to the network pending that?
The new backbone would solve those issues by offering plain VPNs, that can be installed on many routers and other equipment out-of-the-box, and where a user could route the entire 44.0.0.0/9 and 44.128.0.0/10 minus their local network. No need for complicated routes. There is always some minimal equipment or minimal effort. When you want to transmit on 20M, you cannot do that using your ISP router (some of them do...) but you need to build or buy a transceiver. When you want to be on AMPRnet, you may need to install some VPN software, or you may need to get a Raspberry Pi or a MikroTik router or similar. I do not see that as prohibitive and we should not try to make a network that covers that, because users will find another reason why they do not want to join.
The fact that you hear that from the users is not very relevant. Back in the early days of packet radio there already were users that "would not invest in a Digicom modem". Not every aspect of ham radio is for everyone. That people respond "I do not want to purchase any equipment" in a questionnaire about "what would you want to do to join HAMNET" should not be taken as an indication that everything should be done without extra equipment! And even less so that the existing population should make whatever effort necessary to accomodate that type of new user.
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 barrier will be lowered with the new backbone network.
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.
1. you cannot research the network by scanning it from the outside. I, as an IP coordinator, have never seen any request for information about the usage of our network. Sure when you scan it from the outside you see only like 20 hosts. But that is because of trapdoor firewalling, not because there are so few. We just guard against port scanners and blacklist them.
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.
You should not look only at the number of hosts, but also the number of subnets. Effort to renumber is likely also depending on routed subnets. We do not have a flat address space where we can move hosts one by one.
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.
IMHO there should be no intranet AT ALL within network 44.
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.
That starting point is totally broken. You need to go back to square one and find a different solution to your problem. (which I have never seen in our network because we offer a default route to those users)
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.
There you go. Not a solution. Move away from the presumption that you need a static route in an ISP router, it is just invalid.
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.
You can setup a management system for 10.x.x.x space to guarantee that no two amateur radio intranets will use the same space. With a little research you can cut out the typical blocks used by existing ISP routers and not allocate those to anyone. Maybe really sometimes you will have an issue and someone has to renumber a small space, but I do not think it is a good idea to force large networks to renumber just to cover this imaginary problem.
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”.
Stop there! No intranet please. people can decide to not route their space, but you should not enforce people to make their network an intranet just because someone else cannot manage their local network.
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.
I prefer not to enter into NAT solutions in a network that was clean of NAT solutions until now. Let's go back to constructing the backbone that makes the routing decisions, allows users who do not get involved with that to stay away from those (and still allows users who want advanced solutions to interface with the routing), and lets not hardwire policy into the address space. That has never been a good idea.
Rob