On 26/09/2024 00:41, Andy Smith via BitFolk Users wrote:
If I understand you correctly, this is not the case, and I would like to
understand why you have come to this conclusion so that I can avoid
implying it when we communicate about this in future.
I conflated "Past experience has shown that the majority of people won't
be interested in the upgrade and would rather not have to do anything"
and "since eventually all servers do require at least an OS upgrade"
into a possibility that the "OS upgrade" was an upgrade of the OS
running on the VMs rather than the OS providing the VMs. That seemed
unlikely, but the two things together made me a little uncertain, hence
my query. Your answer is the one I most expected.
I do not
expect to take away the legacy assignments from out of the
2001:ba8:1f1::/48 provided by Jump from existing VMs, but after we begin
rolling this out new VPS orders and new self-installs will not have the
legacy IPv6 space. At some point in the fairly distant future a retirement
date will be announce for that range.
When the distant future arrives (it's always sooner than you think) will it
be possible to route old and new subnets in parallel for a while?
I don't expect to ever take away the Jump /64s but they do belong to
Jump, so if Jump ceases to exist as a business or if BitFolk decides to
change colo provider, we lose the ability to use those IPs. That is not
the case for the 85.119.80.0/21 IPv4 space, which is BitFolk's, as is
the 2a0a:1100::/29 which we should also be using.
I'd be happy to have a /56 allocated in the Bitfolk address space and
then relinquish the Jump addresses after a few months when I'd moved
every thing over. It would probably be worth the effort to remove the
dependency on the existence of Jump.
Simon.