On Oct 25, 2010, at 1:44 PM, Chris Engel wrote: > What Fred is talking about here sounds a whole heck of alot like the > philosophy behind the OSI model that I was taught some 20 years ago or > so..... The idea that higher level applications shouldn't neccesarly dictate > choices far lower in the Model. That's a vaulable thing, IMO.
ah yes. OSI worked so well.... > Now, I realize that reality is far different in practice then theory...but I > think efforts would be better spent improving reporting capabilities of > higher level naming schemes rather then mandating lower level protocol > choices. Going that route, a guy could be running IPX/SPX and your > application (in theory) would still be able to function. Fred likes to refer to reality...well, the reality is that lower level protocol choices do affect applications, in subtle and not-so-subtle ways. And it's all well and good in theory to say that applications should be agile enough to tolerate differences in lower protocol choices (like TCP vs. SCTP, say, or IPv4 vs IPv6, or NAT vs. no NAT. What that means in practice is that you want applications to not have a predictable environment in which to operate. And that is simply unacceptable. The people who keep wanting to impose arbitrary brain damage onto apps are the ones who need to "get over it". You can make an Internet without NATs. You can't get there from here without some fairly disruptive changes in how routing is done, but it can be done. You can also make an Internet with NATs as an explicit part of the architecture, though I think it's suboptimal. What doesn't work is to try to make an Internet where the NATs aren't explicit - where applications are expected to work in the presence of NATs that they don't interact with directly and which try to guess what the applications need. So you have the applications second-guessing the NATs and the NATs second-guessing the apps. And that's exactly where we are heading, and we're heading that way because of a failure to make an architectural decision about direction. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
