> At the cost of sacificing the independence and survivability of the
> mesh structure that is the current AMPRNet, one or more central v4 to
> v6 gateways could be established. I believe it would be too much to
> expect each of the 600 or so subnet gateways to become "dual-stacked".
I will certainly consider adding IPv4-over-IPv6 tunneling to our gateway for 44.137.0.0/16
when there is demand for it. We are already IPv6-connected but at the moment this is
only used for out-of-band management (to prevent locking myself out of the system when
doing work on the complicated IPv4 routing and firewall)
Of course that would indeed mean it is not meshed over IPv6 but of course it still
participates in the IPv4 mesh.
When there is sufficient uptake in other parts of the world, additional meshing over
IPv6 could be considered. I agree that some method, preferably an internet standard,
should be used to disseminate IPv6 tunnel information. It would decrease the difficulty
of adding a gateway for those that e.g. want to use surplus commercial routers.
Rob
It's been interesting going over historical documents, RFCs, and some
personal correspondence with people who were involved with the AMPRNet
at various times. I think we've now got a pretty good picture of the
history of the AMPRNet up to the current day.
Let me recap the history as I know it:
In 1981, Hank Magnuski, KA6M, got the network with a phone call to Jon
Postel at USC-ISI, later the SRI-NIC.
Around 1983, Hank passed it on to Phil Karn (KA9Q), then at BellCoRe.
Phil managed it until he left to go to work at Qualcomm in San Diego,
and gave it to Wally Linstruth (WA6JPR) [RIP 2010]. Phil is now retired,
and continues to be involved with AMPRNet.
Around 1988, Wally passed the network on to me to manage, and I've been
doing so ever since.
In 2011, it seemed wise to legally formalize the ownership, so we
incorporated our organization, Amateur Radio Digital Communications
(ARDC), as a non-profit 501(c)(3) tax-exempt charitable organization,
and I became its president.
The American Registry of Internet Numbers (ARIN) and Internet Assigned
Numbers Authority (IANA), which are the authority in these matters,
recognizes us (ARDC) as the legal owner of the AMPRNet, 44.0.0.0/8.
If there's any corrections needed in the above brief history, please
let me know.
- Brian
Hi All,
AMPRNET consists of IPv4 addresses 44.x.x.x. Tunnels used to support
AMPRNET use IPv4 hosts as destinations for the tunnels, creating a
"mesh-like" network.
Bent OZ6BL and I have been experimenting with using an IPv6 host to
carry AMPRNET traffic. The reason you might want to do this is that
IPv6 addresses, particularly static addresses, can be much more readily
available than with IPv4. Also, it's an interesting thing to try! We
have working tunneled 44.x.x.x connectivity between three different
IPv6 hosts. However, there are some issues that arise, mainly due to the
way in which AMPRNET functions.
Tunneling IPv4 inside IPv6 (ip4in6) is easily done and is well
documented. In Linux, commands like these are all that's needed:
/sbin/ip -6 tunnel add ip6tnl1 mode ip4ip6 \
remote 2001:0DB8:112:35c::5630:6324 \
local 2001:0DB8:1245:5200::ca0c:5902
/sbin/ip link set dev ip6tnl1 up
/sbin/ip route replace 44.145.40.32/32 dev ip6tnl1 src 44.136.170.20
It's very similar to how conventional AMPRNET is set up. However,
the first issue is that with ip4in6 you cant (unlike ip4in4) leave the
"remote" address empty, and then use routing commands to set the
destination for different AMPRNET hosts (you'd be trying to add an IPv4
route to an IPv6 gateway destination). So there's a scalability
problem - you'd need to set up a different tunnel device for each subnet
you communicate with!
The second issue is interoperability - if Alf, Bob and Charlie each only
have IPv6 hosted AMPRNET, and Doug, Ed and Fred have only IPv4, then A,
B, and C can communicate with themselves, as can D,E,F, but the two
groups cannot interconnect from tunneled addresses. Of course, A,B and
C could host IP4 tunnels as well, but that would somewhat defeat the
purpose! Alternatively, one or more gateways (G) could host both IP4 and
IP6 based tunnels, and route between the different type of network, a
bit like this:
A,B,C <----> G <----> D,E,F
Could/should amprgw be configured to do this? Or maybe some hosts
elsewhere do that function? But it adds complexity to the overall
routing setup (and starts to become a more centralised network).
The final issue is dissemination of the information - can the portal be
modified to support IPv6 hosts, or do we need another mechanism? Can
encap.txt be used still? Would facilities such as ampr-ripd and ripd44
need modifications?
So there's plenty to think about....
Steve, VK5ASF
I am in need some guidance. I have a number of ways I can use this and I
dont want to set it up wrong from the beginning.
I was assigned a subnet in Denver, Colorado where I am working with local
groups to get on some tower sites, but I have a Data Center in New Jersey
that has a large VM infrastructure. I live in Colorado but since the data
center is in New Jersey should I get another allocation? I still plan to
use the Denver/Colorado Springs subnet, but that upstream ISP is being
difficult at the moment since I am a subtenant, and my MOU is only for
tower space and a two routers in the cabinet there.
I was going to just route the Colorado IPs to my New Jersey Data Center
then tunnel back to the Colorado Gateway, but am not sure what the policies
on that are.
My plans are to offer some free VMs and VPN tunnels to HAMS on my back end
systems as well as VPN gateway points, etc. Those would be in NJ, but once
I finish my migration into a dedicated cabinet here in Denver I would offer
additional VMs / Gateways here as well. Future plans include California and
Croatia.
Please let me know if anyone has any ideas about what direction I should
go. My provider in NJ is ready to add the routes next week (as soon as the
go ahead authorization from AMPR).
Thanks,
Mike Vespoli
Denver Colorado
KE0HFH
> Yes, I'm now aware that there are nameservice problems
> and I'm working on it. It won't be fixed quickly because
> it requires manual intervention by several people in many
> different places around the globe, including the registries.
> Thanks all for bringing this to my attention.
> - Brian
Well, it appears that the originally envisioned problem (not all servers uptodate) has
been fixed. The 2nd problem (incorrect servers in org zone) is still open, but that
should affect only the lookup time. It probably explains why ampr.org lookups are
often so slow.
However, when I checked before there were only some servers that were at most 24h behind.
Maybe they synchronize only once per day.
Was that the "slave nameservers are not updating" issue that you were after?
Or was there another slave that had not been updating for a much longer time?
Generally, 24h out of date should not be that much of an issue. Of course, when it stopped
syncing completely that would be bad.
Rob
Through the kind courtesy of John, KI5D, mailman.ampr.org has a new
home, on a virtual host in Fremont Calif. It is now at IP address
199.249.223.193, and has a revised SPF record. This should significantly
reduce the spam filtering problems we've been having. The hostname and
web URLs have not changed.
Because of long times-to-live in the ampr.org DNS tables (1 day), your
mailer may still attempt to connect to the old address of 44.0.0.1 if you
send mail to the 44net(a)mailman.ampr.org or 44-announce(a)mailman.ampr.org
mailing lists. It's been about 12 hours since the address change, so
about half of the cache entries people may have should have expired by
now, but some will not have yet.
I've reduced the TTL on ampr.org DNS records to 1 hour from the previous
1 day to help prevent this sort of long cache delay from occuring in
the future.
If you send mail to the 44net or 44-announce mailing lists and the
connection is refused, you have the old address still and your mail
should be delivered on some subsequent retry when that entry has expired.
Or you might be able to flush the DNS cache on your mail host and retry
for faster delivery.
Similarly, if your web browser has the old address in its cache, you
will get a 404 error attempting to access the mailman web interface.
Flush the cache or wait.
Thanks John!
- Brian
--
44-announce mailing list
44-announce(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44-announce
Ever since I moved the 44net mailing list from 'hamradio' to 'mailman'
it's been running into spam filters.
This is caused in part by the fact that 'mailman' is actually an
alternate (duplicate A record) name for 44.0.0.1. The machine serving
as 'mailman' is itself dual-homed to both 169.228.34.84 and 44.0.0.1
but uses 169.228.34.84 as its outgoing email IP address, and I can't
change that. And UCSD blocks inbound SMTP to 169.228.34.84 as part of
THEIR spam filtering.
Another part of it was that the mailer on amprgw was identifying itself
as 'gw.ampr.org' instead of 'amprgw.ucsd.edu' which is its name when
looked up by the outgoing mail IP address of 169.228.34.84. This was
tripping spam filters which believed that the mail was coming from a
forged address.
Among other people, Marius wasn't getting 44net mail because of his site's
spam filtering objecting to the misidentification of amprgw's mailer.
I've corrected the mailer name issue; it now identifies itself on
incoming and outgoing mail as 'amprgw.ucsd.edu' which is its primary
name in the DNS. Mail to it as 'amprgw.ucsd.edu', 'amprgw.ampr.org',
'gw.ampr.org', or 'mailman.ampr.org' will all be accepted. (Although mail
to amprgw.ucsd.edu will be processed by UCSD's spam filters. Arrgh.) Mail
from it will come from a connection from 'amprgw.ucsd.edu'. This may
result in the need to adjust a few spam filters but will make other spam
filters happy.
The mailing list sender address will still be 'mailman.ampr.org'. I have
updated the SPF record for that hostname to include all the MXs for it,
and both addresses of it (169.228.34.84 and 44.0.0.1):
"v=spf1 +mx +a ip4:169.228.34.84/32 ip4:44.0.0.0/24 ?all"
With any sort of luck, this will appease the other spam filters.
The reason for all this complication is that I've had to condense two
machines, hamradio and amprgw, into one because hamradio is going away.
The reason for using 'mailman' as the hostname in the mailing list headers
is that we may someday move the mailing lists to their own machine with
that name (and it's own IP address!) and I don't want to go through the
pain of renaming the mailing list once again and having everybody have
to change their filters and address books again.
So if you encounter difficulties with the mailing list I apologize for
the confusion. If this is the first message you've received since the
list moved, then I've fixed your problem. If you find this message in
your spam mailbox, then I've broken it for you.
The basic problem is that there is no good solution for getting rid
of spam. SPF is incomplete and DKIM is just broken itself because it breaks
years-old tradition of mailing list formats. (It checks the Author address
['From:'] instead of the sender ['Sender:'] or error-return address
['MAIL FROM:' or 'From '] address.)
So people, including myself, resort to kludges of various kinds, all
of which are not fully satisfactory, and some mail just doesn't get
delivered.
It's a mess. Sorry.
- Brian
