On Feb 4, 2021, at 8:02 AM, G1FEF via 44Net <44net(a)mailman.ampr.org> wrote: Hello Angelo, You are correct, an ASN (Autonomous System Number) is just a number, although often you will see it with “AS” before it, e.g. AS12345 There are generally speaking two ways folks announce their 44-net prefixes… 1) If you have your own ASN and suitable equipment in a suitable location etc, then you can setup a BGP session on your own equipment and announce your prefix to your ISP/NSP. In which case the originating ASN would be yours and the NSP details would be the organisation you announce to (there may be more than one NSP if you are multi-homing). 2) You don’t have your own ASN and your ISP/NSP will be announcing your prefix for you. In which case the originating ASN will belong to your ISP/NSP. In your case, it sounds very much like 2) so on the form I sent you, you need to put your NSP’s ASN as the originating ASN, either in the format 12345 or AS12345 I don’t mind which! So you just need to ask your ISP/NSP what their ASN is. Your ISP is no doubt connected to multiple providers but I don’t need to know about them, unless they specifically request that they are mentioned in the LOA - which occasionally happens. I thought I would reply on the mailing list in case this helps others. 73, Chris - G1FEF _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Hello Chris, I want to thank you so so much for this email. I am sure this will help other as well. It has been a real challenge.  I finally got the information we need. ( I hope ) 73 de Angelo

You act or it is already decided. There are also clearly disadvantages of what some have proposed and I don't   talk about backups of ucsd to Internet, what is good. No, it is that it makes amprnet gateways more (or totally) dependent on other core (ARDC) routers to route to other amprnet gateways over Internet. It doesn't make it less dependent, it adds another layer on top of that. Presently, I'm more or less independent with my individual tunnels (and I care less that they are using ipip or another protocol) or when I should be running bgp. Instead that the risk is spread, it will be more concentrated with these proposals what I have read here and at the 44NGN list. This all to make it more easier? I'm already providing a lot of these services. Bob VE3TOK On 2021-02-05 09:59, Rob PE1CHL via 44Net wrote: When you change the way you look at things, the things you look at change  Max Planck _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

a method to facilitate easier connection for those that do not have the luxury of a static IP and incoming IPIP passing through their ISP router.

That is becoming more and more common, and a solution is required not to lock out those that cannot have a suitable internet connection.

  Even VPS offerings from major providers all over the world no longer

of participating in the IPIP tunnel mesh directly, as their "control

allows TCP and UDP ports to be opened incoming ...

But when someone wants to do it "the old way", they still can do that.

That was in fact my proposal. Have ARDC setup a mesh of routers over

commonly known VPSes run under Apache Aurora and similar.

Those cannot do IPIP [snip] People getting a $3/mon VPS often find

once they get it deployed.  When you have a more directly managable

will not have this problem.

stuck in the past

But I do not want to force everyone with an unsuitable home internet

to get a suitable VPS, run IPIP from there, and then setup a VPN to

all because we have done IPIP for 25+ years and now want to continue it indefinitely.

Rob, Okay, so what's stopping 'us' from setting up a pilot ? If anyone at ARDC is listening, how about you assign a small pilot 44 subnet to our project, get us a linode account, make one of us administrators, and we setup an openVPN server. Have the routing to our small pilot 44 subnet put into place once we get the linode account setup.

