28 Jul
2021
28 Jul
'21
6:11 p.m.
On 7/28/21 12:24 PM, Antonios Chariton (daknob) via 44Net wrote:
I think you are
proposing a solution in search for a problem, and you inserted different
"problems" in your proposal that seem fabricated at best.
We need to look at the matter based on FACTS and not by setting up an entire problem
sketch with fabricated reasons and evidence.
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.
You are correct that this is something that
should be managed locally and not by ARDC. It was brought up as an example and the TAC has
no intention of setting a policy at this level. This can be seen from our resolution that
does not mention anything related. I apologize for the confusion.
We currently have a large number of users that have reached out that have an ISP-provided
router that they do not want to change, regardless of cost, as it’s simple and it just
works. These users have a radio on their roof that connects to an Intranet like HAMNET.
They want a single prefix they can point as a static route to this radio, and the
remaining of it to be caught by the default route they have to their commercial ISP. The
equipment their ISPs typically give them does not support any kind of VPN or tunnel.
Moreover, if they install e.g. a Raspberry Pi to do the VPN, then they still have the
issue of “what prefix do I need for the static route”. The 44 address space that is
"Direct BGP" made the conscious decision of being available on the Internet,
which means that these users should reach them via their commercial ISPs. Some other
operators want to only be reached over the Intranet. This proposal gives a way for all
these users to finally connect to the Intranet that they want to join without forcing them
to massively complicate their network with more equipment, VPNs, dynamic routing
protocols, etc.
About 8 months ago we had a discussion about a new backbone that would replace the IPIP
mesh and
that would exactly cover this. We had a lot of input, but the discussion was taken
offline and the TAC
would come with a proposal on how this would be designed and implemented.
After that, we have heard nothing for 8 months and now we get a paper that proposes to
change the
network layout, rather than implement the new backbone that would make that change
unnecessary.
What happened to the backbone proposal? When will it be published, and when will the
implementation
start? Would it not be better to not make unnecessary changes to the network pending
that?
The new backbone would solve those issues by offering plain VPNs, that can be installed on
many routers
and other equipment out-of-the-box, and where a user could route the entire 44.0.0.0/9 and
44.128.0.0/10
minus their local network. No need for complicated routes.
There is always some minimal equipment or minimal effort. When you want to transmit on
20M, you
cannot do that using your ISP router (some of them do...) but you need to build or buy a
transceiver.
When you want to be on AMPRnet, you may need to install some VPN software, or you may need
to get
a Raspberry Pi or a MikroTik router or similar. I do not see that as prohibitive and we
should not try to
make a network that covers that, because users will find another reason why they do not
want to join.
The fact that you hear that from the users is not very relevant. Back in the early days
of packet radio
there already were users that "would not invest in a Digicom modem". Not every
aspect of ham radio
is for everyone. That people respond "I do not want to purchase any equipment"
in a questionnaire about
"what would you want to do to join HAMNET" should not be taken as an indication
that everything should
be done without extra equipment! And even less so that the existing population should
make whatever
effort necessary to accomodate that type of new user.
We therefore believe that it massively decreases the barrier to enter in both cost,
knowledge, complexity, and time. For the current TAC, lowering the barrier to entry is
something we need to address now, and not in 20 years. We do not like to exclude people
and tell them to come back in 20 years because they’re not as knowledgeable or willing to
spend the time, money, and effort right now. Instead, we try to serve them today, and help
them join the 44 Net.
The barrier will be lowered with the new backbone network.
It is true that there are more advertised IPv4 addresses in 44.128/10 on the Internet.
However, according to the study that we did, and is linked in the original post, there is
a *massive* discrepancy between advertised space on BGP and actual usage. We see large
parts being advertised (entire /16’s) yet only 2-3 users with < 20 hosts within them.
Although we looked at the allocation plan, we identified that it’s more helpful to either
look at it in more depth (e.g. end-user allocations) or also rely on the ICMP checks we
did, where possible.
1. you cannot research the network by scanning it from the
outside. I, as an IP coordinator, have never seen any request for information about the
usage of our network. Sure when you scan it from the outside you see only like 20
hosts. But that is because of trapdoor firewalling, not because there are so few. We
just guard against port scanners and blacklist them.
These checks showed us that about 75% of the IPv4
addresses that respond to ping are available on a large Intranet and the vast majority of
that is in 44.128/10. That said, if we did not use 44.128/10 for the Intranet part, we
would cause around 75% of the global users (in terms of IPv4 addresses responding to ping)
to renumber.
You should not look only at the number of hosts, but also the number of
subnets. Effort to renumber is likely also depending on routed subnets. We do not have a
flat address space where we can move hosts one by one.
To sum up, I agree that 44.128/10 has more advertisements on the Internet, but in our
detailed look, the vast majority of hosts within it are Intranet-exclusive. Therefore, we
decided that this should be the Intranet prefix.
IMHO there should be no intranet AT
ALL within network 44.
This proposal aims to make it as simple as possible for the users to join the network.
This can be achieved with a single static route in their ISP-provided equipment, for
44.128/10.
That starting point is totally broken. You need to go back to square one
and find a different solution to your problem.
(which I have never seen in our network because we offer a default route to those users)
The users don’t want to have to create multiple
entries (some equipment limits to 8 static routes) or have to update them regularly every
time we allocate something, and until everyone changes their static route to have network
splits or reachability problems. If this passes, they can add a single static route (to a
radio or a VPN server) and never have to worry about changes again.
There you go.
Not a solution. Move away from the presumption that you need a static route in an ISP
router, it is just invalid.
Using any RFC1918 prefix for the Intranet has been considered by the TAC. Unfortunately,
it comes with a set of problems that don’t occur in the currently proposed scheme: because
everyone can use these networks, by definition, there *will* be collisions, and there will
be no central coordination and guarantee of non-overlapping spaces. Nobody can prevent two
“Intranets” from using the same address space, a lot of users already have a 10/8 network
on their homes, that will most likely have overlaps with the Intranet, etc. By using
44.128/10 that is centrally managed and coordinated by ARDC, we guarantee that each user
can enjoy a globally unique allocation that is guaranteed to not overlap with existing
network infrastructure or with other networks they want to interconnect with.
You
can setup a management system for 10.x.x.x space to guarantee that no two amateur radio
intranets will use the same space.
With a little research you can cut out the typical blocks used by existing ISP routers and
not allocate those to anyone.
Maybe really sometimes you will have an issue and someone has to renumber a small space,
but I do not think it is a good idea to force large networks to renumber just to cover
this imaginary problem.
We want to be able to accommodate for every use case
with our proposal, so we don’t want to leave any user or community behind. Perhaps it’s
better to think of the two spaces as “Internet” and “Intranet”.
Stop there! No
intranet please. people can decide to not route their space, but you should not enforce
people to make their network an intranet just because someone else cannot manage their
local network.
The first use allows communication of hosts to and
from the entire Internet, 0/0. The second use case is a private network that only ham
radio operators can access. This can be connected with radio links, satellites, VPNs over
the Internet, etc. We do not want to force you to use a specific technology. We just want
to make sure that we provide a network for both use cases.
Your users in The Netherlands may want to remain connected to HAMNET in Germany and the
rest of Europe. They may also want to have Internet access with publicly routable
addresses. Both these use cases are fine and perfectly acceptable.
If you determine that you need to be connected to both networks, and connection to the
Intranet is not simply enough, you can request a matching allocation (I think /17?) in
44.0/10, and then set up a “netmap”. This is an iptables target (also available in
RouterOS) that replaces the first bits of an IPv4 address. With this, you can leave all
the IPs intact so you can communicate with Germany, and on the single point that you
connect to the Internet you can advertise the new prefix, and perform “netmap” of the
entire old /17 to the entire new /17. So the Internet will see you as 44.0/10 and the
“radio network” / Intranet will see you as 44.128/10.
I prefer not to enter into NAT solutions in a network that was clean of NAT
solutions until now.
Let's go back to constructing the backbone that makes the routing decisions, allows
users who do not get involved with that to stay away from those (and still allows users
who want advanced solutions to interface with the routing), and lets not hardwire policy
into the address space. That has never been a good idea.
Rob