On Sat, Jan 7, 2023 at 11:12 AM Gert Doering <g...@greenie.muc.de> wrote:

> > Though I vaguely understand why we set the address with /128 and then set
> > the route for the vpn subnet with fe80::8 as the gateway for
> tap-windows6,
> > wonder why we do this for dco as well.
> Let me recap why we do this for tap-windows - for windows, this is always
> an Ethernet adapter, so it wants to always do neighbour discovery (ND),
> IPv6's equivalent of ARP for all "on this interface" addresses.
> For "--dev tun" setups, OpenVPN does not want to deal with "Ethernet
> things",
> so the TAP driver replies to ARP requests for "special addresses" - for
> net30, OpenVPN ioctl()'s the "peer" address (which is also the gateway
> address) into the TAP driver, and only this address is replied to -
> admittedly, I do not know how "topology subnet" works wrt virtual ARP,
> need to read up on this again.
> For IPv6, I decided that having to deal with ND is easier if I could just
> look at a magic number, namely fe80::8, in the tap driver code - so, we
> use /128 for the ifconfig bit ("no network here, everything is behind the
> gateway") and point all routing to "on this interface, fe80::8" - so for
> whatever IPv6 destination, windows will only do ND for fe80::8, and the
> TAP driver will reply to it, without any further help (ioctl()) from
> OpenVPN.

Thanks for the explanation. I had a vague idea that this is done for ND.

> This said, I have no idea why we do it that way for wintun and DCO -
> most likely because it avoids having to add even more windows-driver-
> specific special case handling in places where we are nicely generic
> today.

I guess it works because nexthop is ignored[*] for tun adapters and we
could have just set an onlink route omitting the gateway parameter.


[*] Any bogus gateway seems to work, but still, "netsh int ipv6 show
lists any such gateway set for dco as initially "Probe" and then
so not totally ignored?
Openvpn-devel mailing list

Reply via email to