[41399] in North American Network Operators' Group
RE: end2end? (was: RE: Where NAT disenfranchises the end-user ...)
daemon@ATHENA.MIT.EDU (Tony Hain)
Fri Sep 7 19:10:55 2001
Reply-To: <alh-ietf@tndh.net>
From: "Tony Hain" <alh-ietf@tndh.net>
To: "steve uurtamo" <uurtamo@arttoday.com>, <nanog@merit.edu>
Date: Fri, 7 Sep 2001 16:10:12 -0700
Message-ID: <IEEOIFENFHDKFJFILDAHMEDKDBAA.alh-ietf@tndh.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20010907151307.A6061@ofc-204.arttoday.com>
Errors-To: owner-nanog-outgoing@merit.edu
steve uurtamo wrote:
> when you write a protocol, regardless of the application, that tries
> to make requirements _in the data portion_ about how the remote side
> should write its _header portion_, you really are asking for trouble.
Explain how to build a protocol for the following:
A -|
|-Nat-<>-C
B -|
A wants to tell C how to contact B for a multi-party app.=20
A 'knows' the address of B, so why should it require C to=20
take several seconds to look it up by name? Even if C were
to look up the name, it would map back to A as far as C is
concerned, so C might not go into multi-party mode because
it has one name and single matching locator.
> NAT !=3D evil, so let's try to be a little bit more evenhanded=20
> about this.
NAT is just a technology, so your statement is arguably=20
true. As long as the end user has elected NAT as the tool=20
for solving the current problem, he accepts the associated
drawbacks. The evilness appears when humans get involved
and NAT is forced on the end user. This could either=20
explicitly, or (to be truly evil) unannounced by the service=20
provider, while at the same time claiming that they are=20
selling Internet service. (This is the point that started=20
the original thread)
> and the understanding that if there are such restrictions,=20
> it might be a little while (i.e. until all NAT implementations=20
> everywhere plug in a handler for the new protocol in question)=20
> before all networks in the world are going to be able to pass=20
> their packets around with ease and zen-like harmony. =20
> is that really so much to ask? =20
Actually it is. It is equivalent to insisting that my PI
prefix be distributed globally. From an end user perspective
there is no reason a little pain on the ISPs part should=20
prevent me from having continuous connectivity through
full prefix announcement multi-homing. Yet ISPs are=20
fat-&-happy pointing out that developers should never=20
require a protocol to carry locator information in the=20
data stream. There are reasons to do it, so it is=20
incumbent on the service providers that enforce NAT to be
straight with their customers about the fact the service
is not full capability transparent Internet access.
Tony
