Hello Rob, thanks again for the long reply. Please find my thoughts below:
On 28 Jul 2021, at 13:11, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:
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.
In case it wasn’t clear, the TAC or ARDC never proposed anything that would force rules upon local networks and how they connect to each other, or what bandwidth and latency allocations and requirements they make on their links. This is not our goal, nor do we believe that it is our job to do so.
Furthermore, I would like to clarify that this proposal is that of the entire TAC, and I am responding to the e-mails on behalf of the TAC, as its designated Spokesperson. This is not simply the proposal and the opinion of a single person of this body.
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.
I am aware of the discussion but our current TAC was formed 5 months ago and there was no TAC prior to that. I will look into the archives again to better understand what was said. All the members of the current TAC have been following the mailing list in the past and we never make decisions or proposals in vacuum: we always take into account the past, as well as the opinions and comments of current users.
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?
This is a good question: as you can see, our proposed resolution to the Board of Directors includes a statement that requests the funding of this network. Currently it is not fully defined, but we plan to finish this after this resolution, as we need to ensure there is funding for it, and the address plan is defined, since the solution will depend on it. You should expect more news soon, especially if this resolution is approved as is.
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.
This is something that we took into consideration but we don’t want to create a network where the only option to participate is to connect to these ARDC-operated Points of Presence / VPNs. We want to give users more freedom to do what they like. Building a global VPN network is much easier if you force all users to connect directly to that and receive their prefix statically. But this does not address use cases of Internet-connected radio networks that want to have multiple Internet uplinks and a shared prefix. What I’m saying is that there’s more to it than meets the eye. We could easily ignore all these users and set up an OpenVPN instance or equivalent and be done with it.
Again, our goal is to help interconnect everyone. Not only the people that happen to have a use case that is supported. This requires more advanced planning, more complicated decisions, and it’s never clear which is the right option: it’s all a series of decisions with each carrying its own tradeoffs.
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.
Indeed, you need to have some minimal equipment or minimal effort for everything. I agree with that. What we try to do with this proposal and as a TAC is to push this “minimal” as much down as possible. For example, we identified that a lot of users do not want a statically assigned prefix, and they only get one because it’s required to connect.
For this reason, the proposed Global Connectivity Platform will provide access to end-user devices directly, in “Access Mode”: it’s like connecting to a simple VPN server and receiving an ephemeral IPv4 address that gives you access to the network, without having to set up anything. You won’t even need a special router or anything special to set up. It’s like EchoLink allows you to transmit without a VHF radio..
As you can tell, it’s not easy to accommodate for every user perfectly, but it is our belief that we can accommodate for many more users without costing the existing ones too much (or nothing at all). We try to avoid the selection bias: if we only ask existing users, they will tell us that everything is fine, or they will suggest more technically advanced solutions. We also have to ask the non-users that want to join, but for whatever reason, they can’t. Who knows, maybe they are much more than the existing ones, too.
If you look at the Survey results that were presented last Saturday, the top 3 things that we need to improve according to the people are inclusivity, removing gatekeeping, etc. I believe that our current proposal has the ability to achieve that, at least to the degree possible by setting network policy. I think it’s a nice step towards this direction. We have many more that we need to take, but this is a good first one.
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.
As I said earlier, the TAC believes that there are many users that will join if we make “minimal” even less than what it is now. On top of that, we want to be inclusive, and like a community, in order to help some members of it participate equally, the others will have to make a few sacrifices. Just like a society, some members are more privileged than others: some have more money, time, knowledge, experience, etc. We believe that this privilege should be used to help others participate equally, and not as a gatekeeping mechanism to isolate or prevent others from joining. If some users don’t want to join because they don’t know, teach them, don’t block them.
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.
Indeed, the new backbone network aims to decrease the barrier, but it will be heavily helped if we also get the proposed split of address space based on the use case.
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.
- 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.
Indeed, one can argue that the methodology used is not perfect. But we believe that it is “good enough”. We cannot take the time to talk to every single operator unfortunately and work around any weird firewall or route policy they may have. We scanned the network from the Internet, from IPIP Mesh, from HAMNET, and from the Internet using a 44 address. I think that this is reasonable enough to understand it. Sure, there may be a network that does not answer on odd-numbered ports or does trapdoor firewalling, or any crazy mechanism you can think of like only forwarding packets in even-numbered seconds.
If you are concerned about the Dutch network 44.137/16, then I can assure you that we scanned it, evaluated its size, and took it into account. I also have to say that the links you provided about the route collectors that you have internally certainly helped to get a better picture.
We are perfectly aware that our methodology was not 100% accurate, but we argue that it doesn’t have to be 100% accurate, it has to be good enough to a reasonable degree. And for the rest of the use cases, we have the mailing list to point out things that we missed. I personally believe that it’s unlikely we missed “5 full /16s” after all these scans and by trying different vantage points, but you never know..
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.
Indeed, this is the primary metric that we used. Typically the number of hosts makes sense in servers, and the number of subnets makes sense in access. We had to take both into account. Although we could not get visibility into any network, we looked at several large ones, and certainly at everything that exists in the HAMNET DB, where 80% of the users of the total space reside.
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.
We respect this opinion, and we tried to present our view on why we need one and how that would help. However, we understand that we cannot and should not force anyone to change their opinion. We can only present our way of thinking, some context, and answers to your questions, to the best of our ability.
This proposal is the product of the work of the TAC over the past 5 months and hundreds of hours of calls and discussions and documents.
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)
I understand that you may never had problems in your network, but for better or worse, not every network is set up and managed similarly to yours, nor do they want to do this. There is a very diverse set of setups out there, and we would like to see even more. The job of the TAC is to help every user build whatever they want, and not to force them all to do one thing that seems to be working somewhere else in the world, in a different environment.
Would you feel comfortable if we mandated the use of a specific network policy across 44 Net that was not yours? I don’t think anyone would like it. So instead of forcing a single use case and network policy, we simply aim to provide everything with the policy, guarantees, and technical infrastructure to do whatever they want, and be able to operate together with everyone else, no matter how they do it.
As I said earlier, it would be very easy for us to only provide a single VPN server and force everyone to connect there, with our terms. We would be done in a day, and with no renumbering. But that’s not our goal. We hope that you get to see that through these responses.
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.
We have a number of users that ask this question to us weekly, and some times daily. We cannot just ignore them. If you cannot see that, I am afraid that there’s not much we can do towards this point. As I have said many times today, we try to help as many people as possible, not only a few privileged (by any definition) or existing users.
We know that we can find A solution that would work for SOME users by forcing them all to do SOMETHING. This is not our goal. We choose not to do this and instead try to find a solution that would work for ALL users and they can do ANYTHING and they can still talk to each other.
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.
This is not an imaginary problem. We have networks that would need to renumber and some times can’t renumber (e.g. their ISP gives a 10/8 address to their PPPoE connection). Trying to maintain a global register of 10/8 networks and carve out all the blocks that are used by something and could cause problems is a much worse solution technically speaking. What if we allocate 10.137/16 to The Netherlands, and then we have users in Spain where their ISP gives them an IP from this part in their PPPoE session? Will we buy the ISP and force them to renumber, or will we have The Netherlands renumber to another block, until we find that e.g. Docker uses it and we have to renumber them again?
All these problems go away if the space that we use is globally unique, like 44.128/10. So by having a few users renumber once, we avoid having to constantly maintain a registry that by definition overlaps with so many use cases that exist now, or will exist in the future. We have enough address space and we can afford to do this, and the pros outweigh the cons.
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.
We value your opinion, but as I said earlier this is a conscious decision. We outline this in the proposal in detail, but if some networks advertise everything on BGP and some others don’t, and some networks are only on BGP and not on the Global Connectivity Platform, then things start to break and we have network splits and reachability problems.
To avoid this entire class of problems, and make sure that it can’t happen, no matter what the users choose to do, we split the address space so that you can reach every single host on 44.0/10 (and 44.64/10) over any consumer ISP connection, and you can reach 44.128/10 hosts through this network that you need to somehow get access to (either via VPN, the ARDC PoPs, Radio Networks, Pigeons, etc.).
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.
The backbone is coming and will certainly help, but we do not think it will be adequate to address all the problems, and most importantly, we will not force anyone to connect to that. Our vision is that anyone should connect to others however they like, and we even allow for the option to create your own Global PoP Backbone if you want to!
I hope this is helpful.
Antonis