1TODO for IPv6 payload support 2----------------------------- 3 41.) "--topology subnet" doesn't work together with IPv6 payload on FreeBSD 5 (verified for FreeBSD server, Linux/ifconfig client, problems 6 with ICMP6 neighbor solicitations from BSD not being answered by Linux) 7 8 * 2012-01-22 fixed in platform cleanup, commit 62c613d46dc495d74 9 102.) NetBSD IPv6 support doesn't work 11 ("connected" route is not auto-created, "route-ipv6" adding fails) 12 13 * fixed, 3.1.10 * 14 153.) route deletion for IPv6 routes is not yet done 16 17 * fixed for configured routes, 3.1.10 * 18 * missing for manual-ifconfig-connected (NetBSD, Darwin, Win32) 19 20 * 2012-06-10 - fixed somewhere in 2010 21 224.) do "ifconfig tun0 inet6 unplumb" or "ifconfig tun0 destroy" for 23 Solaris, *BSD, ... at program termination time, to clean up leftovers 24 (unless tunnel persistence is desired). 25 26 For Solaris, only the "ipv6 tun0" is affected, for the *BSDs all tun0 27 stay around. 28 29 * 2012-06-10 - fixed in individual platform cleanups early-2012 30 314a.) deconfigure IPv6 on tun interface on session termination, otherwise 32 one could end up with something like this (on NetBSD): 33 34tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 35 inet 10.9.0.18 -> 10.9.0.17 netmask 0xffffffff 36 inet6 fe80::a00:20ff:fece:d299%tun0 -> prefixlen 64 scopeid 0x3 37 inet6 2001:608:4:eff::2000:3 -> prefixlen 64 38 inet6 2001:608:4:eff::1:3 -> prefixlen 64 39 40 (pool was changed, previous address still active on tun0, breakage) 41 42 * semi-fixed for NetBSD, 28.2.10, always do tun0 destroy / tun0 create 43 before actual ifconfig -- tunnel still lingers after OpenVPN quits 44 45 * 2011-09-16 fixed in platform cleanup, commit 8ca19c014c149cf69 46 474b.) verify this - on FreeBSD, tun0 is auto-destroyed if created by 48 opening /dev/tun (and lingers if created by "ifconfig tun0 create") 49 50 -> use for persistent tunnels on not-linux? 51 52 * 2012-06-10 tun interface behaviour is documented in "man tun(4)" 53 545.) add new option "ifconfig-ipv6-push" 55 (per-client static IPv6 assignment, -> radiusplugin, etc) 56 57 * implemented, 14.1.10 * 58 596.) add new option "route-ipv6-gateway" 60 61 * 2012-06-09 - decided there is no current need (but fairly trivial) 62 637.) add "full" gateway handling for IPv6 in route.c 64 (right now, the routes are just sent down the tun interface, if the 65 operating system in questions supports that, without care for the 66 gateway address - which does not work for gateways that are supposed 67 to point elsewhere. Also, it doesn't work for TAP interfaces. 68 69 * 2012-06-09 use "dev tun" for tun devices, "via $gateway" for tap 70 (and purposely do not support off-link routes) 71 728.) full IPv6 support for TAP interfaces 73 (main issue should be routes+gateway - and testing :-) ) 74 75 test 2010/09/24: TAP itself works on linux/ifconfig+iproute2, but 76 route-via-tap doesn't work at all (route points to "tap0" which fails) 77 7817: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 79 80 * 2012-06-09 missing gateway support implemented 81 828a.) 83 how is iroute-via-tap supposed to work?? 84 85 * 2012-06-10 - answer: not at all, OpenVPN doesn't do "iroute" in 86 tap mode - set up "route-ipv6" with gateway address = individual 87 client's tap0 address to get the per-client routes 88 89 909.) verify that iroute-ipv6 and route-ipv6 interact in the same way as 91 documented for iroute/route: 92 93 A's subnet, OpenVPN must push this route to all clients 94 EXCEPT for A, since the subnet is already owned by A. 95 OpenVPN accomplishes this by not 96 not pushing a route to a client 97 if it matches one of the client's iroutes. 98 9910.) extend "ifconfig-ipv6" to handle specification of /netbits, pushing 100 of /netbits, and correctly ifconfig'ing this 101 (default, if not specified: /64) 102 103 * done * 2012-02-03 104 10511.) do not add ipv6-routes if tun-ipv6 is not set - complain instead 106 107 * done * 12.1.10 108 10912.) handle incoming [::] and [fe80:...] packets in tun-p2mp MULTI mode 110 (most likely those are DAD packets) 111 silently ignore DAD? 112 Or accept-and-forward iff (multicast && client2client)? 113 handle NS/NA 114 11513.) from Martin List-Petersen: 116 117 One thing, and I guess this requires modifications in 118 network-manager-openvpn: It also works, BUT ignores "push 119 route-ipv6-gateway" and "push route-ipv6 ...." (obviously routes pushed 120 from the server) entirely. 121 12214.) from ##openvpn-discussion: 123 124 new features should be #ifdef'ed 125 126 (check whether this is feasible at all) 127 12815.) IPv6 related environment variables 129 130 - document all of them in openvpn.8 131 - make sure that all existing IPv4 stuff has IPv6 counterparts 132 13316.) OpenBSD 134 - implement ifconfig/route for IPv6 135 - revert ifconfig/open_tun order to "normal" (separate commit!!!) 136 (openvpn-devel, Subject: OpenBSD) 137 - test 138 139 * 2012-02-05 platform cleanup, commit 82d4e12068774b0a6ca 140 14117.) client-option (Elwood) 142 - ignore-v6-push-options yes/no 143 - ignore-v6-route-push ("as for IPv4 routes") 144 14518.) fail-save? "what if 'ip -6 addr add' fails" -> fail, or fallback to v4? 146 (-> recomment setting "ignore-v6-push-options yes") 147 14819.) safety check: if connecting over IPv6 (v6 transport) and the pushed 149 route-ipv6 network encompasses the server IPv6 address, make sure 150 we at least log a warning (until we can fiddle with external routing 151 to make this work correctly). 152 15320.) show "route add" / "route delete" commands for IPv6 in log file 154 (we show the "ifconfig" commands, so why not the routes?) 155 156 2010-08-07: this is a null-feature - it's already there, but with 157 different debug level (M_INFO vs. D_ROUTE) so user 158 didn't notice 159 16021.) enable ipv6-only server operations 161 - decouple ipv6 pool handling from ipv4 pool 162 - make sure Rest of OpenVPN doesn't assume "there will always be IPv4" 163 16422.) implement --learn-address for IPv6 165 16623.) FreeBSD 8 seems to require explicit setting of the "ifconfig" IPv6 167 route, while FreeBSD 6+7 don't --> more testing, and code fix 168 169 workaround for the time being: just add 170 171 server-ipv6 2001:608:4:a051::/64 172 route-ipv6 2001:608:4:a051::/64 173 174 to the config 175 176 (problem + workaround applies both to tun and tap style devices) 177 178 * 2012-06-09 - this got fixed in one of the platform cleanups 179 180 181 182 183TODO for IPv6 transport support 184------------------------------- 185 186[ Last updated: 2014-01-03. ] 187 188* All platforms: 189 o mgmt console: as currently passes straight in_addr_t bits around 190 191 o make possible to get AF from getaddrinfo() answer, ie allow openvpn to 192 use ipv4/6 if DNS returns A/AAAA without specifying protocol. 193 Hard: requires deep changes in initialization/calling logic 194 - Done by dual stack patches 195 196 o use AI_PASSIVE 197 - Done by dual stack patches 198 199 o the getaddr()/getaddr6() interface is not prepared for handling socktype 200 "tagging", currently I abuse the sockflags bits for getting the ai_socktype 201 downstream. 202 - Still done by flags, seems clean enough. 203 204 o implement comparison for mapped addresses: server in dual stack 205 listening IPv6 must permit incoming streams from allowed IPv4 peer, 206 currently you need to pass eg: --remote ffff::1.2.3.4 207 - OpenVPN will compare all address of a remote 208 but will still fail on mapped addresses 209 210* win32: 211 o find out about mapped addresses, as I can't make it work 212 with bound at ::1 and connect to 127.0.0.1 213 - Should be fixed by 8832c6c - "Implement listing on IPv4/IPv6 dual 214 socket on all platform" 215 216