Compiles correctly: app/build-native + gradle.

1 files changed, 209 insertions, 0 deletions

diff --git a/app/openvpn/TODO.IPv6 b/app/openvpn/TODO.IPv6
new file mode 100644
index 00000000..29d75546
--- /dev/null
+++ b/app/openvpn/TODO.IPv6
@@ -0,0 +1,209 @@
+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: 10-Jun-2012. ]
+
+* 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
+
+  o use AI_PASSIVE
+
+  o the getaddr()/getaddr6() interface is not prepared for handling socktype
+    "tagging", currently I abuse the sockflags bits for getting the ai_socktype
+    downstream.
+
+  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
+
+
+* 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
+