On 28 Jul 2021, at 11:40, Tony Langdon via 44Net 44net@mailman.ampr.org wrote:
On 28/7/21 7:08 pm, Antonios Chariton (daknob) wrote:
Hello Tony, thank you very much for your e-mail!
Arrrgh, your use of Reply All and not deleting the direct email disabled my Reply List function, it seems. :(
Sorry, I just hit “Reply” now so it won’t happen again.
Indeed, some users will have to renumber under the proposed scheme. This is why we included the statement to the Board that they will support these users in doing so. As a side-note, most of the TAC will have to renumber to some degree and ARDC will have to renumber its infrastructure as well.
We hope that we will give everyone adequate time to do that, so it will be as painless as possible, but this depends on the people doing it as well, how early they will begin, etc.
Hardly painless! I have a VPS with approximately 200 active IPs on it. A number of the services are tied to a specific IP, requiring third party intervention to get working again, which requires a degree of coordination One of the reasons I switched from provider commercial IPs to 44.190.x IPs was to avoid that, as my service provider has had to renumber a few times over the years, as his commercial arrangements changed.
This would be the most difficult transition, as I'll have more IPs than ever before to manage, unless I do it in a few stages. I'd also be hoping I can parse some configuration files through sed (hand editing 200 entries is error prone!). Does anyone know how many IPs a Linux box can have on an interface?
I understand that a renumbering is not painless. But at least we are here to help to make it as painless as possible. I wish we could do something better. Germany had to renumber more than 8,000 hosts recently and it’s not something that we want anyone to go through often.
We aim to make this change a long-term decision: we do not plan on changing the use case again. However, keep in mind that the TAC members have an one year term. Ours expires in about 7 months. It may be different people next year with different opinions, but we hope that the Board will agree to the “at least 5 years” that we proposed.
There are some technical solutions (like netmap that I mentioned in a previous e-mail) that can help you be available on the new space from day 1, and then give you enough time to renumber the hosts while both IP addresses work at the same time. As I said earlier, we plan to give time to people, and we hope that it will be something that will happen only once. We are also all available here, in this mailing list, to share our experiences and help each other. I am sure that Germany has plenty of that to share with us as the unofficial 44 Net champions of renumbering :)
We are all in this together, and I would like to think that we are all working towards a common goal. Renumbering is something that we have to do, but the benefits of doing so will probably outweigh the cost, especially in the long term. The ARDC Board typically sets the direction for many years to come, and not for short periods of time that then get changed frequently.
For a renumbering of BGP space where Geolocation is important I think it will slightly increase the time it takes, but probably not the effort. What I would do is to get an allocation from 44.31/16 right now and change its geolocation by notifying all the providers as soon as I begin advertising it. From my personal experience, most providers will have updated their location within 2 weeks, but the tail end of them will need up to three months. If geolocation is important, you can wait for 3 months, or however much it takes for the provider you rely on to update it, and then perform the migration within e.g. 1 or 2 months. After this is done, you can release back the 44.190/16 space back to the pool. The TAC proposal will likely cause a lot of changes in the geolocation landscape of the IPv4 Internet, so if there are some particularly slow providers there, we could definitely reach out to them, inform them of this change, and request that they update more frequently if possible.
Seems the provider Echolink uses is near the longer end of that range. :(
Yes, this is something that causes issues for network operators globally.. Just have a look at NANOG and all the geolocation problems they have weeks after the acquisition of new space. But Echolink is an amateur radio software, so I am confident that we could talk to the maintainers and be able to work out a solution, because of the changes that we do in a large scale. In the worst case that this isn’t possible, I think the 3 month period is definitely a reasonable time to wait for, if not more.
Don’t worry, we propose these changes to enable people, not to break their use case and cause them problems.
Also, in case it wasn’t clear, we don’t expect people to migrate immediately after the Board approves this. There will be a transition period of O(months) definitely. However, it will not be a “flag day” where we go at a specific date and time and change everything, globally. People will have to slowly migrate at a pace they can be comfortable with. We don’t want to cause any more trouble than we have to. The only reason to accelerate the transition is that as more and more people migrate to their respective use case, they may adjust their routing and firewall rules, which means that you will slowly lose reachability if you are on the “wrong” use case.
I can see why you're doing this, and on paper, it's a good idea. Ironically, for me, the IPIP tunneled space on my LAN would be easier to renumber!
Then start from that :) Let’s all take easy small steps first for quick wins, and move to the more complicated ones after we determined a path and found a solution.
Finally, for the record, 44.190/16 was a space that concerned us a lot, as it’s exactly what you describe. However, most Direct BGP users were in 44.0/10, and 44.128/10 already had multiple /16’s worth of Intranet users. About 80% of the IP addresses that respond to a ping and are exclusively available via an Intranet reside in this block.
I hope the above answer is adequate, but I will be happy to provide more information if needed.
It's going to be a nightmare scenario this time, the last time put my D-STAR reflector (REF023) offline due to unanticipated complications. I think I can avoid this one, however. Luckily, my DVSwitch and other digital reflectors aren't in this space.
Off the top of my head, the IRLP and D-STAR reflectors require external administrative intervention to change. The Echolink infrastructure doesn't require outside help, just a LOT of reconfiguration, as every IP involved has to be explicitly configured. The easiest part is the web and normal Internet services, which just require DNS changes (a dozen or more A records is about the size of that). Luckily I never trusted the geolocation enough to register an Echolink relay server, otherwise I'd have to contact them as well.
I can’t say I am familiar with that personally, but I would start a thread on the mailing list to figure out what other people did. Probably Germany had at least a D-STAR Reflector and an Echolink Proxy and they can provide some insight on how they did this. Alternatively, we can all figure out a path to do this together. You’re not alone! Collectively it should be easier!
I think I've covered everything. ;)
Thank you very much for the comments!
Antonis