Speaking of Standards

There’s a fascinating exchange of views over at Ars Technica on the question of “Should there be a free market for IPv4 addresses?” Or, to put it another way:

Should companies be able to buy and sell their IPv4 address blocks?

If you recall, back in March Microsoft purchased a block of IPv4 addresses from Nortel for $7.5 million, and with the ongoing depletion of IPv4 addresses available from registries, this approach of purchasing IPv4 addresses may become more common.

The two sides of the debate are represented by:

• Timothy Lee: The case for a free market in IPv4 addresses
• Iljitsch van Beijnum: Trading IPv4 addresses will end in tears

Both make for interesting reading.

I definitely agree with Iljitsch that on a technical level, a free market for IPv4 addresses will lead to severe fragmentation of the overall routing tables… and just make a big mess in general. I also agree with Iljitsch that broader adoption of IPv6 would take care of these issues… but as strong an advocate as I am of IPv6, I’m skeptical that companies will move until they are forced to… or until it becomes extremely easy for them to do so.

That said, as I mentioned in our recent webinar about IPv6 and communication applications, I fully expect to see more of these kind of transactions occurring. There are simple economics – for many companies the current cost of transitioning to IPv6 (even just undertaking the planning) outweighs the current cost of purchasing IPv4 address blocks.

Will it evolve into the full-blown free market that Timothy Lee would like to see? I don’t know… I think at some point the cost of IPv4 address blocks will start to escalate to the point where IPv6 transition will suddenly seem like a good deal. So if a free market is to exist, I see it as a temporary situation at best (where “temporary” may admittedly be measured in years)

Regardless, it’s a discussion that needs to be had because this kind of exchange of IPv4 addresses is certainly one way that companies will try to stay on IPv4 for as long as possible.

What do you think? Should there be a free market for IPv4 addresses? Or should that be restricted and not permitted?

For those tracking the the “RTCWEB/WebRTC” initiative the next “virtual interim meeting” for the IETF side of the effort will be held on Thursday, September 8th. From the announcement email:

The RTCWEB working group plans to hold an interim meeting meeting. It will be held on September 8, 2011 at 7:00 A.M. PDT. We’re currently allocating 4 hours for the meeting. Details of participation will follow on the working group mailing list (http://www.ietf.org/mail-archive/web/rtcweb/).

If you are already on the mailing list, you’ll get the announcements and agenda… if not, it’s a good time to join the mailing list!

P.S. And if you don’t know what any of this is about, see my last post.

Would you like to understand what the “RTCWEB/WebRTC” initiative is all about? And how it will enable real-time communications from within web browsers without the use of additional plugins or extensions? (like those in Flash, Quicktime, etc.)

A great place to start would be this Internet-Draft at:

http://tools.ietf.org/html/draft-ietf-rtcweb-overview

As the draft URL indicates, the document truly is an “overview” of the effort:

This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers – “real time communication on the Web”.

It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track.

The latest version, released today, includes a reference to the WebRTC specification released yesterday by the W3C.

Definitely worth a read for anyone interested in learning more about this very important industry effort.

As part of the ongoing RTCWEB/WebRTC initiative to enable real-time communications in web browsers without extra plugins or extensions, the W3C working group released its first draft of the API specification. It can be found at:

http://dev.w3.org/2011/webrtc/editor/webrtc.html

As that URL actually points to a version that will change as more edits are made, there is also a URL to a static version of what was released yesterday:

http://dev.w3.org/2011/webrtc/editor/webrtc-20110823.html

Discussion that led to the document happened up at the face-to-face meeting recently in Quebec… and continues on the public-webrtc mailing list, to which anyone can subscribe.

And yes, you’ll notice Voxeon Dan Burnett, our Director of Speech Technologies and point person on industry standards, as one of the co-editors of this document.

The RTCWEB/WebRTC effort is an incredibly important project… and I hope that as many of you as possible can take a look at the draft and contribute feedback on the (very active) mailing list.

Great to see!

If you are a network geek (like me) who likes to understand how networks are put together, there’s a great Internet-Draft out about how IPv6 works in 3GPP mobile networks such as EPS and LTE. The draft is at:

http://tools.ietf.org/html/draft-ietf-v6ops-3gpp-eps

And comes complete with ASCII network diagrams that include clouds!

Seriously, though, this is a well-done document that provides a great amount of insight into how 3GPP networks work in general and how IPv6 is used within the network. Definitely worth a read for anyone interested in IPv6 and/or the evolution of mobile networks.

Here’s the beginning of the introduction to give you the context:

IPv6 has been specified in the 3rd Generation Partnership Project (3GPP) standards since the early architectures developed for R99 General Packet Radio Service (GPRS). However, the support for IPv6 in commercially deployed networks remains low. There are many factors that can be attributed to the lack of IPv6 deployment in 3GPP networks. The most relevant one is essentially the same as the reason for IPv6 not being deployed by other networks as well, i.e. the lack of business and commercial incentives for deployment. 3GPP network architectures have also evolved since 1999 (since R99). The most recent version of the 3GPP architecture, the Evolved Packet System (EPS), which is commonly referred to as SAE, LTE or Release-8, is a packet centric architecture. The number of subscribers and devices that are using the 3GPP networks for Internet connectivity and data services has also increased significantly. With the subscriber growth numbers projected to increase even further and the IPv4 addresses depletion problem looming in the near term, 3GPP operators and vendors have started the process of identifying the scenarios and solutions needed to transition to IPv6.

This document describes the establishment of IP connectivity in 3GPP network architectures, specifically in the context of IP bearers for 3GPP GPRS and for 3GPP EPS. It provides an overview of how IPv6 is supported as per the current set of 3GPP specifications. Some of the issues and concerns with respect to deployment and shortage of private IPv4 addresses within a single network domain are also discussed.