IPv6 - Adding Requirements to your RFP

IPv6 - Adding Requirements to your RFP

Updated #2! 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 thrived 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 purchase. They reward vendors who are fully IPv6 compliant and eliminate vendors who are not investing in their own 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 specific 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 is 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 requirements 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 compliance to a US IPv6 NIST document?"). But, in general, these requirements drive the desired response. This list of IPv6 requirements has been evolving over time. 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.3

  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 to) functionality: IPv4-only, IPv6-only and Dual-Stack. To the extent the following are relevant to the deployment; 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 on 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 is 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 a 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 equivalent, 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 operate 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 vendors 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 requires 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 need 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.

  16. Vendors shall contractually guarantee the IPv6 requirements. The vendor shall submit IPv6 contracting text draft that would be reviewed and used if the vendor is awarded the contract. These IPv6 contractual obligations would legally bind the vendor to deliver on the IPv6 commitments.

  17. All data analytics, network management, logging, and other “big data” services must work in IPv6 only modes. Many “data analytics” applications & services use the IPv4 address as the primary element label. This means an IPv6 only system would break as the IPv6 would not fit in the IPv4 field. The vendor should review all applications and services to ensure that the IPv4 address is not a required dependency.

What to do during the RFP dialog (no vendor Blahs)?

All of these requirements require dialog, test data, and analysis. Items like protocol break-downs need to be compared to the standards work. Two tasks are critical.

First, review all the data. Get the vendor to submit, present, and review all the test and certification reports. If there is any questions, get the vendor to set up Proof of Concept (POC) labs. Look for the little things. Turn off IPv4 and have the test in native IPv6 and see it would work. Look out at the vendor’s grasp of IPv6 addressing and routing plans. That would let you know if the vendor really has IPv6 deployment experience. This interactive dialog and investigation is critical to weed out vendors who say “yes” to all RFP requirements.

Second, all of this need to be then put into the contract. As Todd G pointed out ‘they will be submitting a legally enforceable contract specifying "That there are no back doors or other holes in their products they are directly aware of or participated in the construction of”’.  Moving from an RFP review to legally binding IPv6 requirements will sift out the vendors who say “yes” to all RFP requirements, only to look at you with “blah” looks one year after deployment when it is time to deploy IPv6. This is a good time to pull in your legal/contract team to review the IPv6 contract languages.

IPv6 Vendor Requirement Reference Documents

As mentioned, there are a number of 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.

Todd G - for suggesting the contracting angle. This is really important and inspired the section what to do when the RFP responses get submitted. 

More suggestions are welcomed with more updates to this guide.

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

➥ 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).

Mukom Tamon

The Chief Excellence® Officer | I teach managers how to transform strategy → excellence using OKRs, 4DX & Lean Six Sigma | Trained 5K+ in 45+ countries.

8y

Thanks for writing this up. It's great actionable advice that managers can use now and this will put vendors on notice.

Like
Reply
Stya P.

Enterprise Security || Security Architecture & Engineering || Cloud Security

8y

Couldn't agree more with RFP format, without right RFP format everyone will use their own RFP format and so hard to combine it and it will be useless at the end :)

Like
Reply
Alan Levin

Internet public servant and CEO at Vanilla

8y

This is excellent! Thank you Barry - I've always admired you greatly! I would like to be able to share this in some kind of email format... just working out how to translate...

Like
Reply

To view or add a comment, sign in

Insights from the community

Explore topics