Good evening all,

Forgive me if this is common knowledge, but my reading of bgpd.conf(5) on OpenBSD 4.3 did not make the following clear to me:

When running BGP with only IPv4 prefixes, the examples given in the sample bgpd.conf work splendidly.

Reading the FILTERS section of bgpd.conf lead me to believe that simply adding
"allow from any inet6 prefixlen 12 - 48"
would allow the IPv6 prefixes that my neighbor was announcing to me be added from the RIB into the FIB, however this was not the case. After trying to specify each rule as explicitly pertaining to "inet" or "inet6" I found that bgpd would only match the announced IPv6 prefixes to my "allow" line when I qualified each "deny" line with a prefixlen, regardless of the CIDR mask appended to the address. Specifically, the "deny from any prefix 0.0.0.0/0" line in the sample config would always match *all* IPv6 prefixes (but not clobber any of my IPv4 prefixes, which were merged into the FIB just fine), even if I inserted the "inet" parameter into the rule.

I ended up with the following minimum FILTER config, which works just fine:
-----------------------------
# filter out prefixes longer than 24 or shorter than 8 bits
deny from any
allow from any inet prefixlen 8 - 24

# allow most IPv6 prefixes
allow from any inet6 prefixlen 12 - 48

# do not accept a default route
deny from any inet prefix 0.0.0.0/0 prefixlen = 0

# filter bogus networks
deny from any inet prefix 10.0.0.0/8 prefixlen >= 8
deny from any inet prefix 172.16.0.0/12 prefixlen >= 12
deny from any inet prefix 192.168.0.0/16 prefixlen >= 16
deny from any inet prefix 169.254.0.0/16 prefixlen >= 16
deny from any inet prefix 192.0.2.0/24 prefixlen >= 24
deny from any inet prefix 224.0.0.0/4 prefixlen >= 4
deny from any inet prefix 240.0.0.0/4 prefixlen >= 4
----------------------------------

If this (having to always specify a prefixlen even if a CIDR mask is present) is the desired behavior (which is fine by me), I'll be happy to write a diff for bgpd.conf(5) but in my opinion it appears that at the very least the family (inet or inet6) parameter in the filter syntax is busted, though as I've just now noticed this I haven't looked at the source at all. I've also not yet tried to reproduce this behavior on -CURRENT, so forgive me if this is old news -- the only IPv6-related brokenness that I could find that seemed to even remotely be similar is http://marc.info/?l=openbsd-misc&m=121036759606446&w=2

et voila!
$ ping6 -S 2607:f618:1::1 ipv6.google.com PING6(56=40+8+8 bytes) 2607:f618:1::1 --> 2001:4860:0:2001::68
16 bytes from 2001:4860:0:2001::68, icmp_seq=0 hlim=59 time=76.009 ms

Anyhow, cheers!
-Tico

Reply via email to