January 2008 Archives

In my previous blog entry, I reported at PSU has about 300,000 IPv4 addresses assigned to it, and that ITS manages a little more than half of those. ITS projects that it will exhaust its IPv4 pool sometime in late 2009 or early 2010. This graph is based on data from TNS in January 2008:


The text on the graph is hard to read. Click on it for a larger version.

When we finally exhaust our pool, will we able to go ARIN and get more? That depends on the status of ARIN's IPv4 pool and on any new policy ARIN has adopted. Several of the RIRs have adopted policies which make it much more difficult to obtain additional IPv4 space. I believe that ARIN will still have addresses left, but we probably won't be able to get space due to policy changes. If that's the case, it's a pretty scary realization. Quite likely, we'll be stuck with the IPv4 space we already have.

It will be several years before ITS runs out of IPv4 space, but the end is closer than many people think. No, the sky is not falling, but I firmly believe that we have to start planning now for what to do when we do run out of space. IP addressing will be a serious issue during the University's next strategic planning period (2009-2014).

Several network managers on campus have already begun efforts to conserve IPv4 space. They're doing things like moving networked printers and internal servers to private address space. But there are only so many printers to move! These steps are important in the short-term to preserve business continuity, but ultimately, they only relieve the pressure temporarily. We're still left with the question: What is our long-term solution to the address crunch?

Some within the university have proposed using static NAT for desktops. This approach has issues, including potentially breaking certain applications. The number of apps broken by NAT has declined in recent years, in part due to protocols such as STUN, TURN and ICE, to name just a few. Frequently, NAT-enabled apps will have to support multiple such protocols. Adding NAT traversal support to an application can add considerable development and testing costs (see this paper on Skype for a good example of NAT-enabling a real-world app). Given the aggressive use of NAT today, many developers are already adding NAT support to their apps.

Others are proposing using IPv6. Of course, deploying IPv6 isn't free either. There are both hardware and software costs involved. New routers and firewalls have to be purchased. Of course, network equipment needs to be regularly replaced anyway to keep up with increased user demands. If IPv6 support is introduced as network equipment is replaced, deployment costs can be considerably reduced (but not eliminated). Software may need to be upgraded to use IPv6-safe APIs or to remove hard-coded IPv4-assumptions. There will certainly be testing costs. Fortunately, many programming languages (Python, Ruby, Java) and networking libraries (CFNetwork, Qt, NSPR, APR) are already IPv6-enabled. This support tremendously helps reduce programming costs. Even so, there will certainly be at least a few legacy apps which will be very expensive to convert to IPv6.

Ultimately, I think this is an economic question: In the long-term is it cheaper to (more aggressively) deploy NAT and NAT-enable our apps, or to deploy IPv6 and v6-enable our apps? Any measurement of cost should include the factors outlined above plus opportunity cost.

My vote is for IPv6. Why? Because the graph above scares me. I'm just not comfortable living in a network where we've used up most of our publicly routable addresses. Even with extensive use of NAT, I'm afraid that such an environment limits our ability to deploy new applications and services. Even if Penn State can reclaim significant portions of its IPv4 space, the story doesn't end at our border router. What about our partners? What about network operators in Europe and Asia who are already deploying IPv6? If we need to interoperate with them, we'll need an IPv6 story of our own.

I'm curious what others think. How do you answer the question?

A brief history of IP address allocation at Penn State, based on whois data.

March 31, 1986:

We got five Class C networks (256 addresses each):

192.5.157.0/24
192.5.158.0/24
192.5.159.0/24
192.5.160.0/24
192.5.161.0/24

We also got a Class B network (65,536 addresses):

128.118.0.0/16

October 5, 1988:

The Department of Computer Science and Engineering got its own Class B network (so another 65,536 addresses):

130.203.0.0/16

A good portion of this space is shared with the rest of the University. For example, about 3,300 of these addresses are in the University's dial-up modem pool.

February 26, 1991:

We got another Class B network (another 65,536 addresses):

146.186.0.0/16

August 7, 1991:

The Hershey Medical Center got a Class B network. This netblock was and still is managed by Hershey Medical Center, not by ITS.

150.231.0.0/16

September 25, 1991:

We got another Class C (256 addresses):

192.112.253.0/24

February 5, 2001:

We got a /17 (32,768 addresses):

66.71.0.0/17

This is used for the residence halls.

January 13, 2006:

We got our permanent IPv6 prefix (which can hold 4,294,967,296 sub-networks, with 18,446,744,073,709,551,616 addresses each):

2610:8::/32

Summary:

Total IPv4 addresses assigned to Penn State: 296,448

A little over half of those addresses are managed by ITS. While it seems like PSU has a lot of addresses (and we do), ITS estimates that we'll run out in less than 5 years. More on that in a future blog entry.

When a user posts a comment to a MovableType 4 blog, MT4 logs the user's IP address. However, the relevant column in MT's database is only big enough to store an IPv4 address. Here's the relevant code from lib/MT/Comment.pm:

PSU is using MovableType 4 for its blogging pilot, so I suppose I should submit a patch to fix this.

