IPv6-first networking

Ankra Cloud sells the cheapest useful unit of compute: one server with a public IPv6 prefix and no IPv4 address. IPv4 addresses are scarce and expensive (around €40–50 each to buy), so bundling one into every server would make small servers impossible. IPv6 is plentiful, so every server gets a lot of it.

What every server gets#

The API fields are public_ipv6 (default true) and public_ipv4 (default false) on POST /v1/servers. A server must have at least one of a public IPv6 prefix, a public IPv4 address or a private network. The server view reports public_ipv6 (the address), public_ipv6_prefix (the /64) and public_ipv4 (or null).

IPv6 is never a line on your invoice. The prefix belongs to the server for its lifetime and is returned to the zone's pool when the server is deleted.

Moving to a public IPv6 address#

A zone can move to a new IPv6 prefix. New servers then get their /64 from the new pool, and servers created before the move keep the /64 they have. Some of those older /64s are private: a unique local address such as fd64:1:0:5::1 (the view reports public_ipv6_is_private: true) that servers inside Ankra Cloud reach and the internet does not. The portal marks such an address as private and shows no SSH command for it.

When ipv6_renumber_available is true, Move to a public IPv6 address on the server's overview (or POST /v1/servers/{id}/renumber-ipv6) gives the server a new /64 from the zone's public pool. A running server restarts to take it, so it is unavailable for up to a minute; a stopped server takes it on its next start. Its IPv4 add-on, floating IPs and private network addresses stay the same, and bastions forward to the new address. Update any DNS record that names the old address. The move is refused while a load balancer member, edge member or firewall rule names an address of the old /64; the error lists them so you can change them first. Servers are never moved on their own.

How the /64 is routed#

Each zone announces a /48 to the internet and delegates one /64 of it to each server. The server's default IPv6 route points at fe80::1, a link-local gateway address every gateway of the zone holds at once, so there is no single gateway to fail over. Addresses are configured statically when the server is built; router advertisements from the guest are dropped and neighbour discovery never depends on learning.

Anti-spoofing is enforced on every interface: a server may only send from its own MAC address and its own addresses (its /64 on the public interface, its assigned addresses on private legs). ICMPv6 neighbour discovery and packet-too-big messages always pass, whatever your firewall rules say, because IPv6 does not work without them.

Reaching the IPv4 internet#

An IPv6-only server reaches IPv6 destinations directly. Where the zone runs a zone NAT64, it also reaches the IPv4 internet with nothing to set up, through the zone's NAT64 for the well-known prefix 64:ff9b::/96:

• IPv4-only names resolve through the zone's DNS64 resolvers to synthesised 64:ff9b::… addresses, so curl https://ipv4-only.example or apt install just work.
• IPv4 addresses typed as literals (ping 8.8.8.8, curl -4 …, software that only speaks IPv4) work through 464XLAT: every IPv6-only server gets a CLAT (clatd, installed and started at boot by the platform's cloud-init vendor-data), which gives the server an IPv4 default route on its clat interface and translates that traffic to IPv6 from the address <your prefix>::c1a7 (inside your /64, or your /80 in zones that delegate /80s). Your own user-data does not replace it, and a server that later gets IPv4 of its own stops using it at its next boot.

Traffic through the zone NAT64 leaves from the zone's shared IPv4 address, outbound only: nobody on the IPv4 internet can open a connection to your server through it. For a stable IPv4 address of your own, or for the zones without a zone NAT64, there are three options:

1. A NAT gateway edge on a private network the server is attached to (recommended). The edge runs NAT64 for the well-known prefix 64:ff9b::/96 and a DNS64 resolver, so apt install or curl https://ipv4-only.example just work: DNS64 answers with a synthesised 64:ff9b::… address and NAT64 translates the traffic out of the edge's IPv4. See Network edges.
2. A router with NAT on the private network (NAT44 for the network's IPv4 subnet, €10 a month). Servers route IPv4 through their first network's router.
3. The public IPv4 add-on on the server itself.

A network has either a NAT router or a NAT gateway edge as its IPv4 exit, never both.

Reaching IPv6 servers from IPv4 clients#

IPv4-only clients (many office and mobile networks still are) reach IPv6-only servers through a network edge:

• Bastion: SSH jump host with its own IPv4 address: ssh -J admin@<edge IPv4> debian@<server>.
• Load balancer: one IPv4 frontend in front of IPv6 backends, for HTTP(S) and other TCP services.

One IPv4 address per network instead of one per server is what keeps the compute cheap.

Metadata and DNS#

The metadata service answers IPv6-only servers at http://[fd00:ec2::254]/ (and at http://169.254.169.254/ when a server has IPv4 of its own; the CLAT's IPv4 is translated to IPv6, so use the IPv6 address). IPv6-only servers get the zone's DNS64-capable resolvers, replaced by the network edge's own DNS64 resolver when their network has a NAT gateway edge.

Firewalls and IPv6#

Firewall rules take IPv4 or IPv6 addresses and CIDRs in remote_cidr. Because the whole /64 is routed to your server, write rules against the prefix when a service binds to more than the first address. See Floating IPs and firewalls.