Incomplete Thought: Support of IPv6 in Cloud Providers…
This is the first of my "incomplete thought" entries; thoughts too small for a really meaty blog post, but too big for Twitter. OK wiseguy. I know *most* of my thoughts are incomplete, but don't quash my artistic license, mkay?
Here it is:
How many of the cloud providers (IaaS, PaaS) support IPv6 natively or support tunneling without breaking things like NAT and firewalls? As part of all this Infrastruture 2.0 chewy goodness, from a networking (and security) perspective, it's pretty important.
/Hoff
Categories: Cloud Computing, Cloud Security
Hoff,
One option is to move to IPv6 via a gateway capable of translating between IPv6 and IPv4 such as is supported by F5 BIG-IP. This allows support for IPv6 and IPv4 at the same time and doesn't break NAT or firewall or security implementations. It has the added benefit of also not requiring a massive overhaul of the network admist a migration from IPv4 to IPv6.
So if the provider took advantage of a solution like this, the problem would be more easily addressed.
Lori
The VLANs don't need to differentiate between IPv4 and IPv6; the deployment is just dual-stack, as Ethernet is without VLANs. Why not just use VLAN technology to "overlay" IPv6 links onto existing IPv4 links?
v6 can do this for cloud computing –
– massively scalable internet architecture underneath the compute cloud platform (since cloud platforms are completely internet based and assume sound internet infrastructure)
– use of mobile ipv6 to migrate or transition virtual machines across geographical boundaries / affinities
– inherent security between compute elements by way of IPSec in v6
– aid dynamic allocation of capacity by autoconfiguring virtual machines based on demand fluctuation
– use of extension headers for new capabilities for cloud services
Extension headers are problematic for hardware-based packet-forwarding/-classification engines, FYI. Also, in keeping with the end-to-end principle as expressed by Salter, et. al., the utility and desirability of extension headers in the underlying transport is contraindicated.
IPSec in no way provides 'inherent security'; encryption <> security. Overencryption is actually a serious and growing securitiy problem, as it degrades the ability to classify and detect undesirable network traffic.
VMs <> cloud. VM mobility is neither helped nor hindered by IPv6. Autoconfiguration of computing/networking/application/service resources is orthagonal to the underlying layer-3 transport. Workload mobility <> VM mobility.
Where IPv6 comes into play is that it is the solution, such as it is, for IPv4 address exhaustion. IPv6 plus LISP is probably the best solution we currently have on the table to both address exhaustion and routing-table bloat in the DFZ (which is only going to increase as more and more entities are multi-homed, not to mention the additional memory/ASIC requirements for carrying 128-bit IPv6 addresses in the RIB and mapping them into the FIB). Mobility, the rise of spimes, and M2M all require copious and flexible addressing, and a world of NAT isn't going to the the optimal solution.
I've been talking about IPv6 being a first class citizen in cloud computing environments for a while… it may cause some pain for providers but they should be building out new infrastructure anyway rather than sprinkling magic fairy dust on existing kit.
Sam
Isn't this the same space that things like VPN-Cubed (and, presumably, Cloudswitch) live in?
Using VLANs in a dual stack approach has been around for a long time and we have done it in countless enterprise, federal and SP customers. VLANs work well if you continue to adhere to best practices with VLAN deployment. The issue that I have seen with many accounts is that they want to start spanning VLANs past their traditional L3 boundaries and they end up in a massive heap of Spanning-Tree issues. Dual stack with v6 and v4 live harmoniously side by side if you don't do anything stupid. 😉