Alex Bligh wrote:
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. -- Phil Howard KA9WGN phil@intur.net phil@ipal.net