Martian list of IP's to block???
sthaug at nethelp.no
sthaug at nethelp.no
Sat Oct 2 12:25:36 UTC 1999
> > deny ip 10.0.0.0 0.255.255.255 any log
> > deny ip 172.16.0.0 0.15.255.255 any log
> > deny ip 192.168.0.0 0.0.255.255 any log
>
> These three clauses will block things like ICMP would-fragment and
> ttl-expired messages, in the event that some transitory bit of network
> between your customer and someone else's customer is numbered using
> RFC1918 address space (and causes such messages to be sent).
>
> I know of several networks which use RFC1918 addresses like this,
> in the belief that since the elements with these numbers never
> need to receive a packet from anybody outside the operator's network,
> there is no need for the numbers to be globally unique.
Unfortunately, they're wrong.
> In my opinion, such RFC1918 visibility in the public network is
> misguided, and half of the disruption to service caused by rules
> like those above could be considered just punishment.
Agreed.
> Trouble is, the other half of the disruption is for your customers,
> and you know who they're going to blame if they can't reach their
> favourite repository of huge flesh-tone jpegs.
>
> Operational content: does anybody actually block packets inbound
> from off-net, in the case where they are sourced from an RFC1918
> address? If so, do your customers complain?
We (UNINETT, AS224) block RFC 1918 source addresses on our border
routers, and have been doing so for a couple of years now. We have
had zero complaints about this. We certainly intend to continue.
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
More information about the NANOG
mailing list