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

On 7/28/21 12:31 AM, Antonios Chariton (daknob) via 44Net wrote: 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. 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. 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. 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. 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). 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. Rob