Betting the Farm on IPv6

41366342

IPv6 seems to have taken a back seat to discussions about more marketing-friendly topics like software defined networking and the Internet of Things.  People have said that IPv6 is an integral part of these initiatives and any discussion of them implies IPv6 use.  Yet, as I look around at discussions about SDN host routes or NATed devices running home automation for washing machines and refrigerators, I wonder if people really understand the fundamental shift in thinking.

One area that I recently learned has been investing heavily in IPv6 is agriculture.  When people think of a farm, they tend to imagine someone in a field with a plow being pulled by a horse.  Or, in a more modern environment you might imagine a tractor pulling a huge disc plow across hundreds of acres of fallow land.  The reality of faming today is as far removed from the second example as the second example is from the first.

Farming In The East

Modern farmers embrace all kinds of technology to assist in providing maximum yields, both in the western world as well as the east.  The biggest strides in information technology assistance for farmers has been in East Asia.  Especially in China, a country that has to produce massive amounts of food to feed 1.3 billion people.

Chinese farmers have embraced technologies that allow them to increase productivity.  Think about how many tractors are necessary to cultivate the huge amount of land needed to grow food.  Each of those tractors now comes equipped with a GPS transmitter capable of relaying exact positioning.  This ensures the right land is being worked and the area is ideal for planting certain types of crops.  All that telemetry data needs to be accumulated somewhere in order to analyze and give recommendations.

Think also about livestock.  In the old days, people hired workers to ensure that livestock didn’t escape or wander away from the herd.  It was a process that was both time and labor intensive.  With modern technology, those same cattle can be tagged with a small GPS transmitter.  A system can poll each animal in a given interval to determine herd count and location.  Geofences can be erected to ensure that no animal moves outside of a safe area.  When that occurs, alarms can be sent to monitoring stations where a smaller number of farm hands can drive out and rescue the errant animal.

Those two examples alone show the power of integrating traditional agriculture with information technology.  However, an unstated problem does exist: Where are we going to get those addresses?  We joke about giving addresses to game consoles and television sets and how that’s depleting the global IPv4 pool.  What happens when I do the same to dairy farmer’s herd?  Even my uncle and his modest dairy years ago had around one hundred cattle in his herd.  What happens when your herd is bigger than a /24?

IPv6 Rides To The Rescue

China has already solved this problem.  They don’t have any more IPv4 prefixes available.  They have to connect their devices.  The only answer is IPv6.  Tractors can exist as IPv6 endpoints in the monitoring station.  They can be tracked globally via monitoring stations.  Farm workers and supervisors can determine where the unit is at any given time.  Maintenance information can be relayed back to the manufacturer to alert when a part is on the verge of failure.  Heavy equipment can stay in working condition longer and be used more efficiently with this type of tracking.

Livestock herds can be monitored for position to ensure they are not trespassing on another farmers land.  The same telemetry can be used to monitor vital statistics to discover when animals have become ill.  That allows the farm workers to isolate those animals to prevent the herd from contracting illness that will slow production or impact yields.  Keeping better track of these animals ensures they will be as productive as possible, whether that be in a dairy case or a butcher shop.


Tom’s Take

I grew up on a farm.  I have gathered eggs, bottle fed calves, and milked cows.  Two of my uncles owned dairies.  The biggest complaint that I’ve heard from them was the lack of information they had on their products.  Whether it be a wheat crop or a herd of dairy cattle, they always wanted to know more about their resources.  With IPv6, we can start connecting more and more things to the Internet to provide access to the data that’s been locked away for so long, inaccessible to the systems that can provide insight.  Advancing technology to the point where a tractor or a bull can have a 2001::/16 address is probably the safest bet a farmer will make in his entire career.

IPv4? That Will Cost You

ipvdollar

After my recent articles on Network Computing, I got an email from Fred Baker.  To say I was caught off guard was an understatement.  We proceeded to have a bit of back and forth about IPv6 deployment by enterprises.  Well, it was mostly me listening to Fred tell me what he sees in the real world.  I wrote about some of it over on Network Computing.

One thing that Fred mentioned in a paragraph got me thinking.  When I heard John Curran of ARIN speak at the Texas IPv6 Task Force meeting last December, he mentioned that the original plan for IPv6 (then IPng) deployment involved rolling it out in parallel with IPv4 slowly to ensure that we had all the kinks worked out before we ran out of IPv4 prefixes.  This was around the time the World Wide Web was starting to take off but before RFC 1918 and NAT extended the lifetime of IPv4.  Network engineers took a long hard look at the plans for IPv6 and rightfully concluded that it was more expensive to run IPv6 in conjunction with IPv4 and instead it was more time and cost effective to just keep running IPv4 until the day came that IPv6 transition was necessary.

You’ve probably heard me quote my old Intro to Database professor, Dr. Traci Carte.  One of my favorite lessons from her was “The only way to motivate people is by fear or by greed.”  Fred mentioned that an engineer at an ISP mentioned to him that he wanted to find a way to charge IPv4 costs back to the vendors.  This engineer wants to move to a pure IPv6 offering unless there is a protocol or service that requires IPv4.  In that case, he will be more than willing to enable it – for a cost.  That’s where the greed motivator comes into play.  Today, IPv6 is quickly becoming equivalent in cost to IPv4.  The increased complexity is balanced out by the lack of IPv4 prefixes.

What if we could unbalance the scales by increasing the cost of IPv4?  It doesn’t have to cost $1,000,000 per prefix.  But it does have to be a cost big enough to make people seriously question their use of IPv4.  Some protocols are never going to be ported to have IPv6 versions.  By making the cost of using them higher, ISPs and providers can force enterprises and small-to-medium enterprises (SMEs) to take a long hard look at why they are using a particular protocol and whether or not a new v6-enabled version would be a better use of resources.  In the end, cheaper complexity will win out over expensive ease.  The people in charge of the decisions don’t typically look at man-hours or support time.  They merely check the bottom line.  If that bottom line looks better with IPv6, then we all win in the end.

