Re: [Openvpn-devel] [IPv6 support] - usage of gethostbyname() in getaddr()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/02/10 17:20, Gert Doering wrote: > Hi, > > On Wed, Feb 17, 2010 at 02:47:28PM +0100, David Sommerseth wrote: >> When reviewing the patch "FQDN for routes should expand to all IPs" >> today, I spotted that there is a function called getaddr() (renamed to >> getaddr_all() in the mentioned patch). This function again makes use of >> the old gethostbyname() function. This is not compatible with IPv6 >> addresses. > > This is actually "existing code", and not something changed by the patch > (just to point that out to readers that have not reviewed the patch). > > >> I would strongly recommend a move to getaddrinfo() instead. This is >> based on an article [1] written by Ulrich Drepper, who is a glibc >> maintainer. Any thoughts about that? It might even be more functions >> needing to be ported as well. The mentioned article lists most >> important functions which should be ported to newer APIs. >> >> Any comments on this issue would be appreciated. Another issue is of >> course how this will influence other platforms than Linux. > > Well, let me answer the second thing first (because I've spent a while > thinking about this and whether I want to make the IPv6 payload stuff > #ifdef'ed from the start). > > On the Unix side of things, I'm fairly sure that any platform recent enough > to have tun/tap support (which isn't all of them, just *BSD, Solaris, > Linux and MacOS) also has getaddrinfo() and IPv6. > > I don't know a thing about Windows programming, though. > > OpenSSH tackles this by providing their own getaddrinfo() function (from > OpenBSD) if the system has no such function, or if it is broken, and > "configure" seems to do a good job in deciding what to do. Sounds clever. I believe PuTTY got IPv6 support, which might give a clue for a Windows implementation. But I'm not a Windows coder, so I won't be able to contribute too much in this area. Windows coders, please share your thoughts here! > Now, on the question of whether we want / should use it. Right now, the > "upstream" code only uses gethostbyname() because it wouldn't know what to > do with an IPv6 record anyway, if any such record were to be returned - the > code is used for connection handling (IPv4 only) and for setting routes > to FQDN (again, IPv4 only). > > In the long term, this whole area of the code will see some changes :-) > - when merging jjo's tree, we should already see use of getaddrinfo() for > connection handling, and if people see the need for it, I might need to > implement setting of IPv6 routes to FQDN targets. > > > So... if you'd ask me what I would to today, the answer would be "leave > the code as it is, merge jjo's code, and then revisit what he already > had to change for IPv6 connection handling". If gethostbyname() is still > there, come back and make this lookup function v4- and v6-capable, and > implement FQDN routes for IPv6 :-) Sounds very sensible. I am of the same opinion, it's anyway something we need to be aware of, as we're now working more and more in implementing IPv6 support. Thank you, Gert, for taking the time answering this. And I did give you a copy, just because I know your background with the IPv6 patches :) kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkt8HNYACgkQDC186MBRfrodhACaA3s/veqT1x70wYlEEfhNm4Ea YZoAn0Ns/QLo57S9X/QrwwQ/RZBO5W07 =+kCC -END PGP SIGNATURE-
Re: [Openvpn-devel] [IPv6 support] - usage of gethostbyname() in getaddr()
Hi, On Wed, Feb 17, 2010 at 02:47:28PM +0100, David Sommerseth wrote: > When reviewing the patch "FQDN for routes should expand to all IPs" > today, I spotted that there is a function called getaddr() (renamed to > getaddr_all() in the mentioned patch). This function again makes use of > the old gethostbyname() function. This is not compatible with IPv6 > addresses. This is actually "existing code", and not something changed by the patch (just to point that out to readers that have not reviewed the patch). > I would strongly recommend a move to getaddrinfo() instead. This is > based on an article [1] written by Ulrich Drepper, who is a glibc > maintainer. Any thoughts about that? It might even be more functions > needing to be ported as well. The mentioned article lists most > important functions which should be ported to newer APIs. > > Any comments on this issue would be appreciated. Another issue is of > course how this will influence other platforms than Linux. Well, let me answer the second thing first (because I've spent a while thinking about this and whether I want to make the IPv6 payload stuff #ifdef'ed from the start). On the Unix side of things, I'm fairly sure that any platform recent enough to have tun/tap support (which isn't all of them, just *BSD, Solaris, Linux and MacOS) also has getaddrinfo() and IPv6. I don't know a thing about Windows programming, though. OpenSSH tackles this by providing their own getaddrinfo() function (from OpenBSD) if the system has no such function, or if it is broken, and "configure" seems to do a good job in deciding what to do. Now, on the question of whether we want / should use it. Right now, the "upstream" code only uses gethostbyname() because it wouldn't know what to do with an IPv6 record anyway, if any such record were to be returned - the code is used for connection handling (IPv4 only) and for setting routes to FQDN (again, IPv4 only). In the long term, this whole area of the code will see some changes :-) - when merging jjo's tree, we should already see use of getaddrinfo() for connection handling, and if people see the need for it, I might need to implement setting of IPv6 routes to FQDN targets. So... if you'd ask me what I would to today, the answer would be "leave the code as it is, merge jjo's code, and then revisit what he already had to change for IPv6 connection handling". If gethostbyname() is still there, come back and make this lookup function v4- and v6-capable, and implement FQDN routes for IPv6 :-) 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
[Openvpn-devel] ipv6 support of tun for solaris/opensolaris
Hi, I added ipv6 support to tun driver for solaris. Full source tar ball and patch against original universal tun/tap driver is available here. http://www.whiteboard.ne.jp/~admin2/tuntap/ In response to this change, I revised the patch against openvpn and set 'ipv6_explicitly_supported' to true. Please find attached patch. The patch is based on OpenVPN 2.1_rc21, and it also includes code to handle tap driver for solaris. With above tun driver and attached patch, solaris/opensolaris is capable to forward ipv6 packets through tun interface. Thanks, Kazuyoshi patch.openvpn-2.1_rc21.tun.c Description: Binary data
Re: [Openvpn-devel] IPv6 Support
Marcel Pennewiß wrote: On Thursday 13 November 2008 01:23:46 Marcel Pennewiß wrote: Hi, Hi again, a long time ago Juanjo Ciarlante wrote a patch for openvpn to create a tunnel via ipv6 [1]. Later i fixed the patch to work with openvpn-2.0 and 2.1 which i use on OpenWRT and Gentoo. Roy (from Gentoo) wrote about this also to the devel-list [1]. But since that no one answered :( What about IPv6-support to create a tunnel over IPv6? Since my first patch i try to adapt the patch to newer versions. This patches are not properly tested but works fine for me (on gentoo).[2][3] What about full IPv6-support - is this scheduled in the future or on any roadmap? No answer is not a good practice :( Full IPv6 support is planned for OpenVPN 3. Some more details on OpenVPN 3: OpenVPN 3.0 is a revamping of the OpenVPN core into a modular, more maintainable architecture. Planned features include: * IPv6 support * IP multicast support * Pluggable crypto library support (so that crypto libraries other than OpenSSL may be used) * Pluggable packet filter and network access control API * Pluggable dynamic routing API (BGP, OSPF, etc.) * Support for full-mesh topologies (in addition to the star and point-to-point topologies supported in OpenVPN 2.x) * Library API support allowing OpenVPN tunnels to be programmatically created and destroyed * Embedding support to allow OpenVPN to be embedded in other applications * Asynchronous, event driven I/O subsystem (in the vein of Twisted, boost::asio, or libevent) James
Re: [Openvpn-devel] IPv6 Support
On Thursday 13 November 2008 01:23:46 Marcel Pennewiß wrote: > Hi, Hi again, > a long time ago Juanjo Ciarlante wrote a patch for openvpn to create a > tunnel via ipv6 [1]. Later i fixed the patch to work with openvpn-2.0 and > 2.1 which i use on OpenWRT and Gentoo. Roy (from Gentoo) wrote about this > also to the devel-list [1]. But since that no one answered :( > > What about IPv6-support to create a tunnel over IPv6? Since my first patch > i try to adapt the patch to newer versions. This patches are not properly > tested but works fine for me (on gentoo).[2][3] What about full IPv6-support - is this scheduled in the future or on any roadmap? No answer is not a good practice :( Best regards, Marcel
[Openvpn-devel] IPv6 Support
Hi, a long time ago Juanjo Ciarlante wrote a patch for openvpn to create a tunnel via ipv6 [1]. Later i fixed the patch to work with openvpn-2.0 and 2.1 which i use on OpenWRT and Gentoo. Roy (from Gentoo) wrote about this also to the devel-list [1]. But since that no one answered :( What about IPv6-support to create a tunnel over IPv6? Since my first patch i try to adapt the patch to newer versions. This patches are not properly tested but works fine for me (on gentoo).[2][3] I'm not able to adapt the patch detailed 'cause of not enough knowledge about the source and missing programming skills. JuanJo want some integration to the official openvpn source code, but knowone did this until now. [1] http://sourceforge.net/mailarchive/message.php?msg_id=20070629101345.0f8beeba%40uberlaptop.marples.name [2] http://source.pennewiss.de/openvpn/udp6/ [3] http://bugs.gentoo.org/show_bug.cgi?id=183457 Are there plans to integrate it to the future? Regards, Marcel
[Openvpn-devel] IPv6 support (was Re: A special IP address range for exclusive VPN usage?)
On Thu, Jul 27, 2006 at 10:18:55AM -0500, Charles Duffy wrote: > Personally, I think that adding IPv6 support (with its massive space for > private networks) is a better long-term fix for this issue. On that note, does anyone have any idea what the status of IPv6 support is? (I know about the old patches for 2.0, but they haven't been updated in over a year, and I can't find where anyone has forward-ported them to 2.1.) Steve -- Steven Pritchard - K Pritchard Enterprises, Inc. Email: st...@kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320
[Openvpn-devel] IPv6 support for OpenVPN 2.0 release (UDPv6, --udp6)
Hi
I've finished polishing mi udp6 patch for openvpn-2.0
You can get it from
http://www.irrigacion.gov.ar/juanjo/openvpn/
There are two patch flavors: udp6 and udp6+MH (mutlihome , as required by
James for merging). I've successfully tested udp6 on both (MH support
compiles ok but it isn't tested).
Feedback is welcome, enjOY!
Regards
--
--Juanjo
# Juan Jose Ciarlante (JuanJo) jjo ;at; mendoza.gov.ar #
# GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key 66727177 #
# Key fingerprint: 0D2F 3E5D 8B5C 729E 0560 F453 A3F7 E249 6672 7177 #
# $Id: README.IPv6,v 1.1.8.2.2.1 2005/04/29 20:23:41 jjo Exp $ #
This README covers UDP/IPv6 v0.2.4 ( --udp6 ) support for openvpn-2.0
Also, with address family "generalization" changes came local AF_UNIX socket
support.
Available under GPLv2 from
http://www.irrigacion.gov.ar/juanjo/openvpn/
See "Examples" section below for usage.
* Working:
- upd6->upd6 (AF_INET6)
tested on GNU/Linux, FreeBSD-5.3 and OpenBSD-3.6.
- upd4->upd6 bound (show correctly mapped address) but requires
--float (to be fixed soon)
- unix-dgram->unix-dgram (AF_UNIX)
useful for implementing local proxies that can take full advantage
of POSIX filesystem permissions ( more powerfull access mechanisms
than inet, even for localhost)
* Setup:
./configure --disable-ipv6(enabled by default)
./configure --enable-unix-sockets (disabled by default)
:
* Usage:
For IPv6 just specify "-p upd6" an proper IPv6 hostnames, taking the example
from man page ...
On may:
openvpn --proto udp6 --remote --dev tun1 --ifconfig
10.4.0.1 10.4.0.2
--verb 5 --secret key
On june:
openvpn --proto udp6 --remote --dev tun1 --ifconfig
10.4.0.2 10.4.0.1
--verb 5 --secret key
* Examples: some succesfully tested command lines
[ BTW did you know that openvpn can succesfully negotiate to self
with --remote localhost ? (VERY useful for fast testing) ]
- IPv6 "normal" usage (+succesfully tested tunnel traffic)
server# openvpn --proto udp6 ...
:
Thu Sep 23 22:15:48 2004 Peer Connection Initiated with
[AF_INET6]fe80::205:5dff:fef1:1ceb%wlan0wds1:5000
:
client# openvpn --proto udp6 --remote fe80::240:5ff:feae:c851 ...
:
Thu Sep 23 22:13:19 2004 Peer Connection Initiated with
[AF_INET6]fe80::240:5ff:feae:c851%wlan0wds0:5000
:
- IPv6 server, IPv4 client (more detailed)
server# openvpn --proto udp6 ...
:
Thu Sep 23 22:28:36 2004 UDPv6 link local (bound): [AF_INET6][undef]:5000
Thu Sep 23 22:28:36 2004 UDPv6 link remote: [AF_INET6][undef]
Thu Sep 23 22:28:50 2004 Peer Connection Initiated with
[AF_INET6]:::10.55.14.253:5000
Thu Sep 23 22:28:51 2004 Initialization Sequence Completed
Thu Sep 23 22:28:56 2004 WARNING: Actual Remote Options ('... proto UDPv4
... ') \
are inconsistent with Expected Remote Options
('... proto UDPv6 ...')
client# openvpn --remote 10.55.14.254 ... ### same default as now: --udp
:
Thu Sep 23 22:26:11 2004 UDPv4 link local (bound): [AF_INET][undef]:5000
Thu Sep 23 22:26:11 2004 UDPv4 link remote: [AF_INET]10.55.14.254:5000
Thu Sep 23 22:26:21 2004 Peer Connection Initiated with
[AF_INET]10.55.14.254:5000
Thu Sep 23 22:26:21 2004 WARNING: Actual Remote Options ('... proto UDPv6
...') \
are inconsistent with Expected Remote Options
('... proto UDPv4 ...')
Thu Sep 23 22:26:22 2004 Initialization Sequence Completed
- IPv6 loopback
alone# openvpn --proto udp6 --remote ::1 ...
:
Wed Sep 22 13:03:07 2004 Peer Connection Initiated with [AF_INET6]::1:5000
:
- AF_UNIX toself
alone# openvpn --proto unix-dgram --local /tmp/o.s --remote /tmp/o.s --dev
tun ...
:
Thu Sep 23 16:37:27 2004 Peer Connection Initiated with [AF_UNIX]/tmp/o.s
:
- AF_UNIX between to diff instances
peer1# openvpn --proto unix-dgram --local /tmp/o1.s --remote /tmp/o2.s
peer2# openvpn --proto unix-dgram --local /tmp/o2.s --remote /tmp/o1.s
:
Wed Sep 22 12:49:03 2004 Peer Connection Initiated with [AF_UNIX]/tmp/o1.s
:
* Main code changes summary:
- New sockaddr type (could have been sockaddr_storage but
[[[ NOTE: this has changed change in MH (multihomed) merged tree ]]]
it lacks simple type overloading and maybe portability)
union sockaddr_ovpn {
struct sockaddr addr;
struct sockaddr_in in;
struct sockaddr_in6 in6;
#ifdef USE_PF_UNIX
struct sockaddr_un un;
#endif
};
typedef union sockaddr_ovpn sockaddr_ovpn_t;
struct link_socket_addr
{
sockaddr_ovpn_t local;
sockaddr_ovpn_t remote;
sockaddr_ovpn_t actual;
};
allows simple type overloading: local.addr, local.in, local.in6 ... etc
- several function prototypes moved from
sockaddr_in to
