Building an IPv6 Integrated Project Team

Audience: isp6 members, IT leadership, programme managers, and technology directors responsible for IPv6 adoption programmes — particularly those managing cross-functional teams across networking, cloud/systems, and security disciplines.

Last updated: April 2026

Table of Contents

1. Introduction
2. The Siloed Deployment Anti-Pattern
3. Case Study: The US Department of Defense
4. Organisational Culture and IPv6 Readiness
5. Mapping IPv6 Roles to Team Topologies
6. Building the Integrated Project Team
7. Leading the Transition: Kotter's 8-Step Model
8. The IPv6 Success Framework
9. Recommendations
10. References

1. Introduction

Most IPv6 deployment failures are not technical. The protocol is mature, the RFCs are stable, and the cloud providers have supported it for years. The failure mode is organisational: networking teams design address plans in isolation, cloud teams build dual-stack infrastructure independently, and security teams — untrained and uninvolved — block the deployment at the perimeter firewall.

The most beautifully engineered IPv6 network is entirely useless if no actual user traffic ever touches it.

This article examines why IPv6 adoption is fundamentally a cross-functional organisational challenge, not a networking project, and provides a framework for building the integrated team structure that successful deployments require. It draws on established organisational models — Team Topologies, Westrum's culture typology, and Kotter's change management framework — to give programme managers a structured approach to an initiative that too often drifts into technical silos.

For isp6 members, the good news is that a significant portion of the specialist complexity — RIPE NCC registration, RPKI and ROA management, route6 objects, and ongoing compliance — is already handled by isp6 as a service. This article shows where that fits within the team structure so your organisation can focus on the cross-functional coordination that actually determines success or failure.

flowchart LR
    subgraph failure["Common Failure Mode"]
        direction TB
        A["Networking designs<br>addressing in isolation"]
        B["Cloud teams build<br>dual-stack independently"]
        C["Security blocks at<br>the perimeter firewall"]
    end
    subgraph success["Target State"]
        direction TB
        D["Unified IPv6 Blueprint"]
        E["Cross-functional<br>Integrated Project Team"]
        F["Concurrent security<br>and routing design"]
    end
    failure -->|"Organisational<br>transformation"| success

2. The Siloed Deployment Anti-Pattern

IPv6 deployments that follow the traditional waterfall handoff between functional teams exhibit a predictable cascading failure:

Phase 1: Networking

The networking team — often the most IPv6-literate group in the organisation — charges ahead. They design a global addressing plan, configure routing protocols for dual-stack operation, and allocate prefixes from the organisation's RIPE NCC allocation. The work is technically sound, thoroughly documented, and delivered on schedule.

Phase 2: Cloud and Systems

Cloud and platform teams begin independently. They provision IPv6 CIDRs in AWS VPCs, configure dual-stack load balancers, and update Terraform modules. They may or may not reference the networking team's address plan. Dual-stack infrastructure is built, but host-level concerns — address selection policy, application binding, DNS AAAA record publication — receive inconsistent attention.

Phase 3: Security

The security team encounters IPv6 traffic for the first time at the perimeter firewall. They have not been trained on ICMPv6 filtering requirements (RFC 4890), do not understand why "block all ICMP" breaks Neighbor Discovery, and have no IPv6-specific threat model. Faced with uncertainty, they apply the only risk mitigation available to an uninformed team: block everything.

flowchart LR
    P1["Phase 1<br>Networking<br><em>Designs addressing<br>plan in isolation</em>"]
    P2["Phase 2<br>Cloud Teams<br><em>Build dual-stack<br>independently</em>"]
    P3["Phase 3<br>Security<br><em>No IPv6 training,<br>no threat model</em>"]
    Wall["🧱<br>Perimeter<br>Firewall<br>Block"]

    P1 --> P2 --> P3 --> Wall

    style Wall fill:#f8d7da,stroke:#dc3545

The deployment stalls — not because of a technical deficiency, but because the organisation treated IPv6 as a sequential infrastructure project rather than a cross-cutting capability change.

Gene Kim's The Phoenix Project identifies this exact failure mode: functional silos optimising locally while the end-to-end value stream — in this case, IPv6 traffic reaching users — is blocked by handoff friction and knowledge gaps. Kim's First Way (systems thinking and left-to-right flow) demands that the entire delivery chain, from prefix allocation to firewall policy, be designed as a single system.

3. Case Study: The US Department of Defense

The US Department of Defense provides the most extensively documented example of organisational failure in IPv6 adoption.

In 2003, the DoD issued a mandate requiring all networked systems to be IPv6-capable. The initiative was abandoned due to security risks and a lack of trained personnel. In 2020, the Government Accountability Office published GAO-20-402, "Internet Protocol Version 6: DOD Needs to Improve Transition Planning," which examined why the earlier effort failed and assessed the DoD's readiness for a renewed mandate.

Key Findings

The GAO report is notable because every recommendation it made was organisational, not technical. The DoD did not lack routing engineers who could configure OSPFv3. It lacked a programme structure that treated IPv6 as a cross-functional capability requiring coordinated training, planning, and governance.

