SIP now IPv6

[Dave Katz <[e-mail]>]

Actually I suspect that more ARP implementations will break than will IPv4
implementations (unless the IP header checksum field is in the same place in
SIP as IPv4), since these are notoriously bad about checking all of the
fields.

I think it will be difficult to demonstrate that this does not cause
problem with existing implementations until it is far too late to change
it (i.e., after broad deployment).

I would make the claim that conservative engineering practices suggest that
the right place to do demultiplexing is the place where it is already known
to work, as opposed to a place where it is not done in practice.

   Org: The Branch Office, Sunnyvale CA
   Phone: [phone]; fax: [phone]
   Date: Thu, 24 Dec 92 14:52:08 -0800
   From: Dave Crocker <[e-mail]>
   X-Mts: smtp

   HWB, et al.,

   Always interesting to see straightforward engineering work become
   politicized.

   But since the discussion has finally gotten into the realm of technical
   options, I'd like to suggest that the IP version field is _exactly_ the
   right place to mark the difference, unless there is strong evidence that
   it truly isn't viable, technically.  

   The protocol is trying to run on top of all the existing IPv4 sub-network
   support, e.g., Arp.  The protocol is, in fact, a technical delta of
   v4.  The service interface to the upper layers is also a straight delta.

   In other words, the damn thing really is a variant of IPv4.  So, use of
   the IP version number field makes sense.

   If this turns out to break existing implementations -- assuming that
   SIP-as-IPv6 shows up in its pure, unencapsulated form at IPv4-only
   systems -- then I agree this should be rethought.

   But if we are attempting to develop a running system, then every
   piece that is different from the intended final form leaves us open to
   the charge of doing unrealistic testing or of creating problems that do
   not apply to the final system.

   Dave