I must be behind the times then. Never heard of it, so I just looked it up, for example :      Kubernetes is an open source orchestration system for Docker containers,      Apache Aurora is a Mesos framework for long-running services and cron jobs. Good god, what happened to just a plain old *nix system running on a VM ?  (no, that's not a ludite comment, for anyone who wants to throw that at me)

Why do they have to use IPIP ? with the openVPN system 'we are proposing', you are immediately on 44 net, perhaps I am missing something here.

Remaining stuck in the past VS the KISS principle are two different things.

I don't understand the point to this last comment, why do we need IPIP here, and why would we need to run a VPN to our VPS ? Oh you mean because there is no existing solution which I think should be provided by ARDC. I think we're on the same page on that one (I hope so anyways).

I don't see how deploying some actual hardware is unrealistic. A VPS-based solution will not scale well because in the VPS, you're buying into a system that's oversubscribed by design and you're at the mercy of the software layer inside of the VPS system the host is using. The other consideration is that right now, practical use of 44Net address space is limited by all of the technological hurdles you already summarized so well. If we deploy an easy-to-use system that support things like a single OpenVPN connection for an endpoint or easier tunneling, then usage is likely to ramp up quickly. Having real systems designed in an "enterprise" way actually cuts down on user support problems later on or the need to redesign-on-the-fly as you grow. No one wants to be trying to rebuild the plane while it's in the air.

One of our problems is that we have a hard time coming up with a use case and

On 2/6/21 2:59 PM, Jason McCormick via 44Net wrote: VPS-based solution will not scale well because in the VPS, you're buying into a system that's oversubscribed by design and you're at the mercy of the software layer inside of the VPS system the host is using. The other consideration is that right now, practical use of 44Net address space is limited by all of the technological hurdles you already summarized so well. If we deploy an easy-to-use system that support things like a single OpenVPN connection for an endpoint or easier tunneling, then usage is likely to ramp up quickly. Having real systems designed in an "enterprise" way actually cuts down on user support problems later on or the need to redesign-on-the-fly as you grow. No one wants to be trying to rebuild the plane while it's in the air. One of our problems is that we have a hard time coming up with a use case and killer advantage of our own network compared to the normal internet. One of the few hard advantages we have is the availability of large numbers of IPv4 addresses for free. That enables us to run a network with clean routing and subnetting and without NAT. Once we would migrate to IPv6 we would also lose that advantage. So, there really is no large influx of new users to be expected. After all, why would you connect your system to 44Net unless you already are a networking buff that would like to run services at home and play with networking. Not so many radio amateurs are. In our country with ~13000 registered amateurs (and pop. 17M) we now have issues 244 OpenVPN certificates over the 6.5 year period that service is now up and running, and about 25 of them are usually connected. We also have about 125 AS numbers for routers around the country, and about 170 subnet routes being distributed via BGP (plus those for the VPNs). That is a scale where software solutions like Linux VPSes either bare or with a router oriented OS+Configuration like MikroTik RouterOS still works perfectly fine. We are not to be compared with an ISP with millions of subscribers. Actually using VPSes instead of hardware makes it easier to ramp up (and down) quickly, as those providers normally have very convenient mechanisms to deploy new instances, which beat truck-hauling hardware around the world every time. Also when you use VPSes from an external supplier, it is them who are looking after the hardware, replace the broken fans and disks, and replace the entire machines when they become obsolete. I think the only work we would need to do ourselves is to make a network design and base configuration of the equipment, and likely make some tools to assist in chores like adding a user account or a new node in the network. (doing reconfiguration for that) Some people come up with the "disadvantage" that relying on a VPS provider would mean that your network is less reliable because you rely on some unknown external party. I think it is not so bad because we can always decide to use VPSes from different providers, and even when you provide your own hardware you will still rely on others like a datacenter with their power, cooling and networking infrastructure. Plus you then need to support your hardware or have people do that. I don't think a small group of radio amateurs should think they can do a better job than people like AWS, OVH, LINODE, Microsoft Azure, etc which have dedicated professionals working 24/7 to maintain, monitor and improve their infrastructure. Rob _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

We dont have high bandwith application? What about 50 Mb/s ? is that high speed enough? SDR kike the Hermes-Liet 2.0 can feed the HF spectrum to a software remotely By IP stream at up to 50Mb/s Would it be a nice thing to have multiple SDR transceiver on multiple bands all over the world available to ham that run a 44net adress?

Would it even be a nice intitative to build an high speed RF linking system for that use case?

I can think of many more project like that. Most people dont think of such project for a simple reason, most of the mode we use are narrow by definition, and since the FCC limit the maximum Bandwith available by bands to a bare minimum and that the USA ham's must comply to this insane thing, the rest of the world is kind of being drag to that fact. Just take the New pascket radio project, Canadian hams could use it at the maximum spead it was designed for, US, nope 70cm bandwith limit will prevent it. Frustrating I must say.

On 7/2/21 8:32 am, pete M via 44Net wrote: remotely By IP stream at up to 50Mb/s bands all over the world available to ham that run a 44net adress? Now that would be neat - having access to SDR IFs remotely, though those speeds are only going to be available at a regional level if routing over the Internet.  While I have 80+ Mbps available downstream, that really only applies to relatively local (within VK for me) endpoints.  Once I'm going overseas, usable bandwidth can drop to 10 Mbps or less, from end to end.  But the 2-2.4 MHz bandwidth of RTL-SDR class devices might be more practical on an international scale, which means a transport that can scale to suit available bandwidth.  Also, for latency reasons, we would want optimal routing on our core infrastructure, which ties back to the previous discussion. Nice out of the box thinking there. :) system for that use case? The biggest challenge with high speed RF is cost and complexity.  Not everyone is able to build UHF/microwave equipment reliably.  I have a number of issues in that area - some intrinsic, some are time related, and the cost of high speed/wide bandwidth microwave equipment tends to be rather expensive, given that amateur applications tend to be low volume, compared to something like mobile phones or wifi. the mode we use are narrow by definition, and since the FCC limit the maximum Bandwith available by bands to a bare minimum and that the USA ham's must comply to this insane thing, the rest of the world is kind of being drag to that fact. at the maximum spead it was designed for, US, nope 70cm bandwith limit will prevent it. Frustrating I must say. I'm pretty sick to death of being held back by archaic US regulations.  Here, we can also use whatever bandwidth a mode requires, provided we stay within the band limits (on VHF and up).  There may be some interesting band plan issues on 70cm, but we hams can resolve those.  On 1.2 GHz and up, there's bandwidth to burn, and it would be good to make use of that. :)  Maybe the rest of the world should just get on with it and encourage US hams to lobby to get their regulations updated to match the rest of the world, and in the meantime, the US battles on as best it can until they can sort out their regs and join us RF wise. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On Feb 9, 2021, at 6:02 AM, pete M via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: There is always multiple ways to skin a cat. But the SDR I talk about is a transceiver. I know we can use other type of processing and less BW. But what is the fun? Téléchargez Outlook pour Android<https://aka.ms/ghei36> ________________________________ From: 44Net &lt;44net-bounces+petem001=hotmail.com(a)mailman.ampr.org&gt; on behalf of Cliff Sojourner via 44Net &lt;44net(a)mailman.ampr.org&gt; Sent: Monday, February 8, 2021 6:01:48 PM To: 44Net general discussion &lt;44net(a)mailman.ampr.org&gt; Cc: Cliff Sojourner &lt;cls(a)employees.org&gt; Subject: Re: [44net] ASN # and Network Service Provider (NSP) We already have hundreds of SDRs available via IP. One aggregation is at http://websdr.org/ Frankly, sending 50MHz bandwidth at say 16 bits over IP is perhaps the worst way to do it... Just to find that elusive 50Hz CW signal!?? The latest SDRs have a massive A/D for baseband capture, perhaps 250MHz, immediately processed by multiple FPGAs, then perhaps sent to Gnu Radio on a very fast multicore CPU. This is no simple trick. But my point is, people smarter than me have figured out it is better to decimate and process locally, not at the end of an IP connection. So i am still at a loss for compelling high bandwidth applications. (Thanks for indulging my detour here. Back to regularly scheduled BGP etc.) Cliff K6CLS CM87 _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

