Many of us assume that most vendors\u2019 products or services support IPv6, right?\u00a0 If this question were asked in a Request for Proposal (RFP), they are sure to check the \u201cmy product is IPv6 ready\u201d box.\u00a0 But what exactly does that mean\u2014does that mean you can confidently deploy the device in your production IPv6 network?\u00a0 You see that IPv6 is listed as a supported protocol on the product spec sheet, but will it work in your environment?\u00a0 And what if your production network must operate IPv6-only?<\/p>\n
Unfortunately, a number of products do not support top-to-bottom IPv6 today.\u00a0 We will delve into this topic to create a better understanding of what IPv6-only means, and attempt to nudge vendors, many of whom have devoted considerable resources to support IPv6 already, over the finish line.\u00a0 This blog will not call out or shame any particular vendor (though you know who you are!), rather it is an attempt to obtain better IPv6-only buy-in.<\/p>\n
When I was younger, to make the point that IPv6 support should be standard, I often joked that \u201cIPv6 is old enough to drink.\u201d\u00a0 Sadly, I\u2019ve been saying that for years now.\u00a0 Why are some vendors still centering their attention on IPv4?\u00a0 At this point IPv4 is merely a holdover that we should be accommodating, not focusing primary development around.\u00a0 Below I will attempt to provide some context on this topic.<\/p>\n
There is a true need for network products and services to operate in the absence of IPv4.\u00a0 Public and private organizations alike have recognized this and are making the push.\u00a0 In November of last year (2020), the Office of Management and Budget (OMB) issued Memorandum M-21-07 \u201cCompleting the Transition to Internet Protocol Version 6 (IPv6)<\/a>\u201d, which outlines the Federal government’s strategic intent to \u201cdeliver its information services, operate its networks, and access the services of others using only IPv6.”\u00a0 There have been other Federal government IPv6 mandates dating back to 2005, but this document has more \u201cteeth\u201d and dictates concrete and aggressive IPv6-only goals that must be met.\u00a0 The memorandum includes typical structural directives dictating the creation of a project team, IPv6 pilots, drafting an implementation plan, etc.\u00a0 But at the heart of the directive are milestones to \u201cfully enable native IPv6 operation.\u201d\u00a0 The memorandum requires Federal agencies to develop and implement plans to ensure that \u201cat least 80% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2025,\u201d with initial, incremental targets for 2023 (20%) and 2024 (50%).\u00a0 Finally, agencies must provide a plan and schedule to replace or retire systems that cannot be converted to IPv6.\u00a0 This is an aggressive directive.\u00a0 And to be clear, this mandate does not accommodate dual stack (IPv6 and IPv4) environments.\u00a0 Replacing any device that cannot operate in the absence of IPv4 should be a wakeup call for vendors wanting to continue to do business with the Federal government.<\/p>\n The Federal government does not have a monopoly on the IPv6-only focus.\u00a0 An ever-increasing number of enterprises are jumping on board too.\u00a0 The business drivers vary, but typically revolve around performance, scalability, simplicity, and address scarcity.\u00a0 Running IPv6 can also makes mergers and acquisitions (M&A) much simpler.\u00a0 Starting an IPv6 adoption program has long been a recommendation for enterprises, and those with vision have taken this guidance and acted on it.\u00a0 The operational cost of running IPv4 is going up (never mind the actual cost of IPv4 addresses<\/a>) and enterprises realize it.\u00a0 The benefits, best practices, and lessons learned from those that have already rolled out IPv6-only networks was summarized in one of my previous Center of Excellence posts<\/a>.\u00a0 It is good to see enterprises, which have traditionally lagged, starting to get onboard the IPv6-only adoption train.\u00a0 Proper IPv6-only product support from their vendors will be a key to their success.<\/p>\n IPv6 protocol support cannot be encapsulated as a singular thing<\/em>.\u00a0 In other words, support for IPv6 is not a simple \u201cyes\/no\u201d matter.\u00a0 IPv6 is defined by hundreds of various RFCs and standards.\u00a0 A vendor may claim to \u201csupport IPv6\u201d, but do they support RDNSS (RFC 8106<\/a>), or IPv6-signaled LDP (RFC 7552<\/a>), or Segment Routing v6 (SRv6, RFC 8986<\/a>), or\u2026?\u00a0 Perhaps you get the picture: \u201cIPv6 support\u201d can mean many different things that may or may not be operationally relevant to your organization and its network. \u00a0Ultimately, an enterprise will need to create a feature\/support matrix based on their individual networking requirements to assist in product selection.\u00a0 If an enterprise needs DHCPv6 (because they use DHCPv4 and want operational consistency), what version of Network Operating System (NOS) is required in the vendor\u2019s code to support that feature?<\/p>\n When formulating this feature\/support matrix, it is important to maintain a broad view of what constitutes IPv6-only.\u00a0 Generically, all three network planes (i.e., data, control, and management) need to function without IPv4.\u00a0 It is common for IPv6 vendor support to be strong and relatively mature in the data plane.\u00a0 Starting in the data plane makes sense if the assumption is that customers operate in a dual stack environment. \u00a0The vendor wants to make sure, first and foremost, that they can move IPv6 packets.\u00a0 However, IPv6 support in the data plane alone is not sufficient for IPv6-only environments.<\/p>\n For vendors, supporting IPv6 is typically an evolution\u2014especially if there is protocol baggage like a long history of IPv4 in the product line.\u00a0 A common progression is building IPv6 support into the data, then control, then management planes.\u00a0 There is even evolution within each plane.\u00a0 Initially, only static routes may be supported in the control plane.\u00a0 Later, support may be added for dynamic routing protocols such as OSPFv3 and MP-BGP.<\/p>\n While data plane features may be mature, vendor IPv6 support can be weaker when it comes to the control and management planes.\u00a0 The questions to ask your vendor to gauge their progress on IPv6 include, \u201cCan I manage the device over IPv6?\u201d, \u201cCan the device be patched over an IPv6-only network?\u201d, \u201cDoes the SDN underlay (control plane) support IPv6?\u201d\u00a0 It is possible that an SDN fabric can pass IPv6 packets (data plane) but not be able to be managed, nor configured using IPv6-only.\u00a0 Also, the product should support full FCAPS<\/a> management (fault, configuration, accounting, performance, security)\u2014from GUI access to SNMP polling to RESTful APIs to logging to security.\u00a0 There should no management feature fall-off when migrating to IPv6.\u00a0 To assist, if a vendor claims that something can be done via IPv6, ask them for configuration scripts.\u00a0 That is a good initial step to ferret out whether such support truly exists.<\/p>\n Furthermore, an enterprise needs to take into consideration all aspects of its IT networking infrastructure.\u00a0 This includes hardware, software, firmware, applications, cloud partners, and \u201cas-a-Service\u201d environments that an organization may rely on.\u00a0 In general, as enterprises do an assessment of their environment, they should ask the question, \u201cIf IPv4 did not exist, would our hardware, applications, and extranets still operate as required?\u201d<\/p>\n Embarking on an IPv6 adoption program can be intimidating\u2014especially IPv6-only.\u00a0 The good news is that organizations do not need to start from scratch.\u00a0 Remember, IPv6 is old enough to drink, and there are numerous, excellent resources to assist in selecting the right products to meet your networking requirements.<\/p>\n There are two certification programs that your company can leverage to assist in IPv6 assessment.\u00a0 Products in compliance with these programs are not necessarily guaranteed to work with your requirements (see \u201cTest, assess, and verify below\u201d), but certification does provide a starting point.\u00a0 First, the IPv6 Ready Logo program<\/a> is an IPv6 Forum-led initiative with the mission of defining test specifications for IPv6 conformance and interoperability, as well as increasing access to self-test tools.\u00a0 More information can be found on their website<\/a>.\u00a0 A particularly useful link is the IPv6 Ready Logo Program Approved List<\/a> database, which provides various methods to search for complaint devices in a number of different product classifications.<\/p>\n A second program that may be of assistance is the U.S. National Institute of Standards and Technology (NIST) USGv6<\/a>.\u00a0 In conjunction with other U.S. governmental agencies, NIST has developed standards, a testing program, and tools to support the adoption of IPv6 in the U.S. government.\u00a0 Although USGv6 is governmentally focused, NIST makes it clear that their body of work is publicly available for use by any organization \u2013 public or private.<\/p>\n Neither NIST nor the IPv6 Forum have labs to conduct testing against their specifications; they rely on third party agencies for that.\u00a0 The University of New Hampshire Interoperability Lab<\/a> (UNH-IOL) is the sole accredited testing facility for the USGv6 program, and the IPv6 Ready Logo has six \u2013 one of which also happens to be the UNH-IOL.\u00a0 The University of New Hampshire provides a number of great resources on their web site.\u00a0 The IOL also offers a testing suite called INTACT<\/a> that includes protocol validation for IPv6 core, IPsec, DHCPv6, BGP, and CE routers\u2014evaluating them for compliance against various IPv6-related RFCs.\u00a0 A video at the bottom of the INTACT webpage offers an excellent overview of the product.\u00a0 Their IPv6 Testing and Certification<\/a> page provides additional links and information about the USGv6 and IPv6 Ready programs, as well as a link to their USGv6 Tested Registry<\/a>.\u00a0 One note of caution, when looking for certifications and\/or logos, ensure the \u201cIPv6 readiness\u201d category conforms with the function you want the device to perform.\u00a0 For example, a firewall may be IPv6 router certified, however it may not provide the IPv6 L3-7 security protections you require.\u00a0 Make sure you understand the context of the certification and how that applies to your specific requirements.\u00a0 Listen to our IPv6 Buzz podcast show #6 with Tim Winters of the UNH-IOL on “Why And How To Test IPv6 Interoperability<\/a>“.<\/p>\n The programs above are focused on network platforms and infrastructure.\u00a0 Organizations will also want to ensure that their applications (likely developed in an IPv4 setting) work end-to-end in an IPv6-only environment.\u00a0 It is not uncommon for organizations to have developed in-house applications to support their business.\u00a0 For internally developed software, there are several tools to assist in IPv6 application development or updates\u2013<\/strong>two will be noted here.\u00a0 Apple (which mandated IPv6-only support for iOS 9 apps in 2016<\/a>) has a Supporting IPv6-only Networks<\/a> site, which provides resources for app developers.\u00a0 Another excellent guide for coders is Dan York\u2019s book Migrating Applications to IPv6<\/a>.\u00a0 These resources are a good starting point to get developers on the proper track to support IPv6-only.<\/p>\n Not that we don\u2019t trust logos and vendor claims of feature support, but even the best intentions are unable to cover every corner case and boundary condition.\u00a0 If possible, it is highly recommended to validate the functions you require in a POC lab.\u00a0 There is no substitute for a comprehensive proof-of-concept environment.\u00a0 Create test cases that vet your network architecture top-to-bottom and execute them in this safe environment.\u00a0 Turn IPv4 off and confirm deployment, management, and operational functionality.\u00a0 The absence of IPv4 will quickly expose any IPv6 support gaps.<\/p>\n Even small enterprises can build a POC environment.\u00a0 And it does not have to be expensive.\u00a0 Vendors and VARs have a vested interest in helping you succeed with the right product.\u00a0 Leverage them where possible.\u00a0 They may be able to provide loaner equipment or allow you to use their lab environments.\u00a0 Some larger vendors have sandboxes that may also be of assistance.\u00a0 In addition, virtual network simulation tools such as EVE-NG<\/a> can be used to create and test complex network environments (routers, switches, ADCs, firewalls, Linux and Windows servers) for little expense.\u00a0 Finally, there are hosting environments like IPv6 Only Hosting<\/a> that are great platforms to experiment with how tools and applications operate in an IPv6-only world.\u00a0 For additional expert tips, I recommend listening to our IPv6 Buzz podcast show #70 on Building an IPv6 lab<\/a>.<\/p>\n Building a suitable lab and turning IPv4 off will expose any IPv6-only shortcomings.\u00a0 Today, IPv6-only is possible, and numerous entities (typically those that have complete control their networking and application stack) have successfully done it, but it still may be challenging.\u00a0 If a critical network component is not able to function IPv6-only, temporary workarounds may be needed to accommodate pockets of legacy IPv4.\u00a0 In general, however, if a tool, package, or application does not support IPv6, find a modern replacement.\u00a0 Take a cue from the U.S. government\u2019s latest mandate – create a plan to retire these systems.<\/p>\n The push to turn off IPv4 is long overdue.\u00a0 Enterprises are recognizing the cost of hanging on to the legacy protocol, and the Federal government has a fresh mandate to update network elements to operate IPv6-only.\u00a0 This should be a wake-up call for networking vendors to support IPv6 across not only the data plane, but also the management and control planes.\u00a0 A recommendation is to turn IPv4 off when developing products\u2014at this point IPv6 should be considered the default (which happens to be in line with operating system behavior).<\/p>\n Enterprises adopting IPv6 should take solace that there are numerous resources to assist in their journey.\u00a0 One recommendation is to work with vendors and communicate IPv6 requirements to them.\u00a0 This is not just for large companies, but even smaller enterprises.\u00a0 Finally, there is no substitute for creating a POC environment to test IPv6.\u00a0 It will not only help validate functionality, but also double as a training environment\u2014an environment that will successfully allow you to test, verify, and ultimately implement\u2026 IPv6-only.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Many of us assume that most vendors\u2019 products or services support IPv6, right?\u00a0 If this question were asked in a Request for Proposal (RFP), they are sure to check the \u201cmy product is IPv6 ready\u201d box.\u00a0 But what exactly does that mean\u2014does that mean you can confidently deploy the device in your production IPv6 network?\u00a0 […]<\/p>\n","protected":false},"author":351,"featured_media":4042,"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,502],"class_list":{"0":"post-6359","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-ipv6-support","11":"entry"},"acf":[],"yoast_head":"\nWhat constitutes IPv6-only product support?<\/strong><\/h3>\n
Resources and tools to assess IPv6 support<\/strong><\/h3>\n
Test, assess, and verify<\/strong><\/h3>\n
Conclusions<\/strong><\/h3>\n