Category Archives: IPv6

IP Addresses in Entertainment

Posted on by
7

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

Posted on by
2

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

Posted on by
6
"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

Posted on by
14

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:

Start Menus and NAT – An Experiment

Posted on by
1

Fresh off my recent fame from my NAT66 articles (older and newer), I decided first thing Monday morning that a little experiment was in order.  I wanted to express my displeasure for sullying something like IPv6 with something I consider to be at best a bad idea.  The only thing I could come up with was this:

The response was interesting to say the least.  Questions were raised.  Some asked if I was playing a late April Fools joke.  Others rounded up the pitchforks and torches and threatened to burn down my house if I didn’t recant on the spot.  Mostly though, people made sure to express their displeasure by educating me to the fact that I should use something else to do what I wanted rather than rely on the tried-and-true metaphor of a Start Menu.

Now do you see what I’m talking about with NAT66?  Some people think that NAT is needed not because it’s a technological necessity.  Not because it’s solving fifteen problems that IPv6 has right now.  They want NAT because they really don’t understand how things work in IPv6.  It’s the same as bolting a Start Menu on to OS X.  When I started using my new MacBook a few months ago, I took the time to figure out how to use things like Spotlight and Alfred.  They weren’t my Start Menu, but they worked almost the same way (in many cases better).  I didn’t protest the lack of a metaphor I clearly didn’t need.  I adapted and overcame.  And in the end I found myself happier because I found something that worked better than I had hoped.

In much the same way, people that crave NAT on IPv6 are just looking for familiar metaphors for addressing.  I’m going to cast aside the multihoming argument right now because we’ve done that one to death.  Yes, it exists.  Yes, it needs to be addressed.  Yes, NPT is the best solution we’ve got right now.  However, when I started going through all the comments on my NAT66 blog post after the link from the Register article, I noticed that some of the commenters weren’t entirely sure how IPv6 worked.  They did understand that the addresses being assigned to the adapters were globally routable.  But some seemed to believe that a globally routable address meant that every device was going to need a firewall along with DDoS protection and ruleset monitoring.  Besides the fact that every OS has had a firewall since 2002, let me ask one question.  Are you tearing out your WAN firewall when you move to IPv6?  Because as far as I know, you still one have one (maybe two) WAN connections that are terminated on some device.  That could be a router or a firewall.  In the IPv4 world, that device is doing NAT in addition to controlling which devices on the outside can talk to the inside.  Configuring a service to traverse the firewall is generally a two-stage process today.  You must configure a static NAT entry for the device in question and then allow one or more ports to pass through the firewall.  It’s not too difficult, but it is time consuming.  In IPv6, with the same firewall and no NAT, there isn’t a need to create a static NAT entry.  You just permit the ports to access the devices on the inside.  No NAT required.  If you don’t want anyone to talk to the devices on the inside, you don’t configure any inbound rules.  Simple as that.  When you need to poke holes in the firewall for things like web servers, email servers, and so on, all you need to do is poke the hole and be done.

Perhaps what we really need to end this NAT issue is wildcard masking for IPv6 addresses in firewalls.  I have no doubt that eventually any simple home network device that support DHCPv4 today will eventually support DHCPv6 or SLAAC in the near future.  As fast as new chipsets are created to increase the processing power we install into small office/home office devices, it’s inevitable that support will come.  But to support the “easy” argument, what we likely need to do is create a field in the firewall that says “Network Address”.  That would be the higher ordered 48 bits of the IPv6 address.  Once it’s plugged in, the hosts will use DHCPv6 or SLAAC to address themselves.  Then, we select the devices from a list based on DNS name and click a couple of checkboxes to allow ports to open for inbound and outbound traffic.  If a customer is forced to change their address allocation, all they need to do is change the “Network Address” field.  Then, software on the backend would script changes to DHCPv6/SLAAC and all the firewall rules.  DNS would update automatically and all would work again.  Perhaps this idea is too far fetched right now and the scripting necessary would be difficult to write at the present time.  But if it answers the “easy” outcry about IPv6 addressing without the need to add NAT to the protocol, I’m all for it.  Who knows?  Maybe Apple will come up with something just this easy.

Tom’s Take

For the record, I really don’t think there needs to be a Start Menu in OS X.  I think Spotlight is a perfectly fine way to launch programs not located on the dock and find files on your computer.  Even alternatives like Alfred and Quicksilver are fine for me.  The point of my tweet and subsequent replies wasn’t meant to advocate for screwing up the UI of OS X.  It was meant to show that while some people think that my distaste for NAT is silly, all it takes is the right combination of silliness to get people up in arms.  To all of you that were quick to jump and offer alternatives and education for my apparent lack of vision, I say that we need to focus effort like that into educating people about how IPv6 works or spend our time figuring out how to remove the roadblocks standing in the way of adoption.  If that means time writing scripting for low-end devices or figuring out easy UI options, so be it.  After all, someone else has already figured out how to create a Start Menu on a Mac:

IPv6, NAT, and the SME – A Response

Posted on by
5

I think my distaste for NAT is pretty well known by now. I’ve talked time and again about how I believe that NAT is a bad idea, especially where IPv6 is concerned. I’d said my peace and had time for good conversations with my friends Ivan Pepelnjak (@ioshints) and Ed Horley (@ehorley) about the subject. I was content to just wear my “I HATE NAT” t-shirts to conferences and let bygones be bygones. Then, suddenly…

