IPv6: Will matter to the enterprise in five years

Routing guru Jeff Doyle said there’s no need to move to IPv6 now, offered design tips for OSPF nets, and discussed Layer 2 vs. Layer 3 routing among the many networking secrets he shared with attendees of his live Network World chat.

Moderator-Julie: Welcome to Network World Chats. Our guest today is Jeff Doyle, celebrity author, Cisco Subnet blogger and networking guru. He has come prepared to answer your questions on all things routing.

Jeff_Doyle: Welcome, everyone! In most every technical meeting I assume I’m the dumbest person in the room, and discussions like this are a great opportunity for me to prove my assumptions correct. Nevertheless, I’ll do my best to answer any of your questions. But let me start with a funny little story.  I’m in my home office right now, and have had a problem lately with rabbits getting into the office (don’t ask). Consequently the office is now my dog Reggie’s favorite hangout – several bunnies have met a fast but slightly gruesome end. Hopefully we won’t have any “Wild Kingdom” events while in the middle of the chat, but Reggie the mighty hunter is sitting nearby with a keen eye on the utility opening… With that as background, let’s get to it.

IPv6 and IPv4 

Moderator-Keith: We have a pretty long list of pre-submitted questions that people sent us via the Network World Chat page earlier this week. So while Jeff types answers to your live questions, we’ll be posting the pre-submitted questions/answers throughout the chat. Here’s the first one:

So, besides the fact that service providers want people to go to IPv6, why should an enterprise deploy it now? If not now, when should it be deployed?  Any examples of large enterprises using it in the business world and what kinds of problems did they have to solve before it worked flawlessly?

Jeff_Doyle: Many of my fellow IPv6 advocates hate me when I say it, but I don’t think there is much motivation for enterprises to adopt IPv6 anytime soon. IPv6 is important for service providers and any other entities that burn through public IP addresses on a regular basis. All but the largest enterprises don’t so that; they can get along just fine behind NAT.

Enterprise interest will rise as they do need new public addresses and they find that the only thing they can get from their provider is IPv6. When it gets to be a bigger hassle to do IPv6 on the outside of a NAT and IPv4 on the inside, they’ll start to adopt IPv6. My prediction is that this will happen somewhere in the 2012 – 2015 timeframe.

Moderator-Keith: PRE-SUBMITTED QUESTION: Do you have any recommendations for transitioning to IPv6? Are tunnels or dual stacks better?

Jeff_Doyle: Dual stacks would be better; much simpler, and allow the transition to be driven primarily by DNS. Unfortunately, dual stack assumes that you have both IPv4 and IPv6 addresses. At RIPE55 in Amsterdam a couple of weeks ago, Geoff Huston made the very good point that transition to IPv6 should have been completed before IPv4 runs out, so the transition could revolve around dual stacking. Obviously that isn’t going to happen, so tunneling is going to be a key implementation tool. I’m also starting to look more favorably on translators like NAT-PT than I used to; not because I like them, but because they are starting to look inevitable.

Silvia: I have a customer in Italy that has a spaghetti IPv4 network. He is thinking about implementing IPv6 as far as possible instead of fixing the spaghetti network. How would you see the chances for this approach? Is it too early or doable?

Jeff_Doyle: The outlook for him doing this successfully is about as grim as the outlook for those rabbits sneaking into my office. He needs to untangle the spaghetti and get his network under control before adding IPv6, or he will just multiply the complexity. A standard recommendation I make when getting ready for IPv6 is a network inventory and an impact study to ensure the implementation doesn’t push the network over the edge.

Moderator-Keith: PRE-SUBMITTED QUESTION: Do software coders need to understand IPv6? What are some of the things they need to know?

Jeff_Doyle: Absolutely. I have a few clients right now who have brought me in to help their developers know what IPv6 standards are important and which are not (within the context of these particular clients’ product lines). Which is interesting, because I’m not a coder. For writing the code itself, I always direct developers to the two volumes written by Qing Li, Jinmei Tatuya, and Keiichi Shima, “IPv6 [Core and Advanced] Protocols Implementation.”