I know that some of you will say that this is a hair-brained idea.  I would counter with things like Carrier-Grade NAT (CGN).  CGN is an expensive, complicated solution that is guaranteed to break things, at least according to Verizon.  Why would you knowingly implement a hotfix to IPv4 knowing what will break simply to keep the status quo around for another year or two?  I would much rather invest the time and effort in a scaling solution that will be with us for another 10 years or more.  Yes, things my break by moving to IPv6.  But we can work those out through troubleshooting.  We know how things are supposed to work when everything is operating correctly.  Even in the best case CGN scenario we know a lot of things are going to break.  And end-to-end communications between nodes becomes one step further removed from the ideal.  If IPv4 continuance solutions are going to drain my time and effort they become as costly (or moreso) that implementing IPv6.  Again, those aren’t costs that are typically tracked by bean counters unless they are attached to a billable rate or to an opportunity cost of having good engineering talent unavailable for key projects.


Tom’s Take

Dr. Carte’s saying also included a final line about motivating people via a “well reasoned argument”.  As much as I love those, I think the time for reason is just about done.  We’ve cajoled and threatened all we can to convince people that the IPv4 sky has fallen.  I think maybe it’s time to start aiming for the pocketbook to get IPv6 moving.  While the numbers for IPv6 adoption are increasing, I’m afraid that if we rest on our laurels that there will be a plateau and eventually the momentum will be lost.  I would much rather spend my time scheming and planning to eradicate IPv4 through increased costs than I would trying to figure out how to make IPv4 coexist with IPv6 any longer.

IP Addresses in Entertainment

Fake IP

Every time I sit down to watch a TV show or movie and they mention computers or hacking, I get amused.  I know that I’m probably going to see some attempt to make computer hacking look cool or downright scary.  Whether it be highly stylized like Hackers or fairly accurate like the power plant hack in The Matrix Reloaded, there are always little details that get glossed over.  In many cases, one of these is the IP addressing of the systems themselves.  If the producers and writers of the film even choose to show an IP address on the screen, it’s usually so wrong that I laugh at a totally inappropriate moment of drama.

The practice of using fictitious numbering schemes for things in entertainment goes back several decades.  The first known instance of a movie using a fake number for something was in Panic in Year Zero back in 1962.  For the first time, the writers used a fictitious phone number starting with 555 instead of a real telephone number.  Even though 555 prefixes were used for things like directory assistance, they weren’t widely deployed.  As such, the 555 prefix became synonymous with a “fake” phone number.  555-0100 through 555-0199 are the only official numbers in that range set aside for fictitious use, however many people still associate that prefix with a phone number that won’t work in the real world.

Hollywood has been trying for some time to come up with IP addresses that look real enough to pass the sniff test but are totally false.  Sometimes that works.  Other times, you end up with Law and Order.  In particular, the SVU flavor of that show has been known to produce IP address ranges that don’t even come close to looking real.  This page documents a couple of the winners from that show when the police start tracing an offender by their IP address.  Some of them look almost real.  Others seem to have an octet that jumps above 255.  Still others have 4-digit octets or other oddities that don’t quite measure up.  Sure, it heightens the suspense when people can see what the detectives are doing, but for those of us that know enough to be dangerous, it pulls you out of the moment.  It would be like watching ER and hearing the doctors start talking about brain surgery, only to start cutting open a patient’s arm to get to it.

TCP/IP has a large number of address ranges that can be used in a fictitious manner. For instance, Class E experimental addresses (240.0.0.0/4) were set aside and hard coded into most OSes as unavailable.  The address range for example use and documentation purposes 192.0.2.0/24 can also serve as a safe fictitious range.  Then there’s RFC 1918.  These addresses are used for private network ranges and must be NATed to work correctly on the public internet due to their non-routability.  These would be perfect for use in movies, as they represent networks that most people use daily.  They would look believable to those of us that know what to look for.  However, I think the producers and writers avoid doing that because of the inherent curiosity of people.

The greatest example of this comes courtesy of Tommy Tutone.  The band hit radio gold with their song “867-5309/Jenny” back in 1982.  Unlike 555, 867 is a widely used prefix code in the North American Numbering Plan (NANP).  There are numerous stories of people that have received that phone number and been cursed with popularity.  One story from Brown university tells of unsuspecting freshmen that move into the dorm room with that telephone number.  The phone calls never stop until a request is made to shut down the line.  Even back in 1982, the regional Bell companies were seeing huge spikes in telephone calls to that one number.  In many cases, they had to disconnect it in order to keep the traffic to a reasonable level.  If you’re curious, you can hear some of the messages left for the unfortunate possessors of that cursed number over at http://www.jennynetwork.com

People are compelled to try things they see in movies.  This article in the Chicago Tribune talks about the writer memorizing a realistic looking number from a movie and going home to call it several times before giving up.  The movie Magnolia included the real number 877-TAME-HER which the movie studio used to record Tom Cruise giving an in-character speech about his system for the purposes of marketing.  That’s all well and good in the real world when someone gets a few occasional prank calls or other harmless issues.  What happens in a computer network when someone sees a 10.0.0.0/8 address on TV and then decides to try and hack it?  What if they call the police and say that the computer address of a murder or a predator is on their network?  This can cause huge issues for network admins.  The nightmare of trying to explain to people that just because the Gibson in Hackers 3 is at 192.168.1.2 doesn’t mean they get to assault the mail server every day would get old really fast.  And when it comes to IPv6, the opportunity for even more trouble arises.

