[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-devel] tunnelling ipv6 on linux

  • Subject: Re: [Openvpn-devel] tunnelling ipv6 on linux
  • From: Aaron Sethman <androsyn@xxxxxxxxxx>
  • Date: Sat, 28 Sep 2002 19:05:22 -0400 (EDT)

On Sat, 28 Sep 2002, James Yonan wrote:

> Aaron,
> Thanks for the patch, however I was not able to get it to work with IPv4 while talking between a 2.4.9 and 2.4.17 kernel, where both peers are running the patch.  The code compiles and runs, but pings don't go through.  Perhaps there is a minimum kernel version necessary for this to work?  Does the kernel need to be built with IPv6 support in order for this code to work with IPv4?
Well, it shouldn't require any IPv6 support in the kernel to simply pass
IPv4 packets.  I'll need to look at the tun driver in 2.4.9.  Both of my
machines here are running 2.4.19.
> There is also the issue of breaking protocol compatibility by adding the ETH_P_IPV6/ETH_P_IP to the IP-over-tun packet encoding.  I would propose that:
Well, it doesn't break the protocol at all, what ends up happening is, the
kernel takes the tun_pi header and strips it off, so those headers never
get sent on the wire.

> (1) We run-time conditionalize your patch on a --tun-ipv6 option.

> (2) We compile-time (e.g. #ifdef bracket on HAVE_NETINET_IF_ETHER_H, ETH_P_IPV6, etc.) and/or run-time conditionalize so that usage of --tun-ipv6 produces a run-time error if ipv6 over tun is not supported.
That sounds like a good idea.
> (3) We add --tun-ipv6 enabled/disabled state to the options_string function in options.h as a sanity check between peers.
> (4) We think about how to make --tun-ipv6 portable across the platforms which OpenVPN supports.  This may be better addressed at the tun driver level, to reduce the machine-specific ugliness in tun.c?
Well, this one might be a bit more difficult if the tunnel driver doesn't
support it, of course it might be worth the effort to submit patches to
the respective OSes for this.

> (5) We look into making an ipv6 option for the tunnel UDP channel and endpoints as well.
This part shouldn't be much of a problem.