On 29/12/20 8:47 pm, Ruben ON3RVH via 44Net wrote:

I'm all for standardization! There was already a mailinglist created for the new routing infrastructure thoughts and ideas a while ago by late Brian at our request. IIRC that was the 44ngn mailinglist. I do recall some folks not wanting to have yet another mailinglist to follow/comment on

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).

On 29 Dec 2020, at 09:01, Toussaint OTTAVI via 44Net 44net@mailman.ampr.org wrote:

Hi,

Le 29/12/2020 à 00:34, Rob Janssen via 44Net a écrit :

...

But well, it has all been discussed several times already.

Some of us already built alternatives to the good old IPIP mesh in different locations of the world. But nobody does exactly the same thing. Could we create a sub-group, start thinking together about what we would like for the future, define some kind of "standardization", and agree to migrate our nodes to that future "standard", while keeping compatibility with existing networks ? If it works and is easier to use, then many others may follow…

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 :

The main issue is to separate regular users from a backbone infrastructure.

+1

What is done in the infrastructure and how it is interconnected is not important to the end user. It can be mesh, direct routing, whatever.

That would be our first job : define a new commun infrastructure with regional / country-wide POPs.

From my point of view, It should be the choice of the operator of the POP to decide what user access protocol they choose. For example L2TP is still supported on many devices and is a good candidate, and even the old PPTP will do.

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.

There is no need to find a single universal solution for everything. If the backbone works (and the current mesh could be the base of this backbone, with simple users just opting out as other connection options become available).

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:

Marius,

On 29.12.20 at0 16:19 wrote Marius Petrescu via 44Net: ...> The main issue is to separate regular users from a backbone infrastructure. ...

Sure, but there is something special about 44net: I believe a 44 address should be like your callsign in the internet. This is a selling point, and if I read the howto in amprnet where it says that more than 6million addrsses are still unassigned I believe eberything should be done to assign every ham a fixed IP.

So any technical solution should keep that in mind, I believe.

73 roland, oe1rsa

On 30/12/20 10:59 am, G1FEF via 44Net wrote:

As an aside, the old 44NGN mailing list was retired some months ago due to lack of use. Today I cleared the old membership out and have re-purposed it for the group we are putting together to discuss this topic, as this seemed appropriate.

So further to Bdale’s, Rosy’s and my request, if you would like to be part of the group, which will effectively be a sub-committee of the TAC then please let us know and I can add you to the new, revived list. You can email me, or contact@ampr.org mailto:contact@ampr.org

OK, that explains the odd unsubscribe notification I got today.  All good. :)

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:

There where such proposals back in the 90's, with fantastic nonexisting results.

This was a very different situation than today. Internet was in it's infancy. I rember having used ISDN modems at that times.

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.

This is technically correct, but possibly is not the best use of 44 address space in a connected world as we have today.

...

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.

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

On 30/12/20 7:20 pm, Roland Schwarz via 44Net wrote:

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.

Some interesting ideas.

On 30.12.20 at 00:15 wrote Marius Petrescu via 44Net:

...

There where such proposals back in the 90's, with fantastic nonexisting results.

This was a very different situation than today. Internet was in it's infancy. I rember having used ISDN modems at that times.

...

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.

This is technically correct, but possibly is not the best use of 44 address space in a connected world as we have today.

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.

My a priory expectations:

1. 44net is a net made by HAMs for Hams.

Yep.

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.

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.

3. There is some general mechanism by which I can discover activities of

other HAMs. (the equivalent of a CQ call)

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.

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?

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.

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)

Sounds useful.

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!

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).

On 12/31/20 10:47 AM, Roland Schwarz via 44Net wrote:

I absolutely agree! What I wanted to point out is that there might be basically two expectations about 44 addresses. Topological routing as you have pointed out is one of it.

Let me elaborate on the second idea: lots of isolated /32 hosts or /28 subnets: Sure, if I need to load the entire routing table to every node, this will not scale. But a single node will not need the full routing table typically. Only a few entries are interesting at a single time. So if you have a dynamic lookup facility of the gateway address, you could populate your routing tables on demand. This facility could be realized by means of a distributed hash table, so there is no single point of failure. And yes the optimal routing is done by the core internet in such a use case.

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 Jan 1, 2021, at 11:43, Janko Mivšek via 44Net 44net@mailman.ampr.org wrote:

Maybe a concrete example of our current and future S5net in Slovenia together with our expectations from broader 44net community could help.

As you can see from schema of current and planned links:

https://groups.io/g/nbp/topic/s5net_stanje_in_plan/79358609

we are building nationwide radio network, linking our hills with DMR repeaters into a fully redundant network, as much as possible independent from public internet. Main goals:

• reliable DMR, EchoLink, APRS network,
• emergency communications for our communities,
• for radioclubs and individual radioamateurs,
• open for experimentation and innovation into the future.

On 31/12/20 8:47 pm, Roland Schwarz via 44Net wrote:

Tony,

On 30.12.20 at 22:28 wrote Tony Langdon via 44Net:

...

...

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.

I absolutely agree! What I wanted to point out is that there might be basically two expectations about 44 addresses. Topological routing as you have pointed out is one of it.

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.

Let me elaborate on the second idea: lots of isolated /32 hosts or /28 subnets: Sure, if I need to load the entire routing table to every node, this will not scale. But a single node will not need the full routing table typically. Only a few entries are interesting at a single time. So if you have a dynamic lookup facility of the gateway address, you could populate your routing tables on demand. This facility could be realized by means of a distributed hash table, so there is no single point of failure. And yes the optimal routing is done by the core internet in such a use case.

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.

On 1/1/21 1:14 PM, John Gilmore via 44Net wrote:

(2) ZeroTier uses encryption to tunnel packets around the Internet. That works great for everybody except for hams whose packets are transmitted over amateur frequencies. We certainly can't build anything that requires encryption into the basic 44net infrastructure (as we evolve it forward), since our whole goal is moving packets over amateur frequencies.

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:

Even wifi links may and should use encryption, that is not ham radio related neither

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

On 2/1/21 12:05 am, Rob PE1CHL via 44Net wrote:

On 1/1/21 1:55 PM, Roland Schwarz via 44Net wrote:

...

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.

The operator can mostly do that using firewall rules. When an operator believes that https is illegal under their local rules, they can just block port 443 in their access point. Of course it will be difficult to cover everything that way, but it will be impossible to have full control.

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). :)

On 1/1/21 11:27 pm, Rob PE1CHL via 44Net wrote:

I.e.:

user plaintext -> radio -> gateway -> encrypted packet via internet -> gateway -> plaintext to radio.

That was the unstated assumption in my message.  ZeroTier was only for Internet transport.  As would any option be.

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.

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. :)

Le 30/12/2020 à 00:15, Marius Petrescu via 44Net a écrit :

There where such proposals back in the 90's, with fantastic nonexisting results.

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: ...

I think Rob, PE1CHL, had some approach to offer 44net VPN access using LOTW certificate for authentication if I remember correctly... Maybe he could tell us more on how people where attracted to it.

...

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

G1FEF via 44Net 44net@mailman.ampr.org writes:

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.

+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