September 2012 archive

ARIN Enters Phase 2 of IPv4 Countdown – Only 3 /8 Blocks Left

Today marked another milestone in the ongoing exhaustion of IPv4 addresses – the American Registry for Internet Numbers (ARIN) entered Phase 2 of its IPv4 Countdown Plan meaning that it has only 3 “/8″ blocks of IPv4 addresses left.  In fact, the counter on ARIN’s Countdown page shows only 2.89  /8 blocks left.

On a practical level, what this means is that if you want a large block of IPv4 addresses from ARIN, your request will go through a more involved review process and may incur time delays in processing.  Essentially ARIN is starting to get ready and test out their review processes for when they hit their final “/8″ block, as RIPE NCC recently did, where the review process will be even more strenuous.

All of this is just another part of the last dance of IPv4… and is yet another reason why you need to be looking at how your organization is moving to IPv6 if you have not already done so.

The time is now! Check out our IPv6 resources.  Or let us know if you can’t find what you are looking for. And just do it!

How can we help you get started?

How WebRTC Will Fundamentally Disrupt Telecom (And Change The Internet)

Old phoneIf we step back to before 1993, publishing and finding content on the Internet was a somewhat obscure, geeky thing that a very few people cared about and very few knew how to do. It involved gopher servers, ftp sites, archie, veronica, WAIS, USENET newsgroups, etc., and this "World-Wide Web" service primarily demonstrated via the server at info.cern.ch. It was an amazing period of time for those of us who were there, but the number of users was quite small.

Then NCSA released Mosaic in 1993 ... and suddenly everything changed.

Anyone could create a web page that "regular" people could see on their computers. Anyone could download Mosaic and use it. Anyone could share their sites with the installation of server software.

The Web was truly born into public consciousness... the creation of Web-based content was democratized so that anyone could do it... the creativity of developers was unleashed... a zillion new business models were thought of... and the Internet fundamentally changed.

Fast-forward to today...

... and the "Web" is still predominantly a document-based system. You make HTTP queries to retrieve pages and send HTML and XML documents back and forth between web browsers and web servers.

Separately, we have a world of telecommunication apps that have moved to IP. These are not just voice, but they are also video, instant messaging, data-sharing. They have moved so far beyond what we traditionally think of as "telecommunications". The apps use wideband audio, HD video, white boarding, sharing and so many capabilities that cannot have even been remotely imagined by the creators of the PSTN and all the legacy telcos and carriers. They are "rich communications" applications that have severely disrupted the traditional telco world.

The problem is that creating those rich, real-time communications apps is somewhat of a black art.

It is the realm of "telephony developers" or "VoIP developers" who can understand the traditional world of telcos and can interpret the seven zillion RFCs of SIP (as all the traditional telcos have glommed all sorts of legacy PSTN baggage onto what started out as a simple idea).

Deploying those rich communication apps also involves the step of getting the application into the hands of users. They have to download an application binary - or install a Flash app or Java plugin into their browser. Or on a mobile device install an app onto their mobile smartphone.

The world of rich communication experiences is held back by development problems and deployment problems.

Enter WebRTC/RTCWEB

Suddenly, any web developer can code something as easy as this into their web page:

------
$.phono({   
   onReady:   function()   {
       this.phone.dial("sip:9991443046@sip.example.net")
 } } );
------

Boom... they have a button on their web page that someone can click and initiate a communications session ... in ANY web browser. [1 - this is not pure "WebRTC" code... see my footnote below.]

Using JavaScript, that pretty much every web developer knows... and using the web browsers that everyone is using.

And without any kind of Flash or Java plugins.

Boom... no more development problems. Boom... no more deployment problems. [2]

WebRTC is about baking rich, real-time communications into the fabric of the Web and the Internet so that millions of new business models can emerge and millions of new applications can be born.

It is about unleashing the creativity and talent of the zillions of web developers out there and turning the "Web" into more than just a document-based model but instead into a rich communications vehicle. It's about moving these apps from an obscure art into a commonplace occurrence.

We really have absolutely no idea what will happen...

... when we make it as simple for ANY developer to create a rich, real-time communications experience as it is to create a web page.

But we're about to find out... and done right it will fundamentally change the Internet again.

If we think the legacy telco crowd are upset now about how "VoIP" has screwed them over (from their point of view), they haven't seen anything yet. WebRTC/RTCWEB doesn't need any of their legacy models. It bypasses all of that in ways that only the Internet enables. It is NOT shackled to any legacy infrastructure - it can use new peer-to-peer models as well as more traditional models. And it goes so far beyond what we think of as "communication" today. [3]

I see it as the next stage of the evolution of the Internet, disrupting to an even greater degree the business models of today and changing yet again how we all communicate. The Internet will become even more critical to our lives in ways we can't even really imagine.

THAT is why RTCWEB (in the IETF) and WebRTC (in W3C) are so critically important ... and so important to get deployed.


