This is why I've been trying to stay out of it. > > So how to think about it? First, it's *not* NAT, because > > there's no address translation going on. > > I know. I understood this after the discussions of the past few days.
Yet you're still contending the following: > What I pointed out to Anant Narayanan was that his proposed _new_ > capability which involved _packet analysis_ would _have to_ operate on > network layer data units, ergo, NAT again. > > Packet analysis == Network layer operations ~= NAT That's not correct. NAT is network address translation. It implicitly requires that IP headers be rewritten, and when doing port translation as well, the TCP header must also be rewritten. It is a technique that allows machines with non-routable addresses to talk outside the local network. Hence the need for translating addresses. Importing /net doesn't involve any translation of addresses. In fact, as Erik pointed out, the machine on the local network might not even be talking TCP/IP at all! The "packet analysis" that appears to have arisen from a discussion of load balancing is a red herring. NAT is not a technique for load balancing. RFC1631 is where NAT is described. If you're not rewriting the IP header, then it's not NAT, it's not approximately NAT, it has no similarity to NAT at all. > Because packet is the name for specific data units, entities at network > layer. Above it you have datagrams (UDP) or streams (TCP), below it you > have frames. It is true that I wasn't particularly pedantic with my terms, but if we're going to be pedantic, we might as well get it right. RFC791 defines IP and the proper terminology associated with it. Comer does an excellent job distilling the RFCs and phrases it this way: "The internet calls its basic transfer unit an _Internet datagram_, sometimes referred to as an _IP datagram_ or merely a _datagram_." You can find the definition of UDP in RFC768. Again Comer's phrasing: "Each UDP message is called a _user datagram_." Finally, read RFC793 for the details on TCP. Comer's phrasing is "The unit of transfer between the TCP software on two machines is called a _segment_." Comer's definition of a packet is also instructive: "The unit of data sent across a packet switching network. The term is used loosely. While some TCP/IP literature uses it to refer specifically to data sent across a physical network, other literature views an entire TCP/IP internet as a packet switching network and describes IP datagrams as packets." (BTW the reason I've chosen to use Comer's phrasing is that his book arose as a result of an IETF meeting where even some of the attendees didn't understand how it all worked--at least that's the story I heard when I was at Purdue.) > > The OSI protocols are largely forgotten for a reason. > > It's not bad as a conceptual model, but as soon as you > > try to force any predefined definitions of layers on real > > networks, you soon lose your grip on sanity. > > There are rather clearly-defined boundaries in TCP/IP, too. Without the > layered design approach one would lose one's sanity, not with it. Of course TCP/IP has layers. Indeed layering can be seen in most good designs. It is especially natural in network stacks because of the encapsulation of messages. For that matter, I doubt any student of mine has ever gotten away without hearing me say something about the value of layering; I even mentioned it in my book. And it's true that we sometimes are a bit loose with the terms and allow ourselves to use OSI terminology when talking about TCP/IP. However, you can't take that usage too literally, and certainly can't base an argument on that usage. The layers in the two just don't line up exactly. The division of responsibilities among the layers is different between TCP/IP and OSI. For that matter, they don't even have the same number of layers. The luxury I have in this situation is that because you're not my student, I don't have any obligation to make sure you've understood it all. But if you were my student, my first recommendation would be to read *and understand* the RFCs, and the best way to know that you've understood them is to write some network protocol code. If you would like to have help understanding something, I, and I'm sure others here, would be happy to answer if you present your questions as questions. I don't plan to answer any more incorrect assertions. BLS
