TAP-Win32 device and IPv6 addresses

How to customize and extend your OpenVPN installation.
Post Reply
juhovh
OpenVpn Newbie
Posts: 3
Joined: Thu Nov 18, 2010 12:31 pm

TAP-Win32 device and IPv6 addresses

Post by juhovh » Thu Nov 18, 2010 12:38 pm

Hi,

I'm not really talking about OpenVPN itself, but I'm using the nice TAP-Win32 driver in another project. The driver supports setting the option TAP_IOCTL_CONFIG_DHCP_MASQ to automatically configure the IPv4 address using a DHCP server in masquerade mode. Starting from Vista windows also has the option to configure IPv6 addresses by using a DHCPv6 server, but it requires receiving a router advertisement that has the "Managed Address Configuration Flag" and "Other Configuration Flag" set.

I would be very interested in configuring the IPv6 addresses through TAP-Win32 driver and I could work on implementing the DHCPv6 support. If I get anything done, would the upstream be interested in merging my work with the TAP-Win32 driver included in OpenVPN? It's not very high on my priority list right now, but if there's interest I could make it a higher priority.

Juho

User avatar
krzee
Forum Team
Posts: 729
Joined: Fri Aug 29, 2008 5:42 pm

Re: TAP-Win32 device and IPv6 addresses

Post by krzee » Thu Nov 18, 2010 2:56 pm

check out 2.2-beta and see if that covers your use case

cron2
Developer
Posts: 17
Joined: Tue Jan 12, 2010 8:08 pm

Re: TAP-Win32 device and IPv6 addresses

Post by cron2 » Thu Nov 18, 2010 3:29 pm

Hi,

2.2-beta will not help with this specific request - it has IPv6 support in tun mode (using neighbour discovery spoofing for the "magic" next-hop address), but it will neither do RA nor DHCPv6, as OpenVPN configures IPv6 using "netsh.exe" calls.

I'm not exactly sure that DHCPv6+RA is very important for OpenVPN uses, as especially RA is tricky (announcing default routes is not fine grained enough and I don't know if windows understands the "more specific route" options in RA yet).

OTOH, having DHCPv6 in there might be useful in the long run for things like DNS setup if we don't do IPv4 anymore - so this would certainly be an interesting long-term addition and I would be willing to help getting the code back into the official repository.

I do not read the forums regularily, though, so I'd ask for development related IPv6 things to be brought up on the openvpn-devel mailing list or the #openvpn-devel IRC channel.

gert

juhovh
OpenVpn Newbie
Posts: 3
Joined: Thu Nov 18, 2010 12:31 pm

Re: TAP-Win32 device and IPv6 addresses

Post by juhovh » Thu Nov 18, 2010 6:14 pm

cron2 wrote:2.2-beta will not help with this specific request - it has IPv6 support in tun mode (using neighbour discovery spoofing for the "magic" next-hop address), but it will neither do RA nor DHCPv6, as OpenVPN configures IPv6 using "netsh.exe" calls.
I hadn't looked at the 2.2-beta yet, but "netsh.exe" calls is exactly what I'm trying to avoid. I've been using the "netsh.exe" approach myself before and it works but is far from perfect solution and adds some delay as well.
cron2 wrote:I'm not exactly sure that DHCPv6+RA is very important for OpenVPN uses, as especially RA is tricky (announcing default routes is not fine grained enough and I don't know if windows understands the "more specific route" options in RA yet).
I'm not hundred percent sure that it's a good idea either, but should read the RFCs and make some tests to find out. I've written some ND RA stuff in user space emulating a stateless autoconfiguration server to get the addresses automatically configured, but haven't worked with the DHCPv6 yet.
cron2 wrote:OTOH, having DHCPv6 in there might be useful in the long run for things like DNS setup if we don't do IPv4 anymore - so this would certainly be an interesting long-term addition and I would be willing to help getting the code back into the official repository.
Some proof-of-concept using TAP-Win32 in user space would probably be a good starting point and then if that seems to work well could get back to porting the code into the driver itself like the DHCP is done now. I'll get back to it if I have something working.
cron2 wrote:I do not read the forums regularily, though, so I'd ask for development related IPv6 things to be brought up on the openvpn-devel mailing list or the #openvpn-devel IRC channel.
Thanks a lot for your reply, personally I prefer mailing lists and IRC as well, but the forum was the first thing that came up when I tried to find contact information from openvpn.net. I'll keep those in mind for the future.

juhovh
OpenVpn Newbie
Posts: 3
Joined: Thu Nov 18, 2010 12:31 pm

Re: TAP-Win32 device and IPv6 addresses

Post by juhovh » Tue Nov 23, 2010 3:17 pm

I won't spam the mailing list yet, since I haven't had significant progress. However I have completed a custom DHCPv6 handshake with a Windows 7 machine and configured both the IPv6 address and IPv6 DNS server correctly. This is how Windows seems to handle the IPv6 address configuration:

1) When receive link up, send Router Solicitation messages 3 times between around one second
2) If after 3 Router Solicitation messages a Router Advertisement is not received, start sending DHCPv6 solicitations
3) If a Router Advertisement with managed flag set on is received, start sending DHCPv6 solicitations immediately
4) On all following link ups, if Router Advertisement with managed flag was received last time, start sending DHCPv6 solicitations immediately

The DHCPv6 handshake after the solicitation goes the usual way: Solicit -> Advertise -> Request -> Reply.
To make an efficient DHCPv6 handshake a reply to the Router Solicitation is necessary, otherwise the first address configuration after reboot or disabling the TAP-Win32 interface will be quite slow. Otherwise this all should be pretty doable.

I'll continue porting my sample code to C, since I wrote the small proof-of-concept in C#. And by the way if someone is interested, I wrote a C library and .NET API for the TAP device driver interface that can be found from http://code.google.com/p/tapcfg/ website. This is not supposed to be an advertisement, just to let people know, since it's quite useful for experimenting and runs on many platforms.

Post Reply