Hello again,
It seems to me that we are making this more complicated than is
necessary. How about this for a simple approach: There are already a
number of HAMs who are already operating small networks and are
announcing AMPRnet prefixes to their peers/upstreams.
Why can't we just make a list of these "BGP speaker HAMs", if you
will, their locations and their contact info. Other HAMs in the area
who wish to connect to AMPRnet and are interested in a more "local"
approach (rather than just going through the UCSD edge) can then reach
out to one of these "BGP speaker HAMs". Not only would this solve the
issue being discussed, this sort cooperation would help to build up
and strengthen local HAM communities by getting HAMs with different
skill-sets to work together on making AMPRnet connections work.
To get the ball rolling on this (to be a "doer" as KB9MWR mentioned
above), I'd be happy to throw my hat in the ring and put myself on
such a list:
I'm KE5SAI. I'm located in Austin and operate dedicated servers/VPSes
in Dallas and Kansas City. I announce 44.76.17.0/24 to my upstreams. I
do both amateur radio and IP networking as my hobbies. As such, if any
HAM in the region would like "local" AMPRnet connectivity, I would be
more than happy to carve off a piece of 44.76.17.0/24 for them (I've
certainly got plenty of space on it to spare for other HAMs) and
provide them with a tunnel to complete the connection. It would be
better than "turnkey solutions". It would be HAMs working together,
cooperating from each other and experimenting together.
Regards,
Erik
KE5SAI
On Sat, Jul 11, 2020 at 4:11 PM Jason McCormick via 44Net
<44net(a)mailman.ampr.org> wrote:
I'm a relative newcomer to using 44Net for ham things (last 2-ish years) but
we've made extensive use of it in our Megalink project for Northeast Ohio.
I think that something that is more turnkey for the ham community is sorely needed. Most
hams are not network engineers. Much good work has been done over the years to make AMPNet
what it is. However in 2020, most basic infrastructure is largely turnkey (e.g. AWS,
Azure, cloud hosting, VPS, etc.). Infrastructure and network engineering is, sadly, a
diminishing field because the need just isn't there anymore outside of the big
providers. To support ham connectivity into the future, AMPR needs to offer something
comparable.
The one caveat I would offer is that endpoints connecting to such a new service core
should be one of a limited number of supported hardware + software configurations at the
end. Experimentation can be free beyond the connection's edge device but the edge
devices themselves need to be fairly uniform for supportability. I also firmly believe
that any new service should be dual-stack v4 and v6. We should be encouraging the use of
IPv6 as a primary goal. We could get a /32 or so from one of the RIRs as AMPRNet v6.
The other thing is that having lots of transit at major providers is $$$++ (relatively
speaking) and we're probably want run the core on some serious networking hardware.
Would ARDC fund these? I'd be willing to help run one or several, but the expense of
doing so is far beyond my budget.
Jason N8EI
-----Original Message-----
From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On Behalf Of Rob
Janssen via 44Net
Sent: Saturday, July 11, 2020 4:52 PM
To: 44net(a)mailman.ampr.org
Cc: Rob Janssen <pe1chl(a)amsat.org>
Subject: Re: [44net] My view to 44net's future
It is about a year ago that I tried to discuss such a proposal.
My view was like this: let's establish routers at datacenters around the world, in
addition to the existing UCSD router and some others that already handle
/16 networks
on internet. I was thinking about around 10 routers globally. They interconnect using
BGP on private AS numbers (the 32-bit AS numbering scheme we already
use) over a mesh
of tunnels between them, to exchange routing information for 44Net subnets, but on
internet the announcing remains as it is (i.e. the whole network is announced at UCSD, and
regional subnets are, but do not need to be, announced at those global routers).
The "users" connect to those routers using a (small) variety of tunnel
protocols to match the restrictions they face from their internet providers, e.g. forcibly
being behind a NAT router, having a dynamic IP address, maybe having some enforced
firewalling, etc.
I was thinking of standard tunneling protocols like GRE, GRE/IPsec, L2TP/IPsec, etc.
The tunnels would be operated in a point-to-point fashion by default
(/30 or /31 subnets
on the tunnel), and the users would use BGP to announce their own routable subnet over
that.
They can setup redundant tunnels to multiple global routers when they desire to do so.
They can also setup tunnels directly to other users when desired, and run a BGP session
with them. And of course, radio links can be incorporated in the scheme.
Users could use the widely available inexpensive routers available today that can use
these standard protocols without special tinkering with scripting, locally compiled
executables, etc. E.g. the inexpensive models available from MikroTik, Ubiquiti, etc.
More technically inclined users could install software on their own Linux system or
-board.
I see this as a solution for the following problems:
- more and more users struggle with getting IPIP routed on their internet connection, due
to them being behind ISP-managed routers, CGNAT, having dynamic addresses, etc.
- non-technical users struggle to get our special IPIP mesh operational on their routers,
where using industry-standard protocols would be much easier as their router config
interface already knows about those.
- some users requested to have redundant IPIP tunnels (multiple internet routers serving
the same 44Net subnet(s) in a redundant way, which the IPIP mesh cannot do.
- the IPIP mesh does not really allow to check the status of the configured gateway
routers, so routers that have not been operational for a long time just remain in the
tables.
I expected enthousiasm from the users, but unfortunately I was met with a lot of
resistance to change, e.g. from people who believed that such a system would rob them from
their direct tunnel to their buddies on the other side of the world and force them to go
via established and centrally managed hubs (incorrect, of course). As I see this as a
hobby and not as a struggle to be right and convince those that do not want to be
convinced, I did not pursue it further.
I don't know if the attitude an scepticism has gone away now. We would have to see
in a new discussion. Maybe some of the opponents have realized by now that it would be
better to have a more flexible mechanism like this instead of going on with the IPIP mesh
forever. Maybe not.
I don's see the need of routing the entire 44Net from internet to all those routers.
When everyone routes only their own regional subnet(s), it remains more manageble and we
do not face the raised issues. Furthermore, some of us have our ISP announce the relevant
regional subnet on their redundant border routers under their AS, and then route it to our
"gateway" router. That relieves us from being responsible for that
announcement, and we use the ISP NOC services. But of course it also means we are less
integrated with the internet routing, e.g. we cannot allow that subnets from our
announcement are routed to others.
Of course everyone can decide if they want to announce their subnet on internet directly
or via an ISP, but I would suggest that the internet side of things be kept separate from
our internal routing (2 BGP instances, the 44Net one using a private AS number)
W.r.t. the .ham TLD: I don't see what advantage that would bring, we already have the
.ampr.org domain and we run the DNS for it. It should offer the same capabilities as a
dedicated TLD, I think, at a much lower cost.
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net