What the Monostack?Terms, explained.

You're in a maze of twisty little RFCs, all alike. There are some A.C.R.O.N.Y.M.S. here.
Have a guiding hand.

Monostack aka. single-stack or IPv6-only

Unlike a dual-stack network a monostack network exclusively uses the contemporary internet protocol version 6 (IPv6, 2017) for its internal networking needs but may translate to historic legacy protocols such as IP version 4 (IPv4, 1981), ARPANET NCP (1978), X.25 (1976) or SNA (1974) at its edge.

Packet level IPv6⮂IPv4 Translation

The IPv6 and IPv4 protocols are architecturally more similiar than they are different. This gives rise to the idea of translating between the two directly at the packet level (L3). While other approaches such as transport (L4) or application (L7) level translation are technically possible they have more overhead and implementation complexity.

Apart of the obvious address-size difference both IP protocols are unreliable datagram services with control messages (ICMP). For purposes of L3 translation they differ in aspects such as

IP layer translation (ipxlat) is very efficient since no state needs to be kept between individual IP packets, "only" the mismatch of protocol details needs to be handled (see SIIT).

See "Framework for IPv4/IPv6 Translation" (RFC 6144).

Stateful NAT aka NAT44, NAPT44 and NAT/PAT. Can we agree on an acronym already?

Network Address Translation (NAT) usually refers to what is more accurately described as Stateful Network Address and Port Translation between IPv4 and IPv4 (NAPT44) as per IETF nomenclature.

The address and port translation function can operate in one-to-one (stateless) or one-to-many (stateful) modes. The pair of numbers refers to the IP address family (IPv4 or IPv6) used on either side of the address translation function.

Basically stateful NAT allows sharing a single external IP address with many devices on an internal network at the expense of aspects such as:

  1. All systems having to share the same transport protocol (eg. TCP/UDP) port number space,
  2. Connection establishment being restricted to one direction only unless port mappings are used,
  3. Connection maintanance requiring "keep-alive" messages (think of the battery usage!),
  4. Overhead of otherwise unecessary on-path IP defragmentation and re-fragmentation at the translator.

See RFC 6269 for a detailed treatment.

IPv6 was originally designed to avoid NAT all together. however for interoperability with IPv4 during the transition phase the technique is very useful (see NAT64). While discouraged by the IETF NAPT66 is sometimes seen in the wild.

See also

NAT64 squeezing much IPv6 into little IPv4

Mirroring Stateful NAT44, NAT64 enables sharing a single global scope IPv4 address among an entire IPv6-only network with many of the same trade-offs.

What's different is that an an additional 6<>4 translation is done using the SIIT algorithm so an "internal" IPv6 network can reach global IPv4-only services.

If IPv4-only nodes should be able to reach services on the IPv6-only network Static BIB Entries can be used in a manner similar to "port forwarding" in legacy NAT. Alternatively SIIT-DC offers a more scalable alternative to NAT64 in service deployments where the additional complexity is warrented.

Can be combined with DNS64, 464XLAT, IPv6-mostly and PREF64 to build access networks of varying grades of monostack purity.

See also NAT64 (Wikipedia) Implementation deployment: NAT64 Implementations — /STATUS.

Specified in

See also

NAT64 BIB

The Binding Information Base (BIB) conceptually is a table of internal and external address:port mappings for each active connection traversing a NAT64 translator. Usually managed automatically using connection timeouts, but static entries are possible.

Static BIB Entries NAT64 "port forwarding"

Similar to port forwarding in NAT44, making static Binding Information Base (BIB) entries on a NAT64 allows exposing services from an IPv6-only network to IPv4-only clients by mapping the service's static IPv6 address and port to a port on the IPv4 side.

Intended for small networks. See also SIIT-DC and specifically "EAM" a scalable approach to exposing monotsack services to the legacy internet for large networks and datacenters.

SIIT Stateless IP/ICMP Translation

The stateless, packet level translation algorithm underlying full blown stateful NAT64. Conceptually SIIT encapsulates the details of translating between the IPv4 and IPv6 protocols, such as differences in addressing, IP fragmentation approaches (end-to-end vs on-path) and control message formats (ICMP).

