Re: SIP now IPv6

[Steve Deering <[e-mail]>]

First thing, let's shoot all the protocol politicians.  :-(

It was an engineering choice -- not a PR choice, for heaven's sake -- to use
the version field as the mechanism by which SIP is distinguished from IPv4.
When the time came to test SIP implementations in the Internet, we were good
Internet citizens and requested a version number assignment from IANA, rather
than using a number "illegally".  Upon receiving a number assignment, Bob
Hinden announced it to the SIP and IPAE mailing lists, for the information
of those people working on implementations and protocol documents.  I am
surprised that anyone would have misinterpreted his use of the word
"official" in that message, and I am saddened and offended that anyone would
read his message as evidence of some sort of PR conspiracy, rather than as
the legitimate and routine administrative correspondence of a working group
of the IETF doing its job.  In the words of Rodney King, can't we all just
get along?

On the appropriateness and speediness of Bob's announcement message:

	- the announcement was sent to the two mailing lists used for design
	  discussions of SIP and IPAE; if he had wanted to score PR points,
	  he would probably have sent it to the big-internet list, the ietf
	  list, the tcp-ip list, or the trade rags.

	- the need for a version number assignment had been identified at
	  meetings of both the SIP and IPAE groups, and at those meetings,
	  Bob had reported that he had sent a request to IANA; it was entirely
	  appropriate for  him to announce that this action item has now been
	  discharged.

	- Hans-Werner seems to take exception to the speed with which Bob
	  announced the number assignment.  (He accused him of "...trying to
	  win PR battles with immediate announcements...".)  Does he think
	  Bob should have keep it secret for a while?  Doesn't he know that
	  we are under tight deadlines to demonstrate interoperability and
	  that resolution of administrative details like version numbers are
	  essential for meeting those deadlines?

On the appropriateness of the assignment of a version number for SIP by IANA:

	- the IP version number space is in no danger of exhaustion -- there
	  are only two (now three) numbers used up, out of a space of 16
	  (IP version 5 is ST).  The other Next-IP candidates could also be
	  assigned distinct IP version numbers without danger of using up the
	  number space, if they wanted them.  (Even though TUBA doesn't need
	  one, maybe IANA should assign it number 7 anyway, just to be "fair".
	  :-) )

	- SIP meets the normal qualifications for obtaining a well-known
	  number assignment, such as a port number, an IP protocol type, or
	  an IP multicast address.  That is, there is a written, publicly-
	  available protocol spec.  It has *not* been necessary for a
	  protocol to be an Internet Standard, or even on the Internet
	  Standards track, to obtain a well-known number assignment.  ST has
	  its own IP version number, and as far as I know it isn't an
	  Internet Standard.

On "sending the wrong signal" to the community or to "the public":

	- the number assigned to SIP is 6, not 7.  If any signal is being
	  sent, wouldn't it be that SIP is *not* (or not *yet*) IPv7?

	- in my opinion, we would be sending the wrong signal if we chose
	  *not* to assign an IP version number to SIP for political reasons.
	  That would signal that we are willing to subordinate our procedures
	  and technical judgement to the demands of PR, politics, and
	  perceptions, which would strip us of whatever advantage we might
	  have over the "other" protocol standards bodies.  We'd be just like
	  the IEEE or whoever it was who refused to allocate an LSAP for ARP,
	  because ARP wasn't politically correct.

	- yes, there is the danger that some reporter reading Bob's message
	  might write a story headlined "IANA Chooses SIP as Next Version of
	  IP".  That might confuse those folks who were told in another
	  article that Novell IPX is really the next version of IP.  It
	  would really confuse those people who know "SIP" as the SMDS
	  Interface Protocol!  The danger of misinterpretation by the press
	  is present, no matter what we do.

On IPv4 implementations that do not ignore packets of unknown version:

	- any such implementations are already vulnerable to other legal uses
	  of IP version numbers other than 4, such as by ST or ST-2.  They
	  should be fixed or retired.  (Does anyone actually know of an
	  implementation of IP that does not check the version number?)

	- as Dave Katz pointed out, an IPv4 implementation that did not check
	  the version field would ignore SIP packets anyway, due to failure
	  of the IPv4 checksum when computed over the SIP header or to length
	  inconsistencies arising from treating the first word of the SIP
	  header as if it contained IPv4 length fields.  (Dave: SIP does not
	  itself have a header checksum, so there is no danger of coincident
	  checksums in the two protocols.)

	- one potential hazard with using new IP version numbers arises in
	  the usage of TCP/IP header compression over SLIP where, due to the
	  lack of a link-layer demuxing field, some configurations treat any
	  packet with a high-order bit of 1 as if it were a packet with a
	  compressed TCP and IP header.  Therefore, any new version of IP
	  will have to be assigned a version number less than 8 if its
	  packets are to survive crossing such a link.  The number assigned
	  to SIP is safe in that respect.

