Enterprise IPv6 Migration: Planning and Execution Guide

Why Enterprises Need IPv6 Now#

Enterprise IT has delayed IPv6 longer than mobile carriers and cloud providers. The reasoning seemed sound: abundant IPv4 addresses from legacy allocations, NAT solving internal addressing, and "no immediate business need." But this calculus changed.

Business drivers forcing IPv6:

1. Cloud provider requirements: AWS, Azure, and GCP charge premiums for IPv4 addresses. Azure bills $0.004/hour per public IPv4 (over $35/year per IP). Cloud-native architectures require IPv6 to avoid runaway costs.

2. Mobile-first user base: Your users are already on IPv6 networks. Mobile carriers run IPv6-only infrastructure with NAT64 for IPv4 access. IPv6-enabled services reduce latency and improve performance for mobile users by avoiding translation.

3. Security compliance: Frameworks like NIST and DoD mandate IPv6 support. Government contractors face explicit IPv6 requirements. Industry regulations increasingly reference IPv6 readiness.

4. Vendor support timelines: Operating systems, networking equipment, and applications increasingly prioritize IPv6. Legacy IPv4-only systems lose support. Your technology refresh cycles force the decision.

5. Competitive advantage: Organizations with IPv6 deployment experience gain efficiency benefits. Simpler routing (no NAT complexity), better troubleshooting, and reduced address management overhead. Early adopters build expertise while competitors scramble.

The question isn't "if" but "when and how." Delaying makes migration harder as technical debt accumulates.

Enterprise-Specific Challenges#

Enterprise networks differ from ISP and mobile carrier deployments. Unique challenges require adapted approaches.

Legacy Application Inventory#

Twenty years of custom applications, vendor software, and integrations. Many haven't been touched in years. Development teams disbanded. Documentation lost. Some apps have IPv4 addresses hardcoded in database schemas or configuration files.

Impact: You can't flip a switch. Every application needs assessment, testing, and potentially remediation.

Organizational Complexity#

Enterprise IT has multiple teams: network, security, applications, database, compliance. IPv6 affects all of them. Getting coordination across silos takes time. Budget and resource allocation requires business cases and executive approval.

Impact: Technical implementation is often easier than organizational change management.

Risk Aversion#

Enterprises prioritize stability. Quarterly maintenance windows book months in advance. Change review boards scrutinize alterations. A migration affecting core infrastructure faces intense oversight.

Impact: Phased, incremental rollout required. Aggressive timelines fail in enterprise environments.

Diverse Vendor Ecosystem#

The network has Cisco equipment, firewalls from Palo Alto, load balancers from F5, routers from Juniper, servers from Dell, virtualization from VMware. Each vendor has different IPv6 maturity and support.

Impact: Compatibility testing across vendors takes time. Some equipment may need replacement.

Compliance and Audit Requirements#

Financial services, healthcare, and government sectors face regulatory requirements. Security controls must be documented. Changes require compliance review. IPv6 introduces new attack surfaces that auditors question.

Impact: Security architecture and documentation need updates before deployment.

Migration Assessment Phase#

Before planning deployment, understand your current state.

Network Infrastructure Inventory#

Document every network device and its IPv6 capabilities:

Core routing:

• Router models and firmware versions
• IPv6 routing protocol support (OSPFv3, BGP, EIGRP)
• Performance impact of IPv6 (some older routers process IPv6 in software, not hardware)

Switching:

• VLAN support for dual-stack
• First-hop security features (RA Guard, DHCPv6 Guard)
• IPv6 ACL capabilities

Firewalls:

• IPv6 packet filtering support
• Stateful inspection for IPv6
• Parity between IPv4 and IPv6 rule sets

Load balancers:

• IPv6 virtual IP support
• Health checks over IPv6
• SSL/TLS termination for IPv6

VPN concentrators:

• IPv6 transport and tunneling
• Dual-stack client support

Wi-Fi controllers:

• IPv6 on SSIDs
• RA Guard on wireless VLANs

Create a matrix: Device → Model → Firmware → IPv6 Support Level → Required Upgrades

Flag devices that:

• Don't support IPv6 (replacement needed)
• Support IPv6 but need firmware updates
• Support IPv6 with performance caveats

Application Inventory and Assessment#