I was a long-time player of the MMORPG City of Heroes.  One of the reasons that I liked playing it so much was the lore and back story to the world.  I was one of the players that read all of the fluff text to get a better sense of what the writers were trying to do.  Imagine my surprise when I was playing a new mission a several months ago and ran across a little Easter egg.  One of the writers decided that the imaginary world of Paragon City had long ago ran out of IPv4 addresses and decided to upgrade to IPv6.  One of the consoles in the game had a reference to an IPv6 address - 3015:db6:97c4:9e1:2420:9b3f:073:8347.  I was excited.  Finally, someone in the entertainment industry realized we were running out of IPv4!  Then I started thinking.  Right now, the allocations to the RIRs all start with 2001.  Eventually, once we get the intergalactic Internet up and running, we might end up getting into the 3000 range.  It might be a hundred years before the address above is allocated to someone.  By then, most everyone will have forgotten City of Heroes ever existed.  Putting real IPv6 addresses in movies and on TV does run the risk of having people “hacking the Gibson” when you least expect it.  I think you’ll see that even in those far-flung ranges, the odds of a fake address on TV coinciding with a real IPv6 server or workstation address, even on a global scale, is pretty slim.  Despite the fact that all our systems will be globally reachable, the IPv6 address space is so large that no two systems are likely to even overlap.  Add in neighbor discovery, duplicate address detection, and the uniqueness of a MAC address (which forms the basis of EUI-64 addressing and SLAAC) and you can see how difficult it would be.


Tom’s Take

In case the name of my blog didn’t warn you…I’m a nerd.  When I see something inaccurate in a movie, I tend to point it out.  That’s why I don’t watch Armageddon any more.  I understand that writers and directors are trying to entertain people.  When you’re trying to do that, sometimes the details get sacrificed for the sake of telling a good story.  However, when it comes to something that can represented easily for the most realistic look possible, the creative team involved should do that.  Whether it be the night sky in Titanic or the address of the mainframe in a techno thriller, I want the people that care about the production values of a movie to show me how much they care.  With the advent of IPv6, I think creating fake addresses to put in movies and other entertainment will be easier.  Given the vast range of available space it doesn’t take too much effort to pull out something “techy sounding” to put in a movie script.  Trust me, the nerds out there will thank you for it.

2012 Depleted, Time to Adopt ::2013

It’s been 366 days since my last post about goals for 2012.  How’d I do on my list for the past year?

1. Juniper – Dropped the ball on this one.  I spent more time seeing Juniper gear being installed all over the place and didn’t get my opportunity to fire up the JNCIA-Junos liked I wanted.  I’m planning to change all that sooner rather than later.  Doug Hanks even gave me a good head start on immersion learning of the MX Series.

2. Data Center – I did get a little more time on some Nexus gear, but not nearly enough to call it good for this goal.  Every time I sat down to start looking at UCS, I kept getting pulled away on some other project.  If the rumblings I’m hearing in the DC arena are close to accurate, I’m going to wish I’d spent more time on this.

3. Advanced Virtualization – While I didn’t get around to taking either of the VCAP tests in 2012, I did spend some more time on virtualization.  I was named a vExpert for 2012, gave a virtualization primer presentation, and even attended my first VMUG meeting.  I also started listening to the vBrownBag podcast put on by ProfessionalVMware.  They have a ton of material that I’m going to start reviewing so I can go out and at least take the DCD test soon.

4. Moving to the Cloud – Ah ha! At last something that I nailed.  I moved a lot of my documents and data into cloud-based storage.  I leveraged Dropbox, Skydrive, and Google Docs to keep my documentation consistent across multiple platforms.  As I continue forward, I’m going to keep storing my stuff in the big scary cloud so I can find it whenever I need it.

Looks like I’ve got two fails, one tie, and one win.  Still not the 50% that I had hoped for, but it’s funny how real life tends to pull you in a different direction that you anticipate.  Beyond attending a few more Tech Field Day events and Cisco Live, I also attended a Cisco Unified Communications Partner Beta Training launch event and the Texas IPv6 Task Force Winter Summit.  It was this last event that really got me thinking about what I wanted to do in the coming year.

I think that 2013 is going to be a huge year for IPv6 adoption on the Internet.  We’ve been living in the final depletion phase of IPv4 for a whole year now.  We can no longer ignore the fact that IPv6 is the future.  I think the major issue with IPv6 adoption is getting the word out to people.  Some of the best and brightest are doing their part to talk to people about enabling IPv6.  The Texas IPv6 Task Force meeting showed me that a lot of great people are putting in the time and effort to try and drive people into the future.  However, a lot of this discussion is happening outside of people’s view.  Mailing lists aren’t exactly browsing-friendly.  Not everyone can drop what they’re doing for a day or two to go to a task force meeting.  However, people do have the spare time to read a blog post on occasion.  That’s where I come in.

In 2013, I’m going to do my part to get the word out about IPv6.  I’m going to spend more time writing about it.  I’m going to write posts about enabling it on all manner of things.  Hypervisors, appliances, firewalls, routers, and even desktops are on the plate.  I want to take the things I’m learning about IPv6 and apply them to the world that I work in.  I don’t know how service providers are going to to enable IPv6.  However, I can talk about enabling CallManager to use IPv6 and register IP phones without IPv4 addresses.  I can work out the hard parts and the gotchas so that you won’t have to.  I’ve already decided that any presentation that I give in 2013 will be focused on IPv6.  I’ve already signed up for one slot later in the year with a possibility of having a second.  I applied for a presentation slot at the Rocky Mountain IPv6 Task Force meeting in April.  I want to hone my skills talking to people about IPv6.  I’m also going to try and make a lot more blog posts about IPv6 in the coming year.  I want to take away all the scary uncertainty behind the protocol and make it more agreeable to people that want to learn about it without getting scared off by the litany of RFCs surrounding it.  To that end, I’m going to start referring to this year as ::2013.  The more we get familiar with seeing IPv6 notation in our world, the better off we’ll be in the long run.  Plus, it gives me a tag that I can use to show how important IPv6 is to me.

