Winsock

Reaching Opened means the link exists. It does not mean you have an address, and the page now goes on to the three steps that follow. What is genuinely modelled is each protocol's own decision: PAP and CHAP are computed rather than acted out, IPCP's four packets are produced by a peer holding a pool rather than replayed from a script, and TCP's transitions are looked up in figure 6. What is not modelled is anything between the layers. There is no timing, no retransmission, no MTU, and no traffic at all once the connection is open. The subject is how each layer decided it was ready, not what it then carried.

RFC 1661 prints the table as plain text in two blocks, and its columns stop lining up when a cell is wider than its column. Splitting a row on whitespace merges two cells of the RCR+ row, where "sta/2" and "irc,scr,sca/8" are separated by a single space. Slicing at the header positions cuts the Close row in the wrong places for the same reason. What this page does instead is take each cell as a token by its shape and require every row to produce exactly one cell per state, which is a check the other two methods fail loudly rather than quietly getting wrong. The test parses the archived RFC and compares all hundred and sixty cells.

There is no clock here. The Timeout events are things you press, not things that happen after a Restart timer expires, because a page that made you wait three seconds for each retransmission would be teaching patience rather than protocol. The counter that the actions Initialize-Restart-Count and Zero-Restart-Count move is real and is shown; the timer that would decrement it is not modelled.

The difference between RCR+ and RCR- is whether the options the other end asked for were acceptable, and deciding that is real work: maximum receive unit, authentication protocol, magic number, and the rest of section 6. In the LCP panel you pick which of the two events arrived, and the decision behind it is not modelled. One layer up it is: the IPCP panel actually holds a pool of addresses, decides whether the one you asked for is in it, and Naks with one that is. That is the option negotiation this page owes you, done for the option that mattered most.

CHAP's response is a genuine MD5 over the identifier, the secret and the challenge, in that order, computed in the page. It is written out because SubtleCrypto does not offer MD5 and is right not to. It is checked three ways before anything is shown: against the five vectors printed in RFC 1321's own appendix A.5, against a different implementation over four hundred inputs, and at every length either side of a 64-byte block boundary, which is the only place a hand-written MD5 tends to go wrong. Nothing on this site authenticates anything, and MD5 has been unfit for that purpose since the 1990s.

RFC 1994 says the challenge value must change every time it is sent, and here it does. It is not unpredictable, though: it comes from a small generator with a fixed seed, so the same page gives the same run twice. That is deliberate. A demonstration you cannot repeat is one nobody can check, including the test suite. A real authenticator needs the value to be unguessable as well as different, and this one only manages different.

The eleven states and nineteen arrows are transcribed from figure 6, and the RFC is explicit that the picture is partial: it “illustrates only state changes, together with the causing events and resulting actions, but addresses neither error conditions nor actions which are not connected with state changes”. So a state and event the figure does not join is refused here rather than guessed at, and the page says which. One real consequence: the simultaneous close, where both ends send FIN at once and FIN-WAIT-1 goes straight to TIME-WAIT, is not in figure 6 and is not here. Also missing, because they are not state changes: sequence numbers, windows, retransmission, and everything else TCP is actually for. And RFC 793 itself is no longer the current specification: RFC 9293 replaced it in August 2022, consolidating four decades of corrections. It keeps this diagram. So “unchanged since” on this page is a claim about the eleven states and nineteen arrows, not about the document around them, which has been rewritten.

165.113.59.201 is not anybody's, and the pool has two addresses in it because that is enough to show a Nak. The mechanism around them is the RFC's: you send a Configure-Request naming 0.0.0.0, and the peer “can provide this information by NAKing the option, and returning a valid IP-address”. The count of packets, and the fact that a refusal is how you got an answer, are real. The numbers inside them are furniture.

Winsock is the API a Windows application called to use a socket, and its specification is a separate document from this one. It was not reachable when this page was built: it is not on bitsavers, the current vendor documentation is modern developer material rather than the Windows Sockets 1.1 specification of January 1993, which is the version this era ran, and the archive that most likely holds it was refusing automated requests. So this page is named for the thing people installed and models what that thing was doing, rather than pretending to document an interface nobody here has read. If the specification turns up, the honest move is a second machine and not a quiet expansion of this one.