44net January 2016

44net@mailman.ampr.org

62 participants
47 discussions

Re: [44net] looking for Phil Karn KA9Q
by Assi Friedman 21 Jan '16

21 Jan '16

Karn (at) ka9q.net -----Original Message----- From: 44Net [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of R P Sent: Thursday, January 21, 2016 9:59 AM To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] looking for Phil Karn KA9Q (Please trim inclusions from previous messages) _______________________________________________ Does anyone have a contact with Phil Karn (ka9q) ? The email in QRZ didn't get any answer by him Thanks for any assistance Ronen - 4Z4ZQ _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] AMPRNet DNS cleanup
by Rob Janssen 21 Jan '16

21 Jan '16

> Subject: > Re: [44net] AMPRNet DNS cleanup > From: > Pedja YT9TP <yt9tp(a)uzice.net> > Date: > 01/20/2016 09:42 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > > On 19.1.2016. 20:09, K7VE - John wrote: >> I think people are making this way more complex than necessary: >> >> Two conditions exist: >> >> 1 - A DNS entry is essentially dead, nobody will notice if it's deleted. >> (probably > 95%) >> 2 - A DNS entry is in use. If it disappears, the affected party will >> notice and it can be corrected. > > Agree. I would not prefer to use this method. There is no guarantee that an affected party will notice that an address that they use disappears from DNS. Note that the list of addresses serves both as a registration list and a way to load the DNS zone, and people can be actively using their address without ever using the (public) DNS entry for it. > >> In general, it's time to flush old entries. > > > I do not know how whole process works, but on other service I use inactive accounts (and thus IP and DNS records) are not deleted, just disabled. Please understand that there currently is no such thing as "accounts" under which DNS records are registered. The registrations are made by local coordinators (for which there is some information available) on behalf of users who request an allocation. Local coordinators have varying amounts of detail available about the users. There certainly is no list of e-mail addresses of all users available, where they could be contacted about their allocation. Sure it would be nice to move to a new system where more detail is available about every record, like the date of registration and last re-confirmation and a contact address for the user. However, that also has some associated problems (in many countries it is not straightforward to setup such a database, especially not one accessible over internet, while remaining within legal restrictions about storing personal data). It will not be practical to contact everyone and ask them to create some account to manage their allocation. When it is decided to move to such a system, something has to be done about the existing allocations, to the very minimum those addresses that are allocated now should be protected or at least flagged when the new system tries to re-allocate them to someone else. Only unallocated addresses or confirmed obsolete addresses should be re-allocated, and in fact even within the current manual system I almost never re-allocate an abandoned address to someone else. There is no need to do so because of the vast amounts of empty space we have. Rob

1 0

Re: [44net] Traceroute for IPIP ?
by Steve L 20 Jan '16

20 Jan '16

