On May 22, 2008, at 1:06 PM, Christian Vogt wrote:
Except for traceability, fault isolation, etc., not to mention latency of state-reestablishment after a crash in the absence of an explicit control plane state establishment protocol, etc.It's true that there has been a historical assumption that "an addressis an address is an address" and that this has become the essential implement in applying the end-to-end principle (which was written down in 1984 [Saltzer] and resurrected in RFC 1958). Afaics, the essential requirement to apply the e2e principle is an identifier that asserts that a given packet belongs to a given packet stream. Given that, the end system doesn't care about any aspect of the network at all. But we can't avoid the fact that the identifier used by the vast majority of software is the bitstring known as an address in the socket API. You can do what you like below the transport layeras long as you deliver that bitstring. In the real world, we can't changethat (which is why NATs are such a mess, of course).Brian -I fully agree that both sender and receiver need a stable identifier for packet exchanges. But stability does not necessitate that the identifier be the same for the sender and for the receiver. NATs demonstrate this.Of course, I do understand yours and many other people's concerns about NATs. My stance, however, is that the hard problems with NATs are due totheir limitations in global host reachability and robustness to pathchanges. The mere fact that an address looks different on different sidesof a NAT is much easier to deal with.
- Christian
-- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg