SIP Typos

Dear Mr. Stallings, and Mr. Jacobsen,

The Session Initiation Protocol article by Mr. Stallings in the Internet Protocol Journal, Volume 6, Number 1, March 2003, provides an excellent tutorial on the subject, IMHO.

The article does an extraordinary job at presenting what is quite a complicated protocol (SIP) in simple terms. However, there seem to be some typographical errors in the article, which I wanted to bring to your attention:
In Figure 2, message number 10 should be "180 Ringing" as opposed to "100 Ringing."
In Figure 2, the line under message number 14 should be pointing in the opposite direction (that is from Bob's proxy to Alice's proxy).
In Figure 2, message number 16 should read only "ACK" not "180 ACK."
In Figure 2, message number 15 should perhaps read as "200 OK" as opposed to just "OK"
In Figure 3, message number 5 should read "200 OK" as opposed to "200 Trying"
Figure 4 message number 5 and 7 should perhaps read as "NOTIFY " as opposed to ""
Figure 4 "User Agent Bob" should be labelled as "<signed in>" as opposed to "<not signed in>"
There are missing closing angular brackets in the SIP INVITE message listing on page 27:
To: Bob >sip:bob@biloxi.com<
From: Alice >sip:alice@atlanta.com<;tag=...
There are missing closing angular brackets in the SIP 200 OK message listing on page 28:
To: Bob >sip:bob@biloxi.com<:tag=...
From: Alice >sip:alice@atlanta.com<;tag=...

Sincerely,

—Rajnish Jain, Excel Switching Corp.
rajnishjain@xl.com

The author responds:

Rajnish,

Thanks for the comments. I am embarrassed that so many errors slipped through, even though I and several reviewers for Ole checked the paper.

—Bill Stallings
ws@shore.net


DoD and IPv6

Dear Geoff,

After reading your article, I couldn't help but notice the U.S. Department of Defense's announcement concerning their intentions to adopt IPv6 in the coming years (see "Fragments"). Given that you've made some strong statements about the value of IPv6 in your article, would you care to offer some views about this announcement?

—Ole

Dear Editor,

As I said in the article, the true value of IP v6 lies in the massive amount of coherent address space that allows literally billions of devices to be uniquely addressed. Address uniqueness is a strong value proposition when you want an identifier space to cover a very large deployment space. As an example of this, one of the two properties of the original Digital-Intel-Xerox Ethernet II specification that remains in today's 10 Gigabit Ethernet specification is unique MAC addresses. All of that highly innovative CSMA/CD thinking that at the time we thought was the fundamental property of Ethernet has been dispensed with.

The general observation is that any communications systems requires any party to be able to uniquely identify any other party in order to initiate a private communication session. If you cannot perform that most basic of communications functions, then you simply do not have a functional peer-to-peer communications network.

But doesn't that mean that the stories of IPv4 address exhaustion have some substance? With the large amount of addressable devices hidden behind NATs, and the associated move to using domain names as the underlying identifier space for many communications applications, the pressure on consumption of IPv4 address space has been reduced considerably. This has implied that in a world of human-driven screens and keyboards we see some considerable lifetime left in the admittedly comfortable world of IPv4 as we know it. To support this model we've actually moved away from the IP address as the unique identifier token for many applications, and substituted an application model that is driven from domain names. As an example, consider the virtual hosting mechanism as implemented in Apache Web servers to see this shift in communications identifiers from address to domain name. And both as consumers of the technology and as an industry we can live with this for some time yet, because we appear to concentrate our use IP addresses as a routing and forwarding framework and increasingly use the DNS as the identifier realm of an application.

But our world is a world where the device is subservient to the user, and the applications we associate with the Internet of today are applications that are essentially human pastimes, such as e-mail, Web browsing, or high-value automated transactions, such as those commonly bracketed into the e-commerce area. And we've now established a highly valuable global industry upon these foundations.

But in so doing we should recognize the emergence of a second set of communications realms populated by uniquely identified devices that number in their billions, where the inter-device traffic is not human mediated, and the value of the device transactions are, on an individual transactions value level, far lower than the value of the human-driven realm of IPv4. In other words, in a device rich communications realm, it's likely that the human value we'd ascribe on average to each packet is far lower than our current Internet IPv4 world of human-mediated communications. And it's this extravagantly device-equipped world that we see the U.S. Department of Defense heading. If your stock in trade is one of quite astounding feats of logistical deployment of large numbers of people and large numbers of items of equipment, then the communications requirement is of a different order of scale to that of the retail Internet markets, and, yes, I'm sure that there are entirely effective arguments behind that decision to look forward to a communications realm with a uniform base protocol identifier domain in a scale that is 2 to the power 96 times larger than the entire IP address identifier domain of IPv4.