Ronen, Traceroute over IPencap should work. You may need to ensure the TTL is 64 for your encapsulated routes. Your tunnel packets might be inheriting the TTL from some other interface like an IPV6 one. root@ampr-gw:~# traceroute hambook.de.ampr.org traceroute to hambook.de.ampr.org (44.225.164.16), 30 hops max, 60 byte packets 1 db0fhn.as64626.de.ampr.org (44.130.60.100) 134.560 ms 141.343 ms 139.976 ms 2 hamnet.db0fhn.as64626.de.ampr.org (44.130.60.101) 141.220 ms 140.716 ms 140.461 ms 3 bb-db0fhn.db0gw-2.as64621.de.ampr.org (44.224.2.5) 151.931 ms 152.563 ms 152.748 ms 4 bb-hubwest.db0hsn.as64621.de.ampr.org (44.224.2.18) 158.393 ms 159.046 ms 158.744 ms 5 44.224.53.158 (44.224.53.158) 158.890 ms 178.360 ms 178.948 ms 6 koedsp-core.db0dsp.as64632.de.ampr.org (44.224.24.59) 203.592 ms 162.314 ms 164.085 ms 7 link-kpg-koe.db0ko.as64634.de.ampr.org (44.224.28.157) 174.770 ms 206.083 ms 207.899 ms 8 eth3-core.db0kpg.as64634.de.ampr.org (44.224.28.158) 206.909 ms 206.145 ms 205.800 ms 9 bb-db0kpg.db0ko.as64634.de.ampr.org (44.224.28.161) 205.897 ms 206.280 ms 207.114 ms 10 bb-db0kpg.db0ko.as64634.de.ampr.org (44.224.28.161) 3189.252 ms !H 3191.819 ms !H 3192.353 ms !H root@ampr-gw:~# C:\Users\user>tracert hambook.de.ampr.org Tracing route to hambook.de.ampr.org [44.225.164.16] over a maximum of 30 hops: 1 2 ms 1 ms 1 ms 44.92.21.129 2 137 ms 134 ms 135 ms db0fhn.as64626.de.ampr.org [44.130.60.100] 3 135 ms 132 ms 135 ms hamnet.db0fhn.as64626.de.ampr.org [44.130.60.101] 4 147 ms 147 ms 146 ms bb-db0fhn.db0gw-2.as64621.de.ampr.org [44.224.2.5] 5 153 ms 153 ms 153 ms bb-hubwest.db0hsn.as64621.de.ampr.org [44.224.2.18] 6 175 ms 157 ms 155 ms 44.224.53.158 7 160 ms 181 ms 158 ms koedsp-core.db0dsp.as64632.de.ampr.org [44.224.24.59] 8 176 ms 159 ms 161 ms link-kpg-koe.db0ko.as64634.de.ampr.org [44.224.28.157] 9 164 ms 161 ms 162 ms eth3-core.db0kpg.as64634.de.ampr.org [44.224.28.158] 10 170 ms 168 ms 197 ms bb-db0kpg.db0ko.as64634.de.ampr.org [44.224.28.161] 11 bb-db0kpg.db0ko.as64634.de.ampr.org [44.224.28.161] reports: Destination host unreachable. Trace complete. C:\Users\user>

2 1

Re: [44net] Traceroute for IPIP ?
by Assi Friedman 20 Jan '16

20 Jan '16

Ronen: I do not know of a tool that can truly traceroute a tunnel encapsulated frame. When I do testing, I check the route to the to the tunnel endpoint (non 44 address) and when it uses the default router to uscd, I check to see that it gets to mirroshades. Assi

2 1

Re: [44net] AMPRNet DNS cleanup
by Steve L 20 Jan '16

20 Jan '16

I don't know how practical it would be to to try and monitor the dns server queries to help id which entries are used vs unused. But it might be something to consider sooner than later as you'd want to let this run for quite some time to build some statistics. Just throwing the idea out there. >As for figuring out what is unused or not, there isn't any good way of >determining that.

4 3

Re: [44net] DNS
by Steve L 20 Jan '16

20 Jan '16

Neil, Does your script count the BGP'd address space as gateways, or will it kick back GATENOTFOUND for those too? You can get those here: http://thyme.rand.apnic.net/current/data-add-ARIN | grep " 44\."

2 1

Re: [44net] Verifying the identities of IP coordinators
by Rob Janssen 19 Jan '16

19 Jan '16

> Re: [44net] Verifying the identities of IP coordinators > From: > Don Fanning <don(a)00100100.net> > Date: > 01/13/2016 05:56 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Wed, Jan 13, 2016 at 6:25 AM, Brian Kantor<Brian(a)ucsd.edu> wrote: > > I just thought of another possibility. We could ask that the regional > coordinators do an audit of their IP spaces in conjunction with the > above suggestions as they're likely to have closer relationships with > the end user or be more familiar with the record keeping of their > countries amateur radio licensing. Then we can check off that IP > space as "claimed" or "reclaim" it back into the pool. > I have made an effort to do that. I tried to contact all hams that are in the current allocation for the Netherlands, and asked them if they want to maintain their allocation. As a result, some have replied they no longer want to use it, and I have deleted those allocations. The ones that confirmed their allocation I put on a list with a datestamp. But the vast majority of the hams could not be reached. I have no uptodate contact info and even the old contact info is difficult to access (it is a folder in my mail program that stores all original requests starting in 2002, I don't even have those for the addresses requested before 2002). I also regularly delete the allocations for hams that no longer appear in the official callsign listing for the Netherlands. (I have done this every year, but recently I have done it weekly because starting from this year there is a fee for keeping an amateur callsign and lots of inactive hams have removed their registration as a result) I only keep the registrations in a hostsfile and use a script to send the updates to the mail robot. As an afterthought, I should have kept a file with more info like date of registration and contact address for each entry, but it would require a filtering system so this information does not end up in the publicly visible file. I like to keep everything in a textfile as opposed to some database with a web form frontend, because it allows me to browse through the file to see where a new allocation is to be put, something lacking from many address allocation systems including the amprnet portal. Rob

