Tunneling IPv6 over IPv4

elisea

We are trying to tunnel IPv6 over IPv4 using OpenVPN, and have noticed an unexpected dependency between the ifconfig-ipv6 option and the ifconfig option.

If we push an ifconfig-ipv6 option, without preceding it with an ifconfig option, the tun0 device is not created. See the following log snippet:

Tue Nov 26 14:22:46 2013 us=962808 PUSH: Received control message: 'PUSH_REPLY,ping 10,ping-restart 60,ifconfig-ipv6 fc00:00c0:00a8:0030::2 fc00:00c0:00a8:0030::1,route-ipv6 fc00:1::64 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff'
Tue Nov 26 14:22:46 2013 us=962908 OPTIONS IMPORT: timers and/or timeouts modified
Tue Nov 26 14:22:46 2013 us=962922 OPTIONS IMPORT: --ifconfig/up options modified
Tue Nov 26 14:22:46 2013 us=962935 OPTIONS IMPORT: route options modified
Tue Nov 26 14:22:46 2013 us=962988 ROUTE6: default_gateway=UNDEF
Tue Nov 26 14:22:46 2013 us=963224 TUN/TAP device tun0 opened
Tue Nov 26 14:22:46 2013 us=963257 TUN/TAP TX queue length set to 100
Tue Nov 26 14:22:46 2013 us=963317 add_route_ipv6(fc00:1::/64 -> ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff metric -1) dev tun0
Tue Nov 26 14:22:46 2013 us=963347 /sbin/ip -6 route add fc00:1::/64 dev tun0
Tue Nov 26 14:22:46 2013 us=964889 Initialization Sequence Completed

In this case, even though we see the Initialization Sequence Completed log message, if we execute the ifconfig command on the client server (Linux), the tun0 device does not appear in the list of devices.

If we push an ifconfig option, followed by an ifconfig-ipv6 option, the tun0 device is created and everything works perfectly.

ue Nov 26 14:25:47 2013 us=246106 PUSH: Received control message: 'PUSH_REPLY,ping 10,ping-restart 60,ifconfig 192.168.48.5 192.168.48.6,ifconfig-ipv6 fc00:00c0:00a8:0030::2 fc00:00c0:00a8:0030::1,route-ipv6 fc00:1::64 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff'
Tue Nov 26 14:25:47 2013 us=246242 OPTIONS IMPORT: timers and/or timeouts modified
Tue Nov 26 14:25:47 2013 us=246257 OPTIONS IMPORT: --ifconfig/up options modified
Tue Nov 26 14:25:47 2013 us=246270 OPTIONS IMPORT: route options modified
Tue Nov 26 14:25:47 2013 us=246337 ROUTE6: default_gateway=UNDEF
Tue Nov 26 14:25:47 2013 us=247134 TUN/TAP device tun0 opened
Tue Nov 26 14:25:47 2013 us=247204 TUN/TAP TX queue length set to 100
Tue Nov 26 14:25:47 2013 us=247233 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=1
Tue Nov 26 14:25:47 2013 us=247277 /sbin/ip link set dev tun0 up mtu 1500
Tue Nov 26 14:25:47 2013 us=248749 /sbin/ip addr add dev tun0 local 192.168.48.5 peer 192.168.48.6
Tue Nov 26 14:25:47 2013 us=252668 /sbin/ip -6 addr add fc00:c0:a8:30::2/64 dev tun0
Tue Nov 26 14:25:47 2013 us=254119 add_route_ipv6(fc00:1::/64 -> ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff metric -1) dev tun0
Tue Nov 26 14:25:47 2013 us=254216 /sbin/ip -6 route add fc00:1::/64 dev tun0
Tue Nov 26 14:25:47 2013 us=255725 Initialization Sequence Completed

Also note that i this case, if we execute the ifconfig command on the client server (Linux), we do see the tun0 device in the list of devices.

Note that the difference between the two snippets, with the exception of the different options being pushed, is that the following four lines are missing in the first snippet:

Tue Nov 26 14:25:47 2013 us=247233 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=1
Tue Nov 26 14:25:47 2013 us=247277 /sbin/ip link set dev tun0 up mtu 1500
Tue Nov 26 14:25:47 2013 us=248749 /sbin/ip addr add dev tun0 local 192.168.48.5 peer 192.168.48.6
Tue Nov 26 14:25:47 2013 us=252668 /sbin/ip -6 addr add fc00:c0:a8:30::2/64 dev tun0

In our case, even though we are tunneling over IPv4, we are only tunneling IPv6 traffic over IPv4, so it seems unnecessary to have to configure the two IPv4 addresses (i.e. ifconfig 192.168.48.5 192.168.48.6). We are wondering why we can configure IPv4 without IPv6, but are unable to configure IPv6 without IPv4. Is this intentional, or are we missing something? Is there some way to trigger the "do_ifconfig" actions without having to push the ifconfig statement with its two IPv4 addresses?

darx

fyi,

There's a 19 month old bug related to the issue of IPv6 requiring IPv4:

https://community.openvpn.net/openvpn/ticket/208

dev activity to date on it has been limited to

(1) set milestone to 2.4
(2) reduce priority to minor

JoshC

elisea wrote In our case, even though we are tunneling over IPv4, we are only tunneling IPv6 traffic over IPv4, so it seems unnecessary to have to configure the two IPv4 addresses (i.e. ifconfig 192.168.48.5 192.168.48.6). We are wondering why we can configure IPv4 without IPv6, but are unable to configure IPv6 without IPv4. Is this intentional, or are we missing something? Is there some way to trigger the "do_ifconfig" actions without having to push the ifconfig statement with its two IPv4 addresses?

At the moment this is a known requirement, yes. Given the vast space available in RFC1918, it shouldn't be hard to use a "dummy" addressing, and I can't really see a use-case for "needing" to avoid this. If you really want to avoid RFC1918 for some goofy reason, consider (ab)using RFC3927, RFC2544, RFC5737, or (assuming non-Windows) 240/4.

The code changes to disassociate IPv4 addresses are non-trivial; if you're interested in helping out from a programming perspective, get involved on the mailing-lists or IRC.