diff options
Diffstat (limited to 'ics-openvpn-stripped/main/openvpn/TODO.IPv6')
| -rw-r--r-- | ics-openvpn-stripped/main/openvpn/TODO.IPv6 | 215 |
1 files changed, 215 insertions, 0 deletions
diff --git a/ics-openvpn-stripped/main/openvpn/TODO.IPv6 b/ics-openvpn-stripped/main/openvpn/TODO.IPv6 new file mode 100644 index 00000000..24bf865a --- /dev/null +++ b/ics-openvpn-stripped/main/openvpn/TODO.IPv6 @@ -0,0 +1,215 @@ +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" + |