> I'm using this proposal in my systems:
>https://github.com/darconeous/ham-addr/blob/master/ham-addr.txt.md
Maybe it is useful to develop a simple tool, e.g. a webpage with some javascript, that
allows input of a callsign in a field and converts the input to the HAM-64, EUI-48 and EUI-64
forms as far as possible. A similar tool could work the other way around.
This allows some experimentation.
Rob
> Currently many routers (I’ve tested and written a tutorial on Ubiquiti, and OpenWRT) allow you to set the subnet you want. In addition to that, some ISPs have pages that have details on how to do this in FreeBSD, OpenBSD, Gentoo, Windows, Cisco, etc. Of course, the modem / router / switch / access point provided by the ISPs may not allow you this, but it’s certainly possible.
In the MikroTik routers quite popular in amateur networking, and also in the AVM Fritz!box routers that my ISP provides, it is not possible to do this when DHCPv6-PD is used.
(it is possible when static IPv6 addresses are used as is done by some ISPs)
There is an open feature request at MikroTik to implement something like you depict in your tutorial, but currently it is not there.
Rob
> The good thing about IPv6 is that due to the large address space it's
> possible to make it mandatory to encode the callsign in the last 64 bits
> of the address. This eliminates the problem that we have in IPv4 of
> trying to trace back which callsign is behind an IP.
I think it basically is a good idea, but it needs to be more flexible.
We would like to be able to derive the callsign from the IP, but there should
be no 1:1 mapping between callsign and IP, because that would mean only a single
system can be online for each callsign.
The standard should leave some bits (at least 8) available for use as "SSID" as
we had in the packet days (callsign-1 callsign-2 etc), maybe also with some
encoding of alphanumeric values.
Rob
Hi all,
Sorry for the slight off-topic.
I'm testing in my systems the idea of using IPv6 for Amateur Radio. My
idea is to use some way of encoding the callsign in the IPv6 address.
I'm using this proposal in my systems:
https://github.com/darconeous/ham-addr/blob/master/ham-addr.txt.md
Certainly, there are several other proposals that could be used.
The good thing about IPv6 is that due to the large address space it's
possible to make it mandatory to encode the callsign in the last 64 bits
of the address. This eliminates the problem that we have in IPv4 of
trying to trace back which callsign is behind an IP.
The idea is to make some sort of whitelist of globally routable subnets
that are using some way of encoding the callsign into the IPv6 (I would
like to allow for the admin of a net to choose the encoding he wants to
use). This whitelist can then be used in a firewall for several things:
allowing access to some services to Amateurs only or deciding if a
packet is fit to be routed by an RF link (for instance, one could
require that the source and destination have both their callsigns
encoded in their IPv6's).
I'm using the subnet 2001:470:6915:8000::/49 for these tests. If someone
has IPv6 connectivity and wants to try, there's a mumble server and a DX
cluster (telnet port 7300) at ea4gpz.destevez.net (its IPv6 has the
callsign EA4GPZ-Z encoded).
The long term goal would be to have something similar to the 44net but
where each user is using subnets allocated directly from their ISP
instead of having a large block for amateurs (like the 44.0.0.0/8).
Connectivity between different amateur subnets would run over the IPv6
internet instead of using a mesh VPN (as the IPIP mesh of 44net). The
whitelist could be used to decide which IPv6's are amateur and get
"special treatment".
I have a longer text describing these ideas, but it's in Spanish. I'll
translate it and put it somewhere, but I want to keep this email short
enough.
So, is anyone doing something similar already? I would like to get some
subnets into the whitelist, so I can test how well this works.
Questions, suggestions, comments? Anyone interested in joining these tests?
73,
Dani EA4GPZ.
> the "Iot" is quite a culprit..I am constantly probed and attacked by
> routers, refrigerators, and many, many so-called "smart
> TV's"...sometimes, when I'm bored, I shut them off...it gives me a
> tickle to think of someone botting away and abruptly being shut
> down...but the poor, unknowing customer is the one who suffers...I've
> got to wonder if they even notice their appliance is acting strangely,
> or laggy, and why...
> this would best be fixed at the manufacturers end..
At least half of the problem is the refusal of ISPs in general to implement BCP38.
When there would be source address filtering, we would not see all the backscatter
(DNS replies mainly).
Then there are shodan.io and a lot of other "research" systems. I keep a blacklist
to drop all their traffic, but of course it still arrives at the router.
They usually offer unlisting the network, but at least in the case of shodan.io
this is completely fake. A day or a week later they just resume.
Finally we all know about the cheap virtual Linux cloudhosting companies like AWS,
Linode, etc. Probably half blackhats, half sincere users don't even know that
they got hacked. After all, Linux is secure so you don't have to think about that.
Rob
