X

Move your VMware and KVM applications to the cloud without making any changes

  • January 25, 2015

Implementing IPv6 on AWS EC2 using Ravello

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. 

About IPv6

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:

  • DHCPv6 (client and server) - Pretty common practice these days to assign a v6 address.
  • ICMPv6 for TraceRoute & Ping
  • Dual stack IPv4/IPv6 environments
  • ToS - Type of Service
  • Detect the MTU & Adjust the Stack for ICMPv6 'Packet Too Big' errors. RFC 1981 recommends that IPv6 nodes support path MTU discovery.
  • Multicast Listener Discovery (MLD) etc.. which is something not easy to test on the public cloud environments that restrict multicast.

IPv6 address types that are Unicast, Multicast and Anycast, the Unicast and Multicast type gets the most interest.

Ravello supports IPv6 on AWS EC2 with overlay networking

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 :4 and :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.

IPv6 Packet

Additional trace for the http transaction.. just to ensure that TCP handles this correctly :-)

GET / HTTP/1.1
Host: [2001:45::5]
User-Agent:011.01.00
Accept: */*
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 200 OK
Server: 011.01.00 httpd
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html
Content-Length: 10000

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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.