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

Ruben  - I chose your message to reply only because it is relevant, and I do not want to reply to each and every message again. But my reply is towards the proposal and the admins of the German HAMNET. I have been offline (from this list at least) for a couple of days to calm down and not to keep stirred up in this dogfight. It looks like (from the reactions) that this whole proposal is coming mainly from the German HAMNET people, they apparently have a problem with routing that they want the rest of the world to solve.  But it should be clear that it is a problem they create themselves.  Others in the world do not have the issue, and still they are tasked with extensive effort to renumber.  Which the German HAMNET people should know, as they were forced to renumber due to the sale, and they still have not completed that task after two years. It is often brought up that "to route to the Netherlands we need to send the traffic to internet and we do not want all those static routes".  But that is not true at all.  Our Dutch network is reachable in several ways: - over radio - over the IPIP mesh - direct BGP on internet. So to send traffic to 44.137 you do NOT need to route it to some local internet gateway, you can just put it on the radio network and it will get routed to DB0FHN and that will route it via IPIP to us, and the reverse also works. In fact, sending it to internet usually is the CAUSE of problems, because you will NAT the traffic and it will come in from a commercial IP instead of a HAMNET IP on our gateway, where it would usually be blocked. And, when we from 44.137 try to connect to someone in 44.148 we route via the IPIP mesh, so it is just wrong for stations in 44.148 to return the reply via a NAT router.  The reply will not match. Now, the issue seems to be "but we cannot route all traffic for the Netherlands via DB0FHN because that is an enormous detour over loaded links".  Well, that is yet another self-chosen design issue.  Nothing prevents you from setting up another "DB0FHN" which is in another part of the country and which is also on the IPIP mesh, but for a number of smaller subnets (44.148.x.x/20 or similar).  When you register that in the portal and route your traffic via that node, we will correctly reply to that and it will go via that alternative connection just fine.   No need to route everything via one place!  That is just a decision you made. Furthermore, I think it is best to replace the IPIP mesh with a new backbone as described several times now, which would be even better geared towards such regional subdivision.  Every place in the German HAMNET which now sends traffic to internet via a home NAT router should instead connect to a local PoP in the new backbone network and just send all 44.0.0.0/9 and 44.128.0.0/10 traffic for which it does not have a better (local) route there.  Then it can be send to networks like ours (Netherlands) WITHOUT NAT and WITHOUT the problems that are now occurring.   The density of the users in Germany could even make it legitimate to have more than one PoP in that area.  So the delays will really be minimal. And the admins of those connection points do not need to have more than those 2 static routes. Remember that being connected to the backbone does NOT mean that you are forcefully connected to internet.  When you do not want that, it can be disabled.  A feature of the PoP should be to enable/disable internet connectivity for every connected station, and lacking that the same could be achieved with a simple access list rule.   Connecting to the backbone is, just as on the IPIP mesh, primarily a method to connect to fellow AMPRnet users, and internet connectivity is only for those that wish to have it. As a whole, I think the problem the TAC wants to solve is a self-inflicted problem that can be solved in other ways than by forcing a restructuring of the network.  And, like others, I fear that this restructuring in the end will not even solve the problem at all.  It will just me swept into a different corner where other issues will occur. So I want to propose that this whole TAC proposal is put aside and first the TAC works on the design and deployment of the new backbone network, and on making the internet connection points in Germany that now use NAT to use that new backbone. If, after that is completed, there still are issues we can always come back to this proposal and see what can be done and how problems can be solved.  Preferably without wiring policy in network layout (a bad thing IMHO) and without imposing renumbering on OTHERS.   Because the impact is known, it will knock us into instability for 2 years and we finally get nothing out of it. Rob On 7/30/21 5:09 PM, Ruben ON3RVH via 44Net wrote: