[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: reconsidering default exit policy



On Fri, 11 Mar 2005, Valient Gough wrote:

Also, is the list of private networks above exhaustive?  I took my list
of networks to block from my firewall list (from firehol.sourceforge.net):
[..]
RESERVED_IPS="0.0.0.0/7 2.0.0.0/8 5.0.0.0/8 7.0.0.0/8 23.0.0.0/8
27.0.0.0/8 31.0.0.0/8 36.0.0.0/7 39.0.0.0/8 41.0.0.0/8 42.0.0.0/8
73.0.0.0/8 74.0.0.0/7 76.0.0.0/6 89.0.0.0/8 90.0.0.0/7 92.0.0.0/6
96.0.0.0/3 173.0.0.0/8 174.0.0.0/7 176.0.0.0/5 184.0.0.0/6 189.0.0.0/8
190.0.0.0/8 197.0.0.0/8 223.0.0.0/8 240.0.0.0/4"

IMHO it does not make any sense to add any netblocks which are likely to be assigned to real people in near future to the hard-coded list in the source code. People will have trouble connecting to these IPs, because you can not except every tor server operator to update the list when IANA makes an announcement about a new allocation to ARIN/RIPE/APNIC.

This is already a problem with router & firewall configurations
even though folks maintaining those are supposed to keep track of
new IP allocations in case they have bogon IP filters. But in reality
it does not work because people are lazy (or the person who implemented
the bogon filter might have left the company or whatever). This is
happening with many recent IP assignments and causes connectivity
problems. For example 71/8 and 72/8 were allocated to ARIN in Aug
2004 and I suppose 73/8 (which you list) will come next.

So, unless there is a very strong reason to block these ranges, I
suggest not. There shouldn't be any strong reason to do so because
people are not supposed to be currently using these IP blocks for
anything within their infrastructure anyway (unlike RFC1918 addresses
etc).

OTOH it does make sense to block multicast range (224.0.0.0/4) which
is missing from your list, because it is in active use and can not
be used for unicast addressing any more. The same applies to some
other special-use IP address blocks, as listed in RFC 3330.

--
Janne Snabb
snabb@xxxxxx