I am glad to see that IPv6 being available Looking forward on the
progress.
K6DLC
--
Daniel Curry
PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92
IPv6 Sage Certified
San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]
All,
Has anyone attempted to setup an AMPR gateway using Microsoft Windows (http://technet.microsoft.com/en-us/library/cc940485.aspx)?
I surmise that the tunnel setup is straightforward; and ActiveState ActivePerl (http://www.activestate.com/activeperl) can be used to run RIP44d, I have not reviewed the RIP44d file as of yet; but I assume editing the line that adds routes to the Routing Table would be all that is needed. The Perl Packages 'interface' and 'IO-Socket-Multicast' are available through ActivePerl for Windows, has anyone tried a Microsoft setup before; did you have success/failure?
I wanted to make sure no one has already tried the Windows OS before I explore; and if they have, can they provide some insight and instructions.
73,
Lynwood
KB3VWG
44net-request(a)hamradio.ucsd.edu wrote:
> the DNS functionality is a separate module and is not tied to the name of the IP/subnet, not everyone uses their callsign as the DNS name
But that is a license requirement! We need a mapping between IP address and callsign for legal use of IP on amateur radio....
(ID requirement)
Rob
Tony, AH6BW, has set up an IPv6 proxy to enable IPv6ers to reach
www.ampr.org.
This should have no effect on ordinary IPv4 access to the site,
but if you have any trouble reaching it, please let me know.
FYI, the entry in the nameserver to implement this is
www IN AAAA 2605:b00:0:2:211:2fff:fef6:4287
which is how the address for an IPv6 host is entered in the
the 'bind' nameserver.
- Brian
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
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
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
> 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
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.
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