As an aside, it's disappointing that MovableType is storing the address as a string. I suppose this was done for portability reasons, but it means that MT can't take advantage of databases with intelligent IP address datatypes, like PostgreSQL. For almost a decade, PostgreSQL has had the inet and cidr datatypes, which are specifically designed for storing IP addresses. These datatypes have supported IPv6 since release 7.4 in late 2003.

In the early days of the Internet, addresses were assigned in a very wasteful manner. Organizations would frequently get a Class A assignment (16.7 million addresses) regardless of their size. With the introduction of the RIR system in the mid-90s, new allocations are much more appropriately sized.

As we continue to use up IPv4 space, there is increased pressure on the legacy IPv4 class A holders to relinquish their space and switch to a more efficient allocation. But this is a voluntary process -- there doesn't appear to be a legal or policy procedure to force a legacy holder to relinquish their space. So far, there haven't been too many volunteers. Last week, IANA reclaimed the 014/8 legacy block. See RFC 3300 for more on the 014/8 block.

While this is important, I have to point out that this represents less than a 0.5% increase in the amount of available IPv4 space. I still think that IPv6 is the only viable long-term solution to sustainable internet addressing.

I mentioned earlier that IPv6 allocations took off in 2007. From 2006 to 2007, more than double the number of North American organzations got IPv6 space allocated to them. But are those organizations actually deploying their new IPv6 allocations? It seems they are. Hurricane Electric did a study of IPv6 deployment from September 2006 - September 2007. They measured the number of IPv6 networks (using entries in the BGP table), the average distance between IPv6 networks (in terms of autonomous system path length), and the latency of IPv6 compared to IPv4 using pings.

They found a 50% increase in the number of IPv6 networks in 2007. The average AS path length between IPv6 networks dropped by 22% (leading to better-performing routing). Finally, they found that in half of their cases, IPv6 was as fast or faster than IPv4. So much for the myth that IPv6 networking is always slower than IPv4!

Get the report here. It's an interesting read. They also have a neat website with daily updates comparing IPv6 deployment to IPv4.

Just a quick note that Windows Server 2008 is now IPv6-Ready Phase 2 certified. I have a test 2008 server running, and I've been impressed with it so far. Kudos to MS for making the Server 2008 release candidate public.

One of the main factors driving IPv6 adoption will likely be Internet-enabled mobile devices -- cell phones, tablets, PDAs, handheld game devices, etc. Increasingly, these devices will require "always-on" IP connectivity. That need, coupled with the high number of these devices and the decreasing IPv4 address space, makes IPv6 very appealing. IPv6 also has much better support for autoconfiguration and multicast.

There was a very good presentation by Nokia on the benefits of IPv6 for handheld devices at the Global IPv6 Summit in China 2007:

The good news is that IPv6 is very well supported in in several handheld OSes. Microsoft has supported it since PocketPC 2003, Symbian got support in version 7.0s, and VxWorks supports it as of Version 6. BusyBox has supported IPv6 since version 1.3.0. Sadly, neither PalmOS nor the iPhone support IPv6 currently, but since the iPhone runs OS X, and OS X supports IPv6, it can only be a matter of time before Apple enables it.

Per my previous post, IPv6 deployment is growing in North America. I was curious as to who is requesting IPv6 prefixes. I checked the whois data all of the IPv6 prefixes that ARIN assigned in 2007. I saw several US universities in the list:

• Georgia Institute of Technology
  
• Oklahoma State Regents for Higher Education
  
• Kentucky Educational Computing Network
  
• University of Arizona
  
• University of California at Berkeley
  
• University of California, Los Angeles
  
• University of California, Riverside
  
• University of Hawaii
  
• University of Michigan

Great news. I haven't seen evidence of IPv6 deployment at these institutions yet (aside from UC Berkeley), but hopefully we'll see something during 2008. I'm really hoping that U. Mich makes their DNS servers IPv6-accessible, since they provide DNS for many universities (Columbia, U. Memphis, U. Wisconsin, San Diego Supercomputing Center, Pittsburgh Supercomputing Center, and UCAR, to name a few).

There was a big increase in the number of IPv6 network prefixes (/32s) issued by ARIN in 2007:

According to the raw data, there were 108 IPv6 prefixes assigned by ARIN in 2007. This is more than 2.5x the number in 2006 (39 approved prefixes), and almost double the previous record, 2005 (57 approved prefixes).

Suffice it to say, I don't much faith in the claims that IPv6 is dead.

I'm very excited. This morning I found my first IPv6-enabled web site with content for a general audience: www.crooksandliars.com.

All of the IPv6-enabled web sites I've seen so far are oriented at geeks. While some of us may like to see dancing turtles, peruse lists of IPv6-enabled applications, download free operating systems, or even read internet standards, most normal users won't find these activities too interesting. While I'm not necessarily endorsing crooksandliars.com's content, it is aimed at a general audience. So I'm very happy that it's IPv6-accessible.