This is the hardest part. You need to identify every application and assess IPv6 readiness.

Inventory structure:

Assessment criteria:

1. Network binding: Does the app bind to 0.0.0.0 (IPv4-only) or :: (IPv6-capable wildcard)?
2. Address storage: Database schemas using 32-bit integers for IPs? VARCHAR fields long enough for IPv6?
3. Configuration: Config files with hardcoded IPv4 addresses vs. DNS names?
4. API dependencies: Do API calls use IPv4 literals in URLs?
5. Logging and monitoring: Do logs parse IPv6 addresses correctly?

Testing approach:

Start with non-production environments:

# Disable IPv4 on test server to force IPv6
sysctl -w net.ipv4.conf.all.disable_ipv4=1
 
# Run application
# Does it start? Can clients connect? Do all features work?

Applications that fail in IPv6-only environments need remediation or dual-stack accommodation.

Address Planning#

Unlike IPv4's /24 subnets carefully carved from limited space, IPv6 gives you abundance. Plan for growth, future services, and organizational structure.

Typical enterprise allocation: /32 from RIR (or /48 from ISP)

Allocation example for /32:

2001:db8::/32 - Organization allocation
 
Divide by region:
2001:db8:0100::/40 - North America
2001:db8:0200::/40 - Europe
2001:db8:0300::/40 - Asia Pacific
 
Divide North America by site:
2001:db8:0100::/48 - Headquarters
2001:db8:0101::/48 - Data Center 1
2001:db8:0102::/48 - Data Center 2
2001:db8:0103::/48 - Branch Office 1
 
Divide headquarters /48 by function:
2001:db8:0100:0001::/64 - Corporate LAN
2001:db8:0100:0002::/64 - Guest WiFi
2001:db8:0100:0003::/64 - Voice/Video
2001:db8:0100:0010::/64 - Server VLAN 1
2001:db8:0100:0011::/64 - Server VLAN 2
2001:db8:0100:0100::/64 - Management network

Key principles:

• Use /64 for all LANs: Required for SLAAC, simplifies operations
• Use /48 per site: Gives 65,536 subnets per location (enough forever)
• Hierarchical allocation: Makes routing aggregation and summarization easy
• Document the scheme: Create internal registry documenting allocations

Avoid the IPv4 mindset of conserving addresses. Generous allocation simplifies operations.

Security Architecture Review#

IPv6 changes attack surfaces. Security architecture needs updates.

Firewall rule parity:

Many enterprises have hundreds of IPv4 firewall rules refined over years. Each one needs IPv6 equivalent:

# IPv4 rule
permit tcp any host 192.0.2.10 eq 443
 
# IPv6 equivalent
permit tcp any host 2001:db8:100::10 eq 443