IPv6 Sucks for SMEs – The Register

Some of you have seen my responses before. Maybe you’ve even been amused by them. Coupled with the fact that I tend to lean toward the snarky side of things, I can see where I might come off as a bit of a smart ass. But “belitted?” “chastened?” Wow. Maybe I’ve let my passion blind me to the plight of the Small-to-Medium Enterprise/Business (SME/B) network/server folks. Maybe we really should stop trying to undo years of duct tape patches to networking and embrace the fact that NAT is a great thing because it allows the little guys to spend less time changing ISPs and deciding to renumber their internal networks on a whim. In fact, I’m even considering calling all my buddies at the IETF and rescinding the whole idea of IPv6. I mean, after all what good is renumbering the Internet if it breaks such a fundamentally important protocol like NAT?

Oh, sorry. I just couldn’t keep a straight face anymore…

In all seriousness, Trevor Pott (@cakeis_not_alie) brings up some very interesting points in his discourse on the impact of IPv6 for the Small-to-Medium Enterprise/Business (SME/B). I’m even willing to admit that we might have glazed over some of the lower-end aspects of what a change like this will mean to people on the razor’s edge of IT. But in the article, the painting of networking professionals as uncaring dictators of fiat laws is almost as silly as characterizing me as a belittling jackass. Yes, I write some pretty pointed posts about NAT and IPv6. Sure, I have a lot of fun playing the heel. But I would hope that my points are made from somewhat sound networking reasoning and not simply blind hatred of NAT and those that use it.  Yes, especially those on the edge of networking.

When I was an intern at IBM Global Services in 2001, I had my first real exposure to the way networking operates. I spent a lot of time configuring static IP addresses on devices and using DHCP on others. I got a real eye opening experience. It even colored my perception of networking for a few years to come, although I didn’t know it at the time. You see, as one of the “old guard” networking companies, IBM has their own registered /8 (Class A) network prefix. Everything inside IBM runs on 9.0.0.0/8. Apple similarly has 17.0.0.0/8. These folks have the luxury of a globally routable IP space large enough that they never (realistically) have to worry about running out. For many years afterwards, I couldn’t understand why I was unable to reach my 192.168.1.0/24 network at home from my university network. It wasn’t until I really started learning more about networking that I realized that RFC1918 existed and NAT was in place to allow ever-growing LANs to have Internet access in absence of registered IP space like I had enjoyed at IBM. As time moved on and I started becoming involved with more and more network services that are affected by NAT, I began to see what IBM’s /8 could offer an enterprise. The flexibility of being static. By having their own IP space, IBM didn’t have to change their address structure to suit the needs of users. They never had to worry about changing ISPs and renumbering their network. Everything just stayed the same and we went on with our lives. But, as Trevor Pott pointed out in the article, IBM and Cisco and Juniper and Apple are enterprises. They aren’t…small.

On the polar opposite end of the scale, we have the little guys. The folks that keep law offices running on a SOHO router/firewall/DHCP server. The accounting offices that can only get a /28 or a /29 IPv4 block from their ISP. Folks that look at duct tape as a solution and not a patch. The “cost conscious” customer as one might say. I can identify with many of these customers because their are my customers in my day job. I’ve had to renumber a publicly addressed network on the fly on a Saturday morning. I’ve had to reconfigure firewalls because the ISP decided to reclaim IP space from a customer. It’s a giant pain in the exhaust port. It’s not glamorous or fun. It’s a necessary evil. But is it a reason to rail against IPv6?

In my previous posts, I talked about the issues with IPv6 on the small end of the scale. Sure, we’ve got a lot of addresses to hand out. We’ve also got a lot of configuration to do. We have to reexamine our stand on firewalls and routes and DNS and a lot of other things. Yes, I will freely admit that this isn’t going to be cheap. I’ve already started building the costs of these analyses into the contracts I sign with my customers for the coming year because I know it will need to be done and I don’t want them to be surprised when they get the message from their provider that the time has come to renumber. But I’ve also got another solution in mind for some of my most “cost conscious” customers and readers. I don’t really want to spill the secret sauce, but here goes:

If it’s going to bother you that much, don’t use IPv6.

Plain and simple in black and white (and red). Unless your ISP is going to start charging you an inordinately high monthly fee to keep an IP block you’ve had for years, don’t change. Stay on IPv4. There’s a whole world out there that is never going to move from IPv4 and be perfectly happy. People who run equipment that will never have enough memory or CPU power to process a naked IPv6 packet (let alone a NATed or NPTed packet). People who are mandated to use translated addresses because of some kind of regulatory oversight like the Payment Card Industry (PCI). I really don’t mean to sound like I’m snorting derisively with this advice. If the additional cost of maintaining an IPv6 network with things like link local addresses and proper DNS resolution and multiple firewall translations isn’t worth it to you and your customer base, then stay where you are. No one will come to your office and put a gun to your head to make you move. The issues we have with address space exhaustion inside enterprises are a wholly different animal than keeping the small office going. Honestly, you folks will stay in business for years to come serving a subset of the Internet populace. There may come a time when there is an  opportunity cost of being able to reach new customers that are IPv6-only, but that cost will either be balanced by the need to trade out your “low cost” equipment for something that will run newer IPv6 features or it will be balanced out by your need to get any business to offset falling revenues due to IPv6-only customers no longer being able to reach your site on IPv4.

