Hello 44Net Mailing List,
There has been a lot of discussion on this list about the state of 44Net. Some people like how it works, some would like to see an upgrade. In order to make an informed decision that takes a variety of viewpoints into account, ARDC is conducting an assessment. For the first phase, we’ve put together a survey, which we'd love for you to fill out. Our aim is to get input from as many people as possible to help influence the network’s next chapter.
Click here to go to the survey:
survey.ardc.net
(Please note that the above is a redirect.)
We expect that it will take around 15 minutes to complete.
The survey is currently being translated into French, German, and Japanese, shoud you prefer to take it in another language. Thank you for your patience as we complete professional translations. We’ll post them here as soon as they are ready!
It’s important to note: the survey is not a voting mechanism - it’s a research tool. We’ll also be conducting interviews and focus groups with a subset of users. Results from all research will be shared publicly (personal information excluded) on ampr.org.
If you have questions about this survey or are interested in being interviewed or part of a focus group, reach out to us at any time: contact@ardc.net. You can also follow the assessment’s progress by signing up for our newsletter.
Thank you in advance for sharing your input - we look forward to reading your responses!
Warmly, Rosy & the ARDC team
On Thu, 19 May 2022, Rosy Schechter - KJ7RYV via 44net wrote:
Rosy, ...
There has been a lot of discussion on this list ...
... which was summarised, by yourself, on 2022-04-26 with:
... migrating this mailing list to any new system will likely come with pain and user drop-off, [so] it makes sense for this mailing list to remain on its existing and updated mailman instance.
Which seems to be a very sensible and wise summary.
This is the only reliable method we have for communication, reporting bugs, searching for missing HAMs, advertising meeting, requesting feedback, and having discussion ... it would make sense to leave it alone.
"If it ain't broken don't fix it".
-Paul
On 19 May 2022, at 21:21, Paul Sladen via 44net 44net@mailman.ampr.org wrote: : This is the only reliable method we have for communication, reporting bugs, searching for missing HAMs, advertising meeting, requesting feedback, and having discussion ... it would make sense to leave it alone.
"If it ain't broken don't fix it".
The survey is not about this mailing list and whether *it* needs an upgrade. It’s about the whole of 44Net and how we look to the future.
Chris - G1FEF
On 20/5/22 5:42 am, Rosy Schechter - KJ7RYV via 44net wrote:
Hello 44Net Mailing List,
There has been a lot of discussion on this list about the state of 44Net. Some people like how it works, some would like to see an upgrade. In order to make an informed decision that takes a variety of viewpoints into account, ARDC is conducting an assessment. For the first phase, we’ve put together a survey, which we'd love for you to fill out. Our aim is to get input from as many people as possible to help influence the network’s next chapter.
Just finished the survey, covers a lot of good issues. Only thing I'd comment on is it's hard to summarise across my two allocations - they are _very_ different in many respects, both technologically (BGP vs IPIP), use (infrastructure vs experimentation), degree of use (fully utilised vs limited deployment), and importance (mission critical vs experimental/tinkering).
Also, in future, could you please use both the redirect and direct URL in emails. This PC has an IPIP based 44net address and has issues reaching some ARDC hosted content(at best, veeery slow). I had to use another PC without a 44net address to access the survey.
Hi Tony,
Just finished the survey, covers a lot of good issues. Only thing I'd comment on is it's hard to summarise across my two allocations - they are _very_ different in many respects, both technologically (BGP vs IPIP), use (infrastructure vs experimentation), degree of use (fully utilised vs limited deployment), and importance (mission critical vs experimental/tinkering).
Thank you for sharing this, Tony. This insight is super helpful.
Also, in future, could you please use both the redirect and direct URL in emails. This PC has an IPIP based 44net address and has issues reaching some ARDC hosted content(at best, veeery slow). I had to use another PC without a 44net address to access the survey.
Yes! For anyone who wants the direct link, here it is:
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sourc...
Thanks again for sharing your thoughts!
Rosy
On 20/5/22 9:32 am, Rosy Schechter - KJ7RYV via 44net wrote:
Hi Tony,
Just finished the survey, covers a lot of good issues. Only thing I'd comment on is it's hard to summarise across my two allocations - they are _very_ different in many respects, both technologically (BGP vs IPIP), use (infrastructure vs experimentation), degree of use (fully utilised vs limited deployment), and importance (mission critical vs experimental/tinkering).
Thank you for sharing this, Tony. This insight is super helpful.
You're welcome Rosy, and I've left my email address in the survey, if you want to follow up when the time comes. Next time around, it might pay to have a facility in the survey to allow people with IP allocations to be able to list each one separately and answer the questions separately for them.
Also, in future, could you please use both the redirect and direct URL in emails. This PC has an IPIP based 44net address and has issues reaching some ARDC hosted content(at best, veeery slow). I had to use another PC without a 44net address to access the survey.
Yes! For anyone who wants the direct link, here it is:
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sourc...
That may help someone else, thanks for posting the link for those who need it.
On 19 May 2022, at 23:20, Tony Langdon via 44net 44net@mailman.ampr.org wrote:
Just finished the survey, covers a lot of good issues. Only thing I'd comment on is it's hard to summarise across my two allocations - they are _very_ different in many respects, both technologically (BGP vs IPIP), use (infrastructure vs experimentation), degree of use (fully utilised vs limited deployment), and importance (mission critical vs experimental/tinkering).
You could always complete the survey twice, once for each allocation - you might need to do the second one from a private/incognito browser session though.
Chris - G1FEF
Chris - G1FEF — ARDC IT Director
Web: https://www.ardc.net
Good survey I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in learning routing has been an invaluable learning exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One being supporting internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which mostly require a public IPV4 address and the ability to port forward. Such is not the case with cellular providers and will only become more of an issue as the global pool IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s might want to use OpenVPN as it's well supported and issues automated keys or the ARRL LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen. But these will likely be service specific. Ex, I believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing. Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a portal question should exist to point them to their geographic allocation or not. If the intent is non RF or mesh, then a different allocation methodology should be employed (next chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately coordinate forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR
I might suggest WireGuard instead of OpenVPN. I know it's newer but it's also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of routing. I think there's a balance to be struck - ham radio is about learning, but there shouldn't be a high barrier to entry.
Dave/ad8g
-----Original Message----- From: Steve L via 44net 44net@mailman.ampr.org Sent: Sunday, May 22, 2022 14:25 To: Rosy Schechter - KJ7RYV rosy@ardc.net Cc: Amprnet 44 Net 44net@mailman.ampr.org Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in learning routing has been an invaluable learning exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One being supporting internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which mostly require a public IPV4 address and the ability to port forward. Such is not the case with cellular providers and will only become more of an issue as the global pool IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s might want to use OpenVPN as it's well supported and issues automated keys or the ARRL LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen. But these will likely be service specific. Ex, I believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing. Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a portal question should exist to point them to their geographic allocation or not. If the intent is non RF or mesh, then a different allocation methodology should be employed (next chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately coordinate forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
My 2-pence (or cents)…
I typically use Pfsense for routing and the export tool for OpenVPN makes creating certificates and exporting configs as easy as any other solution.
The subnets are plenty big enough for someone to create a platform that supports more than one VPN type and people can choose what they prefer… L2TP is built-in to some Huawei 4G routers for example, OVPN has an app for just about every platform and Wireguard is good for Site-to-Site VPNs.
I have a service offering static addresses on both L2TP and OVPN, I may add Wireguard later on.
On Sun, 22 May 2022 at 19:44, David Andrzejewski via 44net < 44net@mailman.ampr.org> wrote:
I might suggest WireGuard instead of OpenVPN. I know it's newer but it's also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of routing. I think there's a balance to be struck - ham radio is about learning, but there shouldn't be a high barrier to entry.
Dave/ad8g
-----Original Message----- From: Steve L via 44net 44net@mailman.ampr.org Sent: Sunday, May 22, 2022 14:25 To: Rosy Schechter - KJ7RYV rosy@ardc.net Cc: Amprnet 44 Net 44net@mailman.ampr.org Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in learning routing has been an invaluable learning exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One being supporting internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which mostly require a public IPV4 address and the ability to port forward. Such is not the case with cellular providers and will only become more of an issue as the global pool IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s might want to use OpenVPN as it's well supported and issues automated keys or the ARRL LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen. But these will likely be service specific. Ex, I believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing. Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a portal question should exist to point them to their geographic allocation or not. If the intent is non RF or mesh, then a different allocation methodology should be employed (next chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately coordinate forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On Sun, 22 May 2022, Mark Stevenson via 44net wrote:
I typically use Pfsense for routing and the export tool for OpenVPN makes creating certificates and exporting configs as easy as any other solution.
There's also opnsense, the white-box version of pfSense.
It is also possible to configure OpenVPN to use a cipher of "none", which turns off encryption, but it leaves the connection subject to some attacks. This may be useful if you need to cross a NAT by means of a port forward, cross another network that doesn't permit encryption (like Part 97 over the air), or are stacking VPNs in a VPN like VLANs. Another possible use case for cipher = none is to eliminate delays and CPU overhead however the hash function will contribute to jitter anyway.
prefer… L2TP is built-in to some Huawei 4G routers for example, OVPN has an app for just about every platform and Wireguard is good for Site-to-Site VPNs.
I have a service offering static addresses on both L2TP and OVPN, I may add Wireguard later on.
tinc is also an option and don't forget about IPSEC.
The IPIP mesh is not plug and play, which for folks like me who are interested in learning routing has been an invaluable learning exercise. I hope something like this can always continue.
Moreover, using IPIP requires the ability to load kernel modules, which in some enviroments simply isn't possible but some of those environments already support PPP, GRE, tun, and/or tap interfaces.
However there are other use cases that are more plug and play. One being supporting internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which mostly require a public IPV4 address and the ability to port forward. Such is not the case with cellular providers and will only become more of an issue as the global pool IPv4 addresses shrinks.
IPv6 is a solution for dealing with mobile connectivity providers and other providers using Carrier-Grade NAT (CGNAT). Many of them already have end-to-end IPv6 networks. Your mileage may vary (YMMV) based on the quality of the IPv6 implementation in your edge device.
A system of geographic (Points Of Presence) POPs should be deployed. The POPs might want to use OpenVPN as it's well supported and issues automated keys or the ARRL LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI technique to drop bittorrent fingerprints to ease overall administration.
A CA and PKI portal isn't a bad idea but that can be an expensive, on-going process depending on the solution implemented. ICANN provides great examples of this with the various KSK key signing ceremonies on YouTube. Certificates also reinforce authenticity, one of the three legs of the "CIA Triad" for data security and assurance.
I think most of the hams using IP space for regional networks are going to be thinking locally, regionally, or by state in terms of connectivity and looking for where the internet traffic is likely exchanged as a way of avoiding impacts due to disasters.
For the purposes of ARDC, open non-profit internet exchanges like SIX https://www.seattleix.net/ are the best places for PoPs.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager
Wireguard is indeed very easy to set up and run, I am a big fan of it in general. But Wireguard has the distinct disadvantage of being UDP only. OpenVPN can use UDP or TCP based tunnels. For IRLP we chose to use TCP based tunnels.
While TCP has much more overhead, we found that with some connection technologies, TCP can work wonders over flaky infrastructure, and high jitter connections. IRLP actually requires very little bandwidth, less than 100 kbps maximum. But to work well, the packets must arrive in the correct order, even if there is a bit of added delay. TCP numbers each packet and always will deliver them in the correct order, or asks for retransmission. TCP sessions are also easier to maintain over uncooperative routers or networks. Many repeaters use cellular based links, the quality of which can vary a lot, especially if the node/repeater is mobile.
— Dave K9DC, K9IP
On May 22, 2022, at 14:43, David Andrzejewski via 44net 44net@mailman.ampr.org wrote:
I might suggest WireGuard instead of OpenVPN. I know it's newer but it's also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of routing. I think there's a balance to be struck - ham radio is about learning, but there shouldn't be a high barrier to entry.
Dave/ad8g
-----Original Message----- From: Steve L via 44net 44net@mailman.ampr.org Sent: Sunday, May 22, 2022 14:25 To: Rosy Schechter - KJ7RYV rosy@ardc.net Cc: Amprnet 44 Net 44net@mailman.ampr.org Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in learning routing has been an invaluable learning exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One being supporting internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which mostly require a public IPV4 address and the ability to port forward. Such is not the case with cellular providers and will only become more of an issue as the global pool IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s might want to use OpenVPN as it's well supported and issues automated keys or the ARRL LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen. But these will likely be service specific. Ex, I believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing. Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a portal question should exist to point them to their geographic allocation or not. If the intent is non RF or mesh, then a different allocation methodology should be employed (next chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately coordinate forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR
A big advantage of POPs over the current IPIP mesh is that you do not need to have everyone use the same tunneling protocol. POPs can offer multiple tunneling protocols and can experiment with new ones, without impact on all the other users of the network.
So there is no need to have a broad discussion about "do we use OpenVPN OR wireguard", we can offer both of them, and when a new protocol comes around next year we can just add it, first to one or a couple of POPs to try and test it, and then to all of them.
With the IPIP mesh we are stuck with using the same protocol everywhere, and when some user cannot use it due to limitations of their internet connection, they simply cannot join. Also, having POPs as an intermediate makes the network scale much better, as each user only has a tunnel to one or a couple of POPs, instead of having a full mesh to everyone else. The number of POPs can increase with demand and they can be located where demand is highest.
Rob
On 5/22/22 20:43, David Andrzejewski via 44net wrote:
I might suggest WireGuard instead of OpenVPN. I know it's newer but it's also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of routing. I think there's a balance to be struck - ham radio is about learning, but there shouldn't be a high barrier to entry.
Dave/ad8g
-----Original Message----- From: Steve L via 44net 44net@mailman.ampr.org Sent: Sunday, May 22, 2022 14:25 To: Rosy Schechter - KJ7RYV rosy@ardc.net Cc: Amprnet 44 Net 44net@mailman.ampr.org Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in learning routing has been an invaluable learning exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One being supporting internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which mostly require a public IPV4 address and the ability to port forward. Such is not the case with cellular providers and will only become more of an issue as the global pool IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s might want to use OpenVPN as it's well supported and issues automated keys or the ARRL LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen. But these will likely be service specific. Ex, I believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing. Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a portal question should exist to point them to their geographic allocation or not. If the intent is non RF or mesh, then a different allocation methodology should be employed (next chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately coordinate forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I like the regional pops idea and add the ability to have redundant connectivity for an end user (individual or entity). So I connect to a west coast and a central or east coast pop in the US. Europe and others can do something similar. If I wanted, maybe I can connect to as many pops as I think I need to. Could also be admin limited to keep things from getting too crazy. POPs are a full mesh between regions.
End user setup is MUCH more simple at that point as well. No scripts to install hundreds of tunnels into a MikroTik router.
I like the idea that a POP can support multiple tunnel methods. I mean why not right? :D
Are there any programs or ham friendly datacenters that could help with regional bandwidth and transport between hops? When I think regional, I think of things like AWS, Azure and Google Cloud with their multi-region setups. Maybe a bit overkill but something to consider I guess?
Charlie/K7AKT
On 2022-05-23 00:50, Rob PE1CHL via 44net wrote:
A big advantage of POPs over the current IPIP mesh is that you do not need to have everyone use the same tunneling protocol. POPs can offer multiple tunneling protocols and can experiment with new ones, without impact on all the other users of the network.
So there is no need to have a broad discussion about "do we use OpenVPN OR wireguard", we can offer both of them, and when a new protocol comes around next year we can just add it, first to one or a couple of POPs to try and test it, and then to all of them.
With the IPIP mesh we are stuck with using the same protocol everywhere, and when some user cannot use it due to limitations of their internet connection, they simply cannot join. Also, having POPs as an intermediate makes the network scale much better, as each user only has a tunnel to one or a couple of POPs, instead of having a full mesh to everyone else. The number of POPs can increase with demand and they can be located where demand is highest.
Rob
On 5/22/22 20:43, David Andrzejewski via 44net wrote:
I might suggest WireGuard instead of OpenVPN. I know it's newer but it's also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of routing. I think there's a balance to be struck - ham radio is about learning, but there shouldn't be a high barrier to entry.
Dave/ad8g
-----Original Message----- From: Steve L via 44net 44net@mailman.ampr.org Sent: Sunday, May 22, 2022 14:25 To: Rosy Schechter - KJ7RYV rosy@ardc.net Cc: Amprnet 44 Net 44net@mailman.ampr.org Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are interested in learning routing has been an invaluable learning exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One being supporting internet connected infrastructure (ie. IRLP, Allstar, DMR, D-Star etc). All of which mostly require a public IPV4 address and the ability to port forward. Such is not the case with cellular providers and will only become more of an issue as the global pool IPv4 addresses shrinks. A system of geographic POP’s should be deployed. The POP’s might want to use OpenVPN as it's well supported and issues automated keys or the ARRL LoTW method. It would be wise to limit the bandwidth to something modest and employ a DPI technique to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups making this happen. But these will likely be service specific. Ex, I believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing. Which makes sense if you intend to interact with existing (legacy) RF networks. Perhaps a portal question should exist to point them to their geographic allocation or not. If the intent is non RF or mesh, then a different allocation methodology should be employed (next chunk in sequence)
I’ll stress again knowing who is doing what is always good so one can privately coordinate forwarding partners, etc, and just folks to experiment with.
Steve, KB9MWR _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On 5/26/22 19:36, charlie--- via 44net wrote:
I like the regional pops idea and add the ability to have redundant connectivity for an end user (individual or entity). So I connect to a west coast and a central or east coast pop in the US. Europe and others can do something similar. If I wanted, maybe I can connect to as many pops as I think I need to. Could also be admin limited to keep things from getting too crazy. POPs are a full mesh between regions.
Yes, that is also part of my design. An entry-level user can connect to a single PoP and get "their subnet" routed to them, and route all other Net44 space towards that PoP. Simple, static routing. A more advanced user can make multiple PoP connections and use BGP to send and receive individual subnet routes, and let their local router decide to which of the PoPs to send each packet. That would also cover the case where a PoP is down and all traffic is routed via the remaining one(s). These users can also have cross-connections to other users (via radio or direct tunnels) and the routing remains correct.
End user setup is MUCH more simple at that point as well. No scripts to install hundreds of tunnels into a MikroTik router.
Indeed, the setup of one or more tunnel connections and (if desired) BGP peers is very simple in a MikroTik router.
Are there any programs or ham friendly datacenters that could help with regional bandwidth and transport between hops? When I think regional, I think of things like AWS, Azure and Google Cloud with their multi-region setups. Maybe a bit overkill but something to consider I guess?
Several HAMs have stuff in datacenters and could be part of such a network, but a PoP could be an inexpensive VPS in such a cloud network as well. Some platforms have difficulty with protocols like IPIP, but it would be phased out anyway. The PoPs would be interlinked using a (partial) mesh of tunnels, and when possible in that VPS service they can also announce a local part of the Net44 space on internet using BGP, so traffic between local users and internet takes a shorter path.
The advantage is that a PoP can announce a larger network ( /24 .. /16 for example) and the local users take a smaller subnet out of that, reducing the number of BGP subnet announcements on internet while keeping the efficiency of a local announcement. Also many users now announce a /24 because that is the minimum size on internet, while they require much less than that. Centralizing the BGP announcements also makes the administrative effort much less, both for users and network admins.
Of course to make this efficient it is best when IP allocations, also when they are to be BGP announced, remain roughly tied to geographical region. Unfortunately that is not what is currently happening.
Rob
Another approach would be auto-failover between PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net < 44net@mailman.ampr.org> wrote:
Yes, that is also part of my design. An entry-level user can connect to a single PoP and get "their subnet" routed to them, and route all other Net44 space towards that PoP. Simple, static routing. A more advanced user can make multiple PoP connections and use BGP to send and receive individual subnet routes, and let their local router decide to which of the PoPs to send each packet. That would also cover the case where a PoP is down and all traffic is routed via the remaining one(s). These users can also have cross-connections to other users (via radio or direct tunnels) and the routing remains correct.
That sort of thing can be accomplished with routing protocols like BGP, of course.
Along these lines, I might be interested in participating in a 44net network built to use a routed topology. Maybe it’s something like, we use iBGP among ourselves, and those with access to PoPs (like via Vultr etc), can manage access to the public internet on our behalf.
Someday maybe anyway
Get Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: John D. Hays via 44net 44net@mailman.ampr.org Sent: Thursday, May 26, 2022 6:02:34 PM To: Rob PE1CHL 44net@pe1chl.nl Cc: 44net@mailman.ampr.org 44net@mailman.ampr.org Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Another approach would be auto-failover between PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net <44net@mailman.ampr.orgmailto:44net@mailman.ampr.org> wrote:
Yes, that is also part of my design. An entry-level user can connect to a single PoP and get "their subnet" routed to them, and route all other Net44 space towards that PoP. Simple, static routing. A more advanced user can make multiple PoP connections and use BGP to send and receive individual subnet routes, and let their local router decide to which of the PoPs to send each packet. That would also cover the case where a PoP is down and all traffic is routed via the remaining one(s). These users can also have cross-connections to other users (via radio or direct tunnels) and the routing remains correct. -- John D. Hays Kingston, WA K7VE / WRJT-215
Of course, but the reason I proposed this was that when suggesting a PoP network where everyone would connect and send their traffic via probably 2 PoP hops to the destination was that there was the immediate reaction that "this would be so much less efficient" and "I want to send my traffic directly to the guy I am BBS forwarding to" etc. So in my design that is perfectly possible, you can setup a private tunnel to anyone and when using BGP that will automatically be taken as a shorter path. Of course it would even be possible with static routing. And indeed, a first level of fallback could be created using some list of PoPs to call and selecting an alternative when the first is unreachable. Will depend on the router software what is easier to achieve: two permanent connections and autorouting, or two connections with only one being active at any time. My point is that the such a network is much more flexible than the IPIP mesh we have now, which essentially is using static routing and cannot handle any alternatives.
Rob
On 5/27/22 01:02, John D. Hays via 44net wrote:
Another approach would be auto-failover between PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
Yes, that is also part of my design. An entry-level user can connect to a single PoP and get "their subnet" routed to them, and route all other Net44 space towards that PoP. Simple, static routing. A more advanced user can make multiple PoP connections and use BGP to send and receive individual subnet routes, and let their local router decide to which of the PoPs to send each packet. That would also cover the case where a PoP is down and all traffic is routed via the remaining one(s). These users can also have cross-connections to other users (via radio or direct tunnels) and the routing remains correct.-- John D. Hays Kingston, WA K7VE / WRJT-215
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I think the main issue in this endeavor is to attract more users to our network.
Proficient users may use whatever alternatives they like, and they have the necessary knowledge to do it.
The problem is the networking novice, which may have basic networking skills, but lack the "advanced" part, and of course the regular or occasional user, which requires plain network access, without backups, fall backs, roaming, fixed location independent addresses and other goodies, using SOHO class equipment..
For such users, a regional POP access using standard VPN technologies and optional standard routing protocols is a perfect opportunity to get a foothold in this domain while the POPs themselves provide network integration and backbone routing (no matter what the technology behind - it may well be our current mesh for the beginning, and various connection techniques to the POP really don't matter as long as they are well supported). The most important thing is that the access should be as plain and transparent as possible for a novice, and require the dumbest equipment possible for permanent access.
Advanced features may come late on a need to use basis, after the initial learning curve. Let's create momentum by expanding the user base first and worry about advanced user level stuff later, keeping the wizardry at POP level.
Marius, YO2LOJ
On 27/05/2022 11:52, Rob PE1CHL via 44net wrote:
Of course, but the reason I proposed this was that when suggesting a PoP network where everyone would connect and send their traffic via probably 2 PoP hops to the destination was that there was the immediate reaction that "this would be so much less efficient" and "I want to send my traffic directly to the guy I am BBS forwarding to" etc. So in my design that is perfectly possible, you can setup a private tunnel to anyone and when using BGP that will automatically be taken as a shorter path. Of course it would even be possible with static routing. And indeed, a first level of fallback could be created using some list of PoPs to call and selecting an alternative when the first is unreachable. Will depend on the router software what is easier to achieve: two permanent connections and autorouting, or two connections with only one being active at any time. My point is that the such a network is much more flexible than the IPIP mesh we have now, which essentially is using static routing and cannot handle any alternatives.
Rob
On 5/27/22 01:02, John D. Hays via 44net wrote:
Another approach would be auto-failover between PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
Yes, that is also part of my design. An entry-level user can connect to a single PoP and get "their subnet" routed to them, and route all other Net44 space towards that PoP. Simple, static routing. A more advanced user can make multiple PoP connections and use BGP to send and receive individual subnet routes, and let their local router decide to which of the PoPs to send each packet. That would also cover the case where a PoP is down and all traffic is routed via the remaining one(s). These users can also have cross-connections to other users (via radio or direct tunnels) and the routing remains correct.-- John D. Hays Kingston, WA K7VE / WRJT-215
44net mailing list --44net@mailman.ampr.org To unsubscribe send an email to44net-leave@mailman.ampr.org
44net mailing list --44net@mailman.ampr.org To unsubscribe send an email to44net-leave@mailman.ampr.org
Marius,
I fully agree with that. But as you have seen, when suggestions are made here to change towards such a network, there always is negative feedback from some people who just do not want to change, and bring up "advantages" of the current IPIP mesh to explain why we should keep it like that. That is why I tried to provide solutions to enable those people to come on board.
Probably the vast majority of users is well served with a single VPN tunnel to a single PoP somewhere in their network neighborhood, routing only their own subnet. They will never get involved in the "more advanced" topics like running multiple tunnels to either more than one PoP and/or to a friend, and using automatic routing protocols.
Having a local PoP to enable connections from end-users and have that PoP on the IPIP mesh (and on internet BGP), yes, that is what we have been doing here for many years. But in many other places, this local solution does not exist and new users are forced to setup an IPIP mesh node themselves, which as you know is possible but presents a lot of challenges.
Rob
On 5/27/22 11:43, Marius Petrescu via 44net wrote:
I think the main issue in this endeavor is to attract more users to our network.
Proficient users may use whatever alternatives they like, and they have the necessary knowledge to do it.
The problem is the networking novice, which may have basic networking skills, but lack the "advanced" part, and of course the regular or occasional user, which requires plain network access, without backups, fall backs, roaming, fixed location independent addresses and other goodies, using SOHO class equipment..
For such users, a regional POP access using standard VPN technologies and optional standard routing protocols is a perfect opportunity to get a foothold in this domain while the POPs themselves provide network integration and backbone routing (no matter what the technology behind - it may well be our current mesh for the beginning, and various connection techniques to the POP really don't matter as long as they are well supported). The most important thing is that the access should be as plain and transparent as possible for a novice, and require the dumbest equipment possible for permanent access.
Advanced features may come late on a need to use basis, after the initial learning curve. Let's create momentum by expanding the user base first and worry about advanced user level stuff later, keeping the wizardry at POP level.
Marius, YO2LOJ
On 27/05/2022 11:52, Rob PE1CHL via 44net wrote:
Of course, but the reason I proposed this was that when suggesting a PoP network where everyone would connect and send their traffic via probably 2 PoP hops to the destination was that there was the immediate reaction that "this would be so much less efficient" and "I want to send my traffic directly to the guy I am BBS forwarding to" etc. So in my design that is perfectly possible, you can setup a private tunnel to anyone and when using BGP that will automatically be taken as a shorter path. Of course it would even be possible with static routing. And indeed, a first level of fallback could be created using some list of PoPs to call and selecting an alternative when the first is unreachable. Will depend on the router software what is easier to achieve: two permanent connections and autorouting, or two connections with only one being active at any time. My point is that the such a network is much more flexible than the IPIP mesh we have now, which essentially is using static routing and cannot handle any alternatives.
Rob
On 5/27/22 01:02, John D. Hays via 44net wrote:
Another approach would be auto-failover between PoPs in client routers.
On Thu, May 26, 2022 at 10:59 AM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
Yes, that is also part of my design. An entry-level user can connect to a single PoP and get "their subnet" routed to them, and route all other Net44 space towards that PoP. Simple, static routing. A more advanced user can make multiple PoP connections and use BGP to send and receive individual subnet routes, and let their local router decide to which of the PoPs to send each packet. That would also cover the case where a PoP is down and all traffic is routed via the remaining one(s). These users can also have cross-connections to other users (via radio or direct tunnels) and the routing remains correct.-- John D. Hays Kingston, WA K7VE / WRJT-215
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
But the use of POPs does not preclude keeping the current mesh.
From the point of view of the existing users, POPs are just gateways in the mesh, announcing a bigger network, like e.g. a /16 for national services, maybe even a /16 via BGP if possible. Nothing changes at first, and established setups will continue to work, and there is no change needed to their configurations. Of course, if they want, they can alter their setup later on.
It is not changing/replacing existing functionalities, but adding to them.
At least this is how I would see such a development.
Marius
On 27/05/2022 13:04, Rob PE1CHL via 44net wrote:
Marius,
I fully agree with that. But as you have seen, when suggestions are made here to change towards such a network, there always is negative feedback from some people who just do not want to change, and bring up "advantages" of the current IPIP mesh to explain why we should keep it like that. That is why I tried to provide solutions to enable those people to come on board.
The disadvantage of the IPIP mesh it that it cannot cope with node outages or rerouting to users. So, when the IPIP mesh would be used as the backbone between the PoPs, the functions of PoP failover and redundancy by connecting to multiple PoPs or using a fallback mechanism (connect to an alternative PoP when one is unreachable) cannot be realized.
To have that, we need a (possibly partial) tunnel mesh between the PoPs, where a routing protocol like BGP is used between the PoPs so they can tell eachother about the connected users and their subnets, instead of the "static" system that the IPIP mesh uses. (where routing of a subnet to a PoP/gateway is fixed and determined by configuration only, not by network state)
So I think to have a real improvement in the network, the IPIP mesh as it exists now should be abandoned. Of course first the PoP network can be built first, then the users can be encouraged to move over, then the IPIP mesh can be shut down. Large announcements on the IPIP mesh would be moved first, end-users can follow later.
Rob
On 5/27/22 12:26, Marius Petrescu via 44net wrote:
But the use of POPs does not preclude keeping the current mesh.
From the point of view of the existing users, POPs are just gateways in the mesh, announcing a bigger network, like e.g. a /16 for national services, maybe even a /16 via BGP if possible. Nothing changes at first, and established setups will continue to work, and there is no change needed to their configurations. Of course, if they want, they can alter their setup later on.
It is not changing/replacing existing functionalities, but adding to them.
At least this is how I would see such a development.
Marius
On 27/05/2022 13:04, Rob PE1CHL via 44net wrote:
Marius,
I fully agree with that. But as you have seen, when suggestions are made here to change towards such a network, there always is negative feedback from some people who just do not want to change, and bring up "advantages" of the current IPIP mesh to explain why we should keep it like that. That is why I tried to provide solutions to enable those people to come on board.
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
**
*Der „44Net Assessment Survey“ ist jetzt auch auf Deutsch, Japanisch und Französisch verfügbar*
**
L’enquête d’évaluation de 44Net est désormais également disponible en allemand, japonais et français
44Net評価アンケート調査は、ドイツ語版、日本語版、フランス語版があります。
**
*--- *
*
Hello 44Net Mailing List,
We have now completed professional translations of the 44Net Assessment survey released on this mailing list. Please use either link below to access the survey in your preferred language. Translations of the original outreach message are included below.
http://survey.ardc.net/ http://survey.ardc.net/
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sourc... https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Source=website
We appreciate your patience and look forward to reading your responses!
Warmly,
Merideth & the ARDC team
Hallo 44Net-Mailingliste,
wir haben jetzt die professionelle Übersetzung der 44Net-Bewertungsumfrage abgeschlossen, die auf dieser Mailingliste veröffentlicht wurde. Bitte verwenden Sie die nachstehenden Links, um die Umfrage in Ihrer bevorzugten Sprache abzurufen. Nachstehend finden Sie die Übersetzungen der Originalbotschaft.
http://survey.ardc.net/ http://survey.ardc.net/
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sourc... https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Source=website
Wir danken Ihnen für Ihre Geduld und freuen uns darauf, Ihre Antworten zu lesen!
Mit freundlichen Grüßen,
Merideth und das ARDC-Team
Bonjour membre de la liste de diffusion 44Net,
Nous avons maintenant terminé les traductions professionnelles de l'enquête d'évaluation 44Net diffusée via cette liste de diffusion. Merci d’utiliser les liens ci-dessous pour accéder à l'enquête dans la langue de votre choix. Les traductions du message de sensibilisation initial sont incluses ci-dessous.
http://survey.ardc.net/ http://survey.ardc.net/
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sourc... https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Source=website
Nous vous remercions pour votre temps et sommes impatient(e)s de lire vos réponses !
Chaleureusement,
Merideth et l'équipe de l'ADRC
44Netメーリングリスト購読者各位
今回、このメーリングリストでリリースされた、44Net評価アンケート調査の専門家による翻訳が完了いたしました。以下のリンクを使用して、ご希望の言語で本アンケート調査にアクセスしてください。元のアウトリーチメッセージの翻訳は、以下にございます。
http://survey.ardc.net/ http://survey.ardc.net/
https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Sourc... https://corexmsbvjmmfm79wvgq.qualtrics.com/jfe/form/SV_em45824jWUOCXhI?Source=website
本アンケート調査へのご協力ありがとうございます。ご回答をお待ちしております。
敬具
Merideth & ARDCチーム
*
On 5/19/22 12:42 PM, Rosy Schechter - KJ7RYV via 44net wrote:
Hello 44Net Mailing List,
There has been a lot of discussion on this list about the state of 44Net. Some people like how it works, some would like to see an upgrade. In order to make an informed decision that takes a variety of viewpoints into account, ARDC is conducting an assessment. For the first phase, we’ve put together a survey, which we'd love for you to fill out. Our aim is to get input from as many people as possible to help influence the network’s next chapter.
Click here to go to the survey:
survey.ardc.net
(Please note that the above is a redirect.)
We expect that it will take around 15 minutes to complete.
The survey is currently being translated into French, German, and Japanese, shoud you prefer to take it in another language. Thank you for your patience as we complete professional translations. We’ll post them here as soon as they are ready!
It’s important to note: the survey is not a voting mechanism - it’s a research tool. We’ll also be conducting interviews and focus groups with a subset of users. Results from all research will be shared publicly (personal information excluded) on ampr.org.
If you have questions about this survey or are interested in being interviewed or part of a focus group, reach out to us at any time: contact@ardc.net. You can also follow the assessment’s progress by signing up for our newsletter.
Thank you in advance for sharing your input - we look forward to reading your responses!
Warmly, Rosy & the ARDC team
Hallo 44Net-Mailinglist,
auf dieser Liste wurde viel über den Stand des 44Net diskutiert. Einige Leuten sind mit dem gegenwärtigen Stand zufrieden, andere würden gerne ein Upgrade sehen. ARDC führt eine Bewertung durch, um eine fundierte Entscheidung treffen zu können, die eine Vielzahl von Gesichtspunkten berücksichtigt. Für die erste Phase haben wir eine Umfrage zusammengestellt, und wir würden uns freuen, wenn Sie diese ausfüllen würden. Unser Ziel ist es, von so vielen Menschen wie möglich Beiträge zu erhalten, die als Grundlage zur Gestaltung des nächsten Kapitels des Netzwerks dienen werden.
Klicken Sie hier, um zur Umfrage zu gelangen:
survey.ardc.net (Hinweis: Dies ist eine URL-Weiterleitung)
Wir gehen davon aus, dass das Ausfüllen der Umfrage etwa 15 Minuten in Anspruch nehmen wird.
Wichtiger Hinweis: Die Umfrage ist kein Abstimmungsmechanismus, sondern ein Forschungsinstrument. Darüber hinaus werden wir mit einem Teil der Nutzer Interviews durchführen und Fokusgruppen bilden. Die Ergebnisse der Forschung werden auf ampr.org öffentlich zugänglich gemacht (ohne personenbezogene Informationen).
Wenn Sie Fragen zu dieser Umfrage bzw. Interesse daran haben, an einer Befragung oder einer Fokusgruppe teilzunehmen, können Sie sich jederzeit an uns wenden: contact@ardc.net. Sie können die Fortschritte der Bewertung auch verfolgen, indem Sie sich für unseren Newsletter anmelden.
Wir bedanken uns im Voraus für Ihren Beitrag und freuen uns darauf, Ihre Antworten zu lesen!
Mit freundlichen Grüßen, Rosy und das ARDC-Team
Bonjour membre de la liste de diffusion 44Net,
Beaucoup de discussions ont eu lieu dans cette liste à propos de l'état de 44Net. Certaines personnes aiment la façon dont les choses fonctionnent, certaines aimeraient voir une mise à niveau. L’ARDC réalise une évaluation afin de prendre une décision éclairée tenant compte d'un éventail de points de vue. Pour la première phase, nous avons préparé une enquête à laquelle nous serions heureux que vous répondiez. Notre objectif est de recueillir des retours du plus grand nombre de personnes possible pour nous guider vers le prochain chapitre du réseau.
Cliquez ici pour accéder à l’enquête :
survey.ardc.net
(Veuillez noter que le lien ci-dessus implique une redirection.)
Nous estimons que cela prendra 15 minutes environ.
Il est important de noter que cette enquête n'est pas un outil de vote, mais un outil de recherche. Nous réaliserons également des entretiens et mettrons en place des groupes de discussion avec de plus petits groupes d’utilisateurs et utilisatrices. Les résultats de cette enquête seront partagés publiquement (données personnelles exclues) sur ampr.org.
En cas de questions sur cette enquête ou si vous souhaitez être interrogé(e) ou faire partie d'un groupe de discussion, contactez-nous à l’adresse : contact@ardc.net. Vous avez également la possibilité de suivre les avancées de l’évaluation en vous abonnant à notre newsletter.
Nous vous remercions par avance de partager vos commentaires, nous serons heureux de connaitre vos réponses !
Chaleureusement,
Rosy et l’équipe de l’ARDC
44Netメーリングリスト購読者各位
44Netの状況について、このメーリングリストでたくさんの討議がなされてきました。機能方法を好む方、アップグレードを希望している方もいます。さまざまな視点を考慮した上で、十分な情報に基づく決定を行うために、ARDCでは評価を実施しております。この第一段階として、アンケート調査を作成いたしました。皆様からご回答いただければ幸いです。ARDCの将来に良い影響をもたらすために役立つよう、できるだけ多くの方々からご意見を伺うことを目的としております。
アンケート調査に進むには、ここをクリックしてください。
survey.ardc.net
（上記のリンクに転送されます。）
このアンケート調査の所要時間は約15分です。
ご注意いただきたい点は、このアンケート調査は投票機構ではなく、調査ツールであることです。一部のユーザーの方々には、インタビューやフォーカスグループも実施いたします。アンケート調査結果（個人情報を除く）はすべて、ampr.orgに公開されます。
本アンケート調査について何かご質問がある場合、またはインタビューやフォーカスグループに参加することに興味をお持ちの場合、いつでもcontact@ardc.netまでご連絡ください。また、ニュースレターに登録して、進捗状況を追跡することもできます。
あなたのご意見を共有いただけることに前もってお礼を申し上げます。ご回答をお待ちしております。
敬具
Rosy & the ARDCチーム
-
charlie＠theboenings.com -
Chris Smith -
Dave Gingrich -
David Andrzejewski -
John Burwell -
John D. Hays -
Kris Kirby -
Marius Petrescu -
Mark Stevenson -
Merideth Stroh -
Paul Sladen -
Rob PE1CHL -
Rosy Schechter - KJ7RYV -
Steve L -
Tony Langdon