44net July 2019

44net@mailman.ampr.org

86 participants
91 discussions

New mailing list '44NGN' - was '44 net connectivity'
by Brian Kantor 23 Jul '19

23 Jul '19

As a few people have requested, I've created a new mailing list for discussions of the architecture of the Next Generation Network for AMPRNet, such as have been recently discussed here under the subject line of '44 net connectivity'. Feel free to join, and to invite your colleagues to join at <https://mailman.ampr.org/mailman/listinfo/44ngn> Welcome! - Brian

1 0

Re: [44net] 44.192.0.0/10 sale
by Rob Janssen 23 Jul '19

23 Jul '19

> >/And these addresses are normally included with your internet service for free. / > One thing to note however is that in many cases, any ports or protocols > blocked by the ISP on IPv4 are also blocked on IPv6. This is what makes > getting a block from a tunnel broker beneficial. Of course you will not need to have some unusual protocol like IPIP operational over that IPv6 connection, and usually the plain TCP and UDP ports can be opened without problem so it should be possible to run the usual services. A tunnel broker introduces an additional dependency and additional weird routing, so when people complain that using some VPN servers across the world instead of a tunnel mesh is objectionable, they certainly should not use an IPv6 tunnel broker! Rob

4 3

Re: [44net] 44 net connectivity
by Rob Janssen 23 Jul '19

23 Jul '19

> That is true, but only if we are the only ones using private ASNs. > But if happens that some people already uses private ASN for other > purpose, they would be in trouble connecting to 44net... because there > would be collisions. > I see no point of using public IP addresses and route them using private > ASNs. It may be that I do not understand BGP well. It is important to note that the routing in this overlay network, let's call it BGP44 from now, is running as a separate BGP instance that is not combined with BGP announcement to internet or private use of BGP. The BGP44 instance will only distribuite the routing info for AMPRnet subnets, similar to what is now in the IPIP routing table. Also, even though there could theoretically be collisions, in practice there is not much risk because there are 94,967,295 available AS numbers in the space that we use. That is 8 times more than the number of IP addresses we have left. Rob

3 2

Re: [44net] Time to restructure the network?
by Rob Janssen 23 Jul '19

23 Jul '19

> If anyone in Europe fancies announcing their own 44 /24 from a VPS / > ISP and doesn't have their own ASN, I can help out with that element. > Happy to apply for ASNs via my RIPE LIR account for folk from the HAM > community for free. Takes 2 or 3 days for RIPE to approve the > paperwork and issue the ASN, under current RIPE billing policy these > do not cost anything. While this is of course always welcome, please do understand that this is not related to the current discussion! What I am proposing here is to deploy an overlay network (VPN tunnels) to route the AMPRnet around the world and to connect users to it. The autorouting within that overlay network could be done using BGP. It could also be done using OSPF. This use of BGP is NOT related to announcing someone's subnet on internet using BGP! For that, you could require an AS number, amongst other things. (it is also possible that it can be announced using the AS number of your ISP) However, to operate our own overlay network, a group of routers that interconnect using BGP over VPN tunnels, we do not require AS numbers from a LIR! We just use private AS numbers. In the 32-bit AS number space there is a large range of private AS numbers that we can (and already DO) use for that. We already have an allocation scheme to split this range across countries, so we do not need a central registry for them either. Maybe we should refer to this usage of BGP as BGP44, to make clear that it is not related to the use of BGP on internet? Of course, BGP and BGP44 are the same protocol running on standard hardware, but the usage is different. Much like an intranet and the internet use the same protocols, but their usage is different. So while this contribution is of course always welcome, please (those who do not completely understand the discussion) note that it is not related to what we are discussing. That being said, once there is a deployment of VPN routers like I propose, it will be much easier to have parts of AMPRnet announced from the datacenters where these are located. That could be considered part 2 of the project. Rob

2 1

Civility on this mailing list
by Brian Kantor 23 Jul '19

23 Jul '19

