North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: do bogon filters still help?

  • From: william(at)elan.net
  • Date: Wed Jan 11 14:43:35 2006

On Wed, 11 Jan 2006, Florian Weimer wrote:

Thank you for your suggestions.

* william elan net:

For those doing similar exercise, you might want to look at rephrased
version of rfc330 listed blocks:
 http://www.completewhois.com/iana-ipv4-specialuse.txt
You should move 192.88.99.0/24 from SPECIAL to YES (although you
shouldn't see source addresses from that prefix, no matter what the
folks at bit.nl think).  169.254.0.0/16 should be NO (otherwise it
wouldn't be link-local).
I think you just explained it yourself why this is "SPECIAL", i.e.
routing of it depends on local policies and setup. Anything where it
is not clear from RFCs if it should be routable or not and where it depends on local decisions & policy is what I called SPECIAL.

Perhaps better documentation is needed to explain each case, which
I'll likely do some point way in the future when html version of the
same page also becomes available. It is on the TODO list.

to make the list more future-proof, listing 128.0.0.0/16,
191.255.0.0/16, 192.0.0.0/24 and 223.255.255.0/24 as YES might be a
good idea.  I'm not sure what to do with 39/8.
Yes, I considered that. Ultimately these blocks might well become routed.

It should be pointed out though that the file is not set in stone and
was intended to be updated when some block's status changes just like
this is done with iana-ipv4-allocations.txt

It is however possible that I'll change it to YES with special comment
because the data does seem more of something that people are going to
configure and left alone rather then expect changes as with bogon data.

I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24
for examples in documentation.  In practice, this prefix is used for
distributing fake null routes over BGP, so it's a rather strong NO.
If you know which RFC it is, I'll update the reference table.

--
William Leibzon
Elan Networks
[email protected]