WillJ: Are existing Internet routers capable of handling the millions of IPv6 networks/routes? Can/will the carriers work together to summarize each others’ networks to reduce the number of IPv6 networks on the Internet?

Jeff_Doyle: Right now only the most expensive core routers can handle scales of a million or more entries; that’s a big concern. On the one hand the big vendors like Cisco and Juniper express confidence that they can keep up with demand, and past history has proven that out pretty well. But on the other hand at some point you hit the limitations of physics; different kinds of hardware, different kinds of protocols, and different kinds of algorithms are going to be needed. I think it was Tony Li that made the very good point that Moore’s Law doesn’t apply to the silicon used in routers: The commoditization necessary to control costs as capacities grow does not exist in the core router industry.  If you’re interested, some of the more forward-thinking IRTF working groups like the Routing Research Group (RRG) are worth your time to check out.

WillJ: If you were building a new regional network (multiple states) would you be using IPv6 out of the box? Which vendors have the best core routers for a regional network?

Jeff_Dolye: I would insure that IPv6 capability is there, by all means, and if there is a compelling reason I would enable it along with IPv4. But if you’re asking would I build an IPv6-only network, the answer is no. With apologies to other router vendors, Cisco and Juniper pretty much own the core market.

Moderator-Keith: PRE-SUBMITTED QUESTION: I understand what you are saying about enterprises not being interested in IPv6 yet, but even with service providers, what do you see as obstacles to IPv6?

Jeff_Doyle: SPs are quickly moving beyond questioning whether IPv6 is going to be needed and toward practical, reality-based implementation. The big challenge here is that there remains a tremendous number of holes in IPv6 support: Network management, security (try finding an IPv6-capable IDS!), most backoffice applications. What vendors claim and what they can actually deliver is, in a very many cases, two different things. But that’s changing. SPs are pressuring their vendors because their IPv6 operations need to be completely equitable with their IPv4 operations, with as few “paradigm shifts” as possible, and that capability just isn’t there yet.

Silvia: How many organizations do you know that have implemented IPv6 at least partially or gone dual-stack?

Jeff_Doyle: Most ISPs now have implementation plans in the works, although few are at the point of being able to offer IPv6 access on a wide scale (as in IPv6 to the home or small office). On the enterprise side, very few are implementing IPv6 but don’t have any practical need to.

Moderator-Keith: PRE-SUBMITTED QUESTION: You say that IPv4 addresses will run out in 2010 or 2011. What happens then, to all those people who aren’t ready for it?

Jeff_Doyle: Not much, really. Keep in mind that nothing is going to stop working when the last IPv4 address is given out. A bit like Y2K (but with far less potential for catastrophe), the network operators whose business depends on having a steady supply of public IP addresses already recognize the threat and are preparing for it.

Moderator-Keith: PRE-SUBMITTED QUESTION: You have written about IPv4 depletion and predictions about when that will happen. When do you think we will see an “IPv6 only” world?

Jeff_Doyle: There is, and always has been, a focus on v4/v6 interoperability and coexistence. But the reality is that no one wants the complications of running two protocols in their network. As a result, I think that as IPv6 takes off there will be a substantial OPEX incentive to get rid of IPv4. Saying that is still a bit controversial, but my opinion is that IPv4 will cease to exist in most networks somewhere between 2015 and 2020. Let’s schedule another chat on March 3, 2020 and see whether I was right 🙂

Joshi Rivera: Hello Jeff, regards from Mexico. Just a question, I’m in charge of a small network and the plan is to re-plan a new medium network with remote offices. Do you recommend IPv6 to deploy, and Cisco equipment as core and access equipment?

Jeff_Doyle: A bit like a previous answer, I would ensure that what you deploy is IPv6 capable, but for the present you still need IPv4. You have lots of options at the distribution and access layers beyond Cisco, but I do think what you get there is equipment that most everyone knows how to operate and a strong support network behind it.

BillB28: What will be the thing that most people will be talking about in 2008 regarding routing?