Automating this conversion is tempting but dangerous—rule semantics may differ (RFC 1918 private addresses don't have IPv6 equivalent concepts).

New IPv6 attack vectors:

• ICMPv6 filtering: IPv6 requires ICMPv6 for operation (unlike ICMP in IPv4). You can't block all ICMPv6. Understand which types to allow.
• Extension headers: IPv6 extension headers can fragment, encrypt, or route packets in ways that complicate inspection. Firewalls need deep packet inspection.
• NDP security: Neighbor Discovery Protocol replaces ARP and requires protection (RA Guard, SEND). See our NDP Security guide.
• IPv6-specific reconnaissance: Attackers scan IPv6 differently. Monitor for unusual ICMPv6 patterns.

Segmentation strategy:

If you currently use RFC 1918 private addressing (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) with NAT for "security by obscurity," you need a real segmentation strategy for IPv6.

IPv6 has unique local addresses (ULA, fc00::/7) similar to RFC 1918, but the goal should be routable global addresses with firewall protection, not hiding behind NAT.

Design firewall zones:

• Perimeter (Internet-facing)
• DMZ (public services)
• Internal (corporate resources)
• Restricted (sensitive data)

Apply zero-trust principles: default deny, explicit permits based on business need.

Phased Rollout Strategy#

Enterprise migrations require incremental deployment, not big-bang cutover.

Phase 1: Lab and Testing (1-2 months)#

Objective: Validate technical feasibility without production risk.

Activities:

1. Build IPv6 test lab:

   • Replicate production network topology at small scale
   • Enable IPv6 on test network infrastructure
   • Configure dual-stack addressing

2. Test critical applications:

   • Deploy test instances of top 10 business-critical apps
   • Test from IPv6-only clients
   • Document issues and workarounds

3. Validate security controls:

   • Configure firewall rules for test environment
   • Test intrusion detection/prevention with IPv6
   • Verify logging and monitoring capture IPv6 traffic

4. Train core team:

   • Hands-on IPv6 training for network and security teams
   • Troubleshooting practice
   • Document lessons learned

Success criteria: All critical applications work in test environment, team comfortable with IPv6 basics.

Phase 2: Pilot Deployment (2-3 months)#

Objective: Deploy IPv6 to limited production environment, prove operational readiness.

Pilot selection criteria:

Choose a pilot site that:

• Has technical staff on-site for rapid response
• Isn't business-critical (branch office, not headquarters)
• Has manageable application count
• Represents typical environment (not special case)

Pilot activities:

1. Enable IPv6 on network infrastructure:

   # Example Cisco router configuration
   ipv6 unicast-routing
    
   interface GigabitEthernet0/0
     description Uplink to ISP
     ipv6 address 2001:db8:100::1/64
     ipv6 enable
    
   interface GigabitEthernet0/1
     description LAN
     ipv6 address 2001:db8:100:1::1/64
     ipv6 nd prefix default no-advertise
     ipv6 nd other-config-flag

2. Configure dual-stack addressing:

   • SLAAC for client addressing or DHCPv6
   • Static assignments for servers
   • Update DNS with AAAA records

3. Deploy monitoring:

   • IPv6 traffic collection in NetFlow/sFlow
   • Separate dashboards for IPv4 vs IPv6 metrics
   • Alerts for IPv6-specific issues

4. Run pilot for 30-60 days:

   • Monitor stability and performance
   • Collect user feedback
   • Document issues and resolutions
   • Measure key metrics (latency, packet loss, application performance)

Success criteria: Pilot runs stably for 60 days, no major incidents, performance meets baselines.

Phase 3: Production Rollout (6-12 months)#

Objective: Extend IPv6 to all production sites and services.

Rollout approach:

Deploy in waves, grouped by risk and complexity:

Wave 1: Low-risk sites (months 1-3)

• Branch offices
• Regional sites
• Non-critical infrastructure

Wave 2: Medium-risk infrastructure (months 4-6)

• Data center networks (internal)
• Corporate headquarters
• Development/staging environments

Wave 3: Customer-facing services (months 7-9)

• Public websites
• E-commerce platforms
• Customer portals
• External APIs

Wave 4: Critical core infrastructure (months 10-12)

• Core data center servers
• Financial systems
• ERP/CRM systems

Between waves, pause for:

• Review of previous wave's issues
• Refinement of procedures
• Additional training if needed
• Business approval to proceed

Rollback planning:

Every deployment needs a rollback plan:

# Disable IPv6 quickly if needed
interface GigabitEthernet0/1
  no ipv6 address
  shutdown

More sophisticated: keep IPv4 active (dual-stack), remove only AAAA DNS records to shift traffic back to IPv4.

Phase 4: Optimization and IPv4 Sunset (12+ months)#

Objective: Tune performance, deprecate IPv4 where possible.

Activities:

1. Traffic analysis:

   • Measure IPv4 vs IPv6 traffic ratios
   • Identify services still predominantly IPv4
   • Push laggards to IPv6

2. Performance optimization:

   • Tune IPv6 routing (aggregation, prefix summarization)
   • Optimize firewall rules (consolidate, simplify)
   • Remove legacy configurations

3. IPv4 deprecation:

   • Identify services that can go IPv6-only
   • Reclaim IPv4 addresses
   • Reduce dual-stack overhead

This phase extends indefinitely as IPv6 becomes the primary protocol.

Training and Change Management#

Technology is only part of enterprise migration. People and processes matter as much.

Skills Development#

Network team training needs:

• IPv6 addressing and subnetting
• Routing protocols (OSPFv3, BGP4+)
• ICMPv6 and NDP
• Troubleshooting with IPv6 tools
• Security (filtering, NDP attacks)

Security team training needs:

• IPv6 threat landscape
• Firewall rule design for IPv6
• IDS/IPS signature differences
• Incident response with IPv6 artifacts

Application team training needs:

• IPv6-aware application development
• Testing applications for IPv6 compatibility
• Database schema considerations
• API design for dual-stack

Help desk training needs:

• Basic IPv6 concepts (enough to triage tickets)
• Common user-facing issues
• When to escalate to network team

Training delivery options:

• Vendor training (Cisco, Juniper, etc.)
• Online courses (Pluralsight, Udemy, INE)
• Industry conferences and workshops
• Internal knowledge sharing sessions
• Hands-on lab exercises

Budget for training in migration planning. Underskilled teams cause delays and incidents.

Documentation Updates#

Update all operational documentation for IPv6:

Network diagrams: Add IPv6 addressing Runbooks: Update procedures for dual-stack Disaster recovery: Include IPv6 in failover procedures Change management: Templates for IPv6-related changes Incident response: IPv6 troubleshooting guides

Don't assume you can "just add IPv6" to existing docs. Dual-stack networks are more complex.

Communication Plan#

Keep stakeholders informed throughout migration:

Executive updates (monthly):

• High-level progress
• Key milestones reached
• Business impact (cost savings, compliance achievements)
• Risks and mitigation

IT teams (weekly during active phases):

• Detailed technical progress
• Known issues
• Upcoming activities
• Action items

End users (as needed):

• Major changes affecting them
• How to report problems
• Self-service resources

Vendors and partners:

• IPv6 requirements for integrations
• Testing coordination
• Timeline expectations

Poor communication causes resistance and confusion. Over-communicate.

Vendor and Partner Coordination#

Enterprises don't operate in isolation. External parties need coordination.

ISP Coordination#

Your ISP provides IPv6 connectivity (hopefully).

Required information from ISP:

• IPv6 prefix allocation (size, specific assignment)
• Routing protocol (BGP session details, static routes)
• Support contact for IPv6 issues
• SLA terms for IPv6 (same as IPv4?)

Fallback planning:

If primary ISP doesn't support IPv6:

• Request IPv6 support (with timeline)
• Consider dual-ISP with IPv6-capable backup
• Temporary tunnel broker (Hurricane Electric) as bridge

Don't let ISP limitations block your migration. But also don't assume they're ready—verify early.

Application Vendor Coordination#

Off-the-shelf software needs vendor support for IPv6.

Questions for vendors:

• Does product version X support IPv6?
• If not, which version adds support?
• Are all features IPv6-compatible or just some?
• What configuration changes are needed?
• Has it been tested in dual-stack environments?
• Any known issues or limitations?

Get answers in writing. Sales teams say "yes," but verify with technical documentation or engineering.

Contract leverage:

If you're negotiating new contracts or renewals, include IPv6 requirements:

• "Software must support IPv6 addressing"
• "IPv6 support must be at feature parity with IPv4"
• "Vendor provides IPv6 testing assistance"

Partner Network Integration#

B2B integrations, EDI connections, and partner APIs need coordination.

Notification timeline:

• 6 months before: Notify partners of IPv6 deployment plans
• 3 months before: Share specific IPv6 addresses and DNS names
• 1 month before: Joint testing in staging environments
• Deployment: Coordinated cutover with fallback plan

Partners often move slowly. Start early.

Application Compatibility Remediation#

Some applications won't "just work" with IPv6. Remediation strategies:

Strategy 1: Configuration Updates#

Many apps support IPv6 but default to IPv4-only bindings.

Example: Web server configuration

Apache:

# IPv4-only (old)
Listen 80
 
# Dual-stack (updated)
Listen 0.0.0.0:80
Listen [::]:80

Nginx:

# Dual-stack
listen 80;
listen [::]:80;

Database connection strings:

# IPv4 literal (bad)
jdbc:postgresql://192.0.2.10:5432/db
 
# DNS name (good)
jdbc:postgresql://db.example.com:5432/db
 
# IPv6 literal with brackets (if necessary)
jdbc:postgresql://[2001:db8::10]:5432/db

Strategy 2: Code Remediation#

Applications with hardcoded IPv4 assumptions need code changes.

Common issues:

IP storage in 32-bit integers:

-- Old schema
CREATE TABLE connections (
  ip_address INTEGER
);
 
-- New schema (supports both)
CREATE TABLE connections (
  ip_address INET
);

IPv4-specific regex validation:

# Old regex (IPv4-only)
ip_pattern = r'^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$'
 
# Updated regex (IPv4 and IPv6)
import ipaddress
def is_valid_ip(addr):
    try:
        ipaddress.ip_address(addr)
        return True
    except ValueError:
        return False

Socket binding issues:

# IPv4-only
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 
# Dual-stack
sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
sock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_V6ONLY, 0)

