Re: SIP now IPv6

Dave Crocker <dcrocker@mordor.stanford.edu> Sun, 27 December 1992 22:28 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07333; 27 Dec 92 17:28 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07329; 27 Dec 92 17:28 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa14570; 27 Dec 92 17:31 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA05110; Sun, 27 Dec 92 14:29:50 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04933; Sun, 27 Dec 92 14:29:51 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA14476; Sun, 27 Dec 92 14:29:37 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13035; Sun, 27 Dec 92 14:29:45 PST
Received: from Mordor.Stanford.EDU by Sun.COM (4.1/SMI-4.1) id AA05101; Sun, 27 Dec 92 14:29:38 PST
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA07801; Sun, 27 Dec 92 14:29:07 -0800
Message-Id: <9212272229.AA07801@Mordor.Stanford.EDU>
To: Steve Deering <deering@parc.xerox.com>
Cc: yakov@watson.ibm.com, sip@caldera.usc.edu, ip-encaps@sunroof.eng.sun.com, iana@isi.edu, iab@isi.edu, dkatz@cisco.com
Subject: Re: SIP now IPv6
Org: The Branch Office, Sunnyvale CA
Phone: +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Sun, 27 Dec 92 13:24:20 -0800. <92Dec27.132427pst.10779@skylark.parc.xerox.com>
Date: Sun, 27 Dec 1992 14:29:06 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker@mordor.stanford.edu>
X-Mts: smtp
Content-Length: 2329

On the question of urgency...

There always is a challenge to balance between worst-case 
and best-case scenarios.  If you only plan for the former, you waste much
effort, etc., since the world (usually) doesn't turn out all that bad
all that often.  If you only plan for best-case situations, however, you
can lose everything, since you WILL be caught short some of the time.

By any reasonable measure, IP address space (network numbers, router table
size, etc.) involves very, very critical resources and hitting a real
operational wall with any of them would likely bring down the Internet,
cause it to lose its potential for truly mass market use, or otherwise
do a great deal of damage.

CIDR is the most immediate effort to fix the most immediate and real
problem, namely router table size.  However, its real benefits only
accrue from careful assignment of NEW network numbers (and/or re-assignment
of old ones.)  With luck, careful coordination, etc., it will fix the 
immediate table size problem.

But we are relying rather heavily on this, with no backup plan in our
hip pocket.

In project management of critical activities, hip pocket plans are
essential.  And we don't have one.  Not one.  We have ideas, hopes, and
hand-waves.  But no plans.

Worse, there is the matter of network numbers.  A best-case scenario says
we have no problems for 10, 30, or somesuch years.  A worst-case
scenario says we run out next year.  (Really.  It does.)  CIDR does
nothing about this latter, potential problem.  A moderate scenario says
that we well might run out in 5 years.  (Exercise for the reader:  Figure
out the number of network numbers we need if the Personal Digital Assistants
all start using wireless TCP.)

5 years ain't that long.  Worse, good project management says we need to
build in some buffer.  So, 5 years really is about 4 or 3.  So now we
have about 3 years to FULLY field a larger address space replacement
for IP.  And this assumes that CIDR is handling the immediate problem
adequately.  (Sure hope it does.)

Folks, given the degree of administrative complexity in the Internet and
the difficulty of standardizing and deploying a massive new infratstructure,
I strongly suggest that we damn well SHOULD view the current situation
with considerable urgency.  3 years is a very, very short time.

Dave