44net

44net@mailman.ampr.org

3196 discussions

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

22 Jul '19

> I don't think BGP has a problem working over IPIP tunnels. In the end it is just a TCP connection to one or mre endpoints. In principle yes, but unfortunately the current IPIP tunnel implementation handles both the tunnel establishment and the routing. The routing is static. You cannot setup BGP sessions because you do not know the other side's address and AS. Possibly one could work around that by adding the 44net endpoint address and the BGP AS number of each tunnel gateway, so the endpoints could connect eachother for the BGP routing. However that would be another major change and I'm not sure everyone would want to BGP peer with everyone else. That could also introduce new scaling problems. Rob

2 1

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

22 Jul '19

> Oh, I misunderstood maybe. I considered that the Israelian BGP subnet will be announced from the VPN Server’s ASN. It will not go to UCSD and traffic to it will not come via UCSD. > Having UCSD in the middle for non-North America is 200+ ms bonus per packet, so most people want to avoid it. He repeatedly indicates that it his beyond his capabilities to arrange such things. However, once we have a flexible overlay network in place, he could connect to some more nearby gateway and try to get it arranged that this gateway also announces the Israelian subnet. Then he has a shorter roundtrip to internet without having to set it up himself.

1 0

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

22 Jul '19

> What I would do is the following: > > Ask the IP space owner (person allocated to) to send an e-mail to Brian, requesting the block to be advertised over BGP (needs to be /24+, or collection of networks /24+) and Cc me in this e-mail. I reply with the ASN, route objects that need to be created, etc. Brian hopefully approves the request. > > Afterwards, I advertise the /24 via BGP to the Internet. > > Then, I arrange with the IP space owner how the space will be router to them. I can support OpenVPN, PPTP, L2TP, GRE, IPSec, etc. I think he means "after I connect to a VPN server in the USA or e.g. in Greece, how do I make it send the traffic for my Israelian subnet to me over that connection". That is by far not that complicated. He only needs to connect to that VPN server, he will get an IP from the address space of that server, and setup BGP over that connection (using an agreed-upon private AS number) and announce his own Israelian subnet. The BGP protocol will then exchange this information with all other interconnected VPN servers and they will all route his subnet to the VPN server he is connected to, and that will route it to him. Traffic from internet will still be routed to UCSD as part of the default network announcement, and the router there will first route it to the VPN server he is connected to, then to him. No need to announce his /24 on internet explicitly! Of course this gets more difficult when the IPIP mesh is kept in place and is used as backbone. Then the VPN gateway he connects to needs to add his subnet to its list of handled subnets, via the portal. This means he can connect only to a single VPN server and have working routing. When that server goes down, he would have to arrange that the portal information is changed, the subnet being removed from that gateway and added to another. Without IPIP, he could simply connect to two or more VPN servers at the same time, and as long as one of them is working he has connectivity to everywhere. Rob

4 3

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

22 Jul '19

> How do i manage to get my allocated addresses from someone else VPN ? > what about transferring a whole network block via a VPN server ? specially to a home which uses a dynamic IP ? That is why the proposal is not so simply use a VPN, but to use a VPN and run BGP on top of that. The transfer of your network block to the VPN is handled by BGP. The internet address of the home VPN does not matter, you connect to a VPN server and present some ID (e.g. callsign and password) and the VPN server knows who you are. Those topics precisely are the improvements in the proposed system, over the existing IPIP system. Rob

1 0

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

22 Jul '19

> For example, I am able and willing to provide such service, however there hasn’t been any place I can really publish that information. I think this is a generic topic that could be one of the first things to solve within the AMPRnet. When we get new users, we immediately get the question "now that I am connected, what can I do?". Such a VPN server comes before that, but it is another case of information lookup. We could construct some website within AMPRnet where you can look for such information. What interesting websites are there to visit, who is offering SIP telephony, etc. Of course it can be done in a Wiki (it already exists), but such information quickly gets outdated. People post their new services, then they lose interest and the services stop working, but never update the information anymore. Also, access to the Wiki is often problematic: when open to everyone it will have to be monitored and corrected when things go wrong, when access control is used it adds the burden of creating and maintaining trusted user accounts and it is a hurdle for registering services. So we could come up with some way to keep such a services database with some form of automated maintenance. E.g. a user who wants to have his services in the database somehow creates a description in a standard format on some standard URL and submit this once to the central system, which then regularly queries this file and adds info to the listings, plus it automatically drops it when it cannot retrieve the data for some time. It should be easy to add information, but still it should be in a standard format so it can easily be shown in tables. Of course there already is HamnetDB but it is focused mainly on the network layer. Something similar could be made for services, plus it should guard against outdated information as mentioned before (HamnetDB also suffers from that problem) The wellknown WebSDR site "websdr.org" has an example of what I mean. The list of SDRs shown there is always actual. The sysop of the SDR puts its information in the configuration, and the running SDR sends it to the central system automatically (unless you turn that off). Rob

