Recently in Internet2 Category

Absolutely nothing.

KanREN, the Kansas Research & Education Network, is doing a lot with IPv6. As best as I can tell, they're the second Internet2 member to have IPv6-enabled web, email and DNS services (3Rox was first). So, hat's off to them!

This is particularly relevant, since two more IPv4 address blocks were allocated today (blocks 110 and 111, to the Asia Pacific registrar). Only 14% of the IPv4 address space is unallocated.

This week in IPv6

| | Comments (0) | TrackBacks (0)

It's been a busy week for IPv6.

On Tuesday, the Squid web cache announced a beta of version 3.1, the first with IPv6 support. For those of you using Squid 2.x, there are plans to backport this code to release Squid 2 (the work will be spread between 2.8 and 2.9). This has been a long time coming — the code was merged almost a year ago. Given the dearth of IPv6 deployment, dual-stacked web proxies will probably be important during the IPv6 migration.

On Wednesday, UCLA IPv6-enabled its web site:

$ dig -t AAAA

; <<>> DiG 9.4.2-P2 <<>> -t AAAA
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41596
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1


;; ANSWER SECTION: 272 IN AAAA 2607:f010:3fe:101:101d:9ff:fe32:a7d1

;; AUTHORITY SECTION: 21572 IN NS 21572 IN NS 21572 IN NS


;; Query time: 11 msec
;; SERVER: 2610:8:6800:1::4#53(2610:8:6800:1::4)
;; WHEN: Fri Nov 7 14:19:28 2008
;; MSG SIZE rcvd: 131

As far as I know, UCLA is the first university in Internet2 to take this step. Congratulations!

On Thursday, there were several code commits to FreeBSD to remove IPv4 dependencies. The goal is to let the kernel be compiled without IPv4 support (one can only dream of such a day).

Also, RIPE (the Regional Internet Registry for Europe, Middle East and parts of Asia) published the slides from its meeting last month in Dubai. These were several excellent talks. Several European Internet Exchange Points showed growth in the number of IPv6-enabled customers.

Etisalat, a large Middle East telco, discussed their IPv6 deployment, which has been underway for most of the decade. They're motivated for the usual reasons: The significant increase in Internet-attached devices is exceeding NAT's usefullness. I found it interesting that they've required IPv6 support in new equipment purchases since 2001! I'm really hoping that Penn State adopts a similar policy soon.

Google presented two talks on its on-going IPv6 trial. As a refresher, Google doesn't see NAT as a long-term solution to IPv4 address depletion. In fact, they claim that excessive NAT will have significant negative impact on common web apps. So they've run an IPv6 pilot since March. So far, the results are very encouraging: Only 0.09% of users have broken IPv6 connectivity.

I'm glad to see that Google (among others) is actually gathering empirical data on IPv6 usage, since there is a lot of FUD about there that IPv6 will cause all sorts of breakage. To quote Google, "It's not that broken... don't believe the FUD."

Having said that, things are not perfect. IPv6 routing is often sub-optimal (to be polite). Gert Doering presented on the state of the IPv6 routing table, as asked "Why does traffic from Germany to Germany get routed through the US and Hong Kong? He showed an example of a user in Munich accessing a server in Frankfurt. The traffic went across the Atlantic to Washington, DC, across the continental US to Chicago, then Seattle, then across the Pacific to Hong Kong, then finally back to Germany. This has got to stop.

Google also sees these sort of problems. They had an example of traffic from Virginia to Virginia being routed through Amsterdam. All of this adds significant latency to IPv6, making users disinclined to use it. Fortunately, we know how to fix the problem: We need to start filtering IPv6 routes. We've done this for IPv4 for a while, and it's time to do the same for v6.

So that's the week in IPv6. There was a lot more covered at RIPE-57. I'll blog about that later.

I just got back from the Summer 2008 Internet2 Joint Techs Workshop in Nebraska. There was a heavy focus on IPv6 at the workshop. The IPv6 Working Group announced its IPv6 Challenge. This is a challenge to Internet2 members to IPv6-enable several aspects of their networks. Joe Nasal from TNS participated in a very interesting panel discussion on campus IPv6 addressing plans (video here). Both Penn State and Stanford were on the panel. We both have a /32 from ARIN, but we've chosen to use them in very different ways. I found that rather interesting. As usual, DREN gave a useful update on their IPv6 deployment in the Department of Defense.