On the use of the IP version field for distinguishing between SIP and IPv4:

	- as many of you know, the initial SIP proposal did not have a
	  version field.  I dislike the extra overhead of checking a version
	  field on every packet, given that it almost never changes and that
	  the link-layer already provides an adequate demultiplexing service
	  (except for SLIP, which ought to be replaced anyway).  Therefore, I
	  applied for and obtained an "official" ethertype assignment for SIP.
	  (Gee, does that mean that Xerox "officially" endorses SIP as the
	  next network layer protocol for Ethernet?)  However, I was
	  subsequently convinced to add a version field to SIP and to use
	  that to distinguish between SIP and IPv4 for the following two
	  reasons:

		(1) using the existing IP link-layer encapsulations and code
		    points greatly facilitates implementation -- it avoids
		    the need to update all the various link-layer drivers to
		    recognize a new network-layer identifier, which is
		    particularly important on those platforms on which the
		    drivers may be supplied by different sources than the
		    IP/SIP code, or any other case where source code for a
		    driver might not be available to an implementor of SIP.

		(2) link-layer encapsulation schemes and code-point
		    assignments have become so politicized that it seemed
		    best to avoid opening those cans of worms.  I never
		    guessed that the allocation of IP version numbers would
		    be susceptible to the same nonsense.

	  I wanted to add another 32 bits to the SIP header anyway, to achieve
	  64-bit alignment, so I had the bits to spare.  I did *not* add the
	  version field to SIP as part of a conspiratorial plan to dupe people
	  into thinking SIP really is the next, blessed replacement for IPv4,
	  but if it does turn out to be that, I want SIP to be no harder than
	  necessary for people to implement and deploy.

	- the argument that we're going to have to muck with the link-layer
	  anyway, to make changes to ARP, does not necessarily hold.  Initial
	  test implementations of SIP are using unmodified IPv4 ARP, using the
	  4-byte, globally-unique IPv4 addresses that are embedded in the
	  SIP addresses of the test systems, while the SIP group decides
	  whether to update ARP for SIP (bigger addresses, and multicast
	  rather than broadcast) or to be more ambitious and adopt something
	  more ES-IS-like to deal with auto-configuration, mobility, and
	  address reassignment issues, as well as address resolution.  If we
	  do something ES-IS-like, it will be in the form of ICMP messages,
	  so will not require any mucking in the link layer.

On Hans-Werner's messages:

	"Well, obviously, given the PR games people play, early number
	assignments, especially in a contentious four bit wide field where
	assignments are rarely been made, gives significant exposure and
	implicit endorsement by perception to the IPAE missive and the SIP
	missive."

	  What "missives" are you referring to?

	"Besides that, I agree with Dave Crocker in that SIPers/IPAEers are
	politizising by getting a formal number assignment out of a sparse
	space earlyon."

	  Requesting a well-known number assignment to satisfy a legitimate
	  technical requirement is not "politizising", it is routine Internet
	  procedure.  It is not "early on" -- we keep being told that time is
	  running out!  And what is the significance of the "sparseness" of
	  the space?  I could understand concern about allocations from a
	  dense space that was in danger of running out, but not from a
	  sparse space.

	"Excuse me, dudes, but what the heck is going on here. Are we cutting
	any backdoor sweetheart deals and sending powerful signals to the
	community? ..."

	  Who exactly are you accusing of cutting backdoor sweetheart deals?
	  Do you honestly suspect a conspiracy between IANA and the SIP and
	  IPAE working groups?

	"Is there an Internet Standard SIP document somewhere?"

	  No.  Is there a rule that says that a protocol must be an Internet
	  Standard to obtain an IP version number, or do you just wish there
	  were such a rule to impede the testing and deployment of SIP?

	"Does this mean that Jon can assign numbers as he sees fit?"

	  He is the Internet Assigned Numbers *Authority*, so I would expect
	  that the answer is "yes".

Enough.

Steve