44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] 44Net Digest, Vol 2, Issue 21
by Rob Janssen 05 Feb '13

05 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: >> >But it has the disadvantage that you spread the rarely occurring task over many >> >people who do it only once and do not have the knowledge and skills to perform >> >it well. I'm afraid this will lead to many wrong subnet specifications (already seen), >> >strange names in the DNS, questions, etc. > That's just a learning curve which is easily fixed. I think it is better to have the learning curve once and not for every user. It is already very unclear to me (as an expert in IP addressing and a long-time co-ordinator) what the system will exactly do when I perform certain actions, and I think it will be nothing short of a mystery to those that just want an address and have no idea how IP addresses are structured, what subnets are, and how DNS fits in. > >> >I prefer to handle the task for the entire country and have the system only >> >administer what has been assigned, not delegate the subassignments. It is >> >a small country and I get only a couple of requests per year these days. > The system is flexible, if that is how you want to administer the subnet you are responsible for, then go ahead, all your allocations will therefore be to end users instead of regional co-ordinators and it will be your responsibility to keep the portal up to date and if there are any problems, you will be the point of contact to respond and fix the problem. It's more work for you, but if that is how you prefer to manage your subnet I don't see a problem. > > I guess what we need is a facility for co-ordinators to enter allocations to end users manually, I can sort that out. > > Regards, > Chris > I don't mind if users can submit requests for subnets via the system, as long as that does not automatically mean that they become the co-ordinator for that subnet. They get the adressing space, submit the requests for names within that space, and I validate them. That is how it has always worked, and it has served well to prevent silly stuff like non-callsign entries directly under ampr.org from appearing within the 44.137 subnet. For single adresses, it would be preferable if there is a single request form that supplies both the name and desired subnet, and leaves the assignment of the address to the co-ordinator, who approves the entire request in a single action. But if that is too much programming work and it is more convenient to leave the separation between address assignment and DNS mapping, that is not a real problem because of the current rate of requests. Rob

4 5

amprnet dns zones
by Eric Fort 05 Feb '13

05 Feb '13

I'm seeing a lot of good things in the works in the reforming of amprNET/net44 including how ip address assignments and allocations are to be handled and managed, routing info exchanged dynamically via rip and other protocols, and the moving away from a single central point which all traffic has to essentially tunnel to as address space can now once allocated be tied to the appropriate AS and routed via BGP. all great things being done. there are a few things though I have not heard happening that I'll ask if they have been considered and what others thoughts may be. This for the most part deals with a gateway operator being able to manage the DNS zones pertaining to the operation of their gateway and it's users. for the sake of discussion lets say we have a gateway operator with a /24 block assigned to their gateway and let's say that block is 44.128.128.0/24and lets say their call was gw4opr: I would propose that along with the allocation of that block that gateway operator have the option to host and manage the 128.128.44.in-addr.arpa zone on their DNS servers. I would also propose that those who would choose to could host and manage their own DNS zones, in this instance *.gw4opr.ampr.org. It seems to just make sense that reverse dns would be managed by the ones responsible for and closest to the address space assigned and that one ought to be able to manage their own DNS zone without having to go through their address coordinator for every last dns update as long as they are willing to accept delegation of responsibility for their zone. what are the thoughts on this from others on this list? Personally I think delegation of zones is a great idea, but perhaps I missed something. it would seem to further lighten the load on local coordinators. That said, why should we or why should we not plan for, allow, and even encourage, delegation and self management of DNS zones directly by those closest connected to and most responsible for them? AF6EP

3 2

Re: [44net] 44Net Digest, Vol 2, Issue 20
by Rob Janssen 05 Feb '13

05 Feb '13

44net-request(a)hamradio.ucsd.edu wrote: > An example: if I'm the San Diego county coordinator, and I assign a /24 > to AA6ZZ for a gateway in the Santee city area, he can become the > coordinator for that /24, and assign addresses from his block of 256 > addresses to the clients of his gateway. > > Likewise: > 44.0.0.0/9 is assigned to the USA, with me as the current USA coordinator, > 44.124.0.0/16 is assigned to Arizona and handled by the AZ coordinator > 44.124.128.0/24 might be assigned to a gateway in Phoenix who would then > handle address assignments for the clients of that gateway. > > So by registering gateway operators as coordinators for their gateway's > subnet, we localize the network management to the people who are the > best situated to handle it. But it has the disadvantage that you spread the rarely occurring task over many people who do it only once and do not have the knowledge and skills to perform it well. I'm afraid this will lead to many wrong subnet specifications (already seen), strange names in the DNS, questions, etc. I prefer to handle the task for the entire country and have the system only administer what has been assigned, not delegate the subassignments. It is a small country and I get only a couple of requests per year these days. Rob

2 1

network management
by Brian Kantor 03 Feb '13

03 Feb '13

