| Internet-Draft | Single-Stack 100/50 Principle | September 2026 |
| Sun | Expires 6 March 2027 | [Page] |
The Single-Stack 100/50 Principle defines two independent, formally derivable consequences of retiring the IPv4 protocol stack in a dual-stack (IPv4 + IPv6) network environment: (1) 100% elimination of executable attacks attributable to IPv4 under the document's definition, and (2) an exact 50% reduction in the count of concurrently exposed network-layer protocol-stack surfaces when IPv4 is retired, stated by the Principle as a minimum structural floor. The analysis is bounded to the functional Layer 3 scope and parameter universe U_3 defined in this document. Within that premise, Axiom 0 and Axioms 1-15 stipulate protocol independence, operational state transitions, traffic termination, addressing/routing domains, protocol-associated control and resolution functions, header-processing paths, and protocol-specific vulnerability execution. Theorem I follows by removal of the necessary IPv4 Layer 3 execution precondition for every IPv4-attributable attack. Theorem II follows by direct enumeration of two concurrently exposed protocol-stack surfaces before retirement and one after retirement. Neither theorem depends on empirical attack volume, incident frequency, or statistical inference, and neither theorem claims that IPv6 is inherently more secure than IPv4.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document formalizes two structural consequences of retiring IPv4 from a native dual-stack IPv4/IPv6 environment. The first concerns executability of attack vectors whose necessary execution path is IPv4. The second concerns the number of concurrently exposed IP-version-specific Layer 3 protocol-stack surfaces. Both results are definitional and structural; neither depends on empirical attack-volume measurement.¶
This revision expands the formal model while retaining the two independent denominators of the Single-Stack 100/50 Principle. The 100% clause concerns the defined class of executable IPv4-attributable attack vectors. The minimum 50% clause concerns the count of concurrently exposed network-layer protocol-stack surfaces. The document does not claim that IPv6 is inherently more secure than IPv4, nor does it claim a 50% reduction in attack traffic, incident count, financial loss, or total organizational risk.¶
This document defines no conformance requirements and uses no RFC 2119 or RFC 8174 key words.¶
To maintain mathematical and logical rigor, every definition, axiom, parameter, and derivation in this document is bounded to Layer 3 IP protocol mechanics and to the protocol-associated control/resolution functions expressly included in U_3 when they directly support Layer 3 forwarding. Layer 3 supplies network-layer addressing, packet-header processing, forwarding logic, and the IP delivery function between lower-layer connectivity and upper-layer transport [ISO7498-1]. This is a functional proof boundary. It does not assign every auxiliary mechanism (for example, ARP) to OSI Layer 3 as a matter of formal layer classification; only the protocol-associated function expressly defined in U_3 is admitted. No proposition outside that boundary is used as a proof premise.¶
Formal status of the axioms. Within the stipulated Layer 3/U_3 premise, Axiom 0 and Axioms 1-15 are definitional or structural premises used by the derivations. They are not empirical hypotheses and are not conditioned on observed attack traffic. Their applicability is limited to the native IP protocol mechanics and explicit parameters defined in U_3; implementation coupling or cross-layer behavior outside U_3 is not asserted away.¶
A network or host configuration in which both the IPv4 and IPv6 protocol stacks are concurrently active and reachable at Layer 3.¶
A network or host configuration in which only one network-layer protocol stack - IPv4 or IPv6 - is active and reachable at Layer 3.¶
For this document, one active and reachable IP-version-specific Layer 3 protocol-processing surface, treated as a complete independently addressable stack and characterized by its own addressing/routing domain, header format, packet-processing path, protocol-associated control/resolution functions, and protocol-specific vulnerability execution conditions.¶
Any attack vector whose execution requires IPv4 protocol mechanics at Layer 3. The defining test is necessity: if execution does not require an active and reachable IPv4 Layer 3 processing path, the vector is not IPv4-attributable for purposes of Theorem I.¶
The disabled or removed state of the identified protocol stack at Layer 3, such that no active processing path for that protocol remains within the network or host boundary to which the Principle is applied. If translation, tunneling, or another mechanism retains or reintroduces active IPv4 Layer 3 processing inside that same boundary, IPv4 is not retired there for purposes of Theorem I or Theorem II.¶
An IPv4-attributable attack can execute only if an active and reachable IPv4 Layer 3 protocol instance can receive and process the IPv4 protocol data unit needed by that attack. This necessary-condition relationship is the definitional basis of Theorem I. Theorem I addresses the Layer 3 execution prerequisite; it does not require an estimate of how frequently any attack is attempted.¶
Let U_3 denote the bounded Layer 3 parameter universe used by this document. U_3 comprises: (i) IPv4 and IPv6 enable/disable state; (ii) the traffic-flow consequence of each state; (iii) continuity of the remaining enabled protocol; (iv) protocol-specific addressing and routing lookup, including the IPv4 and IPv6 address domains A_4 and A_6 defined in Axiom 12; (v) protocol-specific control/resolution functions; (vi) protocol-specific header-parsing semantics; and (vii) protocol-specific vulnerability execution. Axiom 0 and Axioms 1-15 collectively state all domain-specific premises invoked for those parameters by Theorems I and II. 'Complete' therefore means proof-complete relative to U_3 and the stated premise: no additional unstated proposition concerning a parameter within U_3 is required for the derivations established in this document. It does not mean that the Internet, the OSI Reference Model, an implementation, or cybersecurity generally is a closed or completely enumerated system.¶
| Parameter category | Formal object / scope | Governing axiom(s) |
|---|---|---|
| Governing independence | Native IPv4/IPv6 logical separation within U_3 | Axiom 0 |
| Enable/disable state | (p_4,p_6) in {0,1}^2 | Axioms 1-7, 11 |
| Traffic-flow consequence | Protocol flow after state transition | Axioms 8-11 |
| Continuity of remaining protocol | Surviving stack's own Layer 3 mechanics | Axioms 5-7 |
| Addressing and routing lookup | Protocol-tagged domains A_4 and A_6 | Axiom 12 |
| Control/resolution functions | Protocol-associated control/resolution state | Axiom 13 |
| Header parsing | Version-specific header semantics | Axiom 14 |
| Vulnerability execution | Protocol-specific necessary execution path | Axiom 15 |
The axioms describe native IPv4 and IPv6 protocol mechanics within the selected host or network boundary. They do not assert that real implementations share no code, memory, CPU, configuration, application behavior, or failure modes. Shared-resource and cross-layer effects are outside U_3 unless they are expressly made part of a protocol-specific execution condition.¶
Likewise, Axioms 5-7 concern continuity of the remaining protocol's own Layer 3 mechanics; they do not claim preservation of end-to-end reachability to destinations that require the retired protocol. A translator, tunnel endpoint, compatibility mechanism, or other component that performs active IPv4 Layer 3 processing inside the selected boundary means the premise P_4 = 0 is not satisfied for that boundary.¶
In Dual-Stack Mode of Operations, using both IPv4 and IPv6, the moment the IPv4 stack is retired at Layer 3:¶
100% Elimination - 100% elimination of executable IPv4-attributable attack vectors within the defined Layer 3 scope because their necessary IPv4 processing condition is absent.¶
Minimum 50% Reduction - a minimum 50% reduction in the count of concurrently exposed network-layer attack surfaces: IPv4 + IPv6 becomes IPv6 only.¶
The two percentages have independent denominators. The 100% clause measures the defined set of IPv4-attributable attack vectors and whether they remain executable. The minimum 50% clause measures the count S of concurrently exposed Layer 3 protocol-stack surfaces. Neither percentage is derived from attack-volume statistics, and neither percentage asserts that IPv6 is inherently more secure than IPv4.¶
The axioms form one continuous stipulated premise for Theorems I and II. Axioms 1-11 enumerate operational state and traffic-flow consequences. Axioms 12-15 state the structural parameters used by the proofs. Each axiom is bounded by Section 1 and U_3. The word 'TRUE' in the confirmations below means true within those stipulations; it is not a claim about every implementation, cross-layer dependency, shared resource, or transition mechanism.¶
Within U_3, native IPv4 and IPv6 are logically distinct Layer 3 protocol instances. Each has its own address domain, header semantics, forwarding/control behavior, and protocol-specific processing path. The native specification and operation of one IP version do not require an active instance of the other. This axiom does not deny coexistence mechanisms, translation/tunneling, shared implementation resources, or application-level coupling outside U_3.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. RFC 791 and RFC 8200 specify different IP versions, address lengths, and header-processing rules; RFC 4213 describes dual IP layer operation as complete support for both protocol versions [RFC0791], [RFC8200], [RFC4213].¶
Enabling either native IPv4 or native IPv6 does not alter the protocol-specific Layer 3 mechanics of the other IP version within U_3.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. Enabling one stack does not change the other version's address-domain definition or header semantics. System-level preference or application-selection effects outside U_3 are not part of this axiom.¶
When both native IPv4 and IPv6 are enabled, each retains its own protocol-specific Layer 3 mechanics within U_3.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. RFC 4213 describes dual IP layer operation as complete implementations of both IP versions operating on the same node [RFC4213].¶
Enabling native IPv4 does not alter the protocol-specific IPv6 Layer 3 mechanics defined in U_3.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. IPv4 activation does not redefine IPv6 addressing, IPv6 header semantics, or the IPv6 protocol-specific processing path.¶
Enabling native IPv6 does not alter the protocol-specific IPv4 Layer 3 mechanics defined in U_3.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. IPv6 activation does not redefine IPv4 addressing, IPv4 header semantics, or the IPv4 protocol-specific processing path.¶
Disabling either IPv4 or IPv6 does not remove or alter the remaining protocol stack's own Layer 3 mechanics within U_3.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. Removing Stack A leaves Stack B's protocol-specific processing path intact. This does not claim continued reachability to destinations that require Stack A.¶
Retiring IPv4 preserves the IPv6 stack's own Layer 3 mechanics within U_3.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. IPv6 addressing, header processing, ICMPv6, and IPv6 forwarding remain defined and operable independently of an active IPv4 stack. Reachability to IPv4-only destinations is outside the claim.¶
Retiring IPv6 preserves the IPv4 stack's own Layer 3 mechanics within U_3.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. IPv4 addressing, header processing, ICMPv4, and IPv4 forwarding remain defined and operable independently of an active IPv6 stack. Reachability to IPv6-only destinations is outside the claim.¶
Within the selected boundary, disabling either IP version terminates packet processing and Layer 3 traffic on the protocol that has been disabled or removed.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. The active Layer 3 parsing and processing path for that protocol is absent within the selected boundary.¶
Within the selected boundary, retiring IPv4 terminates IPv4 Layer 3 packet processing and IPv4 traffic through that retired path.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. Zero IPv4 PDUs are processed by an active IPv4 Layer 3 instance within the boundary because no such instance remains.¶
Within the selected boundary, retiring IPv6 terminates IPv6 Layer 3 packet processing and IPv6 traffic through that retired path.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. Zero IPv6 PDUs are processed by an active IPv6 Layer 3 instance within the boundary because no such instance remains.¶
Within the selected boundary, retiring both IPv4 and IPv6 terminates all native IP Layer 3 processing for both protocol versions; no IPv4- or IPv6-based IP delivery path remains there.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. Native IP Layer 3 processing for both versions is absent, while lower-layer connectivity may still physically exist.¶
An IPv4 addressing/routing lookup is evaluated over the IPv4 address domain, while an IPv6 addressing/routing lookup is evaluated over the IPv6 address domain. With the protocol tag included in the formal objects, the two domains are disjoint and a lookup in one domain is not a lookup in the other.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. Define A_4 = {(4,x): x in {0,1}^32} and A_6 = {(6,y): y in {0,1}^128}. The protocol tag makes A_4 intersect A_6 = {} by definition. A_4 and A_6 are address domains referenced by U_3; they are not asserted to be subsets of the parameter universe itself.¶
Protocol-associated control and resolution functions for IPv4 and IPv6 are logically distinct within U_3. For Ethernet-based address resolution, ARP serves IPv4 address-to-link-layer mapping, whereas IPv6 uses ICMPv6 Neighbor Discovery; a protocol-specific state transition in one does not, by definition, constitute a state transition in the other.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. ARP and IPv6 Neighbor Discovery are separately specified mechanisms [RFC0826], [RFC4861]. ARP is included here only as a protocol-associated resolution function supporting IPv4 Layer 3 forwarding; its formal OSI layer classification is not a proof premise.¶
Under the standards-defined semantics, an IPv4 header is not a valid IPv6 header and an IPv6 header is not a valid IPv4 header. The version-specific parsing semantics are logically disjoint within U_3, even if a particular implementation shares code or hardware resources between the two parsing paths.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. RFC 791 and RFC 8200 define distinct version-specific header formats and processing semantics [RFC0791], [RFC8200].¶
A vulnerability is protocol-specific within U_3 only when its necessary execution condition lies in a version-specific protocol-processing path. An IPv4-specific malformed-packet or header-processing exploit cannot execute through the IPv6-specific path merely because IPv6 remains enabled. A vulnerability in shared code, shared memory, a common driver, or an upper/lower layer is not classified as protocol-specific by this axiom unless its execution still requires the retired IPv4 Layer 3 path.¶
Formal confirmation: TRUE within the stated Layer 3/U_3 premise. By definition, the stipulated vulnerability condition and its necessary execution path are confined to the protocol-specific routine represented in U_3; shared-implementation vulnerabilities that do not satisfy that necessity test are outside the axiom.¶
For the two-protocol binary state vector (p_4,p_6) in {0,1}^2, the complete joint state set is {(0,0),(1,0),(0,1),(1,1)}. Axioms 1-4 govern enabling and coexistence; Axioms 5-7 govern preservation of the remaining protocol's own Layer 3 mechanics after disabling; and Axioms 8-11 govern traffic termination for the disabled protocol or protocols. These axioms enumerate every state and every traffic consequence admitted by the binary-state parameters in U_3.¶
Axioms 12-15 enumerate the structural parameter categories used by the proofs: address/routing domain, protocol-associated control and resolution functions, header-parsing semantics, and protocol-specific vulnerability execution. Together with Axiom 0, and as mapped in Section 1.3, they provide the complete structural premise required by Theorems I and II within U_3. No additional domain-specific premise external to U_3 is invoked as a proof premise; ordinary rules of logic, set notation, and arithmetic remain the mathematical framework in which the derivations are expressed.¶
When IPv4 is retired, the active IPv4 Layer 3 protocol instance is absent within the network or host boundary to which the Principle is applied. Layer 2 may still receive and identify a frame carrying an IPv4 payload, but no active IPv4 Layer 3 state machine exists within that boundary to accept and process the IPv4 PDU. The deterministic consequence relevant to this document is failure of IPv4 Layer 3 processing and, consequently, failure of delivery through an IPv4 path. This section assumes the retirement boundary defined in Section 2.1 and excludes mechanisms that reintroduce active IPv4 processing inside that boundary.¶
| Step | Layer interaction | Deterministic consequence within the premise |
|---|---|---|
| 1 | Physical and data-link ingress | Signals may be received and framed at Layers 1-2. |
| 2 | Protocol identification | The payload is identified as IPv4, such as by EtherType 0x0800 on Ethernet. |
| 3 | Layer 3 handoff | No active IPv4 Layer 3 protocol instance exists to accept and process the IPv4 PDU. |
| 4 | Processing termination | The IPv4 PDU is rejected or discarded before IPv4 Layer 3 processing and cannot be delivered upward through an IPv4 path. |
Zero IPv4 parsing by an active IPv4 stack. No active IPv4 Layer 3 parser executes the IPv4 header or its IPv4-specific fields.¶
Zero IPv4 processing. No active IPv4 Layer 3 state machine performs IPv4 forwarding, ICMPv4 handling, fragmentation/reassembly, or other IPv4 protocol mechanics.¶
Zero IPv4-path upper-layer delivery. The payload cannot reach Layer 4 or higher through the retired IPv4 Layer 3 path. IPv6 delivery remains governed separately by Axiom 6.¶
Theorem I is grounded in the definition of IPv4-Attributable Attack, Axiom 0, Axioms 8-9, and Axioms 14-15. It is a necessary-condition proof: every member of the defined attack class requires the active IPv4 Layer 3 processing path that retirement removes.¶
Let P_4 = 1 mean that the applicable IPv4 Layer 3 protocol instance is active and reachable, and let P_4 = 0 mean that it is retired. Let C_4 be the set of IPv4-attributable attack vectors under Section 2.1. For every a in C_4:¶
Exec(a) => P_4 = 1. (1)
IPv4 retirement gives:¶
P_4 = 0. (2)
Therefore, by contraposition of the defining necessity relation:¶
For all a in C_4: not Exec(a). (3)
Accordingly, the post-retirement executable set is:¶
E_4,post = {a in C_4 : Exec(a)} = empty set. (4)
Let E_4,pre subseteq C_4 denote any nonempty pre-retirement set of executable IPv4-attributable attack vectors. Then:¶
Elimination Rate = (|E_4,pre| - |E_4,post|) / |E_4,pre|
= 1 = 100%. (5)
Theorem I - 100% Elimination. Within the defined retirement boundary, retiring the IPv4 Layer 3 protocol stack renders every attack vector in C_4 non-executable because the necessary IPv4 Layer 3 execution condition is absent. If the pre-retirement executable set E_4,pre is nonempty, its elimination rate is 100%. Q.E.D.¶
Theorem II is grounded in the Network-Layer Attack Surface definition, Axiom 0, Axiom 6, and Axioms 12-15. It counts concurrently exposed Layer 3 protocol-stack surfaces as defined in Section 2.1. The derivation is structural and does not weight the stacks by traffic volume, exploit count, or incident frequency.¶
Let S denote the number of concurrently active and reachable Network-Layer Attack Surfaces under the document's definition.¶
S(dual-stack) = |{IPv4, IPv6}| = 2. (6)
S(IPv4 retired) = |{IPv6}| = 1. (7)
Structural reduction = (2 - 1) / 2 = 0.5 = 50%. (8)
The two-to-one count establishes an exact 50% reduction in S. The Principle states this exact result as a minimum structural floor because S deliberately counts only complete protocol-stack surfaces. IPv4 retirement may also remove coexistence, transition, or other IPv4-specific sub-surfaces, but no additional reduction is required for Theorem II and no additional percentage is quantified here.¶
Theorem II - Minimum 50% Reduction. Retiring IPv4 from a dual-stack Layer 3 environment reduces S, the count of concurrently exposed Network-Layer Attack Surfaces, from two to one. The reduction in S is exactly 50%; the Principle states that exact stack-count result as its minimum structural floor. Q.E.D.¶
| Dimension | Theorem I - 100% | Theorem II - Minimum 50% |
|---|---|---|
| Quantity measured | Executable IPv4-attributable attack vectors (C_4) | Concurrently exposed network-layer protocol-stack surfaces (S) |
| Controlling basis | Definition plus Axioms 0, 8-9, and 14-15 | Definition plus Axioms 0, 6, and 12-15 |
| Derivation | Removal of a necessary execution precondition | Direct enumeration: 2 -> 1 |
| Empirical data required? | No | No |
| Formal result | Post-retirement executable set is empty; 100% elimination rate when E_4,pre is nonempty | S: 2 -> 1 = exact 50%; stated as minimum structural floor |
| Separate empirical question | Attempt frequency, attacker substitution, or attacks not requiring IPv4 | Change in attack traffic, incidents, financial loss, or measured organizational risk |
Theorems I and II are definitional and structural. Their admissible propositions are confined to U_3 and the functional Layer 3 meanings fixed in Section 2. The document does not use empirical attack volume, incident totals, or attacker reallocation behavior as proof premises. Those observations may be studied separately, but they neither establish nor negate the two formal results.¶
Theorem I does not claim elimination of attacks that do not require the retired IPv4 Layer 3 processing path.¶
Theorem II does not claim a specific percentage change in attack traffic, incident count, exploit attempts, financial loss, or total organizational risk.¶
The Principle does not claim that IPv6 is inherently more secure than IPv4; the surviving IPv6 stack still requires independent security engineering.¶
The term Network-Layer Attack Surface is used only as expressly defined in this document: one active and reachable IP-version-specific Layer 3 protocol-stack surface.¶
Shared-code, shared-memory, driver, application-layer, and other cross-layer vulnerabilities are outside the protocol-specific claim unless their execution requires the retired IPv4 path.¶
A translator, tunnel endpoint, compatibility mechanism, or other component that performs active IPv4 Layer 3 processing inside the selected boundary means IPv4 is not retired there under the document's definition.¶
Axioms 5-7 do not promise continued access to IPv4-only or IPv6-only destinations after the corresponding protocol is retired; they concern continuity of the remaining stack's own Layer 3 mechanics.¶
The truth status and completeness of Axiom 0 and Axioms 1-15 are relative to the stipulated premise and U_3; they do not assert completeness of an implementation or of cybersecurity generally.¶
The formal premise is anchored to the OSI Basic Reference Model and the protocol specifications for IPv4, IPv6, dual IP layer operation, IPv4 address resolution, and IPv6 Neighbor Discovery. RFC 4213 expressly describes dual IP layer operation as complete support for both IPv4 and IPv6 and notes that either stack may be disabled for operational reasons [RFC4213]. RFC 7381 and RFC 9099 independently observe that dual-stack operation requires security treatment for both protocol versions and creates additional exposure/management complexity [RFC9099], [RFC7381]. Those standards provide corroborating architectural context; the mathematical results in Theorems I and II still follow from the document's definitions, axioms, and enumeration rather than from those external statements.¶
This document specifies no new packet format, protocol mechanism, configuration requirement, or implementable behavior and therefore introduces no new protocol attack surface of its own.¶
The Single-Stack 100/50 Principle does not assert that IPv6 is inherently more secure than IPv4. The surviving IPv6 stack remains subject to IPv6-specific security considerations and requires independent security engineering. Operational security considerations for IPv6 networks are discussed in [RFC9099].¶
The formal results apply only when the retirement boundary is actually satisfied. If translation, tunneling, compatibility processing, or another mechanism retains or reintroduces active IPv4 Layer 3 processing inside the selected boundary, the premise P_4 = 0 is not satisfied there. Likewise, shared-code or cross-layer vulnerabilities that do not require the retired IPv4 path are outside Theorem I.¶
This document has no IANA actions.¶
The Single-Stack 100/50 Principle establishes two definitionally independent results of IPv4 retirement within a defined dual-stack Layer 3 boundary. First, retirement removes the necessary IPv4 Layer 3 execution condition for every IPv4-attributable attack vector in C_4, rendering the defined class non-executable; when the pre-retirement executable set is nonempty, the elimination rate is 100%. Second, the count S of concurrently exposed network-layer protocol-stack surfaces falls from two to one; direct enumeration yields an exact 50% reduction, stated by the Principle as its minimum structural floor.¶
Both results are derived exclusively from the defined Layer 3/U_3 premise, Axiom 0, Axioms 1-15, and the associated definitions. The axioms collectively provide the complete set of stipulated domain-specific premises used by these derivations relative to U_3; they do not assert completeness of the Internet, an implementation, or cybersecurity generally. Theorems I and II require no empirical attack-volume dataset and remain logically independent of any separate measurement of traffic, incidents, attacker behavior, or comparative protocol security. The Principle therefore formalizes the structural consequence of removing one active IP stack without claiming that the surviving protocol is inherently secure.¶
This section is to be removed before publishing as an RFC.¶
This revision expands and tightens the initial formulation without changing the two core results.¶
Defines a bounded Layer 3 parameter universe U_3 and states proof-completeness only relative to that universe and the stipulated premise.¶
Adds an axiom-to-parameter coverage mapping and clarifies that the IPv4 and IPv6 address domains A_4 and A_6 are referenced by U_3 but are not subsets of the parameter universe.¶
Adds a native-stack and retirement-boundary definition covering translators, tunnels, compatibility mechanisms, shared resources, and cross-layer effects.¶
Expands Axiom 0 and Axioms 1-15 to state their domain precisely and adds operational-state and structural-parameter completeness sections.¶
Adds explicit formal notation for Theorem I and distinguishes the exact 50% stack-count reduction in S from the Principle's minimum structural floor.¶
Adds vertical-stack mechanics, a comparative summary, expanded scope boundaries, standards basis, and stronger security considerations.¶