44net

44net@mailman.ampr.org

3198 discussions

Re: [44net] IPv6
by Rob Janssen 03 Oct '16

03 Oct '16

> Perhaps someone would like to know not only what are the callsigns under > which both endpoints of the RF are operating, but also who is the > Amateur that originated the message and which Amateur is the final > recipient. I can imagine several reasons to want to know these. In the packet radio days, our license conditions explicitly included this requirement. It was fulfilled by ordinary digipeating, but not by NET/ROM. I added support to my version of NET to make NET/ROM nodes operate as a virtual digipeater, so the outgoing connect of a NET/ROM on behalf of a user was not made under the USERCALL-(15-SSID) call, but as "user via node". (a packet that was transmitted by the node as if it had been digipeated by the node) IP was a problem under those regulations, however an arrangement was made with the authorities that source and destination of the traffic were sufficiently identified when there was an accessible list of IP addresses and corresponding callsigns. The hosts files provided that information. (I doubt that the authorities ever listened in on amateur IP over AX.25 traffic and tried to identify the endpoints, I heard that the only AX.25 equipment available at the monitoring station was a PK-232) However, since then we have lost our "license" and now operate under a "unlicensed station with mandatory registration" regime here, with usage conditions that are far less detailed. Operating modes are no longer specified, only identification modes. As long as you ID your station in one of a specified set of modes, they no longer care what you transmit and what its source is. This also makes it legal to forward internet content, something that was not allowed under our old license conditions (that explicitly prohibited 3rd party content and connections with external networks). But of course it can still be useful to have identification information in IPv6 addresses, if only because of the general lack of reverse-DNS information in the IPv6 network. Rob

2 1

Re: [44net] IPv6
by Rob Janssen 02 Oct '16

02 Oct '16

> I don't see why anyone would want to encode information about the > country in the first 64 bits, especially since you can use compound > callsigns such as PA/EA4GPZ if you're operating abroad. > Perhaps it would be interesting to have the information about the > Maidenhead locator or GPS coordinates of a subnet (where this makes > sense). Someone could use this info to make a geographical map of the > network. However, I think that this info should belong to an external > database (whois maybe) and not be encoded in the IPv6's. I also don't think it should be done that way, especially because we seem to agree on the idea that we do not want to have a large IPv6 network for amprnet (which we could subnet in creative ways), but rather use the IPv6 addresses provided by a local ISP. We don't have control over the numbering and network size of those addresses, and especially during the initial phase of the rollout there will always be ISPs that do not understand IPv6 and give a customer only a single /64 or even less. Hopefully that will change later, but we cannot wait for that forever. So, keep all special handling in the last 64 bits and treat the first 64 as random. I think a special handling of the address should not even be mandatory, only a good suggestion that may help others to determine the source of traffic easily. It should still be possible to send traffic from addresses not conforming to this methid, at most risking that it will be dropped at an internet-radio gateway when prior arrangements have not been made. Probably a next step would be to standardize a method to distribute information about valid IPv6 AMPRnet networks (that can be somewhat trusted in access lists). E.g. use BGP, downloadable textfiles, (ampr-)RIPv6, etc. It may not be possible to standardize a single method due to limitations of used software and hardware, although this probably is less important than with the current gateway list. (where we need to remain compatible with very old software that cannot do IPv6 anyway) Rob

4 3

Re: [44net] IPv6
by Rob Janssen 02 Oct '16

02 Oct '16

> Hmm.. Do you have any examples of such ISPs? I’ve only seen them give out a /64 to the PPPoE / WAN interface and then also have a routable /56 or /48 which is almost always available using DHCPv6-PD. The /64 is only used for communication with the ISP (can also be a /126) while everything else if up to the router to manage. Although I do get a /48 from my ISP there is nothing I can manage about the subnetting. The 16 bits between my prefix and my networks are assigned by my router using DHCPv6-PD and there is nothing I can do to set these bits. They are assigned to my networks sequentially. I don't think it is feasible to use those bits with a special meaning. Rob

3 2

Re: [44net] IPv6
by Rob Janssen 02 Oct '16

02 Oct '16

> 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

2 1

Re: [44net] IPv6
by Rob Janssen 01 Oct '16

01 Oct '16

> 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

2 1

Re: [44net] IPv6
by Rob Janssen 01 Oct '16

01 Oct '16

> 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

4 5

IPv6
by Dani EA4GPZ 01 Oct '16

01 Oct '16

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.

1 0

Re: [44net] Security - Telnet (port tcp/23)
by Rob Janssen 01 Oct '16

01 Oct '16

> 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

1 0

Re: [44net] Security - Telnet (port tcp/23)
by Rob Janssen 30 Sep '16

30 Sep '16

> The unanswered SYN traffic to port 23 is much, much more. Especially before the "allow only > registered hosts" filter. We are dropping around 80 Mbyte/day of traffic for our /16 subnet due > to the address not being registered, so that would be about 20 GByte/day for amprgw.... Of course it is way more than that. I forgot that the about count is only for the subnets within our /16 that are actually routed. That is about 1/5 of our space. So the total "noise" traffic is more like 400 MB/day and would be like 100 GB/day for the entire AMPRnet. Rob

4 4

Re: [44net] Security - Telnet (port tcp/23)
by Rob Janssen 30 Sep '16

30 Sep '16

> I usually allow remote access (SSH, RDP, etc...) through VPN only. > When access from Internet is absolutely required (because it's not > possible to have a VPN), then I usually add a firewall rule to allow > access only from a list of known WAN IP addresses. That is certainly the best approach! Also, whenever possible, I run those protocols on IPv6 only, preferably on an address that is not as well in DNS for other services on the host. They cannot viably scan the IPv6 range so this obscurity hides the remote access quite well. Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net