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. Regards, Aaron
