Re: (sipp) SST overview paper

William Allen Simpson <bill.simpson@um.cc.umich.edu> Wed, 20 July 1994 05:03 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00841; 20 Jul 94 1:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00837; 20 Jul 94 1:03 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa29525; 20 Jul 94 1:03 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12585; Tue, 19 Jul 94 22:01:52 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA02541; Tue, 19 Jul 94 22:02:24 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00860; Tue, 19 Jul 94 22:02:45 PDT
Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00854; Tue, 19 Jul 94 22:02:37 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16327; Tue, 19 Jul 94 22:00:15 PDT
Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA12484; Tue, 19 Jul 94 22:00:08 PDT
Received: from pm002-25.dialip.mich.net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id BAA06706 for <sipp@sunroof.eng.sun.com>; Wed, 20 Jul 1994 01:00:03 -0400
Date: Wed, 20 Jul 1994 04:28:13 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson@um.cc.umich.edu>
Message-Id: <2886.bill.simpson@um.cc.umich.edu>
To: sipp@sunroof.eng.sun.com
Subject: Re: (sipp) SST overview paper
X-Orig-Sender: owner-sipp@sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp@sunroof.eng.sun.com

> From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan)
> As promised, I have written up an overview paper explaining the Simple
> SIPP Transition (SST) proposal.  I'll send this in to the internet
> drafts editor today so that it can be entered into the archives before
> the Toronto meeting.  Send comments, questions or suggestions to me or
> the list.  We can discuss SST more at the SIPP working group meeting
> in Toronto.
>
As I have already indicated a number of suggestions to Bob that were not
incorporated, I will write up something of my own in the next couple of
days.  I tried explaning what I was looking for, but sometimes it's just
faster to write the whole thing yourself.

I was especially unhappy with the 2 "flag days":

 1) when IP addresses run out, new SIPP/IPv4 nodes can't continue to
    talk with old IPv4 nodes in the same commonwealth.  This was a
    cornerstone of IPAE that I am unhappy to see disappear.  But, I can
    live with that, as it provides an incentive for upgrading, I guess.

 2) when SIPP-only hosts show up in an area, you have to TURN OFF IPv4
    routing.  This is totally unacceptable to me.

Of course, there are other problems, such as:

 - SIPP/IPv4 routing should be a combination, with interoperation, but
   instead means IPv4 routing with SIPP encapsulation.

 - translators have to be specially deployed at SIPP boundaries, and
   need lots of configuration.  Blech.

 - SIPP-only says it "does not understand IPv4", but in reality will
   continue to support A DNS records, a special checksum calculation,
   FTP PORT commands, and who knows what else IPv4 stuff.  I think
   SIPP/IPv4 should support both, and SIPP-only just don't talk IPv4,
   even through translators.

 - I don't expect to see SIPP-only for 20 years, and so much of this
   draft is irrelevant, particularly the ::1 prefix.  Several others
   have stated this, too.

 - I think the topology is wrong.  We won't see islands of SIPP-only,
   we'll see islands of IPv4-only.  That requires a thought experiment.
   I'll just write it out in my draft.

Oh well, enough wasted time explaining, time to write.

Bill.Simpson@um.cc.umich.edu
 ------------------------------------------------------------------------------
IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to majordomo@sunroof.eng.sun.com