IPv6-Only and IPv6-Mostly Terminology Definitions
draft-ietf-v6ops-ipv6-only-01
| Document | Type | Active Internet-Draft (v6ops WG) | |
|---|---|---|---|
| Author | Jordi Palet Martinez | ||
| Last updated | 2026-08-01 | ||
| Replaces | draft-palet-v6ops-ipv6-only | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-v6ops-ipv6-only-01
v6ops J. Palet Martinez
Internet-Draft The IPv6 Company
Intended status: Informational 1 August 2026
Expires: 2 February 2027
IPv6-Only and IPv6-Mostly Terminology Definitions
draft-ietf-v6ops-ipv6-only-01
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 a reference to "IPv6-Only" describes the actual functionality
being used in a given scope, not the installed 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 2 February 2027.
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 2 February 2027 [Page 1]
Internet-Draft IPv6-Only/Mostly Definition August 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Precisely defined scope is a must . . . . . . . . . . . . . . 3
3. IPv4/IPv6 Native . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv4-Only . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. IPv6-Only . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Dual-Stack . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. IPv4 as a Service (IPv4aaS) . . . . . . . . . . . . . . . . . 5
8. IPv6-Mostly . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. IPv6-Only-Strict . . . . . . . . . . . . . . . . . . . . . . 5
10. Additional Scope Qualification . . . . . . . . . . . . . . . 5
11. API Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
12. Example Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
12.1. IPv4-Only Network . . . . . . . . . . . . . . . . . . . 6
12.2. Dual-Stack Network . . . . . . . . . . . . . . . . . . . 7
12.3. IPv6-Only with IPv4aaS Network . . . . . . . . . . . . . 8
12.4. IPv6-Mostly Segment with Dual-Stack Access Link . . . . 9
12.5. IPv6-Only Segment with Dual-Stack Access Link . . . . . 11
12.6. IPv6-Only-Strict . . . . . . . . . . . . . . . . . . . . 12
13. Usage examples and practical applicability . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
17.1. Normative References . . . . . . . . . . . . . . . . . . 14
17.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
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,
Palet Martinez Expires 2 February 2027 [Page 2]
Internet-Draft IPv6-Only/Mostly Definition August 2026
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.
2. Precisely defined 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, is not possible 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 end-site IPv6
networks which have no IPv4 connectivity at all, because at the
current phase of the universal goal of the IPv6 deployment, almost
every end-site network still needs 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; this is very common in Matter/Thread stub-
networks.
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 [RFC7755]).
Palet Martinez Expires 2 February 2027 [Page 3]
Internet-Draft IPv6-Only/Mostly Definition August 2026
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).
In should be noticed that also server segments are transitioning to
IPv6-Only, in enterprise networks, both for servicing internal and
external clients. In this case, to support IPv4-Only clients,
multiple tools are available, such as stateless NAT64 with EAM
([RFC7757]) or SIIT-DC ([RFC7755]).
Consequently, considering the context described above, in order to be
precise and avoid confusing readers by omitting necessary details,
terminology such as "IPv6-Only" cannot be used in a generic way.
Instead, an explicit indication of what part of the network or which
layer of the network stack is being referred, must be provided.
Therefore, it is necessary to define and describe the specific scope
of applicability. The word "scope" is used in this precise sense
throughout this document.
3. IPv4/IPv6 Native
"IPv4 Native" 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. IPv4-Only
"IPv4-Only" in a given scope, means that only IPv4 is native in that
scope. IPv6 is neither configured or managed in that scope, even if
it may be transported (or encapsulated) on top of IPv4.
5. IPv6-Only
"IPv6-Only" in a given scope, means that only IPv6 is native in that
scope. IPv4 is neither configured or managed in that scope, even if
it may be transported (or encapsulated) on top of IPv6.
6. Dual-Stack
"Dual-Stack" in a given scope, means that both, IPv4 and IPv6 are
native in that scope.
Palet Martinez Expires 2 February 2027 [Page 4]
Internet-Draft IPv6-Only/Mostly Definition August 2026
7. IPv4 as a Service (IPv4aaS)
In the case of IPv6-Only scopes, it is common that, to ensure that
communications with legacy IPv4-Only scopes are possible, IPv4 may be
transported on top of IPv6, typically by means of encapsulation or
translation. This can be made explicit by adding "IPv4aaS" (IPv4 as
a Service). For example, IPv6-Only with IPv4aaS access network.
8. 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.
9. IPv6-Only-Strict
"IPv6-Only-Strict" in a given scope, means that only IPv6 is native
in that scope and IPv4 is neither configured or managed, but also not
transported (neither encapsulated nor translated) on top of IPv6. In
other words, it means that communication with other endpoints is only
possible using IPv6.
10. Additional Scope Qualification
In some cases, the scope can be further qualified indicating if
referring to the data-plane, control-plane or both.
11. API Scope
For the foreseeable future, it is not expected that APIs are
IPv6-Only, and typically will be IPv4-Only (worst case) if they
haven’t been updated, or Dual-Stack.
It is expected and recommended that, in normally configured and up-
to-date hosts, the API is Dual-Stack regardless of any usage of
IPv6-Only in other scopes. As a result of this good practice,
applications will operate correctly in any situation.
A typical example of a dual-stack feature in API scope is the
getaddrinfo() function ([RFC3493]).
Palet Martinez Expires 2 February 2027 [Page 5]
Internet-Draft IPv6-Only/Mostly Definition August 2026
12. Example Diagrams
The next example diagrams show only a few of the possibilities of
different scope combinations. They have been chosen and ordered to
follow the most natural approach, that in general, a "full"
transition from IPv4 to IPv6 will follow. This doesn't mean that all
these transition stages are actually needed in all the transition
cases.
12.1. IPv4-Only Network
The following diagram shows the simplest case, when all the scopes
are IPv4-Only and IPv6 is not present.
In general, an IPv4-Only network will have, even if embedded in the
Customer Edge Router (CE), a DHCPv4 function, as well as a DNS or
DNS-proxy. They are represented as different boxes in the diagrams,
so it applies not just to residential and SOHO networks but also to
enterprise networks.
Palet Martinez Expires 2 February 2027 [Page 6]
Internet-Draft IPv6-Only/Mostly Definition August 2026
+------------+ -
| | |
| ISP | |
| | |
+------------+ |
| |
| IPv4-Only |
| Access Link |
| |
+------------+ |
| IPv4-Only | |
| CE | |
| | |
+------------+ | IPv4-Only
| | Network
+--------+ |
| DHCPv4 | |
+--------+ |
| |
+--------+ |
| DNS | |
+--------+ |
| |
| IPv4-Only |
| Segment |
| |
+------------+ |
| IPv4-Only | |
| Host | |
| | |
+------------+ -
Figure 1: IPv4-Only diagram
12.2. Dual-Stack Network
The following diagram shows the simplest case, when all the scopes
are Dual-Stack.
Palet Martinez Expires 2 February 2027 [Page 7]
Internet-Draft IPv6-Only/Mostly Definition August 2026
+------------+ -
| | |
| ISP | |
| | |
+------------+ |
| |
| Dual-Stack |
| Access Link |
| |
+------------+ |
| Dual-Stack | |
| CE | |
| | |
+------------+ | Dual-Stack
| | Network
+--------+ |
| DHCPv4 | |
+--------+ |
| |
+--------+ |
| DNS | |
+--------+ |
| |
| Dual-Stack |
| Segment |
| |
+------------+ |
| Dual-Stack | |
| Host | |
| | |
+------------+ -
Figure 2: Dual-Stack diagram
12.3. IPv6-Only with IPv4aaS Network
The following diagram shows a very common case, when the service
provider deploys IPv6-Only in the access link scope, instead of Dual-
Stack, while the subscriber segments are still Dual-Stack. This is
the 464XLAT case, which is also very frequent in mobile networks,
where User Equipment (UE) and tethered devices remain Dual-Stack;
here the UE will function as a router. The CE (or UE) will have a
CLAT or equivalent function. The Internet Service Provider provides
the stateful NAT64 (PLAT) function. The end-hosts may have a CLAT,
but they not turn it on, because the CE already provides that
functionality and DHCPv4 option 108 is not enabled/available.
Palet Martinez Expires 2 February 2027 [Page 8]
Internet-Draft IPv6-Only/Mostly Definition August 2026
+------------+ -
| ISP | |
| PLAT/NAT64 | |
| DNS/DNS64 | |
+------------+ |
| |
| IPv6-Only |
| Access Link |
| |
+------------+ |
| Dual-Stack | |
| CE | |
| CLAT | |
+------------+ | IPv6-Only
| | with IPv4aaS
+--------+ | Network
| DHCPv4 | |
+--------+ |
| |
+--------+ |
| DNS | |
+--------+ |
| |
| Dual-Stack |
| Segment |
| |
+------------+ |
| Dual-Stack | |
| Host | |
| CLAT | |
+------------+ -
Figure 3: IPv6-Only with IPv4aaS diagram
12.4. IPv6-Mostly Segment with Dual-Stack Access Link
The following diagram shows the case of IPv6-Mostly, which may be
implemented in different ways. For example, when used in
enterprises, the PLAT and DNS64 may be implemented in the enterprise
network itself, in order to gain greater control of the
configuration. It is important to note that, in this case, the
DHCPv4 function needs to support the option 108. As a result, a
Dual-Stack segment will be able to support both, hosts using
IPv6-Only with a CLAT function (even if they are Dual-Stack), as well
as IPv4-Only hosts or Dual-Stack hosts without the support of CLAT/
option 108. In residential and SOHO networks, typically the PLAT is
located in the service provider network, as well as the DNS64 (which
is optional). Using IPv6-Mostly in that case, restricts the
Palet Martinez Expires 2 February 2027 [Page 9]
Internet-Draft IPv6-Only/Mostly Definition August 2026
communication between IPv4-Only hosts and those that are using
IPv6-Only mode. This is resolved in enterprise networks by means of
an internal PLAT with EAM [RFC7757], SIIT-DC [RFC7755] or other
means. Residential, SOHO an enterprise networks could choose an
IPv6-Only+IPv4aaS Access Link, so the case becomes a mix of them.
+------------+ -
| ISP | |
| PLAT/NAT64 | |
| DNS/DNS64 | |
+------------+ |
| |
| Dual-Stack |
| Access Link |
| |
+------------+ |
| Dual-Stack | |
| CE | |
| | |
+------------+ | IPv6-Mostly
| | Segment
+--------+ | with Dual-Stack
| DHCPv4 | | Access Link
| opt.108| |
+--------+ |
| |
+---------+ |
|DNS/DNS64| |
+---------+ |
| |
| IPv6-Mostly |
| Segment |
| |
-+---------------+- |
| | |
+------------+ +------------+ |
| Dual-Stack | | IPv4-Only/ | |
| Host | | Dual-Stack | |
| CLAT | | Host | |
+------------+ +------------+ -
Figure 4: IPv6-Mostly diagram
Palet Martinez Expires 2 February 2027 [Page 10]
Internet-Draft IPv6-Only/Mostly Definition August 2026
12.5. IPv6-Only Segment with Dual-Stack Access Link
The following diagram shows the case, more common in enterprise
networks, when hosts in a segment are able to use IPv6-Only but they
still need Dual-Stack access link because they still need to reach
IPv4-Only in Internet or other networks segments may need IPv4, for
example if the enterprise network needs to expose some Dual-Stack
services to Internet. In this case, DHCPv4 is not needed.
Residential and SOHO networks in general will keep using an IPv6-Only
Access Link.
+------------+ -
| ISP | |
| PLAT/NAT64 | |
| DNS/DNS64 | |
+------------+ |
| |
| Dual-Stack |
| Access Link |
| |
+------------+ |
| Dual-Stack | |
| CE | |
| | | IPv6-Only
+------------+ | Segment
| | with Dual-Stack
+--------+ | Access Link
| DNS64 | |
+--------+ |
| |
| IPv6-Only |
| Segment |
| |
+------------+ |
| Dual-Stack | |
| Host | |
| CLAT | |
+------------+ -
Figure 5: IPv6-Only diagram
Palet Martinez Expires 2 February 2027 [Page 11]
Internet-Draft IPv6-Only/Mostly Definition August 2026
12.6. IPv6-Only-Strict
The following diagram shows the case, when all the scopes of a
network are using IPv6-Only and IPv4 communications are not possible.
This would be the ideal "full transition" stage, which however, is
not feasible in most of the cases, as maybe certain destinations in
Internet, that a network still needs to reach, will remain IPv4-Only
for a long period of time.
+------------+ -
| | |
| ISP | |
| | |
+------------+ |
| |
| IPv6-Only- |
| Strict |
| Access Link |
| |
+------------+ |
| IPv6-Only- | |
| Strict CE | |
| | |
+------------+ | IPv6-Only-Strict
| | Network
+--------+ |
| DNS | |
+--------+ |
| |
| IPv6-Only- |
| Strict |
| Segment |
| |
+------------+ |
| IPv6-Only- | |
| Strict | |
| Host | |
+------------+ -
Figure 6: IPv6-Only-Strict diagram
Palet Martinez Expires 2 February 2027 [Page 12]
Internet-Draft IPv6-Only/Mostly Definition August 2026
13. 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 offers
"IPv6-Only access". It is not common, but may be cases where it is
"IPv6-Only access data-plane" and "Dual-Stack access control-plane"
or "IPv4-only access out-of-band management".
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 an 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-Stack).
In the case of data-centers, "IPv6-Only compute nodes" may be
provided with IPv4 external IPv4 communication, using SIIT-DC. In
this case, there is an "IPv6-Only data-center" when speaking about
the internal LANs (anything behind the Border Relay), but "Dual-Stack
data-center upstreams".
In the case of a mobile network, the UEs (User Equipment, e.g.,
mobile phones) have "IPv6-Only PDP Context", those UEs may offer
"Dual-Stack Tethering" and "Dual-Stack to the UE applications"(by
means of CLAT), and this is possible thanks to the support of NAT64
in the service provider network; the NAT64 is a "Dual-Stack service",
which has an "IPv6-Only transport to the UEs".
In the case of an enterprise network, there may be a mix of VLANs or
network segments offering Dual-Stack, IPv6-Only and IPv6-Mostly. So
in this case, it becomes clear by using "Dual-Stack VLAN x",
"IPv6-Only VLAN y" and "IPv6-Mostly VLAN z".
IPv6-Only server, IPv6-Only data-center and IPv6-Only 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-
Stack).
Palet Martinez Expires 2 February 2027 [Page 13]
Internet-Draft IPv6-Only/Mostly Definition August 2026
* 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 environments may also support IPv6-Only WAN
and at the same time internal Dual-Stack but using only private IPv4
addresses ([RFC1918]).
14. Security Considerations
This document does not have any specific security considerations.
15. IANA Considerations
This document does not have any IANA considerations.
16. 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, Chenhao Ma,
Philipp Tiesel, Wilton Arthur Poth, Tom Petch and ...
17. References
17.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>.
[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>.
Palet Martinez Expires 2 February 2027 [Page 14]
Internet-Draft IPv6-Only/Mostly Definition August 2026
[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>.
17.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>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, March 2003,
<https://www.rfc-editor.org/info/rfc3493>.
[RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
IPv6 Data Center Environments", RFC 7755,
DOI 10.17487/RFC7755, February 2016,
<https://www.rfc-editor.org/info/rfc7755>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", STD 103,
RFC 7757, DOI 10.17487/RFC7757, February 2016,
<https://www.rfc-editor.org/info/rfc7757>.
Author's Address
Palet Martinez Expires 2 February 2027 [Page 15]
Internet-Draft IPv6-Only/Mostly Definition August 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 2 February 2027 [Page 16]