How do I swap IPv6 addresses between Linodes?
I know that you can swap IPv4 addresses between Linodes using this workflow:
However, I would like to swap the IPv6 addresses of my Linodes. How can I do this?
Although Linode Support is able to swap IPv6 address pools that you may request from us between Linodes, we are unable to directly swap the SLAAC IPv6 addresses of your Linodes due to our system architecture. However, you should be able to perform this swap manually using the following method:
Before embarking upon this workflow, I strongly urge you to back up your Linodes or create a manual snapshot of your Linodes through our Backup Service. This will allow you to quickly back out of these changes should you experience any issues with this workflow.
Create a Linode Image for the two Linodes whose IPv6 addresses you would like to swap. You may alternatively use the manual snapshots from your backups instead of creating Linode Images, which will involve a slightly different set of steps as indicated below.
It is ideal to shut down your Linodes before creating these Linode Images -- this will ensure that the image represents your Linodes at a single state in time without any "moving" data.
Deploy these images to the opposite Linode. If using manual snapshots instead, you may instead restore these snapshots directly to the opposite Linode. You should overwrite the Linode's existing data for best results, which should not present any data-loss issues given the existence of your previously created manual snapshots.
Due to the way that our systems are set up, IPv6 addresses are associated with each Linode's ID number, so restoring each image to the opposite Linode will effectively serve to swap their IPv6 addresses. However, this action will not swap the IPv4 addresses between these machines, so you will need to perform this step later.
If your Linodes do not automatically boot up after the image redeployment is complete, boot them up. When logging back into them via SSH, you may encounter a message similar to the following:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:**********************************************. Please contact your system administrator. Add correct host key in ~/.ssh/known_hosts to get rid of this message. Offending ECDSA key in ~/.ssh/known_hosts:### ECDSA host key for 0.0.0.0 has changed and you have requested strict checking. Host key verification failed.
This is a warning presented by your SSH client that it believes you may not be connecting to the machine you may be expecting. Since you are aware of the change that you had made to these machines, it is safe to dismiss this message by removing the old ECDSA key records from your SSH known hosts file, whose line number will be indicated on this line in place of
Offending ECDSA key in ~/.ssh/known_hosts:###
After reconfiguring your
known_hostsfile, you should be prompted to re-add these ECDSA key records when reconnecting to your Linodes over SSH with a message similar to this:
The authenticity of host '0.0.0.0 (0.0.0.0)' can't be established. ECDSA key fingerprint is SHA256:**********************************************. Are you sure you want to continue connecting (yes/no/[fingerprint])?
yesat this prompt should confirm the addition of this key record to your
Warning: Permanently added '0.0.0.0' (ECDSA) to the list of known hosts.
You should not experience any further troubles using SSH to access your machines after doing so, but if SSH access still presents you any further troubles, you may use the Lish console to access your Linodes.
Once you are able to log into your Linodes via SSH or Lish, you may use the
ip -6 addresscommand to determine what your machines believe their IPv6 addresses to be. This should indicate the successful "swap" of IPv6 addresses for these hosts, which you may further confirm by running a
pingtest from an outside device to each of these Linodes' IPv6 addresses (assuming no firewall rules are in the way).
At this point, you may swap the IPv4 addresses between your Linodes. A final reboot of your Linodes is ideal to ensure the proper uptake of this IPv4 address swap (again, assuming no firewall rules are in the way).
Please feel free to follow up with a response if you have any questions about this procedure!
@andrewm I recently sent in a feedback email about being able to swap IPv6 addresses - in particular the /64 ranges.
Are there any plans afoot to implement this functionality.
I get it may be a bit difficult with the SLAAC addresses but the Manager reports the /64 range is routed to one of these addresses, so a simple interface listing your allocated ranges and allowing us to specify to which Linode SLAAC they are routed to would be brilliant.
@andrewm I recently undertook building a new pair of Linodes and asked Linode Support to swap the IPv6 ranges.
24 hours later, I’m still waiting. This isn’t workable for live applications when I don’t know when a switchover will happen.
PLEASE give us the ability to swap IPv6’s on-demand like you can with v4… at least the pool routing if nothing else.
@andysh Thank you for the feedback you've sent. At this time, we don't have an ETA on implementing this feature, and we have included your suggestion on our internal tracker. We also found your ticket and someone will respond to it shortly.
@rdaniels thanks for looking and for getting my ticket sorted.
This is the only part of Linode that feels very “non-cloud” as it still relies on human intervention.
Plus this would enable you to effectively allow “floating” IPv6 addresses if they could be swapped at the drop of a hat, just like IPv4s can now. Talking of drops, it would also give you an edge over a certain water-themed competitor as they can only offer floating IPv4s too :)