6 5

Re: [44net] DNS Clearout
by Rob Janssen 19 Jan '16

19 Jan '16

> Subject: > Re: [44net] DNS Clearout > From: > "John Wiseman" <john.wiseman(a)cantab.net> > Date: > 01/19/2016 04:17 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Thanks, Brian, > > I've just checked on the portal, and it seems I'm too late - they have > already been allocated to someone else. (44.131.4.18-21). So they won't get > removed by the clearout, but I'll need to replace them anyway. But it > highlights a problem with your suggested approach - It won't pick up unused > names which are in address ranges that have been reallocated. And glancing > though the uk dns records I suspect that applies to a lot of entries. > > But I can't think of a better solution, and I guess an incomplete clearout > is better than none! > > 73, > John Note that your entries are registered in the ampr.org DNS, but the portal apparently does not respect that. This is one of the problems with the way the DNS part of the portal works: there is no way to see what is already in use before allocating something new. But nothing has been done about that yet, and the issue is open for many years. Rob

1 0

Re: [44net] DNS (was: Nevada IP Assignments)
by Rob Janssen 19 Jan '16

19 Jan '16

> Subject: > Re: [44net] DNS (was: Nevada IP Assignments) > From: > Neil Johnson <neil.johnson(a)erudicon.com> > Date: > 01/19/2016 02:10 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > The initial script is done: > > " 44.225.65.22 ","GATENOTFOUND" > " 44.50.192.22 "," 108.160.233.78" > " 44.225.66.220 ","GATENOTFOUND" > " 44.225.65.220 ","GATENOTFOUND" > " 44.225.64.220 ","GATENOTFOUND" > " 44.225.66.221 ","GATENOTFOUND" > " 44.225.64.221 ","GATENOTFOUND" > " 44.225.66.222 ","GATENOTFOUND" > " 44.225.64.222 ","GATENOTFOUND" > " 44.225.66.23 ","GATENOTFOUND" > " 44.225.65.23 ","GATENOTFOUND" > " 44.50.192.23 "," 108.160.233.78" > " 44.225.66.24 ","GATENOTFOUND" > > and so on > > Of the 36059 address records 30176 don't have a gateway associated with > them. Seems kind of a large amount. I'll do some more sanity checking. This is going to fail big time!! That 44.225 network is probably the most active net-44 network in the world, but it is not gatewayed to internet. People will not like it when you try to delete that!! Also, again the proposal is made to transfer things to the portal. I do not consider the portal ready for production use for this, and I question if it ever will be. Changes to functionality and replies to questions are so far between that I don't think the maintainer has enough resources to keep this project moving. Note I don't want to blame him for this in any way, but I don't think we should become more dependent on it than we are. Rob

2 1

AMPRNet DNS cleanup
by Don Fanning 19 Jan '16

19 Jan '16

Last year I tried to attack the task of cleaning up the DNS. Brian at one point did an AND against the gateway subnets with the DNS and it produced ~19k A records - hundreds of times what is valid or even being used. So as a curiosity exercise, I wrote some script to import the DNS into MySQL. The result was 16653 unique callsigns in the DNS and 2211 aliased/bad call signs as of June 2015. I then imported the FCC amateur database and compared it to US (A,K,N,W) callsigns - that produced 3742 unique US callsigns matching the DNS. Out of those, 1373 callsigns matched an expired, canceled or terminated license. This doesn't take into account all the vanity call signs for the 1x2/2x2/2x1/1x3 callsigns which may be attributed to another operator. While we can get good grips on the US callsigns, as soon as it crosses an international border, it goes to pot as every country has their own licensing structure. Many do not have online databases. So that's what we're faced with. Ideas welcome as to how we can validate the DNS tables.

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net January 2016