44net

44net@mailman.ampr.org

3198 discussions

Re: [44net] IPv6
by Steve L 04 Sep '17

04 Sep '17

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.

2 1

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 04 Sep '17

04 Sep '17

> 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

1 0

Re: [44net] An anniversary of a sort - 36 years
by Steve L 04 Sep '17

04 Sep '17

>> 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.

1 0

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 04 Sep '17

04 Sep '17

> 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

2 1

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 04 Sep '17

04 Sep '17

> 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

3 2

Re: [44net] Outdated regulations [Was: OFDM Modem]
by Rob Janssen 04 Sep '17

04 Sep '17

> 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

1 0

Outdated regulations [Was: OFDM Modem]
by Steve L 04 Sep '17

04 Sep '17

I just spotted this. Here is every US hams chance to make direct comments to the FCC. http://www.arrl.org/news/fcc-technological-advisory-council-investigating-t… Steve, KB9MWR

9 9

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 04 Sep '17

04 Sep '17

> 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

1 0

Re: [44net] Outdated regulations [Was: OFDM Modem]
by Steve L 04 Sep '17

04 Sep '17

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

2 1

Re: [44net] OFDM Modem
by Rob Janssen 04 Sep '17

04 Sep '17

> 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

8 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net