I often get questions from our customers whether they could run application flows based on IPv6 in the cloud and I thought of writing this quick blog and providing an example on how one can implement IPv6 on AWS EC2 using Ravello’s nested virtualization and overlay networking technology. This is an early preview and we are happy to work with you to help you implement IPv6 on AWS EC2, but please note that as of today, January 25 2015, we are providing experimental support for this functionality.
IPv6 is set to overcome a number of limitations and challenges of IPv4 addressing, these advantages include; extended address ranges, lower packet loss and latency, improved QoE performance on delay sensitive applications and greater security. However, deploying IPv6 poses its own set of challenges; lack of experience, network designs, incomplete testing and test methodologies, vendor selection, etc.
Like IPv4, IPv6 is a connectionless, unreliable datagram protocol that is primarily responsible for addressing and routing packets between hosts. What that means is basically a session is not established before data is exchanged and the delivery is not guaranteed however, IPv6 always makes a best effort attempt to deliver a packet. Sometimes, IPv6 packets might be lost, delivered out of sequence, duplicated, or even delayed.
Unfortunately, IPv6 does not attempt to recover from any of these errors. Apparently, delivery and recovery of lost packets is the responsibility of an upper layer protocol, such as TCP and ensuring that’s handled correctly is always a task for a test engineer.
Like IPV4, one may run application flows such as Web, Video (IPTV, VoD), VoIP, Email, etc over IPv6. In dual stack scenarios, applications could utilize running of IPv4 and IPv6 concurrently. Say that be a unit test or functional test or regression, you’d still want to validate and ensure proper functioning of its basic features such as:
IPv6 address types that are Unicast, Multicast and Anycast, the Unicast and Multicast type gets the most interest.
In the public cloud however, the network is very different from what it is in the datacenter. For example, static IP addresses are usually not available and broadcast/multicasting usually does not work and negative protocols such as DDOS, TCP SYN flood, ARP flood etc are completely restricted. Implications of running such flows could be a risk to the other environments running within the same cloud. However, that is NOT the case with Ravello. We support a lot of complex networking that is not natively supported on AWS EC2. In Ravello, A clean L2 framework and SDN support is provided to the virtual instances in each application environment and they remain private to the environments. This is how Ravello also supports broadcast and multicast on AWS EC2. For instance, you may run an environment that comprises web application traffic and based on IPv6 (example in this blog) and published on AWS or Google Compute in any region. The important thing to note is that IPv6 flows remain private to the application environment in Ravello.
In this blog, I’ve chosen a basic web application test example that’s configured to run over IPv6 and discussed the IP trace captured for a simple http connection between a web client and web server configured on Ravello.
I’ve deployed two vm instances i.e. a http server and a http client. From IPv6 address block of
/64 prefix 2001:45::0/64 I’ve assigned
:5 from this network to the client and the server, respectively.
Ran a capture before initiating a http GET and here it goes - trace comes out as expected… ICMPV6 Neighbor Solicitation and followed with Neighbor Advertisement that brought the first smile and I could see TCP taking over with
HTTP 200OK indicating a successful completion of http connection and the resource download.
One of the cool things in the trace to notice is that the ethernet frames carrying “RavelloS” vendor info along with the mac for packet type: (0x86dd) …. that’s IPv6 packet for sure.
Additional trace for the http transaction.. just to ensure that TCP handles this correctly :-)
GET / HTTP/1.1
HTTP/1.1 200 OK
Server: 011.01.00 httpd
Keep-Alive: timeout=15, max=99
All this is great and I’m happy that I able to run my IPv6 environments in the cloud. How about tunneling this outbound over IPv4 or bringing IPv4 into IPv6? It is natural to run into these questions and the answer is that there are virtual appliances for relaying, routing or tunneling which would facilitate such scenarios and can be easily integrated to your environments running on Ravello. You can email me to see a demo of my IPv6 setup and discuss your specific configuration. I’d be happy to walk you through it.