System iNetwork

New Technology

October 17, 2005

Out of IPv4 Addresses in Five Years?

A recent report by Cisco networking guru Tony Hain predicts the end of IPv4 address space in about 2010, just five years from now. This is in contrast to the prior prediction of 2022 made by the Asian Pacific Network Information Center (APNIC). Why the suddenly sooner deadline? According to A Pragmatic Report on IPv4 Address Space Consumption, the APNIC report does not take into account the temporary growth slowdown of IP address allocations from 2000 to 2003 due to the dot-com crash. Since 2003, IP address allocations have accelerated dramatically.

Today a new /24 (formerly termed a Class C) block of 256 addresses is allocated to somebody every 30 seconds. At that rate, the Internet loses an entire /16 block (a Class B - 65,536 addresses) every two hours. That's 24/7 friends, and the rate is accelerating. Based on the current rate of growth, which Hain documents extensively in his report, we'll have allocated all IPv4 address space in just half a decade.

This prediction adds a new sense of urgency to the IPv6 migration debate. IPv6, which uses 128-bit rather than 32-bit addresses, provides essentially unlimited IP space. But switching the entire Internet over to IPv6 is an expensive undertaking, and many IPv6 opponents have argued that the original 2022 prediction meant that IPv6 is still far off. Some (whose initials are NSF) even say IPv6 is no longer necessary, proposing that we go back to the drawing board and design yet another IP addressing scheme, given that the IPv6 design is already 10 years old.

Hain says we don't have time for that, and his argument is persuasive. He uses the actual IP address allocation history from the Internet Assigned Numbers Authority (IANA) in his analysis, points out the reasons for the APNIC's previous rosy outlook, and explains why those reasons are no longer valid.

I'm often leery of statistical predictions because there are so many ways to lie with statistics. However, Hain bends over backward to be fair and transparent in his reasoning, and even gives the author of APNIC's report, Geoff Huston, a chance to respond in the same document. Huston's answer boils down to the two predictions being within the margins of statistical error. However, the difference between the two dates is significant: moving to IPv6 within five years means everyone needs to begin planning their migration strategy now.

Both authors agree that market forces will automatically curtail IPv4 growth at some point, by making IP addresses more and more expensive as the end approaches. Both also agree that this effect will not be good for business, and in the long run will be more expensive than the cost of moving to IPv6.

Both writers also point out that predictions presume that growth conditions remain as they are, which is almost certainly not likely to be true for the remainder of IPv4's lifetime. Already new network applications, such as mobile computing, are hungrily chewing through IP addresses. And many third-world countries have yet to get much of their populace on the Internet. Both of those foreseeable demands could exhaust IPv4 space even sooner than five years.

Conversely, there could be a growth-slowing technology collapse like the dot-com crash, but given the business lessons learned since 2000 that seems a foolish bet.

The report includes a lively and fascinating roundtable discussion between Hain, Huston, and Internet gurus John Klensin and Fred Baker. All participants concur that IPv4 has entered its end game, and the time has come to get serious about IPv6 migration.

Tony Hain's report A Pragmatic Report on IPv4 Address Space Consumption:
http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html

Geoff Huston's APNIC IPv4 Address Space Report:
http://bgp.potaroo.net/ipv4/

Here's a bonus goody. APNIC produced a movie showing the actual consumption of IP addresses over time, based on Internet routing table data. It's a fun, and frightening, look at the rate of IPv6 network growth:
http://www.potaroo.net/avi/comp.m1v

Posted by mbeckman on October 17, 2005 at 11:40 PM

September 29, 2005

Learn IPv6 Today; Hackers Are

One of the most interesting data points I took away from the recent 2005 North American IPv6 Technology Conference in San Jose is that IPv6 acceptance is growing rapidly in one unexpected "market segment:" the hacker community. Hackers are exploiting freely available IPv6 technology on Macintosh, Unix, and Windows systems to skirt around firewalls and other network security measures. There could be a hacker right now tunneled into your network over IPv6, and chances are your intrusion detection software isn't looking for them and thus can't see them.

In a correctly deployed IPv6 network, security is enhanced over the older IPv4 protocol, because address spoofing can be detected and tracked, and every IP session can be encrypted using IPSec. The operative phrase in the preceding sentence is correctly deployed. Many network administrators haven't given IPv6 a second thought, believing falsely that IPv6 will wait for them. But a slew of open-source programs and free services let hackers deploy IPv6 in your network without your permission, using the advanced protocol to sneak around IDS and IPS systems and to surreptitiously pump data to outside hacker lairs.

