Deploying IPv6 in Data Centers

2.3.1. Procurement and Long-Lead Hardware

Update purchase requirements, RFPs, and vendor questionnaires at program kickoff --- ideally before any production dual-stack or IPv6-only cutover --- so new acquisitions cannot quietly extend the IPv4-only lifetime of the fleet. Infrastructure and facility gear often have 10+ refresh cycles and little or no field-upgradable network stack; buying IPv4-only today can block IPv4 decommissioning long after application code is ready (see Section 5.1).¶

Operators SHOULD:¶

• Require IPv6-only and dual-stack support for new purchases that attach to data center or management networks --- compute BMCs, switches, consoles, PDUs, environmental monitors, network time appliances (NTP or PTP, including GPS-synced stratum servers), storage appliances, and similar long-lived devices --- not only for application software.¶
• Distinguish systems the organization owns or controls (and can mandate in contracts) from systems it does not (public cloud SKUs, SaaS, leased facility gear) so inventory and exception tracking cover both classes early (see Section 2.4 and Section 2.6).¶
• Treat written vendor claims as necessary but insufficient: qualify candidates in a lab or acceptance network, including an IPv6-only path where practical (see Section 4.2 for IPv6-only guest or demo Wi-Fi), before production purchase or racking.¶

Procurement language is the contractual backup; lab "show me" testing catches products that claim IPv6 readiness and fail under operational load.¶

2.6.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 gateway, or operator translation at the border (see Section 3.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.¶

2.6.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 readiness labels and notes on region, tier, and verification date.¶

Label by the default client path used in production (the hostname and options the running SDK, CLI, or library uses with no extra configuration), not by a provider capability page or an alternate dual-stack endpoint that applications do not call unless reconfigured:¶

• supported --- the default client path resolves and works on IPv6.¶
• supported-not-default --- IPv6 exists only behind an alternate hostname, opt-in flag, or non-default region or SKU; production without that change stays on IPv4.¶
• partial --- incomplete feature coverage (some APIs, regions, or SKUs), distinct from "complete but opt-in."¶
• unsupported / unknown --- no usable IPv6 path, or not yet verified.¶

Defaults move over time; re-check on the verification-date column rather than assuming a past "supported" label still matches what clients dial today.¶

Where clients can use operator-controlled DNS (private zones, service discovery, or aliases under a stable convention), prefer names independent of the provider's hostname taxonomy (see Section 5.5). Publish A and AAAA (or point aliases) under that convention so application configuration does not inherit provider path quirks --- for example when one provider hostname has AAAA and a sibling default does not. Operator names are a mitigation when the client stack allows them; the matrix still records whether the provider default path is IPv6-ready.¶

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 on the default path, 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 as supported-not-default or only in select regions or SKUs, record that constraint in the inventory and use Section 2.5 when the business must stay on IPv4-only cloud paths temporarily.¶

2.6.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 4.4: 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.¶

Hybrid programs SHOULD include cloud account and landing-zone reviews in the same governance cadence as on-premise migration metrics (see Section 2.4). A service marked "IPv6-ready on-premise" that calls an IPv4-only cloud API, depends on a supported-not-default cloud path without the required client change, 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.¶

3.2.1. Prefix Allocation for Hosts and Containers

The important software lesson is an explicit prefix plan per role, sized for growth --- what receives a prefix (host, VM, container, pod, service, rack, or other role), at what length, and how those roles nest --- rather than assuming "one address per host" as in legacy IPv4 NAT designs. Operators SHOULD write that numbering policy down, then size for current inventory and plausible 10+ years growth (hosts, clusters, and sites). Request the next allocation before the last usable prefix is assigned; discovering a ceiling mid-migration turns a sizing choice into an allocation request with its own justification and lead time (the same early-case discipline as Section 2.6). The exact mapping depends on orchestrator and CNI design; the templates below are examples, not a single mandatory layout.¶

One template for counting /64s --- not a recommendation every estate must follow --- 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 pods. Under that template each container MAY receive a full /64, with routing between /64 islands instead of NAT for east-west traffic. Arithmetic follows the policy: a /56 per host exhausts a /48 at 256 hosts; larger estates need a shorter site prefix or a different per-entity size. Assigning only a /64 per host without further delegation is often insufficient when containers need SLAAC for address assignment.¶

Orchestrators such as Kubernetes often need several ranges (for example node, pod, and service). Whether this can be combined with a single per-host delegation depends on the orchestrators and its CNI. Common layouts either gives each node a /64 from a pod range or carve out longer-than-/64 subnets from one host prefix.¶

In a closed data center with explicit routing and no SLAAC on container segments, some designs assign one /64 (or longer) per physical host and carve /72 (or longer) subnets from that host prefix for containers. That /72 pattern is not suitable hosts expect standard /64 semantics; use it only with operator-wide agreement and tested CNI or orchestrator support --- do not read it as advising against ordinary orchestrator node /64s.¶

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 2.6), 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 /56-per-host template 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.¶

