Let me be clear about my view of what net44 is what it is not. Net44 is an IP space. That ip space have been granted to the ham community to experiment with networks and digital communication. What I see nett44 as is like network of road. Some of the roads are highways. The flow of traffic is free and there is no bottleneck. some are backroads. the fork from large highways and they go to a ham places. That ham can decide that anyone can come and look at the end of the road, some are more peaky about how get to get in the end point. They prefer that it be only ham's or even just some particular ham's that can and look at the place and maybe use the tracter or drink a beer!
What vehicle that ride on the road can be a simple car, a big truck or even a bike. Each have the vehicle they want. They can come from the big exchange down the main road and be hackers, ham's, plain internet user. Or they can come from inside the net44 road network and be ham.
Those ham also have a back road going towards their place. they can be peaky or not. and the peaky one can choose to go to every place on the road and the big exchange or they can go to see only other peaky ham's places only.
That is net44 for me.
What is not net44 is at the end of the back roads, it can be anything. a garage a liquor store a cloth store or a restaurant. That is to the ham that made the back road available to decide.
My analogy is a bit awkward. It does not show every use case but it very close of doing it.
Net44 is a network. What it should be doing is link ham to either the big internet and be reachable by the big internet and net44. It also should link net44 for ham only to net44 for ham only only. And it should link net44 for ham only to the big internet at the demand of someone inside net44 for ham only like we do at home behind our firewall to prevent the big internet from invading our home.
What run on the links is not a use case of the network. I think of a network as a tool. once we have the tool working we can do something with it. Our tool make the transfert of data possible. Most of the time that data will be served in a client/server fashion. ( I dont think we want to have some multicasting all over the net44) So every thing that is so is not a use case for me.
If a ham put a DMR repeater on a link that is on net44 (what ever the use case) it will be a client that will connect to a server ( like Brandmeister, TGIF, DMR Marc, etc..) and the server will respond. We can now deduct that this repeater should be on the open to the big internet part of net44 as it need to connect outside of net44 ip space and will probably want to be also reachable from outside net44. How do I deduct it? It is by knowing the target audience . this make all the difference in the world. If the target audience of an ip address from net44 is for every one on earth can can connect to the internet or net44, then it is a use case. Since that ip address want to be reachable from the big internet it can also connect to the big internet like anyone else.
If the target audience is ham only then it is a use case. If the same ip address need to access the big internet, it should be doing it as if it was behind a firewall. Now can we make sure only ham's are using net44 ip address to that user? The answer is no. We seen in the last month that hacker were using some of the unused /24 and they were advertising them by BGP. So if someone do this the ham that want to give to ham only access to his SDR or even transceiver, can trust the fact that a user that connect from a net44 address is a ham right now.
Now How can we make sure the ham's that are peaky to whom access their service they put online can trust that the one connecting to their service? The only good way is to make sure that only parts that are ham only can route to ham only section. How can we do this at the network routing level? Simply by giving the route to the router that connect to the ham only part of net44 a list of the "officially" ham only section of net44.
But there is something about net44 right now. Ip address allocation in spread all over the place cause it used to be assigned by country or part of the USA. So imagine how many route a router will have to manage if we go that route, hum.. sorry wrong choice of word, If we choose to keep net44 sparsely assigned to either a net for ham only and some other part connected to the big internet.
And things will get even worst if we now have some POP (point of presence) that will link new ham to the net44 in a more efficient way than the ipip mesh . The number of route will multiply. Cause those ham will want either to experiment with networking in the net44 address space, maybe access the big internet also and maybe connect to ham only services.
How will we manage this? Dont get fooled by the magic idea that the POP will all manage that. This would be a KOLOSSAL thing to achieve with existing technology. And I did not even start thinking about maintaining it. Yes there is a new portal in development. But do we want it soon or only in 5 years? And 5 years is not even difficult to imagine. The portal will need to manage the login of all the ham that are net44 user. It will also need to manage a way to distribute the route of all the various type of connection and target audience to all the POP's It will need to modify the DB of ARIN for all the allocation by itself if we dont want to have to wait a long time to new request. It will need to manage rDNS, location advertising, name it ,all automatically. Am I the only one that thinks this is not far from being magical to think will be done in the next few months?
The proposal made by the TAC was supposed to fix all this at the network level with simple solution that are not that difficult to implement WHILE the new portal is being developed and stuff automated. But at the same time since there would be easy identifiable network in 2 /10 (44.0/10 and 44.128/10) it would not be putting a large burden to develop ways of doing complicated routing transparent to the ham community with software.
We all know what will happen, develop a new soft, test it find bugs, test again, make it alpha to test even more with a small group of user. find new bugs or the idea dont scale well, back to the drawing board, test the new solution again with alpha tester, go to beta, new bugs, strange problems arise, new version, bug fixed, new bugs found, fix bugs, Candidate Release 1, new bugs , CR2, add new user to the test bed. Oups big problems'. patch, CR3, test it a bit lounger with even more beta tester, ok we have version 1.0!!! Now we have the whole community using it. Some like it, and want that and that new fonction, some other dont like this and that and of course, there is no ver 1.0 that does not come with bugs..
The TCP/IP routing stack is mature. It been developed for decades and decades. We still have some modification to it for new protocols or security patch. Why go with new software development to prevent people from renumbering? Cause in the end this is the main problem that been reported to the mailing list.
People want AMPR to find another solution because they are entitled to the address space they've been assigned to. But do they come with easy solution? Nope. Not one solution is simple to implement on the networking point of view. And they all rely on new software or new solution that have not been really test for the use case.
Sorry for the long rant.
Pierre VE2PF