A hacker gains an IPv6 foothold using the standard virus and Trojan propagation techniques: contaminated e-mail, spyware, DNS poisoning, and phishing attacks. Once landed on a victim desktop computer, a hacker can enable IPv6 on that system and use IPv6's autoconfiguration facilities to acquire an IPv6 address on your network -- or simply make up an IPv6 address using the target machine's MAC address. If you don't currently have an IPv6 router on your network, the hacker can convert the victim host into one.

The vast majority of successfully penetrated desktop systems run Windows, and Windows 2003 and XP have IPv6 built in -- it only needs to be enabled using the netsh DOS command. Windows IPv6 supports a transition protocol called 6to4 tunneling, which encapsulates IPv6 packets in a special protocol envelope and routes them to a distant IPv6 gateway, where they're turned back into IPv6 packets. Most IDS systems don't recognize 6to4 packets, or don't report them as a security risk. 6to4 packets don't look like ordinary IP packets, because they use network protocol 41, rather than TCP (6) or UDP (17). Yet many networking components, and virtually all ISPs, will cheerfully route these packets without complaint. The only good news is that most NAT firewalls block everything except TCP and UDP, and thus filter out protocol 41.

Hackers have alternatives should they find 6to4 tunneling infeasible. Windows also supports another IPv6 transition mechanism, called Teredo, that encapsulates IPv6 packets in an IPv4 UDP envelope. These packets pass right through NAT firewalls without trouble, and can even be made to look like DNS queries, which virtually every firewall passes out unmolested. Teredo is also built into Windows XP, as well as being available in a number of open-source IPv6 migration tools.

IPv6 tunneling techniques give attackers a permanent, invisible conduit from the outside world directly to the heart of your network, just as if you ran a Cat-5 cable from some clerk's desk to the far side of your firewall. Worse, once a hacker awakens IPv6 in one workstation, server, or router, he can then enable IPv6 in dozens or hundreds of machines on the same LAN.

The only cure is to block both 6to4 and Teredo at your borders, and upgrade your IDS and IPS to watch for unauthorized IPv6 traffic on your LAN. Check with your security software vendor today for IPv6 sensing capabilities. The open-source Snort IDS has an experimental IPv6 decoder, and many commercial IDS systems use Snort under the covers, so you may be able to install IPv6 awareness yourself.

But most importantly, become IPv6 savvy by giving yourself a short course in this new networking technology. I tell you how in the Dr. I. Doctor entry Take IPv6 Out for a Spin and my review of O'Reilly's book IPv6 Network Administration.

Posted by mbeckman on September 29, 2005 at 9:57 AM

April 14, 2005

Take IPv6 Out for a Spin

After perusing O'Reilly's book IPv6 Network Administration (reviewed in Dr. I. Doctor March 31, 2005), I decided to see just how hard it is to get IPv6 up and running. Not hard at all, it turns out. Just a little reading, a free IPv6 connection from Hurricane Electric, and a few minutes tinkering with an old Cisco 2611 router put me on the IPv6 Internet with my own IPv6 address block. I can now surf to any IPv6 site in the world, and run an IPv6 Web server to boot! You can do it too, and you should.

IPv6 is coming, and I have a feeling that momentum is picking up. My experience getting IPv6 operational convinced me that this is one technology every network admin needs to learn. Today I'm starting a continuing thread describing my IPv6 experiences to encourage you to get your feet wet and save you the trouble of the mistakes I make. The first installment describes everything I did to get IPv6 connected.

What's your motivation for learning IPv6, other than to stay on the bleeding edge of network science? What motivated me is the realization that IPv6 is going to save me a lot of work down the road. IPv6 is actually much, much easier to administer than good ol' IPv4. It supports autoconfiguration, so you need never mess with IP address assignments, subnet masks, DHCP, DNS settings, etc., again! You can plug in any device -- even a server -- and have it automatically join an IPv6 network.

IPv6 also means you'll never run out of IP addresses. I know they say "never say never," but this is a provable exception to that rule. The smallest IP block assigned to a single network is sixty-four bits long. This is twice as many bits as the entire 32-bit IPv4 address space currently serving the entire Internet -- for one network! IPv6 also eliminates IP spoofing, which will be the end of spam, and has IPSec built-in, which lets you establish secure device-to-device communications without VPN software or hardware.

I'm only scratching the surface, but these benefits should be enough to whet your appetite. So let's get you on board.

