44net

44net@mailman.ampr.org

1 participants
3194 discussions

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

21 Jul '19

> The IPIP mesh may be non-standard, but it is distributed, without any single point of failure. To get between two points, the two gateways have to have IP connectivity to each other. That's it. The two end-points can troubleshoot directly. > But every proposal I've seen on this list involves adding at least two other ham points of failure. For example, I would presumably connect to some other ham's BGP node and the other end of the connection would do the same. Why? Mainly because it makes it an "outgoing" connection for most people. That means it is not affected by NAT, CGNAT, dynamic addresses, inflexible router firewalls, etc. Getting IPIP to work bidirectionally often requires to setup the internal system as "DMZ" (which in home router speak means that it will receive all incoming traffic not matched by the NAT engine). This can only be done for a single system, and even then it often does not work correctly (e.g. it receives only TCP/UDP and not other protocols). You should not under-estimate the difficulty that IPIP is causing for more and more people. As an example, I am currently trying to migrate my physical colocation server to a VM. The service offered by the hosting company uses Apache Cloudstack. While the VM itself works fine and can load the ipip module, it turns out that Cloudstack cannot allow IPIP ingress in its firewall settings. So I will have to look for another hosting option... By putting VPN servers in datacenters and having the users connect to them, you avoid those problems. Also, using the topology I propose, there is no requirement that the entire network runs a single tunneling protocol or a single topology. Only the peers need to support the same protocol. And it can be a symmetric protocol like IPIP or GRE when you like that better. Also, there is no requirement that there only be a single connection! You can setup crosslinks to wherever you like. There will rarely be traffic to all IPIP mesh peers. There are more than 500 gateways in the list, and when I look in our stats I see we have had traffic to only 23 of them in the past day. Most active gateways can probably point out at most 5 peers to which they have regular traffic. You can setup crosslinks to those. And this system is not dependent on a central RIP sender! Every node is active in distributing its own subnets and receiving the others. There is no need for a portal that registers the subnets, they only need to be configured in the gateway routers. A portal could still be useful as a management system for VPN accounts. Especially at the major hubs, the users need to have a VPN account that assigns them a point-to-point address, and the BGP on that router needs to be configured with the AS number on that address. This could be done using some form of portal and a program that configures the router using its API. That is not mandatory. On our gateway the addition of new users still is done manually. I once have added a large number of skeleton BGP peers and VPN accounts, and when a new user requests a connection I find an available one, enter the username (callsign), a random password, and enable it. In the BGP peer I enter the AS number and enbale it. Done. There always will be some dependencies, but they do not need to be single-point and with some money available they do not need to be only relying on volunteers and unclear situations where some company hosts a service only because a worker there has arranged it. I think it has big advantages over the system we have now. Rob

2 1

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

21 Jul '19

Well, I think there are enough examples of how to do it (also already doing it within AMPRnet), lots of people who can contribute knowledge and will volunteer to help, the only thing we lack here in this group is someone (with the appropriate authority) who says "Lets' do that!" and gets everyone moving. That is why these discussions usually go on for a couple of days here, then die out, and nothing ever changes. We are still running the same system as 25 years ago, with only the addition of RIP auto route distribution. This gets worse over time, as those who would like to change things see this and leave, and in the end we only have a number of old hats left who don't change anything. That does not improve our reputation... sometimes newcomers ask "why do we use that method when it is so difficult to implement and it can all be done so much easier", and the only response can be "don't ask...". Rob

4 3

ipset matching
by Rob Janssen 20 Jul '19

20 Jul '19

