Timothy Baldwins answer put me on the right track, although the answer was rather cryptic. IPv6 neighbor advertisements/solicitation is like ARP for IPv6. It's used to "see" other machines on the network. The router send a neighbor solicitation on which the machine (server or client) should reply on with a neighbor advertisement.
Even with net.ipv6.conf.all.forwarding set to 1, neighbor advertisements and solicitations are not forwarded. To make eth0 forward neighbor advertisements and solicitations, eth0 should be set as proxy for the IPv6 address of the client behind tap0, and proxying for neighbor stuff should be enabled for eth0:
echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp
/sbin/ip -6 neigh add proxy 2001:db8::100:abc:2 dev eth0
Unfortunately, it's not possible to retrieve the list of proxies added, nor does ip -6 show error messages on repeatedly executing the command. Neither am I sure if "neigh del proxy" works, it does not give an error message and the C source is not really meaningful to me.
As I do not want to do everything manually, I've created a script which does the work for me.
Server configuration
IPv6 addresses are based on the IPv4 part (the 1 in 10.8.0.1). The prefix and netmask are stored in /etc/openvpn/variables.
The next steps are made for setting up OpenVPN with encrypted IPv4/IPv6 connectivity to the Internet over a native IPv4 connection. RSA keys and tls-auth are used for authentication and MITM prevention.
/etc/openvpn/variables contains variables which are used for the up script (run on startup, after creation of tap0 device) and client-connect script (run after the client has authenticated).
# this prefix is handled out by the provider, replace it with your own prefix
prefix=2001:db8::abc
# netmask, 2001:db9::abc:0000 - 2001:db9::abc:FFFF
prefixlen=112
/etc/openvpn/server-clientconnect.sh is executed as root and makes sure that IPv6 is routed properly by adding the IPv6 address to the eth0 proxy. Because client-connect is called after OpenVPN switched to the user specified by the User setting, sudo is needed to give the script sufficient permissions to run as root. Of course, variables should be checked before using, the number should be between and including 2 ad 254. (1 is the gateway, 255 the broadcast address).
#!/bin/sh
. /etc/openvpn/variables
if [ -z "$ifconfig_pool_remote_ip" ]; then
echo "Missing environment variable."
exit 1
fi
ipp=$(echo "$ifconfig_pool_remote_ip" | cut -d. -f4)
if ! [ "$ipp" -ge 2 -a "$ipp" -le 254 ] 2>/dev/null; then
echo "Invalid IP part."
exit 1
fi
hexipp=$(printf '%x' $ipp)
/sbin/ip -6 neigh add proxy $pfx:$hexipp dev eth0
To make this work, the user vpn should be allowed to run the script while preserving $ifconfig_pool_remote_ip which contains the remote network IPv4 address. Add the next lines to the sudoers file by executing sudo visudo and appending:
Defaults:vpn env_keep=ifconfig_pool_remote_ip
vpn ALL=NOPASSWD: /etc/openvpn/server-clientconnect.sh
/etc/openvpn/server-up.sh enables IPv4, IPv6 forwarding (eth0+tap0 did not work, it really had to be all) and neighbor proxy on eth0. It adds the gateway address to servers tap0 too.
#!/bin/sh
. /etc/openvpn/variables
/sbin/ip -6 addr add $pfx:1/$pfxlen dev $dev
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp
Finally, the OpenVPN configuration file at /etc/openvpn/internet.conf:
proto udp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
script-security 2
up /etc/openvpn/server-up.sh
client-connect "/usr/bin/sudo -u root /etc/openvpn/server-clientconnect.sh"
# encrypt all traffic
push "redirect-gateway def1"
# keep the same IP addresses each time
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth ta.key 0
cipher BF-CBC
comp-lzo
# OpenVPN will switch to this user, it is also used for sudo
user vpn
group vpn
persist-key
persist-tun
For completeness, permissions and ownerships of files in /etc/openvpn:
drwx------ root root .
-rw------- root root ca.crt
-rw------- root root dh1024.pem
drwx------ root root easy-rsa <-- left from creation of keys
-rw------- root root ipp.txt
-rwx------ root root server-clientconnect.sh
-rw------- root root internet.conf
-rw------- root root variables
-rwx------ root root server-up.sh
-rw------- root root server.crt
-rw------- root root server.key
-rw------- root root ta.key
-rwx------ root root update-resolv-conf <-- this was installed by default
Firewall settings:
itpables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -i tap0 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -s 2001::db8::abc:0/112 -i tap0 -o eth0 -j ACCEPT
Configuration on client
/etc/openvpn/client.conf:
client
dev tap
proto udp
remote 178.21.112.251 1194
script-security 2
up /etc/openvpn/client-up.sh
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
cert home.crt
key home.key
ns-cert-type server
tls-auth ta.key 1
cipher BF-CBC
comp-lzo
ta.key and ca.key are the same files from the server. home.key and home.crt are files, created on the server.
client-up.sh adds the IPv6 address and route (based on IPv4 address):
#!/bin/sh
pfx='2001:db8::abc'
pfxlen=112
hexippart=`printf '%x' "$(echo $ifconfig_local | cut -d. -f4)"`
/sbin/ip -6 addr add $pfx:$hexippart/$pfxlen dev $dev
/sbin/ip -6 route add default via $pfx:1 dev $dev
The guide at http://www.ipsidixit.net/2010/03/24/239/ was very helpful and OpenVPN manual page is useful for information about various settings.
The first thing that should be mentioned about IPv6 subnetting is that a different mode of thought is called for. In IPv4 you usually think about how many addresses you have available and how you can allocate enough of them to each end user. In IPv6 you usually think about how many /64-subnets you have available and how you can allocate them to end users. You almost never worry about how many IP addresses will be used in a given subnet. Except for some special cases like point to point links, each subnet just simply has far more addresses available than it will ever require, so instead you worry only about allocating subnets, not hosts inside them.
IPv6 subnets are usually /64 because that is required in order for SLAAC (stateless address auto-configuration) to work. Even where SLAAC is not in use, there may be other reasons to use /64. For example, there might be some end user devices out there that just assume /64, or else routing subnets narrower than /64 might be inefficient on some routers because the router implementer has optimized the case of /64 or wider routes in order to save routing table memory.
Why is it recommended to use /127 for point to point links?
For the specific case of point-to-point links, /127 is recommended instead of /64 in order to avoid a vulnerability where packets addressed to any one of the quadrillions of unused addresses on the subnet cause unwanted neighbour solicitation requests and table entries that could drown a router. Such misaddressed packets may be malicious or accidental. But even if you actually configure a point-to-point link as /127, some people advocate assigning a whole /64 anyway just to be consistent.
Why would virtual machines be provisioned with subnets narrower than /64?
I don't know specifically why virtual machines would be provisioned with subnets narrower than /64. Perhaps because a hosting provider assumed that a server was like an end-user and required only a single /64 subnet, not anticipating that the server would actually be a collection of VMs requiring an internal routing topology? It could be done also simply as a matter of making the addressing plan easier to memorize: the host gets PREFIX::/64, then each VM gets PREFIX:0:NNNN::/96 where NNNN is unique to the VM and the VM can allocate PREFIX:0:NNNN:XXXX:YYYY as it pleases.
Can I map directly from IPv4 subnets to IPv6 subnets? For instance, does an IPv4 /24 correspond directly to an IPv6 /56 or /120?
From a low-level perspective of how addressing and routing works, the prefix length has the same meaning in IPv6 and IPv4. On that level, you can make an analogy such as "an IPv4 /16 uses half the bits for the network address and half the bits for the host address, that's like a /64 in IPv6". But this comparison is not really apt. Strong conventions have emerged in IPv6 which make the divisions of network sizes look somewhat more like the old world of classful networks in IPv4. To be sure, IPv6 didn't reintroduce classful addressing in which the most significant few bits of the address force a particular netmask, but what IPv6 does have is certain [de facto/conventional] standard network sizes:
/64: the basic size of a single subnet: LAN, WAN, block of addresses for web virtual hosts, etc... "Normal" subnets are never expected to be any narrower (longer prefix) than /64. No subnets are ever expected to be wider (shorter prefix) than /64 since a /64's worth of host addresses is much more than we can imagine needing./56: a block of 256 basic subnets. Even though current policies permit ISPs to hand out blocks as large as /48 to every end user and still consider their address utilisation well justified, some ISPs may (and already do) choose to allocate a /56 to consumer-grade customers as a compromise between allocation lots of subnets for them and address economy./48: a block of 65536 basic subnets and the recommended size of block that every ISP customer end site should receive./32: the default size of block that most ISPs will receive each time they request more addresses from a regional address registry.
Inside service provider and enterprise networks, many more prefix lengths than these 4 can be seen. When looking at the routing tables of routers inside these networks, IPv4 and IPv6 have much in common including most of the way routing works: routes for longer prefixes override covering routes for shorter prefixes, so it is possible to aggregate (make shorter) and drill down (make longer) routes. Like in IPv4, routes can be aggregated or summarized to larger blocks with shorter prefixes in order to minimize the size of routing tables.
A different question of mapping between IPv4 and IPv6 would be how to harmonize IPv4 and IPv6 assignments on dual-stack machines so that addressing plans can be readily understood. Far that, there are certainly conventions in common use to do this: embed the IPv4 "subnet number" into a portion of the IPv6 prefix, either with BCD (e.g. 10.0.234.0/24 becomes 2001:db8:abcd:234::/64) or binary (10.0.234.0/24 becomes 2001:db8:abcd:ea::/64).
My interfaces have several IPv6 addresses. Must the subnet be the same for all of them?
Absolutely not! IPv6 hosts are expected to be able to be multihomed by having several IP addresses simultaneously that come from different subnets, just like IPv4. If they are autoconfigured with SLAAC then the different subnets might have come from router advertisements from different routers.
Why do I sometimes see a % rather than a / in an IPv6 address and what does it mean?
You would not see one instead of the other. They have different meanings. A slash denotes a prefix (subnet), meaning a block of addresses that all start with the same n bits. An address without a slash is a host address. You may think of such an address as having an implied /128 at the end, meaning all 128 bits are specified.
The percent sign accompanies a link-local address. In IPv6, every interface has a link-local address in addition to any other IP addresses it might have. But the thing is, link-local addresses are always, without exception, in the fe80::/10 block. But if we attempt to talk to a peer using a link local address and the local host has multiple interfaces, how are we to know which interface to use to talk to this peer? Normally the routing table tells us which interface to use for a particular prefix, but here it will tell us than fe80::/10 is reachable via every interface.
The answer is that we must tell it which interface to use using the syntax address%interface. For example, fe80::1234:5678:8765:4321%eth0.
Am I wasting too many subnets? Aren't we just going to run out again?
Nobody knows. Who can tell the future?
But consider this. In IPv6 the number of available subnets is the square of the number of available individual addresses in IPv4. That's really quite a lot. No, I mean really quite a lot!
But still: we are automatically handing out a /32 to any ISP who requests one, we are handing out a /48 to every single ISP customer. Perhaps we're exaggerating and we will squander IPv6 after all. But there is a provision for this: Only one eighth of the IPv6 space has been made available for use so far: 2000::/3. The idea is that if we make a horrible mess of the first eighth and we have to drastically revise the liberal allocation policies, we get to try 7 more times before we're in trouble.
And finally: IPv6 doesn't have to last forever. Perhaps it will have a longer lifetime than IPv4 (an impressive lifetime already and it's not over) but like every technology it will someday stop mattering. We only need to make it until then.
Best Answer
What you want is probably https://jool.mx. It's a kernel module that implements NAT64.