Hey everyone, if you are like me and you’re working to update your firewall rules to carve out the recent subnetwork sale, I’d like to remind you that the proper way to refer to the portion of the network that has been sold is this:
44.192.0.0/10
The converse, “44.192/10” actually expands to "44.0.0.192/10” in some software, and this is probably not what you want!
-Jeremy
> But hey, if you'd really like to go back to only one ACL entry, we could
> also sell 44.128/10. Then you'd only need 44/9. <-- (note smiley)
Actually there would be plenty of space with just the /9 when it had not been
all allocated to the US in the beginning. OTOH, had that been the case, we probably
had been tempted (or forced) to sell it off (or just release it) much earlier.
Rob
Let me propose you an idea although it's an off-topic in this list. We have a serious problem
in amateur radio regarding digital development. It is software quality, platform independence
and openness.
I fully agree. If I have any say in this, *all* hardware and software
development funded by our grants must be open sourced and made freely
available. If you want to keep it proprietary, don't do it with our money.
Some of you may have heard of FCC RM-11831, which would effectively ban
any air interface on the ham bands that isn't publicly documented.
I filed comments stating that while I am personally sympathetic to the
principle that all amateur air interfaces should be open, trying to
enforce that now with a legal rule would have serious unintended
consequences. All three VHF/UHF digital voice modes (D*Star, DMR and
Fusion) would be banned because they all use unpublished voice codecs
proprietary to Digital Voice Systems Inc. I argue that a much better way
to deal with proprietary air interfaces on the ham bands is to beat them
at their own game: develop superior open source alternatives and
persuade hams to adopt them.
This has already been done for low-bit-rate voice coding: VK5DGR has
developed the excellent Codec2 and made it freely available.
So here is our chance to seriously pursue development of advanced, 21st
century digital communication systems that, from the beginning, will be
free and open.
73, Phil
> Seems that mails to ampraddr at ucsd.edu <https://mailman.ampr.org/mailman/listinfo/44net> requesting IN A is not answering.
> Or something changed ? Please help
Long ago it has been changed to ampraddr(a)gw.ampr.org
Rob
> i) Of note: Brian did ask for donations to offset these expenses which
> were largely ignored.
At that time I actually attempted to make a donation but it got stranded in the payment process.
(I did not want to open an account at a US banking company for it, and I did not understand the
peculiarities of their banking system. Here, you would simply ask the receiver for their bank account
number and transfer the money to it, but there the account number apparently is something you need
to keep secret so Brian would not give it to me. Not something particular to ARDC, with AMSAT it went
the same way...)
Rob
On Fri, 19 Jul 2019, Phil Karn wrote:
> On 7/18/19 23:12, Holger Baust wrote:
>> Is there a IPv6 Block registered to HAMs?
...
> Most ISPs that natively support IPv6 also support prefix delegation.
> They'll typically give you a /64 that you can hand out on your LAN with
> DHCPv6 or stateless autoconfiguration (e.g., advertise with the Linux
> radvd daemon). Some will give you more than one /64 if you ask, but
> nothing actually says you must use a /64 only on a single LAN. You can
> always divide it further if you like, and with twice as many bits in the
> host part of an IPv6 /64 as in the entire IPv4 address space, this can't
> be hard.
Some home router firmwares seem to insist on /64 for using the delegation, so
it might be tricky on some setups. But should be possible to put together at
least on a Linux box with some creative configuration.
>> The usage of IPv6 has some problems. First a lot of software has to be
>> recompiled or completedly rewritten,
> I don't think so. IPv6 has been out for a very long time.
Right, for most applications "completely rewritten" is not true; just some
small parts need to be rewritten in software which uses older low-level network
socket APIs.
Applications using higher-level networking APIs (such as "fetch this URL for me
please" APIs in libraries and operating systems) don't need to be touched as
the code behind those APIs has already been fixed years ago. I've got a lot of
experience in IPv6 support validation and configuration at $work, and with my
hobby systems too, so I know this from practice.
Applications specifically dealing with things as IP address allocation or DNS
data manipulation: yes, those need a lot more work. Such as the amprnet address
allocation portal. Not a small task.
>> the other problem sits between
>> several chairs and keyboards. (as in a lot of other internet companies)
Right, but this thing needs to be done eventually. The world is moving on.
>> Some developers, admins and ops do not understand the new addressing or
>> routing and some hardware vendors do not give IPv6 a priority in
>> developing...
>
> As I said, IPv6 is much more widely supported than many people realize
> and the only problem is just getting people to turn it on.
It's a good idea to check this graph yearly, stare at the growth between 2015
and today for a while, do a little mental extrapolation from there, and think
of the consequences:
https://www.google.com/intl/en/ipv6/statistics.html
Some 25% to 30% of client traffic to Google use IPv6 *today*. Up from 5% at the
beginning of 2015. There's some weekly variance due to office/home use if you
zoom in (weekends: more IPv6 traffic towards Google).
It's getting turned on a lot right now. The wheel is rolling, the momentum is
there.
As for the difficulty: I didn't find it that hard. The addresses are harder to
remember. More cut-n-paste work, but a lot of it can be automated, and DNS help
once you bother to set it up. But the routing is... basically just the same as
IPv4, just with more bits!
Commercial hardware hardware and software vendors are moving pretty fast, and
have mostly implemented IPv6 already. All major network operators, ISPs and
such absolutely *require* IPv6 support when purchasing anything, and have done
so for quite some time.
Smaller vendors are lagging more (think of the APRS iGate appliances,
remoterig boxes, and other gadgets made for small audiences). But I
suspect the ease of setting up direct remote access to those gadgets,
thanks to the lack of NAT in IPv6-enabled residential networks, will get
that ball moving soon. Just open up the firewall - the thing will have
it's own public IPv6 address just like that, no need to do port
forwarding!
- Hessu, OH7LZB / AF5QT
> I just noticed that traceroutes from my home to, e.g., 44.192.0.1, get
> stuck in a routing loop within the rr.com network.
Apparently they have some default routes in a loop...
My ISP returns a !N
Rob
I just noticed that traceroutes from my home to, e.g., 44.192.0.1, get
stuck in a routing loop within the rr.com network. (I'm on Spectrum
Cable, formerly Time Warner Cable which branded its service as
"roadrunner" (rr.com). I suppose this means Amazon isn't BGP advertising
these addresses yet.
Traces to, e.g, 44.0.0.1, 44.64.0.1 and 44.128.0.1 all behave as expected.
Just an observation.
Phil
This is a below an email I sent to the NANOG list.
On 7/18/19 10:57 PM, Majdi S. Abbas wrote:
>
> What's interesting about this is it was not an ARIN allocation,
> and the ARDC folks are not the original registrant. This IANA /8 was
> initially delegated to a community, not an organization.
>
> So, to the individuals listed in the blog, that I've excerpted
> below, what do you have to say about this?
>
> Brian Kantor
> kc claffy
> Phil Karn
> Paul Vixie
This is par for the course with ARDC. I was a TAC committee member (I
resigned in disgust just 15 min ago), and the board has failed to inform
anyone this was happening.
I discussed this prior as we could lease it, do something with it, make some
money from it, and was 100% shot down. This has always been Brian Kantor's
private little thing ever since he took over administration of it. This take
over was before ARDC existed, and ARDC was never structured to be a proper
community focused organization. I'd addressed this at TAPR meetings and NANOG
with Brian and KC before. This also over looked the huge conflict of interest
in KC being a board member of ARDC and Network Telescope getting a feed of
44/8 direct at no cost. This 44/8 announcement and UCSD routing broke
connectivity to directly connected BGP subnets for years.
My concern as an ARDC supporter an member is now no planning in the community
for this, many people assume 44/8 is going to be licensed amateurs (I have
many firewalls with permit 44/8 in them), and no accountability of what ARDC
is doing. I believe with Brian retiring from UCSD he's looking for a job and
being a board member of a well funded 501(c)3 can be a lucrative job.
Also it's 100% broken reverse DNS for all of 44/8. :golf clap:
This was theft from the community it was meant to serve.
--
Bryan Fields, W9CR
Former ARDC TAC member
727-409-1194 - Voice
http://bryanfields.net
