Let’s cut to the chase: the Cloud is nothing new. You’ve probably read this before–but that’s alright! A little reminder doesn’t hurt (most of the time). If this is your first time hearing about the Cloud, welcome home! I had no idea it was possible to survive 10 years off of slugs and beetles under that rock. You’d probably like to have a nice hearty meal after so long. Remember the cardinal rule of dinner though, you have to begin with GRACE.

Gameplan – Start with the basics here, folks. We’ll expand upon this a little bit later in this issue of the newsletter, but what do you plan on doing with your cloud? You need to plan your goals and then work your way up the ladder. Depending on your needs, you may want to implement an internal cloud of your very own, or perhaps outsource it to a cloud provider. Either is an acceptable solution, it just depends on what your needs are at the time. For the remainder of this article, we’ll assume you’ll be taking advantage of an exterior cloud.

Research

Let’s look at some cloud providers, shall we? There’s quite a few out there and depending on what you need, you’ll be looking at a few different establishments. Google Apps offers a wide variety of services, including e-mail, calendar scheduling, and a web-based office suite. If you don’t feel comfortable leaving all your eggs in one basket, one alternative to Google Docs would be Zoho. Want more from your cloud? Well look no further than Amazon EC2 and Rackspace. While Google and Zoho provide SaaS (Software as a Service), Amazon and Rackspace specialize in IaaS (Infrastructure as a Service). This allows you more flexibility with your cloud space (for the right price, of course.) Again, outsourcing will be expanded upon later in this newsletter.

Access

While not something you would immediately consider, the physical location of your data could impact what you can and cannot do (or rather, should and should not do). If this is for your own personal use, then this may not be an issue. But, if you’re storing crucial data (such as incriminating evidence, government conspiracy cover-ups, or the genome of Sasquatch), you might want to take into consideration where your cloud might be located. If anything were to happen, do you know what type of jurisdiction you have over your information? Just something you may want to look into if you’re concerned with the legality of what you may be storing.

Compliance

Striking fear in the hearts of men. This right here is what could break your entire cloud. In fact, according to an article featured on Techworld, “Nearly half of enterprises that use cloud providers admit that they might struggle to pass a compliance audit when it comes to cloud data.” Did you read that? Almost HALF of the companies out there aren’t sure if they’re compliant. That’s a scary thought. Now, admittedly, it’s difficult to be compliant in a cloud, but not totally impossible. You just need to be smart about it and, again, do a little research before you start your implementation.

Emergency Disaster Recovery

Another branch of location, what would you do if you suddenly lost access to your cloud? With the recent outbreak of natural disasters, this could be critical to your plan. If a dynamite-strapped buzzard were to swoop in and eliminate the building where your servers were being held, would you be prepared? You’ll need to decide on a.) a backup solution or b.) more clouds (because if it happened once, obviously it will never happen again.)

Although just an appetizer on the full menu of cloud computing, this simple list can take you a long way toward your goal. And by the time you’re through reading this newsletter, you will be absolutely sick of weather puns.

The Cloud seems to be the catchphrase that IT journalists love to throw out into anything vaguely related to technology involving more than one computer. It ends up being used to describe many different things that IT managers have been doing for years if not decades. The new technology that the cloud offers is the concept of elastic computing, and elastic computing is really just a clever way to dynamically allocate the resources of a virtualized computing environment. OK, that is definitely cool technology, but the thing most people seem to reference when talking about putting something in the Cloud is to get it off their network and onto some magical supercomputer in the sky so it is no longer their problem. In other words, outsource it.

Outsourcing got to be a dirty word when we were talking about shipping all those IT and developer jobs overseas about ten years ago, but perhaps it is time to take it back. What purposes could outsourcing serve for your IT environment? Are there some applications on your network that are such a burden to maintain that throwing a little extra money at it will do wonders for your productivity and service level? Let us walk together through some common outsourcing scenarios and come up with a few ideas to keep in mind when deciding whether or not this whole cloud thing really does have a silver lining. The first step is identifying what applications would absolutely not be a candidate for this kind of outsourcing. While almost anything can be made to run on another provider’s network, some aspects of applications might make this difficult to do. Any application dealing with sensitive information, whether it be customer data, trade secrets, or other proprietary information may make your management a bit nervous when you tell them Amazon is hosting it all now. Other critical applications such as the ERP system or other financial software might be best left on your local network. After all, the next time that construction company sends its backhoe through all the fiber running to your building, do you really want production to come to a screeching halt? In fact, some may argue that cutting Internet access off may make many workers more productive.

Amazon Elastic Compute was the first major Cloud computing service to use the “cloud” terminology.

With an idea about which things may be poor choices for the cloud, we can start to envision the applications that cause the most grief on the network. Public Enemy Number One has to be the management of inbound email on the network. Thanks to the Cloud before it was even called that, many organizations have been able to reap the benefits of allowing another company to accept email for their domains, then deliver the cleaned mail to a host name of your choosing. This eliminates the extra bandwidth usage, CPU cycles, and disk storage for the backscatter from your world. Many of these services also have integrated self-help portals for each user to view their quarantine and decide if any messages were stopped erroneously. How could it go wrong?

Well, with the front-end successfully outsourced, your eyes may now be on that large Exchange environment taking up time and money. What about just outsourcing email entirely? This can be successful as well, but there are a few things to keep in mind. Firstly, depending on the number of users you have, you may re-consume all of that saved bandwidth with your user population connecting out to the outsourced mail system. Secondly, while spam management tends to have only positive impact on the user experience, accessing calendars, contacts, and potentially large messages over the Internet instead of the local network may tax the impatience of the average business user. I recommend taking some measurements of the average usage of your Exchange systems using network monitoring tools and comparing them against the size of your current bandwidth available on your Internet connection. Depending on how much your organizations depend on the ancillary features of Exchange, you might be shocked to find that it uses an awful lot. Also with a nod to our earlier discussion about what not to outsource, how much proprietary information ends up in email or public folders in Exchange? These questions should be covered before considering outsourcing backend email and groupware services to any provider.

Another candidate that comes to mind quickly is the public website for your organization. Generally this site will contain mostly marketing material, and it is meant for public consumption anyhow, so that would seem to fit well into the outsourced model. Websites can potentially take up a lot of bandwidth depending on the number of visitors or other visibility it may have elsewhere on the Internet. If your marketing team puts together a brand new website and does a lot of advertising of its release date, you may find an abnormally high amount of traffic coming into your network.

You may get linked on another popular website that drives up traffic quickly for a few days. With the website outsourced, your provider will likely have far more capacity available to accommodate the higher load for those few days. This will certainly give a better overall impression to the public at large when your website is not getting “slashdotted” off of the Internet. Of course, the same rules about sensitive information still apply on the web as well as email, so any customer portals or other non-public websites may not be the best candidate for this sort of outsourcing.

While it may not initially register as being in the Cloud, authoritative DNS is a service that has been often outsourced to a group of servers from the registrar or another provider for nearly two decades. While there are downsides to this, including lack of finer controls of the DNS records, overall it is easy to get geographically diverse nameservers from the registrar instead of maintaining systems in datacenters or colocation facilities across the world.

A newer trend for outsourcing is to put your entire Internet connection into the Cloud. While this sounds mildly insane at first, the concept behind it is that your MPLS network provider will attach their facilities into your network and provide firewall, VPN, and proxy services from whatever location they have available and up. Major problem in the Chicago facility that you normally use? No problem, just bring your address space online in Munich and keep on working, albeit slightly slower. This is not an option for everyone, but if you have an MPLS network already, this could be a way to further reduce the costs and complexity of the infrastructure you need to manage. The downside is giving up control of the type of devices used to implement the perimeter security. In addition, consistent auditing and copies of the policy should be requested should you ever decide bring your head back out of the clouds.

