30 Jul
2021
30 Jul
'21
7 p.m.
Dear Mario,
Indeed, yes. This is up to the operators of these services. We do not want to interfere
with what they do and how.
To be clear: 44.0/9 *cannot* directly to 44.128/10 and 44.128/10 *cannot* talk directly to
44.0/9 under our proposal. I believe that this is what we include in the proposal text as
well. For all intents and purposes, we treat 44.0/9 as any other IPv4 address on the
Internet when we talk to it from the Intranet. The same way a 10/8 host cannot talk to
1.1.1.1 a 44.128/10 address cannot talk to 44.0.0.1. The operators of the networks will
have to use NAT (like they do today), or they can also request a 44.0/10 space and do a
1:1 mapping of hosts, or anything else.
- You should never receive a packet in your 44.128/10 address from a non-44.128/10
address
- You should never receive a packet in your non-44.128/10 network from a 44.128/10
address
Yes, this is something we can do, and it’s a good idea.
We agree that this is what should happen. However, for any Internet-connected network,
there’s no guarantee it will always be true.
This is true, and a very common problem in community networks that I know of. People at
one point have a diverging vision and don’t agree anymore and then they stop exchanging
traffic. It is unfortunate to see in a network that’s supposed to connect people and it
can really slow down deployment efforts, but it can always happen. We even see parts of
that in the Internet too. I don’t think there’s anything ARDC can do to prevent this. The
only thing is to make sure there’s enough room for everyone and interconnecting is easy.
If some people want to be isolated or not talk to specific people, then I guess that’s
that..
This proposal aims to have ARDC continuously advertise 44.128/10 on the Internet, but as a
whole block to which all traffic is dropped and not forwarded. We don’t want to change
that. We have to keep advertising the space, for many reasons. Hopefully if we could get
RPKI we could publish a ROA that would cause people validating to drop all announcements
smaller than /10 in this space as well, so they are automatically discarded by filtering
ISPs.
As I have mentioned above, this problem is not simply solved by an ACL. It’s not a
firewall rule to drop all traffic and that’s it. If all want to be on the same routing
plane without causing massive packet loss and unreachable destinations, we have to find a
way to inform everyone else of our policy. And BGP cannot currently do this, especially
with the limitations of vendors like Ubiquiti and MikroTik. An ACL could solve this
problem if we had a very centralized network where everyone connects to the PoPs and it’s
mandatory, and interconnections between end users or networks is not allowed. If 44 Net
looked like this then applying any type of police would be much easier. But if you allow
for any use case, like hundreds of nodes connecting to each other, and only talk to the
PoPs from 3 points on the Internet, then things can get more complicated. “Simple ACL” is
easy on paper, but in reality it’s much more complicated than that.
Of course, I agree that there isn’t any mandate that I know of. However, all the policies
of each and every individual link in every single part of the network must be immediately
available to every single (at least “backbone”) router and must be used in the routing
decision making. If people have links visible through BGP that silently drop traffic this
will cause a lot of practical issues with unreachability like many we see in the network
today. And the people, no matter how much they want to fix them, won’t be able to.
Unfortunately mechanisms like uRPF that you mention only work to protect others from your
network. If anything is more than a hop away, especially in a scenario where a gateway has
a single transit provider / default route, then they can’t do anything. If you have a
default route on your Vultr VPS (or even a full table, doesn’t matter), you see the entire
Internet behind “eth0”. So everything coming that way will make it into your network just
fine. The only thing that uRPF will do is to not allow packets from your own network to
come via the Internet. Which you may have to allow eventually if e.g. your network is
connected to the Internet via 3 points, and you want to go over the Internet in the case
of a net split. So a lot of networks will end up disabling it (or choosing a more relaxed
version, or technically not enabling it as it’s off by default) in the first place because
it breaks legitimate use cases.
I would personally agree that people running more core parts of the network should have
more networking knowledge, and that would be expected, but I wouldn’t expect perfect,
state-of-the-art operational expertise and equipment support. I would still expect to see
operators like these to simply configure BGP and a few filters. And that’s fine. We’ve
learned from the Internet that any system that relies on everyone adopting it and playing
fair is far less likely to be useful.
If the network was more centralized and every 44 island required the PoPs to connect to
each other, and everything had to go through them, then you could argue that the ARDC
staff maintaining it would have to follow state-of-the-art procedures and since it’s only
a few points we could also have capable equipment, etc. So this becomes kinda better. But
still, this means a centralized network. Do we really want that?
Yes, and that’s exactly the problem! The control plane that BGP sees is different than the
data plane where the ACL drops the packets at. People using BGP see a valid path, but then
without telling anyone the operator(s) of the link drop the packets. There’s no way for
BGP to convey what firewall rules each link has attached to it and then take it into
account during path selection based on packet values. And there’s probably a good reason
for that, as you can’t accelerate any of that on hardware I imagine.
Yes, I agree.
Yes, this can easily be built. But isn’t building it easier if we guarantee that 44.128/10
does not appear on the Internet and should only be routed either on top of the Internet
(tunnels, VPNs, …) or other means (radio) ?
What I’m trying to say is that if every user of the network was competent and could easily
do such changes (like many people have claimed in this thread), then we wouldn’t have
cases where a single person is managing the network of 20 others. Everyone would probably
manage their own network. So it’s a point to make towards the fact that not even the
existing users are or want to be involved in all this routing.
We don’t really know to be honest as only a few people have participated in this
conversation out of the thousands that use the network. So our margin of error here is 99%
;)
We’re also not taking away anyone’s toys, if anything, we give them more.
I respect the people that have been doing this for decades, but I also understand that we
need to leave a lot of room for people that do this one decade, or 5 years, or 1 year, or
0 to grow as well and do what they want to achieve. Just because some people started this
25 years does not mean that this thing we have shouldn’t evolve to allow for more and more
users to participate.
I am not sure about that, but see, thats the thing. The decision of this
being illegal can not be made globally (and your intranet is consisting
of the current allocations for allmost all of the world) but it needs to
be made on a local / country basis, as it has been in the past.
There are certainly arguments for and against country-based vs use-case-based allocations.
I feel like if we do country-based allocations, as is evident from my e-mail above, we
will have a lot of trouble finding a way to represent the ACLs of each link on BGP (or any
other mechanism that can reconfigure all network routers). If this is not possible, then
we’ll need to have people maintain complex routing tables to go around entire countries
(if they even can) just to be able to deliver some traffic, because the BGP Best Path
drops it.
If we go with a system based on use case, then this is not needed, as people can easily
hardcode the two network policies that exist and easily route any way they want based on
them. This list of links is easy to aggregate: any link in 44.128/10 has policy X, and
each link in 44.0/9 has policy(ies?) Y.
Antonis
On 30 Jul 2021, at 17:11, Mario Lorenz
<ml(a)vdazone.org> wrote:
Dear Antonios,
Am 30. Jul 2021, um 15:32:26 schrieb Antonios Chariton (daknob):
The first reference of people is hams, the second is non-hams. So this sentence becomes:
That’s what hams want to do though. Hams want to use an amateur radio resource (44.0/10)
to talk to non-hams on the Internet (that are not licensed).
We do not want to restrict people on 44.0/10 and we want them to be able to speak to
anyone on the Internet. Of course, ARDC here may have some policies against e.g. spam,
piracy, etc. but that’s not relevant. They are responsible of figuring out though if their
communication is legal.
The proposal simply puts all the people that want to talk to the Internet in 44.0/10 and
leaves all the people that don’t want to talk to the Internet with a 44 address to
44.128/10.
That’s what people want to do though. They want
to use an amateur radio resource (44.0/10) to talk to people on the Internet that are not
licensed. Normally in RF you use a ham radio frequency to only talk to radio amateurs. In
the IP world, the src and dst can be different. People want to use an amateur radio
resource to talk to a commercial resource, and a commercial resource to talk to a ham
radio resource.
Please define "people". Are these radio amateurs ? If so, why do you
want to restrict communication with them ? What they have to say can go
over amateur radio airwaves. If not, why are they in 44.(0). in the
first place ? Here's the thing: If there are "people" that are not radio
amateurs but want IP space for non amateur communication, they can go
and get it somewhere else, and pay for the privilege.
If that needs any TAC resolution to propose at ARDC,
I think you would find much support on this list. These two
networks can interconnect. EchoLink now bridges the Internet with the amateur radio
spectrum. But we don’t use IP addresses on EchoLink, we use our callsigns, transmitted
over IP packets. And similarly, when we do IP / Internet connectivity over amateur radio
spectrum, we use IP addresses on top of callsigns.
In which case you need to differentiate between amateur radio and third
party traffic. We have
collected minutes of meetings that we did as the TAC, and they capture a part of the total
work that has been put through this. However, at this time, they are not public. Is there
something specific that you’re looking for? I could help provide more information on that.
As discussed before, the pdf statement contains contradictory, not
sufficiently specific language. Your explanations, as given in your role
as TAC speaker, appear to contradict the specific resolutions that
TAC wants to propose to ARDC. The specific example being whether 44.0/9
should be able to communicate with 44.128/10.
I'd like to resolve this obvious misunderstanding by looking at primary sources.
So far, we are not working on any such response, and all TAC members agree with the
responses provided by me.
They are inconsistent...
We only want to preserve some IP space that can
be used for ham-to-ham communication. How they communicate is up to them. If they want to
use radio-only, they can get an allocation off this space and build a radio-only network.
If they want to communicate with carrier pigeons only, they can get an allocation and
build a carrier-pigeon-only network. If they are okay with using tunnels *through* the
Internet, then they can do that.
OK, having established that, you would agree that any references to a
"radio-only networks" in the PDF should be reworded. We just want
to make sure that we have some space reserved for this type of communication. Going back
to the RF analogy, ALL amateur radio space is for ham-to-ham only. In our proposal SOME of
the space is for ham-to-ham, and the rest is for
ham-to-Internet-and-possibly-hopefully-some-hams-too. If anything, and we go by RF
standards, advertisement of 44/8 should be prohibited on the Internet as non-hams can
reach you.
Each packet bears a source and a destination IP. If we agree
that any packet originating from IP from either 44/9 or 44.128/10
are licensed ham radio amateurs (as stipulated by current ARDC AUP). If they are destined to a 44.destination via a radio
link, it can be
assumed they have sufficient authority to be passed on as ham-ham
communications.
What happens if they do not have sufficient authority to pass? Where will this be
reflected and how can users pick an alternative path?
If they are destined to non-44, or originate from
non-44
they *may* still be allowed as third-party communication, but this will
be jurisdiction-specific.
I guess this is up to the operators and the local laws they have for each link, as you
mention. However, how is it signaled and to whom that packets can or cannot pass from a
link so if they’ll be dropped I can avoid sending them and pick a different path. Can I as
an end-user pick a different path?
It seems to me that some paths on this global BGP network will only pass some forms of
traffic based on the source and the destination. Accounting for the destination is easy:
if no traffic should go there, remove / filter out the route. But what happens when you
want to filter by source a few hops down the network? How does my router know (and
everything else in the network) which *source* decision is also made? What happens with
combinations of (src, dst) and how will they be reflected on BGP? Do you plan to introduce
BGP Extended Communities that will have a global meaning and all users should alter their
path selection algorithm by using these and applying appropriate terms and rules in their
BGP peerings?
The problem here is how do I know which path I need to follow (and since I only control
the first hop, the path that everyone must route with, through 44/8) that will get me to a
given destination within 44/8? If I see 20 paths, but only 2 of them will forward my
traffic based on my use case (src, dst) how can I tell which ones are that, and how can I
affect the routing from my node to this one in order to ensure packet delivery? Do I just
have to rely that BGP will hopefully pick the path that doesn’t drop my packets instead of
the ones that does?
Will every router in the entire network apply source-based policy routing? How will this
be signaled? Will every have to manually maintain tables of “if src is x, use table y”?
Most routers today can do this as statically configured firewall rules + additional
routing tables. Is there a way to dynamically propagate this information to the entire
network? Is it safe to allow people to control your routing policy? Who can modify your
firewall rules to point to the “no radio” table?
Any station in the business of forwarding packets (ie.
not your "end
user") can and must make the decision whether he actually forwards those
packets. Therefore anyone implementing a ham-to-ham-only policy can do
so within his network, *without placing any undue burden on other
people* to do the same or leave.
You can’t just advertise routes on the single BGP control plane and then drop packets
based on firewall rules. If you do this, any connection becomes unpredictable, and whether
you get or not to your destination is a hit or miss, even if there are multiple valid
paths to this network. If we use simple BGP then you only control the routes you advertise
to your neighbors, and the AS Path. You can’t tell them “this route is available, but only
if you are from 44.154/16, and if not, it doesn’t exist”. It’s all or nothing. If you
advertise it, then for a correctly functioning network you must forward to this
destination all traffic you receive for it, unconditionally.
If for convenience (and thats strictly convenience)
several networks
want to partake on such a common strategy, it is *their* task to find
some unused IP range and renumber there. Precedent here is the original
HAMNET, which did this because it could not or did not want to use the
old 44.130 german network.
As you can see above, creating a single BGP control plane across the entire network, that
works with every use case people want can be a problem. Not only does it require advanced
BGP knowledge and configuration, but it may not even be possible with most common
hardware. For example MikroTik is known not to support Extended Communities in the first
place.
This is partly
true: there is not a “single 44.128/10” but anyone can create their own network within
this space. However, if some of these networks don’t want to talk to everything else, then
this is working as intended, and they are by design not reachable. We hope that most of
the networks there would want to be interconnected and they can do so through radio links,
VPNs, Internet tunnels, satellites, or any other technology they see fit. One of them (but
not a mandatory or the only one) will be the ARDC-provided PoPs. They will act as one of
the many methods people could use to make sure that these networks talk to each other.
Now if one such network does not want to take part in this, then what do
you do ? Networking is a mutual understanding. Apparently therer seem
some difficulties between the dutch network and HAMNET. As long as
they dont get resolved, there will be no traffic exchange. meaning I as
an end user would have to have some sort of separate routing. This is
independent of which IP space is used. This is an
important distinction and something we still allow: the ONLY thing we say is that
44.128/10 MUST NOT be reachable from a non-44.128/10 address. By definition, that means
that no part of this space may appear on the Internet. Of course, the exception here is
that ARDC will still advertise it to combat hijacking, etc. but will DROP ALL traffic sent
to it. It will be dropped at the edge and not forwarded anywhere.
You are making this decision on top and over that of the people who
built and have run their respective networks for 25+ years.
You want to build such a network ? Fine. You find some unused space
and build it, or convince some existing ones to adopt that policy.
You need to learn sandbox etiquette. I appreciate you want to build a
bigger castle, but if you do that by trampling over the small ones built
by the other kids, you will be the bully. Nobody wants to play with
bullies.
You also destroy the other ones completely unnecessarily, since your
isolationist approach can be solved by an ACL. Ultimately it will be
anyhow because ARDC will want to announce the space to prevent
hijacking.
And telling them that they can move to another sandbox isnt cutting it
either. We can’t be
certain, I agree with what you say. What we can do is make it much better than it is right
now. We think that even if we can’t provide a perfect solution, we should still make steps
to improve the situation.
If you are in this 44.128/10 network, it’s extremely less likely for non-hams to reach
you. If you are connected to the Internet, and you advertise your space with BGP, it is in
fact *guaranteed* for non-ham traffic to reach you.
I think your fundamental problem is that you confuse network nodes,
which are identified by IPs, and vertices, or links. The legal mandates
pertain to the links, not to the nodes. it is the responsibility of a
licensed ham to make sure only suitable stuff gets sent over a radio
link. There is no legal mandate not to communicate, using the radio ID,
over a non amateurradio link. You could
argue that you could deploy ACLs or Firewalls, or any measure like that, and this would
help you only accept 44/8 traffic. But this is still worse: packets on the Internet today
can be spoofed. A non radio amateur could send a spoofed packet appearing from 44/8 from a
commercial ISP, and it would get through your firewall and possibly over your RF links
just fine.
That was true more in the past than now due to reverse-path protection
and so on. It does not make a difference - you could tune a transmitter
to any frequency all the time. If you forward such packets, you have to
take certain responsibilities. Mind you, youre not an end user then.
You would employ things like route verification, checking if the packet
arrived via the correct tunnel etc. pp.
If you are not prepared to handle this, you should not be running a
gateway. Moreover, if two 44/8 networks connect with
intermediate hops over the Internet, e.g.:
Yes, exactly, the ACL would drop these packets, but how do nodes #1 and #6 know that this
path drops certain packets? How do they know which packets are dropped? Do they have to
manually set up routes to an alternative path to route around these links if they want to
send some types of packets? Will they maintain a separate table of static routes by hand?
How often will they update it? What if the policy of a link changes and suddenly more
packets are dropped than before? Will they have to notice packet loss and take action to
route around this region of the network?
1. 44.1.2.3
2. 44.3.2.1
3. 192.0.2.15
4. 193.5.16.50
5. 44.4.6.7
6. 44.7.6.5
(Which I assume is what you want to do if you want to be on the Internet BGP and block
all incoming traffic from non-44/8 hosts)
Then hosts #3 and #4 that are non-hams can easily modify any and all traffic and cause a
transmission in a ham band of packets that are not from a ham. This is much more common
than you can imagine, and not always done maliciously. If I am node #1 and I do a
traceroute to node #6, due to the way the traceroute utility works, nodes #3 and #4 will
generate a new packet themselves (TTL Exceeded) and send it back to #2, who will forward
it over a ham link to #1. Node #2 probably did something illegal, as they transmitted a
packet that was not generated by a radio amateur (it’s a non-manned station / router of
Cogent / Telia / Hurricane Electric, …) over a ham band.
Yes. And an ACL would block those packets, and I'd see * * * in the
traceroute. That is not unusual. Though they may not be illegal in all
jurisdictions with more liberal third party rules. Now for the
use case where you want to be on the Internet with 44.0/10 addresses, but don’t want to
drop all incoming traffic that is not sourced from 44/8, then it is normal to expect that
all these port scans that people do will reach all IPv4 addresses in your network. Since
you know this is going to happen, you cannot use any radio link in a non-ham band, as it
is guaranteed that these stations will transmit a message over an amateur radio band that
is not from a licensed user. Even with a stateful firewall that only allows outgoing
connections, all responses you get from Facebook, Netflix, Altavista, etc. will be from a
non-radio-amateur and you will be transmitting them over a band illegally.
They *might* qualify as valid third party traffic. Someone sending an
to a loved one, for example when only ham radio links are available. You
can not know. The operator of the radio must make that decision.
The control knob for such things is called an access control list. Thats
a different concept than that of a route. If this law
applies to you, then you cannot use the ham bands to “communicate with the open
Internet”.
I think that we both agree on that.
I can not use an amateur radio link as part of
that communication. I can
still identify as a ham radio operator. Now moving to
the case of “communicating through the Internet”. Let’s examine that.
If the network does not appear via BGP on the Internet, then everyone has to set up
tunnels to interconnect everything. You can’t just send traffic to a commercial ISP and
have it delivered. It will be dropped by ARDC. This guarantees that the traceroute problem
I described earlier (and any other similar case) won’t happen. The only routers and
equipment that participates in this network is (or must be) owned and operated legally by
hams. You don’t rely on Internet infra and expect any guaranteed. This means that it is
almost guaranteed to not break the law or at least it is much much much much much much
more certain that such a system would not break the law than talking transparently
“through the Internet”.
You can easily build such infrastructure. In fact it has been done that
way for all the 25+ years I am in this game. There are a
lot of people that would have to renumber e.g. 200 hosts that we saw earlier, or possibly
more. But I think this is a testament that the current network is not easy to use: you may
have 20 users, but a single person was managing it and has to renumber everyone. If anyone
participating was an expect, they would simply have to renumber their own hosts, that
would be less than 200 for a typical setup.
I do not follow this logic.
Your statement that one person renumbering 200 hosts is more work than
20 persons renumbering 10 each. That is certainly not true, in fact it
is the opposite, youd have to coordinate those 200 people, and you would
have to assume these 200 people are fully competent -- that is the
opposite of your assumption in the first place... And the
current users force their world view upon future users and also a large part of this
network. I don’t think that it’s about who wins and who gets forced to submission. The TAC
tries to create space for both use cases so we all win, and we are all happy. Like any
rule in any civilized society, some people will have to make some sacrifices to co-exist.
They will have to understand why they need to do this, and then they will have to give the
others space to grow and have fun as well.
Yes, and their demonstrated contributions over decades give them the
right to do that. And no, this is not a win-win solution. Youre taking
some peoples toys away and force them to expend work. .
If people voluntarily *agree* to move and make this sacrifice, that is
one thing. But this appears not to be the case here. I am aware
that the bands are different for different regions of the world, but I do not want to make
the example complicated. I thought that it was enough for people to understand my point,
even if it’s region-specific, and that you can easily replace those numbers with your
local ones. I did not see a benefit in being extremely precise in something that is not
related to the point I try to make when the audience can probably understand it.
If you did not get my point because of the fact that two digits are off, then I can
rephrase the sentence with these digits as they stand around the world.
Now if you
changed those digits, we would now have a transceiver
transmitting on 146..148 in Region 1, which in some jurisdictions can be
illegal.
Secondly,
why would I not be allowed to listen to that amateur radio
repeater using my commercial all-band radio receiver?
First of all, it may be illegal in some areas of the world, e.g. I think the U.K. or
Greece. But I think that’s not your point ;) 
31 Jul
31 Jul
10:42 a.m.
New subject: A new era of IPv4 Allocations
Antonios,
Why are you making this so difficult? No need for source routing, no need to drop routes
in the backbone bgp table, no need for extended bgp communities, hell even no need for
communities at all if you don't want to use communities..
just use firewall rules if you do not want someone to access your network/content like in
all best practices?
It should be up to the operator if he/she wants to allow certain traffic or not.
If someone want to direct peer with another ham, let them and let the hams decide which
content they want to share with each other. They have been doing so for years with the
IPIP mess so they know how to add an iptables firewall rule/firewall rule on their
router/Mikrotik whatever they use
A simple ACL is easy on paper AND in reality. How do you think everyone does it now on the
internet? I have 3 transit providers and still my firewall works like it should. My
customers have multiple transit routes and still their firewall works as intended.
And yes, we really do want a backbone with at least a few pops, maybe a pop per region,
maybe a pop per coordinator, if a coordinator want to build-out a pop, why not? But, all
pops should adhere to the same rules and setup, we can deviate with possible vpn methods
for accessing the pop and the rest of the network, but that should be standardized as much
as possible.
Let me stress again the importance of reading up on the 44NGN list, it’s all been
discussed there with all valid ways of building out pops and connectivity. As a senior
network engineer I can tell you that it’s not as hard as you make it out to be.
73
Ruben ON3RVH
-----Original Message-----
From: 44Net <44net-bounces+on3rvh=on3rvh.be(a)mailman.ampr.org> On Behalf Of Antonios
Chariton (daknob) via 44Net
Sent: Friday, July 30, 2021 20:01
To: 44Net general discussion <44net(a)mailman.ampr.org>
Cc: Antonios Chariton (daknob) <daknob(a)daknob.net>
Subject: Re: [44net] A new era of IPv4 Allocations
Dear Mario,
Indeed, yes. This is up to the operators of these services. We do not want to interfere
with what they do and how.
To be clear: 44.0/9 *cannot* directly to 44.128/10 and 44.128/10 *cannot* talk directly to
44.0/9 under our proposal. I believe that this is what we include in the proposal text as
well. For all intents and purposes, we treat 44.0/9 as any other IPv4 address on the
Internet when we talk to it from the Intranet. The same way a 10/8 host cannot talk to
1.1.1.1 a 44.128/10 address cannot talk to 44.0.0.1. The operators of the networks will
have to use NAT (like they do today), or they can also request a 44.0/10 space and do a
1:1 mapping of hosts, or anything else.
- You should never receive a packet in your 44.128/10 address from a non-44.128/10
address
- You should never receive a packet in your non-44.128/10 network from a 44.128/10
address
Yes, this is something we can do, and it’s a good idea.
We agree that this is what should happen. However, for any Internet-connected network,
there’s no guarantee it will always be true.
This is true, and a very common problem in community networks that I know of. People at
one point have a diverging vision and don’t agree anymore and then they stop exchanging
traffic. It is unfortunate to see in a network that’s supposed to connect people and it
can really slow down deployment efforts, but it can always happen. We even see parts of
that in the Internet too. I don’t think there’s anything ARDC can do to prevent this. The
only thing is to make sure there’s enough room for everyone and interconnecting is easy.
If some people want to be isolated or not talk to specific people, then I guess that’s
that..
This proposal aims to have ARDC continuously advertise 44.128/10 on the Internet, but as a
whole block to which all traffic is dropped and not forwarded. We don’t want to change
that. We have to keep advertising the space, for many reasons. Hopefully if we could get
RPKI we could publish a ROA that would cause people validating to drop all announcements
smaller than /10 in this space as well, so they are automatically discarded by filtering
ISPs.
As I have mentioned above, this problem is not simply solved by an ACL. It’s not a
firewall rule to drop all traffic and that’s it. If all want to be on the same routing
plane without causing massive packet loss and unreachable destinations, we have to find a
way to inform everyone else of our policy. And BGP cannot currently do this, especially
with the limitations of vendors like Ubiquiti and MikroTik. An ACL could solve this
problem if we had a very centralized network where everyone connects to the PoPs and it’s
mandatory, and interconnections between end users or networks is not allowed. If 44 Net
looked like this then applying any type of police would be much easier. But if you allow
for any use case, like hundreds of nodes connecting to each other, and only talk to the
PoPs from 3 points on the Internet, then things can get more complicated. “Simple ACL” is
easy on paper, but in reality it’s much more complicated than that.
Of course, I agree that there isn’t any mandate that I know of. However, all the policies
of each and every individual link in every single part of the network must be immediately
available to every single (at least “backbone”) router and must be used in the routing
decision making. If people have links visible through BGP that silently drop traffic this
will cause a lot of practical issues with unreachability like many we see in the network
today. And the people, no matter how much they want to fix them, won’t be able to.
Unfortunately mechanisms like uRPF that you mention only work to protect others from your
network. If anything is more than a hop away, especially in a scenario where a gateway has
a single transit provider / default route, then they can’t do anything. If you have a
default route on your Vultr VPS (or even a full table, doesn’t matter), you see the entire
Internet behind “eth0”. So everything coming that way will make it into your network just
fine. The only thing that uRPF will do is to not allow packets from your own network to
come via the Internet. Which you may have to allow eventually if e.g. your network is
connected to the Internet via 3 points, and you want to go over the Internet in the case
of a net split. So a lot of networks will end up disabling it (or choosing a more relaxed
version, or technically not enabling it as it’s off by default) in the first place because
it breaks legitimate use cases.
I would personally agree that people running more core parts of the network should have
more networking knowledge, and that would be expected, but I wouldn’t expect perfect,
state-of-the-art operational expertise and equipment support. I would still expect to see
operators like these to simply configure BGP and a few filters. And that’s fine. We’ve
learned from the Internet that any system that relies on everyone adopting it and playing
fair is far less likely to be useful.
If the network was more centralized and every 44 island required the PoPs to connect to
each other, and everything had to go through them, then you could argue that the ARDC
staff maintaining it would have to follow state-of-the-art procedures and since it’s only
a few points we could also have capable equipment, etc. So this becomes kinda better. But
still, this means a centralized network. Do we really want that?
Yes, and that’s exactly the problem! The control plane that BGP sees is different than the
data plane where the ACL drops the packets at. People using BGP see a valid path, but then
without telling anyone the operator(s) of the link drop the packets. There’s no way for
BGP to convey what firewall rules each link has attached to it and then take it into
account during path selection based on packet values. And there’s probably a good reason
for that, as you can’t accelerate any of that on hardware I imagine.
Yes, I agree.
Yes, this can easily be built. But isn’t building it easier if we guarantee that 44.128/10
does not appear on the Internet and should only be routed either on top of the Internet
(tunnels, VPNs, …) or other means (radio) ?
What I’m trying to say is that if every user of the network was competent and could easily
do such changes (like many people have claimed in this thread), then we wouldn’t have
cases where a single person is managing the network of 20 others. Everyone would probably
manage their own network. So it’s a point to make towards the fact that not even the
existing users are or want to be involved in all this routing.
We don’t really know to be honest as only a few people have participated in this
conversation out of the thousands that use the network. So our margin of error here is 99%
;)
We’re also not taking away anyone’s toys, if anything, we give them more.
I respect the people that have been doing this for decades, but I also understand that we
need to leave a lot of room for people that do this one decade, or 5 years, or 1 year, or
0 to grow as well and do what they want to achieve. Just because some people started this
25 years does not mean that this thing we have shouldn’t evolve to allow for more and more
users to participate.
I am not sure about that, but see, thats the thing. The decision of
this being illegal can not be made globally (and your intranet is
consisting of the current allocations for allmost all of the world)
but it needs to be made on a local / country basis, as it has been in the past.
There are certainly arguments for and against country-based vs use-case-based allocations.
I feel like if we do country-based allocations, as is evident from my e-mail above, we
will have a lot of trouble finding a way to represent the ACLs of each link on BGP (or any
other mechanism that can reconfigure all network routers). If this is not possible, then
we’ll need to have people maintain complex routing tables to go around entire countries
(if they even can) just to be able to deliver some traffic, because the BGP Best Path
drops it.
If we go with a system based on use case, then this is not needed, as people can easily
hardcode the two network policies that exist and easily route any way they want based on
them. This list of links is easy to aggregate: any link in 44.128/10 has policy X, and
each link in 44.0/9 has policy(ies?) Y.
Antonis
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
On 30 Jul 2021, at 17:11, Mario Lorenz
<ml(a)vdazone.org> wrote:
Dear Antonios,
Am 30. Jul 2021, um 15:32:26 schrieb Antonios Chariton (daknob):
The first reference of people is hams, the second is non-hams. So this sentence becomes:
That’s what hams want to do though. Hams want to use an amateur radio resource (44.0/10)
to talk to non-hams on the Internet (that are not licensed).
We do not want to restrict people on 44.0/10 and we want them to be able to speak to
anyone on the Internet. Of course, ARDC here may have some policies against e.g. spam,
piracy, etc. but that’s not relevant. They are responsible of figuring out though if their
communication is legal.
The proposal simply puts all the people that want to talk to the Internet in 44.0/10 and
leaves all the people that don’t want to talk to the Internet with a 44 address to
44.128/10.
That’s what people want to do though. They want
to use an amateur radio resource (44.0/10) to talk to people on the Internet that are not
licensed. Normally in RF you use a ham radio frequency to only talk to radio amateurs. In
the IP world, the src and dst can be different. People want to use an amateur radio
resource to talk to a commercial resource, and a commercial resource to talk to a ham
radio resource.
Please define "people". Are these radio amateurs ? If so, why do you
want to restrict communication with them ? What they have to say can
go over amateur radio airwaves. If not, why are they in 44.(0). in the
first place ? Here's the thing: If there are "people" that are not
radio amateurs but want IP space for non amateur communication, they
can go and get it somewhere else, and pay for the privilege.
If that needs any TAC resolution to propose at ARDC, I think you would
find much support on this list. These two
networks can interconnect. EchoLink now bridges the Internet with the amateur radio
spectrum. But we don’t use IP addresses on EchoLink, we use our callsigns, transmitted
over IP packets. And similarly, when we do IP / Internet connectivity over amateur radio
spectrum, we use IP addresses on top of callsigns.
In which case you need to differentiate between amateur radio and
third party traffic. We have
collected minutes of meetings that we did as the TAC, and they capture a part of the total
work that has been put through this. However, at this time, they are not public. Is there
something specific that you’re looking for? I could help provide more information on that.
As discussed before, the pdf statement contains contradictory, not
sufficiently specific language. Your explanations, as given in your
role as TAC speaker, appear to contradict the specific resolutions
that TAC wants to propose to ARDC. The specific example being whether
44.0/9 should be able to communicate with 44.128/10.
I'd like to resolve this obvious misunderstanding by looking at primary sources.
So far, we are not working on any such response, and all TAC members agree with the
responses provided by me.
They are inconsistent...
We only want to preserve some IP space that can
be used for ham-to-ham communication. How they communicate is up to them. If they want to
use radio-only, they can get an allocation off this space and build a radio-only network.
If they want to communicate with carrier pigeons only, they can get an allocation and
build a carrier-pigeon-only network. If they are okay with using tunnels *through* the
Internet, then they can do that.
OK, having established that, you would agree that any references to a
"radio-only networks" in the PDF should be reworded. We just want
to make sure that we have some space reserved for this type of communication. Going back
to the RF analogy, ALL amateur radio space is for ham-to-ham only. In our proposal SOME of
the space is for ham-to-ham, and the rest is for
ham-to-Internet-and-possibly-hopefully-some-hams-too. If anything, and we go by RF
standards, advertisement of 44/8 should be prohibited on the Internet as non-hams can
reach you.
Each packet bears a source and a destination IP. If we agree that any
packet originating from IP from either 44/9 or 44.128/10 are licensed
ham radio amateurs (as stipulated by current ARDC AUP). If they are destined to a 44.destination via a radio
link, it can be
assumed they have sufficient authority to be passed on as ham-ham
communications.
What happens if they do not have sufficient authority to pass? Where will this be
reflected and how can users pick an alternative path?
If they are destined to non-44, or originate from
non-44 they *may*
still be allowed as third-party communication, but this will be
jurisdiction-specific.
I guess this is up to the operators and the local laws they have for each link, as you
mention. However, how is it signaled and to whom that packets can or cannot pass from a
link so if they’ll be dropped I can avoid sending them and pick a different path. Can I as
an end-user pick a different path?
It seems to me that some paths on this global BGP network will only pass some forms of
traffic based on the source and the destination. Accounting for the destination is easy:
if no traffic should go there, remove / filter out the route. But what happens when you
want to filter by source a few hops down the network? How does my router know (and
everything else in the network) which *source* decision is also made? What happens with
combinations of (src, dst) and how will they be reflected on BGP? Do you plan to introduce
BGP Extended Communities that will have a global meaning and all users should alter their
path selection algorithm by using these and applying appropriate terms and rules in their
BGP peerings?
The problem here is how do I know which path I need to follow (and since I only control
the first hop, the path that everyone must route with, through 44/8) that will get me to a
given destination within 44/8? If I see 20 paths, but only 2 of them will forward my
traffic based on my use case (src, dst) how can I tell which ones are that, and how can I
affect the routing from my node to this one in order to ensure packet delivery? Do I just
have to rely that BGP will hopefully pick the path that doesn’t drop my packets instead of
the ones that does?
Will every router in the entire network apply source-based policy routing? How will this
be signaled? Will every have to manually maintain tables of “if src is x, use table y”?
Most routers today can do this as statically configured firewall rules + additional
routing tables. Is there a way to dynamically propagate this information to the entire
network? Is it safe to allow people to control your routing policy? Who can modify your
firewall rules to point to the “no radio” table?
Any station in the business of forwarding packets (ie.
not your "end
user") can and must make the decision whether he actually forwards
those packets. Therefore anyone implementing a ham-to-ham-only policy
can do so within his network, *without placing any undue burden on
other
people* to do the same or leave.
You can’t just advertise routes on the single BGP control plane and then drop packets
based on firewall rules. If you do this, any connection becomes unpredictable, and whether
you get or not to your destination is a hit or miss, even if there are multiple valid
paths to this network. If we use simple BGP then you only control the routes you advertise
to your neighbors, and the AS Path. You can’t tell them “this route is available, but only
if you are from 44.154/16, and if not, it doesn’t exist”. It’s all or nothing. If you
advertise it, then for a correctly functioning network you must forward to this
destination all traffic you receive for it, unconditionally.
If for convenience (and thats strictly convenience)
several networks
want to partake on such a common strategy, it is *their* task to find
some unused IP range and renumber there. Precedent here is the
original HAMNET, which did this because it could not or did not want
to use the old 44.130 german network.
As you can see above, creating a single BGP control plane across the entire network, that
works with every use case people want can be a problem. Not only does it require advanced
BGP knowledge and configuration, but it may not even be possible with most common
hardware. For example MikroTik is known not to support Extended Communities in the first
place.
This is partly
true: there is not a “single 44.128/10” but anyone can create their own network within
this space. However, if some of these networks don’t want to talk to everything else, then
this is working as intended, and they are by design not reachable. We hope that most of
the networks there would want to be interconnected and they can do so through radio links,
VPNs, Internet tunnels, satellites, or any other technology they see fit. One of them (but
not a mandatory or the only one) will be the ARDC-provided PoPs. They will act as one of
the many methods people could use to make sure that these networks talk to each other.
Now if one such network does not want to take part in this, then what
do you do ? Networking is a mutual understanding. Apparently therer
seem some difficulties between the dutch network and HAMNET. As long
as they dont get resolved, there will be no traffic exchange. meaning
I as an end user would have to have some sort of separate routing.
This is independent of which IP space is used. This is an
important distinction and something we still allow: the ONLY thing we say is that
44.128/10 MUST NOT be reachable from a non-44.128/10 address. By definition, that means
that no part of this space may appear on the Internet. Of course, the exception here is
that ARDC will still advertise it to combat hijacking, etc. but will DROP ALL traffic sent
to it. It will be dropped at the edge and not forwarded anywhere.
You are making this decision on top and over that of the people who
built and have run their respective networks for 25+ years.
You want to build such a network ? Fine. You find some unused space
and build it, or convince some existing ones to adopt that policy.
You need to learn sandbox etiquette. I appreciate you want to build a
bigger castle, but if you do that by trampling over the small ones
built by the other kids, you will be the bully. Nobody wants to play
with bullies.
You also destroy the other ones completely unnecessarily, since your
isolationist approach can be solved by an ACL. Ultimately it will be
anyhow because ARDC will want to announce the space to prevent
hijacking.
And telling them that they can move to another sandbox isnt cutting it
either. We can’t be
certain, I agree with what you say. What we can do is make it much better than it is right
now. We think that even if we can’t provide a perfect solution, we should still make steps
to improve the situation.
If you are in this 44.128/10 network, it’s extremely less likely for non-hams to reach
you. If you are connected to the Internet, and you advertise your space with BGP, it is in
fact *guaranteed* for non-ham traffic to reach you.
I think your fundamental problem is that you confuse network nodes,
which are identified by IPs, and vertices, or links. The legal
mandates pertain to the links, not to the nodes. it is the
responsibility of a licensed ham to make sure only suitable stuff gets
sent over a radio link. There is no legal mandate not to communicate,
using the radio ID, over a non amateurradio link. You could
argue that you could deploy ACLs or Firewalls, or any measure like that, and this would
help you only accept 44/8 traffic. But this is still worse: packets on the Internet today
can be spoofed. A non radio amateur could send a spoofed packet appearing from 44/8 from a
commercial ISP, and it would get through your firewall and possibly over your RF links
just fine.
That was true more in the past than now due to reverse-path protection
and so on. It does not make a difference - you could tune a
transmitter to any frequency all the time. If you forward such
packets, you have to take certain responsibilities. Mind you, youre not an end user
then.
You would employ things like route verification, checking if the
packet arrived via the correct tunnel etc. pp.
If you are not prepared to handle this, you should not be running a
gateway. Moreover, if two 44/8 networks connect with
intermediate hops over the Internet, e.g.:
Yes, exactly, the ACL would drop these packets, but how do nodes #1 and #6 know that this
path drops certain packets? How do they know which packets are dropped? Do they have to
manually set up routes to an alternative path to route around these links if they want to
send some types of packets? Will they maintain a separate table of static routes by hand?
How often will they update it? What if the policy of a link changes and suddenly more
packets are dropped than before? Will they have to notice packet loss and take action to
route around this region of the network?
1. 44.1.2.3
2. 44.3.2.1
3. 192.0.2.15
4. 193.5.16.50
5. 44.4.6.7
6. 44.7.6.5
(Which I assume is what you want to do if you want to be on the
Internet BGP and block all incoming traffic from non-44/8 hosts)
Then hosts #3 and #4 that are non-hams can easily modify any and all traffic and cause a
transmission in a ham band of packets that are not from a ham. This is much more common
than you can imagine, and not always done maliciously. If I am node #1 and I do a
traceroute to node #6, due to the way the traceroute utility works, nodes #3 and #4 will
generate a new packet themselves (TTL Exceeded) and send it back to #2, who will forward
it over a ham link to #1. Node #2 probably did something illegal, as they transmitted a
packet that was not generated by a radio amateur (it’s a non-manned station / router of
Cogent / Telia / Hurricane Electric, …) over a ham band.
Yes. And an ACL would block those packets, and I'd see * * * in the
traceroute. That is not unusual. Though they may not be illegal in all
jurisdictions with more liberal third party rules. Now for the
use case where you want to be on the Internet with 44.0/10 addresses, but don’t want to
drop all incoming traffic that is not sourced from 44/8, then it is normal to expect that
all these port scans that people do will reach all IPv4 addresses in your network. Since
you know this is going to happen, you cannot use any radio link in a non-ham band, as it
is guaranteed that these stations will transmit a message over an amateur radio band that
is not from a licensed user. Even with a stateful firewall that only allows outgoing
connections, all responses you get from Facebook, Netflix, Altavista, etc. will be from a
non-radio-amateur and you will be transmitting them over a band illegally.
They *might* qualify as valid third party traffic. Someone sending an
to a loved one, for example when only ham radio links are available.
You can not know. The operator of the radio must make that decision.
The control knob for such things is called an access control list.
Thats a different concept than that of a route. If this law
applies to you, then you cannot use the ham bands to “communicate with the open
Internet”.
I think that we both agree on that.
I can not use an amateur radio link as part of
that communication. I
can still identify as a ham radio operator. Now moving to
the case of “communicating through the Internet”. Let’s examine that.
If the network does not appear via BGP on the Internet, then everyone has to set up
tunnels to interconnect everything. You can’t just send traffic to a commercial ISP and
have it delivered. It will be dropped by ARDC. This guarantees that the traceroute problem
I described earlier (and any other similar case) won’t happen. The only routers and
equipment that participates in this network is (or must be) owned and operated legally by
hams. You don’t rely on Internet infra and expect any guaranteed. This means that it is
almost guaranteed to not break the law or at least it is much much much much much much
more certain that such a system would not break the law than talking transparently
“through the Internet”.
You can easily build such infrastructure. In fact it has been done
that way for all the 25+ years I am in this game. There are a
lot of people that would have to renumber e.g. 200 hosts that we saw earlier, or possibly
more. But I think this is a testament that the current network is not easy to use: you may
have 20 users, but a single person was managing it and has to renumber everyone. If anyone
participating was an expect, they would simply have to renumber their own hosts, that
would be less than 200 for a typical setup.
I do not follow this logic.
Your statement that one person renumbering 200 hosts is more work than
20 persons renumbering 10 each. That is certainly not true, in fact it
is the opposite, youd have to coordinate those 200 people, and you
would have to assume these 200 people are fully competent -- that is
the opposite of your assumption in the first place... And the
current users force their world view upon future users and also a large part of this
network. I don’t think that it’s about who wins and who gets forced to submission. The TAC
tries to create space for both use cases so we all win, and we are all happy. Like any
rule in any civilized society, some people will have to make some sacrifices to co-exist.
They will have to understand why they need to do this, and then they will have to give the
others space to grow and have fun as well.
Yes, and their demonstrated contributions over decades give them the
right to do that. And no, this is not a win-win solution. Youre taking
some peoples toys away and force them to expend work. .
If people voluntarily *agree* to move and make this sacrifice, that is
one thing. But this appears not to be the case here. I am aware
that the bands are different for different regions of the world, but I do not want to make
the example complicated. I thought that it was enough for people to understand my point,
even if it’s region-specific, and that you can easily replace those numbers with your
local ones. I did not see a benefit in being extremely precise in something that is not
related to the point I try to make when the audience can probably understand it.
If you did not get my point because of the fact that two digits are off, then I can
rephrase the sentence with these digits as they stand around the world.
Now if you
changed those digits, we would now have a transceiver
transmitting on 146..148 in Region 1, which in some jurisdictions can
be illegal.
Secondly,
why would I not be allowed to listen to that amateur radio
repeater using my commercial all-band radio receiver?
First of all, it may be illegal in some areas of the world, e.g. I
think the U.K. or Greece. But I think that’s not your point ;) 
10:34 a.m.
New subject: A new era of IPv4 Allocations
On Sat, 31 Jul 2021, Ruben ON3RVH via 44Net wrote:
Let me stress again the importance of reading up on
the 44NGN
list,
I'm sure people would *love* to read up on the 44ngn discussions.
Please provide a working link so that everyone can read along.
-Paul
10:13 p.m.
New subject: A new era of IPv4 Allocations
Dear Antonios,
Am 30. Jul 2021, um 20:00:47 schrieb Antonios Chariton (daknob):
It is difficult to protect from malice.
The packet will be
dropped, possibly with an ICMP
administratively-prohibited or similar packet.
You see, here is where you can improve.
The first reference of people is hams, the second is non-hams. So this sentence becomes:
That’s what hams want to do though. Hams want to use an amateur radio resource (44.0/10)
to talk to non-hams on the Internet (that are not licensed).
We do not want to restrict people on 44.0/10 and we want them to be able to speak to
anyone on the Internet. Of course, ARDC here may have some policies against e.g. spam,
piracy, etc. but that’s not relevant. They are responsible of figuring out though if their
communication is legal.
Good. And we are in agreement that is the status quo for both 44.0/9 and
44.128/10 at the moment - that all of them are hams, and want to
communicate amateur radio related topics (as required by the current
ARDC TOS) ?
The proposal simply puts all the people that want to
talk to the Internet in 44.0/10 and leaves all the people that don’t want to talk to the
Internet with a 44 address to 44.128/10.
This would be perfectly valid if people were to make the choice over
their IP now. It is not for those who have made their allocations some
30+ years ago. That is why "grandfathering" is such an important concept.
It recognizes the value of the work that other people have done.
It keeps the peace.
It is this concept we still get to keep 44 in the first place.
If you changed your proposal such that no _new_ allocations/direct BGP
shall be made in 44.128/10, everyone would likely somewhat more relaxed.
That is not to say that such a restriction is necessary.
- You should never receive a packet in your 44.128/10 address from a non-44.128/10
address
- You should never receive a packet in your non-44.128/10 network from a 44.128/10
address
That can be enforced, for each single network, using ACLs.
>> We just want to make sure that we have some
space reserved for this type of communication. Going back to the RF analogy, ALL amateur
radio space is for ham-to-ham only. In our proposal SOME of the space is for ham-to-ham,
and the rest is for ham-to-Internet-and-possibly-hopefully-some-hams-too. If anything, and
we go by RF standards, advertisement of 44/8 should be prohibited on the Internet as
non-hams can reach you.
Such a space could be useful. If you had some unallocated space, that
would be no problem.
Each packet bears a source and a destination IP. If we agree
that any packet originating from IP from either 44/9 or 44.128/10
are licensed ham radio amateurs (as stipulated by current ARDC AUP).
We agree that this is what should happen. However, for any Internet-connected network,
there’s no guarantee it will always be true. If they are destined to a 44.destination via a
radio link, it can be
assumed they have sufficient authority to be passed on as ham-ham
communications.
What happens if they do not have sufficient authority to pass? Where will this be reflected and how can users pick an
alternative path?
Nowhere. Users could pick an alternative path using source
routing.
This has however been deprecated for the very security reason you
illustrate - it potentially allows to route around firewalls. As such,
there are no end user applications allowing this option to be even set.
I guess this is up to the operators and the local laws
they have for each link, as you mention. However, how is it signaled and to whom that
packets can or cannot pass from a link so if they’ll be dropped I can avoid sending them
and pick a different path. Can I as an end-user pick a different path?
Once we have a sound definition for "end-user", I possibly can answer that
question. Sit back and reread the abstract of your proposal to see
why.
It seems to me that some paths on this global BGP
network will only pass some forms of traffic based on the source and the destination.
Accounting for the destination is easy: if no traffic should go there, remove / filter out
the route. But what happens when you want to filter by source a few hops down the network?
How does my router know (and everything else in the network) which *source* decision is
also made? What happens with combinations of (src, dst) and how will they be reflected on
BGP? Do you plan to introduce BGP Extended Communities that will have a global meaning and
all users should alter their path selection algorithm by using these and applying
appropriate terms and rules in their BGP peerings?
Are you discussing the Internet BGP side ?
The problem here is how do I know which path I need to
follow (and since I only control the first hop, the path that everyone must route with,
through 44/8) that will get me to a given destination within 44/8? If I see 20 paths, but
only 2 of them will forward my traffic based on my use case (src, dst) how can I tell
which ones are that, and how can I affect the routing from my node to this one in order to
ensure packet delivery? Do I just have to rely that BGP will hopefully pick the path that
doesn’t drop my packets instead of the ones that does?
The internet is not built that way, so we can not change it. In theory,
the capabilities were there (TOS based routing) but the global internet
has not seen fit to standardize on QoS guarantees and ressource.
In the network you directly control you can implement something like
this. For others, youre out of luck.
Will every router in the entire network apply
source-based policy routing? How will this be signaled? Will every have to manually
maintain tables of “if src is x, use table y”? Most routers today can do this as
statically configured firewall rules + additional routing tables. Is there a way to
dynamically propagate this information to the entire network? Is it safe to allow people
to control your routing policy? Who can modify your firewall rules to point to the “no
radio” table?
No, not on the internet. You might invent or adapt a routing protocol,
but it will not be of much use since it is unlikely to get adopted on
the internet side. MultiTopology Routing might fit your ticket tho.
You can’t just advertise routes on the single BGP
control plane and then drop packets based on firewall rules.
If you consider
nullroutes or lack of IPIP encap destinations to be
firewall rules, that has been done on amprgw or mirrorshades for ages.
In fact your proposal still envisions that..
If you do this, any connection becomes unpredictable,
and whether you get or not to your destination is a hit or miss, even if there are
multiple valid paths to this network. If we use simple BGP then you only control the
routes you advertise to your neighbors, and the AS Path. You can’t tell them “this route
is available, but only if you are from 44.154/16, and if not, it doesn’t exist”.
It’s all or nothing. If you advertise it, then for a correctly functioning network you
must forward to this destination all traffic you receive for it, unconditionally.
That is a simplification and not true in the real world.
By your logic, the amprgw at UCSD who announces 44/8 would be somehow
required to deliver them. Which is somewhat difficult if there is no
registered and operational gateway....
As you can see above, creating a single BGP control plane across the entire network, that
works with every use case people want can be a problem. Not only does it require advanced
BGP knowledge and configuration, but it may not even be possible with most common
hardware. For example MikroTik is known not to support Extended Communities in the first
place.
Too bad. Everybody will commend you for writing software to do that.
Keep compatibility and honor what others have been done before.
This proposal aims to have ARDC continuously advertise
44.128/10 on the Internet, but as a whole block to which all traffic is dropped and not
forwarded. We don’t want to change that.
But you do. The current state is that ARDC
forwards this traffic to
registered gateways via the IPIP mesh.
Unfortunately mechanisms like uRPF that you mention
only work to protect others from your network.
And they protect you if you receive
packets from the wrong interface.
For example, not from the proper IPIP tunnel. You could also mandate an
AH header for any AMPRnet packet, but for this proposal to get traction
is somewhat difficult, too.
If the network was more centralized and every 44
island required the PoPs to connect to each other, and everything had to go through them,
then you could argue that the ARDC staff maintaining it would have to follow
state-of-the-art procedures and since it’s only a few points we could also have capable
equipment, etc. So this becomes kinda better. But still, this means a centralized network.
Do we really want that?
Yet you take away the authority to define internet connection policy
from the individual networks, graciously offering them to renumber. Next
year a new proposal will come along. Youre going to ask them to renumber
again ?
Yes, exactly, the ACL would drop these packets, but
how do nodes #1 and #6 know that this path drops certain packets? How do they know which
packets are dropped? Do they have to manually set up routes to an alternative path to
route around these links if they want to send some types of packets? Will they maintain a
separate table of static routes by hand? How often will they update it? What if the policy
of a link changes and suddenly more packets are dropped than before? Will they have to
notice packet loss and take action to route around this region of the network?
You see, valid questions. But too far reaching. You are trying to encode
things in the address. You'll never be able to do this in such a way.
Next year someone could propose a pure radio only link, now what ?
I plan running parts over the net via satellite. Latency will be very
harmful for Echolink. Do I get another set of possible IP space
combinations for that purpose ?
Yes, this can easily be built. But isn’t building it
easier if we guarantee that 44.128/10 does not appear on the Internet and should only be
routed either on top of the Internet (tunnels, VPNs, …) or other means (radio) ?
see above.
What I’m trying to say is that if every user of the
network was competent and could easily do such changes (like many people have claimed in
this thread), then we wouldn’t have cases where a single person is managing the network of
20 others. Everyone would probably manage their own network. So it’s a point to make
towards the fact that not even the existing users are or want to be involved in all this
routing.
And they would have known someone to set this up for them. Otherwise
they wouldnt have got that mikrotic on the first place...
Yes, and their
demonstrated contributions over decades give them the
right to do that. And no, this is not a win-win solution. Youre taking
some peoples toys away and force them to expend work. .
If people voluntarily *agree* to move and make this sacrifice, that is
one thing. But this appears not to be the case here.
We don’t really know to be honest as only a few people have participated in this
conversation out of the thousands that use the network. So our margin of error here is 99%
;) I respect the people that have been doing this for
decades, but I also understand that we need to leave a lot of room for people that do this
one decade, or 5 years, or 1 year, or 0 to grow as well and do what they want to achieve.
Just because some people started this 25 years does not mean that this thing we have
shouldn’t evolve to allow for more and more users to participate.
That is perfectly OK, but you have to make such room first, and not to
*decree* that there is such room available. Part of my beef with the
board over the sale of the IP space was their repeated public denial of
any, let alone meaningful use of this space, despite hamnetdb
documentation. It was completely unnecessary not to acknowledge that
HAMNET was there, given that mutually agreed provisions for renumbering
were made (which I understand they were, probably long before).
But this causes resentment and uncertainty --- if I invest lots of time
into an innovative IP setup tomorrow, what is the chance that in one years
time Ill be forced to renumber ?
I have this particular problem in a commercial setting right
now. They offer me a cheap replacement of the server hardware of my
rented server because they want to get rid of the old one for
reliability. The offer is financially advantagous for me. The downside
is I would get a new IP address. That forces me to change dozens of
ACLs, DNS entries and other configurations. Calculating the time to do
so *easily* outweights any financial advantage...
There are certainly arguments for and against
country-based vs use-case-based allocations. I feel like if we do country-based
allocations, as is evident from my e-mail above, we will have a lot of trouble finding a
way to represent the ACLs of each link on BGP (or any other mechanism that can reconfigure
all network routers). If this is not possible, then we’ll need to have people maintain
complex routing tables to go around entire countries (if they even can) just to be able to
deliver some traffic, because the BGP Best Path drops it.
Maybe AMPRnet should use a different IGRP then ?
One that still has to be invented ? You know, advancing the art and
stuff ?
If we go with a system based on use case, then this is
not needed, as people can easily hardcode the two network policies that exist and easily
route any way they want based on them. This list of links is easy to aggregate: any link
in 44.128/10 has policy X, and each link in 44.0/9 has policy(ies?) Y.
You force renumbering to match policy. You should offer that, but not
force it. In the meantime, maybe those policy attributes should be
collected when registering a gateway ?
73s,
Mario
--
Mario Lorenz Internet: <ml(a)vdazone.org>
1001
days inactive
1002
days old
3 comments
4 participants
participants (4)
-
Antonios Chariton (daknob) -
Mario Lorenz -
Paul Sladen -
Ruben ON3RVH