release/src/router/openvpn/TODO.IPv6

   1 TODO for IPv6 payload support
   2 -----------------------------
   3
   4 1.) "--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
  10 2.) NetBSD IPv6 support doesn't work
  11     ("connected" route is not auto-created, "route-ipv6" adding fails)
  12
  13     * fixed, 3.1.10 *
  14
  15 3.) 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
  22 4.) do "ifconfig tun0 inet6 unplumb"  or "ifconfig tun0 destroy" for
  23     Solaris, *BSD, ... at program termination time, to clean up leftovers
  24     (unless tunnel persistance 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
  31 4a.) deconfigure IPv6 on tun interface on session termination, otherwise
  32     one could end up with something like this (on NetBSD):
  33
  34 tun0: 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
  47 4b.) 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 persistant tunnels on not-linux?
  51
  52     * 2012-06-10 tun interface behaviour is documented in "man tun(4)"
  53
  54 5.) add new option "ifconfig-ipv6-push"
  55     (per-client static IPv6 assignment, -> radiusplugin, etc)
  56
  57     * implemented, 14.1.10 *
  58
  59 6.) add new option "route-ipv6-gateway"
  60
  61     * 2012-06-09 - decided there is no current need (but fairly trivial)
  62
  63 7.) 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
  72 8.) 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
  78 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
  79
  80     * 2012-06-09 missing gateway support implemented
  81
  82 8a.)
  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
  90 9.) 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
  99 10.) 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
 105 11.) do not add ipv6-routes if tun-ipv6 is not set - complain instead
 106
 107      * done * 12.1.10
 108
 109 12.) 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
 115 13.) 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
 122 14.) from ##openvpn-discussion:
 123
 124         new features should be #ifdef'ed
 125
 126         (check whether this is feasible at all)
 127
 128 15.) 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
 133 16.) 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
 141 17.) client-option (Elwood)
 142         - ignore-v6-push-options yes/no
 143         - ignore-v6-route-push  ("as for IPv4 routes")
 144
 145 18.) fail-save?  "what if 'ip -6 addr add' fails" -> fail, or fallback to v4?
 146         (-> recomment setting "ignore-v6-push-options yes")
 147
 148 19.) 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
 153 20.) 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
 160 21.) 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
 164 22.) implement --learn-address for IPv6
 165
 166 23.) 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
 183 TODO for IPv6 transport support
 184 -------------------------------
 185
 186 [ Last updated: 10-Jun-2012. ]
 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
 195   o use AI_PASSIVE
 196
 197   o the getaddr()/getaddr6() interface is not prepared for handling socktype
 198     "tagging", currently I abuse the sockflags bits for getting the ai_socktype
 199     downstream.
 200
 201   o implement comparison for mapped addesses: server in dual stack
 202     listening IPv6 must permit incoming streams from allowed IPv4 peer,
 203     currently you need to pass eg:  --remote ffff::1.2.3.4
 204
 205
 206 * win32:
 207   o find out about mapped addresses, as I can't make it work
 208     with bound at ::1 and connect to 127.0.0.1
 209