While the excitement of all of this cloud computing can be infectious, it is really important to take a step back from it all and think about what is really happening. Outsourcing is nothing new, and whether you are putting your website on a server at your ISP or on a server in Amazon’s EC2, the thought process and risk are essentially the same. Each IT department needs to weigh their specific use cases against the risks involved both with the integrity of the data and the availability of the service. As always, if you ever have questions about migrating services to the cloud or other outsourcing situations, we are here to help keep your feet on the ground.

In today’s economy, a large number of organizations are turning to cloud computing as a means of cutting costs. While switching to a cloud provider such as Amazon can make sense from a fiscal standpoint, many times it is hard to justify the move from an auditing and security standpoint when you do not control the underlying infrastructure. Questions such as “how secure is my data?” and “who REALLY has access to it?” frequently arise. With so many benefits to moving your applications into the cloud, what are you supposed to do? My answer to this problem lies in the Open Source community, with two projects in particular looking quite appealing: Eucalyptus and OpenStack. Both implementations have great community support behind them; the former has been included as an option in Ubuntu installations since version 8.04, also known as “Hardy Heron,” while the latter is slated to be included as an installation candidate in Ubuntu’s next release, version 11.04, or “Natty Narwhal.”

So why would you want to build your own cloud? As I mentioned earlier, one of the biggest reasons would be for applications that you can’t currently move to a public cloud provider due to security restrictions or cost of storage/processing. This can sometimes be disheartening, as you gain many benefits by moving to the cloud, the biggest being features such as dynamic failover, simple node provisioning and scalability. Typically we see this niche being filled by virtualization suites offering these features at outrageous costs, requiring proprietary software and offering no leeway to people who want to customize the software to fit their environment. So, instead of buying software to fit the environment we want to deploy it in, we buy an environment to fit the software in. Folks, it is time to put an end to this Tom Foolery! If you already have applications deployed into your cloud provider of choice’s infrastructure, would it not make sense to want to integrate that into your already existing management interface? Almost all of the Open Source cloud computing stacks integrate perfectly into the exorbitant amount of interfaces that support the Amazon EC2 API. Also, by migrating to an internal cloud, you make it easier to eventually move that application to an external cloud if you ever decide in the future to do so. This allows you to test and quickly overcome any quirks of having your application running on top of a cloud computing stack, while maintaining compatibility with popular EC2 cloud providers. Even if you never decide to deploy the application to a public cloud, wouldn’t it be nice to reap all of the benefits of cloud computing AND know who has access to your data and how secure it is? By having an internal, Open Source cloud, you can accomplish high-availability, scalability and security all in the same interface that you currently use to manage your public cloud.

Now that we have the “why” how do we plan to start this project? I say project, as it should go without saying that this idea needs to be tested and perfected in your environment, on your hardware, before you can decide whether this is a viable solution or not. Before we get started, we have some considerations to fulfill. First: Your hardware must be 64-bit, and your CPU must contain the VMX flag. Most modern processors will, however it is important to make sure that yours supports virtualization. On Linux, you can figure this out quickly by running “cat /proc/cpuinfo|grep vmx” and searching the “flags” section. Second: You must have dedicated Gigabit interfaces and a switch/VLAN for node traffic. Unfortunately in this case, 10/100Mbs is simply not enough bandwidth for synchronizing instances between nodes. Third: Choose a cloud stack that is well supported, easy to install and feature-rich. In this lab, we will be using the Ubuntu Enterprise Cloud, or UEC, which is based on Eucalyptus. The reasoning behind this is, Ubuntu makes it VERY easy to deploy a cloud. If you haven’t noticed, Ubuntu introduced a new installation option in Ubuntu Server versions 8.04 and up, allowing you to quickly deploy an entire cloud infrastructure in a matter of hours. In figure 1-1, I have included a basic network diagram outlining a distributed setup.

As you can see from the diagram above, our setup is very similar to a virtualization environment. The one difference you will notice is that we have a cloud-controller and a cluster-controller running on the same machine. If we wanted to, we could further distribute this setup into separate clusters as well, with the cloud-controller overseeing all operations, and providing an interface for managing instances on different clusters. The four components that you need to run a cloud on the UEC infrastructure are: 1.) Cloud Controller (CLC) 2.) Cluster Controller (CC) 3.) Node Controller (NC) and 4.) Storage Controller (SC). These services can run all on one box, or they can be distributed out to many different servers, giving you many options for scalability. The CLC is basically the front-end to the entire cloud, allowing you to start and stop instances on different clusters. It is recommended to build the CLC server with at least 2G of RAM, 1-2 CPUs, and 200GB of space for the Operating System. You will also need two interfaces, one for public traffic, and one for communicating with the CC/NCs. Also, traffic going to and from the instances (virtual machines) will be going in and out of the public/private interfaces of the CLC, unless you run the CC on a separate machine, in which case the CC will be performing IP forwarding in order to allow users to get to instances. The CC distributes instances to each NC it is connected to, as well as passes traffic to and from each instance it is managing. You will need to meet the same hardware requirements as you did with the CLC for the CC. For your storage controller, I recommend some sort of SAN to store each instance on. In my diagram, I connected the SAN to the CLC, and ran the SC services directly on the CLC. The SC will share out storage via the Walrus service, and is compatible with Amazon’s S3 APIs. You can choose to share out storage via iSCSI or AoE to the NCs as well. Finally, the NCs need to have the VT extension, and as much RAM and CPUs as possible. At a minimum I would recommend 4G of RAM and 4CPUs. You can go with however much local storage the server comes with, as storage for the instances is done via Walrus or iSCSI/AoE. UEC uses KVM as the virtualization hypervisor by default, however with some tweaking it is possible to use XEN as well. The last step in our planning is allocating a subnet for instances to run on and choosing the networking mode. I recommend starting out with a /24 for testing, although for production you will need to decide what subnets you will want to allocate to your cloud infrastructure. Although it is not possible in the installer, you can add more subnets easily with the euca_conf tools on the CC after you are finished with the installation. As far as the network mode goes, you have 4 options System, Static, Managed, Managed-NOVLAN. The most feature-rich is Managed, as it allows you to filter based on groups, and provides separation between your different VM networks with VLANs. If your NCs are connected to the same network as your CC, you can also use the System mode, in which the CC will provide the NC with a random MAC address for your instance to use when trying to negotiate DHCP. This is easy for starting out, however it does not provide you much control over the addressing or traffic. Static mode is similar, however you will need to map MAC addresses to IP addresses, allowing you to control who gets what IP address directly on the CC. With Managed mode, you can implement security groups for your different instances, for instance you can have a security group for web servers, DNS servers, or servers that Golden set up, and then have the CC allocate addresses out of different subnets, depending on which security group that particular instance is a member of. Finally, with Managed-NOVLAN mode, you get all of the features of Managed mode, sans VLAN tagging.

