Speaking of Standards

I’ve mentioned the “RTCWEB” initiative in the past and in particular the BOF session the group was having at IETF 80 this week in Prague. That session has now been held and Christer Holmberg nicely distributed some notes for those of us who couldn’t attend.

The end result seems to be that Harald Alvestrand has now distributed a revised charter for the IETF work which again sets out this overall goal:

There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers’ web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients.

The charter is worth a read … and if you are interested in getting more involved, the best way is to join the rtc-web mailing list. It’s definitely a critical initiative in my mind… and I’m looking forward to seeing where it goes.

As I mentioned before, this year the SIP Forum is holding its first ever SIPNOC: The SIP Network Operators Conference event on April 25-27 in Herndon, Virginia, just outside of Washington, DC. The abstract of the event is:

SIPNOC is a unique event for service providers and carriers to gather to discuss the challenges of deploying and implementing SIP-based communications technology, and to learn the best-practices and strategies that enable the successful and profitable operation of SIP-based services and applications. SIPNOC is not a sales event, a marketing event, nor an event for corporate positioning.

The tentative schedule is now out and as I note over on our page for the event, I’ll be speaking twice at the event. In one panel I’ll be wearing my VOIP Security Alliance hat and talking about communications security. In the other session I’ll be speaking about some of the lessons we’ve learned at Voxeo in building the large-scale, global carrier-grade SIP infrastructure we operate.

It should be a fun event and I’m very much looking forward to being down there in DC with the SIP Forum crowd! If you can join us there, it should be a great event for anyone operating a network using the SIP protocol.

The 80th Meeting of the Internet Engineering Task Force (a.k.a. IETF 80) is happening this week in Prague, Czech Republic, and Dan Burnett, Voxeo’s Director of Speech Technologies, is on the ground there attending sessions on Voxeo’s behalf.

If you’d like to meet up with him, you can contact him at dburnett@voxeo.com. Odds are that you’ll also find him in most of the “RAI” (Realtime Applications and Infrastructure) area sessions as those are the ones dealing with SIP and the other protocols important to the kind of communication we’re involved with.

You may be most familiar with Dan from his leadership over in the other major standards organization, the W3C, where he co-chairs the Voice Browser Working Group which is the group overseeing standards such as VoiceXML, CCXML, SCXML, SSML and an alphabet soup of others. Dan is also the primary editor right now on the emerging VoiceXML 3 specification.

Over on the IETF side, Dan’s been active in a number of the working groups and has been the main editor of the Media Resource Control Protocol (MRCP) version 2 specification that is working its way toward completion.

Anyway, Dan’s there in Prague if you would like to connect…

Aren’t going to be in Prague this week for IETF 80 but still want to participate? Thankfully as per usual the IETF has provided a number of ways to join in remotely, all shown here:

http://www.ietf.org/meeting/80/remote-participation.html

Streaming audio is available for all the rooms where the formal meetings take place and this time around there are also WebEx sessions for many of the events.

A list of materials for each of the meetings is available on this page (do note that often the materials for each session are being updated right up until the session begins):

https://datatracker.ietf.org/meeting/80/materials.html

There’s a great agenda page that lets you see all the sessions, download the relevant docs and join the relevant Jabber room at:

http://tools.ietf.org/agenda/80/

Keep in mind that Prague is on Central European Time which is currently UTC+2, so it’s 6 hours earlier than where I live in US Eastern Time. (Translation: Sorry, but I’ll be missing the 9am CET sessions!)

Note also that both the streaming audio and the WebEx sessions are one-way broadcast ONLY. To provide feedback back into the session or to raise a question remotely, you need to be participating in the appropriate Jabber chat room. For each session there is someone acting as the “Jabber scribe” who will step up to the microphone and ask questions that come in remotely. The transcripts of the chat rooms are also archived for later viewing if you can’t attend.

And of course there are also the ubiquitous mailing lists that exist for each of the IETF working groups. However, these links above let you participate in a more “real-time” matter. All in all it’s very cool that the IETF makes all these participation methods available for those who can’t attend… kudos to all the volunteers, staff and others who make it happen!

