New /48 assignments, October 2024
In October 2024 BitFolk assigned new IPv6 /48 netblocks to customers. This article describes how existing customers can make use of these. New customers do not need to know this as this is all set up for them.
TL;DR:
All existing customers have been assigned a new IPv6 /48 per VM. The one you've been assigned can be found at the DNS and IP addresses page of the Panel. You can now start assigning addresses and routes from within it and then they should work. If you don't care about IPv6 or just want to carry on using the addresses you have you can stop reading and do nothing.
History
BitFolk has offered native IPv6 connectivity from the beginning, but has always used IPv6 addresses provided by its colo provider. As that was all out of a single /48 assigned to BitFolk each customer VM got only a /64 and optional /56 netblocks were available on request.
As of October 2024 BitFolk's own IPv6 allocation will be used and new customer VMs (and new installs of existing VMs) will be set up to exclusively use the new IP addresses. Administrators of existing VMs will need to configure the new addresses themselves. There are also some configuration details that may cause problems.
Examples used here
It is normally good practice to use the IPv6 documentation prefix 2001:db8::/32 when giving examples of IPv6 addresses. However, this article is aimed at existing customers of BitFolk and the documentation prefix does not resemble real BitFolk addresses; this could be confusing for those less familiar with IPv6 so we are going to use the following example addresses.
- Deprecated IPv6 assignment
- 2001:ba8:1f1:f004::/64
- New IPv6 assignment
- 2a0a:1100:1018::/48
All BitFolk customer /48 assignments currently start with 2a0a:1100:1xxx and all of the old BitFolk /64 assignments start with 2001:ba8:1f1:fxxx. Yours will look similar to this example apart from the last three hexadecimal digits which will be unique to your VM.
Other assumptions
Main network interface name
We'll assume enX0 which is what it is on the latest Linux releases unless you have forced it not to be. On older releases it will be eth0.
IPv6 enabled, with an open firewall
By default BitFolk VMs don't come with a firewall and do have IPv6 enabled. If you've disabled it or firewalled it off then this is not going to work and you'll have to undo that first.
Making it work
Immediate configuration
Just add a single IPv6 address from inside your assignment.
# ip address add 2a0a:1100:1018::/128 dev enX0
Since the :: means "everything from here onwards is 0", 2a0a:1100:1018::/128 is the same as 2a0a:1100:1018:0000:0000:0000:0000:0000/128. It's the all-zeroes address for your assignment; the first usable IP address.
This address should now be reachable from outside BitFolk. If it's not then you need to do some Troubleshooting and should not continue until you have this working.
Permanent configuration
The above command just adds an address to the running system but does not make that change permanent. To make a permanent change you need to adjust your configuration and that depends upon which network configuration framework is in use.
The basic things you need to do though are:
- Add one or more new addresses
- Add a blackhole route for your whole /48
- Change your default route to be through fe80::1 (optional)
- Add back the deprecated addresses you were using before, if you need to keep using them (optional)
The purpose of the blackhole route is to stop traffic for the vast number of unassigned addresses in your assignment from going back out of your default gateway and looping around inside BitFolk until their TTL expires. It will not cause a problem for any directly assigned addresses or routes you are using. New BitFolk VMs are installed this way and it's BitFolk policy for you to have a route like this, or some other means of preventing that happening.
The purpose of having your default route be via fe80::1 is that it
- is neater 😀
- doesn't use an address from your assignment
- will allow you to stop using the deprecated IPv6 addresses entirely
Things will continue working if you don't do that though.
It is suggested that you make sure you can connect to your Xen Shell console before modifying your network configuration so that if there are problems you can still administer the VM.
Here's how to accomplish the above in various network configuration frameworks.
ifupdown, as typically found on Debian, and older Ubuntu
ifupdown is configured in the /etc/network/interfaces file. The relevant section of your file probably started off looking like this:
iface enX0 inet6 static
address 2001:ba8:1f1:f004::2
netmask 64
gateway 2001:ba8:1f1:f004::1
The netmask line might be missing, with the /64 seen on the end of the line above it instead.
You would change that to this:
iface enX0 inet6 static
address 2a0a:1100:1018::/128
gateway fe80::1
post-up ip route add blackhole 2a0a:1100:1018::/48 || true
pre-down ip route delete blackhole 2a0a:1100:1018::/48 || true
post-up ip address add 2001:ba8:1f1:f004::2/128 dev $IFACE
To test it out, reboot or log in to your Xen Shell console and do:
xen shell> console
# ifdown enX0
# ifup enX0
Note that the network is going to go down when you type ifdown which is why you need to do that from the console.
netplan, as typically found on Ubuntu systems
netplan is configured through a YAML file in the /etc/netplan/ directory.
Yours probably started off looking like this:
network:
version: 2
ethernets:
enX0:
dhcp4: false
dhcp6: false
addresses:
- "85.119.82.121/21"
- "2001:ba8:1f1:f004::2/64"
routes:
- to: default
via: "85.119.80.1"
- to: default
via: "fe80::1"
nameservers:
addresses:
- "85.119.80.232"
- "85.119.80.233"
- "2001:ba8:1f1:f205::53"
- "2001:ba8:1f1:f206::53"
The new version should look like this:
network:
version: 2
ethernets:
enX0:
dhcp4: false
dhcp6: false
addresses:
- "85.119.82.121/21"
- "2a0a:1100:1018::/128"
- "2001:ba8:1f1:f004::2/64"
routes:
- to: default
via: "85.119.80.1"
- to: default
via: "fe80::1"
- to: "2a0a:1100:1018::/48"
via: "::"
type: blackhole
nameservers:
addresses:
- "85.119.80.232"
- "85.119.80.233"
- "2001:ba8:1f1:f205::53"
- "2001:ba8:1f1:f206::53"
After changing the file you can apply those changes with:
$ sudo netplan try
That will apply the changes and ask you to confirm, rolling them back if you don't confirm within a short period of time.
NetworkManager, as found on Red Hat-like systems
NetworkManager can be configured from the command line using nmcli though this may temporarily break IPv6 connectivity (IPv4 should be unaffected).
# nmcli connection modify enX0 \
ipv6.addr-gen-mode eui64
# nmcli connection modify enX0 \
ipv6.method manual \
ipv6.addresses 2a0a:1100:1018::/128
# nmcli connection modify enX0 \
+ipv6.addresses 2001:ba8:1f1:f004::2/128
# nmcli connection modify enX0 ipv6.gateway fe80::1
# nmcli connection modify enX0 \
+ipv6.routes 2a0a:1100:1018::/48 type=blackhole
The new thing here is ipv6.addr-gen-mode eui64. BitFolk is routing your netblocks (both your deprecated /64 and the new /48) to you through the link-local address in your VM so it's necessary for your link-local address to be predictable. NetworkManager appears to take over the generation of these addresses and by default uses a stable-privacy mode.
Unsure if changing the ipv6.addr-gen-mode takes effect immediately or if it needs the interface to be taken down and brought up again. See Troubleshooting for more info.
Reverse DNS
This works exactly the same as it currently does for the deprecated IPs. You can delegate reverse DNS for your whole /48 to nameservers of your choosing at the DNS and IP addresses page of the Panel.
The default setting is for auto-generated reverse DNS.
Monitoring
If ping checks against any of your IPv6 addresses already exist then they were added manually by BitFolk so if you're planning to stop using the deprecated /64 or any /56s you were routed you should ask Support for these checks to be removed. Also ask if you would like a new check to be added.
Over on the users mailing list we are discussing automated IPv6 ping checks. It's not clear if anything will come of this but it may help if you made the first usable address in your /48 work and respond to pings. The first usable address is the all zeroes address, in this example 2a0a:1100:1018:0000:0000:0000:0000:0000/128. Since blocks of four zeroes can be compressed to ':' and multiple consecutive colons compressed to '::', this is more usually written as 2a0a:1100:1018::/128. It is the shortest address string that is available to you.
If you are intending to route /64s or /56s to your users then perhaps you want to keep the first block for your VM itself. sipcalc can help you understand where the next block starts.
Second /64 starts at 2a0a:1100:1018:1::/64:
$ sipcalc --v6split=64 2a0a:1100:1018::/48 | head -9
-[ipv6 : 2a0a:1100:1018::/48] - 0
[Split network]
Network - 2a0a:1100:1018:0000:0000:0000:0000:0000 -
2a0a:1100:1018:0000:ffff:ffff:ffff:ffff
Network - 2a0a:1100:1018:0001:0000:0000:0000:0000 -
2a0a:1100:1018:0001:ffff:ffff:ffff:ffff
Network - 2a0a:1100:1018:0002:0000:0000:0000:0000 -
2a0a:1100:1018:0002:ffff:ffff:ffff:ffff
Second /56 starts at 2a0a:1100:1018:100::/56:
$ sipcalc --v6split=56 2a0a:1100:1018::/48 | head -9
-[ipv6 : 2a0a:1100:1018::/48] - 0
[Split network]
Network - 2a0a:1100:1018:0000:0000:0000:0000:0000 -
2a0a:1100:1018:00ff:ffff:ffff:ffff:ffff
Network - 2a0a:1100:1018:0100:0000:0000:0000:0000 -
2a0a:1100:1018:01ff:ffff:ffff:ffff:ffff
Network - 2a0a:1100:1018:0200:0000:0000:0000:0000 -
2a0a:1100:1018:02ff:ffff:ffff:ffff:ffff
Troubleshooting
If the new IPv6 address you added manually with ip address add … was not reachable, here's some things to try.
Do you have an unpredictable link-local address?
Every IPv6 interface has a link-local address, which is an address with scope link that starts with fe80::. It is for talking to things on the local network (only), typically default gateways and things of that nature.
By default such addresses are generated by the Linux kernel and are predictable; they are based on your MAC address. BitFolk has routed your IPv6 through what it predicts your link-local address will be, which BitFolk can work out because BitFolk knows what your MAC address is. Here's an example of a predictable link-local address (and how to show yours):
$ ip address show dev enX0 scope link
2: enX0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether aa:00:00:6a:38:0c brd ff:ff:ff:ff:ff:ff
inet6 fe80::a800:ff:fe6a:380c/64 scope link
valid_lft forever preferred_lft forever
It's that fe80::a800:ff:fe6a:380c/64 one.
Does yours look a bit like that? Importantly, does it have an ff:fe in the middle and look a bit like the MAC address?
Some systems enable privacy addresses and make even their link-local addresses not be based on MAC address. Here's an example of one of those:
2: enX0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
link/ether aa:00:00:6a:38:0c brd ff:ff:ff:ff:ff:ff
inet6 fe80::f3bb:39a4:10fa:7036/64 scope link noprefixroute
valid_lft forever preferred_lft forever
As you can see it doesn't have ff:fe in the middle and it's nothing like the MAC address.
If you see that you have to either:
- Turn off privacy addresses, or;
- Add the actual predictable address as a permanent address on your side
We will assume that if you want to do (2) then you know how to work out what address to add and how to add it, so go ahead! Option (1) is discussed below.
Disabling privacy addresses
During a survey of the entire customer base it was found that around 9% of customer VMs were not responding on what BitFolk guessed would be their link-local address. All of these were contacted and so far 100% of the respondents were found to either be running NetworkManager or to have disabled IPv6 entirely.
NetworkManager
Privacy addresses can be disabled with nmcli.
# nmcli connection modify enX0 ipv6.addr-gen-mode eui64
This change will be permanent. Unsure if it takes effect immediately. Let us know!
Have you disabled IPv6?
If your IPv6 has never been known to work then possibly you disabled it. This is typically done by adding ipv6.disable=1 to the kernel command line from the boot loader. You can see the kernel command line with cat /proc/cmdline. Once you have changed this you will need to reboot.
Are you firewalling IPv6 too aggressively?
Again, if you have never had working IPv6 this could be because you have firewalled it off.
Fixing that is a bit beyond the scope of this article, but if you have a firewall it's worth checking what rules it has with regard to IPv6. With nftables the rules for both IPv4 and IPv6 are all in one ruleset. With iptables you'll need to do something like ip6tables -nL to list IPv6-specific rules.
Unlike IPv4, IPv6 needs certain ICMP traffic to be allowed to work. If your firewall is default-deny and you don't see any rules allowing that sort of thing then this is probably why IPv6 doesn't work.
Minimal rules to allow IPv6 to work
ip6tables
Here's the least amount of rules for an ip6tables default-deny firewall.
Only some ICMPv6 is necessary, and the source addresses of that necessary ICMPv6 can be tightened up.
-A INPUT -i enX0 -p ipv6-icmp -j ACCEPT
-A INPUT -i enX0 -j DROP
nftables
Help?
Some other problem?
Please contact Support with the following information:
- Account name
- Output of "ip address show"
- Output of "ip -6 route show"
- Whether IPv6 has ever worked for you and to what extent
- Network configuration framework in use if you know it, or at least which Linux distribution you use
Frequently Asked Questions
If you don't see your question here please ask it of Support.
Do I really need to do anything?
No!
If you aren't using IPv6 then feel free to continue not using it. If you are happy with the deprecated addresses then keep on using them.
The main reasons for making this change are:
- Should BitFolk's colo provider ever change you will be forced to stop using the deprecated addresses, possibly at short notice, because those addresses belong to them. There is no indication of this happening at time of writing.
- The new assignments are bigger (65,536 times bigger).
- The new assignments are shorter and therefore more pretty!
Isn't a /48 a ridiculously wasteful amount of address space to give to each VM
BitFolk doesn't think so and neither does RIPE, which considers a /48 per end user site to be fine and a VM as an end user site.
What does my usable address range look like?
You would have 80 bits to use, starting with the prefix 2a0a:1100:1xxx::. Installing the sipcalc utility can make things clearer:
$ sipcalc 2a0a:1100:1018::/48
-[ipv6 : 2a0a:1100:1018::/48] - 0
[IPV6 INFO]
Expanded Address - 2a0a:1100:1018:0000:0000:0000:0000:0000
Compressed address - 2a0a:1100:1018::
Subnet prefix (masked) - 2a0a:1100:1018:0:0:0:0:0/48
Address ID (masked) - 0:0:0:0:0:0:0:0/48
Prefix address - ffff:ffff:ffff:0:0:0:0:0
Prefix length - 48
Address type - Aggregatable Global Unicast Addresses
Network range - 2a0a:1100:1018:0000:0000:0000:0000:0000 -
2a0a:1100:1018:ffff:ffff:ffff:ffff:ffff
So, the first usable address for our example VM would be 2a0a:1100:1018:0000:0000:0000:0000:0000 but as consecutive zeroes can be collapsed down to :: this comes out as 2a0a:1100:1018::, which is also the shortest string available to you.
If you're interested in routing /64s to your end users then as you have 80 bits to play with that means 80 - (128 - 64) = 16 bits of those, or 65,536 of them starting at 2a0a:1100:1018:0::/64
$ sipcalc 2a0a:1100:1018:0::/64
-[ipv6 : 2a0a:1100:1018:0::/64] - 0
[IPV6 INFO]
Expanded Address - 2a0a:1100:1018:0000:0000:0000:0000:0000
Compressed address - 2a0a:1100:1018::
Subnet prefix (masked) - 2a0a:1100:1018:0:0:0:0:0/64
Address ID (masked) - 0:0:0:0:0:0:0:0/64
Prefix address - ffff:ffff:ffff:ffff:0:0:0:0
Prefix length - 64
Address type - Aggregatable Global Unicast Addresses
Network range - 2a0a:1100:1018:0000:0000:0000:0000:0000 -
2a0a:1100:1018:0000:ffff:ffff:ffff:ffff
As you can see, that range ends at 2a0a:1100:1018:0000:ffff:ffff:ffff:ffff and your next /64 would be starting at 2a0a:1100:1018:0001::/64 (also known as 2a0a:1100:1018:1::/64 since leading zeroes can be omitted). And so on up to your final /64 which would start at 2a0a:1100:1018:ffff::/64.
If you're interested in routing /56s to end sites, then you have up to 80 - (128 - 56) = 8 bits, so 256 of those.
Are the deprecated addresses going away?
No, there are no plans to ever do that.
New installs (both for new customers and re-installs of existing VMs) don't use the deprecated addresses though and eventually no BitFolk infrastructure will either. None of the examples on this wiki will refer to them.
What if I need to reinstall my VM and continue using the deprecated IPv6 space?
You will need to contact Support about that, but you can do it.
What if I don't want to disable privacy addresses?
Privacy addresses for link scope seem totally silly.
They're meant to get your MAC address out of the IPv6 address so that other people can't tell what it is, but the only people seeing link scope traffic are on the same network link and already see your MAC address with every Ethernet frame you send. And in fact in this case the only people on the same network link as you are you and BitFolk, and BitFolk knows your MAC address already.
I don't know if it is possible to disable privacy addresses for only link scope and not global scope though. The instructions given in this article disable it for the whole interface.
If you don't want to do that then all you have to do is work out what the predictable link local address would be and add that address as a link scope address on the interface. BitFolk doesn't care whether you added it manually or your kernel did it or NetworkManager did it.
Here's an online generator for link-local addresses.
Do I really have to add a blackhole route?
Yes please. It won't stop anything working for you.
If you don't like that traffic to unassigned addresses just gets silently dropped you can change the word blackhole to prohibit instead. This will cause your VM to send an ICMP error message back to the system that tried to contact the unassigned address. Due to scanners this could end up being quite a lot of ICMP traffic you end up sending though.
Alternatively, this actually only matters during routing so in your routing chain you can firewall off every address block you're not using with a drop rule and possibly some logging to let you know what was dropped. You would then be able to dispense with the blackhole route.