Deploying IPv6 in Data Centers
draft-martin-deploying-ipv6-data-center-02
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 | Franck Martin | ||
| Last updated | 2026-07-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| 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-martin-deploying-ipv6-data-center-02
IPv6 Operations F. Martin
Internet-Draft Peachymango.org
Intended status: Informational 18 July 2026
Expires: 19 January 2027
Deploying IPv6 in Data Centers
draft-martin-deploying-ipv6-data-center-02
Abstract
Data center operators are moving toward IPv6-only operation to
simplify addressing, restore end-to-end connectivity, and meet
operator and government timelines. Much published IPv6 guidance
targets network engineers; this document instead addresses *Site
Reliability Engineers (SREs)* and *Software Engineers (SWEs)* who
deploy, operate, and debug services in *operator-owned data centers*.
It is organized in two parts after IPv6 fundamentals: a *migration
program* (transition strategy and observability) and a *technical
stack* (hardware, provisioning, transport, applications, and
diagnostics). It documents common software and infrastructure gaps
and offers practical deployment patterns aligned with the IPv6
Operations (v6ops) working group charter.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://github.com/franckhlmartin/ietf-draft-deploying-ipv6-data-
center/ (https://github.com/franckhlmartin/ietf-draft-deploying-ipv6-
data-center/). Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-martin-deploying-ipv6-data-
center/ (https://datatracker.ietf.org/doc/draft-martin-deploying-
ipv6-data-center/).
Discussion of this document takes place on the v6ops Working Group
mailing list (mailto:v6ops@ietf.org (mailto:v6ops@ietf.org)), which
is archived at https://mailarchive.ietf.org/arch/browse/v6ops/
(https://mailarchive.ietf.org/arch/browse/v6ops/). Subscribe at
https://www.ietf.org/mailman/listinfo/v6ops/
(https://www.ietf.org/mailman/listinfo/v6ops/).
Source for this draft and an issue tracker can be found at
https://github.com/franckhlmartin/ietf-draft-deploying-ipv6-data-
center (https://github.com/franckhlmartin/ietf-draft-deploying-ipv6-
data-center).
Martin Expires 19 January 2027 [Page 1]
Internet-Draft deploying-ipv6-data-center July 2026
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 19 January 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Audience and Purpose . . . . . . . . . . . . . . . . . . 4
1.2. Related Guides . . . . . . . . . . . . . . . . . . . . . 5
1.3. Document Structure . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. IPv6 Fundamentals for Software Engineers . . . . . . . . . . 6
2.1. Address Size and Header Format . . . . . . . . . . . . . 6
2.2. Checksums, Jumbo Frames, and Fragmentation . . . . . . . 7
2.3. ICMPv6 and Neighbor Discovery . . . . . . . . . . . . . . 7
2.4. End-to-End Connectivity . . . . . . . . . . . . . . . . . 7
2.5. Address Types and Terminology . . . . . . . . . . . . . . 7
2.6. Address Representation . . . . . . . . . . . . . . . . . 8
2.7. Prefix Length and the /64 Convention . . . . . . . . . . 9
2.8. Link-Local Gateways . . . . . . . . . . . . . . . . . . . 9
2.9. Naming Services . . . . . . . . . . . . . . . . . . . . . 10
Martin Expires 19 January 2027 [Page 2]
Internet-Draft deploying-ipv6-data-center July 2026
3. Part I: Running the Migration . . . . . . . . . . . . . . . . 10
4. Transition Strategies . . . . . . . . . . . . . . . . . . . . 10
4.1. Easier to Provision Than to Transform . . . . . . . . . . 10
4.2. IPv4-Only Exceptions and Remediation Plans . . . . . . . 10
4.3. IPv6-Only Jump Hosts . . . . . . . . . . . . . . . . . . 11
5. Observability and Metrics . . . . . . . . . . . . . . . . . . 12
5.1. Service Inventory and Discovery . . . . . . . . . . . . . 12
5.2. Progress Metrics . . . . . . . . . . . . . . . . . . . . 12
5.3. Dual-Stack Regression and Hard Failures on IPv6 . . . . . 13
5.4. Host-Level Listen-Socket Audit . . . . . . . . . . . . . 13
5.5. Host Agents Before Application Provisioning . . . . . . . 14
5.6. Traffic by Protocol and Address Family . . . . . . . . . 14
5.7. HTTP Signaling and Planned IPv4 Drills . . . . . . . . . 14
5.8. Live Traffic and Service Call Trees . . . . . . . . . . . 15
6. Part II: Building the IPv6 Data Center . . . . . . . . . . . 15
7. Out-of-Band Management and Network Boot . . . . . . . . . . . 15
7.1. Often-Forgotten Infrastructure Devices . . . . . . . . . 15
7.2. Firmware and PXE/UEFI Boot . . . . . . . . . . . . . . . 16
7.3. IPMI and Redfish . . . . . . . . . . . . . . . . . . . . 16
8. Internet and Data Center Addressing . . . . . . . . . . . . . 16
8.1. Prefix Allocation for Hosts and Containers . . . . . . . 16
8.2. Static Addressing, Router Advertisements, and IPAM . . . 17
8.3. Semantic Prefixes for Internal Traffic . . . . . . . . . 18
8.4. Internet Egress and Edge Gateways . . . . . . . . . . . . 19
8.5. Internal vs External: Where IPv6-Only Applies . . . . . . 19
8.5.1. Dual-Homed Hosts During Internal IPv6 Rollout . . . . 20
8.6. Frontends for IPv4-Only Services . . . . . . . . . . . . 21
8.7. Access Control List Propagation . . . . . . . . . . . . . 21
8.7.1. IPAM-Based IPv4-to-IPv6 Mapping for ACLs . . . . . . 22
9. DNS Registration and Dynamic Addressing . . . . . . . . . . . 23
9.1. SLAAC, Switches, and the DNS Gap . . . . . . . . . . . . 23
9.2. DHCPv6 and Hostname Registration . . . . . . . . . . . . 23
9.3. DHCPv6 Suitability Considerations . . . . . . . . . . . . 24
10. Hybrid On-Premise and Cloud Environments . . . . . . . . . . 24
10.1. Connectivity Models . . . . . . . . . . . . . . . . . . 24
10.2. Cloud Provider Gap Analysis . . . . . . . . . . . . . . 25
10.3. Cloud as Platform Software . . . . . . . . . . . . . . . 25
11. ICMPv6, PMTUD, and Middleboxes . . . . . . . . . . . . . . . 26
11.1. Do Not Block ICMPv6 . . . . . . . . . . . . . . . . . . 26
11.2. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 26
11.3. VPNs and NAT64 . . . . . . . . . . . . . . . . . . . . . 26
12. Application and Software Readiness . . . . . . . . . . . . . 27
12.1. Enterprise Platform Inventory . . . . . . . . . . . . . 27
12.2. Dependency and Platform Readiness Gates . . . . . . . . 27
12.3. Developer and Pre-Production Environments . . . . . . . 28
12.4. Hard-Coded Addresses and Localhost Pitfalls . . . . . . 28
12.5. IP Address Storage in Application Data . . . . . . . . . 29
12.6. Databases, ACLs, and Security Tools . . . . . . . . . . 29
Martin Expires 19 January 2027 [Page 3]
Internet-Draft deploying-ipv6-data-center July 2026
12.7. Language Runtimes and Libraries . . . . . . . . . . . . 30
12.8. Static Analysis and Pull Request Automation . . . . . . 30
12.8.1. Pattern Scanners in CI . . . . . . . . . . . . . . . 30
12.8.2. Automated Remediation Pull Requests . . . . . . . . 31
12.8.3. Opt-Out Annotations for Engineers . . . . . . . . . 31
12.8.4. AI Coding Agent Skills . . . . . . . . . . . . . . . 32
12.9. Documentation and Presentations . . . . . . . . . . . . 32
13. Resolving Hostnames to Addresses . . . . . . . . . . . . . . 33
13.1. Use getaddrinfo(), Not Legacy One-Address APIs . . . . . 33
13.2. Why the Full List Matters . . . . . . . . . . . . . . . 34
13.3. Numeric Input at the Edge . . . . . . . . . . . . . . . 35
13.4. Address Selection, gai.conf, and DNS Round Robin . . . . 35
13.5. Runtime-Specific Resolution (Not Always glibc) . . . . . 36
14. Client-Side Load Balancing . . . . . . . . . . . . . . . . . 36
15. Network Diagnostics in the Data Center . . . . . . . . . . . 37
15.1. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . 37
15.2. Controlled ICMP Echo (Ping) . . . . . . . . . . . . . . 37
16. Security Considerations . . . . . . . . . . . . . . . . . . . 38
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
19. Normative References . . . . . . . . . . . . . . . . . . . . 38
20. Informative References . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction
1.1. Audience and Purpose
This document is written for *Site Reliability Engineers (SREs) and
Software Engineers (SWEs)* who run services in data centers --- not
primarily for network engineers designing routing policy. Network
teams still own prefixes, routing, and firewalls, but IPv6 deployment
succeeds or fails in application code, configuration management,
monitoring pipelines, and the long tail of enterprise software that
assumes IPv4.
Martin Expires 19 January 2027 [Page 4]
Internet-Draft deploying-ipv6-data-center July 2026
*Scope:* The primary audience runs services on infrastructure the
organization *owns or directly controls* --- operator-managed
networks, prefixes, routing, firewalls, and bare-metal or virtualized
hosts in *physical or private data centers*. This document does *not*
prescribe how to deploy IPv6 *natively inside third-party
Infrastructure-as-a-Service (IaaS)* platforms (public cloud VPCs,
provider-managed Kubernetes, and similar). Each cloud provider
imposes its own addressing models, quotas, APIs, and processes; the
deployer is *constrained* by those platform choices in ways this
draft cannot generalize. Operators with hybrid estates SHOULD still
understand cloud IPv6 gaps and connectivity limits (see Section 10)
because those constraints often determine whether an on-premise
IPv6-only program can succeed.
1.2. Related Guides
This document focuses on data center SRE and software engineering
practice. Operators and developers may also find these *informative
guides* useful alongside this draft:
* [RFC7381] --- enterprise IPv6 deployment framework (v6ops)
* [RFC4038] --- application aspects of IPv6 transition
* [I-D.ietf-v6ops-ipv6-app-testing] --- testing applications' IPv6
support across IPv4-only, dual-stack, IPv6-only with NAT64, and
IPv6-only-strict scenarios (v6ops); the testing companion to the
deployment guidance in this document
* [I-D.ietf-v6ops-ipv6-only] --- IPv6-only and IPv6-Mostly
terminology definitions (v6ops)
* [ARCEP-IPV6-GUIDE] --- enterprise IPv6 rollout guidance from ARCEP
(France)
* [ARIN-APPS-V6] --- application and software developer guidance
from ARIN
They overlap partially with sections here (applications, addressing,
operations) but cover broader enterprise and regional context.
1.3. Document Structure
This document uses a *dual-track structure* after Section 2: *Part I*
defines migration policy and measurement; *Part II* implements the
stack from management hardware upward. Fundamentals establish shared
vocabulary for SREs and software engineers; both parts are required
for a complete IPv6-only data center. Overlapping themes (for
example internal vs external scope in Section 8.5 and Section 4.1)
appear where each audience needs them; sections cross-link rather
than repeat editorially.
Martin Expires 19 January 2027 [Page 5]
Internet-Draft deploying-ipv6-data-center July 2026
*Part I --- Running the migration:* Section 4 covers operating model
and scope (greenfield provisioning vs brownfield conversion,
IPv6-only jump hosts). Section 5 defines inventory schema,
dashboards, and success metrics --- fix what you measure before bulk
technical change.
*Part II --- Building the IPv6 data center* follows a bottom-up
order: Section 7 (hardware and management plane), Section 8 and
Section 9 (provisioning), Section 10 (on-premise plus public cloud
connectivity), Section 11 (transport health), then application work
--- Section 12, Section 13, Section 14 --- and Section 15 for
production troubleshooting.
*Reading paths by role:*
* _Program lead / engineering manager:_ Part I first, then Part II
as overview.
* _Network / DC infrastructure engineer:_ Section 2, then Part II
sections on OOB through Section 10 and ICMPv6/PMTUD.
* _Application / SRE engineer:_ Section 2, Part I Section 5, then
Part II application and diagnostics sections.
* _Full migration owner:_ linear --- fundamentals, Part I, Part II,
then Security Considerations.
1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. IPv6 Fundamentals for Software Engineers
Software engineers who have worked only in IPv4 environments often
discover that IPv6 is not "IPv4 with longer addresses." The
differences below affect code, configuration, monitoring, and
troubleshooting daily.
2.1. Address Size and Header Format
IPv4 addresses are *32 bits*; IPv6 addresses are *128 bits*
[RFC8200]. The IPv4 header has a *variable length* because options
are carried in the main header. The IPv6 header has a *fixed 40-byte
length*, which simplifies fast-path processing on routers and hosts.
Additional IPv6 options live in *extension headers* chained after the
main header; routers *do not need to process* most extension headers
for forwarding [RFC8200].
Martin Expires 19 January 2027 [Page 6]
Internet-Draft deploying-ipv6-data-center July 2026
2.2. Checksums, Jumbo Frames, and Fragmentation
IPv6 removed the header checksum present in IPv4; integrity is
assumed to be covered by upper-layer protocols (for example, TCP,
UDP, and SCTP) and link layers where applicable [RFC8200]. Operators
can use *jumbo frames* on supported paths to reduce per-packet
overhead and acknowledgment rates on high-throughput links. Jumbo
frames are an operational choice on the LAN and require end-to-end
support; they are not an IPv6 requirement but are often easier to
reason about once NAT middleboxes are removed.
IPv4 allowed routers to fragment packets in transit. IPv6 *fragments
only at endpoints* [RFC8200]. If a packet exceeds the path MTU, the
source discovers the limit through Path MTU Discovery (see
Section 11) rather than relying on router fragmentation. Application
teams that tune MSS or disable PMTUD on IPv4 must not copy those
habits blindly to IPv6.
2.3. ICMPv6 and Neighbor Discovery
IPv4 Address Resolution Protocol (ARP) is replaced in IPv6 by
*Neighbor Discovery (ND)* carried in *ICMPv6* [RFC4861] [RFC4443].
ND resolves addresses on the local link, discovers routers, and
performs other essential functions. *ICMPv6 therefore MUST NOT be
blocked wholesale* on IPv6 paths the way some IPv4 deployments block
all ICMP. Blocking ICMPv6 breaks ND and PMTUD and produces failures
that look like application bugs. Guidance exists to identify
essential ICMPv6 traffic that should not be blocked [RFC4890].
2.4. End-to-End Connectivity
IPv4 data centers often rely on Network Address Translation (NAT),
carrier-grade NAT (CGNAT), and overlapping private address space
[RFC1918]. IPv6 restores the *end-to-end principle*: globally unique
addresses (with deliberate exceptions noted below) can be routed on
the Internet without translation. Routing replaces NAT for many
multi-tenant container scenarios, which simplifies traffic inspection
but requires disciplined prefix planning (see Section 8).
2.5. Address Types and Terminology
Careless use of the word "IPv6" causes outages. This document uses
the following terms:
Martin Expires 19 January 2027 [Page 7]
Internet-Draft deploying-ipv6-data-center July 2026
*Link-local address*: An address in fe80::/10 used only on a single
link [RFC4291]. Link-local addresses are *not* routed on the
Internet. On Linux, connecting to a link-local destination requires
a *zone identifier* (for example, fe80::1%eth0) because the same
link-local prefix exists on every interface.
*Unique Local Address (ULA)*: An address in fc00::/7 intended for
local use and *not* globally routed [RFC4193]. ULAs resemble IPv4
private space in purpose but are uncommon in many data center designs
that use provider- aggregated global unicast space internally. Like
IPv4 private address space, ULAs can create *renumbering work* when
companies merge or networks are combined --- a data center network is
never final.
*Global Unicast Address (GUA)*: A globally routable IPv6 address
assigned from an organization's allocation of IPv6 addresses.
Unlike IPv4, there is *no RFC 1918 equivalent that dominates data
center design*. With rare exceptions (link-local, ULA, and special-
purpose ranges in [RFC6890]), *IPv6 unicast addresses are designed to
be globally unique and routable*. Security boundaries are enforced by
routing policy and firewall rules, not by assuming addresses are
inherently non-routable. We use two additional terms to distinguish
addresses based on thes policies:
*Internal global unicast address*: A globally routable IPv6 address
used *inside* the data center. These addresses are reachable
according to routing and security policy, not because they are
"private."
*External global unicast address*: A globally routable address
presented to clients on the Internet, often via load balancers or
anycast.
Unlike IPv4, nodes typically have multiple IPv6 addresses assigned to
each of their interfaces. The link-local addresses are necessary to
participate in Neighbor Discovery and so serve a vital purpose even
though they are not globally routable. Additionally, because so many
IPv6 addresses are available, some machines may use multiple global
addresses simultaneously for purposes such as privacy or temporary
use.
2.6. Address Representation
IPv6 addresses have several equivalent textual forms [RFC4291]:
* Full form: 2001:db8:0:0:0:0:0:1
* Compressed zeros: 2001:db8::1
Martin Expires 19 January 2027 [Page 8]
Internet-Draft deploying-ipv6-data-center July 2026
* Loopback: ::1 (compare IPv4 127.0.0.1)
* Unspecified: ::
* IPv4-mapped IPv6: ::ffff:192.0.2.1
In *dual-stack* environments, IPv4 addresses also appear in multiple
forms in code and configuration:
* Dotted decimal: 192.0.2.1
* Integer (historical APIs): 3232235521
* Hex packed in configs: 0xC0000201
* Mapped in IPv6 APIs: ::ffff:192.0.2.1
In software, addresses MUST be stored in a *binary field or structure
sized for 128 bits* (for example, in6_addr, sockaddr_storage, or an
equivalent language type), so the same field can hold IPv4 or IPv6.
*Do not store addresses as strings* in databases, logs-as-data,
caches, or message payloads. Provide helper functions to convert
between the binary form and a human-readable representation for
display and configuration I/O, and use those helpers at boundaries
--- *never parse or compare address strings ad hoc* in application
logic. When addresses are handled as data (logging, ACLs, management
output), test that code accepts all valid representations [RFC4291]
and renders canonical text [RFC5952];
[I-D.ietf-v6ops-ipv6-app-testing] covers this "addresses as data"
testing.
Applications SHOULD treat names, not literal addresses, as the stable
interface (see Section 2.9). To turn a name into addresses, use the
APIs described in Section 13 --- not legacy one-address helpers and
not string parsing.
2.7. Prefix Length and the /64 Convention
On most LANs and data center segments, the *network/host split is at
the 64th bit* --- a /64 prefix on the wire [RFC4291]. Roughly
speaking, a /64 is the IPv6 analogue of an IPv4 /24 in terms of "one
subnet per broadcast domain," though the address space is vastly
larger. A good data center pattern assigns a */56 per host* so each
container can receive its own */64* (see Section 8.1).
2.8. Link-Local Gateways
A good practice is to place the default gateway at *fe80::1* on each
link. That choice avoids consuming a global address for the router
and matches common vendor examples. Servers MUST specify the
outgoing interface when using link-local next hops (for example, ip
-6 route add default via fe80::1 dev eth0). The router platform MUST
actually configure fe80::1 on the expected interface.
Martin Expires 19 January 2027 [Page 9]
Internet-Draft deploying-ipv6-data-center July 2026
2.9. Naming Services
::1 is localhost; 127.0.0.1 is localhost. *Do not embed IP addresses
in application code* when a name will do --- especially for *listen/
bind* targets. Use hostnames and service discovery; resolve names at
connection time. Clients that connect to 127.0.0.1 remain acceptable
where IPv4 loopback stays on lo (see Section 12.4).
DNS (or an equivalent naming and service registry) becomes
*essential* in IPv6 because humans cannot memorize 128-bit addresses.
Operational maturity includes forward and reverse DNS for
infrastructure, health checks keyed on names, and monitoring that
labels series by hostname rather than by address literals.
3. Part I: Running the Migration
4. Transition Strategies
4.1. Easier to Provision Than to Transform
*It is easier to provision IPv6 correctly than to transform a running
service.* Enabling dual-stack or IPv6-only on a server, container, or
service that was deployed IPv4-only means changing addresses, ACLs,
DNS, health checks, and often application configuration --- then
*restarting in place* and hoping nothing was missed. Provisioning
time already runs those checks, supports canary or phased ramp-up,
and catches failures before the service takes production traffic.
Teams SHOULD treat every *new service*, *new software version*, and
*rewrite of an existing application* as an opportunity to ship
*IPv6-only on internal interfaces* from the start (see Section 8.5),
with *dual-stack only where external reachability requires it*,
rather than cloning an IPv4-only template and scheduling conversion
later. Brownfield conversion remains necessary for legacy estates,
but the default for greenfield work SHOULD NOT be "IPv4 now, IPv6
someday."
4.2. IPv4-Only Exceptions and Remediation Plans
The business will sometimes *require an IPv4-only product, service,
or technology* --- a vendor constraint, acquisition, regulated
workload, or time-to-market trade-off. Business goals matter, but
*IPv4-only dependency SHOULD NOT be discovered only after full
production adoption*, when rollback is expensive and the migration
program has already assumed dual-stack or IPv6-only readiness.
Martin Expires 19 January 2027 [Page 10]
Internet-Draft deploying-ipv6-data-center July 2026
*Default to hard failure on missing IPv6 early* in inventory, CI,
dependency gates, and synthetic checks (see Section 5 and Section 12)
so non-compliant software surfaces before it reaches tier-1 paths.
Where IPv4-only is genuinely required, use a *formal exception
process* --- the same discipline security teams apply to policy
waivers:
* *Record the business reason* for IPv4-only adoption and who
approved it.
* *Require a remediation plan* --- path to dual-stack, IPv6 support,
or replacement --- with *milestones and a target date*.
* *Track progress* in the same service catalog and dashboards used
for migration metrics; exceptions SHOULD expire or be renewed on
review, not roll forever.
* *Flag dependents* so downstream teams know they are building on a
known exception.
An approved exception MAY permit production use of IPv4-only software
for a bounded period; it MUST NOT be an informal verbal waiver.
Review open exceptions in change advisory or migration governance the
same way security reviews open risk acceptances --- stale plans
become blockers again when dates slip without an updated timeline.
4.3. IPv6-Only Jump Hosts
Moving to IPv6 is not only a routing change --- it requires a
*cultural shift* for SREs and SWEs who have spent years assuming IPv4
literals, RFC 1918 mental models, and IPv4-first tooling. *Make that
shift visible before emergencies:* IPv6-only jump hosts, IPv6-first
runbooks, and labeled lab networks teach the new defaults while
change windows are calm. Engineers under incident pressure *do not
have time to learn IPv6 idioms*; if the first time they need dig -x
on an ip6.arpa name or SSH over a global v6 management address is
during a sev-1, the organization has already failed the migration
program.
A practical staged transition puts *administrative jump hosts on
IPv6-only* access while leaving application tiers dual-stack
temporarily. Engineers run configuration management, monitoring CLI
tools, and break-glass SSH from those hosts, forcing administrative
tooling onto IPv6. Maintain at least one *dual-stack backup jump
host* during migration and *audit who connects and which commands
run* until parity is proven.
Temporarily *reducing IPv4 SSH session timeouts* on jump hosts can
accelerate detection of accidental IPv4 dependency without blocking
emergency access.
Martin Expires 19 January 2027 [Page 11]
Internet-Draft deploying-ipv6-data-center July 2026
Apply the same staged exposure to *corporate wireless*, not only SSH
bastions. Provide *dual-stack Wi-Fi* for everyday employee devices
during migration, and at least one *IPv6-only employee Wi-Fi* SSID so
laptops, phones, VPN clients, and captive-portal flows are exercised
on AAAA-only paths before production depends on them. Label SSIDs
explicitly (for example, corp-dualstack and corp-v6-only) so
engineers know which network they joined.
Some operators MAY additionally offer *IPv6-only guest Wi-Fi* --- for
example in lab, conference, or vendor demo areas --- so external
teams can demonstrate that hardware and software work without IPv4
fallback during evaluations and acceptance testing. That network
SHOULD be clearly marked, rate-limited, and isolated from internal
management zones; it complements jump hosts but does not replace them
for break-glass administration.
5. Observability and Metrics
IPv6 migration needs *inventory plus measurement*: a service list
with IPv6 readiness labels, automated discovery of what is missing
from that list, and time-series metrics that show progress toward
dual-stack or IPv6-only targets.
5.1. Service Inventory and Discovery
The inventory in Section 12 MUST list every application and platform
component with a readiness state (for example: IPv6-only ready, dual-
stack, IPv4-only, unknown). Inventory alone is not enough ---
operators SHOULD run periodic *discovery* that compares running
processes, container images, load balancer pools, and DNS names
against the catalog and *flags unregistered services*. Shadow
deployments and shared hosts routinely run software that no team has
classified.
5.2. Progress Metrics
Dashboards SHOULD expose fleet-level indicators, for example:
* Percentage of services *IPv6-only*, *dual-stack*, or *IPv4-only*
(by count and by criticality tier)
* Trend of *AAAA vs A-only* DNS names for production hostnames
* Ratio of *ingress bytes or connections* over IPv6 vs IPv4 at load
balancers
* Count of hosts or pods *without any IPv6 address* in IPAM or
configuration management
Set explicit targets (for example, "90% of tier-1 APIs dual-stack by
Q4") and review the same metrics in change advisory boards.
Martin Expires 19 January 2027 [Page 12]
Internet-Draft deploying-ipv6-data-center July 2026
5.3. Dual-Stack Regression and Hard Failures on IPv6
Dual-stack is a valuable migration step, but *without monitoring it
invites regression*. A service that passed dual-stack testing can
*stop working on IPv6* after an unrelated code push --- for example,
a new dependency, a changed bind address, or a refactored HTTP client
that silently prefers IPv4. Unmonitored dual-stack fleets often
*mask* such regressions because IPv4 still succeeds.
*Treat IPv6 failures as hard failures as soon as policy allows* ---
alert on IPv6-only health checks, IPv6 listen-socket regressions, and
rising IPv4-only connection share for tier-1 services. Where
production remains dual-stack, synthetic probes SHOULD exercise *IPv6
explicitly* (AAAA-only paths, IPv6 literal targets, or IPv6-only test
clients), not only dual-stack clients that can hide breakage.
[I-D.ietf-v6ops-ipv6-app-testing] describes client-, server-, and
network-based tracing strategies that distinguish genuine IPv6-only-
strict behavior from dual-stack masking. The sooner IPv6 errors page
on-call the same way IPv4 errors do, the less likely a team discovers
IPv6 rot months later during an IPv4 decommissioning drill.
Approved *IPv4-only exceptions* (see Section 4.2) are the controlled
counterpart to this policy: hard failure is the default; a documented
waiver with remediation timeline is the escape hatch, not silent
dual-stack masking.
5.4. Host-Level Listen-Socket Audit
On each host, collect which services *listen on IPv4-only*,
*IPv6-only*, or *dual-stack*. On Linux, ss -tulnp (or /proc/net/tcp
and tcp6) is the usual source, but classification is *non-trivial*:
* Separate tcp/udp vs tcp6/udp6 lines are often *IPv4-only* vs
*IPv6-only* listeners.
* A single IPv6 socket with IPV6_V6ONLY=0 may accept IPv4-mapped
traffic without a matching tcp line --- treat as *dual-stack* only
after checking socket options or process documentation.
* Match rows by *PID, port, and inode* when correlating multiple
lines for one daemon; export a normalized label (v4-only, v6-only,
dual-stack, unknown) for metrics.
Run this audit on a schedule and on every deploy; alert when a tier-1
service regresses to IPv4-only.
Martin Expires 19 January 2027 [Page 13]
Internet-Draft deploying-ipv6-data-center July 2026
5.5. Host Agents Before Application Provisioning
Before any application software is installed, *inventory every agent
and daemon already running on the host* --- configuration management,
monitoring, log shippers, vulnerability scanners, *EDR*, host
firewalls, and other platform packages the fleet image includes by
default. These components often *bind IPv4-only*, ship IPv4-only
policy from a central console, or break when the host loses IPv4 even
if the workload you plan to deploy is IPv6-ready.
Run this baseline check on *golden images and freshly provisioned
servers*, not only on production services. A host cannot safely move
to dual-stack or IPv6-only if an unknown agent still requires *IPv4
loopback for listening* (that is, it binds only on 127.0.0.1 while
IPv6-only local clients must connect), RFC 1918 reachability, or
IPv4-only reporting to its controller. *IPv4 loopback on lo itself*
--- including clients that dial 127.0.0.1 --- is expected to remain
on many platforms (for example Linux, where IPv4 cannot be disabled
in the kernel) and is not the same as routable IPv4 on application
interfaces. Export agent name, version, listen sockets (see above),
and *IPv6 readiness* into the same catalog as Section 12. Re-run
when the image or security baseline changes.
5.6. Traffic by Protocol and Address Family
Switches and routers expose *IPv4 and IPv6 packet counters* but often
*do not break out TCP and UDP by IP version* (TCPv4 vs TCPv6, UDPv4
vs UDPv6). Where the platform allows, collect *tcp4/udp4 vs tcp6/
udp6* (or equivalent flow records) on hosts, hypervisors, and top-of-
rack devices. Application SREs need *L4 metrics split by address
family* to confirm traffic is migrating and to find stragglers still
on IPv4-only or translated paths.
Log pipelines SHOULD record address family explicitly (AF_INET vs
AF_INET6) rather than inferring from string shape.
5.7. HTTP Signaling and Planned IPv4 Drills
For HTTP services, implementing HTTP Signaling of Planned IPv4
Unavailability (https://datatracker.ietf.org/doc/draft-martin-retry-
over-ipv6/) (566 responses, Retry-Over-IPv6, and related headers)
gives *measurable signals* during planned IPv4 outages: count 566
responses, soft vs hard failures after IPv6 retry, and clients still
hitting IPv4. That data belongs on the same dashboards as listen-
socket and byte-ratio metrics when rolling out dual-stack or
IPv6-only frontends.
Martin Expires 19 January 2027 [Page 14]
Internet-Draft deploying-ipv6-data-center July 2026
5.8. Live Traffic and Service Call Trees
Inventory and socket audits show *what could* run on IPv6; live
traffic shows *what does*. Instrument outbound and inbound
connections (service mesh, eBPF, proxy access logs, or APM) to tag
each hop with *address family*. Roll those tags into a *call tree or
dependency graph per service* so teams see, for example, "API gateway
is dual-stack but 80% of backend calls still use IPv4" or "this batch
job is IPv4-only despite an IPv6-ready binary."
Use call-tree family breakdown to prioritize refactors: fix the
highest-volume IPv4-only edges first. Reconcile call-tree findings
with the inventory --- a service marked "IPv6 ready" with no IPv6
traffic is not done. [I-D.ietf-v6ops-ipv6-app-testing] describes
decomposing complex, multi-service cloud applications into per-flow
test cases, matching this per-hop view.
6. Part II: Building the IPv6 Data Center
7. Out-of-Band Management and Network Boot
Software readiness is insufficient if servers cannot be *installed,
booted, or power-cycled* over IPv6. This area *SHOULD be tackled
very early* in an IPv6 program --- before application tiers ---
because *hardware refresh cycles can take up to five years*. A server
bought today with an IPv4-only baseboard management controller (BMC)
or provisioning stack may still block IPv6-only operation long after
application code is ready.
7.1. Often-Forgotten Infrastructure Devices
Out-of-band work is not limited to compute *IPMI*, *Redfish*, and
*PXE*. Teams routinely overlook *facility and operations gear* that
shares the same management VLANs and must be reachable during
incidents:
* *UPS* and power distribution monitoring
* *Climate control* (CRAC, chillers, environmental sensors)
* *NTP* appliances or stratum servers on dedicated hardware
* *Console servers* and serial concentrators
* *KVM switches*, rack PDUs, and other *data center infrastructure
management* devices
These systems often ship with *fixed IPv4-only interfaces*, embedded
web UIs bound to 192.168.x.x, and long firmware cadences. Include
them in the same IPv6 readiness inventory as production servers (see
Section 12 and Section 5); they become blockers during IPv4
decommissioning even when every application pod is dual-stack.
Martin Expires 19 January 2027 [Page 15]
Internet-Draft deploying-ipv6-data-center July 2026
7.2. Firmware and PXE/UEFI Boot
Many *BIOS* implementations still lack usable IPv6. *UEFI network
boot* over IPv6 exists but *varies by server vendor* in ways that
affect automated provisioning. Network appliance *EFI*
implementations are similarly inconsistent. An IPv6-only
provisioning VLAN requires explicit qualification of every hardware
generation in the fleet.
7.3. IPMI and Redfish
*IPMI over IPv6* is *essential* for *remote power cycle and reboot*
when management networks move to IPv6-only. Without a working BMC
address on v6, automation cannot recover a hung host without a
physical visit. The same requirement applies to the *provisioning
and reboot toolchain* --- imaging, PXE/UEFI orchestration,
configuration management kickstart, and out-of-band serial
concentrators SHOULD be *dual-stack or IPv6-only capable* before
internal management VLANs drop IPv4.
*IPMI* and *Redfish* IPv6 support differs by vendor and firmware
generation: some platforms support SLAAC, others DHCPv6, others
require initial IPv4 configuration before enabling IPv6. Linux
ipmitool subcommands and output formats vary with firmware.
Enterprises often *defer firmware upgrades* because failed BMC
updates require physical data center visits --- plan IPv6 on
management networks with spare in-rack capacity and conservative
change windows.
8. Internet and Data Center Addressing
Network teams assign prefixes; SREs consume them in orchestration
templates, container runtimes, and firewall tickets. This section
covers patterns that reduce outages during rollout.
8.1. Prefix Allocation for Hosts and Containers
A common data center pattern assigns a */56 to each physical host*
(or rack entity), providing *256 /64 subnets* --- one /64 for the
host itself and up to *255 /64 prefixes* for containers, virtual
machines, or Kubernetes pods. Each container MAY receive a full
*/64*, not a longer prefix carved out of a single host /64. Routing
between /64 islands replaces NAT for east-west traffic and avoids
CGNAT-style visibility loss in flow logs. Assigning only a */64 per
host* (or per rack entity without further delegation) is *often
insufficient* when multiple containers each need their own address
space; request a */56 (or shorter)* delegation from the network team
instead. In a *closed data center* with explicit routing and no
Martin Expires 19 January 2027 [Page 16]
Internet-Draft deploying-ipv6-data-center July 2026
SLAAC on container segments, some designs assign one */64 per
physical host* and carve */72 (or longer) subnets* from that host
prefix for container tiers. That pattern is *not* suitable on the
public Internet or where hosts expect standard /64 semantics; use it
only with operator-wide agreement and tested CNI or orchestrator
support.
The exact mapping depends on orchestrator and CNI design; the
important software lesson is that *each tier needs an explicit prefix
plan* rather than assuming "one address per host" as in legacy IPv4
NAT designs.
These patterns assume an *operator-controlled* data center fabric
where the network team can delegate prefixes freely. In *hybrid*
environments that connect on-premise fabric to public cloud (see
Section 10), operators MAY choose different prefix plans so numbering
stays consistent across sites. Cloud providers impose subnet sizes,
delegation limits, and aggregation rules that cannot be changed from
the data center alone; mirroring (or mapping cleanly to) those
conventions on bare metal MAY simplify IPAM, ACLs, and runbooks even
when a strict /56-per-host layout would otherwise be preferred
locally. The right trade-off depends on connectivity model,
orchestrator, and how much of the estate shares addressing with cloud
virtual networks. This document does not enumerate cloud or IaaS
offerings; it focuses on networks the operator controls directly.
Kubernetes clusters often use eBPF-based service NAT on the node.
Traditional Linux tools (ss, /proc/net/tcp) may show node-level
sockets, not pod-level flows, when NAT is involved. IPv6 routing
reduces NAT use --- which also *reduces the complexity inherent in
NAT when tracing connections* --- but *does not remove the need for
observability hooks* at the CNI layer.
8.2. Static Addressing, Router Advertisements, and IPAM
Enterprise data centers usually prefer *static addresses* from an IP
Address Management (IPAM) system over SLAAC-derived random interface
identifiers. Disable *Router Advertisements (RA)* on server-facing
*switch ports* (for example by clearing the *Managed* and *Other*
flags) *and* disable *SLAAC* on *servers and other endpoints* when
static addressing is required. Applying both controls --- at the
*network edge and on the host* --- provides *two layers of
protection* so hosts do not acquire unexpected addresses alongside
provisioned ones.
Gateway at *fe80::1*, global addresses from IPAM, and DNS names
registered in forward and reverse zones should be one coordinated
change set.
Martin Expires 19 January 2027 [Page 17]
Internet-Draft deploying-ipv6-data-center July 2026
8.3. Semantic Prefixes for Internal Traffic
On IPv4, operators quickly tell *internal from Internet* traffic: RFC
1918 space such as 10.0.0.0/8 and 192.168.0.0/16 signals "inside the
organization" in logs, captures, and mental models [RFC1918]. On
IPv6, most data center addresses are *global unicast* --- there is no
automatic "private vs public" heuristic. Debugging and ACL writing
become harder unless the site *designates a small set of well-known
aggregates* in IPAM and teaches SREs to use them.
A practical pattern is to carve *one prefix for each operational
class*, for example:
* *Everything in the data center* --- one aggregated prefix (the
exact length depends on fleet size; a /26 under the site GUA is an
example when the block is purely semantic and routing summarizes
wider internally)
* *Everything employees* --- corporate VPN, office wired/wireless
for staff
* *Everything guest Wi-Fi* --- captive portal and untrusted clients
SREs then remember *three networks*, not hundreds of /64s, when
filtering pcaps, writing runbooks, or explaining an incident.
Document these prefixes in the same place as Section 8.1 and
Section 8.7 rules so logs, firewall objects, and monitoring use
consistent names (dc-internal, corp-employee, guest-wifi).
*Internal data center prefixes SHOULD NOT be announced or routed to
the Internet.* When addresses are global unicast, *routing policy* at
the edge SHOULD filter site-internal aggregates so they remain
reachable only inside the operator network. Operators MAY suppress
these GUA prefixes from BGP advertisements if permitted by the
relevant RIR and if such exclusion does not cause unnecessary prefix
de-aggregation. That routing boundary adds *defense in depth* on top
of firewalls: a misconfigured ACL or leaked route is less likely to
expose internal infrastructure to the public Internet.
Monitoring, security analytics, and log UIs SHOULD let operators
*assign visible colors or tags to semantic prefix ranges* --- for
example, external (Internet-facing) addresses in one color, data
center internal prefixes in another, and corporate or employee VPN
ranges in a third. The exact palette is operator choice; the goal is
instant recognition in dashboards, alerts, and pcap summaries without
parsing every /64.
Martin Expires 19 January 2027 [Page 18]
Internet-Draft deploying-ipv6-data-center July 2026
8.4. Internet Egress and Edge Gateways
On IPv4 it is often convenient to give a data center host Internet
access via *NAT44* (or operator CGNAT) on a central device. That
pattern *SHOULD NOT be copied onto IPv6 hosts* --- do not deploy ad
hoc *NAT66* or per-server masquerading so internal servers "hide"
behind random IPv6 ports. Internal hosts SHOULD reach the Internet
through a *gateway at the edge* (border router, firewall, or
dedicated translation cluster) with explicit policy and logging.
That edge model still helps when an *IPv6-only server* must reach an
*IPv4-only Internet service*: the server sends IPv6 to the edge; the
gateway performs *NAT64* or protocol translation [RFC6146] (and DNS64
where needed) on the way out. Translation is *centralized,
observable, and rate-limited* --- not duplicated on every app host.
8.5. Internal vs External: Where IPv6-Only Applies
A practical *IPv6-only data center* usually means *IPv6-only on
internal interfaces and east-west paths*, not on every interface
facing the outside world. The *Internet is not yet ready for an
IPv6-only-only edge*: clients, transit, partners, and operator
tooling still expect *dual-stack* (or IPv4 fallback) on *external*
interfaces --- load balancers, border routers, VPN concentrators, and
customer-facing anycast fronts.
This document uses "IPv6-only," "dual-stack," and related terms
informally for deployment context. For precise, testable definitions
of the connectivity scenarios --- *IPv4-only*, *dual-stack*,
*IPv6-only with NAT64*, and *IPv6-only-strict* (no IPv4 connectivity,
encapsulated or translated) --- see [I-D.ietf-v6ops-ipv6-app-testing]
and the terminology in [I-D.ietf-v6ops-ipv6-only]. Aligning
verification with those scenarios keeps this deployment guidance
consistent with application-side IPv6 testing.
Plan accordingly:
* *Inside the data center:* servers, containers, and service-to-
service traffic SHOULD move to *IPv6-only* (or IPv6-primary) on
internal VLANs and /64 islands as readiness allows.
* *At the edge:* *external interfaces SHOULD remain dual-stack*
until IPv4 dependency is gone for your user base and upstream
paths. The edge gateway performs translation when an internal
IPv6-only host must reach IPv4-only destinations (see above).
*Dual-home servers on the edge* --- one *internal* interface
(IPv6-only or IPv6-primary) and one *external* interface (dual-stack)
--- simplify *administration and break-glass access*: operators and
Martin Expires 19 January 2027 [Page 19]
Internet-Draft deploying-ipv6-data-center July 2026
automation can reach management paths on the internal v6 network
while the service still serves dual-stack Internet clients. Document
which interface is which in IPAM and host naming; do not collapse
"internal v6-only" and "external dual-stack" into a single ambiguous
address on production boxes. During migration, the internal
interface may remain *IPv4-only* for a time; see Section 8.5.1 for
routing and DNS pitfalls on those hosts.
8.5.1. Dual-Homed Hosts During Internal IPv6 Rollout
Edge servers often have *two interfaces*: an *external* interface
toward the Internet (dual-stack, *default route*) and an *internal*
interface toward the data center (today *IPv4-only*, with *more-
specific routes* for internal prefixes). That layout is common
during brownfield migration before the internal VLAN gains IPv6 on
every host.
When internal services begin publishing *AAAA* records, a dual-homed
host that still has *no IPv6 on the internal interface* may resolve
both A and AAAA for an internal name but send IPv6 connection
attempts out the *default route* on the external interface. Those
packets never reach the internal service. Symptoms include *long
timeouts* on dual-stack clients, flaky automation, and "internal DNS
works from other hosts but not from the edge box."
Operators SHOULD align *routing policy with DNS*, not assume AAAA
implies a working IPv6 path from every interface:
* *Preferred long-term:* enable IPv6 on the internal interface and
install *scoped routes* (or policy routing) so internal GUA
prefixes egress the internal interface (see Section 8.3).
* *Transitional mitigation:* while the internal NIC remains
IPv4-only, install an *unreachable* route for the site *internal
IPv6 aggregate* on the host (for example, the dc-internal prefix
from Section 8.3). The kernel then rejects connection attempts to
internal AAAA addresses *immediately* with a local "no route to
host" error instead of forwarding them via the Internet default
route. Clients that iterate all resolved addresses --- or use
Happy Eyeballs [RFC8305] --- can fall back to the *A* record over
the internal IPv4 path (see Section 13). Do *not* use a
*blackhole* route for this purpose: blackhole *silently discards*
packets and recreates the same *timeout* behavior the operator is
trying to avoid.
* *Alternative:* *split-horizon DNS* so resolvers used on edge hosts
do not return AAAA for names that are reachable only on the
internal IPv4 path until routing is fixed.
Martin Expires 19 January 2027 [Page 20]
Internet-Draft deploying-ipv6-data-center July 2026
This pattern is *not* a substitute for enabling IPv6 on internal
interfaces; it prevents *misrouted IPv6* during rollout. Application
code that stops after the first address (gethostbyname(),
InetAddress.getByName(), and similar) *will not benefit* --- fix
routing *and* resolution behavior together.
Example (Linux, illustrative prefix):
ip -6 route add unreachable 2001:db8:dc::/48
Express the same policy in configuration management on every dual-
homed edge role during the transition; remove the unreachable route
when the internal interface is dual-stack and correct scoped routes
are in place.
8.6. Frontends for IPv4-Only Services
Legacy applications that remain *IPv4-only* SHOULD NOT be exposed
directly to dual-stack or IPv6-only clients. Surround them with a
*gateway tier* --- for example *nginx*, *HAProxy*, or a service-mesh
ingress --- that accepts *IPv6 (and IPv4 if required)* on the front
side and speaks IPv4 only to the backend. Clients see a normal
v6-capable service name; the IPv4-only binary stays on an internal
path until it is rewritten or replaced (see Section 4.1).
In dual-stack deployments where session persistence is required, SREs
MUST verify that the gateway tier preserves session continuity across
both IPv4 and IPv6. Implementations that maintain separate
persistence state for each address family may experience session loss
when clients alternate between IPv4 and IPv6.
An alternative on the host is *NAT64 implemented with eBPF* (similar
in spirit to Kubernetes node NAT). That can unblock a single service
quickly but *often does not scale* as a fleet-wide strategy ---
connection state, troubleshooting, and upgrade churn multiply with
every host doing translation. Prefer a *small number of shared
frontends or edge translators* over per-host NAT64 except in
controlled exceptions. See also Section 11 for VPN and middlebox
interactions with translated traffic.
8.7. Access Control List Propagation
When IPv6 is added to a service that already runs on IPv4, *firewall
and ACL automation may lag by minutes*. During that window the
service can appear *healthy on IPv4 but broken on IPv6*, or reachable
in one direction only. SRE runbooks SHOULD treat "IPv6 enabled on
the host" and "IPv6 permitted end-to-end" as separate checklist
items. Do not announce IPv6 on a load balancer until policy
Martin Expires 19 January 2027 [Page 21]
Internet-Draft deploying-ipv6-data-center July 2026
propagation completes. Application-level IP allow and deny lists are
a related deployment risk: enabling IPv6 can shift clients onto
addresses missing from the list, causing service disruption;
[I-D.ietf-v6ops-ipv6-app-testing] discusses testing for this before
rollout.
Software teams SHOULD NOT create entirely new ACL models per address
family when the same role-based policy can express both; parallel
rule sets double drift risk. Where separate rules are unavoidable,
generate them from the same source of truth.
8.7.1. IPAM-Based IPv4-to-IPv6 Mapping for ACLs
When IPAM tracks both address families, operators can *derive a
predictable IPv6 address from a hostname* before an AAAA record
exists in DNS. That mapping lets ACL and firewall systems publish
*IPv6 rules in advance*, so policy is already in place when the
service starts listening on IPv6 --- there is no window where the
host is up on IPv6 but ACL automation is still catching up.
This pattern *requires ACL policy to be expressed by hostname (or
role)*, not by scattered literal addresses maintained separately per
family. Given a hostname, a controller can resolve or derive
addresses with the following *pseudo-rules*:
1. Look up the *AAAA* record. If present, use that IPv6 address.
2. If no AAAA exists, look up the *A* record and obtain the IPv4
address.
3. In IPAM, find the *IPv4 network* that contains that address.
4. Find the *associated IPv6 network* paired with that IPv4 network
in IPAM.
5. *Embed the IPv4 address* into the IPv6 network according to the
site's translation plan (for example, a fixed nibble layout or
well-known offset). The result is the *predicted IPv6 address*
for that hostname.
The benefit is operational: *ACLs for IPv6 can be built and deployed
everywhere before DNS advertises AAAA*, because the IPv6 address is
computable from the same hostname and IPAM data already used for
IPv4. When the service later enables IPv6 and the AAAA is published,
the pre-provisioned rules should match without a second ACL rollout.
The site translation plan in step 5 MUST be documented and stable; ad
hoc embedding layouts defeat this approach.
The same correlation policy supports an *early dual-stack step on the
host* without advertising *AAAA* in DNS. IPAM assigns the predicted
IPv6 address on the interface; the application tier can remain
*IPv4-only* (A record only, IPv4 listen sockets) while *outbound*
Martin Expires 19 January 2027 [Page 22]
Internet-Draft deploying-ipv6-data-center July 2026
traffic from the host uses IPv6. That lets platform agents ---
configuration management, monitoring, log shippers, vulnerability
scanners, and other infrastructure daemons (see Section 5.5) ---
reach *IPv6-only* services on the fabric before application code is
ready. Inbound clients still use IPv4 until a deliberate cutover
adds AAAA and dual-stack or IPv6-only listeners; pre-provision ACLs
and routing for the predicted v6 address using the steps above.
If ACL systems cannot accept hostnames and expand them through this
logic, teams fall back to the lag problem described above --- IPv6
goes live while firewall tickets are still in flight.
9. DNS Registration and Dynamic Addressing
IPv6's default autoconfiguration (SLAAC) generates addresses from
interface identifiers. Without operational discipline, *DNS lags
behind actual addresses*, and break-glass access by name fails.
9.1. SLAAC, Switches, and the DNS Gap
Wi-Fi controllers often integrate with DNS to register client names;
*access switches frequently do not*. To populate DNS for wired
servers using SLAAC, operators need *MAC and address visibility* from
switches (for example, via Neighbor Discovery logging or sFlow/IPFIX)
correlated with inventory to derive hostnames. Ideally, selected
*Neighbor Discovery events* would be exported to a registration
service --- a gap in many switch implementations.
9.2. DHCPv6 and Hostname Registration
Enterprises that distrust client self-registration prefer *DHCPv6*
with central lease logging. Clients SHOULD send *DHCPv6 Option 39
(Client FQDN)* so the server can register forward and reverse DNS
[RFC4704] [RFC8415]. Support for Option 39 has varied by OS;
operators SHOULD verify current behavior on every deployed OS image
(including macOS, Windows, Linux, and container base images) rather
than assuming parity.
Device-side *Dynamic DNS updates* remain possible but are often
disabled in enterprise policy. For why reverse zones matter during
incidents, see Section 15.
Martin Expires 19 January 2027 [Page 23]
Internet-Draft deploying-ipv6-data-center July 2026
9.3. DHCPv6 Suitability Considerations
DHCPv4 is extremely common in IPv4 deployments, as it is best
mechanism to automatically provide network information (such as IP
address, router, netmask, recursive DNS resolvers) to nodes. This,
combined with a desire to have centralized logging of assigned
addresses, leads to a desire for DHCPv6 in new IPv6 deployments.
However, IPv6 includes much of this functionality in the base
protocol; a central server is not needed. Moreover, operating system
support for DHCPv6 is not as universal as for DHCPv4, so it is not a
full replacement for SLAAC. This means that using DHCPv6 for
centralized logging of addresses or DNS synchronization either means
that some clients may be logged (as they will use SLAAC), or some
clients may not work at all (if SLAAC is disabled on the network).
Operators SHOULD verify DHCPv6 support for all existing and planned
hardware before relying on it for logging features.
10. Hybrid On-Premise and Cloud Environments
This section is *in scope* for operator-owned data centers that
*connect to* public cloud; it is *not* a guide to replacing the data
center with IaaS or to running production workloads *inside*
provider-controlled virtual networks. Native IPv6 deployment on AWS,
Azure, GCP, or other platforms belongs in provider documentation or a
separate document --- prefix sizes, subnet models, managed services,
and control-plane IPv6 support differ by vendor, region, and SKU in
ways no single recommendation can capture. The material below *does*
matter for on-premise migration: cloud dependencies, private
connectivity, and provider IPv6 gaps routinely block or reshape
IPv6-only programs on operator-managed fabric even when compute stays
in the physical data center.
Most enterprises are not pure on-premise: data centers connect to
*public cloud* providers (AWS, Azure, GCP, and others) for burst
capacity, managed services, disaster recovery, and SaaS integration.
*IPv6 support across cloud control planes and managed services is
seldom complete* --- capabilities differ by provider, region, SKU,
and release. Hybrid gap analysis belongs in *Part I inventory and
early program planning*, not a discovery phase after the on-premise
fabric is already IPv6-only.
10.1. Connectivity Models
Migration design *depends on how on-premise reaches cloud*:
* *Centralized gateway or cloud edge* --- on-premise workloads reach
cloud APIs and resources through a *narrow path*: site-to-site
VPN, Direct Connect, ExpressRoute, Cloud Interconnect, transit
Martin Expires 19 January 2027 [Page 24]
Internet-Draft deploying-ipv6-data-center July 2026
gateway, or operator translation at the border (see Section 8.4).
IPv6 may terminate at that gateway; an internal v6-only host might
reach cloud only via a dual-stack hub or translation. Prefix
plans, ACLs, DNS views, and observability probes must anchor on
that *choke point*.
* *Direct or flat hybrid routing* --- on-premise and cloud workloads
share *routable reachability* (extended L3, cloud CIDRs advertised
into the DC, cross-site service mesh). *Any host may connect to
any cloud instance* on the allowed paths; IPv4 and IPv6 *must both
be validated end-to-end*, including cloud VPC/VNet IPv6 CIDRs,
security groups, network ACLs, private endpoints, and on-premise
firewall policy.
Document which model each environment uses *before* declaring
internal IPv6-only. A data center that is v6-only on the fabric but
cloud-connected only through an *IPv4-only VPN or private link* still
depends on translation or exceptions at the edge --- a common hidden
blocker.
10.2. Cloud Provider Gap Analysis
Cloud portfolios change frequently. Operators SHOULD maintain a
*provider-specific IPv6 matrix* for every service in use --- compute,
load balancing, databases, object storage, key management, logging,
identity, managed Kubernetes control planes, firewalls, WAF,
PrivateLink-style endpoints, and inter-region peering --- with
*supported / partial / unsupported / unknown* labels and notes on
*region, tier, and verification date*.
*Identify blockers early:* review architecture diagrams and
infrastructure-as-code for implicit IPv4 assumptions (RFC 1918-only
security groups, IPv4 health checks, managed endpoints without AAAA,
IPv4-only egress appliances). Open *provider support cases and
feature requests* as soon as a required service lacks IPv6 ---
enterprise cutover dates cannot wait for roadmap surprises discovered
in production. Where IPv6 exists only in select regions or SKUs,
record that constraint in the inventory and use Section 4.2 when the
business must stay on IPv4-only cloud paths temporarily.
10.3. Cloud as Platform Software
From the data center team's perspective, *cloud is platform software
the business cannot fully control* --- APIs, quotas, and feature
availability change on the provider's schedule. Apply the same
discipline as Section 12: list each cloud dependency in the fleet
inventory, assign IPv6 readiness labels, and *raise gaps before
platform adoption*, not after teams have built on IPv4-only managed
services.
Martin Expires 19 January 2027 [Page 25]
Internet-Draft deploying-ipv6-data-center July 2026
Hybrid programs SHOULD include *cloud account and landing-zone
reviews* in the same governance cadence as on-premise migration
metrics (see Section 5). A service marked "IPv6-ready on-premise"
that calls an *IPv4-only cloud API* or runs on an *IPv4-only managed
control plane* is not ready for internal v6-only operation. Treat
cloud like any other long-lead vendor: inventory, support tickets,
and exception tracking SHOULD start at program kickoff.
11. ICMPv6, PMTUD, and Middleboxes
11.1. Do Not Block ICMPv6
Teams trained to block ICMPv4 "for security" sometimes apply the same
policy to ICMPv6. *ND and PMTUD depend on ICMPv6* [RFC4443]
[RFC8201]. Blocking ICMPv6 produces hung connections, mysterious TLS
timeouts, and DNS failures that are misdiagnosed as application bugs.
Filter *specific message types* judiciously; do not implement blanket
deny rules. For *echo request/reply* used in reachability testing
inside the data center, see Section 15.
11.2. Path MTU Discovery
When many organizations enabled IPv6 on their web sites during *World
IPv6 Day* (2011) and *World IPv6 Launch* (2012), *Path MTU Discovery
failures* forced operators to *lower TCP MSS* on servers and load
balancers until paths were validated --- a reminder that IPv6 MTU
assumptions differ from internal IPv4 MTU 1500 end-to-end paths.
Mobile operators (for example, T-Mobile USA and Reliance Jio in
India) run *IPv6-only* access networks successfully at scale;
problems on enterprise fixed networks often come from *middleboxes
and policy*, not from IPv6 itself.
Hard PMTUD failures also interact with *DNS over large responses*
when fragmentation is mishandled. If fragmented UDP is dropped, DNS
appears "flaky" only for some records.
11.3. VPNs and NAT64
Some VPN products treat translated packets as attacks. *NAT64*
[RFC6146] changes headers; a VPN that validates packet integrity on
IPv4 paths may *drop NAT64 flows*. Prefer *edge gateways* for
translation as described in Section 8.4 and Section 8.6 rather than
sprouting translators on every host. Long-term, *VPN endpoints
should be native IPv6* on the data center side. Until then, document
which access paths require IPv4 literal connectivity vs IPv6.
Martin Expires 19 January 2027 [Page 26]
Internet-Draft deploying-ipv6-data-center July 2026
12. Application and Software Readiness
IPv6 deployment exposes software that "worked on the LAN" only
because the LAN was IPv4. This section lists classes of problems
seen in production data centers and enterprise rollouts.
12.1. Enterprise Platform Inventory
Many enterprise platforms still assume IPv4-only access paths.
Examples reported in operator experience include *Hadoop*, certain
*object storage APIs*, *Kubernetes* dependencies (especially third-
party charts and sidecars), *cloud firewalls* (for example, Azure
Firewall and third-party NGFW images on cloud platforms where IPv6
support lagged vendor roadmaps), and *security analytics* pipelines
that ingest NetFlow or packet metadata on IPv4 only. Hybrid and
multi-cloud estates need the same inventory discipline for managed
services and connectivity paths (see Section 10).
*Action for SRE teams:* maintain a *living inventory* of software in
the deployment path (data plane, control plane, CI/CD, security,
logging) with an explicit *IPv6 supported / broken / untested*
classification. Monitoring pipelines SHOULD continuously *discover
services not yet in that inventory* (see Section 5). Security
research or monitoring that runs IPv4-only cannot validate IPv6
attack surface; teams SHOULD require IPv6 parity before accepting "no
IPv6 security issues" claims.
This document does not attempt a canonical vendor matrix --- products
change --- but the inventory practice is mandatory for sane rollout
planning.
12.2. Dependency and Platform Readiness Gates
Many SREs and software engineers *will not* study address
representation, getaddrinfo() semantics, or Happy Eyeballs in depth
--- and should not have to before every deploy. Platform teams
SHOULD publish *monitored readiness gates*: for each shared
dependency (language runtime, HTTP/RPC client, database driver,
messaging library, observability agent, base container image),
document a *minimum version or image tag* validated on dual-stack and
IPv6-only paths. Example gate: _upgrade *example-http-client to
2.4.0 or newer* --- then the service is cleared for IPv6_; versions
below the threshold remain *blocked or flagged* in the inventory
until upgraded.
*Automate enforcement* against that catalog: compare SBOMs,
lockfiles, image scans, and configuration-management reports to the
matrix on a schedule and in CI (see Section 5). When a service
Martin Expires 19 January 2027 [Page 27]
Internet-Draft deploying-ipv6-data-center July 2026
crosses the threshold --- dependency bumped, agent replaced, golden
image refreshed --- *update its readiness label* without requiring
every engineer to audit socket call sites by hand. Put the gates
where teams already work (service catalog, Renovate or equivalent
dependency bots, deployment checklists) and SHOULD tie change-
advisory or promotion policy to them so *unknown* or *below-minimum*
software cannot reach production dual-stack or IPv6-only paths
unnoticed.
12.3. Developer and Pre-Production Environments
*Provide dual-stack (and eventually IPv6-only) networks to developers
as early as possible* --- ideally before production rollout, not
after. Engineers who code and debug only on IPv4-only laptops or lab
VLANs ship software that "works in the office" and fails when AAAA
records appear in production.
It is customary to *build and test new code in VMs or containers*
that mirror production topology before release. Those evaluation
environments MUST include *dual-stack* and *IPv6-only* variants
alongside legacy IPv4-only images where brownfield support is still
required. CI pipelines SHOULD run integration tests against both
address-family modes so a code push cannot silently regress IPv6
without failing the build. [I-D.ietf-v6ops-ipv6-app-testing] defines
the connectivity-scenario combinations and testing strategies these
pipelines SHOULD cover, including IPv6-only-strict and IPv6-only with
NAT64.
Platform teams SHOULD publish standard developer network profiles
(dual-stack lab, IPv6-only sandbox, simulated edge with NAT64) and
document how to attach local IDEs, test harnesses, and AI coding
agents to them.
12.4. Hard-Coded Addresses and Localhost Pitfalls
*Listening* and *connecting* to loopback are different problems.
A recurring *server-side* defect is binding services to *127.0.0.1*
instead of *localhost* (or an explicit dual-stack listen). On dual-
stack hosts, 127.0.0.1 listens *IPv4 loopback only*; IPv6 clients
that resolve localhost to ::1 cannot connect even when the service
"runs locally." The fix is to use name-based bind targets
(localhost), listen on *both* loopback families (127.0.0.1 and ::1),
or use explicit dual-stack sockets depending on platform API.
*Client-side* use of *127.0.0.1 as a connect target* is a different
case. Local agents, scripts, and libraries that dial 127.0.0.1
continue to work on hosts where IPv4 loopback remains on lo --- which
Martin Expires 19 January 2027 [Page 28]
Internet-Draft deploying-ipv6-data-center July 2026
is the normal state even on systems that are IPv6-only on application
interfaces and, on Linux, cannot disable IPv4 in the kernel entirely.
Migration programs are not required to spend effort replacing every
client connect to 127.0.0.1 when loopback IPv4 is left in place;
prioritize *listen* misconfigurations that block IPv6-only local
clients. To surface applications that wrongly assume IPv4 loopback
is present, [I-D.ietf-v6ops-ipv6-app-testing] recommends testing in
an environment without IPv4 on the loopback interface.
Similar *listen-side* bugs appear with *0.0.0.0* vs *::* semantics,
health probes that curl IPv4 literals against services bound
IPv6-only, and container images that ship /etc/hosts without IPv6
entries.
12.5. IP Address Storage in Application Data
Many services store client or server IP addresses in databases, logs,
caches, and message queues using *fixed-width fields* (32-bit
integers, CHAR(15)) or parsers that accept dotted decimal only. IPv6
requires *structured address types* (128-bit binary, or text with
adequate length) and family-aware comparison.
Affected areas include:
* *Geolocation databases* (for example, MaxMind and similar) used
for compliance, fraud, and ad targeting --- coverage and accuracy
for IPv6 vary widely.
* *Real User Monitoring (RUM)* and *DNS steering* products that map
clients to "nearest" PoP --- if the probe or edge logic is
IPv4-only, steering decisions silently degrade for IPv6 clients.
* *Rate limiting and abuse detection* keyed on "IP" strings with
naive splitting on . characters.
Refactoring often touches every schema, serializer, and analytics job
that touched the field --- plan migration as a *program*, not a one-
line fix.
12.6. Databases, ACLs, and Security Tools
*MySQL and MariaDB* host-based ACLs are historically *string
comparisons* on the client address field. IPv6 literals contain
colons and zone identifiers; copying IPv4 ACL patterns without
testing produces false denials or overly broad grants. Test
USER@'2001:db8::/32'-style entries explicitly.
Martin Expires 19 January 2027 [Page 29]
Internet-Draft deploying-ipv6-data-center July 2026
Security agents (EDR, IDS, WAF) may lack IPv6 decode paths even when
they claim dual-stack support. Validate *both directions* ---
ingress to the service and egress from the service --- under
IPv6-only client paths. The same teams can extend PR checks with
static analysis rules (see Section 12.8).
12.7. Language Runtimes and Libraries
*Python* exposes several *deprecated socket helpers that are
IPv4-only or return only one address*, yet remain common in
production code and older tutorials. Examples include:
* *socket.gethostbyname()* and *socket.gethostbyname_ex()* ---
resolve a name to IPv4 only; use *socket.getaddrinfo()* and
iterate all results (see Section 13).
* *socket.gethostbyaddr()* --- reverse lookup with IPv4-centric
assumptions; prefer *getnameinfo()* with a binary sockaddr from
the connection.
* *socket.inet_aton()* and *socket.inet_ntoa()* --- convert IPv4
literals only; use *socket.inet_pton()* and *socket.inet_ntop()*
for both address families.
These APIs *will not return IPv6* even when the host has AAAA records
and IPv6 connectivity. Replacing them is rarely a one-line change
--- call sites, tests, and error handling often assume 32-bit or
dotted-decimal form.
Other languages have similar legacy (inet_aton assumptions, IPv4-only
standard library gaps). Code review checklists SHOULD include:
* No unparsed string IPs in business logic
* Resolve names with a *full-list* API (see Section 13); never call
legacy one-address helpers in new code
* Tests that run against *IPv6 literals and DNS names with AAAA
records*
12.8. Static Analysis and Pull Request Automation
Manual review does not scale across large monorepos. *Security and
platform teams SHOULD integrate IPv6 readiness checks into pull
request (PR) workflows*, piggybacking on existing gates rather than
relying on a separate audit cycle.
12.8.1. Pattern Scanners in CI
Ship *Semgrep*, *CodeQL*, or equivalent rules that flag likely
IPv4-only patterns, for example:
Martin Expires 19 January 2027 [Page 30]
Internet-Draft deploying-ipv6-data-center July 2026
* Literal 127.0.0.1 or 0.0.0.0 in *listen/bind* configuration (not
every client connect to 127.0.0.1; see Section 12.4), or dotted-
decimal regexes used as addresses
* Calls to deprecated Python socket helpers (see Section 12.7)
* AF_INET sockets where dual-stack or AF_INET6 is required
* Database columns or structs sized for IPv4-only (CHAR(15), 32-bit
integers)
* String splits on . to parse "IP addresses"
Security teams often own the rule pack; application teams own
remediation. Rules SHOULD be published internally with examples and
fix guidance.
12.8.2. Automated Remediation Pull Requests
Beyond blocking merges, pipelines MAY open *automatic PRs* that
propose fixes when a scan finds matches on default branches or on a
schedule. Some findings are straightforward (replace gethostbyname
with getaddrinfo usage); others need context. *AI-assisted patch
generation* can speed up bulk refactors, but MUST be reviewed by a
human --- expect *false positives* (for example, code that
intentionally handles IPv4-only legacy clients).
Treat auto-generated PRs like any other contribution: tests,
ownership by code owners, and rollback plan.
12.8.3. Opt-Out Annotations for Engineers
Engineers SHOULD be able to *suppress a finding on a specific line*
when the IPv4-only behavior is intentional and documented --- for
example, a compatibility shim with a planned removal date. Define a
*codified comment* recognized by the scanner, placed *immediately
before* the flagged line. An example directive:
# ipv6-readiness: ignore-next-line -- see TICKET-123
The project MUST document the exact directive string, required
rationale format, and whether ticket references are mandatory.
Blanket disables of entire files SHOULD NOT be allowed without
security team approval.
Martin Expires 19 January 2027 [Page 31]
Internet-Draft deploying-ipv6-data-center July 2026
12.8.4. AI Coding Agent Skills
Many teams now use *AI coding agents* in the IDE and in CI. Add an
*IPv6 readiness skill* (or equivalent project rule) to the agent
environment --- and *push the same skill into application
repositories* --- so generated patches default to *dual-stack APIs*,
*getaddrinfo()-style resolution*, and IPv6-safe listen/bind patterns.
The skill SHOULD require agents to verify that new network code works
when AAAA records are present and when IPv4 is absent (IPv6-only
paths). Treat this as part of the same program as Semgrep and CodeQL
rules, not a substitute for automated tests on dual-stack and
IPv6-only runners (see Section 12.3).
12.9. Documentation and Presentations
Runbooks, architecture diagrams, wikis, training decks, and
conference slides *SHOULD use IPv6 addresses in examples by default*,
unless the example is inherently IPv4-specific. Using IPv4-only
literals in internal documentation normalizes the wrong protocol for
new engineers and hides gaps until production rollout. IETF
documents follow the same principle: examples SHOULD use IPv6 and
reserved documentation prefixes rather than arbitrary or production
addresses [RFC3849] [RFC5737].
When an example needs an IP address or prefix, follow *IETF
documentation address rules*:
* *IPv6 (preferred):* use the documentation prefixes reserved in
[RFC3849] (2001:db8::/32) and [RFC9637] (3fff::/20 for larger or
more realistic layouts). Represent addresses in *canonical text
form* per [RFC5952] (lowercase hex, suppress leading zeros, use ::
compression).
* *IPv4 (only when required):* use the TEST-NET blocks in [RFC5737]
(192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) --- not production
space, arbitrary 10.0.0.0/8 lab subnets, or other unreserved
ranges that could collide with real deployments.
* *Names:* use example domain names from [RFC2606] (example.com,
example.net, example.org) rather than real operator domains.
Review documentation the same way code is reviewed: a slide full of
10.x.x.x or 192.168.x.x examples teaches habits that conflict with
IPv6-first data center operation. Prefer 2001:db8:... and service
names unless the document explicitly covers legacy IPv4 behavior.
Martin Expires 19 January 2027 [Page 32]
Internet-Draft deploying-ipv6-data-center July 2026
13. Resolving Hostnames to Addresses
This section covers name-to-address APIs and client resolution
behavior --- the connection layer above application readiness gaps
cataloged above.
Turning a hostname into addresses is a separate step from choosing
which address to connect to. Application code MUST use an API that
returns *all* candidate addresses, then apply local policy (retries,
Happy Eyeballs [RFC8305], load spreading --- see Section 13.4 and
Section 14). When implementing Happy Eyeballs, *delay the IPv4
connection attempt* so IPv6 has more time to succeed first --- a late
start for IPv4 is consistent with [RFC8305] and reduces accidental
IPv4-first behavior on dual-stack paths.
Even with correct client retry logic, *missing or wrong IPv6 routes*
can send internal AAAA targets out an Internet default route. Edge
hosts in transitional layouts SHOULD install *unreachable* routes for
internal aggregates so address-family fallback can succeed (see
Section 8.5.1).
13.1. Use getaddrinfo(), Not Legacy One-Address APIs
On POSIX systems the correct resolver entry point is *getaddrinfo()*
[RFC3493]. It takes a hostname (or numeric address string), service/
port hints, and an addrinfo hints structure, and returns a *linked
list of addrinfo structures* --- one node per address. The caller
*MUST iterate the entire list* (the ai_next chain), copy each
sockaddr into binary form (see Section 2.6), and MUST release the
list with freeaddrinfo().
Please note: *getaddrinfo()* is the name-to-address API for
retrieving a full list; it is not the same as:
* *gethostbyname()* and *gethostbyname2()* --- deprecated, not
thread-safe, and still present in old tutorials. Many call sites
use only the first address even when multiple are available.
* *inet_addr()*, *inet_aton()*, and *inet_pton()* --- parse a
*literal* address string into binary; they perform *no DNS lookup*
and return a single address only.
* Higher-level HTTP or RPC helpers that resolve a name internally
and connect to *one* chosen address without exposing the full set
--- fine for quick clients, unsuitable when the service relies on
multiple A/AAAA records.
Martin Expires 19 January 2027 [Page 33]
Internet-Draft deploying-ipv6-data-center July 2026
To request both IPv4 and IPv6 results, set hints.ai_family to
AF_UNSPEC (unless a deliberate single-family policy applies).
Inspect ai_family, ai_addrlen, and ai_addr on *each* list element; do
not assume every node has the same address family.
Language runtimes expose the same idea under different names:
* *Python:* socket.getaddrinfo() returns a list of tuples ---
iterate all entries; avoid socket.gethostbyname(), which returns
one IPv4 address.
* *Go:* net.DefaultResolver.LookupIPAddr() or LookupIP(); avoid code
paths that stop after the first returned address.
* *Java:* InetAddress.getAllByName() returns an array; *getByName()*
returns only the first address and is a common source of "works in
the lab" failures under round-robin DNS.
* *Node.js:* dns.promises.resolve() or dns.lookup() with { all: true
}; the default lookup() without all: true returns a single
address.
Pay special attention when connecting to a *hostname* (as opposed to
a numeric literal): resolution can return both IPv4 and IPv6
addresses, and often more than one of each. A failed connect() to
*one* of those addresses does *not* mean the host is unreachable.
Application code MUST NOT report the destination as down after trying
only the first AAAA or A record and never the other family, or after
IPv4 fails while unused IPv6 candidates remain (and vice versa). Try
other addresses from the resolved list --- or use Happy Eyeballs
[RFC8305] --- before concluding that the service cannot be reached.
13.2. Why the Full List Matters
DNS often publishes *multiple A and AAAA records* for availability
and load distribution. Connecting to result->ai_addr and ignoring
ai_next defeats that design. After collecting the list, the
application (or a shared library) chooses order: IPv6-first, Happy
Eyeballs, random shuffle within a family, or explicit retry on
failure. *getaddrinfo() supplies candidates; it does not replace
client-side load balancing.*
Note that libc implementations may *reorder* the list per [RFC6724]
before returning it (see Section 13.4). You still need every element
--- reorder yourself if policy requires --- but you cannot skip
resolution and hope DNS order survives unchanged.
Martin Expires 19 January 2027 [Page 34]
Internet-Draft deploying-ipv6-data-center July 2026
13.3. Numeric Input at the Edge
When configuration or user input contains an address *literal* rather
than a hostname, *inet_pton()* (or the language equivalent) converts
it to binary for storage. When input might be either a name or a
literal, *getaddrinfo()* accepts both; alternatively, try literal
parse first, then fall back to DNS. Either way, convert once to
binary and use binary forms internally.
13.4. Address Selection, gai.conf, and DNS Round Robin
The Linux file /etc/gai.conf and the algorithms in [RFC6724] control
*address selection order* for dual-stack hosts --- which address
family and which destination address are tried first. This is
invisible in application source but visible in production load
distribution.
*RFC 6724 destination address selection Rule 9* ("Use longest
matching prefix") compares each candidate destination with its likely
source address and *sorts addresses deterministically* [RFC6724].
Resolver libraries such as *glibc* implement this sorting inside
getaddrinfo(). The effect: *DNS round-robin is not a load-balancing
strategy on IPv6* (and is weakened on IPv4 in many cases). A round-
robin AAAA record can collapse to "always try the same address first"
once Rule 9 runs, concentrating connections on one backend. The
problem is subtle on IPv4 but *often severe on IPv6*.
Rule 9 is reasonable on the global Internet but *often wrong inside a
data center*, where many servers are functionally declared
equidistant and operators expect DNS or anycast to spread load.
Mitigations include:
* Perform *client-side load balancing* in the application or
library.
* Fetch all addresses (for example, via getaddrinfo() without
premature sorting, or via a resolver that preserves DNS order),
then choose randomly *within the same address family* --- do not
shuffle v4 and v6 together in ways that accidentally defeat IPv6
preference policy.
* Use service meshes, anycast, or explicit endpoint lists rather
than naive round-robin alone.
Changing /etc/gai.conf adjusts precedence tables but *does not fully
disable Rule 9* in all implementations. Treat load balancing as a
*software concern*, not something DNS alone provides.
Martin Expires 19 January 2027 [Page 35]
Internet-Draft deploying-ipv6-data-center July 2026
13.5. Runtime-Specific Resolution (Not Always glibc)
Examples above assume POSIX *getaddrinfo()* via *glibc* (or an
equivalent libc). Not every language or runtime uses libc for name
resolution. *Java* maintains its own resolver stack and system
properties such as *java.net.preferIPv4Stack* and
*java.net.preferIPv6Addresses* that override address-family
preference independently of /etc/gai.conf. A JVM configured to
prefer IPv4 can appear "IPv6 broken" even when the OS resolver
returns AAAA records. Test Java services with explicit property
settings and with *InetAddress.getAllByName()*, not *getByName()*.
[I-D.ietf-v6ops-ipv6-app-testing] catalogs these destination-address-
selection and address-filtering deviations (including Java preferring
IPv4 and resolvers such as NGINX that ignore address-family
availability) as common IPv6 failure sources.
In extreme cases, an */etc/resolv.conf* that lists *only IPv6
nameserver addresses* can interact badly with runtimes that bootstrap
DNS over IPv4 first or assume a v4-reachable resolver path. Symptoms
include slow resolution, timeouts, or unexpected family ordering.
Qualify resolver configuration on dual-stack and IPv6-only hosts for
each runtime in the fleet, not only for C callers of getaddrinfo().
14. Client-Side Load Balancing
Client-side load balancing builds on the resolution patterns in
Section 13 when services publish multiple A/AAAA records.
As described in Section 13.4, *RFC 6724 Rule 9* reorders addresses
returned from DNS. In data centers that rely on multiple AAAA
records for spread, connection counts can skew badly --- one backend
receives most IPv6 connections while others appear idle. This
section assumes the application has already obtained the *full
address list* using the patterns in Section 13.
*Recommended pattern:*
1. Resolve the service name to all addresses.
2. Partition addresses by address family.
3. Apply family preference policy (operator choice: IPv6-first,
happy eyeballs, or parallel). For Happy Eyeballs, *start IPv4
attempts after a deliberate delay* so IPv6 connections have
priority time to complete.
4. *Randomize or round-robin within each family* rather than
trusting DNS order after getaddrinfo().
5. Optionally implement retries across the full set on failure.
Martin Expires 19 January 2027 [Page 36]
Internet-Draft deploying-ipv6-data-center July 2026
Implement load balancing in *shared client libraries* so every
service does not rediscover the same RFC 6724 interaction.
15. Network Diagnostics in the Data Center
A data center is a *closed, operator-controlled environment*. Two
practices that help SREs diagnose routing, DNS, and reachability
problems on *both IPv4 and IPv6* are often skipped because they feel
optional or risky.
15.1. Reverse DNS
Maintain *forward and reverse DNS* for long-lived infrastructure:
servers, load balancers, management interfaces, and other addresses
that appear in logs, firewall hits, flow records, and packet
captures. Reverse zones (*PTR* for IPv4, *ip6.arpa* for IPv6
[RFC3596]) map an address back to a hostname. That mapping is
routine on IPv4 but becomes *essential on IPv6*, where prefixes are
not human-scannable and incidents otherwise devolve into comparing
128-bit literals. Reverse records SHOULD be created in the same
change workflow as forward records and IPAM assignments (see
Section 9). Spot-check with dig -x or equivalent on both address
families before relying on reverse lookup during an outage.
15.2. Controlled ICMP Echo (Ping)
Teams trained to drop *ICMP echo request/reply* ("ping") on the
public Internet sometimes apply the same rule everywhere. *Inside the
data center*, allowing echo request/reply *with limits* --- rate
limits, scoped ACLs, source restrictions to management networks or
jump hosts, or equivalent controls --- is RECOMMENDED for
troubleshooting. A successful or failed ping quickly separates "no
route" from "route but service down" on both IPv4 and IPv6 without
opening application ports.
This is separate from the ICMPv6 requirements in Section 11: Neighbor
Discovery and Path MTU Discovery need specific ICMPv6 types on
production paths and MUST NOT be blocked wholesale. Controlled echo
is an additional *diagnostic convenience* on top of that baseline.
Operators SHOULD NOT replace protocol-required ICMP with echo-only
rules, nor block echo in ways that remove a basic reachability tool
from on-call engineers. Apply the same philosophy to *ICMPv4 echo*
inside the fabric: constrain abuse, but preserve a controlled way to
test L3 connectivity during incidents.
Martin Expires 19 January 2027 [Page 37]
Internet-Draft deploying-ipv6-data-center July 2026
16. Security Considerations
IPv6 restores global routability; *absence of NAT is not absence of
need for firewall policy*. ULAs and link-local addresses still
require filtering at boundaries. ICMPv6 filtering must preserve ND
and PMTUD. Application-level ACLs and security products must parse
IPv6 literals correctly (see Section 12).
*Security appliances and host security software are notoriously weak
on IPv6* --- incomplete decode, IPv4-only dashboards, agents that
drop or mislabel v6 traffic, and policies that silently fail open or
closed. Engage the *security organization very early* in the IPv6
program, in parallel with out-of-band and network design (see
Section 7). In many enterprises, application SREs *do not have full
visibility* into which tools the security team deploys; there is
often deliberate *operational secrecy* around EDR, NDR, DLP, and
forensics platforms. Assume unknown agents exist on every host until
proven otherwise (see Section 5.5); establish a shared readiness
process with security leadership rather than discovering blockers
during the first IPv6-only pilot.
Security monitoring systems MUST receive IPv6 traffic mirrors, tap
coverage, and metadata *on parity with IPv4* before declaring IPv6
production-ready. Validate that incident response playbooks (pcap
collection, IP blocking, geo blocking, threat intel feeds) work with
*128-bit addresses* and canonical text forms [RFC5952]. PR static
analysis for IPv4-only patterns (see Section 12.8) complements but
does not replace security-tool qualification.
Operator inventory practices in Section 12 also reduce supply-chain
risk from undeclared IPv4-only dependencies in the control plane.
17. IANA Considerations
This document has no IANA actions.
18. Acknowledgments
The authors thank the following people who contributed suggestions
and editorial improvements to this document:
* *Jason Healy* (Suffield Academy)
19. Normative References
Martin Expires 19 January 2027 [Page 38]
Internet-Draft deploying-ipv6-data-center July 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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849,
DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/info/rfc3849>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<https://www.rfc-editor.org/info/rfc4704>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
Martin Expires 19 January 2027 [Page 39]
Internet-Draft deploying-ipv6-data-center July 2026
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890,
DOI 10.17487/RFC4890, May 2007,
<https://www.rfc-editor.org/info/rfc4890>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[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>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
Martin Expires 19 January 2027 [Page 40]
Internet-Draft deploying-ipv6-data-center July 2026
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
20. Informative References
[ARCEP-IPV6-GUIDE]
ARCEP, "How to Deploy IPv6 in Your Enterprise (Guide for
Enterprises)", March 2022,
<https://www.arcep.fr/fileadmin/cru-
1648459125/reprise/observatoire/ipv6/guide-entreprises-
how-to-deploy-IPv6-march-2022.pdf>.
[ARIN-APPS-V6]
ARIN, "Preparing Applications for IPv6: A Software
Developers Guide to Writing and Migrating Networked
Applications for Use on IPv6 Networks",
<https://www.arin.net/resources/guide/ipv6/
preparing_apps_for_v6.pdf>.
[I-D.ietf-v6ops-ipv6-app-testing]
Tiesel, P. S., Linkova, J., Ouellette, K., and B. Patton,
"Testing Applications' IPv6 Support", Work in Progress,
Internet-Draft, draft-ietf-v6ops-ipv6-app-testing-01, 26
May 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-v6ops-ipv6-app-testing-01>.
[I-D.ietf-v6ops-ipv6-only]
Martinez, J. P., "IPv6-Only and IPv6-Mostly Terminology
Definitions", Work in Progress, Internet-Draft, draft-
ietf-v6ops-ipv6-only-00, 1 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
ipv6-only-00>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<https://www.rfc-editor.org/info/rfc2606>.
[RFC4038] Shin, M., Ed., Hong, Y., Hagino, J., Savola, P., and E. M.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, DOI 10.17487/RFC4038, March 2005,
<https://www.rfc-editor.org/info/rfc4038>.
Martin Expires 19 January 2027 [Page 41]
Internet-Draft deploying-ipv6-data-center July 2026
[RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014,
<https://www.rfc-editor.org/info/rfc7381>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC9637] Huston, G. and N. Buraglio, "Expanding the IPv6
Documentation Space", RFC 9637, DOI 10.17487/RFC9637,
August 2024, <https://www.rfc-editor.org/info/rfc9637>.
Author's Address
Franck Martin
Peachymango.org
Email: franck@peachymango.org
Martin Expires 19 January 2027 [Page 42]