Summary

  • RFC 2043 defined two separately negotiated SNA Network Control Protocols on PPP: 0x804B controlled the LLC 802.2 path carried as 0x004B, while 0x804D controlled the HPR NLP path carried as 0x004D.
  • Reaching Opened meant that PPP could carry the corresponding envelope. With no SNACP configuration options and no security discussion, it did not prove the other envelope, recovery outcome, identity, authorization, delivery, deployment or a successful SNA session.

The easy operational sentence is “SNA is open.” The accurate sentence is longer: a particular SNA Network Control Protocol has reached the state in which PPP may carry one particular kind of SNA packet.

That extra precision is the historical object inside RFC 2043. Published in October 1996, the memo did not invent a general bridge between the Internet and IBM enterprise networking. It specified how PPP distinguished two SNA paths that happened to share a point-to-point link. The distinction lived in protocol numbers, independent control automata and different packet envelopes. It did not live in a single Boolean called SNA.

The link came first; the network permissions came later

PPP already had a layered lifecycle. RFC 1661 separated a physical link becoming usable, LCP establishing and configuring the data-link connection, optional authentication and link-quality work, and the later Network-Layer Protocol phase. Only in that last phase did each network-layer family use its own NCP.

This order matters because a live carrier is not a network-layer result. LCP's Opened state says the shared PPP link has completed its control exchange. It does not say that IP, SNA or any other carried family is ready. RFC 1661 therefore allowed each NCP to open and close independently. Packets for a supported network-layer protocol arriving while its corresponding NCP was not open had to be silently discarded.

RFC 2043 inserted SNA into that architecture, then divided it again. It said explicitly that there were “actually two” SNA NCPs: one for SNA over LLC 802.2, another for SNA without LLC 802.2. They were negotiated separately and independently. The shared cable and shared PPP phase were necessary context, not authority to merge their state.

Four numbers describe two control/data pairs

The numbers make the separation visible. PPP reserved the lower range containing 0x004B and 0x004D for network-layer packets, and the 0x8*** range containing 0x804B and 0x804D for associated NCP traffic. RFC 1700 recorded all four values before RFC 2043 was published; the present IANA PPP registry still names them and cites the memo.

The first pair is the LLC-bearing path. Control packets for SNA over LLC 802.2 use 0x804B. After that NCP is open, 0x004B frames carry exactly one SNA XID or FID2 Path Information Unit behind LLC fields: destination service access point, source service access point, control and LLC information.

The second pair is the direct HPR path. Its control packets use 0x804D. Its data packets use 0x004D and contain exactly one High Performance Routing Network Layer Packet, represented by its network header, transport header and data. No LLC fields sit in that envelope.

These are not redundant spellings of the same permission. If the 0x804B NCP is open, an operator may infer that PPP is allowed to carry the 0x004B envelope. Nothing in that fact opens 0x804D, and nothing in an open 0x804D authorizes 0x004B. A monitoring system that reports only “SNACP open” has thrown away the discriminating evidence.

Recovery belonged to one path, and even there it was not a verdict

RFC 2043 gave the LLC wrapper an explicit job. LLC(2) was included for link-level error recovery, performed by routers at the two ends of the PPP link. That allocation is operationally important: recovery was not an invisible property of the cable, and it was not delegated to an application beyond the routers.

But placement of responsibility is not proof of result. A 0x004B observation shows that an LLC-bearing SNA unit was presented in that envelope. It does not show that retransmission occurred, that recovery completed, that the far router accepted the PIU, or that a half-session processed its Basic Information Unit.

The HPR form makes the contrast sharper. 0x004D carries an NLP without the LLC wrapper. RFC 2043 nevertheless noted an architectural possibility: an implementation with the optional HPR link-level error-recovery tower could carry HPR NLPs over the LLC path and use 0x004B. That possibility concerns an implementation choice. It does not fuse the two NCPs or let one open state stand in for the other.

An optionless negotiation makes a narrow promise

SNACP reused the LCP exchange mechanism with a restricted code set: Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject. Yet the memo declared that there were no Configuration Options for either SNA form.

This is the most revealing limitation in the specification. The exchange can converge on whether the fixed protocol family is enabled. It carries no option that negotiates an SNA identity, an application profile, a recovery target, a security property, a route, a transaction guarantee or business readiness. A Configure-Ack cannot acknowledge information that the request never carried.

The word Opened must therefore stay attached to its automaton. It means the peer exchange has reached the state that allows the corresponding Network-Layer Protocol packets. It does not mean “SNA worked” in the broad sense that an operations dashboard, incident review or service owner might care about.

Security and identity remained outside the memo

RFC 2043's Security Considerations section is one sentence: security issues are not discussed. That is not a hidden assurance. It is a boundary.

PPP itself could perform authentication before the Network-Layer Protocol phase, but RFC 1661 made authentication optional by default. Even where a separate authentication exchange had succeeded, the evidence would need to identify the method, peer and result. An open SNA NCP is not a substitute for those records. Nor does it prove authorization inside SNA, confidentiality on the link, integrity beyond whatever other mechanisms were configured, or the identity of an application endpoint.

The maximum packet length illustrates the same restraint. RFC 2043 tied an SNA packet's maximum length to the PPP Information field; RFC 1661 described that ceiling as the MRU, defaulting to 1500 octets unless negotiated otherwise. The size boundary proves what can fit in the carrier. It says nothing about what the receiver did with the contents.

A small protocol with a durable evidentiary lesson

RFC 2200 listed PPP-SNACP as Elective in 1997. RFC 3790 later observed that the specification had no IPv4 dependency. The current IANA registry preserves its four assignments. Those records establish publication status, architectural independence from an IP version and present registry identity. They are not an adoption survey.

No named deployment, implementation test, traffic measurement or business outcome follows from them. The RFC Editor currently lists no errata for RFC 2043; that describes the errata database, not the perfection or prevalence of the protocol.

Read through Heng Lu's distinction between specification and running reality, RFC 2043 offers a disciplined miniature. The common rule was thin: identify the envelope, run the appropriate control exchange, and refuse supported traffic until its NCP opened. Decisions about implementation, recovery behavior, security and use remained elsewhere. Publication described a compatibility option. Only implementation, observation and reliance could establish operational reality.

That is why the correct historical sentence keeps four clauses apart: the PPP link reached the Network-Layer Protocol phase; one named SNACP reached Opened; a packet with the matching data Protocol value was carried; and separate evidence showed what happened next. Remove any clause and the record becomes less useful. Collapse them all into “the session was up” and the record becomes false.

Sources