[1] The code I'm showing is for a library, "Phono", that in fact will sit on top of the WebRTC/RTCWEB protocols. It is an example of the new apps and business models that will emerge in that it makes it simple for JavaScript developers to create these apps. Underneath, it will use the rich communications protocols of WebRTC/RTCWEB. Someone else will come up with other ways to do this in JavaScript... or python... or ruby... or whatever language. But because they will all use the WebRTC/RTCWEB protocols, they will interoperate... and work in any browser.

In full disclosure I should also note that Phono is a service of Voxeo, my previous employer.

[2] And BOOM... there go the heads exploding within the legacy telco crowd when they start to fully understand how badly the Internet has rendered them even MORE irrelevant!

[3] Note that a WebRTC app certainly can communicate with the traditional PSTN or other legacy systems. My point is that it is not required to do so. One usage of WebRTC will, I'm sure, be to "web-enable" many VoIP systems (ex. IP-PBXs) and services. But other uses will emerge that are not connected at all to the PSTN or any legacy systems.

Image credit: dmosiondz on Flickr


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


FIR #669 – 09/17/12 – For Immediate Release

Twitter handle now @FIRpodcast; FIR Book Review coming; Dr. Pepper vs creationists on Facebook; James Bond trades Martini for Heineken; FCC chairman blows tweetchat; 'kerfuffle' the best word ever; Ragan promo; social media and diplomacy; Michael Netzley's Asia report; Media Monitoring Minute; Deloitte's social technologies report; listener comments; welcome to the #SocialEra; TemboSocial promo; Dan York's report; what makes content marketing succeed; music from The Revivalists; and more.

Tor (The Onion Router) Expands IPv6 Support in 0.2.4.1-alpha

Tor Project logoLast week the Tor Project announced a new alpha release 0.2.4.1 that includes as one of its major features expanded support for IPv6. From the release notes:

  • Bridge authorities now accept IPv6 bridge addresses and include them in network status documents. Implements ticket 5534.
  • Clients who set “ClientUseIPv6 1″ may connect to entry nodes over IPv6. Set “ClientPreferIPv6ORPort 1″ to make this even more likelyto happen. Implements ticket 5535.
  • All kind of relays, not just bridges, can now advertise an IPv6 OR port. Implements ticket 6362.
  • Directory authorities vote on IPv6 OR ports using the new consensus method 14. Implements ticket 6363.

This builds on an earlier 0.2.39 alpha in December 2011 that introduced initial IPv6 support and  follows on some plans for IPv6 support written earlier in 2011.

If you are not familiar with the Tor Project it is a widely used tool for protecting your privacy and enabling anonymous use of the Internet without being tracked.  The history of Tor is quite interesting because it originated with a desire within the U.S. Navy to protect online government communications but today is used by many people who want to access Internet services without exposing their identity and/or location.

Tor has many uses across a wide range of fields… and now, at least in an early release version, it can work even better across IPv6!

Can You Add 1 Line of HTML To Your Site To Help Measure DNSSEC Usage?

DNSSEC validator search resultsCan you please help out with efforts to measure the number of DNSSEC-validating DNS resolvers out there?

The folks at Verisign Labs are conducting some research into trying to understand what level of DNSSEC-validating resolvers are out on the open Internet. This is critical to understand as the availability of DNSSEC-validating resolvers is a key piece of getting DNSSEC deployed.

They are asking for your help.

If you operate a website, they are asking if you can please add one line of HTML to your site, preferably in a page header, footer, sidebar or other component that gets frequently loaded:

<a href=”http://prefetch.validatorsearch.verisignlabs.com”></a>

That’s it!  As they say on their page:

This HTML snippet should have no visible impact on a rendered page. Since nearly all web browsers now implement DNS prefetching, the code above results in a DNS query for the name shown and allows us to characterize the recursive name server that the query goes through.

They also mention that you can alternatively modify the HEAD element of your page to include this one line of code:

<link rel=”prefetch” href=”http://prefetch.validatorsearch.verisignlabs.com” />

I’ve chosen this latter approach here at Deploy360 and as a result visitors to our site will be helping with this important research.  If we can get more sites adding this code, Verisign Labs can get that many more data points feeding in and helping them characterize the level of DNSSEC validating resolvers out there.

Here at Deploy360, we are in favor of research like this because we’d like to get a baseline now and then see trends over time.  Encouraging the wider deployment of DNSSEC-validating resolvers by ISPs and other network operators is one of the key activities we are planning to work on over the next 12 months – and this research will help us and many others understand how successful we are collectively in encouraging that deployment.

Can you please help you by adding a line of code to your site?  (Thanks!)

P.S. For those curious to learn more about “DNS prefetching” (also called “pre-resolving” by some) and how this research works, here are some articles you may find of interest:

FIR #668 – 09/10/12 – For Immediate Release

New Speaker and Speeches available; CW Bulletin addresses Wikipedia; Quick News: Connectify gets Kickstarter funding, Kred rolls out Salesforce.com integration, WordPress live-blogging plugin released, content marketing budgets rise; Ragan promo; News That Fits: information overload was a myth, Dan York's report, Media Monitoring Minute, the PR war over fracking, listener comments, communications planning needs to account for two screens, TemboSocial promo, Michael Netzley's Asia report, BBC guidance on headline-writing SEO; music from Annie Stevenson; and more.