Strategy 3: Proxy/Translation#

For applications that can't be updated (vendor-unsupported, legacy, lost source code), use proxies.

Application-layer proxy:

nginx as reverse proxy:

# Frontend (dual-stack)
server {
    listen 80;
    listen [::]:80;
 
    server_name legacy.example.com;
 
    # Backend (IPv4-only)
    location / {
        proxy_pass http://192.0.2.100:8080;
    }
}

Clients connect via IPv4 or IPv6 to nginx. Nginx forwards to IPv4-only backend.

Network-level translation:

NAT64 gateway for IPv6-only clients to reach IPv4-only services (see our NAT64 guide).

Monitoring and Metrics#

You can't manage what you don't measure. Track IPv6 deployment progress and health.

Key Performance Indicators#

Deployment progress:

• Percentage of network devices IPv6-enabled
• Percentage of servers with AAAA records
• Percentage of applications tested and certified IPv6-ready
• Number of sites completed vs. total

Traffic metrics:

• IPv6 vs. IPv4 traffic volume ratio
• Trend over time (should increase)
• Per-application protocol usage
• Geographic distribution

Reliability:

• IPv6 packet loss rate vs. IPv4
• IPv6 latency vs. IPv4
• IPv6-related incidents and downtime
• Mean time to resolution for IPv6 issues