If you’re an SME/B network admin that’s still reading this, I’d highly recommend that you take a moment to think about something though. Is IPv6′s insistence on one-to-one communications and move away from NAT really disrupting the way the Internet works? Or is it moving back to the way things were before? Setting right what once went wrong? One of the funny things about information technology that I’ve noticed can best be summed up by a quote from the new Battlestar Galactica, “All of this has happened before. All of this will happen again.” Think about mainframes. We used to do all of our work from a dumb terminal that gave us a window to a large processing system that housed everything. Then we decided we didn’t like that and wanted all the processing power to live locally in minicomputers and client/server architecture. Now, with the advent of things like virtualization and virtual desktop infrastructure (VDI), we’ve once again come back to using dumb terminals to access resources on large central computers. All of this has happened before. And when we get constrained on our big hypervsior/VDI servers, we’ll go right back to decentralized processing in a minicomputer or client/server model once more. All of this will happen again.

In networking, we moved from globally routable address space on all of our nodes to running them all behind a translated boundary. At first we did it to prevent exhaustion of the address pool before a suitable replacement was ready. But as often is the case in networking (and information technology for that matter), we patched something and forgot to really fix the problem. NAT became a convenient crutch that allowed network admins to not have to worry about address renumbering and creating complex (even if appropriate) firewall rules. I’m just as guilty of this as anyone. It was only when I realized that many of the things that I want to do with networking, such as video conferencing, require more effort to work with NAT than they would otherwise. We spent so much time trying to patch things to work with the patch that we forgot what things looked like before the patch. I’d argue that getting back to end-to-end communications to “fix” protocols like SIP and FTP is just as important as anything. Relying on Skype to do VoIP/video communications just because it doesn’t care about NAT and firewalls isn’t good design. It’s just an inexpensive way to avoid the problem for a little longer. The funny thing about IPv6 is that while there is a huge amount of configuration up front and a lot of design work, when things are configured correctly, stuff just works. Absent of a firewall in the middle, I can easily configure an end-to-end connection directly to a system. Before you say that something like that is only important to an enterprise, think about something like remotely supporting a small office. I no longer have to poke holes in firewalls and create one-to-one NAT translations to remotely connect to servers. I can just fire up my RDP client (or your screen sharing tool of choice) and connect easily. No fuss, no muss, and no NAT needed.

I’ve also said before that I now see that there is a use case for Network Prefix Translation (NPT). Ivan has talked about it before and showed me the light from the networking side. Ed Horley has also given me a perspective from the Microsoft side of things that has changed my mind. But exhorting NPT as a solution to all of our NAT problems in IPv6 is like using a butter knife as a screwdriver. NPT was designed to solve one really huge issue – IPv6 multihoming. Announcing address space to two different upstream providers, which is easier to do with NAT in IPv4 than it currently is in IPv6 absent of the solution provided in RFC6296. NPT for multihoming is a good idea in my mind because of the inherent issues with advertising multiple address spaces to different providers and configuring those addresses on all the internal links in an organization. I also believe that NPT is a transition mechanism and will allow us to start “doing it right” down the road when we’ve overcome some of the thinking that we’ve used with IPv4 for so long. One-to-one NAT makes no sense to me in IPv6. Why are you hiding your address? The idea is that the device is reachable, whether it be a web server or a video conferencing unit. Why force a translation at the edge for no apparent reason? Is it because you don’t want to have to re-address your internal network devices?

Absent the aforementioned multihoming issues, let’s talk about renumbering for a second. How often to you really renumber your internal network? At the company that I work for, we’ve done it once in ten years. That’s not because we were forced to. It was because we ran out of space and needed to move from a /24 to a /23 (and now maybe to a /22). We didn’t even renumber half the devices in the network. We just changed a couple of subnet masks and started adding things in new subnets that were created. Now, granted, that was with an RFC1918 private address space internally. However, with SLAAC/DHCPv6 and IPv6, renumbering isn’t that big of a pain. You just change the network ID that is being handed to your end nodes. Thanks to EUI-64 addressing, the host portion of the address won’t change one bit. And Trevor Pott points out in the article that enterprises assume that DNS resolution will take care of the changeover just before he snorts derisively about how no one has managed to make it work yet. I’d argue that he’s more right than he knows. I have the IP addresses of hundreds of customers memorized. Most of them are RFC1918. Some are not. All of them are dotted decimal octets. I know that when I move these customers to IPv6, I will be relying on DNS resolution to reach these end nodes. My days of memorizing IP addresses are most definitely coming to a middle. And for those that might scoff at the ability of a DHCP server to register and maintain a database of DNS-to-host address mappings, you might take a look at what Active Directory has been doing for the last twelve years. I say that because in my experience, many SME/B networks run some form of Microsoft operating systems, even if it is just for directory services.