Jeff_Doyle: IPv6, in terms of practical deployment experience and best practices.

Niharika: 2015 and 2020 seems a long time away. I started preparing and reading about IPv6 now to enhance my position. But I think it’s too early. Am I wasting my time?

Jeff_Doyle: Depends on whether you are in the enterprise or the service provider space. If you are in a SP, you should have been planning two years or more ago. If you are in the enterprise space, you probably have another five years or so before you need to worry about it, although it certainly helps to be thinking about it now.

BillB28: Whatever happened to IPv5? Why are we jumping from IPv4 to IPv6?

Jeff_Doyle: IPv5 was designated to an experimental protocol that was never deployed. So “6” was the next number on the list of available version labels.

OSPF, routing, switching

Moderator-Keith: PRE-SUBMITTED QUESTION: What kinds of limitations does OSPF have with large hub and spoke networks?

Jeff_Doyle: Adjacencies are the limitation here, but (assuming you have a beefy enough hub router) it only starts to become a limitation when the adjacencies start moving past the many tens into the hundreds. A sane design probably isn’t going to do this, plus if it’s a straightforward hub-and-spoke topology you can (and probably should) use a lot of static default routes and get away from an IGP on the spokes.

Moderator-Keith: PRE-SUBMITTED QUESTION: You’ve talked about oddball multi-area OSPF topologies in your blog. In what circumstance is the traditional daisy design problematic?

Jeff_Doyle: The oddball topologies I’ve talked about are primarily thought exercises, not something you should actually do on a production network. The “daisy” model is something every multi-area OSPF topology should look like; the very nature of the daisy model means areas are being used, so the topology can scale hugely. This assumes, of course, you’re not doing anything really dumb like a poorly interconnected area 0 or 50,000 areas with 2 routers each. 🙂

RoutetoMe: I am currently managing a network with multiple site-to-site VPN links and we want to do away with a lot of the static routing and incorporate OSPF into the mix… is it wise to think of the remote offices as OSPF areas (the locations are dispersed around the world) and make our main site Area 0?

Jeff_Doyle: Hard to answer without seeing your topology, but I personally am a fan of big single OSPF areas: I’ve seen too many networks with tons of unnecessary areas, complicating operations. But areas certainly have their place; if you are worldwide, doing areas by region might make sense. How’s that for an ambivalent answer?

Router-gal: Why is it that routers are used in the core layer to network, can’t switches be used?

Jeff_Doyle: Great question, and one that has been asked for years. The chief architects of one of the world’s largest Internet carriers told me years ago that if they could get rid of all the routers in their core and build the whole thing with stacks of cheap, dumb, fast switches, they would. The reason that isn’t happening is that you still need some intelligence in the core for security, CoS [class of service] and such. The popularity of MPLS is a reflection of this: Moving most intelligence to the edge and leaving the core to do (mostly) just high-speed forwarding.

RoutetoMe: So getting back to your expression of being a fan of single large areas vs. having multiple unnecessary areas. How exactly would you describe this? Is it a total number of routers and routes that would in the end determine how many areas in your networks?

Jeff_Doyle: Actually, the number of routers (the old “rule of thumb”) in an area is a bit irrelevant; you can have hundreds; I’ve seen a thousand or more in a single area with no problems. The real issue is the number of links, the stability of the links, and the number of neighbor adjacencies.

Robert: Is using a Layer-3 protocol such as OSPF/ECMP to provide alternate paths and dynamic rerouting a reasonable approach in a large enterprise network? Or is a Layer-2 alternative a better approach?

Jeff_Doyle: My opinion is that Layer 3 routing is far better – really the only practical – means of dynamic redundancy in a network.

Security and voice

Dsingh: With voice being taken for granted as a key app over the network, the heat is on to make sure that packets get through with low latency. I’ve heard SP say and some vendors push for the fact that QoS is only a stop gap and the key is to add enough bandwidth in the core. Isn’t that really pushing the problem to someone else’s domain? I would have thought that queuing to smooth out peaks would be the solution, but then I keep hearing about queues getting synched and Armageddon. What are your thoughts about the QoS vs. Bandwidth debate?