Once we have the planning done, it’s time for implementation. Ubuntu has a great guide for deploying their UEC infrastructure (http://hlurl.com/z3), so I won’t go too far in depth, but I will try to explain some of the caveats and tricks during the installation and post-configuration processes. I used Ubuntu 10.10 Server for the installation, as it offers the newest stable version of the UEC suite, and comes with a newer underlying version of Eucalyptus containing many bug fixes. In order to get to the cloud installation, you must boot off of the server CD, and choose “Install Ubuntu Enterprise Cloud” instead of “Install Ubuntu Server” at the installation prompt. For the most part, the UEC install will seem exactly the same as a typical installation of Ubuntu. You will be asked what services you want to run on the server. You must install the CLC first, then you can install the CC and SC servers if they will be separate. Also, during the CC install, you will be asked which subnet you want to allocate to virtual machines. Once you have your CLC, CC, and SC installed, you may then move on to installing your first NC. The NC installation is much easier, as it will automatically recognize that you have a CC running and join itself to it. This allows for easy NC deployment, as you will have a fully functioning NC upon first boot.

Once you have everything installed, I highly recommend you immediately do an “apt-get dist-upgrade” on every server before you start configuring it. This will ensure you have the latest version of the UEC suite. Once you are done upgrading, you will need to go to https://<<CC IP address>>:8443, generate a new set of credentials, and download them. Since I am using  an Ubuntu 10.04 client to administer the cloud, I can install the Eucalyptus command line tools to query the CC for different values, such as the number of running instances, free CPUs, node status, and more. These tools also provide a way to provision and manage instances running on the cloud and can be installed from the APT repository with the euca2ools package. Once this has finished, you can uncompress the credentials downloaded from the CC, move them to ~.euca/, and source the supplied script (. ~/.euca/eucarc) that will export all of the required variables needed for the euca2ools package to work properly.

A nice alternative to the command line tools is ElasticFox, which is a plugin for Firefox that can manage Eucalyptus and Amazon instances simultaneously. I recommend using the CLI tools first, in order to get an understanding of what exactly needs to be done when you are working with UEC. Then, once you have a firm grasp on the concepts, you can use ElasticFox to make things quicker. ElasticFox also makes it quite easy to define “security groups” and access rules for each group. For instance, you can create a security group called webserv, for all of your web servers. In this group, you can allow port 80 and port 443 from 0.0.0.0/0, and allow SSH access from a different network or user group.

By default, UEC will choose Managed-NOVLAN mode for the cloud networking. You will want to edit the Eucalyptus configuration files (located in /etc/eucalyptus), switching to MANAGED mode on all members in order to harness the full security and networking feature-sets. In order to complete this change, you need to set up the switch port that the CC is plugged into as a trunk port. This will allow tagged packets to traverse the switch and access any VLANs necessary. Also, you will need to set up SSH keys for the eucalyptus user between the CLC and every CC, NC and SC.

Once you have the basic setup completed, you can now start to run instances, or VMs, on your cloud. Canonical provides several different flavors of Ubuntu that are ready to be installed on top of UEC, and can be downloaded in the CLC’s web interface. When you are finished downloading the image, you can either use ElasticFox or euca2ools to start the instance. If you have your own special build that you follow for your cloud instances, you may also roll-your-own image and upload it to the CLC for it to be used. This allows a consistent, quick, and secure build the first time, every time. There are a few extra steps that must be taken when making your own image, such as using DHCP for the networking and tying the hostname to the DHCP address, such as host-10-3-254-109 for a system with the IP address of 10.3.254.109. Changing the hostname is not essential for booting, but can be quite tedious when deploying 10 instances at once. Also, if you are using Ubuntu for your instance, you can install the cloud-init package, which will assist in most of the initial “first-boot” setup.

Once you have your cloud up and running, it is important to remember that just because you have hardware failover does not mean you are going to get 100% uptime. You must plan accordingly for software failures, ISP failures, and natural disasters. Clustering services whenever possible and keeping members geographically separated can increase your chances of achieving your 99.999% uptime goal. Training staff on the ins and outs of your cloud suite will also further your success rate in troubleshooting and recovering from outages related to the cloud infrastructure itself. One of the biggest caveats of investing in an internal, private cloud is the training overhead. On Amazon, cloud deployment just works and does not involve troubleshooting issues related to cluster controllers or instance storage concerns. When you move the cloud inside of your network, you also move the management overhead inside of your network too. Although this can be a major drawback in the beginning, I really do think that Eucalyptus and OpenStack deserve a closer look as an addition to your environment. Both cloud suites have very active communities, with Canonical offering professional training and support on the former. Whether you already have applications deployed to public clouds, such as Amazon, GoGrid, or Rackspace, or you are still on the edge about utilizing any of the “* as a Service” providers, cloud computing is here to stay. Its strengths far outnumber its weaknesses, and seems to be the next evolutionary step from virtualization in our computing existence.

The last time I checked, “cloud” was one of the most misunderstood words in the IT community buzzword dictionary. Misunderstood both in the very definition of the buzzword and in its usage when it comes to security. I looked for a definition of cloud computing online and the one that I liked the most actually came from Wikipedia:

“Cloud computing can be compared to the supply of electricity and gas, or the provision of telephone, television and postal services. All of these services are presented to the users in a simple way that is easy to understand without the users needing to know how the services are provided. This simplified view is called an abstraction. Similarly, cloud computing offers computer application developers and users an abstract view of services that simplifies and ignores much of the details and inner workings. A provider’s offering of abstracted Internet services is often called ‘the Cloud’.”

The reason I was drawn to this definition is its use of a few keywords that I think are key when talking about the Cloud: abstract, simple, and ignores. Wikipedia compares cloud computing to things like your utilities at home or your television provider, and the allusion to such services translates nicely into how the Cloud is thought of in the IT world. Think about it, how often do you vet your natural gas provider? Do you often request an SLA from your electric company? Have you recently requested security specifications from Dish Network? The same holds true of many of the Cloud services that companies employ today for such critical services as email, DNS, data storage, and (gasp!) even firewalls and pen testing.

As a managed security services provider (MSSP) Hurricane Labs provides log monitoring and analysis, security monitoring, and penetration testing, along with other services that when put together form what one person described as “a SIEM in the Cloud”. This got me thinking about what our clients expect from us and what standards they should hold us to. This may sound a little like a sales pitch, but bear with me as the expectations that our clients have (or should have) of us are the same as anyone should have of their cloud provider, regardless of what genre of services is provided. The standards that are set for security in the Cloud should not be any different than if you are outsourcing your CRM or document management.

So what criteria do you use to judge your cloud or services provider? Let’s talk about four areas of responsibility that you should hold your service provider to.

Availability

This one seems to be the most obvious to me. Any cloud provider must be available 24x7x365. When you start to work with a cloud company be sure to read through their Service Level Agreement (SLA). I realize that this is not often a fun read and your cloud SLA won’t sit in your magazine rack next to your copy of PC Magazine and Sports Illustrated but it is an important read. This will tell you what to expect from your cloud provider from an availability perspective. the Cloud is not something that should only be available to you during bank hours unless that is what you choose. You should also ask your cloud provider about their scheduled maintenance and ask how often they have downtime. Ask about their infrastructure and DR capabilities. This is especially important if you are using them for a service such as CRM, email, DNS, and especially security. Those are not services that you can afford to have downtime on. Let’s just pick on the email providers for a minute. Google can host your corporate email and provide spam filtering, but what happens if their spam filtering services goes down for an hour? I realize that Google has the resources of a small country but what if? Like most businesses, I’m assuming yours is pretty reliant on email and the lack of email for even five minutes would have phones ringing off the hook with angry executives and all other manner of employees. What if the Cloud service that you’re signing up for just went away for an hour? What impact would it have on the business? These are questions that I hope and expect that our clients and potential clients would ask of us and are questions you should pose to potential cloud vendors.

Consistency

When I say that your cloud provider needs to be consistent, I’m mostly referring to two areas: services and support. The services you get today should be the same as what you receive six months from now. The only reason I bring this up is because as more and more cloud providers flood the market, the services that they offer will inevitably change as the market for that service matures and grows. Hopefully what you’re getting today will be the same as what you signed up for.

You should also expect consistency in support. Inevitably you’ll need to work with their support personnel to get the service set up and work with them on troubleshooting any problems that arise. Ask what the support structure looks like. Make sure that support will be available to you whenever you need it.

The Cloud market is an evolving thing even if cloud computing itself isn’t a new concept. Expect your provider to give a consistent service throughout your cloud experience.

Transparency

The definition of cloud services that we referenced earlier described the Cloud as being “abstract.” That’s not necessarily a good thing when it comes to the provider itself. Often it is enough for some companies that the work they need gets done and the manner in which that is accomplished is not important to the client. I understand that the reason for contracting these services is to get the work done that you cannot or do not wish to do. You outsource that which is too difficult or distasteful right? This does not mean you should settle for an entity in the sky that you don’t understand. I know it sounds a little harsh but that approach is ignorant at best and lazy at worst. When we here at Hurricane Labs bring a client on board, it is common for us to have them tour our facility, talk to our people, and get a better understanding of how we will be doing the work for them. In our portal the client sees all activity done on our part. They are given a log of all changes that were made. They can track our workflow and our processes to the smallest detail. This makes us accountable to our customers and every cloud or service provider should show (and want to show) every aspect of the work that is being done. The company you work with needs to be accountable and transparent with the service being provided.

Security

All too often the least transparent aspect of the Cloud business is in the security measures being taken to secure and protect the data that you the customer are entrusting this third party with. Hopefully that will be at least somewhat addressed in the SLA, but unfortunately that isn’t always the case. Ask your cloud provider what security measures are in place to guard you against the threats that exist for cloud companies the same as they exist for your network locally.

A good example of how it should be handled was presented to me recently by a client who wished to see a recent penetration test report from their cloud provider. They requested confirmation that the service had been tested for security vulnerabilities and the Cloud provider could not give them that confirmation. They involved us to see if we could perform the testing to ensure that there was no risk to their data. I proceeded to contact the Cloud company and start the process of performing the penetration test. We talked over things for a bit and right before we ended the call the VP of the Cloud company said to me “It will be interesting to see what you find. We never thought about getting a penetration test before.” At first I was shocked to hear that, but it got me wondering how often these cloud services put time and resources into securing themselves and the client data that they have access to. I’m guessing that unfortunately it’s not all that often.

So what’s the moral of the story? What’s good for the goose is good for the gander. The same stringent security measures and high expectations that you hold your own networks to should apply to the Cloud companies that you work with. Put the same energy into taking care of the data that sits on their network that you do for things that sit in your own datacenters. Take the time to read the boring SLAs and grill the technical people at the Cloud providers so you have the assurance that they are taking those same precautions. I know I’ve been grilled plenty of times, and when those questions come up I know that the people asking them are going to be clients that I’m going to enjoy working with. Great minds think alike I guess.

Are you an IT security specialist looking for new solutions to be implemented in your company? Enterprise IT Security magazine is a great source of ideas! Just see for yourself:

Everyone from IT security circles to Corporate Executives in business management is talking about the “Cloud” or “Cloud Computing”. First, does anyone know what the “Cloud” really is? How does it differ from the “Web or the “Internet” and why is it so important?’ Gary S. Miliefsky (CTO, NetClarity, Inc.) will provide you with the answers to those (and many more!) questions.
Read more…

‘The information overload is so big that human beings are not able to analyse that data in a timely manner.’ Have this problem in your company? Grid computing is the answer! Siân Haynes and Stilianos Vidalis from University of Wales will share their knowledge on this topic.
Read more…

Interested? We have much more to offer! Subscribe now and get inspired!

Late last year we decided to update our Eye of the Storm newsletter, going to an every other month release as opposed to monthly. This will give our team more time to devote to the quality of the articles and information provided as opposed to rushing around to meet a monthly deadline along with our day jobs. Having said that, I hope you like this issue devoted to IPv6 and, as always, comments and questions are welcome.

IPv6! I know what you’re saying, “That’s years away, why worry about it now?!” I know that up until about a year ago that was my reaction. I recall all too well sitting in boardrooms in the early century talking about the “big migration” to IPv6 and working with a particularly forward thinking company on an implementation plan. It was then, of course, we realized maybe they were too forward thinking as many vendors hadn’t worked out their support plans just yet. Fast forward a decade or so later, and well, a lot of that is still true. Vendor support is spotty and many ISPs are saying “IPv6, sure we have that in beta.” Unfortunately though, now we’re really running out of IP addresses — like really, really this time. It’s important that businesses at least recognize the need to move on to this exciting new realm. Why, you ask? Great question.

Strictly speaking from an infrastructure perspective, the IPv6 transition will likely dominate meeting planning and budget forecasts for the next couple of years. If I were in your shoes (and I am) I would start my strategic thinking now. How will you do you a proof of concept? How will you lab this new way of connecting up? What is it going to cost? What are the benefits/drawbacks? What is the impact to the bottom line? Of course these are questions you should ask of any project but they are particularly important to IPv6 because, for starters, it impacts the entire way you connect to the world. From desktops to desk phones, mobiles and laptops, it affects everything your business touches on a daily basis. I say all of that to stress that it’s a pretty big project with far reaching consequences. Of course, my standard, stolen disclaimer applies: “Don’t panic!” There are quite a few resources out there to help you figure it out.

This edition of our newsletter was a way for our engineers to learn more about this emerging technology and then share it with our customer base and whoever is interested. There’s even a “cheat sheet” included that links IPv4 concepts to their IPv6 counterparts to help clear up some confusion. There are also the wonderful people at Hurricane Electric no relation that provide wonderful connectivity to the IPv6 world and even a free certification program. Then there are the SixXS guys who provide tunnel broker services and links to many, many other resources. So all is not lost; there are a lot of people providing a lot of free resources to guide you along the way.

This issue examines some of the why, a lot of the how and poses some “what next” types of questions. Patrick will give you a review of how IPv6 came to be and why a version was skipped. Brian explores the mysterious world of IPv6 addressing and relates a lot of the “newer” concepts to older IPv4 concepts to make it a little more digestible. Matt discusses how some of the more prevalent security vendors currently takes on IPv6, along with their strengths and weaknesses. Finally, Kyle will actually detail out his first IPv6 lab implementation to highlight some of the intricacies of actually deploying IPv6 in any real way. We will also include a cheat sheet which should help you along on your road to IPv6 glory.

This brings me to IPv6 world day on June 8, 2011. It’s a nice little event where companies will show off their IPv6 readiness and have at least their websites presented to the world. We plan to have our network serving both IPv4 and IPv6 versions of our services by then, won’t you join us?

Well, it finally happened: we’ve reached the end of the Internet. Time to throw in the towel, nothing left to see here, folks. Whoa, not so fast bucko, you mean the end ISN’T near? IPv6 you say? You’re telling me we have more Internet left? Good, I don’t know what I’d do without my funny cat pictures. But before we get into the latest and greatest Internet Protocol, let’s go back and learn a little bit about it’s predecessor — IPv4.

The Year: 1981. A crack team of techies in Southern California decided to set the computer world afire with RFC791: IPv4. If you’re not familiar with RFC, allow me to explain. RFC (Request for Comments) are documents outlining a specific idea that the IETF (Internet Engineering Task Force) might have regarding the Internet and the way it works. Think of it as a city hall bulletin board where you gather the opinions and suggestions of your peers. After time (and much discussion), some RFCs are adopted as Internet Standards by the IETF (I always pictured it as a roundtable debate within the Internet Justice League). IPv4 did just that, with 45 pages of backing evidence that this was the real deal. With the support of the IETF, IPv4 is, basically, how you navigate the Internet as you know it today. Those numbers you see sometimes— 192.168.37.1, 10.163.40.22, 172.16.0.59 —are all IP addresses. And as it was established back in 1981, there are just over 4 billion of them out in the world as we know it. Sure seems like a lot, right? Surprisingly no, we’ve finally run out. After 30 years of 32-bit addresses, we need to move on. To what, you might ask? Well IPv6 of course.

Hold on there chief, I know how to count. Shouldn’t we go to 5? I mean, that IS what comes after 4. Well, back in the day, an experimental protocol was developed to provide end-to-end guaranteed service. They called it “Internet Stream Protocol”, or ST for short. It used IPv4’s addressing scheme and brought about the idea of Voice over IP. That’s nice, but what does this have to do with IPv5? Well ST2 decided to unofficially identify itself as 5. And to avoid confusion, the IETF decided to go straight to 6 as a result.

UCLA campus computer lab: 40 years ago. At 10:30 p.m., Leonard Kleinrock and his colleagues (Al Gore was not present) send the first computer message. It was sent via packet-switching mathematics Kleinrock had conceived for transmitting data. 5 minutes later that message and computer was hacked into.

Chicken Little hasn’t gone running and screaming past my office just yet, but I feel like he will anytime now. The IPv4 sky is officially falling. The major media outlets are telling me that the Internet is out of IP addresses and that we’re switching from four to six digit addresses; yes, one article actually said that. IT security publications are offering all kinds of advice on what should be done to secure your IPv6 address space. Twitter is abuzz with talk about “this whole IPv6 thing is no big deal.” Security vendors are telling me that their products will do what no other product can and secure my IPv6 addresses. What is a person supposed to believe? So I went on the hunt myself to figure out what was out there that could help me to keep my IPv6 stuff safe. What I found didn’t shock me, it just disappointed me.

I started with firewalls; it seemed like a logical place to start and I learned that a firewall is no longer just a firewall. The firewall market has evolved and that thing protecting your perimeter network isn’t your grandpa’s firewall. It does so much more than that now (I feel obliged at this point to at least mention the bad form of having single vendor protections). From IPS to DLP, from AV to mobile security, every firewall vendor has grown their product into something that protects multiple facets of your network. The Gartner Magic Quadrant is littered with UTM (Universal Threat Management) products that will handle those different attack vectors and do more than just packet filtering. Juniper, Check Point, Palo Alto and more are all claiming to be UTM or Next Generation firewall devices. So, I started sifting through all these products to see what they did to secure IPv6.

The first thing I noticed is that EVERYONE has IPv6 support, well everyone claims to at least, and EVERYONE has the leading product for firewalling IPv6. As a whole it seems that the major firewall vendors are all able to do packet filtering on v6 and you can write rules for IPv6 addresses. Don’t get me wrong, it is very important to be able to do that and the importance of writing proper firewall rules becomes even more so with the imminent departure of NAT. My issue comes from the concept of UTM — that’s where the firewall industry is heading. The trouble is that the concept of UTM hasn’t quite made it to IPv6. All the cool features and market leading application protections don’t exist yet for IPv6. Now, I understand that the firewall technology has to catch up a bit, but I don’t for one second believe that there isn’t someone out there right now crafting an attack for those applications running over IPv6.

The other problem I ran into was ease of use. While the firewalls may support version 6, it isn’t always so easy to actually get it set up. I’ll use Check Point for this example, only because I know them the best, but they aren’t alone in the difficult to implement department. To start filtering over IPv6 you have to have a separate license, be running on a specific version, and have to jump through multiple hoops to set the thing up. Even after you’ve done your backflips to get through those hoops, there are still limitations to how the product actually works. Little nuances that, while they aren’t debilitating, can be maddening.

Please don’t think that you should abandon firewall technology for IPv6 because you shouldn’t. You still need to do your best to protect your network from all possible attack vectors. My point in all this isn’t to say that these firewall technologies aren’t doing great things with IPv4, but if IPv6 is the future, then unfortunately firewall technology is still stuck in the past.

The other thing I took a look at was IPS technology. Again, everyone has support for IPv6 in one form or another, but I was faced with the same problem. They support it, but don’t really have features to back it up. Cisco, a networking company at heart, has an IPS module for IPv6, but like Check Point, you have to be at a specific version and running specific hardware in this case. You can run their IPS on version 6.2 but you can’t run it on the 4215 appliance that you may have. You’ll need to get the newest version of the appliance to be able to run it. Check Point has IPv6 integration in their IPS product, but in their case, all they are inspecting is IPv4 traffic that has been tunneled over IPv6. These are just a couple of examples of the “gotchas” that exist when looking for an IPS product that will help you in your quest to defend your IPv6 network.

There were two products that did stand out a bit from the rest in my opinion. Tipping Point seems to have taken IPv6 seriously and has started writing protections for IPv6 specifically, not just packets tunneling over IPv6, but protections against exploits written for IPv6. They are working with the DoD (Dept of Defense) to implement protections for the federal government. As with other products, you will need to be on a specific platform (2500N and 5200N) to take advantage of their IPv6 protections. I’m also drawn to good central management, and their’s is up there with Check Point. Working with the federal government doesn’t necessarily make them the be all/end all of IPS technologies, but it was good to see that they are making legitimate steps forward.

Further Resources

IPv6 Capabilities in Cisco’s IPS Software Version 6.2
HP TippingPoint Security
CheckPoint Intrusion Prevention

Introduction

IPv6 presents multiple challenges to the network administrator implementing it on a production network. The combination of new concepts and types of addresses with a different format for representing those addresses makes the task seem much more daunting than it is. While an open mind will be a requirement to grasp the concepts and design of an IPv6 network, it is not quite as different as it appears on first glance. This article will focus on those differences and help relate the new ideas introduced in IPv6 to your existing knowledge of how IPv4 works today.

Contrary to what some misinformed reporters have published, IPv4 and IPv6 differ by much more than two digits. While IPv4 is using thirty-two (32) bits to support its addressing, IPv6 uses one hundred and twenty-eight (128) bits. This is an increase in address space far larger than is easily comprehensible, considering that each VLAN/network subnet will have more addresses available to it than the entire IPv4 Internet has available globally today. Before your eyes light up like you won the lottery, read on, for there are many more changes to how networks are subnetted.

Address Concepts and Layout

A new concept introduced in IPv6 is that of a link-local IP address. Instead of performing interface setup and configuration without an address, the IPv6 stack generates an address to use for any purpose that is local to the interface. This includes functions such as Neighbor Detection (the function ARP used to support), Router Solicitation and Advertisements that perform many of the functions that DHCP used to support, and the addresses used as next-hop routers for a host’s default gateway. If you have a reasonably modern operating system and you have done nothing to disable IPv6, check out your interface configuration and you may be surprised to find an IPv6 address beginning with fe80:: lurking on your system. This can be a security consideration as well if your platform is not firewalling IPv6 as well as IPv4.

IPv6 addresses are laid out in a similar fashion to IPv4 addresses, but instead of using the dotted quad notation (four decimal numbers separated by periods, e.g. 192.168.1.1), IPv6 addresses are separated into eight sections of four hexadecimal digits (also called hexits) each separated by colons, e.g. 2001:0db8:b33f:0001:0000:0000:0000:f00d. Fortunately, there are a few shortcuts available to make these new addresses look far less intimidating. First, any leading zeros in a particular set of four hexits can be omitted, which makes the second group read “db8” instead of “0db8,” and the fourth group read as “1” instead of “0001.” Second, the largest contiguous set of zeroes in the entire address can be completely replaced with a double colon. Combining these two shortcuts, our address above would read as 2001:db8:b33f:1::f00d, which is much less painful to type.

IPv6 addresses are separated into a network portion and a host portion determined by the subnet mask just as they are in IPv4. The host portion of the address can be set statically to any unique value for the subnet, but a scheme exists to generate the address based on the MAC address of the interface. This format is called Modified EUI-64 and works as follows, given the MAC address 00:1A:0F:03:27:34 and the network address used in our example above, which is 2001:db8:b33f:1::/64:

1. Insert FF:FE into the middle of the MAC address, resulting in 00:1A:0F:FF:FE:03:27:34.
2. Because MAC addresses are considered globally unique, the 7th most significant bit is set to a 1 to indicate that this address is globally unique. This would change the resulting 64-bit string to 02:1A:0F:FF:FE:03:27:34.
3. Remove every other colon starting with the leftmost and use lowercase letters to leave the address in the IPv6 format. Prepend it with the network portion, resulting in 2001:0db8:b33f:0001:021a:0fff:fe03:2734.
4. Performing the shortening techniques described above would result in the address 2001:db8:b33f:1:21a:fff:fe03:2734.

IPv6 also has a few special addresses that are analogous to IPv4. The following table shows a few of these:

As you can discern from the table, IPv6 has done away with the concept of broadcast addresses and now uses multicast to deliver packets to different classes of devices. Part of an IPv6 implementation requires that the network device joins the appropriate multicast group via IGMP when assigning an IPv6 address to an interface. This is an important consideration for the administrators of switching devices because it will require functional IGMP snooping to avoid flooding all of this multicast traffic to all ports in a VLAN.

Subnet Design

Much like IPv4, there are subnets set aside for specific usage. The following table shows the most commonly used or implemented network prefixes in IPv6 and their IPv4 counterparts:

Link-Local addressing was discussed above. Private addressing, defined in IPv4 by RFC1918, has now been consolidated down to one /7 network. Unlike IPv4, however, only systems that will never communicate with the Internet at all should be assigned an address from the ULA range. Because there is no concept of NAT in IPv6, there is no way to get ULA-addressed systems onto the Internet without some kind of application-layer proxy.

Also unlike RFC1918, ULA addresses are still supposed to remain globally unique even if they are not globally routable. RFC4193 defines a procedure for generating your ULA prefix to be reasonably sure that no conflicts exist. Because this method is not completely foolproof, there is a registry located at http://www.sixxs.net/tools/grh/ula/ that both implements the generation procedure as well as allows for the registration of the prefix. When in doubt, it is likely a good idea to assign Global addresses rather than Unique-Local Addresses in your environment unless there is a specific need for a subnet with no Internet connectivity.

With these basics on address layout and special subnetting, we can look a little deeper into the details of implementing Global addresses on your network. IPv6 will continue the use of the Classless Inter-Domain Routing (CIDR, often pronounced “cider”) subnet notation as shown above. CIDR was implemented to help slow the exhaustion of IPv4 addresses by allowing a finer gradation of subnetting to be done. Those with smaller networks could now be allocated only to the public address space needed to cover the services being presented to the Internet by combining it with Network Address Translation (NAT), and private address space allocated from the RFC1918 address space. While the same style of notation is still used, the subnetting in IPv6 is not quite as flexible. Here is the breakdown of the example address used in the previous section:

IPv6 networks should always use a 64-bit subnet mask with a few rare exceptions discussed below. While this may sound inflexible to those network operators trying to squeeze every last address from an IPv4 allocation, the standard allocation of a /48 from your ISP or Regional Registrar allows for 65,536 distinct subnets to be defined at the given site. From an addressing point of view, there is quite a lot of room to grow and experiment.

That 64-bit network address is broken down into two parts. The routing prefix is the IPv6 allocation provided to you from your ISP or directly from a regional registrar (more on this below). This prefix will almost always be 48 bits long and is properly written as 2001:db8:b33f::/48. The other 16 bits of the address are collectively called the Subnet ID. Rather than breaking down a /24 IPv4 allocation into smaller networks as is commonly done today, IPv6 has this hierarchical concept built into it. There are a few possible exceptions to the smallest subnet being a /64. The most common exception will be quite familiar to those who follow Cisco’s best practices regarding router IP addressing and identification. Router loopback addresses do not have to use an entire /64 subnet. The current recommendation in IPv6 is to designate one Subnet ID to be for router loopback addressing and assign a single /128 for each router from that /64 block. Because of the large number of addresses available in a /64, it is unlikely that a single site will ever need more than one Subnet ID assigned for loopback addresses. A similar proposal exists for assigning addresses to point-to-point interfaces for serial links and other tunnels. In this case, much like a /30 network in IPv4, a /126 subnet could be defined to handle networks that will only ever have two interfaces. If any sort of auto-configuration could be used on the tunnel or point-to-point interface in the future, it may be best to stick with a /64 subnet.

Internet Routing of IPv6 Networks

Address allocations will continue to come from your ISP as most IPv4 allocations do today. Your ISP will assign a /48 network for you to use at your site as described above. This network is then aggregated into the ISP’s larger block, which is most likely a /32 according to current policies. Another direction to go with IPv6 addressing is to receive your own /48 block directly from ARIN. Those who have had IPv4 space for a long time and got in early currently enjoy the flexibility of switching ISPs without the nightmare of renumbering all of your devices. Fortunately, for those with current allocations in IPv4 or for those who are currently using BGP to announce a /24 block to multiple ISPs, ARIN will assign a /48 directly to you. Because of the flexibility it provides (all devices with few exceptions will be given publicly routable IP addresses), this is by far the best situation to be in for IPv6, so check out ARIN’s website for end-user IPv6 assignment: https://www.arin.net/resource /request/ipv6_initial_assign.html. Direct allocations from ARIN require the use of BGP on your Internet routers to announce address space to your ISP, so you must also have an autonomous system number (ASN) from ARIN in order to use your new IPv6 addresses.

While all of this sounds quite simple, it is unfortunately just a pipe dream today. No ISP in the Northeast Ohio area and beyond seem to be offering any sort of IPv6 transport as of the writing of this article. The response has been anything from being hung up on to a response of “Um, we’re still beta testing that.” Even though IPv6 has been around for about a decade, most network operators seem to be dragging their feet on offering it as a production service. Fortunately, one ISP in particular seems to have drunk the entire pitcher of IPv6 Kool-Aid and is offering a method to tunnel over the existing Internet on IPv4 and pass IPv6 traffic over the tunnel. Hurricane Electric is offering this service for free and will support both receiving a /48 delegation from their existing address range or will allow advertisement of directly allocated address space from ARIN or another RIR via BGP. Currently, this is the easiest way to attach to the IPv6 Internet, so check out http://tunnelbroker.net/ for details.

Where Do We Go From Here?

Once you have worked through the process of getting IPv6 online in your environment and getting connectivity via Tunnel Broker, what’s next?

ISPs are businesses, so their primary goal is to take your money and in return provide the service that you want from them. I suggest calling your account representative for each of your ISPs and telling them you want IPv6 transport from them. The only way the ball will move forward in adoption of IPv6 is if the businesses that need to support it think their customers want it. If enough people start requesting it, it will eventually make it up the sales chain and down the engineering chain and become reality.

World IPv6 Day is an event coming up in June sponsored by ISOC and supported by many major players on the Internet scene including Google, Facebook, and Akamai. The goals behind the event are to have the first full scale test of major Internet content via IPv6. Check out World IPv6 Day for further details including how to participate in the event with your own network.

Download our IPv6 Quick Reference Guide

Well it’s a new year and time to discover an [old] new protocol. I know a lot of you have been regretting the change, but it is, in Matrix terms, “inevitable.” As we delve into a symphony of packet headers, solicitations and address assignments, I recommend that if at any time you start to feel a sudden onset of nausea, headache or loss of balance, please take a deep breath and realize that you are among a majority of professionals who are hearing most of the topics discussed in this article for the first time. Four months ago I was part of that majority. Innocent and naive, I read the RFCs, tried to make sense of the vernacular, set up and broke countless labs, but I persevered. I write before you today not as an expert, but as someone on a journey, and it is my goal to start you in the right place on yours. You will find that a lot of the security thoughts and ideals in IPv4 still apply in IPv6, sometimes even more so. Since I believe that the best way to learn is through getting your hands dirty, I highly suggest that if you do not have a lab environment already set up, quickly grab a server, install your virtualization suite of choice, and join me as we hike up the 2001::/3 mountain.

Since we will be viewing packet captures and referencing various headers, I think the best place to start our trip is with a sideby-side comparison of an IPv4 packet to an IPv6 packet. In figure 1-1, we see the header format of a typical IPv6 packet. It is interesting to note what has been carried over and left behind in the transition to IPv6. one of the biggest changes you willnotice, is the size of the header is now 40 octets, as opposed to 20 in IPv4, as opposed to 20 in IPv4. This is due mostly to the source and destination fields containing 128-bit addresses, which increases the header size considerably. The 20-bit flow label, which is intended to be used for packets that request non-default QoS or “real-time” handling by IPv6 routers, is the only “new” field that never existed in IPv4. Currently this is still considered experimental. You will also see that some fields are synonymous to their IPv4 parents. In v6, Traffic Class replaces Type of Service, Hop Limit replaces Time to Live, and Payload Length replaces Total Length. Also, a notable mention is the next-header field, which indicates what? The next header! Be it TCP, UDP, ICMPv6, Fragment or others, they can be layered one on top of the other. These extension headers should not be processed along a packet’s path until it reaches it’s destination address. If an extension header is to be processed, they must be processed in order, in the case of multiple extension headers. One exception to the previous two sentences is the HBH, or Hop By Hop header, which must be processed by all nodes it is forwarded through. I have included an example of a typical HTTP connection to Google in figure 1-2, and an HBH header as well in 1-3. In figure 1-3, we see a node sending a packet to the link-local all MLDv2 routers address, joining the all-hosts multicast group. Also, please note the source address of ::, as we will be referencing this later on in this article.

Figure 1-1: IPv4 and IPv6 Header Comparison:

Figure 1-2: HTTP Capture of a SYN-ACK from Google:

00:04:23:d2:92:47 > 00:0c:29:fc:c0:a7, ethertype IPv6 (0x86dd), length 94:
(hlim 55, next-header TCP (6) payload length: 40)2001:4860:b007::63.80 >
2001:---:---:---:20c:29ff:fefc:c0a7.44107: Flags [S.], cksum 0xf04c (correct),
seq 2423006157, ack 3909226675, win 5712, options [mss 1410,sackOK,
TS val 2947579728 ecr 214482298,nop,wscale 6], length 0

Figure 1-3: HBH Header:

00:0c:29:0d:0b:8a > 33:33:00:00:00:16, ethertype IPv6 (0x86dd),
length 90: (hlim 1, next-header Options (0) payload length: 36) :: >
ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] ICMP6, multicast
listener report v2, length 28, 1 group record(s)
[gaddr ff02::1:ff0d:b8a to_ex { }]

