![\"\"](\"https:\/\/blogs.infoblox.com\/wp-content\/uploads\/ipv6-dual-stack-1.png\")
<\/p>\nThe enterprise journey from using solely IPv4 to running IPv6-only leads through different stages.\u00a0 It will take many years for enterprises to phase in IPv6 as they begin to phase out IPv4.\u00a0 The early-stage transition techniques involved joining islands of IPv6 over an ocean of IPv4.\u00a0 The middle-stage transition involves both protocols in parallel in a dual-stack configuration.\u00a0 The late-stage transition techniques are still developing as organizations are seeking to operate a single-protocol, IPv6-only environment.<\/p>\n
<\/p>\n
Back in 2007, the typical guidance on IPv6 deployment was “IPv6: Dual stack where you can; tunnel where you must<\/a>“.\u00a0 In the early days of IPv6 deployment there were many tunnel-based approaches intended to smoothly allow implementors to roll out IPv6 on top of an existing IPv4 network.\u00a0 However, there were downsides to techniques like 6to4 (RFC 7526<\/a>), ISATAP (RFC 5214<\/a>), and Teredo (RFC 4380<\/a>).\u00a0 Tunneling techniques added overhead, reduced MTU size, and required latency-adding backhauling through a gateway. There were also many security concerns about IPv6 during this early period.\u00a0 These issues led to IETF discussions of deprecating dynamic tunneling approaches.\u00a0 Steps were taken to demote them in the address selection preference policy tables (RFC 6724 section 2.1<\/a>) in host operating systems.\u00a0 That is why the IPv6 prefixes 2002::\/16, 2001::\/32 have low precedence values.\u00a0 Now, Windows 10<\/a> and Windows Server 2019<\/a> have ISATAP (since the Creators Update – 1703) and 6to4 (since the Anniversary Update – 1607) disabled by default.<\/p>\n During the middle-stage of the transition, the predominant Enterprise IPv6 Deployment Guidance<\/a> (RFC 7381<\/a>) has been to deploy IPv6 to create a dual-protocol network.\u00a0 Even today, some enterprises are struggling to start their IPv6 journey and are postponing their dual-protocol deployments.\u00a0 It appears that some enterprises are “playing chicken” with the oncoming rapidly-approaching IPv6 requirement and are delaying deployment.\u00a0 They are in danger of becoming in the “technology laggards<\/a>” category when it comes to IPv6. They could be delaying for a variety of reasons, such as lack of talent or skills with IPv6, being unable to articulate the business benefits, financial or operational reasons to adopt IPv6, or other non-technical delays. We previously covered some common \u201cissues\u201d that enterprises come up with in the \u201cIPv6: It\u2019s Not You, It\u2019s Me\u201d<\/a> post.<\/p>\n There is evidence that IPv6 usage on the Internet has been growing slowly but significantly over the past decade.\u00a0 The graph below shows the typical “diffusion of innovations<\/a>” graph with the Google IPv6 Statistics<\/a> graph showing the actual IPv6 usage.\u00a0 This green-line graph is the global IPv6 usage from Google’s content-provider perspective as an early-adopter of IPv6.\u00a0 (Side-note: On the Google IPv6 Statistics graph, the weekly oscillation of the green line is “enterprise effect<\/a>” whereby end-users consuming Google’s content are more likely to go over IPv6 when at home or on their mobile device, than when they are inside the IPv4-only office.<\/p>\n Ice hockey star Wayne Gretzky’s famous quote “I skate to where the puck is going to be, not where it has been.” also applies to the enterprise transition to IPv6.\u00a0 By the time enterprises get around to deploying IPv6, it will be the dominant Internet protocol.\u00a0 If an enterprise observes that IPv6 usage in their country of operation is between 40% and 50% today, and it expects them to take 4 years to fully deploy IPv6, when they finally get IPv6 implemented the country’s IPv6 usage could be at 60% to 70%.\u00a0 This late-mover strategy may place a traditionally innovative and technology aggressive company into the unenviable “slowpoke” category.<\/p>\n When the IETF protocol designers were creating IPv6 and planning for the transition to this new protocol they did not intend for organizations to spend a lengthy amount of time in the dual-stack middle stage.\u00a0 Unfortunately, there are still many IPv4 dependencies in enterprise networks and most enterprises still need to operate an IPv4 environment (including NATs).\u00a0 There are some significant drawbacks to spending too much time in the dual-stack phase and one of the primary considerations is the increased operational costs<\/a> to maintain a dual-stack network and all its connected systems and applications running on two protocols.<\/p>\n Fast-forward to today and much of the Internet, wireless mobile services, and residential broadband subscribers are actively using IPv4 and IPv6.\u00a0 When running dual-protocols, algorithms like Happy Eyeballs (RFC 8305<\/a>) attempt connections using either IPv4 or IPv6 depending on which one performs best.\u00a0 However, this “behind-the-scenes” optimization can make it difficult to troubleshoot<\/a> when either of the address families fail.\u00a0 Dual-stack can mask IPv6 failures, giving enterprises a false sense of security that their IPv6 deployment is solid.\u00a0 End users may not realize they have broken IPv6 connectivity until they reach the point of starting to remove IPv4 from the environment (and remove Happy Eyeballs from the equation).<\/p>\n Therefore, one of the benefits of running an IPv6-only network is the simplicity of operating an environment with a single protocol with a simpler address model<\/a>.\u00a0 IPv6’s plentiful supply of globally-unique addresses relieves organizations from the constraints of limited public and private IPv4 address<\/a> space (and can even help solve challenging technical problems arising from business growth such as mergers and acquisitions<\/a>).\u00a0 Moving toward IPv6-only is the best and only way to completely divest one’s self of the constraints of IPv4 (like NAT and limited RFC 1918 space) and potentially obtain the performance improvements of IPv6<\/a>.<\/p>\n Now there are organizations that are contemplating or have already moved into the late-stage of IPv6-only networking.\u00a0 Tech-forward companies like Microsoft<\/a>, LinkedIn<\/a>, Facebook<\/a>, Cisco<\/a>, Apple<\/a>, T-Mobile<\/a>, and Google<\/a> have had IPv6-only environments for many years.\u00a0 Internet Service Providers (ISPs) and hosting companies, like Ungleich.ch Data Center Light<\/a> and Mythic Beasts<\/a>, are now operating IPv6-only core networks for operational simplicity.<\/p>\n This is some of the thinking and justification behind some government IPv6 mandates.\u00a0 The U.S. Federal government Office of Management and Budget (OMB) published a mandate in November 2020 (M-21-07<\/a>) that re-emphasizes the importance of IPv6 for government departments and agencies and sets forth a schedule to disable IPv4.\u00a0 The schedule is to have 20% IPv6-only by end of FY 2023, 50% IPv6-only by end of FY 2024, and 80% IPv6-only by end of FY 2025 (see graph below).\u00a0 The thought here is that by the 80% stage, the Internet will be predominantly using IPv6.\u00a0 The State of Washington has an IPv6 “Policy 300<\/a>” to disable IPv4 by the end of 2025, and the Chinese government<\/a> has a 100% IPv6 goal by 2025.<\/p>\n As your enterprise begins to consider a migration to IPv6, the architecture and design should not aim to end in the middle-term, dual-protocol state, but instead should chart a course through to the eventual IPv6-only goal.\u00a0 The “Lessons Learned and Recommendations from IPv6-Only Deployments<\/a>” have been documented by a few organizations (part 1<\/a>, part 2<\/a>).\u00a0 The benefits of IPv6 are realized when taking a long-term view of the transition and planning accordingly.<\/p>\n","protected":false},"excerpt":{"rendered":" The enterprise journey from using solely IPv4 to running IPv6-only leads through different stages.\u00a0 It will take many years for enterprises to phase in IPv6 as they begin to phase out IPv4.\u00a0 The early-stage transition techniques involved joining islands of IPv6 over an ocean of IPv4.\u00a0 The middle-stage transition involves both protocols in parallel in […]<\/p>\n","protected":false},"author":321,"featured_media":7019,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[38,410,411],"class_list":{"0":"post-7016","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-ipv6","9":"tag-ipv6-only","10":"tag-dual-stack","11":"entry"},"acf":[],"yoast_head":"\n![\"\"](\"https:\/\/blogs.infoblox.com\/wp-content\/uploads\/ipv6-dual-stack-2.png\")
<\/p>\n![\"\"](\"https:\/\/blogs.infoblox.com\/wp-content\/uploads\/ipv6-dual-stack-3.png\")
<\/p>\n