1 0

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

22 Jul '19

> >Again, while there are over 500 gateways in the current network with tunnels > >between all of them, there is no way they are all going to be in use. > > It doesn't matter how many are in use. If my ampr routing table has 50 or 500 or 5000 routes, who cares? That is true for the Linux or JNOS situation. However, people want to use the equipment they have available, and on many other systems there has to be a separate virtual interface for every tunnel. Scripts exist for e.g. MikroTik and Cisco routers that manage this, but they have to create a large number of tunnel interfaces and they hit limits of NVRAM size and others. With 5000 endpoints there will certainly be issues! > >Wiring them up for everyone really makes no sense, and introduces a scalability > >problem that would become real when it were easier to use the system and we had like > >50000 participants instead of 500. > > Do you have evidence for your statements? Yes. See above. I also once tried to use a left-over Cisco router and its NVRAM already was too small for this. > https://qrznow.com/us-amateur-radio-population-grows-slightly-in-2018/ > It looks like from 2014 to 2018, the US ham population only grew 4%. > And I haven't monitored it closely. But it seems to me that the size of amprnet has remained about the same (+/- 100 or so) for the last 10 years. > So who/where are these 49,500 other gateways? They probably are either not interested, or they are unable to overcome the problems setting up an IPIP gateway. When we introduced the easier OpenVPN connection method here, there was a flurry of requests for certificates and there now are 200 certificates active. And that is only for one small country. Rob

1 0

A few thoughts on recent developments
by John D. Hays 22 Jul '19

22 Jul '19

The sale of 44.192.0.0/10 took most of us by surprise and for some it somehow feels like a coup. Here are a few thoughts I have had, since the announcement: 1) ARDC (Amateur Radio Digital Communications), is a California Nonprofit Public Benefit Corporation and has existed since the 11th of October 2011. ARDC has had control/ownership of 44.0.0.0/8 that whole time. This corporation allows for continuity of control vs. a single person being the designated "owner" of the address space. This is a good thing. (E.g. there is no probate should the “owner” die intestate.) a) Brian Kantor did the work and paid the expenses to move control from himself as an individual to the non-profit organization. To my understanding, he is the President and CEO, who under the direction of the Board of Directors manages the day-to-day operations of the ARDC i) Of note: Brian did ask for donations to offset these expenses which were largely ignored. 2) There are no “voting members” in the corporation, nor according to the by-laws <https://www.ampr.org/wp-content/uploads/Bylaws-2019-03-03.pdf> are there any procedures for voting beyond those afforded the Board of Directors. As such, there was no requirement to get approval from anyone outside of the Board of Directors. 3) There are no “shareholders” to be consulted in the transaction. 4) Since no individual or individuals can claim to have property rights to the address space beyond the ARDC, nothing was stolen. 5) Negotiations for the purchase and sale of tangible assets often require a certain degree of privacy. Public disclosure is a two-edged sword, it can help or hurt the interests of the seller and/or buyer. 6) As reported in communications from the Board, some non-disclosures were required for the transaction, among them the price and buyer identity. a) The controlling entity can be discovered easily using *whois 44.192.0.0/10 <http://44.192.0.0/10>* b) Based on known market values, this transaction likely produced the mid to high tens of millions of dollars for the ARDC. i) Splitting the address space further actually would provide less value to the buyer and less money to the seller. Based on estimates given me by a buyer, the collection of 65 thousand /24 in a /8 would only return 65% of the price of the entire /8. 7) The proceeds are going to be used to further Amateur Radio, specifically through grants, scholarships, and funded studies. Which would not exist without this action. If administered properly, this will be a monumental boon to Amateur Radio. a) I know some of the board members, and of those whom I know I am confident they will manage this process well and honorably. i) That doesn’t mean their decisions will be universally accepted. ii) I have served on the technical advisory committee for ARDC for years and if asked will help with review of applications. b) To this point I am not aware of any officer, board member, or committee member receiving compensation for their work. They are volunteers. 8) 75% of the /8 address space was retained and only one block out of the 44.192.0.0/10 had been allocated. See https://portal.ampr.org/networks.php a) Of the remaining 12 million addresses, less than half have been allocated, and a tiny fraction are actually in use. b) Even though I and others have advocated for more utilization of the address space and provided tools, tutorials, etc. this address space has been sorely underutilized. 9) As others have mentioned, this is an excellent time to reexamine the structure of the network and modernize it. a) Deprecate the IPIP tunnel mesh b) Update firewall rules, replacing 44.0.0.0/8 with similar rules for 44.0.0.0/9 and 44.128.0.0/10 c) Adopt BGP and VPNs (or similar strategies) for interconnection and routing. d) Develop better management tools (e.g. money allows hiring out improvements to things like http://portal.ampr.org) including DNS/rDNS delegation. 10) There were some operational issues overnight such as reverse DNS. Major ones have already been resolved and the others can be worked through. No matter how well planned, these things can happen. 11) This will not be reversed. One can involve oneself in second guessing and fighting it or one can step up and help ARDC come up with appropriate processes to provide a perpetual fund for Amateur Radio research, education, and outreach. tl;dr – It’s a done deal, work with it. Become active and take the initiative to improve the network. -- John D. Hays Kingston, WA K7VE

