Re: IPv6: what is required of lower layers?

[Gert Doering <gert%greenie.muc.de@localhost>]

Hi,

On Wed, Apr 05, 2023 at 12:44:52PM -0400, Mouse wrote:
> > In OpenVPN we've avoided all the drama related to ND by configuring
> > the tun interfaces to IFF_POINTOPOINT|IFF_MULTICAST - so as far as
> > the kernel is concerned, there is no neighbour discovery, just a dumb
> > pipe "whatever is routed into the tun interface is sent to userland".
> 
> Perhaps I should try that.  It's probably a holdover from the past; I
> tend to think of POINTOPOINT interfaces as being inherently /32 (or
> /128 for v6) on each end.  But if it works to put a nontrivial netmask
> on them, that may be worth doing.

Sort of.  For IPv4, it's "two /32s".  For IPv6, it's "a network with
a netmask", this "two distinct A and B addresses" seems to have never
been implemented anywhere.

> However, a POINTOPOINT interface necessarily has a destination address.
> I don't know what I'd specify for the destination address, since there
> is no single peer whose address it makes sense to use on the tun.

From the rest of the thread, it seems POINTOPOINT won't be of much
use to your use case, if you make use of the TUNSLMODE destination
address - which is something OpenVPN never did, it does an "internal
routing lookup" on the in-header destination IP address (on the 
multipoint server, the client is dumb and sends everything coming
in from the tun interface onwards to the server).

[..]
> I use TUNSLMODE instead, to get prepended destination addresses, rather
> than TUNSIFHEAD's multi-AF mode.  My if_tun.c has been significantly
> worked over; I forget whether that was one of my changes.  A quick look
> at the commit makes me think not, but I'm not sure.

TUNSLMODE is something NetBSD and FreeBSD both have (but not OpenBSD),
so it seems to be "not something private to your tree".

> > [...] because multicast is oh so much better than just broadcast as
> > ARP will do.
> 
> That reads as though you are sarcastically criticizing v6's use of
> multicast.  If so, I think that is at least partially unfair; multicast
> _is_ better, in that, on multicast-capable media, it can reduce the
> traffic third-party nodes have to deal with by a significant fraction.

I do understand the theoretical benefits of multicast.

The problem here is that it adds quite a bit of complexity to something
that needs to be very simple, or vendors will get it wrong.

My first IPv6-induced network explosion was on an Intel E100 card which
got stuck when the multicast filter was programmed, spewing out garbled
packets at wire speed, killing *other* hosts on the network due to
interrupt load... later, I've been hit by "Big Name" ethernet switch
vendors getting multicast forwarding wrong again and again, breaking
IPv6 ND (and, incidentially, IPv4 EIGRP hellos).

With the move towards smaller network segments and (on wifi) local
ARP/ND spoofing, the packet rate for ARP/ND tends to be fairly low in
modern networks, so the saved CPU is really not worth the extra hassles.

Of course all of this is easy to say in hindsight, while the design
comes from the times of Yellow Cables with slow CPUs attached to it
where "less IRQ" mattered.

[...]
> I am not fond of the use of ICMP6 for neighbour discovery.  Pulling
> neighbour address resolution up into the IP layer strikes me as a wrong
> choice.  Perhaps I'm just ignorant of some tradeoffs....

I can see why this was done, so they could avoid to specify a medium
dependent neighbour resolution protocol - like ARPv6 on Ethernet, 
"something" for SDH, ATM, ...

OTOH, basing this on a routable protocol - ICMPv6 - was not a very
security-conscious decision.  There has been a number of attacks on
devices using NDP "from the world", because vendors (again) are not
good at applying proper sanity checks ("yes, an NS packet really must
have a TTL of 255", before doing any other processing, or putting it
into the same rate-limiting queue as "good" NS packets).

Or, Big Name vendors forwarding packets with fe80:: sources, helping
the attack against the other Big Name vendor (because you must ACL permit
fe80:: sources).

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert%greenie.muc.de@localhost