Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/10/16 11:13, Arne Schwabe wrote:
> This option was useful when Ipv6 tun support was non standard and
> was an internal/user specified flag that tracked the Ipv6
> capability of the tun device.
> 
> All supported OS support IPv6. Also tun-ipv6 is pushable by the
> remote so not putting tun-ipv6 does not forbid ipv6 addresses.
> 
> This commit also clean up a bit of the ipv6 related tun.c. Changes
> for most platforms are minimal.
> 
> For linux a bit more cleanup is done: - Remove compatibility
> defines that were added 2008 - Always use IFF_NO_PI for the linux
> tun and not only for IPv4 only tun setups (Android also always
> IFF_NO_PI works fine with Ipv6).
> 
> This commit also remove a non ipv6 fallback for tap driver from
> OpenVPN 2.2-beta or earlier and only warns.
> 
> Patch V2: Integrate Gert's comments Patch V3: Remove tun_ipv4
> option. It only used for MTU discovery and there it was wrong since
> it should on the transport protocol if at all Patch V4: Completely
> remove support for NetBSD <= 4.0 and remove NETBSD_MULTI_AF
> defines --- Changes.rst   |   3 ++ src/openvpn/forward.c |
> 2 +- src/openvpn/helper.c  |   2 - src/openvpn/init.c|   6 --- 
> src/openvpn/multi.c   |   8 ++- src/openvpn/openvpn.h |   5 -- 
> src/openvpn/options.c |  11 +--- src/openvpn/options.h |   1 - 
> src/openvpn/route.c   |  13 ++--- src/openvpn/tun.c | 139
> +++--- 
> src/openvpn/tun.h |   2 - 11 files changed, 30 insertions(+),
> 162 deletions(-)
> 
> diff --git a/Changes.rst b/Changes.rst index 9fcba75..2956003
> 100644 --- a/Changes.rst +++ b/Changes.rst @@ -135,6 +135,9 @@
> User-visible Changes ciphers configured in the config file.  Use
> --ncp-disable if you don't want that.
> 
> +- ALl tun devices on all platforms are considered always IPv6
> capable. The --tun-ipv6

Silly typo.  (I would have done this one in-flight, hadn't it been for
a few other minor things).

