Philadelphia skyline photos

My colleague Deke Kassabian posted an older photo of the Philly skyline (that I'd taken a number of years ago) on his Facebook page. So I thought I'd post a more recent set. Since I try not to use Facebook, I've posted the set to my Google Plus page instead.

These were taken in September, on my walk home from work across South Street and the South Street bridge. Equipment: Nikon D90 with Nikon 18-200mm lens.

Internet2 IPv6 Panel recap

A few notes from last month's IPv6 deployment panel at the Fall Internet2 Member Meeting in Philadelphia, which I moderated (October 2nd 2012). Watch the entire video of the session (1 hour 15 minutes) for full details.

I opened the session with a brief review of World IPv6 Launch and some its measurement data, and a mention of other IPv6 deployment measurement projects, including the NIST survey of universities.

ARIN - Mark Kosters, CTO

Mark began his presentation by talking about the current state of IPv4 address depletion. ARIN has 2.87 /8 equivalent address blocks left (note: it's down to 2.79 as of Nov 18th). RIPE and APNIC are almost out, below the one /8 threshold at which a real address rationing stage has already begun - they will give out a maximum of only /20 or /22 sized blocks regardless of how much IPv4 address space you really need. With current projections, ARIN is scheduled to exhaust in August 2013, but events could dramatically change the timeline. For example there are some ISPs in the ARIN region that could easily qualify for /9 allocations. ARIN is in phase 2 of a 4-phase runout plan - details can be seen at https://www.arin.net/resources/request/ipv4_countdown.html. Today, 58% of ARIN's membership has only IPv4 address space, 6% has only IPv6, and 36% have both IPv4 and IPv6 space. Legacy address blocks (ie. allocated to organizations prior to ARIN's existence - this is quite common in the US higher ed community) comprise 45% of the ARIN address space.

The second part of Mark's talk was about IPv6 deployment activites at ARIN itself. He went through a short history of their IPv6 implementation, which dates back to 2003, at which time they had a somewhat creaky, segregated (ie. non dualstack) implementation. By 2008 they migrated to a robust dualstack implementation. All ARIN services today are native, dualstack. Meeting networks are a bit more challenging, where they often have to rely on tunnels (due to hotel carrier limitations).

Comcast - John Brzozowski, Chief IPv6 Architect

Comcast now has IPv6 enabled on 50% of their broadband network footprint. However only 2.5% of the customer base is currently dualstack - of these dualstack users about 65% are using a computer directly connected to the cable modem, and 35% have an IPv6 enabled home router to which devices are attached. Comcast expects this ratio will eventually flip over to 80/20 in favor of home routers as it is in IPv4. To date, their focus has been on residential broadband, but they have pilots for business and commercial service. The Comcast metro ethernet service is IPv6 ready and they'd love to have more customers using it. In terms of traffic, Comcast has seen a 375% increase in IPv6 compared to World IPv6 day (June, 2011), with the majority of the increase occurring between January and June 2012, in the run up to World IPv6 Launch. The majority of the traffic is composed of services like Youtube and Netflix. The 2012 Olympics (streamed by Comcast/NBC in the US) had a noticeable impact - about 6% of this traffic to Comcast customers used IPv6. Comcast continues to work on content and services. Xfinity and comcast.net are IPv6 enabled and they use Akamai as a content delivery network.

They've put in place an extensive measurement and metrics platform to proactively detect any adverse affects on customer experience and take action if needed. Comcast sees advantages to IPv6 beyond the usual address space depletion concerns. An example cited was the fact that once they've allocated an IPv6 subnet, they don't have to be concerned about resizing it again, in marked contrast to their IPv4 deployment - this adds up over time to a significant operational benefit.

Marist College - Eric Kenny

Marist College is located in upstate network with 5,500 students on a 180-acre campus with 50 buildings. They started IPv6 deployment in 2010, and by June 2012 the wired network was mostly done. They plan to deploy IPv6 to the wireless network in the winter of 2012. One big item for them was getting provider independent address space from ARIN (mostly internal process issues). They started with a provider allocated block from NySERNET, but eventually got a /48 from ARIN, and are now wondering if they should have applied for a larger block. They also have a native IPv6 BGP peering with their commercial ISP, Lightower, which was described as an interesting experience, since they were their first IPv6 customer. They use stateless address autoconfiguration, and most devices on their network support IPv6. They haven't yet made much progress with IPv6 enabled network services, apart from DNS. At the current time about 4% of the traffic crossing their border is IPv6 - they expect this number to go up considerably after wireless deployment. One of their biggest concerns has been address tracking and accountability. They've developed their own application to track IPv6 address and MAC address associations.

Louisiana State University - Allie Hopkins

Allie focussed more on the application and process side of things. As part of their rollout process, LSU has had a great dialog with the user community, with extensive outreach and communications via message boards and e-mail lists, and close contact with application developers and deployers. And despite a set of issues (described later), they rate their deployment a success and as can be seen from World IPv6 Launch measurements, they generate a substantial amount of traffic. One of the issues they've had is with their DNS based network registration system which was incapable of working properly with IPv6 enabled hosts. Another issue they encountered was connectivity issues between tagged and untagged VLANs on interfaces, due to the Cisco routers using the same IPv6 link local addresses on them - this was fixed by manually configuring unique addresses on the VLAN interfaces. They've also had ongoing issues with being put on Google's AAAA blacklist.They are aware that they have some pockets of poor IPv6 connectivity within their campus network, but so far they've gotten no help from Google about measurement data that could help them more easily track down these cases.

I was scheduled to do a short presentation about IPv6 at Penn, but I decided to skip it (I'll post the slides later) in the interests of providing more time for audience discussion and questions.

Q&A Portion

Richard Machida (U of Alaska) asked if anyone was looking into deploying IPv6-only networks for any purpose. I answered that we've deployed them only in the lab for testing purposes (longer term, we would investigate whether it's possible to run specific applications that may not need IPv4, like VoIP on them). John says Comcast has no IPv6-only networks, but they do have plenty of IPv6-only devices that sit on dual-stack networks.

There was a question about more details of LSU's network registration system (from what I gathered it's a Netreg or Netreg like system), and whether 802.1x based network access control would be a solution (802.1x authentication happens at the link layer and is IP protocol independent). It probably would, but LSU was not quite prepared to deploy it yet.

There was discussion about what folks were doing about measuring IPv4 vs IPv6 traffic. Comcast went into some more detail about their work. I showed some data from Penn, where over the summer we were approaching 11% inbound and 4% outbound traffic composed of IPv6. We've since dropped down substantially, because we had to take IPv6 off the wireless network (I'm planning to write another blog article detailing why, but the quick summary is that deploying v6 broke IP address mobility, and we're working with our wireless equipment vendor on some possible solutions).

Dan Magorian (Johns Hopkins) asked what cable modem data specifications support IPv6 and what is the state of IPv6 support in the currently deployed field. John's answer is that DOCSIS 3, the current spec supports it pretty completely, almost all current equipment implements it, but there are ways to support IPv6 on older specs too.

---

Addendum: John B was one of the recipients of the Internet Society's Itojun Service Award recently, and presented at IETF'85, for his "for his tireless efforts in providing IPv6 connectivity to cable broadband users across North America and evangelizing the importance of IPv6 deployment globally". Congratulations John!

Shumon Huque

IPv6 and DNSSEC in San Diego

I'll be in San Diego, California in early December for the USENIX LISA 2012 conference. As part of the conference's training program, I'm teaching two courses - a full day on IPv6, and a half-day on DNS and DNSSEC.

The early registration deadline (cheaper rates) is November 19th. Various discounts are available for members of USENIX and LOPSA.

The IPv6 course "Using and Migrating to IPv6", is on Monday, December 10th. This is a revised and expanded version of the half-day course I taught at last year's LISA conference in Boston, Massachusetts, which was well received. I had originally proposed to do a full-day course last year too, but the organizers at the time felt that they wouldn't be able to attract enough attendees for day long session on IPv6. It turned out that my session was packed and the audience was quite engaged - I even ran over by 30 minutes to cover some advanced topics and almost everyone stayed the extra time. Hopefully I'll get a good turnout this time also.

The DNS and DNSSEC course, is on Tuesday morning, December 11th. This will cover the basic DNS protocol as well as the DNS Security Extensions, including practical configuration examples.

Attendee comments and feedback on my last IPv6 and DNS courses (PICC 12) are available if you're interested. In courses like these with audiences with potentially diverse backgrounds, it's rarely possible to please everyone, but my courses generally get almost uniformly positive reviews (so far at least).

Incidentally, "IPv6 and DNSSEC" is one of the themes of the conference this year. Other sessions in the category include Owen DeLong of Hurricane Electric on "IPv6 Address Planning", Scott Rose of NIST on "Progress of DNSSEC deployment in the federal government", and Roland van Rijswijk of SURFnet on "DNSSEC, what every sysadmin should be doing to keep things working".

Vint Cerf is delivering the keynote on "The Internet of Things and Sensors and Actuators", which will surely discuss IPv6.

There are many other interesting sessions. Check out the agenda for the technical program, the training program, and the workshops.



Co-located with LISA, the Internet Society is also hosting its ION Conference on the afternoon of Tuesday, December 11th.  ION is a conference series organized by ISOC's Deploy360 programme, which provides deployment information on advanced technologies like IPv6, DNSSEC, secure routing, etc.

I'm moderating a panel session titled "Advancing the Network: Where We've Been, Where We're Headed" - joining me on the panel are Ron Broersma (DREN), Paul Ebersman (Infoblox), John Spence (Nephos6), and Paul Mockapetris (inventor of the DNS). Another panel focussed on DNSSEC is being run by Dan York. The full agenda is available.

Registration for the ION conference is free, but seats are limited.

Hope to see some of you in San Diego ..

Shumon Huque

DNSSEC and Certificates

DNSSEC is a system to verify the authenticity of DNS data using public key signatures. With increasing deployment of DNSSEC comes the possibility of applications using the DNS to store and retrieve TLS/SSL certificates in an authenticated manner. And possibly obviating the need for public/global certification authorities (CA), and empowering domain owners to issue their own certificates instead.

For those of you who know me a little better, you're probably aware that I've been griping about the inherent deficiencies of the public CA model for years. Certainly my colleagues at Penn have been subjected to many a diatribe on this topic, and occasionally I've done so more publicly (no pun intended).

In brief, the problems are that applications (such as web browsers) are pre-configured to trust a very large number of global CAs. These CAs have absolutely no constraints on the namespace for which they can issue certificates. Any of them can issue a certificate for any of your services (whether you have a business relationship with them or not). And thus, we have what is tantamount to least common denominator security - the collective security of the system is equivalent to the CA with the weakest security and laxest policies. It gets worse - many of these CAs in turn issue subordinate CA certificates for their customers, again with no namespace constraints.

Another issue is that most of these CAs are capable only of issuing certificates with the most basic capabilities. If you need to deploy a certificate with some more exotic feature (eg. an alternate name form or extension), you're basically out of luck.

Incidentally the PKIX specifications do have the capability of constraining the namespace (see RFC 5280 Section 4.2.1.10: Name Constraints extension), but deploying it in the existing public CA model will require a huge amount of work (both technical and political), including deployment of a hierarchical global CA architecture, as well as enhancing client software to validate name constraints (which practically none do today).

Introducing DANE and TLSA

Recent work in the IETF holds some promise to improve things. RFC 6698 (DANE) defines the new DNS record type TLSA, which holds what is called Certificate Association data. In conjunction with DNSSEC signatures, this will permit better and more secure ways for applications to authenticate certificates. The record can be used in 4 different ways (defined by a "Usage" field):

• (Usage 0) Specify authorized public CAs - this can prevent certificates signed by CAs that you didn't explicitly specify from being trusted by client software.
• (Usage 1) Specify which specific server certificate can be trusted. The public CA certificate validation chain all the way to the server certificate must still be validated.
• (Usage 2) Authorize a new non-public CA (eg. a CA that the domain owner operates itself)
• (Usage 3) Directly specify the server certificate in the DNS - no certificate chain from a public CA needs to be used. This is called a "Domain issued certificate"

If you're looking for a way to not use public CAs, Usage 3 is probably the one for you.

The owner name of the TLSA record defines the port, transport protocol, and server host name. Here's an example for the HTTPS service (port 443, TCP) at www.example.com:

  _443._tcp.www.example.com. IN TLSA ( 0 0 1
                                d2abde240d7cd3ee6b4b28c54df034b9
                                7983a1d16e8a410e4561cb106618e971 )

The right hand side ("rdata" or resource data) of the TLSA record contains 3 numbers and the raw certificate data in hexadecimal. The 3 numbers are the usage field (previously described), the selector field (which says whether the certificate data takes into account the full certificate or only the subject's public key), and the matching-type field (which says whether the certificate data is the full content that the selector field specifies, or whether it is a cryptographic hash of it). See RFC 6698 for a more detailed description.

Deploying a TLSA record for my website

After seeing several prominent mentions of DANE at this week's ICANN'45 DNSSEC workshop, (see Dan York and Paul Wouters' presentations for example) I felt motivated to install a TLSA record for my website.

Now billions of users with TLSA capable web browsers and DNSSEC validating resolvers will be able to securely reach my website! Okay, that's a slight exaggeration, but perhaps one day, in the not too distant future!

I wanted to see if I could do this using standard tools already available on most UNIX systems. It wasn't too hard. My site already has an SSL certificate issued by StartCom Ltd, but I want to specify that the server certificate can also be authenticated directly without a CA (TLSA Usage type 3). I'll also use a SHA256 hash (match-type 1) of the full certificate (selector 0) as the certificate association data (so the 3 numbers in the rdata will be 3 0 1).

OpenSSL can be used to easily generate the certificate association data portion. We first convert my PEM encoded certificate (in file huque.crt) into the binary DER encoding (openssl x509 -outform DER) and then pipe the output to "openssl sha256". This generates the 256-bit SHA hash represented as a string of 64 hex digits (each hex digit is 4 bits):

  $ openssl x509 -in huque.crt -outform DER | openssl sha256
  (stdin)= 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

The resulting TLSA DNS record will thus look like:

  _443._tcp.www.huque.com. IN TLSA 3 0 1 ( 
       8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1 )

One quick nsupdate command  (details omitted) and the record was installed in my DNSSEC signed zone. We can check that the record (and its signature) is present with dig:

$ dig +dnssec +noall +answer +multi _443._tcp.www.huque.com. TLSA

_443._tcp.www.huque.com. 893 IN TLSA 3 0 1 (
                                8CB0FC6C527506A053F4F14C8464BEBBD6DEDE2738D1
                                1468DD953D7D6A3021F1 )
_443._tcp.www.huque.com. 893 IN RRSIG TLSA 8 5 900 (
                                20121117202722 20121018192722 14703 huque.com.
                                OJ4b/O7J+Fh3KVDGG8nH9X5dRSXgl3j7/S/PbB1RczcY
                                fYxdu5C9xZSALCz0MgVFW6Kcne74ou5R/Wd+CDKm7mYY
                                Ga28MrtE1boNLuOTa6kOpFcNjW+UYnMFQuc6S8zhU1G7
                                LH0n3TbM3rJS0wH0u6J4NgtiowZS2VlkwPez3D8= )

(If you're using an older version of BIND/dig that doesn't understand the TLSA record type, you can replace TLSA in the command line above with TYPE52.)

Note: the huque.com zone does not currently have a secure delegation from the .COM TLD. This is mainly because my current DNS registrar (Network Solutions) is incapable of processing DS records, sigh, and I've been too lazy to switch. In the meantime, it has a DLV record published in the DLV registry operated by ISC, so any validating resolver configured to use that registry (and many are) should be able to authenticate records in huque.com.

Not surprisingly, there are already tools out there that make it easy to generate TLSA records. Paul Wouter's hash-slinger package can do it (supposedly integrated into newer Fedora Linux releases). With the "tlsa" program included in that package, we can do this via:

  $ tlsa --create --output rfc --usage 3 --certificate huque.crt www.huque.com
  _443._tcp.www.huque.com. IN TLSA 3 0 1
       8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Obviously DANE needs to be widely adopted by the Internet community for it to be successful, and it's not yet clear how long that will take. And obviously browsers and other application sofware will have to evolve to make use of TLSA records. But preliminary work appears to already be in progress - there are a few browser extensions that try to validate TLSA records for HTTPS websites. I plan to look into those next ..

Incidentally, I'm teaching a half-day DNS and DNSSEC course at the upcoming USENIX LISA conference in San Diego, December 9th-14th. I hope to talk more about DANE and TLSA there.

Shumon Huque

-------------------------------------------------------------------------
Updates:

* (June 2013)  I thought I'd mention I have a small program that generates the resource data for a TLSA record from a certificate file and given parameters. You can find it on github: tlsa_rdata ]

* (September 2013) Randy Bush pointed out to me that OpenSSL versions on a number of operating systems like current versions of Mac OS X and FreeBSD are too old to support sha256. It appears that the sha256 digest command in OpenSSL is fairly new, appearing in version 1.0.1, which is newer than many current operating system distributions provide.  So I'll provide a few alternatives to "openssl 256" for them:

On Mac OS X, you can use shasum (/usr/sbin/shasum):
  openssl x509 -in certfile.crt -outform DER | shasum -a 256
On FreeBSD, you can use sha256 (/sbin/sha256):
  openssl x509 -in certfile.crt -outform DER | sha256
On Redhat Linux, you can use sha256sum (/usr/sbin/sha256sum):
  openssl x509 -in certfile.crt -outform DER | sha256sum

Or you can use Python's hashlib module (going back as far as Python 2.5). I've put up a small program on github called dgst that provides a simple command line utility to generate various cryptographic hashes of files or whatever is fed on standard input:

    https://github.com/shuque/dgst

IPv6 panel at Internet2 meeting

Penn is co-hosting the Fall 2012 Internet2 Member meeting in Philadelphia, Oct 1st through the 4th. I'm moderating an IPv6 Deployment Panel at the conference (October 2nd, 1:15pm-2:30pm). Joining me will be John Brzozowski from Comcast, Allie Hopkins from Tulane University, Eric Kenny from Marist College, and Mark Kosters from the American Registry for Internet Numbers (ARIN).

The description says: "Several panelists will provide an update on IPv6 deployment activity and plans at their respective organizations, including both network infrastructure and application services. Other topics might include IPv6 security issues, network monitoring, technical support and training, etc"

John Brzozowski is Comcast's chief IPv6 architect. Comcast is one of the industry's leading adopters of IPv6, and I hope that John will share the latest news about IPv6 developments at Comcast. Mark Kosters is the Chief Technology Officer for ARIN. Allie Hopkins is an IT director at Tulane, but was formerly at Louisiana State University. I expect that Allie will be able to talk about the state of IPv6 deployment at LSU. As you may recall, LSU was on the list of the top IPv6 traffic generating sites during World IPv6 Launch. Eric Kenny is a network engineer from Marist College, which also made that list. I'll meet Eric for the first time at the conference. I've known the other panelists for a while.

In addition to deployment details, some combination of us will try to do a little bit of IPv6 evangelism. I'll also be asking Mark to do the usual ARIN update on the state of IPv4 address depletion.

I hope to see some of you at the conference. The panel session will also be netcast (and most likely archived video will be available to view later). If anyone has suggestions on specific IPv6 related topics the panel should discuss or comment on, feel free to let me know.

References:
* IPv6 at Penn
* IPv6 at LSU
* Comcast IPv6 Information Center
* ARIN: IPv4/IPv6 the bottom line
* ARIN: IPv6 Wiki

Yosemite Photos

Some photos from a recent visit to one of my favorite places, Yosemite National Park.  A larger collection of photos is available on my Google Plus page.

The one small disappointment with visiting in late July is that many of the park's famous waterfalls are close to drying up. The rest of the outstanding natural scenery more than makes up for this though. There are few places in the world where you can see such stunning vistas in such close proximity to each other.

The photo below was taken from the Tunnel View turnout, near the Wawona tunnel, and looks eastward towards Yosemite Valley. Many of the valley's most famous landmarks and monoliths are visible in this scene, including El-Capitan, the giant granite block with the vertical face, Half Dome (in the center), the Cathedral Rocks and Bridalveil Fall.

Below: a close-up of El-Capitan (7,569 feet), which rises 3,000 feet above the valley floor. It's vertical face is a favorite challenge for experienced climbers.

Below: Half Dome, perhaps the most famous of the granite monoliths in the park. This view looks at the sheer vertical face; the other three sides are rounded and smooth. The peak (8,835 ft) rises 4,800 ft above the valley floor.

Another view of Half Dome with Cloud's Rest (I can see where that name comes from) to the left. Cloud's Rest at 9,931 feet is actually quite a bit taller than Half Dome.

Many of the famous waterfalls largely dry up by late July, early August.

Bridalveil Fall, below has mostly been reduced to a mist. When in fuller flow, this is an outstanding example of a waterfall leaping from a "hanging valley", a characteristic feature of many glaciated landscapes. The large glaciers that carved out much of Yosemite Valley left tributary streams like Bridalveil creek hanging high above the valley floor once the ice receded, and dropping from a cliff into the Merced river.

Vernal Fall (317 ft) flows throughout the year, but with much less volume in late July.

Yosemite Falls is almost dried up. Up close, some water can be see in the upper and lower portions of the falls.

Below: Half Dome and the Tenaya Canyon, viewed from Olmsted Point just off the Tioga Road.

Tenaya Lake, elevation 8150 ft, 222 acres in area, is a remnant of the Tenaya glacier. which retreated 15,000 years ago.

Below: "Roche Moutonnees" -- glacier and river carved, highly polished, granite domes in Tuolumne meadows. Many of these domes have an asymmetic profile, with a gentle slope on one side, and a much steeper slope on the other, indicating the direction of ice flow. These are geologically quite distinct from the various exfoliation domes seen around Yosemite Valley.

Pothome dome (8,766ft), rises 200 ft above the meadow floor. So named, because its south flank contains numerous deep cylindrical holes formed by subglacial rivers swirling rocks in a tight circle.

Lembert Dome (9,449 ft), another classic roche moutonnee, rises 700 ft above the surrounding meadow.

View from close to the top of Lembert Dome

Unicorn peak from Tuolumne Meadows.

Alpine meadows, strewn with glacial erratics, near the eastern end of the park near Tioga pass.

Tioga Pass, at the east entrance to the park, 9,943 ft.

Below: Giant Sequoia trees at the Mariposa Grove, in the south part of the park. Giant Sequioas are the largest living organisms on earth, and grow only in specific areas on the western slope of the Sierra Nevadas - there are groves in Yosemite, Sequoia, and King's Canyon national parks. The largest known Sequoias are actually in Sequoia national park's Giant Forest. But the Mariposa Grove has some pretty big ones too. The famous "Grizzly Giant" is 209 ft tall and 34,000 cubic feet in volume! California coastal redwoods (which I saw at Muir woods the day before arriving at Yosemite) are the world's tallest trees, but in sheer mass, they are dwarfed by the Giant Sequoias.

Looking north west towards "Taft Point". Apart from a small railing at the point, the cliffs around Taft point are completely unguarded, a 3,400 ft drop to the valley floor. Inching up to the edges, the views are incredible - but not for the acrophobic!

View from Taft Point.

Below: The upper chamber of Yosemite Valley (sometimes called Little Yosemite), from Washburn Point off the Glacier Point road. Half Dome is prominent in this view, as are Mt Broderick, Liberty Cap, Vernal and Nevada Falls, the Panorama cliffs, and in the distance, the vast panorama of the Sierra Nevadas.

Below: Also from Washburn Point, a zoomed in shot of the "Giant Staircase". The Merced river descends this staircase via two waterfalls that are at right angles to each other, Nevada Fall (594 ft) and Vernal Fall (317 ft), flanked by Libery Cap and Mount Broderick.

Yosemite Valley and the Tenaya Canyon from Glacier Point.

The Royal Arches - a collection of arches carved into the rock face by large sheet joints. Above the arches are several smoothly shaped granite domes, North Dome & Basket Dome. To the immediate right of the Arches is Washington Column, an enormous natural rock pillar.

Yosemite Valley from the Valley View turnout - another very popular photo-op.

More photos (including larger versions) are available on my Google Plus page.

Stanford Linear Accelerator tour

At the recent Joint Techs conference, our host Stanford University arranged a lunch time tour of the Stanford Linear Accelerator Center (SLAC) for a small group of attendees. I signed up early as I knew it was going to popular with this crowd. SLAC is a 50 GeV electron-positron accelerator operated by Stanford on behalf of the US Dept of Energy.

(SLAC is now officially known as the "SLAC National Accelerator Lab".)

This is the second particle accelerator site I've visited. In the summer of 2007 (also during a Joint Techs conference), I saw Fermilab and the 2 TeV Tevatron, at that time the world's most powerful particle accelerator. My annotated photos from that visit are on flickr. The Tevatron ceased operation in late 2011. One of these days, I hope to visit the Large Hadron Collider at CERN.

Here are some photos from the SLAC tour. The full set is also available.

Bebo White, a noted SLAC computational physicist, was our tour guide. He's an entertaining and jolly character, who by his own admission looks like Santa Claus :-)

How the LINAC works:

Hmm, Science has a long way to go!

SLAC had the first website in North America (the first in the world of course was at CERN, where Tim Berners-Lee worked). Seeing a NeXT Cube brings back memories. That was my main computer for most of my undergraduate years at Penn, when I worked for NeXT as a campus consultant.

Mock-up of accelerator components just outside the end of the Klystron gallery:

Facilities photo/map:

The Klystron gallery along the nearly 2-mile long building that houses the main linac. Klystrons are the key driving force for the accelerator and produce amplified electromagnetic carrier waves that help boost the electrons along the beam line. The Klystrons are to the left of this photo, and sit above the main accelerator beam line which is situated 25-feet beneath the ground.  There are 240 Klystrons in total. The particles are injected at the other end of this tunnel.

Our merry tour group ...

A Look at World IPv6 Launch Traffic Measurements

The World IPv6 Launch website has compiled a set of measurements at  http://www.worldipv6launch.org/measurements/. I'll take a quick look at some of them here, with a focus on universities.

The "Network Operator measurements" include data collected by Google, Facebook, and Yahoo! for access to their services on June 6th 2012 from the various network operator participants registered for the event. There were only 77 networks in total registered. I'm sure there are a number of other qualified networks that could have provided significant numbers of IPv6 users and traffic. I suspect the initial requirement that network operator participants be able to demonstrate that at least 1% of their traffic constitute IPv6 prior to the event likely dissuaded some potential participants from registering.

Different views of the network operator measurement charts require manipulating javascript controlled knobs at the website, so I can't provide a direct URL link to them. Instead, in the discussion below, I'm including the relevant screen captures.

View by Total Traffic 

The default view presents the participating networks sorted by total volume of IPv6 traffic measured, although the absolute volume number is not disclosed. Several large ISPs lead the list, with Free Telecom (France) occupying the top spot. AT&T (US), KDDI (Japan), RCS & RDS (Romania), Comcast (US), and Verizon Wireless (US) round out the next five. There is a significant disparity in the proportion of IPv6 traffic generated by those networks though, with Comcast seeing only 1.47% and Free seeing 17.35%. I suspect the numbers for Comcast will go up significantly as they turn up IPv6 on more of their home network customers during the coming year (the number was 1.5% on June 6th).  The US wireless carriers should also see their numbers go up as more of their users switch to IPv6-enabled 4G/LTE cell phones.

It's great to see a number of US universities (including my own) feature prominently in the top part of this list also - in ranked order: Indiana University, University of Pennsylvania, Virginia Tech, Louisiana State, and University of Iowa.

View by IPv6 Traffic Percentage

Sorting the table by the "IPv6 traffic percentage" column (the 3rd column below) produces some very impressive looking numbers. In this measure, universities start to dominate the rankings. The top two spots are held by Virginia Tech and Louisiana State, for which close to 60% of traffic constituted IPv6. Other notables include Marist College (53%), Indiana University (49%), RPI (47%), Penn (32%), University of Iowa (31%), Karlsruhe Institute of Technology (20%), & University of Phillipines Diliman (12%).  The effect of many of these universities having large parts of their campus networks IPv6 enabled and presumably large numbers of IPv6 enabled computers on those networks undoubtedly had a lot to do with these results.

It would be interesting to see more detailed measurement data from some of these extensively IPv6 enabled campuses about what proportion of their total traffic is IPv6 (as opposed to the subset of traffic only to a set of popular IPv6 enabled services). I hope to be able to share some data from Penn in the near future - we're currently dealing with some IPv6 traffic accounting bugs with a router vendor first. But our initial calculations are that we were seeing IPv6 account for 8 to 10% of the total traffic traversing the campus border during peak hours of the day. Even though the vast majority of the Internet is not IPv6 enabled, the existence of a number of popular and high-traffic generating services (Google, YouTube!, Netflix, etc) are likely skewing the numbers in favor of IPv6.