RFC 1498

On the Naming and Binding of Network Destinations 🎀

okay bestie, this one is from RFC 1498, published in August 1993 🌸. The author is J. Saltzer from the M.I.T. Laboratory for Computer Science 🧚. It's informational, which means it provides information for the Internet community. It doesn't specify an Internet standard 💅. The title block doesn't list anything it obsoletes or updates ✨.

Status of this Memo ✨

okay so the status section says this memo provides information for the Internet community. It does not specify an Internet standard, and distribution of the memo is unlimited 🦋.

Abstract 🦋

this paper is a whole perspective on how we name destinations in data communication networks 🫶. It has two big ideas. First, it's super helpful to tell apart four different kinds of objects that can be named as the destination of a packet in a network 👑. Second, the operating system concept of binding is a really useful way to describe how those four kinds of objects relate to each other 🔥. To show why this approach is so good, the paper uses it to explain some of the more subtle and confusing properties of two real-world network systems for naming destinations 💖.

Note 📜

this part is a little legal-ish but it matters 🙈. The document was first published in "Local Computer Networks", edited by P. Ravasio et al., by North-Holland Publishing Company, Amsterdam, 1982, pp. 311-317. Copyright IFIP, 1982 🌈. IFIP grants permission for reproduction for non-commercial purposes. You can copy it without a fee as long as the copies are not made or distributed for commercial advantage, the IFIP copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of IFIP. Copying any other way, or republishing, needs a specific permission 💅.

This research was supported in part by the Defense Advanced Research Projects Agency of the United States Government, and it was monitored by the Office of Naval Research under contract number N00014-75-C-0661 ⭐.

What is the Problem? 💭

okay so, even after John Shoch [1] tried really hard to bring some order to the way people talk about names, addresses, and routes to destinations in computer networks, these discussions are still way more confusing than they should be 😭. Sometimes the confusion comes from tying network objects too tightly to the most common form of their names 🙈. It also happens because people try to talk about the issues without enough well-defined concepts on hand 💀. This paper takes a different route to build insight, by applying a perspective that has already been super helpful in the matching area of computer operating systems 🧚.

Operating systems have the same confusion problem with names and addresses ✨. There are file names, unique identifiers, virtual and real memory addresses, page numbers, block numbers, I/O channel addresses, disk track addresses, and a seemingly endless list 🌀. But most of that confusion has been made harmless for a long time now, by realizing that the concept of binding gives you a systematic way to think about naming [2]. (Shoch pointed out this chance to use the operating system concept, and this paper makes it the central theme 🎀.) In operating systems it was obvious very early on that there were too many different kinds of identifiers, so you don't get much insight from trying to separate names from addresses alone 💅. It's more useful to look at all identifiers as examples of one single phenomenon, and to ask instead "where is the context in which a binding for this name (or address, or indentifier, or whatever) will be found?", and "to what object, identified by what kind of name, is it therein bound?" 🦋 And this same approach works just as well in data communications networks 🫶.

To start, let's look at Shoch's suggested terminology in its broadest form 🍓:

• a name identifies what you want,
• an address identifies where it is, and
• an route identifies a way to get there.

there's no need to change these definitions 💜, but you'll see they leave a lot of room for interpretation 🙈. Shoch's suggestion implies there are three abstract concepts that together give you an intellectual cover for discussion ✨. In this paper, we propose that a more mechanical view might lead to a set of concepts that's easier to think with 👑. This more mechanical view starts by listing the kinds of things you find in a communication network 🔥.

Types of Network Destinations, and Bindings Among Them ✨

okay bestie, picture a data network 🌐. when you're figuring out where a packet is headed, there are a few kinds of things that come in lots of copies, so you gotta give each one a name to tell them apart 💅. four of these show up literally everywhere:

