[27406] in North American Network Operators' Group
Re: private RFC-1918 addresses on public routers
daemon@ATHENA.MIT.EDU (Dana Hudes)
Thu Feb 17 19:40:18 2000
Message-ID: <03da01bf79a8$521a86c0$3d5cdcd1@hudes.org>
From: "Dana Hudes" <dhudes@panix.com>
To: "William Allen Simpson" <wsimpson@greendragon.com>,
<nanog@merit.edu>
Date: Thu, 17 Feb 2000 19:37:22 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: owner-nanog-outgoing@merit.edu
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?=20
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 -----=20
From: "William Allen Simpson" <wsimpson@greendragon.com>
To: <nanog@merit.edu>
Sent: Thursday, February 17, 2000 4:22 PM
Subject: private RFC-1918 addresses on public routers
>=20
> Usually, when a "private" address hits the bogon filters, a quiet=20
> 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=20
> awhile (posted here about 8 months ago), perhaps he's educable.
>=20
> His characterization isn't what I remember from the previous =
discussion(s).
>=20
> Moreover, with the recent emphasis on filtering bogus source =
addresses,=20
> maybe it's time to take a stronger stand on the practice.
>=20
> The facts:
> - a not-insignificant regional public backbone.
> - a private class B (172.19) on public backbone router interfaces,=20
> 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=20
> 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=20
> medium-sized university, disappears into a black hole, although the =
> university itself is certainly not in private address space.
>=20
> While not of earth-shaking consequence, it clearly isn't helpful for=20
> debugging the network.
>=20
> What kind of actions should we take? Complain to a supervisor? =20
> Construct a web page of infamy?
>=20
> #(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?
>=20
> WSimpson@UMich.edu
> Key fingerprint =3D 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C =
32
>=20
