private RFC-1918 addresses on public routers

[William Allen Simpson <wsimpson () greendragon com>]

Usually, when a "private" address hits the bogon filters, a quiet 
note to the perpetrator gets the problem fixed promptly.  This time,
the fellow seems to want to argue.  Since he's been on this list for 
awhile (posted here about 8 months ago), perhaps he's educable.

His characterization isn't what I remember from the previous discussion(s).

Moreover, with the recent emphasis on filtering bogus source addresses, 
maybe it's time to take a stronger stand on the practice.

The facts:
 - a not-insignificant regional public backbone.
 - a private class B (172.19) on public backbone router interfaces, 
   contrary to the guidelines in RFC-1918 (p 3).
 - a congested link that generates a significant number of ICMP messages.
 - the private source address is not being properly filtered by the 
   ISP from reaching the public network, as required (RFC-1918 p 5).
 - upstream links with non-maintained (missing) in-addr entries.
 - traceroute downstream, after this private address, on the way to a 
   medium-sized university, disappears into a black hole, although the 
   university itself is certainly not in private address space.

While not of earth-shaking consequence, it clearly isn't helpful for 
debugging the network.

What kind of actions should we take?  Complain to a supervisor?  
Construct a web page of infamy?

#(name removed to protect the guilty)
# I have followed and participated in several of the lively NANOG discussions.
# As I recall the usual conclusion on NANOG is - let's agree to disagree. That
# seems to me to leave it open to interpretation on whether this practice is
# good  - it saves public IP space, or bad - you can see it on a traceroute.
#
# I am aware of the MTU problem but how does it break ICMP?

WSimpson () UMich edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32