8 7

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

22 Jul '19

/> From my point of view, any interconnection technology that requires /> going through a third point (e.g. external OpenVPN server) likely won't > fly with me. Odds are that any such interconneciton is going to be a > long way from here and add unacceptable latency. Ideally, where direct > connections are possible, a mesh topology, like the current IPIP mesh is > what I'd like to see, regardless of underlying technology. There is no reason why you cannot have some VPN servers in datacenters in Australia, and connect them to the system and interconnect them in a mesh fashion. Then everyone can connect to their closest server and you have fast local connectivity, combined with ease of access. When, in addition, you arrange for the subnets involved to be BGP announced on internet, you will have fast internet connectivity as well, without a roundtrip via UCSD. While this is already possible with the current system, it is much more complicated to implement it and it can only be done on a select number of router types. > Obviously, > there will be corner cases, such as endpoints stuck behind CGNAT, which > may require a relay point external to them. For me, I'd rather beat my > router into submission and get that direct connection (like I have with > IPIP). ;) As several people have written, may users are not network architects and have limited knowledge about networking. And there may be many more who are interested in joining the network but have been unable to do so, because of lack of knowledge and/or lack of a suitable internet connection. Making the system easier to access may get us many more participants and after that we may ask ourselves "why did we live with that complicated IPIP system for so long"? Here in the Netherlands, there are 16 registered IPIP gateways (some of them are not actually operational), and 36 active VPN connections with BGP. Plus at this time there are 14 active OpenVPN connections (endpoints not using BGP) out of 220 registered accounts for that. So 50 "new technology" connections vs at most 16 old IPIP connections. That should be clear. There used to be more active connections, it is on a decrease again. Probably after some time the users start asking "what is the benefit of being on this network, what service is it offering that I don't have on plain internet". That is something we should be working on as well. Rob

1 0

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

22 Jul '19

