I'm not really qualified to talk about how tag data access is done because I'm not a software developer. Probably Archie Jacobs could describe the process in detail. But the topic has come up, so here are some (non-exhaustive, simplified) comments.
It's easy to focus on the addressing syntax and forget that most automation protocols start with a "Service".
Like in Modbus... you're "reading register 40001" but really the protocol is sending a request to "execute service code 0x03, Offset 1, length 1".
It's the same principle in ControlLogix. The client software or communications driver needs to send a Service code along with the Class/Instance/Attribute address data, and any arguments or data payloads that go with it.
The NetBiter doesn't seem to provide a place to specify the Service Code by name or by number; it just has Class, Instance and Attribute. When that's all you see, it usually means that only the services Read Attribute Single and Write Attribute Single have been implemented.
Those are great for simple devices. In an AC drive, for example, Class 0x0F is the Parameter Class. The Instance number is the Parameter number, and the actual value of the parameter is Attribute 1.
A lot of third party devices make use of Class 0x64, the "Vendor Defined" object, and use it in a similar way where parameter "P0001" is Class 0x64, Instance 0x01, Attribute 0x01.
The ControlLogix tag database is too complex and flexible to be represented by a simple object like that.
Instead, you have to send a service like "Data Table Read", along with the Class, Instance, and Attribute for an 'ANSI Symbolic Identifier' and the data payload with that symbolic identifier, aka the Tag Name.
The RSLogix 5000 Data Access Manual (1756-PM020) is the published and supported reference manual for using CIP to perform these services.
I haven't even touched on the unconnected message manager object, the session registration protocol, the multiple service group code, or the physical memory optimization method.