> You can also host it in vultr. I would have to check, but IPIP should
not be a problem there and it costs indeed about 5$ per month
Toussaint TK1BI is also using that, isn't it? It seems one can even
advertise BGP space there.
I see they also host in Amsterdam. In fact, when we would deploy a VPN
server in all 16 datacenters
they offer we already would have covered most of the world. But that is
another topic, this query
is mainly intended for my personal colocation server.
(it serves my mail, my website, an IPIP gateway for testing, and an
echolink proxy server for testing)
Rob
> No it is not possible with my ISP. To run any local services is a
> violation of the ToS agreement. The ports and services they close they
> will not open. I've tried. They also incorporate a watchdog on all
> sockets that destroys them after so many minutes of "birth". This kills
> client services such as VPN, SSH, etc. Web services often aren't
> affected since most web elements are downloaded within 300 seconds +/-.
I would go away. How do you get IPIP working over that? Probably not
working correctly either.
> IMHO the dependency is a moot issue. If I used your VPN I'd be dependent
> on you... but you're suggesting that you can still reach me if my ISP's
> edge router dies and this is not true. Also if I were on your VPN, I
> would have to travel all the way to the netherlands and back half way
> across the US to reach say Indiana. So very inefficient.
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.
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.
Then it will improve your connectivity to internet, and connectivity
to other AMPRnet systems is the same or similar.
Furthermore, you can buy a 4G router and use that as a backup for when
your ISP link or -router dies, and you can switchover all your routing
to that path automatically within seconds. Even when its address is
dynamic and probably even when they have such idiotic policies as your
ISP appears to have (because the VPN will just re-establish when it fails).
Rob
Now that the space isn't legacy we can begin to use ARIN services.
Delegated RPKI definitely needs to happen. What about SWIP?
Looking forward to helping anyway I can. I believe most of the lift for
RPKI would be for the portal programmer.
Regards,
Scott. ki4cuw
> 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
> 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.
> 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
> 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
> 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
> >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
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