Security:

• IPv6 firewall denials (unexpected traffic)
• IPv6-specific attack attempts
• NDP security violations (RA Guard drops)

Monitoring Tools#

NetFlow/sFlow:

Collect IPv6 flow data separately from IPv4:

# Cisco NetFlow for IPv6
interface GigabitEthernet0/1
  ipv6 flow monitor FLOW-MONITOR input
  ipv6 flow monitor FLOW-MONITOR output

SNMP:

Monitor IPv6 interface statistics:

• ipv6IfStatsInReceives
• ipv6IfStatsOutTransmits
• ipv6IfStatsInDiscards

Synthetic monitoring:

Regular health checks from IPv6 sources:

#!/bin/bash
# Check critical services via IPv6
ping6 -c 5 app1.example.com
curl -6 https://app1.example.com/health

Alert if IPv6 health checks fail while IPv4 succeeds (indicates IPv6-specific issue).

Log aggregation:

Ensure SIEM/log aggregation handles IPv6:

• Parse IPv6 addresses correctly
• Correlate IPv4 and IPv6 connections from same user
• Alert on IPv6 anomalies

Common Enterprise Migration Mistakes#

Learn from others' failures:

1. Lack of Executive Sponsorship#

Mistake: Treating IPv6 as "IT project" without business buy-in.

Result: Insufficient budget, resources deprioritized, stalls during difficult phases.

Solution: Build business case highlighting costs (cloud IPv4 fees), compliance requirements, and competitive positioning. Get executive sponsor who owns migration success.

2. Underestimating Application Complexity#

Mistake: Assuming "modern apps support IPv6, no problem."

Result: Discovering mid-migration that critical apps fail with IPv6, causing delays.

Solution: Thorough application inventory and testing early. Assume nothing works until proven.

3. Inadequate Training#

Mistake: Deploying IPv6 with team that learned IPv6 from Wikipedia articles.

Result: Configuration errors, slow troubleshooting, lack of confidence, rollbacks.

Solution: Invest in formal training before deployment. Hands-on lab practice. Hire consultants for knowledge transfer.

4. Forgetting Security#

Mistake: Enabling IPv6 without updating firewall rules.

Result: Hosts exposed to Internet with no filtering. Security incidents. Emergency rollback.

Solution: Security design before deployment. Test with vulnerability scanning. Never enable IPv6 on production networks without matching security policies.

5. No Rollback Plan#

Mistake: Assuming migration will go smoothly, no plan B.

Result: When issues arise, panic. Uncoordinated changes. Outages extended.

