Archive for July, 2011

07/27/2011

The Perils of a Hasty IPv6 Deployment

by Jeff Loughridge

If World IPv6 Day and other recent IPv6 publicity have convinced you that your network needs IPv6 now, I offer this advice– carefully plan your IPv6 deployment. Many of us have experienced the thrill of an exciting gift requiring assembly and quickly attempted to put it together without reading the instructions. Does this ever work out well? Rarely. The same holds true for deploying IPv6. The perils of rushing deployment are many. Here are a few that I’ve encountered.

Addressing – You are likely to regret your addressing plan if sufficient thought isn’t put into its creation. Develop a plan for addressing that fits the current and future needs of the network. The drivers that led us to skimp on IPv4 addresses no longer apply. I recommend encoding POP or geography into the addresses for troubleshooting. There are enough bits in IPv6 that you can even embed service identifying information (e.g.,  VoIP, content).  Use static addresses on all router interfaces. Addresses obtained via stateless address autoconfiguration (SLAAC) do not belong on routers.

Infrastructure Protection– Did you remember to lock down your routers from unwanted IPv6 logins and DoS attacks aimed at the control plane? I’ve witnessed IPv6 deployments in which operator access was restricted for IPv4 addresses but completely open for IPv6. If your router vendor doesn’t offer IPv6 awareness for control plane protection/policing, interface access lists, and unicast reverse path check (uRPF), demand those features. The security challenges that IPv6 ushers in must not be overlooked.

Reverse DNS – Create the PTR records for your IPv6 address space on your DNS server. In many cases, converting in-addr.arpa zones to IP6.arpa zones is not difficult. Implement reverse DNS so that your network operations staff doesn’t have to guess at what routers are in the path of traceroute output. Depending on your IPv6 addressing scheme, the guesswork could be even more difficult with IPv6.

Distributing DNS server info – Assuming that users have an IPv4 stack for IPv6 DNS look up is a short-sighted design decision. A solid IPv6 deployment should include an IPv6 DNS server. Use DHCPv6 to distribute DNS server info. You may want to assign the well-known DNS addresses–fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 and fec0:000:0000:ffff::3–as secondary addresses on your DNS server. Note that hese addresses fall into the site-local range, which has been deprecated. The effort involved in using them is minimal, and Windows 7 supports their use.

I’m certain that others can contribute to this list. We don’t have the years of widespread operational experience with IPv6 that we’ve accumulated with IPv4. We’ll get to that point quickly.

Advertisements
Tags: , ,
07/22/2011

Misunderstandings About IPv6

by Jeff Loughridge

IPv6 has been defined for over decade yet the protocol lacks the years of operational experience of its predecessor. IPv4 is well understood in terms of behavior, troubleshooting, and best practices. That IPv6 will reach operational parity is a given once it becomes the dominant IP protocol. In the meantime, I expect that misunderstandings about IPv6 will continue to exist.

IPv6 will not engender an improved Internet experience. If the transition is highly successful, the average Internet user will not notice. He or she will continue to interact with the Internet in the same way. IPv6 equals more address space, which will allow network operators to uniquely identify more endpoints. You could argue that the benefit to the end user is indirect; the sheer number of IP-enabled devices–gaming consoles, TVs, tablets, smart phones–that will be online in the coming years could not happen without more addresses. From the perspective of network engineers, certain components of IPv6 such as Neighbor Discovery could be viewed as improvements upon the equivalent IPv4 functions. Overall, I do not believe that maintaining an IPv6 network will be easier. During the transition period, the duties of network engineers will be very challenging.

Let’s dispel the myth that IPv6 has better QoS mechanisms than IPv4. There is no truth in this. Around the turn of the century, some people seemed convinced that QoS manufactures bandwidth. Unfortunately, no such bandwidth fairy existed then, and IPv6 does not change the QoS landscape.

