IPv6-only and IPv6-Mostly Terminology Definition
draft-palet-v6ops-ipv6-only-09
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Jordi Palet Martinez | ||
| Last updated | 2025-11-14 | ||
| Replaces | draft-palet-ietf-v6ops-ipv6-only | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-palet-v6ops-ipv6-only-09
v6ops J. Palet Martinez
Internet-Draft The IPv6 Company
Intended status: Informational 14 November 2025
Expires: 18 May 2026
IPv6-only and IPv6-Mostly Terminology Definition
draft-palet-v6ops-ipv6-only-09
Abstract
This document defines the terminology regarding the usage of
expressions such as "IPv6-only" and "IPv6-Mostly", in order to avoid
confusions when using them in IETF and other documents. The goal is
that the reference to "IPv6-only" describes the actual native
functionality being used, not the actual protocol support.
Status of This Memo
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 18 May 2026.
Copyright Notice
Copyright (c) 2025 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.
Palet Martinez Expires 18 May 2026 [Page 1]
Internet-Draft IPv6-only Definition November 2025
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Context is a must . . . . . . . . . . . . . . . . . . . . . . 3
3. Native (IPv4 or IPv6) . . . . . . . . . . . . . . . . . . . . 4
4. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. IPv4-only . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Dual-stack . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. IPv6-Mostly . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Usage examples and practical applicability . . . . . . . . . 4
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
12.1. Normative References . . . . . . . . . . . . . . . . . . 5
12.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Due to the nature of the Internet and the different types of users,
parts of a network, providers, flows, etc., there is not a single and
easy way to categorically say something such as "IPv6-only".
The goal of this document is to depict this situation and agree in a
common language to be used for IETF and other documents, in order to
facilitate ourselves and future readers, the correct understanding of
what we are talking about.
The term IPv6-only is being used by many IETF documents, with a clear
definition of the scope or terminology, for example [RFC6877],
[RFC8585] and [RFC8683].
Note that all the references in this document are regarding the
actual usage of IPv4/IPv6, not the support of those protocols by
nodes. For example, a device or access network may support both IPv4
and IPv6, however actually is only "natively" forwarding IPv6,
because the link used for that communication is only natively
configured for IPv6. IPv4 may be used as well, but it is being
encapsulated or translated by means of IPv6. So, from this
perspective, this device is attached to an IPv6-only link.
As such, a network service is considered IPv6-only if it forwards
IPv6, not IPv4, even if IPv4 is still supported and enabled but not
configured neither used in the nodes participating in the service.
Palet Martinez Expires 18 May 2026 [Page 2]
Internet-Draft IPv6-only Definition November 2025
2. Context is a must
The transition from IPv4 to IPv6 is not something that can be done,
in the large majority of the cases, overnight and in a single step in
a complete network. Consequently, in general, we are unable to talk
about a whole network having a "single and uniform" status regarding
the IPv6 support, at least not in the early deployment stages of an
operator network.
Even if possible, it is not frequent to deploy new IPv6 networks
which have no IPv4 connectivity at all, because at the current phase
of the universal goal of the IPv6 deployment, almost every network
still need to provide some kind of "access" to IPv4(-only) sites and
services. It is not feasible for most of the operators to tell their
customers "I can provide you IPv6 service, but you will not be able
to access all Internet contents and apps, because some of them still
don't support IPv6, so you will miss every content that it is
IPv4-only". Of course, this will change over the time, and there
will be less and less dependency on IPv4-only end-sites/services.
Some networks may have IPv6-only support for specific purposes or
services. For example, a DOCSIS provider may have decided that is
worth the effort to get rid of IPv4 for the management network of the
cable-modems. Or a network that provides connectivity only to IoT
devices, may be IPv6-only.
However, the "end-networks", in general, need to continue supporting
IPv4, as there are many devices or apps, in both corporate and end-
user networks (smartTV, IP cameras, etc.), which are IPv4-only and it
is not always feasible to update or replace them. Also if customer
devices in a LAN are IPv4-only, they will not be able to access
IPv6-only services, so this means that IPv6-only services can't be
deployed unless it is done in such way that some transition mechanism
solves that problem as well (example an IPv6-only Data Center,
requires SIIT-DC)
In IPv6-only access networks, IPv4 support may be provided by
mechanisms that allow "IPv4-as-a-service" (IPv4aaS, for example by
means of encapsulation and/or translation on top of IPv6).
Consequently, considering the context described above, if we want to
be precise and avoid confusing others, we can't use the terminology
such as "IPv6-only" in a generic way, and we need to explicitly
indicate what part of the network we are referring to.
Palet Martinez Expires 18 May 2026 [Page 3]
Internet-Draft IPv6-only Definition November 2025
3. Native (IPv4 or IPv6)
"Native" means that IP packets run directly over a layer 2 (logical
link layer) interface, for example, IEEE 802 link layer, without
anything at layer 3 being encapsulated within an IP packet of another
IP protocol.
4. IPv6-only
"IPv6-only" in a given context, means that only IPv6 is native in
that context. IPv4 is not configured neither managed in that
context, even if it may be transported (or encapsulated) on top of
IPv6.
5. IPv4-only
"IPv4-only" in a given context, means that only IPv4 is native in
that context. IPv6 is not configured neither managed in that
context, even if it may be transported (or encapsulated) on top of
IPv4.
6. Dual-stack
"Dual-stack" means that both, IPv4 and IPv6 are native in that
context.
7. IPv6-Mostly
"IPv6-Mostly" is an "extension" to dual-stack, with two additional
key elements: a NAT64 ([RFC6146]) and DHCPv4 infrastructure operating
Option 108 ([RFC8925]). Optionally there may be also a DNS64
([RFC6147]). This way it can support a mix of IPv4-only, dual-stack
or IPv6-only clients, depending on the client capabilities or
configuration.
8. Usage examples and practical applicability
A typical example will be a service provider network, which has
different types of IPv4/IPv6 support in different arts of the
network. Typically it will be a "dual-stack core", "dual-stack
upstream", "dual-stack BGP", "dual-stack router", but "IPv6-only
access".
As of this writing, most end-user networks and hosts need to support
IPv4, due to many global resources being only available over IPv4.
Transition technologies may allow islands to be connected to the
broader Internet over a IPv6-only access networks acting as an
underlay for legacy IPv4 traffic. An organization aiming to switch
Palet Martinez Expires 18 May 2026 [Page 4]
Internet-Draft IPv6-only Definition November 2025
to an IPv6-only end-user network will need to ensure that all host/
routers are capable of IPv6-only operation and need to ensure that
all off-network resources are available over IPv6 (either as
IPv6-only or dual-stacked).
IPv6-only server, data-center and cloud environments are entirely
possible as of this writing, as long as:
* All host/routers are capable of IPv6-only operation.
* All accessed resources (DNS resolvers, NTP servers, software
update servers, network management services, and other external
resources) are available over IPv6 (either IPv6-only or dual-
stacked).
* All inbound communications are capable of IPv6, either due to all
external endpoints supporting IPv6 or due to all legacy IPv4
traffic being relayed through a gateway (such as reverse proxy,
SIIT-DC gateway, CDN, etc).
Data-centers and cloud enviroments may also support IPv6-only WAN and
at the same time internal dual-stack but using only private IPv4
addresses ([RFC1918]).
9. Security Considerations
This document does not have any specific security considerations.
10. IANA Considerations
This document does not have any IANA considerations.
11. Acknowledgements
The author would like to acknowledge the inputs from Tim Chown, Noah
Maina, Lee Howard, Azael Fernandez Alcantara, Marcos Sanz Grosson,
Robert M. Hinden, Henri Alves, Brian E. Carpenter, Erik Nygren and
...
12. References
12.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
Palet Martinez Expires 18 May 2026 [Page 5]
Internet-Draft IPv6-only Definition November 2025
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC8585] Palet Martinez, J., Liu, H. M.-H., and M. Kawashima,
"Requirements for IPv6 Customer Edge Routers to Support
IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
2019, <https://www.rfc-editor.org/info/rfc8585>.
[RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for
NAT64/464XLAT in Operator and Enterprise Networks",
RFC 8683, DOI 10.17487/RFC8683, November 2019,
<https://www.rfc-editor.org/info/rfc8683>.
[RFC8925] Colitti, L., Linkova, J., Richardson, M., and T.
Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
RFC 8925, DOI 10.17487/RFC8925, October 2020,
<https://www.rfc-editor.org/info/rfc8925>.
12.2. Informative References
[I-D.ietf-v6ops-6mops]
Buraglio, N., Caletka, O., and J. Linkova, "IPv6-Mostly
Networks: Deployment and Operations Considerations", Work
in Progress, Internet-Draft, draft-ietf-v6ops-6mops-04, 20
October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-v6ops-6mops-04>.
Author's Address
Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
28420 La Navata - Galapagar Madrid
Spain
Email: jordi.palet@theipv6company.com
Palet Martinez Expires 18 May 2026 [Page 6]
Internet-Draft IPv6-only Definition November 2025
URI: http://www.theipv6company.com/
Palet Martinez Expires 18 May 2026 [Page 7]