3.3.1. 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. That double safeguard also limits surprise growth in the number of addresses the fabric and security devices must track (see Appendix A.5 on multiple addresses per host).¶

Gateway at fe80::1, global addresses from IPAM, and DNS names registered in forward and reverse zones should be one coordinated change set.¶

3.3.2. 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¶

Where operators must read or type addresses by hand, aligning those class boundaries on a nibble boundary (a multiple of four bits) keeps the hex form easier to scan than an arbitrary bit split.¶

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 3.2.1 and Section 3.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.¶

3.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 3.3.2).¶
• 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 3.3.2). 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 5.5). 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.¶
• Border visibility: operators MAY also monitor or log at Internet or site border devices any packets destined to internal-only IPv6 aggregates that should never appear on external policy paths --- a useful signal of mis-egress during rollout. Blocking those flows at the border can help, but treat hard denies carefully in multihomed designs.¶
• 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.¶

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

3.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.¶

Operators SHOULD detect drift when DNS or IPAM changes: for example, compare published A/AAAA records to the address predicted by the embedding plan, and alert when they diverge so pre-built ACLs are not left pointing at the wrong host.¶

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 traffic from the host uses IPv6. That lets platform agents --- configuration management, monitoring, log shippers, vulnerability scanners, and other infrastructure daemons (see Section 3.8.3) --- 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.¶

3.8.1. 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. Where operators apply modest IPv4 path friction Section 2.7, a sudden preference for IPv4 often appears first as increased latency or reduced QPS on services that already export those metrics --- treat those regressions as IPv6-preference failures, not generic capacity events, until address-family split confirms otherwise.¶

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. When probing a load balancer or VIP by address to separate DNS or address-selection failures from the data path, HTTP and TLS checks SHOULD still present the production hostname (TLS SNI and HTTP Host) so the probe exercises the same certificate and virtual-host path as real clients; a bare IP literal may pass TCP while missing application-layer faults. [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 2.5) 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.¶

3.8.2. 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.¶

3.8.3. 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 4.4. Re-run when the image or security baseline changes.¶

3.8.4. 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.¶

3.8.5. HTTP Signaling and Planned IPv4 Drills

For HTTP services, implementing HTTP Signaling of Planned IPv4 Unavailability (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.¶

3.8.6. 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. Where translation is present, tag hops as native IPv6, native IPv4, or transitional so dashboards show when NAT64 can be retired from a path. 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.¶

4.3.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 5.2). Spot-check with dig -x or equivalent on both address families before relying on reverse lookup during an outage.¶

4.3.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 ping confirms basic IP reachability (when echo is permitted) without opening application ports. A failed ping alone does not prove there is no route: filtering, rate limits, host firewall policy, or a destination that does not answer echo can produce the same symptom. Combine ping with traceroute, tracepath, or mtr, TCP connects to a known port, or other checks before concluding "no route" versus "route but service down."¶

