Topic
Software Lifecycle and Lock-in
Within the Topic facet, Software Lifecycle and Lock-in topic intelligence connects articles that share a specific subject, signal focus, or monitoring theme. The page gives readers a richer path through related reporting, source evidence, market actors, and infrastructure implications, with enough context to understand why the topic matters across company movements, governance decisions, regional exposure, and operational risk. Readers can compare recurring signals, affected organisations, public evidence, market context, service continuity, procurement, competition, compliance, and strategic planning questions behind the subject instead of stopping at a thin list of matching articles. It explains what the topic covers, which infrastructure actors or policies are involved, what evidence supports the coverage, and why the subject may matter for operators, customers, investors, and policy readers.
History
The Two Flags That Took Up Space: Why TCP Counts SYN and FIN
TCP numbers bytes, yet two control events also advance its sequence space. SYN stands before the first data octet and FIN stands after the last, giving connection opening and closing the same acknowledgment and retransmission protection as the stream without turning either flag…
History
The Push That Was Never a Message Boundary: TCP's PSH Flag
An application asks TCP to push a buffer because waiting for later data could stall the exchange. TCP marks the last segment it creates from that buffer with PSH. Yet the mark does not turn that segment into a message: the sender's write, the packets on the wire, the receiver's…
History
The Connection One Side Forgot: TCP's Half-Open Reset
A TCP connection can look alive from one endpoint and already be gone from the other. The classic specifications called that split a half-open connection. Their recovery examples turn the next packet into a test of shared memory: sequence expectations collide, a reset makes the…
Global Institutional Trends
Who controls the clock when ISC software has a vulnerability?
Internet Systems Consortium’s authority over supported BIND and Kea releases is real, but it is not the authority of a regulator or a universal command centre. It is stewardship power: the ability to concentrate information, coordinate disclosure, produce an official remediation…
History
When Both Sides Knocked at Once: TCP's Simultaneous Open
The standard picture of TCP begins with a client knocking and a server listening. The protocol itself has never required that casting. Its original 1981 specification described what happens when two endpoints knock at once: their SYN segments cross, each side becomes both…
History
The Host That Had to Wait Before Speaking: TCP's Quiet Time After Restart
A restarted machine may look clean precisely because it has forgotten too much. TCP's original quiet-time rule addressed that paradox: if a host lost the sequence numbers used before a crash, it was told to emit nothing for one maximum segment lifetime. Silence was not a repair…
History
The Reset That Ended Waiting Too Soon: TCP's TIME-WAIT Assassination Hazard
TIME-WAIT looks passive: a closed connection remains in a table while a clock runs down. In 1992, RFC 1337 showed that the state could be destroyed by active protocol behavior. One old segment provoked an acknowledgment; that acknowledgment provoked a reset; the reset erased the…
History
The Deadline That Was Not a Retransmission Timer: TCP User Timeout
TCP can decide to retransmit a segment and still decide, on a different clock, that the connection has waited too long. The first decision schedules another attempt. The second ends the connection. RFC 5482 made that persistence preference visible to a peer without turning it…
History
The Offer That Was Not a Negotiation: How TCP MSS Bounded Each Direction
Each side of a TCP connection can place a four-byte option in its opening SYN. The number does not settle a shared packet size. It says how much TCP data the option's sender is prepared to receive in one segment—a directional boundary that the other endpoint must combine with…
History
The Handshake That Had to Remember Its Previous Handshake: How RFC 5746 Bound TLS Renegotiation
A TLS handshake could authenticate its own conclusion while saying nothing cryptographic about the bytes that came before it on the same connection. RFC 5746 repaired that gap by requiring every renegotiation to carry evidence from the immediately previous handshake.
History
The Neighbor That Stayed in the Cache After It Became Unreachable: How RFC 7048 Separated Failover from Forgetting
IPv6 Neighbor Discovery once treated the last unanswered unicast probe as both a warning to seek another path and a reason to erase the path it already knew. RFC 7048 split those decisions: a neighbor could become officially unreachable without its final link-layer address being…
History
The Address That Spoke Before It Was Proven Unique: How Optimistic DAD Bounded Early Use
A newly attached IPv6 host used to wait for a uniqueness test before speaking. RFC 4429 shortened that silence without pretending the test had already passed: the address could carry traffic, but not yet exercise the Neighbor Discovery powers of an uncontested owner.
IETF
The Insecure Middle of a Secure TACACS+ Migration: RFC 9887 and the Cost of Dual-Stack Authentication
A TACACS+ client using TLS must not fall back to non-TLS when TLS negotiation fails. Yet a migration can temporarily keep separate non-TLS TACACS+ servers for devices that cannot move at once. That coexistence is not a secure dual stack: RFC 9887 considers the mixed phase…
CASE FILE
The Notification Arrived. One Backend Still Had Nothing to Serve
The IETF is asking for final comments on a proposed operating guide for RPKI publication services. Its sharpest rule is also the easiest to violate during a routine rollout: do not expose the new notification until every snapshot and delta it names is already available. An index…
CASE FILE
The Candidate Path Reached BGP. The Forwarding Plane Had Not Voted: RFC 9830
A controller advertises two Segment Routing candidate paths to a headend. Both arrive over valid BGP sessions. One wins BGP's comparison for its advertisement; the other remains a distinct route because its Distinguisher differs. Neither fact says which candidate the SR Policy…
History
The Header Described an Archive. It Did Not Authorize the Decoder to Run It: RFC 1505
The line counts agree. The archive expands. The checksum closes. A shell command now waits in a directory created from an email message. In 1993, RFC 1505 drew the most important boundary at exactly this point: successful decoding was not permission to execute.
CASE FILE
The Challenge Released the Message. It Still Had Not Reached the List
The IETF plans to replace the machinery behind its email services on 11 September. The design usefully separates challenges, list handling, identity rewriting, signing and outbound transport. It also makes the central operating question unavoidable: when one component reports…
CASE FILE
The CRL Number Was Higher. RPKI Still Had to Ignore It: RFC 9829
A relying party retrieves two signed revocation lists from one publication point. The first carries the larger CRL Number. The second is the file named by the certificate and hashed on the issuer’s current manifest. A generic PKI instinct says to trust the larger counter. RFC…
History
The Router Saw a New Network. It Was a Shadow of Its Own Mapping: RFC 1504
The route looked newly learned and the number was locally valid. The awkward fact was that no second network had appeared. A number invented at one translation boundary had travelled around a redundant path, lost its lineage and returned as if it belonged to a stranger.
History
The Key That Could Change Mid-Connection: TCP-AO's Rollover Signal
Long-lived routing sessions made a simple operational question unusually dangerous: how can two endpoints replace an authentication key without dropping the TCP connection or guessing the same switching instant? TCP-AO answered with visible key identifiers and directional…