I’d like to take a moment to talk about “small” enterprises versus “large” enterprises. For most people, the breaking point is usually measure in costs or in devices. As an example, if you have more than 1000 devices, you’re large. If you have less than 50, you’re small. Otherwise, you’re in the middle (medium). Me? I don’t like those definitions. 10,000 devices in a flat Layer 2 network is (relatively) simple. A 10-person shop doing BGP multihoming and DMVPN is more of an enterprise than the previous example. For those networking admins that are running tens or even hundreds of servers, ask yourself what you really consider yourself to be. Are you a small enterprise because you have a Linksys/D-Link/Netgear Swiss Army Box at your edge? Or are you really a medium-to-large enterprise because of what you’re doing with all that horsepower? Now ask yourself if you want your network to be easy to configure because that’s the way networks should be, or is it really because you’re understaffed and running far more infrastructure that you should be? I’m not going to sit here and say that you just throw more people at the problem. That’s never the right answer. In fact, it’s usually the one that gets you laughed at (or worse). Instead, you should examine what you’re doing to see why wholesale renumbering or network changes are even necessary in the first place. One of the main points of the article is that IPv6 will allow network admins to finally be able to create hundreds of VMs on a single physical server and make them reachable from the global Internet. I would counter with the idea that if the only thing truly holding you back from doing that has been address space, the SME/B that you work for has really been a large enterprise wolf in small enterprise sheep’s clothing all along.

Now, if you’re still with me this far you should congratulate yourself. I’ve expounded a lot of thoughts about the technical reasons behind the way IPv6 behaves and why there are difficulties in applying it to the SME/B. I also wrote all that in isolation on an airplane. As soon as I stepped off and got my Internet lifeline back, I checked up on the original article and noticed that Trevor Pott had clarified his original intent at the bottom of the post with a long comment. Being no stranger to this myself, I read on with measured intent. What I came away with galvanized my original thoughts even further. Allow me to restate my original point a little more pointedly:

If “cheap” and “simple” are your two primary design goals, IPv6 probably isn’t for you.

We’ve gone through this whole problem before in the infancy on the Internet. Last year, Vint Cerf gave a talk at Interop about the problem of protocol adoption.  One of the stories I love from this talk involved Mr. Cerf’s attempt to spur the adoption of TCP/IP over the then-dominant NCP protocol. He needed to drive people away from NCP, which wouldn’t scale into the future, and force them to adopt TCP/IP. But adoption rates plateaued quite often as network operators just became comfortable that NCP would always be there to do all the work. Mr. Cerf eventually solved his adoption issues. How did he do it? He turned off NCP for a couple of hours. Then for a day. Then for a week. He drove adoption of a better protocol through sheer force of will and an on/off switch. Now, we all know that we can’t do that today. The Internet is too vital to our global economy to just start shutting things off willy-nilly. Despite that, “cheap” and “simple” aren’t design goals for the Internet core or even the ISP distribution layer. We have to have a protocol that will scale out to support the explosion of connected devices both now and in the coming years. Enterprise providers like Cisco and Juniper and Brocade are leading the charge to provide equipment and services to support this in-state transition. There will be no shutdown of IPv4. This is a steady-state parallel migration to IPv6. These kinds of things don’t come without a cost of some kind. It may not be in the form of a purchase order for a new network core. It may not even be in the form of a service contract to a consultant to help engineer a renumbering and migration plan. The cost may be extra hours reconfiguring servers. It may be taking more time to read RFCs and understand the challenges inherent in reconfiguring the largest single creation in the history of mankind at a fundamental level.

Economies of scale are a good thing. They bring us amazing products every day. They also enable us to spend less time configuring or working and spend more time on creating solutions. The first time you tried to ride a bicycle was probably difficult. As you practiced and progressed it became easier. Soon, you could ride a bike without thinking about it. You might even be able to ride a bike with holding the handlebars or ride it standing on the seat (I never could). That kind of practice and refinement is what is needed in IPv6. We have to make it work on a large scale first to get the kinks worked out. Every network vendor does this. Yes, even the ones that only sell their wares at the local big box retailer. Once you can make something work on a big scale, you can start winnowing down the pieces that are necessary to make it work on the small scale. That’s where “cheap” and “simple” come from. No magic wand. No easy button. Just hard work and investment of time and money.

Tom’s Take

Spurring us “priestly” networking people to change the way things work is a very valid goal and should be lauded. Doing it by accusing us of being obstinate and condescending is the wrong way to do things. I don’t consider myself to be a member of the Cabal of IETF High Priests. I’m not even a member of the IETF. Or the IEEE. I’m a solutions guy. I take what the academics come up with and I make it work in real life. Yes, much like Trevor Potts, I’m a blogger. I like to take positions on things and write interesting articles. Yes, I lampoon those that would seek to hobble a protocol I have high hopes for with thinking from fifteen years ago for the sake of making things “simple”. I’d rather be spending my time working on ways to reduce the time and effort needed to roll out IPv6 everywhere. I’d rather focus on ways to make it easier to renumber the “hundreds” of VMs I typically see at my local small business. In the end, I want what everyone else wants. I want an Internet that works. I know that it may take the rest of my career to get there. But at the end of the day, if I’m forced to choose between making the best Internet I can for the sake of everyone or making it “cheap” or “simple”, then I’ll sacrifice and pay a little more in time and costs. It’s the least I can do.

IPv6 Wireless Support – The Broadcast Problem

Posted on by
1