1. Service and Users. these are the functions people use, plus the clients that use them 🫶. examples of services are one that tells the time of day, one that does accounting, or one that forwards packets. an example of a client is some particular desktop computer 🖥️.
2. Nodes. these are computers that can run services or user programs ✨. some nodes are clients of the network, and others help run the network by running forwarding services. (we don't need to tell these two kinds of nodes apart 🙈)
3. Network attachment points. these are the ports of a network, the spots where a node plugs in 🔌. in lots of network talk, the word "address" is an identifier for a network attachment point.
4. Paths. these run between network attachment points, going through forwarding nodes and communication links 🛤️.

ok so that's the list! this first step, listing and describing the objects we're talking about, is borrowed from the world of abstract data types 🧚. our second step is making two observations about naming network objects: one about form and one about bindings 💜.

First, you are totally free to pick whatever form of name feels helpful, like binary identifiers, printable character strings, or whatever 🎀. they can come from a flat name space or a hierarchical one. one type of object can even have more than one form of name. a node might have both a hierarchical character string name AND a unique binary identifier 🌸.

there are also two semantic traps here, and they're sneaky 🙈. trap one: in the network world, "name" usually means a printable character string, while "address" usually means a machine-interpretable binary string. in the world of systems and languages, people use "print name" for the first and "machine name" or "address" for the second, and "name" broadly covers both. (in this paper we're using the broad meaning of "name".) trap two: assuming some conventional form of name is a property of a particular type of object. like, services might be named by character strings, nodes by unique IDs, and network attachment points by hierarchical addresses. when one person assumes a name form always goes with a type and another person doesn't, the conversation gets SO puzzling for everybody 😭.

---

the second observation about those four types of network objects is that most naming requirements in a network can be described super concisely in terms of bindings, and changes of bindings, among them 🦋. the three big ones are:

1. A given service can run at one or more nodes, and it might need to move from one node to another without losing its identity as a service.
2. A given node can be connected to one or more network attachment points, and it might need to move from one attachment point to another without losing its identity as a node.
3. A given pair of attachment points can be connected by one or more paths, and those paths might need to change over time without affecting the identity of the attachment points.

(this summary is intentionally brief! an excellent in-depth review of these requirements is in a recent paper by Sunshine [3] 📚.)

each of these three requirements is about preserving identity, whether it's the identity of a service, a node, or an attachment point 💖. to preserve an identity, the name used to identify it can't change during those moves. if you keep the associations among services, nodes, attachment points, and routes as lists of bindings, you can totally hit this goal ✨. whether all that flexibility belongs in a particular network design is an engineering judgment call 🧠. a judgment that some binding can be made at design time and will never change (say, a particular service always runs on a particular node) shouldn't confuse the question of what names and bindings are in principle present 🙅.

in principle, to send a data packet to a service, you have to discover three bindings:

1. find a node on which the required service operates,
2. find a network attachment point to which that node is connected,
3. find a path from this attachment point to that attachment point.

and there are three conceptually distinct binding services the network needs to provide 🧩:

1. Service name resolution, to identify the nodes that run the service.
2. Node name location, to identify the attachment points that reach the nodes found in step 1.
3. Route service, to identify the paths that lead from the requestor's attachment point to the ones found in step 2.

at each level of binding there can be several alternatives, so you have to choose which node, which attachment point, and which path 🔀. these choices are distinct, but they can interact! for example, you might choose the node only after looking over the various paths leading to the possible choices 🛣️. in that case the network tables might only produce a partial binding, which means a query gives you a list of answers instead of just one 📋. the final binding choice can get delayed until the very last moment and recorded outside the three binding services the network provides ⏳.

---

🚨 bindings are sneaky, and designers fall for this one ALL the time. there's a very important subtlety here, so pay attention!

say we've recorded in a network table that the "Lockheed DIALOG Service" is running on node 5. three different bindings are involved, but only one of them is recorded in this table and changeable just by adjusting it 🔍.

1. the name "Lockheed DIALOG Service" is properly associated with a specific service, management, and collection of stored files 📁. nobody usually reassigns a name like that to a different service. the association is pretty permanent, and that permanence means it isn't usually written down in a single, easily changed table.
2. similarly, the name 5 is assigned to a particular node on a fairly long-term basis, without anyone expecting it to change 🔒. so that assignment isn't typically written in a single, easily changed table either.
3. the fact that "DIALOG" is running on node 5 right now is the one binding our table actually expresses, because we expect that association might reasonably change 🔁. the table exists so we can record changes like "DIALOG" now running on node 6, or the "Pipe-fitting Service" now running on node 5.

