44net July 2019

44net@mailman.ampr.org

86 participants
91 discussions

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

Re: [44net] 44.192/10 route looping observation
by Rob Janssen 19 Jul '19

19 Jul '19

> I just noticed that traceroutes from my home to, e.g., 44.192.0.1, get > stuck in a routing loop within the rr.com network. Apparently they have some default routes in a loop... My ISP returns a !N Rob

1 0

44.192/10 route looping observation
by Phil Karn 19 Jul '19

19 Jul '19

I just noticed that traceroutes from my home to, e.g., 44.192.0.1, get stuck in a routing loop within the rr.com network. (I'm on Spectrum Cable, formerly Time Warner Cable which branded its service as "roadrunner" (rr.com). I suppose this means Amazon isn't BGP advertising these addresses yet. Traces to, e.g, 44.0.0.1, 44.64.0.1 and 44.128.0.1 all behave as expected. Just an observation. Phil

2 1

Re: [44net] 44/8
by Bryan Fields 19 Jul '19

19 Jul '19

This is a below an email I sent to the NANOG list. On 7/18/19 10:57 PM, Majdi S. Abbas wrote: > > What's interesting about this is it was not an ARIN allocation, > and the ARDC folks are not the original registrant. This IANA /8 was > initially delegated to a community, not an organization. > > So, to the individuals listed in the blog, that I've excerpted > below, what do you have to say about this? > > Brian Kantor > kc claffy > Phil Karn > Paul Vixie This is par for the course with ARDC. I was a TAC committee member (I resigned in disgust just 15 min ago), and the board has failed to inform anyone this was happening. I discussed this prior as we could lease it, do something with it, make some money from it, and was 100% shot down. This has always been Brian Kantor's private little thing ever since he took over administration of it. This take over was before ARDC existed, and ARDC was never structured to be a proper community focused organization. I'd addressed this at TAPR meetings and NANOG with Brian and KC before. This also over looked the huge conflict of interest in KC being a board member of ARDC and Network Telescope getting a feed of 44/8 direct at no cost. This 44/8 announcement and UCSD routing broke connectivity to directly connected BGP subnets for years. My concern as an ARDC supporter an member is now no planning in the community for this, many people assume 44/8 is going to be licensed amateurs (I have many firewalls with permit 44/8 in them), and no accountability of what ARDC is doing. I believe with Brian retiring from UCSD he's looking for a job and being a board member of a well funded 501(c)3 can be a lucrative job. Also it's 100% broken reverse DNS for all of 44/8. :golf clap: This was theft from the community it was meant to serve. -- Bryan Fields, W9CR Former ARDC TAC member 727-409-1194 - Voice http://bryanfields.net

2 1

Reverse DNS broken
by Michael Fox - N6MEF 19 Jul '19

19 Jul '19

Folks, I'm sure folks will want to express their outrage about the address sale for months. In the meantime, let's focus on what we can control. How do we get reverse DNS working again for the part of 44/8 that wasn't sold? Michael, N6MEF

6 9

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

19 Jul '19

> But setting up Marius' script on Mikrotik is easy as pie and it > configures the rest "automagically" whereas configuring BGP on a tik, > although easy for those of us that do such things daily, is not that > easy for non network-technical folks Actually, when you think that setting up Marius' script on Mikrotik is easy, you already know enough about MikroTik to make setting up your router as a VPN client to one or a couple of routers on internet and configuring BGP on those VPN links much easier than that. It would be very easy to write a howto for doing that which includes sample configuration where you only need to fill in some fields like the username and password of your VPN, the AS number assigned to you, and the AS number and net-44 address of your peer. Probably even a script could be written that performs the configuration itself based on the few variables it requires, similar to what Marius' script does when installing it. Rob

1 0

← 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