A shorter set of goals this year doesn’t mean a more modest one.  Focus is a good thing in the long run for me.  Being an agent of change when it comes to IPv6 is something that I’m passionate about.  Sure, I’m still going to make the occasional NAT post.  I may even have some unnice things to say about vendors and IPv6 support.  The overall idea is that we keep the discussion focused on moving forward and making IPv6 more widely adopted.  It’s the least I can do to try and leave my mark on the Internet in some other way besides posting cat pictures or snarky memes.  It’s also a goal that is going to keep progressing and never really be finished until the lights are turned out on the last IPv4 webserver out there.  Until that fateful day, here’s hoping that ::2013 is a good year for all.

Unlearning IPv4

"You must unlearn what you have learned." -Yoda

“You must unlearn what you have learned.” -Yoda

As network rock stars, we’ve all spent the majority of our careers learning how to do things.  We learn how to address interfaces and configure routing protocols.  For many of those out there, technology has changed often enough that we often find ourselves need to retrain.  Whether it be a new version of an old protocol or an entirely new way of thinking about things, there will always come a time when it’s necessary to pick up new knowledge.  However, in the case of updated knowledge it’s often difficult to process.  That’s because the old way of doing things interposes itself in our brains while we’re learning to do it the new way.  How many times have you been practicing something only to hear a little voice in the back of your head saying, “That’s not right.  You should be doing it this way.”  In many ways, it’s like trying to reprogram the pathway in your brain that leads to the correct solution to your problem.

This is very apparent to me when it comes to learning how to configure and setup IPv6 on a network.  Those just starting out in the big wide world of IPv6 need to have some kind of reference point to start configuring things, so they tend to lean back on their IPv4 training in order to get started.  This can work for some applications.  For others, though, it can be quite detrimental to getting IPv6 running the way it should.  Instead of carrying forward the old way of doing things because “that’s just the way they should be done,” you need to start unlearning IPv4.  The little green guy in Empire Strikes Back hit the nail on the head.  The whiney farm boy had spent so much of his life convinced that something was impossible that he couldn’t conceive that someone could lift his starship out of a swamp with the Force.  He had to unlearn that lifting things with his mind was impossible.  Once you take that little step, nothing can stop you from accomplishing anything.

With that in mind, here are a few things that need to be unlearned from our days working with IPv4.  Note that this won’t be easy.  But nothing worth doing is ever easy.

Address Conservation – This one is the biggest stumbling block today.  Look at all the discussion we’ve got around point-to-point links and whether to address them with a /64 or a /127 bit mask.  People claim that addressing this link with a /64 wastes addresses.  To  quote the old guy in the desert from Star Wars, “It’s true, depending on your point of view.”  In a given /64, there are approximately 18 quadrillion addresses available (I’m rounding to make the math easy).  If you address a point-to-point link with a /64, you’re only going to be using 0.0000000000000000001% of those addresses (thats 1 * 10^-19).  To many, that’s a pretty big waste.  But with numbers that big, your frame of reference gets screwed up.  By example, take a subnet with 4,094 hosts, which today would need /20 in IPv4.  That’s about the biggest single subnet I can imagine creating.  If you address that 4,094 host subnet with a /64 in IPv6, you’d end up using 0.0000000000000002% (2 * 10^-16) of the address space.  Waste is all a matter of perspective.  On the other hand, by addressing a link with a bit mask beyond a /64, we break neighbor discovery and secure neighbor discovery and PIM sparse mode with embedded RP among other things.  We need to unlearn the address conservation mentality and instead concentrate on making our networks easier to configure and manage.

Memorizing IP addresses – I’m guilty of this.  I spend a lot of time working at the command line with IPv4, whether it be via telnet or SSH or even just plugging numbers into a GUI.  My CUCM systems are setup to use IP only.  I memorize the addresses of my servers, or in many cases try to make this as similar mnemonically to other systems to jog my memory about where to find them in IP space.  In IPv6, memorizing addresses is going to be impossible.  It’s hard enough for me to remember non-RFC1918 address space as it is with 4 octets of decimal numbers.  Now quadruple that and add in hex addressing.  And when it comes to workstations with SLAAC or DHCPv6 assigned addresses?  Forget about it.  Rather than memorizing address space, we’re going to need to start using DNS for communications between endpoints.  Yes, that means setting up DNS for all your routers and CUCM servers too.  It’s going to be a lot of extra work up front.  It’ll pay off in the long run, though.  I’m sure you’d much rather refer to CUCM1.local rather than trying to remember fe80::ba8d:12ff:fe0b:8aff every time you want to get to the phone server.

Subnet Masks – Never again will you need to see 255 in an IPv6 address unless it’s part of the address.  Subnet masking is dead and buried.  Instead, bit masks and slash notation rule the day.  This is going to be one of the most welcome changes in IPv6, but I think it’s going to take a long time to unlearn.  Not really as much for network engineers, but mainly for the people that have ancillary involvement with networking, such as the server people.  Think about the number of server admins that you’ve talked to that have memorized that the subnet mask of their network card is 255.255.255.0.  Now, ask them what that means. Odds are good they can’t tell you.  Worse, some of them might say that it’s a Class C subnet mask.  It’s a little piece of anecdotal information that they heard once when the network folks were talking that they just picked up.  Granted, most of the time the servers are going to be addresses with a /64 bit mask on the IPv6 address.  That’s still going to take a while to explain to the non-networking people.  No, you don’t need any more 255s in your address.  Yes, the /64 is the same as that, sort of.  No, there’s math involved.  Yes, I’ll take care of all the math.

Ships in the Night – As I said on my recent appearance on the Class C block podcast, I think it’s high time that networking vendors stop treating IPv4 and IPv6 like they are separate entities.  I know that I’ve spent the better part of this blog post talking about how IPv4 and IPv6 require a difference in application and not carrying across old habits and conventions.  The two protocols are more alike that they are different.  That means that we need to stop thinking of IPv6 as an afterthought.  Take a look at the CCIE.  There’s still a separate section for IPv6.  It feels like it was just a piece that was added on to the end of the exam instead of being integrated into the core lab.  Look at Kurt Bales’ review of the JNCIE lab that he took.  Specifically, the last bullet point.  You could be asked to configure something on either IPv4 or IPv6, or even both!  Juniper understands that the people taking the JNCIE today aren’t going to have the luxury of concentrating on just IPv4.  The world is going to require us to use IPv6, so I think it’s only fair that our certification programs start doing the same.  IPv6 should be integrated into every level of certification from CCNA/JNCIA all the way up to CCIE/JNCIE.