Jeff_Doyle: I absolutely agree that queuing is not a long-term solution. Queuing is simply a means of, when a link is congested and “something” must be dropped, giving you control over “what” gets dropped. It’s no substitute for sufficient bandwidth. However, good traffic engineering practices are an intermediate solution that ensures you are efficiently using all of your available bandwidth before going to the expense of adding more.

Robert: I believe VoIP will push the demand to have highly available enterprise networks. What architecture directions do you recommend to build a large, reliable enterprise network?

Jeff_Doyle: Architecturally, there’s not much new. More importantly, and newer, is how you manage the network for availability. Being able to dynamically reroute traffic, change queuing, and understand what the loads and flows in your network are doing in real time. That’s a huge challenge.

Dsingh: Jeff, with all the hoopla regarding L2 VPNs and pseudowire. Are there actual successful implementations that allow applications that make assumptions about LAN-like access to work across the underlying WAN?

Jeff_Doyle: Sure, L2 point-to-point service has been the quite successful for many providers. And gaining strength quickly is VPLS, which is really just point-to-multipoint L2 VPNs in a fancy dress.

Router-gal: I have heard flowspec mentioned lately. Can you talk a little about that?

Jeff_Doyle: FlowSpec is a means of quickly pushing BGP policies out to the edge of your network to reactively block DDoS traffic. It’s becoming more and more in use by service providers and large enterprises using BGP. While we don’t have the room or time to go into the details of how it works here, that’s a great idea for a blog post! I’ll try to write something on it in the next month or so.

Moderator-Keith: PRE-SUBMITTED QUESTION: You say that attackers are most likely to go after EBGP. What needs to be done to ensure that they won’t succeed?

Jeff_Doyle: Authentication with separate passwords for each external neighbor is absolutely critical. The Cisco TTL hack is useful, too. But the reality is that these things can themselves be attacked. A few proposals are out there for secure BGP peering; running the peering sessions over encrypted tunnels would be tremendously useful. I plan to do a column or two on the proposals sometime in the near future, so stay tuned…

Karthik: Why do we have two addresses to identify a host-MAC address and IP address? Can we do away with one of them? Is it an OSI design flaw to have two different addresses to identify any host anywhere on the network?

Jeff_Doyle: First the reality: MAC identifies hosts on local links, whereas IP identifies hosts globally (across routers). Having said that, there is a strange dual function in IP addresses, both locator and identifier. The identifier should probably be something different, like a MAC address. Note that in IPv6, the addresses are more like that; the MAC address can be incorporated into the identifier (Interface-ID) part. That should make Bob Metcalfe happy.

Books, troubleshooting and other recommendations

JFDallaire: Alright, I don’t know if it’s appropriate, but here it comes. I would like to know how to pinpoint a high CPU usage by the IP Input process that occurs daily around the same time. I read the “Troubleshooting High CPU Utilization in IP Input Process” on the Cisco website about that, but it didn’t really help.

Jeff_Doyle: Certainly an appropriate question, but in reality if you’ve read the Cisco note you probably know more than me at the moment. I pretty much just work through the sch proc CPU outputs.

Ram: Like many other organizations we have a very large number of routers, switches and other equipment which is managed and maintained by different groups. We also supply very different services to different users accessing multiple types of mainframes and servers. We have gotten to the point where no one can figure out where one VPN starts and another ends, or what path a particular connection is taking, making troubleshooting a nightmare. Is there any particular product you could recommend that would allow us to manage or at least trace all the different connections?

Jeff_Doyle: There are several products I can recommend, although I don’t know if it’s appropriate in this venue; I would likely leave out some good ones. The bigger issue is exactly what you cite; as any network grows in complexity, you need tools that provide insight into what it’s really doing. That often (usually) involves more than just a single product.

Router-gal: So, you said you didn’t want to recommend specific products for tracing connections in large, complex networks. What kinds of product features are out there that does that – any standards?