Note: SIIT is not to be confused with “SIT”, Simple Internet Transition, which is an existing upstream v6-in-v4 tunnel device (kernel docs) you may be familiar with. It's from back in the days when the internet community though this IPv6 transition was going to be so quick and easy we'll be done by January 2012 at the latest ;-)

See also SIIT (Wikipedia).

Specified in

Followup specifications: SIIT-DC, SIIT EAM

The One True Well-Known Prefix

TODO: Incorporate new wisdom: there's also L4 protocol-independence to consider, but NAT64 makes that moot. New protocols should evolve to assume IPv6 anyway.

In the past 64:ff9b::/96 was regarded as a good default translation prefix for translation between IPv6 and v4. However RFC 6052 doesn't allow translation of RFC 1918 addressess (10./192.168./172.18.), see Section 3.1, and (some) implementations actively block these prefixes which presents migration challenges for many deployments which in turn can only hinder IPv6 adoption.

Despite this right and just holy war against legacy IP wrongthink the elders of the internet have relented and carved out 64:ff9b:1::/48 as a replacement that allows translation towards all legacy unicast addresses. This means we now have a good default stateful NAT64 prefix to rule them all: 64:ff9b:1::/96.

For networks sufficiently priviledged that use of [Layer 4][] protocols other than TCP or UDP is thinkable things are more complicated. A "checksum-neutral" prefix can allow translation without explicit transport (L4) protocol support in the translator.

is desirable but not required unless the SIIT implementation requires one. This being a micro-optimization that's pretty irelevant for software on todays hardware we don't bother with that and focus on ease-of-use instead.

SIIT-DC Scalable, fault tolerant monostack for Datacenter

How to run your "datacenter" services on a monostack but with stateless (i.e. high performance and high availability) legacy IP access handled at the edge, RFC 7755.

It's also possible to poke legacy holes into the monostack using "Dual Translation Mode", RFC 7756.

FIXME.

Specified in

SIIT EAM Explicit Address Mappings

Specified in RFC 7757.

464XLAT

A network architecture where access networks are monostack but hosts and sub-networks can still use IPv4 by talking to the network's NAT64 translator (aka. PLAT) to talk to the global legacy internet.

Specified in

CLAT "Customer-side translator"

Part of the 464XLAT architecture. A SIIT translation function that's part of a host or gateway which allows reaching the legacy IPv4 internet despite the network only providing IPv6 directly.

Specified in

perhaps configured as per 464XLAT and perhaps addressed in the manner of RFC 6052, but not necessarily. The term has transcended the strict RFC definition.

DNS64