Now that we have defined what an IPv6 packet looks like, we can continue our on our quest for IPv6 mastery. Next stop: Stateless Address Autoconfiguration or SLAAC. This is used to automatically configure a host’s prefix for it’s global unicast address, as well as link MTU, recursive DNS server(s), routers, default and other miscellaneous network information including directing a host to a DHCPv6 server for additional settings. Without SLAAC, a node cannot configure a global unicast address automatically, which may be advantageous for DMZs or private networks that you do not want to have immediate Internet access.

Our next scheduled stop is the almighty Router Advertisement, or RA. These packets are the seeds of an address, and are sent to the link-local all-hosts multicast address ff02::1, either within a certain time period, or as a response to a router solicitation request. When looking at an RA, you will notice that the hop-limit is 255. This ensures that when a node receives an RA, it has not been forwarded through any other routers, as each router the packet goes through will decrease the hoplimit by 1. If the hop limit is less than 255, or the source address of an RA is not a link-local address, a host must silently discard the packet and consider its information invalid. It is important to monitor your advertisements, either through an IDS or via specialized software, as these packets can make or break a network. Unfortunately there is no production-ready solution to stop someone from spoofing these packets and routing every host’s traffic through their node, however, there is an implementation in the works called SeND, or Secure Neighbor Discovery, that attempts to deal with the caveats of the standard Neighbor Discovery Protocol. Take a look at Figure 1-4, and RFCs 3791 and 3792 for more information. Also, be sure to look at the fields in the actual advertisement, as we will come back to most of them later on in the newsletter.

