Dan York

Just a guy in Vermont trying to connect all the dots...

Author's posts

Comcast Enables IPv6 For Xfinity and Xfinity TV

Great news out of Comcast this week related to IPv6 – they have now made two of their major content portals available over IPv6!  From their comcast6.net page on April 10, 2012:

The newest part today moves two of our major portal sites to IPv6, including Xfinity andXfinityTV. This critical move was made possible via close cooperation with Akamai, our CDN vendor. Over time, we will introduce support for native IPv6 for all of our other key websites.

As we get closer to World IPv6 Launch on June 6, 2012, it’s critical to get content (i.e. web sites) available over both IPv4 and IPv6 so that people joining IPv6 networks will be able to natively connect to these sites.

Kudos to Comcast for moving these two large sites over to IPv6 and we look forward to seeing even more of their content moving to IPv6 in the weeks and months ahead.

Video/Slides: IPv6 Autoconfiguration Tutorial

Want to understand more about how IPv6 addresses are configured using SLAAC and DHCPv6? (Want to understand what “SLAAC” is?) If so, Fred Bovy recently posted a video of a presentation he did about IPv6 autoconfiguration.  In the hour-long video, he explains how autoconfiguration works, provides some examples in Linux and then later gets into mobile IPv6 and other mechanisms involved with IPv6 addressing.  If you are looking for a deep dive on IPv6 address autoconfiguration, you may find this very helpful.

Fred’s slides are also available from SlideShare:

My Report into For Immediate Release (FIR) Podcast #646

In this week's For Immediate Release episode #646, my report covered:

If you are a FIR subscriber, you should have the show now in iTunes or whatever you use to get the feed. If you aren't a subscriber, you can simply listen to the episode online now.


If you found this post interesting or useful, please consider either:


FCC Publishes DNSSEC Recommendations for ISPs

FCC CSRIC logoAre you are network operator or Internet service provider (ISP) seeking to understand what you need to do to implement DNSSEC within your network? Are you looking for guidance to help you understand how to proceed?

If so, the U.S. Federal Communications Commission (FCC) just published a set of “DNSSEC Implementation Practices for ISPs” through one of the working groups of its Communications Security, Reliability and Interoperability Council (CSRIC).  The 29-page PDF is available at:

http://transition.fcc.gov/bureaus/pshs/advisory/csric3/CSRIC-III-WG5-Final-Report.pdf

The document provides:

  • A brief overview of DNS and DNSSEC
  • A view of the current state of DNSSEC deployment
  • How Internet Service Providers (ISPs) can use DNSSEC
  • An analysis of the key drivers and challenges for implementing DNSSEC
  • Specific best practice recommendations to ISPs for deploying DNSSEC

The key recommendations of the working group include:

  1. ISPs implement their DNS recursive nameservers so that they are at a minimum DNSSEC-aware, as soon as possible.
  2. Key industry segments, such as banking, credit cards, e-commerce, healthcare and other businesses, sign their respective domain names. The FCC ask industry-leading companies in key sectors commit to doing so, in order to create competitive pressure for others to follow. These industries may be prioritized based on the prevalence of threats to each one, which would mean focusing on financially related sites first, followed by other sites that hold private user data.
  3. Software developers such as web-browser developers study how and when to incorporate DNSSEC validation functions into their software. For example, a browser developer might create a visual indicator for whether or not DNSSEC is in use, or perhaps only a visual warning if DNSSEC validation fails.

We’re very pleased to see these recommendations as they are very much in line with what we’ve been promoting here on the site about DNSSEC – and are very much in line with our recent analysis of DNSSEC challenges and opportunities.

If you are an ISP or network operator, these recommendations from the FCC are definitely ones to consider and act on.  Kudos to the CSRIC Working Group and the FCC for publishing this document.

Thanks to the DNSSEC Deployment Initiative for pointing out that these recommendations were published.

FCC DNSSEC Implementation Guidlines for ISPs

In March 2012, the United States Federal Communications Commission (FCC) published a set of “DNSSEC Implementation Practices for ISPs” through one of the working groups of the FCC’s Communications Security, Reliability and Interoperability Council (CSRIC).  The full report can be downloaded in PDF at:

http://transition.fcc.gov/bureaus/pshs/advisory/csric3/CSRIC-III-WG5-Final-Report.pdf

The 29-page document provides the following:

  • A brief overview of DNS and DNSSEC
  • A view of the current state of DNSSEC deployment
  • How Internet Service Providers (ISPs) can use DNSSEC
  • An analysis of the key drivers and challenges for implementing DNSSEC
  • Specific best practice recommendations to ISPs for deploying DNSSEC

If you are a network operator or Internet service provider seeking to understand the steps you need to undertake to support DNSSEC, this document is highly recommended.

Network World Tests Six IPv6-Enabled Application Delivery Controllers (load balancers)

