Re: SIP now IPv6

"Vinton G. Cerf" <vcerf@CNRI.Reston.VA.US> Thu, 24 December 1992 18:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04095; 24 Dec 92 13:46 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04091; 24 Dec 92 13:46 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa15138; 24 Dec 92 13:48 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA01140; Thu, 24 Dec 92 10:46:13 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09759; Thu, 24 Dec 92 10:46:12 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA09732; Thu, 24 Dec 92 10:45:59 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22193; Thu, 24 Dec 92 10:46:02 PST
Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by Sun.COM (4.1/SMI-4.1) id AA01121; Thu, 24 Dec 92 10:45:57 PST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04032; 24 Dec 92 13:41 EST
To: Dave Katz <dkatz@cisco.com>
Cc: hwb@upeksa.sdsc.edu, dlynch@interop.com, Christian.Huitema@sophia.inria.fr, postel@isi.edu, sip@caldera.usc.edu, ip-encaps@sunroof.eng.sun.com, iana@isi.edu, iab@isi.edu
Subject: Re: SIP now IPv6
In-Reply-To: Your message of "Thu, 24 Dec 92 10:22:04 PST." <9212241822.AA08585@regal.cisco.com>
Date: Thu, 24 Dec 1992 13:40:55 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf@CNRI.Reston.VA.US>
Message-Id: <9212241341.aa04032@IETF.CNRI.Reston.VA.US>
Content-Length: 1597

Dave,

Let's look at the cases. If we introduce a new version of IP and
demux to the same software that IPv4 now demuxes to, that software
may become confused if it has not been augmented with knowledge of
the new IP version format. Of course, updated software capable of
handling IPv6 (say) as well as IPv4 can handle this case.

Assuming that a "flag day" when all IP packages change is NOT
in the cards, I think it must be the case that demuxing a new
IP in addition to IPV4 has to happen below the IP layer, as
you suggest - so as to avoid handing a new packet format to the
already existing software. Versioning only seems to work if 
it is possible to assume that ALL receiving software has been
updated or that any "new" packet will be caught and dealt
with before it reaches an "old" module (e.g. protocol translations
or something). 

It should be possible to write an IP module which will handle
both IPv4 and IPnew in which case one would configure things to
send packets of both types, even if distinctly marked at the lower
level, to the same software package handling all versions of IP.
IPAE, for instance, allows us to demux IPv4 but to activate new
software able to handle the IPAE protocol (emphasis on protocol)
as a bridge to new IP version.

Sorry for the stream of consciousness - seems to me that assigning
SIP to be version 6 doesn't solve all the problems of live testing
in a mixed environment - so I hope the SIP crew has additional
ideas along the lines you mention.

If my reasoning is broken, please say so - I won't be hurt (embarrassed,
maybe, but not hurt)!

Vint