Opened 8 years ago

Last modified 6 weeks ago

#498 accepted Feature Wish

Support dynamic IPv6 prefixes in server config rather than hardcoded prefixes.

Reported by: brith2o Owned by: Gert Döring
Priority: minor Milestone: release 2.7
Component: IPv6 Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: IPv6, DHCPv6-PD


The use of DHCPv6-PD by many ISPs creates a headache in using IPv6 for an OpenVPN tunnel because OpenVPN currently requires the IPv6 prefix be hardcoded into the server config.

It would be nice to have OpenVPN use whatever prefix is assigned to the TUN adapter by DHCPv6.

For example, let's say the OpenVPN server machine receives a /60 address from the ISP: 2001:db8::/60. The DHCPv6 client on machine then assigns a /64 to the OpenVPN tun adapter: 2001:db8:0:1::1/64. Now I want OpenVPN to assign IPv6 addresses to connecting clients using WHATEVER prefix was assigned to the tun adapter.

Seems like the way to accomplish this would be as follows:
1) Remove the "ifconfig-ipv6" command from the server config. Thus IPv6 assignment to the TUN adapter on the server could be handled by the DHCPv6 client on the machine as and when it receives a new prefix from the ISP. (In the current state, if the IPv6 address is given to the TUN adapter by DHCPv6, then OpenVPN also calls ifconfig to assign the address and produces a file-already-exists error and OpenVPN exits as a result. However, the "ifconfig-ipv6" command cannot currently be removed from the server config because...)
2) Currently "ifconfig-ipv6-pool" also requires that "ifconfig-ipv6" is used. Remove this requirement so "ifconfig-ipv6-pool" can be used without "ifconfig-ipv6".
3) Allow syntax for "ifconfig-ipv6-pool" that only specifies the suffix. For example "ifconfig-ipv6-pool ::100/64" would assign IPv6 addresses to connecting clients starting at <prefix>::100. The <prefix> would be whatever is assigned to the TUN adapter.
4) When the IPv6 prefix assigned by DHCPv6-PD to the TUN adapter on the server changes, re-issue new IPv6 addresses to connected clients with the new prefix.

The only workaround I have come up with is to use ULA addresses, which can be hardcoded. This works for local traffix, but prevents me redirecting all IPv6 internet-bound traffic through the tunnel (because clients do not receive a publicly routable IPv6 address).

Change History (5)

comment:1 Changed 8 years ago by Gert Döring

Owner: set to Gert Döring
Status: newaccepted
Version: 2.3.5git master branch

I can hear you, but this is... tricky.

1) how does DHCPv6 assign addresses to a non-primary interface? Which platform, which DHCPv6 client is that? (Normal DHCPv6 clients will assign to the interface that they use to talk to the DHCPv6 server, or hand a PD prefix to "some sort of downstream entity")

1,2,3) OpenVPN also really likes to control what is happening on its tun interface in server mode, so this would be fairly invasive - it's more than "just don't do the ifconfig", but also the internal routing infrastructure on the server needs to know the prefix.

So this really boils down to a) build an infrastructure to have changing prefixes inside the server, and b) add some glue logic to make it "sniff the tun" or just directly talk to the DHCPv6 server, and request a /64 for the tun. Doable, but complicated.

4) this is even more interesting as there is no support for "renumbering on the fly" in the protocol - PUSH_REQUEST/PUSH_REPLY is pretty much a "one shot at connection setup" thing, not something that can be renegotiated on the fly (also, clients currently have no idea whether a prefix is becoming invalid while the tun still holds). So one would have to extend the client protocol to be more dynamic, and also change the pushed ifconfig-ipv6 message to convey a lifetime - usually the old prefix will not go away hard (killing your session) but be deprecated first...

c) you actually want pushed routes to change as well, if, for example, your LAN network renumbers while an OpenVPN session is established.

So, while I think this is actually fairly cool stuff to have (and necessary in the long run), it's complex, and won't make 2.4 - too untrusive, and there are other more pressing IPv6 things missing that need to get implemented first (handle overlapping gateway address and route6).

As a workaround, you can do it outside OpenVPN by using "dev tap" and radvd... I hate to say this, but this will work right away.

comment:2 Changed 6 years ago by Gert Döring

Milestone: release 2.5

This is not going to make 2.4, but it is a relevant topic (though I still have no idea how to make it work in a sane way).

comment:3 Changed 5 years ago by Antonio Quartulli

maybe, when this automatic logic is activated, OpenVPN might listen for RTNL messages on the tun device and react to addition/deletion of IPv6 addresses (of course, this is going to be a cross-platform nightmare, but we might limit this behaviour to sane platforms only).

This was about the server side.

For the client side, I think Gert already mentioned it all: the logic needs to be extended and made more dynamic, instead of assuming one-shot push settings for the interface.

comment:4 Changed 2 years ago by Gert Döring

Milestone: release 2.5release 2.6

I still think this would be cool stuff - dynamic renumbering of the whole chain of "things" when the delegated upstream prefix changes.

It won't make 2.5, though...

comment:5 Changed 6 weeks ago by Gert Döring

Milestone: release 2.6release 2.7

2.6.0 will bring other exciting things, but not much in the IP addressing / routing department - specifically, not this. Bumping the milestone to 2.7

Note: See TracTickets for help on using tickets.