diff options
Diffstat (limited to 'main/openvpn/TODO.IPv6')
| m--------- | main/openvpn | 0 | ||||
| -rw-r--r-- | main/openvpn/TODO.IPv6 | 215 |
2 files changed, 0 insertions, 215 deletions
diff --git a/main/openvpn b/main/openvpn new file mode 160000 +Subproject 7aaf01766f9718375986600216607aeb6397200 diff --git a/main/openvpn/TODO.IPv6 b/main/openvpn/TODO.IPv6 deleted file mode 100644 index 24bf865a..00000000 --- a/main/openvpn/TODO.IPv6 +++ /dev/null @@ -1,215 +0,0 @@ -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 persistance 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 persistant 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 - documented for iroute/route: - - A's subnet, OpenVPN must push this route to all clients - EXCEPT for A, since the subnet is already owned by A. - OpenVPN accomplishes this by not - 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 - - - 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 - 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. ] - -* All platforms: - o mgmt console: as currently passes straight in_addr_t bits around - - o make possible to get AF from getaddrinfo() answer, ie allow openvpn to - use ipv4/6 if DNS returns A/AAAA without specifying protocol. - 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 addesses: 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 - - OpenVPN will compare all address of a remote - but will still fail on mapped addresses - -* win32: - o find out about mapped addresses, as I can't make it work - with bound at ::1 and connect to 127.0.0.1 - - Should be fixed by 8832c6c - "Implement listing on IPv4/IPv6 dual - socket on all platform" - |