But I would be cautious about high levels of expectation that this immediately translates into an impetus in the market where you and I converse. My host here where I'm typing this message is already IPv6 capable, and if you are running a recent version of host software, then it's a reasonable assumption that yours is too. But I'll send this message over IPv4 and you'll receive it over IPv4, and between my mail sender and your mail receiver the transport channel will also be IPv4. Should we use IPv6 instead? Would I pay my provider additional money to compensate it for part of its additional expenditure to support a simultaneous IPv6 capable network between you and me? To send precisely the same message? In precisely the same time? Along the same path? Using the same transport TCP session? Obviously, to me, as a (hopefully) economically rational consumer of such services, and no doubt to you, in a similar role, there is no value in spending more money to achieve outcomes in IPv6 that are identical to what we can already do today in IPv4. And in the retail Internet world that remains the basic IPv6 conundrum. Why should any provider spend additional resources to service the same market with identical services, and in so doing be unable to raise additional revenue to offset their additional service costs? One interpretation is that there is no natural motivation for such activities in today's market, otherwise it would already be very widespread indeed.

What we've seen in the mainstream Internet world is an emerging mythology about IPv6 that somehow this additional expenditure, ultimately on the part of the consumer, provides some additional benefit for the consumer, motivating them to switch from IPv4-only services to some hybrid of mixed v4 and v6 and ultimately to a v6 world, and thereby funding the additional provider expenditure associated with such a massive transition.

The reality is more sobering in that in the retail Internet world there is so far nothing obvious in the "additional benefit" category. I'm using Network Address Translation (NAT) right now, using an ssh session back to my mail server that drives through NAT boxes to make a secure SMTP session, across a first step of 802.11 wireless in order to send this message to you.

I've auto-configured in the wireless world, and for me I'm living in a plug-and-play world that supports my level of roaming access. Would IPv6 make this session any more secure? Any different in terms of Quality of Service (QoS)? In plug-and-play models of roaming? Would there be any visible difference in terms of my ability to communicate with you? To all of these questions the basic answer is still "no."

So, for you and I, we look inside the IPv6 technology box, and find nothing new there to motivate us to spend more money for our existing Internet-based communications services, and for some time to come it would appear that this will still hold.

On the other hand there are circumstances where there is a need to operate in a much larger base protocol address space. These include situations where one wants to take advantage of Internet applications that operate across a world of literally billions of devices, large and small. The application space may want to gather constant reports on the characteristics of the "thing" it is attached to, from a ration pack to a component of a large naval vessel. You may want to use supply channels for such devices such that the deployment is a plug-and-play world without a massive variety of detailed configuration processes. You may be looking to an architecture that would be stable for many years. In such circumstances you really want take advantage of a uniform set of Internet application technologies that potentially span massive numbers of addressable devices. Here a large base address space is a definite asset. And for such industry sectors in voicing such requirements where there is also a somewhat different ultimate value proposition for the supported communications activity, then it's quite understandable that there can be an attractive proposition offered by immediate adoption of IPv6.

But back in the communications realm where you and I currently exchange our messages, such requirements remain in a future framework that is still waiting for relevant value propositions that allow it to gain traction with you and me. And as I attempted to point out in the article, adding some elements of mythology and over-stating the IPv6 value case won't help here.

Maybe we just need to be patient. Steam ships did not halt operation the first day a diesel powered vessel appeared. It was a much slower process that lead to an outcome of the change of the maritime fleet?the next generation of mechanization offered cheaper services, and, as often happens, market price won in that commodity market.

Market price often wins in competitive commodity markets. And the Internet retail market is, in many parts of the world and in many sectors, a strongly competitive space with all the characteristics of a commodity offering. In addressing such initial specialized dedicated communications requirements with IPv6 technology as represented by the U.S. DoD, there is a distinct possibility that there may be some effective use of initial investment that translates into the retail world in some form of efficiency gain for IPv6-capable providers.

And there no doubt that if you and I could communicate in precisely the same fashion as we do today, with precisely the same applications and service environment, using precisely the same host devices and operating systems as we do today, but at some attractive fraction of today's price, then I'm sure that neither of us would care in the slightest that our data was encapsulated using a packet framing format and address tokens that used the IPv6 protocol specifications.

Kind regards,

—Geoff Huston, Telstra
gih@telstra.net