> But you also say "There is no need for a portal that registers the subnets, > they only need to be configured > in the gateway routers." > > I haven't seen a technical write-up of what you propose. But the statement > above tells me that those who aren't interested in the putting up with the > new problems the overlay hubs would create have lost the simplicity we have > now. The routing of the subnets is not something the user would have to manage, that is what BGP does automatically. There is no need to register them. Every gateway tells its neighbors what subnets it has locally, and this information is passed around the entire overlay network. > It's easy enough to say things like "you can set up crosslinks to wherever > you like". But without the central registry, we lose the simplicity we have > today. Today, we download a file and run a script. Done. Direct > connections to everyone else. No middle men. No added latency. No added > complexity. No added troubleshooting difficulty. No added dependence on > some volunteer at the hub who may or may not be available when needed. As I wrote, to have that it would require an additional protocol like Cisco DMVPN which unfortunately is proprietary and not available in most (if not all) of the inexpensive routers that radio operators want to use. > Now if your proposal included the following, it would truly be solving a > problem for some people with causing a problem for others: > > 1) For folks who can't support direct connections, let them use a VPN > connection to a hub of their choosing (as you appear to be proposing) > > 2) *** BUT *** leave the central registry in place, and augment it so that > when you sign up for a hub, your subnets are still published to all other > gateways as reachable through the hub. > > 3) Therefore, those who can support direct connects but are not a hub can > still see a full registry and automatically create direct links/tunnels to > all other gateways (whether they are individual gateways or hub gateways) > and routes to all subnets behind all other gateways. I think the minor problem of "now some paths are two hops while they would have been direct in the current system" is very minor compared to the many issues there are with the current system. When we want a system that anyone can easily connect to without being a network export, the system I propose provides that. When you do not want that, because it takes away the artificial hurdles "that everyone has to overcome", of course you could object to such changes. It is similar to the situation of no-code licenses. People who already had passed the CW exam were objected to removing the requirement for new licensees, with similar reasoning. Again, while there are over 500 gateways in the current network with tunnels between all of them, there is no way they are all going to be in use. Wiring them up for everyone really makes no sense, and introduces a scalability problem that would become real when it were easier to use the system and we had like 50000 participants instead of 500. A system with regional hubs, while still offering the capability to cross-connect, is much more extensible. Cross-connects require manual intervention because the situation has to be examined. As the new system does not require the IP address of the participants to be static, allows them to be behind NAT, behind a firewall, etc, it has to be decided what type of connection is made, which direction the connection is made, etc. E.g. when one of the two has a static address and the other one dynamic, it is best to connect from the dynamic to the static address (and re-make the connection when the dynamic address changes). When they are behind NAT, it is possible to use a VPN that can cross NAT. Right now, such stations simply cannot participate, and with a new system they can. Rob

3 2

Formal notice of my resignation from ARDC Technical Advisory Committee
by Bryan Fields 22 Jul '19

22 Jul '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 In light of the recent theft from amateur radio, I cannot continue to be part of ARDC. I was a technical committee member for several years, at least since 2014 or so, and while the TAC members wished to accomplish much, not much happened. I will give credit for reverse DNS as we worked to get that delegated to BGP operators properly, and my allocation at 44.98.254.0/24 was the first subnet to have it working. I've recently asked about RPKI, DNSSEC, and even made some noise regarding SWIP. In every talk I've given I've mentioned the resource amateur radio has in 44/8 and how very special it is. Protect the IP space and use it, just as get on and use the bands to protect them. Understand this is likely 50M+ USD for this space paid to ARDC, and has exposed 44net to ARIN control. RDNS seems to have been broken as well. I call for a full public accounting of these monies, and outside public audit of ARDC. Brian Kantor must resign and we must demand a clear ethics policy with self-inurement and cross dealing between organizations prohibited. Best 73s and it was a pleasure helping the community where I could. - -- Bryan Fields, W9CR Former ARDC TAC member 727-409-1194 - Voice http://bryanfields.net -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl0xQu4ACgkQYTmgYVLG kUDRkhAAqpST8VkCAyipaj496C0bO3wjArJKvIookeQYOAqGqYl2wtHxC6zWBEeG zYfolJ4zVOku91RRIP2x/PtTdWLJ8PSpWNVxLWDcb8ofVZ7p8aRTsqCx0nWko18c HKE6FJ1Qfp+NmTeOWrBc7/CWd/7FPJseTVA5oOq9L4VOTrdXUF0DuvzNpcGTihST XO2Mnv0A5a5+5ih+5yeus/mgmmbwSSB9jBQQbZ/wBWLq+wPLnd6rBjBVsZrsOY1G Kr88enrMbrK78h7+9OCM+o19Dz5rItNxXz87o8UfeqNHMldYqMMhXWiMjFjWvvNJ phILyuvjElkh+fgoqJ+tdXyavnteuVJm0lpOKEsNpgpKkw+QQw4QwsJxoAIY9j85 gSa9v1BIwhx+H7r8K2vl/GMdbd81G8fBgVi5c55czIa52LqlX6uAyIm9/iQWiEdA Ob06JxCvszc+DEuRE5xdonN4NpUqIMOPmrz7FB6gigN2u43J8eIt0NdwjaRfIY0c MLd0g4F/9LaGSCo+cDvDhfghYyVJL8yj74RMggiIkJXUDcrLZxlp7o61nXEmPOhS 2zY3yDe485fDvcdr40uDINDt05oBwK1PjEf6ZO02LuO4c6DPVifBGO1gPc3Fovzr +C95bM5SPoeyPC8WWZEHJIG/75n1R5yUYFfHWo49KLGngqioGYo= =0LLk -----END PGP SIGNATURE-----

5 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net