When I was at Wireless Field Day 2, my standard question to all the vendors concerned IPv6 support.  Since I’m a huge proponent of IPv6 and the Internet will be arriving at IPv6 rather soon, I wanted to know what kind of plans the various wireless companies had for their particular flavor of access devices.  Most of the answers were the same: it’s coming…soon.  The generic response of “soon” usually means that there isn’t much demand for it.  It could also mean that there are some tricky technical challenges.  My first thought was about the operating system kernels being run on these access points.  Since most APs run some flavor of BSD/Linux, kernel space can be a premium.  Based on my own experiments trying to load DD-WRT on Linksys wireless routers, I know that the meager amount of memory on these little things can really restrict the feature sets available to network rock stars.  So it was that I went on thinking about this until I had a chance conversation with Matthew Gast (@MatthewSGast) from Aerohive.  Matthew is the chair for the IEEE 802.11 committee.  Yes, that means he’s in charge of running the ship for all the little subletters that drive wireless standards.  I’d say he’s somewhat familiar with wireless.  I spent some time at a party one night talking to him about the challenges of shoehorning IPv6 support into a wireless AP.  His answers were rather enlightening and may have caused one of my brain cells to explode.

Matthew started things off by telling me about wireless keys.  If you pick up Matthew’s book 802.11 Wireless Networks: The Definitive Guide, you can flip over to page 465 to read about the use of keys in wireless.  Keys are used to ensure that all the traffic flying around in the air between clients stays separated.  That’s a rather important thing when you consider how much data gets pushed around via wireless.  However, the frames that carry those keys are limited in the amount of space they have to carry key information.  So some time ago, the architects of 802.11 took a shortcut.  Rather than duplicating key information over and over again for every possible scenario, they decided to make the broadcast key for each wireless client identical.  This saved space in the packet headers and allowed the AP to send broadcasts to all clients connected to the AP.  They relied on the higher layer mechanisms inherent in ARP and layer 3 broadcast control to prune away unnecessary traffic.  Typically, clients will not respond to a broadcast for a different subnet than the one they are attached to.  The major side effect is that clients may hear broadcasts for VLANs for which they are not a member of.  For the most part, this hasn’t been a very big deal.  That is, until IPv6 came about.

Recall, if you will, that IPv6 uses multicast mechanisms to propagate advertisements about neighbor discovery and router advertisement (RA).  In particular, these RAs tell the IPv6-enabled clients about available routers that can be used to exit the local network.  Mulitcast is a purely layer 3 construct.  At layer 2 (and below), multicasts turn into broadcasts.  This is the mechanism that ensures that non-layer 3 aware devices can receive the traffic.  Now, think about the issue above.  Broadcast keys are all the same for clients no matter which VLAN they may be attached to.  Multicast RAs get converted to broadcasts at layer 2.  Starting to see a problem yet?

Let’s say that we have 3 VLANs in a site, VLAN 21, VLAN 42, and VLAN 63.  We are a member of VLAN 63, but we use the same SSID for all 3 VLANs.  If we turn on IPv6 for each of these three VLANs, we now have 3 different devices sending out RAs and SLAAC packets for addressing hosts.  If these multicast packets are converted into broadcast packets for the SSID, all three VLANs are going to see the same broadcast.  The VLAN information is inconsequential to the broadcast key on the AP.  We’re going to see the RAs for the routers in VLAN 21 and VLAN 42 on top of the one in VLAN 63.  All of these are going to get installed as valid exit points off the local network.  As well, the end system may even assign a SLAAC address to itself with a router from a different VLAN.  According to the end system, it heard about all of these networks, so they must all be valid, right?  The system doesn’t know that it won’t have a layer 2 path to them.  Worse yet, if one of those RAs has the best metric for getting off the local LAN, it’s going to be the preferred exit point.  The end system will be unable to communicate with the exit point.  Bummer.

How do we fix this problem?  Well, the current thinking revolves around suppressing the broadcasts at layer 2.  Cisco does this by default in their wireless controllers.  The WLAN controller acts as a DHCP relay and provides proxy ARP while ignoring all other broadcast traffic.  That’s great to prevent the problem from happening right now.  What happens when the problem grows in the future and we can no longer simply ignore these multicast/broadcast packets.  Thankfully, Matthew had the answer for that as well.  In 802.11ac, the new specification for gigabit speed wireless, they’ve overhauled all the old key mechanisms.  No longer will the broadcast key be shared among all clients on the same AP.  Here’s hoping that we can get some 802.11ac clients and APs out there and supported when the time comes to flip the big switch to IPv6.

I’d like to thank Matthew Gast for his help in creating this blog post and pointing out the problems inherent in broadcast key caching.  I’d also like to thank Andrew von Nagy (@revolutionwifi) for translating Matthew’s discussion into terms a non-wireless guy like me can understand.

Nerd v6 – My First IPv6 Tunnel

Posted on by
7

Home - Courtesy of ThinkGeek (Click to buy this shirt!)

I realized the other day that I’ve done a lot of IPv6-related posts in the past few months, but for one reason or another I keep putting off setting up my own IPv6 presence.  I signed up for a free IPv6 tunnel from Hurricane Electric’s Tunnel Broker service almost a year ago.  However, the Cisco Valet Plus router I have running my home network has zero support for IPv6, let alone tunnels.  Because of that little omission, my tunnel sat unused for a while, gathering 128-bit dust.  As the end of the year approached, I found myself with some extra time on my hands and a bit of spare gear thanks to my local Cisco office.  I decided that maybe it was time to turn up my IPv6 nerdiness to the next level.

