On 29/12/20 8:47 pm, Ruben ON3RVH via 44Net wrote: Hmm, I was on this mailing list but just got unsubscribed, with no explanatory text (when one would normally get if it was due to bounces, etc). -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

This is exactly the sort of thing we would like to have the TAC get together for. Why don’t any interested parties email me and maybe we can finally get this going. If we’re going to do this properly it will needs some structure and the extra noise it will generate should be moved to a separate list. Chris - G1FEF

Le 29/12/2020 à 16:19, Marius Petrescu via 44Net a écrit : +1 That would be our first job : define a new commun infrastructure with regional / country-wide POPs. That's what some of us are already doing. Here, in Corsica, we've been using OpenVPN for site to site and user connections, and we are now testing Wireguard (due to lots of odd things with OpenVPN). Our goal was for the user access protocol to be 100% plug-and-play. It must work through any NAT Internet box with not-necessarly-fixed IP. Our endpoints are using OpenWRT. I don't really agree. IMHO, the key for mass adoption is the availability of ready-to-use images for tiny computers such as Raspberry Pi. Distributions such as Pi-Star have been very popular for building digital mode hotspots and repeaters. Same for AllStar in the analog world. And there are many other examples. IMHO, the best solution for me would be the availability of ready-to-use images/firmwares, to be flashed on an inexpensive device, and providing immediate AMPRNet IP addressing with near-to-zero configuration This can only be achieved if we all use the same scheme. Of course, we don't want to "lock" anybody to a specific protocol or platform. And we don't want to prevent anybody from experimenting new things (which is our primary goal, HI). But if we have a common framework all over the world, I think implementation of end-user solutions such as Plug and Play OpenWRT routers, or integration of AMPRNet routing in existing distributions for Raspberry Pi and clones, would be easier. 73 de TK1BI

There where such proposals back in the 90's, with fantastic nonexisting results. First, assigning IPs without establishing a network topology first is futile. You need to be able to create subnets and group users together by topology criteria to ensure routing, not by some arbitrary callsign rule. It would be mononeuronal to maintain hundreds of /32 addresses instead of handling a few /24 subnets and delegating the management to the subnet admins. Think of it like an ISP: You hand out a static IP to a user, as long as he is your client. If he chooses a different provider, he will get a new IP and you would reclaim yours. Second, these allocations should be done on a need to do basis, with a user getting an IP for his use depending on where/how he plans to log in/connect. It is useless to assign IPs to users which do not intend to use them anyway. Also, unused addresses should be reclaimed and should not linger around indefinitely. An IP is just an IP, it does not belong to a specific callsign. The correspondence between callsign and IP being done at DNS level. It is not needed for a user to have a arbitrary assigned perennial IP address, and that address should be changed according to the network needs. Marius, YO2LOJ On 29.12.2020 21:03, Roland Schwarz via 44Net wrote:

On 30/12/20 10:59 am, G1FEF via 44Net wrote: OK, that explains the odd unsubscribe notification I got today.  All good. :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