> User registration and network management are separate functions. I think > that after a user registers, any network (address, LAN, etc.) requests go > to the coordinator for that address space. An example: if I'm the San Diego county coordinator, and I assign a /24 to AA6ZZ for a gateway in the Santee city area, he can become the coordinator for that /24, and assign addresses from his block of 256 addresses to the clients of his gateway. Likewise: 44.0.0.0/9 is assigned to the USA, with me as the current USA coordinator, 44.124.0.0/16 is assigned to Arizona and handled by the AZ coordinator 44.124.128.0/24 might be assigned to a gateway in Phoenix who would then handle address assignments for the clients of that gateway. So by registering gateway operators as coordinators for their gateway's subnet, we localize the network management to the people who are the best situated to handle it. A new ham in Phoenix who wants to get on AMPRNet registers, goes to the networks section, clicks on USA, clicks on Arizona, sees the gateway registered in his area, and clicks on that to request an allocation. The gateway operator picks an available address, say 44.124.128.17, registers it and things are good to go. No need to wait for the state or national coordinator. You don't have to register nor log in just to view the network allocations and who the coordinator is, so folks who just want to know if there's a subnet or gateway in their area can see. - Brian

1 0

Problem with France
by ze.bot＠free.fr 03 Feb '13

03 Feb '13

I think that there is a problem with a new allocation inside France 44.151.0.0. https://portal.ampr.org/networks.php?a=region&id=295 There is a declaration of one single user (not a network) with a /16 at the end... > Network Country Region Allocated to > 44.151.67.22/16 FR Alsace F6EQN [Michel BELLEZIT] Furtheremore, on his website, F5PBG invites all french users to register individually their IP on the "ampr.org" website. This will induce a lot of useless declarations. http://inforadio.free.fr/articles.php?lng=fr&pg=85 > # Changement de fonctionnement du réseau AMPR : > # INSCRIPTION OBLIGATOIRE POUR ETRE PRIS EN COMPTE > # à cette adresse : https://portal.ampr.org/ (Onglet "Register") > # puis après connexion réalisez votre demande (Onglet "Networks") Translation of this extract : > The AMPR network has changed > Registration is compulsory > at this adress : https://portal.ampr.org/ > click on "register", > and then after connexion, > put your request, click on "network". I think that an admin could delete this declaration, and put a reminder about what is an allocation, and what is a network, a subnet, etc... Thanks.

6 7

Dynamic IP GATEWAYS?
by Demetre SV1UY 02 Feb '13

02 Feb '13

Hi, Any news about support for Dynamic IP Gateways yet without having to pester other Gateways having static IPs via AXUDP links? -- 73 de SV1UY Demetre Ch. Valaris e-mail: demetre.sv1uy(a)gmail.com Radio e-mail: sv1uy(a)winlink.org http://www.qsl.net/sv1uy

5 6

ip updating
by K7ILO 02 Feb '13

02 Feb '13

Hello gang. Could an ip coordinator send me via direct email the email robot's address for adding and updating amprnet ip addresses? Thanks Harold K7ilo (formerly KB7RSI) Southern Nevada Ip Coordinator

13 25

AMPRNET Donations
by Paul Delaney - K6HR 02 Feb '13

02 Feb '13

Exactly how will any donated funds be used, accounted for etc? Paul Delaney - K6HR paul.hamradio(a)verizon.net http://k6hr.dyndns.org:8080

2 1

Re: [44net] gateway file
by kb9mwr＠gmail.com 01 Feb '13

01 Feb '13

What you have for a network over there makes me jealous. I guess I'd like to know what in terms of content is on the amprnet. I know there are some AXIP BBS style feeds and that sort of thing. Is anyone running a mailman mailing list of anything interesting? For higher speed radio connections are there any SIP/Asterisk conference servers, or at least FTP repositories of ham stuff? Stuff that is exclusive to the network. I have some point to point 802.11 links over here that I have been using 44 addresses on for a few years. But they haven't been connected to the rest of the amprnet. Is there a compelling reason to setup a gateway to the rest of the amprnet. 73' Steve ----Original--- Btw: We are currently deploying our IP management system for the HAMNET network: http://hamnetdb.net/?m=as&q=&as=-All-&tab=map You should be able to do a traceroute to all "green" sites... Click on a site and you get the description. 73, Jann DG8NGN On 31.01.2013 21:09, kb9mwr at gmail.com wrote: > I have one from Sept 2012 if anyone wants it. > > I second the importance of the data in that file. It's really the > only thing we had to tell what is on the amprnet, in terms of > services, and the speeds of the connected radio subnets, etc.

1 0

Re: [44net] gateway file
by kb9mwr＠gmail.com 31 Jan '13

31 Jan '13

I have one from Sept 2012 if anyone wants it. I second the importance of the data in that file. It's really the only thing we had to tell what is on the amprnet, in terms of services, and the speeds of the connected radio subnets, etc. > Date: Thu, 31 Jan 2013 11:05:14 -0800 > From: Jack Eifer <jeifer(a)cwo.com> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] ip updating > > Chris, > > While we're on the subject of TODO's, > Has any consideration or thought been given to resurrecting the 'GATEWAY' file that Fuller maintained ? > > I found the information in file useful and easy to access. Perhaps the new website has the same info embedded, but somewhere I've yet to discover. > > Jack, AA6HF

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net