Tom’s Take

Working with IPv6 is a big change from the way we’ve done things in the past.  With SLAAC and integrated IPSec, the designers have done a great job of making our lives easier with things that we’ve needed for a long time.  However, we’re doing our best to preclude our transition to IPv6 by carrying over a lot of baggage from IPv4.  I know that our brains look for patterns and like to settle on familiarity as a way to help train for new challenges.  If we aren’t careful, we’re going to carry over too much of the old familiar networking and make IPv6 difficult to work with.  Unlearning what we think we know about networking is a good first step.  A person may learn something quickly with familiarity, but they can learn even faster when they approach it with a blank slate and a keen interest to learn.  With that approach, even the impossible won’t keep you from succeeding.

The Five Stages of IPv6 and NAT

I think it’s time to put up a new post on IPv6 and NAT.  Mainly because I’m still getting comments on my old NAT66 post from last year.  I figured it would be nice to create a new place for people to start telling me how necessary NAT is for the Internet of the future.

In the interim, though, I finally had a chance to attend the Texas IPv6 Task Force Winter 2012 meeting.  I got to hear wonderful presentations from luminaries such as John Curran of ARIN, Owen DeLong of Hurricane Electric, and even Jeff Doyle of Routing TCP/IP book fame.  There was a lot of great discussion about IPv6 and the direction that we need to be steering adoption of the new address paradigm.  I also got some very interesting background about the formation of IPv6.  When RFC 1550 was written to start soliciting ideas about a new version of IP, the Internet was a much different place.  Tim Berners-Lee was just beginning to experiment with HTTP.  The majority of computers connected to the Internet used FTP and Telnet.  Protocols that we take for granted today didn’t exist.  I knew IPSec was a creation of the IPv6 working group.  But I didn’t know that DHCP wasn’t created yet (RFC 2131).  Guess what?  NAT wasn’t created yet either (RFC 1631).  Granted, the IPng (IPv6) informational RFC 1669 was published after NAT was created, but NAT as we know and use it today wasn’t really formalized until RFC 2663.  That’s right, folks.

The reason NAT66 doesn’t exist is because IPv6 was built at a time when NAT didn’t exist.

It’s like someone turned on a lightbulb.  That’s why NAT66 has always felt so wrong to me. Because the people that created IPv6 had no need for something that didn’t exist.  IPv6 was about creating a new protocol with advanced features like automatic address configuration and automatic network detection and assignment.  I mean, take a look at the two IPv6 numbering methods.  Stateless Automatic Autoconfiguration (SLAAC) can assign all manner of network information to a host.  I can provide prefixes and gateways and even default routes.  However, the one thing that I can’t provide in basic SLAAC is a DNS server entry.  In fact, I can’t provide any of the commonly assigned DHCP options, such as NTP server or other vendor-specific fields.  SLAAC is focused solely on helping hosts assign addresses to themselves and get basic IP connectivity to the global Internet.  Now, take DHCPv6.  This stateful protocol can keep track of options like DNS server or NTP server.  It can also provide a database of assignments so I know which machine has which IP.  But you know what critical piece of information it can’t provide?  A default router.  That’s right, DHCPv6 has no method of assigning a default router or gateway to an end node.  I’m sure that’s due to the designers of DHCPv6 knowing that SLAAC and router advertisements (RA) handle the network portion of things.  The two protocols need to work together to get hosts onto the internet.  In 1995, that was some pretty advanced stuff.  Today, we think auto addressing and network prefix assignment is pretty passé.

Instead of concentrating on solving the dilemma of increasing the adoption rate of IPv6 past the 1% mark where it currently resides, we’ve instead turned to the Anger and Bargaining phases of the Küber-Ross model, otherwise known as the Five Stages of Grief. The need for IPv6 can no longer be denied.  The reality of running out of IPv4 addresses is upon us.  Instead, we lash out against that which we don’t understand or threatens us.  IPv6 isn’t ready for real networking.  There are security risks.  End-to-end communications aren’t important.  IPv6 is too expensive to maintain.  People aren’t smart enough to implement it.  Any of those sound familiar?  Maybe not those exact words, but I’ve heard arguments very similar to that leveled at IPv6 in just the two short years that I’ve been writing.  Think about how John Curran of ARIN must feel twenty years after he started working on the protocol.

Anger is something I can handle.  Getting yelled at or called expletives is all part of networking.  It’s the Bargaining phase that scares me.  Now, armed with a quiver of use cases that perhaps 5% of the population will ever take advantage of, we now must delay adoption or move to something entirely different to support those use cases.  It’s the equivalent of being afraid to jump off a diving board because there is a possibility that the water will drain out of the pool on the way down.  The most diabolical is Carrier Grade NAT.  Let’s NAT our NATed networks to keep IPv4 around just a little longer.  It won’t cause that many problems, really.  After all, we’ve only got 65,536 ports that we can assign for any given PAT setup.  So if we take that limit and extend it yet another level, we have 65,536 PATed PAT translations that we can assign per CGN gateway.  That has real potential to break applications, and not just from an end-to-end connectivity point of view. To prove my point, fire up any connection manager and go to http://maps.google.com.  See how many separate connection requests are spawned when those map tiles start loading.  Now, imagine what would happen if you could only load ten or fifteen of them.  There’s going to be a lot of blank spots on the that map.