I found an old 2821 in my lab that wasn’t serving an immediate purpose.  I erased it and reconfigured it to serve as a gateway for my IPv6 setup.  I logged back into my account at tunnelbroker.net and found that I could create up to 5 tunnels for free.  Who in their right mind would turn that down?  I created a new tunnel for my lab environment.  In this interface, you would create a regular tunnel for basic connectivity.  You input your IPv4 address as one side of the endpoint.  HE.net provides the IP that you’re coming in on if you wanted to set this up with a home connection, for instance.  In my case, I already had a global IPv4 address ready to go.  However, the router wasn’t all the way up yet.  If HE.net can’t ping your IPv4 tunnel endpoint, they won’t reserve the address space.  So:

Tip #1: Don’t start setting up your tunnel until you’ve got your gateway ready.

I picked the closest endpoint to my geographic area – Dallas, TX.  Once the router came all the way up and the ARP caches had settled down, I registered my new tunnel without a hitch.  HE.net provides you with a /64 for your tunnel interface.  ::1 is an interface on their side, ::2 is an interface to assign to your tunnel.  They also provide you with an entirely different /64 to setup for your client devices behind your router/firewall.  If you’re wanting to bring more than one site online, you can even register for a /48.  That’s 1.20892582 × 10^24 addresses.  Per tunnel.  That’s a lot for nothing!

My first attempt with Dallas didn’t work out so well.  For some reason, I couldn’t ping the other side of my tunnel.  I gave it about 15 minutes and then gave up.  I tore down the tunnel and created a new one.  If you’re going to do that, give the HE.net servers about 5 minutes to clean up their side of things, since the tunnel creation script will think that you’re  trying to register an endpoint twice.  I picked a nice little sunny patch of hex addresses in Fremont, CA and this time it worked!  I was able to ping from one side of my tunnel to the other.  For reference, this is the sample config they gave me for the tunnel and it worked quite nicely:

interface Tunnel0
 description Hurricane Electric IPv6 Tunnel Broker
 no ip address
 ipv6 enable
 ipv6 address <Your Tunnel /64 Endpoint>
 tunnel source <Your IPv4 Interface>
 tunnel destination <HE.net's IPv4 Interface>
 tunnel mode ipv6ip
ipv6 route ::/0 Tunnel0

Easy, right?  Once that’s up and running, you can configure the other interface of your router with the routed /64 or /48 they assign you.  I’d suggest starting with the /64 first to get your feet wet.  There is one other piece of configuration you need to enable that seems to be the cause of many issues on HE.net’s forums when configuring Cisco devices.  You need to enable IPv6 routing with this command:

ipv6 unicast-routing

Tip #2: Don’t forget to enable IPv6 routing.

Now that you’ve got two sides up and running and routing between each other, you should be able to launch some packets toward the Interwebz v6.  HE.net sets you up with an IPv6 DNS server you can plug into your devices to test connectivity.  If you want to be able to ping ipv6.google.com from your router, be sure to enter this command:

ip name-server 2001:470:20::2

Now you can test to your heart’s content.  When you’re sure that your tunnel is going to stay up, you need to concentrate on getting desktops working.  That’s where the routed /64 comes into play.

HE.net gives you an additional routed /64 that is different than the tunnel address for the purposes of setting up a site for IPv6.  Most networking people know that you must have two different subnets on the router for routing to occur.  Yet, on the HE.net forums I see a lot of people that are configuring their routers with addresses from the tunnel /64 subnet.  Save yourself the headache and use the other /64 to get started.

The easiest way to setup your client device with an IPv6 address is good old fashioned static addressing.  This is very easy to do in both Windows and OS X.  Lucky for you that both of the latest versions of those OSes have IPv6 enabled by default.  You just have to click on the option for IPv6 and assign a static IP.  You should also use the HE.net IPv6 name server listed above to allow you to resolve addresses like ipv6.google.com.  I tested with an OS X Lion server and was able to get the machine running on a static IP with no real issues.  I gave my Windows 7 workstation an IP in the same range and they were able to happily ping each other with no problems.  I think I’m going to take another post to talk about the fun of configuring DHCPv6 and SLAAC on my tunnel, as that has caused me a bit of heartburn so far making everything play nice with other people’s ideas about security.

Speaking of security…I would be remiss if I didn’t end this little article without a discussion of securing your new tunneling router from the nastiness on the Internet.  I found a great access list on the HE.net forums and thought I’d share it with you:

ipv6 access-list internet_inbound_ipv6
 remark Permit IPv6 Link-Local & Multicast
 permit ipv6 FE00::/7 any
 remark Block IPv6 Bogons
 deny ipv6 ::/3 any
 deny ipv6 4000::/2 any
 deny ipv6 8000::/1 any
 remark Block own assigned IPv6 space
 deny ipv6 <Your HE.net /64>::/64 any
 remark Block anything going to Windows RPC
 deny tcp any any eq 135
 permit icmp any any
!
ipv6 access-list internet_outbound_ipv6
 remark Prohibit any contact with Windows RPC-NetBIOS
 deny tcp any any eq 135
 deny tcp any any eq 137
 deny tcp any any eq 138
 deny tcp any any eq 139
 deny udp any any eq 135
 deny udp any any eq netbios-ns
 deny udp any any eq netbios-dgm
 deny udp any any eq netbios-ss
 remark Allow traffic from own assigned IP space
 permit ipv6 <Your HE.net /64>::/64 any

Of note here, remember that in IPv6, ICMP does a lot more than just pings.  Read RFC4890 for a lot more info on the subject, but right now I’m just allowing the whole stack in.  If you want to permit traffic to servers for things like HTTP or SMTP, be sure to add those servers at the end of the Inbound ACL so the traffic doesn’t get dropped.