Figure 1-4: Router Advertisement:

00:04:23:d2:92:45 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd),
length 110: (hlim 255, next-header ICMPv6 (58) payload length: 56)
fe80::204:23ff:fed2:9245 > ff02::1: [icmp6 sum ok] ICMP6,
router advertisement, length 56 hop limit 64, Flags [none],
pref high, router lifetime 300s, reachable time 0s, retrans time
0s prefix info option (3), length 32 (4): 2001:---:---:---::/64,
Flags [onlink, auto], valid time 86400s, pref. time 14400s
0x0000: 40c0 0001 5180 0000 3840 0000 0000 2001
0x0010: 0--- ---- 0--- 0000 0000 0000 0000
source link-address option (1), length 8 (1): 00:04:23:d2:92:45
0x0000: 0004 23d2 9245

When an interface on a node becomes enabled, it may send a Router Solicitation, or RS packet to the link-local all-routers address ff02::2 to induce an RA, instead of waiting for the next scheduled advertisement. It is imperative that you remember all routers will respond to this solicitation, so be sure to set a priority on each router if they are set up in a failover scenario, otherwise your node will not get very far when you try ping6 google.com! Router solicitations are sent only after an interface has verified that there is not a duplicate link-local address on its network. In figure 1-5, we see an example of a host requesting an RA from the all-routers address.