4. Organisational Culture and IPv6 Readiness

Ron Westrum's typology of organisational cultures — originally published in the context of healthcare safety and later applied to technology organisations by the DORA (DevOps Research and Assessment) programme — provides a diagnostic lens for IPv6 readiness.

Westrum's Three Culture Types

The DORA research, published in Accelerate (Forsgren, Humble, Kim, 2018), demonstrated that generative culture is a statistically significant predictor of both software delivery performance and organisational outcomes. For IPv6 adoption, the cultural type determines how cross-functional friction is handled:

• Pathological: The networking team hoards IPv6 expertise as a power base. Security blocks the deployment and blames networking for "creating risk." The programme dies in political crossfire.
• Bureaucratic: Each team follows its own change process. Networking files a change request; security opens a review ticket; months pass. IPv6 is technically approved but operationally stalled by sequential handoffs and approval queues.
• Generative: Networking, security, and cloud teams form a joint working group from day one. Security raises ICMPv6 filtering concerns during the addressing design phase, not after deployment. Risks are surfaced, discussed, and resolved as a shared problem.

Diagnosing Your Organisation

Before launching an IPv6 programme, assess which cultural pattern dominates your infrastructure teams. If the answer is pathological or bureaucratic, the organisational change work must begin before the technical work — or it will be consumed by it.

flowchart TD
    Q["How does your organisation<br>handle cross-team risk?"]
    P["Pathological<br><em>Blame and conceal</em>"]
    B["Bureaucratic<br><em>Escalate through process</em>"]
    G["Generative<br><em>Surface, discuss, resolve</em>"]
    PA["Fix culture first.<br>IPv6 will fail without<br>cross-team trust."]
    BA["Streamline handoffs.<br>Embed security in the<br>IPv6 team, don't gate it."]
    GA["Ready for an integrated<br>project team. Proceed<br>with the framework below."]

    Q --> P --> PA
    Q --> B --> BA
    Q --> G --> GA

    style PA fill:#f8d7da,stroke:#dc3545
    style BA fill:#fff3cd,stroke:#ffc107
    style GA fill:#d4edda,stroke:#28a745

5. Mapping IPv6 Roles to Team Topologies

Matthew Skelton and Manuel Pais's Team Topologies (IT Revolution Press, 2019) provides a vocabulary for structuring teams around the flow of change rather than around functional specialisations. The model defines four fundamental team types and three interaction modes.

The Four Team Types

The Three Interaction Modes

Why This Matters for IPv6

The traditional model — a "networking project" staffed by network engineers — maps to a single complicated-subsystem team working in isolation. It produces technically excellent routing configurations that never reach users because the stream-aligned teams (application delivery) and the platform teams (cloud infrastructure) were not part of the design.

Team Topologies reframes the question: Who owns the end-to-end flow of IPv6 traffic from allocation to production? That owner is the stream-aligned team — the Integrated Project Team — and it must include representatives from every discipline that IPv6 touches.

flowchart TD
    subgraph ipt["Stream-Aligned: IPv6 Integrated Project Team"]
        direction LR
        NET["Networking"]
        SEC["Security"]
        CLD["Cloud / Systems"]
    end

    subgraph enabling["Enabling Team"]
        TRAIN["IPv6 Training<br>& Skills Uplift"]
    end

    subgraph complicated["Complicated-Subsystem"]
        BGP["BGP / RPKI<br>Specialists"]
        ISP6["isp6 LIR Service<br>RIPE registration, ROA,<br>route6, RPKI, compliance"]
    end

    subgraph platform["Platform Team"]
        PLAT["Dual-Stack VPCs,<br>LBs, Terraform<br>Modules"]
    end

    enabling -->|"Facilitating"| ipt
    complicated -->|"X-as-a-Service"| ipt
    ipt -->|"Collaboration"| platform

IPv6 natively bridges the gap between network transport and host OS behaviour — address selection (RFC 6724), SLAAC, and NDP operate at the intersection of networking, systems, and security. A deployment model that treats these as separate domains will fail at exactly those intersection points.

6. Building the Integrated Project Team

The Integrated Project Team (IPT) is a cross-functional group with a single mandate: deliver end-to-end IPv6 connectivity from prefix allocation to production traffic. It is not a committee, a working group, or a review board. It is a delivery team with shared accountability for outcomes.

Composition

Operating Principles

1. Single source of truth. The IPT maintains one IPv6 addressing and policy blueprint. There is no separate "networking address plan" and "security firewall policy" — they are sections of the same document, reviewed and approved together.

2. Concurrent design, not sequential handoff. Security policy is designed at the same time as the addressing plan, not after it. Cloud provisioning is planned in parallel with routing, not as a follow-on phase. This eliminates the cascading failure described in Section 2.

3. Embed, don't gate. Security is a member of the IPT, not an external review gate. If security concerns are raised during design, they are resolved within the team. If they are raised after deployment by an external review board, the programme is structurally broken.

