<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-xie-v6ops-ipv6only-classification-00" ipr="trust200902">
  <front>
    <title abbrev="IPv6-only Networks Classification">Classification of IPv6-Only Networks by Levels</title>

    <author fullname="Chongfeng Xie" initials="C" surname="Xie">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>xiechf@chinatelecom.cn</email>
      </address>
    </author>

    
    <author fullname="Xing Li" initials="X" surname="Li">
      <organization>CERNET Center/Tsinghua University</organization>

      <address>
        <postal>
          <street>Shuangqing Road No.30, Haidian District</street>

          <city>Beijing</city>

          <code>100084</code>

          <country>China</country>
        </postal>

        <email>xing@cernet.edu.cn</email>
      </address>
    </author>


    <date day="31" month="March" year="2026"/>

    <area>OPS Area</area>

    <workgroup>V6ops Working Group</workgroup>

    <keyword>RFC</keyword>

    <abstract>
      <t>IPv6-only networking is recognized as the ultimate goal of network 
      evolution. However, in practice, the understanding and implementation of IPv6-only varies significantly.
      To address ambiguity and improve communication, this document proposes a 
      classification for IPv6-only networks. It defines three distinct levels, from
      a pure state with no IPv4 support to scenarios where IPv6-only and 
      dual-stack coexistence exists. This approach of classification is
      applicable to all network scenarios and aids operators and protocol designers
      in precisely specifying the nature of their IPv6-only deployments.</t>

      </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The deployment of IPv6-only networks represents a fundamental transition
      in internet architecture, where the network is built exclusively around the
      IPv6 protocol for addressing, routing, and interconnection. 
      This model is widely recognized as the ultimate stage of IPv6 evolution. 
      IPv6 only can be applied to various scenarios, such as backbone networks, 
      metropolitan area networks (MANs), access networks, IDCs, enterprise networks, 
      the Internet of Things (IoT), inter-network peering, and agent networks, among others.
      However, in practice, the path to a pure IPv6-only environment is shaped by
      the necessity to maintain backward compatibility with existing services, particularly
      those that do not support IPv6. To address this, various IPv4-as-a-Service
      (IPv4aaS) mechanisms, such as DS-Lite <xref target="RFC6333"/>, 
      Lightweight 4over6 <xref target="RFC7595"/>, and IVI <xref target="RFC7915"/>, have been developed and deployed.</t>

      <t>For an operator, when all services have been migrated to IPv6,
      a fully realized IPv6-only network would require no support for IPv4 traffic
       whatsoever, representing a clean-state architecture. In contrast, many operational networks 
      exhibit a mix of IPv6-only and dual-stack (IPv4/IPv6) components,
       with varying degrees of IPv6-only penetration. This heterogeneity
      leads to inconsistent interpretations of what constitutes an IPv6-only network,
      creating confusion in technical discussions, network planning and operation, and standardization efforts.</t>
      
      <t>To address this ambiguity, this document proposes a graded classification 
      approach for IPv6-only networks. The goal is to provide a standardized set of
      definitions that allow network operators to precisely characterize the extent
      to which their networks support IPv6-only operations, thereby facilitating
      clearer and more efficient communication and more consistent deployment practices. 
      In addition, it enables the industry to develop different technical solutions 
      and standards for different IPv6-only levels. When building an IPv6-only network,
      operators can also choose solutions that correspond to their respective
      levels. In the long run, it will benefit the overall IPv6-only deployment worldwide.
      This document does not intend to define new protocols or technological approaches.</t>


      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section title="Terminology">
      <t>The following terms are defined and used in this document,</t>

       <t>AS: Autonomous System.</t>

          <t>CE: Customer Edge.</t>

          <t>DC: Data Center.</t>

          <t>NP: Network Provider.</t>

          <t>NSP: Network-Specific Prefix.</t>

          <t>P: Provider Router.</t>

          <t>PE: Provider Edge (Section 5.2 of <xref target="RFC4026"/>).</t>

    </section>

    <section title="Classification of IPv6-Only Levels">
      <t>The following three levels are defined to describe the degree of IPv6-only
      adoption within a network. Each level reflects a distinct architectural
      state, ranging from full pure IPv6-only to partial coexistence with
      IPv4 capabilities.</t>

            <figure>
      <artwork>
