Some weeks ago, at RIPE 68 in Warsaw, Sander Steffann gave a presentation about revising RIPE 554 which, in his own words, “is a template guideline for procurement of stuff that should do IPv6” (here’s the steganography transcript of the IPv6 working group session). Some of you will probably know RIPE 554 as a quite helpful document for identifying reasonable real-world requirements for IPv6 capable network devices (in particular at times when vendors quite willingly put an “IPv6 ready” sticker on all their gear…).
The goal of that revision process – “RIPE 554bis” – is mainly (besides correcting some errors in the current version) to reflect either new standards or added experience in the IPv6 space and to potentially broaden the document’s scope as for hardware/software or even “services” like hosted stuff or “the cloud”. The latter made me thinking about “what could IPv6 requirements directed to cloud service providers (CSPs) look like”, with some focus on enterprise customers.
Initially I thought “why should there be any such (specific) requirements at all?”, aside from the motivation that expressing those might – even in 2014 – help raising IPv6 awareness amongst them (the CSPs). I mean, why formulate dedicated IPv6 requirements if, in the end of the day, it’s just a service (to be delivered), isn’t it? So one could be tempted to just expect (and hence require) sth along the lines “$SERVICE must work properly, regardless of the underlying network technology”.
Still it might make sense to prepare more specific requirements once one realizes that IPv6 networking is a bit different from its IPv4 counterpart and “the cloud is all about networking”. Let’s have a look what a typical customer might expect from “the cloud”? (and what this could mean as for IPv6 specific requirements):
(Service|System|Network) Reliability and Network Connectivity
In this space the following IPv6 related requirements come to mind:
– provide equivalent SLAs and performance (in all its aspects) for IPv6 as for IPv4 offerings.
– support path MTU discovery (PMTUD) in all parts of your network & infrastructure (read: do not block ICMP “Packet Too Big” messages anywhere).
– provide full transparency as for potential maximum MTU for IPv6 in your network & infrastructure (read: show us where tunnel/overlay/whatever technologies are used that might impact the MTU).
Telemetry (Ability to monitor the above reliability, connectivity, performance aspects)
In this space the following IPv6 related requirements come to mind:
– evidently: provide the same performance indicators & monitoring/measurement capabilities for IPv6 as for IPv4 based services.
– ideally: given global IPv6 network connectivity might be a bit less mature than its IPv4 counterpart, provide even better telemetry for IPv6 (e.g. to avoid stuff like this one recently: “IPv6 End points of Azure CDN don’t respond to HTTP requests from particular network.“).
– allow for display of all relevant parameters individually/separately for IPv6 and IPv4.
– support RFC 5952 oriented representation for all elements where IP addresses are displayed.
Management Interfaces & APIs
Both access to management interfaces and any stuff that can be configured there (like IP address ranges authorized to access either the services at all or the management interfaces themselves) must fully support IPv6. The same for all APIs.
Where IP addresses are to be entered or processed, support RFC 5952 oriented representation (while keeping the abstract of that RFC in mind where it is stated that “all implementations must accept and be able to handle any legitimate RFC 4291 format”!).
Security Services
Again, it’s about feature parity. All offered security services, like traffic filtering (incl. its GUI based configuration), security logging & reporting and all potential additional offerings (e.g. crypto gateways for private/hybrid type cloud offerings, virtual IDPS or WAF appliances added to traffic path on customer request and the like) must fully support IPv6, on the implementation/configuration level and when it comes to performance.
===
These are some points that come to mind when reflecting on potential IPv6 related requirements for cloud service providers. I hope some of you find some of them useful for one context or another, or this may serve as very preliminary input for the next version of RIPE 554. Given we’ve probably overlooked quite a few relevant points we’re happy to add/receive those in the comments section ;-).
Have a great day
Enno