On Wed, Apr 30, 2003 at 03:09:22PM -0400, Ofer Inbar wrote: > Keith Moore <moore@cs.utk.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