4. Time-box the collaboration. Per Team Topologies, close collaboration between teams is cognitively expensive and should be time-limited. The IPT operates in intensive collaboration mode during the design and initial deployment phases, then transitions to an X-as-a-Service model where the platform team provides self-service IPv6 capabilities and the IPT disbands or scales down to a maintenance function.

5. Measure traffic, not configuration. The success metric is not "IPv6 is configured" — it is "IPv6 traffic is flowing in production." Instrument your deployment to measure the percentage of traffic using IPv6 from day one.

7. Leading the Transition: Kotter's 8-Step Model

John Kotter's eight-step model for leading organisational change (Leading Change, Harvard Business School Press, 1996) provides a proven structure for IPv6 adoption programmes. IPv6 is not a technology upgrade — it is a capability change that requires new skills, new processes, and new ways of working across team boundaries.

The Critical Step: Number 5

Most IPv6 programmes fail at step 5. The barriers are not technical — they are procedural and educational:

• Security teams lack IPv6 training and default to blocking what they do not understand
• Firewall change processes do not include IPv6-specific templates or baselines
• Platform teams have not updated their Terraform modules / CloudFormation templates for dual-stack
• Application teams do not know how to bind to IPv6 or test dual-stack connectivity

Removing these barriers is the programme manager's primary responsibility. It is not glamorous work, but it is the work that determines whether the programme succeeds or produces another shelf of unused documentation.

8. The IPv6 Success Framework

Successful IPv6 adoption rests on two pillars. Technical competence without organisational alignment produces an engineered network that nobody uses. Organisational alignment without technical competence produces a programme that cannot deliver. Both pillars must be built concurrently.

flowchart TD
    TOP["End-to-End IPv6 Adoption"]
    P1["Pillar 1:<br><strong>Abundance Mindset</strong>"]
    P2["Pillar 2:<br><strong>Organisational Synchronisation</strong>"]

    P1A["Standardise on the<br>/64 boundary"]
    P1B["Adopt Global Unicast<br>Addressing (not ULA)"]
    P1C["Decouple filtering<br>from translation"]

    P2A["Mandate a cross-functional<br>Integrated Project Team"]
    P2B["Design security policy<br>concurrently with routing"]
    P2C["Align training across<br>all IT disciplines"]

    TOP --> P1
    TOP --> P2
    P1 --> P1A
    P1 --> P1B
    P1 --> P1C
    P2 --> P2A
    P2 --> P2B
    P2 --> P2C

Pillar 1: Abundance Mindset

Stop applying IPv4 scarcity constraints to a protocol designed for abundance:

• Standardise on /64. Every end-host subnet gets a /64 — no exceptions. Do not carve smaller prefixes to "conserve" space (RFC 7421).
• Use Global Unicast Addresses. Do not default to ULA as a replacement for RFC 1918. GUA behind stateful firewalls provides equivalent security without the address selection problems of RFC 6724.
• Decouple filtering from translation. Firewalls provide security; NAT provided address sharing. In IPv6, these are separate concerns. Design your security posture around stateful filtering, not address translation (RFC 4864).

For a detailed treatment of these technical misconceptions, see Stop Thinking in IPv4: Misconceptions That Sabotage Your IPv6 Deployment.

Pillar 2: Organisational Synchronisation

Stop building in functional silos:

• Mandate a cross-functional IPT. Networking, cloud/systems, and security must be represented in a single delivery team with shared accountability. Use the Team Topologies model to structure the team and its interactions.
• Design security concurrently with routing. Security policy is not a review gate after the network is built — it is a design input from day one. The ICMPv6 filtering baseline, the IPv6 threat model, and the flow telemetry strategy are all designed alongside the address plan.
• Align training across disciplines. Every member of the IPT needs IPv6 training, not just the networking engineers. Security teams need ICMPv6 and NDP training. Cloud teams need BYOIP and dual-stack provisioning training. Use the RIPE NCC's free training courses at learning.ripe.net as a baseline.

Successful IPv6 deployment is 50% unlearning old technical constraints and 50% dismantling operational silos.

9. Recommendations

10. References

Organisational Models and Change Management

Government and Institutional Reports

IPv6 Training and Deployment Guidance

Technical References

Related Articles

• Designing the Next Internet: An Introduction to IPv6 — an accessible primer to share with cross-functional team members who need a baseline understanding of the protocol before joining the programme
• Stop Thinking in IPv4: Misconceptions That Sabotage Your IPv6 Deployment — technical companion covering the six most common IPv4 reflexes that harm IPv6 deployments
• Planning Your isp6 Allocation — sizing and structuring a /48 or /44, the architect's counterpart to the programme-level framing in this article
• Bring Your Own IPv6 to AWS — step-by-step guide for isp6 members, covering what isp6 handles vs. cloud-side configuration
• Bring Your Own IPv6 to Azure — Custom IP Prefix onboarding for isp6 members
• Bring Your Own IPv6 to Google Cloud — PAP/PDP model for isp6 members

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.