I do my fair share of network scut work: replacing cables, configuring printers, troubleshooting DHCP failures, etc. I found setting up IPv6 no harder than configuring a managed Ethernet switch. All you need is a Cisco router, an IPv6-capable desktop computer (Windows XP or Mac OS X will do nicely), and a spare afternoon. You'll configure the Cisco router to serve as an IPv6 gateway, connecting to the IPv6 backbone via a VPN tunnel. You plug one side of the Cisco into your public Internet connection, and the other side into your test IPv6 LAN. Ordinary Ethernet switches and NICs suffice for your LAN equipment, which can be as simple as a single desktop or notebook computer.

Technically, you don't need the router, but I think using one makes a far more valuable testbed than directly connecting a computer to the IPv6 world. A dual-Ethernet Cisco 2611 will do nicely; you can buy these all day on eBay for under $300. Make sure you're running at least IOS version 12.3 (I used 12.3.13/IP: c2600-i-mz.123-13.bin), with 32MB RAM and 8MB flash.

Before configuring the router, sign up for free IPv6 connectivity via Hurricane Electric's (HE) slick IPv6 Tunnel Broker service. HE gives you a huge IPv6 address block and an unencrypted IPv6 tunnel directly to the HE IPv6 backbone. The tunnel and address space are free -- a public service of HE to help spread the IPv6 gospel. Just visit their site at http://ipv6.he.net, click on IPv6 Tunnel Broker, and follow the instructions. The process is fully automated; I had an IPv6 account in a few minutes. It takes about 24 hours for the tunnel to become operational, but you can start the next step immediately.

If you haven't already done so, this would be a good time to either buy O'Reilly's IPv6 Network Administration, or read it online at O'Reilly's Safari Bookshelf (http://safari.oreilly.com. The critical knowledge you need for now is in Chapter 3: Planning and Chapter 5: Installation and Configuration, but if you have time, read Chapters 1 and 2 to gain a basic knowledge of IPv6 terminology and address formats.

Now you're ready to configure the Cisco router. Here's the exact configuration I used. You should replace the IP addresses in this example with the ones for your own network and IPv6 tunnel. HE's Tunnel Broker actually generates the Cisco router configuration statements for the tunnel interface, so you can just cut and paste that into the listing below:

service nagle
no service pad
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
service password-encryption
!
hostname ipv6-gateway
!
logging buffered 100000 debugging
no logging console
!
ipv6 unicast-routing
ip subnet-zero
no ip source-route
ip name-server 4.2.2.1
!
interface Tunnel0
 description Hurricane Electric IPv6 Tunnel 
 bandwidth 10000
 no ip address
 ipv6 address 2001:470:1F00:FFFF::865/127
 ipv6 enable
 tunnel source 206.83.0.1
 tunnel destination 64.71.128.82
 tunnel mode ipv6ip
 no shutdown
!
interface Ethernet0
 description Public Internet side of the router
 ip address 206.83.1.254 255.255.255.0
 no shutdown
!
interface Ethernet1
 description My IPv6 LAN
 ip address 206.83.0.1 255.255.255.0
 ipv6 address 2001:470:1F00:1174::1/64
 no shutdown
!
ip classless
ip route 0.0.0.0 0.0.0.0 206.83.1.1
ipv6 route ::/0 Tunnel0
!
no ip http server
!
line con 0
 transport preferred all
 transport output all
 stopbits 1
line vty 0 4
 transport preferred none
 transport output all
!
end

Here are two gotchas to watch for. First, make sure that you include the IPv6 address block from HE in your router's LAN Ethernet IP address. My block is 2001:470:1F00:1174::/64, so I set the Router's LAN interfaced to the .1 address in that block: 2001:470:1F00:1174::1. If these addresses look bizarre to you, just skim through IPv6 Network Administration Chapters 1 and 2 and you'll get the hang of it.

The second take-care item is to be sure you get this statement:

ipv6 unicast-routing

into the router configuration. If you don't, the router won't route IPv6 packets. This requirement is emphasized in section 5.2.1 of the book, but I missed it the first time (the authors even warn that, "Everyone forgets to turn this on.").

After you've configured the router, you're ready to test. Plug the router's Ethernet0 port into your Internet connection and the Ethernet1 into your test LAN. Then check to see if your IPv6 tunnel has come up, using the show interface tunnel0 command. You should see the following:

ipv6-gateway>show interface tunnel0
 