Tom’s Take

One of the things that impressed me when I started troubleshooting some of the issues with my HE.net tunnel was the help that people were more than willing to give in the HE.net forums.  Especially where they helped their brethren with things like establishing connectivity.  Lots of posts about being able to ping router tunnel endpoints and things like that.  It shows that setting up your own IPv6 presence isn’t really that hard and should allow you to get out on the wider Internet with IPv6 in short order.  Thanks to all the work that other’s have been more than willing to share, I had an easier time than many.  I just hope my examples here help someone to get their tunnels up and running.

What’s The Point of NAT66?

Posted on by
61

Frequent visitors to this site know of my crusade against all things Network Address Translation (NAT).  Despite its few useful properties and our current reliance on it with IPv4, I consider it to be a kludge at best.  However, some people see NAT as a necessity of modern networks and have begun working hard to ensure that NAT will live on with our shift to IPv6.

I realize that NAT is a necessary evil today.  The IPv4 Internet would have imploded long ago without translating the meager number of prefixes available into the large number of “private” devices sitting behind NAT gateways.  IPv4 is the duct tape that has held things together for the last ten years while we prep a long term solution like IPv6.  Alas, some people in the community think that since NAT has done such a good job fixing things for so long that it should be the all-in-one tool in their toolbox for every network problem.  Some people think it’s a great way to provide security for a network.  These people often confuse NAT with what a firewall does in conjunction with NAT.  NAT in and of itself provides no additional security beyond masking addresses.  NAT also adds in additional complexity when troubleshooting.  NAT boundaries break things like VoIP.  Packets hit the gateway device and get lost headed back to the source.  NAT does this for almost every form of end-to-end communication in the Internet.  If you add in Port Address Translation (PAT), where you translate a whole block of private addresses to one public IP address, you push the processor on your firewall to the breaking point.  I don’t have the hard numbers to prove my supposition, but I’d venture a guess that 50% of a firewall’s processor time is spent translating NAT/PAT rather than shuffling packets to their proper destinations.

IPv6 doesn’t currently have a concept of direct address translation.  Nor does it need one. There isn’t a dwindling pool of global addresses than need to be extended.  With the large amount of addresses available, the odds that two companies are going to have overlapping address spaces that will need to be translated in a merger are slim.  Right now, the only viable use case I can see for NAT used in relation to IPv6 is for translating the IPv6 addresses on a network to something that can access the IPv4 Internet without a dual-stacked router (NAT64).  Even this use case is rather dubious in my mind, but Ivan has managed to convince me that it’s useful in the short term.  So why do I still hear about RFC 6296? Why does Jeff Fry point out stories like this to me?  What is this world coming to?  Let me make this clear:

NAT on IPv6 is pointless and a bad idea.

There is no reason to implement native IPv6-to-IPv6 NAT (NAT66) in reality.  The address space is way too big to require translation in the foreseeable future of my lifetime or even that of my kids.  If you are really concerned about hiding your addresses or disguising your MAC address, you can look into the idea of Temporary Addressing.  In the middle of writing this post, Paul Regan asked me about using NAT to translate when you move from one provider to another.  That might be a good use case, and it happens to be the one that RFC 6296 is lined up to address, but if keeping your IPv6 space is so important when you move, why not sign up for a provider-independent block from your local Regional Internet Registrar (RIR) and run BGP to advertise it yourself?  If you switch ISPs often enough to keep switching IP schemes every few months, maybe you need to worry more about stability and less about chasing the lowest ISP price.  If your ISP keeps forcing you to switch addressing space that often, it might be time to shop around.

I truly believe that the people out there chasing the NAT66 sasquach are looking for a new security blanket.  They’ve dealt with NAT for so long in IPv4 that the idea of using IPv6 sans NAT makes them lie awake at night in a cold sweat.  Why else would you take something so unnecessary and bolt it on after the fact?  There’s no need to have NAT unless you take the position “it’s how we’ve always done it”.  The NAT66 proponents must think that NAT is needed simply because they’re unsure how to configure a firewall otherwise.  Obviously, without NAT the Internet breaks.  So we must have it in IPv6 or things won’t work right.  However, I think that having NAT66 will cause people to keep configuring their networks incorrectly and lead to confusion and problems down the road.  If IPv6 is going to require a shift in thinking like so many people keep telling me, why not truly shift our thinking away from things like NAT?  We’ve already done it once before with the concept of reserved local addresses.  RFC 1884 tried to define a site local address similar to what we think of with RFC 1918 addressing.  This was such a horrible idea that RFC 3879 came out and deprecated the whole idea (Yes, I know about RFC 4193.  I’m not talking about it.)

If there are people out there that think we still need to cling fervently to old ideas to help ease our transition to the Internet of the Future™, then I’m going to make my own proposal.  I think it’s time that we put the IP checksum field back into the IPv6 header.  Yes, I know that TCP has its own checksum and that the underlying packet must be good if the TCP checksum comes out okay.  Yes, I know that having a checksum in the IPv6 header is silly if there aren’t going to be any naked IP packets floating around anywhere.  However, I think that since it’s always been there in IPv4 it’s comforting to have it available in case I want to double check each of the packets moving into and out of my network.  Who cares if it introduces a small amount of latency to calculate?  I feel better knowing it’s still there.  Now, doesn’t that kind of thinking sound silly?  Yes, I purposely picked something totally trivial to make my point, but that’s how I feel about NAT.  If we want to move forward out of the IPv4 Dark Ages and into the realm of the IPv6 Renaissance, we need to leave behind childish things like the need to NAT IPv6 packets on IPv6 networks.  Let’s spend more time making the Internet work the right way and less time trying to make it work the way we think it should.

