The Sky is Falling – oh no it’s worse, IPv4 addresses are running out! That was they key message in the latest Cisco campaign that utilized an integrated social media approach to get its message across. Video was the anchor of this high touch campaign which involved the viewers by allowing them to select the ending of the story and drove them to the Cisco landing page. However it was the integrated social media approach that really set this campaign apart and is the type of planning that should go into every social campaign. One key success factor was that they tapped into existing communities – the Cisco myPlanNet campaign (which by the way was the winner for the B2B integrated social media awards last year had a following in the tens of thousands and rather than start a new community the team tapped into this community to spread awareness about the IPv4/IPv6 campaign. Other existing communities on Twitter, LinkedIn and even Cisco’s Support Forum were also leveraged in addition to blogging about it on the Cisco Service Provider blog.
The results – over 50,000 video views in the first three months – the second most viewed Service Provider video of all time after the first four months! It’s no wonder that this campaign was a runner-up in the B2B integrated social media awards category; congrats to EMC for winning first place for their mega launch! It’s also worth mentioning that Cisco did take home the first place spot for the viral video category which I posted about last week – you can read about it here!
To get the back story of this campaign I was able to meet with Stephen Liu, Senior Manager of the Service Provider Marketing team who was yet again the mastermind behind this successful production. Stephen provides an overview of the campaign, shares some of the impressive metrics and ends with some best practices which he believed led to the success of this campaign (hint: humor and tapping into established communities!). Check it out!
When faced with a life changing situation such as the depletion of the IPv4 address space, the emotional reaction tends to track the Kübler-Ross model, better known as The Five Stages of Grief.
DENIAL: There is no crisis! There are lots of IPv4 addresses; we just need to reclaim the ones that are not used.
The increasing consumption rate of IP addresses combined with the natural inefficiencies inherent in IPv4 subnetting makes complete exhaustion of the IPv4 address space inevitable. In October 2010, a return of a “/8 block” (16 million addresses) added only one month to the depletion date. As of April 2011, the Asia-Pacific region alone consumes two /8 network blocks every month. No amount of conservation or reclamation can solve the problem.
ANGER: What a stupid design! How could we run out of addresses?
Vint Cerf sends his most sincere apologies. Nobody imagined the phenomenal growth of the Internet when Vint and his team defined the 32-bit IPv4 address space back in 1977. The good news is that the problem has been recognized since the 1980s and the IETF has had the successor IPv6 protocol defined since 1998. You can take advantage of more than a decade of experience in navigating this transition.
In the previous installment of our series of IPv6 security posts, we covered some of the ways addressing has changed in IPv6 compared to IPv4. In this post, we’ll talk about some of the things to consider when securing IPv6 compared to IPv4. Before digging into this topic, however, it is important to remember that while IPv6 may have different security concerns than IPv4, it is not necessarily any more secure than IPv4. Furthermore, the post will focus on those aspects that are different or unique to IPv6, since many of the common best practices for IPv4 networks also apply to IPv6 networks.
A few years back I set up IPv6 connectivity on my home network for the first time. I had a rush of exhilaration when the first ping and traceroute commands completed successfully. Suddenly, I was free of Network Address Translation and bypassing my firewall, connecting directly to any IPv6 device on the Internet. But then it slowly dawned on me that those people same people could also directly connect to my device! In a panic, I wondered if my SMB shares were visible to the world, or if criminals could relentlessly probe my open ports for zero-day vulnerabilities. How could I even check if I had any open ports? My fear got the best of me and I disabled IPv6.
I contacted my friend Dan and posed my dilemma to him. How could I tell if my ports were locked down on a machine which ran IPv6? A number of sites provided port scanners for IPv4, but nobody had a general purpose scanner for IPv6. Hurricane Electric provided one, but only for devices that were on their network. Dan hacked up a primitive IPv6 open port testing site, which uses NMAP to scan an IPv6 visitor for typically vulnerable ports before issuing a simple report. I was pleased to discover that my computer did not answer on any of those commonly attacked ports.
In this process, I discovered that many modern operating systems with IPv6 enabled also come with a set of reasonable host firewall defaults which do not expose listening ports as much as I had expected based on my experience with IPv4. Many hosts with IPv6 enabled by default also come with some very sensible settings to prevent network-launched crimes of opportunity from malicious users.
IPv6 also provides a natural defense against classic portscanning attacks, where an attacker probes for commonly vulnerable ports of every IP address on a subnet. For densely packed IPv4 service provider networks with one IP address assigned per typical user, a few thousand probes across a known DSL or cable subnet can yield a rich collection of potential targets. Since the address space of IPv6 is so much larger and sparsely populated than IPv4, blind portscanning of subnets becomes impractical since a typical IPv6 subnet contains quintillions of addresses hosting a relatively small number of end devices.
From my home network, I can successfully ping or traceroute to some IPv6 hosts, but I cannot subsequently open a web page or use other applications with it. How can this be? Maximum Transmission Unit (MTU) gotchas…
There is a subtle difference between IPv4 and IPv6 fragmentation strategies. IPv4 routers fragment traffic in the network when needed and then the receiving host reassembles those fragments. This generally works well, but there are a number of potential issues. Because of these issues, the IETF developed means for higher layer protocols such as TCP to determine the smallest MTU on a path and send appropriately sized datagrams in order to avoid fragmentation. The IPv6 designers presumed the presence of this Path MTU Discovery so that in IPv6, fragmentation no longer happens in the network but only at the hosts -- and then only in special cases in that absolutely require it.