Now, for the fun part.  I’ve been accused of hating NAT.  Yes, it’s true.  I dislike any protocol that breaks basic connectivity and causes headaches for troubleshooting and end-to-end communications.  I have to live with it in IPv4.  I’d rather not see it carried forward.  That’s the feeling of many IPv6 evangelists.  If you think I dislike NAT, ask Owen DeLong his feelings on the subject.  However, to say that I dislike NAT for no good reason is silly.  People are angry at me for saying the emperor has no clothes.  Every time I discuss the lack of need for NAT66, the same argument gets thrown in my face.  Ivan Pepelnjak wrote an article about about using network prefix translation (NPT) in a very specific case.  If you are multihoming your network to two different providers and not using BGP then a case for NPT can be made.  It’s not the best solution, but it’s the easiest.  Much like Godwin’s Law, as the length of any NAT66 argument increases, the probability of someone bringing up Ivan’s article approaches approaches one.

So, I’ve found a solution to the problem.  I’m going to fix this one scenario.  I’m going to dedicate my time to solving the multihoming without BGP issue.  When I do that, I expect choirs of angels to sing and a chariot pulled by unicorns to arrive at my home to escort me to my new position of Savior of IPv6 Adoption.  More realistically, I expect someone else to find a corner case rationale for why IPv6 isn’t the answer.  Of course, that’s just another attempt at bargaining.  By that point, I’ll have enough free time to solve the next issue.  Until then, I suggest the following course of action:

The Land Of Opportunity

It’s been *checks watch* about 38 minutes since I last thought about NAT, so it’s probably time to sit down and write some more about it.  I’ve got an image to uphold after all.  I wrote about my position on NAT a couple of posts ago, and in it I discussed NAT64.  I railed against it much the same as introducing any kind of NAT into IPv6.  Ivan Pepelnjak, a very well respected and frighteningly intelligent networking rock star, listened to the Packet Pushers show that fueled my rant and read my blog post.  He then posted an article where he takes NAT64 and puts it into proper perspective.  I read through it, and guess what?

He’s absolutely right.

Yep, Ivan nailed that one.  NAT64, which is the process of translating IPv6 addresses into IPv4 addresses, has a use when it comes to allowing the IPv6 Internet to access content that is still stuck on the IPv4 Internet.  Without some sort of translation mechanism, those IPv6-only hosts will be walled off from the IPv4 Internet in general.  The other methods he discusses are either completely insane, like Carrier-grade NAT (NAT444), or are impractical from a support standpoint, like dual-stacking.  I happen to think dual-stacking is the way to go with this, but I don’t want to be the local ISP trying to support a D-Link router running a dual stack when someone’s mom calls for support.

Ivan’s final point of the article hits home in a way that should make people sit up and pay attention.  “The proper way to tackle this issue is to make your content available over IPv4 and IPv6. IPv4 clients won’t notice it and IPv6 clients will use native IPv6 connectivity bypassing NAT64.”  He’s spot on with this one too.  If you build your content aware of both IPv4 and IPv6, you won’t have any real issues when it comes to IPv6-only hosts.  I’m going to take this one step further, though.  Let me ask a question that I think really cuts to the heart of the Internet in general when it comes to content creation and consumption:

What content would you access that is IPv4-only?

Right now, that question would be answered with “everything”, since IPv6 adoption is spotty at best.  However, with World IPv6 Day looming in less than a month, the sponsor list is growing quickly.  Google, Yahoo, & Facebook are already on board, and 163 more companies are ready to flip the switch as well.  If you think about it, there’s a great importance that should be attached to making your content IPv6 accessible.  In my IPv6 presentation, I talked about the impact of new content providers in the APNIC region creating things that you won’t be able to see if you are on the IPv4 Internet, since they are out of IPv4 addresses totally at this point, for all intents and purposes.  However, look at it from the perspective of an IPv4-only content provider.  You’ve got all this great content that you want to serve out to your audience.  Many of your audience members are starting to hear about IPv6 and wonder how it will be implemented.  More still, like those in the APNIC region, are unable to view your IPv4 content right now.  For those hopping on the IPv6-only Internet, it probably looks a lot like it did back in Vint Cerf’s day – a whole lot of nothing.  If you want to stake your claim for your content, are you going to wait for someone to come out with a NAT64 appliance?  Are you going to sit around until an IPv6-to-IPv4 transition is possible on a load balancer?  If you are, you had best start packing up your office, because you won’t stick around for long.  The handwriting is already on the wall.

World of Warcraft, the largest Massively Multiplayer Online Role-Playing Game (MMORPG) enabled IPv6 connectivity in their recent v4.1.0 patch.  They’ve been talking about it since March.  Now, those 10 million subscribers won’t have to worry about NAT64 if they get assigned an IPv6-only prefix.  They’ll just keep on playing the same way they’ve always played.  I think it’s going to end up being the same for 75% of the services that you use today.  Things like e-mail, calendaring, and popular websites will be IPv6 ready well ahead of any kind of IPv4 exhaustion.  Those that rely on advertising revenue won’t hesitate to get IPv6 enabled so as to not lose out on an untapped market of IPv6-only hosts.

Tom’s Take

NAT isn’t pretty.  It’s a necessary evil.  It has uses, and as Ivan pointed out they can be pretty important to keep the content-rich Internet from looking like a barren desert.  But at the same time, there is a path away from the need to slap a NAT64 band-aid on things.  By enabling IPv6 now, you avoid the expense and hassle of needing to wait for NAT64 to be finalized and argued about until the vendors are blue in the face.  You, as a content provider, can serve your content and ads and subscriptions to a whole new world of consumers in this new land of opportunity while the IPv4-only world gets left by the wayside, trying to figure out how to patch the problem rather than fixing it right the first time.

As a side note here, if you are at all interested in IPv6 and its implementation and impact, you need to sign up for Ivan’s excellent webinars.  He’s a genius when it comes to MPLS, IPv6, and datacenter networking.  In fact, do yourself a favor and save money by just buying a subscription to all of them.  At $199, it might sound like a pricey purchase, but since you’re going to want to listen to everything he’s got to say, it works out to be a great investment in your future.

Cut Me Some SLAAC, Or Why You Need RA Guard