Back in February, Scott Hogg at Network World put together a “Clear Choice Test” on “IPv6-Enabled Application Delivery Controllers (ADCs)” that explored the idea of using an ADC (what we used to think of typically as a “server load balancer”) to IPv6-enable content that exists on IPv4-only web servers.  As the intro to the series of posts explains:

If an organization were to deploy an IPv6-capable Server Load Balancer (SLB) or, using the most current term, Application Delivery Controller (ADC), they could configure an IPv6 Virtual IP (VIP) and an IPv4-only server farm.

This would allow Web apps hosted on IPv4-only servers to appear to the Internet user as IPv6-applications. The way it works is that clients would connect to the IPv6 VIP, and the ADC would perform a reverse-proxy function and terminate the IPv6 HTTP Internet connection, then create a new IPv4 HTTP back-end connection to the IPv4-only application servers. The server would not necessarily know the IP version being used by the client and it would happily return the data to the ADC appliance using IPv4. The ADC appliance takes that IPv4 response from the server, copies the HTTP application data and transmits it back to the IPv6-connected client.

Essentially, you are using your load-balancing infrastructure to also proxy the IPv6 to IPv4 connection.

It’s quite a useful and interesting idea for enterprises who want to make their content available over IPv6  (particularly with World IPv6 Launch approaching) but are concerned about making changes directly to their current web servers.  It may be easier as a first step to make changes to your ADC infrastructure (or even to install such an infrastructure).

Sadly, Network World has now locked this good content behind a registration wall and so you can only read their full report if you sign up to be an “Insider”. This is “free” in cost but does require you to provide info for them to track and monitor your usage.  If you are registered already or are okay doing so you’ll be able to read the full report and recommendations.  If you don’t want to register, the idea in general may be worth pursuing and you should explore your options.  (Wikipedia has a nice writeup on Application Delivery Networks that provides names and links to some of the vendors involved.)

Twitter Can Help You Escape Kidnappers (in South Africa)

Fascinating story at Ars Techica: "Twitter helps free kidnapped South African from trunk of his car." A man in South Africa was stuffed into the trunk of his own car when thieves stole it, but they neglected to take his mobile phone from him... and so he texted his girlfriend... who then turned to Twitter!

Twitter and kidnappingIt's actually quite a good example of how Twitter can be used by a variety of different people to help deal with a situation happening right now. We've seen this kind of response using Twitter with disasters and natural events... nice to see the Twitter network effect also helping in the case of an individual.

And very good to hear that the gent in question made it out safely.

The full story is worth a read...


If you found this post interesting or useful, please consider either:


Video: Short Documentary on 2012 Curling Nationals in Philadelphia

A gent named Jeff Albertini produced this great short video about the 2012 US National Curling Championships in Philadelphia:

Philly Curling Nationals 2012 Documentary Short from Jeff Albertini on Vimeo.

Nicely done!

Would You Buy a ".blog" Domain Name?

DotblogIf you could get a domain name ending in ".blog" for your blog site, would you buy one?

Over on Domain Incite, Kevin Murphy reports on the first applicant to publicly state that they are applying for ".blog" as part of the massive generic top-level domain (gTLD) expansion by ICANN. Murphy expects that ".blog" will probably be the most heavily contested new gTLD, meaning that multiple companies will be vying to be the registry for ".blog". He points out:

Media analysts NM Incite (great name) tracked 181 million blogs in 2011, up by about 25 million from 2010. A gTLD that could grab just 1% of that business would still be a nice little earner.

I'm not sure, myself. I remain rather skeptical that people will break out of their reliance on ".com" and go for all these other gTLDs. We've seen some of the existing gTLDs like ".biz" and ".pro" that haven't really gone anywhere. (In fact, the only .biz address I personally am aware of is the FIR podcast.)

Still, with a range of more gTLDs perhaps we finally will see people starting to use and accept other domain endings beyond .com/.org or the various country codes.

But would I register "danyork.blog"? or "disruptiveconversations.blog"?

Probably not, given that I already own the .com and .org variants on the names... although admittedly "danyork.blog" would be tempting purely because I do own .com/.org/.me/etc. and could see that one fitting in well with my "personal brand" online. Probably not for my other sites because I already have established names for them.

If I were crazy enough to start up another new blog, the ".blog" gTLD might be interesting... although to be honest I find the name "blog" to be a bit tired these days. I tend to talk more about my "sites" versus my "blogs" as the difference between what is considered a "blog" and what is considered a regular "web site" seems to get increasingly narrow. I'm not sure if I would want a new site to be labeled as a "blog".

What about you? If a ".blog" becomes available sometime in 2013, would you buy one?


If you found this post interesting or useful, please consider either:


Want To Monitor the North American IPv6 Summit? Follow #NAv6Summit on Twitter

Would you like to track what is going on at the North American IPv6 Summit this week in Denver?  If so, just follow the #NAv6Summit hashtag on Twitter. A number of people are tweeting out some of the major points and occasionally providing photos like this one:

As we noted yesterday, our Richard Jimmerson is there presenting today, in fact, as part of a panel about World IPv6 Launch.