In an earlier blog entry, I mentioned the ShowIP extension for FireFox. This tool displays the IP address of the site you're visiting in FireFox's toolbar. If it's green, you're using IPv6. This morning, while reading digg, I followed a link to crooksandliars.com and noticed my toolbar go green:

As an added bonus, not only is www.crooksandliars.com accessible over IPv6, but so are its authoritative nameservers:

$ dig -t NS crooksandliars.com.

; <<>> DiG 9.3.4 <<>> -t NS crooksandliars.com.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13613
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;crooksandliars.com. IN NS

;; ANSWER SECTION:
crooksandliars.com. 2395 IN NS grittykitty.ziaspace.com.
crooksandliars.com. 2395 IN NS lain.ziaspace.com.
crooksandliars.com. 2395 IN NS reva.xtremeunix.com.
crooksandliars.com. 2395 IN NS andromeda.ziaspace.com.

;; ADDITIONAL SECTION:
reva.xtremeunix.com. 2396 IN A 72.37.180.251
reva.xtremeunix.com. 2396 IN AAAA 2001:4830:1210::280:10ff:fe00:48b9
grittykitty.ziaspace.com. 171596 IN A 72.37.180.250
grittykitty.ziaspace.com. 2396 IN AAAA 2001:4830:1200:17::2

;; Query time: 0 msec
;; SERVER: 2610:8:6800:1::4#53(2610:8:6800:1::4)
;; WHEN: Mon Jan 7 11:39:44 2008
;; MSG SIZE rcvd: 232


Sadly, the IPv6 internet's routing system is still less developed that the IPv4 internet's. Pings to www.crooksandliars.com from my desktop over IPv6 take about 3x longer than over IPv4 (252 ms compared to 83 ms, respectively).

A few months ago, I blogged that only two of the Big 10 schools have IPv6-reachable authoritative DNS servers. Things are a little better now: Indiana University has IPv6 DNS servers, bringing the total to three Big Ten schools.

I wanted to see how other grouping of US higher-ed institutions faired. In the CSG, things are the same: 3 of the 26 members (PSU, IU and UCSD) have IPv6 DNS.

Things are slightly better in Internet2: 12 of their 209 university members have IPv6-accessible DNS servers:

• Indiana University
  
• Pennsylvania State University
  
• Princeton University
  
• University of California, Berkeley
  
• University of California, San Diego
  
• University of Delaware
  
• University of Illinois at Urbana-Champaign
  
• University of Notre Dame
  
• University of Oregon
  
• University of Pennsylvania
  
• University of South Florida
  
• Wichita State University

Note that Internet2 itself does not have IPv6-accessible DNS. Which is very strange, since they've routed IPv6 across their network for at least 4 years. Also note that not all schools on the above list have IPv6 themselves. In some cases, an IPv6-capable third-party is providing DNS. For example, Princeton does not have IPv6, but one of their backup DNS servers (ns3.nic.fr.) has IPv6.

The indefatigable Iljitsch van Beijnum published a story on ArsTechnica about IPv6 in the DNS root servers. For various technical reasons the root DNS servers have not listed their IPv6 addresses in the hints file, which is used by recursive nameservers. There was concern that old, broken DNS software and poorly configured firewalls would break if IPv6 addresses were added to the hints file.

In February, 2008, this will change; IANA will publish IPv6 addresses in the hints file. Initially, they will include IPv6 addresses for the F, H, K, and M servers. This means that it will be possible to do DNS entirely over IPv6, provided, of course, that all of the intermediate DNS servers are IPv6-accessible. This is a huge step for the IPv6 transition.

This got me thinking: How many of the top-level-domains have IPv6-accessible authoritative nameservers? I whipped up a quick Java program to check this. Answer: About two-thirds of them. (Sadly, .edu is not among them. Damnit, educause!) I was very surprised by this. IPv6 DNS is more prevalent than I had thought.

Here's the complete list:

ac	ca	ga	is	ml	pn	tm
ad	cat	gb	it	mm	pr	tn
ae	cd	ge	je	mn	ps	tp
aero	cg	gg	jm	mobi	pt	tr
af	ch	gh	jo	mr	py	travel
ag	ci	gi	jp	ms	re	tw
al	cl	gl	ke	mt	ro	tz
am	cm	gn	kg	museum	rs	ua
an	cn	gp	kh	mw	ru	ug
ao	com	gr	ki	my	rw	uk
aq	cr	gs	kr	na	sc	um
ar	cu	gt	kz	nc	sd	us
as	cv	gy	lb	ne	se	uy
asia	cx	hk	lc	net	sg	va
at	cy	hn	li	ng	sh	vc
au	cz	hr	lk	nl	si	ve
ba	de	ht	lr	np	sk	vg
be	dz	hu	ls	nr	sn	vi
bg	ee	id	lt	nu	st	vn
bi	er	ie	lu	nz	sv	wf
biz	es	il	lv	om	tc	yt
bj	exit	in	ly	org	td	yu
bm	fi	info	ma	pe	tel	za
br	fj	int	mc	ph	tf	zm
bw	fm	io	md	pl	th	zw
by	fr	ir	me	pm	tl