Possibly users behind your filters are tracerouting through
somewhere which has PtP links configured in RFC1918 space,
and you are seeing ICMP TTL exceeded back from these addresses.
Some people allege configuring publicly visible PtPs to RFC1918
addresses is not bad practice. YMMV.
And other people allege that it is easier to use RFC1918 space
for /30's than having to deal with ARIN to get more space. More
than just using up allocated space (I only have a dozen or so
such links) is the issue of fragmenting the space. I put all
my /30's that don't have a specific need for public addresses
in 172.30.0.0/16 (I call it "30 space").
One advantage that RFC1918 doesn't mention is that having this
space available helps keep down the amount of address space
fragmentation so I don't have to do so much renumbering to keep
large enough free space for big customers.
My outbound access lists block it, so you should never see 1918
sources coming from me. You should see "* * *" instead, even
if you don't block them coming in to your net.
I also run some 1918 traffic inside. For example, I have DNS
running on 172.16.4.4, 172.16.5.5, 172.16.6.6, and 172.16.7.7.
There's no actual subnet for them. They are just IP aliased
and statically routed to the correct box. The next time we
renumber, we won't have to change DNS numbers for a large chunk
of our customers.
Again, none of this should be leaking because the servers have
public addresses as the real address for their interfaces, and
the access lists take care of any other strays.
[ On Friday, April 23, 1999 at 00:59:06 (-0500), Phil Howard wrote: ]
Subject: Re: address spoofing
My outbound access lists block it, so you should never see 1918
sources coming from me. You should see "* * *" instead, even
if you don't block them coming in to your net.
I think this sucks big-time. It wouldn't be quite so bad if traceroute
were the only thing that were broken by it (though I do like my
traceroutes to work properly too), but when all ICMP traffic from such a
router is hosed, and one of the links my packets are trying to hop onto
through such a router is down, then I'm a particularly unhappy camper
(if I could see the !H or !N I'd still be unhappy of course, but not
throwing my arms up in disgust at the guy generating the * * *). Of
course even an upstream provider from my own home network does this,
depsite the fact I've chided and cajoled and otherwise bugged them to
change it.
Now in Phil's networks perhaps it is normally impossible for illegally
formed host-unreachables to be generated even in the face of outages
because hopefully he's got everything running fully redundant, but *I*
see this kind of breakage from all kinds of places many times a day in
the filter logs on my networks and those of my clients.
There's also not really any difference between you blocking those
packets on the way out, and me blocking them on the way in -- the end
result is that all ICMP and whatever else from those routers is busted.
Perhaps router vendors can figure out some way to ensure that all
packets generated by a router get a unique, valid, non-RFC1918 number
when they would otherwise have used an RFC1918 number. Maybe people who
think they need to use RFC1918 should instead just hide all their
internal crap in a big ATM or FR cloud.
Then there's the crap I see in the filter logs on my HTTP transparent
cache and proxy machines that seems to indicate people have publicly
published URLs (perhaps with publicly visible DNS) that point at RFC1918
space..... Grrrrr.