Sorry for cross posting, but this mail is an answer to something in the general thread, but with an idea that I think belongs to the "new generation network" list. I will not cross post in the future (without good reason) Here the good reason is to give motivation to continue on the new list. On 30.12.20 at 00:15 wrote Marius Petrescu via 44Net: This was a very different situation than today. Internet was in it's infancy. I rember having used ISDN modems at that times. This is technically correct, but possibly is not the best use of 44 address space in a connected world as we have today. ... I do not agree. If I read the FAQ it says that we still have over 6 million 44 addresses unassigned, and we most likely will be unable to assign them due to the lack of request by hams. So, since I am rather new in the 44 world, let me talk about what I expected from the net before I (partly) found out what it seems to be, followed by a proposal what I think could be a "new generation network": My a priory expectations: ------------------------- 1) 44net is a net made by HAMs for Hams. 2) If I connect to a 44 address it will be HAM content that I access, i.e. according to similar rules as for radio. 3) There is some general mechanism by which I can discover activities of other HAMs. (the equivalent of a CQ call) Oddly only 1) seems to be true. My observations: ---------------- Most of the questions seem to be dealt with from a network operators perspective. I still have a hard time to find basic user information: Open questions: --------------- 1) Is there a document of polite behaviour on 44 (a 44tiquette)? E.g. is it ok to port-scan address ranges for services, machines-online, crawl the ports 80 of the 44 net? 2) Is there a policy what it means to hold a 44 address? E.g. could a service like echolink rely on the fact that it is a HAM user when 44 is inbound and avoid the need for a password to discriminate HAMs? 3) Is there a directory where I can register my interest for communication during my station is online (not all HAMs may run their radio 24/7) 4) How can I find out if a host is addressable from the internet and from within 44? ok this one I discovered myself: dig -x 44.x.x.x and when it is in the portal it is, but again I have to guess the exact details, because there seems to be a country in between the portal part and ampr.org. Why is this interesting? It would be helpful for an end user, because I guess this could be used for a firewall rule that would not allow such addresses to go on radio. My ideas for evolution: ----------------------- I think understanding 44 net as an overlay network would be way more useful to HAMs than it is today. Sure overlay networks can be built by other means as well. Converting 44net however, gives unique possibilities since it will not loose it's rooting abilities within the outer net. Also there already is a big community around this net and converting to an overlay net could go gradually. Also I believe there will be quite some technical challenges to master. This could be an interesting matter for experienced people like you. What would it need: A) A clear and easy to understand policy. B) A technical implementation. About B) first: (I am a technician ;-) Marius you said it would be detrimental to have millions of /32 hosts. Sure, if every router needs to whole table yes. But what if we had a service that could learn routes on demand? Similar than what a DNS lookup does? We possibly could repurpose DNS entries for this. I.e. lookup tunnel endpoint IP by 44net IP. This is just one idea, I am sure you have a better one! About A) A clear policy of the dos and donts. We also should help those that spent many hours climbing up towers mounting radio equipment useable by other HAMs i.e. 44ers. Such a policy therefore should express a clear preference for stations accessing 44 by radio. (This is just my opinion, this should and must be discussed in deep of course.) I am in hope that some of these ideas sound interesting to the 44net community. I am very curious about the pros and cons of my proposal. (Please don't beat at me if this already has been discussed somewhere in length, and has been discarded for some good reason. In this case pls just point me to the correct place in the archives.) vy 73 de roland, oe1rsa -- __________________________________________ _ _ | Roland Schwarz |_)(_ | | \__) | mailto:roland.schwarz@blackspace.at ________| http://www.blackspace.at

On 30/12/20 7:20 pm, Roland Schwarz via 44Net wrote: Some interesting ideas. My question here is why do you think that?  I have a /24, which I am hoping to put on air properly at some stage in the near future.  When it's all up and running, I'd need to be able to assign address (most likely through DHCP or similar - they could be static or dynamic).  Now if everyone locally has a /32, how are they going to communicate with each other?  Also, how would routing work in the core of such a network of /32s?  I for one don't want to have to route via some gateway in the USA or Europe.  That would add at least 200mS RTT to me.  Some form of routing hierarchy is still needed for best performance, though for many hams (it's not an acronym, so lower case is correct), a dynamic IP associated with their local RF net or access router would suffice. Yep. I would expect the same.  For example, my BGP routed /24 that's on the public internet is dedicated to services for amateurs, which include an IRLP reflector, several Echolink conferences and well over 100 Echolink proxies. That would be nice.  There's no directory that I'm aware of.  I've only ever found out about services by word of mouth. Interesting idea, though as the password is stored in the client, I don't see what it would achieve, and the client still has to log into the Echolink servers, if others are to connect to it. Sounds useful. Still have to find the /32 somehow.  And I still see a lot of suboptimal routing happening here, unless there's some other protocol in the core doing clever routing.  Being in VK, I see the effects of distance related latence all the time - sadly, the speed of light is finite, and it's significant enough to impact performance on a global scale.  If I have to communicate with a site on the other side of the world, I only want to traverse that path once, not 2 or 3 times, getting into and out of some tunnel.  In other words, enter the tunneled part of the network at a point close to here, and emerge close to my destination.  Something the existing mesh does fairly well (but it does have other issues, as has been pointed out by others). -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

On 12/31/20 10:47 AM, Roland Schwarz via 44Net wrote: But there already is the BGP protocol which on internet manages to maintain the route tables for hundreds of thousands of routes and which should easily manage to maintain the routes in our network even when done to /32 level. We do this inside 44.137.0.0/16 now and we have about 270 routes. In other similar networks they have like a few thousand routes. Cheap routers handle that easily.  No need to invent something that is "more efficient" and again kill the advantage that you can use off-the-shelf routers instead of having to tinker with general-purpose computers running specialized images. The advantage of routing to the /32 level is that every address can connect from every place using every method.  Sure you can gain some advantage by strictly subnetting everything and e.g. limiting the addresses by POP, but that introduces a dependency on that POP.  If the POP is down the users cannot connect to the network anymore, which worries some people.  But when you just route every end-user address or subnet, the user can just connect to another POP and still get his traffic on his fixed address. And of course there can always be hybrid solutions.  We can advertise our entire network as a single 44.137.0.0/16 route and handle all detail routes ourselves, when we like.  Of course that would mean a user could not connect somewhere else. Rob

Well, FWIW, your first bullet below (reliable DMR, EchoLink, APRS network) REQUIRES the public Internet to work at all, both outbound AND inbound. Dave K9DC

