|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical private RFC-1918 addresses on public routers
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? [email protected] Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
|