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