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. :(
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?
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. :(
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!
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 think I've covered everything. ;)