Opened 8 years ago

Last modified 13 months ago

#208 assigned Feature Wish

Allow ipv6 only tunnels

Reported by: joshie Owned by: Gert Döring
Priority: major Milestone: release 2.5
Component: Configuration Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: ipv6
Cc:

Description

It would appear as of 2.3-alpha1, in order to have an ipv6-tun, you must use the server directive, which forces ipv4 as well. It is preferable to those who wish to only have an ipv6 tunnel not to be forced to have an additional ipv4 tunnel.

Change History (13)

comment:1 Changed 8 years ago by David Sommerseth

Keywords: ipv6 added
Owner: set to Gert Döring
Status: newassigned
Version: git master branch

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

Milestone: release 2.4

Currently, the OpenVPN implementation assumes "always IPv4, optional IPv6". So you need to have IPv4 on your tunnel. (It's not "an additional tunnel" but the tunnel will be dual-stacked).

If you want to have it IPv6-only, just configure some RFC1918 IPv4, and do not route
that anywhere - it's not pretty, but it will not have any extra overhead except send a few bytes of "ifconfig for IPv4" at session handshake.

To make IPv4 optional is a useful goal, but first we need to get 2.3 released :-)

comment:3 Changed 6 years ago by darx

subscribing

comment:4 Changed 6 years ago by Samuli Seppänen

Priority: majorminor

comment:5 Changed 4 years ago by WGH

but it will not have any extra overhead except send a few bytes of "ifconfig for IPv4" at session handshake.

Even if you don't actively use the IPv4 network, it still will be "attached" to your computer. It might prevent you from using several VPNs simultaneously, or it might even conflict with some other intranet.

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

Milestone: release 2.4release 2.5

Nobody had time to work on this for 2.4 - but for 2.5 we really should be able to do ipv6-only. Bumping milestone.

comment:7 Changed 20 months ago by Antonio

@gert it seems people are asking for this feature more and more.
Since you have the best understanding of the ipv6 infrastructure in openvpn, would you mind providing a list of things "to check" and "to hack" in order to get done with this? (I am not sure how easy this is)

By having a list of smaller tasks we might be able to coordinate the effort of different people and finally move forward.

comment:8 Changed 20 months ago by Gert Döring

Uh... let me try...

  • client-side is fairly easy
    • change the ifconfig setup stuff in tun.c to do IPv6 even if IPv4 has not been set up (as far as I remember, ifconfig is only run if IPv4 is requested, and later in that same function, we check for "oh, do we want IPv6 as well?")
    • test across all platforms if IPv6-only tuns work nicely
    • test this on 3 as well - ISTR that iOS was a bit icky if you give it a v6-only tunnel, but this might have been fixed now
    • this can be tested fairly easy independently from the server side by using --pull-filter ignore "ifconfig " in the client config - pretending "there is no IPv4 in the PUSH_REPLY"
  • server side stuff is more interesting
    • maybe trivial: --server-ipv6 depends on --server being active - so this needs to be de-coupled, or specifically, --server-ipv6 needs to enable the "I am a p2mp server!" functionality without the "IPv4 bits"
    • decouple IPv6 pool handling from IPv4 - if we have no IPv4, we have no IPv4 pool, and the naive logic "just take the offset from the IPv4 pool and add it to the IPv6 base address" will no longer work (--ifconfig-ipv6-push might still work)
    • check all the connection setup bits if there is anything relying on "we do have an IPv4 address for the incoming client" - I could see push.c, multi.c as possible candidates for surprises
      • using --push-remove 'ifconfig ' might be enough to bring up fireworks in push.c, though the rest of the code will still assume "client instance has v4" so it's not a full-grown test
    • the actual forwarding parts should be fine, the mroute stuff only cares for a single mroute, and never checks for "other" routes being present

comment:9 Changed 20 months ago by Gert Döring

Actually this seems to be a nice goal for 2.5 - v6-only tunnels.

The client side should be trivial enough that we might even backport to 2.4, but the server is larger changes (pool). As usual, if you want a server with all the cool things in it, you need to run the latest version.

comment:10 Changed 20 months ago by tincantech

CC

comment:11 Changed 18 months ago by Gert Döring

First patch set has landed and discussion has started...

https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16943.html

comment:12 Changed 14 months ago by Antonio

Update: the patches implementing the client side of things have been merged. We now miss some changes required by the server side (i.e. handling pool, decoupling v4/v6 logic) and small fixes for the redirect-gateway logic.

comment:13 Changed 13 months ago by Antonio

Priority: minormajor

moving to 'major' as we agreed this is a "nice to have" in 2.5

Note: See TracTickets for help on using tickets.