Re: [44net] A new era of IPv4 Allocations

28 Jul 2021

...
  On 28 Jul 2021, at 11:40, Tony Langdon via 44Net
&lt;44net(a)mailman.ampr.org&gt; 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Re: [44net] A new era of IPv4 Allocations