44net

44net@mailman.ampr.org

4 participants
3198 discussions

Re: [44net] amprhosts update
by Rob Janssen 19 Jul '19

19 Jul '19

> 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

2 1

Re: [44net] A few thoughts on recent developments
by Rob Janssen 19 Jul '19

19 Jul '19

> 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

1 0

amprhosts update
by Pedro Converso 19 Jul '19

19 Jul '19

Seems that mails to ampraddr(a)ucsd.edu requesting IN A is not answering. Or something changed ? Please help 73, lu7abf, Pedro

1 0

Re: [44net] IPv6 adoption (was: address sale)
by Heikki Hannikainen 19 Jul '19

19 Jul '19

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

2 1

Re: [44net] 44.192/10 route looping observation
by Rob Janssen 19 Jul '19

19 Jul '19

> 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

1 0

44.192/10 route looping observation
by Phil Karn 19 Jul '19

19 Jul '19

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

2 1

Re: [44net] 44/8
by Bryan Fields 19 Jul '19

19 Jul '19

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

2 1

Reverse DNS broken
by Michael Fox - N6MEF 19 Jul '19

19 Jul '19

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

6 9

Re: [44net] Time to restructure the network?
by Rob Janssen 19 Jul '19

19 Jul '19

> 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

1 0

Re: [44net] Time to restructure the network?
by Rob Janssen 19 Jul '19

19 Jul '19

> 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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net