[27405] in North American Network Operators' Group
private RFC-1918 addresses on public routers
daemon@ATHENA.MIT.EDU (William Allen Simpson)
Thu Feb 17 19:29:57 2000
Message-ID: <38AC6676.7974C8D8@greendragon.com>
Date: Thu, 17 Feb 2000 16:22:10 -0500
From: William Allen Simpson <wsimpson@greendragon.com>
MIME-Version: 1.0
To: nanog@merit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
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
