| I claim rather that most routers _never_ have an operational need | to talk directly to random strangers, i.e. to have their interface | addresses leak. So sure, honor RFC 1918 strictly and utterly and to | the letter: put egress filters for the addrs that would guarantee | that anyone who tried to traceroute through you would see timeouts | as the replies were blocked. If that makes whingers happier, groove | on it. If your router doesn't have any different-MTU interfaces that | it routes between, then there's no harm in using RFC 1918 addresses | on the endpoints of inter-router links. Exactly. I think Vix settled that a few years back when we had this discussion (I dont remember specifically, but I remember occasions when he chimes in, he's usually the closing argument) :-) - RFC1918 addressing on *endpoint* or leaf links, is fine. - RFC1918 addressing on transit links, isn't the best idea, but except for PMTUD (which arguably shouldn't even be, um, an argument) holds no technical reasoning(correct me if i'm wrong) to abstain. My biggest complaint is that RFC1918 addresses for the most part don't have in-addr (and if they do, it's generic) and debugging a problem based on just an IP address is hard when you're talking to cluebies at someone else's NOC. While I'm not suggesting that in-addr be created for RFC1918 specific to each provider's arbitrary allocation of IPs (this would defeat a lot of 1918) I do think that, in a global or public/enterprise network, 1918 addressing on a transit link is just a bad idea. OARnet is doing it for "security" last I talked to them (which was several years ago), they've been using RFC1918 on transit links for a while now, CIP ohio-dmz.net. -jamie
OARnet is doing it for "security" last I talked to them (which was several years ago), they've been using RFC1918 on transit links for a while now, CIP ohio-dmz.net.
-jamie
Security? I have not, nor do I plan to, but I can think of tons of different points on OARnet directly and two places offnet that one could inject packets into their network and get to those routers, 1918 addressed or not. What ever happened to using good old access-lists on the router for security and blocking traffic destined for the router itself at the borders? It seems to be a much better security model than using 1918 space on the routers. Beyond that, it lets you actually have REAL in-addr.arpa replies for the WAN interfaces in a traceroute. Then again, being an OS-hUge activity, it is very much in character for them to do things their own way and damn the world if they don't like it. I'm convinced that the only thing OS-hUge breeds is primadonnas with a worthless piece of paper that proves they wasted their money and several years of their life. --- John Fraizer EnterZone, Inc
John, I've been silent on this list for quite a while but it has always erked me the way you insist on proving your network knowledge about "How to Build Networks". Since you feel the need to criticize those who have built networks that you consider inferior why don't you share some of the IP backbones that you have worked for and helped create. (And yes, I do take it personally.) T..S
Security? I have not, nor do I plan to, but I can think of tons of different points on OARnet directly and two places offnet that one could inject packets into their network and get to those routers, 1918 addressed or not.
What ever happened to using good old access-lists on the router for security and blocking traffic destined for the router itself at the borders? It seems to be a much better security model than using 1918 space on the routers. Beyond that, it lets you actually have REAL in-addr.arpa replies for the WAN interfaces in a traceroute.
Then again, being an OS-hUge activity, it is very much in character for them to do things their own way and damn the world if they don't like it.
I'm convinced that the only thing OS-hUge breeds is primadonnas with a worthless piece of paper that proves they wasted their money and several years of their life.
--- John Fraizer EnterZone, Inc
On Fri, 14 Jul 2000, Todd R. Stroup wrote:
John,
I've been silent on this list for quite a while but it has always erked me the way you insist on proving your network knowledge about "How to Build Networks". Since you feel the need to criticize those who have built networks that you consider inferior why don't you share some of the IP backbones that you have worked for and helped create.
(And yes, I do take it personally.)
T..S
Todd, you know that I can not give any details about most of the network buildouts I have been involved with. That's just fine though. I think the root of what erks you most is that you screwed the pooch when you bet against me, period, the end. It might also have something to do with the fact that you chose your alliances poorly. No matter. If you really must know a few networks I have been involved with (and left on good graces, I might add) here you go: Digital Equipment Corporation (back when it was still DEC) CitiCorp Hoescht Cellonese Siemens Rolm MacGuire Nuclear Power plant (and, yes, they have on-net connectivity) Catabwa Nuclear Power plant (same here) Duke Power Microsoft Corporation Walnut Creek CDROM (as in CDROM.COM) Blockbuster, Inc The Walt Disney Company Seagate Corporation Fidelity Investments First Union National Bank Wachovia Corporation The State of North Carolina The University of North Carolina at Charlotte The State of Tennessee The University of Tennessee at Knoxville The State of Ohio ..and yes, even The Ohio State University The list above was on my resume' before I was even your age, Son. When was the last time you worked inside the Pentagon? (and I'm not talking about the mall) Never? Oh, too bad. It's el-nifty-neato. The moral of this story is: Don't piss in the wind or you will end up all wet and smelly. Had you shown the curtosy of _attempting_ to flame me privately, I would have shown you the same when I shut you down. Since you just had to go to the list, I have returned the favor. This is the end of this little debate Todd. I did not personally attack you, no matter if you took my remarks about some network entity personally. You attacked me personally. You crossed the line. I only hope that I am the only one who has lost all respect for you, for your sake. --- John Fraizer EnterZone, Inc
On Sat, Jul 15, 2000 at 01:53:59PM -0400, John Fraizer wrote:
If you really must know a few networks I have been involved with (and left on good graces, I might add) here you go:
[..penis waving deleted..] Walnut Creek CDROM (as in CDROM.COM) [..penis waving deleted..]
The internal network of Walnut Creek CDROM (now BSDi's OpenSource division) before some recent fixups was one of the largest, festering piles of shit and ducttape I had ever seen. I truely hope that what I saw isn't what you're trying to use as some sort of reference. On that note, I truely hope whoever setup what I saw isn't in the business anymore.
The list above was on my resume' before I was even your age, Son. When was the last time you worked inside the Pentagon? (and I'm not talking about the mall) Never? Oh, too bad. It's el-nifty-neato.
"My penis is bigger then yours, nyah nyah nyah nyah." All Todd's post said is that you have to "insist on proving your network knowledge" about how "you feel the need to criticize those who have built networks that you consider inferior". You just proved him right. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org
Actually, when I worked there, the only groups that were using RFC 1918 were some internal test networks at Ohio State University and the internal network of the State of Ohio (both of these organizations used a mix of real and 1918 space). OARnet has never had and will never have control over those organizations and their network policies. At the time of my departure in 1996 we mostly used a couple of /24's out of our 199.18/16 for serial connections. To www.utoledo.edu 13 tlp1-atm1-1-0.toledo.oar.net (199.18.202.51) 43.366 ms 54.371 ms 43.360 ms 14 utoledo-atm2-0s1.toledo.oar.net (199.18.111.90) 44.644 ms 44.263 ms 44.405 ms 15 www.utoledo.edu (131.183.1.7) 44.781 ms 45.440 ms 44.609 ms To www.akron.edu 13 alp1-atm6-0.akron.oar.net (199.18.202.71) 42.051 ms 41.962 ms 42.196 ms 14 uakron1-atm2-0s1.akron.oar.net (199.18.101.42) 42.090 ms 41.844 ms 46.048 ms 15 130.101.18.1 (130.101.18.1) 42.837 ms 45.823 ms 42.534 ms 16 mulder.cc.uakron.edu (130.101.5.50) 46.281 ms 42.777 ms 41.934 ms To www.udayton.edu 13 dlp2-atm2-0.dayton.oar.net (199.18.202.102) 37.537 ms 37.461 ms 50.051 ms 14 udayton-atm2-0s1.dayton.oar.net (199.18.109.14) 55.810 ms 40.436 ms 38.168 ms 15 131.238.11.5 (131.238.11.5) 39.048 ms 38.256 ms 42.208 ms 16 reliant.udayton.edu (131.238.75.30) 52.704 ms 38.672 ms 37.917 ms To www.onu.edu 13 sot1-atm1-0.columbus.oar.net (199.18.202.21) 38.906 ms 43.136 ms 37.208 ms 14 onu-sl0.columbus.oar.net (199.18.103.54) 51.666 ms 53.201 ms 53.414 ms 15 * * * 16 db01.onu.edu (140.228.8.60) 71.364 ms 64.060 ms 58.205 ms I think you get the point. T..S ----- Original Message ----- From: Jamie Rishaw <jamie.rishaw@mypotential.com> To: 'Bennett Todd' <bet@rahul.net>; Gary E. Miller <gem@rellim.com> Cc: <nanog@merit.edu> Sent: Friday, July 14, 2000 4:18 PM Subject: RE: RFC 1918
| I claim rather that most routers _never_ have an operational need | to talk directly to random strangers, i.e. to have their interface | addresses leak. So sure, honor RFC 1918 strictly and utterly and to | the letter: put egress filters for the addrs that would guarantee | that anyone who tried to traceroute through you would see timeouts | as the replies were blocked. If that makes whingers happier, groove | on it. If your router doesn't have any different-MTU interfaces that | it routes between, then there's no harm in using RFC 1918 addresses | on the endpoints of inter-router links.
Exactly.
I think Vix settled that a few years back when we had this discussion (I dont remember specifically, but I remember occasions when he chimes in, he's usually the closing argument) :-)
- RFC1918 addressing on *endpoint* or leaf links, is fine.
- RFC1918 addressing on transit links, isn't the best idea, but except for PMTUD (which arguably shouldn't even be, um, an argument) holds no technical reasoning(correct me if i'm wrong) to abstain.
My biggest complaint is that RFC1918 addresses for the most part don't have in-addr (and if they do, it's generic) and debugging a problem based on just an IP address is hard when you're talking to cluebies at someone else's NOC. While I'm not suggesting that in-addr be created for RFC1918 specific to each provider's arbitrary allocation of IPs (this
would
defeat a lot of 1918) I do think that, in a global or public/enterprise network, 1918 addressing on a transit link is just a bad idea.
OARnet is doing it for "security" last I talked to them (which was several years ago), they've been using RFC1918 on transit links for a while now, CIP ohio-dmz.net.
-jamie
participants (4)
-
Bill Fumerola -
Jamie Rishaw -
John Fraizer -
Todd R. Stroup