We already have hundreds of SDRs available via IP. One aggregation is athttp://websdr.org/

Well, I don't think network level security is usable for that.  Right now, half the users do not even make their reverse-DNS working, so you cannot tell whom the incoming connects are coming from.

Le 16/02/2021 à 10:45, Rob PE1CHL via 44Net a écrit : now, half the users do not even make their reverse-DNS working, so you cannot tell whom the incoming connects are coming from. I was not talking about mapping every ham callsign with an IP address, which seems pretty un-doable to me, as we are mostly using subnets and not individual addresses... As we already talked about, a certificate is probably the best way to use at application level (Echolink), where the user must be identified by its callsign. For that, a Certification Authority managed by ARDC is probably a good idea :-) Anyway, there are situations, at lower layers, where it may be useful to be able to grant/deny access based on source address, where we need to ensure the user is a ham, but without necessarily knowing its exact callsign. One of the things in my ToDo list is a "Content Manager" on our public web server, that would display a catalog of all the resources available on the internal network : - Users coming from Internet would see only the "public" things (WEB, APRS, XLX, meteo...) - Users coming from 44Net would be able to access other services such as Nagios monitoring, Netbox IPAM, NAS file server, dashboards of repeaters, ... But we can be even more granular. We could offer direct access to some specific resource such as a radio-club remote rig only for the active (paid) members, repeater dashboard in read/write for local users and in read-only for other 44net users, SSH management restricted to local IP ranges, etc... Voice repeater systems such as XLX, D-Star, DMR, Asterisk could also use basic source filtering on 44Net, which would avoid full exposure to "the wild Internet", which is a huge security concern, because all systems currently connected to Internet do not necessarily have full upgrade and patch management, etc... All that without having to implement a full certificate management, just with a few basic firewall rules at the gateway. 73 de TK1BI _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Le 16/02/2021 à 14:02, Cliff Sojourner via 44Net a écrit : 44net is not Internet ;-) 73 de TK1BI _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