Because of the current changes, people want to change firewall entries that check an address to be "within AMPRnet". This of course used to be simple, like "-s 44.0.0.0/8" as a matcher in Linux iptables. I already read remarks like "well I just need to split those rules in two, one for 44.0.0.0/9 and another for 44.128.0.0/10". This is not really required. And it is not so easy when the match was in a "not" context, like: ! -s 44.0.0.0/8. Also it makes the firewall rule list longer and maybe less intuitive. Maybe not everyone knows how ipset can be used to match more than one address in the same rule. The ipset program creates "address sets" that can be lists of addresses, networks, portnumbers etc that can then be referenced in a match. For example, create an address set that contains the new AMPRnet ranges: ipset create AMPRnet hash:net ipset add AMPRnet 44.0.0.0/8 ipset add AMPRnet 44.128.0.0/10 ipset add AMPRnet 44.224.0.0/15 (the last one of course has to go, but I kept it there to give our German friends some time to renumber) Now instead of "-s 44.0.0.0/8" you can use: -m set --match-set AMPRnet src Instead of "-d 44.0.0.0/8" it would be: -m set --match-set AMPRnet dst And instead of "! -s 44.0.0.0/8" you still can use the form: -m set ! --match-set AMPRnet (src or dst), so there is no need to change the structure of the rules to work around the problem of not having a "not" operator. Of course you need to arrange for the above commands to be run before the iptables rules are loaded. No problem for me as I have always done that in an own shellscript not using distributor's solutions that use iptables-save or similar. (I prefer to have the possibility to have comments, use variables holding certain addresses and networks, etc) In MikroTik RouterOS the same feature is available as "Address list" in the firewall. You can create an address list and load those subnet values: /ip firewall address-list add address=44.0.0.0/9 list=amprnet add address=44.128.0.0/10 list=amprnet and then use that in filter rules by using Src.Address List instead of Src.Address for the match. Rob

1 0

CIDR Syntax Reminder! 44.192/10 != 44.192.0.0/10
by Jeremy Cooper 20 Jul '19

20 Jul '19

Hey everyone, if you are like me and you’re working to update your firewall rules to carve out the recent subnetwork sale, I’d like to remind you that the proper way to refer to the portion of the network that has been sold is this: 44.192.0.0/10 The converse, “44.192/10” actually expands to "44.0.0.192/10” in some software, and this is probably not what you want! -Jeremy

1 0

Re: [44net] AMPRNet Address Sale
by Rob Janssen 19 Jul '19

19 Jul '19

> But hey, if you'd really like to go back to only one ACL entry, we could > also sell 44.128/10. Then you'd only need 44/9. <-- (note smiley) Actually there would be plenty of space with just the /9 when it had not been all allocated to the US in the beginning. OTOH, had that been the case, we probably had been tempted (or forced) to sell it off (or just release it) much earlier. Rob

2 1

Re: [44net] AMPRNet Address Sale
by Phil Karn 19 Jul '19

19 Jul '19

Let me propose you an idea although it's an off-topic in this list. We have a serious problem in amateur radio regarding digital development. It is software quality, platform independence and openness. I fully agree. If I have any say in this, *all* hardware and software development funded by our grants must be open sourced and made freely available. If you want to keep it proprietary, don't do it with our money. Some of you may have heard of FCC RM-11831, which would effectively ban any air interface on the ham bands that isn't publicly documented. I filed comments stating that while I am personally sympathetic to the principle that all amateur air interfaces should be open, trying to enforce that now with a legal rule would have serious unintended consequences. All three VHF/UHF digital voice modes (D*Star, DMR and Fusion) would be banned because they all use unpublished voice codecs proprietary to Digital Voice Systems Inc. I argue that a much better way to deal with proprietary air interfaces on the ham bands is to beat them at their own game: develop superior open source alternatives and persuade hams to adopt them. This has already been done for low-bit-rate voice coding: VK5DGR has developed the excellent Codec2 and made it freely available. So here is our chance to seriously pursue development of advanced, 21st century digital communication systems that, from the beginning, will be free and open. 73, Phil

2 1

Re: [44net] amprhosts update
by Rob Janssen 19 Jul '19

19 Jul '19

> Seems that mails to ampraddr at ucsd.edu <https://mailman.ampr.org/mailman/listinfo/44net> requesting IN A is not answering. > Or something changed ? Please help Long ago it has been changed to ampraddr(a)gw.ampr.org Rob

2 1

Re: [44net] A few thoughts on recent developments
by Rob Janssen 19 Jul '19

