Re: breaking the IP model (or not)
Keith Moore wrote: perhaps architectural impurity alone shouldn't keep you from doing something, but the fact that something violates fundamental design assumptions should cause you to do some analysis and hard thinking about the likely consequences of using them. and if you are in the business of selling boxes that violate the design assumptions you shouldn't misrepresent these to your customers. True, however I think at least some of the customers are also to blame. In their haste to get on the Internet they went out and bought NAT boxes without understanding their limitations. I hear about this sort of thing even outside of the context of NAT, e.g. with people who have non-globally routable IP address blocks and don't understand why they can't reach certain sites. They then complain to their ISPs, who point out that their service does not guarantee global routing. --gregbo
Re: breaking the IP model (or not)
Greg Skinner wrote: My general (cynical) opinion of NAT and other proxy technology is that the marketplace spoke louder than the voices of the architectural purists. (No offense intended.) However, given recent changes in the economic climate, perhaps things will head in the opposite direction. Looks like the IPv6.com IPO is on hold until the market picks up .
Re: breaking the IP model (or not)
At 04:12 PM 4/10/00 -0400, Keith Moore wrote: it's completely natural that people will try such approaches - they are trying to address real problems and they want quick solutions to those problems. but if the quick fix solutions get entrenched then they cause their own set of problems which are worse then the original problems. this is not progress. IMHO we need to see these things for what they are: - quick fixes with limited applicability and future - indicators that there is an important problem that needs to be solved in a technically sound fashion Agreed completely ... but this still doesn't lead to your conclusion. Suppose we had suppressed every kludge that's come up since we started working on a new Internet design as a group? Let me see, ROAD gave their report, where they recommended CLNP, in Santa Fe, right? That was (let me look at the back of my shirt a second ...) in 1991. OK, OK, I'm being a bit extreme but the point is that just because something is architecturally bad doesn't mean you shouldn't do it, since these days it takes us years to make any architectural enhancements. Peter Deutsch is right: let the work go forward and *in addition* be sure you document very well what its limitations are. Stick that documentation in the same RFCs whenever possible. ...Scott __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: breaking the IP model (or not)
I'm being a bit extreme but the point is that just because something is architecturally bad doesn't mean you shouldn't do it, since these days it takes us years to make any architectural enhancements. perhaps architectural impurity alone shouldn't keep you from doing something, but the fact that something violates fundamental design assumptions should cause you to do some analysis and hard thinking about the likely consequences of using them. and if you are in the business of selling boxes that violate the design assumptions you shouldn't misrepresent these to your customers. most of these hacks can be employed in ways that are mostly harmless, but knowing when they are harmless and when they will cause harm can be quite difficult. NATs seemed mostly harmless when they were first deployed; now they're a huge problem. Keith
Re: breaking the IP model (or not)
--- Keith Moore [EMAIL PROTECTED] wrote: I'm being a bit extreme but the point is that just because something is architecturally bad doesn't mean you shouldn't do it, since these days it takes us years to make any architectural enhancements. perhaps architectural impurity alone shouldn't keep you from doing something, but the fact that something violates fundamental design assumptions should cause you to do some analysis and hard thinking about the likely consequences of using them. and if you are in the business of selling boxes that violate the design assumptions you shouldn't misrepresent these to your customers. most of these hacks can be employed in ways that are mostly harmless, but knowing when they are harmless and when they will cause harm can be quite difficult. NATs seemed mostly harmless when they were first deployed; now they're a huge problem. Hmm... Depends on one's perspective. Do not underestimate the timeliness of a solution. Timeliness is operational reality. It could have been catastrphic had we not had a timely solution with no addresses to issue. NAT is the reason we have had this much time to work on IPng. Keith regards, suresh = __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
Re: breaking the IP model (or not)
Hmm... Depends on one's perspective. Do not underestimate the timeliness of a solution. Timeliness is operational reality. I'm very much aware of this. timelinesss is what gives you (or denies you) the opportunity to deploy a new technology. but just because something is timely (in the sense that there is an opportunity to deploy it) does not mean that deploying it leaves the world in a better place. It could have been catastrphic had we not had a timely solution with no addresses to issue. NAT is the reason we have had this much time to work on IPng. it's not at all clear whether NAT provided additional time for IPng development or whether such time was really needed. IPv6 was largely developed before NAT enjoyed significant deployment, and arguably NAT has delayed adoption of IPv6. and because of the NAT deployment it is now somewhat "untimely" to deploy applications like IP telephony. whereas if IPv6 had been adopted a bit earlier (because NAT had not filled the vacuum, so to speak) IP telephony would work just fine with it. of course, IPv6 might have moved along slowly even without NAT. but it would probably have moved faster had NATs not existed. best thing I can say about NAT is that it motivated me to work on 6to4. Keith
Re: breaking the IP model (or not)
At 01:27 PM 4/12/00 -0400, Keith Moore wrote: I'm being a bit extreme but the point is that just because something is architecturally bad doesn't mean you shouldn't do it, since these days it takes us years to make any architectural enhancements. perhaps architectural impurity alone shouldn't keep you from doing something, but the fact that something violates fundamental design assumptions should cause you to do some analysis and hard thinking about the likely consequences of using them. Yes. So why don't we have a new design which decouples all the meanings for an IP "address"? and if you are in the business of selling boxes that violate the design assumptions you shouldn't misrepresent these to your customers. Sounds like we have some agreement on the list. most of these hacks can be employed in ways that are mostly harmless, but knowing when they are harmless and when they will cause harm can be quite difficult. There is precedent for the IESG getting draft authors to include caveats and limitations. NATs seemed mostly harmless when they were first deployed; now they're a huge problem. Just wait until mobile IP-based "phones" take off! ...Scott __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: breaking the IP model (or not)
On Wed, 12 Apr 2000 17:02:28 PDT, Pyda Srisuresh said: --- Keith Moore [EMAIL PROTECTED] wrote: can be quite difficult. NATs seemed mostly harmless when they were first deployed; now they're a huge problem. Hmm... Depends on one's perspective. Do not underestimate the timeliness of a solution. Timeliness is operational reality. I think Keith meant "huge problem" in the same sense that a kidney dialysis machine is a huge problem. They keep the patient alive, but never in the greatest of health or comfort. Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: breaking the IP model (or not)
it's completely natural that people will try such approaches - they are trying to address real problems and they want quick solutions to those problems. In particular, they will try such approaches if they are not presented with better alternatives. there's something odd to my ear about people needing to *be presented* with better alternatives than doing harm to the architecture as opposed to those people *developing* better alternatives. I suspect there's something about the current economic climate that favors development of quick fixes over development of sane ones. but the apparent shortsightedness still bothers me. Keith
Re: breaking the IP model (or not)
It's much worse than that. In the End to End model, far too many of our problems require changing all the end systems to solve. However, that's extremely difficult to do, particularly as there is little or no incentive (the DCA/DISA had guns, and control of the IMPs in 1982/1983 to force the NCP-TCP/IP conversion - there is no equivalent agency today). Almost all of the pressure created by the growth of the Internet is on the network operators and their vendors (e.g. router vendors), rather than on the users and the end systems (and the end system vendors, e.g. PCs, Macs, Suns, etc). It's also bad that there is little or no integration of intermediate system vendors with end system vendors (or vice versa), because that results in insufficient sharing of information between those two industry segments. The IETF should be facilitating information exchange, but it isn't working as well as it should (otherwise we wouldn't have these problems, right?). So, with nearly all the pressure on the operators and the vendors that serve them, the "solutions" they come up with are necessarily pretty ugly hacks (e.g. NAT, TCP spoofing, Firewalls) because they have to deal with the reality that they can't change the end systems themselves, or require them to be changed. This is a structural problem. Until the situation changes, we're going to keep on seeing ugly hacks that do violence to the Internet architectural model deployed, marketed, touted as "solutions." an author of RFC 1627, Erik [EMAIL PROTECTED]
Re: breaking the IP model (or not)
It's also bad that there is little or no integration of intermediate system vendors with end system vendors (or vice versa), because that results in insufficient sharing of information between those two industry segments. The IETF should be facilitating information exchange, but it isn't working as well as it should (otherwise we wouldn't have these problems, right?). it's not clear that the problems are caused by lack of information exchange, given time-to-market pressures that cause folks to ship product now and deny causing problems later.
RE: breaking the IP model (or not)
it's completely natural that people will try such approaches - they are trying to address real problems and they want quick solutions to those problems. In particular, they will try such approaches if they are not presented with better alternatives. but if the quick fix solutions get entrenched then they cause their own set of problems which are worse then the original problems. this is not progress. Progress is created by the development of solutions that do not cause their own set of problems. This does not happen merely by condemning other less desirable solutions. It happens by presenting a better alternative. - indicators that there is an important problem that needs to be solved in a technically sound fashion If this mail thread is any indication, I'd say the indicator is shining brightly.
