Adding IPv6 Requirements to your RFP

Posted on

[ Originally posted on Linkedin here: IPv6 – Adding Requirements to your RFP. Adding IPv6 Requirements to your RPF is a necessity when all the major Google, Facebook, Linkedin, and other sites are built for “IPv6” first. Meaningful IPv6 requirements in RFPs are a core tool to your dialog with your vendors. This is a shortcut for you IPv6 vendor conversations.]

Updated! We have some excellent suggestions to be included in the list. Please consider these question for any RFP you send out for Network, Systems, Cloud, SDN, NFV, Data Center, IoT, M2M, or any other buzz word you can think of …. 🙂

IPv6 is not optional! Everything in every network must support IPv6 with all the capabilities, capacity, and performance seen with IPv4 networks. In other words, you must deploy IPv6 to survive and thrive in the connective world of IoT, M2M, and everyone/everything interconnected.  The question that all networked organization must ask is “how.” How would a network organization ensure all the products meet all the IPv6 requirements?

One tool available to the network organization is the Request for Purchase (RFP). RFPs allow a networked operator influence their vendors through the power of the acquisition. They reward vendors who are fully IPv6 compliant and eliminate vendors who are not investing in their future (i.e. the future of the Internet is IPv6).

For the vendors, RFPs are tools to understand customer IPv6 requirements. Two or three RFPs which demand IPv6 feature parity will be enough for a product manager to justify coding a particular IPv6 feature.

There are some other documents that have helped network organizations write IPv6 RFP requirements. For example, RIPE-501 Requirements For IPv6 in ICT Equipment provides good materials for an RFP. But, RIPE-501 is not written in a format that can readily be cut and pasted into an RFP. What the operator needs are something that they can just “cut and paste” into their RFP. What follows are requirements that can be cut and pasted into an RFP.

What follows are elements that can be cut and pasted into an RFP. Each of these requirements has been used RFPs. They work. Sometimes vendors ask questions and push back (“why do I need to be compliant to a US IPv6 NIST document?”). But, in general, these requirements drive the desired response. This list of IPv6 requirements has been evolving. It is not a perfect list. New insight, suggestions, changes, and experience is always welcomed. If you have suggestions, please e-mail Barry Greene bgreene@senki.org.

