



v6ops                                                  J. Palet Martinez
Internet-Draft                                          The IPv6 Company
Intended status: Informational                             14 March 2026
Expires: 15 September 2026


            IPv6-only and IPv6-Mostly Terminology Definition
                     draft-palet-v6ops-ipv6-only-10

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 15 September 2026.

Copyright Notice

   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.




Palet Martinez          Expires 15 September 2026               [Page 1]

Internet-Draft            IPv6-only Definition                March 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Scope 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 15 September 2026               [Page 2]

Internet-Draft            IPv6-only Definition                March 2026


2.  Scope 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, or to say in
   another way, what is the specific "scope".






Palet Martinez          Expires 15 September 2026               [Page 3]

Internet-Draft            IPv6-only Definition                March 2026


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 scope, means that only IPv6 is native in that
   scope.  IPv4 is not configured neither managed in that scope, even if
   it may be transported (or encapsulated) on top of IPv6.

5.  IPv4-only

   "IPv4-only" in a given scope, means that only IPv4 is native in that
   scope.  IPv6 is not configured neither managed in that scope, 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 scope.

7.  IPv6-Mostly

   "IPv6-Mostly" is similar 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, in a dual-stack network scope, it can support
   a mix of IPv4-only, dual-stack or IPv6-only clients, depending on the
   client capabilities or configuration.  It can be seen as a way to
   provide IPv4 support on demand.

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 parts of the
   network.  Typically it will be a "dual-stack core", "dual-stack
   upstream", "dual-stack BGP", "dual-stack router", but "IPv6-only
   access".











Palet Martinez          Expires 15 September 2026               [Page 4]

Internet-Draft            IPv6-only Definition                March 2026


   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
   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,
   Jeremy Duncan, David Farmer, Nick Buraglio, Stan Barber, Goetz
   Goerisch, Mark Andrews, Michael Richardson, XiPeng Xiao and ...

12.  References

12.1.  Normative References



Palet Martinez          Expires 15 September 2026               [Page 5]

Internet-Draft            IPv6-only Definition                March 2026


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

   [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-07, 2
              March 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-v6ops-6mops-07>.

Author's Address





Palet Martinez          Expires 15 September 2026               [Page 6]

Internet-Draft            IPv6-only Definition                March 2026


   Jordi Palet Martinez
   The IPv6 Company
   Molino de la Navata, 75
   28420 La Navata - Galapagar Madrid
   Spain
   Email: jordi.palet@theipv6company.com
   URI:   http://www.theipv6company.com/












































Palet Martinez          Expires 15 September 2026               [Page 7]
