5 Aug
2021
5 Aug
'21
9:38 a.m.
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