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
- (sipp) New SIPP Addressing Draft Bob Hinden
- Re: (sipp) New SIPP Addressing Draft Brian Carpenter CERN-CN
- Re: (sipp) New SIPP Addressing Draft Steve Deering
- Re: (sipp) New SIPP Addressing Draft William Allen Simpson
- Re: (sipp) New SIPP Addressing Draft Brian Carpenter CERN-CN
- Re: (sipp) New SIPP Addressing Draft Bob Hinden