Dear Mario,
On 30 Jul 2021, at 17:11, Mario Lorenz ml@vdazone.org wrote:
Dear Antonios,
Am 30. Jul 2021, um 15:32:26 schrieb Antonios Chariton (daknob):
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.
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.
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.
Indeed, yes. This is up to the operators of these services. We do not want to interfere with what they do and how.
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.
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
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.
Yes, this is something we can do, and it’s a good idea.
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).
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?
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 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 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.
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.
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.
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.
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.
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?
Moreover, if two 44/8 networks connect with intermediate hops over the Internet, e.g.:
- 44.1.2.3
- 44.3.2.1
- 192.0.2.15
- 193.5.16.50
- 44.4.6.7
- 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.
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?
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.
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.
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.
Yes, I agree.
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.
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) ?
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...
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 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.
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 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 ;)
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
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@mailman.ampr.org On Behalf Of Antonios Chariton (daknob) via 44Net Sent: Friday, July 30, 2021 20:01 To: 44Net general discussion 44net@mailman.ampr.org Cc: Antonios Chariton (daknob) daknob@daknob.net Subject: Re: [44net] A new era of IPv4 Allocations
Dear Mario,
On 30 Jul 2021, at 17:11, Mario Lorenz ml@vdazone.org wrote:
Dear Antonios,
Am 30. Jul 2021, um 15:32:26 schrieb Antonios Chariton (daknob):
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.
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.
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.
Indeed, yes. This is up to the operators of these services. We do not want to interfere with what they do and how.
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.
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
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.
Yes, this is something we can do, and it’s a good idea.
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).
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?
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 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 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.
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.
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.
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.
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.
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?
Moreover, if two 44/8 networks connect with intermediate hops over the Internet, e.g.:
- 44.1.2.3
- 44.3.2.1
- 192.0.2.15
- 193.5.16.50
- 44.4.6.7
- 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.
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?
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.
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.
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.
Yes, I agree.
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.
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) ?
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...
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 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.
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 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 ;)
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
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
Dear Antonios,
Am 30. Jul 2021, um 20:00:47 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.
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.
It is difficult to protect from malice.
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?
The packet will be dropped, possibly with an ICMP administratively-prohibited or similar packet.
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% ;)
You see, here is where you can improve.
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
-
Antonios Chariton (daknob) -
Mario Lorenz -
Paul Sladen -
Ruben ON3RVH