This is separate from the ICMPv6 requirements in Section 5.3: 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.¶

4.4.1. Enterprise Platform Inventory

Many enterprise platforms still assume IPv4-only access paths. Examples reported in operator experience as of this writing include Hadoop, certain object storage APIs, Kubernetes dependencies (especially third-party charts and sidecars), cloud firewalls (for example, Firewalls 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. Re-check product status at publication and deployment time --- capability claims change. Hybrid and multi-cloud estates need the same inventory discipline for managed services and connectivity paths (see Section 2.6).¶

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 2.4). 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.¶

4.4.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 and the required configuration profile, both validated on dual-stack and IPv6-only paths.¶

A version or image threshold is a prerequisite, not proof that the deployed service is IPv6-ready. The same binary can still run IPv4-only because a feature flag, environment variable, listen address, or endpoint-selection setting is wrong. Software version and configuration version MAY be shipped as one bundle or pushed independently --- the usual case in large data centers using Puppet, Ansible, or similar. Operators already monitor which software and configuration versions are deployed; IPv6 gates SHOULD use those same signals.¶

Configuration commonly inherits and overrides along a hierarchy (for example organisation, site, maintenance zone, application, host). A ready package with a leftover override is still not ready. The gate is therefore often "upgrade to version X" and/or "remove the override so the general value applies" --- for instance dropping a host-level java.net.preferIPv4Stack=true (see Section 5.5.5).¶

Example gates: upgrade example-http-client to 2.4.0 or newer; remove application or host overrides of java.net.preferIPv4Stack. Versions or profiles below the threshold remain blocked or flagged in the inventory until both the package and the effective configuration match.¶

Automate enforcement against that catalog: compare SBOMs, lockfiles, image scans, and configuration-management reports (resolved inheritance, not only the default) to the matrix on a schedule and in CI (see Section 2.4). Crossing the software-version threshold SHOULD NOT by itself mark a service ready. When version and configuration match the gate and end-to-end validation on dual-stack and IPv6-only paths succeeds --- dependency bumped, agent replaced, golden image refreshed, override removed --- 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, configuration-management dashboards, deployment checklists) and SHOULD tie change-advisory or promotion policy to them so unknown, below-minimum, or misconfigured software cannot reach production dual-stack or IPv6-only paths unnoticed.¶

4.4.3. 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.¶

4.4.4. Pattern Scanners in CI

Ship Semgrep, CodeQL, or equivalent rules that flag likely IPv4-only patterns, for example:¶

• 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 5.4), or dotted-decimal regexes used as addresses¶
• Calls to deprecated Python socket helpers (see Section 5.10)¶
• 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"¶
• getaddrinfo() (and language equivalents) that use only the first returned address, or that treat DNS response order as load balancing without within-family selection --- assumptions that ordinary review often misses (see Section 5.5.4 and Section 5.7)¶

Security teams often own the rule pack; application teams own remediation. Rules SHOULD be published internally with examples and fix guidance.¶

4.4.5. 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.¶

4.4.6. 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.¶

5.1.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 4.4 and Section 2.4); they become blockers during IPv4 decommissioning even when every application pod is dual-stack.¶

5.1.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.¶

5.1.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.¶

5.2.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.¶

5.2.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 4.3.¶

5.2.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.¶

5.3.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 4.3.¶

Blanket deny is often a sequencing failure, not only a knowledge gap: security meets IPv6 for the first time at the perimeter firewall late in the rollout, with no agreed threat model and full accountability for residual risk. Agree filtering with security when the addressing plan is written (see Section 2.3), not as the last firewall change. Treat [RFC4890] training as a prerequisite to the rule change.¶

5.3.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 large records. Where classic ICMP-based PMTUD is unreliable, operators and implementers MAY also use Packetization Layer Path MTU Discovery (DPLPMTUD) [RFC8899].¶

5.3.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 3.4 and Section 3.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.¶

5.5.1. Use getaddrinfo(), Not Legacy One-Address APIs

