On Wed, Apr 30, 2003 at 03:09:22PM -0400, Ofer Inbar wrote:
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
[Tony Hain writes:]
What many are missing here is that this is not about 1918 style
addressing. This is about the fact that addresses do not have the same
visibility and accessibility throughout the network.
no, it's not just about that. you are the only one who keeps insisting
that. you seem to be trying to conflate two different notions of scope.
For what it's worth, I've been watching this discussion for a while,
not as a proponent of any particular side, and I completely agree with
Keith on this point. I've seen Tony Hain repeatedly make the assertion
that this discussion is about the fact that not all addresses can be
reached from everywhere, or that we don't have a "flat routing space",
or any number of related restatements... but I have seen nothing other
than Tony's assertions that would make me think this dicussion is
about any of those things. It puzzles me that he keeps repeating them.
Tony, *why* do you think this discussion is about reachability?
Everyone else: Do any of you believe that's what this is about, aside
from Tony's assertions and peoples responses to those assertions?
I certainly agree that it's all about ambiguous addresses and not about
about reachability. And it's why I have to agree with Keith that Site
Local addresses are a bad idea, and why ditching them is absolutely
the right thing.
Perhaps if we were doing things all over again, we would have two
entirely different addresses; one which is appropriate for identifying
the end-point, and which would be used by the IP layer and up (i.e.,
IP, TCP/UDP), and application level protocols, and another address
which is used for the purpose of routing the packet from one location
to another, and which would be used by the IP layer and below.
Hmm.... why does this remind me of the 8+8 proposal? Shear
coincidence, I sure. :-)
Anyway, for better or for worse, we don't have two separate addresses,
and protocols above and below the IP layer have been using the single
IP address for multiple different things. As some have pointed out,
one can consider TCP as using the IP address as an end-point
identifier, which means that we can't renumber without breaking the
TCP connection. So if we say that applications are "broken" when they
use IP addresses in this fashion, such that NAT's need to know about
the about the low-level details about the protocol when they perform
their charming man-in-the-middle attack^H^H^H^^H^H^H^Hpacket rewriting
function, this applies as much to TCP as it does to FTP.
For whatever reason that I've not been able to understand we've
decided not to do the architecturally clean thing and either used two
fixed-length addresses, one for routing and one for end-point
identifications, *or* required that TCP connections store and utilize
DNS names in TCP headers in order to specify the source and
destination end-points. That way, NAT boxes wouldn't need to modify
TCP (psuedo-) headers and TCP checksums when they did their magic.
But given that we've not decided to go down this path, we have to live
with the consequences of our using a perhaps "unclean" architecture.
It means that applications should avoid trying to using IP addresses
when it can't, but at the same time, routing folks can't claim that
the IP address is only a routing entity and that no other assumptions
of the IP addresses should ever be used by applications. For better
or for worse, applications need a reliable end-point identifier, and
while IP addresses aren't perfect, DNS names are not appropriate for
various reasons either. So applications and end users will continue
to muddle along, and that's just life in the big, muddled, "unclean",
city.
- Ted