the design mistake is believing this table lets you give the Lockheed DIALOG service a new name just by editing this table entry 🙈. that is not what this table of bindings is for, and a name change is actually really hard to pull off, since the association usually isn't expressed as a binding in one table. you'd have to change not only this table, but also user programs, documentation, scribbled notes, and advertising copy 📝📣 💀.

Some Real-World Examples ✨

okay so everything we've covered so far sounds super straightforward, right? 💅 but it is SO easy to find real examples that make you go "wait, what does that even mean" 😭. take the Xerox/DEC/Intel Ethernet [5, 6]. there, the idea of a network attachment point is kinda elusive, bc it collapses right into the node name 🫠. a node can physically attach to an Ethernet anywhere along it. the node brings along a 48-bit unique identifier that its interface watches for in packets passing by. so you could argue this identifier should probably be thought of as the name of a network attachment point, even tho the physical point of attachment can be literally anywhere 🦋. but also, you can adopt a policy where the node supplies that 48-bit identifier from its own memory for the Ethernet interface to use. so a second view (which is likely what other parts of the network will assume when they interpret these identifiers) is that the 48-bit identifier IS the name of the node itself 👑. from a binding perspective, this way of using Ethernet binds the node name and the network attachment point name to be the same 48-bit unique identifier.

This permanent binding of node name to attachment point name has several network management advantages:

• a node can be moved from one physical location to another without changing any network records. 🚚
• one level of binding tables is omitted. this advantage is particularly noticeable in implementing internetwork routing. 🧚
• a node that is attached to two Ethernets can present the same attachment point name to both networks, which simplifies communication among internet routers and alternate path finding. 🌈

but permanent binding also produces a curiosity 🙈 if it happens that one wants one node to connect to two attachment points on the same Ethernet. the curiosity shows up because the only way to make the second attachment point independently addressable by others is to let the node use two different 48-bit identifiers. that means some other network records (the ones that interpret the ID to be a node name) will likely be fooled into believing there are not one, but two nodes 😵. to avoid this confusion, the same 48-bit identifier could be used in both attachment points, but then there will be no way to intentionally direct a message to one rather than the other. one way or another, the permanent binding of attachment point name to node name has made some function harder to accomplish, though the overall effect of the advantages probably outweighs the lost function in this case.

for another example, the ARPANET NCP protocol gives us character string names that look, from their mnemonics, like node names or service names. but in fact they are the names of network attachment points [6] 🤯. so the character string name RADC-Multics is the name of the network attachment point at ARPANET IMP 18, port 0. that means reattaching the node (a Honeywell 68/80 computer) to another network attachment point requires either that the users learn a new name for the service or else a change of tables in all other nodes. changing tables superficially looks like what rebinding is all about, but needing to change more than one table is the tip-off that something deeper is going on 👀. what's actually happening is the change of the permanent name of the network attachment point. we can see this more clearly by noting that a parallel attachment of that Honeywell 68/80 to a second ARPANET port would only be possible by assigning a second character string identity. this requirement really emphasizes that the name belongs to the attachment point, not the node 💅.

unfortunately, because of their mnemonic value, the ARPANET NCP name mnemonics are often thought of as service names. so one expects that the Rome Air Development Center Multics service is operated on the node reached by the name RADC-Multics. this particular assumption doesn't produce any surprises ✨. but any one of the four Digital PDP-10 computers at Bolt, Beranek and Newman can accept mail for any of the others, as can the groups of PDP-10's at the USC Information Sciences Institute, and at the Massachusetts Institute of Technology 🎀. if the node you try to send mail to is down, the customer has to realize the same service is available by asking for a different node, using what appears to be a different service name. the customer needs to realize he must give a different name to get the same service because in the ARPANET, the name isn't of a service bound to a node that's bound to an attachment point. it's directly the name of an attachment point. the whole vibe is "the name is the attachment point, periodt" 💀.

finally, confusion can arise because the three conceptually distinct binding services (service name resolution, node name location, and route dispensing) may not be mechanically distinct. there is usually only one identifiable service suggested, a "name server" 🧚‍♀️. the name server starts with a service name and returns a list of network attachment points that can provide that service. it thereby performs both the first and second conceptual binding services, though it may leave the final choice of which attachment point to use to the customer. path choice may be accomplished by a distributed routing algorithm that provides the final binding service without anyone noticing it 🫶.

