[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] arguments for map and encap




On May 22, 2008, at 1:06 PM, Christian Vogt wrote:

It's true that there has been a historical assumption that "an address
is 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 layer
as long as you deliver that bitstring. In the real world, we can't change
that (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 to
their limitations in global host reachability and robustness to path
changes. The mere fact that an address looks different on different sides
of a NAT is much easier to deal with.

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.

- 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