Why Do It?
With the increasing pressure to transition to IPv6 due to the rising costs of acquiring IPv4 addresses, this guide aims to provide a collaborative comprehensive overview of setting up Proxmox vms with only IPv6 addresses (single stack) while still allowing access to and from IPv4-only services from individual VMs and the host network.
I will update this guide as you contribute in responses. Ideally we get this simplifed down to a numbered step by step to add to Proxmox official docs.
Despite the long history of IPv6 (see https://www.arin.net/resources/guide/ipv6/history/), it is surprising how many services still do not allow access from IPv6 networks (e.g., GitHub: https://github.com/orgs/community/discussions/10539). This guide aims to bridge the gap and provide a collaborative resource for those facing challenges with the IPv4-to-IPv6 transition. As you are reading please consider what you can contribute to this guide with your exprience.
Overview
Because IPv6 is not directly compatible with IPv4, to achieve backwards compatibility with IPv4, you can use a "SIIT server" along with DNS64 and NAT64. This acts as a translation gateway between your IPv6 only vms and IPv4 only targets. There are public services that offer this, such as https://nat64.net/, or you can host your own server using Tayga or Jool. Jool provides excellent documentation on the differences between SIIT, DNS64, and NAT64: https://www.jool.mx/en/intro-xlat.html.
Here are simple definitions of these technologies:
- SIIT (Stateless IP/ICMP Translation): SIIT is a broad term for any address translation method that enables IPv6-only hosts to communicate with IPv4-only hosts and vice versa. It works by replacing the headers in IP packets. SIIT can be stateless (Stateless NAT64) or stateful, depending on whether it maintains the state of network address translation.
- DNS64: DNS64 is a SIIT mechanism used with NAT64. It provides name resolution for IPv6 hosts trying to reach IPv4 servers. DNS64 creates synthetic AAAA records (IPv6 addresses) for IPv4-only servers, allowing IPv6 hosts to communicate with them using NAT64 translation.
- NAT64 (Network Address Translation): NAT64 is a SIIT mechanism that enables IPv6-only hosts to communicate with IPv4-only hosts. It translates IPv6 addresses to IPv4 addresses and vice versa. NAT64 can be stateless or stateful, depending on whether it maintains the state of the translation. In a NAT64 network, DNS64 and 464XLAT are often used together for end-to-end communication between IPv6 and IPv4 hosts.
In summary, SIIT is the overarching method, while DNS64 and NAT64 are specific tools within the SIIT framework.
The EAMT (Explicit Address Mapping Table)
The EAMT is a table that contains rules or mappings for address translation. Each entry includes an IPv4 prefix and its corresponding IPv6 prefix. When an IP packet needs translation, the SIIT device refers to the EAMT to determine how to translate the source and destination addresses.
Here's a step-by-step guide on how an IPv6-only machine can access an IPv4 address using an SIIT server:
- IPv6-only Machine Initiates a Request: Your IPv6-only machine wants to access a website with an IPv4 address, such as "192.0.2.50". It sends a request to the SIIT server, which acts as a gateway between IPv6 and IPv4 networks.
- SIIT Server Receives the Request: The SIIT server receives the IPv6 packet and identifies that the destination address needs to be translated.
- Address Translation using EAMT: The SIIT server looks up the EAMT to find the corresponding IPv6 prefix for the IPv4 address. For example, the EAMT maps the IPv4 address range containing "192.0.2.50" to the IPv6 prefix "2001:db8:1::/48".
- Translation and Forwarding: The SIIT server translates the IPv4 destination address ("192.0.2.50") into an IPv6 address within the specified prefix, e.g., "2001:db8:1::50". It updates the packet with this new IPv6 destination address and forwards it toward the IPv4 network.
- Reverse Translation at the IPv4 Network: Upon reaching the IPv4 network, another SIIT device (or the same SIIT server) performs the reverse translation, replacing the IPv6 destination address with the original IPv4 address ("192.0.2.50") for correct routing to the intended IPv4-only server.
- Response and Reverse Translation: The IPv4-only server receives the request, processes it, and sends a response back to the SIIT device. The SIIT device translates the IPv4 address back to IPv6 using the EAMT and forwards the response to your IPv6-only machine.
- Response Received by IPv6-only Machine: The response, now in IPv6 format, reaches your IPv6-only machine for processing.
Resources
For this guide, we will focus on using Jool as it is currently the most performant option (Research: https://www.sciencedirect.com/science/article/pii/S0140366419311569). Alternatively, you can use a public SIIT server like https://nat64.net/ if you prefer not to host your own.
Here are some additional resources:
- List of SIIT software:
- Public SIIT servers to try:
- Example of IPv6-only hosting: https://ipv6onlyhosting.com
Let's Get Started!
IPv6 Block Access
First, ensure you have access to an IPv6 block through your network where your Proxmox server nodes reside. If you are using a service provider, you can request or manually configure this. If you run your own servers, you can obtain IPv6 blocks directly from a Regional Internet Registry (RIR), such as https://www.ripe.net/. There may be associated costs.
IPv4 Pool Access
When setting up your own SIIT server, you will typically need a pool of IPv4 addresses that can be used for translation and mapping. The IPv4 addresses used for mapping in the SIIT (Stateless IP/ICMP Translation) process are defined and mapped using the Explicit Address Mapping Table (EAMT) as previously described. This pool of IPv4 addresses is an essential component of the SIIT server's functionality and enables it to facilitate communication between IPv6-only hosts and IPv4-only hosts. The number of ipv4 addresses you need is determined by your network traffic. You are able to configure how the SIIT server rotates through them to balance the load.The SIIT server performs address translation by replacing the IPv6 addresses in packets with IPv4 addresses, and vice versa using the EAMT table. This translation process requires a pool of IPv4 addresses that the SIIT server can use as mappings for the IPv6 addresses. When an IPv6-only host wants to communicate with an IPv4-only host, the SIIT server assigns an IPv4 address from its pool to represent the IPv6 host during the translation process.
The size of the IPv4 address pool you need depends on various factors, including the number of concurrent connections you anticipate and the specific SIIT implementation you are using.
When setting up your SIIT server, you will need to configure this pool of IPv4 addresses. This typically involves defining a range of IPv4 addresses that the SIIT server can use for translation. These addresses should be publicly routable and not in use by any other devices or services on your network to avoid conflicts.
It's worth noting that there are different types of SIIT implementations, such as stateless (SIIT-DC) and stateful, and they may have slightly different requirements for IPv4 address pools. For example, with stateless SIIT, the IPv4 address mappings are typically predetermined and static, while stateful SIIT may involve dynamic allocation of IPv4 addresses from the pool based on demand.
Deciding on your SIIT implementation:
Please refer to the cheat sheet Jool provides for an overview of each configuration: https://www.jool.mx/en/cheat-sheet.htmlOpen Question: What is best? After researching more it is not clear to me what configuration is best for our stated use and goal here.
Setting up Proxmox DNS for IPv6
Once you have your IPv6 allocation, you need to add DNS nameservers that can resolve both IPv6 and IPv4 on your Proxmox host node network. You can choose to implement the SIIT server DNS here or use a combination of IPv4 and IPv6 nameservers (Slot 1 for IPv4, Slot 2 for IPv6). Here is a list of public DNS providers for reference: https://www.lifewire.com/free-and-public-dns-servers-2626062
To configure DNS in Proxmox, click into a node and then select "DNS" under the "System" options. You have 3 slots for nameserver addresses, and Proxmox will use them based on the following criteria:
- Resolver Priority: The lowest number is tried first.
- Failure Handling: If a DNS address resolver fails or times out, Proxmox moves on to the next resolver in the list.
Open Question: Should we use public SIIT nameservers like https://nat64.net/ here, or only in individual VMs? My initial testing has shown that using these nameservers in the host network allows successful pings to IPv4 services from IPv6-only VMs.
Configuring Individual VMs
Move on to configuring an individual VM. Locate the DNS settings based on your VM's OS and whether you're using a cloud image, ISO, or container.
Setting up Your Own SIIT Server
As mentioned, we'll be using Jool, although there are alternative options. Jool can be installed via package manager, built from source, or using Docker:
- https://www.jool.mx/en/ubuntu.html
- https://www.jool.mx/en/install.html
- https://github.com/wandera/jool-docker
it is generally preferable to run the SIIT server (Jool) on an individual VM rather than directly on the Proxmox host node. This approach provides better isolation, simplifies management, and allows for easier scaling if needed. Please let me know if you disagree.
Here are the key considerations:
- Performance: Running the SIIT server on a dedicated VM ensures that it has exclusive access to the required resources, potentially improving performance.
- Security: Isolating the SIIT server in a VM enhances security by containing any potential vulnerabilities or exploits within that VM, protecting the host node and other VMs.
- Flexibility: With the SIIT server running in a VM, you have the flexibility to easily migrate it, scale it, or make configuration changes without directly impacting the host node.
- Management: Managing the SIIT server in a VM follows standard VM management practices, allowing for straightforward backups, snapshots, and replication if needed.
NEXT STEPS: Let's experiment with Jool in an individual VM using package manager, Docker, and building from source to identify the most straightforward approach.
We need to clearly define how to network other vms with the self-hosted SIIT server. I'll be experimenting over the next few days.
Hopefully this is enough to get the ball rolling!