README.IPv6 is quite useless because IPv6 is not a second class citizen anymore. Most of the content is "obvious" or explained in the manpage along with other details/options.
TODO.IPv6 is old and many implemented things are still reported there for no clear reason. Prune all useless details and keep what seems to still be not implemented. Cc: Gert Doering <g...@greenie.muc.de> Signed-off-by: Antonio Quartulli <a...@unstable.cc> --- I am personally in favour of killing TODO.IPv6 as well and rather document missing features in trac tickets. Thoughts? README.IPv6 | 56 ---------------- TODO.IPv6 | 180 +++------------------------------------------------- 2 files changed, 9 insertions(+), 227 deletions(-) delete mode 100644 README.IPv6 diff --git a/README.IPv6 b/README.IPv6 deleted file mode 100644 index 18068fee..00000000 --- a/README.IPv6 +++ /dev/null @@ -1,56 +0,0 @@ -Since 2.3.0, OpenVPN officially supports IPv6, and all widely used -patches floating around for older versions have been integrated. - -IPv6 payload support --------------------- - -This is for "IPv6 inside OpenVPN", with server-pushed IPv6 configuration -on the client, and support for IPv6 configuration on the tun/tap interface -from within the openvpn config. - -The code in 2.3.0 supersedes the IPv6 payload patches from Gert Doering, -formerly located at http://www.greenie.net/ipv6/openvpn.html - - -The following options have been added to handle IPv6 configuration, -analogous to their IPv4 counterparts (--server <-> --server-ipv6, etc.) - - - server-ipv6 - - ifconfig-ipv6 - - ifconfig-ipv6-pool - - ifconfig-ipv6-push - - route-ipv6 - - iroute-ipv6 - -see "man openvpn" for details how they are used. - - - -IPv6 transport support ----------------------- - -This is to enable OpenVPN peers or client/servers to talk to each other -over an IPv6 network ("OpenVPN over IPv6"). - -The code in 2.3.0 supersedes the IPv6 transport patches from JuanJo Ciarlante, -formerly located at http://github.com/jjo/openvpn-ipv6 - -OpenVPN 2.4.0 includes a big overhaul of the IPv6 transport patches -originally implemented for the Android client (ics-openvpn) - -IPv4/IPv6 transport is automatically is selected when resolving addresses. -Use a 6 or 4 suffix to force IPv6/IPv4: - - --proto udp6 - --proto tcp4 - --proto tcp6-client - --proto tcp4-server - --proto tcp6 --client / --proto tcp6 --server - -On systems that allow IPv4 connections on IPv6 sockets -(all systems supporting IPV6_V6ONLY setsockopt), an OpenVPN server can -handle IPv4 connections on the IPv6 socket as well, making it a true -dual-stacked server. Use bind ipv6only to disable this behaviour. - -On other systems, as of 2.3.0, you need to run separate server instances -for IPv4 and IPv6. diff --git a/TODO.IPv6 b/TODO.IPv6 index 465eaa66..61a76d0a 100644 --- a/TODO.IPv6 +++ b/TODO.IPv6 @@ -1,93 +1,7 @@ TODO for IPv6 payload support ----------------------------- -1.) "--topology subnet" doesn't work together with IPv6 payload on FreeBSD - (verified for FreeBSD server, Linux/ifconfig client, problems - with ICMP6 neighbor solicitations from BSD not being answered by Linux) - - * 2012-01-22 fixed in platform cleanup, commit 62c613d46dc495d74 - -2.) NetBSD IPv6 support doesn't work - ("connected" route is not auto-created, "route-ipv6" adding fails) - - * fixed, 3.1.10 * - -3.) route deletion for IPv6 routes is not yet done - - * fixed for configured routes, 3.1.10 * - * missing for manual-ifconfig-connected (NetBSD, Darwin, Win32) - - * 2012-06-10 - fixed somewhere in 2010 - -4.) do "ifconfig tun0 inet6 unplumb" or "ifconfig tun0 destroy" for - Solaris, *BSD, ... at program termination time, to clean up leftovers - (unless tunnel persistence is desired). - - For Solaris, only the "ipv6 tun0" is affected, for the *BSDs all tun0 - stay around. - - * 2012-06-10 - fixed in individual platform cleanups early-2012 - -4a.) deconfigure IPv6 on tun interface on session termination, otherwise - one could end up with something like this (on NetBSD): - -tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 - inet 10.9.0.18 -> 10.9.0.17 netmask 0xffffffff - inet6 fe80::a00:20ff:fece:d299%tun0 -> prefixlen 64 scopeid 0x3 - inet6 2001:608:4:eff::2000:3 -> prefixlen 64 - inet6 2001:608:4:eff::1:3 -> prefixlen 64 - - (pool was changed, previous address still active on tun0, breakage) - - * semi-fixed for NetBSD, 28.2.10, always do tun0 destroy / tun0 create - before actual ifconfig -- tunnel still lingers after OpenVPN quits - - * 2011-09-16 fixed in platform cleanup, commit 8ca19c014c149cf69 - -4b.) verify this - on FreeBSD, tun0 is auto-destroyed if created by - opening /dev/tun (and lingers if created by "ifconfig tun0 create") - - -> use for persistent tunnels on not-linux? - - * 2012-06-10 tun interface behaviour is documented in "man tun(4)" - -5.) add new option "ifconfig-ipv6-push" - (per-client static IPv6 assignment, -> radiusplugin, etc) - - * implemented, 14.1.10 * - -6.) add new option "route-ipv6-gateway" - - * 2012-06-09 - decided there is no current need (but fairly trivial) - -7.) add "full" gateway handling for IPv6 in route.c - (right now, the routes are just sent down the tun interface, if the - operating system in questions supports that, without care for the - gateway address - which does not work for gateways that are supposed - to point elsewhere. Also, it doesn't work for TAP interfaces. - - * 2012-06-09 use "dev tun" for tun devices, "via $gateway" for tap - (and purposely do not support off-link routes) - -8.) full IPv6 support for TAP interfaces - (main issue should be routes+gateway - and testing :-) ) - - test 2010/09/24: TAP itself works on linux/ifconfig+iproute2, but - route-via-tap doesn't work at all (route points to "tap0" which fails) - -17:51:14.075412 fe:ab:6e:c5:53:71 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2001:608:4:a053::1:0 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:608:4:a001::1, length 32 - - * 2012-06-09 missing gateway support implemented - -8a.) - how is iroute-via-tap supposed to work?? - - * 2012-06-10 - answer: not at all, OpenVPN doesn't do "iroute" in - tap mode - set up "route-ipv6" with gateway address = individual - client's tap0 address to get the per-client routes - - -9.) verify that iroute-ipv6 and route-ipv6 interact in the same way as +1.) verify that iroute-ipv6 and route-ipv6 interact in the same way as documented for iroute/route: A's subnet, OpenVPN must push this route to all clients @@ -96,94 +10,26 @@ tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 not pushing a route to a client if it matches one of the client's iroutes. -10.) extend "ifconfig-ipv6" to handle specification of /netbits, pushing - of /netbits, and correctly ifconfig'ing this - (default, if not specified: /64) - - * done * 2012-02-03 - -11.) do not add ipv6-routes if tun-ipv6 is not set - complain instead - - * done * 12.1.10 - -12.) handle incoming [::] and [fe80:...] packets in tun-p2mp MULTI mode - (most likely those are DAD packets) - silently ignore DAD? - Or accept-and-forward iff (multicast && client2client)? - handle NS/NA - -13.) from Martin List-Petersen: - - One thing, and I guess this requires modifications in - network-manager-openvpn: It also works, BUT ignores "push - route-ipv6-gateway" and "push route-ipv6 ...." (obviously routes pushed - from the server) entirely. - -14.) from ##openvpn-discussion: - - new features should be #ifdef'ed - - (check whether this is feasible at all) - -15.) IPv6 related environment variables +2.) handle incoming [::] and [fe80:...] packets in tun-p2mp MULTI mode + (most likely those are DAD packets) + silently ignore DAD? + Or accept-and-forward iff (multicast && client2client)? + handle NS/NA +3.) IPv6 related environment variables - document all of them in openvpn.8 - make sure that all existing IPv4 stuff has IPv6 counterparts -16.) OpenBSD - - implement ifconfig/route for IPv6 - - revert ifconfig/open_tun order to "normal" (separate commit!!!) - (openvpn-devel, Subject: OpenBSD) - - test - - * 2012-02-05 platform cleanup, commit 82d4e12068774b0a6ca - -17.) client-option (Elwood) - - ignore-v6-push-options yes/no - - ignore-v6-route-push ("as for IPv4 routes") - -18.) fail-save? "what if 'ip -6 addr add' fails" -> fail, or fallback to v4? - (-> recomment setting "ignore-v6-push-options yes") - -19.) safety check: if connecting over IPv6 (v6 transport) and the pushed +4.) safety check: if connecting over IPv6 (v6 transport) and the pushed route-ipv6 network encompasses the server IPv6 address, make sure we at least log a warning (until we can fiddle with external routing to make this work correctly). -20.) show "route add" / "route delete" commands for IPv6 in log file - (we show the "ifconfig" commands, so why not the routes?) - - 2010-08-07: this is a null-feature - it's already there, but with - different debug level (M_INFO vs. D_ROUTE) so user - didn't notice - -21.) enable ipv6-only server operations - - decouple ipv6 pool handling from ipv4 pool - - make sure Rest of OpenVPN doesn't assume "there will always be IPv4" - -22.) implement --learn-address for IPv6 - -23.) FreeBSD 8 seems to require explicit setting of the "ifconfig" IPv6 - route, while FreeBSD 6+7 don't --> more testing, and code fix - - workaround for the time being: just add - - server-ipv6 2001:608:4:a051::/64 - route-ipv6 2001:608:4:a051::/64 - - to the config - - (problem + workaround applies both to tun and tap style devices) - - * 2012-06-09 - this got fixed in one of the platform cleanups - - - TODO for IPv6 transport support ------------------------------- -[ Last updated: 2014-01-03. ] +[ Last updated: 2022-02-04. ] * All platforms: o mgmt console: as currently passes straight in_addr_t bits around @@ -193,14 +39,6 @@ TODO for IPv6 transport support Hard: requires deep changes in initialization/calling logic - Done by dual stack patches - o use AI_PASSIVE - - Done by dual stack patches - - o the getaddr()/getaddr6() interface is not prepared for handling socktype - "tagging", currently I abuse the sockflags bits for getting the ai_socktype - downstream. - - Still done by flags, seems clean enough. - o implement comparison for mapped addresses: server in dual stack listening IPv6 must permit incoming streams from allowed IPv4 peer, currently you need to pass eg: --remote ffff::1.2.3.4 -- 2.34.1 _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