On 31/12/20 8:47 pm, Roland Schwarz via 44Net wrote: Yes, I'm usually on the wrong end of global RTT delays when using online services, unless it's a Google or Facebook with a distributed CDN that has POPs all over the world, so topological routing is an issue of high importance to me. That assumes the case of a single device wanting to access the network.  That would also lead to suboptimal routing locally here, because I have multiple devices on the network (4 or 5 currently on 44.x).  There is one way that could work, using something like ZeroTier to do the "last mile".  That wouldn't give you a /32 address, but instead an address on a virtual LAN, of a size specified by the network admin.  But while ZeroTier does have a lot of desirable qualities, like working transparently through NAT (and that can be tweaked), and using the best route it can find (two ZT hosts on the same physical LAN will quickly find the direct path between them, and route over that), it doesn't meet the criteria of running on routers, AFAIK.  ZeroTier may be available on OpenWRT (I don't know if that's the case), but I highly doubt you'd find it on Cisco.  It is available for Linux, Windows, Android and iOS, and is open source. I use ZT myself.  It allows me to be on the same virtual LAN as my VPSs, which makes moving data between all sites much easier.  And when I travel, I can connect back here both securely and without worrying what NAT timeouts will do to idle sessions. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

On 1/1/21 1:14 PM, John Gilmore via 44Net wrote: Without specific reference to ZeroTier I think it should be clear that whatever encryption we use to transport packets between routers ON INTERNET is completely irrelevant, as long as the packets are delivered out of the routers connected to radio in plain text. I.e.: user plaintext -> radio -> gateway -> encrypted packet via internet -> gateway -> plaintext to radio. The gateway routers encrypt and decrypt the packets, the users see only plaintext. Use of encryption in this way should not affect "amateurs are not allowed to use encryption" rules, right? When we can agree on that, we don't have to come back and discuss and re-discuss every use of encryption. Rob

Am 01.01.21 um 13:37 schrieb Ruben ON3RVH via 44Net: We need a facility by which a link operator is able to put a tag on the link that basically says what is legal on a particular link because what is legal in a particular country best can be decided in that country. In the end the link operator is responsible that only legal content is on his link, be it radio or not. oe1rsa -- __________________________________________ _ _ | Roland Schwarz |_)(_ | | \__) | mailto:roland.schwarz@blackspace.at ________| http://www.blackspace.at

On 2/1/21 12:05 am, Rob PE1CHL via 44Net wrote: That will be easy for me.  I'm not interested in supporting Internet access (beyond what systems like Winlink offer), so anything outside 44:0.0.0/9 and 44.128.0.0/10 would be blocked at my gateway.  ip route and iptables will do the trick. :) Beyond that, yes, it's up to individual amateurs to play by the rules (i.e. regulations). :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

On 1/1/21 11:27 pm, Rob PE1CHL via 44Net wrote: That was the unstated assumption in my message.  ZeroTier was only for Internet transport.  As would any option be.  Agree totally Rob.  I see no reasons not to use encryption on the Internet and plenty of reasons to use it for our internal links.  The proper use of encryption will further isolate our network from arbitrary Internet traffic (packet injection, etc).  Gateways have to properly decapsulate the traffic before forwarding it over the air in the clear.  Perhaps I should have stated this, but it was so obvious to me that I didn't even think to mention it. :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

Le 30/12/2020 à 00:15, Marius Petrescu via 44Net a écrit : Previously, we were only individuals working in non-profit mode on our free time, and with different approaches in different contexts. Now, we have professionals, and ability to hire people if needed. They can help in keeping track of all our remarks, synthesize them, and help us work in a more structured manner. We have no more reason not to obtain results, HI :-) 73 de TK1BI

Am 30.12.20 um 12:36 schrieb Marius Petrescu via 44Net: ... ... Uhm, I was trying this route once ago, but with very unsatisfactory results: For one the lotw certificate had issues with the root certificate, i.e. lotw and VPN gateway didn't use the same. Then the VPN tunnel appeard to be as beeing not very stable. But technology has advanced since then. Perhaps I should give it a try again. 73 oe1rsa -- __________________________________________ _ _ | Roland Schwarz |_)(_ | | \__) | mailto:roland.schwarz@blackspace.at ________| http://www.blackspace.at

G1FEF via 44Net <44net(a)mailman.ampr.org> writes: +1 I (and I suspect the rest of the ARDC board) look forward to seeing the TAC re-vitalized in 2021 and some plans emerge for actions we can take to improve 44net operations. Please do contact Chris and/or Rosy if contributing to the TAC is something you want to do and have time for! And, as Rob so correctly points out, improvements that involve some on-going operational expense are completely valid to consider now. 73 - Bdale, KB0G