Where is IPv6 actually being used? Inspired by a presentation he saw, Mark Prior decided to go out and survey sites from various universities, Internet Service Providers (ISPs), corporations and other entities to see who was actually using IPv6 on a daily basis.

His survey criteria were pretty straightforward:

1.Web server accessible via IPv6;
2.Email deliverable via IPv6;
3.DNS name servers accessible via IPv6;
4.An NTP service accessible via IPv6; and
5.A Jabber service accessible via IPv6

What he found, though, was a whole lot of “FAIL”… see for yourself at:

http://www.mrp.net/IPv6_Survey.html

He explains there more details of his criteria and the partial points he awarded in some cases. I agree with his first three criteria in that I think all organizations will ultimately need web, email and DNS accessible via IPv6. I’m not so sure of his final two (NTP and XMPP), but certainly in some environments those are quite common.

Anyway, he goes on to provide long lists of the sites he surveyed with do make for interesting reading. For instance, I found it interesting that of all the Internet2 members, only UCLA and the University of Maine received full success marks on the first three criteria (with Virginia Polytechnic Institute almost there). It was also perhaps not surprising to see the high success rates within the National Research and Education Networks.

Toward the end, he also lists all the entities that have signed on to World IPv6 Day coming up on June 8, 2011, most of whom are NOT yet showing IPv6 connectivity to their websites.

He indicates that the survey will be continually updated and has a timestamp at the bottom of the page for when it was last updated.

Mark has also provided a way for anyone to test a domain using his script here:

http://www.mrp.net/cgi-bin/ipv6-status.cgi

All in all a very cool initiative. Kudos to Mark for putting it all together and making it available.

With the end of IPv4 address allocations, it’s no surprise to see that blocks of the remaining IPv4 addresses will be put up for sale. In this case, though, I was surprised by the buyer. Nortel Networks, Inc., has petitioned the bankruptcy court to allow it to sell a block of 666,624 IPv4 addresses to none other than Microsoft for the nice price of $7.5 million.

The court document makes for interesting reading, and says this about the address block in question (“NNI” = “Nortel Networks Inc”):

The Internet Numbers consist of 666,624 IPv4 Numbers that were allocated to NNI’s predecessors in interest in the 1990s, which entities were ult imately merged into NNI. Of the 666,624 IPv4 Numbers proposed to be transferred to the Purchaser pursuant to the Agreement, 470,016 are available for immediate use by the Purchaser (the “Initial Legacy Numbers”), and the remaining 196,608 are currently being used in connection with the provision of transition services to existing purchasers of Nortel’s business lines, and would not be transferred to the Purchaser until those respective agreements terminate later this year (the “Subsequent Legacy Numbers”)

It also shows that the folks involved with Nortel’s bankruptcy realized that they had an asset here that was worth shopping around:

NNI began actively marketing the Internet Numbers in late 2010, following its research into the potential value of the assets and the opportunities to realize such value. …

On behalf of the Seller, Addrex forwarded solicitation materials to over eighty (80) potential purchasers in early December, 2010. The Seller signed non-disclosure agreements with fourteen (14) potential purchasers, who were then provided access to an electronic data room containing summary financial information, an initial process letter, chain of custody information, and draft agreements. The Seller received bids in January, 2011 from four (4) potential purchasers who bid for the entire portfolio of Internet Numbers, along with three (3) addit ional bids for less than all of the Internet Numbers. Pursuant to the bid process letter, the bids included a full markup of the draft sale agreement.

With the result of that process being this agreement for sale to Microsoft.

Given the end of IPv4 availability, my first response was to wonder why they didn’t go for an auction, but that, too, is addressed:

The Debtors believe that the sale of the Internet Numbers to the Purchaser without an auction is the best way to maximize value for their estates. As described above, the proposed Agreement is the result of an effort by Nortel to market the interests to numerous potential bidders and the Purchaser was selected as the highest and best bidder following the marketing process. Based on this marketing process, the Debtors have concluded that it is unlikely the Debtors would realize a higher purchase price for the Internet Numbers that would warrant the costs and delays associated with a further formal auction process.