But it can be useful as a simple pre-authentication for a group of users : all users coming from a 44net IP are licensed operators. Then, a simple firewall rule can grant them access to the private parts of the network.

But it can be useful as a simple pre-authentication for a group of users :

When I get a request like "I am Rob PE1CHL and I want some addresses to use on 44Net" there is no way for me to really verify that this mail is really coming from a licensed operator, and even less to verify that he keeps that license during the time he can still use that address.

Sure, the admittance of only 44Net traffic (44.0.0.0/9 and 44.128.0.0/10) is a first step when guarding a system from access by just everyone, and try to limit it to mostly radio amateurs with hopefully good intentions.

But I never would use it as a method to allow e.g. to operate a transmitter (as was the example use case).

pete M via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: I agree that our current methods of connecting new hams are pretty klunky and could use some improvement. We could do as you suggest, but if the wireguard traffic ever was transmitted over ham frequencies, that would make that new ham liable for violating their country's laws against encrypted traffic.

-----Original Message----- From: 44Net &lt;44net-bounces+dave.g4ugm=gmail.com(a)mailman.ampr.org&gt; On Behalf Of Toussaint OTTAVI via 44Net Sent: 17 February 2021 10:04 To: 44net(a)mailman.ampr.org Cc: Toussaint OTTAVI &lt;t.ottavi(a)bc-109.com&gt; Subject: Re: [44net] ASN # and Network Service Provider (NSP) Le 16/02/2021 à 14:02, Cliff Sojourner via 44Net a écrit : there is no place for those in any network layer. I don't know on which layer you could put it, but filtering access by source IP is a commonly used technique in business networks for restricting access. Of course, it's different from user authentication. But it can be useful as a simple pre-authentication for a group of users : all users coming from a 44net IP are licensed operators. Then, a simple firewall rule can grant them access to the private parts of the network. 73 de TK1BI _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On Feb 17, 2021, at 12:24, Angelo via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: Well, I have changed to another NSP and still no success. Seems to be a problem with the advertisement of my subnet 44.108.2/24. I have received my LOA and have forwarded it to the NSP, but still been unable to get my subnet advertised. I know the stock answer to most of you will be, if they are a NSP, they should know what do. Since this is the second NSP, I am looking specific steps/commands that need to be done to get subnet advertised. Please refrain from sending the message, " They should know ." Forward that type of message to the NSP does not help much at all. I am trying to help get this worked out. Any help would be appreciated. 73 de Angelo

Well, I have changed to another NSP and still no success. Seems to be a problem with the advertisement of my subnet 44.108.2/24. I have received my LOA and have forwarded it to the NSP, but still been unable to get my subnet advertised. I know the stock answer to most of you will be, if they are a NSP, they should know what do. Since this is the second NSP, I am looking specific steps/commands that need to be done to get subnet advertised. Please refrain from sending the message, " They should know ." Forward that type of message to the NSP does not help much at all. I am trying to help get this worked out. Any help would be appreciated. 73 de Angelo _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