On Tue, Jul 23, 2019 at 09:52:29AM +0200, Marc Williams via 44Net wrote: > I suppose recent examples would be personal attacks on named individuals. While those are never welcome, as mailing list manager, I don't like the idea of banning those persons from participating in the list because, however unlikely, they may be able to contribute usefully to discussions here. I feel that correct mailing list etiquette would be, when someone is out of line, or indeed, out of control, for list members to send him a private email reminding him that civility and rational discussion achieve more than frenzied, often hastily composed diatribes do. That said, it is possible for repeat or particularly vile offenders to be subject to moderation or struck off or banned from the list. So please, folks, no matter how angry or upset a posting here gets you, at all times remember to be civil to your fellow list members. Thank you. - Brian PS: to discourage trolls and bots, it's my policy that when a newcomer is first subscribed to the list, his 'mod' flag is turned on, so that his initial posting is reviewed before being forwarded to the list. I recognize that this causes a delay, but I believe its in the best interests of our subscribers. As soon as a valid posting is received, the 'mod' flag will be turned off. Many other mailing lists have this same policy.

1 0

Re: [44net] 44 net connectivity
by Rob Janssen 23 Jul '19

23 Jul '19

> But to be honest I would say a bigger deterrent to using 44 net is the nature of some of the discourse on here. I can't claim to be a Saint myself but honestly some people's dialog is frankly appalling. > Yes there is some improvement to be made around technology but also some rules around acceptable use of the mailing list should go hand in hand with it. It is unclear to me what you are referring to. Maybe you should be reminded that part of the people here do not have English as their first language. Their language vocabulary is limited and it is difficult for us to express the subtleties that you may want to see. Rob

2 1

Adding VPN server at UCSD ?
by R P 23 Jul '19

23 Jul '19

Hi there Now that we have a lot of money in the pocket may we consider installing a VPN server at UCSD to allow user connecting AMPRNET with VPN in addition to the IPIP tunnel ? I myself will be more then happy to move our networks from IPIP connectivity to VPN (or any other more sophisticated technology) . Thanks Forward Ronen - 4Z4ZQ

6 10

Re: [44net] Time to restructure the network?
by Rob Janssen 23 Jul '19

23 Jul '19

> Personally, I love the idea of allowing the network to be more inclusive by allowing connections other than the current IPIP one. Rather than replace IPIP, I would suggest that we keep it and just allow people to act as hubs for those that are behind NAT/Limiting firewalls, etc. This is what we already have working, and others have that too. A local VPN server that is connected to IPIP (and in our case BGP too). However, such a setup is a bit complicated because the IPIP mesh is not well supported on many router types, and having the two different network types integrated in the same router also is kind of tricky. Not everyone gets that right: all routes have to be in the same routing table and evaluated from more-specific to less-specific. But you still need to handle cases where multiple routes to the same subnet (using different protocols) can exist. In some cases, people have resorted to having multiple routing tables and searching them in a specific sequence, but that does not work correctly in some cases. Also there is the issue of determining the correct source address. Sometimes such gateways send traffic with a non-44net source address through an IPIP tunnel, which of course is unwanted. So my proposal is to drop the IPIP mesh to remove this additional complexity, and make the system easier to rollout and maintain. > While I think BGP would be great, it adds questions like: can people announce their own non-44 space, can people use their own ASNs, how will we allocate ASNs, how do we confirm people are announcing space actually allocated to them. One thing we can do, is look at DN42 and how they work. Their network is similar to some of these suggestion with the exception that they use private space. Some of those topics have already been addressed and resolved before. For example w.r.t. the AS numbers, we have agreed to use an allocation scheme for private AS numbers so this can be delegated to individual regions without chance of collisions. The scheme is to use "42"+iso country designator+5 digits, where these 5 digits can be subdivided in a region specific way. Large countries have several iso country designators so there should be ample space using this scheme. Here we use 42204+3digits+2digits where a router in our 44.137.aaa.bbb/16 subnet gets AS 44204aaann where nn=bbb/16. Of course this network is only meant to distribute net44 addresses, our routefilters filter announcements outside that. But you can announce space for your friend inside net44. Actually the same as the current IPIP situation. Indeed very similar to what DN42 does. Rob