Jeff_Doyle: Graphical depictions of the network are important. Anything that allows you to visualize link loads and application flows. You also want to ensure that the monitoring doesn’t itself affect the network (loading down CPUs with queries and the such). Netflow is an example of something that gives you good visibility piping into a monitoring product, but can negatively impact your network if you use it too aggressively.

Niharika: If I had to focus on one main routing protocols to study, what should it be?Jeff_Doyle: Definitely OSFP. RIP these days stands for “Rest in Peace.” EIGRP is the second protocol to study. If you are going into an service provider environment, however, BGP and MPLS are the protocols to learn. In fact, good MPLS knowledge is quite marketable right now.

Adamf533: Jeff, what would you recommend to someone who has been R&S focused for 10-plus years to move towards (specializations)? Storage, voice, etc.?

Jeff_Doyle: Voice is in big demand right now, as is security. And both, I think, are going to grow much more; so lots of opportunities in that area.

CarlC: Along the same lines, as someone who has been in the business a long time, but never specialized: Recommendations on good books or techniques to “fill in the gaps” and “smooth the rough spots”? Voice and security are definitely the way I am pointing.

Jeff_Doyle: Well, I can plug the “books” page on my Web site (www.doyleassociates.net), which below the self-promoting part is a list of my own favorites. Almost all the books on the list are written by people I know and respect, so I’m comfortable recommending them. 

BillB28: Any plans for a Routing TCP/IP Volume 3?

Jeff_Doyle: That’s a timely question. I would like to do that, and proposed a Volume III to Cisco Press about a year ago. I wanted the volume to focus on MPLS. Unfortunately my editors at Cisco Press tell me the market is flooded with MPLS books and they didn’t feel it would sell. I was (and am) thinking of writing a post opening the question to my readers, as to what they would like to see in a Volume III. So let me do a preliminary question just on this chat: What topics would you like to see in a potential “Routing TCP/IP Volume III”?

Moderator_Julie: You can send Jeff ideas for Volume III by posting a comment to his blog.

Raul: Jeff, I came from the server management end of IT and was “forced” to take over the network infrastructure of the business. We are a Nortel shop internally and Cisco externally. Could you recommend one or two good books on corporate routing protocols, i.e., VLANs, Trunking, RIP, OSPF, Spanning Tree, LACP, VRRP, BGP, EAPOL & SNMP/MIBs & RMON, for a quick learner who can digest “logical” concepts readily?

Jeff_Doyle: There’s a good Cisco Press book on VLANs and related topics, although I hate to say I can’t remember the title at the moment. E-mail me offline and I’ll look it up. For routing, I have to recommend my own books.

Niharika: How can I learn more about IPv6? Which books and protocols do you recommend?

Jeff_Doyle: I highly recommend either Merike Kaeo’s book Designing Network Security, Second Edition, or Marc Blanchet’s book, Migrating to IPv6: A Practical Guide to Implementing IPv6 in Mobile and Fixed Networks. Both are excellent introductions.

Raul: What is the current state of NAC and who are the “real” players? There are so many variants it’s hard to get the “big picture.”

Moderator-Julie: Good question. We had a chat on this topic a short time ago by security expert Joel Snyder. So I’m going to refer you to that chat transcript. Here’s also a link to a product test that Network World did on NAC. Hope that helps.

BillB28: How long will Cisco remain as the dominating force in routing?

Jeff_Doyle: Oooh, provocative. I’m not selling my Cisco stock anytime soon.

Moderator-Julie: So thanks for coming today! Remember to keep reading Jeff’s blog on the Cisco Subnet site. Mark your calendars for Nov. 13, 2 p.m. EST, for LAN switch security: What hackers know about your switches with Christopher Paggen, from Cisco. Then join us on Wednesday, Nov. 28, 2 p.m. EST, for Greatest Techno-Gifts of the Season, with Cool Tools columnist Keith Shaw.

Jeff_Doyle: Thanks everyone for attending! And certainly submit any more questions you have to me at my blog; always looking for good topics!