Solution: Document rollback procedures for each phase. Test rollback in lab. Have clear decision criteria for when to roll back.

6. Ignoring DNS#

Mistake: Adding AAAA records without ensuring IPv6 connectivity works.

Result: IPv6-capable clients try IPv6 first, fail, wait for timeout, fall back to IPv4. Slow performance, user complaints.

Solution: Only publish AAAA records after verifying IPv6 connectivity is stable. Monitor DNS query patterns.

7. Over-Aggressive Timeline#

Mistake: Ambitious "complete in 6 months" plan for large enterprise.

Result: Corners cut, testing skipped, incidents, failed migration.

Solution: Realistic timeline based on organizational capacity. Better to take 18 months and succeed than fail in 6.

Success Metrics and Milestones#

Define success clearly:

Phase 1 (Lab) Success:

• Test environment operational
• Top 10 apps tested and documented
• Team trained and confident

Phase 2 (Pilot) Success:

• Pilot site running dual-stack for 60 days
• No major incidents
• User satisfaction maintained
• Monitoring and processes proven

Phase 3 (Production) Success:

• All sites dual-stack enabled
• Critical apps accessible via IPv6
• Security policies enforced
• IPv6 traffic > 25% of total

Long-term Success:

• IPv6 traffic > 50% of total
• IPv4 address reclamation underway
• Team proficient in IPv6 operations
• Compliance requirements met

Celebrate milestones. Migration is long—team morale needs positive reinforcement.

Case Study: Financial Services Enterprise#

Organization: Regional bank, 5,000 employees, 100 branches, highly regulated

Business drivers:

• Cloud migration increasing IPv4 costs
• Compliance requirement from regulatory audit
• Security improvements (end-to-end encryption without NAT)

Timeline: 18 months

Approach:

Months 1-3: Assessment

• Network audit: 90% of equipment supported IPv6, 10% needed firmware updates
• Application inventory: 150 applications, 80% vendor-supported IPv6, 15% needed testing, 5% legacy (IPv4-only with proxy solution)
• Address planning: /32 allocation from ARIN, hierarchical design by region and function

Months 4-6: Lab and Training

• Built dual-stack test environment
• Tested core banking application (vendor-supported, worked)
• Tested custom loan processing app (needed database schema update)
• Trained 20-person network and security team

Months 7-9: Pilot

• Selected mid-sized branch for pilot
• Enabled dual-stack on network infrastructure
• Deployed monitoring
• Ran for 90 days, no issues
• Documented procedures

Months 10-15: Production Rollout

• Wave 1: 50 branches (months 10-12)
• Wave 2: Data centers and headquarters (months 13-14)
• Wave 3: Customer-facing web services (month 15)
• Monthly review meetings with executive sponsor

Months 16-18: Optimization

• IPv6 traffic reached 35%
• Reclaimed 1,024 IPv4 addresses for cloud migration
• Updated disaster recovery plans
• Passed compliance audit

Key success factors:

• Strong executive sponsorship (CIO owned it)
• Realistic timeline (resisted pressure to rush)
• Thorough testing (caught issues in pilot, not production)
• Excellent documentation (procedures reused across waves)

Challenges overcome:

• Legacy ATM network vendor delayed IPv6 support → isolated on separate network
• Third-party payment processor not IPv6-ready → maintained IPv4 connectivity for integration
• Initial firewall rule gaps → discovered in pilot, fixed before production rollout

Start Your Migration Journey#

Enterprise IPv6 migration is complex but manageable with proper planning:

Immediate next steps:

1. Secure executive sponsorship: Build business case, get commitment
2. Inventory current state: Network devices, applications, skills
3. Plan addressing: Design your IPv6 allocation structure
4. Build lab environment: Test before production
5. Train core team: Invest in skills development
6. Run pilot: Prove it works before wide deployment

Don't wait for "perfect conditions." They won't come. Organizations that started IPv6 five years ago are now reaping benefits while peers scramble to catch up.

The best time to start was 2010. The second-best time is now.

Related Articles#

• IPv6 Migration Strategies - Technical migration approaches
• IPv6 Best Practices - Operational excellence for IPv6 networks
• Dual-Stack Deployment - Running IPv4 and IPv6 together

Frequently Asked Questions#