HI Angelo, I can explain my journey, and hopefully it will help with your situation. There are a lot of barriers to this process, and some make sense. While there are some network providers that will announce the netblock, some of the issue stems from what the end goal is. If one of those goals is to 'learn a life skill', you've hit a jackpot, there is a lot to learn. If it's simply to just have a few static IPs for your own use, cloud providers are a much easier and cheaper option. The benefits of 'leasing' and announcing a netblock is mostly around portability of your IPs. For me, I wanted to setup a service where I can use the same IP address anywhere for time services. The idea is that if you're on AREDN (or another service), NTP can be setup on an IP address like 44.4.53.2, and anybody with a time server can create a time server with the IP 40.4.53.2. It's 'anycast' with some RF added for fun. Think of using 8.8.8.8 for DNS, we could use something like 44.4.4.4 for NTP/time. That aside, there is likely a better mechanism than NTP to do this over the air, and that's where the experimentation and fun happens. I will go forward with the idea that you would like these IPs to be portable somehow for the project you're using this block for. The Internet is built on BGP, and a major part of that is the autonomous system number (AS or ASN). This number is unique on the internet for BGP services to learn how to get from one IP to another. For example, if your IP is 10.0.0.1, and trying to reach 10.10.0.1, will probably go through multiple autonomous systems to get there. Usually the shortest path wins. 10.0.0.1 (AS65536) -> (AS65537) -> 10.10.0.1 (AS65551) There might be multiple routes to get there, which is where BGP comes in. 10.0.0.1 (AS65536) -> AS65538 -> AS65539 -> AS65551 etc.. This is a longer AS path, it becomes the less ideal path to send traffic. This way, if a path fails, there are 5 more paths left to get to me. For visual representation of all the routes to my AS and path, check out https://bit.ly/3sggrKj - packets can go multiple different paths to get to me like Level3 and NTT but the shortest path wins. To acquire an AS number, you need a business entity. For me, I already had a business entity called "I am a Bad Actor, LLC" for another project I had in the past for pen testing. I registered it in Wyoming using wyomingagents.com, which pretty much took about a day to receive the articles of incorporation. Cost here was $25 for a 'Registered Agent' + $102 for compliance filing. We're up to $127 so far. With the articles of incorporation, you can request an AS number. These are manually approved by various authorities (ARIN, RIPE, etc) but assuming you're in the US, ARIN is where you go (www.arin.net) You'll need to submit 'sample documentation' for why you need an AS number. It will look something like this: ┌────────────────────────────────────────────────────────┐ │ │ │┌───────────────┐ ┌─────────┐ ┌────────────────────┐ │ ││ │ │ │ │ ARIX │ │ ││ Packet │ │ Choopa │ │ Amateur Radio │ │ ││ │ │ │ │ Exchange │ │ ││ │ │ │ │ │ │ │└───────────────┘ └─────────┘ └────────────────────┘ │ │ ▲ ▲ ▲ │ │ │ │ │ │ │ └────────────────┼──────────────────┘ │ │ │ │ │ │ │ │ │ │ │ ┌──────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ MY ASN │ │ │ │ ┌─────┴───────┐ │ │ │ │ Hurricane │ │ │ └────────────────────┤Electric FRE2│ │ │ └─────────────┘ │ └────────────────────────────────────────────────────────┘ Something like that. Make it pretty. Basically, you need the ASN to connect to multiple providers, including our very own internet exchange ARIX based in Hurricane Electric in Fremont. This step will cost $550 for this ASN -, plus $150 per year. So far we're up to $677 + 150 yearly. Once you have the AS number, you will now be taken slightly more seriously with the ISPs and NSPs of the world. You've paid your dues to be part of an exclusive club. Mind you, there are as many AS numbers as there are IPv4 addresses, so there is no shortage of AS numbers, just additional barriers to entry for a reason (will go into this later) For a list of providers that are willing to announce your new ASN with your IP range, head over to https://bgp.services and you can find a good list there. Vultr/Choopa is on the list, as well as many others. I would recommend a small shop called FreeRangeCloud (freerangecloud.com), as the contacts there are really nice. It's not a big operation so you're not just a number. Also, be patient with them. :) You have a few options at this point, but at first it involves getting a linux system up and running with BGP access. I personally use a Raspberry Pi 4 with 8GB of memory so I can hold full BGP feed in memory. I sent it to FRC to be installed in the rack within Hurricane Electric in Fremont. Raspberry pi was $75, plus a case, memory card, and an NTP shield for my use-case. All said and done, about $110 + ntp sheild. You can get a VM that has similar specs for $8 or $10/mo. It's probably cheaper to do the VM path, but I needed the additional hardware. Now we're up to $752 + $270/year. You might want to also pick up a IPv6 IP range from freerangecloud while you're at it - a /48 (the minimum you can announce over BGP) goes for $5 setup, plus $5 a year. The steps below will be similar, but not exact for IPv6. After your linux box is provisioned for your new IP range, we'll just add a dummy interface to accept the new IP range # ip link add dummy0 type dummy # ip addr add <44-IP>/24 dev dummy0 44-IP is a real IP, not just network IP There are a few services that can talk BGP on Unix, and the major one is called BIRD. I still use 1.6, but you can use any you'd like. BIRD is a bit overkill, but works well. install it with your favorite package manager. I use apt. apt-get -y bird vi /etc/bird/bird.conf to get started. here is a sample config: # something unique here on the network. Helps avoid routing loops in certain iBGP configs router id 10.0.0.1; # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol kernel { export all; scan time 20; } protocol direct { interface "dummy0"; import all; } # Setup an outbound filter to ONLY announce the /24 assigned to you filter my_route { if net = <my netblock>/24 then accept; else reject; } protocol bgp bgp_uplink { export filter my_route; import all; local as <your new ASN>; direct; neighbor <NSP BGP router> as <NSP ASN>; } Save configs, start bird (service bird start) and check on it with "birdc" birdc show protocol all After this is complete, you'll need to get routes into the IRR (Internet Routing Registry) for your ASN. IRR is a group of registries loosely used to validate you own the netblock you are announcing with your AS. Not only that, but it also lists your uplink transit providers so they can re-announce your block. This is as an attempt to avoid someone hijacking your IP range and saying "this is mine". The IRR through ARIN was free and easy through their email interface. Since they've moved to web-based, they now validate the routes with blocks that are ARIN-owned, of which 44.x.x.x addresses are not. The other options available are RADb, which currently costs $425/year for non-profit. There was talk about AMPR opening up an account, but that will require using the API for people with an ASN can update the DB themselves with authentication. I'm assuming this is in the works already. But for now, this is the only way I know to update the IRR now ARIN is no longer accepting email-based updates. So we're up to $1177 to start, and $575 per year to announce the IP. There is a chance you can bypass a lot of the above ASN malarkey, but you will be met with mixed results. If you use a small provider like Free Range Cloud (freerangecloud.com) or Neptune Networks (neptunenetworks.org) they can announce using their own ASN, and provide you a 'private ASN' that you can announce your route, and it will be passed on. You'll still need BIRD, but it gives you control over which network provider gets your traffic (which is, after all, the whole purpose, right? :) Why is this so difficult, you say? Well, the short answer is that the internet providers as a whole don't want more ASNs on the network. It means their route tables get bigger, requires more memory/cpu, and routers get more expensive over time. I went for a 8GB raspberry pi, and that should give me some wiggle room for a while. Most routers have much less memory than that. Each additional route adds a little bit extra step for routers to do. ARIN also has bills to pay themselves. Now for options - If we can get IP addresses registered as "legacy" status in RIPE, we can use their IRR to avoid the RADb step above (saves $425/year). Also, if RIPE announces the IPs as legacy, it would be possible to take a chunk of IPs and announce them via AWS via AWS Global Accelerator and utilize cloud resources using the IPs. Instead of IPIP, we can hand out world-wide VPN endpoints. We can also create our own VPCs for different projects. This would give amateur radio a huge boost of bandwidth in places like Europe, Australia, South America, and India, and Africa. For those of us who wish to keep our racks/cages/routers at datacenters, that's completely cool. We could maybe setup AWS Direct Connect in popular datacenters for direct connectivity to other AMPRnet nodes. I learned a lot about BGP in the last 8 months doing it myself. It's also an expensive lesson to learn. Worth it? Maybe. But not everyone wants to learn BGP just to get a network IP block for a project. ' Anyway - got a little soapbox-ey for a minute. I hope this helps. For anybody doing this for the first time, freerangecloud.com and neptunenetworks.org are the nicest and most willing to help NSPs out there. 73, KF6DMA On Wed, Feb 17, 2021 at 9:24 AM Angelo via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Ok, I give up. Stop moving the goal posts. You said 44net isn't Internet, now you say to use basic techniques used by business for Internet. Src IP is insufficient for this. Lots more needed. Lookup stateful firewall. Also, think about multiple users per IP. Friendly advice. Cliff K6CLS CM87 On February 17, 2021 2:03:59 AM PST, Toussaint OTTAVI via 44Net &lt;44net(a)mailman.ampr.org&gt; wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

but we largely have the proposed network already running ...

*I* am talking about *what we have now* ...

Rob, Jason's comment about VPS scalability made me want to ask this (I forgot) : already running So the Dutch network is running it's own VPS service on it's 'own hardware' ? So the proposal is to have ARDC run it's own VPS service that would give amateur radio ops what they need as far as tunneling requirements and so on ? In addition we could add openVPN service as well ? Maiko Langelaar / VE4KLM _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

So the Dutch network is running it's own VPS service on it's 'own hardware' ? So the proposal is to have ARDC run it's own VPS service that would give amateur radio ops what they need as far as tunneling requirements and so on ? In addition we could add openVPN service as well ?

And if you're looking for various providers that offer Internet BGP to VMs: http://bgp.services On Thu, Feb 4, 2021 at 4:20 PM Dave Gingrich via 44Net < 44net(a)mailman.ampr.org&gt; wrote: _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net