6 5

Re: [44net] 44.192.0.0/10 sale
by Rob Janssen 22 Jul '19

22 Jul '19

> >/I don't suggest that you would use only our VPN server, you could /> >/connect it in addition to some other to have additional redundancy /> >/and maybe a more efficient path to western europe. / > Why would I want or need to go across the Atlantic when it's not > necessary since IPIP is working fine for me. Because we are trying to draft a new solution that would not work only for you, but also for others. You do not seem to be interested in that. > >/You (or ARDC, using their money) should eastablish one or more VPN /> >/servers on the eastcoast and/or Canada, then you connect there and /> >/those servers connect back to UCSD or maybe even advertise some of /> >/the locally assigned subnets on internet BGP. / > I don't see where this would be a reasonable allocation of funds by > ARDC. Come on, it costs like $5-$10 per month per location to host such a service. And that is only when it is paid for. Last time I asked here for volunteers to host an echolink proxy farm, there were like 10 volunteers that would do (and did) it for free. It is likely that they would add such a VPN server feature to their already existing hosted system, if we would kindly ask it to them. > If ARDC were to allocate funding I would rather see it go into research > of new techologies. We as hams are not leaders anymore, we're lemmings. That would be a complete waste of money! As is clearly shown by this entire discussion, there is nothing that hams hate more than to change something that they think is working well for them, even without considering how it works for others. Again, it is much like the discussion about CW. Large groups of hams still believe that CW is the most efficient mode and can be received when all other modes fail. Utter bullshit, of course, but it was like that 50 years ago so it still must be true today. > >/Then it will improve your connectivity to internet, and connectivity /> >/to other AMPRnet systems is the same or similar. / > How will that improve my connectivity to the internet? I can and do get > around blocks by my ISP just fine - once I know what they are and I take > full advantage of the 200Mbs link I have for a residential circuit. The connectivity to internet from your 44net systems, of course! That would now go via UCSD and when you could get a local VPN server which also announces the state's network allocation on BGP, it would be faster than the trip via UCSD in many cases. > I could get another circuit with 4G backup and shell out almost > $2,000/yr additional as a business circuit but why? For people on this > list to try and tell me what to do with my circuit that I spend my money > on? I think not thank you. That's when a ham community turns into a ham > dictatorship. It is always amazing to see people on this list toggle between "but there are single points of failure in this solution, I do not like that!" and "don't tell me to do things the way you like" after explaining them how to work around those single points of failure. Apparently they bring that up only to put a spanner in the works of any discussion about change, not because they really care about it. Also I think your solution is way too expensive. My home internet connection (with fixed IPv4, native IPv6 /48, 100 Mbps, unlimited data, no silly filtering) costs me less than $600/year and it includes 4G backup up to 1GB/month. Rob

3 3

Re: [44net] Adding VPN server at UCSD ?
by Rob Janssen 22 Jul '19

22 Jul '19

> No need to use UCSD. Cloud based server(s) work just fine. Places like > AWS drip with bandwidth. Is AWS able to run an IPIP gateway? I am currently trying to migrate an IPIP gateway from the "Hosted Raspberry Pi" that it is now to a VM that is being offered as a replacement, but it turns out that the "Apache Cloudstack" that this (and apparently many other) hoster uses to deploy VMs is unable to pass other network traffic than TCP and UDP. (and replies to outgoing traffic) Good enough for OpenVPN and will probably work with IPsec and other VPN protocols, but not suitable for an IPIP gateway that also accepts incoming traffic. I am now looking for a solution. Of course I can make a VPN to our gateway, but this system was a test environment for an IPIP gateway. When IPIP goes away, I no longer need it. However, I could also use it to draft an example of how to setup a VPN service on a Linux machine. Rob

3 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net July 2019