Re: SIP now IPv6

Noel Chiappa <jnc@ginger.lcs.mit.edu> Fri, 25 December 1992 01:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05675; 24 Dec 92 20:44 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05671; 24 Dec 92 20:44 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa23883; 24 Dec 92 20:47 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24415; Thu, 24 Dec 92 17:46:49 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19986; Thu, 24 Dec 92 17:46:53 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA09872; Thu, 24 Dec 92 17:46:35 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28237; Thu, 24 Dec 92 17:46:44 PST
Received: from ginger.lcs.mit.edu by Sun.COM (4.1/SMI-4.1) id AA24398; Thu, 24 Dec 92 17:46:35 PST
Received: by ginger.lcs.mit.edu id AA24233; Thu, 24 Dec 92 20:45:27 -0500
Date: Thu, 24 Dec 1992 20:45:27 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9212250145.AA24233@ginger.lcs.mit.edu>
To: dcrocker@mordor.stanford.edu, dkatz@cisco.com
Subject: Re: SIP now IPv6
Cc: iab@isi.edu, iana@isi.edu, ip-encaps@sunroof.eng.sun.com, jnc@ginger.lcs.mit.edu, sip@caldera.usc.edu, vcerf@CNRI.Reston.VA.US
Content-Length: 2325

	It is this evident inabilty of the Internet technical community to
solve the slightest issue without lurching into charges and counter-charges
(perhaps associated with truth, perhaps not) which is driving many people to
despair. Can you all turn down your political manoevering paranoia sensitivity
levels, please?
	And now, a few technical comments:


    There are certainly other demultiplexing mechanisms available, with
    varying degrees of technical and administrative suffering accompanying
    them

I actually don't think that we want to go around, and, on a case-by-case
basis, allocate N new protocol types (one for each proposal which goes into
field test) for each kind of hardware network in the known universe which
carries IP (along with potentially updating the "IP over <foo>" documents)
Allocating a new IP version number is clearly the right thing, although
perhaps recycling 1-3 for test deployments is a good idea.

    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.

I rather think that we should use the mechanism that we designed to do this,
and if some engineers out there did shoddy work, and tried to cut a corner,
tough. To me, *this* is "conservative engineering practise" - not to excuse
bad workmanship.
I know we have to be practical, but we also have to have some sense of
direction, and if we allow our course to be diverted by the slightest previous
act of bad engineering, we're in for a rough ride. If some code doesn't check
the IP version number, and act reasonably if it's one it doesn't grok, sorry,
it loses.

    Actually I suspect that more ARP implementations will break than will IPv4
    implementations, since these are notoriously bad about checking all of the
    fields.

In addition to allocating an IP version number, we are going to have to
allocate an ARP 'protocol address family identifier', since the existing one
is allocated to IPv4 addresses, and SIP addresses are different. Sure, you
could check the lenght to see which one you've got, but that wasn't what
Plummer and I had in mind.
Again, if you don't check the fields, tough: shoddy engineering is it's own
punishment.


	Noel