I would wonder, though, if that decision was made before the actual end of IPv4 allocations back in February.

Regardless… I expect we’ll see more of this kind of thing going on as IPv4 addresses become scarcer commodities.

Note that this is a request to make the sale. The sale has not happened yet and there is a hearing on the matter coming up on April 26, 2011. So there still could be changes. (A fact pointed out by the President and CEO of ARIN in a comment to a post on another site.)

Note, too, that this nets out at around $11.23 / IP address, a fact pointed out by other posts.

Image credit: quinnanya on Flickr

With the launch of Firefox 4 today, the folks at Mozilla also launched a very cool site focused on HTML5 at:

https://demos.mozilla.org/en-US/

Very cool demos… I like the 360 degree video and the Letterheads among the various demos. Cool stuff… try it out!

Note, of course, that you need to use Firefox 4 or a latest build of Google Chrome, Safari or another modern browser.

This week the IETF issued the “Last Call” for comments on version 2 of the Media Resource Control Protocol (MRCP), a.k.a. “MRCPv2″. Voxeo’s Dan Burnett is the editor for the specification and this week released the 24th (and hopefully final) revision of the document:

http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2

I’ve written about MCRP before, in November 2008 and then in September 2009, but if you aren’t familiar with MRCP, it is a protocol that allows platforms such as our Prophecy platform to easily interact with Automatic Speech Recognition (ASR) or Text-To-Speech (TTS) engines. You can think of it like this:

MRCP is an open standard that enables your application platform to connect to any “MRCP-compliant” speech engine. This can allow you to connect to speech engines that, for instance, support a language that is not one that we commonly make available. Or you might have a very specialized speech engine for a specific use case. I recall one customer who was looking to do speech recognition in a very noisy environment and wanted to use a very specialized speech engine that they had access to. Because that speech engine was MRCP-compliant our platform could connect to it. That’s the kind of interop that MCRP can enable.

As the IETF Last Call announcement indicates, the IESG is asking for comments by April 13, 2011. After this Last Call process, the IESG will make a decision that will hopefully lead to MRCPv2 being published as an RFC. (If not, there could be another review process.)

Did you know that Apple’s “Back To My Mac” service uses IPv6? Or that it sets up its encrypted tunnels using IPSEC and uses dynamic DNS?

Those are just a few of the fascinating pieces of info in an Internet-Draft that just recently (March 10) issued a new version:

http://tools.ietf.org/html/draft-zhu-mobileme-doc

As the abstract notes:

This document describes the implementation of Apple Inc.’s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery and end- to-end connectivity in face of Network Address Translators (NAT) and mobility of devices.

The introduction of the document gives an overview of what is inside:

Apple Inc.’s Back to My Mac (BTMM) service was first shipped with MAC OS X 10.5 release in October 2007, since then it has been widely used. BTMM provides an integrated solution to host mobility support, NAT traversal, and secure end-to-end data delivery through a combination of several existing protocols and software tools instead of designing new protocols. Note that we generally refer to Network Address Port Translation (NAPT) as NAT in this document. This document describes the implementation of BTMM and we hope the reader find it informative.

BTMM provides secure transport connections among a set of devices that may be located over a dynamic and heterogeneous network environment. Independent from whether a user is traveling and accessing the Internet via airport WiFi, or staying at home behind a NAT, BTMM allows the user to connect to any of Mac hosts with a click, after which the user can share files with remote computers or control the remote host through screen sharing. When a user moves around and changes locations and hence the IP address of his computer (e.g. roaming around with a laptop and receiving dynamically allocated IP address), BTMM provides a means for the roaming host to update its reachability information to keep it reachable by the user’s other Mac devices. BTMM maintains end-to-end transport connections in the face of host IP address changes through the use of unique host identifiers. It also provides a means to reach devices behind a NAT.