On POSIX systems, when a higher-level family-agnostic helper is not available, 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 destination address candidate. The caller MUST iterate over the entire list (the ai_next chain) trying to connect to each candidate until either successful or no candidates are left, and MUST release the list with freeaddrinfo() afterwards.¶

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.¶
• 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.¶

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(); better use net.Dialer which provides Happy Eyeballs support.¶
• 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.lookup() or dns.lookup() with { all: true } as the default lookup() without all: true returns a single address; better use net.connect with autoSelectFamily which provides Happy Eyeballs support.¶

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. When none of the candidates succeed, do not surface only the error from the first attempt: preferably report all failures encountered. If this is not feasible, report at least the most pertinent failure --- typically the attempt that progressed furthest (for example TCP handshake completed but TLS or application protocol failed, or a clear ICMP unreachable rather than a timeout on an earlier candidate).¶

5.5.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) may ether rely on the order produced by the libc implementation (usually following [RFC6724]) or apply a more sophisticated re-ordering strategy based on Happy Eyeballs, within-family random or weighted selection for equivalent data-center backends. There is no guarantee that the first entry is the best choice, reflects order from DNS or is even functional at all.¶

Note that libc implementations may reorder the list per [RFC6724] before returning it (see Section 5.5.4). You still need every element --- reorder yourself if policy requires --- but you cannot skip resolution and hope DNS order survives unchanged.¶

5.5.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.¶

5.5.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 has two axes that operators often conflate:¶

• The policy table decides which class wins (for example ULA vs GUA vs IPv4). [I-D.ietf-6man-rfc6724-update] updates that table so known-local ULA-ULA is preferred over IPv4 and, for local use, over GUA. That helps dual-stack sites that use ULAs internally. It does not change Rule 9.¶
• Rule 9 ("Use longest matching prefix") decides which same-family destination is tried first. It compares each candidate with its likely source address and sorts addresses deterministically [RFC6724]. Resolver libraries such as glibc implement this sorting inside getaddrinfo().¶

Rule 9 is a problem if you expect DNS load balancing. A rotated set of A or AAAA records 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, especially inside a data center where many servers are functionally equidistant and operators expect DNS or anycast to spread load. Changing /etc/gai.conf adjusts precedence tables but does not fully disable Rule 9 in all implementations.¶

[I-D.martin-ipv6-addr-selection-updates] is trying to address that gap at the resolver: operators would configure prefix ranges for which Rule 9 does not apply, so getaddrinfo() preserves same-family DNS order without application changes. That is not something operators can assume on the fleet today.¶

Meanwhile, load balancing MUST be treated as something the client handles --- a shared library, service-discovery client, or mesh --- not DNS order after getaddrinfo(). The discipline matches Happy Eyeballs: do not assume destination selection is correct for every language, runtime, and client. Review it per client, especially inside a data center where Rule 9 is most harmful. DNS load balancing is often an implicit assumption buried in connection code --- "we publish multiple AAAA records, so clients will spread" --- so ordinary code review may never surface it. Pattern scanners such as Semgrep or CodeQL (see Section 4.4.3) SHOULD flag getaddrinfo() and language equivalents that take only the first result, skip within-family spreading, or otherwise treat DNS order as load balancing, so each call site is questioned rather than assumed correct.¶

Mitigations while Rule 9 still reorders:¶

• Internal / cluster backends intended to be equivalent: within-family random or weighted selection (or service mesh / anycast). Do not trust DNS or getaddrinfo() order for spread. Do not shuffle the entire resolved list across families --- that breaks IPv6 preference; partition by family first, then randomize or weight within each family.¶
• External Internet destinations: keep RFC 6724 family and prefix-class order (do not shuffle IPv4 with IPv6). Same-family DNS round-robin is still not a load-balancing strategy while Rule 9 runs.¶
• Prefer putting resolution, Happy Eyeballs, and within-family spreading in shared client libraries so each application team does not rediscover the same interaction (see Section 5.7).¶

5.5.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().¶