---

Correspondence with Names, Addresses, and Routes

with this model of binding among services, nodes, network attachment points, and paths in mind 🧠, one possible interpretation of Shoch's names, addresses and routes goes like this:

1. any of the four kinds of objects (service, node, network attachment point, and path) may have a name, though Shoch would restrict that term to human-readable character strings 🏷️.
2. the address of an object is a name (in the broad sense, not Shoch's restricted sense) of the object it is bound to. so an address of a service is the name of some node that runs it. an address of a node is the name of some network attachment point it connects to. an address of a network attachment point (a concept not usually discussed) can be taken to be the name of a path that leads to it. this interpretation captures Shoch's meaning "An address indicates where it is," but it doesn't match very well with Shoch's other notion that an address is a machine-processable, rather than a human-processable, form of identification 🤖. this is probably the main point where our perspectives differ on which definitions give the most clarity.
3. a route is a more sophisticated concept 💖. a route to either a network attachment point or a node is just a path, the way we've been using the term. because a single node can run several services at once, a route to a service consists of a path to the network attachment point of a node that runs the service, plus some identification of which activity within that node runs the service (e.g., a "socket identifier" in the PUP internet [4] or the ARPA Internet [7] protocols). but note that a route may actually consist of a series of names, typically a list of forwarding name nodes or attachment points, plus the names the forwarding nodes use for the paths between them 🛤️.

whether or not you like this particular interpretation of Shoch's terms, it's clear there are more than three concepts involved, so more than three labels are needed to talk about them 🌸.

---

Summary

this paper argued that some insight into naming destinations in a network can come from recognizing four kinds of named objects at or leading to every destination (services, nodes, attachment points, and routes), and then identifying three successive, changeable, bindings (service to node, node to attachment point, and attachment point to route) 🦋. this perspective is modeled on analogous successive bindings in storage management systems (file--storage region--physical location) and virtual memories (object--segment--page--memory block). it provides a systematic explanation for some design problems encountered in network naming systems 👑.

Acknowledgements

discussions with David D. Clark, J. Noel Chiappa, David P. Reed, and Danny Cohen helped clarify the reasoning here 🫶. John F. Shoch provided both inspiration and detailed comments, but shouldn't be held responsible for the result 💜.

References

1. Shoch, John F., "Inter-Network Naming, Addressing, and Routing," IEEE Proc. COMPCON Fall 1978, pp. 72-79. Also in Thurber, K. (ed.), Tutorial: Distributed Processor Communication Architecture, IEEE Publ. #EHO 152-9, 1979, pp. 280-287.
2. Saltzer, J. H., "Naming and Binding of Objects", in: Operating Systems, Lecture notes in Computer Science, Vol. 60, Edited by R. Bayer, New York; Springer-Verlag, 1978.
3. Sunshine, Carl A., "Addressing Problems in Multi-Network Systems", to appear in Proc. IEEE INFOCOM 82, Las Vegas, Nevada, March 30 - April 1, 1982.
4. Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., "PUP: An Internetwork Architecture", IEEE Trans. on Comm. 28, 4 (April, 1980) pp. 612-623.
5. (Anonymous), "The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications, Version 1.0", published by Xerox Corp., Palo Alto, Calif., Intel Corp., Sunnyvale, Calif., and Digital Equipment Corp., Tewksbury, Mass., September 30, 1980.
6. Dalal, Y. K., and Printis, R. S., "48-bit Absolute Internet and Ethernet Host Numbers", Proc. Seventh Data Communications Symposium, Mexico City, Mexico, October 1981, pp. 240-245.
7. Feinler, E., and J. Postel, Editors, "ARPANET Protocol Handbook", SRI International, Menlo Park, Calif., January, 1978.

Security Considerations 🔐

security issues are not discussed in this memo. 💀 so if you were hoping for a security chapter, sorry bestie, this one's a no-show. please take that seriously and don't assume anything about security from the content here.

Author's Address

Jerome H. Saltzer
M.I.T. Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139
U.S.A.

Phone: (617) 253-6016
EMail: Saltzer@MIT.EDU