Figure 1-5: Router Solicitation:

00:0c:29:0d:0b:8a > 33:33:00:00:00:02, ethertype IPv6 (0x86dd),
length 70: (hlim 255, next-header ICMPv6 (58) payload length: 16)
fe80::20c:29ff:fe0d:b8a > ff02::2: [icmp6 sum ok] ICMP6,
router solicitation, length 16 source link-address option (1),
length 8 (1): 00:0c:29:0d:0b:8a 0x0000: 000c 290d 0b8a

How do we get to the point where we can send a router solicitation? Well, to accomplish this we will need some assistance from our friends, the Neighbor Solicitation or NS, and the Neighbor Advertisement, or NA. You can think of these as packets of a hybrid version of ARP in IPv4. After an interface calculates it’s link-local address from it’s EUI-64 address, it will send out packets with a source address of “::” in order to figure out if there is a duplicate address on the network. This is what is known as Duplicate Address Detection, or DAD. It does this by first joining the all-hosts multicast group, and then sending out an NS packet for its own link-local address. If it does not receive a reply, the node will then proceed to send an RS, using its link-local address as the source. Once it receives an RA, the host will again send an NS packet for its global unicast address, and again if it does not receive a reply, the host will use its auto-configured global unicast address for accessing the Internet. I have included this beautiful symposium in its entirety in figure 1-6.

