Re: [44net] 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, 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. 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. What happens if they do not have sufficient authority to pass? Where will this be reflected and how can users pick an alternative path? 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? 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. 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 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, 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? 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. 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