I gave a lightening talk on a quick way to IPv6-enable lot of DNS servers (slides here). Essentially, there is a "clustering" effect in DNS, where one server will provide authoritative DNS for three or four other domains. For example, UC Berkeley provides DNS for Columbia, UC San Francisco and UCLA. So v6-enabling that one server provides considerable extra benefit. If you map out these "clusters" in DNS, you get a list of the most beneficial servers to target. It turns out that by v6-enabling 11 extra servers, you would give 31 domains v6-reachable DNS. Put another way, that's 15% of Internet2 members, but requires upgrading only 1.5% of its nameservers.

In non-IPv6 news, there was a good DNSSEC talk from NIST. This was especially interesting in light of the recent Kaminsky DNS attack. Suffice it to say, there are still a fair number of hurdles to integrating DNSSEC.

A week-and-a-half ago, I commented that 10% of Internet2 schools had IPv6-reachable DNS. It's time to add one more: Georgetown. And, unlike many schools, Georgetown isn't piggybacking on someone else's DNS server.

For those of you keeping count, here's the updated list:

IPv6-reachable DNS in Internet2
  • Columbia University
  • Georgia Institute of Technology
  • Georgetown University
  • Indiana University
  • Internet2
  • Ohio University
  • Pennsylvania State University
  • Portland State University
  • Princeton University
  • University of California, Berkeley
  • University of California, Los Angeles
  • University of California, San Diego
  • University of California, San Francisco
  • University of Delaware
  • University of Illinois, Urbana-Champagne
  • University of Iowa
  • University of Notre Dame
  • University of Oregon
  • University of Pennsylvania
  • University of Rhode Island
  • University of South Florida
  • Virginia Tech
  • Wichita State University
  • Worcester Polytechnic Institute

For the past few months, I've been keeping track of how many .edu domains have IPv6-reachable authoritative DNS. So far the results have been less than exciting: Less than 10% of Internet2 University Members had taken the plunge.

That's changed. We're now over the 10% threshold. Four more universities have IPv6 DNS:

  • Columbia University
  • University of California, Los Angeles
  • University of California, San Francisco
  • Virginia Tech

This means that 22 of the 212 Internet2 University members (or 10.4%) have IPv6-reachable DNS. Six months ago, that number was 5%. Doubling that in a few months makes me hopeful. I'm having a beer to celebrate.

I've noticed a clustering of .edu DNS. Typically one institution will provide DNS for many others. For example, UC Berkeley v6-enabled one of their DNS servers ( That box also provides DNS for Columbia, UCLA and UC San Francisco. Likewise, the University of Orgeon provides IPv6 DNS for Portland State and Internet2. And Indiana University also provides for UIUC and U. Rhode Island. There are many more examples.

These clusters are both good and bad. They're good because they provide "easy targets" for IPv6 -- by IPv6 enabling a handful of machines, you provide maximum coverage. They're bad because, often, they're the only IPv6-enabled server for a domain -- if one server at Berkeley goes down, three other universities effectively drop off the IPv6 Internet.

But I'm still taking this as a win.

A few months ago, Internet2 made one of their DNS servers reachable over IPv6. Their other DNS server ( was still IPv4-only. That's now changed.

All of the authoritative name servers for are now reachable over IPv6. This has been a long time coming, and it's great to see it done:

$ dig -t NS

; <<>> DiG 9.2.4 <<>> -t NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1475
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 6


;; ANSWER SECTION: 3913 IN NS 3913 IN NS 3913 IN NS

;; ADDITIONAL SECTION: 7138 IN A 7155 IN AAAA 2001:468:1420::59 7143 IN A 7151 IN AAAA 2001:468:c07:1::250 61905 IN A 61905 IN AAAA 2001:468:d01:20::80df:2023

;; Query time: 1 msec
;; SERVER: 2610:8:6800:1::4#53(2610:8:6800:1::4)
;; WHEN: Fri Jun 13 10:51:53 2008
;; MSG SIZE rcvd: 229

I just got back from the Spring '08 Internet2 Member Meeting. Internet2 has routed IPv6 across their backbone since 2001, but until recently they hadn't enabled it on their services (dns, www, mail, etc). In recent weeks, that's started to change.

In the past, Internet2 has IPv6 enabled only on a few test machines (their CoManage SP and InCommon's IdP). At the Member Meeting, they enabled IPv6 on one of their authoritative DNS servers ( They plan to v6-enable their other authoritative server next week. And they're talking about v6-enabling their incoming mail server in a few months. Oh, and the Internet2 IPv6 Working Group home page is now reachable over IPv6.

In the closing session, Internet2 invited John Curran, the chair of ARIN, on-stage to discuss the need to transition to IPv6. You can get his slides or watch the video of his talk (it starts at 17:40).

So congrats to I2 for starting to use (as opposed to just route) IPv6.

Now if they could only get reverse DNS setup....