1.4 Relationship to Other Protocols

  • Article

The SMB 2 Protocol can be negotiated by using an SMB negotiate, as specified in [MS-SMB] section 1.7. After a dialect of the SMB 2 Protocol is selected during negotiation, all messages that are sent on the connection (including the negotiate response) will be SMB 2 Protocol messages, as specified in this document, and no further SMB traffic will be exchanged on the connection.

For authentication, the SMB 2 Protocol relies on Simple and Protected GSS-API Negotiation (SPNEGO), as described in [MS-AUTHSOD] section 2.1.2.3.1 and specified in [RFC4178] and [MS-SPNG], which in turn can rely on the Kerberos Protocol Extensions (as specified in [MS-KILE]) or the NT LAN Manager (NTLM) Authentication Protocol (as specified in [MS-NLMP]).

The SMB 2 Protocol uses either TCP or NetBIOS over TCP as underlying transports. The SMB 3.x dialect family also supports the use of RDMA as a transport. SMB 3.1.1 dialect also supports QUIC as a transport as specified in [IETFDRAFT-QUIC-33].

Machines using the SMB 2 Protocol can use the Distributed File System (DFS): Referral Protocol as specified in [MS-DFSC] to resolve names from a namespace distributed across many servers and geographies into local names on specific file servers.

DFS clients communicate with DFS servers via referral requests/responses conveyed in SMB2 IOCTL messages, analogous to a file system client performing control operations on a remote object store via requests/responses conveyed in SMB2 IOCTL messages. The communication between the SMB2 server and the DFS server (or SMB2 server and object store), for the purpose of performing the specified IOCTL operations, is local to the server machine, and takes place via implementation-dependent means.

The Remote Procedure Call Protocol Extensions, as specified in [MS-RPCE], define an RPC over SMB Protocol or SMB 2 Protocol sequence that can use SMB 2 Protocol named pipes as its underlying transport. The selection of protocol is based on client behavior during negotiation, as specified in section 1.7.

Peer Content Caching and Retrieval framework, or Branch Cache as described in [MS-PCCRR], is designed to reduce bandwidth consumption on branch-office wide area network (WAN) links by having clients request Content from distributed caches. Content is uniquely identified by Content Information retrieved from the server through SMB 2 IOCTL messages, as specified in sections 3.2.4.20.7 and 3.3.5.15.7. This capability is not supported for the SMB 2.0.2 dialect.

Relationship to other protocols

Figure 2: Relationship to other protocols

The diagram shows the following:

  • [MS-RPCE] uses [MS-SMB2] named pipes as its underlying transport.

  • [MS-DFSC] uses [MS-SMB2] as its transport layer.

  • [MS-SRVS] calls [MS-SMB2] for file server management.

  • [MS-SMB2] calls [MS-SPNG] for authenticating the user.

  • [MS-SMB2] calls [MS-DFSC] to resolve names from a namespace.

  • [MS-SMB2] calls [MS-SRVS] for server management and for synchronizing information on shares, sessions, treeconnects, and file opens. The synchronization mechanism is dependent on the SMB2 server and the server service starting up and terminating at the same time.

  • [MS-SMB2] uses either TCP, NetBIOS over TCP, QUIC, or RDMA as underlying transports.