On Fri, Jun 11, 2010 at 1:37 PM, Chris Grundemann <cgrundem...@gmail.com> wrote: > Although I have been lurking here for some time, I am a newcomer to > this group and to IETF participation in general so please forgive my > naivety but this search for solid terminology reminds me of something > I am told that Jon Postel once said: > > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." > > I have always found that statement to be a great summary of how the > Internet works in the simplest terms possible.
Hi Chris, That's a great summary of how things were supposed to be. It's not such a great description of how things are. At work a run a ground system tied to a satellite service. IP addresses for the servers are anycasted from two locations 5000 miles apart. They're backended by a server cluster spread between those two sites. Each server in the cluster has the same IP address. A load balancer/tunnelling apparatus is used to divvy up the packets between the cluster servers and move the packets between sites back out across the Internet when the selected backend server is not local. In this scenario the address no longer describes "where" the servers are except in a very fuzzy sense. The address certainly doesn't describe the host or interface sought. But it very accurately describes a set of services sought, with each address tied to a different cluster providing that specific set of services. More generally, the address gets used in the following processes that have nothing to do with "where" the address is located: node identification - an address is often used to uniquely identify a particular computer on the network. As a result, the computer retains the same address when it moves instead of acquiring a new address. application identification - as in my ground station example above, an address can be tied to a particular service, rerouting to find that service on any machine capable of providing it that is still online. The route still indicates how to get to it but the address identifies the service, not so much where the service is located. authentication - The human being users identified by the IP addresses I designate may access. You may not. Maybe at my network border. Maybe in my server's .htaccess file. No comment about the security efficacy - just noting that it gets used this way. packet association - in TCP, the connection ID is composed of the source and destination IP addresses plus the source and destination ports. The network stack uses the IP addresses in this scenario both to associate incoming packets with the connection to which they belong and to select the identity of the other host to which packets should be returned, regardless of that other host's movement within the network. Should that either endpoint in a TCP conversation present a different IP address (because they're no longer where they used to be), that TCP connection is dead. Regards, Bill Herrin -- William D. Herrin ................ her...@dirtside.com b...@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