Tunnel0 is up, line protocol is up 
  Hardware is Tunnel
  Description: Hurricane Electric IPv6 Tunnel 
  MTU 1514 bytes, BW 10000 Kbit, DLY 500000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 206.83.0.1, destination 64.71.128.82
  Tunnel protocol/transport IPv6/IP, key disabled, sequencing disabled
  Tunnel TTL 255
  Checksumming of packets disabled,  fast tunneling enabled
  Last input 19:13:04, output 19:13:04, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     2 packets input, 320 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     3 packets output, 436 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

The critical status indicators are in the first line: Tunnel0 is up, line protocol is up. If you don't see both "up" indications, then check to make sure the router has Internet connectivity, and that something is plugged into the LAN Ethernet port. A good test is to try and ping your regular Internet gateway.

If the tunnel is up, you can execute your first IPv6 command, a ping to the far end of your IPv6 tunnel. This requires use of Cisco's extended ping command, which means you must first be in the router's privileged ("enable") mode:

ipv6-gateway>enable
ipv6-gateway# ping ipv6
Target IPv6 address: 2001:470:1F00:FFFF::864
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands? [no]: 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:470:1F00:FFFF::864, timeout is 2 seconds:
!!!!!

Those five !!!!! characters mark a momentous rite of passage: your baptism into the world of IPv6. But don't stop there! Try to ping something a little farther out on the Internet:

ipv6-gateway# ping ipv6
Target IPv6 address: 2001:0770:0800:0003::1
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands? [no]: 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:470:1F00:FFFF::864, timeout is 2 seconds:
!!!!!

How far out is that? Traceroute to it and see:

ipv6-gateway# traceroute 2001:0770:0800:0003::1
Type escape sequence to abort.
Tracing the route to callisto-fe1-0-0-0.cork.core.hea.net (2001:770:800:3::1)
  1 mel.tunnel.tserv1.fmt.ipv6.he.net (2001:470:1F00:FFFF::864) 24 msec 16 msec 20 msec
  2 2001:470:1FFF:2::26 16 msec 16 msec 16 msec
  3 3FFE:80A::C 20 msec 20 msec 20 msec
  4 2001:450:1:1::21 84 msec 80 msec 90 msec
  5 schiphol-tun12.bh.core.hea.net (2001:770:8:12::1) 90 msec 98 msec 90 msec
  6 luna-pos4-0.kil.core.hea.net (2001:770:90:2::1) 91  msec 91 msec 92 msec
  7 hyperion-gige3-0-1.bh.core.hea.net (2001:770:90:5::2) 92 msec 92 msec 92 msec
  8 callisto-fe1-0-0-0.cork.core.hea.net (2001:770:800:3::1) 92 msec 97 msec 92 msec

You've just traveled to HEAnet, Ireland's National Education and Research Network! I'll leave further exploration as an excercise for the reader. In the next installment, I'll describe how to connect and configure an IPv6 desktop computer (hint: just plug it in!) and show you how the process works under the covers.

Posted by mbeckman on April 14, 2005 at 1:44 AM | Comments (1)

February 27, 2005

Don't Be Fooled by MIMO Hype

802.11n, the new WiFi standard slated to replace 802.11g, is still two years away from finalization. But that hasn't stopped a bevy of vendors from bringing so-called Pre-N products to market. The main draw with 802.11n is MIMO -- Multiple In, Multiple Out -- antenna technology, which can double the throughput of a WiFi network and increase its range and coverage by up to 100%.

A MIMO-enabled endpoint uses two or more (usually three to five) antennas to talk to a MIMO-enabled access point over several channels simultaneously, taking advantage of multiple paths between the devices to augment bandwidth and get around obstacles.

The trouble is that 802.11n is incompletely defined thus far, so vendors must make things up to fill in the blanks spaces in 802.11n's specs. The obvious caveats for any pre-standard product applies: the product likely will not interoperate with other vendors, may not perform as well as the standard anticipates, and may never end up being compliant with the actual standard when it finally arrives.

To take advantage of MIMO's performance gains, all devices in a network must be MIMO enabled. In my tests, any non-MIMO devices dragged the network back down to 802.11g speeds instantly. Given the two- to three-times higher price for MIMO-enabled gear, you have to ask yourself if the cost is worth the risk. There are plenty of people who bought pre-802.11g gear who discovered they had incompatible doorstops when 802.11g became official.

If you're building a new network and can afford to throw the first iteration away, then MIMO might be a reasonable early leap. But for most of us, the fact that 802.11g works very well, and that we must coexist with legacy 802.11b and g devices, makes MIMO a no no.

Posted by mbeckman on February 27, 2005 at 7:43 PM