|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: private RFC-1918 addresses on public routers
So you explained that his router is generating source quench messages that are treated, rightfully so, as bogus? Does he understand what source quench is for? It takes more than theory you/we all have to show that hosts such as winX PCs obey and consume such messages and modify their behavior. ----- Original Message ----- From: "William Allen Simpson" <[email protected]> To: <[email protected]> Sent: Thursday, February 17, 2000 4:22 PM Subject: 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 >
|