BTMM achieves the above functions mainly by integrating a set of existing protocols and software tools. It uses DNS-based Service Discovery [DNS-SD] to announce host reachability information, dynamic DNS update [RFC 2136] to refresh the DNS resource records (RRs) when a host detects network changes, and DNS Long-lived Queries (LLQ) [DNS-LLQ] to notify hosts immediately when the answers to their earlier DNS queries have changed. BTMM uses IPv6 Unique Local Address(ULA) [RFC 4193] as the host identifier, and employs the NAT Port Mapping Protocol (PMP) [NAT-PMP] to assist NAT traversal. It uses Kerberos [RFC 4120] for end-to-end authentication, and uses IPsec [RFC 4301] to secure data communications between two end hosts.

What I immediately found fascinating was the usage of IPv6 Unique Local Addresses (ULA – defined in RFC 4193). Think of the IPv6 ULA space as essentially like the IPv4 RFC1918 private address space (10.x, 192.168.x, etc.). A big block of IP addresses that are not publicly routable. They are designed to be used inside of a site or private network.

In effect, that’s what Apple is doing… creating a secure, encrypted IPv6 tunneled network between your devices and Apple’s servers. The document dives into great detail about how the Back To My Mac (BTMM) service works using tunneling, dynamic DNS, NAT traversal, IPSEC and more.

If you’re an Apple user or are just interested in network technologies and/or IPv6, the document is definitely worth a read!

Kudos to the team involved for all the work they put into creating this truly fascinating document.

Do you want to get your home network set up with globally routable IPv6 addresses? If you have an Apple WiFi base station, I previously explained the easy instructions for how to configure IPv6 using an Apple AirPort or Time Capsule. However, ever since I wrote that, I’ve had people ask me…

What if I don’t have an Apple base station? How can I get IPv6 via Tunnelbroker.net?

The answer is that yes, you most certainly can get IPv6 from Tunnelbroker.net.

The initial steps are basically identical to what I wrote in the other post..

1. Register with Tunnelbroker.net

Head over to Tunnelbroker.net and register for a free account if you don’t already have one:

2. Create a new IPv6 tunnel

Once you are logged in, you click on “Create Regular Tunnel”, which will bring you to this page: (I already have created 1 of the 5 tunnels you can create with a free account, so my screen may be different from what you see)

All you really need to do here is copy/paste the IP address you are viewing from into the “IPv4 endpoint” box on the form:

You also need to choose which of the Tunnelbroker servers are nearest to you, but odds are you can just take their recommendation. After entering the IP address and server selection, just hit “Submit” and you’ll have your IPv6-to-IPv4 tunnel all set up on the Tunnelbroker side. Click on the “Tunnel Details” link on the confirmation page and you should see a page like this:

Now you are ready to configure your home network to use IPv6…

3. Obtain the instructions for your operating system

This next part is going to be different for each of you depending upon what operating system you are using and even what device you are connecting the tunnel to. If you are just connecting a single computer inside of your home network, you can just perform the operations here from that one computer. If you are going to going to connect from whatever router or gateway you have on the edge of your network and then do routing for the devices on the inside of the network… well… you may or may not have to do a bit more work.

Regardless, the folks at Hurricane Electric provide this nice, handy drop-down menu at the bottom of your list of tunnels:

Choose an option and you’ll see what you need to do. For instance, here was one set of Linux instructions for one of my tunnels:

With those instructions you should be able to get up and going with IPv6. If the instructions don’t work for you, I’ve found the Tunnelbroker forums to be a great resource as well.

Two Critical Caveats

As I wrote about in the earlier article in more detail, there are two important things to think about with using this setup:

1. Tunnelbroker.net relies on a static IPv4 address on your end

2. Do think about security – you have a live, PUBLIC IPv6 address

Please refer to my earlier article for more details, but these are critical issues to be aware of when setting up your home network.

In The End…

If you’ve done all of this, you should now have IPv6 connectivity on your home network (or single machine). A simple test is to try out these sites:

• http://www.ipv6-test.com/ – will give you a full report on your IPv6 and IPv4 connections
• http://www.kame.net/ – the turtle will dance if you have IPv6, and will be still if you don’t.

If you have IPv6 working, you can then go check out Google, Facebook, Netflix, CNN or any of the many other sites now offering IPv6 connectivity.

Enjoy!