The Internet has been buzzing for the last couple of weeks about a new vulnerability discovered in IPv6 and the way it is interpreted by networking devices.  Firstly, head over to Sam Bowne’s excellent IPv6 site and read his assessment of the attack HERE.  What is being exploited is a “feature” in IPv6.

Since IPv6 doesn’t use Address Resolution Protocol (ARP), it relies on ICMP and Neighbor Discovery messages to determine neighbors on the network.  It also uses Router Advertisements (RA) to build a picture of how to get off the local network.  When the Stateless Address AutoConfiguration (SLAAC) flag is set in the RA, the local host will choose an address from the announced address space and begin using it.  This is a great addition to the protocol, since it allows a network admin to setup an automatic addressing protocol that isn’t reliant on a server like DHCPv6.  However, from a security standpoint, it introduces some possible problems.  If a host on the network were to start sending RA packets to the LAN, that man-in-the-middle could start influencing packet routing.  Worse still, if the attacker isn’t really interested in rerouting packets, they could just take the anarchist’s approach and burn the whole network down with a specially-crafted DoS attack.  By flooding a ton of RA messages onto the local network with different network address spaces, the attacker can cause the CPUs on Windows and FreeBSD boxes to spike to 100% and stay there indefinitely.  This is because the host system continually tries to process the RAs flooding in from the network and starts trying to pick address space in every network announcement that it hears.  This consumes all its resources with updating the routing table and addressing the adapters on the system.  This could cause problems for your end users should an attacker get into a position to launch RAs into your LAN.  Right now, there are a couple of ways to fix this:

1. Disable IPv6 – Okay, this doesn’t fix the problem it just makes it go away.

2.  Disable RAs on the local network – Again, not a fix, just hiding it.  Plus, this breaks SLAAC, which I see is a real advantage to IPv6.

3.  Install a firewall or ACL on your host-facing ports to block RAs or filter out the ICMPv6 packets carrying them.

What I find even more interesting about this whole affair is the response of the three biggest players in the game in regards to the issue.  Let me sum it all up using their words:

Microsoft – This is Working As Intended (WAI).  We don’t plan on fixing this.

Juniper – We need to work with the IETF and figure out a standard solution to address this problem, and until we do we aren’t patching against it.

Cisco – We fixed this last year, and by the way have you heard of RA Guard?

Cisco has implemented a solution very similar to what they do with DHCP snooping on IPv4 switches.  They call it RA Guard.  As defined in RFC 6105, RA Guard can be enabled on all host-facing switchports to filter RAs from non-trusted sources.  In this case, the trusted source would be a switchport you know to contain a valid router, so you wouldn’t enable RA guard on it.  The RFC defines a discovery method using Secure Neighbor Discovery (SeND) that made me chuckle because the four states of the discovery are the same as 802.1w Rapid Spanning Tree.  Seems we’re never going to get rid of it.  When you enable SeND-based RA Guard discovery, it can dynamically scan the network for devices broadcasting RAs and block or allow them as necessary.  That way, you don’t have to worry about misconfiguring a switchport and killing all the advertisements coming from it. By enabling RA guard on a Cisco switch with firmware 12.2(50)SY, you can effectively mitigate the possibility of an unauthorized attacker DoSing your entire network with what amounts to a script-kiddie style attack.

Tom’s Take

Take a vulnerability that has been known about for two years but swept under the rug, add in a dash of vendor disregard, and shake until the Internet security community is frothing at the mouth to tell you that you should turn off IPv6 on your entire network.  Sounds like a recipe for overreaction to me.  I’m not denying that it is a serious vulnerability.  In fact, given the fact that IPv6 is enabled by default on the current Windows version, it could cause issues.  That is, unless you are smart and take measures to fix the issue rather than sweeping it back under the rug.  Rather than just turning off IPv6 until someone other than Microsoft releases a patch, we need to work through the issue and fix the underlying security issue.  At the same time, this needs to be agreed upon by the major networking vendors sooner rather than later.  The longer this issue exists in its present form, the more security sensationalists can point to it and decry one of the advantages of IPv6 on your network when in fact they should be focusing on the lack of security in the software that allows anyone to masquerade as an IPv6 router.  Then, maybe we can cut IPv6 a little bit of slack.

IPv6 for Enterprise Networks – Review

Unless you’ve been living in a cave with Tony Stark for the past several months, you are well aware that IPv6 is a reality that can’t be ignored by today’s networker.  Part of the issue affecting IPv6 adoption is the lack of good reading material.  Yes, there are mountains of RFCs out there that talk about IPv6 in nauseating detail.  However, these documents aren’t all that accessible for the average network rock star that is working 50 hours a week and doesn’t have time to pour over page after page of dry Internet-ese.  There have been some great posts about IPv6 for the common man from people like Jeremy Stretch and Chris Jones but there is a segment of the population that would rather read about the subject from a vendor source.  Enter Shannon McFarland and company:

IPv6 for Enterprise Networks Cover

Cisco Press graciously provided a copy of this book for my evaluation.  Clocking in at a svelte 361 pages, this tome has a great wealth of IPv6 information from a design perspective.  There are some code examples for your networking gear, but much of the discussion in this book revolves around IPv6 design and building your network right the first time.

Chapter 1 starts off the same way many network rock stars will start off pitching IPv6 to their company, with a discussion of the market drivers for IPv6 adoption.  Even though networking professionals know IPv6 is inevitable, the C-level executives will most likely need some additional convincing.  This chapter is great for them to hear about the reasons why IPv6 is necessary.  Chapter 2 is an overview of the Cisco hierarchical network design, now expanded to include IPv6 content.  If you’ve seen any network design documentation in the past decade, this should be a review for you.  Just note the IPv6 sections.

