phil at whistler.intur.net
Fri Apr 23 05:59:06 UTC 1999
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 at intur.net phil at ipal.net
More information about the NANOG