Misunderstanding about IPv6 and security are particularly dangerous. Although IPsec is mandated in IPv6 RFCs and better integrated in the header, IPsec can’t be used for all traffic flows. IPsec in IPv4 and IPv6 are roughly equivalent in terms of usage. IPv6 introduces a new attack vector for dual stack networks. Creating a like-for-like security policy for the two protocols is not sufficient. There are mechanisms in IPv6 that do not have exact parallels in IPv4 and vice versa.

The misunderstanding that inspired this post falls in the security area. I was using the nmap security tool to experiment with an IPv6 stack on a virtual Ubuntu server. The IPv6 functionality is very limited in nmap. I had to consult the web to figure out why certain features were failing. I came across the statement that nmap lacks the ability to scan IPv6 ranges (the developers report that this will be fixed by the end of summer 2011). What bothered me was a comment from an nmap user that scanning IPv6 ranges would less than useful since IPv6 uses EUI-64 to create IPv6 addresses. This logic is debatable even if all IPv6 nodes used stateless autoconfiguration (SLAAC). ISP backbones are an example where SLAAC is not used (let’s hope not at least). Some providers derive IPv6 address by mapping the existing 32-bit IPv4 address into a /96. Others manually define IPv6 using other techniques. The use of DHCPv6 on LANs is another reason why crackers will scan IPv6 address ranges.

There many other misunderstandings about IPv6 that are covered in article such as Earl Carter’s IPv6 myths post. For more on this subject, read his article and others on the web.

Tags: , ,
07/15/2011

An Acid-Test for Service Provider Routers

by Jeff Loughridge

Business school majors learn that an acid-test ratio measures a company’s ability to pay off immediate  liabilities without selling inventory. I’m using this post to suggest an acid-test for edge and core routers in service provider (SP) networks. The analogy isn’t perfect, but let’s follow the lead of  the Acid-3 HTML compatibility test and go with it.

If I’m involved in an SP (or SP-like networks such as the mobile packet core) router RFP, I can usually gauge the vendor’s ability to play in the SP space based on a small subset of necessary features. The following list is intentionally inexhaustive.

  • ISIS – The implementation of ISIS historically has been a barrier to entry into SP networks. While OSPF deployments vastly outnumber ISIS deployments overall, ISIS has its proponents in many engineers who have maintained large-scale SP networks. The movement to IPv6 will likely increase ISIS’s popularly since its use eliminates the need for two IGPs to carry IPv4 and IPv6 prefixes.
  • IPv4-IPv6 feature parity – In a previous post, I mentioned the cavalcade of “buts” in IPv6 feature support. Being very explicit in RFPs about IPv6 is vital. You don’t want to find out after purchase that control plane protection of the route processor does not support IPv6 or something similarly frustrating.
  • Two-stage commit – A vendor in 2011 that pitches a product without the ability to change configuration and then apply the new configuration is not serious about courting SP business.
  • Solid In-Service Software Upgrade (ISSU) and High Availability (HA) Story – When I joined a Tier 1 ISP in 1998, I heard the stories from the veterans about reloading routers during and day and upgrading code at night without supervision by using the “reload at” IOS command. Times have changed. Businesses’ reliance on IP and the Internet demands five nines reliability and fast convergence after a failure. Ten minutes of downtime for a software upgrade or software defect blows your five nines budget for the year on an edge device in the SP network. (Yes, I know how SPs play with definitions and averages, but we need to be serious with the vendors in laying out requirements for uptime in today’s IP networks).
  • /31s – Many provisioning systems for ISPs are set up to select and configure /31s for internal point-to-point interfaces to avoid the waste of two addresses when using /30s for point-to-point. Let’s hope for the day when we can implement IPv6-only and spend our time debating the best practice for numbering point-to-point links in IPv6.
Keep these items in mind the next time you are involved in selecting a new router. Even if you don’t maintain a Tier 1 ISP network now, you’ll likely find yourself dealing with scaling challenges as bandwidth utilization continues to rapidly increase.
Tags: , ,