> 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
Folks,
I'm sure folks will want to express their outrage about the address sale for
months.
In the meantime, let's focus on what we can control. How do we get reverse
DNS working again for the part of 44/8 that wasn't sold?
Michael, N6MEF
> But setting up Marius' script on Mikrotik is easy as pie and it
> configures the rest "automagically" whereas configuring BGP on a tik,
> although easy for those of us that do such things daily, is not that
> easy for non network-technical folks
Actually, when you think that setting up Marius' script on Mikrotik is easy,
you already know enough about MikroTik to make setting up your router as
a VPN client to one or a couple of routers on internet and configuring BGP on
those VPN links much easier than that.
It would be very easy to write a howto for doing that which includes sample
configuration where you only need to fill in some fields like the username
and password of your VPN, the AS number assigned to you, and the AS number
and net-44 address of your peer.
Probably even a script could be written that performs the configuration
itself based on the few variables it requires, similar to what Marius'
script does when installing it.
Rob
> it's still possible to setup a VPN to a remote host and interface with
> the IPIP mesh there. It's not idea, but it's a solution. As long as all
> the nearby sites have a route over VPN, it can work. By tuning the VPN
> parameters, latency can be kept down.
That is what we have operating right now. Our 44.137.0.0/16 network
is now BGP announced from a datacenter where we have a MikroTik CCR1009
router that has many users connected via different kinds of VPN
(L2TP/IPsec, GRE, GRE/IPsec, GRE6 (GRE over IPv6)) and the users run
BGP to announce their subnets and receive our subnet.
They can (and do) inter-connect using radio links and setup BGP peering
over there as well, so the routing between users can be over radio and
towards internet over the VPN. We have some BGP communities to steer
the routing, e.g. to prefer a multihop radio path over a path via VPN
which is always two hops at most.
This router is on the IPIP mesh as well, but when that mesh were to be
taken down we only would need to setup some similar VPNs and BGP
peerings, of course one to UCSD where a router would be for the space not
announced separately (44.0.0.0/9 and 44.128.0.0/10), and anyone in the
world would have the possibility to setup a VPN server for some subnet
(be it BGP announced or not, that does not matter) and serve their
local users from it. Users in a region not covered by such a service
could connect to UCSD and have similar performance to what it is now.
Those VPN servers do not need to peer with ALL others, but they can peer
with a couple of them and we still have redundancy.
In addition to this, we also offer OpenVPN VPNs without BGP, for users
that are endpoints only. A single fixed address is routed to the VPN
client when it is connected.
This all is really easy for the users to setup, and when the L2TP/IPsec
VPN is used it works over all internet connections even when they have
dynamic address, are behind CGNAT, have agressive firewalls, or whatever.
Should it prove necessary, an SSL based VPN like SSTP could easily be
added (it uses TCP port 443 so it always works, but of course VPNs using
TCP transport are to be avoided when possible)
BGP in the MikroTik routers is configured in a few mouseclicks or a
cut-and-paste of a small text fragment. Set the local AS and ID, add
a peer with remote address and AS, set 2 or 3 options, and it works.
For best operation, use a small routing filter that can be cut-and-paste.
Rob