[...snip...]
> @@ -4577,7 +4569,6 @@ add_option (struct options *options, else if
> (streq (p[0], "tun-ipv6") && !p[1]) { VERIFY_PERMISSION
> (OPT_P_UP); -  options->tun_ipv6 = true; }

Should we add a "Deprecated/NO-OP option used." message?

[...snip]

> +++ b/src/openvpn/route.c @@ -1729,10 +1729,10 @@ add_route_ipv6
> (struct route_ipv6 *r6, const struct tuntap *tt, unsigned int fla 
> } #endif
> 
> -  if ( !tt->ipv6 ) +  if (!tt->did_ifconfig_ipv6_setup) { -
> msg( M_INFO, "add_route_ipv6(): not adding %s/%d, no IPv6 on if
> %s", -network, r6->netbits, device ); +  msg( M_INFO,
> "add_route_ipv6(): not adding %s/%d, no IPv6 ifconfig on if %s", +
> network, r6->netbits, device);

Wouldn't it be nicer we said "no IPv6 address configured on
interface %s" ?  Just trying to be slightly more user friendly in the
logs.

> --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -741,8 +741,8 @@
> do_ifconfig (struct tuntap *tt,
> 
> argv_init ();
> 
> -  msg( M_INFO, "do_ifconfig, tt->ipv6=%d,
> tt->did_ifconfig_ipv6_setup=%d", -   tt->ipv6,
> tt->did_ifconfig_ipv6_setup ); +  msg( M_INFO, "do_ifconfig,
> tt->did_ifconfig_ipv6_setup=%d", +
> tt->did_ifconfig_ipv6_setup );

While we're changing log lines ... could we make this one a bit less
technical, or at least increase the verb level if we want it to be so
technical?  Again, just to be more user friendly

[...snip...]

> @@ -1526,7 +1513,7 @@ open_tun_generic (const char *dev, const char
> *dev_type, const char *dev_node, bool dynamic_opened = false;
> 
> 
> -  if ( tt->ipv6 && ! ipv6_explicitly_supported ) +  if (  !
> ipv6_explicitly_supported ) msg (M_WARN, "NOTE: explicit support
> for IPv6 tun devices is not provided for this OS");

Isn't this if() block a NOOP?

$ git grep -Hni ipv6_explicitly_supported
src/openvpn/tun.c:1521:  bool ipv6_explicitly_supported, bool dynamic,
src/openvpn/tun.c:1529:  if ( tt->ipv6 && ! ipv6_explicitly_supported )

Could we kill this as well?


[...snip...0
> @@ -1977,53 +1940,13 @@ close_tun (struct tuntap *tt) int write_tun
> (struct tuntap* tt, uint8_t *buf, int len) { -  if (tt->ipv6) -
> { -  struct tun_pi pi; -  struct iphdr *iph; -  struct
> iovec vect[2]; -  int ret; - -  iph = (struct iphdr *)buf; 
> - -  pi.flags = 0; - -  if(iph->version == 6) -   pi.proto =
> htons(OPENVPN_ETH_P_IPV6); -  else -  pi.proto =
> htons(OPENVPN_ETH_P_IPV4); - -  vect[0].iov_len = sizeof(pi); -
> vect[0].iov_base =  -  vect[1].iov_len = len; -
> vect[1].iov_base = buf; - -  ret = writev(tt->fd, vect, 2); -
> return(ret - sizeof(pi)); -} -  else -return write (tt->fd,
> buf, len); +  return write (tt->fd, buf, len);

whitespace issue.

> }
> 
> int read_tun (struct tuntap* tt, uint8_t *buf, int len) { -  if
> (tt->ipv6) -{ -  struct iovec vect[2]; -  struct tun_pi
> pi; -  int ret; - -  vect[0].iov_len = sizeof(pi); -
> 

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Thanks to both Gert and Arne for their answers.

On Wed, Oct 12, 2016 at 9:12 AM, Arne Schwabe  wrote:
>> What I should have asked is: with this patch will an OpenVPN client
>> still send out IPv4 packets if there are no IPv6 options specified or
>> pulled from the server?

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Arne Schwabe]

> What I should have asked is: with this patch will an OpenVPN client
> still send out IPv4 packets if there are no IPv6 options specified or
> pulled from the server?

In short: Behave exactly as before.

Longer explaination:

Without the patch OpenVPN refuses ifconfig-ipv6 and route-ipv6 without
tun-ipv6 option because the tun device has not been configured in a IPv6
safe way. With patch it does not refuse the commands.


The problem that tun-ipv6 solved was "Method A works with IPv6/IPv4 but
might break on old versions of Linux(?) and Method B always works but
only IPv4".

On Linux the tun device has been opend/configured in different ways for
tun-ipv6 and non tun-ipv6 which are both IPv4/IPv6 capable (prepend a
header to packet/do not prepend a header) for reasons that are probably
lost in history. The patch unifies that to never prepends headers (IPv4
behaviour and Android behaviour).

For OS X tun (and utun) has always been opened in the same way no matter
if tun-ipv6 was specifiied. So only change for OS X is no longer
refusing ifconfig-ipv6 and route-ipv6 without tun-ipv6 option.
 

Arne

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Gert Doering]

Hi,

On Wed, Oct 12, 2016 at 08:53:02AM -0400, Jonathan K. Bullard wrote:
> What I should have asked is: with this patch will an OpenVPN client
> still send out IPv4 packets if there are no IPv6 options specified or
> pulled from the server?

Yes.   Basically, the tun interface is now always in "dual-stack mode"
on those platforms where it matters (some, like NetBSD, can have 
"IPv4 only mode" or "dual stack mode", and the latter was "newly added"
some 10 years ago...).

IPv4 is not going to be broken :-)

The only user visible change *expected* by this change is that previously,
"ifconfig-ipv6" would be rejected unless "tun-ipv6" was also configured, 
and now this dependency is gone - if you configure (or push) ifconfig-ipv6,
you get dual-stack v4+v6, if not, you get a dual-stacked tun interface
with only IPv4 active.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Thanks, Arne. Sorry if I wasn't a clear as I should have been.

On Wed, Oct 12, 2016 at 8:08 AM, Arne Schwabe  wrote:
>
> Am 12.10.16 um 13:17 schrieb Jonathan K. Bullard:
> > Hi.
> >
> > On Wed, Oct 12, 2016 at 5:13 AM, Arne Schwabe  wrote:
> >> This option was useful when Ipv6 tun support was
> >> non standard and was an internal/user specified flag
> >> that tracked the Ipv6 capability of the tun device.
> >>
> >> All supported OS support IPv6. Also tun-ipv6 is
> >> pushable by the remote so not putting tun-ipv6
> >> does not forbid ipv6 addresses.
> > How will this patch affect a VPN on a system that has IPv6 disabled?
> >
> >
> Short version: Fail as miserable as before.

Connections don't fail in the situation I describe (IPv6 disabled at
the OS level). At least not when there are no IPv6 options enabled in
the OpenVPN configuration or pushed from the server, which is the
setup that many VPN service providers use.


> You might think that leaving out tun-ipv6 might fix your
> problem but tun-ipv6 is a pushable option and the server-ipv6 macro will
> push it, so you end up with tun-ipv6 without having it in the client config.

The problem was not that the server was pushing tun-ipv6 (the
configurations and server pushes did not have any IPv6 references).
The problem was that the OS prefers IPv6 over IPv4 when both were
available. So the OS was sending out IPv6 packets, which caused
information leakage. The solution was not leaving out the tun-ipv6
option, but disabling IPv6 in the OS.

What I should have asked is: with this patch will an OpenVPN client
still send out IPv4 packets if there are no IPv6 options specified or
pulled from the server?

If yes, the connection will succeed. If no, then disabling IPv6 in the
OS will cause failed connections. (Unless with IPv6 disabled the OS
translates IPv6 packets to IPv4 and sends them, which seems unlikely
to me.)

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Arne Schwabe]

Am 12.10.16 um 13:17 schrieb Jonathan K. Bullard:
> Hi.
>
> On Wed, Oct 12, 2016 at 5:13 AM, Arne Schwabe  wrote:
>> This option was useful when Ipv6 tun support was
>> non standard and was an internal/user specified flag
>> that tracked the Ipv6 capability of the tun device.
>>
>> All supported OS support IPv6. Also tun-ipv6 is
>> pushable by the remote so not putting tun-ipv6
>> does not forbid ipv6 addresses.
> How will this patch affect a VPN on a system that has IPv6 disabled?
>
>
Short version: Fail as miserable as before.

tun-ipv6 is not saying "My OS can do IPv6" but more "My OS has the
required calls to configure a IPv6 tun". It came from a time when
configuring/sending IPv6 packets into a non IPv6 prepared tun screwed
things ups. You might think that leaving out tun-ipv6 might fix your
problem but tun-ipv6 is a pushable option and the server-ipv6 macro will
push it, so you end up with tun-ipv6 without having it in the client config.

You can do pull-filter tun-ipv6 or disable pulling all together but then
again you can do also pull-filter ifconfig-ipv6 and pull-filter
route-ipv6 which is a cleaner way then letting those commands fails (and
probably also the connection attempt).

The option really serves no good purposse anymore. If someone really
wants a disable IPv6 option this option isn't it.

Arne

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Hi.

On Wed, Oct 12, 2016 at 5:13 AM, Arne Schwabe  wrote:
>
> This option was useful when Ipv6 tun support was
> non standard and was an internal/user specified flag
> that tracked the Ipv6 capability of the tun device.
>
> All supported OS support IPv6. Also tun-ipv6 is
> pushable by the remote so not putting tun-ipv6
> does not forbid ipv6 addresses.

How will this patch affect a VPN on a system that has IPv6 disabled?

To prevent information leakage, Tunnelblick has an option in tun mode
that forces the OS to disable IPv6 (via a "networksetup -setv6off" OS
X command.)

The information leakage when using IPv6 in a VPN is described in [1].
As of the date of the article (June 2015), the problem was common
among VPN service providers. The "disable IPv6" feature was added to
Tunnelblick because disabling IPv6 was the only way that a user of
such services could protect themselves. It isn't clear if all VPN
service providers have fixed their configurations yet (or will ever
fix their configurations).

Best regards,

Jon Bullard

[1] http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Arne Schwabe]

This option was useful when Ipv6 tun support was non standard and was an 
internal/user specified flag that tracked the Ipv6 capability of the tun device.

All supported OS support IPv6. Also tun-ipv6 is pushable by the remote so not 
putting tun-ipv6 does not forbid ipv6 addresses.

This commit also clean up a bit of the ipv6 related tun.c. Changes for most 
platforms are minimal.

For linux a bit more cleanup is done:
- Remove compatibility defines that were added 2008
- Always use IFF_NO_PI for the linux tun and not only for IPv4 only tun setups 
(Android also always IFF_NO_PI works fine with Ipv6).

This commit also remove a non ipv6 fallback for tap driver from OpenVPN 
2.2-beta or earlier and only warns.

Patch V2: Integrate Gert's comments
Patch V3: Remove tun_ipv4 option. It only used for MTU discovery and there it 
was wrong since it should on the transport protocol if at all
Patch V4: Completely remove support for NetBSD <= 4.0 and remove 
NETBSD_MULTI_AF defines
---
 Changes.rst   |   3 ++
 src/openvpn/forward.c |   2 +-
 src/openvpn/helper.c  |   2 -
 src/openvpn/init.c|   6 ---
 src/openvpn/multi.c   |   8 ++-
 src/openvpn/openvpn.h |   5 --
 src/openvpn/options.c |  11 +---
 src/openvpn/options.h |   1 -
 src/openvpn/route.c   |  13 ++---
 src/openvpn/tun.c | 139 +++---
 src/openvpn/tun.h |   2 -
 11 files changed, 30 insertions(+), 162 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 9fcba75..2956003 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -135,6 +135,9 @@ User-visible Changes
   ciphers configured in the config file.  Use --ncp-disable if you don't want
   that.
 
+- ALl tun devices on all platforms are considered always IPv6 capable. The 
--tun-ipv6
+  option is ignored (behaves like it is always on).
+
 
 Maintainer-visible changes
 --
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 6c11439..b3077ed 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -391,7 +391,7 @@ check_fragment_dowork (struct context *c)
   struct link_socket_info *lsi = get_link_socket_info (c);
 
   /* OS MTU Hint? */
-  if (lsi->mtu_changed && c->c2.ipv4_tun)
+  if (lsi->mtu_changed)
 {
   frame_adjust_path_mtu (>c2.frame_fragment, c->c2.link_socket->mtu,
 c->options.ce.proto);
diff --git a/src/openvpn/helper.c b/src/openvpn/helper.c
index 62f88ec..229523d 100644
--- a/src/openvpn/helper.c
+++ b/src/openvpn/helper.c
@@ -200,8 +200,6 @@ helper_client_server (struct options *o)
add_in6_addr( o->server_network_ipv6, 0x1000 );
o->ifconfig_ipv6_pool_netbits = o->server_netbits_ipv6;
 
-   o->tun_ipv6 = true;
-
push_option( o, "tun-ipv6", M_USAGE );
  }
 
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index cc8e945..73f8c6d 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1400,9 +1400,6 @@ do_init_tun (struct context *c)
   !c->options.ifconfig_nowarn,
   c->c2.es);
 
-  /* flag tunnel for IPv6 config if --tun-ipv6 is set */
-  c->c1.tuntap->ipv6 = c->options.tun_ipv6;
-
   init_tun_post (c->c1.tuntap,
 >c2.frame,
 >options.tuntap_options);
@@ -1420,9 +1417,6 @@ do_open_tun (struct context *c)
   struct gc_arena gc = gc_new ();
   bool ret = false;
 
-  c->c2.ipv4_tun = (!c->options.tun_ipv6
-   && is_dev_type (c->options.dev, c->options.dev_type, 
"tun"));
-
 #ifndef TARGET_ANDROID
   if (!c->c1.tuntap)
 {
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 3bc6ee9..93a554d 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1378,8 +1378,7 @@ multi_select_virtual_addr (struct multi_context *m, 
struct multi_instance *mi)
* (see below) so issue a warning if that happens - don't break the
* session, though, as we don't even know if this client WANTS IPv6
*/
-  if ( mi->context.c1.tuntap->ipv6 &&
-  mi->context.options.ifconfig_ipv6_pool_defined &&
+  if ( mi->context.options.ifconfig_ipv6_pool_defined &&
   ! mi->context.options.push_ifconfig_ipv6_defined )
{
  msg( M_INFO, "MULTI_sva: WARNING: if --ifconfig-push is used for 
IPv4, automatic IPv6 assignment from --ifconfig-ipv6-pool does not work.  Use 
--ifconfig-ipv6-push for IPv6 then." );
@@ -1452,8 +1451,7 @@ multi_select_virtual_addr (struct multi_context *m, 
struct multi_instance *mi)
* way round ("dynamic IPv4, static IPv6") or "both static" makes sense
* -> and so it's implemented right now
*/
-  if ( mi->context.c1.tuntap->ipv6 &&
-   mi->context.options.push_ifconfig_ipv6_defined )
+  if ( mi->context.options.push_ifconfig_ipv6_defined )
 {
   mi->context.c2.push_ifconfig_ipv6_local = 
mi->context.options.push_ifconfig_ipv6_local;
@@ -1511,7 +1509,7 @@ multi_set_virtual_addr_env (struct multi_context *m, 
struct 

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Gert Doering]

Hi,

On Sat, Sep 17, 2016 at 12:36:16PM +0200, Arne Schwabe wrote:
> @@ -1127,6 +1127,8 @@ do_ifconfig (struct tuntap *tt,
>if ( do_ipv6 )
>   {
>  #ifdef NETBSD_MULTI_AF
> +#error no IPv6 support for tun interfaces on NetBSD before 4.0, upgrade your 
> system.
> +#endif

If we keep this, this needs to be an #ifndef (you change the if/else
branches).  But I think this could also just go - 4.0 has been released
9 years ago.  It will fail at compile time, and then people can either
use 2.3 or upgrade their NetBSD.

Besides that, I think it mostly looks good.  Needs explicit testing
on those platforms where tun.c got changed (which I did not do yet).

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Arne Schwabe]

This option was useful when Ipv6 tun support was non standard and was an 
internal/user specified flag that tracked the Ipv6 capability of the tun device.

All supported OS support IPv6. Also tun-ipv6 is pushable by the remote so not 
putting tun-ipv6 does not forbid ipv6 addresses.

This commit also clean up a bit of the ipv6 related tun.c. Changes for most 
platforms are minimal.

For linux a bit more cleanup is done:
- Remove compatibility defines that were added 2008
- Always use IFF_NO_PI for the linux tun and not only for IPv4 only tun setups 
(Android also always IFF_NO_PI works fine with Ipv6).

This commit also remove a non ipv6 fallback for tap driver from OpenVPN 
2.2-beta or earlier and only warns.

Patch V2: Integrate Gert's comments
Patch V3: Remove tun_ipv4 option. It only used for MTU discovery and there it 
was wrong since it should on the transport protocol if at all
Patch V4: do not send V3 as V2
---
 Changes.rst   |   3 ++
 src/openvpn/forward.c |   2 +-
 src/openvpn/helper.c  |   2 -
 src/openvpn/init.c|   6 ---
 src/openvpn/multi.c   |   8 ++--
 src/openvpn/openvpn.h |   5 ---
 src/openvpn/options.c |  11 +
 src/openvpn/options.h |   1 -
 src/openvpn/route.c   |  13 ++
 src/openvpn/tun.c | 110 ++
 src/openvpn/tun.h |   2 -
 11 files changed, 32 insertions(+), 131 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 9fcba75..2956003 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -135,6 +135,9 @@ User-visible Changes
   ciphers configured in the config file.  Use --ncp-disable if you don't want
   that.
 
+- ALl tun devices on all platforms are considered always IPv6 capable. The 
--tun-ipv6
+  option is ignored (behaves like it is always on).
+
 
 Maintainer-visible changes
 --
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 6c11439..b3077ed 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -391,7 +391,7 @@ check_fragment_dowork (struct context *c)
   struct link_socket_info *lsi = get_link_socket_info (c);
 
   /* OS MTU Hint? */
-  if (lsi->mtu_changed && c->c2.ipv4_tun)
+  if (lsi->mtu_changed)
 {
   frame_adjust_path_mtu (>c2.frame_fragment, c->c2.link_socket->mtu,
 c->options.ce.proto);
diff --git a/src/openvpn/helper.c b/src/openvpn/helper.c
index 62f88ec..229523d 100644
--- a/src/openvpn/helper.c
+++ b/src/openvpn/helper.c
@@ -200,8 +200,6 @@ helper_client_server (struct options *o)
add_in6_addr( o->server_network_ipv6, 0x1000 );
o->ifconfig_ipv6_pool_netbits = o->server_netbits_ipv6;
 
-   o->tun_ipv6 = true;
-
push_option( o, "tun-ipv6", M_USAGE );
  }
 
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 9236a9f..7b73509 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1400,9 +1400,6 @@ do_init_tun (struct context *c)
   !c->options.ifconfig_nowarn,
   c->c2.es);
 
-  /* flag tunnel for IPv6 config if --tun-ipv6 is set */
-  c->c1.tuntap->ipv6 = c->options.tun_ipv6;
-
   init_tun_post (c->c1.tuntap,
 >c2.frame,
 >options.tuntap_options);
@@ -1420,9 +1417,6 @@ do_open_tun (struct context *c)
   struct gc_arena gc = gc_new ();
   bool ret = false;
 
-  c->c2.ipv4_tun = (!c->options.tun_ipv6
-   && is_dev_type (c->options.dev, c->options.dev_type, 
"tun"));
-
 #ifndef TARGET_ANDROID
   if (!c->c1.tuntap)
 {
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index ba7f2c0..228b393 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1377,8 +1377,7 @@ multi_select_virtual_addr (struct multi_context *m, 
struct multi_instance *mi)
* (see below) so issue a warning if that happens - don't break the
* session, though, as we don't even know if this client WANTS IPv6
*/
-  if ( mi->context.c1.tuntap->ipv6 &&
-  mi->context.options.ifconfig_ipv6_pool_defined &&
+  if ( mi->context.options.ifconfig_ipv6_pool_defined &&
   ! mi->context.options.push_ifconfig_ipv6_defined )
{
  msg( M_INFO, "MULTI_sva: WARNING: if --ifconfig-push is used for 
IPv4, automatic IPv6 assignment from --ifconfig-ipv6-pool does not work.  Use 
--ifconfig-ipv6-push for IPv6 then." );
@@ -1451,8 +1450,7 @@ multi_select_virtual_addr (struct multi_context *m, 
struct multi_instance *mi)
* way round ("dynamic IPv4, static IPv6") or "both static" makes sense
* -> and so it's implemented right now
*/
-  if ( mi->context.c1.tuntap->ipv6 &&
-   mi->context.options.push_ifconfig_ipv6_defined )
+  if ( mi->context.options.push_ifconfig_ipv6_defined )
 {
   mi->context.c2.push_ifconfig_ipv6_local = 
mi->context.options.push_ifconfig_ipv6_local;
@@ -1510,7 +1508,7 @@ multi_set_virtual_addr_env (struct multi_context *m, 
struct multi_instance *mi)
   setenv_del (mi->context.c2.es,