WIRED INFRACOM // Internetworked binary

<-- Return to index

"Internetworked binary master protocol"

TCP/IP ports: 86, 686, 8686, 18686, 28686, 38686, 48686
UDP/IP ports: 87, 687, 8687, 18687, 28687, 38687, 48687

Background

There are many thousands of different layer 7 protocols built atop both TCP and UDP. Due to the incidence of contrast between the IETF's four-layer IP suite and the now-ubiquitous seven-layer OSI model, port assignment tends to correspond to a specific application, even though this is not the most effective way to do port allocation. While this presents less generic abstraction at the outset to application protocol designers, it is prone to inefficiencies as protcols are developed from scratch on top of general purpose layer 4 protocols which are only distinguished by their transport reliability constraints.

Design & purpose

The Internetworked binary master protocol, shortened and stylised to ib, proposes six (6) general-purpose layer 7 protocols, each providing a category of communication architecture to specific applications. Simplifying this state of affairs presents two advantages: (1) application protocol developers can choose whichever of these six protocols according to their needs, being provided a robust communication model, and (2) it greatly reduces the multiplicity of engineering currently present in the grandfathered four-layer IP Suite based allocation of IP ports.

Basic protocol structure

ib structures its transmission into 508-octet packets for both TCP and UDP. ib packets are structured like so:

Offset Size Explanation $0000 8 Session ID $0008 4 Metadata bitfield (see below) $000C 496 Payload

The subprotocol bitfield is structured like so:

Bit Explanation 0-2 Version number. Must be zero (0) 3-5 Subprotocol number (0=HELO, 1=PTP, 2=TTP, 3=PRP, 4=PSP, 5=AP, 6=IAP, 7=prohibited) 6-31 Packet sequence ID

1. In the HELO subprotocol, the session ID is simply set by the initiating party in the first packet and is maintained by both parties until the HELO is complete and the connection changes to another subprotocol.
2. For other subprotocol sessions, the session ID (among other details) is set in the payload of the HELO that set them up.
3. ib packet sequence IDs start at zero at the beginning of a session and are incremented by one with eventual integer overflow back to zero.
4. Packet sequence IDs are only assumed to be related if the rest of the packet sans the payload is identical.
   • Consequently, if any other bits of the bitfield are changed or if the session ID changes, either it is an unrelated session or an error condition, depending on the context.
5. It is always an error condition if:
   1. the version number is higher than the application can support,
   2. if any reserved bits are nonzero,
   3. the subprotocol number is 7 (this is currently prohibited),
   4. if the session ID is zero, or
   5. if the subprotocol number changes while the session ID remains the same.

HELO & subprotocol setup

While the specifics of this still need to be hashed out, suffice to say that the HELO protocol will, in a nutshell:

1. Establish a cryptographically secure channel over an otherwise clear medium of transmission, similar to SSL
2. That secure channel will be vetted using a hybrid security model: a hierarchical Web of Trust
3. The secure channel will be used to decide the subprotocol to transition to, as well as the session ID it will use upon transition

Subprotocol summaries

More concretely, ib provides these six communication protocols to achieve the communication styles of various existing protocols such as IMAP and HTTP, but in a generalised way that stamps out duplication of the communication architecture.

Persistent Transmission Protocol

Main page: ib-PTP - Persistent Transmission Protocol

The Persistent Transmission Protocol, or ib-PTP, provides sustained bidirectional transmission of data for highly interactive or high-volume protocols like video streaming and SSH. It fosters the familiar client-server architecture so ubiquitous already on the Web.

Transactional Transmission Protocol

Main page: ib-TTP - Transactional Transmission Protocol

The Transactional Transmission Protocol, or ib-TTP, provides one-and-done style bidirectional transmission of data for protocols like HTTP and FTP. It fosters the familiar client-server architecture like ib-PTP.

Polling Retrieval Protocol

Main page: ib-PRP - Polling Retrieval Protocol

The Polling Retrieval Protocol, or ib-PRP, provides polling-oriented data retrieval and synchronisation mechanisms similar to POP3 or IMAP. It is also suitable to provide for the fetching of subscription material as in RSS or Atom.

Polling Syndication Protocol

Main page: ib-PSP - Polling Syndication Protocol

The Polling Syndication Protocol, or ib-PSP, provides for publishing and bidirectional syndication of data in a polling-oriented fashion alongside ib-PRP, similar to SMTP or ActivityPub's inter-server provisions.

Aggregation Protocol

Main page: ib-AP - Aggregation Protocol

The Aggregation Protocol, or ib-AP, provides mechanisms for comprehensively aggregating data of a similar structure from various sources across the Web. This protocol is functionally analogous to a distributed ledger protocol, since it amasses a computational consensus in a decentralised way from countless sources in a low-trust fashion.

Ident-Auth Protocol

Main page: ib-IAP - Ident-Auth Protocol

The Ident-Auth Protocol, or ib-IAP, provides for identifying the author of some data or the authenticity of a network location for the purposes of establishing a limited basis of trust. It is functionally similar to OpenPGP in that it provides a Web of Trust model, but also like SSL/TLS in that it promotes hierarchy to help foster usability for people who have not already accrued trust within the system.