I am testing out RIPng and tunnels (to try to understand firewall issues
i a different context, external to my systems) and seeing what seems
like wrong behavior from route6d.
I have a NetBSD 9 machine with
xennet0
gif0
gre0 (with UDP encap)
where gif0 and gre0 are tunnels to the same remote machine. (The
machine in question and the remote are in different ASes, and I know
that what I am doing is thus wrong in the larger sense.)
I started routed6d with "-N xennet0" because I didn't want to publish
learned routes, and didn't want to send anything that might be being
advertised by who knows who on the xennet0 LAN. (I also added a -L for
gif0,gre0 to ignore prefixes that don't belong to the remote's AS.)
The routes I expect (3 /64s within the remote machine's AS, and some
/128s for the specific addresses configured on gif0/gre0) are being
exchanged fine. This is uninteresting except that it shows the packets
are not being firewalled.
The ripng packets going out gif0 (and gre0) also include some unexpected
prefixes:
The /64 that belogns on xennet0
A bunch of /128s that are hosts on the xennet0 LAN. These are not
speaking ripng, says tcpdump. They are in the ND cache (which is in
the routing table). I see:
the /64 that belongs to the LAN
two /128s for the LAN's router and nameserver
a /128 for my own v6 address
a /128 for another VPS's v6 address
(all of the /128s are within the /64)
However:
Having passed -N xennet0, I don't expect routes from xennet0 to be
used. Although reading the man page text, it seems to be "don't send
ripng and don't listen to ripng", and that's separate from "don't
include the /64 connected route".
While I can see the point of exchanging the /64 for xennet0, sending
local ND entries in ripng just seems entirely wrong.
So probably I should be using -O to omit the local lan being advertised
towards the remote, -L on the remote side, or really both.
I suspect route6d has a bug that it is not ignoring ND entries (which do
have the L flag). But I don't understand why I would be the one to find
it, in 2021.
Hints/comments appreciated.
Greg
Attachment:
signature.asc
Description: PGP signature