Re: (sipp) New SIPP Addressing Draft

Bob Hinden <Bob.Hinden@eng.sun.com> Wed, 20 July 1994 16:29 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08677; 20 Jul 94 12:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08673; 20 Jul 94 12:29 EDT
Received: from [192.9.9.1] by CNRI.Reston.VA.US id aa11194; 20 Jul 94 12:29 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25031; Wed, 20 Jul 94 09:27:47 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA17963; Wed, 20 Jul 94 09:28:58 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01092; Wed, 20 Jul 94 09:29:48 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01086; Wed, 20 Jul 94 09:29:41 PDT
Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA29374; Wed, 20 Jul 1994 09:27:25 -0700
Date: Wed, 20 Jul 1994 09:27:25 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bob Hinden <Bob.Hinden@eng.sun.com>
Message-Id: <9407201627.AA29374@jurassic.Eng.Sun.COM>
To: sipp@sunroof.eng.sun.com
Cc: Bob.Hinden@eng.sun.com
In-Reply-To: <2881.bill.simpson@um.cc.umich.edu>
Subject: Re: (sipp) New SIPP Addressing Draft
X-Orig-Sender: owner-sipp@sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp@sunroof.eng.sun.com

Bill,

 > I have to agree, this version is a marked simplification over previous
 > versions.  There are a lot of typos, but I'll wait to point them all out
 > until we have been through some review and another draft.

Please send me the typos. 

 > I see that it will be very simple to change back to 64 bits when this
 > excursion into "silly" 128 size is over.

I think the removal of the "extended addresses" made this document much
simpler.

 > I particularly like the :: convention.  That will make things a lot easier
 > when writing about IPng.

Thanks.  It will also make writting cluster addresses much simpler.

 > I'm glad that the route reversal has been removed (it's _not_ really in
 > SIPP-16).  I always thought route reversal was a serious security risk.

The intent was to move the source route reversing to the main SIPP spec.

 > I disagree with removing the binding of addresses to interfaces.  I use
 > it in Neighbor Discovery.  I like using the same lower bits with
 > different higher bits.  Simplifies configuration.
 > 
 > I suggest, yet again, that loop-back be FF01::1.  This makes more sense
 > than yet another address.

My preference was to put it in the local use block.  This would make it a
bit easier for a boundary router to filter out all of these addresses at
once.

 > I suggest, yet again, that IPX and all other "legacy" addresses be in
 > the "00" block, rather than split between the "00" and "Ex" blocks.

I think it is arbitrary where they go.  They could all (IPv4, IPX, NSAP)
all be moved to the 00 prefix.

 > Indeed, I'd like to move the "local-use" there, too.  Makes it cleaner.
 > Keeps the main allocation blocks as big as they can be.

I need to think about that a bit more, but I don't see any reason to not
to this.

 > You go on the describe "provider", "subscriber", and "subnet" prefixes,
 > then never use them to describe routing.  I'd rather use the more
 > generic term we have in Mobile-IP: "routing-prefix".  "Cluster" should
 > mean the same thing -- a cluster is a group of routers with the same
 > routing prefix.

I agree the terminology is a bit inconsistent.  I will try to fix this in
the next version.

 > You don't define a Geographic prefix!  Then why a Provider prefix?
 > After all, most of us will refuse to use a "provider" based prefix, and
 > be using geographical instead.

We need to flesh out how to do provider (and geographical) allocation.  I
am working on an update to the SIPP unicast provider allocation.  It
would be good to do a geographical one later.

 > You describe a NSAP format, but not the more important IPX one.  Please
 > leave it in somebody else's separate draft.  Who gives a damn about
 > worthless NSAPs?  IPX is a real widely deployed protocol.

We should do an IPX one too.  I included the NSAP one to show an approach
how it could be done.  It needs to be fleshed out more.

 > I'd put the "unspecified" address first, since it is in numerical order.

Yes.

 > I was disappointed that there wasn't more routing description.  Not good
 > enough.  All you really do is describe addressing.

Yes, this needs to be done too.

Thanks for the comments.

Bob

 ------------------------------------------------------------------------------
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