Hi, IPv6 payload in OpenVPN "master" is working mostly well, but it has one important missing piece: pushed routes for "tap" interfaces are not working yet - and I plan to implement that "really soon now".
The missing bit is "gateway handling".
For tun devices, we currently install IPv6 routes pointing to the interface
itself ("tun3"), and not to the IPv6 address of the other end. This works
perfectly, because the tun device is (from the kernel point of view) always
a point-to-point device, so setting a gateway doesn't add value - and with
the tun interface used, everybody can see right away "ah, vpn tunnel".
Now, a tap device is always a multiacess device with neighbor discovery
going on - so if you point a route to the device itself, the kernel will
assume it can ND ("arp") for it *on* the LAN, and not send it *across* the
LAN to the gateway on the other side. This is messy, only works if the
other end does proxy ND, and eats up needless resources - so we need to
specify a gateway address when installing the route.
The currently-implemented code has two ways to specify a gateway (which
is currently just stored for later perusal):
- ifconfig-ipv6 takes a "this is the address of the server" parameter,
which will install a "if we need a gateway, you can use *this*" value
- route-ipv6 takes an (optional) second parameter that specifies the
gateway to be used for *this* route.
IPv4 in OpenVPN additionally has the "--route-gateway" parameter, which
basically does the same thing as the extra argument of "--ifconfig-ipv6",
but it has a special flag "dhcp" which means "use the gateway that the
TAP server provided via DHCP".
Now my questions :-)
- I think we do not need "--route-gateway-ipv6" for IPv6, as all it does
can be achieved by either using what "ifconfig-ipv6" installed, or
specifying the next hop in "route-ipv6" (especially if pushed from
the server). But if you see value in implementing this, I'll do...
(There is no "dhcp" in IPv6 right now, so it might eventually be
taught to listen to bridged-in route advertisement from the server's
LAN router, but that's 2.4 music - so for now, it would just specify
a value to be inserted for routes that have no explicit gateway
specification)
- on a related note, there is "--route-metric n" which does not
currently exist in a "--route-ipv6-metric" variant. I do not think
this would be useful to have, as a) currently, most platforms don't
use the metric value anyway, and b) even if, the chance that the
metric will be different for IPv4 and IPv6, *and* you can't just
specify the metric as last parameter for "--route" / "--route-ipv6"
is low...
- do we need to support off-interface routes?
Right now, in IPv4, you can have, say, 10.1.1.0/24 on the tun/tap
interface, and install an IPv4 route that points to a gateway address
of 192.168.1.1 - somewhere which is *not* on the interface to OpenVPN.
I'm not sure I see use cases for this, but it would complicate the
implementation - because I would need to check "is the specified
next-hop on the tun/tap interface? if yes, point the route to tun,
or to tap+gateway - and if no, point the route to the next-hop, without
specifying an interface". I can do that, of course, if there are
use cases that cannot be implemented otherwise - tell me, so I can
learn :-)
- is there violent opposition to the approach "point route to interface,
if possible"? *I* think that this is a useful way to do things, and
has been implemented and extensively tested on all platforms - but if
there are strong reasons to do it the IPv4 way (don't specify interfaces,
just specify gateway addresses) I could be convinced to do it that way.
I will fight for my code, though :-)
(I'm happy to answer questions if what I wrote was unclear and confusing -
you'll find me in #openvpn-devel)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpmIK317H5Zq.pgp
Description: PGP signature