Motivating for Enterprise IPv6 Adoption

Posted on by
4

Firstly, head over to Packet Pushers and read Ethan’s excellent blog post about The Reason Enterprises Aren’t Deploying IPv6.  This post made me start thinking about IPv6 adoption, especially in light of the things I talked about almost 8 months ago in front of a group of education IT professionals.  In his post, Ethan discusses the problem with IPv6 in the enterprise from the perspective of it being more trouble than it’s worth right now.  I agree with him that there are a lot of issues to overcome today for very little immediate gain.  Today’s IPv6 implementations are still relegated to a lab or to the IT department network where they can be contained and properly tested.  I’d wager that Hurricane Electric tunnels is the most common method of IPv6 support right now.  It’s still very much a “hobby kit” type of implementation where the nerd spends several hours pouring over documentation and expends energy typing furiously at a dimly lit console only to finish up and say, “Cool.  It works.”  No fanfare, no raise.  Just the satisfaction of a hard job well done.  So how do we change that?

In college, I studied Management Information Systems, which is a fancy way of spelling Database Administrator.  I promptly forgot all my DBA training, but the Introduction to Database class was a goldmine of information thanks to my wonderful professor, Dr. Traci Carte.  She once told me that there are basically two ways to motivate people in business: fear and greed.  The more time I spend in the business world, the more I see that she had a good point.  Those two emotions tend to be pretty strong and are great motivators for people that wouldn’t ordinarily be compelled to take action.

When it comes to IPv6, we’ve already tried to motivate through fear.  If you remember any of the headlines from earlier this year you’ll agree that the Chicken Little mentality of the IPv4 sky falling down on us was reaching a fever pitch quickly.  It even made the local nightly news, which of course made my mom call and wonder when her computer was going to blow up.  Unfortunately, fear didn’t work here.  Why not?  Because there wasn’t a consequence.  It’s like announcing that an asteroid is going to hit the earth tomorrow.  If we make to the end of the day and no big rock comes down in our front yard, we just go back to life as it was.  When ICANN depleted their IPv4 prefixes and the Internet just kept working the next day, the rank-and-file users went right back to watching cat videos on Youtube without a care in the world.  After all, how bad can this problem be if there are still cat videos?

I think it’s time we move to motivator #2 – greed.  Greed, for lack of a better word, is good.   And greed can work for you.  IPv6 isn’t a compelling case when you tell your boss that most everyone can still use the Internet with no issues.  The key is that “most everyone” statement.  As APNIC and ARIN begin to deplete their reserves of IPv4 prefixes, the cost to acquire them will start skyrocketing.  For those not willing to pay a king’s ransom for a /28, there has to be an alternative.  Based on my distaste for things like carrier-grade NAT or NAT64, I would hope that pure IPv6 prefixes would start to be handed out.  Assuming that NAT64 does end up getting used as a necessary evil for those newly-minted prefixes, are we to assume that it’s going to work all the time?  What happens when there are hiccups or outages?  Only pure IPv6 sites will be available.  Right now, that’s Facebook or Google.  Greed comes into play when you can convince your decision makers to implement IPv6 to reach those customers.  If your widget is the only one those IPv6-only users can find when they search http://ipv6.google.com then you are going to have a competitive advantage over everyone else.  This might be a wash up front when you think about the costs needed to plan and implement IPv6 versus the additional revenue from those IPv6 only users.  However, we aren’t going to slow down our ravenous consumption of IPv4 addresses any time soon.  As more and more customers come online with native IPv6 support, they’re going to be surfing an Internet where you don’t have a presence.  First-to-market has a whole new meaning here.

Another avenue of greed to appeal to is the ego of a company and its decision makers when it comes to IPv6 implementation.  The same kind of mentality that drives executives to drive fancy cars and wear expensive accessories can be manipulated to drive adoption of new protocols.  Comments like, “Wouldn’t you like to be known as the first CxO to make their website ready for IPv6 in this market?” or “I hear that <competitor> is working on an IPv6 implementation and I’d like to beat them to it.” work on the ego of people that love attention and want to be known as leaders in their industry.  Giving them another headline or accolade plays right into their desire for recognition and gets you the time and resources needed to plan your implementation of IPv6.

Tom’s Take

This may seem a little like gamesmanship to some.  You may disagree with me boiling things down to simplistic terms.  You may even think I’m a bit crazy for thinking that someone can be manipulated into implementing new technology solely by appealing to their desire for money and recognition.  However, until a real business case materializes for IPv6, it won’t really get implemented.  And until it is more pervasive, real business cases won’t materialize.  A classic Catch-22 scenario.  Something has to give.  It’s time to draw a line in the sand.  Maybe I have to spend a little more time stroking egos or building a compelling business case instead of typing away on a keyboard or working in Visio.  If I can drive IPv6 implementation along by playing a few head games now and then, I think I can sleep well at night knowing I made the world a slightly better place one /48 at a time.