Figure 1-6: DAD and SLAAC, from start to finish:

00:0c:29:0d:0b:8a > 33:33:00:00:00:16, ethertype IPv6 (0x86dd),
length 90: (hlim 1, next-header Options (0) payload length:
36) :: > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok]
ICMP6, multicast listener report v2, length 28, 1 group record(s)
[gaddr ff02::1:ff0d:b8a to_ex { }]
00:0c:29:0d:0b:8a > 33:33:ff:0d:0b:8a, ethertype IPv6 (0x86dd),
length 78: (hlim 255, next-header ICMPv6 (58) payloadlength: 24)
:: > ff02::1:ff0d:b8a: [icmp6 sum ok] ICMP6, neighbor solicitation,
length 24, who has fe80::20c:29ff:fe0d:b8a
00:0c:29:0d:0b:8a > 33:33:00:00:00:02, ethertype IPv6 (0x86dd),
length 70: (hlim 255, next-header ICMPv6 (58) payload length:16)
fe80::20c:29ff:fe0d:b8a > ff02::2: [icmp6 sum ok] ICMP6, router
solicitation, length 16source link-address option (1), length 8 (1):
00:0c:29:0d:0b:8a0x0000: 000c 290d 0b8a 00:04:23:d2:92:45 >
33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 110:
(hlim 255, next-header ICMPv6 (58) payload length: 56)
fe80::204:23ff:fed2:9245 > ff02::1: [icmp6 sum ok] ICMP6, router
advertisement, length 56hop limit 64, Flags [none], pref high,
router lifetime 300s, reachable time 0s, retrans time 0s prefix info
option (3), length 32 (4): 2001:---:---:---::/64, Flags
[onlink, auto], valid time 86400s, pref. time 14400s 0x0000: 40c0
0001 5180 0000 3840 0000 0000 2001 0x0010: 0--- ---- 0--- 0000 0000
0000 0000 source link-address option (1), length 8 (1):
00:04:23:d2:92:45 0x0000: 0004 23d2 9245 00:0c:29:0d:0b:8a >
33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90:
(hlim 1, next-header Options (0) payload length: 36)
fe80::20c:29ff:fe0d:b8a > ff02::16: HBH (rtalert: 0x0000) (padn)
[icmp6 sum ok] ICMP6, multicast listener report v2, length 28,
1 group record(s) [gaddr ff02::1:ff0d:b8a to_ex { }]
00:0c:29:0d:0b:8a > 33:33:ff:0d:0b:8a, ethertype IPv6 (0x86dd),
length 78: (hlim 255, next-header ICMPv6 (58) payload length:
24) :: > ff02::1:ff0d:b8a: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 24, who has 2001:---:---:---:20c:29ff:fe0d:b8a