19 Jul '19

> i) Of note: Brian did ask for donations to offset these expenses which > were largely ignored. At that time I actually attempted to make a donation but it got stranded in the payment process. (I did not want to open an account at a US banking company for it, and I did not understand the peculiarities of their banking system. Here, you would simply ask the receiver for their bank account number and transfer the money to it, but there the account number apparently is something you need to keep secret so Brian would not give it to me. Not something particular to ARDC, with AMSAT it went the same way...) Rob

1 0

amprhosts update
by Pedro Converso 19 Jul '19

19 Jul '19

Seems that mails to ampraddr(a)ucsd.edu requesting IN A is not answering. Or something changed ? Please help 73, lu7abf, Pedro

1 0

Re: [44net] IPv6 adoption (was: address sale)
by Heikki Hannikainen 19 Jul '19

19 Jul '19

On Fri, 19 Jul 2019, Phil Karn wrote: > On 7/18/19 23:12, Holger Baust wrote: >> Is there a IPv6 Block registered to HAMs? ... > Most ISPs that natively support IPv6 also support prefix delegation. > They'll typically give you a /64 that you can hand out on your LAN with > DHCPv6 or stateless autoconfiguration (e.g., advertise with the Linux > radvd daemon). Some will give you more than one /64 if you ask, but > nothing actually says you must use a /64 only on a single LAN. You can > always divide it further if you like, and with twice as many bits in the > host part of an IPv6 /64 as in the entire IPv4 address space, this can't > be hard. Some home router firmwares seem to insist on /64 for using the delegation, so it might be tricky on some setups. But should be possible to put together at least on a Linux box with some creative configuration. >> The usage of IPv6 has some problems. First a lot of software has to be >> recompiled or completedly rewritten, > I don't think so. IPv6 has been out for a very long time. Right, for most applications "completely rewritten" is not true; just some small parts need to be rewritten in software which uses older low-level network socket APIs. Applications using higher-level networking APIs (such as "fetch this URL for me please" APIs in libraries and operating systems) don't need to be touched as the code behind those APIs has already been fixed years ago. I've got a lot of experience in IPv6 support validation and configuration at $work, and with my hobby systems too, so I know this from practice. Applications specifically dealing with things as IP address allocation or DNS data manipulation: yes, those need a lot more work. Such as the amprnet address allocation portal. Not a small task. >> the other problem sits between >> several chairs and keyboards. (as in a lot of other internet companies) Right, but this thing needs to be done eventually. The world is moving on. >> Some developers, admins and ops do not understand the new addressing or >> routing and some hardware vendors do not give IPv6 a priority in >> developing... > > As I said, IPv6 is much more widely supported than many people realize > and the only problem is just getting people to turn it on. It's a good idea to check this graph yearly, stare at the growth between 2015 and today for a while, do a little mental extrapolation from there, and think of the consequences: https://www.google.com/intl/en/ipv6/statistics.html Some 25% to 30% of client traffic to Google use IPv6 *today*. Up from 5% at the beginning of 2015. There's some weekly variance due to office/home use if you zoom in (weekends: more IPv6 traffic towards Google). It's getting turned on a lot right now. The wheel is rolling, the momentum is there. As for the difficulty: I didn't find it that hard. The addresses are harder to remember. More cut-n-paste work, but a lot of it can be automated, and DNS help once you bother to set it up. But the routing is... basically just the same as IPv4, just with more bits! Commercial hardware hardware and software vendors are moving pretty fast, and have mostly implemented IPv6 already. All major network operators, ISPs and such absolutely *require* IPv6 support when purchasing anything, and have done so for quite some time. Smaller vendors are lagging more (think of the APRS iGate appliances, remoterig boxes, and other gadgets made for small audiences). But I suspect the ease of setting up direct remote access to those gadgets, thanks to the lack of NAT in IPv6-enabled residential networks, will get that ball moving soon. Just open up the firewall - the thing will have it's own public IPv6 address just like that, no need to do port forwarding! - Hessu, OH7LZB / AF5QT

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net