http://www.informationweek.comInformationWeeken-usCopyright 2012, UBM LLC.2011-10-17T08:00:00ZThe emerging protocol promises to make it easier to deal with virtualization while also using lower-cost switches.http://www.informationweek.com/news/231900201?cid=SBX_iwk_related_commentary_Business_telecomServer virtualization is now a proven practice, creating a cost-effective means of allocating compute resources to changing user and application requirements. But when packets leave the server, they still pass through a traditional switching architecture, which doesn't have that same level of flexibility. </p> <P> The goal of software-defined networking (SDN) is to bring the benefits of virtualization--shared resources, user customization, and fast adaptation--to the switched network. SDN puts the "intelligence" of the network into a controller or hierarchy of controllers in which switching paths are centrally calculated based on IT-defined parameters, and then downloaded to the distributed switching architecture. </p> <P> The cost savings are apparent. The expensive part of a high-end switch is the sophisticated control plane and custom silicon. By moving the control plane to a centralized controller, the architecture can use inexpensive commodity switches built with standard silicon. Reducing the cost of each switch by 70% or more, spread across a data center or campus, quickly adds up to real money.</p> <P> SDN is also about improving performance. A centralized control plane lets companies customize their networks without depending on or coordinating different vendor operating systems. Networking pros can quickly change what data types get forwarding priority, as business requirements change.</p> <P> The first step toward SDN is to define a messaging protocol between the controller and the individual switches making up the forwarding plane. This is where the emerging OpenFlow networking standard comes in. OpenFlow enables open, virtualized, and programmable networks. Each of these elements is key.</p> <P> Open: The standardized instruction set means any OpenFlow controller can send a common set of instructions to any OpenFlow-enabled switch, regardless of the vendor.</p> <P> Virtualized: IT can specify different forwarding rules for different data types, creating multiple logical forwarding paths over the same physical network, depending on the needs of a particular app.</p> <P> Programmable: The still-evolving OpenFlow instruction set lets IT create rule sets that work in combination with a switch vendor's configuration options, or independent of them. With its roots in academic research networks, OpenFlow lets users try new ideas or create new protocols independent of any vendor. Most important, IT can program a network for specific application requirements.</p> <P> <!-- KINDLE EXCLUDE --> <center> <div id="inlineReportPromo"> <div class="inlineReportPromo_headline"><a href="http://reports.informationweek.com/abstract/19/8351/Network-Infrastructure/strategy-inside-openflow.html?cid=pub_analyt__iwk_20111017" target="_blank" style="color:#ffffff;">Inside OpenFlow</a></div> <div class="inlineReportPromo_inner"> <img src="http://twimgs.com/informationweek/1313/313CS_Reportcover_175.jpg" width="175" height="107" style="float:right;"> Sign up for a free membership with <strong><a href="http://reports.informationweek.com/abstract/19/8351/Network-Infrastructure/strategy-inside-openflow.html?cid=pub_analyt__iwk_20111017"><i>InformationWeek Reports</i></a></strong> and get our full report on OpenFlow and software-defined networks.<br /> <br /> This report includes additional analysis, an in-depth tutorial on the OpenFlow protocol, and seven diagrams illustrating software-defined networks. <center><strong><a href="http://reports.informationweek.com/abstract/19/8351/Network-Infrastructure/strategy-inside-openflow.html?cid=pub_analyt__iwk_20111017">Get This</a> And <a href="http://reports.informationweek.com/">All Our Reports</a></strong></center> </div> </div> </center></p><br clear="all"> <!-- /KINDLE EXCLUDE --><strong>Roots Of Network Virtualization</strong></p> <P> The separation of the control plane from the forwarding plane isn't new with OpenFlow. It has been used in the design of high-end routers since the mid-1990s and telephony switches long before that. The initial motivation was to protect each switch element from a degradation in another: A very busy route processor doesn't hurt forwarding performance, and peaks in network load don't pull processing resources away from the control plane. Significantly, that separation--first within a single chassis, and more recently with a single processor controlling multiple switching fabrics--provided an environment for the development of high-availability features.</p> <P> Multiprotocol label switching (MPLS), another key technology in modern networks, also has features that relate to this trend, since it builds an "intelligent" access layer around a relatively dumb but high-performance network core. That structure enables the creation of flexible, innovative services over a homogeneous backbone. MPLS also reflects a trend in networks similar to what we're seeing in server virtualization: A single physical network uses a logical component--MPLS--to allow the overlay of multiple virtualized network services. </p> <P> What's new and different with OpenFlow is that, in theory, it could work with any type of commodity switch.</p> <P> Operating in the gap between a centralized control plane and a distributed forwarding plane, OpenFlow defines a protocol that lets a controller use a common set of instructions to add, modify, or delete entries in a switch's forwarding table. An instruction set might not sound like a technology breakthrough, but it's all about what people do with that instruction set, says Kyle Forster, co-founder of Big Switch Networks, a startup building networking products based on the OpenFlow standard. If you read the x86 server instruction set, it "isn't obvious that you could build Linux, Microsoft Word, or the Apache Web Server on top," Forster says. "I think OpenFlow is the same way. It isn't about the basics. It's all about the layers and layers of software built on top. That is where the benefits are going to be felt."</p> <P> <strong>Origins Of OpenFlow</strong></p> <P> OpenFlow began at Stanford University, under professors Nick McKeown, Martin Casado, and others. Their goal was to create an environment in which researchers could experiment with new network protocols while using the campus's production network. It let researchers try out those protocols in a realistic environment without the expense of building a test network or the risk of blowing up the campus network and disrupting production traffic.</p> <P> The first consideration for using OpenFlow outside of academia was to scale bandwidth in massive data centers. Forster calls this the "million-MAC-address Hadoop/MapReduce" problem. For uses such as Google's search engine, parallel processing of massive data sets takes place across clusters of tens or hundreds of thousands of servers. For such big data applications, "it doesn't take much back-of-the-envelope calculating to come to the conclusion that a tree-based architecture will require throughput on core switches/routers that simply can't be bought at any price right now," Forster says.</p> <P> Interest in OpenFlow has since expanded to cloud computing and virtualized services companies. Earlier this year, six companies--Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo--formed the Open Networking Foundation (ONF) to support development of SDN and, by extension, the OpenFlow protocol. ONF now has more than 40 members, mostly vendors, which pay $30,000 a year to fund development of the standard.</p> <P> The version of the OpenFlow specification in most widespread use is version 1.0.0, which in December 2009 defined three components: controller, secure channel, and flow table.</p> <P> The newest version of the spec, 1.1.0, released in February, adds two more components: group table and pipeline (see diagram, right). </p> <P> The controller is of course the control plane, and it provides IT programmability to the forwarding plane. The controller manages the forwarding plane by adding, changing, or deleting entries in the switches' flow tables.</p> <P> The controller manages the switches across a secure channel. "Secure channel" is in fact slightly misnamed, since it doesn't provide any security on its own. While the channel is normally authenticated and encrypted using Transport Layer Security, it can be simple unsecured TCP. Implementing an SDN architecture using unsecured communication channels is utter folly, of course, but it can be done. Also, messages across the secure channel are reliable and ordered, but aren't acknowledged and therefore aren't guaranteed.</p> <P> <center><img src="http://twimgs.com/informationweek/1313/313_CSdiagram3.jpg" width="550" height="473" alt="How do you manage small projects that are not part of PMI methodologies?" hspace="0" vspace="0" border="0" style="margin-bottom:7px;" /><br /></center></p><strong>Who Needs It</strong></p> <P> While the most intense interest in OpenFlow is in large-scale data center applications, there's already speculation about how OpenFlow-based SDNs can benefit other industries. The fact that Deutsche Telekom and Verizon are among the founders of the ONF provide some hints at next applications.</p> <P> In mobile networks, OpenFlow can help solve a notoriously hard problem in IP: monitoring, metering, and servicing user traffic. In service provider networks, OpenFlow may provide a more workable alternative to MPLS traffic engineering. </p> <P> More broadly, the ability of a network operator to create custom functions applicable to its own network, and then apply those functions to switches from multiple vendors, is the true promise of SDNs. Technology users have always found surprising ways to use the tools available to them, innovating from the bottom up rather than limiting themselves to top-down vendor systems. An open instruction set could accelerate that innovation.</p> <P> OpenFlow version 2.0 is in the works, bringing with it a generalized networking instruction set, as well as a standardized API to the network operating system that's planned for 2012 release. That upgrade would make it easier for third-party network management systems and data center provisioning tools to interact with OpenFlow controllers. Manufacturers of commodity switches, including Hewlett-Packard and Extreme Networks, are starting to line up behind OpenFlow and SDNs, as are new vendors such as Nicira Networks and Big Switch Networks that are focused on network control systems. </p> <P> OpenFlow has the right combination of industry and academic backing to ensure that its development and evolution continue. It has the potential to turn the networking world on its head by disrupting the market positions of high-end router and switch vendors, including Cisco and Juniper. Or those vendors have the potential to turn this trend to their advantage (see related story, p. 33). </p> <P> While still in its infancy, OpenFlow has already been used to demonstrate fixes to old problems. Conventional Ethernet switching architectures have long been stuck in inefficient, inflexible tree structures. Those don't look sustainable for a lot of what companies will want to accomplish. OpenFlow can be expected over the next few years to change the landscape of large data center and enterprise campus networks.</p> <P> <center><img src="http://twimgs.com/informationweek/1313/313_CSdiagram1.jpg" width="542" height="550" alt="How do you manage small projects that are not part of PMI methodologies?" hspace="0" vspace="0" border="0" style="margin-bottom:7px;" /><br /></center></p> <P> <strong>Related Links:</strong><br> <ul class="normalUL"> <li> <b><a href="http://www.informationweek.com/news/hardware/data_centers/231900200">The Biggest Thing Since Ethernet: OpenFlow</a></b> </li> <li> <b><a href="http://www.informationweek.com/news/hardware/data_centers/231900201">OpenFlow Tutorial: Next-Gen Networking Has Much To Prove</a></b> </li> <li> <b><a href="http://www.informationweek.com/news/hardware/data_centers/231900585">OpenFlow's Impact: The Industry Debate Rages</a></b> </li></p>2011-10-17T08:00:00ZWhat's new about the networking protocol, and why some argue it isn't a game changer.http://www.informationweek.com/news/231900585?cid=SBX_iwk_related_commentary_Business_telecomIs OpenFlow just the latest attempt to centralize network control, or is it something wholly new? People across the industry have been debating whether OpenFlow is really an industry game-changer.</p> <P> "The 'new thing' in my mind is the timing," says Kyle Forster, co-founder of Big Switch Networks, a startup developing a network controller based on OpenFlow. "The first leg of this is silicon trends--merchant silicon is changing the rules around who makes what. The second leg is supply chain trends. Server vendors must react to the Cisco UCS by expanding into networking. Last, customer requirements are changing. Networks for VMs and for the increasingly disparate types of mobile and embedded devices on a campus LAN are different from networks of five and 10 years ago."</p> <P> OpenFlow itself is just a definition of instruction and messaging sets between a server-based controller and a group of switches. It's how the controller uses the instruction set that will determine how disruptive the protocol becomes to the networking industry.</p> <P> Ivan Pepelnjak, chief technology adviser at NIL Data Communications, has written a number of blog posts (at blog.ioshints.info) questioning whether the expectations being set around OpenFlow are overblown. "I can't see a single area where a TCAM download protocol--which is what OpenFlow is--can do things that a router or switch could not do. There are things that can be done with OpenFlow that cannot be done with current protocols. But then one has to ask oneself: Why has nobody yet developed a protocol to address those things?"</p> <P> Pepelnjak does see the protocol as a means of consolidating and streamlining the way networks are controlled. He says OpenFlow will make it easier to implement customized functionality, and it will give third-party software lower-level control in multivendor networks.</p> <P> Forster counters that OpenFlow will make a lot of difficult networking problems easier to solve. "Automating move-add-change requests, virtual network overlays, multipath forwarding, and automated provisioning are all relatively straightforward engineering initiatives with an OpenFlow-style centralized control plane," he says. "While they can be done with a distributed control plane or, practically speaking, with a classic set of networking features and a lot of Expect scripts, these classic approaches tend to be a fragile set of scripts that open up a Pandora's box of corner cases."</p> <P> Martin Casado, one of OpenFlow's developers and currently CTO of Nicira Networks, says he's seen some "pretty cool stuff" built on OpenFlow, like network connectivity managed by a high-level language that plugs into an existing, proprietary security framework. The key points are that OpenFlow gives network mangers programmatic control of their networks using industry standards, he says, "using the same distributed system libraries and packages they use to orchestrate the rest of their infrastructure."</p> <P> Ultimately, the success or failure of OpenFlow--and, more widely, of software-defined networking--depends on how well controllers integrate with switches and how widely available OpenFlow-capable switches become. "I think we're a long way out," Casado says, "before a controller vendor can support an OpenFlow-capable switch without a fairly close partnership between the two companies."</p> <P> Dave Ward, CTO of Juniper Networks' Infrastructure Products Group, says the biggest benefit of OpenFlow is giving IT more visibility and control in virtualized data centers. "As endpoints move around in the ever-expanding network footprints, we think that flexible methodologies are needed to enable and disable certain traffic conditions or to enable and disable certain types of traffic," Ward says. "Having such functionality via a common interface could prove very valuable for anyone operating an infrastructure that is experiencing high rates of change."</p> <P> So far, Cisco and Juniper have supported OpenFlow, and Juniper has demonstrated support in some of its products. "The real question about OpenFlow," Ward says, "is not if it provides additional capabilities in any one device, but whether it can deliver those capabilities across a heterogeneous network."</p> <P> <strong>All Articles In This Cover Story:</strong><br> <ul class="normalUL"> <li> <b><a href="http://www.informationweek.com/news/hardware/data_centers/231900200">The Biggest Thing Since Ethernet: OpenFlow</a></b> </li> <li> <b><a href="http://www.informationweek.com/news/hardware/data_centers/231900201">OpenFlow Tutorial: Next-Gen Networking Has Much To Prove</a></b> </li> <li> <b><a href="http://www.informationweek.com/news/hardware/data_centers/231900585">OpenFlow's Impact: The Industry Debate Rages</a></b> </li></p> <P>2011-05-28T00:00:00ZIT pros who see NAT as essential to network security are worried about a wide-open, any-to-any connection model. Should they be?http://www.informationweek.com/news/229502450?cid=SBX_iwk_related_commentary_Business_telecomWe see security as a major stumbling block in enterprise migrations from IPv4 to IPv6. For starters, the code is mostly untested, and too few of our current network security products support IPv6, something the black hat community is banking on. And there's widespread confusion--the idea that some characteristics of IPv6 make it intrinsically more secure than IPv4 is, sadly, just plain false, and information security teams are largely in the dark on how to help their companies safely transition. </p> <P> Consider the "NAT-bashing" slide, a fixture in IPv6 presentations. Presenters gleefully list all the reasons Network Address Translation is evil, and explain how an abundance of IPv6 addresses will finally let us eliminate what was always supposed to be a temporary address-conservation kludge and get back to a true peer-to-peer Internet. High-fives ensue.</p> <P> Except, IT security professionals don't share the enthusiasm. Let's face it, IPv6 idealists can wave their fists at NAT all they want, but there are legitimate concerns about losing the ability to shield internal address schemes.</p> <P> No wonder, then, that among the sessions InformationWeek Analytics presented at the recent Interop conference, by far the most popular was our program on IPv6 with a focus on security. A quick show of hands revealed that most attendees are still in the planning stages of their deployments, par for the course among companies we work with. The good news is that they can take advantage of the lessons learned by telecom carriers and ISPs, which tend to be well along the road to IPv6. And while many conventional enterprise security systems will need to change to work in a v6 network, the upgrade also provides opportunities for improvement--possibly even an outright reimagining of your security strategy.</p> <P> A prime opportunity to see how all this works in real life is World IPv6 Day, set for June 8. This is a milestone in the transition from IPv4 to IPv6, when companies including Akamai, Facebook, Google, and Yahoo will offer their content over IPv6 for 24 hours. The event will provide valuable data on connectivity, ranging from simple system misbehavior to the amount of user traffic that will switch to IPv6 when content is available over the 128-bit version of IP. We're also fielding our first <i>InformationWeek Analytics</i> <a href="http://informationweek.IPv6.sgizmo.com">IPv6 Survey</a> now through June 13, to see where our readers are on the migration curve. We'll share our results in an upcoming report.</p> <P> <!-- KINDLE EXCLUDE --> <center> <div id="inlineReportPromo"> <div class="inlineReportPromo_headline"><a href="http://analytics.informationweek.com/abstract/19/5296/Network-Infrastructure/best-practices-ipv6-transition.html" target="_blank" style="color:#ffffff;">Best Practices: IPv6 Transition</a></div> <div class="inlineReportPromo_inner"> <center><strong>Deploying IPv6: Gateway To the Next-Gen Internet</strong></center><br /> <img src="http://twimgs.com/informationweek/1301/301F2_reportcover_110.jpg" width="110" height="110" class="report110" /> Become an <strong><a href="http://analytics.informationweek.com/abstract/19/5296/Network-Infrastructure/best-practices-ipv6-transition.html"><i>InformationWeek Analytics</i> subscriber</a></strong> and get our full report on IPv6 security.<br /> <br /> This report includes <strong>15</strong> pages of action-oriented analysis including: <ul class="normalUL"> <li>What attackers are looking for in IPv6 networks</li> <li>More on the seven critical features in IPv6that affect your secrity stance</li> <li>Key ways to mitigate your operational risk</li> </ul> <center><strong><a href="http://analytics.informationweek.com/abstract/19/5296/Network-Infrastructure/best-practices-ipv6-transition.html">Get This</a> And <a href="http://analytics.informationweek.com/">All Our Reports</a></strong></center> </div> </div> </center></p><br clear="all"> <!-- /KINDLE EXCLUDE --> <P><strong>The Perimeter Problem</strong></p> <P> Back to security. One thing that quickly becomes clear when rolling out IPv6 is that network systems themselves are the easy part of the project, so much so that it's become accepted wisdom to start a deployment in the center and work outward. Difficulties present themselves in greater numbers as you make your way toward the network edge, where users are connected to services. Envision a "core-to-edge" deployment strategy with your IPv6-enabled network in the middle, surrounded by concentric perimeters of services. Closest to the center are the services essential to the fundamental operation of the network: DNS, DHCP, and the like. Around that perimeter are the services necessary to both manage the network and provide support: Think configuration management, change policy enforcement, monitoring, alarming, and logging.The outside perimeter comprises your security bulwark: firewalls, access control lists, intrusion detection and prevention systems, and the policies enforced by them. The order in which systems are tackled under this model reflects the current v6 readiness of our systems. </p> <P> If your company lists support for IPv6 among the must-have criteria when purchasing new security gear, you're ahead of the game--and likely frustrated that there isn't more such gear available. While network architects have long had a wide variety of IPv6-capable routers and support systems to choose from, security products have lagged the rest of the industry. Incredibly, until recently, relatively few firewalls had useful IPv6 capabilities, and there are still significant limitations.</p> <P> <strong>Security Mythology</strong></p> <P> We hear all the time that IPv6 is intrinsically more secure than IPv4. This misconception likely springs from the fact that support for authentication and encryption is integral to the IPv6 specification. Problem is, a capability called for in a spec does not necessarily translate into a capability that works in an actual network. In fact, our experience shows that few IPv6 implementations provide "built-in" authentication and encryption, and end-to-end IPv6 sessions are not automatically secured. Again, a limitation of vendor implementations of the specification. </p> <P> Another facet of the IPv6 security myth stems from characteristics of the protocol that, while not directly security-related, do have security implications. For example, you'll often hear that IPv6's huge address space makes it immune to port scanning. Assuming a port scanner could "hit" one address per second, a scan of the entire address space of a 64-bit subnet would take upward of 584 billion years. That's an impressive stat, but it ignores the fact that smart subnet spies are already selective about the ports they scan and predictive about the IP addresses they target. Yes, port scanning is more problematic on a typical IPv6 subnet--for both snoops and for your own security team--compared with almost any IPv4 subnet. But stating that IPv6 is immune to scanning is just plain wrong.</p> <P> And don't assume that because most network engineers aren't yet familiar with IPv6, the bad guys aren't either. In fact, as we <a href="http://analytics.informationweek.com/abstract/21/7076/Security/strategy-ipv6-security.html">discuss in our full report</a>, the opposite is true: There are black hats out there who see IPv6 as a once-in-a-lifetime opportunity. So much new code, so much time to probe for flaws. </p> <P>It's up to you to ensure that your systems are protected and your security personnel are educated. The best place to start identifying potential vulnerabilities is to understand key differences between IPv6 and IPv4 that affect security. Here are seven areas to know:</p> <P> <b>Neighbor Discovery Protocol:</b> NDP is essential to the operation of IPv6. It replaces several functions performed by separate protocols under IPv4, such as router discovery and redirects, and enables new functions for IPv6. However, NDP also presents a range of exploits for an attacker who can gain local access to a subnet.</p> <P> <b>ICMPv6:</b> The ICMP messaging protocol is a favorite vector for denial-of-service and CPU attacks, and guarding against ICMP message floods is a fundamental security best practice. But IPv6 is more dependent on ICMP than is IPv4, so simply blocking all ICMP messages at security checkpoints will break some IPv6 functions. </p> <P> <b>Fragmentation:</b> Fragmentation attacks are another old favorite that might be given a new spin by IPv6. Unlike IPv4, IPv6 routers don't fragment packets. Instead, the spec requires the originating end system either to test the maximum transmission units along a path to a destination and fragment accordingly or to fragment all packets exceeding 1,280 bytes--the smallest MTU an IPv6 interface is allowed to support.</p> <P> <b>Extension Headers:</b> IPv6 economizes its default header by eliminating optional fields. Instead, when an optional capability, such as fragmentation, source routing, encryption, or authentication is required, an applicable extension header is inserted between the default IPv6 header and the packet payload. Unfortunately, attackers can abuse extension headers in a number of ways, as we discuss in our full report.</p> <P> <div style="margin:0; padding:0 0 10px 10px; width:250px; float:right;"> <div style="border:1px solid #000000; padding:0;"> <div style="margin:0; padding:4px; font-size:1.4em; text-align:center; color:#ffffff; background-color:#000000;"> <strong>5 Key Considerations </strong> </div> <div style="margin:0; padding:4px; font-size:1.2em; text-align:center; color:#ffffff; background-color:#CC0000;"> <strong>For IPv6 Security</strong> </div> <div style="margin:0; padding:8px;"> Security involves more than firewalls and access control lists. Are all your IP systems ready for IPv6? How about your processes and people? Training is critical. <div style="margin:10px 0 10px 0; padding 0; border-bottom:solid 1px #666666;"></div> Some networking systems process IPv6 in software vs. hardware support for IPv4. Can you say CPU depletion attacks? <div style="margin:10px 0 10px 0; padding 0; border-bottom:solid 1px #666666;"></div> Many modern operating systems enable IPv6 by default. Do you know where all instances of these operating systems reside? <div style="margin:10px 0 10px 0; padding 0; border-bottom:solid 1px #666666;"></div> IPv6 standards and code are new, and new code is buggy. There have been security holes found, and more will come to light as v6 systems are put into production. Monitor and patch. &#9;&#9;&#9;<div style="margin:10px 0 10px 0; padding 0; border-bottom:solid 1px #666666;"></div> Black hats are studying IPv6 closely, looking for new attack vectors. Your security team needs to do the same </div> </div> </div> <P> <b>Flow Labels:</b> The Flow Label field is the only field in the default IPv6 header that has no analogous function in the IPv4 header. It's intended to enable efficient processing of microflows for improved service classification, but mainstream network systems do not yet use it. An intentionally miswritten Flow Label value could create a covert channel.</p> <P> <b>Automatic Tunnels:</b> Automatic tunneling mechanisms, such as 6to4 and Teredo, are supported by most host operating systems. They're used to create IPv6 connectivity over an IPv4-only network or segment, but they may also be used to create an unsecured channel, and most lack a means of authentication.</p> <P> <b>Large-Scale NAT:</b> Also called Carrier-Grade NAT, or CGN, LSN isn't a part of the IPv6 specification, but it is often associated with IPv6 transitional architectures. LSN setups allow network operators to centralize their public IPv4 address pools, thus extending their useful lives by multiplexing more IPv4 flows to each address. These centralized NATs--often single points of failure for tens of thousands of end systems--represent attractive targets for CPU or address pool depletion attacks.</p> <P><strong>Beyond Black Hats</strong></p> <P> Security goes beyond deflecting attacks. You must also guard against unintended side effects that can bring down portions of your network as effectively as any denial-of-service exploit. In the case of IPv6, there are two key nonmalicious threats to watch for.</p> <P> First, don't assume that because you achieve a given performance level from a network system running IPv4 you will realize the same performance when you add IPv6. A router that processes and forwards IPv4 packets in hardware might process IPv6 packets in software. A firewall's CPU might slow significantly when it processes IPv6, particularly if extension headers are involved. The other major nonmalicious threat to your IPv6 network is lack of training. From the very different address format to the key protocol differences between IPv4 and IPv6, your network operators and engineers need to be prepared. </p> <P> <strong>Watch For Bugs</strong></p> <P> IPv6 implementations almost always mean running code that hasn't yet undergone production vetting. A router vendor might have supported OSPFv2 for almost 20 years, but OSPFv3 for IPv6? It's new--and very likely buggy. Did your firewall vendor release IPv6 support only within the past couple of years--or even months? Then there are surprises awaiting you. This isn't an indictment of sloppy development work; we all depend on extensive production deployments to reveal problems. Yet worldwide, IPv6 is still in its early stages of use, meaning even IPv6 implementations that were written years ago may just be getting their first large-scale field tests.</p> <P> Even standards bodies are occasionally guilty of overlooking security risks. Two infamous examples of early oversights in IETF specifications were an IPv6 source routing vulnerability that opened the possibility of amplification attacks and firewall bypasses, and an ICMPv6 vulnerability that allowed ping-pong attacks on point-to-point links. Both vulnerabilities were well known in IPv4 and had long been corrected in earlier standards, but were simply overlooked in initial IPv6 specifications. And while these mistakes have been corrected in newer versions of the protocol, you need to assume that some operating systems in your network incorporate the older, problematic standards--which brings us right back to awareness, communication, and testing. </p> <P> <strong>New Opportunities</strong></p> <P> <div style="margin:0; padding:0 0 10px 10px; width:260px; float:right;"> <div style="border:1px solid #000000; padding:0;"> <div style="margin:0; padding:4px; font-size:1.4em; text-align:center; color:#ffffff; background-color:#000000;"> <strong>5 Key Policy Changes </strong> </div> <div style="margin:0; padding:4px; font-size:1.2em; text-align:center; color:#ffffff; background-color:#CC0000;"> <strong> in IPv6</strong> </div> <div style="margin:0; padding:8px;"> Extension headers <div style="margin:10px 0 10px 0; padding 0; border-bottom:solid 1px #666666;"></div> Neighbor Discovery Protocol <div style="margin:10px 0 10px 0; padding 0; border-bottom:solid 1px #666666;"></div> Heavier dependencey on ICMP <div style="margin:10px 0 10px 0; padding 0; border-bottom:solid 1px #666666;"></div> Flow labels &#9;&#9;&#9;<div style="margin:10px 0 10px 0; padding 0; border-bottom:solid 1px #666666;"></div> No NAT66--get over it </div> </div> </div> <P> The transition from IPv4 to IPv6 is a major evolution. It's also unavoidable, unless retirement is in your near-term plans. And although IPv6 presents some new security challenges, none of them are insurmountable given the right preparation. In fact, smart CIOs are looking at the transition as an opportunity. Are your security practices and systems all that you want them to be? If not, an IPv6 deployment can be the perfect time to assess your situation and improve or replace your current security architecture and practices.</p> <P> The transition to IPv6 is also an opportunity for us as a community to reconsider the way security is practiced. Are firewalls and intrusion detection systems sufficient protection? All of the 1,000-plus respondents to our latest InformationWeek Analytics Strategic Security Survey use firewalls, and 93% have intrusion detection/prevention systems in place. But walls have never truly protected us--maybe it's time to consider a new outlook, like moving to a model of end-to-end authentication and encryption, creating "zones of protection" around individual hosts and servers, and adding improved algorithms for threat analysis and interdiction. And maybe IPv6 can help us get there.</p> <P> <em>Jeff Doyle is president of Jeff Doyle and Associates. He specializes in IP routing protocols, MPLS, and IPv6 and has worked globally with large IP service provider networks. </em> </P> <P> <!-- KINDLE EXCLUDE --> <center> <div id="printfeaturePDFpromo"><div class="printfeaturePDFCover"><a href="http://analytics.informationweek.com/abstract/83/7294/IT-Business-Strategy/informationweek-full-issue-may-30-2011.html"><img src="http://twimgs.com/infoweek/1301/smallcov.jpg" alt="InformationWeek: May 30, 2011 Issue" title="InformationWeek: May 30, 2011 Issue" /></a></div> <div class="printfeaturePDFCopy"><strong><a href="http://analytics.informationweek.com/abstract/83/7294/IT-Business-Strategy/informationweek-full-issue-may-30-2011.html">Download a free PDF of <nobr><em>InformationWeek</em> magazine</nobr></a><br /> (registration required)</strong></div> <div class="clearBoth"></div> </div> </center> <!-- /KINDLE EXCLUDE --> <P>2011-04-28T08:00:00ZWe've known for almost 20 years that IPv4 addresses were a dwindling resource. Yet here we are.http://www.informationweek.com/news/229402282?cid=SBX_iwk_related_commentary_Business_telecomSince around 2000, analysts have pointed to the accelerating "everything over IP" trend and warned that we had better get ready for IPv6. So why, 11 years later, are we are still nagging many networking vendors to please, just add IPv6 support to their products already? <P> Since 2006 we've known that 2011 would be the year IPv4 addresses would be depleted, yet so many of us were caught flat-footed by the announcement that--surprise!--the very last IPv4 addresses had been handed out to the regional registries. <P> How did this happen? It's really not all that surprising. We tend to prioritize our network upgrades around the most urgent needs, and IPv6 has always seemed like something that could be put off just a year or two longer while we focus our budgets and engineering resources on that new MPLS core or those new data center switches or whatever else appears to present a more tangible return on investment. <P> So does IPv6 <em>finally</em> have the requisite urgency to move at least close to the top of our priority lists? Yes, in the service provider arena, where the business case is straightforward: We are running out of an essential network resource (addresses) and must do something about it. But in most of the enterprises and content providers I work with, that urgency has not yet hit home. Internally, most enterprise networks can continue to grow using private IPv4 addresses behind IPv4-to-IPv6 Network Address Translation (<a href="http://www.nanog.org/meetings/nanog50/presentations/Wednesday/NANOG50.Talk65.weil-SP%20NAT44.pdf">NAT44</a>), and externally accessible services do not grow quickly enough for IPv4 address depletion to present a near-term resource shortage. <P> Nevertheless, as I discussed in a recent <a href="http://analytics.informationweek.com/abstract/6/5296/Data-Center/best-practices-ipv6-transition.html">InformationWeek Analytics report</a>, externally accessible services are behind the business case for IPv6 in enterprise and service provider networks. Service providers, particularly broadband service providers, will soon be provisioning thousands of new home and small office customers on IPv6. <P> There are three alternatives for those IPv6 customers to reach online content and services: <P> -- The broadband service provider will provide a centralized NAT (<a href="http://en.wikipedia.org/wiki/Carrier_Grade_NAT">Large-Scale NAT</a>, or LSN) system that allows the user to reach IPv4 content using private IPv4 addresses. <P> -- The enterprise will stand up IPv6 proxies in front of their IPv4-only servers. <P> -- The services can be made accessible natively by IPv6. <P> Lab testing and some field experience have revealed that LSN and IPv6 proxies will adversely affect or completely break some applications. If your customers experience problems with your online services, they are not going to blame their service providers. They are going to blame you. <P> Therefore, the case for IPv6 in the enterprise and content provider arena is not the continuation of addressing resources, but the continuation of customer quality of experience. You can hope for the best with service provider LSNs (completely out of your control) or IPv6 proxies, or you can bypass those temporary workarounds completely by making your services natively accessible via IPv6. <P> I know what you're thinking--you're not feeling pressure from large groups of IPv6 users yet, so there is the temptation, as usual, to put off IPv6 deployment in your edge services for another year or two. <P> That would be a mistake. Every IPv6 project I have been involved with has been more complex than originally expected, and most of that complexity has stemmed from the need to identify and test applications in an IPv6 environment. Your IPv6 planning should begin by determining what applications, content, and services must be externally accessed. Are those services IPv6 ready? How do you certify them? <P> Who's responsible for modifying applications that don't behave well over IPv6? What are the criteria for determining whether to modify a noncompliant application or to replace it? <P> And don't forget your telecommuting employees, who must access internal services over VPNs. Will your systems be ready when their home broadband providers begin rolling out IPv6? <P> Sure, you can find plenty of reasons to put off IPv6 planning until next year, or to implement a workaround that appears to get you off the hook for the near term. But IPv6 is inevitable. Avoidance now <em>will</em> eventually cost you more money, in lost customers and lost productivity, than it will cost you to begin IPv6 implementation now. Trust me on this. <P> Learn more at the <a href="http://www.interop.com/lasvegas/conference/information-week-analytics-live.php">InformationWeek Analytics Live</a> session at Interop Las Vegas on Thursday, May 12, called "IPv6: Moving to the Next Generation Internet." <P> <em>Jeff Doyle has designed or assisted in the design of large-scale IP service provider networks throughout North America, Europe, Japan, Korea, Singapore, and the People's Republic of China. He is one of the founders of the Rocky Mountain IPv6 Task Force and is an IPv6 Forum Fellow.</em> <P> <!-- KINDLE EXCLUDE --> <!-- RECOMMENDED READING --> <a name="recommended"></a> <center> <div id="recommendedReadingPromo"> <div class="recommendedReadingPromoHeader"><strong>Recommended Reading:</strong></div> <ul class="normalUL"> <li><a href="http://www.informationweek.com/news/interop/">Interop Special Report</a></li> <li><a href="http://www.informationweek.com/news/security/vulnerabilities/229401525">Windows IPv4 Networks Vulnerable To IPv6 Attack</a></li> <li><a href="http://www.informationweek.com/news/government/policy/229401269">NTIA Tool Helps IPv6 Transition</a></li> <li><a href="http://www.informationweek.com/news/infrastructure/ipv6/229218783">IPv6: Four Steps to Take Now</a></li> <li><a href="http://www.informationweek.com/news/internet/policy/229201157">Internet Runs Out Of IP Addresses</a></li> <li class="last-li"><a href="http://www.informationweek.com/news/government/enterprise-architecture/227500974">White House Sets IPv6 Transition Deadlines</a></li> </ul> </div> </center><br clear="all"> <!-- / RECOMMENDED READING --> <!-- /KINDLE EXCLUDE -->