Speaking in Montenegro about DNSSEC on September 12

ccTLD conference in MontenegroOn Wednesday of this week I’ll be speaking about DNSSEC at the 5th international conference for ccTLD registries and registrars of CIS, Central and Eastern Europe in Budva, Montenegro.  I’m very much looking forward to this event as it is entirely focused around the concerns of registries and registrars – and they are one of the key groups who can accelerate the deployment of DNSSEC.  In fact, you can see DNSSEC come up a few times on the agenda  – and I’m looking forward to hearing the case study of the .UA deployment of DNSSEC.

My session on Wednesday is titled “Key Steps in Accelerating DNSSEC Deployment” and for the registries and registrars the steps really can be ultimately reduced down to these:

  • Registries need to make it as simple as possible for registrars to upload DS (Delegation Signor) records into the registries’ zones.
  • Registrars need to make it as simple as possible for DNS hosting providers to upload DS records into the registrars databases.

Those two steps right there would greatly accelerate the deployment of DNSSEC in those ccTLDs.

That’s not all I’ll talk about, of course.  I’m also going to be discussing the growth of the .NL signed domains as that example may be something some of the ccTLDs can replicate. I’ll be talking about how the ongoing work with DANE securing SSL/TLS certificates via DNSSEC should spur enterprise interest in deployment.  I’ll be providing some examples of a good user experience … and much more.  I’ll be making the slides available later and potentially an audio or video recording if I am able to do so.

The main point of my attendance, too, is to interact with registries and registrars and find out what we can do to make it easier for them to deploy DNSSEC.  That feedback will certainly help our DNSSEC content roadmap and help us prioritize what materials we are creating first.

If you attending the event I look forward to meeting up with you,  and I look forward to learning from those there about DNSSEC – and all the other issues – in the Central and Eastern European region.

New Mailing List for “Migrating Apps to IPv6” Updates

Would you like to be notified when updates are made to “Migrating Applications to IPv6“?  If so, there’s a nifty little sign-up box over in the right sidebar that will add you to an email distribution list that I will use ONLY to alert you to news about the book.  Info about updates will also be posted here to the book’s blog, of course, and will also appear on the Google+ page and in my normal Twitter stream. But I realized recently that some readers might want to receive specific messages when updates are available.  If you purchase the ebook directly from O’Reilly, you’ll get notified through their notification system, but if you purchase through another retailer – or would just like to receive an extra update, please feel free to subscribe.  I promise I won’t spam you or do anything else with your email address outside of alert you to the new updates.

Thanks for your interest in the book!

AdhearsionConf 2012 Call For Speakers Ends Tomorrow (Sept 8)

Adhearsionconf2012Do you like building telephony apps with Adhearsion? Have you built a really cool app that is worth sharing? Or used Adhearsion in an unusual way? Are you planning to attend AdhearsionConf 2012 in Palo Alto on October 20-21? Or would you attend if you could speak?

If you answered yes to any of the above questions, why not consider applying to be a speaker? The call for speakers is at:

http://adhearsionconf.com/call-for-speakers/

The only catch is ... the deadline is TOMORROW, Saturday, September 8th!

Ever since I first saw Jay Phillips present about Adhearsion back at one of the early ETel conferences in maybe 2006 or so I've been intrigued by how easy Adhearsion made it to develop telecom apps. It's just incredibly simple to make powerful apps.

If you are a Ruby developer (or want to be) and you are interested in building telephony apps, Adhearsion is definitely worth a look... and if you do use Adhearsion, why not consider signing up as a speaker?


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


.NL Becomes First TLD To Pass 1 Million DNSSEC-Signed Domain Names!

History was made today in the ongoing effort to deploy DNSSEC globally and bring about a more secure Internet -

.NL became the first top-level-domain (TLD) to pass 1 million DNSSEC-signed domain names!

Celebrated in tweets from SIDN, the operator of the .NL registry, and from Bert Hubert, principal author of PowerDNS, as well as in an announcement from SIDN, the milestone can be clearly seen in the unofficial .NL statistics site operated by PowerDNS:

It is also visible on SIDN’s home page where they also show the total number of .NL domains:

Note, too, the significance of those numbers –

over 20% of all .NL domains are now signed!

Outstanding to see… and we look forward to seeing how much higher it grows.

We’ve previously covered (also here) the rise of the .NL domain and we’re delighted to see them hit this milestone! Kudos to the folks at SIDN, PowerDNS, SURFnet, NLNet Labs and everyone else involved!

Now we just need to get all the other TLDs moving on the same path!  (Including .COM, which has just over 106,000 domains signed… as Bert commented to me on Twitter, .NL had more signed delegations added yesterday than .COM has in total!)

Want to help?  Here are some steps for how you can get started signing your domain!