> 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
> Ultimately, IPv4 just cannot handle the demands of the modern Internet,
> the emergence of IoT (that being a good or bad thing is another matter),
> etc. The world needs to move on to IPv6.
Actually the problem is less for "the modern Internet" because that has transformed
from a peer-to-peer network into a client-server network where most of the users are
only connecting to a couple of services, and the presence of NAT is less of a problem.
When IPv6 was designed, the designers still believed that every device should be able
to communicate with every other device. A peer-to-peer network. That was already
frowned upon at the time. Why would my refrigerator need to talk to yours?
But as the problem if malvolent users (usually called "hackers" in the press, although
that word originally has a different meaning) is becoming more and more prevalent,
firewalls have been deployed everywhere and such communication is not possible anyway.
Now, when ISPs deploy IPv6 for their customers, the routers they provide are by
default configured with a stateful firewall that allows only outgoing connections
and possibly has capability to "open" communication to some specific device/port.
This is roughly the same as an IPv4 router with NAT and port forwarding.
So, while some expansion of the address space is desirable due to the increasing
number of users, it certainly is not as critical as the IPv6 proponents claim.
(that also explains why the deployment of IPv6 has been such a fiasco)
Rob
Well we just heard a few days ago that some foreign hams don't have a
bandwidth restriction, other than it fits in the band. I haven't
heard of any ill effects from over there, but maybe someone from
abroad can chime in.
I can see it being a concern on HF, where the spectrum is more
limited, but I am pretty much with Brain for above 50 MHz. Further
more is takes a least a dozen years to make any headway with the FCC,
so I highly recommend futuristic thinking when writing comments.
Bruce Perens recommended basically do away with the bandwidth limits,
and let gentlemans agreements take rule. I think that seems logical.
Especially when the alternative is a 10-15 year re-revising the rule,
piece meal approach game like we have been playing, that really just
impedes innovation. But no one has to agree with me. You just have
to file comments to make me happy :-)
Further more, I see like less that 5% of the ham population being
actually capable of sending a 2 MHz wide signal, so the point is
pretty much moot (Everyone else has a Beofeng HT.)
>Now imagine someone sending a signal 2 mhz wide on 447 mhz not really cool for the rest of the >Ham community. That is why we need band with limitation
> A couple of decades ago, the "GRAPES" WA4DSY 56kbit modem kit was
> available for a moderate price. They weren't too difficult to put
> together. Alignment did take a scope, but took only a few minutes. About
> five people in San Diego had them. As far as I know, only three ever
> made it onto the air here.
I remember that modem, but also I remember that there were quite some issues at that time.
It was not easy to reliably make 56k HDLC using affordable hardware at that time.
For interrupt-per-character serial devices the performance of a PC-XT was not quite enough.
There were DMA-based controllers but they were difficult to obtain, hard to find reliable
drivers for, and expensive.
Some people built 68000-based boards for that kind of datarate, and later for 1-2Mbps, also
using DMA. I also considered using PC-LANA adapters that had all the data generating hw
as a co-processor but were not AX.25 compatible. (they use the NETBIOS interface, I added
IP over NETBIOS to my version of NET to be able to use them)
However, no real radio link has ever been made here.
Of course wide acceptation would have been even more difficult.
Today, the computer performance problem no longer exists, but the problem of wide deployment
of a locally designed solution still exists.
Rob
In an online conversation with Brian N1URO, we have both come to the
same conclusion:
We need a group such as TAPR to start getting more involved with the
FCC and bypass the ARRL.
I remember back when I never really understood TAPR. I knew what the
name stood for, so I always assumed they were the voice representing
the digital aspects of the hobby. Then I heard a 2008 Rain report
where Steve Bible explained TAPR.
http://kb9mwr.blogspot.com/2009/02/tapr-explained.html
I wonder if there is any chance of them taking up the role that I
thought there were about?
And as I stressed before, I feel its important to have a futuristic
thought process when making comments as it takes many years for
regulator changes to actually happen. And in that light, this is
from a 2012 webinar, where Chris Imlay W3KD and Ed Hare W1RFI predict
and speculate what ham radio will be like in 25 years (2037):
http://kb9mwr.blogspot.com/2013/09/amateur-radio-in-2037.html
Listen to that when you have the time, add your own thinking and start
drafting your thoughts to the commission.
Steve
Very interesting indeed!
You are probably aware that there is some activity on Digital ATV and the boards made
for that purpose (and/or the cheap dongles they use) could be used for this as well.
We have a Digital ATV repeater here that is currently under some reconstruction, and I
have suggested putting some IP broadcast on the multiplex. Indeed, as you note, a
Linux-based DVB receiver can easily put the demodulated and extracted IP traffic on its
LAN interface. More than a decade ago I did some "experiment" logging the downlink of
satellite-internet on a Dreambox and it just used standard features of its software.
But your test of using this full-duplex (rather than just unidirectional as it was envisioned)
surely is innovative.
It could be useful here as well, indeed as you indicate to make links on amateur bands
for which there is no commercial WiFi equipment. It is not straightforward to use that
equipment with transverters, and a steady fullduplex link would certainly be easier.
Some people are also working on a 70cm digital access with smaller bandwidth, there is
little detail on what modulation they use, it would be interesting to see if using DVB-T2
in halfduplex more is feasible. Probably not, due to high turnaround delays.
Rob
