Filters

Bernhard Schmidt berni at birkenwald.de
Tue May 24 01:59:48 CEST 2005


Jimmy Sadri wrote:

Hi Jimmy,

> Does anyone have any good links to ipv6 bogon lists so far I've found
> this one http://www.space.net/~gert/RIPE/ipv6-filters.html but it
> seems a little outdated.  Actually, if you people wouldn't mind I'd
> like to see what people are actually using on their routers… post
> your bogon filter if you want.  If you could give a little
> explaination as to why you block things and weather you consider it
> to be a strict or more loose.

I'm currently using the following filters

! documentation prefix, RFC3849
ipv6 prefix-list strict deny   2001:DB8::/32 le 128
! ARIN Microallocations
ipv6 prefix-list strict permit 2001:500::/30 ge 48 le 48
! ARIN IXP
ipv6 prefix-list strict permit 2001:504::/30 ge 48 le 48
! RIPE IXP
ipv6 prefix-list strict permit 2001:7F8::/32 ge 48 le 48
! APNIC IXP
ipv6 prefix-list strict permit 2001:7FA::/32 ge 48 le 48
! Allow 6to4 anycast prefix
ipv6 prefix-list strict permit 2002::/16
ipv6 prefix-list strict deny   2002::/16 le 128
! rest of unicast
ipv6 prefix-list strict permit 2000::/3 ge 17 le 35
ipv6 prefix-list strict deny   ::/0 le 128

As some people may know I still don't think supporting IPv6 multihoming
with random /48-/40 more-specifics chunked from larger PA allocations is
wise, so my filters strictly block them. The only exception is for the
known blocks where /48s are issued (IXP and ARIN microallocations). IXP
space may be filtered, that is up to you.

The rest of 2000::/3 is opened up to the current in-the-wild maximum
allocation prefix len of /35. In published filters you could often see
something like

permit 2001::/32 ge 17 le 35
permit 2003::/32 ge 17 le 35

since now 2600:: and 2a00:: are (about to be) allocated and a bogus
prefix somewhere in the middle of free space (3123:abcd::/32) does not
do more or less harm than something in the allowed holes of RIR space
(2001:db9::/32) this does not make sense in my opinion.

WARNING: These filters are certainly _not_ fire and forget. If there is
the probability that the system might run on autopilot at some day (as
happened with many of the prior 6bone-participants) you should open the
filters for anything up to /48, there might be /48s allocations from
other blocks ("IPv6 PI") at a later time.

Other than that, to my observation more-specific paths are often longer
and useless (leaked iBGP, clueless operator, filtered on a couple of
transits), so if you can keep your filters up to date if something in
the allocation rules changes, you should filter them IMHO.

Bernhard

P.S.: Please don't send HTML mails to mailinglists.



More information about the ipv6-ops mailing list