Chapter 3 starts the meat of the book.  This chapter discusses the coexistence mechanisms that you are likely to face when prepping your network, since we are going to need to run IPv4 alongside IPv6 no matter how much we might not want to.  Tunnels and NAT64 get some discussion, along with running IPv6 over MPLS.  Chapter 4 discusses the various network services that will need to be IPv6 aware to help run your network, such as OSPFv3 or BGP.  Great discussion is made about multicast, since multicast is such a crucial component in IPv6.  Chapter 5 is a short one, discussing the planning that one will need to go through for implementing an IPv6 infrastructure.  This is more of the paperwork and staging behind the scenes that might be boring, but in an enterprise is critical for painless IPv6 deployment.

Chapter 6 is the largest chapter and will most likely be where you spend most of your time.  This is a soup-to-nuts campus IPv6 deployment.  The authors analyze the deployment from three different perspectives, the dual stack (my favorite), the hybrid model that is useful for non-IPv6 applications, and the service block model, which allows you to bring IPv6 online in sections.  Every facet of your network is analyzed in this chapter, from VLANs to routing protocols to QoS and other network services.  If you are going to be deploying IPv6 in your network in the future, you’d do well to just dog ear Chapter 6 so you can turn back to it quickly.

Chapters 7 through 10 deal with specific cases of IPv6 deployment to support use-cases, such as virtualization, branch offices, datacenters, or remote access.  They exist so that you can quickly reference these scenarios as needed, since you may not need to worry about deployment of IPv6 in a datacenter in your environment for instance.  The authors do a wonderful job of explaining all the things you might need to take into account in your deployment of ancillary technologies, such as Microsoft protocols to be aware of or application requirements that may not necessarily be network dependent.

Chapter 11 is all about managing your shiny new IPv6 network through things like Netflow and SNMP.  Careful attention should be paid if you don’t want to find yourself chasing poltergeists in your network at 3 a.m. on a Sunday.  Chapter 12 gives you a great breakdown of parts and pieces that would be great to construct a lab to pilot your IPv6 implementation before unleashing it on your live network.  That way, IPv6 doesn’t call the Resume Generating Event (RGE) protcol.

Tom’s Take

I liked this book quite a bit.  There is a ton of good information to be found inside for all levels of network rock star, from those just learning about deploying IPv6 to the poor souls that find themselves mired in a remote access IPv6 deployment gone wrong.  With a big focus on proper network design, IPv6 for Enterprise Networks ensures that you don’t have to rebuild your IPv6-enabled network after a short time due to bad design decisions or compromises. Every scenario I’ve seen discussed concerning IPv6 deployment is laid out in clear language, with both pros and cons for deployment.  I highly recommend picking up this book as soon as you can so your journey down the IPv6 yellow brick road starts off smoothly and you can avoid the pitfalls before you encounter them.

As a bonus, if you are going to Cisco Live 2011 in Las Vegas, Shannon McFarland is giving a session based around this book, BRKRST-2301 Enterprise IPv6 deployment.  If you aren’t adverse to 8 a.m. sessions the morning after the Customer Appreciation Event you should sign up and check it out.  I plan on bringing my book so that Shannon can autograph it.  That way, I can claim I met him before he became a gigantic IPv6 rock star.

So? So, so-so.

By now, many of you have read my guidelines to presentations HERE and HERE.  I sit through enough presentations that I have my own opinions of how they should be done.  However, I also give presentations from time to time.  With the advent of my new Flip MinoPRO, I can now record my presentations and upload to whatever video service I choose to annoy this week.  As such, allow me to present you with the first Networking Nerd presentation:

47 minutes of me talking.  I think that’s outlawed by the Geneva Convention in some places.  So you can follow along, here’s a link to my presentation in PowerPoint format.

I don’t like looking at pictures of myself, and I don’t like hearing myself talk.  You can imagine how much fun it was for me to look at this.  I tried to give an IPv6 presentation to a group of K-12 technology directors that don’t spend  a lot of time dealing with routing and IP issues.  I wanted to give them some ideas about IPv6 and what they needed to watch out for in their networks in the coming months.  I have about a month to prepare for this, and I spent a good deal of that time practicing so my delivery was smooth.

What’s my opinion of my performance?  Well, as you can tell by the title of this post, I immediately picked up on my unconscious habit of saying “so”.  Seems I use that word to join sections of conversation.  I think if I put a little more conscious thought into things, I might be able to cut that part down a bit.  No sense putting words like “so”, “um”, and “uh” in places where they don’t belong.  They are crutches that need to be removed whenever possible.  That’s one of the reasons I like writing blog posts much more than spoken presentations: I can edit my writing if I think I’ve overused a word.  Plus, I don’t have to worry about not saying “um” while I type.

You’ll notice that I try to inject some humor into my presentation.  I feel that humor helps lighten the mood in presentations where the audience may not grasp everything all at once.  Humor has it’s place, so it’s best to leave it out of things like eulogies and announcing the starting lineup at a Yankees game.  But if you watch a lot of “serious” types of presentations, a little levity goes a long way toward making things feel a lot less formal and way more fun.

I also try to avoid standing behind a lectern or a podium when I speak.  I tend to use my hands quite a bit to illustrate points and having something sitting in front of me that blocks my range of motion tends to mess with my flow a little.  I also tend to pace and wander around a bit as I talk.  Having to be held to a physical object like a lectern would drive me nuts.  I would have preferred to have some kind of remote in my pocket that I could advance the slides with and use a laser pointer to illustrate things on the slides, but I lost mine some time ago and it has yet to turn up.  Luckily, I had someone in the room that was willing to advance my slide deck.  Otherwise, there would have been a lot of walking back and forth and out of frame.  Note to presenters, invest in a remote or two so you can keep the attention focused on you and your presentation without the distraction of walking back and forth or being forced to stay close to your laptop.

Let me know what you think, good or bad.  If you think I spaced out on my explanation of the content, corrections are always welcomed.  If you don’t like my gesticulations, I want to know.  Even tell me if you thought my Spinal Tap joke was a little too corny.  The only way I can get better as a presenter is to get feedback.  And since there were 8 people in the room, 7 of which I knew quite well, I don’t think I’m going to get any feedback forms.