Re: [44net] A new era of IPv4 Allocations

Hello Mario, please find my answers below: These are equivalent. The radio network and the Intranet are the same for the given context. Think of it like using amateur radio frequencies vs 4G / 5G frequencies. This is the first point. We do not want to limit the hardware, but we would like to have an IP version of the frequency plan: 44.128/10, however you connect to it, is the radio amateur band, and 44.0/10 is the commercial 5G band or the ISM band of WiFi. One is for people that are licensed, and the other is simply the Internet that anyone can use. Yes, correct. One of the things that this proposal can bring is that a part of the network is reserved for radio amateur to radio amateur communication. This is actually (part of) the proposal. That we guarantee that people in 44.128/10 can only be reached by other people there, and people in 44.0/10 (technically /9) can be reached from the entire Internet, except 44.128/10 (natively). This is similar to how only radio amateurs can transmit in a ham band, but everyone can transmit to an ISM band (including hams). You can address the “radio network” with a single route: 44.128/10. This proposal guarantees that everyone there will be on the radio-only network, the same way transmitting to 144-146 MHz in the EU is to reach hams only. Any traffic you receive is (should be) from a ham, and you should only send anything if you are a ham, and you intend to reach other hams. Transmitting to 2.4 GHz in the ISM band allows you to talk to more people (anyone), but also anyone can talk to you. We probably have a lot of people in this mailing list that were even a part of this and can speak up, but this happened before the Internet was (broadly) adopted and the 44/8 was a way for this “Internet” project some people were working on to talk to this network of these “radio amateurs” that they set up in the USA or Europe, etc. Yes, correct. This proposal wants 44.128/10 to not have any direct BGP allocations that appear on the Internet. Connectivity of these networks should happen between themselves (network to network VPN, radio links, …), the ARDC (or anyone else’s) PoPs, etc. and they will not communicate through the open Internet. Unfortunately this would be difficult to accommodate as the guarantees cannot be offered then. If radio amateurs don’t have a dedicated band to talk to each other, and they have to use the ISM bands, there’s no way to distinguish between normal people and licensed hams. You can’t tell and there’s no guarantee that the person you’re speaking with is a ham or anyone else. Similarly to the RF world, in IP there’s this kind of problem as well. If you have IP addresses on the Internet, you could receive traffic from anyone. Sure, you can use an ACL or a firewall, but that’s not guaranteed. Packets could be spoofed for example. If you have a special network where you know that all senders and recipients are hams, then you can build things with different assumptions. You can build internal tools or apps, websites, etc. It’s up to you. It’s a band where you will only find people of the same hobby as you, that are licensed. The other part is like an ISM band. Sure, you can use this to talk to other hams, and you can use it to talk to non-hams, and non-hams can use it to talk to you, and you have to establish by your own means who is who, and ensure that they can’t trick you. What our proposal aims to do is to create a separate “Ham Band” / Intranet / 44.128/10 and a separate "ISM band” / Internet / 44.0/9. By using simple RF or IP you can’t have them collocated into the same space. This is the reason why we cannot have scattered space and we want to have it aggregated and easy to address. Instead of our “band plan” being hundreds of lines and have it change daily, and move band from “ISM” to “Amateur Radio” and vice versa, we want to create a very simple band plan of 2 entries that don’t change. One is, and will remain to be “ISM” (44.0/9) and one is, and will remain to be “Radio Amateur” (44.128/10). Having a more stable and simple band plan is easier for everyone. They can make more informed decisions for the future, they can choose who they want to talk to, and they can even decide to use both bands: use a handheld radio (Radio Amateur) and a phone with WiFi (ISM). This is what we try to do on a technical level. Clearly define the two bands, and make sure that they are very few, and very stable. In the IP world this translates to easier routing (each “band plan” entry is a route, and if it’s just one, it could even be a static one), and less frequent changes. I don’t have to consult today’s band plan to know why 44.5.5.5 does not respond from 44.128.128.128, if the reason is that 44.5.5.5 decided to be Internet-only today or Intranet-only tomorrow. We could have made use of complex routing protocols and policies that would dynamically try to discover what each address or subnet is (because it’s not always clear and we can’t always tell what each address wants to do, even if we forced everyone to connect to an ARDC PoP) and then continually adjust this and maintain a complex state. This is something that a lot of people would also have to do, or they would have to find someone to do it for them (e.g. the ARDC PoPs). Going towards our value of being as inclusive as possible, we did not want to force people that don’t want to to have to do this or to have to connect via an entity that can do this. By having a 2-line band plan that doesn’t change over time people can even hard-code it if they don’t want to deal with all of this complexity or necessarily rely on someone to do it for them and then form a dependency to them. Furthering the analogy, a handheld VHF manufacturer relies on a constant band plan to allow TX to 144-146 MHz and doesn’t have to build a system for their product to download this hour’s or this day’s Amateur Radio allocation and change the functionality based on that. You can also be sure that your local amateur radio repeater won’t be today at 89.7 MHz and your favorite radio station won’t transmit to 145.500 MHz this afternoon. That’s an interesting point, and we could look into improving the language, but we thought that the “TAC-proposed Global PoP Infrastructure” was specific enough to prevent ambiguity. In any case, I imagine that after we deliver our proposal to the ARDC Staff, it will be vetted by both them, and the Board, to avoid problems like that. Thanks for mentioning it though! I hope this clarifies it enough for everyone, Antonis