Thank you for your comment! Please find my replies inline:
On 28 Jul 2021, at 12:36, PH5X via 44Net 44net@mailman.ampr.org wrote:
Seems like a waste of a /10 to never route and never announce it to the internet by policy, especially with the current scarcity of IPv4 addresses.
It may seem wasteful, but it’s really not a problem. I’ve went a bit into that in a previous e-mail, but so far the usage is < 5%, and probably we could fit everything in a handful of /16’s if we applied heavy compression and renumbered everyone. But for better or worse, we have 192 /16’s. We have plenty of space, and we as the TAC propose to use it for radio amateur purposes. We have plenty of space where “wasting” some of it (we don’t believe it’s a waste) to make it easier for so many users to join easier is something we believe is a good choice.
If in the future 44.0/10 fills up, and we allocate 44.64/10 gradually and it still fills up, we can worry about running out of space. But we predict that this will probably not happen in a time frame that would not give us enough time to prepare and find a solution. Until then, there’s no point having address space that we prefer to not use and keep it reserved instead of having it available to support new users and make it easier for them to join, no matter which (or both) use case they pick.
It should be up to the coordinator of assigned 44 net space to decide if they want to announce their network to the Internet or not. It should always be an option to start or stop announcing a block at any time for any reason, without having to renumber entire networks with possibly hundreds of users and thousands of machines. Firewalling and routing policies are also a tool that coordinators or operators can use to steer or block traffic.
This creates the problem of the users without “prosumer” or higher routers to join the network. They would have to daily look at what the coordinators chose to do today, and then update their static routes manually. And that’s only for the people that can have more than a few static routes added. By choosing to do what you propose we leave a number of these users out of the network, as they simply don’t have the means / resources (not just monetary) to join.
We do not want to exclude users. If anything, we want to do as much as possible to help them succeed in joining the network. We want them to be able to experiment, learn, use, at any level they feel comfortable, at any pace they feel comfortable, at any investment they feel comfortable. We want to massively decrease the barrier to enter.
If operators want to be flexible, they can get an allocation in both 44.0/10 and 44.128/10. Assuming the Board approves this, Chris will be more than happy to provide you with the complementary one. Then, using the “netmap” solution discussed earlier and appropriate firewall rules you can have both networks at the same time and be able to control which one is active: none, both, or only one of them.
However, something that I would like to personally point out here is that the typical structure of networks for 44 Net is that the coordinators are there to allocate the space. They are not there to provide connectivity or dictate what the users should do. Some networks have developed with this principle and this is fine, as long as all the users are happy and trust this person. But this is not the coordinator role. This is something different, by Portal definition.
We want to allow anyone to connect, however they like, and have the use case they like. Users who cannot set up something themselves will have to trust such a “provider” (for lack of a better term) to connect them, like HAMNET, etc. but we don’t want to limit them to only have this option. In the future we plan for ARDC to act as a “provider” with the Global PoP infrastructure. All of that is done to make sure that all users have multiple options available and we can support them in whatever it is that they want to do.
Offering a single provider means that there’s a single thing you can do. If they give you IP space over a tunnel, you cannot e.g. advertise your IP space via BGP. If you only want to connect to the Intranet, and they provide Internet addresses, you may not be able to do that. We want to support even these users that their current (or only available provider) is not enough for what they want to play and experiment with. We even want them to be able to become a “provider” for other users if they want to.
It’s all about enabling users and making it as easy as possible for them to do what they like.
With this proposal a machine would require at least two IP addresses from two different networks (with additional overhead for subnet, router, broadcast addresses) just to have connectivity to both. This doesn't help with the limited amount of addresses we have. It would also make it impossible for devices and routers to automatically choose the most optimal path towards a machine, whether it is via a radio link, the internet or a tunnel. This means we would need more address space, and we are not benefiting from the advantages of multi homing.
As argued earlier, using more address space is fine. About the multihoming scenario I think you can advertise the 44.128/10 space to Intranet people, and the 44.0/10 space to Internet people. Each device can have a single IPv4 address. By using “netmap”, which is available in all Linux distributions (at least), you can translate between the use cases transparently for the end-device. And since netmap, unlike NAT, is completely stateless, you can have multiple locations where you perform this action. In NAT, due to the stateful nature, you need to pass all traffic through a single point. With netmap, you can statelessly do this anywhere, even if traffic exits one point of presence, and enters another.
44.137.0.0/16 for example already shows that a network that connects both to the internet and to a local radio network works perfectly fine. Users only need 1 IP address for a single machine to have connectivity to the internet and to the radio network.
There also seems to be a lot more announcements in 44.128.0.0/10 (876 prefixes) than in 44.0.0.0/10 (533 prefixes) or 44.64.0.0/10 (340 prefixes), so your statement that most current Intranet users reside on 44.128/10, and that most Internet-connected users reside on 44.0/10 is not true.
I hope that this was addressed with my response to Rob. TL;DR: it’s not about /16’s but about end users and hosts.
Regards,
PH5X
Thanks, Antonis