<![CDATA[
+------------+--------------------------------------------+--------------+
| IPv6-only  |              Description                   |  Degree of   | 
|   Levels   |                                            |  IPv6-only   |
|            |                                            |   Support    |
+------------+--------------------------------------------+--------------+
|            | The network forwarding plane is entirely   |              |
|            | IPv6-only, and no IPv4 service support is  |              |
|            | provided. This represents the purest form  |              |
|  Level-0   | of IPv6-only operation, where all traffic  |    High      |
|            | ---including any residual IPv4 dependencies|              |
|            | ---is either absent or handled without     |              |
|            |  network-level IPv4 mechanisms.            |              |
+-- ---------+--------------------------------------------+--------------+
|            | The network core is IPv6-only, but IPv4    |              |
|            | service capabilities are available at the  |              |
|            | edge through IPv4-as-a-Service (IPv4aaS)   |              |
|  Level-1   | techniques such as DS-Lite, 4over6, or IVI.|    Medium    |
|            | In this model, IPv4 traffic is             |              |
|            | encapsulated or translated, but the        |              |
|            | underlying transport infrastructure        |              |
|            | remains IPv6-only.                         |              |
+------------+--------------------------------------------+--------------+
|            | The network is a mixed environment where   |              |
|            | IPv6-only and dual-stack (IPv4/IPv6)       |              |
|            | components coexist. A typical example is   |              |
|            | is an "IPv6-mostly" network, where most    |              |
|  Level-2   | nodes operate in IPv6-only mode but certain|     Low      |
|            | segments or devices still maintain full    |              |
|            | dual-stack functionality.This level        |              |
|            | represents a transitional phase with       |              |
|            | lower overall IPv6-only consistency.       |              |
+------------+--------------------------------------------+--------------+

 Table 1: Representation Examples of IPv4-Embedded IPv6 Address
]]></artwork>
    </figure>

      <t>As mentioned before, these levels are intended to serve as a practical 
      reference for network operators to assess and communicate the current state
      of their IPv6-only transition. By applying this classification, operators can 
      more clearly define their architectural posture, identify transition milestones,
      and align with industry best practices. When an operator claims to have 
      deployed an IPv6-only network, it is recommended to also specify the 
      corresponding level defined in this document. Similarly, protocol 
      designers developing solutions intended for IPv6-only environments are
      encouraged to clarify which level(s) their design targets, as the technical
      requirements may differ significantly between Level-0, Level-1, and 
      Level-2 scenarios.</t> 
      <t>It should be noted that this classification is applicable to all types of 
      network environments, including access networks, backbone networks, data center
      networks, and interconnection points between networks.</t>

    </section>

   
    <section title="Security Considerations">
      <t>This document presents a classification framework for IPv6-only
      networks and does not introduce new protocols or operational procedures.
      As such, no direct security implications are identified at this stage.
      However, it is worth noting that the security properties of a network
      may vary significantly across the defined levels. For instance, 
      Level-0 networks, lacking any IPv4 support, inherently reduce the attack
      surface associated with legacy IPv4 stacks and transition mechanisms. 
      Conversely, Level-1 and Level-2 networks may introduce additional 
      considerations related to encapsulation, translation, and dual-stack 
      coexistence, which should be addressed through appropriate security
      architectures.</t>
    </section>

    <section title="Operational Considerations">
      <t>This classification is designed to assist network operators in 
      characterizing their IPv6-only deployment status. While no specific operational
      requirements are mandated, the grading approach can support use cases such as:</t>

      <t indent="4">1) Benchmarking IPv6-only progress across different networks or time periods.</t>

      <t indent="4">2) Clarifying assumptions in operational documentation, service-level agreements,
      and interconnection agreements. </t>

      <t indent="4">3) Facilitating clearer communication between operational teams, vendors, and standardization bodies. </t>

    </section>

    <section title="IANA Considerations">
      <t>There are no other special IANA considerations.</t>
    </section>

    <section title="Acknowledgment">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.4026"?>

      <?rfc include="reference.RFC.5565"?>

      <?rfc include="reference.RFC.6052"?>

      <?rfc include='reference.RFC.6877'?>

      <?rfc include='reference.RFC.7915'?>

      <?rfc include='reference.RFC.8174'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4213"?>

      <?rfc include="reference.RFC.4760"?>

      <?rfc include='reference.RFC.6333'?>

       <?rfc include='reference.RFC.6480'?>

      <?rfc include='reference.RFC.6992'?>

      <?rfc include="reference.RFC.6144"?>

      <?rfc include='reference.RFC.7595'?>

      <?rfc include='reference.RFC.7597'?>

      <?rfc include='reference.RFC.7599'?>

      <?rfc include='reference.RFC.8585'?>

      <?rfc include='reference.RFC.8950'?>

      <?rfc include="reference.RFC.9313"?>

      <?rfc include="reference.I-D.ietf-v6ops-6mops"?>


         </references>
  </back>
</rfc>