It's important to be aware of the timeline but this anniversary might
also be a good time to look back at the history and think about the
impact this assignment has made.
What *new* technologies has been developed because of this network?
Which crises have been mitigated using this network? Have it helped to
spread the HAM radio "spirit" to the young people? What other good
things have this network done?
It's very sad for me to say that the only thing I can see about this
network is a bunch of guys trying to stick with old technology (RIP?
please.) at all cost and arguing who is more important in a tree of
people allocating numbers.
A /8 network is a great value nowadays, the IPv4 especially in Europe is
in a huge crisis and getting new addresses is nearly impossible. From
the other hand most of the address space in this network is unused but
when you try to request allocation for yourself you can easily get
rejected because of silly reasons. (I didn't even try to request one for
myself after my friends showed me the coordinator responses.)
There might be some things going on the used parts of the network but I
couldn't find any example that could be genuinely useful to the world.
Could you please prove me wrong or if I'm right try to consider sharing
the address space with a "new" movement of hacking and hackerspaces? HAM
radio should be all about hacking [1] but frankly speaking I don't see
much of it in HAM radio space these days. There are some exceptions -
i.e. "OFDM modem" thread from the last days but there are as rare as
freakin' unicorns.
This message is not meant to be mean. I'm just trying to pinpoint some
things I've seen as an observer of this network and HAM radio (mostly in
Poland but also the "worldwide" parts) and share some ideas how the
things can be done better and provide a better value to the whole world.
[1] https://en.wikipedia.org/wiki/Hacker_culture
--
I wish you all the best
SQ9PID
Hi,
Try "sixornot" for IPv6
status: https://addons.mozilla.org/en-US/firefox/addon/sixornot/
It works great for me with FF release 55 and 56 beta.
Depending upon what version of Firefox you're using the web site may
say "This add-on is not compatible with your version of
Firefox.". This is due to Mozilla killing off all add-ons not
implemented with WebExtensions starting with FF version
57. sixornot will still run fine up through FF version
56. Download it anyway! After FF 56 you'll have to switch to the
PaleMoon browser (sixornot works great on it for me too).
73,
-Tom WS7S
At 12:16 PM 9/4/2017, you wrote:
>Does anyone know of nifty little firefox add-on that will denote that
>you are connected via IPv6 to the site? I'd like to be more aware of
>what all supports it in the course of my general browsing. I think
>that could really bring an awareness. Kind like the more recent "This
>site may not be secure" when Browsers detect login details over a non
>HTTPS connection.
>
>Having to sniff it with netstat to tell if its 4 or 6 is less than appealing.
John,
I see IPv6 to http://nw7dr.ampr.org/ with netstat:
TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65219
[2001:470:b:40f::3]:http ESTABLISHED
TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65220
[2001:470:b:40f::3]:http ESTABLISHED
TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65221
[2001:470:b:40f::3]:http ESTABLISHED
Pinging k7ve.ampr.org [2001:470:b:40f::2] with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Pinging nw7dr.ampr.org [2001:470:b:40f::3] with 32 bytes of data:
Reply from 2001:470:b:40f::3: time=99ms
Reply from 2001:470:b:40f::3: time=102ms
Reply from 2001:470:b:40f::3: time=117ms
Does anyone know of nifty little firefox add-on that will denote that
you are connected via IPv6 to the site? I'd like to be more aware of
what all supports it in the course of my general browsing. I think
that could really bring an awareness. Kind like the more recent "This
site may not be secure" when Browsers detect login details over a non
HTTPS connection.
Having to sniff it with netstat to tell if its 4 or 6 is less than appealing.
> Phil Karn, KA9Q, invented the /N network-bits-width notation back in ham
> AMPRNet-related documents in the 1980s, so it should be more properly
> known perhaps as "Karn notation" rather than "CIDR notation".
That certainly would be good, he has done tremendous work for the acceptance
of internet protocols.
> I like to bring this up from time to time to remind people that inventors
> deserve credit especially when they don't charge for their inventions.
Some time ago I noticed that my hack in PE1CHL-NET version 950819 (Aug 19, 1995):
TCP SYN packets are examined when routed, and the MSS option will be
adjusted down to the maximum MSS possible on the incoming and outgoing
interfaces. Thus, a more optimal end-to-end MSS is chosen, and
fragmentation is avoided (e.g. when running IP over NET/ROM somewhere
inbetween the endpoints)
pre-dates the addition of this feature in e.g. Cisco routers (ip tcp adjust-mss)
by several years.... that would certainly have been patentable...
> I'm reminded of this because Phil and I had dinner last night (he's
> doing well, thanks) and got to chatting about the old days of packet
> and AMPRNet.
Great to hear that!
Rob
>> I guess the more pertinent questions I have for Brian would be:
>>
>> Are there a plan so that folks who only have IPv6 commercial address
>> or are suck behind carrier grade IPv4 with no firewall access (some
>> cellular carriers presently) can participate with the amprnet? In
>> other words are there plans to make amprgw dual stack?
>
>(I think you meant 'stuck', not 'suck'. Is that a Freudian slip?)
>
>There's no plan to make amprgw dual stack. I'm not sure that the question
>is meaningful; what would it DO with an incoming IPv6-only packet?
>It's not going to be a NAT64 gateway, that's for certain.
Okay, its just something I have been wondering. I feel as commercial
IPv4 addresses become more scarce, and more carrier grade NAT comes
into play there will be more hams looking for solutions for the
various internet ham radio services (IRLP, Echolink, D-Star etc),
where they need the ability to control their port forwarding/firewall
stuff. Basically I see a large number of folks seeking commercial VPN
services.
>
>Interoperability of IPv4-only and IPv6-only hosts is a sticky wicket
>that in my opinion NO ONE has solved satisfactorily.
>- Brian
I am slowing learning what a complicated mess it is (going to be) myself.
> My interpretation of the question was whether the gateway would support
> tunnels running over IPv6 to carry 44/8 traffic. That way, endpoints on
> DS-Lite, for instance, could tunnel their 44/8 traffic over IPv6, and
> those of us with dual stack might be able to avoid the usual issues with
> routers that don't support IPIP encap packets over NAT properly.
I'm not sure amprgw is the place to do that. The IPIP tunnel network is a mesh, and
such endpoints would not be able to participate in the mesh.
On the other hand, local gateways could offer this service to local users, when
they are both on IPv4 (to participate in the mesh) and IPv6 (to service local users).
E.g. we offer connectivity to local users on our gw-44-137 using various different
protocols (all over IPv4):
- IPsec tunnel
- GRE (with or without IPsec)
- L2TP/IPsec
- OpenVPN
Some IPv4-over-IPv6 protocol(s) could be added to that when the need arises.
However, all ISPs offering IPv6 locally that I know of, offer dual-stack.
There have been some requests to offer IPv6 inside our hamnet, but we are not
quite ready for that yet (depending on support in routers etc). However, I
never received a request to setup a tunnel over IPv6.
Rob
> Someone else with a more thorough understanding of the IPv6 address
> allocation procedure can explain why there will never be a ham-radio-only
> block of IPv6 addresses akin to the IPv4 AMPRNet 44/8.
It would not be a good idea to have that, because we would again be faced with the difficulty
to get it connected and routed. The whole tunneling and BGP issue all over again.
When we just want some IP space on internet it is much easier to have everyone use the IPv6
netblock they get from their local ISP, and compile some list of netblocks that are assigned
to hamradio that way. So everyone just connects their stuff to internet, and where required
imports some list of netblocks that they want to talk to.
The distribution of that list can be done using similar mechanisms as are now being used
for the tunnel mesh:
- use a file that is posted somewhere and that can be downloaded
- use some API to retrieve the data (like on the portal)
- use a central system that sends the info using some routing protocol (like the RIP daemon)
- setup an ad-hoc mesh network that distributes the info peer-to-peer
I think the latter option is the best. We can use multihop BGP where everyone connects to
a couple of friends and maybe some higher-tier service in the country or continent and they
advertise their local netblock(s) there. BGP will compile a table of all netblocks advertised
by hams, without any need of a central service or authority. You only need to setup a couple
of peerings (a full mesh is not required) so most outages will be covered. This table of
netblocks will not be used for routing, only for source-address filtering for ham-only
communication.
The actual routing over-the-globe will be done directly by the ISPs, no tunneling or special
arrangements required, the netblocks are just part of their standard allocation.
Locally, you can route over radio in additional to this, using whatever routing protocol is
locally customary. When properly configured, radio paths will be taken where possible and
other traffic will be routed over internet.
I am not the only one proposing this. Daniel Estévez EA4GPZ and others have written about it
as well.
The reason this is possible on IPv6 is that you normally get a large chunk of addressing space
from your ISP so you can easily carve out netblocks to be used for different purposes.
When getting IPv6 from your ISP, you should check that they DO assign you multiple netblocks,
as is recommended in all IPv6 deployment strategies, but not all ISPs do understand that.
(also, it is of course best when your allocation is static and does not change every day or so)
Rob
> The one thing I know that we need to request is elimination of symbol-rate
> restrictions, to be replaced with bandwidth restrictions.
I think you should not focus too much on symbol-rate restrictions. As has already
been written, using a high symbol-rate usually is impractical anyway. It is better
to use techniques like OFDM that combine a high bitrate with a low symbol-rate.
You only need to ensure that you can use the bandwidth that is technically required
for the experiment you want to run, within the limits of the band and the bandplan,
and without causing intentional interference to other users.
(i.e. you don't use the entire band. you don't cover the existing small-signal
and repeater allocations with your strong wideband signal, etc. spread spectrum
allows for some co-existence of wideband signals and other users, but it is not
what I am referrring to here)
Rob
