Classification of IPv6-Only Networks by Levels

Abstract

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.¶

1. Introduction

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 [RFC6333], Lightweight 4over6 [RFC7595], and IVI [RFC7915], have been developed and deployed.¶

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.¶

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.¶

2. Terminology

The following terms are defined and used in this document,¶

AS: Autonomous System.¶

CE: Customer Edge.¶

DC: Data Center.¶

NP: Network Provider.¶

NSP: Network-Specific Prefix.¶

P: Provider Router.¶

PE: Provider Edge (Section 5.2 of [RFC4026]).¶

3. Classification of IPv6-Only Levels

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.¶

+------------+--------------------------------------------+--------------+
| 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

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.¶

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.¶

4. Security Considerations

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.¶

5. Operational Considerations

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:¶

1) Benchmarking IPv6-only progress across different networks or time periods.¶

2) Clarifying assumptions in operational documentation, service-level agreements, and interconnection agreements.¶

3) Facilitating clearer communication between operational teams, vendors, and standardization bodies.¶

6. IANA Considerations

There are no other special IANA considerations.¶

7. Acknowledgment

8. References