[ Originally posted on Linkedin here: IPv6 – Adding Requirements to your RFP.]
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 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 email@example.com.
IPv6 RFP “Cut and Paste” Requirement – Version 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 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.
The vendor solution shall support native IPv6 from the device to the end-points on the Internet with no network address translation.
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.
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.
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
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.
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.
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).
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.
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.
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.
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.
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.
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.
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 a number of documents created to ensure IPv6 compliance. This is a short list.
- Requirements For IPv6 in ICT Equipment – RIPE-501 http://ftp.ripe.net/ripe/docs/ripe-501.pdf
- Planning Guide/Roadmap Toward IPv6 Adoption within the U.S. Government https://cio.gov/wp-content/uploads/downloads/2012/09/2012_IPv6_Roadmap_FINAL_20120712.pdf
- Requirements for IPv6 in ICT Equipment – RIPE-554 http://www.ipv6forum.com/dl/presentations/ripe-554.pdf
- The IPv6 Forum (http://www.ipv6forum.com) IPv6 Ready Logo Program
Do you have suggestions for addition IPv6 requirements? Please comment or E-mail.
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.
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).