IPv6 RFP “Cut and Paste” Requirement – Version 1.1

  1. Products and Services in the vendor’s proposal that are to be network connected or attached are expected to support both IPv4 and IPv6. This must include the ability to operate in all of the following deployments without loss of (or impact too) functionality: IPv4-only, IPv6-only, and Dual-Stack. To the extent, the following are relevant to the implementation; this must include full feature parity and should include full performance parity across all management, reporting, maintenance, provisioning, connectivity, and service – supporting functions.

  2. The vendor solution shall support native IPv6 from the device to the end-points on the Internet with no network address translation.

  3. The vendor shall provide an IPv6 deployment impact statement with the issues that would impact the existing network. This impact statement would list all the protocols supported by the product, confirmation that the protocol works on IPv6 at full equivalence to IPv4.

  4. The vendor’s solution shall allow for all elements of the network management, control, and signaling plane to use native IPv6 throughout the network. Several large carriers have converted all their internal IP addressing to IPv6. This conserves the finite IPv4 addresses for customer addressing.

  5. Service Level Agreements (SLAs) and Key Performance Indicators (KPIs) must verify both IPv4 and IPv6 addresses, interfaces and inter-connectivity are properly functioning. All performance KPI, O&M, and network monitoring tools will operate in dual IPv4 and IPv6 modes

  6. The vendor shall ensure all equipment, software and functionality uses IPv6 and is at parity with IPv4. Support for feature-parity covers area of routing (control plane), security policies (ACLs), deep packet inspection (DPI), logging (Syslog, IPFIX, etc), other functions.

  7. All computer and networking hardware, services, and applications must support IPv6 and must conform to the mandatory components of the US National Institute of Standards and Technology (NIST), Advanced Network Technologies Division (ANTD), http://www.antd.nist.gov/usgv6/ “Profile for IPv6 in the U.S. Government – Version 1.0” (USGV6). Alternative IPv6 compliance profiles can be used if approved by an industry peer-reviewed forum equivalent to NIST.

  8. All vendor equipment and software will be validated as IPv6 compliant using the IPv6 Forum, 6Connect, or other equivalents, repeatable, and peer reviewable methodologies. As a minimum, the IETF’s BMWG work for IPv6 will be used (see RFC 5180 IPv6 Benchmarking Methodology for Network Interconnect Devices).

  9. The vendor shall supply validated, repeatable, and peer reviewable test that to demonstrate IPv6 performance parity with IPv4.

    IPv6 will operate at performance parity to IPv4. Packets per Second (PPS), Transactions per Second (TPS), and other IPv6 features and functions will work at the same levels as IPv4.

    This requirement will apply to all control plane, management plane, signal plane, and data plane protocols.

    The vendor shall provide test reports at smallest packet size and IMIX to demonstrate compliance.

    All IPv6 testing shall take into account the variable IPv6 options in the headers and ensure that no header addition will cause unexpected issues. The vendor shall produce test results to demonstrate this with all IPv6 speaking network elements.

  10. All state calculations and engineering will be done with IPv4 and IPv6 addresses. This would include any state in the network element, firewalls, NATs, IPS, services or other functions.

  11. All network design and scaling projections will be completed with IPv6. This will ensure the network can scale with no impact and match the capabilities and advantages of IPv6’s feature set.

  12. The vendor’s website, support services, and other interfaces used over the Internet shall support native IPv6. This shall be demonstrated by native IPv6 connections each of the vendor’s Internet facing services. Vendors who do not have all Internet facing elements IPv6 is not a vendor who truly supports IPv6.

  13. All elements, protocols, and services must support IPv6 without the need for IPv4. True IPv6 support means there are no other signal, protocol, or other element support that needs IPv4.

  14. All elements in the system which require the ability to communicate back to the cloud (or support services) must be able to do this with IPv6 only. For example, an element in the system which needs to check for software/firmware updates must work with IPv6 only. This means the vendor’s total solution must be IPv6 functional. Other examples include status updates to the cloud, API access, and other “system communications. This requirement is essential for IoT and M2M elements in a system.

  15. The vendor’s solution must include IPv6 only certificate key management. This includes the ability to manage certificate revocation and validation. This infers that the vendor must use Certificate Authorities which support IPv6 natively. The Certification Revocation List (CRL) and Online Certificate Status Protocol (OCSP) must support IPv6 only elements.

IPv6 Vendor Requirement Reference Documents

As mentioned, there are some documents created to ensure IPv6 compliance. This is a short list.

Do you have suggestions for addition IPv6 requirements? Please comment or E-mail. 

Credits

Special thanks to everyone who is reading, commenting, and providing suggestions.

Lee Howard – Director, Network Technology – Time Warner Cable – pointing out how vendor’s own Internets services need to be IPv6 as well as insisting that IPv6 should work with no IPv4. The pointer which Lee added to Erik’s point where the certificates support must be IPv6 is one the most forget.

Erik Nygren – Chief Systems Architect at Akamai Technologies – pointing out how all element communications to the cloud need to be all IPv6. We cannot have an IoT element not able to automatically their software because the update process only supports IPv4.

We are always looking for more suggestions to IPv6 Adding Requirements to your RFP & Drive IPv6 Deployment.  Please E-mail or comment with suggestions that work for your organization. For more related articles about using the RFP to drive the vendors, check out  Demand Security from your Vendors.

≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣

➥ Barry Greene is Business Development Executive ★ Internet Technologist ★ 25 Year Veteran of Internet Security ★ Emerging Technology Mentor ★ Advisor to Innovative Startups ★ Internet in Asia Expert

➥ Barry connects to peers, colleagues and aspiring talent via Linkedin (www.linkedin.com/in/barryrgreene/). You can also follow on Barry on Twitter (@BarryRGreene) or his blogs on Senki (www.senki.org).