Summary

  • DRAP replaced a workstation-per-DLSw-peer pattern with many lightweight clients behind one server and one central DLSw peer connection.
  • The server assigned or cached MAC addresses, answered reachability probes, negotiated capabilities, created session identifiers and could preserve circuits while TCP was suspended.
  • None of those operational signals proved a person’s identity, authorization, authentic provenance or end-to-end delivery; RFC 2106 specified no authentication and was Informational, not an Internet Standard.

One backbone peer, many edge clients

The most revealing sentence in RFC 2106 is not a packet definition. It is the scaling complaint that came before the packet definitions. A remote workstation could run Data Link Switching itself, but then the number of TCP sessions toward the central site grew with the number of workstations. A switch-to-switch protocol was being pushed all the way to individual endpoints.

The Data Link Switching Remote Access Protocol, or DRAP, changed the topology. Workstations became clients of a nearby DRAP server. That server, rather than every workstation, maintained the DLSw peer relationship toward the central router. Many edge attachments could therefore share one backbone-facing relationship. Complexity did not disappear; it moved into a gateway that accumulated state on behalf of the clients.

This is the article’s boundary. RFC 1434 addressed two local LLC links sharing a transport; RFC 2024 exposed DLSw directory, cache, transport and circuit state through a MIB; RFC 2043 separated two PPP SNA admissions; RFC 2097 projected NetBIOS names into an admission procedure. RFC 2106 did something else: it made a router-side server the operational memory and speaking authority for remote workstations.

A virtual MAC was a routing instrument

A workstation attached through PPP might have an IP address but no LAN MAC address. DRAP let the server allocate a virtual MAC. If the client supplied a nonzero address, the server checked whether it was already in use and cached it. For server-initiated sessions, a client could preregister its MAC and IP so the server knew where to reconnect.

That mechanism was useful, but its meaning was narrower than the familiar word “identity” suggests. The MAC selected an endpoint within the protocol’s operating model. It did not establish which human controlled the workstation, whether the user was entitled to reach an application, or whether the registration came from an authentic source. The server’s cache was an operational claim store, not an identity authority.

The same discipline applies to server selection. A client configured with several server addresses could send requests to all of them and use the first server that replied. First response was a liveness and timing result. It was not a proof that the responder was the right administrative authority.

Protocol state was evidence of a transition

DRAP’s message vocabulary is unusually good at showing how much meaning operators can accidentally place on small signals. CAN_U_REACH asked whether the server could reach a target; I_CAN_REACH reported the server’s answer. START_DL requested a link station; DL_STARTED said that the server had created one. Origin and receiver session identifiers distinguished circuits. Capability exchange established details such as the client MAC, NetBIOS support, SAP lists and whether the client could listen for a new TCP connection.

Each message proved something specific. A positive reachability response showed that the server was willing to assert a path. A started-link response showed that a local protocol transition had succeeded. A session identifier named state inside the relationship. None demonstrated application delivery, authorized use, or provenance beyond the party generating the message.

The transport boundary was equally subtle. RFC 2106 used one bidirectional TCP connection per client-server pair on port 1973. A close-peer operation could suspend that TCP connection while leaving data-link circuits intact. When new user data appeared, the client could reconnect without repeating capability exchange. Optional keepalives tested whether the peer still answered; after three missed responses, the recommended action was to close TCP and the circuits.

This separation was operationally elegant. It also made “connected” a layered statement. A TCP socket could be absent while a circuit remained logically alive. A keepalive could prove responsiveness without proving that a transaction reached its intended application. The protocol’s state machine was not confused about those distinctions; later readers must not be either.

An Informational snapshot, not consensus by deployment

RFC 2106 was published in February 1997 as Informational and explicitly said it did not specify an Internet Standard. It described no authentication mechanism and offered no Security Considerations section. That absence should be read historically and literally: the document specified a remote-access adaptation and its state transitions, not an identity or authorization architecture.

RFC 2114 obsoleted it in the same month, renamed the scheme Data Link Switching Client Access Protocol and added discovery options while retaining the central client/server idea. The rapid succession matters. A registered port, an interoperable implementation or an RFC number can make a system operable and discoverable. None alone proves durable standards consensus.

Sources