Keeping the legacy Internet Protocol working over an IPv6 backbone<\/p>\n
2016 has witnessed\u00a0IPv6 adoption continuing<\/a>\u00a0at an amazing rate.\u00a0 Even though IPv6 adoption has been doubling every year for the past few years, IPv4 usage continues to rise as well.\u00a0 However, at some point in the next few years,\u00a0IPv6 will overtake IPv4<\/a>\u00a0and\u00a0IPv4 will eventually be considered the legacy<\/a>\u00a0protocol.\u00a0 The IETF has been watching these trends for more than two decades now and advocates for IPv6-only efforts as well as the prioritization of standards that support dual-protocol configuration.\u00a0 There have also been many discussions about\u00a0declaring IPv4 as a “historic” protocol<\/a>.<\/p>\n The IETF has formed a\u00a0sunset4 working group<\/a>\u00a0focused on planning for the sun to set on IPv4 and to plan for the eventual disabling of IPv4.\u00a0 This group has produced\u00a0a draft exploring the gaps that exist<\/a>\u00a0for systems that still cling to IPv4 and are unable to operate smoothly in an IPv6-only world.\u00a0\u00a0Lee Howard<\/a>\u00a0of Charter Communications has written a draft on\u00a0ending work on IPv4<\/a>\u00a0and a draft\u00a0declaring IPv4 historic<\/a>.\u00a0 The\u00a0sunset4 WG met at IETF 95<\/a>\u00a0and discussed if\u00a0IPv4 can be considered historic<\/a>.\u00a0 Geoff Huston\u00a0also wrote<\/a>\u00a0about the conversations that took place at IETF 95, \u201cDeclaring IPv4 Historic<\/a>\u201d and about \u201cDeclaring IPv6 an Internet Standard<\/a>\u201d.\u00a0 The point of these efforts is that even though IPv6 is widely deployed on the Internet,\u00a0RFC 2460<\/a>\u00a0remains listed as \u201cStandards Track, Draft Standard\u201d and should be promoted to a full \u201cInternet Standard\u201d.\u00a0 The\u00a0Internet Architecture Board<\/a>\u00a0(IAB) has also made a statement about the\u00a0preference for IPv6 in new Internet standards<\/a>.<\/p>\n Even back in the mid-1990s, the inventors of IPv6 knew full well that a transition to IPv6 would be challenging and that there needed to be a wide variety of\u00a0transition mechanisms<\/a>\u00a0to make migration feasible and manageable.\u00a0 These transition techniques (RFC 4213<\/a>) fall into three categories: dual-stack, tunneling, and translation. However, in spite of these techniques to facilitate transition to IPv6, as IPv4 continued to grow on a global scale, the process of wholesale rapid migration directly to IPv6 became increasingly unlikely.<\/p>\n Dual-stack is the dominant transition strategy. With dual-stack networks are configured with both IPv4 and IPv6 simultaneously and nodes support both protocols at the same time using whichever one is available, configured, or performs better (as in the case of Happy Eyeballs (RFC 6555<\/a>).\u00a0 Tunneling techniques involve encapsulating IPv6 packets within IPv4, thus allowing \u201cislands\u201d of IPv6 to cross over an \u201cocean\u201d of IPv4.\u00a0 Due to the drawbacks of tunneling (e.g., static configuration, poor resiliency and\/or scale, MTU problems, general difficulty in troubleshooting, etc.),\u00a0dual-stack is preferred whenever possible<\/a>.\u00a0 Translation is a sub-optimal approach as it is difficult to properly map IPv4 to and from IPv6 due to the differences in their protocol headers and how applications behave.<\/p>\n All of the mid-1990s transition mechanisms have now largely been superseded by the\u00a0dual-stack approach<\/a>.\u00a0 Today, IPv6 is widely deployed across the Internet and is continuing to be adopted by organizations.\u00a0 Although there is still significant effort required to fully deploy IPv6 within enterprises, IPv6 is becoming more ubiquitous everywhere else.\u00a0 IPv6 deployment has been a focus for all large service providers for many years and now virtually all large International carriers operate IPv6 on their backbones.\u00a0 Service providers have certainly felt the pressures of\u00a0IPv4 address exhaustion<\/a>\u00a0and that has driven their IPv6 deployments.<\/p>\n However,\u00a0operating a dual-protocol network<\/a>\u00a0is not a panacea.\u00a0 Running two network protocols in an environment may increase the administrative burden and\u00a0drive up operating expenses<\/a>.\u00a0 For Internet Service Providers (ISPs), reducing administrative overhead and creating a scalable network infrastructure that easily supports millions of subscribers are the primary paths towards higher profits.\u00a0 Operating a core network and services with IPv4 and IPv6 simultaneously increases expenses. Therefore, service providers would rather run a core network that uses a single protocol.\u00a0 Service providers would like to be able to operate an IPv6-only backbone network, yet still furnish connectivity for legacy IPv4 subscribers to the soon-to-be legacy IPv4 Internet.<\/p>\n It is important to recognize that dual-protocol is a transition strategy, but the goal is to end up with an IPv6-only environment.\u00a0 Making\u00a0the jump directly from IPv4 to IPv6 is not practical<\/a>, but organizations \u2013 especially service providers \u2013 will typically want to minimize the time they spend in the dual-protocol transition phase.\u00a0 As we are making this transition from\u00a0IPv4-only to dual stack to IPv6-only<\/a>, service provider network architecture and design strategies will continue to evolve.\u00a0 For example, one benefit of having an IPv6-only network is that an organization reduces the number of routes their routers must process and store, which has the byproduct of reducing the cost of their hardware infrastructure.\u00a0 During the dual-protocol transition phase, the routers must hold both the IPv4 routing table (over 600,000 prefixes) and the IPv6 routing table (over 33,000 prefixes) in memory.<\/p>\n As service providers contemplate how to operate an\u00a0IPv6-only core<\/a>, they are still responsible for providing connectivity for IPv4 subscribers to content from the IPv4 Internet.\u00a0 Subscribers have numerous legacy devices that only use IPv4 and may not be IPv6-capable.\u00a0 As an example, consider a grandma who has a digital picture frame that can use exclusively IPv4 to retrieve pictures of her grandkids from a cloud picture repository. \u00a0If her ISP turns off her IPv4 Internet connectivity in favor of IPv6, she will call the ISP\u2019s tech support line to resolve the problem.\u00a0 As they attempt to explain to her how the world is moving toward IPv6, grandma will become more agitated and angry and tech support will soon feel the full force of her fury. \u00a0She might even say something like, \u201cBack in my day, all we had was 32 bit addresses, 32 bits was enough, and we were thankful!\u201d. \u00a0You don\u2019t want to take that tech-support call so it is best to keep her IPv4-only keepsake working.<\/p>\n Early transition mechanisms involved joining islands of IPv6 over an ocean of IPv4 by tunneling the IPv6 packets within IPv4.\u00a0 That gave way to the dual-protocol transition period we are in now.\u00a0 Therefore, it is only logical that there will be late-stage transition strategies that involve tunneling the ever-more-scarce IPv4 nodes over the IPv6-enabled core network.\u00a0 Service providers are financially motivated to explore the feasibility of running IPv4 as an overlay protocol over an underlay IPv6-only core network infrastructure.<\/p>\n The use of the word \u201ccloud<\/a>\u201d has become an overused term and now every new technology is referred to as some type of \u201cas a service<\/a>.\u201d The same is true for this concept of providing IPv4 service on top of a cloud of IPv6.\u00a0 There have been many other permutations of this as-a-service nomenclature.\u00a0 Hence, these methods of supporting legacy IPv4 subscribers over an IPv6-only core are now being referred to as \u201cIPv4 as a Service<\/a>\u201d or IPv4aaS.<\/p>\n This picture illustrates this concept of an IPv6-only service provider core network that connects to the Internet at one end and to subscribers at the other.\u00a0 Subscribers using IPv6 (addresses shown in green) will traverse the IPv6-only ISP backbone seamlessly, without any NAT function, and flow directly to the IPv6 Internet.\u00a0 Subscribers using legacy IPv4 (addresses shown in red) will be tunneled across the IPv6-only ISP backbone and then go through a gateway where the decapsulation occurs and a centralized\u00a0Carrier-Grade NAT<\/a>\/Large-Scale NAT<\/a>\u00a0(CGN\/LSN) function will take place before the traffic reaches the IPv6 Internet.<\/p>\n IPv4 as a Service (IPv4aaS) (Part 1) – cixhp49439<\/a><\/p>\n Many residential broadband Internet subscribers are lucky enough to\u00a0already have dual-protocol<\/a>\u00a0Internet connectivity through their ISPs.\u00a0 Most mobile phone subscribers\u00a0already have dual-protocol<\/a>\u00a0connectivity — though they probably didn\u2019t even realize it.\u00a0 Some enterprises, like\u00a0U.S. Federal government departments and agencies<\/a>, have established dual-protocol connectivity to their Internet perimeter, but few enterprises have purposely introduced IPv6 to their internal networks and systems.\u00a0 Beyond effectively managing the IPv6 that\u2019s already running internally, Enterprises may also want to establish IPv6 Internet connectivity sooner than later to allow their internal users to take advantage of\u00a0potentially faster connectivity<\/a>.<\/p>\n For enterprises, IPv4 as a Service can become part of the equation as they move to\u00a0SD-WAN architectures<\/a>.\u00a0 Enterprises already have IPv6-capable systems in their environments but many have not yet intentionally established end-to-end IPv6 connectivity.\u00a0 As enterprises procure cost-effective direct Internet links to their branches, stores, and remote-offices they may automatically receive dual-protocol Internet access.\u00a0 This will have an\u00a0effect on their IPv4 and IPv6 addressing<\/a>\u00a0at those locations.\u00a0 With IPv4 as a Service from their ISPs, the native IPv6 systems at a branch will access the Internet directly, while the IPv4-only devices at a branch will experience tunneling.\u00a0 The bottom line is that if you are using IPv6, your Internet-bound traffic will not be tunneled and is\u00a0end-to-end<\/a>\u00a0(as intended in the original concept of the Internet).\u00a0 However, if you are the last person on your block clinging to IPv4 then you may experience challenges.<\/p>\n In the\u00a0second article<\/a>, we will explore the various methods with which service providers can create an IPv4 as a Service.\u00a0 In the\u00a0third article<\/a>, we delve into even more of these IPv4 as a Service protocols.<\/p>\n","protected":false},"excerpt":{"rendered":" Keeping the legacy Internet Protocol working over an IPv6 backbone Declaring IPv6 a Standard and Declaring IPv4 Historic 2016 has witnessed\u00a0IPv6 adoption continuing\u00a0at an amazing rate.\u00a0 Even though IPv6 adoption has been doubling every year for the past few years, IPv4 usage continues to rise as well.\u00a0 However, at some point in the next few […]<\/p>\n","protected":false},"author":321,"featured_media":1993,"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":[56,38,31,39],"class_list":{"0":"post-1984","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-ipv4","9":"tag-ipv6","10":"tag-networking","11":"tag-protocols","12":"entry"},"acf":[],"yoast_head":"\nTunneling IPv6 Within IPv4<\/h2>\n
Operating a Dual-Protocol Network<\/h2>\n
Supporting IPv4-Only Nodes on an IPv6-Only Network<\/h2>\n
IPv4 as a Service<\/h2>\n
Summary:<\/h2>\n