Figure 1-7: mDNS Example:

00:0c:29:fc:c0:a7 > 33:33:00:00:00:fb, ethertype IPv6
(0x86dd), length 325: (hlim 255, next-header UDP (17) payload length:
271) fe80::20c:29ff:fefc:c0a7.5353 > ff02::fb.5353: [udp sum ok] 0
[3q] [5n] ANY (QM)? landscape [00:0c:29:fc:c0:a7]._
workstation._tcp.local. ANY (QM)? landscape.local. ANY (QM)?
7.a.0.c.c.f.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.
arpa. ns: landscape.local. [2m] AAAA fe80::20c:29ff:fefc:c0a7,
7.a.0.c.c.f.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.
arpa. [2m] PTR landscape.local., landscape.local. [2m] HINFO,
landscape [00:0c:29:fc:c0:a7]._workstation._tcp.local. [2m] SRV
landscape.local.:9 0 0, landscape [00:0c:29:fc:c0:a7]._workstation.
_tcp.local. [1h15m] TXT "" (263)

Figure 1-8: Static address configuration of /etc/network/interfaces:

auto eth0
iface eth0 inet6 static
address 2001:---:---:---::51
netmask 64
gateway 2001:---:---:---::1
# Additional addresses
up /sbin/ifconfig eth0 inet6 add 2001:---:---:---::60
up /sbin/ifconfig eth0 inet6 add 2001:---:---:---::61
up /sbin/ifconfig eth0 inet6 add 2001:---:---:---::62

Figure 1-8: IPv6 Test Network:

Immediately, I hit the ground running, cloning virtual machines left and right, installing SecurePlatform and configuring VLANs. Not soon after I started, I hit my first wall. Check Point’s IPv6Pack ONLY runs on R70.10. For those of you who do not know, the latest Hot-Fix Accumulator for R70 is HFA40, which contains some great fixes to HFA10′s “shortcomings.” This is a prime example of the lack of vendor support for IPv6 today, and unfortunately you will find this across the board. Regardless, I carried on, built my management server, and got my IPv6 cluster up and running. Applying an IPv6 address to SPLAT is more of a manual process than applying an IPv4 address, however, Check Point’s release notes for the IPv6Pack are well documented, and if followed correctly, you will end up with a fully functioning, stateful failover capable, dual-stacked cluster. One thing to remember in your rulebase is that you cannot have the following rule combinations: source IPv4 -> destination IPv6, or source IPv4 + IPv6 -> destination IPv6 or IPv4. You may create rules that contain both IPv4 and IPv6 as the source and destination, or create them with only IPv6 addresses/networks as the source and destination. Aside from that, your rulebase structure is still as straightforward as it was in IPv4, and should adhere to the same guidelines.

After I setup an IPv6 cluster, it was time to move on to a Linux client. I chose Ubuntu 10.04 as it is the latest LTS or long-term support version of Canonical’s OS, and it is typically what we deploy in production networks. The server installation is fairly straightforward, except that you will not be able to configure an IPv6 address at all during the install. Once the server boots up for the first time, you can edit /etc/network/interfaces in relatively the same style as an IPv4 address. One important note is that if you want to use a privacy address, you may echo 1 into /proc/sys/net/ipv6/conf/<ifname /use_tempaddr, or add the appropriate configuration to /etc/sysctl.conf. Also, if you only intend on using a static address and would like to disable SLAAC altogether, you can echo 0 into /proc/sys/net/ipv6/<ifname>/autoconf. In figure 1-8, I have included an example configuration of a static address configuration, with additional static addresses. You can also set your default route manually, show neighbors or show the IPv6 routing table with the “ip -6” command, shown in Figure 1-9. The “ip -6 neighbor show” command is the equivalent to “arp -an” in IPv4 terminology.

Figure 1-9: ip -6 commands:

ip -6 neighbor show
2001:---:---:---::1 dev eth1 lladdr 00:04:23:08:c5:a5 DELAY
fe80::204:23ff:fe08:c5a5 dev eth1 lladdr 00:04:23:08:c5:a5 DELAY
ip -6 route show
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
default via 2001:---:---:---::1 dev eth1 metric 1 mtu 1500 advmss 1440 hoplimit 0

On to the Windows machines. At first I decided to try Windows Server 2003, to see how it fares as far as configuring an IPv6 address goes. You need to go into your network adapters and install the IPv6 adapter, and that is all you can do from the GUI. From here, you need to open up your trusty cmd.exe, and use netsh to configure your address, netmask, routers, and DNS. Server 2008 on the other-hand does offer a way for you to do this in the network configuration GUI, and it’s pretty straightforward: you can either use automatic configuration, or tell it to use a static address. Technet contains valuable information on how to use the netsh commands to do any custom configuration beyond the scope of the GUI.

I have my hosts up and my firewalls configured, so what’s next? RADVd. Check Point offers an RPM for SPLAT that is a little out-dated from the latest version of the router advertisement daemon, but works fine and integrates into the cpstop and cpstart commands. I have included the configuration taken from my primary, active cluster member in figure 1-10. Some important things to note in the configuration are that all configuration directives must be followed by a semicolon. The exception to this is when the configuration directive is followed by subdirectives, in which case they are encased in brackets, with the last bracket promptly followed by a semicolon. When I am setting up RADVd, I like to have a copy of the manpage handy, as there is no default configuration when you first install it. Some important directives to note are the AdvDefaultLifetime; if this is set to 0, this router will not be used as a default router; and also the AdvReachableTime, and AdvRetransTimer, which if set to 0, will disable NUD. Also, if you would like to have RADVd include a DNS server to use in its advertisements, you can use the RDNSS directive, and set the priority of the DNS server if you need to. In order to get Ubuntu to work with this, you must install rdnssd, which is in the Ubuntu APT repository.

Figure 1-10: /etc/radvd.conf:

interface eth9
{
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 4;
AdvReachableTime 20;
AdvRetransTimer 10;
AdvDefaultLifetime 4;
AdvSourceLLAddress off;
AdvDefaultPreference high;
prefix 2001:---:---:---::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
RDNSS 2001:470:20::2
{
AdvRDNSSPreference 12;
};
};