A surprisingly effective hack to direct hosts that don't support IPv6-mostly to a network's NAT64 service. Only works with (DNS) name-based connections. IP-literals (eg. https://203.0.113.42) don't bend to its will.

The idea is this: DNS names unable to afford IPv6 AAAA record(s) will have ones synthesized for them by a generous DNS64 enabled recursor. eg https://ipv4.example.net might resolve to https://[64:ff9b:1::203.0.113.42].

Yes this breaks DNSSEC validation for domains with only legacy IP records. Easy fix: add AAAA records. For cases where this is a dealbreaker RFC 7050 envisions doing address synthesis locally by running a full validating resolver on systems that need DNSSEC working for legacy domains.

Implementation deployment: /STATUS — DNS64

Specified in

See also

Tutorials

Related: DeLegacy RPZ

Another nasty DNS hack: Override websites' use of IPv4-only CDN endpoints for an entire network by using a Response Policy Zone (RPZ) ruleset at the DNS recursor.

Chat: #ipv6-rpz:matrix.org

Code: IPv6-Monostack/delegacy-rpz on Codeberg

IPv6-mostly aka. IPv6-only preferred (DHCPv4 option 108)

A deployment where the network asks hosts that support it to turn off their IPv4 stack by including a special DHCPv4 option alongside the usual legacy address offer.

This provides an incentive for networks and applications to focus on IPv6 as it reduces the number of legacy IP addresses (large) networks need and exposes more applications to the IPv6-only future.

The DHCPv4 option is specified in RFC 8925 and technicalities of IPv6-mostly deployment are documented in the v6ops-6mops IETF draft.

Implementation deployment:

IPv6-mostly provider — /STATUS IPv6-mostly client — /STATUS

PREF64

Announces a network's NAT64 prefix info in the existing IPv6 Router Advertisements (RAs) to provide an easier, faster and cleaner way for host software to find the translation service it's supposed to be using. Long-term this is supposed to make DNS64 unecessary.

Implementation deplyment: PREF64 — /STATUS.

Specified in

TODO: link status.html

SVCB RRs Service Binding and HTTPS DNS Records

SVCB and HTTPS are new DNS resource records (RRs) that should become useful for efficiently running services in a monostack environment once browsers consistently support them as they allow cramming more unrelated services onto scarce legacy IPs by de-multiplexing using a unique "port" SvcParamKey number per service.

Consider the following two domains. Each has it's own IPv6 address with a HTTPS service listener on port 443, but they share a legacy address on which they each own a distinct port number:

aaa.example.    HTTPS 1 .
aaa.example.    HTTPS 1 legacy.example. port=1443
aaa.example.    AAAA 2001:db8::aaa

bbb.example.    HTTPS 1 .
bbb.example.    HTTPS 1 legacy.example. port=2443
bbb.example.    AAAA 2001:db8::bbb

legacy.example. A 192.0.2.1

TODO: How this kind of setup interacts with Happy Eyeballs implementations is still unclear.

Without the new RRs the well-known port numbers (443 for HTTPS) have to be shared using a high-touch de-multiplexing technique based on parsing TLS-SNI inside the TCP stream. This essentially requires an active proxy. On the other hand load balancing on TCP layer can be done much more efficiently using high performance network equipment.

Specified in

"Service Binding and Parameter Specification via the DNS", RFC 9460.

Implementations

End-to-end Principle

See End-to-end principle (Wikipedia)

TODO.

CDN Content delivery network

See Content delivery network (Wikipedia)

TODO.

CG-NATCarrier-grade NAT aka "NAT444"

A hacky, but wideley deployed, legacy IP deployment approach squeezing more address- and consequently cost-efficiency out of a given IPv4 allocation at great cost (RFC 7021) to users and IPv6 deployment incentives.

Traditionally ISPs assigned each customer site (CPE) a public IPv4 address and the CPE performed NAT for the customer LAN behind it. However since most customers don't use anywhere near the maximum number of simultanious connections on a single IP (~65k) it's more efficient to share one IPv4 address among many customers and this is what CG-NAT enables by moving the NAT away from the on-site customer CPE into the ISP's network where multiple customers can be squeezed onto a single crowded IP.

One of the major downsides of this approach is that users loose the ability to configure port-forwarding on their CPE to expose local services to the internet. This is sometimes offset by ISPs also deploying dualstack i.e. IPv6 alongside CG-NAT but not always.

The IETF recognised this problem and in reponse specified the Port Control Protocol (PCP, RFC 6887) which allows remotely adding port forwardings. However PCP has not seen significant adoption AFAWCT.

Address Privacy

In the beginning (2001) there was RFC 3041 called IPv6 "privacy extensions", or "temporary addresses". It suggested creating new random addressess to be used for outgoing connections periodically in addition to keeping the established MAC-based SLAAC address.

It became clear this allows tracking devices as they attach to different networks because part of the address say the same. No good for mobile computers eer.. "phones". RFC 7217 (2014) called "stable privacy addressess" went on to suggest a more modern cryptographic approach where we hash a number of identifiers with a secret key generated per device.

IPv4 exhaustion

TODO: Explain difference between (well known) public addressing and RFC1918 exhaustion that only very large orgs feel.

See https://en.wikipedia.org/wiki/IPv4_address_exhaustion.

Router Advertisements aka RAs

Specified in "IPv6 Neighbour Discovery", RFC 4861.

Network classification

TODO: Explain common terms from network engineering:

https://en.wikipedia.org/wiki/Access_network https://en.wikipedia.org/wiki/Backbone_network

TODO

Let's break throught the 6EP field together.

Anything missing, got an idea?: ipv6@lists.monostack.org

Last changed: 2025-12-13