From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 01:45:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16548; Thu, 30 Jun 1994 22:54:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA23863; Thu, 30 Jun 1994 22:54:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA23860; Thu, 30 Jun 1994 22:47:29 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15517; Thu, 30 Jun 1994 22:23:26 +1000 (from ihanson@pcs.dec.com) Received: from cssec4.pcs.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA29032; Thu, 30 Jun 94 05:15:46 -0700 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA07544; Thu, 30 Jun 94 14:15:39 +0200 Message-Id: <9406301215.AA07544@cssec4.pcs.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, ihanson@cssec4.pcs.dec.com Subject: Re: IPng ADs request In-Reply-To: Your message of "Thu, 30 Jun 94 00:01:01 EDT." <9406300401.AA16128@ginger.lcs.mit.edu> Date: Thu, 30 Jun 94 14:15:38 +0200 From: "Iain K. Hanson" X-Mts: smtp Noel, I intutitively feel that seperating Name (EID) from location is a good thing. But then my intutition has been wrong more times than I care to remember. So I would like to understand the relationship between TLN (Transport Level Name), EID ( End point Identifier ) and locator and exactly what each is ( irespective of form ). There are some elements of your reply that I don't think I understand. For instance, starting with the simplest case of a host with one physical interface, one locator, and one EID. The EID identifies the host from an administrative point and the locator defines where the host is within the topology. If the location of the host changes then a new locator is bound to the EID. How in all this is an application or process identified without a seperate TLN. Seperate that is, from the EID. >More than one endpoint can be reached through the same interface (i.e. the >same locator), yes. For instance, if some EID's name mobile processes, you >could have several in one machine. Using the same simple case above, this now sounds more like a TLN. But it seems a very expensive way of identifing processes ( communicating applications ), both for address space and administration. >> An EID has N Locators associated with it. > ..... yes In the case of a single homed host, if I understand correctly, this could occur to obtain different levels of service i.e. security, reliability, bandwidth, etc... This would mean a mapping or binding between one physical ( MAC ) address and the many locators. In the case of a single EID, you still have the problem of identifing the applications using the EID? This leads me to the following possible relationships between EID and Locator: 1:1 , 1:Many , many:1 , and many:many. >Well, that sort of astonishes me, since when I defined the concept of an EID, >I fully intended that it be a TLN. >This is about right. EID's inhabit a hazy plane which is sort of at the top >of the internetwork layer, and the bottom of the transport layer. Could you clarify this for me a little please, as I still can not see how one can do without a port number as the TLN. Even in the case of a single homed host. And I think that using multiple EIDs as TLNs would be prohubitavely expensive. /ikh From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 01:50:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18138; Thu, 30 Jun 1994 23:34:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA23934; Thu, 30 Jun 1994 23:34:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA23920; Thu, 30 Jun 1994 23:19:51 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17562; Thu, 30 Jun 1994 23:19:48 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 30 Jun 94 22:13:49 +0859 From: Masataka Ohta Message-Id: <9406301314.AA16686@necom830.cc.titech.ac.jp> Subject: Mobility and DNS To: big-internet@munnari.OZ.AU Date: Thu, 30 Jun 94 22:13:46 JST X-Mailer: ELM [version 2.3 PL11] > You could use a best effort approach of allowing resolvers to cache > potentially wrong values, and then look up the authoratative values if > the value is determined to be wrong, which is ugly, but should work > ok. It doesn't work. Authoritative data is not guranteed to be up-to-date. A stationary host can not distinguish whether an error is caused by the stale value on a mobile host or a temporal failure of links to an immobile host. The latter should not be the reason to make an authoritative query. What if, when the stational host is wrapped by a firewall and can't make the authoritative query? You are proposing ugly modification to networking code of all the hosts. Then, why, do you think, we shouldn't achieve the same goal with a lot more elegant modification, which should result in less complex and smaller operating system? Note that, with the concept of locator, multiple locators of a mobile host will point to multiple home registries, which is a little more elegant and a lot more fault tolerant than the current SMIP. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 01:55:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20682; Fri, 1 Jul 1994 00:34:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA24001; Fri, 1 Jul 1994 00:34:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA23998; Fri, 1 Jul 1994 00:28:49 +1000 Precedence: list From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18178; Thu, 30 Jun 1994 23:36:11 +1000 (from jcjones@MIT.EDU) Received: from BOLOGNESE.MIT.EDU by MIT.EDU with SMTP id AA27728; Thu, 30 Jun 94 09:36:07 EDT Received: by bolognese.MIT.EDU (5.57/4.7) id AA29630; Thu, 30 Jun 94 09:36:05 -0400 Message-Id: <9406301336.AA29630@bolognese.MIT.EDU> To: Big-Internet@munnari.OZ.AU Subject: Toronto Meeting Date: Thu, 30 Jun 94 09:36:05 EDT Where can I get when/where information about the upcoming meeting in Toronto? -J.C. Jones- From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 02:02:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22712; Fri, 1 Jul 1994 01:34:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA24068; Fri, 1 Jul 1994 01:34:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA24054; Fri, 1 Jul 1994 01:16:33 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22176; Fri, 1 Jul 1994 01:16:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18834; Thu, 30 Jun 94 11:16:24 -0400 Date: Thu, 30 Jun 94 11:16:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406301516.AA18834@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: Masataka Ohta >> I think EID is, like domain name, a network level name. > Yes. I'm afraid you said EID a transport layer name elsewhere. Ooops, sorry, you're right; I saw the part about "EID is like a domain name" and misread the rest. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 02:14:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24012; Fri, 1 Jul 1994 02:14:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA24160; Fri, 1 Jul 1994 02:14:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24146; Fri, 1 Jul 1994 02:04:26 +1000 Precedence: list From: little@ctt.bellcore.com Received: from mgm.ctt.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23683; Fri, 1 Jul 1994 02:04:22 +1000 (from little@ctt.bellcore.com) Received: from montana.ctt.bellcore.com by mgm.ctt.bellcore.com with SMTP id AA15880 (5.65c/IDA-1.4.4 for ); Thu, 30 Jun 1994 12:04:17 -0400 Received: from localhost.ctt.bellcore.com by montana.ctt.bellcore.com (4.1/Spike-2.2) id AA28597; Thu, 30 Jun 94 12:04:15 EDT Message-Id: <9406301604.AA28597@montana.ctt.bellcore.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of "Tue, 28 Jun 94 21:41:19 EDT." <9406290141.AA07568@ginger.lcs.mit.edu> Date: Thu, 30 Jun 94 12:04:15 -0400 >Yo! Wake up out there! If you *don't* reply, the IPng AD's are going to think >that *nobody* wants to separate end-end names (e.g. EID's) from toplogically >sensitive names (e.g. locators). If you favor such a split (e.g. into locators >and EID's,), *SAY SO NOW*. Can everyone who thinks we need to split these two >apart *please* send a message, at least to Allison and Scott, if not to Big-I? > I think it would be a big mistake not to separate these names from each other. In the eight years since I became convinced this was a good idea, I haven't come across a reason that justifies throwing away the advantages this separation would provide. So there, you have my vote. You may have thought I wasn't listening any more, but I've been keeping an eye out. Good luck to all at the next meeting. -Mike From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 02:15:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24098; Fri, 1 Jul 1994 02:15:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA24175; Fri, 1 Jul 1994 02:15:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24143; Fri, 1 Jul 1994 02:02:39 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23635; Fri, 1 Jul 1994 02:02:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19308; Thu, 30 Jun 94 12:01:30 -0400 Date: Thu, 30 Jun 94 12:01:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406301601.AA19308@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: Steve Deering The name on a postal envelope is *not* analagous to an EID. It is not required to be globally unique (just unique within the the addressed postal location) Yes, the analogy is not perfect. A closer analogy is that the addressed postal location is like an IP subnet, and the addressee name serves the role of the host number (final component) of an IP address. I don't think this is a better analogy, since (at least with IPv4, where the host number is a small, locally assigned number) my name always stays the same wherever I go (and with a bizarre name like "Noel Chiappa", you don't get collisions :-). You don't usually get to keep your small number when you change subnets.. This postal analogy can only be taken so far before it breaks down... Your plea for EIDs is like demanding that postal envelopes all carry Universal Person Numbers, in addition to the information they now contain. Personal names already have a very high likelihood of being unique. Adding another name which has a higher likelihood of being unique is thus of only a limited value. Again, the analogy can only be pushed so far. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 03:14:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26104; Fri, 1 Jul 1994 03:14:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24298; Fri, 1 Jul 1994 03:14:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24232; Fri, 1 Jul 1994 02:58:47 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25648; Fri, 1 Jul 1994 02:58:39 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-08.dialip.mich.net (pm002-08.dialip.mich.net [35.1.48.89]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA03680; Thu, 30 Jun 1994 12:58:27 -0400 Date: Thu, 30 Jun 94 15:29:34 GMT From: "William Allen Simpson" Message-Id: <1219.bill.simpson@um.cc.umich.edu> To: Paul Robinson Cc: On the Growth of the Internet , IETF List Reply-To: bsimpson@morningstar.com Subject: Re: In the matter of 64-bit addresses Yes, this was Steve Deering's geographical-addressing plan. For scaling, it requires interconnection at various geographical points: continents to start, eventually every metropolitan area. I consider it the right way to go, other pundits rejected the idea, saying that providers would refuse to interconnect. Let's keep this on the big-internet list, shall we? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 03:36:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26373; Fri, 1 Jul 1994 03:19:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24323; Fri, 1 Jul 1994 03:19:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA24263; Fri, 1 Jul 1994 03:10:31 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25979; Fri, 1 Jul 1994 03:10:27 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty13.jvnc.net. (franklin-tty13.jvnc.net) by tigger.jvnc.net with SMTP id AA26155 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Thu, 30 Jun 1994 13:10:02 -0400 Message-Id: Date: Thu, 30 Jun 94 13:09:11 EDT From: "David M. Piscitello" Subject: Re: smart buildings, cars, doorknobs, coffee-cups, etc.... Reply-To: dave@corecom.com To: "Dave Crocker" , "Mike O'Dell" Cc: big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 There's another piece to this: what is global today is unquestionably going to turn out to be local tomorrow. Actually, make that "what we once construed as global is local today", and becoming increasingly so. >Internet address has evolved to a model of global, unique, homogeneous >addressing largely because it is so much easier to deal with the >administration, and because what is local today may well turn out to need >to be global tomorrow. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 03:37:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26385; Fri, 1 Jul 1994 03:20:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24338; Fri, 1 Jul 1994 03:20:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24229; Fri, 1 Jul 1994 02:58:45 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25650; Fri, 1 Jul 1994 02:58:39 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-08.dialip.mich.net (pm002-08.dialip.mich.net [35.1.48.89]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA03691 for ; Thu, 30 Jun 1994 12:58:34 -0400 Date: Thu, 30 Jun 94 17:01:09 GMT From: "William Allen Simpson" Message-Id: <1221.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: assignment efficiency > From: yakov@watson.ibm.com > In addition to (net, subnet(s), host), we have today 2 more levels -- > (provider, site). So, the total number of levels in the routing > hierarchy used *today* is 5 -- you are correct. > This must be some new method of counting, which is not monotonic. The "net" has been split into (provider, site). That's 2 _total_ (not more) levels. Inside a site are subnets. That makes 3 levels of routing. I have yet to see CIDR aggregation of multiple IPv4 addresses for a single host. (when would we need it?) Moreover, hosts are usually found within subnets by ARP, not by routing. So, now 3 instead of the previous 2. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 03:54:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27674; Fri, 1 Jul 1994 03:54:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24434; Fri, 1 Jul 1994 03:54:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA24428; Fri, 1 Jul 1994 03:48:55 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27464; Fri, 1 Jul 1994 03:48:49 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA14094; Thu, 30 Jun 1994 10:48:40 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Jun 1994 10:48:44 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu At 9:01 AM 6/30/94, Noel Chiappa wrote: >I don't think this is a better analogy, since (at least with IPv4, where the >host number is a small, locally assigned number) my name always stays the same >wherever I go (and with a bizarre name like "Noel Chiappa", you don't get >collisions :-). You don't usually get to keep your small number when you >change subnets.. Noel, I'm afraid that you are confusing statistics with core basis/policy. In fact, the statistics of personal names means that we usually can re-use the same personal name string as we move about. But Steve's point was that collisions can and do happen. Another Steve I know joined a company with lots of other Steves. I went to visit headquarters one day and everyone started referring to some guy named 'Zeke'. It was clear they thought I knew who they meant. I finally broke down and asked who the heck they were referring to. This got me some very, very strange looks. The Steve I know is my brother and when he joined TIS he decided that unambiguous naming was going to be a problem, so he chose 'zeke' as his internal moniker. The TIS folks therefore could not understand how it was that I didn't know my brother's own name... In other words, I think that Steve's (Deering's) postal example is right on the mark. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 03:55:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27741; Fri, 1 Jul 1994 03:55:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24460; Fri, 1 Jul 1994 03:55:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA24431; Fri, 1 Jul 1994 03:54:05 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27665; Fri, 1 Jul 1994 03:54:01 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA00980; Thu, 30 Jun 94 12:53:57 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:big-internet@munnari.oz.au id AA07403; Thu, 30 Jun 94 12:53:55 -0500 Date: Thu, 30 Jun 94 12:53:55 -0500 Message-Id: <9406301753.AA07403@benedick.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Cc: Greg_Minshall@novell.com From: "Richard Carlson" From: Greg Minshall >Maybe you could define "must". To me, "must" says there is no other way. >However, there clearly is an existence proof of another way - IPv4 >addresses. Be glad to. The discussion is on the features I want for the next version of the Internet protocol suite (TCP/IPng). I used the term "must" to indicate my preference in how this suite should be developed and deployed. You are correct that the identifier and topological names can be combined into a single name (i.e. IPv4 address). However, I think that the current problems in growth are aggravated by having only a single name. I see the transition from IPv4 to IPng as a long and painfull struggle. By having a single name, we guarantee that we will revisit all the current problems when (not if) we move from IPng to IPngng (IP3g?). Yes I say when, because I don't think we can crooectly predict how the Internet will change in the next 10 years. I think seperate names are the best way to hedge our bets and design something that will allow for future growth. So I say any new IPng _must_ have seperate location and identification names. Single names mean that I get to argue this all over again when we develop IP3g. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 03:56:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27764; Fri, 1 Jul 1994 03:56:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24475; Fri, 1 Jul 1994 03:56:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA24406; Fri, 1 Jul 1994 03:35:27 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25921; Fri, 1 Jul 1994 03:07:35 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA09069; Thu, 30 Jun 94 12:09:11 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id an25269; 30 Jun 94 17:04 GMT Date: Thu, 30 Jun 94 12:03 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Noel Chiappa To: big internet To: pvm Subject: Re: IPng ADs request Message-Id: <02940630170320/0003858921NA5EM@mcimail.com> >> Actually I was trying to be vague and get someone to tell me how the >> EIDs worked. ... If not 802 numbers, then what? >Well, I personally liked the idea of having a part of the EID space be >assigned to 802 numbers, so that would be an easy source of EID's, NO NO NO !!!! 802 numbers are too limited and may get even more limited. What is the 802 number for my serial port? What is the 802 number for my PCS? 802 numbers are broken. EID is for at least the system (though some think it can be for a process, I don't) and a system can have multiple 802 numbers and they can change with time. >but there are those who think that's not workable due to duplicates. Some >people seem to like EID's which are assigned much the same way IPv4 >addresses are now; i.e. via an assignment hierarchy. Minshall asks how can we be sure that there are no duplicates in EID numbering since it is a globally flat space. Or how do we determine ownership of an EID to resolve a duplicate? There have been a number of attempts to develop an administrative hierarchy for EIDs. This is part of the answer. Let's start by saying that the IAB/IETF 'owns' the IPng numbering scheme. We can patent it or copyright to or something. Then a functionary of the IAB can determine sub-admins (e.g IANA!). This functionary doles out largish blocks of addresses (2^32) to large organizations (2^32 max based on our 64 bit EID). A large organization could sub-let address blocks (say the org is an IP provider), but we probably should stop at two levels of admin delegation (OK, maybe 3). The true owner of an EID is determined by the admin delegation in the EID. So Greg's problem has a resolution methodology. Bob From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 04:42:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23421; Fri, 1 Jul 1994 01:57:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA24101; Fri, 1 Jul 1994 01:54:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA24095; Fri, 1 Jul 1994 01:42:49 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16236; Thu, 30 Jun 1994 22:45:16 +1000 (from ihanson@pcs.dec.com) Received: from cssec4.pcs.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA29704; Thu, 30 Jun 94 05:34:50 -0700 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA07605; Thu, 30 Jun 94 14:34:45 +0200 Message-Id: <9406301234.AA07605@cssec4.pcs.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, ihanson@pcs.dec.com, ihanson@cssec4.pcs.dec.com Subject: Re: auto-configuration ( was Re: IPng ADs request ) In-Reply-To: Your message of "Thu, 30 Jun 94 00:01:01 EDT." <9406300401.AA16128@ginger.lcs.mit.edu> Date: Thu, 30 Jun 94 14:34:45 +0200 From: "Iain K. Hanson" X-Mts: smtp >Some want to do this. >> EIDs can be auto-configured without a server ( or router ) for >> plug-and-play out of the box. >Without ROM, or use of 802 numbers as a sourc for "unique" numbers, this is >kind of hard. I don't think it is that inportant how it is achieved. For instance, an arbitration scheme could be used ( similar to 802.4 - MAP ) I don't believe anybody required such a scheme to be scalable to large networks. >> Auto-configuration can be prevented by routers or servers if so required. >I think you're getting confused with the "serverless autoconfiguration of >addresses" discsussion. I don't think I'm confused. Both points were refering to serverless auto-configuration of EIDs ( and possibly locators ). But the large corporate users on this list have, if I rember correctly, said that if plug-and-play out of the box is available then it must also be preventable. My experience with medium and small companies leads me to the same conclusion. /ikh From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 04:42:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23424; Fri, 1 Jul 1994 01:57:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA24127; Fri, 1 Jul 1994 01:55:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA24098; Fri, 1 Jul 1994 01:43:15 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16653; Thu, 30 Jun 1994 22:56:54 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14530(7)>; Thu, 30 Jun 1994 05:56:34 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 30 Jun 1994 05:56:29 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Date: Thu, 30 Jun 1994 05:56:24 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun30.055629pdt.12171@skylark.parc.xerox.com> > Are you basically saying you need one name to say "who" you are and > another name to say "where" you are? > > Yes, exactly. The analogy is with what you put on a postal letter; there's > the name of an individual (which stays the same no matter where you go), > which says *who* it's to. Then, there's the street address (well, a postal > address, technically), which is used to say *where* you are. Noel, The name on a postal envelope is *not* analagous to an EID. It is not required to be globally unique (just unique within the the addressed postal location) and, contrary to what you said, does not necessarily stay the same no matter where you go (if a John Smith moves into a house where another John Smith already lives, one of them has to change the name that his correspondents use to reach him by postal mail). A closer analogy is that the addressed postal location is like an IP subnet, and the addressee name serves the role of the host number (final component) of an IP address. Another, equally valid analogy is that the addressed postal location is like an IP host, and the addressee name serves the role of a UDP port number. Your plea for EIDs is like demanding that postal envelopes all carry Universal Person Numbers, in addition to the information they now contain. You imagine that this could make certain problems in the postal delivery system (like delivering mail to travelling salespersons, or delivering mail to people with more than one residence) easier to solve, even though existing solutions that do not use Universal Person Numbers exist, and you have not yet identified any problem whose solution *requires* Universal Person Numbers to be written on all envelopes. Of course, a new bureaucracy would have to be established to allocate and administer Universal Person Numbers, unless another, existing numbering plan, say Social Security Numbers plus Country Code, had properties close enough to your imagined requirements for Universal Person Numbers (like not too many duplicates). You wish to impose this new burden on every person and every piece of mail in the world because you just *know* that putting Universal Person Numbers on every envelope will turn out to be useful someday. Steve From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 04:48:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26420; Fri, 1 Jul 1994 03:21:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24353; Fri, 1 Jul 1994 03:21:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24226; Fri, 1 Jul 1994 02:58:43 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25646; Fri, 1 Jul 1994 02:58:36 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-08.dialip.mich.net (pm002-08.dialip.mich.net [35.1.48.89]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA03684 for ; Thu, 30 Jun 1994 12:58:31 -0400 Date: Thu, 30 Jun 94 16:45:27 GMT From: "William Allen Simpson" Message-Id: <1220.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Mobility, Security and DNS Mobility has been interjected here in regard to locators and identifiers. Let me say right off, mobility requires that the node identifier and locator functions be separated. There are many ways to do this. The way that I support is putting the locator function in a separate "routing" header. There was a comment that having topological information in the IPv4 address enhances security, since you "know" where the packet came from. Nothing could be further from the truth. In fact, the current Mobile-IP draft assumes that outgoing packets are not filtered on source, and any source can appear anywhere on the net. Mobility will require security, but only between the Home Agent, and the Mobile Node. Any correspondent may have its own security relationship with the Mobile Node, which is not required for mobility or locators. That security relationship can be used by the Mobile Node to update such correspondents at the same time it updates its Home Agent. The DNS is there for mapping domain names to identifiers. It is probably beyond the capabilities of the DNS to maintain mobile locators that are updating on the order of seconds or milliseconds. Any amount of security will make this update problem slower, not faster. Therefore, it is my thought that locators will remain part of the routing tables, and route servers (closely tied to routers) will be responsible for disseminating the information. This limits the trust relationships to the Mobile Node and Home Agent (route server). Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 04:48:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26457; Fri, 1 Jul 1994 03:23:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24368; Fri, 1 Jul 1994 03:23:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24234; Fri, 1 Jul 1994 02:58:49 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25652; Fri, 1 Jul 1994 02:58:43 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-08.dialip.mich.net (pm002-08.dialip.mich.net [35.1.48.89]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA03696 for ; Thu, 30 Jun 1994 12:58:37 -0400 Date: Thu, 30 Jun 94 17:12:23 GMT From: "William Allen Simpson" Message-Id: <1222.bill.simpson@um.cc.umich.edu> To: big internet Reply-To: bsimpson@morningstar.com Subject: Re: IP in Cars Can't speak as to Chrysler, since I've never had a contract there. And all of my car information is pretty old (which hopefully means I'm not violating any confidentiality agreements here). At Ford, an address of only 6 bits was considered "big", although I have since heard that larger values (of 10 bits) were in consideration for future use. But then, they were/are still using tiny proprietary 8-bit chips. They never seem to upgrade, just tack on more obscure code, which can take years to debug. Moreover, since in some crucial engine design the consideration is not the values of the packet, but the _timing_ between packets, the packets themselves have to be _very_ short to allow rapid updates. At GM, before EDS, MAP was rejected for a test station project (Saginaw Steering Gear), specifically because the headers were "too big". The serial links were only 9,600 multi-drop async, and the updates were frequent. The MAP overhead would have been frightful. We used a simple ARCnet-like framing, with 8-bit addresses (there were no more than 60 test stations planned, although I heard it grew to 100). At Holly Carb, we used a simple async frame, very like Kermit. Because of factory floor electronic noise, even 80 byte packets got hit all the time, even using RS-422 differential links. Although the data concentrators used a flavor of Unix (Motorola's early 68000 VME-bus products), TCP/IP was just "too big", and "cost too much" ($20,000 was way out of line). MAP/TOP wasn't even available. I've found only modem EE's are more willing to bit twiddle than auto ME's. Big packet headers will gain you no friends among either group. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 04:48:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26983; Fri, 1 Jul 1994 03:34:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24398; Fri, 1 Jul 1994 03:34:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA24395; Fri, 1 Jul 1994 03:32:46 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25976; Fri, 1 Jul 1994 03:10:09 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty13.jvnc.net. (franklin-tty13.jvnc.net) by tigger.jvnc.net with SMTP id AA26058 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Thu, 30 Jun 1994 13:09:43 -0400 Message-Id: Date: Thu, 30 Jun 94 13:08:50 EDT From: "David M. Piscitello" Subject: Re: IPng ADs request Reply-To: dave@corecom.com To: "Scott Bradner" , big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 > Please address the following questions: > >1/ are the transport and internetwork level names the same thing? No, they are not. >2/ if not, are they totally different or is the transport level name > part of the internetwork level name? They are separable. I'll quote Noel, who stated it cleanly enough "For things like TCP, you want a "name" which stays the same no matter where you go in the network, so you can tell the thing you're talking to over here is the same thing you were talking to over there. However, the routing requires a "name" which depends on where you are in the network, since it uses that to get the data to you. You can't have one "name" which stays the same wherever you are, and changes depending on where you are; ergo, you need two "names"." There's a third component that I call a system identifier (RFC 1523), which may or may not be embedded in the network address; if embedded, it can be used for autoconfiguration. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 05:14:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00530; Fri, 1 Jul 1994 05:14:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA24577; Fri, 1 Jul 1994 05:14:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA24563; Fri, 1 Jul 1994 05:09:11 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00461; Fri, 1 Jul 1994 05:09:07 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id MAA29079; Thu, 30 Jun 1994 12:08:59 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA04420; Thu, 30 Jun 94 13:08:25 -0600 Date: Thu, 30 Jun 94 13:08:25 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406301908.AA04420@rhyolite.wpd.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs request > ... > Your plea for EIDs is like demanding that postal envelopes all carry > Universal Person Numbers, in addition to the information they now contain. > > Personal names already have a very high likelihood of being unique. Adding > another name which has a higher likelihood of being unique is thus of only a > limited value. Again, the analogy can only be pushed so far. "Personal names are likely unique" is a strange thing to say, but perhaps understandable coming from someone named either "Noel Chiappa" or "Vernon J. Schryver". There are probably only one of each of us in the world--since my father died, that is. Last I knew there were three (3) different interested people with a claim to "David B. Anderson @ sgi.com". That situation dates from when the total employee count was less than 2000 and the total email name count was only several hundred. The only thing notable about that is 3 people matched to middle initial--there are always plenty of 1st-and-last collisions. It is absolutely clear that personal names are far less globally or locally unique than 802.3 48-bit MAC addresses, and it seemed that you guys all agreed weeks ago that those are not nearly unique enough for something or other related to EID's, locators, addresses, names, and/or 8/16 bytes. What's my excuse for pointing this out? At the risk of offending people, I want to observe that the IETF mailing lists continue to show an awful lot of the style and substance of the ISO. There is a lot of discussion that is not well grounded in reality or is very unsophisticated considering the number of years the IPng effort has been going on (e.g. "IPng addresses=U.S.Postal addresses" and "human names are unique"). Many people seem to think that it makes sense to continue to design and architect on (email virtual) white boards and hotel ballroom overhead projectors. No, it's worse than the ISO stuff; the ISO produced draft standards. Here the arguments seem to concern the qualitative implications of ambiguous changes to a large number of unstated and often contradictory assumptions. I think the idea of separating EID's and locators is very likely to be fruitful, provided someone someday gets around to saying something concrete about it. It is years (YEARS!) past the time to stop talking about the desirability (or not) of separating names from addresses from zip codes from social security numbers. It's past time to have a concrete protocol to talk about. Bigten was only a start and seems to have been ignored (perhaps in part because it is itself only a start and in part because it involves 448 bit addresses). Still, at least bigten is not just yet another a qualitative "EID's ought [not] to be separate" usenet-style "discussion." It's about time to decide that since nothing concrete has come of the idea of separating EID's from locators in 3 or 4 years that the idea is not as good as it sounds, and to dismiss it with prejudice, to make it a topic that may not be discussed until there is at least a concrete protocol and preferablly a prototype implementation. If I'm wrong, that one of the IPng contendors has separated EID's from whatever, then the concrete implications of that should be argued, not what happens to the U.S.Postal mail of traveling salesmen. Don't shug me off as one who doesn't like abstractions--my training and first love is pure and purely useless math, where you have nothing but abstractions and analogies. This IPng and big-Internet stuff has been entirely unlike math and generally no better than the usual netnews flame fest. At this rate it can be expected to be almost as productive. Is nimrod intended to make this concrete? If so, what's happening to it? Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 05:35:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29830; Fri, 1 Jul 1994 04:54:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA24534; Fri, 1 Jul 1994 04:54:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA24531; Fri, 1 Jul 1994 04:43:17 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23298; Fri, 1 Jul 1994 01:53:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19188; Thu, 30 Jun 94 11:51:32 -0400 Date: Thu, 30 Jun 94 11:51:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406301551.AA19188@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, ihanson@pcs.dec.com Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: "Iain K. Hanson" So I would like to understand ... exactly what each is (irespective of form). Yes, the last bit is key; what's most important is not what they look like, but what they name. For instance, starting with the simplest case of a host with one physical interface, one locator, and one EID. The EID identifies the host from an administrative point I don't have a strong view as to how EID's are allocated; it might be an admiinistrative hierarchy, but that's not crucial. the locator defines where the host is within the topology. If the location of the host changes then a new locator is bound to the EID. Yes. How in all this is an application or process identified without a seperate TLN. Seperate that is, from the EID. There appears to be some lack of concreteness over exactly what a TLN names. We never said whether it names: - the entire endpoint, including all the protocols inside it (i.e. the demultiplexing point where you look at the "proto" field in the internetwork header - sort of like what a NET in ISOese names) - a single transport protocol, such as TCP (i.e. prior to port demultiplexing - sort of like what an NSAP, including a SEL, names) - a single connection of a given tranport protocol You seem to be using the latter meaning, whereas I was using more of the first. (Thus, to me, a TLN+proto identifies a particular transport layer, and a TLN+proto+port identifies a particular connection.) Perhaps this is part of the problem? I'll keep using the former meaning, since it names something which doesn't otherwise have a name, and I think it's a more useful concept anyway. I'm open to a case that says this is not the best thing, though. > More than one endpoint can be reached through the same interface ... > For instance, if some EID's name mobile processes, you could have > several in one machine. Using the same simple case above, this now sounds more like a TLN. Well, I was thinking that a single mobile process might have a number of TCP connections, some UDP stuff, and maybe some other protocols, all going at once. A single TLN would name them all. But it seems a very expensive way of identifing processes ( communicating applications ), both for address space and administration. If you have *mobile* processes which desire to have network communications, I don't know of an easier way to do it... You don't *have* to give processes an TLN, just ones which want to be separately identified to the network for some reason. >> An EID has N Locators associated with it. > yes In the case of a single homed host, if I understand correctly, this could occur to obtain different levels of service i.e. security, reliability, bandwidth, etc... No. It would mostly occur if the endpoint named by that EID were reachable through multiple interfaces, each of which had its own locator. This would mean a mapping or binding between one physical ( MAC ) address and the many locators. In general, I'm not a fan of using multiple locators (or addresses) to solve choice-in-routing issues. A single interface is at a single place in the topology, and needs only a single locator. In the case of a single EID, you still have the problem of identifing the applications using the EID? Why is this a problem? This leads me to the following possible relationships between EID and Locator: 1:1 , 1:Many , many:1 , and many:many. Sure: examples of each are i) one host, one interface; ii) multi-homed host; single-homed host with several mobile processes in it; iv) multi-homed host with several mobile processes in it. > Well, that sort of astonishes me, since when I defined the concept of an > EID, I fully intended that it be a TLN. An EID had, in my mind, certain characteristics above and beyond the general characteristics of a TLN. It was topologically insensitive, and globally unique. (I also imagined that it was fixed length, but this is less crucial than the former two attributes.) You can thus see that it differs from another example of a TLN (or at least what I think of as a TLN), the NSAP (with SEL), which *is* topologically sensitive. > EID's inhabit a hazy plane which is sort of at the top of the > internetwork layer, and the bottom of the transport layer. Could you clarify this for me a little please, as I still can not see how one can do without a port number as the TLN ... I think that using multiple EIDs as TLNs would be prohubitavely expensive. I think this has perhaps been cleared up by the explanation of what a TLN names? Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 07:14:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04412; Fri, 1 Jul 1994 07:14:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24763; Fri, 1 Jul 1994 07:14:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24723; Fri, 1 Jul 1994 07:08:52 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02170; Fri, 1 Jul 1994 05:56:48 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08263; Thu, 30 Jun 1994 21:56:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07502; Thu, 30 Jun 1994 21:56:43 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406301956.AA07502@dxcoms.cern.ch> Subject: Re: assignment efficiency To: bsimpson@morningstar.com Date: Thu, 30 Jun 1994 21:56:43 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <1221.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Jun 30, 94 05:01:09 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 164 If a subnet hangs off a subnet that hangs off a subnet that hangs off a subnet that hangs off a site backbone, how many levels of hierarchy can you count? Brian From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 07:16:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04580; Fri, 1 Jul 1994 07:16:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24778; Fri, 1 Jul 1994 07:16:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24716; Fri, 1 Jul 1994 07:06:06 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00168; Fri, 1 Jul 1994 04:58:39 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14502(1)>; Thu, 30 Jun 1994 11:58:19 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 30 Jun 1994 11:58:10 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs request In-Reply-To: jnc's message of Thu, 30 Jun 94 09:01:30 -0800. <9406301601.AA19308@ginger.lcs.mit.edu> Date: Thu, 30 Jun 1994 11:57:54 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun30.115810pdt.12171@skylark.parc.xerox.com> > This postal analogy can only be taken so far before it breaks down... Actually, I think it applies almost exactly, just not the way you did the mapping. Yes, it broke down for your purposes. The postal system works just fine if the people in a house decide to have themselves addressed as "Resident 1", "Resident 2", etc., at the house's postal address, which is just like the IP host number analogy that you objected to (where hosts are given a small integer label within a subnet). > Personal names already have a very high likelihood of being unique. How can you say that?? How many John Smiths are there? Heck, there's even a Steve Deering (not me) who sells used cars on late night TV, here in the San Francisco Bay Area -- I've received a couple of phone calls for him (but no letters, yet). Steve From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 07:17:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04606; Fri, 1 Jul 1994 07:17:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24793; Fri, 1 Jul 1994 07:17:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24757; Fri, 1 Jul 1994 07:11:02 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03196; Fri, 1 Jul 1994 06:30:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22921; Thu, 30 Jun 94 16:30:45 -0400 Date: Thu, 30 Jun 94 16:30:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406302030.AA22921@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu > This postal analogy can only be taken so far before it breaks down... Yes, it broke down for your purposes. I was just using it as a rough analogy to try and get a basic understanding across to someone. I think it's reasonable to say that most people feel there is a difference between your name and your postal address. To continue my very rough analogy, the USPS (routers) delivers the mail (packets) to the postal delivery point (interface) identified by a particular postal address (locator), and then the residents sort it out based on the personal name (EID), if there is more than one resident (endpoint) at that delivery point (interface). > Personal names already have a very high likelihood of being unique. How can you say that?? To be more precise, what I meant to convey is that personal names already have a very high likelihood of being unique within a given postal address. The rate of collision is low enough that it is dealt with by local renaming, not by a separate naming system with a higher probability of uniqueness. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 07:18:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04679; Fri, 1 Jul 1994 07:18:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24808; Fri, 1 Jul 1994 07:18:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24720; Fri, 1 Jul 1994 07:08:49 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01680; Fri, 1 Jul 1994 05:44:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22322; Thu, 30 Jun 94 15:44:24 -0400 Date: Thu, 30 Jun 94 15:44:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406301944.AA22322@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: assignment efficiency Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" The "net" has been split into (provider, site). That's 2 _total_ (not more) levels. Inside a site are subnets. That makes 3 levels of routing. ... Moreover, hosts are usually found within subnets by ARP, not by routing. So, now 3 instead of the previous 2. There's an off-by-one fence-post type deal here; are you counting the number of boundaries between fields in an address, or the number of fields? The number of boundaries gives you the number of times something is "aggregated", but you have to add one to get the number of fields. Since this was all in the context of "how many layers do you need *in an address*", the latter definition seems more useful here. Working with that definition, and your list of layers, we have 4: provider, site, subnet, host. I'll leave it up to people running networks to give examples of more seen out there in the real network. Yakov gave 5: he inserted "net" in between "site" and "subnet", since apparrently large sites have more than one network number. I suppose you could argue that this is an artifact of pre-CIDR IPv4, and in a pure CIDR system they'd only have two layers at that site; wire and host. Anyway, it's an off-by-one; is it really that big a deal? Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 07:20:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04877; Fri, 1 Jul 1994 07:20:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24823; Fri, 1 Jul 1994 07:19:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24713; Fri, 1 Jul 1994 07:05:33 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03407; Fri, 1 Jul 1994 06:39:10 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA07880; Thu, 30 Jun 94 13:31:29 -0700 Received: by xirtlu.zk3.dec.com; id AA20308; Thu, 30 Jun 1994 15:38:29 -0400 Message-Id: <9406301938.AA20308@xirtlu.zk3.dec.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of "Thu, 30 Jun 94 06:36:18 +1000." <25369.772922178@munnari.OZ.AU> Date: Thu, 30 Jun 94 15:38:23 -0400 X-Mts: smtp Kre, >I should also say here that the proposed "transport connection >identifier" label is absolutely wrong - the EID (will) form >part of transport connection ID's, along with the port number, >but by itself doesn't identify transport anythings. The EID, >as a globally unique number, can also be used to make unique >transaction numbers by appending a locally unique transaction >id's (however big they need to be for the protocol in question) >which avoids having to work out yet another way to get globally >unique numbers (one good way is enough). OK seeing how I stated this I will accept that TCI could imply usinng the ports too. It could cause confusion. You seem to have the most practical handle on this IMHO. Could you do us a favor and in bullets state what you think we need to do to move this discussion to a point where its focused and related to the IPng ideas on the table right now. Do we need an EID BOF at Toronto and then an EID Working Group. Could you lead this BOF? I will help you with admin stuff. This is going no where fast and has become more like the song What do you eant from Life. I will add I really don't think 802 addresses should be part of the scenario to define an EID. If not I understand I would do it if I could, but thougt I would ask. I think it would be a very popular and crowded BOF. p.s. Richard Carlson could you help too. thanks /jim From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 07:21:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04979; Fri, 1 Jul 1994 07:21:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24838; Fri, 1 Jul 1994 07:21:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24760; Fri, 1 Jul 1994 07:12:26 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03589; Fri, 1 Jul 1994 06:46:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23039; Thu, 30 Jun 94 16:46:18 -0400 Date: Thu, 30 Jun 94 16:46:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406302046.AA23039@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, vjs@rhyolite.wpd.sgi.com Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu I think the idea of separating EID's and locators is very likely to be fruitful, provided someone someday gets around to saying something concrete about it. It is years (YEARS!) past the time to stop talking about the desirability (or not) of separating names from addresses ... It's past time to have a concrete protocol to talk about. I agree completely that the separation is likely to be good, but some people don't, which is why they continue to turn out designs which *don't* do the separation, and won't listen to requests to put them in, have maintained this position all the way down the line, and have used their positions to prevent them being added, no matter how many people asked otherwise. This leaves us with few choices: try and get separate names added to that design; do another design which looks much like the initial design, except it has the separate names, and put that into contention; give up until the next time, etc, etc. Still, at least bigten is not just yet another a qualitative "EID's ought [not] to be separate" usenet-style "discussion." ... It's about time to decide that since nothing concrete has come of the idea of separating EID's from locators in 3 or 4 years ... make it a topic that may not be discussed until there is at least a concrete protocol and preferablly a prototype implementation. At least one IPng proposal (PIP) was a fully worked out design, with EID's. PIP is no longer on the table, for complicated reasons having little to do with the fact that it had EID's. If I'm wrong, that one of the IPng contendors has separated EID's from whatever, then the concrete implications of that should be argued, not what happens to the U.S.Postal mail of traveling salesmen. I couldn't agree more. I used a rough analogy to try and get a point across, and it was picked up and turned into a theological debate. At this rate it can be expected to be almost as productive. That's certainly true. Is nimrod intended to make this concrete? Nimrod still intends to use variable length locators (i.e. topological names which *do no necessarily* occur in all packets), together with EID's. If so, what's happening to it? A new set of document, about .25Mbyte worth, were just released by the busy elves at BBN, and announced to the WG mailing list. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 07:23:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05038; Fri, 1 Jul 1994 07:23:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24853; Fri, 1 Jul 1994 07:23:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24754; Fri, 1 Jul 1994 07:10:19 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01355; Fri, 1 Jul 1994 05:38:39 +1000 (from news@sgi.com) Received: by sgi.sgi.com (940627.SGI.8.6.9/910110.SGI) for Big-Internet@munnari.OZ.AU id MAA01303; Thu, 30 Jun 1994 12:24:32 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: IPng ADs request Message-Id: Precedence: list Date: Thu, 30 Jun 1994 19:23:55 GMT > ... > Your plea for EIDs is like demanding that postal envelopes all carry > Universal Person Numbers, in addition to the information they now contain. > > Personal names already have a very high likelihood of being unique. Adding > another name which has a higher likelihood of being unique is thus of only a > limited value. Again, the analogy can only be pushed so far. "Personal names are likely unique" is a strange thing to say, but perhaps understandable coming from someone named either "Noel Chiappa" or "Vernon J. Schryver". There are probably only one of each of us in the world--since my father died, that is. Last I knew there were three (3) different interested people with a claim to "David B. Anderson @ sgi.com". That situation dates from when the total employee count was less than 2000 and the total email name count was only several hundred. The only thing notable about that is 3 people matched to middle initial--there are always plenty of 1st-and-last collisions. It is absolutely clear that personal names are far less globally or locally unique than 802.3 48-bit MAC addresses, and it seemed that you guys all agreed weeks ago that those are not nearly unique enough for something or other related to EID's, locators, addresses, names, and/or 8/16 bytes. What's my excuse for pointing this out? At the risk of offending people, I want to observe that the IETF mailing lists continue to show an awful lot of the style and substance of the ISO. There is a lot of discussion that is not well grounded in reality or is very unsophisticated considering the number of years the IPng effort has been going on (e.g. "IPng addresses=U.S.Postal addresses" and "human names are unique"). Many people seem to think that it makes sense to continue to design and architect on (email virtual) white boards and hotel ballroom overhead projectors. No, it's worse than the ISO stuff; the ISO produced draft standards. Here the arguments seem to concern the qualitative implications of ambiguous changes to a large number of unstated and often contradictory assumptions. I think the idea of separating EID's and locators is very likely to be fruitful, provided someone someday gets around to saying something concrete about it. It is years (YEARS!) past the time to stop talking about the desirability (or not) of separating names from addresses from zip codes from social security numbers. It's past time to have a concrete protocol to talk about. Bigten was only a start and seems to have been ignored (perhaps in part because it is itself only a start and in part because it involves 448 bit addresses). Still, at least bigten is not just yet another a qualitative "EID's ought [not] to be separate" usenet-style "discussion." It's about time to decide that since nothing concrete has come of the idea of separating EID's from locators in 3 or 4 years that the idea is not as good as it sounds, and to dismiss it with prejudice, to make it a topic that may not be discussed until there is at least a concrete protocol and preferablly a prototype implementation. If I'm wrong, that one of the IPng contendors has separated EID's from whatever, then the concrete implications of that should be argued, not what happens to the U.S.Postal mail of traveling salesmen. Don't shug me off as one who doesn't like abstractions--my training and first love is pure and purely useless math, where you have nothing but abstractions and analogies. This IPng and big-Internet stuff has been entirely unlike math and generally no better than the usual netnews flame fest. At this rate it can be expected to be almost as productive. Is nimrod intended to make this concrete? If so, what's happening to it? Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 08:44:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06357; Fri, 1 Jul 1994 07:58:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24941; Fri, 1 Jul 1994 07:58:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24921; Fri, 1 Jul 1994 07:44:55 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05844; Fri, 1 Jul 1994 07:44:51 +1000 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of "Thu, 30 Jun 1994 15:38:23 -0400." <9406301938.AA20308@xirtlu.zk3.dec.com> Date: Fri, 01 Jul 1994 07:44:48 +1000 Message-Id: <25633.773012688@munnari.OZ.AU> From: Robert Elz Date: Thu, 30 Jun 94 15:38:23 -0400 From: bound@zk3.dec.com Message-ID: <9406301938.AA20308@xirtlu.zk3.dec.com> You seem to have the most practical handle on this IMHO. Hmm... Could you do us a favor and in bullets state what you think we need to do to move this discussion to a point where its focused and related to the IPng ideas on the table right now. This I'm not sure about, I've never had any luck in getting discussions focussed before, especially not where the basic argument seems to be "we need them" "no we don't" ... But if perhaps we temporarily set aside the "no we don't" stuff, and concentrate only on the nature of EIDs then it may be possible. Do we need an EID BOF at Toronto I was wondering whether that may be a reasonable idea myself. Big problem is which area director is the right one to approve it, and make it happen. EIDs span such a potentially broad area of internet activities. For now I'm willing to simply pick one out of the hat ... Internet area seems right. Claudio, you're on this list,, can you arrange for this to happen? Or if you think some other area is better, then pass this along to them? and then an EID Working Group. If it seems required. Could you lead this BOF? OK, if no-one else wants to volunteer (if they do, fine, the thing will probably end up schedelled against something else I'd prefer to be at, or even have to be at). kre From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 08:45:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06381; Fri, 1 Jul 1994 08:00:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24956; Fri, 1 Jul 1994 07:59:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24918; Fri, 1 Jul 1994 07:44:07 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05394; Fri, 1 Jul 1994 07:32:05 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA15418; Thu, 30 Jun 1994 14:31:57 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Jun 1994 14:32:01 -0700 To: big-internet@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Transport, Mobility, Robustness (was: Re: IPng ADs request) If we are careful, the IPng ADs' query could turn out to have been very, very useful. For most of the last n months/years, discussion of EIDs-vs-Addresses has been in terms of both serving network-level functions. In those terms, I've thought it a mistake to pursue EIDs. I still do. But the AD's query was about transport-level identifiers, therefore separating them meaningfully from the network-level string that we all know and love. Various notes over the last two days, such as from O'Dell, Minshall and Piscitello, are particularly helpful to that end. We need to remember that IP was designed to do a basic job and do it cleanly. Whatever warts and limitations exist with it, we need to remember that it does its basic job astonishingly well. My own opinion is that something like mobility is damn difficult and that supporting it is likely to be too heavy a burden for the network-level protocol. (My current mantra is to quote the great systems engineer, Richard Nixon: "We could do it, but it would be wrong.") Hence, it's worth trying to think in terms of a less "unitary" solution. For highly localized mobility, I strongly believe the link layer should do the job. Mike O' asserts that this is difficult and there's no reason to dispute that. Still, it's the right place for local micro-management. For long-distance mobility, I continue to believe that we need to enhance the DNS. The recent discussions have been about caching and TTLs. Clearly we also need to add dynamic registration/update. It is heartening to see this line of discussion since it will be quite productive, I believe. (Particularly since we already know we need to add dynamic registration to the DNS.) Unfortunately, O'Dell and some others have cited the one major failing of this model and that is the need to maintain a single connection during the transition from one "address" to another. In fact, this seems to be the critical requirement that forces folks to think of network-level constant id's. Talking in terms of Transport Identifers at least keeps us talking about maintaining state in a place we already have to. However, a related requirement has been cited to me which might help further: Maintaining application connectivity across outages. The current wisdom is that the way to recover from a network outage is to keep the TCP connection going and eventually the network will heal. Unfortunately, this model is useless for mission-critical work. Potentially long delays are just as bad as explicit failures. I.e., such applications need to be able to exploit alternate paths quickly so that they can continue on, without waiting for the outage to heal. But, you no doubt are thinking, IP is wonderful at routing around problems. Well, I respond, first its recovery time can be protracted and second, there are critical single points of failure that often can't be routed around at all, such as the host interface. Going back to a hallway question that Jack Haverty spontaneously asked me about 5 or so years ago at BBN, I believe that the way to recover from these sorts of outages is to have at least one other path ALREADY in use. I.e., start with a load-sharing model with two or more paths. Then when one fails, you simply lose capacity, not perceived connectivity. How does this relate to Transport Identifiers? First, please note that we already have persistent transport ids: : used for source and dest. This is used at the start of the connection effort, when it is then turned into : for src & dest. What we do NOT have is a way for TCP to use multiple mappings of the domain name into multiple IP addresses or to merge multiple data streams into one. Perhaps enhancing TCP would be useful. Personally, I doubt it, unless it's done in a peculiar fashion, which I don't see doing easily. My own suspicion is that we need a simple, clean Session mechanism which is able to combine multiple transport 'associations' into a single logical stream for the application, including the ability to "recover" from outages by any given association. An "outage" which really is movement from one cell to another then becomes a case of having one connection open and overlapping the addition of a second one as the first fades away. It may well be that we can graft this mechanism onto TCP and UDP in a way which does not hurt their fastpath processing. Maybe not. One point to worry about is that TCP processing usually is not fully end-to-end with respect to the application. Really. Namely, it's usually in the kernel and the app isn't, so that there is some exposure for lossage when TCP acknowledges receipt but the app hasn't gotten the data yet. Hence, a session-level ack, like with RPC, really does have a major benefit over a transport-level, when the RPC code is part of the app. If we are serious about wanting major robustness across communications transitions (outages, movements, etc.) then we probably want a simple mechanism that it part of the app. Cheers. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 08:58:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08711; Fri, 1 Jul 1994 08:58:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA25032; Fri, 1 Jul 1994 08:58:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA25016; Fri, 1 Jul 1994 08:42:57 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07744; Fri, 1 Jul 1994 08:42:45 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 1 Jul 94 07:36:40 +0900 From: Masataka Ohta Message-Id: <9406302236.AA18407@necom830.cc.titech.ac.jp> Subject: Re: Transport, Mobility, Robustness (was: Re: IPng ADs request) To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Fri, 1 Jul 94 7:36:39 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Jun 30, 94 2:32 pm X-Mailer: ELM [version 2.3 PL11] > My own opinion is that something like mobility is damn difficult and that > supporting it is likely to be too heavy a burden for the network-level > protocol. What's wrong with SMIP with triangle elimination through secure DNS? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jul 1 09:00:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08761; Fri, 1 Jul 1994 09:00:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA25047; Fri, 1 Jul 1994 09:00:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA25013; Fri, 1 Jul 1994 08:41:42 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07695; Fri, 1 Jul 1994 08:41:36 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU Subject: Omnibus reply - EIDs Date: Fri, 01 Jul 1994 08:41:34 +1000 Message-Id: <25642.773016094@munnari.OZ.AU> From: Robert Elz To save everyone from having to read a whole bunch of messages from me... Subject: Re: IPng ADs request Message-Id: <199406300217.AA12839@zephyr.isi.edu> Date: Wed, 29 Jun 94 19:14:08 PDT From: Paul Mockapetris The next question in above scenario is are there two TLNs for every process in a multi network adapter machine? First, assume that a TLN is an EID, protocol, and port. EIDs are technically unrelated to hardware at all. I could have several EIDs on one host, but that would have nothing to do with how many network adaptors (interfaces) real or virtual the host happened to have. However any particular process on the host would be associated with a particular EID, and hence would have a single TLN (for each connection). Apart from being the simple way to work things, it also allows stuff like the DNS to function more rationally - the requirement that replies come from whence the queries were sent can be satisfied without caring about the interface addressing - a DNS reply would come from the EID to which the query was sent, and not care about which interface address the server chose to use as the source addr in the packets. Also, I could have one EID split over multiple hosts. This can allow load sharing with the recipient end of the connections deciding which particular interface (and thus host, and cable into the host) is burdened by this particular connection, and even allow that to shift during the connection, unlike current load sharing schemes which attempt mostly to fiddle the DNS to attempt to get the initiator of the connection to pick a particular host based on what address it is told to use. And yes, this is something that will take more work and research, however it looks possible with EIDs, and something between difficult, kludgy, and impossible without. From: Masataka Ohta Message-Id: <9406300424.AA14687@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request Date: Thu, 30 Jun 94 13:24:11 JST I think I agree with everything in this message, but to this .. Both hostname and EID share the same difficulty to monitor and manage though EID is a little more easier and a lot more efficient to handle. I just wanted to add that yes, DNS names and EIDs do have rather similar properties, with the advantages you mention for EIDs for their area of application, though there need not be any 1:1 mapping between EIDs and DNS names. EIDs have one very important advantage over DNS names though - they are not subject to political changes for no intelligent reason that DNS names are (because the latter are human visible). Eg: an Australian university decided to change its name from "The University of Central Queensland" to "Central Queensland University" a month or so ago ... naturally its DNS name was forced to change from ucq.edu.au to cqu.edu.au (and no, of course there's no rational explanation for this, but this is all politics, and rationality isn't a pre-requisite). If EIDs were being used, they wouldn't have had to change (nor of course did IPv4 addresses, nor would locators). Message-Id: <9406301311.17084@munnari.oz.au> Subject: Re: IPng ADs request Date: Thu, 30 Jun 94 14:10:33 +0100 From: Jon Crowcroft tut tut Jon - sending out messages without a Message-ID header forcing munnari to add one for you... but the argument about structure inside an EID seems to me to be irellevant to the IPng This is certainly true, however the opponents of EIDs object to them on the basis (among others) that nothing is known about how they're defined, allocated, ... Hence work to define them is probably needed soon, just to avoid that objection, even though from an IPng perspective, 64 meaningless but unique bits is all that they need to know. Subject: Re: IPng ADs request Date: Thu, 30 Jun 1994 11:57:54 PDT From: Steve Deering Message-Id: <94Jun30.115810pdt.12171@skylark.parc.xerox.com> While I don't think that Noel's postal analogy was a very useful one (no, no need to justify it again Noel) ... The postal system works just fine if the people in a house decide to have themselves addressed as "Resident 1", "Resident 2", etc., at the house's postal address, which is just like the IP host number analogy that you objected to (where hosts are given a small integer label within a subnet). but this is only going half way - we know that the delivery system in IPng can work without EIDs, in fact, that's exactly what we want it to do. The EID is for identification, not for delivery. To (probably stupidly, but never mind) take the postal analogy further, the EID isn't the name at the start of the envelope, its the name on the file in which I put the letter when it arrives - it identifies the other end of the conversation (I would be filing by source EID not dest but that doesn't matter). When I, as a human, have a conversation (paper mail, e-mail, or voice) with "Steve Deering" about EIDs, my human brain can make the association very quickly with the "Steve Deering" that works at Xerox PARC, and wouldn't even think of the car salesman, even if I knew of him. Someday perhaps computers will be able to make that kind of association as accurately and quickly as humans do - when that happens perhaps we will no longer need unique numbers (labels, whether they be numbers of not) for computer communications. Similarly, if we humans couldn't do pattern matching that well, we'd probably insist that each of us have a unique name to make recognition more feasible. For the forseeable future anyway, computers need unique labels, the EID is just that, a short, non-political, variant of the roughly the equivalent of a DNS name that can be used everywhere we need a concept of identity. kre From owner-Big-Internet@munnari.OZ.AU Sat Jul 2 00:00:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15046; Sat, 2 Jul 1994 00:00:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA25778; Fri, 1 Jul 1994 23:59:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA25775; Fri, 1 Jul 1994 23:58:44 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15032; Fri, 1 Jul 1994 23:58:37 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA04463; Fri, 1 Jul 94 06:54:27 -0700 Received: by xirtlu.zk3.dec.com; id AA06097; Fri, 1 Jul 1994 09:54:17 -0400 Message-Id: <9407011354.AA06097@xirtlu.zk3.dec.com> To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Cc: big-internet@munnari.OZ.AU Subject: Re: Transport, Mobility, Robustness (was: Re: IPng ADs request) In-Reply-To: Your message of "Thu, 30 Jun 94 14:32:01 PDT." Date: Fri, 01 Jul 94 09:54:11 -0400 X-Mts: smtp >If we are careful, the IPng ADs' query could turn out to have been very, >very useful. I agree. >But the AD's query was about transport-level identifiers, therefore >separating them meaningfully from the network-level string that we all know >and love. Various notes over the last two days, such as from O'Dell, >Minshall and Piscitello, are particularly helpful to that end. Many of us had already made this distinction per Chiappa's excellent analysis of fnortes and gronks sometime back. But what ever gets us singing out of the same barrel is progress. I would add to the names Noel, Deering, Kre, and Richard Carlson who I am listening to in addition to your list. >We need to remember that IP was designed to do a basic job and do it >cleanly. Whatever warts and limitations exist with it, we need to remember >that it does its basic job astonishingly well. Absolutely. But that does not mean we cannot make it better. >For highly localized mobility, I strongly believe the link layer should do >the job. Mike O' asserts that this is difficult and there's no reason to >dispute that. Still, it's the right place for local micro-management. For >long-distance mobility, I continue to believe that we need to enhance the >DNS. The recent discussions have been about caching and TTLs. Clearly we >also need to add dynamic registration/update. It is heartening to see this >line of discussion since it will be quite productive, I believe. >(Particularly since we already know we need to add dynamic registration to >the DNS.) Well come to the DNS IXFR meeting and hear what a few of us have come up with as first draft on how to do dynamic registration. But I don't think we want to overload the DNS model everytime we have handle movement of state in the network paradigm. >Unfortunately, O'Dell and some others have cited the one major failing of >this model and that is the need to maintain a single connection during the >transition from one "address" to another. In fact, this seems to be the >critical requirement that forces folks to think of network-level constant >id's. Here is where the dis-agreement may be happening technically. EIDs by definition state that they are not related at all to the network-level. Thats what locators are for. See Kre's mail right after yours to Big-I. >Talking in terms of Transport Identifers at least keeps us talking about >maintaining state in a place we already have to. However, a related >requirement has been cited to me which might help further: Maintaining >application connectivity across outages. As I started the TI or TCI thought I now agree with Kre that this semantic is wrong because there are other parts to a Transport Connection and EIDs are just one part. But I do believe that if in IPng we define that which is an identifying address and that which is a routing sequence then the basic model to switch to EIDs and Locators is possibile technically at least in host network kernels tomorrow. Not sure about the routing code. >First, please note that we already have persistent transport ids: > > : used for source and dest. > >This is used at the start of the connection effort, when it is then turned into > > : for src & dest. But the IP address contains routing state which is the issue for most of us who believe in EIDs. >What we do NOT have is a way for TCP to use multiple mappings of the domain >name into multiple IP addresses or to merge multiple data streams into one. I understand the mappings need and that is what an EID needs to be defined to do. Can you say more about the multiple data streams as I am thinking of at least 3 scenarios right now: Cluster Aliases, TCP Recovery, and Distributed Filesystem. >My own suspicion is that we need a simple, clean Session mechanism which is >able to combine multiple transport 'associations' into a single logical >stream for the application, including the ability to "recover" from outages >by any given association. An "outage" which really is movement from one >cell to another then becomes a case of having one connection open and >overlapping the addition of a second one as the first fades away. It may >well be that we can graft this mechanism onto TCP and UDP in a way which >does not hurt their fastpath processing. Maybe not. I think this may add a new layer above transport but before the application layer. Putting it in the application layer would be a performance hit unless other parts of the OS were enhanced (like doing moves instead of copies when crossing into kernel space). I think this is separate from EIDs and another issue to be solved though? >Namely, it's usually in the kernel and the app isn't, so that there is some >exposure for lossage when TCP acknowledges receipt but the app hasn't >gotten the data yet. Hence, a session-level ack, like with RPC, really >does have a major benefit over a transport-level, when the RPC code is part >of the app. If we are serious about wanting major robustness across >communications transitions (outages, movements, etc.) then we probably want >a simple mechanism that it part of the app. But as I stated we need some changes in present OS technology and VM to make this really fast, until thats done then us networking folks have to live in the realm of the tools we have within the OS today. IMHO I think Mach already solved this problem but we are still figuring out how to apply it to gain an order of magnitude in performance gains. /jim From owner-Big-Internet@munnari.OZ.AU Sat Jul 2 01:39:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19692; Sat, 2 Jul 1994 01:39:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA25873; Sat, 2 Jul 1994 01:39:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA25859; Sat, 2 Jul 1994 01:24:36 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19087; Sat, 2 Jul 1994 01:24:30 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA06768; Fri, 1 Jul 94 10:24:25 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:kre@munnari.oz.au id AA08146; Fri, 1 Jul 94 10:24:20 -0500 Date: Fri, 1 Jul 94 10:24:20 -0500 Message-Id: <9407011524.AA08146@benedick.ctd.anl.gov> To: bound@zk3.dec.com, kre@munnari.OZ.AU Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU From: "Richard Carlson" >You seem to have the most practical handle on this IMHO. Could you do >us a favor and in bullets state what you think we need to do to move >this discussion to a point where its focused and related to the IPng >ideas on the table right now. > >Do we need an EID BOF at Toronto and then an EID Working Group. Could >you lead this BOF? I will help you with admin stuff. > >This is going no where fast and has become more like the song What do >you eant from Life. > >I will add I really don't think 802 addresses should be part of the >scenario to define an EID. > >If not I understand I would do it if I could, but thougt I would ask. >I think it would be a very popular and crowded BOF. > >p.s. Richard Carlson could you help too. Jim; I would be happy to help. I have written a paper describing my view of how things should work. I just submitted it to the RFC editor yesterday (shameless plug) .-} It may not be what we want, but it's a starting point. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Sat Jul 2 02:14:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20390; Sat, 2 Jul 1994 01:59:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA25914; Sat, 2 Jul 1994 01:59:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA25900; Sat, 2 Jul 1994 01:44:19 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19938; Sat, 2 Jul 1994 01:44:14 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA19146; Fri, 1 Jul 1994 08:44:02 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Jul 1994 08:44:05 -0700 To: bound@zk3.dec.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Transport, Mobility, Robustness (was: Re: IPng ADs request) Cc: big-internet@munnari.OZ.AU At 6:54 AM 7/1/94, bound@zk3.dec.com wrote: >>We need to remember that IP was designed to do a basic job and do it ... >Absolutely. But that does not mean we cannot make it better. Well, I'm probably not likely to say you're wrong... On the other hand, I need to re-assert my basic concern that we not burden this wonderful "module" with too much additional functionality. >But I don't >think we want to overload the DNS model everytime we have handle >movement of state in the network paradigm. Jim, I too am quite concerned that we be careful about messing with the DNS. Nonetheless, this feels like a reasonable line of attack to me, given that I see the other choices as being overburdening IP or creating yet-another directory service. Mumble. >> In fact, this seems to be the >>critical requirement that forces folks to think of network-level constant >>id's. > >Here is where the dis-agreement may be happening technically. EIDs by >definition state that they are not related at all to the network-level. I may be wrong, but I think we are in violent agreement. Just to be sure: My view is that IP should have a string that really the same as we currently use. I'll call that an "interface address" because it does pertain to an interface rather than node and because it gives location information without describing a path. This other thing that we need refers to the node, not any of its interfaces, and stays constant. I'm using to calling this a "host name". >>Talking in terms of Transport Identifers at least keeps us talking about ... >As I started the TI or TCI thought I now agree with Kre that this >semantic is wrong because there are other parts to a Transport >Connection and EIDs are just one part. Agreed. I did not intend that we use that term specifically. Rather, I was noting that starting with the transport and such a term moved us to think about this "ID" thing in a different way (and separately) from puting it in the network level. >But I do believe that if in IPng we define that which is an identifying >address and that which is a routing sequence then the basic model to >switch to EIDs and Locators is possibile technically at least in host >network kernels tomorrow. Not sure about the routing code. Jim, you lost me on the above paragraph. I don't really understand what any of it means, other than it sounds like ripping out the current style of IP adressing and routing and puting in something entirely different. I'm not sanguine about anything that revolutionary, since the basic stuff works so well and is so well understood. >But the IP address contains routing state which is the issue for most of >us who believe in EIDs. Agreed. My point is that : does NOT have routing state. >>What we do NOT have is a way for TCP to use multiple mappings of the domain >>name into multiple IP addresses or to merge multiple data streams into one. > >I understand the mappings need and that is what an EID needs to be >defined to do. My point is that I think we need to start by asking whether the current hostname string will suffice. I think it can. The argument for a new string is that we need something shorter. Well, we only need something shorter if we believe we need to put it into every packet. I think we don't. I think that it might need to go at the start of a session, or at the start of each connection, to allow the end-systems know how to synchronize the multiple streams. >thinking of at least 3 scenarios right now: Cluster Aliases, TCP Recovery, >and Distributed Filesystem O'Dell's (et al) example of moving from cell to cell. This is particularly interesting because the additional connections come and go, rather than being possible to set up all at once. Makes things a bit hairier... This is the critical "maintaining the connection while being mobile" requirement. >>My own suspicion is that we need a simple, clean Session mechanism which is ... >I think this may add a new layer above transport but before the Mike O privately used the term 'facility' and explicitly argued against the term 'layer'. I'm inclined to agree. This could turn into a nitpicky issue, but my own concern is that understand just how light-weight this needs to be and that we understand that it MUST be truly end-to-end. Calling it a "layer" may cause some people to think more grandiosely than is appropriate and, worse(?), may cause them to implement it outside of the application. > Putting it in the application layer would be a >performance hit unless other parts of the OS were enhanced (like doing Huh? That's not required, I believe. Please explain. >moves instead of copies when crossing into kernel space). Bad joke. Someone observed that no computer ever moves data. It ONLY ever copies it. >I think this is separate from EIDs and another issue to be solved >though? Not necessarily. Let's hear what the real and concrete requirements are that would dictate it being separate. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sat Jul 2 03:19:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22888; Sat, 2 Jul 1994 03:19:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25991; Sat, 2 Jul 1994 03:19:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25977; Sat, 2 Jul 1994 03:00:05 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22258; Sat, 2 Jul 1994 03:00:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28391; Fri, 1 Jul 94 12:59:58 -0400 Date: Fri, 1 Jul 94 12:59:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407011659.AA28391@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: Transport, Mobility, Robustness (was: Re: IPng ADs request) Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) My view is that IP should have a string ... I'll call that an "interface address" because it does pertain to an interface rather than node and because it gives location information without describing a path. This other thing that we need refers to the node, not any of its interfaces, and stays constant. Yes, exactly. (Some might disagree with you that it doesn't describe a path, but not me! :-) I'm using to calling this a "host name". ... My point is that I think we need to start by asking whether the current hostname string will suffice. Wow, there's an interesting thought; have the *DNS name* be part of the transport pseudo-header! Hmmm... The argument for a new string is that we need something shorter. Well, we only need something shorter if we believe we need to put it into every packet. I think we don't. This is true *iff* we only ever have a single endpoint per interface; i.e. all packets that come in are destined for, say, the same TCP port demultiplexor. If not, then there needs to be something in the packet that tells you which endpoint the packet is for. For example, if a mobile process with UDP port Q open moves from one host H1 to another H2, if some other process on H2 already has a UDP port Q open, you're screwed; there's a collision. (You can get the same thign with TCP, too.). The endpoints need to drag their entire demultiplexing naming space (both protocols, and ports within protocols) around with them. So, to disambiguate which one to look in when you have several of these, you have some sort of endpoint name in the packets. (At least for those cases, and then you've got all the extra hassle of deciding when to put it in, and when to leave it out, handling two different packet formats, etc, etc, etc.) This doesn't thrill me, but... Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 2 05:09:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24358; Sat, 2 Jul 1994 04:19:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA26077; Sat, 2 Jul 1994 04:19:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA26042; Sat, 2 Jul 1994 04:03:37 +1000 Precedence: list Received: from ni.umd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23977; Sat, 2 Jul 1994 04:03:32 +1000 (from zben@ni.umd.edu) Received: from zben-mac-ii.umd.edu (zben-mac-ii.umd.edu [129.2.8.98]) by ni.umd.edu (8.6.9/8.6.9) with SMTP id OAA18828; Fri, 1 Jul 1994 14:03:23 -0400 Date: Fri, 1 Jul 94 14:03:23 -0400 From: Charles B Cranston To: Paul Robinson Subject: Re: In the matter of 64-bit addresses Cc: On the Growth of the Internet , IETF List , Namedroppers Message-Id: In-Reply-To: Your message <01.1994Jun29.17h27m45s.PAUL-0100000@TDR.COM> of Wed, 29 Jun 1994 20:25:30 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII You might want to consider addresses for space stations, the moon, Mars and Venus, etc if you're REALLY looking at the next 20-100 years. Or maybe they come out of the 13 or 14 group??? Converting the ISO two-letter country codes to ASCII would take a max of 14 bits. Random thoughts from another Silver Spring denizen. From owner-Big-Internet@munnari.OZ.AU Sat Jul 2 05:13:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24384; Sat, 2 Jul 1994 04:21:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA26092; Sat, 2 Jul 1994 04:21:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA26074; Sat, 2 Jul 1994 04:16:18 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24292; Sat, 2 Jul 1994 04:16:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28894; Fri, 1 Jul 94 14:16:08 -0400 Date: Fri, 1 Jul 94 14:16:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407011816.AA28894@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs Cc: jnc@ginger.lcs.mit.edu From: Robert Elz First, assume that a TLN is an EID, protocol, and port. This wasn't what I had in mind when I started using the TLN acronym, but... There are three things we can name: - the entire endpoint, including all the protocols inside it (i.e. the demultiplexing point where you look at the "proto" field in the internetwork header - sort of like what a NET in ISOese names) - a single transport protocol, such as TCP (i.e. prior to port demultiplexing - sort of like what an NSAP, including a SEL, names) - a single connection of a given tranport protocol I think the name of the first thing is the most important one to have a term for, since i) it names something which doesn't otherwise have a name, and ii) it's a field that we will have to have in packets (whether some or all is open, I guess) which is *separate* from the existing "proto" and "port" fields. If you all want to use the term "TLN" to name the latter thing, I guess I can't stop you, but if so can you please give me a term which means a name for the first thing; moreover, one y'all don't promtly snarf and redefine? :-) Whatever this name is (call it a "TLN" for now), a "TLN"+proto identifies a particular transport protocol, and a "TLN"+proto+port identifies a particular connection. I like having the term "TLN", in addition to "EID", since an EID had, in my mind, certain characteristics above and beyond the general characteristics of a "TLN". E.g. it's topologically insensitive, and globally unique. There are other "TLN"s, which don't share these characterstics; e.g. the NET (i.e. an NSAP without the SEL), which is topologically sensitive. It's nice to have a term so that we can discuss the general concept of separating the TS-ILN from the "TLN", without getting into the usual interminable debates over the particular characteristics of EID's (how do you make them unique, etc). However any particular process on the host would be associated with a particular EID This *doesn't* mean that each process would have a *separate* EID, right? Also, I could have one EID split over multiple hosts. This can allow load sharing Only if the application is carefully arranged so that you can shoot one host dead with no warning, and have the others pick up seamlessly. I.e., any critical state (e.g. TCP connection state) must be replicated... When I, as a human, have a conversation ... with "Steve Deering" about EIDs, my human brain can make the association very quickly with the "Steve Deering" that works at Xerox PARC ... Someday perhaps computers will be able to make that kind of association ... when that happens perhaps we will no longer need unique numbers ... for computer communications. Similarly, if we humans couldn't do pattern matching that well, we'd probably insist that each of us have a unique name to make recognition more feasible. Exactly. One reason the postal analogy is not an exact match is that human names existed a long time before the mail system did, and people didn't feel inclined to change their naming system to make the mail work a little easier. Another solution to collisions, local renaming, was adopted instead. Noel From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 02:00:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29582; Sun, 3 Jul 1994 02:00:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA27149; Sun, 3 Jul 1994 01:59:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA27135; Sun, 3 Jul 1994 01:46:48 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22963; Sat, 2 Jul 1994 23:30:11 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 2 Jul 94 22:23:38 +0900 From: Masataka Ohta Message-Id: <9407021323.AA24825@necom830.cc.titech.ac.jp> Subject: Re: Omnibus reply - EIDs To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sat, 2 Jul 94 22:23:37 JST Cc: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9407011816.AA28894@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jul 1, 94 2:16 pm X-Mailer: ELM [version 2.3 PL11] > First, assume that a TLN is an EID, protocol, and port. > > This wasn't what I had in mind when I started using the TLN acronym, but... > There are three things we can name: Could you stop creating new acronyms without understanding its meaning in advance? > - the entire endpoint, including all the protocols inside it (i.e. the > demultiplexing point where you look at the "proto" field in the internetwork > header - sort of like what a NET in ISOese names) Such a entity precisely belongs to the internetwork layer (or, with ISO terminology, network layer). So, don't call it "transport". Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 07:20:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07530; Sun, 3 Jul 1994 07:20:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA27463; Sun, 3 Jul 1994 07:19:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA27449; Sun, 3 Jul 1994 07:08:53 +1000 Precedence: list Received: from access1.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07215; Sun, 3 Jul 1994 07:08:50 +1000 (from tdarcos@access.digex.net) Received: by access1.digex.net id AA24600 (5.67b8/IDA-1.5 for On the Growth of the Internet ); Sat, 2 Jul 1994 17:08:43 -0400 Newsgroups: tdr.paul.private.mail Date: Sat, 2 Jul 1994 17:08:42 -0400 (EDT) From: Paul Robinson Sender: Paul Robinson Reply-To: Paul Robinson Subject: Location Independent Routing in the Next Generation IP? To: Charles B Cranston Cc: On the Growth of the Internet , IETF List , Namedroppers Message-Id: <01.1994Jul02.16h25m27s.PAUL-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- I'm going to talk about location independent routing of IP addresses, but first I want to explain how something similar is being done in a related manner. The question is if we want to go that route. In North America telephone dialing area 1 (Canada, USA and several other countries as well as other locations around the world), there is a capability for the provision of a telephone call to be made to a party in which the party that is called automatically pays for all charges to that called number. This feature is called "Inward WATS" and is identified in the United states by a 10-digit telephone number starting with "800". The "800" code indicates that the number is paid for by the called party within the range where the number allows it. This has become so popular that other countries are changing their reverse-charge numbers to start with 800 also. Up until a few years ago, you could only get an 800 number from your local telephone company or from the national long distance provider, AT&T. With the implementation of separate long distance companies such as MCI, Sprint and others, it was now possible for a customer to obtain an 800 number from any of these firms. Each firm was assigned a "prefix" in the 800 number range (800-200-xxxx through 800-999-xxxx where the 200 or 999 is the prefix). For example, 800-222 belonged to AT&T, while 800-673 belonged to MCI, for example. You could look up how to route a call by the prefix and know what company handled it. This means you need about 800 or so entries, one for each prefix, in the routing tables. Earlier this year, this was changed. Now, any company can issue any 800 number to a customer, except prefixes reserved to customers outside the U.S., ones not allowed to be assigned to customers (800+0 and 800+1), and ones removed for future assignment according to request. This means that a pool of perhaps 7 million toll-free numbers can all have any of the carriers for anywhere in the country. Also, a customer can ask that his particular number can be handled by multiple carriers, for example, calls in Dallas might be handled by MCI, calls in Kansas and Oklahoma might be handled by Sprint, and calls in the rest of the country might be handled by AT&T. What does this have to do with anything the IETF, or big internet lists subscribers might be interested in? Think about it for a moment. With the coming of IP Next Generation, a much larger IP space - some want 64 bits, some want 10 bytes, some want 16 bytes - is going to be created. We cannot expect a common router to carry the entire IP routing list for all addresses created; the list could conceivably hold millions or tens of millions of entries. Carrying a few thousand tables alone is causing problems. The 800 number portability issue settled this by creating a master database indicating how to route to an 800 number. But to do this, it required that a single database with all of the millions of customer numbers be created, and that all of the local and long distance companies cooperate in setting it up. In doing telephone call lookups, taking a second or so to see how to route an 800 call isn't significant. But taking that long to route packets might be disasterous. If we do not want to go to setting up a massive database of this type - and we can do it, it just requires figuring out who is going to pay for it - the only other answer is coding some part of the routing information as either part of the transaction setup or as part of the transaction itself. If we want to have one - or perhaps 2 or 3 to reduce the amount of overhead to any one site, as well as for reliability - replicated databases of the entire IPng list, we can do this, but it means having huge shared databases. It's not extremely expensive - a bank of 10 PCs set up to handle nothing but NSlookup requests with a shared 3 GB database could do it - for perhaps $20,000 or so. It also means that except for cached addresses, routers could not keep routing lists because there would be too many. We could do something similar to what is done now; take the first 8 bits of the new IP number and assign it to some 256 distributed servers, or however many portions of the number we will use. Each of those servers would carry routing information on any address starting with the 8-bit code they use. This would reduce the size of the database and thus make the network perhaps a little more resilliant to failure because the routing would be distributed at many points. The first option sets up a list of servers that have "base level" information, the second divides up the IP space hierarchically. Either we need to make IP numbers geographic or we have to start having HUGE routing tables at machines dedicated to the purpose for the entire network; a router can't be expected to carry the routing for perhaps 50 million sites. These are the only two alternatives I can see. --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: They're only trying to make me LOOK paranoid! From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 11:10:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08773; Sun, 3 Jul 1994 08:19:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA27528; Sun, 3 Jul 1994 08:19:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA27514; Sun, 3 Jul 1994 08:04:20 +1000 Precedence: list Received: from access1.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06264; Sun, 3 Jul 1994 06:25:24 +1000 (from tdarcos@access.digex.net) Received: by access1.digex.net id AA23158 (5.67b8/IDA-1.5 for On the Growth of the Internet ); Sat, 2 Jul 1994 16:25:09 -0400 Newsgroups: tdr.paul.private.mail Date: Sat, 2 Jul 1994 16:25:09 -0400 (EDT) From: Paul Robinson Sender: Paul Robinson Reply-To: Paul Robinson Subject: Re: In the matter of 64-bit addresses To: Charles B Cranston , On the Growth of the Internet Message-Id: <01.1994Jul02.15h52m56s.PAUL-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- Charles B Cranston , writes: > You might want to consider addresses for space stations, the moon, > Mars and Venus, etc if you're REALLY looking at the next 20-100 > years. I think I posted an issue about this a year or more ago due to the fact that speed-of-light lag would make many timing issues impossible in interplanetary travel and it was suggested that something akin to UUCP would probably pop up since synchronus links would not be possible when round trip time for transmissions was in excess of 4 hours. > Or maybe they come out of the 13 or 14 group??? The 13 group can be reserved for off-planet sites. But not even that much space is probably needed. You could probably assign multiple IP addresses to every person who will be in space in the next 20 years with one current class B address at current rates of exploration. In the next 100 years, do we seriously expect large-scale outmigration? We need it if humanity is to survive, but rather than look at the huge long-term profits, most companies see no short-term profit and thus have no interest. There is money to be made to those who figure ways to use the resources of space; a lot of money. But it's going to take some to get there; estimates are that one trip to the moon with a large enough freight capacity - 10 or 20 tons - could return US $15 billion over a couple of years on an investment of US $300 million. > Converting the ISO two-letter country codes to ASCII would > take a max of 14 bits. You could probably get it into 10 bits since both fields are only A-Z, which is some 760 or so possible entries, 26^2 (and some ISO codes won't be used, e.g. XA-XZ and ZZ, if memory serves me). I think that 5 bits per letter would fit the entire scope. If 6 bits (or 10 bits to make the field use 20 bits) were used, this would allow for 700 providers in each country. Using the 10-bit country code, someone in, say, the USA can pick whichever of his providers (if he has more than one) routes messages to a site with a TW (Taiwan) address. Once the packet gets near to Taiwan, someone there could look at the provider code to see which provider he has to route the messages to. Some people have complained because it means that if they move or change providers they have to change their IP number. Well, what can be done is to assign the last bunch of numbers in a form as I indicated, e.g. using the 4-bit length field to assign a 44-bit number to them, part of which representing the network and part representing the user's local portion, in a manner similar to the Class A, B and C routing used now, only with better scaling since someone can be assigned what they need, e.g. 16, 256, 4096, 65536, 1.04M, and so on for 24, 28, 32, 36 and 40 bits. Yes, you would have to change the upper part of the number if your provider changes. But the advantage is that if part of your network is on one provider and part is on another, people can route to it directly. This was what I considered a reasonable suggestion; people could simply program in a 12-bit table of a couple thousand routes, and the local area could have routings for the ones in its area. The only other solution is location independent routing, which is another ball of wax that I'll tackle in a subsequent message, due to having to explain what I mean and allow people to see what I think is wrong there. --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: If I kiss you, that is a psychological interaction. On the other hand, if I hit you over the head with a brick, that is also a psychological interaction. The difference is that one is friendly and the other is not so friendly. The crucial point is if you can tell which is which. -- Dolph Sharp, "I'm O.K., You're Not So Hot" From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 11:20:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12602; Sun, 3 Jul 1994 11:20:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA27689; Sun, 3 Jul 1994 11:19:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA27675; Sun, 3 Jul 1994 11:08:19 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09482; Sun, 3 Jul 1994 08:48:36 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id SAA29502; Sat, 2 Jul 1994 18:48:32 -0400 Date: Sat, 2 Jul 1994 18:48:32 -0400 From: Vadim Antonov Message-Id: <199407022248.SAA29502@titan.sprintlink.net> To: PAUL@TDR.COM, zben@ni.umd.edu Subject: Re: Location Independent Routing in the Next Generation IP? Cc: Big-Internet@munnari.OZ.AU, ietf@cnri.reston.va.us, namedroppers@rs.internic.net >Either we need to make IP numbers geographic or we have to start having >HUGE routing tables at machines dedicated to the purpose for the entire >network; a router can't be expected to carry the routing for perhaps 50 >million sites. >These are the only two alternatives I can see. Or we do dynamic address allocation. This is the trivial solution to both mobility and routeing bloat (and also guarantees >50% address space utilization if implemented in a sane way). Long and variable length transport level addresses - JUST SAY NO. There are easier solutions. The *ONLY* state a machine should carry is its domain name(s) plus authentication key. The rest should be done automagically when you plug it into an outlet. How to do that is not a rocket science; and the first technologically viable product of that sort will kill IP NG or not NG (ever thought why IPX machines are still by order of magnitude outnumber IP machines -- with all the idiotism in IPX stack design?) Why people fail to see the obvious way out of the situation and keep trying to solve the wrong problem? What is greater -- 17 or green? That's how the current "variable vs fixed" discussion looks like to an observer not burdened with camp allegiances and old clever hacks. Any propsal which assume humans will be dealing with 20-byte hex sequences should be killed immediately without futher elaborations; and its author(s) should be awarded the honorary title "OSI Wannabe Of The Year". --vadim From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 14:10:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14670; Sun, 3 Jul 1994 12:40:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA27766; Sun, 3 Jul 1994 12:39:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA27763; Sun, 3 Jul 1994 12:28:06 +1000 Precedence: list Received: from BIG-SCREW.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14374; Sun, 3 Jul 1994 12:27:59 +1000 (from jis@mit.edu) Received: by big-screw id AA20041; Sat, 2 Jul 94 22:27:51 -0400 Date: Sat, 2 Jul 1994 22:27:50 -0400 (EDT) From: "Jeffrey I. Schiller" Sender: "Jeffrey I. Schiller" Reply-To: "Jeffrey I. Schiller" Subject: Re: IPng ADs request To: big-internet@munnari.OZ.AU In-Reply-To: <25633.773012688@munnari.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Let me throw a random thought in here. I apologize for joining this conversation a little late. I have read a few messages that imply that providing for a globally unique EID would be an administrative headache (you would have to have blocks of EID address space delegated to agencies who would then allocate individual EIDs etc.). However if EIDs are at least 128 bits, then this isn't necessarily the case. They can be chosen at random (assuming good randomness) with little probability of collision. My favorite approach to doing this is to have each end point generate a public/private key pair. An end point's EID can then be the MD5 hash of its public key. Not only does this provide for a unique EID, but it also provides a neat way to tie an entities public key to its EID. Food for thought. -Jeff From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 15:20:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18591; Sun, 3 Jul 1994 15:20:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA27918; Sun, 3 Jul 1994 15:19:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA27915; Sun, 3 Jul 1994 15:15:34 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18406; Sun, 3 Jul 1994 15:15:24 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA29948; Sat, 2 Jul 94 22:14:22 -0700 Received: by xirtlu.zk3.dec.com; id AA20270; Sun, 3 Jul 1994 01:14:12 -0400 Message-Id: <9407030514.AA20270@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Transport, Mobility, Robustness (was: Re: IPng ADs request) In-Reply-To: Your message of "Fri, 01 Jul 94 12:59:58 EDT." <9407011659.AA28391@ginger.lcs.mit.edu> Date: Sun, 03 Jul 94 01:14:06 -0400 X-Mts: smtp >For example, if a mobile process with UDP port Q open moves from one host H1 >to another H2, if some other process on H2 already has a UDP port Q open, >you're screwed; there's a collision. (You can get the same thign with TCP, >too.). The endpoints need to drag their entire demultiplexing naming space >(both protocols, and ports within protocols) around with them. So, to >disambiguate which one to look in when you have several of these, you have >some sort of endpoint name in the packets. You are now talking about process migration which is notin my reality model of what Mobile can even think about without many enhancements to the OS technology. This is something we need to do and something I am working on in a backroom right now for other reasons, which may become reality 10 years from now as a product? Or am I missing something basic above. Thanks. /jim From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 15:59:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18605; Sun, 3 Jul 1994 15:21:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA27933; Sun, 3 Jul 1994 15:21:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA27912; Sun, 3 Jul 1994 15:10:19 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18342; Sun, 3 Jul 1994 15:10:13 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA29617; Sat, 2 Jul 94 22:08:38 -0700 Received: by xirtlu.zk3.dec.com; id AA20219; Sun, 3 Jul 1994 01:08:28 -0400 Message-Id: <9407030508.AA20219@xirtlu.zk3.dec.com> To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Transport, Mobility, Robustness (was: Re: IPng ADs request) In-Reply-To: Your message of "Fri, 01 Jul 94 08:44:05 PDT." Date: Sun, 03 Jul 94 01:08:22 -0400 X-Mts: smtp =>>We need to remember that IP was designed to do a basic job and do it ... =>Absolutely. But that does not mean we cannot make it better. >Well, I'm probably not likely to say you're wrong... >On the other hand, I need to re-assert my basic concern that we not burden >this wonderful "module" with too much additional functionality. Definitely not without much thought and also prototype implementations to test any performance pain that might occur. So I essentially agree with you just want to be able to investigate 'ideas' in this discussion. =>But I don't =>think we want to overload the DNS model everytime we have handle =>movement of state in the network paradigm. >Jim, I too am quite concerned that we be careful about messing with the >DNS. Nonetheless, this feels like a reasonable line of attack to me, given >that I see the other choices as being overburdening IP or creating >yet-another directory service. Mumble. Whoaa.. I agree with you I don't this to redefine anything about DNS at all. DNS works fine and can evolve agreed. Lets talk it out I am not sure any of this should even go into the application layer at all yet. =>> In fact, this seems to be the =>>critical requirement that forces folks to think of network-level constant =>>id's. => =>Here is where the dis-agreement may be happening technically. EIDs by =>definition state that they are not related at all to the network-level. >I may be wrong, but I think we are in violent agreement. Just to be sure: >My view is that IP should have a string that really the same as we >currently use. I'll call that an "interface address" because it does >pertain to an interface rather than node and because it gives location >information without describing a path. This other thing that we need >refers to the node, not any of its interfaces, and stays constant. I'm >using to calling this a "host name". I am with you almost. I would like to see us get away from the 'interface' model as in IP today. Here is a good example of why? If a database application or a cluster address is being used and for some reason (pick one) the actual interface ln0, ln1, etc is corrupted the network connection should be able to restart without bothering the application on the Host system. But I would not go so far as to say the 'string' your referring to should identify the node? Thats the question I have not figured out yet without an error in my logic tables yet at the transport or in DNS. I am still pondering this presently with no luck. Would you or Paul Vixie please send something to us defining Path and Address and if possible Locator or Mike O'. )---> Thanks ... I think we need to see this in print. =>>Talking in terms of Transport Identifers at least keeps us talking about ... =>As I started the TI or TCI thought I now agree with Kre that this =>semantic is wrong because there are other parts to a Transport =>Connection and EIDs are just one part. >Agreed. I did not intend that we use that term specifically. Rather, I >was noting that starting with the transport and such a term moved us to >think about this "ID" thing in a different way (and separately) from puting >it in the network level. ACK here too. =>But I do believe that if in IPng we define that which is an identifying =>address and that which is a routing sequence then the basic model to =>switch to EIDs and Locators is possibile technically at least in host =>network kernels tomorrow. Not sure about the routing code. >Jim, you lost me on the above paragraph. I don't really understand what >any of it means, other than it sounds like ripping out the current style of >IP adressing and routing and puting in something entirely different. I'm >not sanguine about anything that revolutionary, since the basic stuff works >so well and is so well understood. Sorry. Let me try to be more clear. First I have learned alot about what is the affect of IPng on the core host architecture and what I am alluding to is can we define IPng 'now', so that tomorrow it can be used for a new routing model so there is no transition or at least just a mater of checking a bit somewhere. Let me try again. If in the IPng header the src and dst addresses are addresses that only pertain to a subnet within a site and if you must route out of that site then you must use a source route. This maintains the basic IP model but adding more reliance on source routing (and all the problems that come with that). This keeps the IPng address as the 'string' for a site and I think should be globally unique. IMHO Most traffic will remain on the LAN and within the site for some time even when toaster net begins (using set top devices as an example). But when the traffic leaves the site it must use a source route. Now if we figure out how to name and use 'strings' at the transport that have no location (subnet or site) information then we can migrate to that model when it becomes in place. One way to do this is to have a routing version in the IPng header defining a routing paradigm which defines the algorithm for that routing version. It can permit multiple routing strategies within the Internet. In other words a routing demux bit. [Steve Deering / Yakov Rehketer - What do you think about having such a routing bit in an IPng header] ??? =>But the IP address contains routing state which is the issue for most of =>us who believe in EIDs. >Agreed. My point is that : does NOT have routing state. OK thats more clear. So do you want to actually use the name 'foo' as the EID? =>>What we do NOT have is a way for TCP to use multiple mappings of the domain =>>name into multiple IP addresses or to merge multiple data streams into one. => =>I understand the mappings need and that is what an EID needs to be =>defined to do. >My point is that I think we need to start by asking whether the current >hostname string will suffice. I think it can. OK you do mean an ascii string. Hmm I worried about collisions of name space? Whats your thought on that? >The argument for a new string is that we need something shorter. Well, we >only need something shorter if we believe we need to put it into every >packet. I think we don't. I think that it might need to go at the start >of a session, or at the start of each connection, to allow the end-systems >know how to synchronize the multiple streams. Still worried about collisions. Its fair for you to name your node 'foo' at your end and for me to name my node 'foo' at my end under DNS today? =>>My own suspicion is that we need a simple, clean Session mechanism which is ... =>I think this may add a new layer above transport but before the >Mike O privately used the term 'facility' and explicitly argued against the >term 'layer'. I'm inclined to agree. This could turn into a nitpicky >issue, but my own concern is that understand just how light-weight this >needs to be and that we understand that it MUST be truly end-to-end. >Calling it a "layer" may cause some people to think more grandiosely than >is appropriate and, worse(?), may cause them to implement it outside of the >application. I will go along with facility but where it resides on a host needs to have more discussion. => Putting it in the application layer would be a =>performance hit unless other parts of the OS were enhanced (like doing >Huh? That's not required, I believe. Please explain. When you cross the user to kernel space you have to take a context switch in the OS. This is a performance hit. Some of the various Micro kernels in research land are having to deal with this big time. Its very costly. =>moves instead of copies when crossing into kernel space). >Bad joke. Someone observed that no computer ever moves data. It ONLY ever >copies it. You jest right? Loading off of an index from a register and then later accessing the data at that location is far cheaper than using a new register and then moving that data to that register (copy). In the former you are just placing your data at an offset to a register that points to memory available to all parts of the OS. =>I think this is separate from EIDs and another issue to be solved =>though? >Not necessarily. Let's hear what the real and concrete requirements are >that would dictate it being separate. Well lets see what Richards draft tells us. /jim From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 16:00:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19522; Sun, 3 Jul 1994 16:00:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA27992; Sun, 3 Jul 1994 15:59:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA27986; Sun, 3 Jul 1994 15:55:39 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19470; Sun, 3 Jul 1994 15:55:35 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA02288; Sat, 2 Jul 94 22:52:19 -0700 Received: by xirtlu.zk3.dec.com; id AA20652; Sun, 3 Jul 1994 01:52:10 -0400 Message-Id: <9407030552.AA20652@xirtlu.zk3.dec.com> To: "Jeffrey I. Schiller" Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of "Sat, 02 Jul 94 22:27:50 EDT." Date: Sun, 03 Jul 94 01:52:04 -0400 X-Mts: smtp Jeff, This is a good idea and food for thought. You referenced 128bits in your mail. Certainly 128bits would be enough for the world, but wouldn't 64bits be enough just for an EID? And could we even go to 48bits? Obviously I am thinking about using those other 16bits for something else (like site/subnet). This would be very good for autoconfiguration too which is one of the IPng carrots for folks to move to IPng in the first place. /jim From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 17:58:11 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00552; Sun, 3 Jul 1994 17:58:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00458 Sun, 3 Jul 1994 16:01:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA28007; Sun, 3 Jul 1994 16:01:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA27972; Sun, 3 Jul 1994 15:51:43 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17473; Sun, 3 Jul 1994 14:37:02 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 3 Jul 94 13:30:22 +0900 From: Masataka Ohta Message-Id: <9407030430.AA26491@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request To: jis@MIT.EDU Date: Sun, 3 Jul 94 13:30:21 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: ; from "Jeffrey I. Schiller" at Jul 2, 94 10:27 pm X-Mailer: ELM [version 2.3 PL11] > My favorite approach to doing this is to have each end point generate a > public/private key pair. An end point's EID can then be the MD5 hash of > its public key. Not only does this provide for a unique EID, but it also > provides a neat way to tie an entities public key to its EID. As we are talking about packet format, source EIDs are contained in incoming IP packets. They are there because they are useful to query some databases (DNS, for example) to extract some information (such as public key) of the source host. Flat, random EIDs are no good for such queries. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 17:58:18 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00557; Sun, 3 Jul 1994 17:58:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00476 Sun, 3 Jul 1994 16:03:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA28022; Sun, 3 Jul 1994 16:02:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA27989; Sun, 3 Jul 1994 15:59:07 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19137; Sun, 3 Jul 1994 15:46:02 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA01555; Sat, 2 Jul 94 22:40:22 -0700 Received: by xirtlu.zk3.dec.com; id AA20578; Sun, 3 Jul 1994 01:40:11 -0400 Message-Id: <9407030540.AA20578@xirtlu.zk3.dec.com> To: Masataka Ohta Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU, kre@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Omnibus reply - EIDs In-Reply-To: Your message of "Sat, 02 Jul 94 22:23:37 +0200." <9407021323.AA24825@necom830.cc.titech.ac.jp> Date: Sun, 03 Jul 94 01:40:05 -0400 X-Mts: smtp => First, assume that a TLN is an EID, protocol, and port. => => This wasn't what I had in mind when I started using the TLN acronym, but... => There are three things we can name: >Could you stop creating new acronyms without understanding its meaning >in advance? I second this request. It causes us to not be able to see the target except maybe with binoculars from a very far distance. => - the entire endpoint, including all the protocols inside it (i.e. the => demultiplexing point where you look at the "proto" field in the internetwork => header - sort of like what a NET in ISOese names) >Such a entity precisely belongs to the internetwork layer (or, with ISO >terminology, network layer). >So, don't call it "transport". ACK. /jim Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 19:55:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01211; Sun, 3 Jul 1994 18:20:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA28148; Sun, 3 Jul 1994 18:19:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA28134; Sun, 3 Jul 1994 18:02:31 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18956; Sun, 3 Jul 1994 15:40:39 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA01328; Sat, 2 Jul 94 22:36:22 -0700 Received: by xirtlu.zk3.dec.com; id AA20546; Sun, 3 Jul 1994 01:36:13 -0400 Message-Id: <9407030536.AA20546@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Omnibus reply - EIDs In-Reply-To: Your message of "Fri, 01 Jul 94 14:16:08 EDT." <9407011816.AA28894@ginger.lcs.mit.edu> Date: Sun, 03 Jul 94 01:36:07 -0400 X-Mts: smtp >This wasn't what I had in mind when I started using the TLN acronym, but... >There are three things we can name: >- the entire endpoint, including all the protocols inside it (i.e. the > demultiplexing point where you look at the "proto" field in the internetwork > header - sort of like what a NET in ISOese names) This confuses me. Help. At the transport you are only looking at that part of the internetwork datagram TCP or UDP. Then at the transport you proceed from there? I will have to ask my OSI expert but I don't think they care about nsel until they get to the transport? So I am not really sure what you are naming here?????? $#^[,,1...99] !! >- a single transport protocol, such as TCP (i.e. prior to port demultiplexing - > sort of like what an NSAP, including a SEL, names) Now I am totally confused. An NSAP contains routing information, authorities, location of area, and ID. NSEL is like a port in TCP/UDP? This goes against EID and Locator as we are discussing it. An NSAP may be the complete set of names but not a unique name for one part of the address? >- a single connection of a given tranport protocol This is the only thing an EID should name IMHO. Whether Locators have names is I think a point of discussion. What is .dec.com to you in your model? I think it is a location qualifier for the name space where the address can be determined. Or its a hint? >I think the name of the first thing is the most important one to have a term >for, since i) it names something which doesn't otherwise have a name, and ii) >it's a field that we will have to have in packets (whether some or all is >open, I guess) which is *separate* from the existing "proto" and "port" >fields. Well first redefine it and clarify the description its not clear presently. >If you all want to use the term "TLN" to name the latter thing, I guess I >can't stop you, but if so can you please give me a term which means a name for >the first thing; moreover, one y'all don't promtly snarf and redefine? :-) Whats that last sentence mean. I am not going to participate in this IETF discussion or any discussion if we cannot get away from I invented it and therefore you can't change it if thats what you mean. The reason the EID term is coming up with different names is that your ideas generate sub-thoughts and focused thoughts on parts of your model. But if the only way you will feel comfortable with us working on that subset is by changing the name then thats what we have to do. What is not acceptable is for us to pursue this as its in a midevil court where the king declares all the rules of play. No kings in the IETF or has this changed. Now if someone is not getting credit for their work thats not cool but I don't see that happening we are trying to run with the ball you have thrown to us for this game. One reason IMHO this has not moved further faster and I think one of the issues others have with EIDs and Locators is that it contains lots of chunks in the model. Most of the chunks are big enough you must chew them for awhile and you cannot swallow them whole. I think we need to pick a few chunks and solve each problem (the sub-thoughts-focus from above). But trying to design large chunks intertwined perfectly without looking at the individual chunks piece-meal will result in continued chaos on this subject. Its also mandatory that terminology be crisp and clear. /jim From owner-Big-Internet@munnari.OZ.AU Sun Jul 3 23:40:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09806; Sun, 3 Jul 1994 23:40:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA28626; Sun, 3 Jul 1994 23:39:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28623; Sun, 3 Jul 1994 23:34:08 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09610; Sun, 3 Jul 1994 23:33:58 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 3 Jul 94 22:26:48 +0859 From: Masataka Ohta Message-Id: <9407031327.AA27461@necom830.cc.titech.ac.jp> Subject: Re: Location Independent Routing in the Next Generation IP? To: avg@sprint.net (Vadim Antonov) Date: Sun, 3 Jul 94 22:26:47 JST Cc: PAUL@TDR.COM, zben@ni.umd.edu, Big-Internet@munnari.OZ.AU, ietf@cnri.reston.va.us, namedroppers@rs.internic.net In-Reply-To: <199407022248.SAA29502@titan.sprintlink.net>; from "Vadim Antonov" at Jul 2, 94 6:48 pm X-Mailer: ELM [version 2.3 PL11] > Or we do dynamic address allocation. This is the trivial solution to > both mobility You can't solve mobility that way. Dynamic address allocation (and/or dynamic DNS with IXFR and NOTIFY) may give the up-to-date address at the time of the query. But you can't expect them to predict future changes of the address. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 4 04:49:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18106; Mon, 4 Jul 1994 04:21:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA29271; Mon, 4 Jul 1994 04:19:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA29268; Mon, 4 Jul 1994 04:18:14 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15733; Mon, 4 Jul 1994 02:48:01 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA26965; Sun, 3 Jul 1994 09:47:54 -0700 Message-Id: <199407031647.JAA26965@Mordor.Stanford.EDU> To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: Transport, Mobility, Robustness (was: Re: IPng ADs request) Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sun, 03 Jul 94 01:08:22 -0400. <9407030508.AA20219@xirtlu.zk3.dec.com> Date: Sun, 03 Jul 94 09:47:54 -0700 From: Dave Crocker X-Mts: smtp Jim, ---- Included message: >My view is that IP should have a string that really the same as we >currently use. I'll call that an "interface address" because it does >pertain to an interface rather than node and because it gives location >information without describing a path. This other thing that we need >refers to the node, not any of its interfaces, and stays constant. I'm >using to calling this a "host name". I am with you almost. I would like to see us get away from the 'interface' model as in IP today. Here is a good example of why? If a database application or a cluster address is being used and for some reason (pick one) the actual interface ln0, ln1, etc is corrupted the network connection should be able to restart without bothering the application on the Host system. But I would not go so far as to say You state an application functional requirement with which I agree completely. Where we are differinging is in the implication for IP. You assume that it requires changing IP and its addressing model. I am trying to ask that we look around for alternate schemes which do not. You're earlier comment about it being ok to make changes after test implementations is, in fact, less cautious than I'm feeling. Testing means small scale stuff and I am very, very concerned about changing any basic characteristics of the core model that drives the core protocol for the Internet. Scaling effects don't show up in testing. That does not mean holding on to all the current detail forever. However, I do take it as weighting things massively. I.e., we should try to avoid any changes we find alternate solutions to. But remember that I DO agree with the application-level benefit you are seeking. Would you or Paul Vixie please send something to us defining Path and Address and if possible Locator or Mike O'. )---> Thanks ... I think we need to see this in print. I don't know that the term 'locator' means, so I'll punt. I use the term Name to refer to a thing independent of its location(s). I use the term Address to refer to its "place" within the net, where that address does not change according to ones perspective. I.e., globally unique and constant. I use Path to refer to the way to get from one place to another. It is very, very dependent upon the relationship between the two places. (For reference, this is all straight Schoch.) alluding to is can we define IPng 'now', so that tomorrow it can be used for a new routing model so there is no transition or at least just a mater of checking a bit somewhere. This raises the on-going desire to delay and defer IPng until we solve large and appealing technical questions "for the long term", where advanced routing is one of the major examples of planned future benefit. I'm sympathetic with the desire to improve things. I'm not sympathetic with the desire to delay, particularly in the absence of concrete benefits that are concretely demonstrable. It would be great if we had a wonderful new routing model, adequately tested and understood to incorporate. We don't. We need to move on in spite of that. If in the IPng header the src and dst addresses are addresses that only pertain to a subnet within a site and if you must route out of that site then you must use a source route. This maintains the basic IP model Jim, this does NOT maintain the basic IP model. It's the sort of scheme we proposed in the original IPAE spec, with the classic IPv4 header being used for a "next hop" within a given internetwork, but not holding the globally unique string that we currently require. Vint, for example, was very, very uncomfortable about it. It changes our basic model. but adding more reliance on source routing (and all the problems that We have little and poor experience with heavy use of source routing. What makes it wonderful all of a sudden? Now if we figure out how to name and use 'strings' at the transport that have no location (subnet or site) information then we can migrate to that model when it becomes in place. One way to do this is to have a Ahhh. Now we are talking about changes at the transport level. Not part of IPng, but rather Tng. Probably a useful and interesting discussion, since it is in terms of adding flexibility, without necessarily displacing the current model. On the other hand, there's nothing in it that requires changing the current network layer, is there? routing version in the IPng header defining a routing paradigm which Jim, are we talking transport changes or IP changes? YOu seem to be switching. >Agreed. My point is that : does NOT have routing state OK thats more clear. So do you want to actually use the name 'foo' as the EID? I'd like to try. But the clear implication is that this string does NOT show up in every packet. I'd like to find a way for it to be out of the fast path. The current fastpath processing is quite good and the current functionality of getting a packet from one interface to another is quite good. I'd like to find a solution to the functional requirements which does not require changing/disrupting either of these... >My point is that I think we need to start by asking whether the current >hostname string will suffice. I think it can. OK you do mean an ascii string. Hmm I worried about collisions of name space? Whats your thought on that? Huh? Domain names are globally unique. What collision are you worried about? Since is able to be unique, why should changing one set of globally unique strings (IP addresses) for another (domain names) pose new or different problems in attaining uniqueness? Still worried about collisions. Its fair for you to name your node 'foo' at your end and for me to name my node 'foo' at my end under DNS today? JIM!!! It's foo.org1.com and foo.org2.com. Domain names. Remember? I will go along with [session] facility but where it resides on a host needs to have more discussion. Lots and lots. It might even need a spec... When you cross the user to kernel space you have to take a context switch in the OS. This is a performance hit. Some of the various Oh that. Yes. Must make sure not to impose additional crossings. In the former you are just placing your data at an offset to a register that points to memory available to all parts of the OS. This could bog us down. I assume you simply mean that we need to preserve the ability to do page-flipping. In any event, I'm certain that we all agree that whatever is proposed/adopted, it must maintain performance. Dave From owner-Big-Internet@munnari.OZ.AU Mon Jul 4 05:40:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20475; Mon, 4 Jul 1994 05:40:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA29357; Mon, 4 Jul 1994 05:39:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29354; Mon, 4 Jul 1994 05:37:22 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20395; Mon, 4 Jul 1994 05:37:17 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id PAA02046; Sun, 3 Jul 1994 15:37:05 -0400 Date: Sun, 3 Jul 1994 15:37:05 -0400 From: Vadim Antonov Message-Id: <199407031937.PAA02046@titan.sprintlink.net> To: avg@sprint.net, mohta@necom830.cc.titech.ac.jp Subject: Re: Location Independent Routing in the Next Generation IP? Cc: Big-Internet@munnari.OZ.AU, PAUL@TDR.COM, ietf@cnri.reston.va.us, namedroppers@rs.internic.net, zben@ni.umd.edu >You can't solve mobility that way. >Dynamic address allocation (and/or dynamic DNS with IXFR and NOTIFY) may >give the up-to-date address at the time of the query. >But you can't expect them to predict future changes of the address. Who told that dynamic addressing assumes name-address lookup only at the time of opening a connection? It is the feature of the bad implementation making transport-level addresses visible at the application level; not the inherent feature of the design. Applications should NEVER deal with addresses -- only with names. Since *sessions* aren't stateless it is easy to notify all peers about change in the address. (Nobody needs to predict future changes of addresses -- it is enough to discover changes after they happened and to allow coexistance of both addresses for some transitional time for the real-time applications). --vadim From owner-Big-Internet@munnari.OZ.AU Mon Jul 4 07:15:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21200; Mon, 4 Jul 1994 06:00:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA29400; Mon, 4 Jul 1994 05:59:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29386; Mon, 4 Jul 1994 05:53:22 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16608; Mon, 4 Jul 1994 03:20:48 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA11112; Sun, 3 Jul 94 10:17:18 -0700 Received: by xirtlu.zk3.dec.com; id AA01317; Sun, 3 Jul 1994 13:17:08 -0400 Message-Id: <9407031717.AA01317@xirtlu.zk3.dec.com> To: Dave Crocker Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Transport, Mobility, Robustness (was: Re: IPng ADs request) In-Reply-To: Your message of "Sun, 03 Jul 94 09:47:54 PDT." <199407031647.JAA26965@Mordor.Stanford.EDU> Date: Sun, 03 Jul 94 13:17:02 -0400 X-Mts: smtp Dave, I am with you almost. I would like to see us get away from the 'interface' model as in IP today. Here is a good example of why? If a database application or a cluster address is being used and for some reason (pick one) the actual interface ln0, ln1, etc is corrupted the network connection should be able to restart without bothering the application on the Host system. But I would not go so far as to say >You state an application functional requirement with which I agree >completely. Where we are differinging is in the implication for IP. You >assume that it requires changing IP and its addressing model. I am trying >to ask that we look around for alternate schemes which do not. You're >earlier comment about it being ok to make changes after test implementations >is, in fact, less cautious than I'm feeling. Testing means small scale >stuff and I am very, very concerned about changing any basic >characteristics of the core model that drives the core protocol for the >Internet. Scaling effects don't show up in testing. Agreed. >That does not mean holding on to all the current detail forever. However, >I do take it as weighting things massively. I.e., we should try to avoid >any changes we find alternate solutions to. But remember that I DO agree >with the application-level benefit you are seeking. OK. Would you or Paul Vixie please send something to us defining Path and Address and if possible Locator or Mike O'. )---> Thanks ... I think we need to see this in print. >I don't know that the term 'locator' means, so I'll punt. I use the term >Name to refer to a thing independent of its location(s). I use the term >Address to refer to its "place" within the net, where that address does not >change according to ones perspective. I.e., globally unique and constant. >I use Path to refer to the way to get from one place to another. It is very, >very dependent upon the relationship between the two places. (For reference, >this is all straight Schoch.) OK. alluding to is can we define IPng 'now', so that tomorrow it can be used for a new routing model so there is no transition or at least just a mater of checking a bit somewhere. >This raises the on-going desire to delay and defer IPng until we solve >large and appealing technical questions "for the long term", where advanced >routing is one of the major examples of planned future benefit. I'm >sympathetic with the desire to improve things. I'm not sympathetic with >the desire to delay, particularly in the absence of concrete benefits that >are concretely demonstrable. It would be great if we had a wonderful new >routing model, adequately tested and understood to incorporate. We don't. >We need to move on in spite of that. I do not want anymore delay either. If in the IPng header the src and dst addresses are addresses that only pertain to a subnet within a site and if you must route out of that site then you must use a source route. This maintains the basic IP model >Jim, this does NOT maintain the basic IP model. It's the sort of scheme >we proposed in the original IPAE spec, with the classic IPv4 header being >used for a "next hop" within a given internetwork, but not holding the >globally unique string that we currently require. Vint, for example, was >very, very uncomfortable about it. It changes our basic model. Yep it does. We will never evolve if we don't. But if now is the time is seriously in question. but adding more reliance on source routing (and all the problems that >We have little and poor experience with heavy use of source routing. What >makes it wonderful all of a sudden? It may be a vehicle to move to a new paradigm and thats the fulcrum of its discusion I think. Now if we figure out how to name and use 'strings' at the transport that have no location (subnet or site) information then we can migrate to that model when it becomes in place. One way to do this is to have a >Ahhh. Now we are talking about changes at the transport level. Not part of >IPng, but rather Tng. Probably a useful and interesting discussion, since >it is in terms of adding flexibility, without necessarily displacing the >current model. On the other hand, there's nothing in it that requires >changing the current network layer, is there? Not to get new transport benefits. routing version in the IPng header defining a routing paradigm which >Jim, are we talking transport changes or IP changes? YOu seem to be >switching. No not at all. I am talking about enhancing the transport model to use a new end to end identifier which does not alter the network layer if for example its in the tcp or udp packet. But also source route is on the table for IPng too at this time. The idea for the bit comes from trying to tell folks we are not changing the model for the network layer right now, but it could evolve hence if we need to change the routing model we turn the bit (or field) on to another level of indirection for routing. Its a place holder. I am not wedded to this being the way to approach evolution but I think it needs to be thought about. >Agreed. My point is that : does NOT have routing state OK thats more clear. So do you want to actually use the name 'foo' as the EID? >I'd like to try. But the clear implication is that this string does NOT >show up in every packet. I'd like to find a way for it to be out of the >fast path. The current fastpath processing is quite good and the current >functionality of getting a packet from one interface to another is quite >good. I'd like to find a solution to the functional requirements which does >not require changing/disrupting either of these... Hmmm. I need to analyze this statement for awhile OK. >My point is that I think we need to start by asking whether the current >hostname string will suffice. I think it can. OK you do mean an ascii string. Hmm I worried about collisions of name space? Whats your thought on that? >Huh? Domain names are globally unique. What collision are you worried about? >Since is able to be unique, why should changing >one set of globally unique strings (IP addresses) for another (domain >names) pose new or different problems in attaining uniqueness? OK your using the whole name. This reduces collisions. Yes performance is an issue and must be part of the analysis. /jim From owner-Big-Internet@munnari.OZ.AU Mon Jul 4 14:04:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02782; Mon, 4 Jul 1994 12:20:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA29720; Mon, 4 Jul 1994 12:19:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA29717; Mon, 4 Jul 1994 12:10:29 +1000 Precedence: list From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02407; Mon, 4 Jul 1994 12:10:22 +1000 (from jcjones@MIT.EDU) Received: from W20-575-18.MIT.EDU by MIT.EDU with SMTP id AA01363; Sun, 3 Jul 94 22:10:19 EDT Received: by w20-575-18.MIT.EDU (5.0/4.7) id AA07608; Sun, 3 Jul 94 22:10:18 EDT Message-Id: <9407040210.AA07608@w20-575-18.MIT.EDU> To: Big-Internet@munnari.OZ.AU Subject: Source Routing & Provider Selection Date: Sun, 03 Jul 94 22:10:17 EDT Content-Length: 357 I've read many discussions about these two topics, but I still don't have a clear picture in my mind of what they actually mean. What is source routing? Does one specify a source route statically, quasi-statically, or dynamically? What is provider selection? Why would anyone want to specify a particular provider? J.C. Jones From owner-Big-Internet@munnari.OZ.AU Mon Jul 4 14:40:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07882; Mon, 4 Jul 1994 14:40:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA29919; Mon, 4 Jul 1994 14:39:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA29910; Mon, 4 Jul 1994 14:25:03 +1000 Precedence: list From: kannan@catarina.usc.edu Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04967; Mon, 4 Jul 1994 13:22:24 +1000 (from kannan@catarina.usc.edu) Received: from catarina.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08030; Sun, 3 Jul 94 20:22:20 PDT Received: from catarina.usc.edu by catarina.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA00598; Sun, 3 Jul 94 20:25:35 PDT Message-Id: <9407040325.AA00598@catarina.usc.edu> To: jcjones@mit.edu Cc: Big-Internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of Sun, 03 Jul 1994 22:10:17 -0400.<9407040210.AA07608@w20-575-18.MIT.EDU> Date: Sun, 03 Jul 1994 20:25:34 -0700 Sender: kannan@catarina.usc.edu >>> From: jcjones@MIT.EDU >>> Date: Sun, 03 Jul 1994 22:10:17 EDT > What is source routing? Does one specify a source route statically, > quasi-statically, or dynamically? Source routing is the means of having the source specify the route a packet must take through the network to be delivered to the destination. RFC 791 specifies source routing as part of the IP forwarding mechanism, but is limited in a couple of different ways only (either strict or loose, max size of header etc.). SDRP (Source Demand Routing Protocol) overcomes these restrictions, and shows how to get extended source routes. Creation of sdr source routed packets, and forwarding is now an internet-draft under the sdr working group. Versions of telnet or traceroute allow the user to specify an IP level source route. Our (USC/ISI) implementation of SDRP has the sysadmin specify a packet filter that triggers source routes when a packet matches the filter. > What is provider selection? Why would anyone want to specify a > particular provider? Provider selection is a means for a end domain to specify a network service provider that they choose. One classic use example is that of a research department of a company using a research oriented NSP, while the commercial wing of the company using a commercial NSP; or a stub domain connected to a service provider using an alternate backbone service provider from that chosen by that service provider. Provider selection schemes are not usually specified in the context of you, the individual specifying providers, but you, the sysadmin, or you, the netadmin specifying providers based on politic, financial, or other considerations. There are a few internet-drafts on provider selection in the internet drafts directory. There should be one on sdr route construction coming along soon (plug :-) that also talks about provider selection among other things. Kannan From owner-Big-Internet@munnari.OZ.AU Mon Jul 4 15:51:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05702; Mon, 4 Jul 1994 13:40:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA29808; Mon, 4 Jul 1994 13:39:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA29794; Mon, 4 Jul 1994 13:24:41 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00912; Mon, 4 Jul 1994 11:24:57 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11728; Sun, 3 Jul 94 19:24:37 MDT Received: from [130.57.64.146] by WC.Novell.COM (4.1/SMI-4.1) id AA14105; Sun, 3 Jul 94 18:20:42 PDT Date: Sun, 3 Jul 94 18:20:39 PDT Message-Id: <9407040120.AA14105@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Masataka Ohta From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU Masataka, >I hate people who believes DNS can solve all the mapping problems. Yeah, me too... :-) >> WHAT IS AN EID USED FOR? >As a fixed length ID of a node. You want a fixed length ID of a node? Fine, an IPv4 address (for example) is a fixed length ID of a node. An IPng address will, presumably, be a fixed length address (or, at least, embeddable in a fixed length address) for a node. >> What are the uses of an EID? >For example, EID combined with flow ID is useful to identify a flow >on intermediate routers. IPv4 and/or IPng addresses should do just *fine* here, too. >> WHAT ARE THE CONSEQUENCES OF A DUPLICATE EID? >Same as that caused by duplicated domain name. This sounds good, but i think if you think about it, you will see it doesn't make a whole lot of sense. Today, a *host* never *asserts* a domain name for itself. DNS does that. So, today a "duplicate domain name" can't happen except by a screwup in the administrative hierarchy of DNS. If *i* am foo.wc.novell.com, and sometimes DNS tells *you* that George over there is foo.wc.novell.com, then either my DNS messed up, some ancestor of my DNS messed up, your DNS messed up, or some ancestor of your DNS messed up. With EIDs, *anyone* can claim to be that EID. In some sense the logic of what you are saying is that everytime a node sees an EID, it should do a gethostbyEID(). Yes, you could do that. (Though it somewhat violates this fundamental principal that Dave Clark keeps saying was key to the architecture of IPv4: two nodes, without any third node around, should be able to talk. Yes, one side could have the user enter "telnet 1:2:4:8:8:9:1:2::82:33:88:32" - *that* would work; but what does the *receiving* side do if there is no DNS to ask about the EID 82.33.88.32?) >Both hostname and EID share the same difficulty to monitor and manage >though EID is a little more easier and a lot more efficient to handle. Hostname has not been fundamental to the internet layer of the architecture. (Though, with the number of FTP servers which refuse to serve any IPv4 address for which gethostbyaddr() doesn't work, one might not notice!) What has been fundamental has been the routing system. I tend to think we should continue to rely on that at the internet layer. Greg Minshall ps - Peter Ford made a very good observation last weekend, obvious i'm sure to everyone but me: there are three key components to "our" infrastructure in the internet - DNS, the routing system, and the address assignment structure. From owner-Big-Internet@munnari.OZ.AU Mon Jul 4 15:56:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07276; Mon, 4 Jul 1994 14:20:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA29870; Mon, 4 Jul 1994 14:19:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA29867; Mon, 4 Jul 1994 14:16:18 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04216; Mon, 4 Jul 1994 12:58:32 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 4 Jul 94 11:51:31 +0900 From: Masataka Ohta Message-Id: <9407040251.AA28905@necom830.cc.titech.ac.jp> Subject: Re: Location Independent Routing in the Next Generation IP? To: avg@sprint.net (Vadim Antonov) Date: Mon, 4 Jul 94 11:51:28 JST Cc: avg@sprint.net, Big-Internet@munnari.OZ.AU, PAUL@TDR.COM, ietf@cnri.reston.va.us, namedroppers@rs.internic.net, zben@ni.umd.edu In-Reply-To: <199407031937.PAA02046@titan.sprintlink.net>; from "Vadim Antonov" at Jul 3, 94 3:37 pm X-Mailer: ELM [version 2.3 PL11] > >You can't solve mobility that way. > > >Dynamic address allocation (and/or dynamic DNS with IXFR and NOTIFY) may > >give the up-to-date address at the time of the query. > > >But you can't expect them to predict future changes of the address. > > Who told that dynamic addressing assumes name-address lookup > only at the time of opening a connection? No, I don't assume connection. > Applications should NEVER deal with addresses -- only with > names. Since *sessions* aren't stateless it is easy to notify > all peers about change in the address. I don't mind if you do so. The problem is that dynamic address allocation nor dynamic DNS has nothing to do with it. > (Nobody needs to predict future changes of addresses -- it is > enough to discover changes after they happened With communication errors, that's one of the hardest part. Moreover, the difficulty has nothing to do with dynamic address allocation nor dynamic DNS. > and to allow > coexistance of both addresses for some transitional time for > the real-time applications). If you assume we can have coexistance period, there is no reason to limit it transitional time and all the issue does not exist from the beginninng. So, dynamic address allocation is not a solution for mobility. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 4 16:07:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07313; Mon, 4 Jul 1994 14:21:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA29887; Mon, 4 Jul 1994 14:21:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA29851; Mon, 4 Jul 1994 14:00:02 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06669; Mon, 4 Jul 1994 13:59:51 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 4 Jul 94 12:53:03 +0900 From: Masataka Ohta Message-Id: <9407040353.AA29041@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request To: Greg_Minshall@Novell.COM (Greg Minshall) Date: Mon, 4 Jul 94 12:53:02 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407040120.AA14105@WC.Novell.COM>; from "Greg Minshall" at Jul 3, 94 6:20 pm X-Mailer: ELM [version 2.3 PL11] > >> WHAT IS AN EID USED FOR? > > >As a fixed length ID of a node. > > You want a fixed length ID of a node? Fine, an IPv4 address (for example) > is a fixed length ID of a node. An IPng address will, presumably, be a > fixed length address That's fine. > (or, at least, embeddable in a fixed length address) > for a node. That's nothing. Anything in IP header is embedddable in a fixed length something which is as large as maximum header size. I rather prefer domain names, which is already assured to be embeddable in a fixed length (256 bytes) quantity, than other forms of variable length IDs. > >For example, EID combined with flow ID is useful to identify a flow > >on intermediate routers. > > IPv4 and/or IPng addresses should do just *fine* here, too. Of course. Do you mind if I call it EID? > >> WHAT ARE THE CONSEQUENCES OF A DUPLICATE EID? > > >Same as that caused by duplicated domain name. > > This sounds good, but i think if you think about it, you will see it > doesn't make a whole lot of sense. Today, a *host* never *asserts* a > domain name for itself. DNS does that. So, today a "duplicate domain > name" can't happen except by a screwup in the administrative hierarchy of > DNS. If *i* am foo.wc.novell.com, and sometimes DNS tells *you* that > George over there is foo.wc.novell.com, then either my DNS messed up, some > ancestor of my DNS messed up, your DNS messed up, or some ancestor of your > DNS messed up. Tomorrow, we'll have autoconfiguration and secure DNS. A host can assert anything. But the assetion won't be heard by anyone if not accompanied with authentication information using host's private secret information. > With EIDs, *anyone* can claim to be that EID. In some sense the logic of > what you are saying is that everytime a node sees an EID, it should do a > gethostbyEID(). Yes, you could do that. (Though it somewhat violates this > fundamental principal that Dave Clark keeps saying was key to the > architecture of IPv4: two nodes, without any third node around, should be > able to talk. To run DNS, you only need a single host. So, two is already enough and there is no reason for the third. > Yes, one side could have the user enter "telnet > 1:2:4:8:8:9:1:2::82:33:88:32" - *that* would work; but what does the > *receiving* side do if there is no DNS to ask about the EID 82.33.88.32?) No, after dentist's autoconfiguration which may be valunerale to snooping or active attacks from outside which is not the case with two hosts isolated from the outside, I just want to type "telnet hostname" through autoconfigured DNS servers. We should also have a little more robust autoconfiguration for semi-professionals, of course. > >Both hostname and EID share the same difficulty to monitor and manage > >though EID is a little more easier and a lot more efficient to handle. > > Hostname has not been fundamental to the internet layer of the > architecture. Domainname is not fundamental to the internetwork layer of the architecture. Hostname, a domainname with A records, is tied to the internetwork layer of the architecture through DNS. IPv4 address is fundamental to the internetwork layer of the architecture because it is included in the internetwork layer header. The reason is that IPv4 address in header is a little more easier and a lot more efficient to handle than hostname and locator in header. > What has been fundamental has been the routing system. I tend to think we > should continue to rely on that at the internet layer. Then, we should talk about the locator aspect of IPv4 addresses. Variable length locator such as routing header of 64 bit SIPP or any other source routing scheme is OK, but I don't think locator's must be of variable length. I only think that pure locator information needs at least 64 bits in the far future. So, for example, if 64 bit SIPP address acts as EID, upper 32 bit of SIPP address acts as lowest level locator segment for the time being and SIPP routing header will be added in the future as supplimental locator segments, it will be just fine. NSAP with source routing, though inefficient, may also be fine. > ps - Peter Ford made a very good observation last weekend, obvious i'm sure > to everyone but me: there are three key components to "our" infrastructure > in the internet - DNS, the routing system, and the address assignment > structure. If you assume DNS, "address assignment structure" is almost automatically determined so that you don't have to worry so much. On the other hand, I'm afraid you miss security. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 5 01:18:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28086; Tue, 5 Jul 1994 00:20:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA00781; Tue, 5 Jul 1994 00:19:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA00762; Tue, 5 Jul 1994 00:10:09 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24131; Mon, 4 Jul 1994 22:36:06 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwxcc15456; Mon, 4 Jul 1994 08:35:59 -0400 Message-Id: To: Paul Robinson Cc: Charles B Cranston , On the Growth of the Internet , IETF List , Namedroppers Subject: Re: Location Independent Routing in the Next Generation IP? In-Reply-To: Your message of "Sat, 02 Jul 1994 17:08:42 EDT." <01.1994Jul02.16h25m27s.PAUL-0100000@TDR.COM> Date: Mon, 04 Jul 1994 08:35:59 -0400 From: "Mike O'Dell" Please note that 800 numbers are not really "routed" in any fashion at all, except for service determination puprposes. When you dial an 800 number, the local switch sends a request off to it's nearest "Service Control Point" presenting the 800 number for translation. The SCP returns a regular 10 digit phone number with a regular area code and an indication that the call is to be a "collect" call (as we say here the States for "recipient pays"). The remainder of the phone network knows nothing about 800 calls - it just processes a collect call, and arrangements are made at the recipient end to automagically say "yes" to the "collect call" request instead of vectoring to a local area operator for verification. Yes, the database contains an entry for each number - it is essentially purely flat-routed. and it works reasonably well. More details: This picture is an oversimplification and is where the real "routing" comes in as far as 800 service is concerned - there is actually a state machine stored in the database. this state machine allows calls made early morning east-coast time to be routed to an east coast service center, and then as the rest of the country wakes up, the calls can be switched to another service center. Or having a skeleton center on weekends and an east coast and west coast center during weekday business hours, etc. The things that can be done with this machinery are pretty amazing. ANd it is technically feasible to flat-route the entire north american numbering plan, which they may do eventually for PCS mobility, but not any time very soon. And no, you can't do this with internet addresses.... -Mike O'Dell From owner-Big-Internet@munnari.OZ.AU Tue Jul 5 01:18:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29298; Tue, 5 Jul 1994 01:00:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA00977; Tue, 5 Jul 1994 00:59:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA00939; Tue, 5 Jul 1994 00:40:43 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28719; Tue, 5 Jul 1994 00:40:34 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA15164; Mon, 4 Jul 1994 16:41:16 +0200 Message-Id: <199407041441.AA15164@mitsou.inria.fr> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: barney@databus.com, big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of "Wed, 29 Jun 1994 22:48:29 EDT." <9406300248.AA15618@ginger.lcs.mit.edu> Date: Mon, 04 Jul 1994 16:41:15 +0200 From: Christian Huitema => But Noel clearly took it to mean is the EID = Locator? => => Well, Noel took the question to mean "why not stick the TLN inside the => transport layer, and hide it totally from the internetworking layer", => actually. To which I why say, yes, precisely. Using EIDs instead of addresses means that one has to revisit TCP. If one revisit TCP, there are 2 items one may want to do: * insert some security, e.g. draw some "session key" during the initial synchronization. * revisit the way connections are identified. Note that the "session key" business can be either zero-knowledge (but that is weak) or tied to an authentication procedure. But authentication procedure most likely use high level names - one authenticate users, not machines. In which case the "ID" has to be something like a PEM/X.509 name, or a secured "domain" name, or maybe a bilateral convention a la PGP. EID are not useful there. If the initial exchanges draws a session key, it can also draw a pair of "local IDs", i.e. using the "your-ref/my-ref" strategy. Or it can use "channel IDs" in the case of multipoint groups. Or whatever. But there is no proof that EID would be useful. => => I vote for TCPname = EID+port and EID != Locator (and not a subset either). => => In case it's not clear, this is what I like too. => => Noel This is only an approximation. In fact, today, TCP is "address+port". In the long run, it will have to be some secure identification. An intermediate layer of naming between IP and today's TCP is not going to bring much services... Christian Huitema From owner-Big-Internet@munnari.OZ.AU Tue Jul 5 06:18:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08070; Tue, 5 Jul 1994 05:20:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA01275; Tue, 5 Jul 1994 05:20:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA01270; Tue, 5 Jul 1994 05:12:38 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04250; Tue, 5 Jul 1994 03:25:14 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18201; Mon, 4 Jul 94 11:24:52 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB14988; Mon, 4 Jul 94 10:20:54 PDT Date: Mon, 4 Jul 94 10:20:54 PDT Message-Id: <9407041720.AB14988@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Richard Carlson" From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU Richard, [>Be glad to. The discussion is on the features I want for the next version >of the Internet protocol suite (TCP/IPng). I used the term "must" to indicate >my preference in how this suite should be developed and deployed. A reasonable definition of "must".] >You are correct that the identifier and topological names can be combined >into a single name (i.e. IPv4 address). However, I think that the current >problems in growth are aggravated by having only a single name. I see the >transition from IPv4 to IPng as a long and painfull struggle. By having a >single name, we guarantee that we will revisit all the current problems when >(not if) we move from IPng to IPngng (IP3g?). Yes I say when, because I >don't think we can crooectly predict how the Internet will change in the >next 10 years. I think seperate names are the best way to hedge our bets >and design something that will allow for future growth. I don't see how, in *practice* the "current problems in growth are aggravated by having only a single name", at least not to any significant degree. We have a an address space problem with our current "locator == id" (IPv4 address), as well as some strain on the routing system. If we today had separate locators and ids, then we might well have address space problems with either or both of these. The strain on the routing system seems to me independent of the separation. If there is ever a need for an IPds9, it will be for one of two general reasons, i suspect: things in the IPng header which don't scale past a certain point (address space exhaustion, TTL exhaustion, not enough "flows" supported in the header, maximum datagram size not large enough, etc., etc.), and/or new features (facilities) which can only be exploited by "universal" adoption of a new packet format and new procedures at end nodes and routers. I don't think we can say a priori that separating locators from identifiers will ameliorate either of these two reasons. Greg Minshall From owner-Big-Internet@munnari.OZ.AU Tue Jul 5 06:20:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10041; Tue, 5 Jul 1994 06:20:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA01340; Tue, 5 Jul 1994 06:20:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA01337; Tue, 5 Jul 1994 06:17:33 +1000 Precedence: list From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09114; Tue, 5 Jul 1994 05:52:59 +1000 (from jcjones@MIT.EDU) Received: from W20-575-15.MIT.EDU by MIT.EDU with SMTP id AB15135; Mon, 4 Jul 94 15:52:53 EDT Received: by w20-575-15.MIT.EDU (5.0/4.7) id AA16845; Mon, 4 Jul 94 15:52:52 EDT Message-Id: <9407041952.AA16845@w20-575-15.MIT.EDU> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: Big-Internet@munnari.OZ.AU Subject: Source Routing & Provider Selection Date: Mon, 04 Jul 94 15:52:51 EDT Content-Length: 519 > Source routing is the placing of a series of addresses in the > header of a packet that defines the path that the packet should follow > through the network. This can be done for security reasons and > to support mobility. Suppose that security and mobility could be solved through some other mechanism. Are there any other reasons why IPng needs source routing? Is it more desirable to have fixed-length packet headers or source routing functionality? (I'm assuming that one precludes the other.) -J.C. Jones- From owner-Big-Internet@munnari.OZ.AU Tue Jul 5 12:11:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15904; Tue, 5 Jul 1994 09:40:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA01521; Tue, 5 Jul 1994 09:40:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA01514; Tue, 5 Jul 1994 09:25:06 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12644; Tue, 5 Jul 1994 07:55:37 +1000 (from sob@hsdndev.harvard.edu) Date: Mon, 4 Jul 94 17:55:31 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407042155.AA06421@hsdndev.harvard.edu> To: jcjones@MIT.EDU Subject: Re: Source Routing & Provider Selection Cc: Big-Internet@munnari.OZ.AU one way of doing provider selection is through the use of source routing. there may be other reasons that it will be hard to do fixed length headers. There are other optional functions such as authentication that may be done using options that change the length of what would be seen as the packet header. Scott From owner-Big-Internet@munnari.OZ.AU Tue Jul 5 18:05:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02010; Tue, 5 Jul 1994 17:00:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01935; Tue, 5 Jul 1994 17:00:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01919; Tue, 5 Jul 1994 16:46:52 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01478; Tue, 5 Jul 1994 16:46:47 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA26729; Mon, 4 Jul 1994 23:46:27 -0700 Date: Mon, 4 Jul 1994 23:46:27 -0700 From: Tony Li Message-Id: <199407050646.XAA26729@lager.cisco.com> To: jcjones@mit.edu Cc: Big-Internet@munnari.OZ.AU Subject: Source Routing & Provider Selection Suppose that security and mobility could be solved through some other mechanism. Are there any other reasons why IPng needs source routing? General policy routing seems to require some mechanism for routing other than conventional hop-by-hop routing. Source routing is one mechanism for specifying your routing policy. Yes, we're pretty sure that you can invent another mechanism... Is it more desirable to have fixed-length packet headers or source routing functionality? (I'm assuming that one precludes the other.) Bad assumption. It's not clear that the source route must be in the packet header. If you use SDRP, for example, you get a source routed tunnel where the source routing information is contained in the tunnelling encapsulation but not in the internetwork layer header itself. Tony From owner-Big-Internet@munnari.OZ.AU Tue Jul 5 20:00:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08452; Tue, 5 Jul 1994 20:00:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA02119; Tue, 5 Jul 1994 20:00:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA02085; Tue, 5 Jul 1994 19:51:44 +1000 Precedence: list Received: from sundance.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07583; Tue, 5 Jul 1994 19:38:16 +1000 (from atkinson@sundance.itd.nrl.navy.mil) To: bsimpson@MorningStar.Com Subject: Re: Mobility, Security and DNS In-Reply-To: <1220.bill.simpson@um.cc.umich.edu> Organization: Naval Research Laboratory, DC Cc: big-Internet@munnari.OZ.AU Date: Tue, 5 Jul 94 10:37:30 GMT From: Ran Atkinson Sender: atkinson@sundance.itd.nrl.navy.mil Message-Id: <9407051037.aa12892@sundance.itd.nrl.navy.mil> In article <1220.bill.simpson@um.cc.umich.edu> Bill Simpson wrote: >Mobility has been interjected here in regard to locators and identifiers. >Mobility will require security, but only between the Home Agent, and the >Mobile Node. Any correspondent may have its own security relationship >with the Mobile Node, which is not required for mobility or locators. >That security relationship can be used by the Mobile Node to update such >correspondents at the same time it updates its Home Agent. Bill, Please avoid use of the word "security" when you really mean "authentication" or "confidentiality" or "integrity". The word "security" is ambiguous in many contexts and clarity is important. The HA and the MN require _authentication_ of Mobile IP Registration Protocol packets in order to work properly. They don't necessarily require confidentiality. By contrast, a Mobile Node and its Correspondent Host should be able to just use ordinary IP-layer security mechanisms (e.g. the not yet specified IPv4 Security Protocol, swIPe, SP3) for any needed security. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 02:48:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19456; Wed, 6 Jul 1994 01:21:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02500; Wed, 6 Jul 1994 01:20:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02493; Wed, 6 Jul 1994 01:13:14 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19065; Wed, 6 Jul 1994 01:13:09 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA27383; Tue, 5 Jul 94 09:12:48 MDT Received: from [130.57.64.146] by WC.Novell.COM (4.1/SMI-4.1) id AA16406; Tue, 5 Jul 94 08:08:45 PDT Date: Tue, 5 Jul 94 08:08:43 PDT Message-Id: <9407051508.AA16406@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Dave Bridgham From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU Dave, >Because IPv4 addresses are also addresses (aka locators), you have to >change your address when you move. This is not a good quality in an >EID. *One* model is that when you move, you prepend some glop in front of your IPv4/ng address. So, you keep your identifier, and add some locator stuff in front. And, in a very useful way, you can "always" toss the glop, and just route to the IPv4/ng address (albeit, sub-optimally). Greg From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 02:48:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19598; Wed, 6 Jul 1994 01:25:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02566; Wed, 6 Jul 1994 01:25:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02479; Wed, 6 Jul 1994 01:03:32 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18714; Wed, 6 Jul 1994 01:03:27 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: Greg_Minshall@Novell.COM Cc: big-internet@munnari.OZ.AU In-Reply-To: Greg Minshall's message of Sun, 3 Jul 94 18:20:39 PDT <9407040120.AA14105@WC.Novell.COM> Subject: IPng ADs request Date: Tue, 5 Jul 94 11:02:11 -0400 Message-Id: <9407051102.aa24031@quern.epilogue.com> Date: Sun, 3 Jul 94 18:20:39 PDT From: Greg Minshall >> WHAT IS AN EID USED FOR? >As a fixed length ID of a node. You want a fixed length ID of a node? Fine, an IPv4 address (for example) is a fixed length ID of a node. An IPng address will, presumably, be a fixed length address (or, at least, embeddable in a fixed length address) for a node. Because IPv4 addresses are also addresses (aka locators), you have to change your address when you move. This is not a good quality in an EID. >> What are the uses of an EID? >For example, EID combined with flow ID is useful to identify a flow >on intermediate routers. IPv4 and/or IPng addresses should do just *fine* here, too. Until you move and change your address. Though I suppose if you move you want that flow taken down anyway. But maybe not until after you've told everyone about your new location. Dave From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 03:40:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24914; Wed, 6 Jul 1994 03:40:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02755; Wed, 6 Jul 1994 03:40:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02729; Wed, 6 Jul 1994 03:28:34 +1000 Precedence: list Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24468; Wed, 6 Jul 1994 03:28:18 +1000 (from kre) Date: Wed, 6 Jul 1994 03:28:18 +1000 From: Robert Elz Message-Id: <9407051728.24468@munnari.oz.au> To: Greg_Minshall@Novell.COM, dab@epilogue.com Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU Date: Tue, 5 Jul 94 08:08:43 PDT Message-Id: <9407051508.AA16406@WC.Novell.COM> From: Greg Minshall *One* model is that when you move, you prepend some glop in front of your IPv4/ng address. So, you keep your identifier, ... What happens if the address you used to have is then reallocated to some other node? True, this may not happen often with traditional mobility, but some of us see mobility as simply an example of locator change, which can also happen due to net renumbering - after a net is renumbered its entirely possible, even likely, that the old numbers will be allocated elsewhere. kre From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 04:00:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25840; Wed, 6 Jul 1994 04:00:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA02792; Wed, 6 Jul 1994 04:00:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02787; Wed, 6 Jul 1994 03:58:42 +1000 Precedence: list Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23805; Wed, 6 Jul 1994 03:13:28 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA04568 for big-internet@munnari.oz.au; Tue, 5 Jul 94 13:11:20 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA00804; Tue, 5 Jul 1994 10:11:12 -0700 Message-Id: <199407051711.KAA00804@aland.bbn.com> To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, sob@hsdndev.harvard.edu Subject: Re: IPng ADs request From: Craig Partridge Date: Tue, 05 Jul 94 10:11:09 -0700 Sender: craig@aland.bbn.com > A question much like this one went to the SIPP list last week .. > One thing that seems to have been missing in the recent extensive > discussions about address size options is a understanding of whether the > transport level 'name' should be the same as the internetwork level > 'name' > > I'm quite surprised this didn't generate more comment, since it seems (to me > at least) to be a fairly crucial point. It didn't generate more comment on the SIPP list because Christian Huitema had a wonderfully insightful comment that (I think) convinced that list that the Internet names in the Transport name should be the same as that used by the Internet level (at least for the time being). Craig From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 04:49:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24143; Wed, 6 Jul 1994 03:20:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02699; Wed, 6 Jul 1994 03:20:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02694; Wed, 6 Jul 1994 03:10:24 +1000 Precedence: list Received: from access1.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18350; Wed, 6 Jul 1994 00:49:57 +1000 (from tdarcos@access.digex.net) Received: by access1.digex.net id AA06558 (5.67b8/IDA-1.5 for big-internet@munnari.oz.au); Tue, 5 Jul 1994 10:49:50 -0400 Newsgroups: tdr.paul.private.mail Date: Tue, 5 Jul 1994 10:49:50 -0400 (EDT) From: Paul Robinson Sender: Paul Robinson Reply-To: Paul Robinson Subject: Re: IP in Cars [was Re: Why variable length?] To: Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU Message-Id: <01.1994Jul05.10h30m49s.PAUL-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- Bob.Hinden@eng.sun.com writes in , as follows: > Bob, > > > This info is from our electrical people that are designing the > > components. USCar is a research group under the American Automotive > > Manufacturer's Association (AAMA). My influence is with the > > Automotive Industry Action Group (AIAG). I've been told that even > > IPv4 is viewed as too expensive per component. > > Any data on why they think it is too expensive? It would be good > to understand this. Bob Moskowitz <0003858921@MCIMAIL.COM> subscribes to this list (When I get this list on MCI Mail, his name appears after my account), so he can probably confirm some of this since he works for Chrysler. If you take a look at Arthur Hailey's "Wheels", a story of the automotive industry, (and this was back in the 1960s but I suppose the cost differences aren't that significant), there was concern about ways to shave even 25c off the cost of a car, for the simple fact is that 25c on 100,000 cars is $25,000. Today those numbers are probably somewhat higher but still, every dollar saved on an automobile means extra profit to the company. If they can buy something proprietary that costs $1 per car, they are probably more likely to buy it than something using an open standard that costs $1.50. And, if the method means they can require people to buy something from them instead of being able to use third-party products, then they would probably use a $1.50 proprietary item over a $1 open standard. Now if the proprietary item costs $3 and the open one 50c, then there is a cost benefit as to whether using a proprietary one is going to return enough in either off-warranty parts orders or customer purchases to justify the difference. If the open standard is 50c and the lifetime exceeds the expected lifetime of the car or would not generate new revenue, the saving of $2.50 per car justifies using the open standard. So the fact is that unless a component is relatively inexpensive or gives them a market advantage which exceeds the cost of the item, an automotive manufacturer is not going to put it in unless mandated by law upon all automobile manufacturers. Also, I think the delay is something like 3 years between a car's design and the finished product reaching the dealer's showroom. --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: Maybe Computer Science should be in the College of Theology. -- R. S. Barton From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 04:49:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26070; Wed, 6 Jul 1994 04:04:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA02812; Wed, 6 Jul 1994 04:04:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02784; Wed, 6 Jul 1994 03:57:06 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23402; Wed, 6 Jul 1994 03:02:35 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA19626; Tue, 5 Jul 1994 19:03:07 +0200 Message-Id: <199407051703.AA19626@mitsou.inria.fr> To: Dave Bridgham Cc: Greg_Minshall@Novell.COM, big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of "Tue, 05 Jul 1994 11:02:11 EDT." <9407051102.aa24031@quern.epilogue.com> Date: Tue, 05 Jul 1994 19:03:06 +0200 From: Christian Huitema Dave, => Because IPv4 addresses are also addresses (aka locators), you have to => change your address when you move. This is not a good quality in an => EID. The question really is what you own and what you use. If there is an address that you "own", then you can use it for a lot of reasons, including as an EID. Which means that you have to own it for long enough - longer that the purported use of EIDs, i.e. longer than the max duration of your TCP connections. That you need to wrap it inside another header means you cannot use it for "routing". It does not mean you cannot use it "at all" - as long as you own it. Now, who owns what and for how long is another interesting debate. Alternatives could only be compared if they were entirely defined... Christian Huitema From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 07:20:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02831; Wed, 6 Jul 1994 07:20:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03034; Wed, 6 Jul 1994 07:20:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA03025; Wed, 6 Jul 1994 07:13:24 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02594; Wed, 6 Jul 1994 07:13:20 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA01455; Tue, 5 Jul 94 15:12:54 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB17822; Tue, 5 Jul 94 14:08:56 PDT Date: Tue, 5 Jul 94 14:08:56 PDT Message-Id: <9407052108.AB17822@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Masataka Ohta From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU Masataka, [>That's nothing. Anything in IP header is embedddable in a fixed length >something which is as large as maximum header size. Aw, shucks!] >Tomorrow, we'll have autoconfiguration and secure DNS. >A host can assert anything. But the assetion won't be heard by anyone >if not accompanied with authentication information using host's >private secret information. I don't think you've yet sat down and thought about my point. With EIDs, the assertion is being made between host A and host B. With DNS ("autoregistration", i assume), host A asserts something to server B. With EIDs, the assertions are being made at a very high rate. With DNS, the rate is fairly low. So, the ability to do autoregistration in DNS, in a "secure" way, really says nothing about our ability to protect EIDs from impersonation. >Hostname, a domainname with A records, is tied to the internetwork layer >of the architecture through DNS. For better or worse, i can *now* send a packet from host A to host B without knowing anything about DNS. >On the other hand, I'm afraid you miss security. Today, there isn't any (so, go buy Bellovin and Cheswick's book... :-). Greg From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 07:24:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02892; Wed, 6 Jul 1994 07:24:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03049; Wed, 6 Jul 1994 07:24:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA03022; Wed, 6 Jul 1994 07:12:45 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02576; Wed, 6 Jul 1994 07:12:39 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA01403; Tue, 5 Jul 94 15:12:12 MDT Received: from [130.57.64.152] by WC.Novell.COM (4.1/SMI-4.1) id AA17822; Tue, 5 Jul 94 14:08:14 PDT Date: Tue, 5 Jul 94 14:08:09 PDT Message-Id: <9407052108.AA17822@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Elz From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU kre, >What happens if the address you used to have is then reallocated to some >other node? True, this may not happen often with traditional mobility, >but some of us see mobility as simply an example of locator change, which >can also happen due to net renumbering - after a net is renumbered its >entirely possible, even likely, that the old numbers will be allocated >elsewhere. Good question. One of the real problems *i* have with my own positions is that mobility, in the way i "define" it, conflicts with stateless autoconfiguration. If mobility is *the* way of the future, then we are back to square one in our configuration nightmares (well, nightmares for me, anyway). This bothers me muchly, but *i* don't know how to reconcile the two issues right now. (I *tend* to think the answer here is in gethostbyname() - i.e., the user will know his/her *domain* name, or maybe a user name stored in DNS, and *that* will be used to produce the locator==id.) However, there is at least one issue specifically wrt your question. One is, given a host which has a bad locator==id (now assigned to someone else) configured into it, how badly does what in the big internet break? Maybe not so much. If hosts initiate a conversation by sending to the locator==id address, or by querying some other database which can only be updated with some authentication, then packets will flow in the direction of the new, current, owner of the address (and, assuming DNS *was* updated, TTLs expired, etc., then this will be the desired behaviour). And, the "mobile" host should find out fairly quickly that it is using an out-of-date address when it tries to register its current address with the database (home agent, whatever). If hosts *verify* the asserted "current location" of a host (asserted in an incoming connection request) based on some authentication scheme like the above, or based on some local knowledge of the host, things don't break too badly. So, i think a) things don't break too badly, and b) the bogus state is flushed from the network rather promptly. Does this *help*? Am i not seeing the holes for the puddles? Greg From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 09:16:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02381; Wed, 6 Jul 1994 07:00:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA02995; Wed, 6 Jul 1994 07:00:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02979; Wed, 6 Jul 1994 06:49:33 +1000 Precedence: list From: smb@research.att.com Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27696; Wed, 6 Jul 1994 04:49:18 +1000 (from smb@research.att.com) Message-Id: <9407051849.27696@munnari.oz.au> Received: by bigbird.zoo.att.com; Tue Jul 5 14:46:49 EDT 1994 To: "Jeffrey I. Schiller" Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Date: Tue, 05 Jul 94 14:46:47 EDT Let me throw a random thought in here. I apologize for joining this conversation a little late. I have read a few messages that imply that providing for a globally unique EID would be an administrative headache (you would have to have blocks of EID address space delegated to agencies who would then allocate individual EIDs etc.). However if EIDs are at least 128 bits, then this isn't necessarily the case. They can be chosen at random (assuming good randomness) with little probability of collision. My favorite approach to doing this is to have each end point generate a public/private key pair. An end point's EID can then be the MD5 hash of its public key. Not only does this provide for a unique EID, but it also provides a neat way to tie an entities public key to its EID. Jeff, Scott Bradner (I think) mentioned this idea at the Big 10 retreat. I've given it a lot of thought since then, and I don't think it buys us much except as a way to provide a very random number. First, of course, we need to decide what an EID is, and what it's for. The consensus -- or at least a lot of the recent messages -- indicate that it's a TLN, a transport-level name. (At least, I *think* that's what TLN is...) That'a concept that works well with mobility, where the network-level address is simply a locator -- and for mobile hosts, if you move, you just tell your communicants your new location, and let the routing protocols find you. Connections will persist, because the EID is constant. But since the locator has no relation to *who* you are, it can't be used to look up a name (and thus an organization, a public key, a certificate, etc.). We therefore have to do that based on EID -- and a random number is no good for lookups. Some other hook for the ``name''? Where? In the TCPng SYN packet? What about UDP? Security? There's no benefit to tying an EID to a public key from that perspective. Public keys are just that -- public -- and anyone who wants to impersonate a host can retrieve its key quite easily. And since we're talking about a hash, rather than a key itself, it can't be used directly for authentication. In short, I don't see what this scheme buys us. You'd still need the structured address-to-name databases, and if you have them, why add one more random number? If you perceive the need for one anyway, your idea is as good as any I've heard as a suggestion for how to generate the appropriate value, and I wouldn't mind an informational RFC to that effect -- but there doesn't seem to be any benefit to mandating this procedure. From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 12:03:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07479; Wed, 6 Jul 1994 09:40:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03228; Wed, 6 Jul 1994 09:40:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03193; Wed, 6 Jul 1994 09:22:06 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04386; Wed, 6 Jul 1994 08:10:45 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA28494; Tue, 5 Jul 94 17:10:31 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:big-internet@munnari.oz.au id AA09512; Tue, 5 Jul 94 17:10:29 -0500 Date: Tue, 5 Jul 94 17:10:29 -0500 Message-Id: <9407052210.AA09512@benedick.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs From: "Richard Carlson" From: Masataka Ohta >> First, assume that a TLN is an EID, protocol, and port. >> >> This wasn't what I had in mind when I started using the TLN acronym, but... >> There are three things we can name: In my mind you just set TLN = socket. Did you really mean to do this? >> - the entire endpoint, including all the protocols inside it (i.e. the >> demultiplexing point where you look at the "proto" field in the internetwork >> header - sort of like what a NET in ISOese names) > >Such a entity precisely belongs to the internetwork layer (or, with ISO >terminology, network layer). > >So, don't call it "transport". But "transport" is exactly where entity identification belongs. The internetwork layer should control the routing of data between nodes. These are 2 distinct functions, that are currently being handled by the IPv4 address. What we need is to separate the identification and location functions and develope a dynamic mapping routine to link them together (much like ARP maps IPv4 -> MAC). Why should users or applications care about the IPv4 address? I mean, what benefits do you get by using the address instead of the Domain Name (FCDN's)? My users want to be able to communicate with others in a timely and efficent manner. They don't care if the data goes over Ethernet, FDDI, T1 links or carrier pigeon. As long as it's fast (< 1 second response time for interactive work). If they don't care about the physical media, why should they care about the internetwork layer. I contend that with IPv4, users are _forced_ to care. Not only about addresses but netmasks, default/dynanic/static routes and everything else going on there. By breaking identification and location into 2 separate functions and dynamically mapping between them, a user will be able to ignore all these internetworking issues. This is one reason I think we should separate them. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 12:08:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06710; Wed, 6 Jul 1994 09:20:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03185; Wed, 6 Jul 1994 09:20:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03180; Wed, 6 Jul 1994 09:12:53 +1000 Precedence: list Received: from BIG-SCREW.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01284; Wed, 6 Jul 1994 06:28:45 +1000 (from jis@mit.edu) Received: by big-screw id AA22582; Tue, 5 Jul 94 16:28:23 -0400 Date: Tue, 5 Jul 94 16:28:23 -0400 Message-Id: <9407052028.AA22582@big-screw> From: "Jeffrey I. Schiller" Sender: jis@mit.edu To: smb@research.att.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407051849.AA26364@MIT.EDU> (smb@research.att.com) Subject: Re: IPng ADs request From: smb@research.att.com Cc: big-internet@munnari.oz.au Date: Tue, 05 Jul 94 14:46:47 EDT First, of course, we need to decide what an EID is, and what it's for. The consensus -- or at least a lot of the recent messages -- indicate that it's a TLN, a transport-level name. (At least, I *think* that's what TLN is...) That'a concept that works well with mobility, where the network-level address is simply a locator -- and for mobile hosts, if you move, you just tell your communicants your new location, and let the routing protocols find you. Connections will persist, because the EID is constant. But since the locator has no relation to *who* you are, it can't be used to look up a name (and thus an organization, a public key, a certificate, etc.). We therefore have to do that based on EID -- and a random number is no good for lookups. I guess this all depends on what you use the EID for. Certainly when I establish a connection to a remote host I will have to lookup its EID in the DNS, and I can get its public key while I am at it. However there are transactions where I may care about knowing that a particular bit pattern originates from a particular EID, but I don't need to know the name associated with the EID. Consider the following hypothetical mobile host protocol: Each mobile host is registered in the DNS with its NAME, EID and PUBLIC KEY. When a mobile host "comes up" in some locale it requests and is assigned a locator address. It then registers this locator with some NAME/EID->locator mapping service (maybe the DNS, maybe something more dynamic and/or different). This registration transaction is authenticated because you sign it with the EID's private key. The transaction itself is: {EID-->Locator}signed by EID, EID, Public Key ==> Reg. Authority. The Registration authority can validate that this transaction did come from the claimed EID directly without having to communicate with any database (trusted or not). Furthermore during an association between two nodes (in this context I use the word "association" to mean one or more open connections) a mobile host on the move can get a new locator address in real-time and send the EID->new locator, mapping directly to the other node. The recipient node can verify that this message did indeed come from the claimed EID because it will be signed (the same way the message to the registration authority is signed). In essence we are using the PUBLIC KEY as the "name" of a system. At least as an identifier that doesn't change (often) with time. The EID is just a way of taking a long and variable length PUBLIC KEY and compressing it down to a manageable fixed length field. Without structure such "names" are of little value if what you want to do is use them as database keys for lookups (as in a DNS lookup). However in situations where the question you ask is "Is this the same entity that I was communicating with earlier?" they can work well. Security? There's no benefit to tying an EID to a public key from that perspective. Public keys are just that -- public -- and anyone who wants to impersonate a host can retrieve its key quite easily. And since we're talking about a hash, rather than a key itself, it can't be used directly for authentication. Ah, but in my scheme(s) whenever you send something where you claim that you are a particular EID, you sign the information with the EID's private key, which only the EID itself will control. In short, I don't see what this scheme buys us. You'd still need the structured address-to-name databases, and if you have them, why add one more random number? Again, it comes down to what the purpose of an EID is and where it comes from. If it is a time invariant "address" (or an "administrative" address) which has structure to it that tells you information about it, then my scheme isn't much use. However if the EID is a unique number without any structure (as you would get if you assigned the first node to be EID "1" and the next "2" and so on) and is expected to be globally unique, then I point out that with 128 bit (or greater) EIDs you do not have a need for a registration authority if they are randomly chosen. I then elaborated to say that if you generate them as hashes of keys you get some of the benefits I mentioned above. -Jeff From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 12:26:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09202; Wed, 6 Jul 1994 10:20:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA03274; Wed, 6 Jul 1994 10:20:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA03258; Wed, 6 Jul 1994 10:09:25 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08652; Wed, 6 Jul 1994 10:09:21 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA29125; Tue, 5 Jul 94 19:09:17 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:big-internet@munnari.oz.au id AA09655; Tue, 5 Jul 94 19:09:15 -0500 Date: Tue, 5 Jul 94 19:09:15 -0500 Message-Id: <9407060009.AA09655@benedick.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request From: "Richard Carlson" From: Greg Minshall Greg; >I don't see how, in *practice* the "current problems in growth are >aggravated by having only a single name", at least not to any significant >degree. We have a an address space problem with our current "locator == >id" (IPv4 address), as well as some strain on the routing system. If we >today had separate locators and ids, then we might well have address space >problems with either or both of these. The strain on the routing system >seems to me independent of the separation. We have an address space problem because the division of IPv4 addresss into classes has proved to be very inefficient. The solution is to change from IPv4 to IPng. All the IPng proposals I have read, will require me to change the IP protocol, _and_ the TCP protocol, _and_ some of the applications (NFS/AFS, FTP, RPC, ...). In my mind this is going to be more than a simple change. Since "growth" forces us to make this transition, I say that a single name is "aggravating" the current problem. If the TCP/IP protocol suite had separate locators and ids, then it would be possible to replace one without affecting the other (i.e. replace IPv4 with IPng and leave TCP alone). You are correct, in saying that we might have space problems with separate names. But I think that as long as both don't occur at the same time, the solution would be easier. Let's take SIPP and IPAE (not to pidk on them, but as a useful example). How much work is going on in SIPP to provide a migration path for IPv4 only hosts? Would SIPP be any easier to implement if no migration was needed? With separate names, you could support multiple IP protocols, meaning that SIPP would be easier to test and deploy. (Yes I realize that this makes TCP more complex, after all "there is no such thing as a free lunch"). The benefit is that SIPP deployment means that only the IP protocol needs to change, not the entire communications stack. I also agree that the routing problems are a separate issue. >If there is ever a need for an IPds9, it will be for one of two general >reasons, i suspect: things in the IPng header which don't scale past a >certain point (address space exhaustion, TTL exhaustion, not enough "flows" >supported in the header, maximum datagram size not large enough, etc., >etc.), and/or new features (facilities) which can only be exploited by >"universal" adoption of a new packet format and new procedures at end nodes >and routers. I don't think we can say a priori that separating locators >from identifiers will ameliorate either of these two reasons. Well I think those are all possible problems. My dispute would be with "If there is ever", I think it's more like "when". Since _I_ feel that it's a forgone conclusion that IPng will need to be replaced at some future date, I'd like to see us at least try and think of how a future migration will work. Maybe 10 years from now I'll be arguing a complety different point (I hope nobody in archiving these notes to throw up in my face then .-), but right now I feel that separate locators and identifers will allow for future growth better than a single entity. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 12:31:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13117; Wed, 6 Jul 1994 12:00:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA03376; Wed, 6 Jul 1994 12:00:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA03371; Wed, 6 Jul 1994 11:56:52 +1000 Precedence: list Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08289; Wed, 6 Jul 1994 09:58:48 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06580 for big-internet@munnari.oz.au; Tue, 5 Jul 94 19:58:37 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id QAA02353; Tue, 5 Jul 1994 16:58:30 -0700 Message-Id: <199407052358.QAA02353@aland.bbn.com> To: "Jeffrey I. Schiller" Cc: smb@research.att.com, big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of Tue, 05 Jul 94 16:28:23 -0400. <9407052028.AA22582@big-screw> From: Craig Partridge Date: Tue, 05 Jul 94 16:58:29 -0700 Sender: craig@aland.bbn.com Jeff: How does your scheme work for multicast (and maybe anycast) EIDs? Craig From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 12:40:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14530; Wed, 6 Jul 1994 12:40:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA03434; Wed, 6 Jul 1994 12:40:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03418; Wed, 6 Jul 1994 12:36:31 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14436; Wed, 6 Jul 1994 12:36:14 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 6 Jul 94 11:28:17 +0900 From: Masataka Ohta Message-Id: <9407060228.AA06729@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request To: jis@mit.edu (Jeffrey I. Schiller) Date: Wed, 6 Jul 94 11:28:16 JST Cc: smb@research.att.com, big-internet@munnari.OZ.AU In-Reply-To: <9407052028.AA22582@big-screw>; from "Jeffrey I. Schiller" at Jul 5, 94 4:28 pm X-Mailer: ELM [version 2.3 PL11] > Furthermore during an association between two nodes (in this context I > use the word "association" to mean one or more open connections) a > mobile host on the move can get a new locator address in real-time and > send the EID->new locator, mapping directly to the other node. The > recipient node can verify that this message did indeed come from the > claimed EID because it will be signed (the same way the message to > the registration authority is signed). If you assume "association", some information for mutual authentication is already exchanged. So, > Without structure such "names" are of little value if what you want to > do is use them as database keys for lookups (as in a DNS lookup). However > in situations where the question you ask is "Is this the same entity that > I was communicating with earlier?" they can work well. the question is not asked again in that form. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 15:12:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14704; Wed, 6 Jul 1994 12:44:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA03449; Wed, 6 Jul 1994 12:44:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03404; Wed, 6 Jul 1994 12:24:25 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10458; Wed, 6 Jul 1994 11:01:42 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 6 Jul 94 09:55:32 +0900 From: Masataka Ohta Message-Id: <9407060055.AA06398@necom830.cc.titech.ac.jp> Subject: Re: Omnibus reply - EIDs To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Date: Wed, 6 Jul 94 9:55:30 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407052210.AA09512@benedick.ctd.anl.gov>; from "Masataka Ohta" at Jul 5, 94 5:10 pm X-Mailer: ELM [version 2.3 PL11] > >> - the entire endpoint, including all the protocols inside it (i.e. the > >> demultiplexing point where you look at the "proto" field in the internetwork > >> header - sort of like what a NET in ISOese names) > >Such a entity precisely belongs to the internetwork layer (or, with ISO > >terminology, network layer). > > > >So, don't call it "transport". > > But "transport" is exactly where entity identification belongs. No. Identification is everywhere. Transport is exactly where socket's identification belongs. Internetwork is exactly where host's identification belongs. > The internetwork > layer should control the routing of data between nodes. The internetwork layer controls the exchange of data between hosts, which includes routing and host identification. > These are 2 distinct > functions, that are currently being handled by the IPv4 address. What we need > is to separate the identification and location functions and develope a dynamic > mapping routine to link them together Exactly. And, as IPv4 address is at the internetwork layer, both function is at the internetwork layer. Why, do you think, one functionality changes layer just because you separate it from the other? > (much like ARP maps IPv4 -> MAC). EID->locator is much like IPv4->next_hop. > Why should users or applications care about the IPv4 address? They shouldn't. > They don't care if the data goes over Ethernet, FDDI, T1 links or > carrier pigeon. Yes they do. Users with policy such as QoS reqirement do care, that's one of the reasons why the spaces for EIDs and locators should be managed separately. > I contend that with IPv4, users are _forced_ to care. Not only about addresses > but netmasks, default/dynanic/static routes and everything else going on > there. What? My users are not forced to care about addresses. Aren't you using DNS? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 16:00:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21711; Wed, 6 Jul 1994 16:00:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA03654; Wed, 6 Jul 1994 16:00:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA03649; Wed, 6 Jul 1994 15:58:56 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21674; Wed, 6 Jul 1994 15:58:52 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id WAA05748; Tue, 5 Jul 1994 22:58:43 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Jul 1994 22:58:46 -0700 To: "Richard Carlson" From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Omnibus reply - EIDs Cc: big-internet@munnari.OZ.AU At 3:10 PM 7/5/94, Richard Carlson wrote: >But "transport" is exactly where entity identification belongs. The >internetwork >layer should control the routing of data between nodes. These are 2 distinct I happen to agree with you. But from a conversation with Mike O'Dell today, I gather that there is a very basic debate over the place to put the support for mobility. In classic form, this appears to be an edges/core debate. Change the infrastructure to support mobility or change the end-systems. Choosing one can/should mean making it invisible to the other. Change the infrastructure and you might risk destablilizing basic connectivity for all, but you get the benefit of supporting mobility in a fashion that requires no changes to any host system or application. Big win. Change the end-systems, such as at the transport level, and you will keep basic and existing connectivity stable and will allow incremental benefit for individual adopters. On the other hand, changing ALL end-systems is required for benefit to accrue to all users. Mumble. From the IPAE/SIPP transition work, and before, I'm fond of trying to avoid changing the core any more than necessary. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Wed Jul 6 16:33:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20225; Wed, 6 Jul 1994 15:20:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA03595; Wed, 6 Jul 1994 15:20:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA03579; Wed, 6 Jul 1994 15:08:47 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13755; Wed, 6 Jul 1994 12:16:49 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 6 Jul 94 11:09:51 +0859 From: Masataka Ohta Message-Id: <9407060210.AA06656@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request To: Greg_Minshall@Novell.COM (Greg Minshall) Date: Wed, 6 Jul 94 11:09:49 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407052108.AB17822@WC.Novell.COM>; from "Greg Minshall" at Jul 5, 94 2:08 pm X-Mailer: ELM [version 2.3 PL11] > >Tomorrow, we'll have autoconfiguration and secure DNS. > > >A host can assert anything. But the assetion won't be heard by anyone > >if not accompanied with authentication information using host's > >private secret information. > > I don't think you've yet sat down and thought about my point. With EIDs, > the assertion is being made between host A and host B. With DNS > ("autoregistration", i assume), host A asserts something to server B. With > EIDs, the assertions are being made at a very high rate. With DNS, the > rate is fairly low. The frequency has nothing to do with EID nor DNS. With connection oriented communication, the assertion is verified once at the beginning of the communication. After that, a session key is exchanged confidentially and there is no need to hear the assertion. With connectionless communication, the assertion is made and verified everytime, regardless of whether you use EID, hostname or IPv4 address. That's what is actually happening today around inetd with a TCP wrapper. > So, the ability to do autoregistration in DNS, in a > "secure" way, really says nothing about our ability to protect EIDs from > impersonation. I don't think you've yet sat down and thought about your point. You are talking about "serverless autoconfiguration", aren't you? In a closed environment where there are only two host's on an isolated LAN, you don't have to worry about impersonation during autoconfiguration. In an open environment, a newly purchased host should be preconfigured with authentication information of a name server running at a user service center of a vendor, through which, the host can securely know which autoconfiguration server is it talking. Now, it is user's responsibility to judge whether the autoconfiguration server represented with symbolic host name is trustable or not. > >Hostname, a domainname with A records, is tied to the internetwork layer > >of the architecture through DNS. > > For better or worse, i can *now* send a packet from host A to host B > without knowing anything about DNS. As I wrote "Hostname, a domainname with A records", you must use DNS to convert it to IPv4 address. Of course, you don't have know anything about DNS. Just use it. Then, you can have an illusion of sending a packet from host A to host B now and in the future without knowing anything about DNS. But, it's you who said "impersonation". So, actually, you can't. You can't be sure that host B is not impersonated and is really the host B. For the authentication, you must have access to some authentication information of the host B such as a public key through a locally configured file (just like today`s /etc/hosts) or secure DNS. > >On the other hand, I'm afraid you miss security. > > Today, there isn't any (so, go buy Bellovin and Cheswick's book... :-). No, of course. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 00:20:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09277; Thu, 7 Jul 1994 00:20:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA04165; Thu, 7 Jul 1994 00:20:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA04091; Thu, 7 Jul 1994 00:15:40 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05993; Wed, 6 Jul 1994 22:55:52 +1000 (from yakov@watson.ibm.com) Message-Id: <9407061255.5993@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2735; Wed, 06 Jul 94 08:55:52 EDT Date: Wed, 6 Jul 94 08:55:52 EDT To: tli@cisco.com, jcjones@mit.edu Cc: Big-Internet@munnari.OZ.AU Subject: Source Routing & Provider Selection Ref: Your note of Mon, 4 Jul 1994 23:46:27 -0700 Tony, >It is not clear that the source route must be in the packet header. >If you use SDRP, for example, you get a source routed tunnel where >the source routing information is contained in the tunneling encapsulation >not not in the internetwork layer header itself. You are certainly correct, that source routing capabilities *may* be implemented outside of the network layer header. However, these capabilities are clearly the part of the functionality provided by the network layer. By not implementing this functionality within a *single common* network layer header, we introduce *in effect* yet one more internetwork layer header. One need to carefully evaluate the trade-offs of a single common network layer header vs two internetwork layer headers. In the case of SDRP we didn't have that much choice -- the current IPv4 source routing capabilities are certainly insufficient for the type of applications SDRP is intended to, so we had to resort to defining a new internetwork layer header (namely SDRP) and using IPv4 as a "virtual subnetwork" protocol. In the context of IPng the questions on the table are: (a) do we need source routing forwarding capabilities ala SDRP/GRE in IPng ? (b) if the answer to (a) is "yes" then: (b.1) Should source routing capabilities be treated as a first-class citizen within IPng ? (b.2) Should these capabilities be realized within a common internetwork layer protocol (so that we'll have just one internetwork layer protocol), or should we have two internetwork layer protocols -- one is IPng, and one is SDRP/GRE-over-IPng ? (b.3) How should such capabilities be encoded ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 01:00:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10348; Thu, 7 Jul 1994 01:00:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA04225; Thu, 7 Jul 1994 01:00:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA04220; Thu, 7 Jul 1994 00:58:40 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10045; Thu, 7 Jul 1994 00:46:49 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA23196; Wed, 6 Jul 1994 16:46:07 +0200 Message-Id: <199407061446.AA23196@mitsou.inria.fr> To: yakov@watson.ibm.com Cc: tli@cisco.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Wed, 06 Jul 1994 08:55:52 EDT." <9407061255.5993@munnari.oz.au> Date: Wed, 06 Jul 1994 16:46:05 +0200 From: Christian Huitema => => In the context of IPng the questions on the table are: => => (a) do we need source routing forwarding capabilities ala SDRP/GRE in IPng ? The answer is clearly *YES*. We may debate on the details, e.g. whether we need all of the SDRP functionalities such as route set up or "strict source routing" (how does this relate to cluster addresses?). Some may believe that SDRP has far too many bells and whistles, but it is fairly clear that source routing through cluster addresses is needed, at least for provider selection. => (b) if the answer to (a) is "yes" then: => (b.1) Should source routing capabilities be treated as a first-class => citizen within IPng ? Yes, absolutely. => (b.2) Should these capabilities be realized within a common => internetwork layer protocol (so that we'll have just one => internetwork layer protocol), or should we have two internetwork => layer protocols -- one is IPng, and one is SDRP/GRE-over-IPng ? SIPP's routing header was an attempt at providing this fonctionality. It uses encapsulation for one good reason - keeping the header format fixed. Making this functionality 1st class allows to make it simpler. If you look at SDRP, a fair bit of the complexity comes from the need to provide its own error reporting (because it cannot use ICMP). Having a flow-id per source route helps; defining precise ICMP reports also helps. => (b.3) How should such capabilities be encoded ? Starting from SIPP routing header + explaining what we absolutely need to add. => => Yakov. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 06:29:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21220; Thu, 7 Jul 1994 06:20:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA04595; Thu, 7 Jul 1994 06:20:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA04582; Thu, 7 Jul 1994 06:10:08 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20302; Thu, 7 Jul 1994 05:54:03 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA12508; Wed, 6 Jul 1994 12:53:42 -0700 Date: Wed, 6 Jul 1994 12:53:42 -0700 From: Tony Li Message-Id: <199407061953.MAA12508@lager.cisco.com> To: Christian.Huitema@sophia.inria.fr Cc: yakov@watson.ibm.com, tli@cisco.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU In-Reply-To: Christian Huitema's message of Wed, 06 Jul 1994 16:46:05 +0200 <199407061446.AA23196@mitsou.inria.fr> Subject: Source Routing & Provider Selection Christian, Your answers are self-contradictory. The SIPP routing header certainly does NOT make source routing into a first class citizen. Otherwise, the source route would be in the main header, or more likely, the unicast destination would also be in the routing header and NOT in the fixed header. Perhaps you want to reconsider your answer to (b.1). It is certainly acceptable to chose to make source routing not a first class citizen, but we must do so conciously. While I understand that you feel that SDRP has been subject to featuritis, you may wish to consider that SDRP really was designed to minimally support the perceived requirements. Thus, if you have a disagreement with the features, you probably have a more fundamental disagreement with the requirements. This difference should be resolved first. Please note that simply supporting "source routing" but not having enough features to support operable "policy routing" would be a poor design choice. "Source routing" is the mechanism, not the goal. Tony => (b) if the answer to (a) is "yes" then: => (b.1) Should source routing capabilities be treated as a first-class => citizen within IPng ? Yes, absolutely. => (b.2) Should these capabilities be realized within a common => internetwork layer protocol (so that we'll have just one => internetwork layer protocol), or should we have two internetwork => layer protocols -- one is IPng, and one is SDRP/GRE-over-IPng ? SIPP's routing header was an attempt at providing this fonctionality. It uses encapsulation for one good reason - keeping the header format fixed. Making this functionality 1st class allows to make it simpler. If you look at SDRP, a fair bit of the complexity comes from the need to provide its own error reporting (because it cannot use ICMP). Having a flow-id per source route helps; defining precise ICMP reports also helps. => (b.3) How should such capabilities be encoded ? Starting from SIPP routing header + explaining what we absolutely need to add. From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 06:43:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22156; Thu, 7 Jul 1994 06:40:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA04662; Thu, 7 Jul 1994 06:40:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA04646; Thu, 7 Jul 1994 06:26:36 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20742; Thu, 7 Jul 1994 06:06:57 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA19762; Wed, 6 Jul 94 14:06:36 MDT Received: from [130.57.64.152] by WC.Novell.COM (4.1/SMI-4.1) id AA21025; Wed, 6 Jul 94 13:02:35 PDT Date: Wed, 6 Jul 94 13:02:33 PDT Message-Id: <9407062002.AA21025@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: yakov@watson.ibm.com From: Greg Minshall Subject: Re: Source Routing & Provider Selection Cc: Big-Internet@munnari.OZ.AU Yakov (replying to Tony), >You are certainly correct, that source routing capabilities *may* >be implemented outside of the network layer header. However, these >capabilities are clearly the part of the functionality provided >by the network layer. By not implementing this functionality within >a *single common* network layer header, we introduce *in effect* yet >one more internetwork layer header. One need to carefully evaluate >the trade-offs of a single common network layer header vs two >internetwork layer headers. You could say the same thing about fragmentation, say. SIPP and CLNP (sort of) implement fragmentation outside of the common (case) internet header. So, i think the question is more of *engineering* rather than something like "philosophy". If you do a separate header, you probably have at least a slight performance hit (at least two extra memory reads, i would think) on a source routed packet. On the other hand, a separate header means you consume less space when you aren't using that facility, and some performance gain on non-source-routed packets. (And, a separate header is arguably cleaner/simpler/something; but we aren't doing philosophy, i said!) So, you need to figure out the prevalence of source routed packets (or, the best-case prediction - arghh!), and decide which way to optimize. (We can still offer SDRP a better deal, in that all ISs would be guaranteed to grok the source route header.) Greg From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 09:00:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23138; Thu, 7 Jul 1994 07:20:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA04708; Thu, 7 Jul 1994 07:20:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA04692; Thu, 7 Jul 1994 07:06:32 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22848; Thu, 7 Jul 1994 07:06:28 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA21122; Wed, 6 Jul 94 15:06:10 MDT Received: from [130.57.64.152] by WC.Novell.COM (4.1/SMI-4.1) id AA21292; Wed, 6 Jul 94 14:02:10 PDT Date: Wed, 6 Jul 94 14:02:09 PDT Message-Id: <9407062102.AA21292@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: yakov@watson.ibm.com From: Greg Minshall Subject: Re: Source Routing & Provider Selection Cc: Big-Internet@munnari.OZ.AU Yakov, Yes/no/whatever to all. My point is that the issue is an engineering tradeoff, *NOT* relegating source routing to "second class" status. (I, personally, am neutral on how it happens; i *do* want it in every router.) Greg From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 09:13:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25996; Thu, 7 Jul 1994 09:00:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04810; Thu, 7 Jul 1994 09:00:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA04794; Thu, 7 Jul 1994 08:53:26 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22761; Thu, 7 Jul 1994 07:02:42 +1000 (from yakov@watson.ibm.com) Message-Id: <9407062102.22761@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1377; Wed, 06 Jul 94 17:02:42 EDT Date: Wed, 6 Jul 94 17:02:42 EDT To: Greg_Minshall@Novell.COM Cc: Big-Internet@munnari.OZ.AU Subject: Source Routing & Provider Selection Ref: Your note of Wed, 6 Jul 94 13:02:33 PDT Greg, >On the other hand, a separate header means you consume less >space when you aren't using that facility, and some performance >gain on non-source-routd packets. Let's try to quantify "less space" -- in the BigTen packet format the extra overhead is 2 bytes. Would you consider this overhead substantial ? Likewise, let's try to quantify "some performance gain" -- in the BigTen packet format the performance gain is a single test for a single bit that is in the fixed location in the fixed header. Would you consider this performance gain substantial ? >So, you need to figure out the prevalence of source routed packets. Here is just a couple of the applications of source routing: (a) support for network layer mobility (mobile hosts) (b) provider selection I would leave it up to you to make a judgement on "the prevalence of source routed packets" (especially since you are a co-chair of the mobile-ip WG). Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 10:12:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26797; Thu, 7 Jul 1994 09:20:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04850; Thu, 7 Jul 1994 09:20:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04839; Thu, 7 Jul 1994 09:12:03 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25425; Thu, 7 Jul 1994 08:43:48 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14493(5)>; Wed, 6 Jul 1994 15:43:36 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 6 Jul 1994 15:43:32 -0700 To: yakov@watson.ibm.com Cc: tli@cisco.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Source Routing & Provider Selection In-Reply-To: yakov's message of Wed, 06 Jul 94 05:55:52 -0800. <9407061255.5993@munnari.oz.au> Date: Wed, 6 Jul 1994 15:43:29 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul6.154332pdt.12171@skylark.parc.xerox.com> > (b.1) Should source routing capabilities be treated as a first-class > citizen within IPng ? Could you re-state this question in terms of measurable qualities or quantities, please? The concept of citizenship classes for IPng features is not well-defined, as far as I know. Steve From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 10:12:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26910; Thu, 7 Jul 1994 09:23:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04867; Thu, 7 Jul 1994 09:23:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04842; Thu, 7 Jul 1994 09:12:36 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26017; Thu, 7 Jul 1994 09:01:38 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA28572; Wed, 6 Jul 1994 16:01:35 -0700 Date: Wed, 6 Jul 1994 16:01:35 -0700 From: Tony Li Message-Id: <199407062301.QAA28572@lager.cisco.com> To: deering@parc.xerox.com Cc: yakov@watson.ibm.com, tli@cisco.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Wed, 6 Jul 1994 15:43:29 PDT <94Jul6.154332pdt.12171@skylark.parc.xerox.com> Subject: Source Routing & Provider Selection > (b.1) Should source routing capabilities be treated as a first-class > citizen within IPng ? Could you re-state this question in terms of measurable qualities or quantities, please? The concept of citizenship classes for IPng features is not well-defined, as far as I know. Neither is any other engineering design attribute. Please define "simple". ;-) I view "1st class" as being "doing the absolute best you can". Two 1st class features should have roughly the same performance level. My understanding is that we want unicast and flows to be 1st class features. What about source routing? SIPP clearly makes it at least second (if not third ;-) class. Please don't misunderstand me: I have no objections to source routing being second class if folks feel that it's appropriate. But I see folks conflicting at the packet level where the real difference is at least as far back as design goals and probably even requirements for the support of policy routing. Tony From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 10:23:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27056; Thu, 7 Jul 1994 09:25:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04895; Thu, 7 Jul 1994 09:25:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04845; Thu, 7 Jul 1994 09:15:38 +1000 Precedence: list Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25182; Thu, 7 Jul 1994 08:33:07 +1000 (from day@BBN.COM) Message-Id: <9407062233.25182@munnari.oz.au> From: John Day Subject: Re: IPng ADs request To: big-internet@munnari.OZ.AU Date: Wed, 6 Jul 94 11:15:58 EST Mail-System-Version: People, I have been following this discussion now for a week or so and have intended to reply but . . . well, there is work that seems to get in the way. So running the risk of the being a bit behind let me make the following comments: From the discussion it would appear that people are talking about (at least) 5 distinct identifiers, which I will term Network addresses, transport ports, application names, system identifiers, and equipment serial numbers. There seems to be reasonable agreement about what a Network address is and what it names, but EID has been used in all 4 of the other ways which has lead to much of the confusion. One can make good arguments for all of these. It would appear that most people agree that network (or internetwork) addresses should not name the interface as IPv4 addresses do. I have taken to describing these as being location dependent and topology dependent but route independent. When I say "topology" I always stress that I use it in the mathematical sense, not the potentially narrower "network topology" sense. By this I mean that given 2 addresses one can tell how "near" they are to each other according to some metric. This allows simpler solutions for multi-homing, mobility and all the other reasons that have appeared on this list. While we have tended to construct a topology based on hierarchies of sets of addresses, this definition leaves it open for someone to come up with a more useful topology for addresses. (I don't know what they might be, but someone may have a bright idea.) But the property one needs is the ability to determine nearness in some meaningful way. The problem is that early on we did not understand this. This lead to the idea that MAC addresses should be globally unique and assigned at the factory to an interface. This makes them more serial numbers than addresses. Consequently, MAC addresses are not topologically significant. MAC addresses really only need to be unique within the scope of the LAN. This has also lead to the belief by a lot of companies that they should be assigning network addresses to their products at the factory. This is also bad since it means the addresses will not be topologically significant when the box is installed. Application names should be location independent, so that names do not change if the applications move. Application names should be globally unique. Specific Application names could be location dependent is certain circumstances. The important property is that they *can* be location independent. This is a name that we do not have currently. It would be useful to have it. It would provide the means to make FTP independent of network addresses and would make any IPng transition simpler. Since we have to change FTP for the transition, it would be nice to change it so that we don't have this problem again. Also, it would allow us to get a way from well-known sockets and all of the problems they will present as applications proliferate. This would seem to be what would be passed by those who have suggested that we need some sort of session protocol above transport and below the applications. Transport ports identify individual transport connections and are only unique within the scope of the network address. Since there is a one-to-one mapping between transport and application names one could argue that both are not necessary. Although there is the issue of what happens if an application opens more than one connection. However, one probably needs to distinguish these in the application as much as in transport. But Frank's suggestion that these are relatively short, i.e. 16 bits is correct. But this doesn't mean you should get rid of them. Nothing is hurt by having both. OSI did it all the time. System identifiers are globally unique identifiers that identify the system as a whole. This is an identifier that would seem to be mainly of importance to management. Frank Kastenholtz had a good phrase for this which I don't have at my command but it was something like "the state that doesn't change as hardware is changed" His phrase was much better. One might easily confuse a system's system identifier and the application name of its agent, but there are probably good reasons for not doing this. This is mainly what I think of as EID. System-ids or serial numbers could be used to confirm a box is who you think it is for automatic address assignment. Serial numbers are unique numbers assigned by manufacturers to their equipment. I am convinced that every piece of equipment should have a machine readable serial number. These are not EIDs or Mac addresses. Serial numbers are required for inventory control and a single box may have several serial numbers associated with it. Often a box will have one which may also map to its system id. Which ones do we need? With the possible exception of transport ports, we need all of these. Should any of the addresses be built out of others? Probably not. If you put EIDs in network addresses they are no longer topologically signficant. If you put EIDs in application names, then you can't move the application to another system. For some applications, this may not be a problem. EIDs might be part of some serial numbers, but again it may not always be wise to do this. Does this help? On a different subject (sort of) Should these names be fixed or variable length? For network addresses, we all know the advantages of having fixed length addresses and it would certainly be nice if they could be. However, to be fixed length we need to be sure that we don't ever run out again. This coupled with the fact that we have consistently underestimated the number of addresses we need . . . by a lot, indicates that the address had better be long enough that there is no chance of running out. (In ancient history when most compilers limited identifiers to 6 or 8 characters, I remember a compiler for a language that did not put any bound on identifiers that put the upper bound at 64 characters. They figured programmers were too lazy to make them that long and there was little or no chance that would anyone hit their upper bound.) For addresses to be fixed length it would appear that we would need something on the order of 40 or 50 octets to be safe. We can't assume that there will be tight control on handing out addresses. If there is it will limit network growth and push people to do other things which we don't want. So for fixed length to be viable it needs to be large enough that there is absolutely no chance of running out. This probably makes the address much longer than we need for the short or even mid term, i.e. the next 30 to 40 years. So those who are concerned about efficiency may find this is probably unacceptable, not to mention that if I am sending stuff locally why do I need to send these huge addresses. So while it is highly desireable to have fixed length addresses, it does not appear that we can do it and satisfy other constraints. Take care John From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 11:40:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02025; Thu, 7 Jul 1994 11:40:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA05024; Thu, 7 Jul 1994 11:40:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA05008; Thu, 7 Jul 1994 11:38:51 +1000 Precedence: list Received: from primus.cstp.umkc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01978; Thu, 7 Jul 1994 11:38:42 +1000 (from lee@PRIMUS.CSTP.UMKC.EDU) Received: by PRIMUS.CSTP.UMKC.EDU (MX V4.0-1 AXP) id 2; Wed, 06 Jul 1994 20:38:20 CST Date: Wed, 06 Jul 1994 20:38:20 CST From: Sung Jong Lee (David) Reply-To: LEE@vax2.cstp.umkc.edu To: owner-Big-Internet@munnari.OZ.AU Cc: Big-Internet@munnari.OZ.AU Message-Id: <00981097.6C337F82.2@PRIMUS.CSTP.UMKC.EDU> Subject: Please remove me from the list I want unsubcribe this mailing list.R} P.S. I sent the mae message ("5 time so far. UqIs there a administaror for this mailing list or not. Thank you From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 12:45:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02354; Thu, 7 Jul 1994 11:44:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA05041; Thu, 7 Jul 1994 11:44:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA05005; Thu, 7 Jul 1994 11:26:30 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01576; Thu, 7 Jul 1994 11:26:25 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA07462; Wed, 6 Jul 94 20:26:16 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:big-internet@munnari.oz.au id AA10790; Wed, 6 Jul 94 20:26:15 -0500 Date: Wed, 6 Jul 94 20:26:15 -0500 Message-Id: <9407070126.AA10790@benedick.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs From: "Richard Carlson" From: Masataka Ohta Masataka; >No. Identification is everywhere. OK, everything is identified in some way. Thats why I keep a dictionary by my desk. >Transport is exactly where socket's identification belongs. I disagree, a socket is an application end point. It currently uses the transport port number + transport protocol + IPv4 address. If you change the IPv4 addres to something else that doesn't reference the network layer, then I would concede this point. >Internetwork is exactly where host's identification belongs. I disagree again. Tell me what happens with a multi-homed host? Since each interface has a different address (name), what's the offical name? I run into this all the time, and I don't think DNS handles it very well either. >The internetwork layer controls the exchange of data between hosts, which >includes routing and host identification. What about the transport layers roll in data exchange? The IP layer only sends data from Src to Dest, it doesn't verify that data was received correctly, or even if it got there at all! It's up to the TCP to guarantee that data is correctly received. Routing is required, but why is host identification required? >Why, do you think, one functionality changes layer just because you >separate it from the other? Because I want it to change. You disagree, fine, now we have a basis for discussion. I look at the IPv4 and see a flaw in it's design (a single entity for both location and identification purposes). This wasn't an obvious flaw 10 years ago when IP was designed, but things have changed. My conclusion is to fix this flaw by separating the functions. If you can show me where my reasoning is flawed, I'll change my opinion. >> Why should users or applications care about the IPv4 address? > >They shouldn't. > >> They don't care if the data goes over Ethernet, FDDI, T1 links or >> carrier pigeon. > >Yes they do. Users with policy such as QoS reqirement do care, that's >one of the reasons why the spaces for EIDs and locators should be >managed separately. My point is that the IPv4 address determines the physical media you are taking with a multi-homed host. I see that you would like to choose different media for different QoS criterion. But I contend that this decision should be made at the transport layer. By the time you reach the network layer it's to late to change your mind. (This is at the host end, routers may need to make decisions, and they can only act on the network layer information). >What? My users are not forced to care about addresses. Aren't you using DNS? Yes we are using DNS, but that doesn't seem to stop my users from using IP numbers. Try configuring a SunOS 4.1.x box to use DNS without replacing the libc.a. Sure you can turn on NIS, but doing it just to get DNS access is crazy. The only remaining option is to start building a static host table. Even if you aviod that, look at your resolv.conf file once. Right there you have to configure the IP addresses of the nameservers. Yes administrators can hid these issues from the typical user, but I find that a lot of workstations are purchased directly by individuals that I now have to teach networking 101 to. Maybe separate identifiers and locators wouldn't make things better, but I don't see how they would be worse. ~c mohta@necom830.cc.titech.ac.jp ++Rich Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 15:17:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04457; Thu, 7 Jul 1994 12:40:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA05108; Thu, 7 Jul 1994 12:40:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA05092; Thu, 7 Jul 1994 12:36:12 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02821; Thu, 7 Jul 1994 11:57:23 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA12522; Wed, 6 Jul 94 18:52:10 -0700 Received: by xirtlu.zk3.dec.com; id AA08970; Wed, 6 Jul 1994 21:52:09 -0400 Message-Id: <9407070152.AA08970@xirtlu.zk3.dec.com> To: Big-Internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Wed, 06 Jul 94 14:02:09 PDT." <9407062102.AA21292@WC.Novell.COM> Date: Wed, 06 Jul 94 21:52:02 -0400 X-Mts: smtp Here is my two cents. First I really think we are creating polarity here by calling something 1st or 2cnd class. We all know this is natural on Big-I and we don't need help to increase polarization. But if thats what folks want to do. I believe a source route should be treated as a second class citizen. I do not believe the source route should be in the main header. I believe there should be a bit or something in the main header telling you a source route is there in the options. I might believe the source route should always be the first option after the main header. You should not have to use a source route in dec.com, ibm.com, or sun.com. This is what MOST of my customers care about. Hence, I do not believe a source route should be in the main header taking up space for most of my customers traffic or the traffic in my internal network, and we use the Internet a lot, especially for Big-I discussions in the IETF standards committee. I apologize to the providers I understand your need too, but most of the revenue streams come from folks who are not providers and for me that has first priority. /jim From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 18:25:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18683; Thu, 7 Jul 1994 18:25:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05421; Thu, 7 Jul 1994 18:24:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05414; Thu, 7 Jul 1994 18:14:58 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18111; Thu, 7 Jul 1994 18:14:04 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 7 Jul 94 17:07:06 +0900 From: Masataka Ohta Message-Id: <9407070807.AA12543@necom830.cc.titech.ac.jp> Subject: Re: Source Routing & Provider Selection To: yakov@watson.ibm.com Date: Thu, 7 Jul 94 17:07:04 JST Cc: Greg_Minshall@Novell.COM, Big-Internet@munnari.OZ.AU In-Reply-To: <9407062102.22761@munnari.oz.au>; from "yakov@watson.ibm.com" at Jul 6, 94 5:02 pm X-Mailer: ELM [version 2.3 PL11] > Let's try to quantify "less space" -- in the BigTen packet format > the extra overhead is 2 bytes. Would you consider this overhead > substantial ? It seems to me that the design of BigTen is quite unbalanced to support source routing vigirously and, at the same time, to have geography based addressing plan. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 18:25:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17516; Thu, 7 Jul 1994 18:00:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05381; Thu, 7 Jul 1994 18:00:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA05376; Thu, 7 Jul 1994 17:57:51 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17270; Thu, 7 Jul 1994 17:57:44 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26257; Thu, 7 Jul 1994 09:58:34 +0200 Message-Id: <199407070758.AA26257@mitsou.inria.fr> To: Tony Li Cc: yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Thu, 07 Jul 1994 00:37:09 PDT." <199407070737.AAA20470@lager.cisco.com> Date: Thu, 07 Jul 1994 09:58:33 +0200 From: Christian Huitema Tony, I don't know the particular values to place in your picture. If we look at todays load, we observe that: 1) Multicast is about 7% in volume, while the MBONE is still in infancy. That may grow, but Mosaic and Gopher, which are point to point applications, are growing faster. 2) Within "unicast", "datagram" applications represent approximately 5% in volume, essentially for DNS and SNMP. I would expect the same pattern to hold for multicast, e.g. taking into account variations of resource discovery or conference control mechanisms. 3) Source routing for provider selection is not used much. Fact is that you only "need" it, today, if you have several providers for the same site or if you don't want the default provider of your regional. Most of the case I am aware of boil down to tunnelling through a regional to reach your prefered provider. If we look at future usages, using write ups which are at least in IPv4 drafts, we can add that: 4) Source routing towards the "rendez vous" point is required by sparse PIM. 5) Source routing through the base is required by mobile IP. Note that I have a big problem with the notion of "flows" in your matrix. A flow is a set of packets which are marked for special treatment, e.g. resource reservation or priority handling. All packets may well carry a flow id; we may well have on id per TCP connection or RTP association. It certainly does not follow that we should have individual handling of each flow by all routers. Routers will be better off treating "tiny" flows as pure datagrams (for some definition of tiny). We may well see that core routers are datagram only, while the flows are only individualized on some narrow link of the path. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 18:45:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19507; Thu, 7 Jul 1994 18:45:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05482; Thu, 7 Jul 1994 18:44:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05418; Thu, 7 Jul 1994 18:24:53 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16645; Thu, 7 Jul 1994 17:38:42 +1000 (from tli@cisco.com) Received: from lager.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17368 Thu, 7 Jul 1994 17:38:38 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA20470; Thu, 7 Jul 1994 00:37:09 -0700 Date: Thu, 7 Jul 1994 00:37:09 -0700 From: Tony Li Message-Id: <199407070737.AAA20470@lager.cisco.com> To: Christian.Huitema@sophia.inria.fr Cc: yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU In-Reply-To: Christian Huitema's message of Thu, 07 Jul 1994 08:56:58 +0200 <199407070657.AA26094@mitsou.inria.fr> Subject: Source Routing & Provider Selection Christian, It seems we have a misunderstanding over the term "first class citizen". You seem to imply that if something is not in the header itself, it is not "first class". I have the opinion that it is first class if it is in the minimal subset that all implementations must implement. Misunderstanding indeed. "first class" has to do with design priorities, not with encoding. A "first class" feature is fundamental to the design and should receive a semantically complete, robust and efficient treatment in the design. In a truly balanced design, we should give all first class features equal treatment insamuch as we're able to do so. As an example SIPP has tried to make flows and multicasting first-class features. I don't believe that the coding in the header itself (as IPv4 source routes) or in an encapsulated header (as the SIPP routing header) makes a significant difference. In either case, you're correct, neither IPv4 or SIPP source routes (or SDRP, for that matter) treats source routing as a first class citizen. This is obvious as it's clear that both designs do not do their utmost to make source routing efficient. Perhaps an interesting alternative approach is to ask what percentage of the traffic you would expect to see using each flavor of routing. I see the matrix: \ source pure \ flow routed datagram +----------+----------+-----------+ | | | | unicast | | | | | | | | +----------+----------+-----------+ | | | | multicast| | | | | | | | +----------+----------+-----------+ Now, if you go talk to Noel, he'll tell you that almost all traffic in the future will be a flow. And if you believe that multicast services will take off, then the bulk of the traffic will be in the lower half. If you talk to Yakov and discuss provider selection, I think he will say that the bulk of the traffic will be source routed unicasts. Now, if we can come to some consensus here on how to fill the matrix and thereby on what problem we're trying to solve, we can then work to make forwarding most efficient for those cases that need it. Tony From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 18:58:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18768; Thu, 7 Jul 1994 18:27:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05453; Thu, 7 Jul 1994 18:27:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05400; Thu, 7 Jul 1994 18:04:40 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15044; Thu, 7 Jul 1994 16:56:06 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26094; Thu, 7 Jul 1994 08:57:00 +0200 Message-Id: <199407070657.AA26094@mitsou.inria.fr> To: Tony Li Cc: yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Wed, 06 Jul 1994 12:53:42 PDT." <199407061953.MAA12508@lager.cisco.com> Date: Thu, 07 Jul 1994 08:56:58 +0200 From: Christian Huitema Tony, It seems we have a misunderstanding over the term "first class citizen". You seem to imply that if something is not in the header itself, it is not "first class". I have the opinion that it is first class if it is in the minimal subset that all implementations must implement. I don't believe that the coding in the header itself (as IPv4 source routes) or in an encapsulated header (as the SIPP routing header) makes a significant difference. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 19:03:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19583; Thu, 7 Jul 1994 18:46:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05497; Thu, 7 Jul 1994 18:46:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05444; Thu, 7 Jul 1994 18:26:32 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17539; Thu, 7 Jul 1994 18:01:51 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 7 Jul 94 16:55:29 +0900 From: Masataka Ohta Message-Id: <9407070755.AA12460@necom830.cc.titech.ac.jp> Subject: Re: Omnibus reply - EIDs To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Date: Thu, 7 Jul 94 16:55:26 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407070126.AA10790@benedick.ctd.anl.gov>; from "Masataka Ohta" at Jul 6, 94 8:26 pm X-Mailer: ELM [version 2.3 PL11] Richard; > >Transport is exactly where socket's identification belongs. > > I disagree, a socket is an application end point. An application may use multiple transport entities, that is, multiple sockets. A socket is a transport end point in application programs. Transport is exactly where socket's identification belongs. > It currently uses the transport > port number + transport protocol + IPv4 address. Thus, it is at transport. > >Internetwork is exactly where host's identification belongs. > > I disagree again. Tell me what happens with a multi-homed host? What happens? Let's see what is actually happening. % nslookup titccy.cc.titech.ac.jp. Name: titccy.cc.titech.ac.jp Addresses: 131.112.32.173, 131.112.252.3 % nslookup -q=ptr 173.32.112.131.in-addr.arpa. 173.32.112.131.in-addr.arpa name = titccy.cc.titech.ac.jp % nslookup -q=ptr 3.252.112.131.in-addr.arpa. 3.252.112.131.in-addr.arpa name = titccy.cc.titech.ac.jp > Since each > interface has a different address (name), what's the offical name? You don't have to have a single official name to identify something. > I run > into this all the time, and I don't think DNS handles it very well either. DNS handles it very well. The only problem is that identification by IP addresses is no good for real authentication. > >The internetwork layer controls the exchange of data between hosts, which > >includes routing and host identification. > > What about the transport layers roll in data exchange? The transport layer controls the exchange of data between end points, which includes end point identification. > Routing is required, but why is host identification required? Because an end point is identified with port number through host identification. > >Why, do you think, one functionality changes layer just because you > >separate it from the other? > > Because I want it to change. You can't want so. > My conclusion is to fix this flaw by separating the functions. That's fine. > If you can show me where my reasoning is flawed, I'll change my > opinion. Your reasoning is flawed because you insists location identification and host identification must be at separate layers without giving any reason. The internetworking layer is the layer where location identification is performed. The internetworking layer is the layer where host identification is performed. You can't just want to change it. > My point is that the IPv4 address determines the physical media you are > taking with a multi-homed host. No, some physical media does not have IP addresses. Determination of the physical media is at link layer. > I see that you would like to choose different > media for different QoS criterion. But I contend that this decision should > be made at the transport layer. Of course. So? > >What? My users are not forced to care about addresses. Aren't you using DNS? > > Yes we are using DNS, but that doesn't seem to stop my users from using IP > numbers. I don't want to forbid our users to care about addresses, either. > Try configuring a SunOS 4.1.x box to use DNS without replacing > the libc.a. Sure you can turn on NIS, but doing it just to get DNS access is > crazy. I admit engineers of Sun are crazy. Is it your point? > Even > if you aviod that, look at your resolv.conf file once. Right there you have > to configure the IP addresses of the nameservers. Yes administrators can > hid these issues from the typical user, but I find that a lot of workstations > are purchased directly by individuals that I now have to teach networking 101 > to. Maybe separate identifiers and locators wouldn't make things better, but > I don't see how they would be worse. Autoconfigure. Don't let Sun design it. Masataka Ohta PS Reply mechanism of your mail system is broken and your mail has two "From" fields one of which is impersonating me. From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 19:53:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20142; Thu, 7 Jul 1994 19:05:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA05544; Thu, 7 Jul 1994 19:04:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05520; Thu, 7 Jul 1994 18:51:47 +1000 Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19720; Thu, 7 Jul 1994 18:51:42 +1000 (from kpk-big-internet-owner@edvina.se) Received: from c3po.edvina.se by mail.swip.net (8.6.8/2.01) id KAA05537; Thu, 7 Jul 1994 10:51:33 +0200 Received: by c3po.edvina.se (4.1/SMI-4.1) id AA12507; Thu, 7 Jul 94 09:51:52 MET Received: from murtoa.cs.mu.OZ.AU by c3po.edvina.se (4.1/SMI-4.1) id AA12378; Thu, 7 Jul 94 09:47:31 MET Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05448; Thu, 7 Jul 1994 18:26:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05414; Thu, 7 Jul 1994 18:14:58 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18111; Thu, 7 Jul 1994 18:14:04 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 7 Jul 94 17:07:06 +0900 From: Masataka Ohta Message-Id: <9407070807.AA12543@necom830.cc.titech.ac.jp> Subject: Re: Source Routing & Provider Selection To: yakov@watson.ibm.com Date: Thu, 7 Jul 94 17:07:04 JST Cc: Greg_Minshall@Novell.COM, Big-Internet@munnari.OZ.AU In-Reply-To: <9407062102.22761@m From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 19:53:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20172; Thu, 7 Jul 1994 19:07:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA05559; Thu, 7 Jul 1994 19:06:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05539; Thu, 7 Jul 1994 18:59:48 +1000 From: kpk-big-internet-owner@edvina.se Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20026; Thu, 7 Jul 1994 18:59:42 +1000 (from kpk-big-internet-owner@edvina.se) Received: from c3po.edvina.se by mail.swip.net (8.6.8/2.01) id KAA06128; Thu, 7 Jul 1994 10:59:32 +0200 Received: by c3po.edvina.se (4.1/SMI-4.1) id AA12652; Thu, 7 Jul 94 09:59:55 MET Date: Thu, 7 Jul 94 09:54:05 MET Received: from murtoa.cs.mu.OZ.AU by c3po.edvina.se (4.1/SMI-4.1) id AA12520; Thu, 7 Jul 94 09:54:05 MET Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05465; Thu, 7 Jul 1994 18:28:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05400; Thu, 7 Jul 1994 18:04:40 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15044; Thu, 7 Jul 1994 16:56:06 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26094; Thu, 7 Jul 1994 08:57:00 +0200 Message-Id: <199407070657.AA26094@mitsou.inria.fr> To: Tony Li Cc: yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Wed, 06 Jul 1994 12:53:42 PDT." <199407061953.MAA12508@lager.cisco.com> Date From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 19:54:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20260; Thu, 7 Jul 1994 19:08:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA05574; Thu, 7 Jul 1994 19:07:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05515; Thu, 7 Jul 1994 18:47:47 +1000 From: kpk-big-internet-owner@edvina.se Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19604; Thu, 7 Jul 1994 18:47:41 +1000 (from kpk-big-internet-owner@edvina.se) Received: from c3po.edvina.se by mail.swip.net (8.6.8/2.01) id KAA05233; Thu, 7 Jul 1994 10:47:16 +0200 Received: by c3po.edvina.se (4.1/SMI-4.1) id AA12433; Thu, 7 Jul 94 09:47:39 MET Date: Thu, 7 Jul 94 09:37:29 MET Received: from murtoa.cs.mu.OZ.AU by c3po.edvina.se (4.1/SMI-4.1) id AA12333; Thu, 7 Jul 94 09:37:29 MET Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05396; Thu, 7 Jul 1994 18:03:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA05376; Thu, 7 Jul 1994 17:57:51 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17270; Thu, 7 Jul 1994 17:57:44 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26257; Thu, 7 Jul 1994 09:58:34 +0200 Message-Id: <199407070758.AA26257@mitsou.inria.fr> To: Tony Li Cc: yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Thu, 07 Jul 1994 00:37:09 PDT." <199407070737.AAA20470@lager.cisco.com> Date From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 19:54:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20290; Thu, 7 Jul 1994 19:09:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA05595; Thu, 7 Jul 1994 19:09:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05523; Thu, 7 Jul 1994 18:54:08 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19766; Thu, 7 Jul 1994 18:54:04 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA21966; Thu, 7 Jul 1994 01:53:44 -0700 Date: Thu, 7 Jul 1994 01:53:44 -0700 From: Tony Li Message-Id: <199407070853.BAA21966@lager.cisco.com> To: Christian.Huitema@sophia.inria.fr Cc: yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU In-Reply-To: Christian Huitema's message of Thu, 07 Jul 1994 09:58:33 +0200 <199407070758.AA26257@mitsou.inria.fr> Subject: Source Routing & Provider Selection I don't know the particular values to place in your picture. Neither do I. Dontcha' just love engineering? ;-) If we look at todays load, We will undoubtedly be looking at something different tomororow. Note that I have a big problem with the notion of "flows" in your matrix. A flow is a set of packets which are marked for special treatment, e.g. resource reservation or priority handling. All packets may well carry a flow id; we may well have on id per TCP connection or RTP association. It certainly does not follow that we should have individual handling of each flow by all routers. Routers will be better off treating "tiny" flows as pure datagrams (for some definition of tiny). We may well see that core routers are datagram only, while the flows are only individualized on some narrow link of the path. No argument. However, even the routers that aren't dealing with individual flows may well be performing a flow lookup on every packet. The point is that if we made flow processing extremely slow the design wouldn't work very well. Tony From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 03:45:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08969; Fri, 8 Jul 1994 03:45:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA06273; Fri, 8 Jul 1994 03:45:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06257; Fri, 8 Jul 1994 03:33:06 +1000 Precedence: list From: daniel@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08517; Fri, 8 Jul 1994 03:33:03 +1000 (from daniel@ISI.EDU) Received: from dza.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 7 Jul 1994 10:32:58 -0700 Date: Thu, 7 Jul 94 10:32:48 PDT Posted-Date: Thu, 7 Jul 94 10:32:48 PDT Message-Id: <9407071732.AA07036@dza.isi.edu> Received: by dza.isi.edu (4.1/4.0.3-4) id ; Thu, 7 Jul 94 10:32:48 PDT To: Christian.Huitema@sophia.inria.fr Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Christian Huitema's message of Thu, 07 Jul 1994 09:58:33 +0200 <199407070758.AA26257@mitsou.inria.fr> Subject: Source Routing & Provider Selection Reply-To: daniel@ISI.EDU In talking about source routing, Christian Huitema says: > 4) Source routing towards the "rendez vous" point is required by sparse PIM. This is not as I understand it. A receiver sends a PIM-Join to the RP by unicast routing in order to hear about new sources. This message is processed hop-by-hop to add the appropriate PIM state, but that is currently done by re-addressing the packet, at each hop, to the unicast next hop toward the RP. In SIPP, the processing could be accomplished with a hop-by-hop option. A new source sends a PIM-Register to the RP, but that is done purely by unicast routing. Where source routing will *really* be used in the future with PIM is when a branch of the unicast-based shortest-path multicast tree can not provide an adequate QOS guarantee. In that case, PIM control messages will need to be source-routed to find a multicast tree that can support the QOS receivers require. Once a good multicast tree is established, data packets and control packets can be forwarded using PIM forwarding state, so source-routing is used only for initial control messages. Daniel Zappala From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 06:11:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10854; Fri, 8 Jul 1994 04:45:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA06367; Fri, 8 Jul 1994 04:45:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA06362; Fri, 8 Jul 1994 04:40:07 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10698; Fri, 8 Jul 1994 04:39:59 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 7 Jul 1994 14:39:56 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 7 Jul 1994 14:39:56 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA09322; Thu, 7 Jul 94 14:37:55 EDT Date: Thu, 7 Jul 94 14:37:55 EDT Message-Id: <9407071837.AA09322@mailserv-D.ftp.com> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 746 Scott and Alison, There have been at least three sizable notes to the big-i list over the past 4-8 weeks using a bit of math (hard to believe, any sort of quantitative analysis, eh?) showing that 16 bytes is probably the absolute minimum needed for long-term, hierarchically scalable routing. You state that the IPng directorate's consensus (and other mailing lists as well) seems to be that fixed-16 bytes is adequate. I would like to know A) what analysis was done to show that 16 bytes, rather than being the bare minimum, is the maximum needed, and B) what the flaws were in the posted analyses that indicate that 16 is the bare minimum. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 06:11:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10189; Fri, 8 Jul 1994 04:25:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA06330; Fri, 8 Jul 1994 04:25:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA06301; Fri, 8 Jul 1994 04:07:16 +1000 Precedence: list Received: from radegond.cmf.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09601; Fri, 8 Jul 1994 04:07:13 +1000 (from mankin@cmf.nrl.navy.mil) Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id OAA16703 for big-internet@munnari.oz.au; Thu, 7 Jul 1994 14:07:10 -0400 Date: Thu, 7 Jul 1994 14:07:10 -0400 From: IPng Area Directors Message-Id: <199407071807.OAA16703@radegond.cmf.nrl.navy.mil> Reply-To: big-internet@munnari.OZ.AU Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Sender: mankin@cmf.nrl.navy.mil Status: R Apparently-To: big-internet@munnari.OZ.AU Hi, TUBA, SIPP, CATNIP, BIG-INTERNET, and IETF: This message is one last pre-Toronto recommendation attempt to gauge the extent of consensus on one of the IPng issues. We apologize for duplications. We wanted to reach a wide audience. Steve Deering's message "Chicago Meeting -- Possible Changes to SIPP" to the SIPP list a while back elicited quite a bit of discussion on various lists (both SIPP and big-internet and in other venues) about the length of "address" required for an IPng. We have also had considerable discussion within the directorate. At this time it would appear to us that there is considerable consensus that a fixed length, topologically structured, hierarchical address 16 bytes in length is reasonable for an IPng (that is meets the needs of the very very large-scale Internet). We understand that we are being a bit vague in using the term "address" in light of the question we asked two weeks ago. For the purposes of this request, please assume that the transport level and internet level names are the same. Some hold the view that 16 bytes is larger than would be required for any imaginable Internet structure in the future and that an 8 byte address is all that is required. There seems to be a stronger, but still minority, view that, for various reasons, a variable length address, one that could be smaller or larger than 16 bytes, would meet the needs better for the future of the Internet. Much of the discussion on the lists has revolved around the relative efficiency of processing fixed and variable length addresses. We would like to assess the consensus just on the length for the future Internet, instead of discussing efficiency any more at this time. We want to make sure that we have understood consensus on meeting the needs of the very very large Internet. Therefore, this message is to ask people what present or future rationale they see for one of: 8 byte fixed length address. 16 byte fixed length address. longer than 16 byte fixed length address now. only 16 byte length addresses now but ability to lengthen the address later. To amplify a bit more, we are especially interested in your views on the address length's ability to offer: routing aggregation power topological flexibility adminstrative manageability At this point the consensus among the IPng directorate and on several of the mailing lists seems fairly clear (a 16 byte length address is good for those things). This is a good time to bring forward your remaining views about the requirements for address length for IPng. Thank you, Scott and Allison From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 06:11:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12941; Fri, 8 Jul 1994 05:45:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA06440; Fri, 8 Jul 1994 05:45:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA06424; Fri, 8 Jul 1994 05:25:47 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12270; Fri, 8 Jul 1994 05:25:43 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 7 Jul 1994 12:25:21 -0700 Date: Thu, 7 Jul 1994 12:25:21 -0700 Message-Id: <199407071925.AA07596@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: Christian.Huitema@sophia.inria.fr Cc: tli@cisco.com, yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU, estrin@ISI.EDU In-Reply-To: Christian Huitema's message of Thu, 07 Jul 1994 09:58:33 +0200 <199407070758.AA26257@mitsou.inria.fr> Subject: Source Routing & Provider Selection Reply-To: estrin@usc.edu Just a minor correction, source routing toward the RP is not "required" in sparse mode PIM. I plan to make source routing usable in PIM Sparse MOde to control the routing of joins (toward sources or the RP) when the generic unicast route is not satisfactory. But right now PIM uses generic hbh unicast routing. But as our menu of ToS becomes richer we will need source routing more to get the routes we desire (granted, if you look 20 yrs down the line one could argue that some of this wont be needed but in the 10 yr time frame it is). What SIPP needs to do to provide fully-functional (i.e., SDRP style :}) source routing seems relatively straight forward and low cost. * be able to specify cluster/aggregate or host identifiers as elements in the source rou; * be able to specify if the next hop is strict or loose source routing (possibly only do this for cluster elements since the cost for host-type hops may be too high in terms of encoding the flag, and so in this case the strict/loose may be for the entire route, not per hop) * be able to specify what action should be taken if the source route specified is not usable. * the Probe/verify function may be handled by something other than the in-header-bits used by SDRP...this still needs discussion So, what am i missing? From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 06:25:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14275; Fri, 8 Jul 1994 06:25:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA06495; Fri, 8 Jul 1994 06:25:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA06468; Fri, 8 Jul 1994 06:08:16 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12905; Fri, 8 Jul 1994 05:44:01 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: big-internet@munnari.OZ.AU In-Reply-To: IPng Area Directors's message of Thu, 7 Jul 1994 14:07:10 -0400 <199407071807.OAA16703@radegond.cmf.nrl.navy.mil> Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Date: Thu, 7 Jul 94 15:43:06 -0400 Message-Id: <9407071543.aa10740@quern.epilogue.com> I'm really at a loss as to where to begin in answering this call for concensus. There are so many possibilities. Isn't it rather putting the cart before the horse to pick an address size without specifying the addressing and routing architecture that it's for? I'd also expect the details of the address encoding to have an effect of at least a factor of 2 here. Since you're only asking for one size I presume you're asking in the context of a system that does not have separate EIDs and locators. Ouch. Without EIDs it's a lot harder to answer "of course addresses must be variable length", but they probably still should be. Dave From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 06:28:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14450; Fri, 8 Jul 1994 06:28:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA06520; Fri, 8 Jul 1994 06:28:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA06484; Fri, 8 Jul 1994 06:20:39 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13296; Fri, 8 Jul 1994 05:58:00 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 7 Jul 1994 12:57:51 -0700 Date: Thu, 7 Jul 1994 12:57:51 -0700 Message-Id: <199407071957.AA08296@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: tli@cisco.com Cc: Christian.Huitema@sophia.inria.fr, yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU, estrin@ISI.EDU In-Reply-To: Tony Li's message of Thu, 7 Jul 1994 00:37:09 -0700 <199407070737.AAA20470@lager.cisco.com> Subject: Source Routing & Provider Selection Reply-To: estrin@usc.edu Just another word on tony;s matrix: 1. flows will often use generic unicast but will also make use of source routing more than pure datagrams in order to get the QoS desired. It is an important piece of support for flows and we need to look at what is important re. source routing support in this context: -- we need good performance on packet forwarding because of the typically demanding traffic types; but with flow setup of some kind this involves good packet classification techniques as much as anything else. -- we need the functionality of specifying what to do with a source routed packet under different conditions so that at session startup and after topology changes, we can continue to deliver data packets, when appropriate/desired, even when the requested QoS is unavoidable disrupted. -- we need to be able to make use of setup but be able to send data in advance of the round trip delay needed to establish the state. such a design makes startup and adapting to changes much less cumbersome. -- we need to be able to specify strict source routing at times when in order to control the QoS provided we have to make sure no other networks or links are traversed...and at the same time we dont want everythign to be strictly source-routed since that gets in the way of the network nodes doing local and timely adaptation, and makes the source route construction job more difficult. 2. For multicast (which of course will be significant since for each packet sent there is the multiplier effect of multicast that naturally makes that traffic dominate the overall network use ... :}), it is not the packets that will carry the source route but the join/prune messages. Here we need source routing capabilities but the per packet processing is less of an issue. 3. Provider selection is probably going to grow in use as the market matures (but before it matures too much...) but i dont think even yakov would say that it will dominate traffic, just that it is important (not optional) to support...Yakov? From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 06:30:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14540; Fri, 8 Jul 1994 06:30:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA06535; Fri, 8 Jul 1994 06:30:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA06487; Fri, 8 Jul 1994 06:21:14 +1000 Precedence: list Received: from sundance.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12600; Fri, 8 Jul 1994 05:35:12 +1000 (from danmcd@sundance.itd.nrl.navy.mil) Subject: re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: SIPP Mailing list , big-Internet@munnari.OZ.AU Date: Thu, 7 Jul 1994 15:35:29 -0500 (EST) From: "Daniel L. McDonald" Cc: mankin@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu, "Daniel L. McDonald" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3993 Message-Id: <9407072035.aa15952@sundance.itd.nrl.navy.mil> > Hi, TUBA, SIPP, CATNIP, BIG-INTERNET, and IETF: Hi from SIPP, IETF, and BIG-INTERNET. > At this time it would appear to us that there is considerable consensus > that a fixed length, topologically structured, hierarchical ^^^^^^^^^^^^^^^^^^^ Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues of fixed length addresses before. My biggest beef with variable length addresses is the issue of maintaining additional state or taking additional time to parse an address whose length I don't know at the start. Granted, flow ID's and optimizing for certain common ("fast path") cases may help this, but flow ID's still require tables with flow ID's for keys, and today's common case may be tomorrow's exception. Authentication and encryption also present problems similar to flow ID's with key lookup. I don't want to rewrite my (statically configured) OS kernel in 4 years when today's common cases no longer exist. (Although, admittedly, current trends in OS research may render this argument obsolete.) Parsing addresses is a problem all along the path (both network hops, and within each system) an IPng datagram takes. Both routers and end-systems have to parse addresses, at least to the point of finding a fast path. Our implementation experience has shown us that variable length addresses adds a whole new layer of complexity to things such as: * Routing lookups * User interface issues * Storage requirements * Address parsing (for lookups, incoming packets, etc.) and everyone's favorite * Application programmer level backward compatibility As for the options presented... > 8 byte fixed length address. I have no problem with this, but this alienates many people. Also, there seems to be a trend toward low percentage of allocated address space used. (I offer NRL itself as an example, though not the worst, of such waste.) If we could pull it off with 8 bytes, I'd be all behind it. > 16 byte fixed length address. This eliminates much alienation. Furthermore, wasted address space is not a significant problem here. (NOTE: I do feel, especially after attending one of the ALE meetings in Seattle, that people get too much address space, and that it's a longer term problem than just the remainder of IPv4's lifetime.) Since it is still fixed length it has none of the nightmares of variable-length addresses. > longer than 16 byte fixed length address now. I would like to see why we NEED any address space above 16-bytes. Does anyone have any solid arguments as to why 16 bytes is not enough? I've seen ones for 8, but not 16. Also, let's consider alignment issues if picking a size above 16 bytes. 20 blows 8-byte alignment, 24 does not. (But of course, if 128-bit machines happen, 24-byte addresses will be annoying on 128-bit machines.) But hey, at least it's fixed length. > only 16 byte length addresses now but ability > to lengthen the address later. This will add confusion to implementations, and smacks of variable-length. Experience with OSI implementations shows that many do not handle NSAP's greater than 20 bytes. Absolutely not a good idea. > At this point the consensus among the IPng directorate > and on several of the mailing lists seems fairly clear > (a 16 byte length address is good for those things). Yes, but IMHO, no MORE than 16 bytes. > This is a good time to bring forward your remaining views > about the requirements for address length for IPng. My position can be best summarized as: The SMALLEST possible fixed-length address. And that length better have a good justification for why it cannot be smaller. -- Dan McDonald | Mail: {danmcd,mcdonald}@itd.nrl.navy.mil --------------+ Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html | Naval Research Lab | Phone: (202) 404-7122 #include | Washington, DC | "Rise from the ashes, A blaze of everyday glory" - Rush + From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 06:49:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15123; Fri, 8 Jul 1994 06:45:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA06572; Fri, 8 Jul 1994 06:45:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA06553; Fri, 8 Jul 1994 06:36:45 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14694; Fri, 8 Jul 1994 06:36:43 +1000 (from kre@munnari.OZ.AU) To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Thu, 07 Jul 1994 14:07:10 -0400." <199407071807.OAA16703@radegond.cmf.nrl.navy.mil> Date: Fri, 08 Jul 1994 06:36:40 +1000 Message-Id: <26810.773613400@munnari.OZ.AU> From: Robert Elz Date: Thu, 7 Jul 1994 14:07:10 -0400 From: IPng Area Directors Message-ID: <199407071807.OAA16703@radegond.cmf.nrl.navy.mil> For the purposes of this request, please assume that the transport level and internet level names are the same. Given this assumption, 8 byte fixed length addresses will be just fine, as we'll be changing all the hosts again so soon that we'll be able to re-evaluate the addressing and do something completely different way before 8 byte addresses run out (say in 5 years or so). Obviously if 8 is fine, 16 is fine too, but wasteful. On the other hand, if we assume that host identification (I really don't like thinking of this as transport level naming) and internet names aren't the same, then 8 bytes for the former, and 16 for the latter, fixed length, seems right to me. With a fixed length system id, I could be convinced that a variable length net address is reasonable, if only to allow support for nimrod, if that's what it needs, but something tells me that good support for source routing (with long route paths specified) is more important. To amplify a bit more, we are especially interested in your views on the address length's ability to offer: routing aggregation power topological flexibility adminstrative manageability 16 byte addresses would be fine for all of that, and contrary to what Frank said, I believe have been shown mathematically to be adequate... kre From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 08:25:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17751; Fri, 8 Jul 1994 08:25:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA06700; Fri, 8 Jul 1994 08:25:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06684; Fri, 8 Jul 1994 08:24:49 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17738; Fri, 8 Jul 1994 08:24:46 +1000 (from yakov@watson.ibm.com) Message-Id: <9407072224.17738@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7953; Thu, 07 Jul 94 18:24:46 EDT Date: Thu, 7 Jul 94 18:24:46 EDT To: big-internet@munnari.OZ.AU, sob@harvard.edu Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Thu, 7 Jul 1994 14:07:10 -0400 Allison and Scott, >For the purpose of this request please assume that the transport and >internet layer names are the same. Let me just point out that as far as I can see there is no consensus that "the transport and internet layer names are the same" is an appropriate design choice for IPng. So, in case we'll reach a consensus that this is inappropriate design choice and that IPng should have a "locator" separate from EID, we also need to get a consensus on whether in this scenario a "locator" has to be of variable or of fixed length. >There is a considerable consensus that a fixed length topologically >structured hierarchical address 16 bytes in length is reasonable. There is a problem with the way you formulated this statement -- it does not differentiate between various types of addresses (unicast, multicast, cluster addresses). Based on the above two observations I'd like to suggest that you'll repost your message with the following questions: 1. Assume that the transport and internet layer names are the same, 1.1 Should unicast addresses be encoded as a fixed length fields ? 1.2 Should multicast addresses be encoded as a fixed length fields ? 1.3 Should cluster addresses be encoded as a fixed length fields ? 1.4 If the answer to 1.1, 1.2 and 1.3 is "yes", then should the length of a unicast address be equal to the length of a multicast address and be equal to the length of a cluster address ? 1.5 If the answer to 1.4 is "no", then what should the length of individual address types be ? 1.6 If the answer to 1.1 is "no" then what should be an upper bound on the length of a unicast address ? 1.7 If the answer to 1.2 is "no" then what should be an upper bound on the length of a multicast address ? 1.8 If the answer to 1.3 is "no" then what should be an upper bound on the length of a cluster address ? 2. Assume that the transport and internet layer names are different, 2.1 The same as 1.1 2.2 The same as 1.2 2.3 The same as 1.3 2.4 The same as 1.4 2.5 The same as 1.5 2.6 The same as 1.6 2.7 The same as 1.7 2.8 The same as 1.8 I think that asking more specific questions would help to avoid confusion and get a more meaningful discussion. Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 09:19:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19144; Fri, 8 Jul 1994 09:05:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06753; Fri, 8 Jul 1994 09:05:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06743; Fri, 8 Jul 1994 08:58:33 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15538; Fri, 8 Jul 1994 06:56:38 +1000 (from kre@munnari.OZ.AU) To: Dave Bridgham Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Thu, 07 Jul 1994 15:43:06 -0400." <9407071543.aa10740@quern.epilogue.com> Date: Fri, 08 Jul 1994 06:56:37 +1000 Message-Id: <26837.773614597@munnari.OZ.AU> From: Robert Elz Date: Thu, 7 Jul 94 15:43:06 -0400 From: Dave Bridgham Message-ID: <9407071543.aa10740@quern.epilogue.com> Isn't it rather putting the cart before the horse to pick an address size without specifying the addressing and routing architecture that it's for? There is some truth in this, but I think its reasonable to view the question as... "Do we believe that an addressing and routing architecture can be designed to fit in a fixed length 16 byte address, or could one be designed in 8 bytes, or some other fixed length, or is only a variable length address ever going to be acceptable?" Read that way, the question is entirely reasonable. kre From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 09:20:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19201; Fri, 8 Jul 1994 09:07:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06770; Fri, 8 Jul 1994 09:07:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA06748; Fri, 8 Jul 1994 09:03:59 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16344; Fri, 8 Jul 1994 07:37:47 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id RAA15152; Thu, 7 Jul 1994 17:37:41 -0400 Date: Thu, 7 Jul 1994 17:37:41 -0400 From: Vadim Antonov Message-Id: <199407072137.RAA15152@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, kasten@ftp.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements >A) what analysis was done to show that 16 bytes, rather than being > the bare minimum, is the maximum needed, and You need only very limited number of addresses per machine name. You need only very limited number of machine names per a human being. Now with 64 bit addresses you have more than a million addresses per human being. Please note that addressing or naming concerns only machines which should be treated as separate boxes; we definitely don't need to name/address CPUs or logical gates in massively parallel computers. Isn't another 64 bits enough for administrative overhead? I would contend that 64 bits is already enough for all computers humankind can produce out of Earth's natural resources. And please note that "exponential growth" of Internet is nothing more than a myth -- there is a clearly defined physical limit on the number of machines which need to be addressed; there is NO need to address evey quark in the Universe. Exponential growth is characteritic for emerging markets/technologies; the volume of mature products levels out and expansionist evolution turns into efficiency-cost competition. Estimating the right limiting factors is good engineering; the best solution is the most economical solution *within* the limiting factors. >B) what the flaws were in the posted analyses that indicate that > 16 is the bare minimum. It assumes unreasonable levels of administrative overhead. With overhead like that routing tables will become totally unmanageable anyway. Instead of inventing clever ways of doing effifient routing given absymally stupid address allocation strategies we should concentrate on improving the address alloction to achieve realistic levels of address space utilization *and* get humans and institutions out of the address allocation business. --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 09:25:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19863; Fri, 8 Jul 1994 09:25:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06813; Fri, 8 Jul 1994 09:25:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA06781; Fri, 8 Jul 1994 09:08:15 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18070; Fri, 8 Jul 1994 08:32:39 +1000 (from yakov@watson.ibm.com) Message-Id: <9407072232.18070@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8033; Thu, 07 Jul 94 18:32:40 EDT Date: Thu, 7 Jul 94 18:32:40 EDT To: bound@zk3.dec.com, Big-Internet@munnari.OZ.AU Subject: Source Routing & Provider Selection Ref: Your note of Wed, 06 Jul 94 21:52:02 -0400 Jim, >You should not have to use a source route at dec.com, ibm.com, sun.com... Since source route is expected to be used to support network layer mobility, and since I expect there will be enough people at ibm.com that would utilize network layer mobility, I certainly disagree with your assertion with respect to ibm.com. Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 09:45:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20867; Fri, 8 Jul 1994 09:45:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06875; Fri, 8 Jul 1994 09:45:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA06862; Fri, 8 Jul 1994 09:41:54 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20590; Fri, 8 Jul 1994 09:41:49 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: big-internet@munnari.OZ.AU In-Reply-To: Vadim Antonov's message of Thu, 7 Jul 1994 17:37:41 -0400 <199407072137.RAA15152@titan.sprintlink.net> Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Date: Thu, 7 Jul 94 19:41:05 -0400 Message-Id: <9407071941.aa12191@quern.epilogue.com> Date: Thu, 7 Jul 1994 17:37:41 -0400 From: Vadim Antonov I would contend that 64 bits is already enough for all computers humankind can produce out of Earth's natural resources. Only if the addresses are allocated densely. If the address is all we have (no EID/locator split) then the address has to be used for routing. Therefore it has to be allocated in a way that helps with the routing or the routing tables will be unmanageably large. Instead of inventing clever ways of doing effifient routing given absymally stupid address allocation strategies we should concentrate on improving the address alloction to achieve realistic levels of address space utilization *and* get humans and institutions out of the address allocation business. If addresses are to be used for routing they must be allocated for routing and not administration. If we don't invent clever ways of doing efficient routing then all we have is the way we're doing now which is immensely wastefull of address space. If you know a way, with the current routing architecture, to use the address space much more efficiently and that will scale to a network of 10^9 to 10^12 networks connected in a mesh, then I'm quite interested. If it'll work but not for a full mesh but only heirarchical but a heirarchy that's not under your control, it's probably still interesting. Dave From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 11:20:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22464; Fri, 8 Jul 1994 10:25:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA06934; Fri, 8 Jul 1994 10:25:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA06905; Fri, 8 Jul 1994 10:06:18 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21573; Fri, 8 Jul 1994 10:06:12 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id RAA00649; Thu, 7 Jul 1994 17:06:07 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA00552; Thu, 7 Jul 94 18:05:37 -0600 Date: Thu, 7 Jul 94 18:05:37 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407080005.AA00552@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: kasten@ftp.com (Frank Kastenholz) > > Scott and Alison, > > There have been at least three sizable notes to the big-i list over > the past 4-8 weeks using a bit of math (hard to believe, any sort of > quantitative analysis, eh?) showing that 16 bytes is probably the > absolute minimum needed for long-term, hierarchically scalable > routing. You state that the IPng directorate's consensus (and other > mailing lists as well) seems to be that fixed-16 bytes is adequate. > I would like to know > A) what analysis was done to show that 16 bytes, rather than being > the bare minimum, is the maximum needed, and > B) what the flaws were in the posted analyses that indicate that > 16 is the bare minimum. You must be reading a different set of IETF mailing lists than I. I have seen several notes that included numbers that quantified some the implications of some of their assumptions. However "quantitative analysis" is grotesquely inappropriate for anything that I've seen. None of the analysis have been convincing unless you accept their assumptions. Almost all have been immediately convincing if you do accept their assumptions, and the numbers have been little more than rhetorical embelishments. I have nothing against numbers--quite the contrary. If there had been "quantitative analyses" showing that 16 is minimal, there would not still be many apparently competent, honest, and rational people who continue to say that 8 could be enough. It's an uncomfortable fact of life that "quantitative analysis" is often entirely insufficient for such questions as "how many bits are needed in IPng headers?". Labeling the necessary and appropriate Scientific Wild Assed Guesses as something they are not, or pretending that some of the rhetoric that has gone by is more accurate or relevant because of more numbers is ... well, I don't want to be too insulting so I'll shut up. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 12:16:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24168; Fri, 8 Jul 1994 11:05:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA06980; Fri, 8 Jul 1994 11:05:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA06962; Fri, 8 Jul 1994 10:50:04 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23471; Fri, 8 Jul 1994 10:49:48 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA14529; Thu, 7 Jul 94 19:49:11 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:mohta@necom830.cc.titech.ac.jp id AA01174; Thu, 7 Jul 94 19:49:10 -0500 Date: Thu, 7 Jul 94 19:49:10 -0500 Message-Id: <9407080049.AA01174@benedick.ctd.anl.gov> To: mohta@necom830.cc.titech.ac.jp Subject: Re: Omnibus reply - EIDs Cc: big-internet@munnari.OZ.AU From: "Richard Carlson" Masataka; >Masataka Ohta Writes: >> I disagree again. Tell me what happens with a multi-homed host? > >What happens? Let's see what is actually happening. > > % nslookup titccy.cc.titech.ac.jp. > Name: titccy.cc.titech.ac.jp > Addresses: 131.112.32.173, 131.112.252.3 > > % nslookup -q=ptr 173.32.112.131.in-addr.arpa. > 173.32.112.131.in-addr.arpa name = titccy.cc.titech.ac.jp > > % nslookup -q=ptr 3.252.112.131.in-addr.arpa. > 3.252.112.131.in-addr.arpa name = titccy.cc.titech.ac.jp > > --- Original note modified here (RAC)? >> I run >> into this all the time, and I don't think DNS handles it very well either. > >DNS handles it very well. OK now put this information to use. I will assume that this node is a server and it has 2 Ethernet interfaces. Each Ethernet has a number of user workstations attached. In addition there is a (multi-protocol) router connecting each Ethernet to the rest of the sites network. Nasty things will happen if you put a DNS server on one of these Ethernets. This is because the DNS server uses *it's own address* to sort the list of answer RR's. As an example I will make nodeA = 131.112.32.172, nodeB = 131.112.252.4, and DNS = 131.112.252.3. When nodeB askes for the address of titccy, it gets back 131.112.252.3. That is the local cable so no problem. When nodeA askes DNS for the address of titccy it get back 131.112.252.3 *too*. NodeA will send it's packets to the router, which will forward them to titccy. When titccy replies, packets will go directly to nodeA over the 131.112.32 subnet. So if nodeA tries to verify that the reply came from titccy, it can compare the received address with the Dest socket addr, and nodeA will say they dont match (131.112.32.173 != 131.112.252.3). A smarter nodeA will then scan the list of possible addresses to see if any of them match. In my experience, there are a lot of programs that don't try the list (like xhost). This is the major reason I would like to see the identification name moved out of the internetwork layer. It will make communications with multi- homed nodes simpler. The other advantage is robustness. With IPv4, if one of titccy's interfaces fails, the workstations using that address would stop or fail. With separate names, dynamic routing would allow those workstations to continue operating. >> Since each >> interface has a different address (name), what's the offical name? > >You don't have to have a single official name to identify something. >The only problem is that identification by IP addresses is no good >for real authentication. A single official name is a very good thing to have. In DNS you can have A records and CNAME records. A FCDN may have multiple A records, but you shouldn't have multiple FCDN's pointing to a single A record, you use CNAMEs instead. The offical name is what the A and PTR records both agree to. Some applications will check the A and PTR records and if they don't match, they refuse to start. So an offical name is required while multiple aliases (CNAMEs) may also exist. >> Because I want it to change. > >You can't want so. Ah Ha. I think this may be a problem with my use of the English language. There are lots of things I can want. This doesn't mean I will get them. So when I say "I want it to change" I am expressing my desire for change. I am describing how I would design a protocol that I think it would benefit the Internet community if this change took place. You believe otherwise. >Your reasoning is flawed because you insists location identification >and host identification must be at separate layers without giving >any reason. OK I've given two reasons multi-homed hosts, and robustness. What reasons do you have for insisting that they stay the same? >The internetworking layer is the layer where location identification >is performed. Yes. >The internetworking layer is the layer where host identification is >performed. Today yes. Why must we keep thing this way? >You can't just want to change it. See above. I can want change, I am prepared to accept that I wouldn't get what I want. Are you? >> Try configuring a SunOS 4.1.x box to use DNS without replacing >> the libc.a. Sure you can turn on NIS, but doing it just to get DNS access is >> crazy. > >I admit engineers of Sun are crazy. Is it your point? Well since Solaris 2.x allows admins to call DNS directly, maybe the've learned .-) No my point is that hidding IP numbers in DNS is not as simple as it sounds. If the vendor doesn't allow it or makes it difficult, then users may not use it. >PS > >Reply mechanism of your mail system is broken and your mail has two >"From" fields one of which is impersonating me. I wanted the list to know who I was quoting so I cut and pasted your From line into the body of my message. I hope I made it clearer this time. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 13:05:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28434; Fri, 8 Jul 1994 13:05:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA07128; Fri, 8 Jul 1994 13:05:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA07121; Fri, 8 Jul 1994 12:59:58 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27170; Fri, 8 Jul 1994 12:31:31 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA13654; Thu, 7 Jul 94 19:25:27 -0700 Received: by xirtlu.zk3.dec.com; id AA24114; Thu, 7 Jul 1994 22:25:25 -0400 Message-Id: <9407080225.AA24114@xirtlu.zk3.dec.com> To: big-internet@munnari.OZ.AU Cc: bound@zk3.dec.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Thu, 07 Jul 94 18:24:46 EDT." <9407072224.17738@munnari.oz.au> Date: Thu, 07 Jul 94 22:25:19 -0400 X-Mts: smtp Hi, RE-The question. Can we please not discuss the question Toronto is 17 days away, and just give the Area Directors input on what they sent out. thanks a lot really, /jim From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 15:09:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26865; Fri, 8 Jul 1994 12:25:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA07074; Fri, 8 Jul 1994 12:25:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA07047; Fri, 8 Jul 1994 12:06:33 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24265; Fri, 8 Jul 1994 11:09:28 +1000 (from news@sgi.com) Received: by sgi.sgi.com (940627.SGI.8.6.9/910110.SGI) for Big-Internet@munnari.OZ.AU id SAA10750; Thu, 7 Jul 1994 18:08:57 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: Precedence: list Date: Fri, 8 Jul 1994 00:36:29 GMT > From: kasten@ftp.com (Frank Kastenholz) > > Scott and Alison, > > There have been at least three sizable notes to the big-i list over > the past 4-8 weeks using a bit of math (hard to believe, any sort of > quantitative analysis, eh?) showing that 16 bytes is probably the > absolute minimum needed for long-term, hierarchically scalable > routing. You state that the IPng directorate's consensus (and other > mailing lists as well) seems to be that fixed-16 bytes is adequate. > I would like to know > A) what analysis was done to show that 16 bytes, rather than being > the bare minimum, is the maximum needed, and > B) what the flaws were in the posted analyses that indicate that > 16 is the bare minimum. You must be reading a different set of IETF mailing lists than I. I have seen several notes that included numbers that quantified some the implications of some of their assumptions. However "quantitative analysis" is grotesquely inappropriate for anything that I've seen. None of the analysis have been convincing unless you accept their assumptions. Almost all have been immediately convincing if you do accept their assumptions, and the numbers have been little more than rhetorical embelishments. I have nothing against numbers--quite the contrary. If there had been "quantitative analyses" showing that 16 is minimal, there would not still be many apparently competent, honest, and rational people who continue to say that 8 could be enough. It's an uncomfortable fact of life that "quantitative analysis" is often entirely insufficient for such questions as "how many bits are needed in IPng headers?". Labeling the necessary and appropriate Scientific Wild Assed Guesses as something they are not, or pretending that some of the rhetoric that has gone by is more accurate or relevant because of more numbers is ... well, I don't want to be too insulting so I'll shut up. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 17:25:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08733; Fri, 8 Jul 1994 17:25:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA07375; Fri, 8 Jul 1994 17:25:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA07359; Fri, 8 Jul 1994 17:20:17 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08462; Fri, 8 Jul 1994 17:20:12 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA00418; Fri, 8 Jul 1994 09:21:00 +0200 Message-Id: <199407080721.AA00418@mitsou.inria.fr> To: estrin@usc.edu, daniel@ISI.EDU Cc: Big-Internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Thu, 07 Jul 1994 12:25:21 PDT." <199407071925.AA07596@zephyr.isi.edu> Date: Fri, 08 Jul 1994 09:20:59 +0200 From: Christian Huitema Deborah, Daniel, I stand corrected. By listening to several presentations of PIM, I got the impression that the first packet from the source was "encapsulated and sent to the rendezvous point", which I hastily translated into "source routed to the RVP". Fact is that in the pim-sparse design, the packet is encapsulated within a pim specific "register" message. I believe that we could not use source routing to achieve the same effect, pushing back the functionality from the routers into the hosts. But that is something which would better be discussed in the IDRP than in the Big Internet list. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 18:05:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10054; Fri, 8 Jul 1994 18:05:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA07426; Fri, 8 Jul 1994 18:05:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA07421; Fri, 8 Jul 1994 18:04:53 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10043; Fri, 8 Jul 1994 18:04:50 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA18534; Fri, 8 Jul 1994 01:04:18 -0700 Date: Fri, 8 Jul 1994 01:04:18 -0700 From: Tony Li Message-Id: <199407080804.BAA18534@lager.cisco.com> To: Christian.Huitema@sophia.inria.fr Cc: estrin@usc.edu, tli@cisco.com, yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU, estrin@ISI.EDU In-Reply-To: Christian Huitema's message of Fri, 08 Jul 1994 09:45:12 +0200 <199407080745.AA00454@mitsou.inria.fr> Subject: Source Routing & Provider Selection That was the first problem. Now the second one, i.e. performance. The SDRP concept of adjacency is expressed in terms only known to BGP. But BGP is not generally in the fast path. Explain how you can achieve Yakov's "first class citizenship" status. SDRP itself is not generally in the fast path. But we want it to be there... In any case, putting a AS-level routing table into the fast path would not be out of the question for IPv4. I would hope that we can do similar things with SIPP. You are correct in that calculating cluster adjacencies is non-trivial with SIPP because there is nothing in the address to indicate just how many bits you really intend to match on. I believe that this problem is orthogonal to source routing and is an inherent problem with cluster addresses with arbitrary and implicit numbers of significant bits. However, assuming someone can tell us how to do this, there should be some relation IN(SIPP address, cluster address). The question for source routing is then when to advance the source route pointer. I believe that the correct operation is to advance the pointer only when the next hop is NOT in the current cluster. This is somewhat annoying as you actually have to route within the cluster based on the NEXT cluster address. The alternative is to advance the source route pointer when you enter a cluster, but this makes it difficult to analyze if you're in the middle of a strict source route as you actually have to back up. Summary: Source routing is still messy. Cluster addresses don't help. Still gotta think about strict cluster source routes. Source routing requirements are still not clear. Crystal ball, anyone? When we figure out what we want to do, there are ways of making it go fast, and ways of making it go slow. Tony From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 18:08:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10102; Fri, 8 Jul 1994 18:08:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA07446; Fri, 8 Jul 1994 18:07:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA07416; Fri, 8 Jul 1994 17:55:53 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09383; Fri, 8 Jul 1994 17:44:24 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA00454; Fri, 8 Jul 1994 09:45:13 +0200 Message-Id: <199407080745.AA00454@mitsou.inria.fr> To: estrin@usc.edu Cc: tli@cisco.com, yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU, estrin@ISI.EDU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Thu, 07 Jul 1994 12:25:21 PDT." <199407071925.AA07596@zephyr.isi.edu> Date: Fri, 08 Jul 1994 09:45:12 +0200 From: Christian Huitema Deborah, I had come to the same conclusion when analyzing the differences between SDRP and "basic loose source routing". Out of the list that you (and Yakov) mentioned, "cluster addressing" is already in the SIPP spec - this is simple. The next point is "strict or loose source routing". If I understand SDRP correctly, the "strictness" is in terms of "autonomous system adjacencies". The objective is indeed to avoid packets wandering through unspecified domains between two hops on the route. This poses two problems, i.e. the definition of adjacencies with cluster addresses and the insertion in the "fast path". SDRP only handles a two level hierarchy, i.e. the IGP/EGP split. A "cluster address", in SDRP, is essentially an AS number. But a "cluster address", in SIPP, can be expressed at many more levels: a provider, a region within a provider network, a subscriber within that area, an area within the subscriber network. Lets call these levels P, R, S and A. An address is normally expressed as P.R.S.A.H. Now, define which of these are adjacent: P1.R1.S1.A1.H1 P1.R1.S1.A2.0 P1.R1.S1.0.0 P1.R1.S2.0.0 P1.R2.0.0.0 P1.0.0.0.0 P2.R3.S3.A3.H3 The topology is: +- S2 | R1 -+- S1 -+- A1 -+- H1 (P1) | | R2 +- A2 -+- | (P2) R3 -+- S3 -+- A3 -+- H3 Be sure to express the notion in a way that does make hypothesis on the internal structure of addresses - clusters end at arbitrary bits boundaries. That was the first problem. Now the second one, i.e. performance. The SDRP concept of adjacency is expressed in terms only known to BGP. But BGP is not generally in the fast path. Explain how you can achieve Yakov's "first class citizenship" status. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 19:25:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12856; Fri, 8 Jul 1994 19:25:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA07581; Fri, 8 Jul 1994 19:25:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA07565; Fri, 8 Jul 1994 19:12:51 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12542; Fri, 8 Jul 1994 19:12:38 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 8 Jul 94 18:06:37 +0900 From: Masataka Ohta Message-Id: <9407080906.AA17813@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: big-internet@munnari.OZ.AU Date: Fri, 8 Jul 94 18:06:35 JST In-Reply-To: <199407071807.OAA16703@radegond.cmf.nrl.navy.mil>; from "IPng Area Directors" at Jul 7, 94 2:07 pm X-Mailer: ELM [version 2.3 PL11] > At this time it would appear to us that there is considerable consensus > that a fixed length, topologically structured, hierarchical > address 16 bytes in length is reasonable for an IPng (that is > meets the needs of the very very large-scale Internet). There seems to be a consensus that we need not-topoligically-strucutred EID which is AT MOST 64 bit long. There seems to be a consensus that we need additional topoligically- strucutred information which is AT LEAST 64 bit long. So, combining them, I don't think it so wrong to have a fixed length, HALF topologically structured, hierarchical address 16 bytes in length, whose lower 8 bytes is enough for identification. But... > We understand that we are being a bit vague in using the term "address" in > light of the question we asked two weeks ago. For the purposes of this > request, please assume that the transport level and internet level names > are the same. with the utter confusion on layering, I'm afraid you don't understand the issue at all. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 20:05:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13935; Fri, 8 Jul 1994 20:05:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA07630; Fri, 8 Jul 1994 20:05:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA07613; Fri, 8 Jul 1994 19:54:22 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13556; Fri, 8 Jul 1994 19:54:13 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Jul 1994 10:52:11 +0100 To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Fri, 08 Jul 94 18:06:35 +0200." <9407080906.AA17813@necom830.cc.titech.ac.jp> Date: Fri, 08 Jul 94 10:52:08 +0100 Message-Id: <1244.773661128@cs.ucl.ac.uk> From: Jon Crowcroft >with the utter confusion on layering, I'm afraid you don't understand >the issue at all. Masataka Ohta this is an uncontructive remark if there's confusion it is to do with too many architects, and not enough builders jon From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 20:10:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10762; Fri, 8 Jul 1994 18:25:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA07484; Fri, 8 Jul 1994 18:25:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA07440; Fri, 8 Jul 1994 18:06:28 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10077; Fri, 8 Jul 1994 18:06:16 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Jul 1994 09:05:54 +0100 To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Cc: Big-Internet@munnari.OZ.AU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Thu, 07 Jul 94 18:05:37 MDT." <9407080005.AA00552@rhyolite.denver.sgi.com> Date: Fri, 08 Jul 94 09:05:51 +0100 Message-Id: <860.773654751@cs.ucl.ac.uk> From: Jon Crowcroft >still be many apparently competent, honest, and rational people who >continue to say that 8 could be enough. i don't claim to be rational, but i certainly think 8 could be enough, with option for another 8 iff&whenn (=when and only when) needed the problem is that everyone wants to be an architect - that means they all introduce a bunch of implict style&fashion (the assumptions you refer to) and since the assumptions are different, but not all stated, comparison is nigh on impossible i think the only PC answer to lack of consensus on a particular value of length for FIXED length is an ISO style compromise: VARIABLE length. but both failing to grasp a fixed length, or choosing a variable because people can't democratically reach a right answer is a failure. [note someoen might come up with some new ultimately satisfying reason for variable, though] the Internet has 2.5M attached hosts, and works fairly well. this with 32 bits of very BADLY allocated address space. a trivial moronic scheme of allocation of another 32bits would give 2*32 as many class C networks as we have now. a fairly simple hierarchical allocation of these would not scale the routing tables much - more bits is just sloppy, it can't give you smaller routing tables. It might let you do some things that make them bigger (aka more 'flexible' for policies) - but so might other techniques (tunnels, etc) still not convinced. jon From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 20:18:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12297; Fri, 8 Jul 1994 19:05:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA07538; Fri, 8 Jul 1994 19:05:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA07533; Fri, 8 Jul 1994 19:00:21 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12139; Fri, 8 Jul 1994 19:00:09 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 8 Jul 94 17:45:56 +0859 From: Masataka Ohta Message-Id: <9407080846.AA17679@necom830.cc.titech.ac.jp> Subject: Re: Omnibus reply - EIDs To: RACarlson@anl.gov (Richard Carlson) Date: Fri, 8 Jul 94 17:45:54 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407080049.AA01174@benedick.ctd.anl.gov>; from "Richard Carlson" at Jul 7, 94 7:49 pm X-Mailer: ELM [version 2.3 PL11] > >> I disagree again. Tell me what happens with a multi-homed host? > >> I run > >> into this all the time, and I don't think DNS handles it very well either. You completely misunderstand DNS. > As an example I will make nodeA = 131.112.32.172, nodeB = 131.112.252.4, > and DNS = 131.112.252.3. When nodeB askes for the address of titccy, it > gets back 131.112.252.3. When nodeB, or whoever, askes for the addressES of titccy, it gets back 131.112.252.3 AND 131.112.32.173. The sorting order is unspecified. > In my experience, > there are a lot of programs that don't try the list (like xhost). So, xhost, not DNS, is broken. > This is the major reason I would like to see the identification name moved > out of the internetwork layer. There is no reason. > With separate names, dynamic routing would allow > those workstations to continue operating. Both of the separated names belongs to the internetworking layer. > A single official name is a very good thing to have. That's true for host name, not for IPv4 addresses nor EIDs. > So an offical name is > required while multiple aliases (CNAMEs) may also exist. which has nothing to do with EIDs. You now completely miss the point. > >> Because I want it to change. > > > >You can't want so. > > Ah Ha. I think this may be a problem with my use of the English language. Yes. > >Your reasoning is flawed because you insists location identification > >and host identification must be at separate layers without giving > >any reason. > > OK I've given two reasons multi-homed hosts, and robustness. What reasons > do you have for insisting that they stay the same? You have explaind why you need two separate things. I haven't said they stay the same. You haven't explaind why you need two separate things in different layers. I have proved they stay in the same, internetworking, layer. I don't mind if you create two new layers, internetworking-identification layer and internetworking-locating layer. But it has nothing to do with transport layers. That's all. > >The internetworking layer is the layer where host identification is > >performed. > > Today yes. Why must we keep thing this way? Because EID does not contain protocol types nor port numbers, EID can't belongs to the transport layer. > No my point is that hidding IP numbers in DNS is not as > simple as it sounds. If someone thinks hidding IP numbers in DNS is simple, he should be crazy. > I wanted the list to know who I was quoting so I cut and pasted your From > line into the body of my message. What you have innocently done is forgery. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 20:57:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14116; Fri, 8 Jul 1994 20:09:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA07649; Fri, 8 Jul 1994 20:09:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA07627; Fri, 8 Jul 1994 20:04:37 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10892; Fri, 8 Jul 1994 18:30:00 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 8 Jul 94 17:19:11 +0900 From: Masataka Ohta Message-Id: <9407080819.AA17569@necom830.cc.titech.ac.jp> Subject: Re: Source Routing & Provider Selection To: estrin@usc.edu Date: Fri, 8 Jul 94 17:19:08 JST Cc: tli@cisco.com, Christian.Huitema@sophia.inria.fr, yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU, estrin@ISI.EDU In-Reply-To: <199407071957.AA08296@zephyr.isi.edu>; from "Deborah Estrin" at Jul 7, 94 12:57 pm X-Mailer: ELM [version 2.3 PL11] > 1. flows will often use generic unicast but will also make use of > source routing more than pure datagrams in order to get the QoS > desired. If you have QoS requirements, you should set up a flow with the QoS specification, not the source route specification. Then, packets in the flow will have no source route specification and be forwarded by its flow ID. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 23:45:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20746; Fri, 8 Jul 1994 23:45:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07914; Fri, 8 Jul 1994 23:45:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07885; Fri, 8 Jul 1994 23:28:37 +1000 Precedence: list Received: from vinegar.sesqui.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20001; Fri, 8 Jul 1994 23:28:32 +1000 (from bmanning@sesqui.net) Received: by vinegar.sesqui.net (4.1/SMI-4.1 Jun93 - wcm) id AA20813; Fri, 8 Jul 94 08:29:08 CDT From: bmanning@sesqui.net (William Manning) Message-Id: <9407081329.AA20813@vinegar.sesqui.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: Big-Internet@munnari.OZ.AU Date: Fri, 8 Jul 1994 08:29:07 -0500 (CDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 42 I vote variable in 8 byte chunks. -bill From owner-Big-Internet@munnari.OZ.AU Fri Jul 8 23:59:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20840; Fri, 8 Jul 1994 23:49:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07931; Fri, 8 Jul 1994 23:49:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07882; Fri, 8 Jul 1994 23:27:29 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19957; Fri, 8 Jul 1994 23:27:25 +1000 (from kre@munnari.OZ.AU) To: "Richard Carlson" Cc: big-internet@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs In-Reply-To: Your message of "Thu, 07 Jul 1994 19:49:10 EST." <9407080049.AA01174@benedick.ctd.anl.gov> Date: Fri, 08 Jul 1994 23:27:22 +1000 Message-Id: <26914.773674042@munnari.OZ.AU> From: Robert Elz Date: Thu, 7 Jul 94 19:49:10 -0500 From: "Richard Carlson" Message-ID: <9407080049.AA01174@benedick.ctd.anl.gov> One of the problems (I see) in the IETF is the tendancy to overreact badly to problems that are really no more than implementation choices (and in some cases obvious bugs). This looks to be an example of that ... This is because the DNS server uses *it's own address* to sort the list of answer RR's. BIND's server's algorithm is a little more complicated than that, but you're right, it does send addresses in orders that aren't really what clients would prefer. The answer to this isn't to throw out the addressing structure and start over - it's to fix the implementation so it works the way that makes more sense. The resolver distributed with the latest (currently beta) version of BIND fixes this, allowing clients to sort replies in whatever order makes sense to them. This is the major reason I would like to see the identification name moved out of the internetwork layer. It will make communications with multi- homed nodes simpler. I disagree with this - it will complicate the layer below IPng (figuring out which path to use to get to that ambiguous address) and deny hosts the ability to prefer one specific access path to a host with a lot of extra mechanism. The other advantage is robustness. With IPv4, if one of titccy's interfaces fails, the workstations using that address would stop or fail. With separate names, dynamic routing would allow those workstations to continue operating. This is one reason I prefer separate host id naming to net level addressing - the communications should be using the host id (EID) for identification of connections (either in the TCP sense, or the looser "communicating UDP applications" sense) and the net level address to choose the interface to the host to be used. There are times when I would much prefer communications to fail than to allow them to fall back to going over a different path into the destination host - if all that happens at some level lower than that which I can reasonably control (which it does if the routers along the way don't have the information about what I'm doing). Its true that currently (IPv4 architecture) the separate address for each interface can cause problems - that's largely because that address is used for too many other purposes, if it did no more than identify the delivery (or sending) interface of one particular packet in transit, then I suspect that most of the current desire to divorce IP level addressing from interfaces would not exist - yet another case of overreaction (or perhaps the same case). Would those who prefer interface independant IP addressing please indicate how I (as a host, or application, or even user) arrange in a topology like ... |-----|----fddi---+--- me ......(path through several hops)...| rtr | host |-----|----eth----+--- that a datagram I send be delivered to the multi-homed host via (and only via) its ethernet interface? kre From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 00:29:43 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19204; Fri, 8 Jul 1994 23:09:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01121 Fri, 8 Jul 1994 23:07:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07841; Fri, 8 Jul 1994 23:05:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07836; Fri, 8 Jul 1994 22:56:49 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18617; Fri, 8 Jul 1994 22:53:23 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA21076; Fri, 8 Jul 94 07:55:10 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad25952; 8 Jul 94 12:50 GMT Date: Fri, 8 Jul 94 07:51 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <03940708125130/0003858921NA3EM@mcimail.com> Well, I have thought a lot about this. Variable is out. Human's, being the way they are (notice the structure, us IPngers can't be humans :), and corporate creatures, being a more exasperating form of human's, cannot cope with variable decision processes. A lot of people will spin their wheels with the variable length and what will emerge will be a recommendation, followed by everyone eventually on how to structure the address. Just like NSAPs.... People LIKE fixed things. The question is if it is fixed, is it fixed enough over time. So we hedge our bets by doubling our best guess and then do a few things to weaken that guess by adding functionality into the larger number. 8 bytes is out. We really need the EID-Locator paradigm. EIDs assigned somehow to systems and SOME processes (not all, not even a significate number of them). Locators assigned to interfaces dynamically at interface start time (or transition time with a mobile interface). Breaking up 8 bytes for two address spaces gets us back to much of the IPv4 problems; not enough growth. Because part of the address is interface specific and part is system or even process specific, it would seem that Internet and Transport addresses are not the same, rather Transport addresses are made from PART of the Internet address plus something, like port number. 16 bytes SHOULD do it, eventhough it leaves the political NSAP migration issue open. But even if we go to 20 or 24 bytes and put in our model for addressing, NSAPs would need a migration plan. A number of schemes and dreams have been put forth to create a hierarchical, topological, managable model for those 16 bytes. This is good becuase it shows that it fits a lot of people's perceptions of an address. Yes we have too many architects, but then it takes a number of cooks to make a good Stone Soup! I have already expoused my bit twiddle for dividing up those 16 bytes. I naturally think it is one of the better models ;-). I am flexible, however, as long as the eventual format works for the big corporations as well as the big providers and moderate to small users. I fear source routing. Securing a network where source routing is used scares me; but I think that is just because I don't know enough yet on this subject. Whether the source routing is SDRP or NIMROD or something else is mute. IPng will need to handle source routing well, but should not require it in all headers. And source routing should not be a part of the Internet address, but then I don't THINK anyone proposed that.... OK, my $0.01 worth. See you all in Toronto (say that with a rolled R and emphasis on the 'ron' :). Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 01:29:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22487; Sat, 9 Jul 1994 00:25:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA08088; Sat, 9 Jul 1994 00:25:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA08074; Sat, 9 Jul 1994 00:22:18 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19864; Fri, 8 Jul 1994 23:24:01 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Fri, 8 Jul 1994 09:23:46 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 8 Jul 1994 09:23:46 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA16575; Fri, 8 Jul 94 09:21:42 EDT Date: Fri, 8 Jul 94 09:21:42 EDT Message-Id: <9407081321.AA16575@mailserv-D.ftp.com> To: vjs@rhyolite.denver.sgi.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU Content-Length: 1058 > From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) > > From: kasten@ftp.com (Frank Kastenholz) > > > > Scott and Alison, > > > > There have been at least three sizable notes to the big-i list over > > the past 4-8 weeks using a bit of math.... > > You must be reading a different set of IETF mailing lists than I. > > I have seen several notes that included numbers that quantified some > the implications of some of their assumptions. Well, I don't recall seeing these, but for the last couple of weeks I've been rather busy doing other things and have not been able to follow BIG-I/SIPP/TUBA/etc as well as I would have liked. They may easily have slipped my attention. In any event, if there are two analyses, coming to differing conclusions, then at least one (if not both) is wrong in either its logic or its underlying assumptions. Perhaps the discussion should be centering on these analyses, their logic, and their assumptions, yes? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 01:29:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23293; Sat, 9 Jul 1994 00:45:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA08125; Sat, 9 Jul 1994 00:45:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA08102; Sat, 9 Jul 1994 00:27:48 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19858; Fri, 8 Jul 1994 23:24:01 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Fri, 8 Jul 1994 09:23:42 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 8 Jul 1994 09:23:42 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA16569; Fri, 8 Jul 94 09:21:38 EDT Date: Fri, 8 Jul 94 09:21:38 EDT Message-Id: <9407081321.AA16569@mailserv-D.ftp.com> To: kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: dab@epilogue.com, big-internet@munnari.OZ.AU Content-Length: 1116 > From: Robert Elz > From: Dave Bridgham > > Isn't it rather putting the cart before the horse to pick an address > size without specifying the addressing and routing architecture that > it's for? > > There is some truth in this, but I think its reasonable to > view the question as... > > "Do we believe that an addressing and routing architecture > can be designed to fit in a fixed length 16 byte address, > or could one be designed in 8 bytes, or some other fixed > length, or is only a variable length address ever going to > be acceptable?" So perhaps we should let the people who have been studying and developing routing architectures answer the question? I could certainly give an opinion as to whether we can build a 5,000 foot tall building or not -- but since I am not a structural engineer and haven't really thought about the problem, that opinion would have about the same chances of being correct as flipping a coin... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 01:52:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25611; Sat, 9 Jul 1994 01:45:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA08194; Sat, 9 Jul 1994 01:45:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08180; Sat, 9 Jul 1994 01:29:46 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22791; Sat, 9 Jul 1994 00:29:53 +1000 (from pvm@ISI.EDU) Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 8 Jul 1994 07:29:50 -0700 Message-Id: <199407081429.AA00326@zephyr.isi.edu> To: Robert Elz Cc: "Richard Carlson" , big-internet@munnari.OZ.AU Reply-To: pvm@isi.edu Subject: Re: Omnibus reply - EIDs In-Reply-To: Your message of Fri, 08 Jul 1994 23:27:22 +1000. <26914.773674042@munnari.OZ.AU> Date: Fri, 08 Jul 94 07:29:50 PDT From: Paul Mockapetris > One of the problems (I see) in the IETF is the tendancy to > overreact badly to problems that are really no more than > implementation choices (and in some cases obvious bugs). > > This looks to be an example of that ... > > This is because the DNS server uses *it's own address* to > sort the list of answer RR's. > > BIND's server's algorithm is a little more complicated than > that, but you're right, it does send addresses in orders that > aren't really what clients would prefer. > > The answer to this isn't to throw out the addressing structure > and start over - it's to fix the implementation so it works the > way that makes more sense. The resolver distributed with the > latest (currently beta) version of BIND fixes this, allowing > clients to sort replies in whatever order makes sense to them. Just so. Asking the server to sort replies is a "close, but no cigar" strategy, except perhaps if the query contains enough information to specify a reasonable sort ordering. Sorting should be done in the resolver, or at the resolver's direction. I suppose you could use the return address in the query as a rough key, but then the server might need to know network topology around the resolver. From a robustness point of view, the server should randomize the RRs, just to keep resolver implementations that rely on order from springing up. This is similar to making a requirement that root servers refuse to do recursive queries. (perhaps we need an RFC detailing was to prevent noxious fungii, rot, blights, etc on the DNS tree.) paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 02:05:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26271; Sat, 9 Jul 1994 02:05:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08229; Sat, 9 Jul 1994 02:05:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08226; Sat, 9 Jul 1994 02:00:09 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26182; Sat, 9 Jul 1994 01:59:57 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA02184; Fri, 8 Jul 1994 18:00:43 +0200 Message-Id: <199407081600.AA02184@mitsou.inria.fr> To: pvm@isi.edu Cc: Robert Elz , "Richard Carlson" , big-internet@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs In-Reply-To: Your message of "Fri, 08 Jul 1994 07:29:50 PDT." <199407081429.AA00326@zephyr.isi.edu> Date: Fri, 08 Jul 1994 18:00:42 +0200 From: Christian Huitema Paul, You are absolutely right. In fact, there are a couple of principles that should be aplied here, like: * if in doubt, pick at random * end to end is better, keep statistics... Chrsitian Huitema From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 02:08:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26441; Sat, 9 Jul 1994 02:08:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08246; Sat, 9 Jul 1994 02:08:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08212; Sat, 9 Jul 1994 01:51:18 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25805; Sat, 9 Jul 1994 01:51:14 +1000 (from kre@munnari.OZ.AU) To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Fri, 08 Jul 1994 09:21:38 EDT." <9407081321.AA16569@mailserv-D.ftp.com> Date: Sat, 09 Jul 1994 01:51:12 +1000 Message-Id: <26956.773682672@munnari.OZ.AU> From: Robert Elz Date: Fri, 8 Jul 94 09:21:38 EDT From: kasten@ftp.com (Frank Kastenholz) Message-ID: <9407081321.AA16569@mailserv-D.ftp.com> So perhaps we should let the people who have been studying and developing routing architectures answer the question? Of course, from the number of copies of Alison & Scott's message I saw, I'd be surprised if there was anyone even vaguelly concerned with the state of the net who wasn't asked their opinion. Certainly those people should reply, and soon. I could certainly give an opinion as to whether we can build a 5,000 foot tall building or not I doubt its quite fair to suggest that almost any of the people replying to these messages know as little about routing & addressing as you (we all) know about building skyscrapers. I agree that it would be useless to go out into the street and ask passers by their opinions on this issue, I don't regard the people on any of the concerned lists (just possibly excepting the IETF list) as quite the equivalent of street walkers... kre From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 02:45:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27670; Sat, 9 Jul 1994 02:45:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08306; Sat, 9 Jul 1994 02:45:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08287; Sat, 9 Jul 1994 02:26:36 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26895; Sat, 9 Jul 1994 02:26:19 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA28632; Fri, 8 Jul 94 09:17:18 -0700 Received: by xirtlu.zk3.dec.com; id AA05941; Fri, 8 Jul 1994 12:17:08 -0400 Message-Id: <9407081617.AA05941@xirtlu.zk3.dec.com> To: Jon Crowcroft Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Fri, 08 Jul 94 10:52:08 BST." <1244.773661128@cs.ucl.ac.uk> Date: Fri, 08 Jul 94 12:17:01 -0400 X-Mts: smtp >if there's confusion it is to do with too many architects, and not >enough builders I agree. /jim From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 02:48:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27735; Sat, 9 Jul 1994 02:48:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08324; Sat, 9 Jul 1994 02:48:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08301; Sat, 9 Jul 1994 02:40:32 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27401; Sat, 9 Jul 1994 02:40:16 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 8 Jul 1994 09:39:42 -0700 Date: Fri, 8 Jul 1994 09:39:42 -0700 Message-Id: <199407081639.AA02626@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: mohta@necom830.cc.titech.ac.jp Cc: tli@cisco.com, Christian.Huitema@sophia.inria.fr, yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU In-Reply-To: Masataka Ohta's message of Fri, 8 Jul 94 17:19:08 JST <9407080819.AA17569@necom830.cc.titech.ac.jp> Subject: Source Routing & Provider Selection Reply-To: estrin@usc.edu From: Masataka Ohta In-Reply-To: <199407071957.AA08296@zephyr.isi.edu>; from "Deborah Estrin" at Jul 7, 94 12:57 pm X-Mailer: ELM [version 2.3 PL11] > 1. flows will often use generic unicast but will also make use of > source routing more than pure datagrams in order to get the QoS > desired. If you have QoS requirements, you should set up a flow with the QoS specification, not the source route specification. I am very confused as toowhat you are saying/asking... Then, packets in the flow will have no source route specification and be forwarded by its flow ID. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 03:05:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28376; Sat, 9 Jul 1994 03:05:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08356; Sat, 9 Jul 1994 03:05:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08311; Sat, 9 Jul 1994 02:45:30 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27662; Sat, 9 Jul 1994 02:45:19 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 8 Jul 1994 09:45:13 -0700 Date: Fri, 8 Jul 1994 09:45:13 -0700 Message-Id: <199407081645.AA03232@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: emv@garnet.msen.com Cc: big-internet@munnari.OZ.AU In-Reply-To: Edward Vielmetti's message of Fri, 8 Jul 94 09:50 EDT Subject: Source Routing & Provider Selection Reply-To: estrin@usc.edu Provider selection is *an* applicaiton of source routinkg but please do not equate the need for source routing with the need for provider selection! Source routing is needed for other services related to ToS and finding routes that can grant reservation requests...THESE are the dominant demand drivers longer term...in my opinion of course...:} D. From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 03:08:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28426; Sat, 9 Jul 1994 03:08:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08378; Sat, 9 Jul 1994 03:08:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08335; Sat, 9 Jul 1994 02:50:02 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27763; Sat, 9 Jul 1994 02:50:00 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA09591; Fri, 8 Jul 94 09:52:02 -0700 Date: Fri, 8 Jul 94 09:52:02 -0700 From: Eric Fleischman Message-Id: <9407081652.AA09591@atc.boeing.com> To: avg@sprint.net, big-internet@munnari.OZ.AU, kasten@ftp.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: ericf@munnari.OZ.AU >>A) what analysis was done to show that 16 bytes, rather than being >> the bare minimum, is the maximum needed, and > >You need only very limited number of addresses per machine name. >You need only very limited number of machine names per a human being. Dear Vadim, I am seeing from my knot-hole a growing tendency on our networks to attach devices (e.g., doors, elevators, security shacks, forklifts, etc.) which are totally unrelated to "human beings" or to "computers". I believe that this tendency is growing. We also are seeing many creative new uses of "computers" (e.g., PDAs) which were unknown a few years ago which are greatly proliferating the numbers of "computers" used by individuals. Many call this twin phenomena "toasternet". I believe that toasternet is making the the world view underlying your argument above obsolete. I further believe that IPng must be designed with toasternet in mind. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 04:25:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01185; Sat, 9 Jul 1994 04:25:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08501; Sat, 9 Jul 1994 04:25:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08487; Sat, 9 Jul 1994 04:20:19 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01057; Sat, 9 Jul 1994 04:20:13 +1000 (from barney@databus.databus.com) Date: Fri, 8 Jul 94 14:21 EDT Message-Id: <9407081421.AA25869@databus.databus.com> From: Barney Wolff To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs Content-Length: 859 Content-Type: text > Date: Fri, 08 Jul 1994 23:27:22 +1000 > From: Robert Elz > > Would those who prefer interface independant IP addressing > please indicate how I (as a host, or application, or even user) > arrange in a topology like ... > > |-----|----fddi---+--- > me ......(path through several hops)...| rtr | host > |-----|----eth----+--- > > that a datagram I send be delivered to the multi-homed host > via (and only via) its ethernet interface? Answer 1: loose source route listing (only) the ethernet's locator Answer 2: You can't do that even today, if the router's ethernet interface is down and the host has ip-forwarding enabled, and advertises routes (yes, I admit how unlikely this scenario is :-). Barney Wolff From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 04:48:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29111; Sat, 9 Jul 1994 03:25:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08418; Sat, 9 Jul 1994 03:25:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08364; Sat, 9 Jul 1994 03:06:01 +1000 Precedence: list From: daniel@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28390; Sat, 9 Jul 1994 03:05:56 +1000 (from daniel@ISI.EDU) Received: from dza.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Fri, 8 Jul 1994 10:05:35 -0700 Date: Fri, 8 Jul 94 10:05:19 PDT Posted-Date: Fri, 8 Jul 94 10:05:19 PDT Message-Id: <9407081705.AA07221@dza.isi.edu> Received: by dza.isi.edu (4.1/4.0.3-4) id ; Fri, 8 Jul 94 10:05:19 PDT To: 0003858921@mcimail.com Cc: big-internet@munnari.OZ.AU In-Reply-To: "Robert G. Moskowitz"'s message of Fri, 8 Jul 94 07:51 EST <03940708125130/0003858921NA3EM@mcimail.com> Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: daniel@ISI.EDU > Well, I have thought a lot about this. > Variable is out. Human's, being the way they are (notice the structure, us > IPngers can't be humans :), and corporate creatures, being a more > exasperating form of human's, cannot cope with variable decision processes. > A lot of people will spin their wheels with the variable length and what > will emerge will be a recommendation, followed by everyone eventually on how > to structure the address. Just like NSAPs.... > People LIKE fixed things. The question is if it is fixed, is it fixed > enough over time. So we hedge our bets by doubling our best guess and then > do a few things to weaken that guess by adding functionality into the larger > number. From a research standpoint, it seems like our priority is to figure out what type of addressing is best for IPng. If we decide that fixed length addresses are better technology than variable length addresses, then what people LIKE and informing people on how to assign variable addresses are moot points. If, on the other hand, we decide that variable length addresses better fill the needs of the next generation IP, then we should expend considerable effort figuring out how to do them *right* this time, avoiding previous pitfalls, and helping people assign them and like them. Daniel From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 05:11:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02634; Sat, 9 Jul 1994 05:11:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA08600; Sat, 9 Jul 1994 05:11:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08536; Sat, 9 Jul 1994 04:49:28 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29247; Sat, 9 Jul 1994 03:28:15 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id KAA26980; Fri, 8 Jul 1994 10:28:06 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA03314; Fri, 8 Jul 94 11:27:29 -0600 Date: Fri, 8 Jul 94 11:27:29 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407081727.AA03314@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: kasten@ftp.com (Frank Kastenholz) > > > > I have seen several notes that included numbers that quantified some > > the implications of some of their assumptions. > ... > In any event, if there are two analyses, coming to differing > conclusions, then at least one (if not both) is wrong in either its > logic or its underlying assumptions. Perhaps the discussion should be > centering on these analyses, their logic, and their assumptions, yes? How can one label some plausible assumptions about the future "wrong" and others "right" without using a time machine? I wrote something like this before, but deleted it. I guess it needs saying ... It would be very easy today, in the summer of 1994, after years and no evident progress on IPng, to consign the IETF to the same dust heap as the organizations that brought us the OSI protocols and GOSIP mandates. If you look at only the surface of the IETF, it seems to have become a Standard standards organizations. As Jon Crowcraft puts it, "everyone wants to be an architect." There are endless empty arguments in the "yes it is; no it isn't" style about the implications of generally unstated, unacknowledge, evidently often unknown assumptions. People continue make up new jargon, and then try to think of definitions, all in the name of solving obvious and clear problems. Even those proposing radical solutions are unable to say precisely what they want. There is a consequent cowardly enthusiasm to use solutions in the style of TP0-TP4 and CONS/CLNS, to "just make it variable" or "let's make it optional and move on". There is also a lot of hubris. The delusions of grandure in the IETF are familiar to anyone who has attended standard standards meetings. From the mailing lists it's evident that many people think that the IETF has some influence on or even control of the future of the Internet. In reality, the IETF is exactly as powerless as the CCITT and the governments that wrote those GOSIP's. The days when the IETF was in charge of the Internet passed years ago, when the NSF ceased to pay all of the bills, when the IETF stopped worrying about what went in which routing tables and started only designing new protocols. No one will ever willing send or receive production IPng packets. No one will ever willingly move host from IPv4 to IPng. All IPng packets will be from experimentors and those forced to use IPng. If IPng helps enough of the addressing and routing problems and is not too painful, it will get a toehold in the market in 5 years. Eventually, in 10 or 15 years, if IPng is enough better than its competators, including IPv4 and IPX, it might become important. What are the chances of IPng surviving the century with as much vitality as TP4 has today? More than 30%?--I think so. More than 80%--no way. I do not think things are as bleak nor the process quite as Standard as they seem. With a little luck, the SIPP and TUBA people will continue to ignore the babble in the mailing lists and at the meetings, and ignore the Area Directors, ISEG, and Directorate. With luck, they'll produce some code, deploy it, the market will pick one or two, and everything will be continue to be wonderful. If that doesn't happen, then IPX or some other rogue protocol will solve the addressing and routing problems while also carrying IP packets among "legacy systems," the old IETF will become accredited and "liase" with the ITU, IEEE, and ANSI, the young turks will form their own engineering task force, and life will go on. Ah, well. Remember when TCP was a rogue protocol? Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 06:05:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04570; Sat, 9 Jul 1994 06:05:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA08660; Sat, 9 Jul 1994 06:05:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08655; Sat, 9 Jul 1994 06:04:37 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04546; Sat, 9 Jul 1994 06:04:34 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id QAA19446; Fri, 8 Jul 1994 16:04:31 -0400 Date: Fri, 8 Jul 1994 16:04:31 -0400 From: Vadim Antonov Message-Id: <199407082004.QAA19446@titan.sprintlink.net> To: craig@aland.bbn.com, ericf@atc.boeing.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: avg@sprint.net, big-internet@munnari.OZ.AU > I agree that we're seeing a proliferation of devices with computers >in them. Yep, but they don't generally need to have the universal connectivity. Neither universal connectivity is desireable for them. I definitely don't want somebody hacking my W.C. :-) --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 06:19:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02524; Sat, 9 Jul 1994 05:05:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA08557; Sat, 9 Jul 1994 05:05:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08539; Sat, 9 Jul 1994 04:51:54 +1000 Precedence: list From: daniel@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02031; Sat, 9 Jul 1994 04:51:49 +1000 (from daniel@ISI.EDU) Received: from dza.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Fri, 8 Jul 1994 11:51:19 -0700 Date: Fri, 8 Jul 94 11:51:08 PDT Posted-Date: Fri, 8 Jul 94 11:51:08 PDT Message-Id: <9407081851.AA07229@dza.isi.edu> Received: by dza.isi.edu (4.1/4.0.3-4) id ; Fri, 8 Jul 94 11:51:08 PDT To: hcb@clark.net Cc: 0003858921@mcimail.com, big-internet@munnari.OZ.AU, hcb@clark.net In-Reply-To: Howard Berkowitz's message of Fri, 8 Jul 1994 14:11:47 -0400 (EDT) <199407081811.OAA02276@clark.net> Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: daniel@ISI.EDU >> >> From a research standpoint, it seems like our priority is to figure out >> what type of addressing is best for IPng. If we decide that fixed >> length addresses are better technology than variable length addresses, >> then what people LIKE and informing people on how to assign variable >> addresses are moot points. > From a product and operational standpoint, these points, especially > the "how to assign," are moot only if we also define mechanisms, or > at least requirements, for generating the requirements. Sorry. What I meant to say was that whether people like variable addresses is moot if we decide that we're going to use fixed lengths. In other words, figuring out whether to use fixed or variable length addresses comes first. Figuring out how to help people use and like whatever address format we agree on comes second. Daniel From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 06:25:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05413; Sat, 9 Jul 1994 06:25:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA08720; Sat, 9 Jul 1994 06:25:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08695; Sat, 9 Jul 1994 06:10:29 +1000 Precedence: list Received: from risc.austin.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04837; Sat, 9 Jul 1994 06:10:16 +1000 (from manoj@risc.austin.ibm.com) Received: by risc.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA30209; Fri, 8 Jul 1994 14:56:48 -0500 Date: Fri, 8 Jul 1994 14:56:48 -0500 From: manoj@risc.austin.ibm.com (Manoj Kumar) Message-Id: <9407081956.AA30209@risc.austin.ibm.com> To: Big-Internet@munnari.OZ.AU Subject: delete Please delete from this list From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 06:26:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02588; Sat, 9 Jul 1994 05:08:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA08572; Sat, 9 Jul 1994 05:08:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08533; Sat, 9 Jul 1994 04:46:26 +1000 Precedence: list Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29220; Sat, 9 Jul 1994 03:27:46 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA07035 for big-internet@munnari.oz.au; Fri, 8 Jul 94 13:27:25 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA05596; Fri, 8 Jul 1994 10:27:15 -0700 Message-Id: <199407081727.KAA05596@aland.bbn.com> To: Eric Fleischman Cc: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Fri, 08 Jul 94 09:52:02 -0700. <9407081652.AA09591@atc.boeing.com> From: Craig Partridge Date: Fri, 08 Jul 94 10:27:13 -0700 Sender: craig@aland.bbn.com Eric: I agree that we're seeing a proliferation of devices with computers in them. One trend that interests me is that there also seems to be a trend towards what one might term clustered computing -- a full service computer (with IP or IPX or whatever) and a bunch of more limited computers hidden behind it, using a more primitive networking technology. Examples include the automobile communications systems mentioned earlier on the list, and also things like hi-fi systems, home security systems, and sensor networks attached to people (e.g., the networked soldier of the future will have communications devices on his weapon, helmet, etc). I think this trend actually makes some sense. For instance, if I telnet to my home security center and want to see how the roast in my oven is doing, it is quite possible I'd prefer to connect to "craig.home.net oven-port" (i.e. to the well-known oven port) than trying to lookup oven.craig.home.net. One paradox here is the simpler we make IPng, the more likely it will get put directly into the oven equipment (because it is easy) and the larger the required address space will be. Craig From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 06:29:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05518; Sat, 9 Jul 1994 06:29:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA08735; Sat, 9 Jul 1994 06:28:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08701; Sat, 9 Jul 1994 06:16:20 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01636; Sat, 9 Jul 1994 04:39:36 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id OAA18818; Fri, 8 Jul 1994 14:39:33 -0400 Date: Fri, 8 Jul 1994 14:39:33 -0400 From: Vadim Antonov Message-Id: <199407081839.OAA18818@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, dab@epilogue.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements >Only if the addresses are allocated densely. Then the problem is how to allocate addresses densely, right? The answer is: if we have N hosts on any physical network (LAN, P2P, switched level-2 medium) it should be allocated a network with _ _ M = | log N | 2 bits in the host part of the address. By analogy, if a network has N subnets, M bits should be allocated for the host part. Given up to 8 levels of hierarchy the allocation strategy guarantees address space utilization not worse than 0.5%; in reality it will be much better (my estimate is about 40-60%). The catch is: there is too small margin for growth so the strategy will require renumberings. It means that dynamic addressing is necessary (well, it is also quite useful for other purposes like supporting mobile hosts). On the positive side -- such allocation strategy guarantees that the size of the routing table is minimal (i.e. it is the perfect CIDR). Also, it solves the problem of routing flap by eliminating all excessive routing information. Other advantage is making migration of customers from service provider to (competing) service provider real easy. >If the address is all we >have (no EID/locator split) then the address has to be used for >routing. Therefore it has to be allocated in a way that helps with >the routing or the routing tables will be unmanageably large. Packets shouldn't carry EIDs at all -- there is no need to do that (as there is no need to have EIDs different from domain names). >If addresses are to be used for routing they must be allocated for >routing and not administration. If we don't invent clever ways of >doing efficient routing then all we have is the way we're doing now >which is immensely wastefull of address space. Hm. We already invented it. It is called CIDR. Just do that right. >If you know a way, with the current routing architecture, to use the >address space much more efficiently and that will scale to a network >of 10^9 to 10^12 networks connected in a mesh, then I'm quite >interested. The key to scaling is "divide and conquer"; i.e. address allocation should be done by the hierarchy of space allocation servers. Simply, every routing domain should have a server in it. Like we do that now with DNS. There is a "root" server delegating chunks of space to the second-level servers etc etc. >If it'll work but not for a full mesh but only >heirarchical but a heirarchy that's not under your control, it's >probably still interesting. It will work reasonably with the architecture we have now (i do not expect the basic architecture to change radically because it is determined by physical laws; i.e. there will be wires/fibers to conduct signals; routers of different switching capacity etc etc). --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 06:32:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05679; Sat, 9 Jul 1994 06:32:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA08754; Sat, 9 Jul 1994 06:32:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08674; Sat, 9 Jul 1994 06:09:21 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00902; Sat, 9 Jul 1994 04:18:35 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id OAA02276; Fri, 8 Jul 1994 14:11:48 -0400 From: Howard Berkowitz Message-Id: <199407081811.OAA02276@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: daniel@ISI.EDU Date: Fri, 8 Jul 1994 14:11:47 -0400 (EDT) Cc: 0003858921@mcimail.com, big-internet@munnari.OZ.AU, hcb@clark.net (Howard Berkowitz, PSC International) In-Reply-To: <9407081705.AA07221@dza.isi.edu> from "daniel@ISI.EDU" at Jul 8, 94 10:05:19 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2953 > > > > Well, I have thought a lot about this. > > > Variable is out. Human's, being the way they are (notice the structure, us > > IPngers can't be humans :), and corporate creatures, being a more > > exasperating form of human's, cannot cope with variable decision processes. > > A lot of people will spin their wheels with the variable length and what > > will emerge will be a recommendation, followed by everyone eventually on how > > to structure the address. Just like NSAPs.... > > > People LIKE fixed things. The question is if it is fixed, is it fixed > > enough over time. So we hedge our bets by doubling our best guess and then > > do a few things to weaken that guess by adding functionality into the larger > > number. > > From a research standpoint, it seems like our priority is to figure out > what type of addressing is best for IPng. If we decide that fixed > length addresses are better technology than variable length addresses, > then what people LIKE and informing people on how to assign variable > addresses are moot points. From a product and operational standpoint, these points, especially the "how to assign," are moot only if we also define mechanisms, or at least requirements, for generating the requirements. Real world experience with training several hundred router administrators suggests to me that non-octet-aligned subnets, much less VLSM and OSPF aggregation, are right up at the limits of comprehensibility of the average router administrator. I believe that it is unreasonable to expect many operations people to configure structures with more than three or so levels of hierarchy, or more than two levels of overlapping domains. This is not to say that many people on this list do not routinely operate networks of far greater complexity. The people on this list, however, are a relative elite. The average router administrator -- and remember that a network has to be beyond some minimum complexity even to want dedicated router(s) -- is not a programmer, has had no exposure to graph theory, etc. > > If, on the other hand, we decide that variable length addresses better > fill the needs of the next generation IP, then we should expend > considerable effort figuring out how to do them *right* this time, > avoiding previous pitfalls, and helping people assign them and like > them. I support Daniel's position that we need to help people. I've been playing a bit with expert tools just for IP address assignment, and have been concerned that NIMROD and Big-Internet have been developing elegant concepts that are not deployable without tools. I'm losing my in-person IETF virginity in Toronto, and would very much like to compare notes with people interested in the operational address assignment problem, both for current and next-generation addressing structures. Howard BTW--I lean toward 16 octet, with an indicator for extensibility. From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 06:36:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05751; Sat, 9 Jul 1994 06:36:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA08771; Sat, 9 Jul 1994 06:35:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08704; Sat, 9 Jul 1994 06:20:43 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05186; Sat, 9 Jul 1994 06:20:16 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA06430; Fri, 8 Jul 94 13:08:20 -0700 Received: by xirtlu.zk3.dec.com; id AA11882; Fri, 8 Jul 1994 16:08:09 -0400 Message-Id: <9407082008.AA11882@xirtlu.zk3.dec.com> To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Cc: Big-Internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Fri, 08 Jul 94 11:27:29 MDT." <9407081727.AA03314@rhyolite.denver.sgi.com> Date: Fri, 08 Jul 94 16:08:03 -0400 X-Mts: smtp Vernon, I agree with much of what you said except about ignoring the processes to standardize IPng. I have plenty of customer RFCs depicting clearly which IETF standards I must support to even get in the door to do business at many customer sites. So a new set of IETF RFCs could become the next customer requirement I have. I also personally believe customers now have become very conscious of checking into the vendor motel. They very much want to be sure they can dump any vendor at will because they have them all using the same interoperable set of specifications for networking. I also believe this is true for other parts of the customer computer systems paradigm too. The days of rolling your own and hacking into the customers business with non-interoperable multivendor networking software in this business is over and passe IMHO. Vendors who adhere to this philosophical principle will not be around in 2005. Oh you can make a business out of the onesies and twosies, but I am talking about the bids for >$20 million. To win those a vendor will have to conform to some guidelines, which are often standards, not that lower bids should be ignored but its nice to win the big ones once in awhile too. IP is a standard with extreme growth and now is a requirement to do business as a networking vendor. Lets not assume that the IETF has to make the same mistakes other standards groups have made. Lets assume we can build interoperability specifications with some good technical design principles and forethought. But its absolutely valid what you said about the continued discussion of thoughts without practical technical dialogue (my summary to save words). In addition I think we often only have discussion where folks are trying to win or get others to go their way. It would be much better to have dialogue instead of discussion where the object is to achieve a shared technical understanding. But to make this happen the process has to take Dan MacDonalds very good input on why variable addresses are not that great for hosts today at the same time they listen to one of the architects discuss the topology ramifications of a specific technical approach. But how many time have you heard 'we are not ready for the bits and bytes, or I don't believe what that person said about performance loss its just a few instructions'. So part of the problem in the IETF is we are not having dialogue but discussions. They are not the same thing at all. With Dialogue all are equal as far as their ideas being reviewed by the group. With discussion often the perceived more Sr people will dominate the flow ideas (notice I said perceived). This is not good. I could go on about discussion vs dialogue but will stop. The other reason for the change is the International market. This market requires standards and its part of our social and economic evolution as a planet. My diagreement with your mail in summary is that I don't think we can build an Internet IPng without the IETF process. The problem is that this process will undergo change because it is now dealing more directly and consciously with an International focus. This is just life in the fast lane and its darn fast as anyone who has been keeping code base for IPng will tell you (and I have and know you have). /jim From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 06:42:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05997; Sat, 9 Jul 1994 06:42:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA08816; Sat, 9 Jul 1994 06:42:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08698; Sat, 9 Jul 1994 06:15:16 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05003; Sat, 9 Jul 1994 06:15:11 +1000 (from rharris@espresso.rt.cs.boeing.com) Received: by atc.boeing.com (5.57) id AA10301; Fri, 8 Jul 94 13:17:22 -0700 Received: from spook.network-b by espresso.rt.cs.boeing.com (4.1/SMI-4.1) id AA21077; Fri, 8 Jul 94 13:14:55 PDT Date: Fri, 8 Jul 94 13:14:55 PDT From: "Richard L. Harris (206) 865-4922" Message-Id: <9407082014.AA21077@espresso.rt.cs.boeing.com> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: ericf@atc.boeing.com Scott and Allison I've held off on replying because I wanted to do so in detail with nice logical arguements to back it up, but since time for that doesn't seem likely here's the quick and short. To me you appear to have asked the wrong questions and stated them in a quite biased form which makes it hard for me to answer them as asked, so I'm not. I'll state what I think is needed. Variable, or 16 bytes at LEAST with a built in extension or upgrade path to longer AND variable. Separable identifiers (maybe EIDs), Transport level and internet level names SHOULD NOT be the same. Unless by 'name' you mean identifier or a component of the identifier which should be the same at transport and internet. The 'adresses' should not be the same. The 'identifier' or 'name' component of the address should have zero topological significance. An extended form might have administrative significance. My main interest is securability of the network. Significance to security should have been addressed and should be a significant evaluation factor in the 'address length's ability to offer.' Richard Harris rharris@atc.boeing.com 206-865-4922 Boeing Computer Services > From owner-Big-Internet@munnari.OZ.AU Thu Jul 7 11:49:14 1994 > Date: Thu, 7 Jul 1994 14:07:10 -0400 > From: IPng Area Directors > Reply-To: big-internet@munnari.oz.au > Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements > Sender: mankin@cmf.nrl.navy.mil > Content-Length: 2630 > > > Hi, TUBA, SIPP, CATNIP, BIG-INTERNET, and IETF: > > This message is one last pre-Toronto recommendation > attempt to gauge the extent of consensus on one > of the IPng issues. We apologize for duplications. We wanted > to reach a wide audience. > > Steve Deering's message "Chicago Meeting -- Possible Changes > to SIPP" to the SIPP list a while back elicited quite a bit > of discussion on various lists (both SIPP and big-internet and > in other venues) about the length of "address" required for an IPng. > We have also had considerable discussion within the directorate. > > At this time it would appear to us that there is considerable consensus > that a fixed length, topologically structured, hierarchical > address 16 bytes in length is reasonable for an IPng (that is > meets the needs of the very very large-scale Internet). To me you appear to have asked the wrong questions and stated them in a quite biased form which makes it hard for me to answer them as asked, so I'm not. I'll state what I think is needed in the summary and embedded in the text. > We understand that we are being a bit vague in using the term "address" in > light of the question we asked two weeks ago. For the purposes of this > request, please assume that the transport level and internet level names > are the same. > Transport level and internet level names SHOULD NOT be the same. Unless by 'name' you mean identifier or a component of the identifier which should be the same at transport and internet. The 'adresses' should not be the same. Separable identifiers (maybe EIDs), > Some hold the view that 16 bytes is larger than would be required > for any imaginable Internet structure in the future and that an > 8 byte address is all that is required. > > There seems to be a stronger, but still minority, view that, for various > reasons, a variable length address, one that could be smaller or larger > than 16 bytes, would meet the needs better for the future of the > Internet. > > Much of the discussion on the lists has revolved around the relative > efficiency of processing fixed and variable length addresses. We would > like to assess the consensus just on the length for the future Internet, > instead of discussing efficiency any more at this time. We want > to make sure that we have understood consensus on meeting the needs > of the very very large Internet. Therefore, this message is to > ask people what present or future rationale they see for one of: > I'll rank them: 6) [but unacceptable] > 8 byte fixed length address. > 5) > 16 byte fixed length address. > 4) > longer than 16 byte fixed length address now. > 3) > only 16 byte length addresses now but ability > to lengthen the address later. > 1) Variable, or 2) 16 bytes at LEAST with a built in extension or upgrade path to longer AND variable. > To amplify a bit more, we are especially interested in your views > on the address length's ability to offer: My main interest is securability of the network. Significance to security should have been addressed and should be a significant evaluation factor in the 'address length's ability to offer.' > > routing aggregation power > > topological flexibility The 'identifier' or 'name' component of the address should have zero topological significance. An extended form might have administrative significance. By extended form I mean something bigger than the identifier, but probably smaller than the address. The difference between the identifier (extended or not) and the address would be the addition of information of routing, or routing topological significance. > > adminstrative manageability Separable identifiers (maybe EIDs), (I didn't realy know where to place this properly embedded, so it's just kind of stuck here.) SECURITY MANAGEABILITY, Aid in audit, detection, reporting, audit trails, security filtering, firewalls, access control, authorization and other security information and functionality requirements. > > At this point the consensus among the IPng directorate > and on several of the mailing lists seems fairly clear > (a 16 byte length address is good for those things). > This is a good time to bring forward your remaining views > about the requirements for address length for IPng. > I've held off on replying because I wanted to do so in detail with nice logical arguements to back it up, but since time for that doesn't seem likely here's the quick and short. > Thank you, > > Scott and Allison > > > From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 07:45:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07635; Sat, 9 Jul 1994 07:45:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA08882; Sat, 9 Jul 1994 07:45:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08868; Sat, 9 Jul 1994 07:27:03 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07088; Sat, 9 Jul 1994 07:26:59 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA21104; Fri, 8 Jul 94 14:28:27 -0700 Date: Fri, 8 Jul 94 14:28:27 -0700 From: Eric Fleischman Message-Id: <9407082128.AA21104@atc.boeing.com> To: avg@sprint.net, craig@aland.bbn.com, ericf@atc.boeing.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU >> I agree that we're seeing a proliferation of devices with computers >>in them. > >Yep, but they don't generally need to have the universal connectivity. >Neither universal connectivity is desireable for them. I definitely >don't want somebody hacking my W.C. :-) > >--vadim Dear Vadim, Now we have a bit of a problem: which address space will the address of your WC come from? If I had a say, it will come from a "local address". However, there are strong proponents against local addresses in the IETF and I haven't heard yet whether IPng will support this concept or not. If not, then you either will have to "hide" it in an address space behind an entity (e.g., as per Craig's comment of a bunch of devices with a single address to the outside) in a "gateway-like" system or else the entity will have a universal address. However, nobody can legislate that bunches of devices are clustered in this way nor can we legislate that local addresses be used even if they were available. Therefore, the default is that all devices may theoretically have "universal addresses" whether you and I want such a scenario or not. If so, to purposefully constrain the address space in order to hinder the possibility of universal- addresses-for-all-devices is to explicitly shorten the viable life span of that space. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 08:05:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08140; Sat, 9 Jul 1994 08:05:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA08918; Sat, 9 Jul 1994 08:05:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA08913; Sat, 9 Jul 1994 08:05:12 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08131; Sat, 9 Jul 1994 08:05:09 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20240; Fri, 8 Jul 94 15:04:53 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA11494; Fri, 8 Jul 94 15:06:06 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA00083; Fri, 8 Jul 1994 15:04:36 -0700 Date: Fri, 8 Jul 1994 15:04:36 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9407082204.AA00083@jurassic.Eng.Sun.COM> To: big-internet@munnari.OZ.AU Cc: Bob.Hinden@Eng.Sun.COM In-Reply-To: <199407071807.OAA16703@radegond.cmf.nrl.navy.mil> Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Scott and Allison, I will try to only answer your questions. > 8 byte fixed length address. Adequate for very large internet. Makes auto configuration a bit harder and does not fit some peoples requirements for address hierarchies. > 16 byte fixed length address. Provides for a much larger internet and makes possible easier auto configuration by embedding MAC layer address. Allows for additional address hierarchy. > longer than 16 byte fixed length address now. Not necessary. Excessive overhead. Larger addresses also promote assignment inefficiencies. > only 16 byte length addresses now but ability > to lengthen the address later. Not necessary. > To amplify a bit more, we are especially interested in your views > on the address length's ability to offer: > > routing aggregation power > > topological flexibility > > adminstrative manageability Not sure how to answer this. Seems like "motherhood and apple pie" to me. I think 8byte and 16byte addresses both are fine for the first two. 16byte addresses have an advantage in auto configuration which results in better "administrative manageability". > At this point the consensus among the IPng directorate > and on several of the mailing lists seems fairly clear > (a 16 byte length address is good for those things). I think 16 byte fixed length addresses are fine for IPng. They will allow the internet to grow for a very long time and make auto-configuration easier. I don't think larger addresses are necessary. I think 16byte addresses are the best engineering solution to the problem. They provide a reasonable balance between cost and benefits. Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 08:45:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05817; Sat, 9 Jul 1994 06:39:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA08786; Sat, 9 Jul 1994 06:39:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08677; Sat, 9 Jul 1994 06:09:35 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04727; Sat, 9 Jul 1994 06:09:31 +1000 (from news@sgi.com) Received: by sgi.sgi.com (940627.SGI.8.6.9/910110.SGI) for Big-Internet@munnari.OZ.AU id NAA23156; Fri, 8 Jul 1994 13:05:06 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: Precedence: list Date: Fri, 8 Jul 1994 19:23:01 GMT > From: kasten@ftp.com (Frank Kastenholz) > > > > I have seen several notes that included numbers that quantified some > > the implications of some of their assumptions. > ... > In any event, if there are two analyses, coming to differing > conclusions, then at least one (if not both) is wrong in either its > logic or its underlying assumptions. Perhaps the discussion should be > centering on these analyses, their logic, and their assumptions, yes? How can one label some plausible assumptions about the future "wrong" and others "right" without using a time machine? I wrote something like this before, but deleted it. I guess it needs saying ... It would be very easy today, in the summer of 1994, after years and no evident progress on IPng, to consign the IETF to the same dust heap as the organizations that brought us the OSI protocols and GOSIP mandates. If you look at only the surface of the IETF, it seems to have become a Standard standards organizations. As Jon Crowcraft puts it, "everyone wants to be an architect." There are endless empty arguments in the "yes it is; no it isn't" style about the implications of generally unstated, unacknowledge, evidently often unknown assumptions. People continue make up new jargon, and then try to think of definitions, all in the name of solving obvious and clear problems. Even those proposing radical solutions are unable to say precisely what they want. There is a consequent cowardly enthusiasm to use solutions in the style of TP0-TP4 and CONS/CLNS, to "just make it variable" or "let's make it optional and move on". There is also a lot of hubris. The delusions of grandure in the IETF are familiar to anyone who has attended standard standards meetings. From the mailing lists it's evident that many people think that the IETF has some influence on or even control of the future of the Internet. In reality, the IETF is exactly as powerless as the CCITT and the governments that wrote those GOSIP's. The days when the IETF was in charge of the Internet passed years ago, when the NSF ceased to pay all of the bills, when the IETF stopped worrying about what went in which routing tables and started only designing new protocols. No one will ever willing send or receive production IPng packets. No one will ever willingly move host from IPv4 to IPng. All IPng packets will be from experimentors and those forced to use IPng. If IPng helps enough of the addressing and routing problems and is not too painful, it will get a toehold in the market in 5 years. Eventually, in 10 or 15 years, if IPng is enough better than its competators, including IPv4 and IPX, it might become important. What are the chances of IPng surviving the century with as much vitality as TP4 has today? More than 30%?--I think so. More than 80%--no way. I do not think things are as bleak nor the process quite as Standard as they seem. With a little luck, the SIPP and TUBA people will continue to ignore the babble in the mailing lists and at the meetings, and ignore the Area Directors, ISEG, and Directorate. With luck, they'll produce some code, deploy it, the market will pick one or two, and everything will be continue to be wonderful. If that doesn't happen, then IPX or some other rogue protocol will solve the addressing and routing problems while also carrying IP packets among "legacy systems," the old IETF will become accredited and "liase" with the ITU, IEEE, and ANSI, the young turks will form their own engineering task force, and life will go on. Ah, well. Remember when TCP was a rogue protocol? Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 08:56:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09352; Sat, 9 Jul 1994 08:48:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09013; Sat, 9 Jul 1994 08:45:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA08997; Sat, 9 Jul 1994 08:27:15 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06765; Sat, 9 Jul 1994 07:10:51 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwxse25897; Fri, 8 Jul 1994 17:10:46 -0400 Date: Fri, 8 Jul 1994 17:10:46 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: big-internet@munnari.OZ.AU Subject: "cluster nets" As an example of how this is really being done (and a *very* interesting hack to consider as part of a "transition strategy"), consider FIREFOX, a TCP product for the Novell IPX world. The problem is simple - how do you run TCP/IP-based services on a lan full of Netware PCs without dual-stacking the whole bunch? Simple answer - put an NLM (Netware Loadable Module) TCP/IP stack on one designated server, which needs only *one* IP address, and then apps on the PCs use IPX to talk to the TCP stack which does proxy stuff for them. Sounds like "applications translating gateways" - I can hear the groans from here. Now this is where FIREFOX gets interesting. What if we want to be able to use regular, off-the-Internet WIndows TCP/IP applications on these PCs? after all, there's a lotta cool stuff out there being done (or if not cool, at least possibly useful). The problem is that all these apps are done for the Windows Socket API (aka WINSOCK interface). What FIREFOX does is add one little DLL (dynamic link library) to the Windows system directory on all the Netware PCs, and PRESTO!!! all the WINSOCK API calls are turned into RPCs to the TCP/IP stack on the server. Suddenly you can run off-the-net client programs on any of the PCs, without it being dual stacked, without it needing an IP address or administration, with all the grotty work being done on only one machine. From the outside it looks like a large timesharing system - lots of clients originating sessions, an SMTP gateway running on the server to transmorgify the mail, etc (probably no inbound telnet, though), but implemented as a network of PCs... again, the whole IPX net appears to have only one IP address. a stunning hack, methinks. -Mike PS - I have nothing to do with FIREFOX except as an admirer of a cunning piece of hackery when I see it..... From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 09:05:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09969; Sat, 9 Jul 1994 09:05:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09069; Sat, 9 Jul 1994 09:05:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09058; Sat, 9 Jul 1994 08:56:02 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08912; Sat, 9 Jul 1994 08:31:31 +1000 (from kre@munnari.OZ.AU) To: Barney Wolff Cc: big-internet@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs In-Reply-To: Your message of "Fri, 08 Jul 1994 14:21:00 EDT." <9407081421.AA25869@databus.databus.com> Date: Sat, 09 Jul 1994 08:31:28 +1000 Message-Id: <27032.773706688@munnari.OZ.AU> From: Robert Elz Date: Fri, 8 Jul 94 14:21 EDT From: Barney Wolff Message-ID: <9407081421.AA25869@databus.databus.com> Answer 1: loose source route listing (only) the ethernet's locator This is the obvious one - but it presumes that the ethernet and fddi interfaces have distinct locators, which I believe is right, but which wasn't the assumption in the question. Answer 2: You can't do that even today, if the router's ethernet interface is down and the host has ip-forwarding enabled, and advertises routes (yes, Yes I can, I use a strict source route to the router, then to the ethernet's IP address, that way the router is prohibited from forwarding via the FDDI address, whatever the host is advertising. Incidentally, this kind of example also shows the need for strict source routes, there are times they're needed. What's wrong with them is that they currently require too much knowledge, strict routes usually need to apply just one or two hops, not the whole path. Implementation of this could be via a bit in the route to indicate if its strict or loose, of via encapsulated headers, with loose routing to the router in the example, then an encapsulated strict source route header over the hop where I desire that behaviour, then loose (or no) routing to the final destination. Lots of protocol options here, just don't lose the functionality. kre From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 09:19:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10022; Sat, 9 Jul 1994 09:09:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09100; Sat, 9 Jul 1994 09:08:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09061; Sat, 9 Jul 1994 08:56:40 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09349; Sat, 9 Jul 1994 08:48:36 +1000 (from kre@munnari.OZ.AU) To: Vadim Antonov Cc: big-internet@munnari.OZ.AU, dab@epilogue.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Fri, 08 Jul 1994 14:39:33 -0400." <199407081839.OAA18818@titan.sprintlink.net> Date: Sat, 09 Jul 1994 08:46:27 +1000 Message-Id: <27038.773707587@munnari.OZ.AU> From: Robert Elz Date: Fri, 8 Jul 1994 14:39:33 -0400 From: Vadim Antonov Message-ID: <199407081839.OAA18818@titan.sprintlink.net> Packets shouldn't carry EIDs at all -- there is no need to do that (as there is no need to have EIDs different from domain names). You're confusing two issues here, they are unrelated. One is whether the EID (whatever its form) needs to be carried in some or all packets. The other is what form should an EID take. Dave Crocker suggested the "EID is a DNS name" most recently (to which Noel reacted as if a bomb had gone off - I'm not sure why as he had floated the same idea, more than once, earlier). While I believe that DNS names and EIDs are closely related concepts, I don't think that one can replace the other - and it has nothing to do with lengths. Clearly some binary form of EID couldn't replace DNS names (I hope that needs no explanation). I don't believe that DNS names make suitable EIDs for 2 reasons .. first they're not quite the correct granularity (close, but not quite it), and second, because DNS names are not stable enough. Both of these stem ultimately from DNS names being human visible objects - they need to be matched to the humans who will use them, and they're subject to the whims of those humans. The ideal EID would be ultra stable as long as the endpoint remained in existance - that doesn't mean the computer, computers are replaced every few years (or so), when the old one rolls out and the new one rolls in, the EID should remain, just as the DNS name does - but the EID should also remain when a new department head arrives and doesn't like his department's computers being named after Disney characters, or Grateful Dead band members, or whatever... EIDs should also be able to name either groups of computers if they fulfill a single role, and a single computer should be able to have multiple EIDs, and all combinations of those two concepts. Those concepts are a little too abstract to make use of the human visible names - it would lead to confusion. I have less opinion on the other half of the question, whether EIDs should be in none/some/all packets. Whatever works is my opinion here. Different protocol design philosophies will arrive at different answers, all for legitimate reasons. Just as long as the two endpoints of the communications are identified by something which is not the network level address of the endpoints (or one of those addresses), I don't care how its made to work. kre From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 09:25:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10657; Sat, 9 Jul 1994 09:25:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09146; Sat, 9 Jul 1994 09:25:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09129; Sat, 9 Jul 1994 09:18:22 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08730; Sat, 9 Jul 1994 08:28:26 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id SAA11206; Fri, 8 Jul 1994 18:28:09 -0400 From: Howard Berkowitz Message-Id: <199407082228.SAA11206@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: ericf@atc.boeing.com (Eric Fleischman) Date: Fri, 8 Jul 1994 18:28:08 -0400 (EDT) Cc: avg@sprint.net, craig@aland.bbn.com, ericf@atc.boeing.com, big-internet@munnari.OZ.AU In-Reply-To: <9407082128.AA21104@atc.boeing.com> from "Eric Fleischman" at Jul 8, 94 02:28:27 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 519 > > >> I agree that we're seeing a proliferation of devices with computers > >>in them. > > > >Yep, but they don't generally need to have the universal connectivity. > >Neither universal connectivity is desireable for them. I definitely > >don't want somebody hacking my W.C. :-) > > > >--vadim > > Dear Vadim, > > Now we have a bit of a problem: which address space will the address > of your WC come from? This discussion brings an entirely new meaning to the information-theoretic idea of a sink. From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 09:28:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10846; Sat, 9 Jul 1994 09:28:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09163; Sat, 9 Jul 1994 09:28:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09132; Sat, 9 Jul 1994 09:20:10 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10551; Sat, 9 Jul 1994 09:20:03 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id TAA20909; Fri, 8 Jul 1994 19:19:56 -0400 Date: Fri, 8 Jul 1994 19:19:56 -0400 From: Vadim Antonov Message-Id: <199407082319.TAA20909@titan.sprintlink.net> To: avg@sprint.net, kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU, dab@epilogue.com >From: Robert Elz >While I believe that DNS names and EIDs are closely related >concepts, I don't think that one can replace the other - and it >has nothing to do with lengths. Yes, unique identifier of a particular physical box and its name are different. BUT: do we really want to make the exact identification of a physical box to be known to other parties? It's a phylosophical question -- what's in the name? Name describes the role or function the machine perform in the net and as such is used by humans and software agents. Replacing the physical box without changing the name usually means keeping the same role. Changing name w/o replacing box is the good indicator of the box being re-used in some different role. Is knowing the physical identity of the box a good thing? I'm afraid not. It violates privacy and creates complications when you want to do changes in your configuration w/o changing external interfaces (aka "role") of your installation. Hiding information can be good -- consider that an "object-oriented approach" to networking. The less you need to know about your peer, the more freedom the peer has in changing things without breaking anything. The calssical example of bad design in this sense is DNS. DNS name servers have to know the transport-level addresses of other servers which makes it nearly impossible to move them anywhere. The interesting part is that DNS could be constructed in such a way that only ONE address has to be fixed -- i.e. the starting point. >EIDs should also be able to name either groups of computers >if they fulfill a single role, and a single computer should >be able to have multiple EIDs, and all combinations of those >two concepts. Same with names... >Those concepts are a little too abstract to >make use of the human visible names - it would lead to confusion. Well, adding an extra level of mapping will definitely lead to (more) confusion. >I have less opinion on the other half of the question, whether >EIDs should be in none/some/all packets. Whatever works is >my opinion here. I have no proof (in mathematical sense) but isn't every protocol requiring fixed EIDs has a EID-less functional equivalent? EIDs trigger my Occam alarms. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 09:51:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11316; Sat, 9 Jul 1994 09:45:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09198; Sat, 9 Jul 1994 09:45:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09181; Sat, 9 Jul 1994 09:35:35 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10938; Sat, 9 Jul 1994 09:35:31 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA21503; Fri, 8 Jul 94 18:35:26 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:big-internet@munnari.oz.au id AA01819; Fri, 8 Jul 94 18:35:24 -0500 Date: Fri, 8 Jul 94 18:35:24 -0500 Message-Id: <9407082335.AA01819@benedick.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs Cc: mohta@necom830.cc.titech.ac.jp From: "Richard Carlson" Masataka; >You completely misunderstand DNS. Well that news to me. .-) >When nodeB, or whoever, askes for the addressES of titccy, it gets back >131.112.252.3 AND 131.112.32.173. The sorting order is unspecified. Yes, you get back a list, but since the address specifies a route, then the order is significant. Sure I think that applications should sort the list to find the best route, but they don't. Take a look at the hostent struct some time. Buried in there is the h_addr variable for "backword compatability" reasons. Why, so programers wouldn't have to go back and fix all those broken programs. You describe how DNS works in theory. I describe how it works in pratice. To get back to the real discussion. >I have proved they stay in the same, internetworking, layer. I don't think so. Just because you say the EID must be stored in the internetworking layer doesn't make it true. What you are saying is that the transport layer needs 3 pieces of information to form a socket. 1. Port number - unique on individual node 2. Protocol type - unique on individual node 3. EID - globally unique None of these entites is required to be in the internetworking layer. In fact, the EID doesn't need to be in *any* protocol layer. All that is required is that both ends of a communications path know the Src snd Dest values. How they learn these values is not an issue we are discussing. You may think that it is easier to exchange these values by somehow including them in the internetworking layer? But that doesn't mean there aren't other ways that are equally valid. So you haven't "proved" anything, you are simply stating your personal option, just like I am. >I don't mind if you create two new layers, internetworking-identification >layer and internetworking-locating layer. But it has nothing to do >with transport layers. Are you saying we need multiple sub-layeres for the internetworking layer? Why is this better and how would you implement it? As I said above, the transport layer is just one place to put the EID. Why do you insist it can't go there? >Because EID does not contain protocol types nor port numbers, EID >can't belongs to the transport layer. The IPv4 number doesn't contain these either, but on 7 Jul 94 16:55:26 JST you insisted that it belongs in the transport layer. >> It currently uses the transport >> port number + transport protocol + IPv4 address. >Thus, it is at transport. I fail to see what you are driving at here. Please explain. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 09:51:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11367; Sat, 9 Jul 1994 09:48:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09217; Sat, 9 Jul 1994 09:48:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09184; Sat, 9 Jul 1994 09:36:51 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10962; Sat, 9 Jul 1994 09:36:48 +1000 (from kre@munnari.OZ.AU) To: Vadim Antonov Cc: big-internet@munnari.OZ.AU, dab@epilogue.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Fri, 08 Jul 1994 19:19:56 -0400." <199407082319.TAA20909@titan.sprintlink.net> Date: Sat, 09 Jul 1994 09:36:45 +1000 Message-Id: <27069.773710605@munnari.OZ.AU> From: Robert Elz Date: Fri, 8 Jul 1994 19:19:56 -0400 From: Vadim Antonov Message-ID: <199407082319.TAA20909@titan.sprintlink.net> BUT: do we really want to make the exact identification of a physical box to be known to other parties? No, but nor is that what I suggested. EIDs should not be mapped onto anything physical (though that happens to often be a good way to visualise them, as it is with DNS names). Replacing the physical box without changing the name usually means keeping the same role. Yes. Changing name w/o replacing box is the good indicator of the box being re-used in some different role. Only sometimes, names change for that (good) reason, and for lots of others (often without rational explanation at all). Once I used to exchange news with something.mips.com. One day I found I was exchanging news instead with something.sgi.com. As far as I was concerned it was the same role, same function, same everything ... but it certainly wasn't the same name. Sometimes the role changes without either the box or the name changing (though I'm not sure what relevance that has). Well, adding an extra level of mapping will definitely lead to (more) confusion. Here we're getting into opinions, and I disagree. I believe that separating the location and identification functions will (overall) simplify things - esp if it turns out that the locator need be seen by humans about as often, or less, as MAC addresses are today - the system takes care of finding and using those when needed, humans never need bother. (Note this is not considering the other role of MAC addresses as a system identification, in which role then need to added to configuration fies, etc - just their role in delivering packets, which is the sole role I see for locators). Having carved off the locater role, along with topological significance, masks, ..., and made all that essentially invisible to almost anyone, the identifier left that is occasionally seen will be a much simpler beast than that with which we deal today, much less imbedded meaning, ... To me that means less confusion. I have no proof (in mathematical sense) but isn't every protocol requiring fixed EIDs has a EID-less functional equivalent? I have no idea whether this is true or not. I know there's a proof that all boolean formulae can be represented with just the "and" and "not" operators ("or", "xor", ... are not needed). That makes them simpler in some theoretical sense. It doesn't make them simpler in practice. Striving for absolute minima rarely makes things more useful, just more tedious. EIDs trigger my Occam alarms. Mine too, but in the opposite direction to yours I suspect. I see them cutting away all the superfluous baggage hanging round identification (topological relationships), and around locators (identification functions), producing a much cleaner design. kre From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 12:45:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16375; Sat, 9 Jul 1994 12:45:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA09380; Sat, 9 Jul 1994 12:45:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA09364; Sat, 9 Jul 1994 12:38:26 +1000 Precedence: list Received: from fennel.acc.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16067; Sat, 9 Jul 1994 12:38:20 +1000 (from fbaker@acc.com) Received: from [129.192.69.64] (sb-mac-64.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA03737; Fri, 8 Jul 94 19:38:03 PDT Message-Id: <9407090238.AA03737@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Jul 1994 19:38:06 -0800 To: SIPP Mailing list , big-Internet@munnari.OZ.AU From: fbaker@acc.com (Fred Baker) Subject: re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: mankin@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu > The SMALLEST possible fixed-length address. And that length > better have a good justification for why it cannot be smaller. Well stated. Mega-dittos. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 13:25:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17509; Sat, 9 Jul 1994 13:25:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA09439; Sat, 9 Jul 1994 13:25:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA09423; Sat, 9 Jul 1994 13:22:02 +1000 Precedence: list Received: from netcom2.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17439; Sat, 9 Jul 1994 13:21:57 +1000 (from kck@netcom.com) Received: by netcom2 (8.6.8.1/SMI-4.1/Netcom) id NAA05371; Thu, 7 Jul 1994 13:02:18 -0700 Date: Thu, 7 Jul 1994 13:02:18 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407072002.NAA05371@netcom2> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements >There have been at least three sizable notes to the big-i list over >the past 4-8 weeks using a bit of math (hard to believe, any sort of >quantitative analysis, eh?) showing that 16 bytes is probably the >absolute minimum needed for long-term, hierarchically scalable >routing. You state that the IPng directorate's consensus (and other >mailing lists as well) seems to be that fixed-16 bytes is adequate. >Frank Kastenholz There have also been some notes that have used math to show that 8 bytes is sufficient as well. The inquisitvie message stated 3 alternatives: 8,16 & variable sized addresses. What about 8 bytes with an extended header for 16 byte addresses? This seems to be a hybrid of the 8 and 16 byte schemes. -rich From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 15:42:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19860; Sat, 9 Jul 1994 14:45:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09526; Sat, 9 Jul 1994 14:45:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09506; Sat, 9 Jul 1994 14:33:12 +1000 Precedence: list Received: from gn.apc.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19494; Sat, 9 Jul 1994 14:33:06 +1000 (from issr@baraka.gn.apc.org) Received: by gn.apc.org (4.1/Revision: 1.5 ) id AA11767; Sat, 9 Jul 94 05:32:57 BST Received: by baraka.gn.apc.org (1.65/waf) via UUCP; Sat, 09 Jul 94 06:49:22 2 for big-internet@munnari.oz.au To: big-internet@munnari.OZ.AU From: issr@baraka.gn.apc.org (Issa Sarras) Comments: validated Message-Id: Date: Sat, 09 Jul 94 06:49:04 2 Organization: BARAKA - The Palestinian NGO Host System Unsubscribe please | Join BARAKA - the Palestinian NGO Host System | | For INFO, send mail to support@baraka.gn.apc.org | From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 16:55:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21672; Sat, 9 Jul 1994 15:45:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09595; Sat, 9 Jul 1994 15:45:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09581; Sat, 9 Jul 1994 15:33:46 +1000 Precedence: list Received: from netcom2.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17771; Sat, 9 Jul 1994 13:32:48 +1000 (from kck@netcom.com) Received: by netcom2 (8.6.8.1/SMI-4.1/Netcom) id NAA07324; Thu, 7 Jul 1994 13:13:07 -0700 Date: Thu, 7 Jul 1994 13:13:07 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407072013.NAA07324@netcom2> To: big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM Subject: re: IPng ADs Wish to Gauge Consensus on Address Length Requirements *As for the options presented... * *> 8 byte fixed length address. * *I have no problem with this, but this alienates many people. Also, there *seems to be a trend toward low percentage of allocated address space used. *(I offer NRL itself as an example, though not the worst, of such waste.) * *If we could pull it off with 8 bytes, I'd be all behind it. * *> 16 byte fixed length address. * *This eliminates much alienation. Furthermore, wasted address space is not *a significant problem here. One of the problems with IPv4 is the waste factor. There are 2 ways to solve this. Solve the problem or solve the symptom. 16 bytes seems to solve the symptom but not the problem. We should be trying to solve the problem, because by solving the symptom alone, we cause (or magnify) other problems, such as: User admin problems, wasted bandwidth (esp. for mobile hosts, or more accurately slow links). We are making better strides at solving the problem now, we need to continue this effort. Much of the community out there has been under the impression that IPng simply meant replacing 4 byte addresses with 8 bytes addresses (and thats it!!). It would be ashame to sacrifice that goal if we really don't have to. *My position can be best summarized as: * * The SMALLEST possible fixed-length address. And that length * better have a good justification for why it cannot be smaller. Sounds good to me. *Dan McDonald | Mail: {danmcd,mcdonald}@itd.nrl.navy.mil --------------+ -rich From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 22:41:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01837; Sat, 9 Jul 1994 22:25:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA09966; Sat, 9 Jul 1994 22:25:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA09950; Sat, 9 Jul 1994 22:12:38 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01348; Sat, 9 Jul 1994 22:09:59 +1000 (from kre@munnari.OZ.AU) To: "Daniel L. McDonald" Cc: SIPP Mailing list , big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Thu, 07 Jul 1994 15:35:29 EST." <9407072035.aa15952@sundance.itd.nrl.navy.mil> Date: Sat, 09 Jul 1994 22:09:57 +1000 Message-Id: <27147.773755797@munnari.OZ.AU> From: Robert Elz Date: Thu, 7 Jul 1994 15:35:29 -0500 (EST) From: "Daniel L. McDonald" Message-ID: <9407072035.aa15952@sundance.itd.nrl.navy.mil> My position can be best summarized as: The SMALLEST possible fixed-length address. And that length better have a good justification for why it cannot be smaller. To last how long? 32 bits is almost certainly enough for at least the next 10 years if we discard the current address allocations and do it all again more effeciently. Even then I can't prove that 31, or 30, or 29 bits wouldn't be enough. 32 bits is a lot of addresses, if we do it carefully, they could last a very long time. If we could arrive at a time after which 32 bits wouldn't be enough, then another 2 bits a year (maybe 8 bits every 5 years) would be plenty to extend for as many years as you need to cover - again provided that we're ultra careful in how we allocate addresses. There's no way to prove this won't work, other than to try it and have it fail. There's no way to prove it will other than to try it and have it succeed. Do you really want to try this? How many years do you want to aim for (20 years? We need maybe 48 bits). Personally I suspect that 64 bits would be enough for all time, its also a nice kind of size. I can't prove it will be enough - nor am I sure it will be, I also can't prove it won't. This is very much an area where judgement is what is going to count. Unfortunately all our judgements are biased by our preconceptions of how the address space should be allocated and used. As I said, I'm not sure that 64 bits will be enough forever, I am sure that, under any even semi-reasonable allocation policy, 128 bits will be. I can't possibly justify that 128 bits is the smallest that would be needed - 64 could easily be, some size in between might be, or perhaps even something smaller than 64. What I am sure of is that I don't want to have to do all this again. For that reason I'm happy with 128 bits, even if something smaller will, eventually, with hindsight, turn out to have been adequate. kre From owner-Big-Internet@munnari.OZ.AU Sat Jul 9 23:34:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03373; Sat, 9 Jul 1994 23:22:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA10032; Sat, 9 Jul 1994 23:21:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA10019; Sat, 9 Jul 1994 23:15:34 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03182; Sat, 9 Jul 1994 23:15:28 +1000 (from kre@munnari.OZ.AU) From: Robert Elz Reply-To: Big-Internet-Request@munnari.OZ.AU To: Big-Internet@munnari.OZ.AU Subject: Big-Internet is now available in digest form Date: Sat, 09 Jul 1994 23:15:26 +1000 Message-Id: <27155.773759726@munnari.OZ.AU> Sender: kre@munnari.OZ.AU Big-Internet is now available in a once a day daily digest form for those on the list who are essentially only readers. The digest contains the same messages as appear on the regular list - occasionally I might notice and delete a trash message (subscribe/unsubscribe/...) etc, but apart from that the same messages appear, in the same form (all the internal quoting, etc). Most of the headers of the messages in the digest are deleted. Digest messages are sorted to group messages with the same subject together, but otherwise appear in the same order as they are processed by the list (which sometimes approximates the order they're sent). I recommend that those of you who participate actively on the list remain on it as you are now - sending replies to the digest messages will be much more difficult than replying to individual messages (please, never reply to the digest itself, the Subject: on such a reply would be totally meaningless). On the other hand, if you simply browse the list, you may find one message a day (albeit usually a large one) more convenient. The digest is not being archived - the contents are the same as the regular list, archives of the digest would simply be duplicates. I may be convinced to archive a week or so's worth of digests in case you miss one for some reason, and want to fetch it again. Send requests to switch from one form of the list to the other to: Big-Internet-Request@munnari.OZ.AU Other messages about the digests (format, archiving, whatever) should go to the same address. While I'm here I want to remind everyone of a couple of things from the welcome message sent to everyone when they first join the list ... This has appeared in every welcome message since the first... | Requests to be added to, or deleted from, the list, and other | administrivia, should be sent to (and ONLY to) | | Big-Internet-Request@munnari.OZ.AU and this has appeared on all for the last year or thereabouts... | Please save this message, messages sent to the list with content like | "How do I get off this list" or "Unsubscribe me" are not welcome. | Further, if you send something like that, and you catch me in a bad | mood, you may end up with twice as many copies of every message as | you were getting before... Please bear those in mind, Big-Internet is busy enough with real message content. Inflicting extra noise messages on the readers for no useful purpose (you will never get unsubscribed by sending an unsubscribe message to the list) is something that we can all do without. Thanks, kre From owner-Big-Internet@munnari.OZ.AU Sun Jul 10 06:53:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15564; Sun, 10 Jul 1994 06:46:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA10868; Sun, 10 Jul 1994 06:45:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA10850; Sun, 10 Jul 1994 06:27:25 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15017; Sun, 10 Jul 1994 06:27:21 +1000 (from sob@hsdndev.harvard.edu) Date: Sat, 9 Jul 94 16:27:11 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407092027.AA02509@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU, ietf@cnri.reston.va.us Subject: IPng archive update FYI - the IPng archive on hsdndev.harvard.edu (pub/ipng) has been updated with the latest batch of the directorate email list traffic and the notes taken during the directorate and invited guests retreat held at the BigTen conference center. We will be putting copies of the proposal reviews done by the directorate members there in the next few days. Scott & Allison From owner-Big-Internet@munnari.OZ.AU Sun Jul 10 09:10:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18660; Sun, 10 Jul 1994 09:06:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA11040; Sun, 10 Jul 1994 09:05:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA11035; Sun, 10 Jul 1994 09:03:23 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18510; Sun, 10 Jul 1994 09:03:19 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA04542; Sat, 9 Jul 94 18:03:17 CDT Date: Sat, 9 Jul 94 18:03:17 CDT Message-Id: <9407092303.AA04542@achilles.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Draft proposal for EIDs From: "Richard Carlson" I have placed a copy of my proposed RFC on my ftp server. achilles.ctd.anl.gov:/pub/ietf/tcpv11b.txt You should note that I wrote this paper before I heard of EIDs, so the term Transport Address (TA) is used instead. You can send me comments directly, to the list, or wait until Toronto. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Sun Jul 10 09:56:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19082; Sun, 10 Jul 1994 09:25:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA11081; Sun, 10 Jul 1994 09:25:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA11051; Sun, 10 Jul 1994 09:09:19 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18053; Sun, 10 Jul 1994 08:43:27 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA03714; Sat, 9 Jul 94 17:43:24 CDT Date: Sat, 9 Jul 94 17:43:24 CDT Message-Id: <9407092243.AA03714@achilles.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: Omnibus reply - EIDs Cc: kre@munnari.OZ.AU From: "Richard Carlson" > Robert Elz writes >One of the problems (I see) in the IETF is the tendancy to >overreact badly to problems that are really no more than >implementation choices (and in some cases obvious bugs). > >This looks to be an example of that ... > > This is because the DNS server uses *it's own address* to > sort the list of answer RR's. > >BIND's server's algorithm is a little more complicated than >that, but you're right, it does send addresses in orders that >aren't really what clients would prefer. > >The answer to this isn't to throw out the addressing structure >and start over - it's to fix the implementation so it works the >way that makes more sense. The resolver distributed with the >latest (currently beta) version of BIND fixes this, allowing >clients to sort replies in whatever order makes sense to them. I can see that BIND had to do something with the A RR list. I had problems with some vendor codes not handling this so I fixed it by patching BIND 4.9 and 4.9.3-BETA3. In some cases I couldn't get the vendors to change their code, so I choose to patch the server. (I will look at the resolver routines again, as I missed this section when built it a couple of weeks ago.) My purpose in this example was to show that the choices DNS makes can cause unexpected results for some applications. Not because of the way DNS works, but because the applications used (missused) the information DNS returned. After all DNS is just a message delivery service, it doesn't care what the information is. So I'm not trying to change the address structure (information), just improve the way an application uses it. IMHO this means separating idendification and location names. From owner-Big-Internet@munnari.OZ.AU Sun Jul 10 21:53:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08400; Sun, 10 Jul 1994 21:46:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA11691; Sun, 10 Jul 1994 21:45:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA11675; Sun, 10 Jul 1994 21:38:44 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08143; Sun, 10 Jul 1994 21:38:39 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 10 Jul 1994 12:38:12 +0100 To: SIPP Mailing list , big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Date: Sun, 10 Jul 94 12:38:05 +0100 Message-Id: <1608.773840285@cs.ucl.ac.uk> From: Jon Crowcroft say IPv4 scales to 10M systems (should do fairly comfortably) N bits more addressing can be allocated as pure hierarchy, or as pure flat address space - H and F one extreme, N=H, takes N times more table space, and buys us N times as many systems, i.e. maximum aggregation and minimum expansion. Other extreme, N=F, gives`maximum growth, but maximum table space. so N should be split between H & F, to give enough hierarchies for provider and geographic address allocation ,and table space optimisation, while providing enough end system addresses. then the table grows as 2**F * ln H.... if you choose 32 bits extra, and N=H (pure hierarchy) you get about 6 * 10**9 hosts (one each on earth), assuming you as stupid at allocating within the 2**32-1 times as may 32bit address spaces. Of course, since all of these start with the benefit of CIDR, i susect yu can do slightly better.... if you allocate any less hierarchy, then you get more end systems - since a IPng CIDR would be applied across the whole 64bits, i just dont see the problem - but if people really believe there i one, then an escape for another 8 bytes would seem prudent, but not a default of 16 bytes, since the minimum IPng packet size then becomes 16bytes longer then otherwise. This, given predicted growth in wireless, and necessarily bandwidth impovershed links, seems to fly in the face of one actual major source of growth! there's probably some neat information theory thing you ould argue about adding bits` for policy routing, provider and geographic bassed allocation - stee deering wrote a lot of good stuff about how many bits you'd really need for these anyhow, i hope my paranoid fantasy is true that this list is really a lightneing conductor, while the real action is happening elsewhere... coz this is getting nowhere rapido... cheers jon From owner-Big-Internet@munnari.OZ.AU Sun Jul 10 23:45:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11711; Sun, 10 Jul 1994 23:45:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA11827; Sun, 10 Jul 1994 23:45:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA11810; Sun, 10 Jul 1994 23:42:08 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11481; Sun, 10 Jul 1994 23:42:04 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 10 Jul 94 22:34:47 +0859 From: Masataka Ohta Message-Id: <9407101335.AA26137@necom830.cc.titech.ac.jp> Subject: Re: Source Routing & Provider Selection To: estrin@usc.edu Date: Sun, 10 Jul 94 22:34:46 JST Cc: emv@garnet.msen.com, big-internet@munnari.OZ.AU In-Reply-To: <199407081645.AA03232@zephyr.isi.edu>; from "Deborah Estrin" at Jul 8, 94 9:45 am X-Mailer: ELM [version 2.3 PL11] > > 1. flows will often use generic unicast but will also make use of > > source routing more than pure datagrams in order to get the QoS > > desired. > > If you have QoS requirements, you should set up a flow with the > QoS specification, not the source route specification. > > I am very confused as toowhat you are saying/asking... I'm saying that a source host doesn't have to specify it's QoS requirement as source routing as "I want to route the packet to a host D through routers A, B, C. I have already confirmed that the path assures the bandwidth of 32MHz and reserved it for me". Instead, the source host can just say "I want to reserve a 32MHz path to host D with flow ID of 123". Then, the source can expect intermediate routers do the confirmation, reservation and routing table setup. Thus, special route is established as states on routers, not as lengthy source route specification in each packet. For stable operation, the states should be updated periodically, of course. Each data packet will be forwarded on intermediate routers by flow ID. The packet does not have to have lengthy source route information. > Provider selection is *an* applicaiton of source routinkg Provider selection can also be done with 8+8 fixed length locator/EID, where locator part select the provider. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 00:25:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13201; Mon, 11 Jul 1994 00:25:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA11924; Mon, 11 Jul 1994 00:25:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11908; Mon, 11 Jul 1994 00:23:54 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13183; Mon, 11 Jul 1994 00:23:45 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 10 Jul 94 23:17:09 +0900 From: Masataka Ohta Message-Id: <9407101417.AA26289@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: avg@sprint.net (Vadim Antonov) Date: Sun, 10 Jul 94 23:17:07 JST Cc: avg@sprint.net, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, dab@epilogue.com In-Reply-To: <199407082319.TAA20909@titan.sprintlink.net>; from "Vadim Antonov" at Jul 8, 94 7:19 pm X-Mailer: ELM [version 2.3 PL11] > BUT: do we really want to make the exact identification of > a physical box to be known to other parties? Yes, only through such identification, we can lookup databases to know the hostname or public key of the box. Then, we can verify the identity through reverse/forward DNS lookup or public key cryptography. > I have no proof (in mathematical sense) but isn't every > protocol requiring fixed EIDs has a EID-less functional > equivalent? IPv4 and NSAP addresses are acting as EID. > The calssical example of bad design in this sense is DNS. > DNS name servers have to know the transport-level addresses > of other servers which makes it nearly impossible to move > them anywhere. As the standard transport-level addresses of DNS is known to be "TCP or UDP", "port 53" combined with internetwork-level addresses, DNS name servers have to know the internetwork-level addresses only. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 00:29:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13358; Mon, 11 Jul 1994 00:29:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA11945; Mon, 11 Jul 1994 00:29:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11859; Mon, 11 Jul 1994 00:07:16 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12803; Mon, 11 Jul 1994 00:07:11 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 10 Jul 94 23:00:40 +0900 From: Masataka Ohta Message-Id: <9407101400.AA26226@necom830.cc.titech.ac.jp> Subject: Re: Omnibus reply - EIDs To: RACarlson@anl.gov (Richard Carlson) Date: Sun, 10 Jul 94 23:00:38 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407082335.AA01819@benedick.ctd.anl.gov>; from "Richard Carlson" at Jul 8, 94 6:35 pm X-Mailer: ELM [version 2.3 PL11] > >I have proved they stay in the same, internetworking, layer. > > I don't think so. Just because you say the EID must be stored in the > internetworking layer doesn't make it true. What you are saying is > that the transport layer needs 3 pieces of information to form a socket. > > 1. Port number - unique on individual node > 2. Protocol type - unique on individual node > 3. EID - globally unique > > None of these entites is required to be in the internetworking layer. What do you think a "node" is? You should have stated it as: 1. Port number - unique on an individual internetworking layer entity 2. Protocol type - unique on an individual internetworking layer entity Then, to globally identify a socket, you need a globally unique id for the internetworking layer entity, that is, an EID. > In > fact, the EID doesn't need to be in *any* protocol layer. All that is required > is that both ends of a communications path know the Src snd Dest values. > How they learn these values is not an issue we are discussing. Then, how can the source know the locator of the destination? Don't you want to use a destiantion EID to lookup the locator in some database? > You may think that it is easier to exchange these values by somehow including > them in the internetworking layer? But that doesn't mean there aren't other > ways that are equally valid. That's implementation detail having nothing to do with layering. > >I don't mind if you create two new layers, internetworking-identification > >layer and internetworking-locating layer. But it has nothing to do > >with transport layers. > > Are you saying we need multiple sub-layeres for the internetworking layer? No, I don't need them. I say, if you think you want separate layers for locators and EIDs, don't change the established meaning of "transport" but coin new terminologies. > >Because EID does not contain protocol types nor port numbers, EID > >can't belongs to the transport layer. > > The IPv4 number doesn't contain these either, Thus, an IPv4 number, both as an EID and as a locator, belongs to the internetworking layer. > but on 7 Jul 94 16:55:26 JST > you insisted that it belongs in the transport layer. No. > >> It currently uses the transport > >> port number + transport protocol + IPv4 address. > >Thus, it is at transport. > > I fail to see what you are driving at here. Please explain. "port number + transport protocol + IPv4 address" is at transport. "IPv4 address" is at internetworking. "port number + transport protocol + EID" is at transport. Have we agreed so far? If so, how can you say: "EID" is NOT at internetworking? EID is at internetworking for identification purpose. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 01:05:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14415; Mon, 11 Jul 1994 01:05:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA11995; Mon, 11 Jul 1994 01:05:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11988; Mon, 11 Jul 1994 01:00:27 +1000 Precedence: list Received: from access2.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14345; Mon, 11 Jul 1994 01:00:24 +1000 (from tdarcos@access.digex.net) Received: by access2.digex.net id AA24949 (5.67b8/IDA-1.5 for big-internet@munnari.oz.au); Sun, 10 Jul 1994 10:59:49 -0400 Newsgroups: tdr.paul.private.mail Date: Sun, 10 Jul 1994 10:59:48 -0400 (EDT) From: "Paul W. Robinson" Sender: "Paul W. Robinson" Reply-To: "Paul W. Robinson" Subject: Re: IPng ADs request To: Steve Deering , big-internet@munnari.OZ.AU Message-Id: <01.1994Jul10.10h50m40s.PAULW-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul W. Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- Steve Deering , writes: > > Personal names already have a very high likelihood of being > > unique. > > How can you say that?? How many John Smiths are there? Heck, there's > even a Steve Deering (not me) who sells used cars on late night TV, here > in the San Francisco Bay Area -- I've received a couple of phone calls > for him (but no letters, yet). For today's message I am using a slightly different account number, PAULW@TDR.COM instead of my usual PAUL@TDR.COM to respond to this message. I used to work as a contractor for a well-known government agency. We had two people whose first, last and middle initial were identical and they weren't related in any way at all. This agency has about 3200 people. I was a student at Orange Coast College in Costa Mesa, CA. The manager of computing services was ALSO named "Paul Robinson". What a mess that causes, because I could never tell whether people were referring to me or to him. (His middle initial, fortunately, was D.) One time my mother tried to call me, and asked for "Paul Robinson". She was told he'd be in later. So she called back, and got him, and spoke for a few minutes, then said "You're not my Pauly!" This is when Paul Robinson discovered the caller wanted me instead. --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: There's only one way to have a happy marriage and as soon as I learn what it is I'll get married again. -- Clint Eastwood From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 01:25:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14956; Mon, 11 Jul 1994 01:25:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA12040; Mon, 11 Jul 1994 01:25:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12003; Mon, 11 Jul 1994 01:06:39 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14430; Mon, 11 Jul 1994 01:06:35 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101506.14430@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8985; Sun, 10 Jul 94 11:06:30 EDT Date: Sun, 10 Jul 94 11:05:06 EDT To: big-internet@munnari.OZ.AU, mankin@cmf.nrl.nay.mil, sob@harvard.edu Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Thu, 7 Jul 1994 14:07:10 -0400 Folks, The following quote is from "Realizing the Information Future -- the Internet and Beyond" (NRENAISANNCE Committee Report): "The migration to a new address space will be a major upheaval that will affect users, network providers, and vendors. Unifying the various network communities, the Internet, the cable industry, and the telecommunications industry is an additional complex undertaking that will not happen unless there is a clear and explicit advantage. An effort to define a single overarching architecture is the only context in which this integration can be motivated. It will take careful consideration to plan and implement a scheme that properly resolves such major concerns as an appropriate addressing scheme, interim management actions, and migration plans. This implies that overarching architectural decisions for the NII, such as addressing, must be made in a context with an appropriate long-term vision and architectural overview. Wide-ranging discussion is needed on the requirements for next-generation integrated addressing, with the goal of determining what the scope of this coming address space should be. It is critical that the requirements be appropriately specified." Correct me if I am wrong, but I don't think that *today* we have "a single overarching architecture". Correct me if I am wrong, but I don't think that *today* we have "the requirements for next-generation integrated addressing". In absence of *both* the architecture *and* the requirements for next-generation intergrated addressing, the only way to define the IPng packet format *without* waiting for the architecture and the requirements is to make a guess. The guess needs to factor in the uncertainty about the architecture and the requirements. The guess suggested by Scott and Allison -- fixed length 16 bytes for all address types (unicast, cluster, multicast) that carries both EID and locator semantics seems to be too rigid and too constrained in view of the above. I think that a better (more flexible and less constrained) guess is the following: (a) Separate unicast EID from unicast locators, with unicast EID of fixed length and unicast locators of variable length (perhaps multiple of 8). (b) Cluster locators of variable length (perhaps multiple of 8). Yakov. P.S. Let me suggest that we'll pay a serious attention to the NRENAISSANCE committee report. The committee membership represents the top experts in networking (Leonard Kleinrock, Cynthia Braddon, Dave Clark, William Emery, Dave Farber, A.G. Fraser, Russell Hensley, Lawrence Landweber, Robert Lucky, Susan Nutter, Radia Perlman, Susanna Schweizer, Chales Taylor, Thomast West, Robert Kahn). From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 02:05:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16067; Mon, 11 Jul 1994 02:05:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12090; Mon, 11 Jul 1994 02:05:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12085; Mon, 11 Jul 1994 01:59:08 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15887; Mon, 11 Jul 1994 01:59:04 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101559.15887@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9153; Sun, 10 Jul 94 11:58:59 EDT Date: Sun, 10 Jul 94 11:53:45 EDT To: tli@cisco.com, Christian.Huitema@sophia.inria.fr Cc: Big-Internet@munnari.OZ.AU Subject: Source Routing & Provider Selection Ref: Your note of Thu, 7 Jul 1994 00:37:09 -0700 Tony, >If you talk to Yakov and discuss provider selection, I think he will >say that the bulk of the traffic will be source routed unicast... As far as I can see, there are two key applications that will drive the volume of source routed unicast in the near term future: (a) mobility (b) provider selection By the way, (a) and (b) could be combined together as well -- mobile hosts with provider selection. Yakov. P.S. The above is *by no means* an exhaustive list of applications that would drive the source routed unicast From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 02:25:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16652; Mon, 11 Jul 1994 02:25:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12135; Mon, 11 Jul 1994 02:25:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA12106; Mon, 11 Jul 1994 02:09:35 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16111; Mon, 11 Jul 1994 02:09:33 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101609.16111@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9183; Sun, 10 Jul 94 12:09:13 EDT Date: Sun, 10 Jul 94 12:01:55 EDT To: Christian.Huitema@sophia.inria.fr, tli@cisco.com Cc: Big-Internet@munnari.OZ.AU Subject: Source Routing & Provider Selection Ref: Your note of Thu, 07 Jul 1994 08:56:58 +0200 Christian, >I have the opinion that it is first class if it is in a minimal subset >that all implementations must implement. That only constitute a *necessary* condition for the "first class". To make it a *truly* first class requires also an encoding that minimizes the overhead associated with carrying and processing source route. So, the bottom line is that a "first class" for source route implies both: (a) the requirement that all implementations must implement it, and (b) efficient encoding as to minimize the overhead associated with carrying and processing source route Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 03:26:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18279; Mon, 11 Jul 1994 03:26:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA12236; Mon, 11 Jul 1994 03:25:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12203; Mon, 11 Jul 1994 03:08:23 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17816; Mon, 11 Jul 1994 03:08:20 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16503; Sun, 10 Jul 1994 19:08:16 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11144; Sun, 10 Jul 1994 19:08:15 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407101708.AA11144@dxcoms.cern.ch> Subject: Re: Source Routing & Provider Selection To: estrin@usc.edu Date: Sun, 10 Jul 1994 19:08:15 +0200 (MET DST) Cc: emv@garnet.msen.com, big-internet@munnari.OZ.AU In-Reply-To: <199407081645.AA03232@zephyr.isi.edu> from "Deborah Estrin" at Jul 8, 94 09:45:13 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 700 Deborah, I think the need for settlements between providers, and free choice of long distance providers by subscribers, will be very powerful drivers too. But yes, ToS is equally important and probably more challenging. Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) >--------- Text sent by Deborah Estrin follows: > > Provider selection is *an* applicaiton of source routinkg but please > do not equate the need for source routing with the need for provider > selection! Source routing is needed for other services related to ToS > and finding routes that can grant reservation requests...THESE are the > dominant demand drivers longer term...in my opinion of course...:} > > D. > From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 03:29:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18469; Mon, 11 Jul 1994 03:29:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA12251; Mon, 11 Jul 1994 03:29:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12217; Mon, 11 Jul 1994 03:12:46 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17849; Mon, 11 Jul 1994 03:12:43 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101712.17849@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9335; Sun, 10 Jul 94 13:12:29 EDT Date: Sun, 10 Jul 94 12:40:17 EDT To: kre@munnari.OZ.AU, dab@epilogue.com Cc: big-internet@munnari.OZ.AU Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Fri, 08 Jul 1994 06:56:37 +1000 Robert, >Do we believe that an addressing and routing architecture can be designed >to fit in a fixed length 16 bytes address, or could one be designed to >in 8 bytes, or some other fixed length, or is only a variable length >address ever going to be acceptable. > >Read this way, the question is entirely reasonable. The question is reasonable, but imprecise. The question is not only whether an addressing and routing architecture can be designed "to fit in a fixed length" address, but also what are the inherent limitations on the addressing and routing architecture that a "fixed length address" design (with semantics overload of EIDs and locators) imposes. One of the important design requirements for the IPng packet format should be the ability to handle different addressing and routing architecture, so that we'll be able to change the architecture *without* changing packet format. The rigidity and constraints on the IPng packet design may have rather adverse impact on the ability to handle different architectures. I think that the question of whether 16 bytes fixed length address that is semantically overloaded with both the EID and locator should be analysed in view of the above issues. Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 03:31:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18520; Mon, 11 Jul 1994 03:31:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA12268; Mon, 11 Jul 1994 03:31:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12220; Mon, 11 Jul 1994 03:18:34 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18098; Mon, 11 Jul 1994 03:18:27 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Sun, 10 Jul 1994 22:34:46 +0200." <9407101335.AA26137@necom830.cc.titech.ac.jp> Date: Mon, 11 Jul 1994 03:18:25 +1000 Message-Id: <27310.773860705@munnari.OZ.AU> From: Robert Elz Date: Sun, 10 Jul 94 22:34:46 JST From: Masataka Ohta Message-ID: <9407101335.AA26137@necom830.cc.titech.ac.jp> Instead, the source host can just say "I want to reserve a 32MHz path to host D with flow ID of 123". Then, the source can expect intermediate routers do the confirmation, reservation and routing table setup. This only works in the simplest cases, where every possible criterion upon which the source may wish to choose a route is known in advance, that is, standardised, along with a whole syntax to allow the particular combination of all those factors that the source desires to be expressed. The second part of that is possible, though cumbersome - the first seems so unlikely as to be barely worth considering. eg: if you were enumerating the criteria upon which I may want to tell the routers to choose a path, would you include "avoid paths that go through areas where the provider buys power from a power company that uses nuclear power generation" ? That's not the kind of thing that you'd usually consider - yet some users may really want to adopt a policy like that. You can make as big a list of criteria to standardise for all the routers and I promise I'll find something else plausible that you've omitted, though I won't promise to be able to do it until after the standard is finished and deployed all around the world. The only practical way to allow general provider selection is to allow the source to do it, and simply say where the packet should go. That still doesn't goive any clue as to how the source will obtain all the information on which it may want to make decisions, nor how the user's choices should be communicated to the internet layer, but none of that is an internet layer problem, its all localised - vendors can offer this with as much complexity & flexibility as they can find customers to pay for. kre From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 04:25:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20186; Mon, 11 Jul 1994 04:25:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA12365; Mon, 11 Jul 1994 04:25:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12346; Mon, 11 Jul 1994 04:17:47 +1000 Precedence: list Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19882; Mon, 11 Jul 1994 04:17:41 +1000 (from news@vix.com) Received: by gw.home.vix.com id AA26741; Sun, 10 Jul 94 11:17:36 -0700 Date: Sun, 10 Jul 94 11:17:36 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: big-Internet@munnari.OZ.AU From: paul@vix.com (Paul A Vixie) Subject: Re: Omnibus reply - EIDs Organization: Vixie Enterprises Message-Id: References: <9407092243.AA03714@achilles.ctd.anl.gov> Nntp-Posting-Host: gw.home.vix.com In-Reply-To: RACarlson@anl.gov's message of 9 Jul 1994 16:52:02 -0700 If folks are hacking BIND to support BigNet stuff, I (BIND's maintainer) would like to know about it. As far as I know, the A RR list problems are solved by RESOLVSORT. If you know better, I need to hear from you. -- Paul Vixie Redwood City, CA decwrl!vixie!paul From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 04:29:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20265; Mon, 11 Jul 1994 04:29:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA12380; Mon, 11 Jul 1994 04:28:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12360; Mon, 11 Jul 1994 04:25:32 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20182; Mon, 11 Jul 1994 04:25:29 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101825.20182@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9549; Sun, 10 Jul 94 14:24:22 EDT Date: Sun, 10 Jul 94 14:16:21 EDT To: rharris@espresso.rt.cs.boeing.com, big-internet@munnari.OZ.AU Cc: ericf@atc.boeing.com Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Fri, 8 Jul 94 13:14:55 PDT Richard, >To me you appear to have asked the wrong questions and stated >them in a quite biased form... At the minimum the questions asked by Scott and Allison are imprecise and incomplete (see my messages to Big-I on July 8 and July 10). I also think it would be useful if Scott and Allison let us know the opinion of the IPng directorate on both the issue of whether 16 bytes is ok *and* on the issue of whether addresses should be of variable length. Scott and Allison, would you please provide us with this information. Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 04:31:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20438; Mon, 11 Jul 1994 04:31:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA12399; Mon, 11 Jul 1994 04:31:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12331; Mon, 11 Jul 1994 04:11:47 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19734; Mon, 11 Jul 1994 04:11:43 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101811.19734@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9523; Sun, 10 Jul 94 14:11:34 EDT Date: Sun, 10 Jul 94 14:09:26 EDT To: big-internet@munnari.OZ.AU Cc: mankin@cmf.nrl.navy.mil, sob@harvard.edu Subject: BigTen packet format Folks, At the Chicago IPng Directorate retreat (May 1994) there was a discussion on a possible IPng packet format (the IPng archives contain the results of the packet format design). The directorate and their invited guests expressed support for the suggested design with its variable length addresses. The following Internet Draft (see attached) aims at: (a) filling the missing parts of the packet format design done at the retreat, and (b) refining the packet format design done at the retreat Your comments would be greatly appreciated. Yakov. ------------------------------------------------------------------------- Received: from IETF.nri.reston.VA.US by watson.ibm.com (IBM VM SMTP V2R3) with TCP; Wed, 06 Jul 94 18:32:06 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10903; 6 Jul 94 17:28 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10848; 6 Jul 94 17:28 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ford-bigten-bt-format-00.txt Date: Wed, 06 Jul 94 17:28:13 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9407061728.aa10848@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BigTen (BT) Packet Format Author(s) : P. Ford, T. Li, Y. Rekhter Filename : draft-ford-bigten-bt-format-00.txt Pages : 16 Date : 07/05/1994 The BigTen (BT) is a new version of the Internet Protocol, designed as a successor to IP version 4 (IPv4) [RFC791]. This document specifies the basic BT header format and the initially defined BT options. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ford-bigten-bt-format-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ford-bigten-bt-format-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940705135717.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ford-bigten-bt-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ford-bigten-bt-format-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940705135717.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 04:45:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20942; Mon, 11 Jul 1994 04:45:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA12435; Mon, 11 Jul 1994 04:45:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12413; Mon, 11 Jul 1994 04:33:25 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20474; Mon, 11 Jul 1994 04:33:22 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101833.20474@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9599; Sun, 10 Jul 94 14:33:18 EDT Date: Sun, 10 Jul 94 14:28:01 EDT To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU Subject: Omnibus reply - EIDs Ref: Your note of Sat, 09 Jul 1994 08:31:28 +1000 Robert, >Incidentally, this kind of example also shows the need for strict >source route. What's wrong with them is that they currently require >too much knowledge, strict routes usually need to apply just one >or two hops, not the whole path. The functionality you asking for is quite similar to the IPng requirements from the Unified Architecture point of view (see Internet Draft draft-estrin-ipng-unified-routing-00.txt). The source route encoding in the BigTen packet format is designed to address this functional requirement. Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 05:05:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21362; Mon, 11 Jul 1994 05:05:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12476; Mon, 11 Jul 1994 05:05:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12451; Mon, 11 Jul 1994 04:47:39 +1000 Precedence: list Received: from seins.Informatik.Uni-Dortmund.DE by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20961; Mon, 11 Jul 1994 04:47:32 +1000 (from rv@deins.informatik.uni-dortmund.de) Received: from localhost.Informatik.Uni-Dortmund.DE by seins.informatik.uni-dortmund.de id AA04414; Sun, 10 Jul 94 20:47:10 +0200 To: big-internet@munnari.OZ.AU Subject: pointer to NRENAISSANCE Committee Report (was: IPng ADs Wish ...) In-Reply-To: Yakov Rekhter's message of "Sun, 10 Jul 1994 11:05:06 EDT." <9407101506.14430@munnari.oz.au> Date: Sun, 10 Jul 1994 20:47:09 +0200 Message-Id: <4413.773866029@seins.Informatik.Uni-Dortmund.DE> From: Ruediger Volk Yakov had suggested to "pay a serious attention to the NRENAISSANCE committee report". Since I could not remember nor find pointers to that report in either big-internet or ietf archives, I asked back. Since others may be looking for the same information, I'm forwarding the answer to the list: > The NRENAISSANCE report is available via anonymous FTP: ftp.nas.edu > (pub/reports/computing_the_future). You can also get a hard copy > from National Academy Press, 2101 Constitution Avenue, NW, Box 285, > Washington, DC 20055 (phone number 800-624-6242). ISBN 0-309-05044-8. ----- Ruediger Volk Universitaet Dortmund, Informatik IRB D-44221 Dortmund, Germany E-Mail: rv@Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386 From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 05:08:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21390; Mon, 11 Jul 1994 05:08:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12493; Mon, 11 Jul 1994 05:08:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12467; Mon, 11 Jul 1994 04:58:23 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21158; Mon, 11 Jul 1994 04:58:19 +1000 (from sob@hsdndev.harvard.edu) Date: Sun, 10 Jul 94 14:58:04 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407101858.AA08506@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU, rharris@espresso.rt.cs.boeing.com, yakov@watson.ibm.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: ericf@atc.boeing.com > I also think it would be useful if Scott and Allison let us > know the opinion of the IPng directorate on both the issue > of whether 16 bytes is ok *and* on the issue of whether addresses > should be of variable length. Scott and Allison, would you please > provide us with this information. Yakov, We did poll the directorate on the issue of address size. Here is the original question and a summary of the the responses. See the mailing list archives for the full texts of the replies. Scott ---- Peter suggested that we do a straw poll of the directorate about 16 byte fixed length addresses being acceptable for IPng (in the context of the revised SIPP proposal and ones own understanding of the 'real world' both technical and political.) That seems like a good idea so here it is too much ok should be variable J. Allard X Steve Bellovin X Jim Bound X Ross Callon X Brian Carpenter X Add NSAPA option Dave Clark John Curran X X Steve Deering (X) X Dino Farinacci X X Eric Fleischman X X Paul Frances X Mark Knopper X Greg Minshall X X Rob Ullmann Lixia Zhang X add option for var From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 05:55:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21958; Mon, 11 Jul 1994 05:25:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12540; Mon, 11 Jul 1994 05:25:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA12520; Mon, 11 Jul 1994 05:21:34 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21762; Mon, 11 Jul 1994 05:21:31 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101921.21762@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9763; Sun, 10 Jul 94 15:21:27 EDT Date: Sun, 10 Jul 94 15:09:30 EDT To: sob@hsdndev.harvard.edu, big-internet@munnari.OZ.AU Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Sun, 10 Jul 94 14:58:04 -0400 Scott, Thanks for the statistics. I found it quite interesting -- 9 out of 13 indicated that addresses should be of variable length 10 out of 13 indicated that 16 bytes fixed address are ok Note that both results came from the *same* group of 13 people in the IPng Directorate. Based on the above it seems that within the IPng Directorate there is a clear consensus that IPng packet format should (a) support variable length addresses, and (b) support fixed length 16 bytes addresses Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 06:06:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23323; Mon, 11 Jul 1994 06:06:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA12589; Mon, 11 Jul 1994 06:05:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA12584; Mon, 11 Jul 1994 06:03:58 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23301; Mon, 11 Jul 1994 06:03:54 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14407(3)>; Sun, 10 Jul 1994 13:03:45 PDT Received: by redwing.parc.xerox.com id <57153>; Sun, 10 Jul 1994 13:03:35 -0700 Date: Sun, 10 Jul 1994 13:03:21 PDT Sender: Lixia Zhang From: Lixia Zhang To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Sun, 10 Jul 1994 12:09:30 -0700 Message-Id: > Ref: Your note of Sun, 10 Jul 94 14:58:04 -0400 > > Scott, > Thanks for the statistics. I found it quite interesting -- > > 9 out of 13 indicated that addresses should be of variable length > 10 out of 13 indicated that 16 bytes fixed address are ok Yakov, I'm afraid that a pure number count does not accurately reflect the positions of individual directorate members, at least that's the case for me. I did not say the address should be variable length AT THIS TIME. I even do not think it is technically feasible to deploy variable length addresses at this time. I support 16-byte fixed length address at this time. I suggested that the IPng WG study and add options to make the address extensible (hence may be deployed in the future, just in case the need rises). Lixia From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 06:08:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23357; Mon, 11 Jul 1994 06:08:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA12606; Mon, 11 Jul 1994 06:08:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA12581; Mon, 11 Jul 1994 05:56:10 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22609; Mon, 11 Jul 1994 05:47:30 +1000 (from sob@hsdndev.harvard.edu) Date: Sun, 10 Jul 94 15:47:23 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407101947.AA10850@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU, yakov@watson.ibm.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > Based on the above it seems that within the IPng Directorate > there is a clear consensus that IPng packet format should > (a) support variable length addresses, and > (b) support fixed length 16 bytes addresses Yakov, You might just be engaging in a bit of projecting your own feelings here. An alternative interpretation could be that most directorate members think that adopting a fixed length 16 byte address will meet the needs of the Internet for now & the future. In addition, many (but not all) of the same people think that in an ideal world or one definition of ideal or another) a variable length address would be better. Some other directorate members think that only a variable length address would meet the requirements. If you read the directorate mail archives I think you will see that this interpretation may be bit closer to what the discussions within the directorate have indicated. Scott From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 07:38:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24628; Mon, 11 Jul 1994 06:45:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA12684; Mon, 11 Jul 1994 06:45:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA12670; Mon, 11 Jul 1994 06:28:50 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24030; Mon, 11 Jul 1994 06:28:46 +1000 (from yakov@watson.ibm.com) Message-Id: <9407102028.24030@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0169; Sun, 10 Jul 94 16:28:42 EDT Date: Sun, 10 Jul 94 16:18:27 EDT To: lixia@parc.xerox.com Cc: big-internet@munnari.OZ.AU Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Sun, 10 Jul 1994 13:03:21 PDT Lixia, >I did not say the address should be variable length AT THIS TIME. Do you mean that the IPng packet format AT THIS TIME should have only fixed length address capabilities, or do you mean that the addresses used in the Internet AT THIS TIME should be of fixed length ? >I even don't think it is technically feasible to deploy >variable length addresses at this time. Would you please elaborate on why this isn't technically feasible. >I suggest that the IPng WG study and add options to make >address extensible (hence may be deployed in the future, >just in case the need arise). Does the above imply that a conformant IPng implementation does not have to support this option ? If "yes" then should this further imply that "in the future", "in case the need arise", we'll go through IPng to IPng++ (where IPng++ is the IPng with the option to make address extensible) ? Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 08:18:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26163; Mon, 11 Jul 1994 07:46:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA12782; Mon, 11 Jul 1994 07:45:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA12766; Mon, 11 Jul 1994 07:38:02 +1000 Precedence: list Received: from CARAWAY.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24336; Mon, 11 Jul 1994 06:38:47 +1000 (from ddc@caraway.lcs.mit.edu) Received: by caraway.lcs.mit.edu id AA25095; Sun, 10 Jul 94 16:38:36 -0400 Message-Id: <9407102038.AA25095@caraway.lcs.mit.edu> To: Ruediger Volk Cc: big-internet@munnari.OZ.AU Subject: Re: pointer to NRENAISSANCE Committee Report (was: IPng ADs Wish ...) In-Reply-To: Your message of Sun, 10 Jul 94 20:47:09 +0200. <4413.773866029@seins.Informatik.Uni-Dortmund.DE> From: David Clark Date: Sun, 10 Jul 94 16:38:36 -0400 Sender: ddc@caraway.lcs.mit.edu X-Mts: smtp The information on getting the NRENaissance report in the last message was slightly wrong. The title given in the ftp string is the wrong report. The file name is pub/reports/realizing_the_information_future. The full title of the report is "Realizing the Information Future: the Internet and Beyond. In addition to the means cited above for getting the report, one can also use the nas Web server (www.nas.edu) or gopher server (gopher.nas.edu). On can also contact their publication office on the net: amerchan@nas.edu. Note that this is an interesting experiment in free vs. sold information. You can have the report for free if you want to push 300 pages through your printer, or you can pay $25 to have it bound with a cover on it. They are keeping score.... Dave Clark From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 08:45:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28159; Mon, 11 Jul 1994 08:45:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA12875; Mon, 11 Jul 1994 08:45:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA12858; Mon, 11 Jul 1994 08:26:35 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27401; Mon, 11 Jul 1994 08:26:31 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Sun, 10 Jul 1994 15:26:28 -0700 Date: Sun, 10 Jul 1994 15:26:28 -0700 Message-Id: <199407102226.AA25996@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: kre@munnari.OZ.AU Cc: mohta@necom830.cc.titech.ac.jp, big-internet@munnari.OZ.AU In-Reply-To: Robert Elz's message of Mon, 11 Jul 1994 03:18:25 +1000 <27310.773860705@munnari.OZ.AU> Subject: Source Routing & Provider Selection Reply-To: estrin@usc.edu so if you are interested in this question of how to construct the source routes, come to the SDR WG session at IETF on wednesday afternoon... From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 10:08:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29513; Mon, 11 Jul 1994 09:26:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA12934; Mon, 11 Jul 1994 09:25:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12909; Mon, 11 Jul 1994 09:10:02 +1000 Precedence: list Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28599; Mon, 11 Jul 1994 09:02:25 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA10094 (5.65c/IDA-1.4.4nsd for ); Sun, 10 Jul 1994 16:02:18 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA26866 (5.65c/IDA-1.4.4-910725 for ); Sun, 10 Jul 1994 16:02:15 -0700 Message-Id: <199407102302.AA26866@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Sun, 10 Jul 94 12:40:17 EDT." <9407101712.17849@munnari.oz.au> Date: Sun, 10 Jul 94 16:02:14 -0700 From: tracym@NSD.3Com.COM > One of the important design requirements for the IPng packet format should > be the ability to handle different addressing and routing architecture, > so that we'll be able to change the architecture *without* changing > packet format. The rigidity and constraints on the IPng packet > design may have rather adverse impact on the ability to handle > different architectures. I completely, wholeheartedly, and emphatically support this point. Whether or not IPng, as defined in the initial round of RFCs and implemented in the next generation of host and router software, selects 16 byte (or other fixed length) addresses, the ability to use longer (or shorter) addresses with an otherwise identical packet format seems a very good thing. I'm not sure whether I've said it in so many words on this list before, and apologise in advance if I have, but my suggestion is to provide a single address length indication for all addresses in a packet [header;-], and for each suppported address length, provide a means for encodeing it in the next size larger address. I'd be happy with multiple's of 8 bytes(8,16,24,32), but perhaps what's needed is 1,2,4,8,16,32,64. Give the field 3 bits in the standard header, and then performance oriented folks can write a number of fixed length routines for each of the possible sizes. This would provide a nice incentive to keep address lengths short, since all addresses in a header would be the size of the maximum length header. [I've been waiting for this one additional opportunity. Now back to work.] Regards, Tracy From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 10:26:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02023; Mon, 11 Jul 1994 10:26:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA13007; Mon, 11 Jul 1994 10:25:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA12980; Mon, 11 Jul 1994 10:09:06 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29372; Mon, 11 Jul 1994 09:24:13 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA05475; Sun, 10 Jul 94 18:24:11 CDT Date: Sun, 10 Jul 94 18:24:11 CDT Message-Id: <9407102324.AA05475@achilles.ctd.anl.gov> To: mohta@necom830.cc.titech.ac.jp Subject: Re: Omnibus reply - EIDs Cc: big-internet@munnari.OZ.AU From: "Richard Carlson" > Masataka Ohta Writes: Masataka; >> 1. Port number - unique on individual node >> 2. Protocol type - unique on individual node >> 3. EID - globally unique >> >> None of these entites is required to be in the internetworking layer. > >What do you think a "node" is? A node is a physical thing located somewhere in the world. It supports the TCP/IP protocol suite in some way, shape, or form. That support is undefined as long as it interoperates with other TCP/IP nodes (i.e. it may be a commercial or home grown version). >You should have stated it as: > > 1. Port number - unique on an individual internetworking layer entity We are both wrong actually. It should be 1. port number - unique within the scope of a specific protocol type. The port number 53 (DNS) may be used by TCP or UDP. They use the same number, but are identifiable as separate entities. > 2. Protocol type - unique on an individual internetworking layer entity OK how about 2. Protocol type - unique within the scope of a secific internetwork layer entity >Then, to globally identify a socket, you need a globally unique id >for the internetworking layer entity, that is, an EID. No. If the EID is globally unique, it doesn't have to be associated with any specific layer. The locator value is used at the internetworking layer to verify received data is for this node. This locator value is the id for the internetworking layer entity. The locator must be unique within the scope of the network it connects to. >> How they learn these values is not an issue we are discussing. > >Then, how can the source know the locator of the destination? We haven't defined how the either Src or Dest learn the others EID. >Don't you want to use a destiantion EID to lookup the locator >in some database? This is one method (and it's probably what will be used), but it's only one method (i.e. the Internet survived for years with static host tables). > "port number + transport protocol + IPv4 address" is at transport. > "IPv4 address" is at internetworking. This duality of IPv4 (i.e. used for both identification and location) is why the IPv4 address shows up in both places. At transport it's an identifier, at networking it's a locator. > "port number + transport protocol + EID" is at transport. >Have we agreed so far? Yes I think I do. Just to be sure, what do you mean by "at"? My confussion is over your placing IPv4 addresses at both layers. If my statement about duality is correct, then I'm OK. If not, they you will need to explain things better. >If so, how can you say: > > "EID" is NOT at internetworking? > >EID is at internetworking for identification purpose. This is where we disagree. The EID is not for internetworking identification purposes, The locator address is use for that, and it is unique only within a particular network (i.e. a node may have an IPv4 address and a SIPP address). For such a dual stack node you can have 3 possible states. 1. port + protocol + IPv4 -- unique over IPv4 network 2. port + protocol + SIPP -- unique over SIPP network 3. port + protocol + EID -- unique over Both networks I am saying that state 3 doesn't require the EID be in any protocol layer. I feel that it would best fit into the transport layer, but practically it could go anywhere. How the communicating nodes exchange EID's is a matter that has yet to be discussed. Does this clarify things? Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 10:59:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02931; Mon, 11 Jul 1994 10:45:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA13041; Mon, 11 Jul 1994 10:45:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA13023; Mon, 11 Jul 1994 10:33:33 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02438; Mon, 11 Jul 1994 10:33:32 +1000 (from mo@uunet.uu.net) Received: from [153.39.128.10] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17496 Mon, 11 Jul 1994 10:33:22 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwyac23829; Sun, 10 Jul 1994 20:31:48 -0400 Date: Sun, 10 Jul 1994 20:31:48 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: big-internet@munnari.OZ.AU Subject: "over-arching architecture" for NII having now heard the NII song-and-dance a couple of different times now, I'm not at all sure I *want* there to be something like what they have in mind. -mo From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 15:17:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14081; Mon, 11 Jul 1994 15:06:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA13275; Mon, 11 Jul 1994 15:05:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA13270; Mon, 11 Jul 1994 14:57:37 +1000 Precedence: list Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11527; Mon, 11 Jul 1994 14:05:00 +1000 (from dino@cisco.com) Received: from feta.cisco.com by shark.mel.dit.csiro.au with SMTP id AA02468 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 11 Jul 1994 14:04:57 +1000 Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA05302; Sun, 10 Jul 1994 21:02:21 -0700 Date: Sun, 10 Jul 1994 21:02:21 -0700 From: Dino Farinacci Message-Id: <199407110402.VAA05302@feta.cisco.com> To: yakov@watson.ibm.com Cc: sob@hsdndev.harvard.edu, big-internet@munnari.OZ.AU In-Reply-To: yakov@watson.ibm.com's message of Sun, 10 Jul 94 15:09:30 EDT <9407101921.21762@munnari.oz.au> Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements >> Based on the above it seems that within the IPng Directorate >> there is a clear consensus that IPng packet format should >> (a) support variable length addresses, and >> (b) support fixed length 16 bytes addresses Now if the poll asked if "should be variable" is preferred over "16-bytes is OK", it could be more conclusive. Dino From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 16:21:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14898; Mon, 11 Jul 1994 15:25:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA13318; Mon, 11 Jul 1994 15:25:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA13302; Mon, 11 Jul 1994 15:18:17 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12986; Mon, 11 Jul 1994 14:42:17 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Jul 94 13:35:13 +0900 From: Masataka Ohta Message-Id: <9407110435.AA28979@necom830.cc.titech.ac.jp> Subject: Re: Omnibus reply - EIDs To: RACarlson@anl.gov (Richard Carlson) Date: Mon, 11 Jul 94 13:35:12 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407102324.AA05475@achilles.ctd.anl.gov>; from "Richard Carlson" at Jul 10, 94 6:24 pm X-Mailer: ELM [version 2.3 PL11] > >> How they learn these values is not an issue we are discussing. > > > >Then, how can the source know the locator of the destination? > > We haven't defined how the either Src or Dest learn the others EID. Really? Then, we should be talking about different things. I say EID as something to be placed in IPng packet. So, I don't mind if you say something which is not contained in IPng packet transport layer name. But, EID in a packet is at the internetworking layer. > >Don't you want to use a destiantion EID to lookup the locator > >in some database? > > This is one method (and it's probably what will be used), but it's only > one method (i.e. the Internet survived for years with static host tables). I didn't wrote DNS. I said "some database", which includes static host tables. > > "port number + transport protocol + IPv4 address" is at transport. > > "IPv4 address" is at internetworking. > > This duality of IPv4 (i.e. used for both identification and location) is > why the IPv4 address shows up in both places. At transport it's an > identifier, at networking it's a locator. You misunderstand what "identifier" means. "port number + transport protocol + IPv4 address" is the transport layer identifier. Individual "port number", "transport protocol" and "IPv4 address" are not the transport layer identifier. > > "port number + transport protocol + EID" is at transport. > >Have we agreed so far? > > Yes I think I do. Just to be sure, what do you mean by "at"? > My confussion is over your placing IPv4 addresses at both layers. No, I didn't do so. > If my statement about duality is correct, then I'm OK. If not, > they you will need to explain things better. For example, your address "RACarlson@anl.gov" identifies you. But, "RACarlson" is not your identifier. An IP address, "131.112.32.132" identifies my host, but, "131", "112", "32" and "132" is not a identifier of my host > >If so, how can you say: > > > > "EID" is NOT at internetworking? > > > >EID is at internetworking for identification purpose. > > This is where we disagree. The EID is not for internetworking identification > purposes, The locator address is use for that, Locator identifies location of a host. > and it is unique only within > a particular network (i.e. a node may have an IPv4 address and a SIPP > address). In general, locator should also be globally unique, though MAC address based local locator could be useful in some context. Of course a node may have IPv4 address as EID and locator and a 8 byte SIPP address as EID. > For such a dual stack node you can have 3 possible states. > > 1. port + protocol + IPv4 -- unique over IPv4 network > 2. port + protocol + SIPP -- unique over SIPP network > 3. port + protocol + EID -- unique over Both networks No. 1. port + protocol + IPv4 -- unique over IPv4 transport layer to be able to identify IPv4 socket 2. port + protocol + SIPP -- unique over SIPP transport layer to be able to identify SIPP socket 3. IPv4 -- unique over IPv4 internetwork layer to be able to identify IPv4 host 4. SIPP -- unique over SIPP internetwork layer to be able to identify SIPP host > I am saying that state 3 doesn't require the EID be in any protocol layer. No, of course. With IPAE, until 32 bit address space is consumed, both IPv4 and SIPP address acts as EID. After that IPv4 will only be locallly unique EID. > I feel that it would best fit into the transport layer, but practically > it could go anywhere. No. Currently, host identification is at the internetworking layer, which means that the host identifficaiton does not belongs to transport layer, which means you can't place it at the transport layer without changing the difinition of the word "transport". > How the communicating nodes exchange EID's is a > matter that has yet to be discussed. Does this clarify things? Unless you think EID is contained in IPng packet, your argument has nothing to do with IPng packet design. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 16:26:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17417; Mon, 11 Jul 1994 16:26:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA13399; Mon, 11 Jul 1994 16:25:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA13362; Mon, 11 Jul 1994 16:08:32 +1000 Precedence: list Received: from aads.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14998; Mon, 11 Jul 1994 15:28:22 +1000 (from mak@aads.net) Received: from localhost (mak@localhost) by aads.net (8.6.5/aads1.1) id BAA06300; Mon, 11 Jul 1994 01:00:35 -0400 From: Mark Knopper Message-Id: <199407110500.BAA06300@aads.net> Subject: Re: Source Routing & Provider Selection To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Date: Mon, 11 Jul 1994 01:00:35 -0400 (EDT) Cc: tli@cisco.com, yakov@watson.ibm.com, jcjones@mit.edu, Big-Internet@munnari.OZ.AU In-Reply-To: <199407070758.AA26257@mitsou.inria.fr> from "Christian Huitema" at Jul 7, 94 09:58:33 am Reply-To: mak@aads.net X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 830 Christian, We have introduced a strong requirement for source routing for provider selection, with our "AADSnet" service. It will take quite a while for the US concept of LATAs to disappear. AADSnet makes a choice of providers available to subscribers within a LATA. There are only a few options for implementing this, and source route tunnelling seems to be a leading contender. I just wanted to make this need clear in the debates. Mark > > Tony, > > ... > > 3) Source routing for provider selection is not used much. Fact is that you > only "need" it, today, if you have several providers for the same site or > if you don't want the default provider of your regional. Most of the case I > am aware of boil down to tunnelling through a regional to reach your > prefered provider. > > Christian Huitema From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 16:30:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17671; Mon, 11 Jul 1994 16:30:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA13414; Mon, 11 Jul 1994 16:29:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA13365; Mon, 11 Jul 1994 16:09:47 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16852; Mon, 11 Jul 1994 16:09:42 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA11523; Sun, 10 Jul 94 23:00:14 -0700 Received: by xirtlu.zk3.dec.com; id AA12152; Mon, 11 Jul 1994 02:00:08 -0400 Message-Id: <9407110600.AA12152@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: sob@hsdndev.harvard.edu, big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Sun, 10 Jul 94 15:09:30 EDT." <9407101921.21762@munnari.oz.au> Date: Mon, 11 Jul 94 02:00:02 -0400 X-Mts: smtp Yakov, I read the result that folks (I do anyway) generally feel 16 is OK for consensus to begin building IPng after 4 years of talk and no consensus. And a starting point (with the source route function figured out) for an IPng working group to begin work using what we learned from IPng in various working groups. The question of variable was secondary in my mind as a logic check. The real issue is that 16bytes can support a very large Internet, not totally horrible for hosts and routers, and offers a consensus for those who did not think 8bytes were enough for the Internet, Autoconfiguration, or topological administration for networks. In addition I am keeping in a separate folder all mail on this subject for my own sanity and responses are not just flat yes or no, but also why they respond the way they do. So I think the question is bringing forth the result needed to determine if we can move forward now with IPng and get on with building the next generation IP for the Internet. We need to get all of us working on the same solution and putting all our expertise into the same forum and building IPng as a group/team. If we can do this we have made great progress. If there is only a few voices of discontent then we must just move forward anyway. Or we are never going to get anywhere. Kind a like getting all the folks to sing out of the same barrel. p.s. I do hope folks read Richards Draft and come to the EID BOF Kre has set up. I think this is important. take care, /jim From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 17:06:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19214; Mon, 11 Jul 1994 17:06:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA13477; Mon, 11 Jul 1994 17:05:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA13461; Mon, 11 Jul 1994 16:52:19 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18720; Mon, 11 Jul 1994 16:52:00 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 11 Jul 1994 07:50:51 +0100 To: sipp@sunroof.Eng.Sun.COM Cc: SIPP Mailing list , big-Internet@munnari.OZ.AU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: (sipp) Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Sun, 10 Jul 94 12:38:05 BST." <1608.773840285@cs.ucl.ac.uk> Date: Mon, 11 Jul 94 07:50:48 +0100 Message-Id: <480.773909448@cs.ucl.ac.uk> From: Jon Crowcroft >then the table grows as 2**F * ln H.... now given we have a) the internet growth figures b) the memory cost figures c) the router cost figures (for when you need to replace a whole router to be able to put in more memory:-) someone can do some curve fitting and find the most cost effective way of meeting the addressing requirements scientifically.... i havn't seen anyone do that yet. j From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 17:30:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17721; Mon, 11 Jul 1994 16:32:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA13433; Mon, 11 Jul 1994 16:32:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA13383; Mon, 11 Jul 1994 16:19:44 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14438; Mon, 11 Jul 1994 15:14:56 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Jul 94 14:08:50 +0859 From: Masataka Ohta Message-Id: <9407110509.AA29153@necom830.cc.titech.ac.jp> Subject: Re: Source Routing & Provider Selection To: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 11 Jul 94 14:08:48 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <27310.773860705@munnari.OZ.AU>; from "Robert Elz" at Jul 11, 94 3:18 am X-Mailer: ELM [version 2.3 PL11] > Instead, the source host can just say "I want to reserve a 32MHz path > to host D with flow ID of 123". Then, the source can expect intermediate > routers do the confirmation, reservation and routing table setup. > > This only works in the simplest cases, where every possible > criterion upon which the source may wish to choose a route > is known in advance,that is, standardised, along with a whole > syntax to allow the particular combination of all those factors > that the source desires to be expressed. > > The second part of that is possible, though cumbersome - the > first seems so unlikely as to be barely worth considering. Source routing only works in the simplest cases, where every possible routing information upon which the source may wish to choose a route is propagated to the source, that is, standardised, along with a whole semantics to allow the particular thinning of all those factors for the layered routing. The second part is practically impossible, the first is no different between source routing and distributed QoS assurance. > eg: if you were enumerating the criteria upon which I may want > to tell the routers to choose a path, would you include "avoid > paths that go through areas where the provider buys power from > a power company that uses nuclear power generation" ? Though it is not QoS but policy routing, you can say it in your path setup packet that "avoid paths that go through areas with the following providers: A, B, C, ...". You don't have to tell intermediate routers your philosophy. > That's > not the kind of thing that you'd usually consider - yet some > users may really want to adopt a policy like that. Provider selection is the thing we should support, though the complexity of policy should be costly to the user. > You can > make as big a list of criteria to standardise for all the routers > and I promise I'll find something else plausible that you've > omitted, I does not matter. It's source's responsibility to express its policy in a list of favoured and disfavoured providers. > The only practical way to allow general provider selection is to > allow the source to do it, and simply say where the packet > should go. So, let the host express its policy and let routers enforce it. > That still doesn't goive any clue as to how the > source will obtain all the information on which it may want to > make decisions, > but none of that is an internet layer > problem, its all localised - vendors can offer this with as > much complexity & flexibility as they can find customers to > pay for. It is simply impossible for the vendor to tell the source about the states of all the links in the world. So, if you want to say "I need a 32MHz path", to everywhere in the world, you should expect the foreign routers do the job. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 21:58:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28266; Mon, 11 Jul 1994 21:26:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA13720; Mon, 11 Jul 1994 21:25:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA13704; Mon, 11 Jul 1994 21:17:54 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB28037; Mon, 11 Jul 1994 21:17:45 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA13825; Mon, 11 Jul 94 06:19:32 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id as02947; 11 Jul 94 11:14 GMT Date: Mon, 11 Jul 94 06:14 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: "Mike O'Dell" To: big internet Subject: Re: "cluster nets" Message-Id: <54940711111445/0003858921NA2EM@mcimail.com> >As an example of how this is really being done (and a *very* >interesting hack to consider as part of a "transition strategy"), >consider FIREFOX, a TCP product for the Novell IPX world. OK for smallish nets. A loser for big nets like ours. Most user here has at least 2 TCP connections all day long. At 100 users per many servers (and we are working on 'super servers') you run against connection limits. Thus as we all know, proxying is not a very effective solution for large groups of users... But yes, it is neat for the small shop. Bob From owner-Big-Internet@munnari.OZ.AU Mon Jul 11 23:36:58 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00226; Mon, 11 Jul 1994 22:29:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04041 Mon, 11 Jul 1994 22:28:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA13789; Mon, 11 Jul 1994 22:25:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA13773; Mon, 11 Jul 1994 22:22:26 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29924; Mon, 11 Jul 1994 22:22:19 +1000 (from yakov@watson.ibm.com) Message-Id: <9407111222.29924@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3499; Mon, 11 Jul 94 08:22:14 EDT Date: Mon, 11 Jul 94 08:20:35 EDT To: dino@cisco.com, big-internet@munnari.OZ.AU Cc: sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Sun, 10 Jul 1994 21:02:21 -0700 Dino, >Now if the poll asked if "should be variable" is preferred over >"16-bytes is OK", it could be more conclusive. That is an excellent idea. Perhaps we could ask IPng ADs (Allison and Scott) to poll the IPng Directorate on this question ? Yakov. From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 01:46:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07924; Tue, 12 Jul 1994 01:46:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA14328; Tue, 12 Jul 1994 01:45:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA14312; Tue, 12 Jul 1994 01:26:42 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07031; Tue, 12 Jul 1994 01:26:35 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14427(3)>; Mon, 11 Jul 1994 08:26:19 PDT Received: by redwing.parc.xerox.com id <57153>; Mon, 11 Jul 1994 08:26:15 -0700 Date: Mon, 11 Jul 1994 08:26:09 PDT Sender: Lixia Zhang From: Lixia Zhang To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Sun, 10 Jul 1994 13:18:27 -0700 Message-Id: > >I did not say the address should be variable length AT THIS TIME. > Do you mean that the IPng packet format AT THIS TIME should > have only fixed length address capabilities, or do you mean > that the addresses used in the Internet AT THIS TIME should > be of fixed length ? Yes and yes, depending how you interpret the "IPng packet format". Various ways are possible to extend the address, right? e.g. an explicit length field in the base header is one way, defining a special option another. > >I even don't think it is technically feasible to deploy > >variable length addresses at this time. > > Would you please elaborate on why this isn't technically feasible. Two bullets on top of my list: (1) Unsettlement of EID issues. IPv4 transport layer uses the address in its ID. I believe this transport ID desires very much to be of fixed length. Though people have talked a lot about the seperation of the two, there are still open issues. Given IEEE MAC addresses are not unique, I question why we should believe that some other authority can indeed do a much better job to manage truly globaly unique EIDs, how could one assure that every device, however big or small, will manage to get a valid EID from the authority (especially when I think the case of having all light switches on the net). Yes we have to manage address assignment, but addresses management is somewhat different from EIDs (by whatever definition, just independent from address), i.e. much easier enforcement and detection of fraud. A box probably wont get its data if it doesn't have a valid address, and a fraud address seems (to me) easier to detect because of its topological meanings, as compared to much less structured, or totally flat, EIDs. (2)how much variable length addresses buys you, or how much more we need to learn about it All the currently proposed variable length address schemes have a *fixed space* to work within. and as I said at Chicago meeting, if a so called "variable length address" only extends to the right (as the proposal on the table), the shorter an address is, the larger portion of the total space it consumes, a much worse wasting factor. One merely uses a bigger space to tolerate such waste. Ross Callon once commented that, if we do a variable length address, we should make it extensible to the left as well for certain patterns of growth. I have not seen any proposal to address that issue. Personally I just do not feel enough research has been done in variable addresses (e.g. a very simple question: does it have to be limited to a fix max space? Yakov says yes because there is a fixed length field, but I think that's simply how ISO did it. Isnt it possible not to have a length field?) If we go variable address I feel it has to meet the need for infinite growth (say when networking extending to Mars :-). When I suggested to study a var address option, I was really thinking that some new work is yet to be done. I really liked the excellent comment Richard Fox put out: "One of the problems with IPv4 is the waste factor. There are 2 ways to solve this. Solve the problem or solve the symptom." If someone presents strong argument showing 16 bytes is not enough, I feel that it would not be too difficult to twist the argument a bit and say that 24 or 32 byte may not be too much better either if we jsut waste the space carelessly. On the other hand, I havent heard anyone saying we'd run out 16-byte space even if we utilize them efficiently. Lixia From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 01:59:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05432; Tue, 12 Jul 1994 00:26:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA14237; Tue, 12 Jul 1994 00:25:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA14094; Tue, 12 Jul 1994 00:07:24 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02252; Mon, 11 Jul 1994 23:22:22 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwycb18554; Mon, 11 Jul 1994 09:20:38 -0400 Message-Id: To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: "Mike O'Dell" , big internet Subject: Re: "cluster nets" In-Reply-To: Your message of "Mon, 11 Jul 1994 06:14:00 EST." <54940711111445/0003858921NA2EM@mcimail.com> Date: Mon, 11 Jul 1994 09:20:36 -0400 From: "Mike O'Dell" I agree that proxies have their problems, but if this were deemed *important*, I'm quite sure the marketplace could field proxy units which could manage more than 200 TCP connnections without pooping out. sounds like a wonderful business opportunity. -mo From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 03:06:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10906; Tue, 12 Jul 1994 03:06:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14489; Tue, 12 Jul 1994 03:05:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14484; Tue, 12 Jul 1994 03:03:03 +1000 Precedence: list Received: from news.cis.ohio-state.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10849; Tue, 12 Jul 1994 03:02:59 +1000 (from npatel@news.cis.ohio-state.edu) Received: from apache.cis.ohio-state.edu (apache.cis.ohio-state.edu [164.107.42.6]) by news.cis.ohio-state.edu (8.6.8.1/8.6.4) with ESMTP id NAA02600 for ; Mon, 11 Jul 1994 13:02:39 -0400 From: nitesh p patel Received: (npatel@localhost) by apache.cis.ohio-state.edu (8.6.7/8.6.4) id NAA00621 for big-internet@munnari.oz.au; Mon, 11 Jul 1994 13:02:37 -0400 Date: Mon, 11 Jul 1994 13:02:37 -0400 Message-Id: <199407111702.NAA00621@apache.cis.ohio-state.edu> To: big-internet@munnari.OZ.AU Subject: Get on the List I need to get on the list. Please enroll me asap. Thanks Nitesh From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 03:59:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09439; Tue, 12 Jul 1994 02:26:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA14441; Tue, 12 Jul 1994 02:25:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14423; Tue, 12 Jul 1994 02:10:12 +1000 Precedence: list Received: from upurbmw.us.dell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06765; Tue, 12 Jul 1994 01:13:06 +1000 (from sblair@upurbmw.us.dell.com) Received: by upurbmw.us.dell.com (931110.SGI/930416.SGI) for big-internet@munnari.OZ.AU id AA03731; Mon, 11 Jul 94 10:10:50 -0500 From: "Steven C. Blair" Message-Id: <9407111010.ZM3729@upurbmw.us.dell.com> Date: Mon, 11 Jul 1994 10:10:50 -0500 In-Reply-To: "Mike O'Dell" "Re: "cluster nets"" (Jul 11, 9:20am) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Mike O'Dell" , "Robert G. Moskowitz" <0003858921@mcimail.com> Subject: Re: "cluster nets" Cc: big internet Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Mike O'Dell: I agree that proxies have their problems, but if this were deemed *important*, I'm quite sure the marketplace could field proxy units which could manage more than 200 TCP connnections without pooping out. sounds like a wonderful business opportunity. Take the case of the large sites( < 5000 IPX, or NetBios) machines into account and the marketplace will quickly embrace a setup such as FIREFOX. I am currently watching my Corp I/S folks wrestle with the 7000(++) IPX stations going to IP, thus a 8bit space for long term needs + proxy services could stave off the wolves. If the proxy agent is not further architected, then 16bit will be the choice of a small, but quickly growing address space. scb -- Steven C. Blair dell computer corp "We need to remember that IP was designed to do a basic job and do it cleanly. Whatever warts and limitations exist with it, we need to remember that it does its basic job astonishingly well." - Dave Crocker From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 05:24:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13628; Tue, 12 Jul 1994 04:26:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA14655; Tue, 12 Jul 1994 04:25:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA14639; Tue, 12 Jul 1994 04:15:55 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13172; Tue, 12 Jul 1994 04:15:50 +1000 (from pvm@ISI.EDU) Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Mon, 11 Jul 1994 11:14:41 -0700 Message-Id: <199407111814.AA19216@zephyr.isi.edu> To: Jon Crowcroft Cc: vjs@rhyolite.denver.sgi.com (Vernon Schryver), Big-Internet@munnari.OZ.AU Reply-To: pvm@isi.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Fri, 08 Jul 1994 09:05:51 +0100. <860.773654751@cs.ucl.ac.uk> Date: Mon, 11 Jul 94 11:11:16 PDT From: Paul Mockapetris > still not convinced. > > > jon Jon, I'll join you in the "still not convinced" column, but I think the issue not length, per se, but length within an addressing/naming scheme and a vision of customer demand. In general, we could trade additional levels of binding for shorter "addresses" in the packets. UIDs will only be relevant in relation to a precise set of resources, i.e. information, "controlled" by the UID. Accountants and those that seek to bug the communications infrastructure like to be able to trace physical things, but the average user will probably care less and less. In any case, its doubtful that the concept, per se, requires each packet to carry them. However, the bits required in an address is probably linear with respect to the number of administrative levels which allocate addresses, and bureaucracies are a growth industry. So there are many who feel that a variable structure, perhaps with a 5 year moratorium on use, is the only way to go. Just for the insurance. I wonder if we would have all of these disagreements about lengths if we all had the same assumptions and visions to start with? paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 06:01:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15613; Tue, 12 Jul 1994 05:26:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA14795; Tue, 12 Jul 1994 05:25:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14759; Tue, 12 Jul 1994 05:24:52 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13566; Tue, 12 Jul 1994 04:24:06 +1000 (from pvm@ISI.EDU) Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Mon, 11 Jul 1994 11:23:57 -0700 Message-Id: <199407111823.AA20437@zephyr.isi.edu> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: big internet Reply-To: pvm@isi.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Fri, 08 Jul 1994 07:51:00 -0500. <03940708125130/0003858921NA3EM@mcimail.com> Date: Mon, 11 Jul 94 11:20:27 PDT From: Paul Mockapetris > Well, I have thought a lot about this. > > Variable is out. Human's, being the way they are (notice the structure, us > IPngers can't be humans :), and corporate creatures, being a more > exasperating form of human's, cannot cope with variable decision processes. > A lot of people will spin their wheels with the variable length and what > will emerge will be a recommendation, followed by everyone eventually on how > to structure the address. Just like NSAPs.... > > People LIKE fixed things. The question is if it is fixed, is it fixed > enough over time. So we hedge our bets by doubling our best guess and then > do a few things to weaken that guess by adding functionality into the larger > number. I don't understand your argument. People use variable length personal names, domain names, telephone numbers, ... paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 06:16:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17152; Tue, 12 Jul 1994 06:06:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA14843; Tue, 12 Jul 1994 06:05:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14836; Tue, 12 Jul 1994 05:55:35 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16776; Tue, 12 Jul 1994 05:55:30 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty17.jvnc.net. (franklin-tty17.jvnc.net) by tigger.jvnc.net with SMTP id AA02024 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Mon, 11 Jul 1994 15:55:20 -0400 Message-Id: Date: Mon, 11 Jul 94 15:54:20 EDT From: "David M. Piscitello" Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: dave@corecom.com To: big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 >At this time it would appear to us that there is considerable consensus >that a fixed length, topologically structured, hierarchical >address 16 bytes in length is reasonable for an IPng (that is >meets the needs of the very very large-scale Internet). Hi, Sorry to throw fuel on a fire that's totally out of control, but there are 2 dimensions to this problem that always seem to get muddled. There's the address, then there's how to encode it in a packet. There's a considerable force in favor of 64-bit alignment of the IPng header, and 16 octets, a.k.a. 128 bits is conveniently (a) a multiple of 64-bits (b) larger than 8 octets (a.k.a., 64-bits), which a number of people conclude is too small (c) sufficiently large as to allow us to delude ourselves into thinking we won't ever have to repeat this exercise How convenient, a number that seemingly satisfies everyone. But, suppose I use up 8 octets on the system identifier (easy if I elect to embed an E.164 (ATM) address in my IPng address to facilitate autoconfiguration as per TUBA/CLNP). Suppose that the organization that administers E.164 addresses by some remarkable twist of fate discovers that it, too, has run out of addresses, and expands its addresses to 12 octets. Finally, suppose I had used six octets for hierarchy in assignment of networks. I am S-O-L... David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 08:26:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21185; Tue, 12 Jul 1994 08:26:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA15041; Tue, 12 Jul 1994 08:25:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA15011; Tue, 12 Jul 1994 08:08:04 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19672; Tue, 12 Jul 1994 07:39:32 +1000 (from kre@munnari.OZ.AU) To: dave@corecom.com Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Mon, 11 Jul 1994 15:54:20 EDT." Date: Tue, 12 Jul 1994 07:39:27 +1000 Message-Id: <27547.773962767@munnari.OZ.AU> From: Robert Elz Date: Mon, 11 Jul 94 15:54:20 EDT From: "David M. Piscitello" Message-ID: There's the address, then there's how to encode it in a packet. This is true, but I'm not sure that its relevant, for all practical purposes (here at least) the encoding in the packet is the address - that it could conceptually have some other form isn't very useful. But, suppose I use up 8 octets on the system identifier Suppose that the organization ... expands its addresses to 12 octets. Exactly. This is perhaps the best reason why attempting to stick 6 byte MAC addresses (or any other flavour of the month link level address) inside an IPng address is short sighted and silly. Much better would be to define a mapping from random-standard-X type addresses into IPng addresses (the low bits thereof), either algorithmic, or via a server. kre From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 08:31:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21316; Tue, 12 Jul 1994 08:31:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA15056; Tue, 12 Jul 1994 08:31:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA15014; Tue, 12 Jul 1994 08:08:25 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20281; Tue, 12 Jul 1994 08:02:30 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Subject: Re: Source Routing & Provider Selection In-Reply-To: Your message of "Mon, 11 Jul 1994 14:08:48 +0200." <9407110509.AA29153@necom830.cc.titech.ac.jp> Date: Tue, 12 Jul 1994 08:01:24 +1000 Message-Id: <27557.773964084@munnari.OZ.AU> From: Robert Elz Date: Mon, 11 Jul 94 14:08:48 JST From: Masataka Ohta Message-ID: <9407110509.AA29153@necom830.cc.titech.ac.jp> Source routing only works in the simplest cases, where every possible routing information upon which the source may wish to choose a route is propagated to the source, that is, standardised, along with a whole semantics to allow the particular thinning of all those factors for the layered routing. I appreciate your play on my words - but this is simply not true. Not "every possible routing information" needs to be propogated to the source, only those that this particular source wishes to use. Nor does any of this need to be standardised, the source can collect and represent this information however it feels inclined. This need not have anything whatever to do with protocols (in the sense we use them here), the source could have someone reading the tabloid newspapers and arranging for packets to avoid all the areas where little green mean steal and eat babies... Though it is not QoS but policy routing, you can say it in your path setup packet that "avoid paths that go through areas with the following providers: A, B, C, ...". Yes, provided that its a whole provider that you want to avoid, and not just some particular part. You could expand this to any level of detail, eventually what you have is a source route expressed in negative logic. Personally I find positive logic easier to express, and easier to verify, and almost always much much shorter (if I say where I want my packets to go, I will know where they are going, to the level of detail I have expressed, I won't have to list the whole universe where they are not supposed to go). Provider selection is the thing we should support, though the complexity of policy should be costly to the user. yes, exactly - sources with complex requirements should have the burden of working out how to form a path that meets their requirements, the routers don't need to (nb: "source" here could conceivably be a filewall box, exit router, or various other possibilities). I does not matter. It's source's responsibility to express its policy in a list of favoured and disfavoured providers. But "provider" is not necessarily the correct level of granularity. And in any case, expressing a list of favoured providers is a source route. It is simply impossible for the vendor to tell the source about the states of all the links in the world. No-one is likely to need the state of all the links in the world, and if they do, its upon them to obtain all that information somehow. Source routing doesn't need that level of detail, necessarily, though it allows it should it really be required. So, if you want to say "I need a 32MHz path", to everywhere in the world, you should expect the foreign routers do the job. Now you're back to telling intermediate routers your philosophy again - this is not just a list of favoured and disfavoured providers. As soon as you start allowing sources to say "I need..." you're back in the situation of either allowing only a small set of possible needs, which will likely be insufficient for the future, or you have an encoding and representation problem which to me seems impossible to solve. kre From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 10:08:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23235; Tue, 12 Jul 1994 09:26:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA15131; Tue, 12 Jul 1994 09:25:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA15104; Tue, 12 Jul 1994 09:09:54 +1000 Precedence: list Received: from thor.tjhsst.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17678; Tue, 12 Jul 1994 06:22:07 +1000 (from cmetz@thor.tjhsst.edu) Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0qNRt1-000AelC; Mon, 11 Jul 94 16:23 EDT Message-Id: To: pvm@isi.edu Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Mon, 11 Jul 1994 11:20:27 EDT." <199407111823.AA20437@zephyr.isi.edu> Date: Mon, 11 Jul 1994 16:23:34 EDT From: Craig Metz In message <199407111823.AA20437@zephyr.isi.edu>, you write: >People use variable length personal names, domain names, telephone numbers, .. Have any of the people pushing variable length addresses stopped to wonder why, in this age of increasing machine word sizes, people don't make computers that use variable-length integers? Think of the applications! No more range problems. All of the accuracy you need. Specific programs could choose integers based on their needs, and they can always be made bigger or smaller later. No more problems porting to architectures with different word sizes -- programs written for variable length integers will work on machines with 32, 64, or even 67 bit word sizes without any additional difficulties. We never do know just how big a number we might need; why obselete our architectures now by settling for fixed word sizes of only 32 or 64 bits? It's not like it can't be done. Look at all of the multiple-precision math packages out there. It can be emulated in software with ease on today's high performance machines, and we can build variable-length words into tomorrow's processors and bus designs. Sure, there will be technical hurdles, From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 10:43:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24841; Tue, 12 Jul 1994 10:06:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA15177; Tue, 12 Jul 1994 10:05:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA15172; Tue, 12 Jul 1994 10:04:49 +1000 Precedence: list Received: from usage.csd.unsw.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23265; Tue, 12 Jul 1994 09:27:19 +1000 (from paul@atlas.dev.abccomp.oz.au) Received: by usage.csd.unsw.OZ.AU id AA12875 (5.65c/IDA-1.4.4 for big-internet%munnari.oz.au); Tue, 12 Jul 1994 09:19:46 +1000 Received: by atlas (4.1/1.35) id AA16468; Tue, 12 Jul 94 09:29:48 EST Message-Id: <9407112329.AA16468@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 12 Jul 1994 09:29:47 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Masataka Ohta Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU I saw this days ago - I almost made the point then, but since the message has floated around again, I'll make it now.. Thus expounded Masataka Ohta on Jul 6,11:09am: /-------------------- | |You are talking about "serverless autoconfiguration", aren't you? | |In a closed environment where there are only two host's on an isolated |LAN, you don't have to worry about impersonation during autoconfiguration. | |In an open environment, a newly purchased host should be preconfigured |with authentication information of a name server running at a user |service center of a vendor, through which, the host can securely know |which autoconfiguration server is it talking. Now, it is user's |responsibility to judge whether the autoconfiguration server represented |with symbolic host name is trustable or not. If I had a link that could reach the vendor's service centre, I'd be delighted. Even if I did have full global Internet access, there is no guarantee that the link will be up, or that the vendor's link will be working, at the time I run up my newly-purchased machine. Any scheme that requires a host to talk to the vendor's network or any other net outside the installation site just won't fly. Looking ahead, I can just imagine the supervisor telling the building manager "Sorry Sir, but your newly installed internet-capable elevator refuses to start until XYZ Corp overseas repairs their internal network". -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 10:43:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25557; Tue, 12 Jul 1994 10:26:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA15220; Tue, 12 Jul 1994 10:25:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA15191; Tue, 12 Jul 1994 10:08:24 +1000 Precedence: list From: daniel@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23098; Tue, 12 Jul 1994 09:23:13 +1000 (from daniel@ISI.EDU) Received: from dza.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Mon, 11 Jul 1994 16:23:06 -0700 Date: Mon, 11 Jul 94 16:22:53 PDT Posted-Date: Mon, 11 Jul 94 16:22:53 PDT Message-Id: <9407112322.AA07575@dza.isi.edu> Received: by dza.isi.edu (4.1/4.0.3-4) id ; Mon, 11 Jul 94 16:22:53 PDT To: mohta@necom830.cc.titech.ac.jp Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: Masataka Ohta's message of Mon, 11 Jul 94 14:08:48 JST <9407110509.AA29153@necom830.cc.titech.ac.jp> Subject: Source Routing & Provider Selection Reply-To: daniel@ISI.EDU >> Instead, the source host can just say "I want to reserve a 32MHz path >> to host D with flow ID of 123". Then, the source can expect intermediate >> routers do the confirmation, reservation and routing table setup. >> >> This only works in the simplest cases, where every possible >> criterion upon which the source may wish to choose a route >> is known in advance,that is, standardised, along with a whole >> syntax to allow the particular combination of all those factors >> that the source desires to be expressed. >> >> The second part of that is possible, though cumbersome - the >> first seems so unlikely as to be barely worth considering. > Source routing only works in the simplest cases, where every possible > routing information upon which the source may wish to choose a route > is propagated to the source, that is, standardised, along with a whole > semantics to allow the particular thinning of all those factors for > the layered routing. > The second part is practically impossible, the first is no different > between source routing and distributed QoS assurance. There's a big difference between source routing and distributed QOS assurance. With source routing, you only need to distribute topology to the endpoints. Using feedback from prior decisions, the source chooses a route that has a potential to meet the QOS requirements, and the admission control at each node confirms or denies the request. (Relevant to your earlier discussion with Deborah --- Once the route and reservation are established, data packets can use a flow ID to access the preferred route. Data packets don't carry the source route.) With what I guess you mean by distributed QOS assurance, routers need to distribute not only their capabilities, but the current status of their resources to each other router, AND form routes based on numerous combinations of those current QOS attributes. I.e. between endpoint A and enpoint B you would need to store a shortest-path route, a QOS1 route, a QOS2 route, etc. Not to mention different policy combinations. This is far too much state in the network for this solution to scale. Perhaps I've misread what you mean by distributed QOS assurance. Maybe you can post some details of what you mean? Daniel From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 11:26:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27866; Tue, 12 Jul 1994 11:26:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA15292; Tue, 12 Jul 1994 11:25:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA15276; Tue, 12 Jul 1994 11:24:48 +1000 Precedence: list Received: from thor.tjhsst.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27828; Tue, 12 Jul 1994 11:23:41 +1000 (from cmetz@thor.tjhsst.edu) Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0qNWbI-000AelC; Mon, 11 Jul 94 21:25 EDT Message-Id: To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Date: Mon, 11 Jul 1994 21:25:36 EDT From: Craig Metz In message , I wrote: >high performance machines, and we can build variable-length words into >tomorrow's processors and bus designs. Sure, there will be technical hurdles, Sorry, everyone, that wasn't meant to go out to the world, and CERTAINLY wasn't meant to be sent unfinished. An editor session got killed, and it decided to send out the message, anyway. In my opinion, not at all an appropriate way for a mailer to handle the situation. Now pretty well cornered, the point I was trying to make was that, while people may deal well with things that vary in length, machines don't. Anyone who would try to design a computer system that uses all variable word sizes would have to be just slightly crazy. It may be doable, but it couldn't work nearly as well with current technology as fixed word sizes such as 32 or 64 bits. For the same performance and complexity reasons we would use fixed rather than variable word sizes, integers rather than floating point numbers, and native data types instead of multiple-precision libraries, we should use fixed length addresses instead of variable length ones. The latter add more complexity, degrades performance, and it does so in every operation that manipulates the variable (including, but far from limited to, where we would traditionally expect to manipulate address fields). Those of us who use the C programming language will be especially comforted in knowing that, instead of being able to use things like structures and sizeof() to manipulate headers, we would have to actually parse them for many common manipulations. Worse, we have to either make implementations that assume worst-case resource usage or, as in the case of most OSI implementations, we must blindly assume limits that will eventually be the downfall of those implementations and of the protocol itself. And what does this buy us? The illusion that we will never again have to renumber? The freedom to create extravagant, incompatible addressing schemes that will be less efficient and create more routes than even the worst case IPv4 scenarios? I can see why some people may be concerned that eight bytes may not be enough to hold addresses for the next twenty years. Personally, I think that, given a well thought out allocation strategy and automatic address changes, eight bytes of address space (enough for 18,446,744,073,709,551,616 hosts in the impossible case of 100% density) would be plenty for the next twenty years, if not much more. But I can understand some people's reasons for wanting sixteen bytes of address space, and I don't think that they are unreasonable. So, that's what I personally support (though I'm working with negative credibility due to the aforementioned mailer problem). The big problem here is that most everyone on this list already has his or her own opinion and is not going to change it. The same people support variable addresses, the same people support 8-byte, and the same people support 16-byte. So, maybe the more appropriate question would be, since there will not be agreement and there will not be compromise, where really can we go from here? Again, my apologies for the first letter. It was not supposed to go to the entire list in *any* case, and wasn't supposed to get sent out on a virtual terminal hangup, either. In the meantime, I think it's time for me to find a new mailer. -Craig From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 13:06:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01833; Tue, 12 Jul 1994 13:06:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA15451; Tue, 12 Jul 1994 13:05:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15440; Tue, 12 Jul 1994 12:56:17 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01542; Tue, 12 Jul 1994 12:56:00 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Jul 94 11:49:16 +0900 From: Masataka Ohta Message-Id: <9407120249.AA03436@necom830.cc.titech.ac.jp> Subject: Re: Draft proposal for EIDs To: RACarlson@anl.gov (Richard Carlson) Date: Tue, 12 Jul 94 11:49:15 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407092303.AA04542@achilles.ctd.anl.gov>; from "Richard Carlson" at Jul 9, 94 6:03 pm X-Mailer: ELM [version 2.3 PL11] > I have placed a copy of my proposed RFC on my ftp server. > > achilles.ctd.anl.gov:/pub/ietf/tcpv11b.txt > > You should note that I wrote this paper before I heard of EIDs, so the > term Transport Address (TA) is used instead. You can send me comments > directly, to the list, or wait until Toronto. I have read it. You say: As not all the hosts in the world have IPv4 addresses, we can't have the uniform transport layer identifier (IPv4 address, protocol, port). If all the hosts in the world have globally unique EID, we can have the uniform transport layer identifier (EID, protocol, port). Of course, it is as true as: If all the hosts in the world have globally unique IPv4 addresses, we can have the uniform transport layer identifier (IPv4 address, protocol, port). or If all the hosts in the world have globally unique IPng addresses, we can have the uniform transport layer identifier (IPng address, protocol, port). or If all the hosts in the world have some globally unique internetwork layer identifier, we can have the uniform transport layer identifier (internetwork layer identifier, protocol, port). So? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 13:26:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02714; Tue, 12 Jul 1994 13:26:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA15494; Tue, 12 Jul 1994 13:25:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA15478; Tue, 12 Jul 1994 13:24:40 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02674; Tue, 12 Jul 1994 13:24:34 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Jul 94 12:17:50 +0859 From: Masataka Ohta Message-Id: <9407120318.AA03609@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request To: paul@atlas.abccomp.oz.au Date: Tue, 12 Jul 94 12:17:49 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407112329.AA16468@atlas>; from "paul@atlas.abccomp.oz.au" at Jul 12, 94 9:29 am X-Mailer: ELM [version 2.3 PL11] > |You are talking about "serverless autoconfiguration", aren't you? > | > |In a closed environment where there are only two host's on an isolated > |LAN, you don't have to worry about impersonation during autoconfiguration. > | > |In an open environment, a newly purchased host should be preconfigured > |with authentication information of a name server running at a user > |service center of a vendor, through which, the host can securely know > |which autoconfiguration server is it talking. Now, it is user's > |responsibility to judge whether the autoconfiguration server represented > |with symbolic host name is trustable or not. > If I had a link that could reach the vendor's service centre, I'd be delighted. > Even if I did have full global Internet access, there is no guarantee that the > link will be up, or that the vendor's link will be working, at the time I > run up my newly-purchased machine. You still have an option to do insecure autoconfiguration or secure handconfiguration, of course. > Any scheme that requires a host to talk > to the vendor's network or any other net outside the installation site just > won't fly. On the other hand, as vendors can't provide site local authentication information, any local autoconfiguration scheme can't be so secure. > Looking ahead, I can just imagine the supervisor telling the building > manager "Sorry Sir, but your newly installed internet-capable elevator refuses > to start until XYZ Corp overseas repairs their internal network". IMHO, it's better than "Sorry Sir, but your newly installed internet-capable elevator is hijacked." Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 14:55:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00246; Tue, 12 Jul 1994 12:26:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15384; Tue, 12 Jul 1994 12:25:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15352; Tue, 12 Jul 1994 12:11:03 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24892; Tue, 12 Jul 1994 10:07:42 +1000 (from yakov@watson.ibm.com) Message-Id: <9407120007.24892@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6181; Mon, 11 Jul 94 20:07:42 EDT Date: Mon, 11 Jul 94 19:59:43 EDT To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Fri, 8 Jul 94 09:21:42 EDT Frank, >If there are two analyses, coming to different conclusions, then at least >one (if not both) is wrong in either its logic or its underlying >assumptions. >Perhaps the discussion should be centered on these analyses, their >logic, and their assumptions, yes ? YES !!! Since the IPng Directorate is responsible for evaluating various IPng proposals, and since the issue of address length requirements is one of the key issues for the IPng, we probably should ask the IPng Directorate, and specifically Scott and Allison, two questions: (a) do they see a need for the discussion that is centered on the various analyses, their logic and their assumption ? (b) if the answer to (a) is "yes", then how do they plan to proceed ? Yakov. From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 15:06:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06727; Tue, 12 Jul 1994 15:06:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA15591; Tue, 12 Jul 1994 15:05:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA15584; Tue, 12 Jul 1994 14:55:40 +1000 Precedence: list Received: from olivea.atc.olivetti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01629; Tue, 12 Jul 1994 12:58:44 +1000 (from jerry@strobe.ATC.Olivetti.Com) Received: by olivea.ATC.Olivetti.Com (5.65/1.34) id AA13233; Mon, 11 Jul 94 19:57:15 -0700 Received: from strobe.ATC.Olivetti.Com by olivea.ATC.Olivetti.Com (4.1/SMI-4.1) id AA13230; Mon, 11 Jul 94 19:57:13 PDT Received: by strobe.ATC.Olivetti.Com (4.1/SMI-4.1) id AA17404; Mon, 11 Jul 94 19:57:13 PDT Date: Mon, 11 Jul 94 19:57:13 PDT From: jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) Message-Id: <9407120257.AA17404@strobe.ATC.Olivetti.Com> To: big-internet@munnari.OZ.AU, cmetz@thor.tjhsst.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements From: Craig Metz >high performance machines, and we can build variable-length words into >tomorrow's processors and bus designs. Sure, there will be technical hurdles, I don't find this a good analogy. Today's processors DO support variable length integers in hardware. Of course I don't mean 1-N bits but every general purpose processor I am familiar with supports, using C naming conventions, char, short int, and long int. That is three sizes of integers typically 1, 2, or 4 bytes. And for floating point they typically support single and double precision. If you are going to argue based on CPU designs then the network should support "fixed length" 4, 8, and 16 byte address formats. We could refer to these sizes as old, new, and silly. :-) From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 15:14:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00333; Tue, 12 Jul 1994 12:27:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15401; Tue, 12 Jul 1994 12:27:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15356; Tue, 12 Jul 1994 12:11:54 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29361; Tue, 12 Jul 1994 12:11:41 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14441(5)>; Mon, 11 Jul 1994 19:11:26 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 11 Jul 1994 19:11:21 -0700 To: Big-Internet@munnari.OZ.AU Cc: deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: pvm's message of Mon, 11 Jul 94 11:11:16 -0800. <199407111814.AA19216@zephyr.isi.edu> Date: Mon, 11 Jul 1994 19:11:13 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul11.191121pdt.12171@skylark.parc.xerox.com> > I wonder if we would have all of these disagreements about lengths if > we all had the same assumptions and visions to start with? A number of people have made this point, and it's a very good one. Therefore, I'll try to explain some of the assumptions behind my conviction that 8-byte addresses would be plenty big enough, let alone 16-byte addresses. (1) I consider 10^15 to be a *very* conservative scaling goal for the number of *globally-reachable* IPng devices. The Kastenholz/Partridge IPng technical Criteria document specifies that IPng should support at least 10^12 hosts. 10^15 multiplies that by 3 orders of magnitude for "safety" (*beyond* the safety factor already built into the 10^12 number). This goal does *not* ignore the possible introduction of huge numbers of new types of devices; on the contrary, it *requires* the introduction of such new devices to approach anywhere near 10^15. After all, the United Nations and the CIA predict that world human population 30 years from now will still be less than 10^10, so there aren't going to be 10^15 desktop computers in use anytime soon. The 10^15 goal does not constrain the number of devices that do *not* need globally-reachable addresses. For security reasons, I expect many networked devices to be intentionally given "local" addresses, and all access to those devices to be mediated through "front-end" or "management" or "firewall" nodes. I fail to see the need for, or desireability of, global IPng reachability of all the lightbulbs in my car, all the appliances in my house, or all the nano-machines in my bloodstream. But if my failure to see is just short-sightedness, it is comforting to know that 10^15 is still big enough to provide global addresses to all those devices (except, maybe, the nano-machines). (2) I assume that we could achieve the .0001 address space utilization required to accommodate 10^15 devices in a 64-bit (approx. 10^19) address space, while meeting the goals of reasonable routing table size and reasonable distribution of address assignment authority. I validated approximately this assumption by going through the exercise of devising a 64-bit addressing plan in the early days of SIP. I showed that a geographic plan could provide for the assigment of 16 bits of address space (equivalent to an IPv4 Class B net number) to every home in the world, with large offices and campuses being treated simply as bundles of homes, while consuming only 3/16ths of the 64-bit space. Another 3/16ths was allocated to a parallel, provider-oriented hierarchy, which was harder to pre-plan, due to the unpredictable distribution of provider sizes; however, the auto-renumbering facility that will be necessary to support provider-based addressing (in order to prevent "provider lock-in") would provide the means to re-adjust the provider hierarchy in response to evolving needs. I expect the authorities responsible for the high-order parts of the address (i.e., the top-level assignment authorities and the providers) to be competent enough to achieve relatively high utilitization, so that those responsible for the low-order parts (i.e., the customers) can be relatively sloppy in their internal allocation schemes. (3) I assume that it is neither necessary nor desirable to specify the addressing hierarchy as one with fixed-width fields in the address, aligned on byte boundaries. I would guess that this is the major point of departure between myself and those who are arguing for variable-length, large-maximum-size addresses. There are lots of ways of squandering address space. CIDR-style allocation offers a way of actually using address space efficiently, while still meeting the same scaling goals and providing the processing efficiency of fixed-width addresses. In other words, I think variable-length fields within a fixed-length address are greatly to be preferred over fixed-length fields within a variable- length address. I think that keeping the addresses relatively compact and fixed- length are important goals, because the bandwidth and processing that addresses consume are valuable shared resources in the Internet. If a particular organization decides to allocate, say, 32-byte addresses for all their machines, they are not just consuming their own resources, but also the resources of any external site they communicate with and any external path over which they communicate. Granted, keeping the header size small is not the most important goal -- I would not give up the robustness benefits of datagrams in order to achieve the smaller header size of virtual circuits, and I would gladly spend spend a few bits to achieve reasonable alignment of packet headers -- but I do rank it as more important than making network administrators' jobs easier. In other words, I think it is more important to make addresses machine- friendly than user-friendly. If you want user-friendly, use DNS names. By all means, let's develop better software tools, protocols, and education programs to relieve administrators from the mental challenges of variable-length subnets, and let's use more discipline when allocating the high-order address parts, so they can be less disciplined at their end. But lets not penalize every packet just to simplify the once-every-couple-years task of doing an organization's addressing plan. I expect there to be much more use of encapsulation and/or source routing in the future, so many packets will end up carrying more than just two addresses, which is another reason to be concerned with maximum address size. (And, no, not all those extra addresses will be cluster addresses that can be expressed as short prefixes.) (Maybe I am less concerned than many people with byte-aligned address fields because I work for a company that has divided its class A IP address space into 14 bits of subnet and 10 bits of host. As far as I can tell, the lack of byte-aligned field boundaries has not had a significant negative impact on our bottom line.) (4) Despite my belief that 8 bytes is the perfect trade-off between all the conflicting demands imposed on IPng addresses, I am willing to go along with 16-byte addresses for SIPP, in order to support serverless autoconfiguration of addresses, using 6-byte IEEE 802 addresses as host numbers. I think the arguments in favor of autoconfiguration of global addresses (as opposed to local addresses) are weak -- there will be a need for manual or server-based configuration of parameters *other than* host addresses, for secure global communication, so we could just as well use the same mechanism for global addresses -- but I am getting darned tired of arguing and also I had hoped that the extra 10^6 safety margin provided by those extra bytes *not* burned up by IEEE 802 numbers (i.e., the high-order 2 bytes of the low-order 64-bits, and the low-order ~1 byte of the high-order 64 bits) would provide comfort to those who don't realize what a big number 10^15 is, or who think .0001 utilization of an address space is "dense". A vain hope, I guess. (5) I was going to talk about EIDs here, but I haven't got the energy. Suffice it to say that my ranking of compact header size as an important goal means that I'm inclined to demand much stronger proof of the value of EIDs than those who care less about header size. And if everyone really does decide that EIDs are indispensible, I hope you'll consider making them be the low-order 8 bytes of a 16-byte address, rather than additional header fields. Steve From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 15:26:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07585; Tue, 12 Jul 1994 15:26:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA15634; Tue, 12 Jul 1994 15:25:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA15618; Tue, 12 Jul 1994 15:20:36 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07299; Tue, 12 Jul 1994 15:18:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21594; Tue, 12 Jul 94 01:18:19 -0400 Date: Tue, 12 Jul 94 01:18:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407120518.AA21594@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Steve Deering I assume that we could achieve the .0001 address space utilization required to accommodate 10^15 devices in a 64-bit (approx. 10^19) address space, while meeting the goals of reasonable routing table size and reasonable distribution of address assignment authority. This is where a number of us part paths from you. I don't have a good, mathematically defendable, estimate on what kind of address space utilization we will see, since there are too many future trends I can't quantify. However, it's easy to create scenarios in which you don't get .0001 utilization; e.g. 7 layers of naming (and we've got 5 now in many branches) at 10% each (which is about what we get now, per layer, quite often), gives you an efficiency of 10^-7. However, this is all beside the point, as far as I'm concerned; all these calculations are coming at this from the wrong end. Instead of saying "here's the address, routing, go figure out how to use it", we need to ask "what does the routing need", and then figure out a way to provide that efficiently. Speaking of which... I assume that it is neither necessary nor desirable to specify the addressing hierarchy as one with fixed-width fields in the address, aligned on byte boundaries. ... CIDR-style allocation offers a way of actually using address space efficiently, while still meeting the same scaling goals and providing the processing efficiency of fixed-width addresses. In other words, I think variable-length fields within a fixed-length address are greatly to be preferred over fixed-length fields within a variable-length address. This is just a representation issue, and a really insignificant one at that. If you look at what *any* hierarchical naming scheme used by routing is *really* doing, it's *always* the same. You take a group of things, draw a circle around it, and give the circle a name. Recurse a bunch of times. The complete name of a low-level object consists of the sequence of the names of all the enclosing objects. Since, in a very large real network, you don't have the same number of nesting levels everywhere, the resulting names are, *by definition*, variable length. You may or may not be able to pack them into a fixed length field, using some representation or other, but the choice of a representation ought to be based on a more thorough analysis of what the routing and routers really need, not arguments about the generic benfits of fixed versus variable. My take (for reasons too long to explain here, but it basically boils down to not thinking I have perfect knowledge of the future, and not wanting to cram an inherently variable sized thing into a fixed size field) is that the names used by the routing ought to be a very simple representation, basically just that sequence of elements, laid down with separators between them. As a side note, why do we have subnet masks anyway (they weren't in the original IP)? You got it, how else to put 3+ layers of s*** into a 2 layer sack; i.e. they were a kludge we came up because we didn't do the right thing to start with. A reasonably elegant kludge, perhaps, but still, a hacked on kludge. CIDR made the complexity of IP addresses worse; at least you used to be able to figure out the *network number* from looking at the address. People are saying that subnet masks are complex, and they are, and better software may make them easier, but there are still going to be things you just can't do easily with them, like stick an extra layer of hierarchy in there. I think that keeping the addresses relatively compact and fixed- length are important goals, because the bandwidth and processing that addresses consume are valuable shared resources in the Internet. You seem to be assuming that the internetwork routers of the future are going to make the choice of what to do with the packet based on an address in the packet. This seems very unlikely to me. There's going to be more and more information needed to forward packets, and as a matter of efficient we won't i) ship it all around in every packet, and ii) make the routers paw through it for every packet. Most packets, but not all, will be forwarded based on some data about that particular sequence of packets which is cached in the routers. This is not a startling leap from what we do now; all high-end routers *already* cache data about active packet trains. As soon as you face that, you realize the "address" need not be carried in every packet, and then it's less important to smash every last bit out of a fixed-length representation of those innately variable-length routing names. Granted, keeping the header size small is not the most important goal ... but I do rank it as important than making network administrators' jobs easier. I dunno, I think cycles and bytes are cheap, and getting cheaper, and anything we can do to make the system more user friendly is worth it, even if it costs some of the above. I was going to talk about EIDs here, but I haven't got the energy. Likewise. I was thinking about Dave Crocker's message about using DNS names while driving, and I came up with something called "endpoint selectors" which sort of lets you have some cake and eat it too, but I'll put that in a separate message. And if everyone really does decide that EIDs are indispensible, I hope you'll consider making them be the low-order 8 bytes of a 16-byte address, rather than additional header fields. The hitch here is that it has to be done in a way which keeps the location independence of EID's. One way to do this is to make a low-order EID the "host number" on the physical network, but then, for networks which can't do a straight map, you've got either a directory, or, even uglier, a routing problem. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 16:26:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09975; Tue, 12 Jul 1994 16:26:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA15705; Tue, 12 Jul 1994 16:25:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA15687; Tue, 12 Jul 1994 16:14:48 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09469; Tue, 12 Jul 1994 16:14:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22089; Tue, 12 Jul 94 02:14:40 -0400 Date: Tue, 12 Jul 94 02:14:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407120614.AA22089@ginger.lcs.mit.edu> To: RACarlson@anl.gov, mohta@necom830.cc.titech.ac.jp Subject: Re: Omnibus reply - EIDs Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: "Richard Carlson" > Then, to globally identify a socket, you need a globally unique id > for the internetworking layer entity, that is, an EID. If the EID is globally unique, it doesn't have to be associated with any specific layer. Yes; the "thing" named by the EID is the entire "machine"; the whole protocol stack, the applications, the lot. The locator value is used at the internetworking layer to verify received data is for this node. This locator value is the id for the internetworking layer entity. No. A single internetwork layer can have multiple locators; e.g. a host with several interfaces. The locators name attachment points to the internetwork. I'm not sure how useful it is to be able to name the "internetwork layer"; what would you do with such a name? The ICMP protocol, etc, give you ways to pass data to the internetworking layer, etc; what do you want to do that "EID+proto=ICMP" does not do? Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 16:46:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10929; Tue, 12 Jul 1994 16:46:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA15735; Tue, 12 Jul 1994 16:45:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA15716; Tue, 12 Jul 1994 16:28:08 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10046; Tue, 12 Jul 1994 16:28:01 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02191; Tue, 12 Jul 1994 08:28:07 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA25059; Tue, 12 Jul 1994 08:27:50 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407120627.AA25059@dxcoms.cern.ch> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: big-internet@munnari.OZ.AU (bigi) Date: Tue, 12 Jul 1994 08:27:50 +0200 (MET DST) In-Reply-To: <9407120518.AA21594@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 12, 94 01:18:19 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 769 Steve, > From: Steve Deering ... > And if everyone really does decide that EIDs are indispensible, I > hope you'll consider making them be the low-order 8 bytes of a > 16-byte address, rather than additional header fields. > I have to push back a bit on this. If 8-byte EIDs become a mandatory part of the address (=locator+EID), then as far as I can see 16 bytes are no longer sure to be enough, because there would only be 8 bytes of locator (which IMHO is insufficient for the long term). So mandatory EIDs would actually change my vote in the Directorate sraw poll that Scott posted. Now I realise that you and others don't agree with this analysis, and I hope this will get on the table in the BOFs in Toronto. Brian From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 18:52:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13091; Tue, 12 Jul 1994 17:46:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA15808; Tue, 12 Jul 1994 17:46:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA15792; Tue, 12 Jul 1994 17:31:14 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12434; Tue, 12 Jul 1994 17:31:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22963; Tue, 12 Jul 94 03:30:30 -0400 Date: Tue, 12 Jul 94 03:30:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407120730.AA22963@ginger.lcs.mit.edu> To: avg@sprint.net, kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Robert Elz > EIDs trigger my Occam alarms. Mine too, but in the opposite direction to yours I suspect. I see them cutting away all the superfluous baggage hanging round identification (topological relationships), and around locators (identification functions), producing a much cleaner design. Yes, exactly. Sometimes having one mechanism do two different things (as the IPv4 address does) makes for a more complex design, and less satisfactory operation overall to boot (since it's a compromise that does neither well). The late Colin Chapman (perhaps the greatest car designer of all time) used to run into this problem in his early suspension designs. He'd have one part do two things; e.g. a drive shaft would also provide lateral location to the wheel. Unfortunately, when you do this, for arcane reasons I won't bore the non-car-people with, neither job gets done well. He tinkered and tinkered, and never could get it to work well, and finally gave up and put a separate link in. Almost always, his later designs used more pieces, but the result was in some sense "simpler", since each piece did one thing, and did it well. Noel PS: So there, now you all know why I'm a Lotus nut; I'm *really* just studying them for IPng design lessons! :-) From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 19:46:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17693; Tue, 12 Jul 1994 19:46:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA15997; Tue, 12 Jul 1994 19:46:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA15981; Tue, 12 Jul 1994 19:36:18 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17287; Tue, 12 Jul 1994 19:36:13 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 10:33:50 +0100 To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 18:23:08 +0200." <9407120923.AA05217@necom830.cc.titech.ac.jp> Date: Tue, 12 Jul 94 10:33:42 +0100 Message-Id: <1159.774005622@cs.ucl.ac.uk> From: Jon Crowcroft >> If the EID's onbly raison d'etre is for autoconfig, then of >EID is good to improve provider independence. provider independence is what the mask/prefix is all about - the EID is what you have left...thats why its ponly conceptual >While it is not the strict requirement by ATM standards, it is expected >that ATM equipments from sane vendors have ATM addresses containing globally >unique 6 byte mac address. good! jon From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 19:47:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17728; Tue, 12 Jul 1994 19:47:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA16014; Tue, 12 Jul 1994 19:47:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA15978; Tue, 12 Jul 1994 19:31:46 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16990; Tue, 12 Jul 1994 19:31:29 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Jul 94 18:23:09 +0900 From: Masataka Ohta Message-Id: <9407120923.AA05217@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Tue, 12 Jul 94 18:23:08 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <732.774002292@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jul 12, 94 9:38 am X-Mailer: ELM [version 2.3 PL11] > If the EID's onbly raison d'etre is for autoconfig, then of EID is good to improve provider independence. > i.e. on an 802 subnet, an EID is a 6 byte mac address. Such an EID is good only for autoconfiguration. But, anyway, > on a point to > point link, it is a null, on an ATM net is as yet an > undiscovered country. in Another Terrible Mistake territory, using an While it is not the strict requirement by ATM standards, it is expected that ATM equipments from sane vendors have ATM addresses containing globally unique 6 byte mac address. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 19:57:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15347; Tue, 12 Jul 1994 18:46:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA15899; Tue, 12 Jul 1994 18:46:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA15894; Tue, 12 Jul 1994 18:40:08 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15084; Tue, 12 Jul 1994 18:39:51 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 09:38:12 +0100 To: big-internet@munnari.OZ.AU (bigi) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 08:27:50 +0100." <9407120627.AA25059@dxcoms.cern.ch> Date: Tue, 12 Jul 94 09:38:12 +0100 Message-Id: <732.774002292@cs.ucl.ac.uk> From: Jon Crowcroft >> From: Steve Deering >... >> And if everyone really does decide that EIDs are indispensible, I >> hope you'll consider making them be the low-order 8 bytes of a >> 16-byte address, rather than additional header fields. If the EID's onbly raison d'etre is for autoconfig, then of necessict,y it is a) technology specific and b) not structured by other people trying to achieve 'locator-hood' (c.f. E.164 addresses) i.e. on an 802 subnet, an EID is a 6 byte mac address. on a point to point link, it is a null, on an ATM net is as yet an undiscovered country. in Another Terrible Mistake territory, using an a atm level locator for autoconfig flies in the face of mobility, multicast, autoconfig actual base requirements, and is nonsense. it should only ever be a conceptual thing when looking at an IPng address except, of necessity, when applying to a IPng address authoritiy for a prefix/mask, an organisation will stater the technology, autoconfiguatrion methods, and thus _imply_ the EID space required. thus i totally agree with steve deering (i hope). jon From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 20:46:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19868; Tue, 12 Jul 1994 20:46:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA16085; Tue, 12 Jul 1994 20:46:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA16069; Tue, 12 Jul 1994 20:29:34 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19157; Tue, 12 Jul 1994 20:29:28 +1000 (from skh@merit.edu) Received: from localhost (skh@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id GAA25715; Tue, 12 Jul 1994 06:29:25 -0400 Message-Id: <199407121029.GAA25715@merit.edu> To: big-internet@munnari.OZ.AU Cc: skh@merit.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Thu, 07 Jul 1994 14:07:19 EDT." <199407071807.OAA16707@radegond.cmf.nrl.navy.mil> Date: Tue, 12 Jul 1994 06:29:24 -0400 From: Susan Hares Scott and Allison: I vote for variable length address. Count me in the minority. 8 do not think any fixed length address schema (8/16/xxx) is in the best interest of the Internet. We will just be back at this thought pattern sometime in the Future. I'm having so much fun with transitions that I'd like to lengthen my life trying to stamp out as many as possible. The fixed length just points to another transition for the Internet. The longer address you have the more bits to have to: - aggregate routing addresses - have a flexible topology with (extra bits are extra bits to build levels with. Nothing new, see my NSAP Paper (shortly to be in the internet Draft directory just as historical node. By the By, read NSAP as variable length dudette of Network packet. I'm so into variable length, I'd support ISO ;-0... ;-)) - adminstrative manageability (extra bits are extra bits) The levels in the Internet look to explode in the next few years. At least that's my crystal ball. Sorry.. I'd like to travel the minority path with the TOS of variable length. Thanks for asking. Sue Hares From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 21:09:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14608; Tue, 12 Jul 1994 18:26:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA15867; Tue, 12 Jul 1994 18:26:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA15851; Tue, 12 Jul 1994 18:13:23 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08068; Tue, 12 Jul 1994 15:37:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21664; Tue, 12 Jul 94 01:36:33 -0400 Date: Tue, 12 Jul 94 01:36:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407120536.AA21664@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, cmetz@thor.tjhsst.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Craig Metz For the same performance and complexity reasons we would use ... native data types instead of multiple-precision libraries, we should use fixed length addresses instead of variable length ones. There are applications where use of fixed length native integers are appropriate, and applications where variable length ones (e.g. LISP 'bignum's) are the right thing. Without knowing a lot more about the particular application, you can't say which is the right choice; sometimes the variable length *is* preferable. The latter add more complexity, degrades performance, and it does so in every operation that manipulates the variable (including, but far from limited to, where we would traditionally expect to manipulate address fields). Let's not go back over all this again. Even assuming that you do use a single, variable length name everywhere (much the same way we now used the fixed length IPv4 address), thoughtful implementation can avoid most of the costs associated with simple, straight-forward, brute-force implementation. It seems that the latter costs are what spring to mind in those who don't like variable-length, which leads one to wonder if they've decided on fixed-length, and then looked for reasons why it's the right thing, instead of the other way around. Worse, we have to either make implementations that ... must blindly assume limits that will eventually be the downfall of those implementations and of the protocol itself. Gee, if variable-length addresses have this failure mode, I guess the fixed-length address (as used in IPv4) will never be the downfall of the protocol, then. That's nice to know. The big problem here is that most everyone on this list already has his or her own opinion and is not going to change it. Yup. So, maybe the more appropriate question would be, since there will not be agreement and there will not be compromise, where really can we go from here? I've often wondered this, but I don't have a good answer. Perhaps we should send the IPng AD's to magic school, since they're certainly going to have to pull a rabbit out of the hat! :-) Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 21:12:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16156; Tue, 12 Jul 1994 19:06:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA15933; Tue, 12 Jul 1994 19:06:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA15917; Tue, 12 Jul 1994 18:52:35 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12925; Tue, 12 Jul 1994 17:42:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22997; Tue, 12 Jul 94 03:42:02 -0400 Date: Tue, 12 Jul 94 03:42:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407120742.AA22997@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Robert Elz Dave Crocker suggested the "EID is a DNS name" most recently (to which Noel reacted as if a bomb had gone off - I'm not sure why as he had floated the same idea, more than once, earlier). Well, I'd been (and remain) unhappy about the costs of maintaining a separate allocation hierarchy which seems to closely parallel the DNS. This bugs me. The reason I didn't like Dave's original idea was not the DNS aspect, but the fact that by leaving any endpoint naming info out of the packets, it make "multiple endpoints at a single address" not work. While I believe that DNS names and EIDs are closely related concepts, I don't think that one can replace the other - and it has nothing to do with lengths. Hmm, you may not like endpoint selectors (ESEL's), then, since they make DNS names the *only* endpoint names, getting rid of the separate naming hierarchy that EID's imply. I take your points here, though... I have less opinion on the other half of the question, whether EIDs should be in none/some/all packets. Whatever works is my opinion here. Different protocol design philosophies will arrive at different answers, all for legitimate reasons. Ah. If you go back to my message to Dave, I think I concluded that *somehow*, some indication of the endpoint has to be given in the packet (even if it's inherent, as part of a flow id), otherwise you can't have multiple endpoints at a single address. You don't want to discard that capability, do you? If not, how else do you figure out which endpoint to deliver the packets to if there are several of them there? Maybe it's not a full EID (and ESEL's aren't), but there has to be *something* in the packets, no? Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 23:32:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21468; Tue, 12 Jul 1994 21:46:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA16156; Tue, 12 Jul 1994 21:46:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA16140; Tue, 12 Jul 1994 21:26:41 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20682; Tue, 12 Jul 1994 21:26:36 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 12:25:17 +0100 To: Susan Hares Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 06:29:24 EDT." <199407121029.GAA25715@merit.edu> Date: Tue, 12 Jul 94 12:25:16 +0100 Message-Id: <1725.774012316@cs.ucl.ac.uk> From: Jon Crowcroft >The longer address you have the more bits to have to: > - aggregate routing addresses > - have a flexible topology with > (extra bits are extra bits to build levels with. > Nothing new, see my NSAP Paper (shortly to be in > the internet Draft directory just as historical > node. By the By, read NSAP as variable length > dudette of Network packet. I'm so into variable > length, I'd support ISO ;-0... ;-)) > - adminstrative manageability > (extra bits are extra bits) none of those require variable lengths. just for longer. the only thing i konw of tha argues for variable is the requirement of _low bandwidthj_ to not incur the header overhead (i.e. the requirement to not use the 'longest so far'). however, if most the low bandwidth is mobile, it needs the biggest address space and most flexibility, and probably multicast and TOS etc etc, and so the largest fixed length better also be the biggest the worst case can tolerate.... hence fixed. hence not more than 16 and preferble not more than 8. i assert that address utilisation efficieny will be around 50% at each level if the tools for auto-re-prefixing when you change area or provider are sufficently well designed. if this is the case, then accomodataing a lot of levels in the 16byte space is really quite trivial tony li's clear note on Why Variable Length had assertions about hierarchies being on convenient boundaries for network managers, and therefore assuming you couldn't get 50% per level, because they'd want to put boundaries on *8. this is not the case right now. I know quite a few big bridged/subnet mixed nets that put subnet masks across smaller granluarity boudnaries. good network management tools will improve this further. with generalised CIDR, it should be straightforwasrd to size the net and allocate... jon From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 23:45:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23270; Tue, 12 Jul 1994 22:26:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA16216; Tue, 12 Jul 1994 22:26:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA16200; Tue, 12 Jul 1994 22:19:58 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23034; Tue, 12 Jul 1994 22:19:50 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 13:19:00 +0100 To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 21:03:36 +0200." <9407121203.AA05870@necom830.cc.titech.ac.jp> Date: Tue, 12 Jul 94 13:18:57 +0100 Message-Id: <2175.774015537@cs.ucl.ac.uk> From: Jon Crowcroft >If we want to use EID for the key of DNS query to extract identification >information such as hostname, we need locally controllable hierarchy >(mask/prefix) in EID. Perhaps, 16 bits for hierarchy is not enough. what? >Though it is not impossible to use locator to extract identification >information, it will make the entire scheme more provider dependent. sorry, if an EID is a LOCAL KEY, it has 0 to do with providers any organisation hierarchy should be in higher level names (what you are using, not where it is (EID), or a hint on how to get their (Locator). hierarchies are either for users to manage things (i.e. DNS names) or for aggregation of info for efficent indexing. not for a mix of these functions.... jon From owner-Big-Internet@munnari.OZ.AU Tue Jul 12 23:45:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23306; Tue, 12 Jul 1994 22:28:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA16233; Tue, 12 Jul 1994 22:28:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA16197; Tue, 12 Jul 1994 22:18:45 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22754; Tue, 12 Jul 1994 22:13:20 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Jul 94 21:03:37 +0900 From: Masataka Ohta Message-Id: <9407121203.AA05870@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Tue, 12 Jul 94 21:03:36 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <1159.774005622@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jul 12, 94 10:33 am X-Mailer: ELM [version 2.3 PL11] > >> If the EID's onbly raison d'etre is for autoconfig, then of > >EID is good to improve provider independence. > > provider independence is what the mask/prefix is all about - What? > the EID > is what you have left...thats why its ponly conceptual If we want to use EID for the key of DNS query to extract identification information such as hostname, we need locally controllable hierarchy (mask/prefix) in EID. Perhaps, 16 bits for hierarchy is not enough. Though it is not impossible to use locator to extract identification information, it will make the entire scheme more provider dependent. > >While it is not the strict requirement by ATM standards, it is expected > >that ATM equipments from sane vendors have ATM addresses containing globally > >unique 6 byte mac address. > > good! And, we can even enforce it as an Internet standard. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 00:06:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27123; Wed, 13 Jul 1994 00:06:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA16454; Wed, 13 Jul 1994 00:06:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA16449; Wed, 13 Jul 1994 00:05:30 +1000 Precedence: list Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27069; Wed, 13 Jul 1994 00:05:19 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA14136; Tue, 12 Jul 94 09:10:21 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA07877; Tue, 12 Jul 94 09:05:09 CDT Date: Tue, 12 Jul 94 09:05:09 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9407121405.AA07877@anubis.network.com> To: 0003858921@mcimail.com, big-internet@munnari.OZ.AU Subject: Re: Thoughts on EIDs Noel has mentioned, I think, that he views EIDs as belonging to a shim layer between IP and Transport, which makes sense to me. Packets get delivered to EIDs, and then transport protocols pick it up from there to tear it apart and do that whole glorious transport thing. I *think* Noel said something like this once. This does not guarantee that he did actually say it, nor that, in the event that he did, he still thinks it's the right thing. I think it's the right model. Transport sees EIDs as the next layer down, Network sees EIDs as the next layer up, and all the pesky horrible details of routing are explicitly concealed from Transport unless Transport specifically asks. Andrew From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 00:07:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27276; Wed, 13 Jul 1994 00:07:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA16469; Wed, 13 Jul 1994 00:07:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA16443; Wed, 13 Jul 1994 00:05:08 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26976; Wed, 13 Jul 1994 00:04:56 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 12 Jul 1994 10:04:54 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 12 Jul 1994 10:04:54 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA20638; Tue, 12 Jul 94 10:02:49 EDT Date: Tue, 12 Jul 94 10:02:49 EDT Message-Id: <9407121402.AA20638@mailserv-D.ftp.com> To: deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU Content-Length: 2624 Steve Deering writes... > A number of people have made this point, and it's a very good one. > Therefore, I'll try to explain some of the assumptions behind my conviction > that 8-byte addresses would be plenty big enough, let alone 16-byte addresses. > (2) I assume that we could achieve the .0001 address space utilization > required to accommodate 10^15 devices in a 64-bit (approx. 10^19) > address space, while meeting the goals of reasonable routing table > size and reasonable distribution of address assignment authority. Steve, I think that this is one of the places where we disagree. You look at the number of desired end-nodes (10^15) and the number of bits available in the addressspace (giving a numerical range of 0 -> ~10^19). If you enumerate each possible end node you get a margin of .0001, as you say. However, I tend to look at this space as having a lot of structure in it, that structure reflecting the structure of the network. The top several bits will be the preserve of the backbones, which will each allocate several further bits to regionals, etc, etc etc. I think that this sort of structure inherently contains a lot of waste. Any one level may utilize only 10% or 1% (or even perhaps 0.1%) if its space, but when that gets multiplied over several levels of hierarchy, you quickly get a very low density. Would it be fair to say that the heart of the disagreement is that you tend to see the address as a 64 or 128 bit number, while I tend to see it as an 8 or 16 byte 'structured' field? (Though this description may well have a couple of orders of magnitude of over-simplification in it). >(3) I assume that it is neither necessary nor desirable to specify the > addressing hierarchy as one with fixed-width fields in the address, > aligned on byte boundaries. I would guess that this is the major point > of departure between myself and those who are arguing for variable-length, > large-maximum-size addresses. I think that this may well be the other disagreement in that I think that for network administrators to easily start using this technology, we will have to make address-hierarchy fields an integral number of bytes long. I would agree with you that better user-interface software can be used to 'hide' the ickyness of 'bit-length' fields, but I just don't see such software being written. It's been how long since we started using IPv4 subnets, and there's not much software to hide its ickyness... I guess I'm just more of a pessimist than you :-( -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 00:09:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27318; Wed, 13 Jul 1994 00:09:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA16490; Wed, 13 Jul 1994 00:09:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA16446; Wed, 13 Jul 1994 00:05:21 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26992; Wed, 13 Jul 1994 00:05:03 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 12 Jul 1994 10:04:53 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 12 Jul 1994 10:04:53 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA20634; Tue, 12 Jul 94 10:02:46 EDT Date: Tue, 12 Jul 94 10:02:46 EDT Message-Id: <9407121402.AA20634@mailserv-D.ftp.com> To: Big-Internet@munnari.OZ.AU Subject: The right numbers (was Re: IPng ADs Wish to Gauge...) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: deering@parc.xerox.com Content-Length: 2796 > (1) I consider 10^15 to be a *very* conservative scaling goal for the number > of *globally-reachable* IPng devices. > > The Kastenholz/Partridge IPng technical Criteria document specifies > that IPng should support at least 10^12 hosts. 10^15 multiplies that > by 3 orders of magnitude for "safety" (*beyond* the safety factor > already built into the 10^12 number). Steve, et al, The 10^15 number was originally put in the document for, as you say, a point of safety. However, the 'Cable TV Whitepaper' (it's an Internet-Draft, I don't recall the name) gave a convincing argument that leads me to believe that 10^15 may not be the 'double safe' number as your note says, but might, in fact, be close to reality. The white paper gives an estimate that there will be about 10^10 homes in the world that use cable tv and then the paper suggests that 10^12 end-nodes would be right, giving a factor of 100 for 'overhead' and safety and the like. However, the cable-tv people see each home/cable-tv-box as an 'end node' in the system. Craig's and my views were more that each home would be a subnetwork (in IPv4 terminology). We took the '10^12 nodes' and changed 'nodes' to 'networks'. Then we had to come up with a guess for how many end-nodes might be in the world. On average, we'd guess that 10/network is too few, 100/net is probably just right, and 1000/ is probably starting to get 'high'. Also, currently, there are ~30,000 networks in the NSFNET routing table and ~3,000,000 hosts guessed to be on the Internet. So this gives an average of ~100 hosts/network, verifying our guess. Adding an order of magnitude, we come up with 1,000 hosts/net. 10^12 nets, with 1,000 hosts per, gives an estimate of 10^15 hosts. Now, why did I type this all in? Well, I'm starting to wonder if 10^12/10^15 rather than being 'nice and safe' are instead, getting very close to being the 'right' numbers. So, since these numbers tend to be used for a lot of the debate on address/eid/locator sizes and so on, any further thoughts on these issue on the part of the community would be greatly appreciated. Some points to consider: 1. Is it reasonable to expect that the network might grow this big in the next 20 years (expected IPng lifetime) or so? Or could it easily be bigger? 2. Are the safety margins built into these numbers (e.g. 1 order of magnitude in the hosts/network factor) enough? Too big? Too small? 3. The numbers are guesstimates of the 'leaves' of the network (leaf nodes and subnetworks). Is there enough built in for overhead (backbones, regionals, service providers, ...)? Too much? Too little? 4. Are the base assumptions correct? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 00:45:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25211; Tue, 12 Jul 1994 23:26:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA16309; Tue, 12 Jul 1994 23:26:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA16292; Tue, 12 Jul 1994 23:11:35 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21761; Tue, 12 Jul 1994 21:54:40 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwyfn20691; Tue, 12 Jul 1994 07:54:18 -0400 Message-Id: To: Craig Metz Cc: pvm@isi.edu, big-internet@munnari.OZ.AU Subject: Re: variable length machines.... In-Reply-To: Your message of "Mon, 11 Jul 1994 16:23:34 EDT." Date: Tue, 12 Jul 1994 07:54:17 -0400 From: "Mike O'Dell" It was called the IBM 1620. it had a machine cycle time of 20 microseconds/tick with the average instruction requiring 12 ticks just to fetch it, plus 2-4 ticks per digit of operand and data (it was a base-10 machine - didn't even have any nasty "doing money in binary problems." next contestant. From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 00:58:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25252; Tue, 12 Jul 1994 23:27:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA16331; Tue, 12 Jul 1994 23:27:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA16295; Tue, 12 Jul 1994 23:19:41 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22107; Tue, 12 Jul 1994 22:00:03 +1000 (from skh@merit.edu) Received: from localhost (skh@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id HAA02105; Tue, 12 Jul 1994 07:58:08 -0400 Message-Id: <199407121158.HAA02105@merit.edu> To: Jon Crowcroft Cc: Susan Hares , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 12:25:16 BST." <1725.774012316@cs.ucl.ac.uk> Date: Tue, 12 Jul 1994 07:58:08 -0400 From: Susan Hares Jon: My apologies for being unclear in my earlier memo. My argument for variable addresses has been that 1 transition in IP addresses is enough not to re-discuss Tony's and your discussion. It was interesting and I could really have fun continuing with this privately. ;-0.. boy what fun! But... for the group... I did not want to restate Tony's argument, even though I tend to agree with him as far as utilization. And I do not think you can project the number of levels we will need for 20-30 years - the time I hope this addressing plan lasts. But... lets carry on that fun outside the group. I have been through lots of transitions, and I think the worst is if it affects the end users. The pain of the current transition in the internet to the NSF Next Generation network plan is nothing compared to re-training that must occur with each user in an address transition. Again, Thanks for the neat node. I love to play bits and bytes ... it's fun! Sue Hares From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 01:08:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25879; Tue, 12 Jul 1994 23:46:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA16380; Tue, 12 Jul 1994 23:46:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA16347; Tue, 12 Jul 1994 23:31:01 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22381; Tue, 12 Jul 1994 22:04:07 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty11.jvnc.net. (franklin-tty11.jvnc.net) by tigger.jvnc.net with SMTP id AA11602 (5.65c/IDA-1.4.4 for big-internet@munnari.OZ.AU); Tue, 12 Jul 1994 08:03:55 -0400 Message-Id: Date: Tue, 12 Jul 94 08:02:54 EDT From: "David M. Piscitello" Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: dave@corecom.com To: "Robert Elz" , dave@corecom.com Cc: big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 >Exactly. This is perhaps the best reason why attempting to >stick 6 byte MAC addresses (or any other flavour of the month >link level address) inside an IPng address is short sighted >and silly. Much better would be to define a mapping from >random-standard-X type addresses into IPng addresses (the low >bits thereof), either algorithmic, or via a server. Or, exactly why choosing a container without any consideration of future requirements is ill-advised. Which side of the elephant are you studying? (I get first dibs on the trunk...) David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 01:08:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25909; Tue, 12 Jul 1994 23:47:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA16395; Tue, 12 Jul 1994 23:47:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA16373; Tue, 12 Jul 1994 23:45:31 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23630; Tue, 12 Jul 1994 22:38:36 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 12 Jul 94 21:29:07 +0900 From: Masataka Ohta Message-Id: <9407121229.AA05963@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 12 Jul 94 21:29:06 JST Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9407120518.AA21594@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jul 12, 94 1:18 am X-Mailer: ELM [version 2.3 PL11] > Most packets, but not all, will be forwarded based on some data about that > particular sequence of packets which is cached in the routers. This is not a > startling leap from what we do now; all high-end routers *already* cache data > about active packet trains. In the future when we will be handling 100 or 1,000 more packets than now, more than 90% of packets will be forwarded with cache. But I don't think the absolute amount of packets without cached data ever decreases. > As soon as you face that, you realize the "address" need not be carried in > every packet, and then it's less important to smash every last bit out of a > fixed-length representation of those innately variable-length routing names. I prefer to carry the address in all the packets so that the best effort can be attempted in case the cached information is lost. > And if everyone really does decide that EIDs are indispensible, I > hope you'll consider making them be the low-order 8 bytes of a > 16-byte address, rather than additional header fields. > > The hitch here is that it has to be done in a way which keeps the location > independence of EID's. Of course, EID should be provider independent. But as I already wrote, it is not so harmful if EID reflects local location information. I know you dislike it, but, to pack everything within 16 bytes, such overlapping is, perhaps, necessary. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 01:12:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25943; Tue, 12 Jul 1994 23:48:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA16414; Tue, 12 Jul 1994 23:48:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA16311; Tue, 12 Jul 1994 23:26:09 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21579; Tue, 12 Jul 1994 21:49:21 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA17923; Tue, 12 Jul 94 06:50:47 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac10105; 12 Jul 94 11:46 GMT Date: Tue, 12 Jul 94 06:46 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Thoughts on EIDs Message-Id: <61940712114616/0003858921NA5EM@mcimail.com> Boy did you people go crazy over the weekend. Now I am behind on BigI again, and I filter those messages out for 1st review (behind 2 weeks on com-priv). My wife doesn't let my read EMail over the weekends, only poll it :) I have thought a lot on EIDs. Noel woke me up to the potential that a process can have an EID to make it more mobile. Let me digress here with a real world application.... We have 2 regional MVS datacenters for our assembly plants. One in Detroit, and one in Bellvidere Indiana. Each has two MVS images. Normally the CICS, WSF2, IMS, DB2, and other regions are distributed over the 4 images. But based on process load and host availablity, the operations people can suffle almost to their heart's content. Thus Detroit might be running all apps on one image and Bellvidere might be running one image's worth on the emtpy Detroit image. VTAM handles the issues of finding the application very nicely thank you. IP does not. We are playing aroung with a couple of ideas. But it is a kludge.... So imagine if each CICS region had a EID, the ops folks could move the region to any image and the client would find it, as the EID will be tied some way to DNS. But whenever I try to think of EID as tied to the process, I get tied in knots! I look at my Comer V 2 drawing of the IP and TCP state machines and say that then EID is a part of the TCP machine. But when I look at the normal case of EID to the image, then EID is a part of the IP machine! Or is it. Perhaps EID is always a part of the TCP machine (with the general case being just that). However, EID has to be a tied to a DNS name so one would think that EID is a part of the internetwork level or the IP machine. HELP!!!! So when I wake up with the sweats from dreaming about EIDs and Locators and processees floating around the corporate body and my wife asks me what is bothering me.... The EID is seems to be a part of the transport level, but MUST be carried in the IP level (I think it gets worst with the UDP machine) and thus is a levels violation. But not a 'bad' violation? Bob From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 02:46:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03353; Wed, 13 Jul 1994 02:46:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16890; Wed, 13 Jul 1994 02:46:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16873; Wed, 13 Jul 1994 02:38:37 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03002; Wed, 13 Jul 1994 02:38:28 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 17:37:44 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 11:56:05 EDT." <9407121556.AA24962@ginger.lcs.mit.edu> Date: Tue, 12 Jul 94 17:37:39 +0100 Message-Id: <3543.774031059@cs.ucl.ac.uk> From: Jon Crowcroft >Second, everyone keep assuming that if the state in the routers is gone, we >have to be able to do something useful with the packets. Wrong! Just drop them >on the floor. We do this all the time now, e.g. as a congestion response, and >things work just fine, thank you! wrong. >get the response it thinks it should, it will take appropriate remedial >action, just as it does now (e.g. by adjusting its congestion control state, >and retransmitting the dropped data). and backs off and loses bandwidth for no good reason - sorry this way you get low utilisation - you must distinguish to the sending congestion avoidance systeme between a) congestion b) real error and c) lost state that can be refreshed by a single packet or else the performance will take a terrible hit. just dropping more packets on the floor is not a good idea. anyhow, one of the ideas with flows was that there are more options than this for instance for some simple types of traffic 'default' behaviour might be to follow some default path anyhow, since this type of less-soft state is not part of IPng basic architecture, i don't beieve it is a design option in IPng, just another part of the nimrod wishlist...which is a different beast altogether jon From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 03:13:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28770; Wed, 13 Jul 1994 00:46:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA16686; Wed, 13 Jul 1994 00:46:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA16662; Wed, 13 Jul 1994 00:29:43 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28080; Wed, 13 Jul 1994 00:29:39 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwyfx06922; Tue, 12 Jul 1994 10:29:30 -0400 Message-Id: To: Susan Hares Cc: Jon Crowcroft , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 07:58:08 EDT." <199407121158.HAA02105@merit.edu> Date: Tue, 12 Jul 1994 10:29:29 -0400 From: "Mike O'Dell" My problem is that I don't think we can accurately predict ANYTHING about network technology 30 years into the future. Therefore, the fact that we can't predict address usage patterns isn't particularly troubling - it's no worse than any other part of it. -mo From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 03:26:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04621; Wed, 13 Jul 1994 03:26:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA17035; Wed, 13 Jul 1994 03:26:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17032; Wed, 13 Jul 1994 03:25:18 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00584; Wed, 13 Jul 1994 01:38:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24864; Tue, 12 Jul 94 11:37:29 -0400 Date: Tue, 12 Jul 94 11:37:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407121537.AA24864@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft If the EID's onbly raison d'etre is for autoconfig I haven't a clue what on earth you're talking about. Nobody I know of who likes the concept of location-invariant names for the entire transport entity (of which EID's are but one example) wants them only for autoconfiguration. With this faulty premise, the rest of your message makes no sense either. GIGO. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 03:27:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04705; Wed, 13 Jul 1994 03:27:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA17057; Wed, 13 Jul 1994 03:27:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17011; Wed, 13 Jul 1994 03:11:16 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28431; Wed, 13 Jul 1994 00:39:16 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA09467; Tue, 12 Jul 1994 16:39:16 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05030; Tue, 12 Jul 1994 16:38:57 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407121438.AA05030@dxcoms.cern.ch> Subject: Re: variable length machines.... To: big-internet@munnari.OZ.AU (bigi) Date: Tue, 12 Jul 1994 16:38:57 +0200 (MET DST) In-Reply-To: from "Mike O'Dell" at Jul 12, 94 07:54:17 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 875 I believe the models sold in Britain (at least) actually contained pounds, shillings, and pence hardware. It was a nice machine for number theorists, since it could store integers whose length was limited only by total memory length (in nibbles). I last saw one running in Massey University, New Zealand in 1975. BTW, it was a fast machine for its time and price, for RPG programs at least. Variable length was a hardware optimisation for the intended applications. There is a lesson in that... Brian >--------- Text sent by Mike O'Dell follows: > > It was called the IBM 1620. it had a machine cycle time of 20 > microseconds/tick with the average instruction requiring 12 ticks just > to fetch it, plus 2-4 ticks per digit of operand and data (it was a > base-10 machine - didn't even have any nasty "doing money in binary > problems." > > next contestant. > From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 03:28:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04808; Wed, 13 Jul 1994 03:28:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA17072; Wed, 13 Jul 1994 03:28:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17018; Wed, 13 Jul 1994 03:22:30 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29131; Wed, 13 Jul 1994 00:54:39 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14416(4)>; Tue, 12 Jul 1994 07:54:24 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 12 Jul 1994 07:54:11 -0700 To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: kasten's message of Tue, 12 Jul 94 07:02:49 -0800. <9407121402.AA20638@mailserv-D.ftp.com> Date: Tue, 12 Jul 1994 07:54:01 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul12.075411pdt.12171@skylark.parc.xerox.com> > > (2) I assume that we could achieve the .0001 address space utilization > > required to accommodate 10^15 devices in a 64-bit (approx. 10^19) > > address space, while meeting the goals of reasonable routing table > > size and reasonable distribution of address assignment authority. > Would it be fair to say that the heart of the disagreement is that > you tend to see the address as a 64 or 128 bit number, while I tend > to see it as an 8 or 16 byte 'structured' field? NO, NO, 10^19 TIMES NO! Of course it's structured! It has hierarchical structure for scalable routing. If it didn't, I would be arguing that a 10^19 address space could support 10^19 hosts, not 10^15. It is precisely the structure that limits the achievable utilization. If you read the second clause of my sentence that you quoted, above, you will see that I *am* taking into account the need for structure. I am shouting this because it is a misunderstanding that people keep trying to use to dismiss my argument, and I don't know how else to clear up the misunderstanding. As I said in my previous message, there's no need for the structure to be encoded as fixed-length fields with byte-aligned boundaries. There's also no need to specify a fixed number of levels of hierarchy. CIDR addresses are structured; different subtrees of the CIDR addressing hierarchy are of different sizes and different depths. You can't draw a nice picture of the CIDR address format, but it works, it supports scalable routing, and it achieves much higher utilization than those address hierarchies that do have nice pictures. I'll add parenthetically that I think we should discourage the creation of lots of unnecessary levels in the hierarchy. The flatter the routing, the better, for the sake of route quality. Hierarchical routing is something we do only because it is not feasible or economical to do flat routing. Steve From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 03:40:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00132; Wed, 13 Jul 1994 01:26:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA16749; Wed, 13 Jul 1994 01:26:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16720; Wed, 13 Jul 1994 01:09:25 +1000 Precedence: list Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29466; Wed, 13 Jul 1994 01:09:22 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA03134; Tue, 12 Jul 94 08:00:31 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA07405; Tue, 12 Jul 1994 11:03:15 -0400 Message-Id: <9407121503.AA07405@skidrow.lkg.dec.com> To: "Mike O'Dell" Cc: pvm@ISI.EDU, big-internet@munnari.OZ.AU Subject: Re: variable length machines.... In-Reply-To: Your message of "Tue, 12 Jul 94 07:54:17 EDT." Date: Tue, 12 Jul 94 11:03:15 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: "Mike O'Dell" To: Craig Metz Cc: pvm@ISI.EDU, big-internet@munnari.oz.au In-Reply-To: Your message of "Mon, 11 Jul 1994 16:23:34 EDT." >It was called the IBM 1620. it had a machine cycle time of 20 >microseconds/tick with the average instruction requiring 12 ticks just >to fetch it, plus 2-4 ticks per digit of operand and data (it was a >base-10 machine - didn't even have any nasty "doing money in binary >problems." Not only that, it did addition and multiplication by table lookup in memory so you could change these operations to be something else! >next contestant. Donald From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:06:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06219; Wed, 13 Jul 1994 04:06:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17195; Wed, 13 Jul 1994 04:06:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17119; Wed, 13 Jul 1994 03:46:55 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01549; Wed, 13 Jul 1994 02:01:08 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id MAA04263; Tue, 12 Jul 1994 12:00:57 -0400 Date: Tue, 12 Jul 1994 12:00:57 -0400 From: Vadim Antonov Message-Id: <199407121600.MAA04263@titan.sprintlink.net> To: J.Crowcroft@cs.ucl.ac.uk, skh@merit.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU >tony li's clear note on Why Variable Length had assertions about >hierarchies being on convenient boundaries for network managers, and >therefore assuming you couldn't get 50% per level, because they'd want >to put boundaries on *8. this is not the case right now. I would add that the idea that humans should ever look at those addresses is completely bogus. Tony, type in some 3 dozen of GOSIP addresses to get rid of that idea. (BTW, strict powers-of-2 minimal blocks always yield *more* than 50% address space utilization -- depending on distribution of network sizes. Just nitpicking.) --vadim From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:11:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06450; Wed, 13 Jul 1994 04:11:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17260; Wed, 13 Jul 1994 04:11:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17192; Wed, 13 Jul 1994 04:03:34 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06164; Wed, 13 Jul 1994 04:03:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25792; Tue, 12 Jul 94 14:03:18 -0400 Date: Tue, 12 Jul 94 14:03:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407121803.AA25792@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Jon Crowcroft > everyone keep assuming that if the state in the routers is gone, we > have to be able to do something useful with the packets. Wrong! Just > drop them on the floor. We do this all the time now, e.g. as a > congestion response, and things work just fine, thank you! wrong. [the host] backs off and loses bandwidth for no good reason - sorry this way you get low utilisation - you must distinguish to the sending congestion avoidance systeme between a) congestion b) real error Yes, this is a problem. However, we don't seem to be working on solving it by providing feedback to the hosts from the routers. Instead, many people seem to be going down the road of putting more state about resources in the routers; i.e. the information flow is the other way. Perhaps this is in part because making the router send packets when it's congested is gas on the fire? (Yes, link congestion is a different issue, since presumably the forward link is congested, but not the return link, which is the one the notification will have to traverse. And yes, I understand why certain applictions won't work in feedback mode, etc.) and c) lost state that can be refreshed by a single packet or else the performance will take a terrible hit. ... just dropping more packets on the floor is not a good idea. I'm not saying we can't do optimizations which try and reduce packet losses due to lost state by trying to recover that state locally, or bypass failed components. I'm just saying we don't need to make the architecture able to forward packets even when the state is lost. It's like TCP now; it doesn't assume 0 packet losses, which makes the design of the routers a lot easier, but it works better if we try and minimize the lost packets. anyhow, since this type of less-soft state is not part of IPng basic architecture, i don't beieve it is a design option in IPng, just another part of the nimrod wishlist...which is a different beast altogether You need to distinguish between the Nimrod routing architecture, and what I'm talking about, which is a new internetwork layer into which a whole bunch of new work (of which Nimrod is just one part) fits. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:12:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06493; Wed, 13 Jul 1994 04:12:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17277; Wed, 13 Jul 1994 04:12:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17155; Wed, 13 Jul 1994 03:49:01 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00469; Wed, 13 Jul 1994 01:33:30 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA26434; Tue, 12 Jul 1994 08:33:14 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Jul 1994 08:33:25 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Where and When is the EID needed? (was: Re: IPng ADs Wish to...) Cc: big-internet@munnari.OZ.AU Noel, et al, Again, the primary problem with the conclusion you keep reaching is not that it is wrong to want the final functionality you cite, but it does not seem to be necessary to achieve it by burdening every packet and by creating yet-another administrative effort to assign a new and extra string. At 12:42 AM 7/12/94, Noel Chiappa wrote: > From: Robert Elz >The reason I didn't like Dave's original idea was not the DNS aspect, but the >fact that by leaving any endpoint naming info out of the packets, it make >"multiple endpoints at a single address" not work. We need a mantra: put overhead where it belongs. First, the function you cite is at best experimental. The closest we have now is for reliability, with one machine going down and another taking over for it. This requires a 'switchover' behavior, rather than changing delivery possibly every packet. I'm wrong. We DO have a current example, and that is any machine which has multiple cpus. And such machines solve the problem already, without burdening packets to have additional addressing. How do they solve this? One example is by using the connection table to do dispatching (i.e., localizing a connection to a particular cpu -- given cache lookup behaviors, this is a useful scheme.) The main point is that for highly localized and specialized functions, we should not burden the entire IP infrastructure with overhead. > While I believe that DNS names and EIDs are closely related concepts, I Please characterize the differences. To repeat my earlier suggestion: Keep the current IP address/Port number scheme in the packets. When special dispatching features are required, conduct a control protocol exchange between the two processes that need the feature. The control protocol associates two dns name/protocol name/port number pairs into a 'transport association' with a (possibly varying) list of IPaddr/Portnum sets. I.e., it logically maps multiple "connections" to the same process pair and for the same logical data stream -- i.e., the same transport connection. The transport layer uses its sequence numbers to determine the 'place' in a stream. Any of the 'connection' identifiers may be used by the transport layer when building the IP layer. I.e., two packets coming in with different IP info, but part of the same connection, get put into their proper order by virtue of the sequence number. This scheme will handle mobility by allowing the moving process to add/delete IP addrs (i.e., interface addresses) on the fly. To the extent that an old one has become inoperable but not deleted yet -- i.e., packets don't reach it via the old IP address, but the sender doesn't know this yet -- the sender retransmits via one of the other IP addresses that are part of the association. This scheme supports improved reliability (more timely recovery from single-point of failure scenarios) by having alternative paths exercised automatically as part of the transport retransmission effort; the sender does not wait for the network to switch over to a new path. (Developing the correct retransmission algorithm to do this well is a non-trivial exercise, of course.) What's good about this scheme? It supports two emerging and important functions and it does it without additional administrative burden and without adding anything to the regular packet format. It lets the IP infrastructure continue in its current model and it burdens only those participants who need the functionality with the additional overhead. That is, it is invisible to the Internet infrastructure. What's bad about this scheme? It only works for those hosts who implement it. I.e., it is very much NOT invisible to hosts. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:14:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02536; Wed, 13 Jul 1994 02:26:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16854; Wed, 13 Jul 1994 02:26:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16836; Wed, 13 Jul 1994 02:20:51 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02284; Wed, 13 Jul 1994 02:20:44 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 17:19:38 +0100 To: "James 'J' Allard" Cc: big-internet@munnari.OZ.AU Subject: Re: why not variable length? In-Reply-To: Your message of "Tue, 12 Jul 94 08:22:27 +0700." <9407121542.AA13378@netmail2.microsoft.com> Date: Tue, 12 Jul 94 17:19:26 +0100 Message-Id: <3326.774029966@cs.ucl.ac.uk> From: Jon Crowcroft >the only argument that i've heard against vl is that it's >harder to implement and a little slower. compare tcp/ip to >ipx/spx. ip is harder to implement and a little slower, but >guess what? there's a clear convergence away from ipx to ip >on the backbone in the world today. hunh? the ipx to ip backbone convergence is to do with router avaialbility .... >if users, administrators and vendors are willing to take >a minor performance hit today, why not tomorrow? what if i am not prepared to pay for your mistakes - jon p.s. we do not run PC DOS< Windows or NT because it costs marginally more to maintain 3000 machiens virus free than it does with other os's:-) From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:21:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01661; Wed, 13 Jul 1994 02:06:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16809; Wed, 13 Jul 1994 02:06:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16804; Wed, 13 Jul 1994 01:56:14 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01292; Wed, 13 Jul 1994 01:56:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24962; Tue, 12 Jul 94 11:56:05 -0400 Date: Tue, 12 Jul 94 11:56:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407121556.AA24962@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Masataka Ohta I prefer to carry the address in all the packets so that the best effort can be attempted in case the cached information is lost. No, for two reasons. First, as I said: > There's going to be more and more information needed to forward packets, > and as a matter of efficient we won't i) ship it all around in every > packet If you need access authorization, or billing tracing (I know, we all hate this, but it may happen) to get packets through, the packets won't get through if the cached info is lost (at least, without that info in the headers too, and my guess is that info may be long and complex). Where do we stop? Second, everyone keep assuming that if the state in the routers is gone, we have to be able to do something useful with the packets. Wrong! Just drop them on the floor. We do this all the time now, e.g. as a congestion response, and things work just fine, thank you! If the entity sending the packets doesn't get the response it thinks it should, it will take appropriate remedial action, just as it does now (e.g. by adjusting its congestion control state, and retransmitting the dropped data). As the system gets more and more complex, trying to continue to ensure that all the critical state the forwarding needs is maintained in the routers automatically, without help from the ends, is just plain the wrong path to take. It's making things *more* complicated, not *less*; the routers have to get more complex to make sure they always have the increasingly complex state needed to forward packets. Just as TCP make data handling in the routers much simpler when we decided to make the ends responsible for reliability, our new design has to lift the burden from routers of maintaining other forwarding state, and put it where it make the overall system simplest. > The hitch here is that it has to be done in a way which keeps the > location independence of EID's. Of course, EID should be provider independent. But as I already wrote, it is not so harmful if EID reflects local location information. Any time an invariant name includes topologically sensitive information, you have to work extra hard when the topololgy information in the name is wrong. Me, I like simple designs: one name to do one simple thing well, and another to do something else. No Colin Chapman kludges for me! Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:26:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07019; Wed, 13 Jul 1994 04:26:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17322; Wed, 13 Jul 1994 04:26:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17253; Wed, 13 Jul 1994 04:10:36 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06432; Wed, 13 Jul 1994 04:10:29 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14424(3)>; Tue, 12 Jul 1994 11:09:07 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 12 Jul 1994 11:09:01 -0700 To: kasten@ftp.com Cc: deering@parc.xerox.com, Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: kasten's message of Tue, 12 Jul 94 09:31:19 -0800. <9407121631.AA23451@mailserv-D.ftp.com> Date: Tue, 12 Jul 1994 11:08:53 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul12.110901pdt.12171@skylark.parc.xerox.com> > Ok. Try number 2 :-) > > Would it be fair to say that the heart of the disagreement is in the > number of hierarchical levels that will be needed and the amount of > aggregation at each level? It seems that you believe that we will > have relatively few levels with a fairly high amount of aggregating > at each level, while I believe that we may have lots of levels with > relatively little aggregation at each level. Yes, that's a reasonable characterization of my position and, presumably, your position. > Of secondary importance (to me) is that we should keep field > boundaries on byte-borders, while you think that this is not what we > should do, yes? Yes, it's not what we should do. Steve From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:28:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07095; Wed, 13 Jul 1994 04:28:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17341; Wed, 13 Jul 1994 04:27:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17295; Wed, 13 Jul 1994 04:14:38 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02693; Wed, 13 Jul 1994 02:31:37 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 17:31:02 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 11:37:29 EDT." <9407121537.AA24864@ginger.lcs.mit.edu> Date: Tue, 12 Jul 94 17:30:59 +0100 Message-Id: <3439.774030659@cs.ucl.ac.uk> From: Jon Crowcroft >I haven't a clue what on earth you're talking about. Nobody I know of who >likes the concept of location-invariant names for the entire transport entity >(of which EID's are but one example) wants them only for autoconfiguration. well, thats a shame coz i though t the idea of a conceptual EID was pretty clear. what i am talkign about (irrelevant of whether you parse or digest it) is that we do not need to size the fields in IPng packets to have arbitrary fields for EID fucntionality as well as for locator functionality and i believe people who think this don't understand EIDs whatever an EID is for, it is something that is implicit in a number of features of an IPng packet. the 'transport entity' stuff is a red herring - we are not at liberty in _this_ debate to change the use of TCP ports, and probably can't sensibly say any more than use TCP port plus low least changing (i.e. most like EID) bits of the IPng locator for the PCB key/pseudo checksum. the problem is that you (noel) are constantly trying to fit a small delta to IPv4 into the nimrod architecture, but in reality, IPng is going to be a shadow of the nimrod platonic ideal... too many people are bewitched by a falsely perceived opportunity to design a perfect IPng a la nimrod....it wont and can't happen sipp with 8+8 represented the height of compromise...which is as good as we can hope for... an ISO 7 layer stack-worth-of-IPng-EID+Locator is a bad idea.... cramming organisational hierarchy into the EID, 7 layers of .0001 % utilised network layer * layers of hierarchy etc etc is just so pessimal that i guess the new fangled IPngETF might go for it:-( i'm getting ready to unsubscribe from this list... jon From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:38:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03414; Wed, 13 Jul 1994 02:47:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16907; Wed, 13 Jul 1994 02:47:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16876; Wed, 13 Jul 1994 02:40:00 +1000 Precedence: list Received: from netmail2.microsoft.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03045; Wed, 13 Jul 1994 02:39:55 +1000 (from jallard@microsoft.com) Received: by netmail2.microsoft.com (5.65/25-eef) id AA17471; Tue, 12 Jul 94 09:40:11 -0700 Message-Id: <9407121640.AA17471@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 12 Jul 94 09:40:11 PDT X-Msmail-Message-Id: C44F62BD X-Msmail-Conversation-Id: C44F62BD From: "James 'J' Allard" To: J.Crowcroft@cs.ucl.ac.uk Date: Tue, 12 Jul 94 09:33:26 TZ Subject: Re: why not variable length? Cc: big-internet@munnari.OZ.AU | hunh? the ipx to ip backbone convergence is to do with router | avaialbility .... most corporations run their own routers. most corporations today are running ipx on the lan and the wan. the trend (according to most every major industry report) is toward ip on the backbone, and like a 50/50 split for lan (desktop) as well. this shift has zero to do with router availablility in the private market (where the majority of tcp/ip is sold and deployed). what is driving this convergence? heterogeneous system availability. nothing to do with the routers. if i can use ip to talk to unix, netware, mac, pc, nt, then why would they want to manage an ipx routed infrastructure in addition to ip? | >if users, administrators and vendors are willing to take | >a minor performance hit today, why not tomorrow? | | what if i am not prepared to pay for your mistakes - pls clarify. what *specifically* is the "mistake" for vl? this is what i'd like to understand. | p.s. we do not run PC DOS< Windows or NT because it costs marginally | more to maintain 3000 machiens virus free than it does with other | os's:-) i don't see the relationship of this statement to the vl discussion. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:39:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03989; Wed, 13 Jul 1994 03:06:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16965; Wed, 13 Jul 1994 03:06:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16935; Wed, 13 Jul 1994 02:49:25 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03469; Wed, 13 Jul 1994 02:49:20 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 17:48:34 +0100 To: "James 'J' Allard" Cc: big-internet@munnari.OZ.AU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: why not variable length? In-Reply-To: Your message of "Tue, 12 Jul 94 09:33:26 +0700." <9407121640.AA17471@netmail2.microsoft.com> Date: Tue, 12 Jul 94 17:48:32 +0100 Message-Id: <3606.774031712@cs.ucl.ac.uk> From: Jon Crowcroft >| what if i am not prepared to pay for your mistakes - >pls clarify. what *specifically* is the "mistake" for vl? >this is what i'd like to understand. if someone offers me 2 IPng options with appratenly 28 and 30 years lifetimes, but a 5% decrease in host performance (e.g. file server etc) today, i will take the 28 years higher performance answer. > >| p.s. we do not run PC DOS< Windows or NT because it costs marginally >| more to maintain 3000 machiens virus free than it does with other >| os's:-) > >i don't see the relationship of this statement to the vl discussion. margins of cost are in the eye of the buyer. jon From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:39:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04011; Wed, 13 Jul 1994 03:07:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16980; Wed, 13 Jul 1994 03:07:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16960; Wed, 13 Jul 1994 03:02:04 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03894; Wed, 13 Jul 1994 03:01:59 +1000 (from skh@merit.edu) Received: from localhost (skh@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA27734; Tue, 12 Jul 1994 12:58:47 -0400 Message-Id: <199407121658.MAA27734@merit.edu> To: "Mike O'Dell" Cc: Susan Hares , Jon Crowcroft , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 10:29:29 EDT." Date: Tue, 12 Jul 1994 12:58:45 -0400 From: Susan Hares Mike: Was your argument for/against variable length addresses? Your right, but that's why I would use the tool of "variable address". So we both see a generic problem - nothing stable. I say Variable length addresses will allow us to migrate easier. You say? Was this your argument for a fixed length addresses? It's nice to see that we all have crystal balls. I only wish we could do a full experience dump of each IETF person into a large bowl. Someplace, in that large bowl we might come up with the solution. Thanks for sending the note! I'm getting a sampling of the brew that might go into that large bowl of experience. Each comment gives me something to think about. Sue Hares From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 04:44:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03458; Wed, 13 Jul 1994 02:48:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16924; Wed, 13 Jul 1994 02:48:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16870; Wed, 13 Jul 1994 02:33:44 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02733; Wed, 13 Jul 1994 02:33:33 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 12 Jul 1994 12:33:30 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 12 Jul 1994 12:33:30 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA23451; Tue, 12 Jul 94 12:31:19 EDT Date: Tue, 12 Jul 94 12:31:19 EDT Message-Id: <9407121631.AA23451@mailserv-D.ftp.com> To: deering@parc.xerox.com, Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 2395 Ok. Try number 2 :-) Would it be fair to say that the heart of the disagreement is in the number of hierarchical levels that will be needed and the amount of aggregation at each level? It seems that you believe that we will have relatively few levels with a fairly high amount of aggregating at each level, while I believe that we may have lots of levels with relatively little aggregation at each level. Of secondary importance (to me) is that we should keep field boundaries on byte-borders, while you think that this is not what we should do, yes? > From: Steve Deering > > > > (2) I assume that we could achieve the .0001 address space utilization > > > required to accommodate 10^15 devices in a 64-bit (approx. 10^19) > > > address space, while meeting the goals of reasonable routing table > > > size and reasonable distribution of address assignment authority. > > > Would it be fair to say that the heart of the disagreement is that > > you tend to see the address as a 64 or 128 bit number, while I tend > > to see it as an 8 or 16 byte 'structured' field? > > NO, NO, 10^19 TIMES NO! Of course it's structured! It has hierarchical > structure for scalable routing. If it didn't, I would be arguing that a > 10^19 address space could support 10^19 hosts, not 10^15. It is precisely > the structure that limits the achievable utilization. If you read the > second clause of my sentence that you quoted, above, you will see that > I *am* taking into account the need for structure. I am shouting this > because it is a misunderstanding that people keep trying to use to > dismiss my argument, and I don't know how else to clear up the > misunderstanding. > > As I said in my previous message, there's no need for the structure to be > encoded as fixed-length fields with byte-aligned boundaries. There's > also no need to specify a fixed number of levels of hierarchy. CIDR > addresses are structured; different subtrees of the CIDR addressing > hierarchy are of different sizes and different depths. You can't draw a > nice picture of the CIDR address format, but it works, it supports scalable > routing, and it achieves much higher utilization than those address > hierarchies that do have nice pictures. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 05:11:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08628; Wed, 13 Jul 1994 05:11:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17341; Wed, 13 Jul 1994 04:27:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17295; Wed, 13 Jul 1994 04:14:38 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02693; Wed, 13 Jul 1994 02:31:37 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 17:31:02 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 11:37:29 EDT." <9407121537.AA24864@ginger.lcs.mit.edu> Date: Tue, 12 Jul 94 17:30:59 +0100 Message-Id: <3439.774030659@cs.ucl.ac.uk> From: Jon Crowcroft >I haven't a clue what on earth you're talking about. Nobody I know of who >likes the concept of location-invariant names for the entire transport entity >(of which EID's are but one example) wants them only for autoconfiguration. well, thats a shame coz i though t the idea of a conceptual EID was pretty clear. what i am talkign about (irrelevant of whether you parse or digest it) is that we do not need to size the fields in IPng packets to have arbitrary fields for EID fucntionality as well as for locator functionality and i believe people who think this don't understand EIDs whatever an EID is for, it is something that is implicit in a number of features of an IPng packet. the 'transport entity' stuff is a red herring - we are not at liberty in _this_ debate to change the use of TCP ports, and probably can't sensibly say any more than use TCP port plus low least changing (i.e. most like EID) bits of the IPng locator for the PCB key/pseudo checksum. the problem is that you (noel) are constantly trying to fit a small delta to IPv4 into the nimrod architecture, but in reality, IPng is going to be a shadow of the nimrod platonic ideal... too many people are bewitched by a falsely perceived opportunity to design a perfect IPng a la nimrod....it wont and can't happen sipp with 8+8 represented the height of compromise...which is as good as we can hope for... an ISO 7 layer stack-worth-of-IPng-EID+Locator is a bad idea.... cramming organisational hierarchy into the EID, 7 layers of .0001 % utilised network layer * layers of hierarchy etc etc is just so pessimal that i guess the new fangled IPngETF might go for it:-( i'm getting ready to unsubscribe from this list... jon From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:20:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05534; Wed, 13 Jul 1994 03:46:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA17111; Wed, 13 Jul 1994 03:46:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17092; Wed, 13 Jul 1994 03:34:29 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01271; Wed, 13 Jul 1994 01:55:08 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id LAA04223; Tue, 12 Jul 1994 11:54:42 -0400 Date: Tue, 12 Jul 1994 11:54:42 -0400 From: Vadim Antonov Message-Id: <199407121554.LAA04223@titan.sprintlink.net> To: J.Crowcroft@cs.ucl.ac.uk, mohta@necom830.cc.titech.ac.jp Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU > While it is not the strict requirement by ATM standards, it is expected > that ATM equipments from sane vendors have ATM addresses containing globally > unique 6 byte mac address. Are you sure all ATM vendors (and other its proponents) are sane? I have serious doubts about it. --vadim From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:21:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05579; Wed, 13 Jul 1994 03:47:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA17131; Wed, 13 Jul 1994 03:47:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17037; Wed, 13 Jul 1994 03:26:04 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04613; Wed, 13 Jul 1994 03:25:58 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA27106; Tue, 12 Jul 1994 10:25:46 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Jul 1994 10:25:49 -0700 To: Susan Hares From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU Sue, and other variable proponents, This recent round of discussion is quite interesting, but would one of you please point me at the specification for variable address length that is being proposed. Without it, I don't see how we can make any reasonable analysis of the cost/benefit tradeoffs against 8 or 16 byte addresses. Thanks. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:29:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05616; Wed, 13 Jul 1994 03:49:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA17150; Wed, 13 Jul 1994 03:48:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17095; Wed, 13 Jul 1994 03:34:50 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00555; Wed, 13 Jul 1994 01:36:40 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id LAA04021; Tue, 12 Jul 1994 11:35:46 -0400 Date: Tue, 12 Jul 1994 11:35:46 -0400 From: Vadim Antonov Message-Id: <199407121535.LAA04021@titan.sprintlink.net> To: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Actually, why EIDs should be the part of the header? Sounds like an awful waste of space. (And DON'T tell me that "links are fast, CPUs are faster" -- a program which works 2 times slower than another on a 10 KIPS machine will still work slower on a 100 MIPS machine -- witness the modern software bloat successfully annihilating all progress in hardware). DNS name is the pretty convinient identification of machine since it allows good flexibility (you may reassign it; one machine may have several DNS names, several machines may share ONE name; names do not violate privacy [have you ever thought that EIDs allow *everybody* to track the movements of a physical box which may be quite undesireable]). MAC-address-based EIDs is the serious misdesign -- they violate the principle of information hiding necessary for building scalable system. Everybody who ever worked on an object-oriented design knows what i'm talking about. As it is EIDs are the relics of unwillingness to recognize DNS as a part of transport layer (instead of application layer as it is now, which is a serious misdesign itself). I would also add that any flat global addressing (which waht EIDs are) is highly suspicious -- it assumes the existance of the addressing authority and associated bureaucratic bodies. What will you do if they start charging for those adresses? Technology should be independent of bureaucracy. With DNS you may start your own "anarchy-net" with a completely independent set of root nameservers. Can you do that with 802 addresses? --vadim From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:31:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11559; Wed, 13 Jul 1994 06:31:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA17631; Wed, 13 Jul 1994 06:30:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17610; Wed, 13 Jul 1994 06:20:03 +1000 Precedence: list Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04499; Wed, 13 Jul 1994 03:21:07 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25394; Tue, 12 Jul 94 13:18:54 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA29039; Tue, 12 Jul 94 13:16:32 EDT Date: Tue, 12 Jul 94 13:16:32 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9407121716.AA29039@pobox.wellfleet> To: Big-Internet@munnari.OZ.AU, kasten@ftp.com Subject: Re: The right numbers (was Re: IPng ADs Wish to Gauge...) 1. Is it reasonable to expect that the network might grow this big in the next 20 years (expected IPng lifetime) or so? Or could it easily be bigger? Frank One thing that I am somewhat uncomfortable with: Folks keep talking about IPng as having to last somewhere between 20 and 30 years. However, if IPng does last at least 20 years, then it will be so widespread by then that it will be impossible to ever change it. Imagine that most houses in the major industrialized nations (and perhaps most houses in every nation) contain a network, and that light switches, clocks, smoke detectors, and the plumbing is all networked. Aren't there going to be so many low-end devices with very long lifetimes installed that none of this will ever be changed? Now, it may be that our crystal ball is so cloudy that trying to anticipate 20 years into the future is the same as trying to anticipate 200 years into the future. However, I think that we should at least admit that what we are doing either will get discarded rather quickly, or will last essentially forever. Ross From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:35:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11679; Wed, 13 Jul 1994 06:35:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA17654; Wed, 13 Jul 1994 06:35:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17613; Wed, 13 Jul 1994 06:22:01 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05753; Wed, 13 Jul 1994 03:54:32 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwygl29438; Tue, 12 Jul 1994 13:54:09 -0400 Message-Id: To: Susan Hares Cc: Jon Crowcroft , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 12:58:45 EDT." <199407121658.MAA27734@merit.edu> Date: Tue, 12 Jul 1994 13:54:08 -0400 From: "Mike O'Dell" I'm very much of the fixed-length pursuasion. I don't believe having variable length address available will solve the kind of dislocation which one should expect in 30 years of technology evolution, so I see no need to pay for the life insurance now. In general, I think it is NUTS to actually believe that any decision we make now is going to be "right" 30 years from now without significant revision. That's not to say FORTRAN won't still be with us (and even isolated pockets of IPv4 in print servers and coke machines and toasters). Even if we were to specify variable length addresses, unless they were really used aggressively and continuously (ie, the length really varied), you'd reach the time when VL is supposed to save us and WHAMMO! People would discover that all this variable-length stuff *really* hasn't been tested very well. You then have a changeover again to IPng+1 which is not very different from what you'd have if you had chosen fixes size addresses AND THAT WAS THE ONLY THING CHANGING. Again, though, it's hard to imagine that simply being able to increase the address size alone will keep IPng viable for 20 or 30 years - in that timeframe, SOMETHING else about the protocol will need to change and almost certainly significantly. What is will be, though, is another mattter. If I could tell the future that well, I wouldn't have to do this for a living...... Cheers, -Mike O'Dell From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:36:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06385; Wed, 13 Jul 1994 04:07:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17212; Wed, 13 Jul 1994 04:07:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17180; Wed, 13 Jul 1994 03:56:18 +1000 Precedence: list Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02517; Wed, 13 Jul 1994 02:25:49 +1000 (from day@BBN.COM) Message-Id: <9407121625.2517@munnari.oz.au> From: John Day Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: cmetz@thor.tjhsst.edu Cc: big-internet@munnari.OZ.AU, pvm@isi.edu In-Reply-To: Date: Tue, 12 Jul 94 12:32:46 EST Mail-System-Version: > Have any of the people pushing variable length addresses stopped >to wonder why, in this age of increasing machine word sizes, people don't >make computers that use variable-length integers? > > Think of the applications! No more range problems. All of the >accuracy you need. Specific programs could choose integers based on their >needs, and they can always be made bigger or smaller later. No more problems >porting to architectures with different word sizes -- programs written for >variable length integers will work on machines with 32, 64, or even 67 bit >word sizes without any additional difficulties. We never do know just how >big a number we might need; why obselete our architectures now by settling >for fixed word sizes of only 32 or 64 bits? > > It's not like it can't be done. Look at all of the multiple-precision >math packages out there. It can be emulated in software with ease on today's >high performance machines, and we can build variable-length words into >tomorrow's processors and bus designs. Sure, there will be technical hurdles, > It was done 20 years ago and was fairly successful in one corner of the world. But then there were all these people from Big Computer Companies (we need mention no names) who kept saying it was too hard and couldn't be done even though it had. So you are saying that the Net is like those Big Computer Companies? From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:37:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06412; Wed, 13 Jul 1994 04:09:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17231; Wed, 13 Jul 1994 04:08:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17183; Wed, 13 Jul 1994 03:56:39 +1000 Precedence: list Received: from netmail2.microsoft.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00797; Wed, 13 Jul 1994 01:42:21 +1000 (from jallard@microsoft.com) Received: by netmail2.microsoft.com (5.65/25-eef) id AA13378; Tue, 12 Jul 94 08:42:25 -0700 Message-Id: <9407121542.AA13378@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 12 Jul 94 08:42:25 PDT X-Msmail-Message-Id: E2736CFA X-Msmail-Conversation-Id: E2736CFA X-Msmail-Fixed-Font: 0001 From: "James 'J' Allard" To: owner-Big-Internet@munnari.OZ.AU, skh@merit.edu Date: Tue, 12 Jul 94 08:22:27 TZ Subject: why not variable length? Cc: big-internet@munnari.OZ.AU, J.Crowcroft@cs.ucl.ac.uk | My problem is that I don't think we can accurately predict ANYTHING | about network technology 30 years into the future. Therefore, | the fact that we can't predict address usage patterns isn't | particularly troubling - it's no worse than any other part of it. couldn't agree more with this statement. that said, wouldn't variable length seem to be the most flexible choice? if no one uses more than 16 bytes in the next n years, well, they can call us paranoid. if we need 'em, i'd rather have them. i (again) vote for v.l. addresses, and think that we should profile 16- (or 8-byte) assignments in the near term. if all of the vendors fast path 16-, and it's enough for 10 years, great, we're all running fast. when we need 17, the 10 year old systems work a little harder, but you don't need to update the software on potentially unsupported devices. in 10 years, the instruction count for processing a vl address will be virtually nothing (i'd argue that this is practically the case today). the only argument that i've heard against vl is that it's harder to implement and a little slower. compare tcp/ip to ipx/spx. ip is harder to implement and a little slower, but guess what? there's a clear convergence away from ipx to ip on the backbone in the world today. if users, administrators and vendors are willing to take a minor performance hit today, why not tomorrow? the biggest cost to users in ipng is upgrading software to make it work. if you can imagine a day when n-byte addresses isn't enough, you can probably imagine the cost to upgrade the systems involved. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:40:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07964; Wed, 13 Jul 1994 04:47:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17374; Wed, 13 Jul 1994 04:47:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17369; Wed, 13 Jul 1994 04:41:58 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07762; Wed, 13 Jul 1994 04:41:54 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-19.dialip.mich.net (pm002-19.dialip.mich.net [35.1.48.100]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA07807 for ; Tue, 12 Jul 1994 14:41:50 -0400 Date: Tue, 12 Jul 94 18:14:36 GMT From: "William Allen Simpson" Message-Id: <2812.bill.simpson@um.cc.umich.edu> To: Big-Internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: The right numbers > From: kasten@ftp.com (Frank Kastenholz) > 1. Is it reasonable to expect that the network might grow this big in the > next 20 years (expected IPng lifetime) or so? Or could it easily be bigger? Actually, I believe the Cable 10^10 household global prediction to be about right -- not for 20 years, but for 100 years. Cable and Cellular industries have a tendency to overstate the immediate demand, since they are trying to raise capital. The world doesn't even have phones in every household after 100 years of telephony. (Neither does the USA, I might add, although primarily for cost rather than infrastructural reasons.) But the long term seems to be a reasonable prediction, although we'll probably entirely replace the cable technology with wireless local loop, which is not what they want to hear. > 2. Are the safety margins built into these numbers (e.g. 1 order of magnitude > in the hosts/network factor) enough? Too big? Too small? One order of magnitude is the standard engineering factor. We just aren't any better at prediction than that. > 3. The numbers are guesstimates of the 'leaves' of the network (leaf nodes > and subnetworks). Is there enough built in for overhead (backbones, > regionals, service providers, ...)? Too much? Too little? The "guesstimates" are verified by the current Internet net:host ratio. I think it is great to have even that much verification. The overhead for routers is only a fraction of the number of hosts, and should decrease as the network scales. Yes, there is enough for overhead. > 4. Are the base assumptions correct? > Yes, as stated they are well thought out. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:40:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08013; Wed, 13 Jul 1994 04:48:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17389; Wed, 13 Jul 1994 04:48:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17295; Wed, 13 Jul 1994 04:14:38 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02693; Wed, 13 Jul 1994 02:31:37 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 17:31:02 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 11:37:29 EDT." <9407121537.AA24864@ginger.lcs.mit.edu> Date: Tue, 12 Jul 94 17:30:59 +0100 Message-Id: <3439.774030659@cs.ucl.ac.uk> From: Jon Crowcroft >I haven't a clue what on earth you're talking about. Nobody I know of who >likes the concept of location-invariant names for the entire transport entity >(of which EID's are but one example) wants them only for autoconfiguration. well, thats a shame coz i though t the idea of a conceptual EID was pretty clear. what i am talkign about (irrelevant of whether you parse or digest it) is that we do not need to size the fields in IPng packets to have arbitrary fields for EID fucntionality as well as for locator functionality and i believe people who think this don't understand EIDs whatever an EID is for, it is something that is implicit in a number of features of an IPng packet. the 'transport entity' stuff is a red herring - we are not at liberty in _this_ debate to change the use of TCP ports, and probably can't sensibly say any more than use TCP port plus low least changing (i.e. most like EID) bits of the IPng locator for the PCB key/pseudo checksum. the problem is that you (noel) are constantly trying to fit a small delta to IPv4 into the nimrod architecture, but in reality, IPng is going to be a shadow of the nimrod platonic ideal... too many people are bewitched by a falsely perceived opportunity to design a perfect IPng a la nimrod....it wont and can't happen sipp with 8+8 represented the height of compromise...which is as good as we can hope for... an ISO 7 layer stack-worth-of-IPng-EID+Locator is a bad idea.... cramming organisational hierarchy into the EID, 7 layers of .0001 % utilised network layer * layers of hierarchy etc etc is just so pessimal that i guess the new fangled IPngETF might go for it:-( i'm getting ready to unsubscribe from this list... jon From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:41:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08305; Wed, 13 Jul 1994 04:56:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17341; Wed, 13 Jul 1994 04:27:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17295; Wed, 13 Jul 1994 04:14:38 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02693; Wed, 13 Jul 1994 02:31:37 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jul 1994 17:31:02 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 11:37:29 EDT." <9407121537.AA24864@ginger.lcs.mit.edu> Date: Tue, 12 Jul 94 17:30:59 +0100 Message-Id: <3439.774030659@cs.ucl.ac.uk> From: Jon Crowcroft >I haven't a clue what on earth you're talking about. Nobody I know of who >likes the concept of location-invariant names for the entire transport entity >(of which EID's are but one example) wants them only for autoconfiguration. well, thats a shame coz i though t the idea of a conceptual EID was pretty clear. what i am talkign about (irrelevant of whether you parse or digest it) is that we do not need to size the fields in IPng packets to have arbitrary fields for EID fucntionality as well as for locator functionality and i believe people who think this don't understand EIDs whatever an EID is for, it is something that is implicit in a number of features of an IPng packet. the 'transport entity' stuff is a red herring - we are not at liberty in _this_ debate to change the use of TCP ports, and probably can't sensibly say any more than use TCP port plus low least changing (i.e. most like EID) bits of the IPng locator for the PCB key/pseudo checksum. the problem is that you (noel) are constantly trying to fit a small delta to IPv4 into the nimrod architecture, but in reality, IPng is going to be a shadow of the nimrod platonic ideal... too many people are bewitched by a falsely perceived opportunity to design a perfect IPng a la nimrod....it wont and can't happen sipp with 8+8 represented the height of compromise...which is as good as we can hope for... an ISO 7 layer stack-worth-of-IPng-EID+Locator is a bad idea.... cramming organisational hierarchy into the EID, 7 layers of .0001 % utilised network layer * layers of hierarchy etc etc is just so pessimal that i guess the new fangled IPngETF might go for it:-( i'm getting ready to unsubscribe from this list... jon From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:48:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08039; Wed, 13 Jul 1994 04:49:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17406; Wed, 13 Jul 1994 04:49:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17303; Wed, 13 Jul 1994 04:18:36 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02447; Wed, 13 Jul 1994 02:23:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25076; Tue, 12 Jul 94 12:23:15 -0400 Date: Tue, 12 Jul 94 12:23:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407121623.AA25076@ginger.lcs.mit.edu> To: 0003858921@mcimail.com, big-internet@munnari.OZ.AU Subject: Re: Thoughts on EIDs Cc: jnc@ginger.lcs.mit.edu From: "Robert G. Moskowitz" <0003858921@mcimail.com> But whenever I try to think of EID as tied to the process, I get tied in knots! I look at my Comer V 2 drawing of the IP and TCP state machines and say that then EID is a part of the TCP machine. But when I look at the normal case of EID to the image, then EID is a part of the IP machine! Or is it. Perhaps EID is always a part of the TCP machine ... However, EID has to be a tied to a DNS name so one would think that EID is a part of the internetwork level or the IP machine. ... The EID is seems to be a part of the transport level, but MUST be carried in the IP level (I think it gets worst with the UDP machine) and thus is a levels violation. First, let me restate the warning that an EID is just one kind of name for these tranporty-type things that are causing you lack of sleep! There are other possibilities, such as DNS-type names, etc. I'll use a generic term for all of them, so we don't have to argue about how to allocate them, how to make sure they are unique, etc, etc. I'll use the term "tranport level entity name" (TLEN) - to make it clear that I'm naming an entire entity, not just one protocol, or one port (another argument I want to avoid :-) You are right that the introduction of separate TLEN's means we have to rethread our brains a little bit. What you used to think of as "the internetwork layer" does have to separate into two sub-layers; one associated with the interface(s), and one associated with the endpoint(s) (the things that TLEN's are names of). A single mobile process would be an endpoint, and have a TLEN. To answer some of your points, the TLEN names not just the TCP, and all its connections, but also the UDP and all its ports, and every other protocol. When the endpoint moves, that part of the internetwork layer which is associated with that endpoint (such as the internetwork layer's protocol demux table) has to move with it. It's not a "layering violation" for the TLEN to be *below* the TCP layer, and carried in the packets in headers before the transport header, since the TLEN names all the protocol instances of that endpoint. If that last part was confusing, thing of it this way. A mobile process has its own TCP, etc; connection blocks, the lot. When the process picks up and moves, all that state has to pick up and move with it. If you draw a line around all the stuff that has to move (including the process itself), that pile of stuff *is* the endpoint, and the TLEN is the name of all that stuff. Does this help? Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:51:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08076; Wed, 13 Jul 1994 04:51:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17421; Wed, 13 Jul 1994 04:50:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17350; Wed, 13 Jul 1994 04:36:35 +1000 Precedence: list Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02500; Wed, 13 Jul 1994 02:25:13 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.9/8.6.4) with SMTP id KAA04834; Tue, 12 Jul 1994 10:24:17 -0600 From: "Peter S. Ford" Message-Id: <199407121624.KAA04834@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: Jon Crowcroft Cc: Susan Hares , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Tue, 12 Jul 94 12:25:16 +0100. <1725.774012316@cs.ucl.ac.uk> Date: Tue, 12 Jul 94 10:24:16 MST Jon, To date the discussion seems to be working with the assumption that the only rationale for variable length addresses is for the purpose of getting really big addresses. It is only one reason in choosing variable lengths for implementing addresses. >>> none of those require variable lengths. just for longer. >>> the only thing i konw of tha argues for variable is the requirement of >>> _low bandwidthj_ to not incur the header overhead (i.e. the >>> requirement to not use the 'longest so far'). It is not only for low bandwidth that one should be worried about transmitting and managing a small number of bits. If we are aggregating a tremendous number of data streams into a major trunk it would be nice to "get back" any bandwidth possible. It also happens to have impact on latency for those systems which do full packet transmission and reception. I would substitute "bandwidth constrained environments" for "low bandwidth" and subsequently argue that this environment could occur almost anywhere in the Internet and thus it is important to have the ability to reduce the address encoding length anywhere in the system. One of the big design tradeoffs in selecting variable length is to preassign bits and trade them off against the worst case length. For example, if we assume that 16 bytes is worst case, then by preallocating 1 bit we also get 8 byte codings. This is a 1 (in the case of variable length) for 64 (in the case of fixed length 16 bytes) tradeoff which is working in the right direction. Given that there will be multiple 8 byte elements in a source route, it sounds even better. We do need to understand what the impact of this kind of coding would have on TCP end point identification. I happen to like the idea of 8 byte EIDs. >>> however, if most the low bandwidth is mobile, it needs the biggest >>> address space and most flexibility, and probably multicast and TOS >>> etc etc, and so the largest fixed length better also be the biggest >>> the worst case can tolerate.... It would seem that mobile will exploit source routing features which exploit the separation of routing information and last hop locator/eid. So I don't quite see your analysis here, since it would seem to me that 8 byte coding of this information would be very useful. Another place where you might want to use short addresses is "local use addresses"; for example, transmitting television signals over local Internet infrastructure. >>> hence fixed. hence variable. >>> hence not more than 16 and preferble not more than 8. hence 8, 16, 24, etc.. (I personally prefer using another bit and getting 4, 8, 12, ...) Once you have variable length'ing trading off another bit to allow even greater lengths is not unthinkable. >>> i assert that address utilisation efficiency will be around 50% at each >>> level if the tools for auto-re-prefixing when you change area or >>> provider are sufficently well designed. >>> if this is the case, then accommodataing a lot of levels in the 16byte >>> space is really quite trivial The experience in the IPv4 world is that administrators use byte boundaries, even when they know how to use variable length subnet masks, CIDR, etc. At present, address assignment is a human activity and whether we like it or not, it inherits many of the limitations of wet-ware. I would love to see better systems emerge to tackle this task, but betting the future on undesigned, untested, undeployed technology is a bit disconcerting. Serverless autoconfiguration is well tested in the IPX world and the administrators of those networks love it. I would recommend using something like it as the base level for IPng autoconfiguration (always steal proven good ideas!) and encourage extending auto configuration in the future. >>> jon cheers, peter From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:51:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08230; Wed, 13 Jul 1994 04:53:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17440; Wed, 13 Jul 1994 04:52:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17353; Wed, 13 Jul 1994 04:39:52 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02719; Wed, 13 Jul 1994 02:33:15 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id JAA27668; Tue, 12 Jul 1994 09:33:03 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA18444; Tue, 12 Jul 94 10:32:52 -0600 Date: Tue, 12 Jul 94 10:32:52 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407121632.AA18444@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: kasten@ftp.com (Frank Kastenholz) > ... > >(3) I assume that it is neither necessary nor desirable to specify the > > addressing hierarchy as one with fixed-width fields in the address, > > aligned on byte boundaries. I would guess that this is the major point > > of departure between myself and those who are arguing for variable-length, > > large-maximum-size addresses. > > I think that this may well be the other disagreement in that I think > that for network administrators to easily start using this > technology, we will have to make address-hierarchy fields an integral > number of bytes long. > > I would agree with you that better user-interface software can be > used to 'hide' the ickyness of 'bit-length' fields, but I just don't > see such software being written. It's been how long since we started > using IPv4 subnets, and there's not much software to hide its > ickyness... I guess I'm just more of a pessimist than you :-( That seems to be saying: 1. code to make handling 4-byte address strings easy has not been written. 2. therefore, let's give up and get as close as possible to using ASCII (or some more appropriate internation character set) in addresses in IPng headers. If things are a bleak as all that, if there is no hope for having reasonable user interfaces for dealing with IPng addresses, then the IETF should close up shop and join the ITU. There is a qualitative difference between a 4-byte IPv4 address, commonly represented as 2 or 3 parts, with a total of less than 6 things among the parts, and anything related to a 16-byte string. Humans can easily remember half a dozen words, letters, digits, or small numbers at a time, and that is why no one cares enough about the ickyness of IPv4 addresses to write a fancy user interface. Network+(subnet+)host is so simple that fancy user interfaces make things more complicated and harder to deal with. The completely non-icky version of IPv4 addresses are DNS domains. Everyone is content. On the other hand, humans cannot handle more than than half a dozen items. Human short term memory is not good for more. Something will have to be done for 8-byte addresses, not to mention 16-byte addresses. Using byte boundaries in a 16-byte string will not help. The address strings would still be too long and apparently unstructured to deal with. The much talked about zillion-layers-of-IPv4-hierarchy are irrelevant in this context. Almost everyone treats IPv4 addresses as having at most 3 hierachial parts, and usually only 2 parts. The fact that people above or below you in the hierarchy divide the same 32-bits differently doesn't bother you, even if you happen to be aware of it. Besides, as other people have repeatedly said, if you like ASCII or other byte or coarser granular address strings, then use DNS. Human-readable IPng addresses not not require ASCII strings in IPng headers! The IETF need not convene a committee and spend the next 6 years designing a replacement for dotted-{decimal,octal,hex} IPv4 addresses in the name of making IPng address tolerable. Besides being misdirected on the face of things (worrying about IPv4 to solve IPng), such an effort would be short-circuited by the market. Someone will come up with a good enough IPng address representation scheme as soon as people outside standards committees have to worry about IPng addresses. It has been asserted that people handle variable length phone numbers, names, and addresses. That is simply false. Those of us with lots of letters in our names know that names are really fixed length, blank-filled fields. Anyone with an unusually long telephone number also immediately discovers that society thinks telephone numbers are fixed length, about 12 characters long, and blank-filled. Anyone who fills out a FedEx ticket or otherwise tries to communicate a long address makes the same discovery about mundane addresses. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:51:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08264; Wed, 13 Jul 1994 04:54:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17457; Wed, 13 Jul 1994 04:54:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17306; Wed, 13 Jul 1994 04:21:44 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01412; Wed, 13 Jul 1994 01:58:38 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14528(4)>; Tue, 12 Jul 1994 08:57:58 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 12 Jul 1994 08:57:45 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: jnc's message of Mon, 11 Jul 94 22:18:19 -0800. <9407120518.AA21594@ginger.lcs.mit.edu> Date: Tue, 12 Jul 1994 08:57:34 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul12.085745pdt.12171@skylark.parc.xerox.com> Noel, > However, it's easy to create scenarios in which you don't get .0001 > utilization; e.g. 7 layers of naming (and we've got 5 now in many branches) > at 10% each (which is about what we get now, per layer, quite often), gives > you an efficiency of 10^-7. As I said, there are lots of ways of squandering address space. It's also possible to design a system that does *not* squander address space, which is what I am advocating. > ... In other words, I think variable-length fields within a > fixed-length address are greatly to be preferred over fixed-length > fields within a variable-length address. > > This is just a representation issue, and a really insignificant one at that. The point of my message was to state my assumptions. I assume that this *is* a significant issue. You assume otherwise. So be it. > If you look at what *any* hierarchical naming scheme used by routing is > *really* doing, it's *always* the same. You take a group of things, draw a > circle around it, and give the circle a name. Recurse a bunch of times. The > complete name of a low-level object consists of the sequence of the names of > all the enclosing objects. Since, in a very large real network, you don't > have the same number of nesting levels everywhere, the resulting names are, > *by definition*, variable length. Save me the Networking 101 lecture, Noel. > You may or may not be able to pack them into a fixed length field, using some > representation or other, but the choice of a representation ought to be based > on a more thorough analysis of what the routing and routers really need, not > arguments about the generic benfits of fixed versus variable. Oh, I agree that the representation is a secondary issue. Another of my assumptions that I forgot to mention is that a hierarchical address, much like we have now with IPv4, but with room for a few more levels of hierarchy and a lot more nodes, satisfies what routing and routers really need. It is from the basis of that assumption (which I thank you for reminding me to make explicit) that I then proceed to think about a representation. At that point, concerns other than the needs of routing and routers come into play (their needs having already been met). One of those concerns is machine-friendliness of fixed vs. variable length addresses. Another is efficiency of bandwidth and memory utilization. Another is the human factors of reading and writing the text representation of an address (for those few people who actually need to do that). And so on. It is balancing all of these concerns that is the engineering challenge of designing the protocol. > You seem to be assuming that the internetwork routers of the future are going > to make the choice of what to do with the packet based on an address in the > packet. This seems very unlikely to me. There's going to be more and more > information needed to forward packets, and as a matter of efficient we won't > i) ship it all around in every packet, and ii) make the routers paw through > it for every packet. As I stated in a lengthy message to the sipp and big-i lists some time ago, I consider the point of this IPng effort to be the design and deployment of a new version of IP. IP uses hop-by-hop routing, based on addresses (and, in theory, TOS bits) carried in every packet. (Now I'm the one giving the Networking 101 lecture!) IPng may provide a convenient shorthand representation of all the relevent bits in the header to avoid the need for routers to "paw through" all the packets looking for them (the SIPP Flow ID is intended to serve this purpose), but those bits (at least the addressing ones) will still be there. > Most packets, but not all, will be forwarded based on some data about that > particular sequence of packets which is cached in the routers. This is not a > startling leap from what we do now; all high-end routers *already* cache data > about active packet trains. So? The fact that high-end routers front their routing tables with a cache doesn't eliminate the need for addresses in every packet. Those addresses have to be there to handle the case of a cache miss. They are also needed to know where to send an ICMP error message, if the packet is erroneous. We've got a datagram network here -- datagrams carry addresses in every packet. Many of us think that the datagram nature of IP is a significant contributor to its success and that we would be crazy to abandon it. Steve From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:51:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10778; Wed, 13 Jul 1994 06:10:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA17562; Wed, 13 Jul 1994 06:10:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17546; Wed, 13 Jul 1994 06:04:37 +1000 Precedence: list Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08321; Wed, 13 Jul 1994 04:57:56 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.9/8.6.4) with SMTP id MAA07832; Tue, 12 Jul 1994 12:56:35 -0600 From: "Peter S. Ford" Message-Id: <199407121856.MAA07832@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: Susan Hares , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Tue, 12 Jul 94 10:25:49 -0700. Date: Tue, 12 Jul 94 12:56:34 MST Dave, There are two variable length proposals floating around that I know of. There is the TUBA proposal, and a good reference for addresses (and a lot more) is: 1629 DS R. Colella, R. Callon, E. Gardner, Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", 05/19/1994. (Pages=52) (Format=.txt) (Obsoletes RFC1237) There is also the BigTen proposal which is documented in: draft-ford-bigten-bt-format-00.txt draft-rekhter-bigten-addr-arch-00.txt draft-li-bigten-addr-format-00.txt cheers, peter From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:52:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10866; Wed, 13 Jul 1994 06:14:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA17577; Wed, 13 Jul 1994 06:14:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17543; Wed, 13 Jul 1994 06:04:13 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10526; Wed, 13 Jul 1994 06:04:06 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-20.dialip.mich.net (pm002-20.dialip.mich.net [35.1.48.101]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA15249 for ; Tue, 12 Jul 1994 16:04:01 -0400 Date: Tue, 12 Jul 94 19:42:01 GMT From: "William Allen Simpson" Message-Id: <2817.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: why not variable length? > From: "James 'J' Allard" > the only argument that i've heard against vl is that it's > harder to implement and a little slower. compare tcp/ip to > ipx/spx. ip is harder to implement and a little slower, but > guess what? there's a clear convergence away from ipx to ip > on the backbone in the world today. > Hmmm. Having worked on both TCP/IP and IPX/SPX, I'd say IP is vastly easier to implement, IP being much better defined. The (few) measurements that I've done suggest that the only reason IP is any slower than IPX is that IPX doesn't calculate a checksum. The reason that people are moving toward IP is that it is better defined and more robust. Let's assume that variable length IP is like the IPX checksum. The code path is never exercised. When IPX checksums are turned on, the net falls apart. If variable length is used, should IP addresses suddenly get longer in 20 years, I predict the _world_ will fall apart. I repeat: The reason that people are moving toward IP is that it is better defined and more robust. Let's keep it that way! Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:52:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09166; Wed, 13 Jul 1994 05:25:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA17457; Wed, 13 Jul 1994 04:54:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA17306; Wed, 13 Jul 1994 04:21:44 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01412; Wed, 13 Jul 1994 01:58:38 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14528(4)>; Tue, 12 Jul 1994 08:57:58 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 12 Jul 1994 08:57:45 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: jnc's message of Mon, 11 Jul 94 22:18:19 -0800. <9407120518.AA21594@ginger.lcs.mit.edu> Date: Tue, 12 Jul 1994 08:57:34 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul12.085745pdt.12171@skylark.parc.xerox.com> Noel, > However, it's easy to create scenarios in which you don't get .0001 > utilization; e.g. 7 layers of naming (and we've got 5 now in many branches) > at 10% each (which is about what we get now, per layer, quite often), gives > you an efficiency of 10^-7. As I said, there are lots of ways of squandering address space. It's also possible to design a system that does *not* squander address space, which is what I am advocating. > ... In other words, I think variable-length fields within a > fixed-length address are greatly to be preferred over fixed-length > fields within a variable-length address. > > This is just a representation issue, and a really insignificant one at that. The point of my message was to state my assumptions. I assume that this *is* a significant issue. You assume otherwise. So be it. > If you look at what *any* hierarchical naming scheme used by routing is > *really* doing, it's *always* the same. You take a group of things, draw a > circle around it, and give the circle a name. Recurse a bunch of times. The > complete name of a low-level object consists of the sequence of the names of > all the enclosing objects. Since, in a very large real network, you don't > have the same number of nesting levels everywhere, the resulting names are, > *by definition*, variable length. Save me the Networking 101 lecture, Noel. > You may or may not be able to pack them into a fixed length field, using some > representation or other, but the choice of a representation ought to be based > on a more thorough analysis of what the routing and routers really need, not > arguments about the generic benfits of fixed versus variable. Oh, I agree that the representation is a secondary issue. Another of my assumptions that I forgot to mention is that a hierarchical address, much like we have now with IPv4, but with room for a few more levels of hierarchy and a lot more nodes, satisfies what routing and routers really need. It is from the basis of that assumption (which I thank you for reminding me to make explicit) that I then proceed to think about a representation. At that point, concerns other than the needs of routing and routers come into play (their needs having already been met). One of those concerns is machine-friendliness of fixed vs. variable length addresses. Another is efficiency of bandwidth and memory utilization. Another is the human factors of reading and writing the text representation of an address (for those few people who actually need to do that). And so on. It is balancing all of these concerns that is the engineering challenge of designing the protocol. > You seem to be assuming that the internetwork routers of the future are going > to make the choice of what to do with the packet based on an address in the > packet. This seems very unlikely to me. There's going to be more and more > information needed to forward packets, and as a matter of efficient we won't > i) ship it all around in every packet, and ii) make the routers paw through > it for every packet. As I stated in a lengthy message to the sipp and big-i lists some time ago, I consider the point of this IPng effort to be the design and deployment of a new version of IP. IP uses hop-by-hop routing, based on addresses (and, in theory, TOS bits) carried in every packet. (Now I'm the one giving the Networking 101 lecture!) IPng may provide a convenient shorthand representation of all the relevent bits in the header to avoid the need for routers to "paw through" all the packets looking for them (the SIPP Flow ID is intended to serve this purpose), but those bits (at least the addressing ones) will still be there. > Most packets, but not all, will be forwarded based on some data about that > particular sequence of packets which is cached in the routers. This is not a > startling leap from what we do now; all high-end routers *already* cache data > about active packet trains. So? The fact that high-end routers front their routing tables with a cache doesn't eliminate the need for addresses in every packet. Those addresses have to be there to handle the case of a cache miss. They are also needed to know where to send an ICMP error message, if the packet is erroneous. We've got a datagram network here -- datagrams carry addresses in every packet. Many of us think that the datagram nature of IP is a significant contributor to its success and that we would be crazy to abandon it. Steve From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 06:52:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10996; Wed, 13 Jul 1994 06:18:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA17596; Wed, 13 Jul 1994 06:18:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17540; Wed, 13 Jul 1994 06:04:08 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10524; Wed, 13 Jul 1994 06:04:04 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-20.dialip.mich.net (pm002-20.dialip.mich.net [35.1.48.101]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA15242 for ; Tue, 12 Jul 1994 16:03:59 -0400 Date: Tue, 12 Jul 94 19:30:20 GMT From: "William Allen Simpson" Message-Id: <2816.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Where and When is the EID needed? > From: dcrocker@mordor.stanford.edu (Dave Crocker) > The transport layer uses its sequence numbers to determine the 'place' in a > stream. Any of the 'connection' identifiers may be used by the transport > layer when building the IP layer. I.e., two packets coming in with > different IP info, but part of the same connection, get put into their > proper order by virtue of the sequence number. > > This scheme will handle mobility by allowing the moving process to > add/delete IP addrs (i.e., interface addresses) on the fly. To the extent > that an old one has become inoperable but not deleted yet -- i.e., packets > don't reach it via the old IP address, but the sender doesn't know this yet > -- the sender retransmits via one of the other IP addresses that are part > of the association. > Great Idea! It should be no surprise that this is what we are already doing in Mobile-IP.... The Mobile Node can register multiple locations, and the Home Agent merely duplicates IP packets for all of the locations. Very important on cellular provider boundaries. No retransmission required. If the mobile recieves all of them, IP handles duplicate packets gracefully. But we still need only ONE "Home-Address" (think Identifier cum EID). > What's bad about this scheme? It only works for those hosts who implement > it. I.e., it is very much NOT invisible to hosts. > No, only the Mobile Node is aware. A non-mobile Correspondent doesn't have to do anything. All the work is done by the forwarding agent. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 07:10:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12791; Wed, 13 Jul 1994 07:10:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA17805; Wed, 13 Jul 1994 07:10:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17648; Wed, 13 Jul 1994 06:35:18 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11659; Wed, 13 Jul 1994 06:35:15 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id NAA09480; Tue, 12 Jul 1994 13:35:08 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA19371; Tue, 12 Jul 94 14:34:37 -0600 Date: Tue, 12 Jul 94 14:34:37 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407122034.AA19371@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: deering@parc.xerox.com (Steve Deering @ parc.xerox.com) > ... > As I said in my previous message, there's no need for the structure to be > encoded as fixed-length fields with byte-aligned boundaries. There's > also no need to specify a fixed number of levels of hierarchy. CIDR > addresses are structured; different subtrees of the CIDR addressing > hierarchy are of different sizes and different depths. You can't draw a > nice picture of the CIDR address format, but it works, it supports scalable > routing, and it achieves much higher utilization than those address > hierarchies that do have nice pictures. That's the crux of the disagreement on the necessary size of the IPng address. People seem to have the idea that: 1. all IPng hosts must be the same depth in the hierarchy. 2. all branches of the IPng hierarchy at a given depth in the hierarchy have the same number of bits. 3. that single, simple symmetric tree of an hierarchy is coded into all routers and hosts. 4. the fixed fields in that hierarchy are integral numbers of bytes long. 5. as a consequence of (1)-(4), the length of the IPng address field must be variable. I do not understand why people seem to be stuck on (1)-(4). Do people believe (1)-(4) were characteristics of IPv4, even before CIDR? Have people read "class-{A,B,C}" so many times they have worn grooves in their brains? I certainly do not understand how (1)-(4) suggest (5). Just because 4.*BSD is full of functions that compute netmasks in the familiar, simplistic, inflexible, justly maligned way does not mean that IPng must be similarly restricted to 5, 7, or however many fixed hierarchies. Why must all routers, not to mention all hosts, understand or even know about the structure of the entire hierarchy? What's wrong with the equivalent of variable subnet masks? What's wrong with CIDR? Perhaps people do not really believe this, but traffic in the mailing lists strongly suggests that many do. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 07:11:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12801; Wed, 13 Jul 1994 07:11:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA17810; Wed, 13 Jul 1994 07:11:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17662; Wed, 13 Jul 1994 06:36:21 +1000 Precedence: list Received: from odin.ucsd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05969; Wed, 13 Jul 1994 03:57:31 +1000 (from jdietz@cs.ucsd.edu) Received: from tartarus.ucsd.edu by odin.ucsd.edu; id AA09789 sendmail 5.67/UCSDPSEUDO.4-CS via SMTP Tue, 12 Jul 94 10:57:26 -0700 for Big-Internet@munnari.OZ.AU Received: by tartarus (5.67/UCSDPSEUDO.4) id AA04499 for Big-Internet@munnari.OZ.AU; Tue, 12 Jul 94 10:57:11 -0700 From: jdietz@cs.ucsd.edu (Jack Dietz) Message-Id: <9407121757.AA04499@tartarus> Subject: Re: IPng ADs Wish To Gauge Consensus on Address Length Requirements To: Big-Internet@munnari.OZ.AU Date: Tue, 12 Jul 1994 10:56:57 -0700 (PDT) In-Reply-To: from "Big-Internet@munnari.OZ.AU" at Jul 13, 94 00:21:12 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3177 > Date: Tue, 12 Jul 94 03:42:02 -0400 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Message-Id: <9407120742.AA22997@ginger.lcs.mit.edu> > Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > > From: Robert Elz > > I have less opinion on the other half of the question, whether EIDs should > be in none/some/all packets. Whatever works is my opinion here. Different > protocol design philosophies will arrive at different answers, all for > legitimate reasons. > > Ah. If you go back to my message to Dave, I think I concluded that *somehow*, > some indication of the endpoint has to be given in the packet (even if it's > inherent, as part of a flow id), otherwise you can't have multiple endpoints > at a single address. > > You don't want to discard that capability, do you? If not, how else do you > figure out which endpoint to deliver the packets to if there are several of > them there? Maybe it's not a full EID (and ESEL's aren't), but there has to be > *something* in the packets, no? Not specifically. It's possible to do endpoint identification with no extra EID field, at the transport layer. Currently, in order to provide an extra level of assurance that a TCP packet has not been misdelivered, there is a pseudo-header included in the checksum computation, adding the the source and destination addresses out of the IP header into the TCP checksum. The same step could be taken with EIDs. By including the EID in the checksum computation at both ends, a certain level of assurance that a packet has been delivered to the proper endpoint, without specifically including the EID in the packet. If the checksum computation fails during TCP demultiplexing, it's bad for some reason, and if the computation succeeds, there's a pretty good chance the packet went to the right place. Moreover, if there are several EIDs colocated within the same machine, picking the right one could be accomplished by trying the checksum computation with each EID in turn. The packet will only be valid for one of the EIDs, and correct delivery will occur. The only possible hitch is that colocated EIDs cannot have the same 1's complement checksum, or that source and destination EID pairs for open connections cannot have the same checksum. An enlarged checksum field in the new versions of TCP and UDP would reduce the occurence of this, and an extra check against the valid TCP sequence numbers during demultiplexing would allow misdirected packets to be identified and run through the EID determination process again. However, it is possible that two UDP applications, speaking with the same port on the same other machine, listening on the same port, and with EIDs that have the same 1's complement checksum, could receive each others packets by mistake. Services provided by servers on mobile EIDs may need to ensure that they are using unique ports. Other than that, this scheme seems to provide the benefits that either a fixed or a variable EID (you choose) gives to the transport layer without incurring the overhead of sending it in each packet. Comments? Jack Dietz // jdietz@ucsd.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 07:24:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13150; Wed, 13 Jul 1994 07:24:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA00152; Wed, 13 Jul 1994 07:24:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA17844; Wed, 13 Jul 1994 07:20:17 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12998; Wed, 13 Jul 1994 07:20:14 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA28672; Tue, 12 Jul 1994 14:20:10 -0700 Message-Id: <199407122120.OAA28672@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 12 Jul 94 15:31:33 -0400. <9407121931.AA26389@ginger.lcs.mit.edu> Date: Tue, 12 Jul 94 14:20:10 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: Humans handle them quite well. Certain computer software (aka the punch-card mentality) doesn't. Turns out that humans handle them well for certain kinds of processing, but if you want to test for high performance, you need to constrain variability. We do fixed- width lists, for example, better than we do searching through a sequence with variable markers. d/ From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 07:29:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13266; Wed, 13 Jul 1994 07:29:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA00213; Wed, 13 Jul 1994 07:29:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA17748; Wed, 13 Jul 1994 07:01:16 +1000 Precedence: list Received: from thor.tjhsst.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09198; Wed, 13 Jul 1994 05:27:56 +1000 (from cmetz@thor.tjhsst.edu) Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0qNnVb-000AelC; Tue, 12 Jul 94 15:28 EDT Message-Id: To: Susan Hares Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 12:58:45 EDT." <199407121658.MAA27734@merit.edu> Date: Tue, 12 Jul 1994 15:28:50 EDT From: Craig Metz In message <199407121658.MAA27734@merit.edu>, you write: >So we both see a generic problem - nothing stable. I say >Variable length addresses will allow us to migrate easier. >You say? Was this your argument for a fixed length addresses? The (oft overlooked) answer to this problem of migration is that many of the IPng proposals embrace autoconfiguration and discovery. The end goal is that anywhere from a subnet to a whole corporation could change all of their addresses automatically should the need to renumber arrive. This allows us, from a technical standpoint, to ``pack'' address space. Combined with routing improvements, a BIG one being CIDR-like facilities, we should be able (again, from a technical standpoint) to achieve a far greater density of address utilitzation than with IPv4. And, should we ever run out of address space before our protocol designs themselves become obselete, we already have the infrastructure in place that can be extended to handle bigger addresses and any change in actual numbering that may come with them. >It's nice to see that we all have crystal balls. While many people are adamant in opposition of any sort of planned obselescence, it really is impractical to think that, a century from now, any of the protocols we are designing will still be used as-is. Even in the PSTN, where backwards-compatibility is crucial, things have changed rather drastically in the past twenty years. And yes, people have found that their phone numbers are changing. But we have two things they don't. We are building discovery and autoconfiguration into our protocols, so that endpoints can change their addresses ``seamlessly'' (how ``seamless'' that is will, of course, remain to be seen in implementations), and we have facilities like DNS that allow us to indirect addresses such that numeric changes are hidden from most users. Right now, 16-byte addresses would offer us a measly 340,282,366,920,938,463,463,374,607,431,768,211,456 endpoint addresses in our base space. Let's say that we only have a .0001% density (what do I hear for IPv4? 20%? 10%?). We're down to 340,282,366,920,938,463,463,374,607,431,768. Say that, in twenty years, the world population is five times what it is now. Assuming 2^32 people because it's a nice number and not too far off from the current world population, that's 158,456,325,028,528,675,187,087 addresses we have allocated for every person on the planet. Sure, we'll actually eat bits for things like routing heirarchy. I don't see much of a long term solution *but* to start eating bits in order to keep the sizes of routing tables sane. But that is a *lot* of bits you have to waste in order to run out of address space. Especially when you can't use excuses like the need for fixed address block sizes (the old Class A/B/C) or the pain of renumbering machines. Many proponents of variable length addresses claim that the proponents of fixed length addresses are ``looking into our crystal ball'' and picking numbers that we think will work. While there is some truth to that, I think it's very reasonable to say that sixteen bytes leaves you so much room that we can be completely sure that the protocol's lifetime will be far shorter than that of the address space. It is because of this that the main argument of the variable-length proponents, that ``we may never know,'' holds no weight with me. I wonder if some of them would want us to use variable length fields to specify the length of the address. ``Just in case''... -Craig From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 07:33:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13309; Wed, 13 Jul 1994 07:33:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA00233; Wed, 13 Jul 1994 07:33:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17668; Wed, 13 Jul 1994 06:36:49 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04528; Wed, 13 Jul 1994 03:21:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25391; Tue, 12 Jul 94 13:21:52 -0400 Date: Tue, 12 Jul 94 13:21:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407121721.AA25391@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Steve Deering > If you look at what *any* hierarchical naming scheme used by routing is > *really* doing, it's *always* the same. ... the resulting names are, > *by definition*, variable length. Save me the Networking 101 lecture, Noel. If everyone would keep in in the front of their minds the fact that fixed length addresses are nothing more than an attempt to represent an inherently variable length thing in a fixed field, I'd be happy to. You may be well aware of this, but I see signs that not everyone else is. One of those concerns is machine-friendliness of fixed vs. variable length addresses. ... IP uses hop-by-hop routing, based on addresses ... carried in every packet. IPv4 was a really nice big step forward. It's also history. I'm not in favor of taking addresses out of packets because I woke up one morning and said "gee, let's do something different today for the sake of doing something different". It's a design decision which I came to based on an analysis of what networking is really doing. IPv4 was a success because people sat down and threw away the past, and used used their increased understanding to take a new path. "Plan to throw one away." We need to stop clinging to the IPv4 model in detail, because to do so is to get washed away on the tide of change. If the IETF doesn't do something radical, and take the next step, it's dead. The fingernails will keep growing for a while, but the writing will be on the wall. We have to very cold-bloodedly sit down and say to ourselves about IPv4: "what is good, and will last, and what is junk, and should be thrown out". If we aren't excrutiatingly brutal about this, we're going to wind up on the junk heap of history, because someone else will. You have done a lot of this: for example, getting rid of the IP header checksum was a bold and innovative stroke, and, now that you've pointed it out, obviously the right thing. We all need to keep on going, though. You want to keep addresses in each packet, but I think we have to throw this model out. Simply assuming that since things used to work this way, they will continue to do so, is not bold enough. We have to look at this very cold- heartedly, to see if it really makes sense. IPng may provide a convenient shorthand representation of all the relevent bits in the header to avoid the need for routers to "paw through" all the packets looking for them ... but those bits (at least the addressing ones) will still be there. That all the relevant bits will always be in the header seems to be your assumption (and it's one widely shared, even among some of the people working on Intergrated Services, so you're in good company :-). I don't believe it. As the service model of the what the internetwork can do for you becomes more complex, it's going to take more bits to specify what you want. Also, the hassle of maintaining all the critical state in the routers that that data refers to is going to get harder. Already we see things like RSVP going to a design where the ends maintain the state. The inevitable result of these trends is a design where, for many (but not all) packets, there is non-critical state in the routers, which the ends have to maintain, and once you get to that, it's clear that the address of the destination is just one more piece of this state. The address is really just useful as input to the route selection, and if *that* is no longer being done by the routers (as many, if not most, people working on routing seem to feel is where we are going), then there's no use to having the destination address in packets. Sure, fixed length headers, and fixed length fields, make processing easier and faster. Things such as flow-ids give you that, though. All you really need in the packet is enough data to find the state in the routers that tells them what to do with the packets. In IPv4, it's the address, which you use to look in routing tables. Things are changing, though. We've got a datagram network here -- datagrams carry addresses in every packet. Many of us think that the datagram nature of IP is a significant contributor to its success and that we would be crazy to abandon it. You're coming close to putting words in my mouth that I never said. You're carefully picking and chosing what pieces of IPv4 define "datagram", and defining anything that doesn't have them as "not datagram" (i.e. "bad"), perhaps so you can tar me with that brush. If so, it's a poor rhetorical device, and one someone needn't stop to if their technical analysis is good. Rather than have useless argument over what the definition of "datagram" is, let me just say that I think the biggest single advance of IPv4 (apart from the separation of transport from internetwork) was the notion of an *unreliable* internetwork layer. The routers get to mangle, drop, reorder, duplicate, etc, to their heart's content. This made the overall design much simpler. This property I very much believe in, and want to keep. The addresses in every packet are just a means to an end, getting the packets from the source to the destination. If we come up with a better mechaism to do that, the addresses are not critical any more. So I disagree with your (effective) conclusion that addresses in every packet are a significant contributor to IP's success. (IP owes its suceess, I think, more to things like the wide availability of working implementations of a non-vendor-specific networking design that worked over a broad range of networking technologies.) Is the network I'm thinking of a "datagram" network? It depends on what you think a datagram network is (and not's let waste time arguing over the definition). If you mean an unreliable layer which carries packets from the source to the destination, yes it is. If you have some more expansive definition, maybe it isn't. But the names are irrelevant; what's relevant is: will it work, and is it the best design? Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 07:44:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13811; Wed, 13 Jul 1994 07:44:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA00263; Wed, 13 Jul 1994 07:44:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00227; Wed, 13 Jul 1994 07:32:32 +1000 Precedence: list Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13301; Wed, 13 Jul 1994 07:32:22 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.9/8.6.4) with SMTP id PAA10440; Tue, 12 Jul 1994 15:32:11 -0600 From: "Peter S. Ford" Message-Id: <199407122132.PAA10440@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: "Mike O'Dell" Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Tue, 12 Jul 94 13:54:08 -0400. Date: Tue, 12 Jul 94 15:32:10 MST Mike, I think the approach that many are taking towards IPng is to anticipate for the 20+ year time frame. While we might not be able to anticipate the absolutes of the future we should be able to say a few things: 1) datagrams with source and destination addrs 2) hop count for limiting loop problems 3) demux for different transports 4) some kind of packet length After this, the degree of consensus seems to fall off, especially in terms of how to implement ... ?) source routing ?) fragmentation ?) security ?) flows ?) extensions/options ?) ??? It seems a key issue debate is how to extend at the Internetwork layer (or perhaps put more precisely: below transport and above subnetwork), including something which we probably can agree will be in IPng: addresses. There are those who believe we will end up using addresses in ways different from the way we anticipate today (probably in addition to, rather than in replacement of unicast, multicast, etc.). This would call for making addresses extensible. At a minimum we probably can agree that saving code space in the high order bits of any addressing choice for future use is a good idea. That is one form of extensibility. There seems to be some disagreement as to whether or not we need to be able to code different lengths in the address fields. The current debate gets close to one of brinkmanship: if we set the worst case small enough then there is no space/bandwidth savings in multiple code sizes for addresses, but we might not be able to meet the requirements. It appears that there is a consensus that 8 bytes is too small so we end up with a bigger size. This opens up the avenue of using variable length both for extension in terms of bigger addresses but also for coding smaller addresses. (when the fixation (pun intentional) was 8 bytes the var length crew was very focussed on vl for getting more bytes). I agree that coding variable length is not for free, but I disagree with the cost estimates that are presented so far. Your concern is that the vendors will not adequately test their code due to lack of use of all cases. Somehow we manage to get things like TCP and its dynamics (which I consider to be far more complicated than variable length addresses) spec'd, coded and interoperating. We get there by interoperation testing and the vendors run test suites, etc. If we provide for 8 and 16 byte encodings, I am confident the vendors can make that work, and I believe that they can make 8,16, ..., 64 to work just as well. Perhaps we should try to set this discussion on firmer analytical ground by challenging the debators to take an existing high performance SIPP-16 implementation for hosts and converting it to handle a variable length case holding as much as possible constant. This is an extension of an idea Craig floated a while ago in terms of coding ip_input() for the variable length case. My guess is that both sides of the debate would learn a lot from this form of exercise. cheers, peter From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 08:05:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12308; Wed, 13 Jul 1994 06:51:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA17698; Wed, 13 Jul 1994 06:50:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17645; Wed, 13 Jul 1994 06:32:27 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11590; Wed, 13 Jul 1994 06:32:22 +1000 (from skh@merit.edu) Received: from localhost (skh@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA18104; Tue, 12 Jul 1994 16:32:16 -0400 Message-Id: <199407122032.QAA18104@merit.edu> To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: Susan Hares , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 10:25:49 PDT." Date: Tue, 12 Jul 1994 16:32:15 -0400 From: Susan Hares Dave: I was going to point you toward all the variable length specifications that Peter Ford did. But he beat me to the punch. She who hesitates doesn't have to write the long email message. Cheers, Sue Hares From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 08:05:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12653; Wed, 13 Jul 1994 07:01:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA17743; Wed, 13 Jul 1994 07:00:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17695; Wed, 13 Jul 1994 06:40:57 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09277; Wed, 13 Jul 1994 05:31:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26389; Tue, 12 Jul 94 15:31:33 -0400 Date: Tue, 12 Jul 94 15:31:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407121931.AA26389@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) It has been asserted that people handle variable length phone numbers, names, and addresses. That is simply false. Those of us with lots of letters in our names know that names are really fixed length, blank-filled fields. Humans handle them quite well. Certain computer software (aka the punch-card mentality) doesn't. I'm quite sensitive to this, as there is computer software out there (less than there used to be, thank goodness) which thinks people have first names and middle initials, and won't accept any alternative. I find this infuriating (for obvious reasons). This used to be a perfectly acceptable naming variant years ago, before we got straightjacketed by lazy programmers. (I've seriously thought about legally changing my first name to "J", just to throw sand in the gears of these idiots.) Anyway, this is pretty much irrelevant to whether we ought to have a fixed length representation in packets. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 08:06:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12557; Wed, 13 Jul 1994 06:56:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA17726; Wed, 13 Jul 1994 06:56:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17674; Wed, 13 Jul 1994 06:37:16 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07999; Wed, 13 Jul 1994 04:48:28 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14425(2)>; Tue, 12 Jul 1994 11:48:11 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 12 Jul 1994 11:48:06 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: jnc's message of Tue, 12 Jul 94 10:21:52 -0800. <9407121721.AA25391@ginger.lcs.mit.edu> Date: Tue, 12 Jul 1994 11:47:50 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul12.114806pdt.12171@skylark.parc.xerox.com> > You have done a lot of this: for example, getting rid of the IP header > checksum was a bold and innovative stroke, and, now that you've pointed it > out, obviously the right thing. We all need to keep on going, though. Hmm. I think I was also bold to specify fixed-length, 8-byte addresses. :-) > You want to keep addresses in each packet, but I think we have to throw this > model out. The approach of putting enough information is every packet to make it forwardable without reference to any previous packets enforces a discipline that limits featuritis -- each feature has to earn its place in the header -- which has in turn kept IP (and IPX and AppleTalk) simple and implementable and manageable. If you relax that constraint, I fear you'll end up with the baroque, complicated, interoperability-challenged "signalling protocols" that are typical of all those efforts that *are* filling up the ash heap of history (e.g., X.25, ISDN, ATM). Steve From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 08:06:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12749; Wed, 13 Jul 1994 07:06:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA17775; Wed, 13 Jul 1994 07:06:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17679; Wed, 13 Jul 1994 06:39:54 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08459; Wed, 13 Jul 1994 05:02:52 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA03737; Tue, 12 Jul 94 15:02:40 EDT Message-Id: <9407121902.AA03737@tipper.oit.unc.edu> To: John Day Cc: cmetz@thor.tjhsst.edu, big-internet@munnari.OZ.AU, pvm@isi.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 94 12:32:46 EST." <9407121625.2517@munnari.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Jul 94 15:02:40 -0400 From: Simon E Spero General comment on this thread; it looks like the curent consensus is rough enough to strip paint... I get the feeling that there's a comprimise lurking just out of sight, but I don't know where it is ("This compromise cannot be seen"). I wonder if something based on the PIP/SIPP routing header might fit the bill. Maybe if SIPP were changed to have 64 bit arpable EIDs, and have slots for the first and last routing entries in the header? Since routing header entries only need to be significant in their local context, maybe half the addresses could be reserved for addresses of global significance and each address sequence could terminate in a global address? The routing tokens in the SIPP header could even be used in place of flows, helping to keep the packet size down a smidgeon. Also, in the common case it eliminates the need for routing headers. This is a simple kludge on SIPP extended addresses and 8+8, but is 8+8+(8n) closer to the middle ground? Simon For fans of IPng, T.H.I.S. presents IP:tG The game where the only card is "Magical Hack" From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 08:06:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14471; Wed, 13 Jul 1994 08:04:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA00299; Wed, 13 Jul 1994 08:04:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00271; Wed, 13 Jul 1994 07:45:08 +1000 Precedence: list Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13822; Wed, 13 Jul 1994 07:44:59 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA28975; Tue, 12 Jul 94 14:35:52 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA11302; Tue, 12 Jul 1994 17:36:41 -0400 Message-Id: <9407122136.AA11302@skidrow.lkg.dec.com> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: Big-Internet@munnari.OZ.AU Subject: Re: The right numbers (was Re: IPng ADs Wish to Gauge...) In-Reply-To: Your message of "Tue, 12 Jul 94 13:16:32 EDT." <9407121716.AA29039@pobox.wellfleet> Date: Tue, 12 Jul 94 17:36:41 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: rcallon@pobox.wellfleet.com (Ross Callon) Precedence: list To: Big-Internet@munnari.oz.au, kasten@ftp.com > 1. Is it reasonable to expect that the network might grow this > big in the next 20 years (expected IPng lifetime) or so? Or > could it easily be bigger? > > Frank > >One thing that I am somewhat uncomfortable with: Folks keep >talking about IPng as having to last somewhere between 20 >and 30 years. However, if IPng does last at least 20 years, >then it will be so widespread by then that it will be >impossible to ever change it. Imagine that most houses in In some sense you are right but it doesn't matter. IPv4 is so widespread it is impossible to make major changes. What does this mean? It means that I believe that at least 10 years from now and quite possibly 20 years from now there will be a viable global IPv4 network working away being useful. >the major industrialized nations (and perhaps most houses >in every nation) contain a network, and that light switches, >clocks, smoke detectors, and the plumbing is all networked. >Aren't there going to be so many low-end devices with very >long lifetimes installed that none of this will ever be >changed? I think it's silly to believe that the same protocol that's good for the global WAN is right for the diddlies low level devices. But that is irrelevant. Your agument could be used to prove that people will never change from vinyl records, that new and incompatible magnetic tape formats will never be adopted, that television can't change to HDTV, etc., etc. There will continue to be multiple protocols. Existing protocols will continue to evolve. New protocols will be created (wait till you see all the features in the 2010 version of OSI :-) ). ... >Now, it may be that our crystal ball is so cloudy that trying >to anticipate 20 years into the future is the same as trying >to anticipate 200 years into the future. However, I think that >we should at least admit that what we are doing either will >get discarded rather quickly, or will last essentially forever. I don't accept that those two outcomes are the only possibilities. I think what will be done will last a long time, evolve a little during that time, and probably be supplated or augmented by "new" protocols. >Ross Donald From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 08:29:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15268; Wed, 13 Jul 1994 08:29:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA00401; Wed, 13 Jul 1994 08:29:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00350; Wed, 13 Jul 1994 08:11:05 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12665; Wed, 13 Jul 1994 07:01:27 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA21162; Tue, 12 Jul 94 14:03:39 -0700 Date: Tue, 12 Jul 94 14:03:39 -0700 From: Eric Fleischman Message-Id: <9407122103.AA21162@atc.boeing.com> To: deering@parc.xerox.com, kasten@ftp.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: Big-Internet@munnari.OZ.AU >As I said in my previous message, there's no need for the structure to be >encoded as fixed-length fields with byte-aligned boundaries. There's >also no need to specify a fixed number of levels of hierarchy. CIDR >addresses are structured; different subtrees of the CIDR addressing >hierarchy are of different sizes and different depths. You can't draw a >nice picture of the CIDR address format, but it works, it supports scalable >routing, and it achieves much higher utilization than those address >hierarchies that do have nice pictures. Dear Steve, It may not be a requirement for the field to have byte aligned boundaries for the various addressing levels of hierachy. However, it is helpful for the poor network administrators if the fields are a) consistently assigned and b) aligned at least on nibble aligned boundaries (though bytes are easier, especially if we continue to use decimal notation for addressing). There also may not be a need to specify a fixed number of levels of hierarchy but it is very desirable if the theoretically permitted levels of hierarchy be "rather large". That is, I suspect that my corporation may need five levels of internal "addressing hierarchy" in addition to whatever levels are imposed by the world-wide addressing infrastructure. But what if I'm wrong? What if we really need 6 levels -- or 10 -- or 4? I believe that the cost of permitting too many levels of theoretical routing hierarchy is much less painful in the long run whan the cost of not permitting as many levels as are actually eventually needed. Finally, your appeal to CIDR in the above paragraph is somewhat of a red herring (whatever that means). That is, Class A, B, C-type addressing artificially grouped "network sizes" which infrequently mapped well into real users actual addressing needs. CIDR permits a more accurate fit. However, it preserved the original IPv4 mindset of a "network" which requires (in actual practice -- i.e., not necessarily in theory -- for a large corporation) several of such entities to actually encompass that corporation's enterprise network. For IPng we are talking about an entirely different idea in which the entire address space of a corporation will hopefully be taken from the same addressing space (i.e., a "network" scaling in size to include the entire enterprise network) -- or, at least, a corporation has the OPTION to do so. This, in turn, requires a great deal more addressing hierarchy than the current IPv4 system because it is dealing with potentially substantially larger entities of indefinite sizes. Furthermore, appeals to the IPv4 space to determine the actual needed levels of addressing hierarchy does not work because IPv4 does not really scale to meet the needs of our largest corporations today. For example, IPv4 today does not aggegate WITHIN the internal networks of very large corporations and thus it is an imperfect indicator of what will actually be needed in a working system in the future. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 09:04:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15086; Wed, 13 Jul 1994 08:24:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA00353; Wed, 13 Jul 1994 08:24:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00338; Wed, 13 Jul 1994 08:10:22 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12624; Wed, 13 Jul 1994 06:58:28 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id NAA13415; Tue, 12 Jul 1994 13:58:22 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA19490; Tue, 12 Jul 94 14:57:50 -0600 Date: Tue, 12 Jul 94 14:57:50 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407122057.AA19490@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: why not variable length? > From: jallard@microsoft.com (James 'J' Allard) > ... > that said, wouldn't variable length seem to be the most > flexible choice? if no one uses more than 16 bytes in the > next n years, well, they can call us paranoid. if we need > 'em, i'd rather have them. > ... Once again, flexibility that cannot be exercised in practice is nonsense. In practice, unless from the very beginning there is more than one address length in active use in the IPng network, most implementations will support only one length. Some implementations will have untested code intended to more or less handle other lengths, but it will not work should new lengths ever be used. If extensible protocols were easy and really practical, those of us who have shipped MTU discover, TCP-LW, TOS support, and TCP windows >=32768 would not have been burned so often by the 1000's of IPv4 hosts and routers that get at least one of those wrong. I hope no one will respond to this objection with ITU/IEEE/ANSI standard nonsense about compliance test suites. The interoperability experience of every protocol supposedly constrained by such certifications programs makes that stuff disgusting. The compliance program I've heard of that even slightly works is Novell's, and it works because it is significantly different from the implementation of all standard committee tests. For one thing, Novell is not required to let everyone implement their own test suites. I bet I'm not the only one who has had fun with customers who have read and misunderstood the standards and the conformance test standards, and then proceded to beat me about the head and shoulders with the bogus results of their bogus tests. For example, a major telecommunications outfit in North America has an Ethernet conformance test that requires vendors to increase the inter-packet gap with the stated goal of keeping the collision rate below 20%! "In theory there is no difference between theory and practice, but in practice there is." In theory, variable length fields work fine, are fast enough, and cause no problems. In practice, they are none of those. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 09:04:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16021; Wed, 13 Jul 1994 08:44:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA00456; Wed, 13 Jul 1994 08:44:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00415; Wed, 13 Jul 1994 08:34:23 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15588; Wed, 13 Jul 1994 08:34:12 +1000 (from barney@databus.databus.com) Date: Tue, 12 Jul 94 18:35 EDT Message-Id: <9407121836.AA06733@databus.databus.com> From: Barney Wolff To: "Peter S. Ford" Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Content-Length: 2124 Content-Type: text > From: "Peter S. Ford" > Date: Tue, 12 Jul 94 10:24:16 MST > > The experience in the IPv4 world is that administrators use byte boundaries, > even when they know how to use variable length subnet masks, CIDR, etc. > At present, address assignment is a human activity and whether we like it > or not, it inherits many of the limitations of wet-ware. I would love to > see better systems emerge to tackle this task, but betting the future > on undesigned, untested, undeployed technology is a bit disconcerting. It is a bit disconcerting to see simultaneous discussion on this list of 1e12 networks and human-administered networks. I am reminded of the early trend in the telephone operator population, which would have predicted that every human would be employed at that trade, before automatic exchanges were developed. To me, this just invalidates the byte-boundary argument. > Serverless autoconfiguration is well tested in the IPX > world and the administrators of those networks love it. I would > recommend using something like it as the base level for IPng > autoconfiguration (always steal proven good ideas!) and encourage > extending auto configuration in the future. Yes, and automatic renumbering, and so on. But as soon as we admit that, we can comfortably fit into 8 EID + 8 Locator. The trauma associated with a variable length scheme which is de-facto fixed for 10-20 years will be no less than changing the IP version number. Can we imagine how many implementations will as a practical matter never be tested with other than the common length? We'll be faced with the all-0's broadcast issue, multiplied by a million or so. It's not just the stacks, but every application program as well. How many socket applications are going to break badly, even after recompilation, when the size of struct sockaddr changes? That's what worries me - the stack folks will get it right, sooner or later, but we applications guys never will. In fact, one could simply use the version number as the address-length field, and save a few bits. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 09:18:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16788; Wed, 13 Jul 1994 09:04:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA00491; Wed, 13 Jul 1994 09:04:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00486; Wed, 13 Jul 1994 08:58:37 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16016; Wed, 13 Jul 1994 08:44:37 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Big-Internet@munnari.OZ.AU Subject: Apologies for duplicate messages Date: Wed, 13 Jul 1994 08:44:33 +1000 Message-Id: <27731.774053073@munnari.OZ.AU> Sender: kre@munnari.OZ.AU The host I run the B-I list from was driven into the ground by today's deluge of messages. It was overloaded so badly that it wasn't able to keep track of what was working and what wasn't - so ended up sending duplicates of some messages (sometimes several times). I have expanded its capabilities a bit in the hope that even larger deluges than today's won't do this to it again. kre From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 09:57:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16947; Wed, 13 Jul 1994 09:09:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA00510; Wed, 13 Jul 1994 09:09:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00472; Wed, 13 Jul 1994 08:55:00 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16370; Wed, 13 Jul 1994 08:54:55 +1000 (from yakov@watson.ibm.com) Message-Id: <9407122254.16370@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2507; Tue, 12 Jul 94 18:54:46 EDT Date: Tue, 12 Jul 94 18:50:44 EDT To: mo@uunet.uu.net Cc: big-internet@munnari.OZ.AU Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Tue, 12 Jul 1994 13:54:08 -0400 Mike, >Even if we were to specify variable length addresses, unless >they were really used aggressively and continuously (i.e., the length >really varied), you'd reach the time when VL is suppose to save us >and WHAMMO !!! I tend to agree with this statement. What I'd like to understand is what *in your opinion* are the factors that could prevent aggressive and continuous use of variable length addresses. Yakov. From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 10:04:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19527; Wed, 13 Jul 1994 10:04:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00612; Wed, 13 Jul 1994 10:04:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA00576; Wed, 13 Jul 1994 09:57:06 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17350; Wed, 13 Jul 1994 09:19:13 +1000 (from yakov@watson.ibm.com) Message-Id: <9407122319.17350@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2789; Tue, 12 Jul 94 19:19:15 EDT Date: Tue, 12 Jul 94 19:13:45 EDT To: vjs@rhyolite.denver.sgi.com, Big-Internet@munnari.OZ.AU Subject: why not variable length? Ref: Your note of Tue, 12 Jul 94 14:57:50 -0600 Vernon, >"In theory there is no difference between theory and practice, >but in practice there is." Let me apply this to the discussion on the achieveable address space utilization -- in theory you can reach 20% (or 50%) utilization, but in practice the number is significantly lower. The sample of the address space done by the IAB almost a year ago showed the average IP address space utilization of 0.19%. Yakov. From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 11:04:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22029; Wed, 13 Jul 1994 11:04:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA00737; Wed, 13 Jul 1994 11:04:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00732; Wed, 13 Jul 1994 11:00:54 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21864; Wed, 13 Jul 1994 11:00:48 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id VAA07201; Tue, 12 Jul 1994 21:00:45 -0400 Date: Tue, 12 Jul 1994 21:00:45 -0400 From: Vadim Antonov Message-Id: <199407130100.VAA07201@titan.sprintlink.net> To: Big-Internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com, yakov@watson.ibm.com Subject: Re: why not variable length? >Let me apply this to the discussion on the achieveable address space >utilization -- in theory you can reach 20% (or 50%) utilization, but >in practice the number is significantly lower. The sample >of the address space done by the IAB almost a year ago >showed the average IP address space utilization of 0.19%. Yeah -- and that's with the manual address allocation with all its inefficiences. 0.19% with 8 bytes is enough for anouther 100 years even given the unrealistic exponential model of growth, ok? Don't fix what is not broken. --vadim From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 11:23:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19660; Wed, 13 Jul 1994 10:10:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00636; Wed, 13 Jul 1994 10:10:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00595; Wed, 13 Jul 1994 10:00:39 +1000 Precedence: list Received: from olivea.atc.olivetti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19221; Wed, 13 Jul 1994 10:00:28 +1000 (from jerry@strobe.ATC.Olivetti.Com) Received: by olivea.ATC.Olivetti.Com (5.65/1.34) id AA10537; Tue, 12 Jul 94 16:58:21 -0700 Received: from strobe.ATC.Olivetti.Com by olivea.ATC.Olivetti.Com (4.1/SMI-4.1) id AA10534; Tue, 12 Jul 94 16:58:20 PDT Received: by strobe.ATC.Olivetti.Com (4.1/SMI-4.1) id AA28380; Tue, 12 Jul 94 16:58:19 PDT Date: Tue, 12 Jul 94 16:58:19 PDT From: jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) Message-Id: <9407122358.AA28380@strobe.ATC.Olivetti.Com> To: cmetz@thor.tjhsst.edu, skh@merit.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU > Right now, 16-byte addresses would offer us a measly >340,282,366,920,938,463,463,374,607,431,768,211,456 endpoint addresses in our >base space. Let's say that we only have a .0001% density (what do I hear for >IPv4? 20%? 10%?). We're down to 340,282,366,920,938,463,463,374,607,431,768. I have seen several postings promissing better address space utilization thru auto configuration and better routing protocols. Does anyone have figures on the current utilization? I would think that 10% is a joke in the sense of being too high. There was a posting a while back from a well known company justifying their use of a class A address because they had grown to a couple of hundred thousand hosts and would not have fit in a class B. This still put them at less than 1% utilization. One could make all these same efficiency arguments for the current IP address format. We currently have 32 bits or 4 billion addresses. I am sure the original designers thought that was plenty. If I didn't have to worry about class A, B, C, fixed subnet masks, and reserving a huge amount of space so I won't have to painfully renumber in case we need to grow, I could get by on a small fraction of my current address allocation. From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 11:23:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19905; Wed, 13 Jul 1994 10:14:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00659; Wed, 13 Jul 1994 10:14:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00609; Wed, 13 Jul 1994 10:03:52 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17809; Wed, 13 Jul 1994 09:29:37 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty11.jvnc.net. (franklin-tty11.jvnc.net) by tigger.jvnc.net with SMTP id AA21730 (5.65c/IDA-1.4.4 for big-internet@munnari.OZ.AU); Tue, 12 Jul 1994 19:29:20 -0400 Message-Id: Date: Tue, 12 Jul 94 19:28:19 EDT From: "David M. Piscitello" Subject: Re: why not variable length? Reply-To: dave@corecom.com To: "James 'J' Allard" , owner-Big-Internet@munnari.OZ.AU, skh@merit.edu Cc: big-internet@munnari.OZ.AU, J.Crowcroft@cs.ucl.ac.uk X-Mailer: VersaTerm Link v1.1.1 >| My problem is that I don't think we can accurately predict ANYTHING >| about network technology 30 years into the future. Therefore, >| the fact that we can't predict address usage patterns isn't >| particularly troubling - it's no worse than any other part of it. > >couldn't agree more with this statement. Add my vote, that makes three for variable length, and on this list, three frequently seems to be called a consensus :-) >that said, wouldn't variable length seem to be the most >flexible choice? if no one uses more than 16 bytes in the >next n years, well, they can call us paranoid. if we need >'em, i'd rather have them. agree again >i (again) vote for v.l. addresses, and think that we >should profile 16- (or 8-byte) assignments in the near >term. if all of the vendors fast path 16-, and it's enough >for 10 years, great, we're all running fast. when we need >17, the 10 year old systems work a little harder, but you >don't need to update the software on potentially >unsupported devices. in 10 years, the instruction count >for processing a vl address will be virtually nothing (i'd >argue that this is practically the case today). there seems to be a preoccupation with the notion that if you have variable length addresses, by definition this means "adding a byte or two when needed". I haven't seen anyone suggest this bandaid approach, and have seen at least 4 message suggest 64-bit increments >the only argument that i've heard against vl is that it's >harder to implement and a little slower. compare tcp/ip to >ipx/spx. ip is harder to implement and a little slower, but >guess what? there's a clear convergence away from ipx to ip >on the backbone in the world today. A while ago, someone sent me an email privately proposing that we bake off to see just how much difference there is between vl and fixed in performance. This used to be the metric for selecting things in the IETF; now we seek electronic consensus:-( >if users, administrators and vendors are willing to take >a minor performance hit today, why not tomorrow? the biggest >cost to users in ipng is upgrading software to make it work. >if you can imagine a day when n-byte addresses isn't enough, >you can probably imagine the cost to upgrade the systems >involved. I think the "performance hit" argument is sort of funny when I consider how many folks are listening in on lists such as these using tcp/ip on 286 machines, original MAC II's, a DEC microvax II (had one, loved it, so back off Jim:-) here and there. I bet lots of this equipment will still be running IPv4 ten years from now, since we haven't yet added anything to IPng that makes it worth the transition. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 11:23:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20075; Wed, 13 Jul 1994 10:19:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00678; Wed, 13 Jul 1994 10:19:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00606; Wed, 13 Jul 1994 10:03:38 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17455; Wed, 13 Jul 1994 09:23:18 +1000 (from kre@munnari.OZ.AU) To: Steve Deering Cc: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Mon, 11 Jul 1994 19:11:13 PDT." <94Jul11.191121pdt.12171@skylark.parc.xerox.com> Date: Wed, 13 Jul 1994 09:23:16 +1000 Message-Id: <27743.774055396@munnari.OZ.AU> From: Robert Elz There are disadvantages to arriving in the morning and finding about 70 or 80 new B-I messages. There are also advantages, its almost certain that someone will have said everything that I would have wanted to say, so I get less typing to do ... Date: Mon, 11 Jul 1994 19:11:13 PDT From: Steve Deering Message-ID: <94Jul11.191121pdt.12171@skylark.parc.xerox.com> (1) I consider 10^15 to be a *very* conservative scaling goal for the number of *globally-reachable* IPng devices. I agree with that. If the 10^10 population estimate is right, that means 10^5 hosts per person. Now I can imagine maybe having of the order of 10^3 hosts under my responsibility related to my work, perhaps even 10^4 - I can also imagine another 10^3 hosts at home, though those will probably be shared amongst a few people (but lets ignore that). A few multiples of 10^2 in my car, clothing, and associated random oddments and I'm still nowhere near 10^5, yet I've just about exhausted everything I can think of. Note that I don't need to count the street lights, road signs, train stations, plane seats, ... as those things all get counted in some other person's work allocation. (2) I assume that we could achieve the .0001 address space utilization required to accommodate 10^15 devices in a 64-bit (approx. 10^19) address space Here I disagree. .0001 is pretty densely packed, and while it might be possible to achieve this, I really wouldn't want to rely upon it. On the other hand, in a 128 bit field we could achieve it easily. Even if we do 8+8 with an EID in the low 8, that EID can be used for final hop routing (via ARP, ES-IS, or something of that nature), which with the assumptions given in the numbering gives us either 2 or 3 orders of magnitude less things to number in the top 8 bits. Achieving .000001 density certainly should be possible. (3) I assume that it is neither necessary nor desirable to specify the addressing hierarchy as one with fixed-width fields in the address, aligned on byte boundaries. Here I disagree too, its not "neither necessary nor desireable" rather it would be downright folly to make any such requirement. Those people wanting some fixed boundaries, especially those wanting some kind of alignment are clearly imagining that humans are going to continue to be dealing with IPng addresses in some numeric form. That only just barely works with 4 byte IPv4 addresses, with 8 byte addresses it would be close to impossible, with 16 or 20 byte addresses much beyond impossible. We simply have to have tools for dealing with addresses this long that completely hide the numbers, no matter how they are represented. Once we have tools like that, the alignments of fields become totally irrelevant, as do the number of levels, etc. kre From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 11:23:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22233; Wed, 13 Jul 1994 11:09:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA00752; Wed, 13 Jul 1994 11:09:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00718; Wed, 13 Jul 1994 10:52:17 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21509; Wed, 13 Jul 1994 10:52:09 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id RAA21586; Tue, 12 Jul 1994 17:52:00 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA20442; Tue, 12 Jul 94 18:51:27 -0600 Date: Tue, 12 Jul 94 18:51:27 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407130051.AA20442@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: ericf@atc.boeing.com (Eric Fleischman) > ... > It may not be a requirement for the field to have byte aligned boundaries > for the various addressing levels of hierachy. However, it is helpful for > the poor network administrators if the fields are a) consistently assigned > and b) aligned at least on nibble aligned boundaries (though bytes are > easier, especially if we continue to use decimal notation for addressing). > ... It's an unfortunate fact of life that those same "poor network administrators" will be unable to handle 16-byte addresses regardless of whether or not the hierarchy boundaries are on byte boundaries. In practice, most current network administrators can barely manage to handle 2 or 3 layers of IPv4 addresses, and do not know the difference between the terms "network" and "subnet". (That is not an insult, but a simple statement of fact based on my years dealing with uncounted official network administrators.) It is a red herring or worse to assert that since it would be difficult for a random person typing by telnet to a random router to handle non-byte aligned boundaries in 16-byte addresses that therefore addresses must be broken up on byte boundaries. Consider this 16-byte address: 192.26.92.75.72.96.180.125.135.66.32.69.237.59.250.195 Who can honestly say that such a monster would be any better or worse if whatever structure inside it is on byte boundaries? No one! Quick--without counting, if the bottom 6-bytes of that address contain an IEEE address, is it a locally administrated address? These monsters cannot and will not be handled by humans! The amount of structure that people are talking about putting into those 16-byte strings is too much for people to handle in any plausible set of circumstances. Quick--without counting, how many layers of management are there in Boeing? People are far more directly affected and concerned with how many bosses are above them than they will ever care about by IPng hierarchies. People simply cannot and will not handle a vastly deep IPng hierarchy. The hierarchy might be that deep, but it will not be thought of that way by humans. The only things that will worry about almost all levels of deep IPng hierarchies will be computers, and they don't care about more than a few of the byte boundaries in 16 bytes. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 11:44:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23584; Wed, 13 Jul 1994 11:44:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA00810; Wed, 13 Jul 1994 11:44:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00796; Wed, 13 Jul 1994 11:35:14 +1000 Precedence: list Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23232; Wed, 13 Jul 1994 11:35:04 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.4); Wed, 13 Jul 1994 10:34:52 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id KAA29105; Wed, 13 Jul 1994 10:34:52 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA21910; Wed, 13 Jul 94 10:34:53 JST Date: Wed, 13 Jul 94 10:34:53 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9407130134.AA21910@cactus.slab.ntt.jp> To: Big-Internet@munnari.OZ.AU Subject: New Concensus Gauge: Either will work I would like to see if the focus of the existing debate can't be changed. I think we've pretty much exhausted the debate of what is better, fixed or variable. There are two camps, both I think understand the reasons of the other camp, and it is unlikely that many people are going to change camps. In other words, the current debate is at a standstill. I would like to see the focus changed from "what is better" to "will either of them not work". The reason for this focus is that I would like to establish the fact that we are really in a win-win situation here. Both solutions will work, for some definition of work. Given that we can't get concensus on "what is better", let's at least get concensus on "both will work". If we do that, then no matter what Scott and Allison recommend, we as a community will be able to move forward on a single protocol design. While I prefer fixed over variable, the most important thing is that we choose one of them and move forward. In the spirit of getting this concensus, I think that the protocols should be considered "innocent until proven guilty". In other words, the onus should be on the detractors of a scheme to "prove" that it will fail. Comments? PF From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 11:49:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23680; Wed, 13 Jul 1994 11:49:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA00829; Wed, 13 Jul 1994 11:48:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00793; Wed, 13 Jul 1994 11:28:21 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20031; Wed, 13 Jul 1994 10:17:55 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id RAA17222; Tue, 12 Jul 1994 17:17:46 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA20252; Tue, 12 Jul 94 18:15:12 -0600 Date: Tue, 12 Jul 94 18:15:12 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407130015.AA20252@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: why not variable length? > From: yakov@watson.ibm.com > Ref: Your note of Tue, 12 Jul 94 14:57:50 -0600 > > Vernon, > >"In theory there is no difference between theory and practice, > >but in practice there is." > > Let me apply this to the discussion on the achieveable address space > utilization -- in theory you can reach 20% (or 50%) utilization, but > in practice the number is significantly lower. The sample > of the address space done by the IAB almost a year ago > showed the average IP address space utilization of 0.19%. The most recent number I've seen is Steve Deering's 0.01%. Who has seriously suggested that any of 0.19%, 20%, or 50% utilization is in practice achieveable for IPng? What is the relevance of any of those numbers? I don't see who 0.19% can be in the same units as 20% or 50%. A per-level efficiency of 0.19% puts .5 hosts on each class-C and 125 on each class-B. Who is claiming a 50% overall utilization in the current Internet? Oh, well, I'll play the silly game too. Utilization can be modeled as a function of the form U(E,H)=E**H, where E=utilization at every individual hierarchy, and H=number of hierarchies. Thus, given a positive number R and a utilization E less than 100%, there exists a number of hierachies H such that U(E,H) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA00908; Wed, 13 Jul 1994 13:04:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA00903; Wed, 13 Jul 1994 13:01:32 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26811; Wed, 13 Jul 1994 13:01:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28911; Tue, 12 Jul 94 23:01:25 -0400 Date: Tue, 12 Jul 94 23:01:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407130301.AA28911@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, jerry@strobe.atc.olivetti.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: jerry@strobe.atc.olivetti.com (Jerry Aguirre) We currently have 32 bits or 4 billion addresses. I am sure the original designers thought that was plenty. Excuse me while I smile! My guess is that the original designers, back in the mid-70's when they put this beast together (a few years prior to my arrival in '77), by and large thought they were doing an large-scale experiment; i.e. a few hundred hosts, or about the size of the old ARPAnet. Remember, the original IP address format had 256 network numbers; the class A/B/C stuff was in itself a relatively *late* kludge, post '80, and subnets are even late than that. The Xerox Altos only date from the mid-70's, and before that it was all timesharing; millions of workstations weren't even a gleam in Jobs'/Gates'/etc eyes back then. Etc, etc. Certainly, when I joined the IP effort back then, if you'd told us that within 20 years the Internet would be the practical basis of the worldwide data network, and you'd be able to send email to the NBC Nightly News, we'd have rolled on the floor laughing, wondering what drugs (or neuro-transmitter disorder :-) you were on. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 14:24:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29919; Wed, 13 Jul 1994 14:24:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01059; Wed, 13 Jul 1994 14:24:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01051; Wed, 13 Jul 1994 14:18:29 +1000 Precedence: list Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29773; Wed, 13 Jul 1994 14:18:25 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.9/8.6.4) with SMTP id WAA14983; Tue, 12 Jul 1994 22:16:56 -0600 From: "Peter S. Ford" Message-Id: <199407130416.WAA14983@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: Big-Internet@munnari.OZ.AU Subject: Re: New Concensus Gauge: Either will work In-Reply-To: Your message of Wed, 13 Jul 94 10:34:53 +0200. <9407130134.AA21910@cactus.slab.ntt.jp> Date: Tue, 12 Jul 94 22:16:56 MST Paul, I think it is a good idea to work towards figuring out how to make a good choice. We should give your approach a try. To this end we should define "will work". I would interpret this as: we get a list of requirements down for what IPng addresses need to do. Would you agree to collect a list of these requirements into a single list and ship to the list. Each "camp" can perform a quick evaluation (pros and cons) and then ship it to the list. Let's say we get the req list done by thurs/fri this week and the evaluations shipped to B-I by middle of next week. yours, From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 14:31:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00393; Wed, 13 Jul 1994 14:31:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01085; Wed, 13 Jul 1994 14:30:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01054; Wed, 13 Jul 1994 14:20:40 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29811; Wed, 13 Jul 1994 14:20:18 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Jul 94 13:11:44 +0900 From: Masataka Ohta Message-Id: <9407130411.AA09702@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: avg@sprint.net (Vadim Antonov) Date: Wed, 13 Jul 94 13:11:43 JST Cc: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU In-Reply-To: <199407121535.LAA04021@titan.sprintlink.net>; from "Vadim Antonov" at Jul 12, 94 11:35 am X-Mailer: ELM [version 2.3 PL11] > Actually, why EIDs should be the part of the header? For provider-independent identification of hosts. > Sounds like > an awful waste of space. Because it's much better than putting DNS hostnames in the header. > (And DON'T tell me that "links are fast, CPUs are faster" If so, put DNS hostnames. > As it is EIDs are the relics of unwillingness to recognize > DNS as a part of transport layer (instead of application layer > as it is now, which is a serious misdesign itself). It seems to me that you confuse "application layer" and "application program". You also confuse "DNS name" and "hostname". While a DNS name with A record is an internetwork layer hostname, a DNS name with MX is a transport layer MTA name. > I would also add that any flat global addressing (which > waht EIDs are) is highly suspicious Agreed (which what EIDs are not). Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 15:16:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27643; Wed, 13 Jul 1994 13:24:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA00952; Wed, 13 Jul 1994 13:24:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA00940; Wed, 13 Jul 1994 13:15:35 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25394; Wed, 13 Jul 1994 12:29:47 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA04720; Tue, 12 Jul 94 19:32:00 -0700 Date: Tue, 12 Jul 94 19:32:00 -0700 From: Eric Fleischman Message-Id: <9407130232.AA04720@atc.boeing.com> To: Big-Internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > Consider this 16-byte address: > 192.26.92.75.72.96.180.125.135.66.32.69.237.59.250.195 > Who can honestly say that such a monster would be any better or > worse if whatever structure inside it is on byte boundaries? No one! > Quick--without counting, if the bottom 6-bytes of that address > contain an IEEE address, is it a locally administrated address? > These monsters cannot and will not be handled by humans! Dear Vernon, Unfortunately, IPv4 addresses -- which are admittedly less monstrous but still rather reptilian -- are indeed routinely being handled by humans. Unless IPng's autoaddressing scheme is as smooth as XNS', I find little comfort in your statements. That is, of course you are correct that humans shouldn't ever have to handle these addresses -- or even know what they are. But such a statement should have been true for IPv4 as well. [Note the subjective mode of the verb.] Since it isn't, why should anyone believe that IPng will be any different? Sincerely yours, --Eric Fleischman P.S. The number of layers of Boeing management fortunately has nothing to do with the numbers of layers needed for Boeing's addressing hierarchy. However, it was a witty statement of yours but certainly a "red herring". BTW: Thanks, Peter, for sending me a definition of the term "red herring". From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 15:22:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27745; Wed, 13 Jul 1994 13:29:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA00982; Wed, 13 Jul 1994 13:29:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA00949; Wed, 13 Jul 1994 13:19:42 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26155; Wed, 13 Jul 1994 12:46:58 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Jul 94 11:40:34 +0900 From: Masataka Ohta Message-Id: <9407130240.AA09094@necom830.cc.titech.ac.jp> Subject: Re: Thoughts on EIDs To: big-internet@munnari.OZ.AU Date: Wed, 13 Jul 94 11:40:32 JST X-Mailer: ELM [version 2.3 PL11] > From: "Robert G. Moskowitz" <0003858921@mcimail.com> > But whenever I try to think of EID as tied to the process, I get tied in > knots! I look at my Comer V 2 drawing of the IP and TCP state machines and > say that then EID is a part of the TCP machine. But when I look at the > normal case of EID to the image, then EID is a part of the IP machine! Until this month, I have never seen anyone claiming IPv4 address is at transport. What a confusion. You are confusing "TCP" and "TCP state machine". "TCP" is at the top of "TCP state machine", that is, at the transport layer. On the other hand "TCP state machine" is a mechanism to construct TCP from IP. It is located *BETWEEN* IP and TCP, that is, between the internetwork and the transport layers. Thus, "IP" and "IP address" are at the bottom of "TCP state machine", that is, at the internetwork layer. So, you can see IP addresses in "TCP state machine", of course. To illustrate: :Protocol Layer Connected by Identified by :----------------------------------------------------------------------- : :TCP Transport (Net ID,protocol,port) : :-------------------------------TCP state machine----------------------- : :IP Internetwork IP address, EID, Locator : :-------------------------------IP state machine------------------------ : :Ether Link MAC addresses So, your observation that IP address belongs both to IP and TCP state machine is another proof of the already obvious fact that IP addresses, EID and locator are at the internetwork layer. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 15:24:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02515; Wed, 13 Jul 1994 15:24:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01193; Wed, 13 Jul 1994 15:24:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01181; Wed, 13 Jul 1994 15:14:33 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28975; Wed, 13 Jul 1994 14:01:02 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Jul 94 12:53:34 +0900 From: Masataka Ohta Message-Id: <9407130353.AA09623@necom830.cc.titech.ac.jp> Subject: Re: Where and When is the EID needed? To: bsimpson@morningstar.com Date: Wed, 13 Jul 94 12:53:33 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <2816.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Jul 12, 94 7:30 pm X-Mailer: ELM [version 2.3 PL11] > The Mobile Node can register multiple locations, and the Home Agent > merely duplicates IP packets for all of the locations. Very important > on cellular provider boundaries. > > No retransmission required. If the mobile recieves all of them, IP > handles duplicate packets gracefully. > > But we still need only ONE "Home-Address" (think Identifier cum EID). No, you don't have to. Though the current proposal does not support it, a mobile host may have multiple A records representing multiple homes. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 15:34:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28075; Wed, 13 Jul 1994 13:35:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA00997; Wed, 13 Jul 1994 13:34:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA00922; Wed, 13 Jul 1994 13:07:44 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27048; Wed, 13 Jul 1994 13:07:23 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id UAA07332; Tue, 12 Jul 1994 20:07:08 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA20844; Tue, 12 Jul 94 21:06:37 -0600 Date: Tue, 12 Jul 94 21:06:37 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407130306.AA20844@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: Eric Fleischman > To: Big-Internet@munnari.OZ.AU, vjs > Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > > > Consider this 16-byte address: > > > 192.26.92.75.72.96.180.125.135.66.32.69.237.59.250.195 > > > Who can honestly say that such a monster would be any better or > > worse if whatever structure inside it is on byte boundaries? No one! > > > Quick--without counting, if the bottom 6-bytes of that address > > contain an IEEE address, is it a locally administrated address? > > > These monsters cannot and will not be handled by humans! > > Dear Vernon, > > Unfortunately, IPv4 addresses -- which are admittedly less monstrous > but still rather reptilian -- are indeed routinely being handled by > humans. Of course. As I recently wrote, IPv4 addresses are small enough so that people can and do handle them. > Unless IPng's autoaddressing scheme is as smooth as XNS', I find > little comfort in your statements. That is, of course you are correct > that humans shouldn't ever have to handle these addresses -- or even know > what they are. But such a statement should have been true for IPv4 as > well. [Note the subjective mode of the verb.] Since it isn't, why should > anyone believe that IPng will be any different? 4-Byte strings are a pain, and it can be reasonably argued that they are not too hard to handle. As I have pointed out, the fact that no one has bothered to implement and use interfaces to hide IPv4 addresses (other than DNS) is good evidence that 4-byte strings are not hard to handle. 4-byte strings involve around half-a-dozen items, typical four decimal numbers. Many, perhaps most people have little trouble handling such four-tuples. 16-byte strings are different in kind. As shown by countless measurement, of humans, humans can handle about a half dozen unrelated things with their short term memories. More than that is not just hard, but impossible or impractical. It does not matter whether or not IPng has a fancy autoaddressing scheme. The conclusion remains that people will not handle 16-byte addresses because they cannot. Any argument that starts or ends by saying that people will do anything directly with 16-byte addresses is bogus. Any set of assumptions that lead to the conclusion that people will need to deal directly with 16-byte addresses is a bogus set of assumptions by 'reducto ad adsurdum'. > P.S. The number of layers of Boeing management fortunately has nothing to > do with the numbers of layers needed for Boeing's addressing hierarchy. > However, it was a witty statement of yours but certainly a "red herring". > ... Wrong! The number of layers of Boeing management is not relevant, but the fact that practically no Boeing employees know how many layers there are (as in any big company) is relevant. People in small companies, where there are only 3-4 layers, know how many layers there are. People in big companies (including SGI) cannot keep the layers straight and must count them every time the subject comes up. The same applies to IP addresses. As long as there are 2-4 layers, people know them and sometimes keep them straight. If IPng has 10 or 12 layers, then no one, not even those who set up or define the layers will know them or keep them straight without resorting to scorecards. The relevance of that fact is that all conclusions based on the assumption that people will know or keep track of 10 layers of IPng address are bogus. Any set of assumptions that imply that people will handle 10 layers of hierarchies (including what I understand of of Boeing's plans) is bogus, because people will not handle them, because they cannot. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 15:42:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00925; Wed, 13 Jul 1994 14:44:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01117; Wed, 13 Jul 1994 14:44:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01099; Wed, 13 Jul 1994 14:34:10 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00489; Wed, 13 Jul 1994 14:33:47 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Jul 94 13:21:45 +0859 From: Masataka Ohta Message-Id: <9407130422.AA09763@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Jul 94 13:21:44 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9407121556.AA24962@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jul 12, 94 11:56 am X-Mailer: ELM [version 2.3 PL11] > > There's going to be more and more information needed to forward packets, > > and as a matter of efficient we won't i) ship it all around in every > > packet > > If you need access authorization, or billing tracing (I know, we all hate > this, but it may happen) to get packets through, I believe providers without free (included in basic charge) best effort service will lose the competition in the free market. > Second, everyone keep assuming that if the state in the routers is gone, we > have to be able to do something useful with the packets. Wrong! Just drop them > on the floor. I don't want my AV session jammed so frequently only because a better route is found but a routing setup packet is passed by data packets. > > The hitch here is that it has to be done in a way which keeps the > > location independence of EID's. > > Of course, EID should be provider independent. But as I already wrote, > it is not so harmful if EID reflects local location information. > > Any time an invariant name includes topologically sensitive information, you > have to work extra hard when the topololgy information in the name is wrong. But it is local work. > Me, I like simple designs: one name to do one simple thing well, and another > to do something else. No Colin Chapman kludges for me! Sometimes, we avoiding some complexity results in a lot worse complexity. In this case, I think overloading is better than variable length addresses. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 15:43:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03134; Wed, 13 Jul 1994 15:43:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01268; Wed, 13 Jul 1994 15:42:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01190; Wed, 13 Jul 1994 15:23:43 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28939; Wed, 13 Jul 1994 13:59:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29301; Tue, 12 Jul 94 23:59:23 -0400 Date: Tue, 12 Jul 94 23:59:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407130359.AA29301@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) The conclusion remains that people will not handle 16-byte addresses because they cannot. ... Any set of assumptions that lead to the conclusion that people will need to deal directly with 16-byte addresses is a bogus set of assumptions by 'reducto ad adsurdum'. Yes. We aren't going to be typing in 16-byte quantities. However, we probably will be handling the list of labels *at a given layer* manually, though. An existing example is the list of assigned subnet numbers within a given site. The exact implications of this for the kind of bit-packed representations most people seem to be thinking of for use with fixed-length addresses aren't too clear, but I expect a simple representation would probably be more useful. If IPng has 10 or 12 layers, then no one, not even those who set up or define the layers will know them or keep them straight without resorting to scorecards. Not if they are stored in bit-packet form, no. The relevance of that fact is that all conclusions based on the assumption that people will know or keep track of 10 layers of IPng address are bogus. Any set of assumptions that imply that people will handle 10 layers of hierarchies ... is bogus, because people will not handle them, because they cannot. Really? People seem to be able to handle quite a few layers of hierarchy in Unix file systems without blowing out. The principle is just the same; it's a way of organizing lots and lots of stuff. Of course, Unix file names are a little more user-friendly than sequences of numeric labels, which is what hierarchical addresses are. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 15:44:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01741; Wed, 13 Jul 1994 15:04:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01149; Wed, 13 Jul 1994 15:04:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01146; Wed, 13 Jul 1994 14:59:32 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27338; Wed, 13 Jul 1994 13:17:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29016; Tue, 12 Jul 94 23:15:40 -0400 Date: Tue, 12 Jul 94 23:15:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407130315.AA29016@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mo@uunet.uu.net Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: "Mike O'Dell" I don't believe having variable length address available will solve the kind of dislocation which one should expect in 30 years of technology evolution ... In general, I think it is NUTS to actually believe that any decision we make now is going to be "right" 30 years from now without significant revision. ... it's hard to imagine that simply being able to increase the address size alone will keep IPng viable for 20 or 30 years - in that timeframe, SOMETHING else about the protocol will need to change and almost certainly significantly. IP was initially done in the mid-70's. It's now basically 20 years later, and if IPv4 had longer addresses, do you think there would be any significant pressure to change it? What make you so sure that a 30-year lifetime is infeasible? Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 15:44:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03327; Wed, 13 Jul 1994 15:44:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01284; Wed, 13 Jul 1994 15:44:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01184; Wed, 13 Jul 1994 15:14:58 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02027; Wed, 13 Jul 1994 15:14:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29448; Wed, 13 Jul 94 01:14:49 -0400 Date: Wed, 13 Jul 94 01:14:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407130514.AA29448@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Whither IPng? Cc: jnc@ginger.lcs.mit.edu Q: What's the diffence between getting in a debate on Big-I, and getting thrown in a rotating cement mixer? A: Things happen more slowly in the cement mixer. I've been musing about all the goings-on, and it seems to me that there are two broad classes of possible outcomes of Toronto. First, as a final culmination to all the back-and-forth on Big-I over the years (which has led to increased understanding, and some new ideas, although not agreement), we could all get stuffed in a room, and come to some rough agreement on what to do. It won't make anyone happy, but it'll be broadly accepted. (A variant of this is that the IPng AD's pick something; the bottom line in all of them is that we have one thing.) Second, we could split into two groups, with fundamentally different goals; the "improvers" and the "radicals" (and I tried to pick non-judgemental names). There is an analogy here. When the ARPAnet work was done, some people went off to build X.25 as a modest increment on that technology. Other people went off to take the radical next step, TCP/IP. It's not clear to me that either of these two groups was "wrong". X.25 was very sucessful, and provided data service for many, many users. TCP/IP probably could not have been developed to provide the same service in the same timeframe anyway. Of course, X.25 is an evolutionary dead end, technically, and these uses now face the costs of converting. Much as it would be nice to avoid this cost, it's not clear that there was any way to avoid having the two separate paths, though. Perhaps we are now in the same situation again. We may simply have to accept that, previous decisions notwithstanding, there is no single design that we can pick that will meet with the usual degree of consensus, and perhaps it's time to part ways. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 16:44:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05487; Wed, 13 Jul 1994 16:44:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01381; Wed, 13 Jul 1994 16:44:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01362; Wed, 13 Jul 1994 16:32:33 +1000 Precedence: list Received: from netcom7.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04956; Wed, 13 Jul 1994 16:32:28 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id XAA14779; Tue, 12 Jul 1994 23:32:46 -0700 Date: Tue, 12 Jul 1994 23:32:46 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407130632.XAA14779@netcom7.netcom.com> To: Big-Internet@munnari.OZ.AU Subject: Re: New Concensus Gauge: Either will work >In the spirit of getting this concensus, I think that >the protocols should be considered "innocent until >proven guilty". In other words, the onus should be >on the detractors of a scheme to "prove" that it will >fail. > >Comments? > >PF Given this statement I would like to know why 8 byte addresses were proven to fail, as you put it. What in the goals of IPng or implementation suggests that 8 will fail? It seems that this should be explored before we move to an even bigger addressing scheme. -rich From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 16:51:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05830; Wed, 13 Jul 1994 16:51:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01396; Wed, 13 Jul 1994 16:51:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01359; Wed, 13 Jul 1994 16:28:36 +1000 Precedence: list Received: from netcom7.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04845; Wed, 13 Jul 1994 16:28:28 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id XAA14433; Tue, 12 Jul 1994 23:28:41 -0700 Date: Tue, 12 Jul 1994 23:28:41 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407130628.XAA14433@netcom7.netcom.com> To: Big-Internet@munnari.OZ.AU Subject: Re: why not variable length? >0.19% with 8 bytes is enough for anouther 100 years even >given the unrealistic exponential model of growth, ok? > >Don't fix what is not broken. > >--vadim I agree with this statement as well. I have no problem in going from 8 bytes to 16 bytes if it can proved that 8 bytes is not enough. Thus far I have not heard any really compelling arguments. In fact, it seems that the problem with 8 bytes that I have heard is auto-configuration. However, since this is an area that seems to have many open ended issues, I find it hard to architect an address encoding for it. Also, it seems that it is easier to encode with 16 bytes but with a little thought I think it can be done with 8 bytes as well. I guess the other problem with 8 bytes that I have heard is space utilization. It seems that we should fix this problem and not just the symptom. One of the original goals of IPng was to go from 4 to 8 bytes. Why have we suddenly changed goals (or at least contemplating change)? Shouldn't we first get our original goals implemented and tested before we decide that we need more? With the extra 4 bytes of addressing I think we will extend the life of IP beyond the usuability of the protocol. To think that what we are going to do is to never change again may be too optimistic and too comprising. From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 17:05:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02667; Wed, 13 Jul 1994 15:31:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01223; Wed, 13 Jul 1994 15:31:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01187; Wed, 13 Jul 1994 15:16:32 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28330; Wed, 13 Jul 1994 13:42:48 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Jul 94 12:33:21 +0900 From: Masataka Ohta Message-Id: <9407130333.AA09480@necom830.cc.titech.ac.jp> Subject: Re: Source Routing & Provider Selection To: daniel@ISI.EDU Date: Wed, 13 Jul 94 12:33:19 JST Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <9407112322.AA07575@dza.isi.edu>; from "daniel@ISI.EDU" at Jul 11, 94 4:22 pm X-Mailer: ELM [version 2.3 PL11] > (Relevant to your earlier discussion with Deborah --- Once the route and > reservation are established, data packets can use a flow ID to access > the preferred route. Data packets don't carry the source route.) OK. Though we may be able to continue the discussion forever, I think we don't have to do it here in big-I if we can agree: Data packets don't carry the source route. Special control packets may carry source route not in their header but in their data portion. IPng header may support source routing, but it is not a requirement. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 17:24:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07102; Wed, 13 Jul 1994 17:24:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01482; Wed, 13 Jul 1994 17:24:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01477; Wed, 13 Jul 1994 17:23:19 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06942; Wed, 13 Jul 1994 17:23:10 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22526; Wed, 13 Jul 1994 09:23:23 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20868; Wed, 13 Jul 1994 09:23:04 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407130723.AA20868@dxcoms.cern.ch> Subject: Re: why not variable length? To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 13 Jul 1994 09:23:04 +0200 (MET DST) In-Reply-To: <199407130628.XAA14433@netcom7.netcom.com> from "Richard Fox" at Jul 12, 94 11:28:41 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 250 >--------- Text sent by Richard Fox follows: ... > One of the original goals of IPng was to go from 4 to 8 bytes. Bogus! It was to go to a big enough address space to support the future Internet. We are arguing about how big is big enough. Brian From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 18:09:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02924; Wed, 13 Jul 1994 15:37:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01238; Wed, 13 Jul 1994 15:37:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01178; Wed, 13 Jul 1994 15:11:48 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27914; Wed, 13 Jul 1994 13:30:49 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Jul 94 12:21:30 +0900 From: Masataka Ohta Message-Id: <9407130321.AA09395@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: deering@parc.xerox.com (Steve Deering) Date: Wed, 13 Jul 94 12:21:28 JST Cc: kasten@ftp.com, deering@parc.xerox.com, Big-Internet@munnari.OZ.AU In-Reply-To: <94Jul12.110901pdt.12171@skylark.parc.xerox.com>; from "Steve Deering" at Jul 12, 94 11:08 am X-Mailer: ELM [version 2.3 PL11] > > Ok. Try number 2 :-) > > > > Would it be fair to say that the heart of the disagreement is in the > > number of hierarchical levels that will be needed and the amount of > > aggregation at each level? It seems that you believe that we will > > have relatively few levels with a fairly high amount of aggregating > > at each level, while I believe that we may have lots of levels with > > relatively little aggregation at each level. > > Yes, that's a reasonable characterization of my position and, presumably, > your position. Though I think fewer levels are better both for locators and EIDs. But... > > Of secondary importance (to me) is that we should keep field > > boundaries on byte-borders, while you think that this is not what we > > should do, yes? > > Yes, it's not what we should do. If we need fewer levels, why do we need byte-unaligned boudaries? Isn't 8 bytes are enough for a few levels? As I wrote about a month ago, byte-unaligned encourages deeper hierarchy and no good for dense allocation. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 18:32:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06033; Wed, 13 Jul 1994 16:57:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01429; Wed, 13 Jul 1994 16:57:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01365; Wed, 13 Jul 1994 16:38:00 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05148; Wed, 13 Jul 1994 16:37:52 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16725; Wed, 13 Jul 1994 08:38:06 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19415; Wed, 13 Jul 1994 08:37:47 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407130637.AA19415@dxcoms.cern.ch> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 13 Jul 1994 08:37:47 +0200 (MET DST) In-Reply-To: <9407122034.AA19371@rhyolite.denver.sgi.com> from "Vernon Schryver" at Jul 12, 94 02:34:37 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1558 Vern, > > That's the crux of the disagreement on the necessary size of the IPng > address. People seem to have the idea that: > > 1. all IPng hosts must be the same depth in the hierarchy. > 2. all branches of the IPng hierarchy at a given depth in the > hierarchy have the same number of bits. > 3. that single, simple symmetric tree of an hierarchy is coded > into all routers and hosts. > 4. the fixed fields in that hierarchy are integral numbers of > bytes long. > > 5. as a consequence of (1)-(4), the length of the IPng address > field must be variable. > > I do not understand why people seem to be stuck on (1)-(4). Are they? It's news to me. (1) is clearly false. > Do people > believe (1)-(4) were characteristics of IPv4, even before CIDR? Have > people read "class-{A,B,C}" so many times they have worn grooves in > their brains? > > I certainly do not understand how (1)-(4) suggest (5). They don't. (2)-(4) do. > > Just because 4.*BSD is full of functions that compute netmasks in the > familiar, simplistic, inflexible, justly maligned way does not mean > that IPng must be similarly restricted to 5, 7, or however many fixed > hierarchies. > > Why must all routers, not to mention all hosts, understand or even know > about the structure of the entire hierarchy? What's wrong with the > equivalent of variable subnet masks? What's wrong with CIDR? > What's wrong with CIDR is the need for CIDR masks in order to interpret IPv4 addresses. This is extra state to manage which is a BAD THING. Brian From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 18:34:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03932; Wed, 13 Jul 1994 16:04:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01318; Wed, 13 Jul 1994 16:04:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01298; Wed, 13 Jul 1994 15:46:36 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01403; Wed, 13 Jul 1994 14:56:13 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.oz.au> id VAA16385; Tue, 12 Jul 1994 21:56:06 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.oz.au id AA21178; Tue, 12 Jul 94 22:55:36 -0600 Date: Tue, 12 Jul 94 22:55:36 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407130455.AA21178@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) > The conclusion remains that people will not handle 16-byte addresses > because they cannot. ... Any set of assumptions that lead to the > conclusion that people will need to deal directly with 16-byte addresses > is a bogus set of assumptions by 'reducto ad adsurdum'. > > Yes. We aren't going to be typing in 16-byte quantities. Does that mean you agree that following the recently stated criterion, any scheme that requires or assumes that people will have to deal directly with 16-byte addresses "cannot work"? > However, we probably will be handling the list of labels *at a given layer* > manually, though. An existing example is the list of assigned subnet numbers > within a given site. The exact implications of this for the kind of > bit-packed representations most people seem to be thinking of for use with > fixed-length addresses aren't too clear, but I expect a simple representation > would probably be more useful. If you suppress all of the remote detail, so that any individual human deals with only 3 or 4 nearby layers, then 10 or 100 layers might work. I mean that the operator of a router 6 levels down might be expected to handle a levels 4 through 8. At any given point in the hierarchy, the entire hierarchy can be, must be, and will be treated as if it were at least as simple as the current Internet. Any argument that assumes or concludes otherwise is bogus. (This seems painfully obvious to me.) > If IPng has 10 or 12 layers, then no one, not even those who set up or > define the layers will know them or keep them straight without resorting > to scorecards. > > Not if they are stored in bit-packet form, no. In what other forms will people be able to handle all 10 or 12 layers? I claim none. > The relevance of that fact is that all conclusions based on the assumption > that people will know or keep track of 10 layers of IPng address are bogus. > Any set of assumptions that imply that people will handle 10 layers of > hierarchies ... is bogus, because people will not handle them, because > they cannot. > > Really? People seem to be able to handle quite a few layers of hierarchy in > Unix file systems without blowing out. The principle is just the same; it's > a way of organizing lots and lots of stuff. Of course, Unix file names are > a little more user-friendly than sequences of numeric labels, which is what > hierarchical addresses are. That statement is false, or you mean that "quite a few layers" to be a lot less than 10. People are able to navigate a modest hierarchy, whether DNS domain or UNIX files, when they are given landmarks, such as .com., .edu, /usr, and /bin. People are not able to navigate UNIX file hierarchies with arbitrary, meaningless names. Even with meaningful names, everyone has trouble with hierarchies far more shallow than 10. (I say that having watched the evolution of commercial UNIX vendors' forests of source trees.) How many people are able to keep straight a DOS or UNIX file hierarchy with more than half a dozen effective levels? Most people either do not keep track of where their home directories live in the tree, or all home directories in the local organization are rooted in a few standard places, like /usr/people or /{u1,u2,...,u7}/home. No one has an "active file hierachy vocabulary" that is more than half a dozen non-trivial layers deep. The rest of the tree is treated like distant forest that you can navigate by reading the landmarks but do not keep in mind. The thrust of my argument is: Those arguments that assume or conclude that individual people can or will actively and directly manage or manipulate or navigate within more than an insignificantly tiny part of a 10 or 12-layer IPng hierarchy are bogus. Yes, I've heard of `gopher`, `www`, and other Internet navigation tools. They buttress my point. Almost everyone is incapable of navigating directly in the current, tiny 1E6 Internet. Instead they use computers to search for what they want. If IPng genuinely requires 10 or 12 layers of hierachy, and if 16-bytes of address are not enough then one or more of the following is necessarily true: 1. people will not understand or directly work on the addresses or the hierarchy. 2. only machines will handle the addresses and hierarchies directly. 3. the IPng tent may as well fold up now. Given any plausible address assignment efficiency, even the reprehsibly, unnecessarily (for IPng) poor performance of the current Internet, humans cannot and will not handle the number of nodes implied by 16-byte addresses. 16-byte addresses will necessarily be mechanically assigned and manipulated, and hierarchies mechanically navigated. This means that very high address assignment efficiencies will occur. This just a restatement of what CIDR is all about. By getting humans out of the loop, the computers aggregate addresses and get reasonable efficiencies. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 18:37:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07311; Wed, 13 Jul 1994 17:30:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01511; Wed, 13 Jul 1994 17:30:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01459; Wed, 13 Jul 1994 17:06:28 +1000 Precedence: list Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03745; Wed, 13 Jul 1994 15:56:10 +1000 (from news@vix.com) Received: by gw.home.vix.com id AA09677; Tue, 12 Jul 94 22:55:52 -0700 Date: Tue, 12 Jul 94 22:55:52 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: big-Internet@munnari.OZ.AU From: paul@vix.com (Paul A Vixie) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Organization: Vixie Enterprises Message-Id: References: <9407130051.AA20442@rhyolite.denver.sgi.com> Nntp-Posting-Host: gw.home.vix.com In-Reply-To: vjs@rhyolite.denver.sgi.com's message of 12 Jul 1994 18:51:53 -0700 >Consider this 16-byte address: > > 192.26.92.75.72.96.180.125.135.66.32.69.237.59.250.195 When I saw my first 32-bit address in a VAX hex dump, I thought those 8-digit numbers were monsters and that I'd never get used to them. When I saw my first 64-bit address in an Alpha hex dump, '' '' '' '' etc. History shows that we get used to this stuff after a while. -- Paul Vixie Redwood City, CA decwrl!vixie!paul From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 18:38:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06372; Wed, 13 Jul 1994 17:04:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01445; Wed, 13 Jul 1994 17:04:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01421; Wed, 13 Jul 1994 16:56:43 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02013; Wed, 13 Jul 1994 15:14:03 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id BAA08098; Wed, 13 Jul 1994 01:13:53 -0400 Date: Wed, 13 Jul 1994 01:13:53 -0400 From: Vadim Antonov Message-Id: <199407130513.BAA08098@titan.sprintlink.net> To: avg@sprint.net, mohta@necom830.cc.titech.ac.jp Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU > Actually, why EIDs should be the part of the header? >For provider-independent identification of hosts. Bull. DNS is doing "provider-independent identification of hosts" just fine, thank you. Also, it does not require names to be present in headers. >> Sounds like >> an awful waste of space. >Because it's much better than putting DNS hostnames in the header. Bull again. Dynamic mapping of EIDs into transport level addresses is as hard algorithmically as dynamic mapping of DNS names into transport level addresses. Neither of them should ever appear in packet headers with a properly designed dynamic binding. You're solving the wrong problem. It is tempting to cure the sympthoms instead of the actual illness. It will get you anyway -- in some other form, like routing flap. >> (And DON'T tell me that "links are fast, CPUs are faster" > If so, put DNS hostnames. Put where? >> As it is EIDs are the relics of unwillingness to recognize >> DNS as a part of transport layer (instead of application layer >> as it is now, which is a serious misdesign itself). > It seems to me that you confuse "application layer" and "application > program". Please leave terminological nitpicking to OSI crowd. I'm confident nobody misinterpreted what i wanted to say. > You also confuse "DNS name" and "hostname". While a DNS name with A > record is an internetwork layer hostname, a DNS name with MX is > a transport layer MTA name. DNS name is a shorthand for hierarchically-organized ASCII-based human-readable network entity identifier. Also, the electrical capacity in CGS is measured in centimeters and the evolution of animus has four distinct stages, ok? >Agreed (which what EIDs are not). C'mon, the fact that EIDs are supposed to be allocated by a pyramid of bureaucratic bodies does not mean that there will be any meaningful ordering of EIDs present in the actual network. An unordered set of addresses is the other name for flat addresses. A hierarchial addressing assumes at least partial topological ordering of addresses. Wake up and try to apply some logic. I at least have a benefit of education in mathematics and trained to see a bogus statement for what it is. --vadim From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 18:56:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07843; Wed, 13 Jul 1994 17:45:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01542; Wed, 13 Jul 1994 17:44:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01507; Wed, 13 Jul 1994 17:29:27 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04673; Wed, 13 Jul 1994 16:25:44 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 13 Jul 94 15:17:11 +0900 From: Masataka Ohta Message-Id: <9407130617.AA10301@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: avg@sprint.net (Vadim Antonov) Date: Wed, 13 Jul 94 15:17:09 JST Cc: avg@sprint.net, Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU In-Reply-To: <199407130513.BAA08098@titan.sprintlink.net>; from "Vadim Antonov" at Jul 13, 94 1:13 am X-Mailer: ELM [version 2.3 PL11] > >> Sounds like > >> an awful waste of space. > > >Because it's much better than putting DNS hostnames in the header. > > Bull again. Dynamic mapping of EIDs into transport level addresses > is as hard algorithmically as dynamic mapping of DNS names into > transport level addresses. I don't understand what "dynamic mapping" means. I don't understand why "transport level address" appears here. > Neither of them should ever appear in packet headers with a properly > designed dynamic binding. What is "dynamic binding" at all? > >> As it is EIDs are the relics of unwillingness to recognize > >> DNS as a part of transport layer (instead of application layer > >> as it is now, which is a serious misdesign itself). > > > It seems to me that you confuse "application layer" and "application > > program". > > Please leave terminological nitpicking to OSI crowd. I'm confident > nobody misinterpreted what i wanted to say. You are using words "application", "transport" and "internetwork" with too much errors with a lot of undefined new terminologies that I don't interpret what you wanted to say. I, myself, didn't use the terms like "internetwork layer identifier" until some pedanttically started saying "transport level name" or, even worse, quite OSIish acronym of "TLN" without thinking about what they, themselves, wanted to say. > > You also confuse "DNS name" and "hostname". While a DNS name with A > > record is an internetwork layer hostname, a DNS name with MX is > > a transport layer MTA name. > > DNS name is a shorthand for hierarchically-organized ASCII-based > human-readable network entity identifier. Though I don't understand you, didn't you say: > is as hard algorithmically as dynamic mapping of DNS names into > transport level addresses. Why it is related to the network entity identifier, here? Do you think "transport" and "network" have the same meaning? Could you teach me which network entity a DNS name "com." identifies? Could you teach me which network entity a DNS name "in-addr.arpa." identifies? Could you teach me which network entity a DNS name "cc.titech.ac.jp." identifies? DNs name is a name. It may identify several things. > Wake up and try to apply some logic. Logic needs correct terminology. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 21:18:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10034; Wed, 13 Jul 1994 18:44:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA01611; Wed, 13 Jul 1994 18:44:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA01597; Wed, 13 Jul 1994 18:39:27 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09682; Wed, 13 Jul 1994 18:39:19 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 13 Jul 1994 09:38:44 +0100 To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU (bigi) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Wed, 13 Jul 94 08:37:47 +0100." <9407130637.AA19415@dxcoms.cern.ch> Date: Wed, 13 Jul 94 09:38:41 +0100 Message-Id: <583.774088721@cs.ucl.ac.uk> From: Jon Crowcroft >What's wrong with CIDR is the need for CIDR masks in order to >interpret IPv4 addresses. This is extra state to manage which is >a BAD THING. routes already have subnet masks all around the internet most our routes also have delay, bandiwth, policies typical routing state cited by cisco et al is 128 bytes+ since the CIDR state does not vary disjointly with an address at a given part of the net, it is not seperate state to manage....its noit a problem jon From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 21:24:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15068; Wed, 13 Jul 1994 21:24:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA01777; Wed, 13 Jul 1994 21:24:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01774; Wed, 13 Jul 1994 21:17:17 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10541; Wed, 13 Jul 1994 18:57:13 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 13 Jul 1994 09:56:54 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Whither IPng? In-Reply-To: Your message of "Wed, 13 Jul 94 01:14:49 EDT." <9407130514.AA29448@ginger.lcs.mit.edu> Date: Wed, 13 Jul 94 09:56:52 +0100 Message-Id: <684.774089812@cs.ucl.ac.uk> From: Jon Crowcroft >Second, we could split into two groups, with fundamentally different goals; >the "improvers" and the "radicals" I think this model is useful, but not quite right.... I think that to get clsure on IPng, we should scope the discussion to the proposals, and their refinement (that means progressive improvement by elimiation of errors and ambiguities, not re-writing!) meanwhile, au fond, we should discuss the longer term goals you tend to bring up. I do not believe that reaching closure on those is feasible in the context of the IETF anymore.....but that you can continue to develop them in the broader research light....if they are sufficiently effective when finalised and implemented, the market will move to those after the products have been upgraded to IPng.... but what you propose (and the mention of things like x.25) is not evolution of the internet, but revolution... jon From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 22:13:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14588; Wed, 13 Jul 1994 21:05:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA01742; Wed, 13 Jul 1994 21:04:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01739; Wed, 13 Jul 1994 21:02:58 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14538; Wed, 13 Jul 1994 21:02:51 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 13 Jul 1994 12:02:10 +0100 To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Date: Wed, 13 Jul 94 12:02:04 +0100 Message-Id: <1055.774097324@cs.ucl.ac.uk> From: Jon Crowcroft i have the sneaking suspicion that some peopel have an empitional inability to accept that each bit doubles the address space, or adds another layer of hierarchy - thus going from 8 to 16 byte addresses gives you 64 more levels or 2**64 more machines, either of which is complete overkill:-) i am prepared to give in on variable length so long as people give away special packet header processors with each host for free - or alternatively, i propose that SIPP use 8 ([+8]*), and the variable people use address lengths 1-17 bytes long, excluding the value 8, and both source and destination must be the same length so we can tell in oure SIPP hosts and routers from the header lengtrh which packets to ignore:-) in fact, why dont you encode 7 levels of hierarchy by using address lengths 1,2,3,5,7,11 and 13 that way we can unabliiguously tell where you are from the IPng class of your address....:-) alternatively, we can use 64bit addr + 64 bit mask and do all the things steve deering has described so clearly. j. From owner-Big-Internet@munnari.OZ.AU Wed Jul 13 22:18:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15272; Wed, 13 Jul 1994 21:30:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA01807; Wed, 13 Jul 1994 21:30:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01771; Wed, 13 Jul 1994 21:12:19 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08718; Wed, 13 Jul 1994 18:10:22 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA20903; Wed, 13 Jul 1994 10:11:16 +0200 Message-Id: <199407130811.AA20903@mitsou.inria.fr> To: kasten@ftp.com Cc: deering@parc.xerox.com, Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 12:31:19 EDT." <9407121631.AA23451@mailserv-D.ftp.com> Date: Wed, 13 Jul 1994 10:11:13 +0200 From: Christian Huitema Frank, This whole business of estimating efficiency, numbers of levels, etc, is difficult to assert. When I try to do this assertion myself, I come to the conclusion that figures like "margin of 1.0E+3" are misleading, because they don't take into account the number of levels. I would suggest that we measure the efficiency on a logarithmic scale: log (number of objects) ----------------------- available bits I will use base 10 logs in what follows, because they are easier to compute mentally. The advantage here is that the ratio does not depend too much of the number of levels. Now, we can take existence proofs from existing numbering plans. What is especially interesting is to consider the moment where the plans broke, i.e. when people were forced to add digits to phone number, or to add bits to computer addresses. I have a number of such figures handy, e.g.: * Adding one digit to all French telephone numbers, moving from 8 digits to 9, when the number of phones reached a treshold of 1.0 E+7. The log value is 7, the number of bits was about 27 (1 decimal digit is about 3.3 bits). The ratio is thus 0.26 * Expending the number of areas in the US telephone system, making it effectively 10 digits long, for about 1.0 E+8 subscribers. The log value is 8, the number of bits is 33, the ratio is about 0.24 * Expending the size of the Internet addresses, from 32 bits to something else. There are currently about 3 million hosts on the net, for 32 bits. The log of 3.E6 is about 6.5; this gives a ratio of 0.20. Indeed, we believe that 32 bits will still be enough for some years, e.g. to multiply the number of hosts by 10, in whichcase the ratio would climb to 0.23 * Expending the size of the SITA 7 characters address. According to their documentation, they have about 64000 addressed points in their network, scattered in 1200 cities, 180 countries. An upper case character provides about 5 bits of addressing, which results in an efficiency of 0.14. This is an extreme case, as SITA uses fixed length tokens in its hierarchy. From these examples, we can assert that the efficiency ratio lies between 0.14 and 0.26. Using a reverse computation, we get the following population counts in the network: Pessimistic (0.14) Optimistic (0.26) 32 bits 3 E+4 (!) 2 E+8 64 bits 9 E+8 4 E+16 80 bits 1.6 E+11 2.6 E+27 128 bits 8 E+17 2 E+33 I guess that the figure explains well why some feel that 64 bits is "not enough" while other feel it is "sufficient by a large margin": depending of the assignment efficiency, we are either well below the target or well above. But there is no question, in my view, that 128 bits is "more than enough". Even if we presume the lowest efficiency, we are still way above the hyperbolic estimate of 1.E+15 Internet hosts. It is also interesting to note that if we devote 80 bits to the "network" and use 48 bits for "server less autoconfiguration", we can number more that E.11 networks in the pessimistic case - it would only take an efficiency of 0.15 to reach the E+12 networks hyperbole. I guess this explains well why I feel that 128 bits is entirely safe for the next 30 year. The level of constraints that we will have to incorporate in the address assignment appears very much in line with what we know how to do, today. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 00:04:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20096; Thu, 14 Jul 1994 00:04:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02062; Thu, 14 Jul 1994 00:04:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA02053; Wed, 13 Jul 1994 23:56:44 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19297; Wed, 13 Jul 1994 23:56:39 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 13 Jul 1994 09:56:36 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 13 Jul 1994 09:56:36 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA07311; Wed, 13 Jul 94 09:54:30 EDT Date: Wed, 13 Jul 94 09:54:30 EDT Message-Id: <9407131354.AA07311@mailserv-D.ftp.com> To: kck@netcom.com Subject: Re: why not variable length? From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU Content-Length: 1435 > One of the original goals of IPng was to go from 4 to 8 bytes. Why > have we suddenly changed goals (or at least contemplating change)? Nope. IPng's public motivations were twofold: 1. Starting at the Vancouver IETF meeting, Frank Solensky started doing some simple statistical predictions of when we would run out of IPv4 addresses, based on past usage patterns, and that date turned out to be 'soon' (at the time, Class B's were predicted to run out by March 1994), rather than 'a long time in the future' AND 2. Noel Chiappa gave a talk at the Boulder IETF meeting where he claimed that efficient routing was getting increasingly problematic as the number of routes in the backbones grew, especially considering that these routes were doubling every 7 or 8 months or so AND that people wanted more out of the routing (e.g. policy). Since then, several people have made the observation that to really and permanently fix these two problems, we would need to completely replace the internet-layer protocol (as opposed to hacking IPv4 a bit). Therefore, if we have to make a major change in this protocol, we should use the opportunity to add new functions which people have wanted (e.g. auto-configuration, security, network service models, etc etc etc) and do it in an architecturally consistant manner. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 00:06:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20149; Thu, 14 Jul 1994 00:06:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02079; Thu, 14 Jul 1994 00:06:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA02054; Wed, 13 Jul 1994 23:56:44 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19299; Wed, 13 Jul 1994 23:56:41 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 13 Jul 1994 09:56:39 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 13 Jul 1994 09:56:39 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA07315; Wed, 13 Jul 94 09:54:32 EDT Date: Wed, 13 Jul 94 09:54:32 EDT Message-Id: <9407131354.AA07315@mailserv-D.ftp.com> To: rcallon@pobox.wellfleet.com Subject: Re: The right numbers (was Re: IPng ADs Wish to Gauge...) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU Content-Length: 2914 > 1. Is it reasonable to expect that the network might grow this > big in the next 20 years (expected IPng lifetime) or so? Or > could it easily be bigger? > > One thing that I am somewhat uncomfortable with: Folks keep > talking about IPng as having to last somewhere between 20 > and 30 years. However, if IPng does last at least 20 years, > then it will be so widespread by then that it will be > impossible to ever change it. Which is why I've been arguing that we, today, must adopt protocol mechanisms that will allow IPng to be able to evolve and be extended 20 years from now in a manner that does not make all those light switches and alarm clocks (or whatever) obsolete. One of those mechanisms, which is the subject of the current debate, is address size. While most of the options under discussion today are probably OK (some more or less optimal than others, but that really is in the noise) for what people's crystal balls are showing them today, I am very concerned about the things that the crystal balls are NOT showing. What kinds of underlying, fundamental, shifts in the computing/networking model will occur over the next 20 years? I'm not talking about the 'simple' stuff like putting more computers into more things and connecting them with a network. I'm expecting some completely unpredictable and fundamental shift in the model. We've already seen this shift once. The original IPv4 address had a 1-byte network number and a 3-byte host field. The original architects of IPv4, as bright as they were then, and still are today, simply did not forsee the change in computing that cheap, powerful, integrated circuits would engender: the rise of affordable, powerful, PCs and workstations, network interfaces, and network switching elements. If they had been able to forsee this then we might not be in the mess we are in today. (As an aside, this is not a flame at the IPv4 architects -- nobody expected the changes that have occured...) > I think that > we should at least admit that what we are doing either will > get discarded rather quickly, or will last essentially forever. If the Internet becomes the Global Information Super-Infra-Bahn- Highway-Structure-thing then its technology will last forever. My parents have a telephone that they've had for 35 years. It has a dial (remember them?). It still works with the phone network just fine. I have an old phone from the 1920s -- you know, the kind with the separate microphone and speaker? A few years ago I jury-rigged it up and it worked just fine. Pulse dialing and 70 year-old technology still work on the phone network. If and when the Internet becomes as ubiquitous as the phone network, our equivalent of pulse dialing and analog voice lines will be around for a long long long long time. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 00:14:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16205; Wed, 13 Jul 1994 22:05:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA01854; Wed, 13 Jul 1994 22:04:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01849; Wed, 13 Jul 1994 21:58:39 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12469; Wed, 13 Jul 1994 20:02:44 +1000 (from kre@munnari.OZ.AU) To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU (bigi) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Wed, 13 Jul 1994 08:37:47 +0200." <9407130637.AA19415@dxcoms.cern.ch> Date: Wed, 13 Jul 1994 20:02:41 +1000 Message-Id: <27856.774093761@munnari.OZ.AU> From: Robert Elz Date: Wed, 13 Jul 1994 08:37:47 +0200 (MET DST) From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-ID: <9407130637.AA19415@dxcoms.cern.ch> (1) is clearly false. (2) (3) and (4) were false too, I think that was the point. What's wrong with CIDR is the need for CIDR masks in order to interpret IPv4 addresses. This is extra state to manage which is a BAD THING. Bad or not, its necessary. We simply have to do route aggregation. We also have to allow non-aggregated special cases. The combination of the two of those requires some kind of length field to indicate just how much of this particular address is meaningful in this context. Whether that field is a mask or a count, whether the count is constrained to be a multiple of 4, 8, or 1, doesn't really matter. Restricting flexibility by imposing constraints with no useful purpose doesn't seem like a good idea to me, so I very much support aggregation on any arbitrary bit boundary that suits. kre From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 00:19:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16226; Wed, 13 Jul 1994 22:06:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA01874; Wed, 13 Jul 1994 22:06:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01835; Wed, 13 Jul 1994 21:44:38 +1000 Precedence: list Received: from thor.tjhsst.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15732; Wed, 13 Jul 1994 21:44:31 +1000 (from cmetz@thor.tjhsst.edu) Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0qO2lg-000AelC; Wed, 13 Jul 94 07:46 EDT Message-Id: To: kck@netcom.com (Richard Fox) Cc: big-internet@munnari.OZ.AU Subject: Re: why not variable length? In-Reply-To: Your message of "Tue, 12 Jul 1994 23:28:41 EDT." <199407130628.XAA14433@netcom7.netcom.com> Date: Wed, 13 Jul 1994 07:46:27 EDT From: Craig Metz In message <199407130628.XAA14433@netcom7.netcom.com>, you write: >I agree with this statement as well. I have no problem in going >from 8 bytes to 16 bytes if it can proved that 8 bytes is not >enough. Thus far I have not heard any really compelling >arguments. In fact, it seems that the problem with 8 bytes that >I have heard is auto-configuration. However, since this is an area >that seems to have many open ended issues, I find it hard to architect >an address encoding for it. The reasons I can think of for sixteen bytes are: * MAC-based local use addresses (putting, for instance, the IEEE 6-byte MAC address space inside an 8-byte address space eats 1/65536th of your address space right there. These are big chunks being taken out of your address space, and they add up quickly) * Extra space for heirarchial routing (which should help to lessen the amount of routing information individual routers need to carry -- a big win when you think about the kind of growth we expect and the kind of performance that will be expected of future routers) * Even farther minimized chance of the address space running out before the protocol becomes obselete. (see my last message or just pull out a good pocket calculator and start playing with numbers. There is no doubt in my mind that the safety margins built into any sane allocation of 16-byte addresses are plenty) * As compressed links become more popular/practical, the information in a 16-byte address is similar to that in an 8-byte one and will occupy a similar number of compressed bits. >Also, it seems that it is easier to encode >with 16 bytes but with a little thought I think it can be done with 8 >bytes as well. I guess the other problem with 8 bytes that I have >heard is space utilization. It seems that we should fix this problem >and not just the symptom. I strongly agree. People are being almost deliberately wasteful of address space from the start. If we divided up and used space efficiently, I can see very practical ways we could handle the needs of the next twenty years on a redone 32-bit address space (magic words being local use networks and application gateways -- even in the most paranoid scenario where every electronic device in your home would be on The Net, do you want and need direct, global addressability for every one of them? I don't *want* anyone outside my house to be able to access my toaster, and I don't *want* it to be able to talk to every other toaster in the world). This is another big win of fixed-length addresses -- you have a finite amount of space, so now you really do have to manage it. With variable length addresses, you just make them bigger and avoid dealing with the real problem. -Craig From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 00:20:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17049; Wed, 13 Jul 1994 22:44:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA01966; Wed, 13 Jul 1994 22:44:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA01950; Wed, 13 Jul 1994 22:36:52 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16836; Wed, 13 Jul 1994 22:36:48 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id IAA02521; Wed, 13 Jul 1994 08:36:43 -0400 From: Howard Berkowitz Message-Id: <199407131236.IAA02521@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: ericf@atc.boeing.com (Eric Fleischman) Date: Wed, 13 Jul 1994 08:36:43 -0400 (EDT) Cc: Big-Internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com In-Reply-To: <9407130232.AA04720@atc.boeing.com> from "Eric Fleischman" at Jul 12, 94 07:32:00 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 544 > > P.S. The number of layers of Boeing management fortunately has nothing to > do with the numbers of layers needed for Boeing's addressing hierarchy. > However, it was a witty statement of yours but certainly a "red herring". > BTW: Thanks, Peter, for sending me a definition of the term "red herring". > > So we can reach consensus on SOMETHING, it would be a public service to share the definition of red herring. We could, in Toronto, have a BOF of fish-eating birds as a means of selecting the proper address for herring. :-) From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 00:28:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16656; Wed, 13 Jul 1994 22:24:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA01906; Wed, 13 Jul 1994 22:24:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA01865; Wed, 13 Jul 1994 22:05:42 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12200; Wed, 13 Jul 1994 19:55:38 +1000 (from kre@munnari.OZ.AU) To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 18:50:44 EDT." <9407122254.16370@munnari.oz.au> Date: Wed, 13 Jul 1994 19:55:35 +1000 Message-Id: <27848.774093335@munnari.OZ.AU> From: Robert Elz Date: Tue, 12 Jul 94 18:50:44 EDT From: yakov@watson.ibm.com Message-ID: <9407122254.16370@munnari.oz.au> I tend to agree with this statement. What I'd like to understand is what *in your opinion* are the factors that could prevent aggressive and continuous use of variable length addresses. Did no-one read Lixia's message of a few days ago? That opened my eyes a bit on variable length addressing, caused me to think of things I had been simply assuming. I had thought that variable length would mean that if we needed more addresses we could simply increase the length and get more. I had resisted that mostly on the basis that the fixed length being planned already contained plenty, and more would never be needed. Lixia pointed out that extending variable length addresses to the right (which is currently the only way we can extend them) is an incredibly wasteful way to gain extra addressing - you certainly gain some, but not nearly as much as you'd gain if you could extend the address to the left. However we don't know how to make that work, in fact, we don't have the vaguest idea (or I don't) how we could make that work. Even better would be the ability to also insert bytes in the middle of addresses - we don't know how to make that work either. This particularly applies to the "make addresses variable, that way we can use 8 bytes, and extend to 16 later if needed, and then maybe 24, or 32 bytes". If we allocate any of those 8 byte addresses, when the field is later extended to 16 bytes, each allocated 8 byte address is using the space that could have been available for 2^64 addresses in the 16 byte space. That's mind boggling. Then think how much that one address uses by the time the longest addresses have reached 32 bytes... Until we have at least some kind of handle on how we'd process variable length addresses in a way that they can grow where they're most needed (its not the end that matters of course, its that they need to grow near the root of the tree, not at the leaves), we're much better off picking a large enough fixed length space, and allocating towards the right end of it, that we know how to handle. It may be that some kind of masking from the least significant end of the address, ignoring the bits we know to be local,then routing on all that's left, rather than masking on what we know to be the most significant part, and ignoring the rest as local stuff could work - but no-one has tried it that I'm aware of, it certainly hasn't been tried enough to make it the standard way of doing things any time soon. kre From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 00:32:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16675; Wed, 13 Jul 1994 22:26:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA01934; Wed, 13 Jul 1994 22:25:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA01901; Wed, 13 Jul 1994 22:17:07 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15406; Wed, 13 Jul 1994 21:34:17 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA07921; Wed, 13 Jul 94 06:36:02 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac13351; 13 Jul 94 11:31 GMT Date: Wed, 13 Jul 94 06:32 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: pvm To: "Tansin A. Darcos & Company" <0005066432@mcimail.com> Cc: big internet Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <41940713113214/0003858921NA4EM@mcimail.com> I said: >>Well, I have thought a lot about this. >> >>Variable is out. Human's, being the way they are (notice the structure, >>us IPngers can't be humans :), and corporate creatures, being a more >>exasperating form of human's, cannot cope with variable decision >>processes. A lot of people will spin their wheels with the variable >>length and what will emerge will be a recommendation, followed by everyone >>eventually on how to structure the address. Just like NSAPs.... >> >>People LIKE fixed things. The question is if it is fixed, is it fixed >>enough over time. So we hedge our bets by doubling our best guess and >>then do a few things to weaken that guess by adding functionality into the >>larger number. pvm responded: >I don't understand your argument. >People use variable length personal names, domain names, telephone numbers, Hmmm, still running quite behind. Been testing out some REAL V.34 modems. Nice... I think I got it. My response to a few comments about people and variable lengths. Paul's comment gelled it for me. People TALK variable all of the time. So it would seem natural to use variable in all that we do. But in practice, people get tired of none deterministic things. Take another look at addresses. They fall into a few descreet lengths in terms on the number of rolls. Again with names, there are only a few fields in names. Those long expections are viewed as 'different' by the majority and are normally shortened for common use. There was a major communications manufacturer that had a DNS that went from 4 to about 9 levels deep. They have since renamed everything from 4 levels with a couple of 5 level exceptions. Finally, look at the IPng 'variable' length discussion. It is not an unbounded length for most of the proposals, but rather a few, descreet, choices of lengths. I don't call that variable. I barely call DNS's 256 length (that 822 will not support, thus really limiting us to 64) variable. And now how long is the longest? 50 some? We talk a good talk about variable, but we end up couching it in some fixed methodology. This shows itself very well with CLNP's NSAPs as well. Thus I contend, again, that if we go and define a variable length IPng address, there will be SOME experimentation with truely variable lengths, but somewhere a convention will arise around on address format that is really fixed length and everyone will gravitate to that. Sort of our: 'let the market decide'. I would hope that there are enough (and not too many :) good people here that can short circuit this process and decide for the market and get on with the business of networking!!!!!! Bob Moskowitz Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:02:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20774; Thu, 14 Jul 1994 00:24:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02412; Thu, 14 Jul 1994 00:24:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02109; Thu, 14 Jul 1994 00:14:41 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16625; Wed, 13 Jul 1994 22:23:05 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23051; Wed, 13 Jul 1994 14:23:17 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27148; Wed, 13 Jul 1994 14:22:58 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407131222.AA27148@dxcoms.cern.ch> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 13 Jul 1994 14:22:58 +0200 (MET DST) In-Reply-To: <199407130811.AA20903@mitsou.inria.fr> from "Christian Huitema" at Jul 13, 94 10:11:13 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 958 Christian, > > log (number of objects) > ----------------------- > available bits Thank you! I have been groping after this for some time. Try two more data points: * The globally-connected physics/space science DECnet (Phase IV) stopped growing at about 15K nodes (i.e. new nodes were hidden) which in a 16 bit space gives a ratio of 0.26 * If I guess that there are 200 million IEEE 802 nodes (does anybody have a good number?) in a 46 bit space (2 are useless) the ratio is 0.18 This confirms your range. Given that running an allocation scheme with the ratio at 0.26 is painful, from my experience, could we aim at a design point of 0.20? Since the design goal is 10**12 networks ~= 10**15 nodes, we need 75 bits [ log(10**15)/75 = 0.20 ]. To put it another way, allocating a 64 bit space and keeping the ratio down to a painless 0.20, we can hope to address almost 10**13 nodes, compared to the criterion of 10**12 networks. Brian From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:10:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20797; Thu, 14 Jul 1994 00:26:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02438; Thu, 14 Jul 1994 00:26:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02115; Thu, 14 Jul 1994 00:16:50 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16745; Wed, 13 Jul 1994 22:32:52 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24639; Wed, 13 Jul 1994 14:33:04 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27331; Wed, 13 Jul 1994 14:32:45 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407131232.AA27331@dxcoms.cern.ch> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 13 Jul 1994 14:32:45 +0200 (MET DST) In-Reply-To: <27856.774093761@munnari.OZ.AU> from "Robert Elz" at Jul 13, 94 08:02:41 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1432 Robert, >--------- Text sent by Robert Elz follows: > > Date: Wed, 13 Jul 1994 08:37:47 +0200 (MET DST) > From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > Message-ID: <9407130637.AA19415@dxcoms.cern.ch> > > (1) is clearly false. > > (2) (3) and (4) were false too, I think that was the point. Well actually I think they are true,but never mind :-) > > What's wrong with CIDR is the need for CIDR masks in order to > interpret IPv4 addresses. This is extra state to manage which is > a BAD THING. > > Bad or not, its necessary. We simply have to do route > aggregation. We also have to allow non-aggregated special > cases. Yes of course. In the IPv4 space (which is broken, see arguments by Eric Fleischman) CIDR is vital. > The combination of the two of those requires some > kind of length field to indicate just how much of this particular > address is meaningful in this context. Whether that field is > a mask or a count, whether the count is constrained to be a > multiple of 4, 8, or 1, doesn't really matter. I'm not suggesting one can construct stateless routers. What I am saying is that the more aggregation can be performed by simple inspection of a locator, without using router state, the better. Which prejudices me in favour of topologically meaningful, hierarchical locators. Which will tend to be longer than the mathematical minimum. Brian From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:13:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20854; Thu, 14 Jul 1994 00:28:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02460; Thu, 14 Jul 1994 00:28:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02087; Thu, 14 Jul 1994 00:07:51 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20164; Thu, 14 Jul 1994 00:07:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00584; Wed, 13 Jul 94 10:07:28 -0400 Date: Wed, 13 Jul 94 10:07:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407131407.AA00584@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Robert Elz Lixia pointed out that extending variable length addresses to the right ... is an incredibly wasteful way to gain extra addressing ... extend the address to the left. However we don't know how to make that work, in fact, we don't have the vaguest idea (or I don't) how we could make that work. It's not that hard; in fact, it's quite natural. Dave Reed sold me on the idea at MIT back in the late 70's, in a talk he gave (probably as a result of thinking about the proposed variable length addresses for IPv4); unfortunately, I don't think he ever wrote it up, so I don't have a reference. Remember, a hierarchical address is just the sequence of the labels of the areas which contain a given object. Imagine a graph, and you draw a bunch of circles which enclose parts of the graph. That's the "first" level of address (counting from the bottom, with the individual node identifiers as the "zeroth" level). Now, repeat the process, and you get more levels; you are extenedd the address to the left in this procedure. Presumably, at some point you get to the point where you have a single circle which encloses the lot. Now, extend the graph; you need to draw an even larger circle to enclose the whole thing; you have extended the address on the left after they were all assigned. Some members of the Nimrod WG want Nimrod locators to work this way. The only problem is that any non-full-length locator is not necesarily unique, and needs a context in which to be interpreted, but this isn't the end of the world. Even better would be the ability to also insert bytes in the middle of addresses - we don't know how to make that work either. With fixed CIDR-like bit-packing, it is basically impossible. Which is why I prefer a syntax for locators which has some "markers" in it to delineate the fields; you can extend one field without having a big hassle. This particularly applies to the "make addresses variable ... If we allocate any of those 8 byte addresses, when the field is later extended to 16 bytes, each allocated 8 byte address is using the space that could have been available for 2^64 addresses in the 16 byte space. Right, which is one more reason addresses should grow to the left, not to the right. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:16:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22123; Thu, 14 Jul 1994 01:04:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02557; Thu, 14 Jul 1994 01:04:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02550; Thu, 14 Jul 1994 01:00:38 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20548; Thu, 14 Jul 1994 00:19:23 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 13 Jul 1994 15:19:08 +0100 To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU Subject: Re: The right numbers (was Re: IPng ADs Wish to Gauge...) In-Reply-To: Your message of "Wed, 13 Jul 94 09:54:32 EDT." <9407131354.AA07315@mailserv-D.ftp.com> Date: Wed, 13 Jul 94 15:19:09 +0100 Message-Id: <1871.774109149@cs.ucl.ac.uk> From: Jon Crowcroft > 35 years. It has a dial >(remember them?). Frank one minor difference: the internet is soft. a phone with a dial isn't we can re-program hosts and routers without having to write off their bitmaps displays and qwerty keyboards if we get carried away by analogy, i'm gonna develop an allergy jon From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:18:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20975; Thu, 14 Jul 1994 00:31:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02477; Thu, 14 Jul 1994 00:30:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02112; Thu, 14 Jul 1994 00:16:09 +1000 Precedence: list Received: from thor.tjhsst.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16363; Wed, 13 Jul 1994 22:14:32 +1000 (from cmetz@thor.tjhsst.edu) Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0qO3Eb-000AelC; Wed, 13 Jul 94 08:16 EDT Message-Id: To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 23:15:40 EDT." <9407130315.AA29016@ginger.lcs.mit.edu> Date: Wed, 13 Jul 1994 08:16:19 EDT From: Craig Metz In message <9407130315.AA29016@ginger.lcs.mit.edu>, you write: >IP was initially done in the mid-70's. It's now basically 20 years later, and >if IPv4 had longer addresses, do you think there would be any significant >pressure to change it? What make you so sure that a 30-year lifetime is >infeasible? If there is no reason to change it, then why are the IPng proposals on the table so radically different than just an IPv4 header with bigger addresses thrown in? When you think about the kind of routing speeds that will be required if we are to ever have a national/global/interplanetary network carrying everything from electronic mail to HDTV, we need to have a protocol in which routers have a *very* fast fast-path. Hosts, especially those based on embedded controllers and ASICs, will need to be able to quickly send and receive data with a minimum amount of processing. We are talking about the day where your cable box might be a host on The Net and thousands if not millions of small substation boxes will be routers. Many of the design decisions in IPv4 were good then, but will not survive well in this world. We need to tailor the protocol for this reality -- the protocol *does* need to be changed more than just by address size. SIPP makes many changes to IPv4. A sampling: * Fields that are frequently unnecessary (those related to fragmentation especially) moved out of the mandatory header and into option space * Removal of unnecessary functions of routers (again, fragmentation) * Removal of extraneous checksum in the SIPP header (most transports provide error detection, ditto most higher- level protocols -- routers also no longer have to update a checksum for every packet they process) * Improved Path MTU Discovery support (in SIPP-ICMP's Too Big) * Fields are now more natural sizes (to today's machines) * Fields are now more naturally aligned (to today's machines) * No more one-bit or three-bit fields * There are far fewer fields, period, that a host need to process * Fields are better defined (Hop Limit especially) than their IPv4 counterparts * Elimination of broadcasts and embracing of multicasts * Options that routers need to proecess are moved to a special hop-by-hop header in a fixed location relative to the SIPP header * Addition of the Flow ID and associated capabilities * Integrated authentication header Noel, if IPv4 would be just fine with bigger addresses, then why are these changes necessary? They look like useful improvements to me, and closer to necessary if we expect IPng to survive the day when everyone's HDTV sets and telephones use it. -Craig From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:24:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21055; Thu, 14 Jul 1994 00:32:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02494; Thu, 14 Jul 1994 00:31:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02406; Thu, 14 Jul 1994 00:23:30 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16743; Wed, 13 Jul 1994 22:32:43 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id IAA02138; Wed, 13 Jul 1994 08:32:36 -0400 From: Howard Berkowitz Message-Id: <199407131232.IAA02138@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Jul 1994 08:32:36 -0400 (EDT) Cc: Big-Internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9407130359.AA29301@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 12, 94 11:59:23 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2836 > > From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) > The conclusion remains that people will not handle 16-byte addresses > because they cannot. ... Any set of assumptions that lead to the > conclusion that people will need to deal directly with 16-byte addresses > is a bogus set of assumptions by 'reducto ad adsurdum'. > > Yes. We aren't going to be typing in 16-byte quantities. > > However, we probably will be handling the list of labels *at a given layer* > manually, though. An existing example is the list of assigned subnet numbers > within a given site. The exact implications of this for the kind of > bit-packed representations most people seem to be thinking of for use with > fixed-length addresses aren't too clear, but I expect a simple representation > would probably be more useful. > > If IPng has 10 or 12 layers, then no one, not even those who set up or > define the layers will know them or keep them straight without resorting > to scorecards. > > Not if they are stored in bit-packet form, no. > > The relevance of that fact is that all conclusions based on the assumption > that people will know or keep track of 10 layers of IPng address are bogus. > Any set of assumptions that imply that people will handle 10 layers of > hierarchies ... is bogus, because people will not handle them, because > they cannot. > > Really? People seem to be able to handle quite a few layers of hierarchy in > Unix file systems without blowing out. The principle is just the same; it's > a way of organizing lots and lots of stuff. Of course, Unix file names are > a little more user-friendly than sequences of numeric labels, which is what > hierarchical addresses are. > > Noel > Again, Noel, you are confusing people with programmers. :-) I am typing this on a Macintosh Quadra running A/UX. I use the UNIX file system for most of my administration, use hierarchical Finder replacements such as DeskTop for most of the remainder, and use the GUI Finder only when I have to. I'm a fast typist and used to file systems. I bought my Macintoshes not for ease of use, but for some of the graphic applications available. However, if traditional file systems were as easy to handle as you suggest, the market would not have developed for the Mac user interface, Windows, etc. Look at Novell's and other workgroup implementations _system administration_ tools that use windows and hierarchical menu interfaces. They sell. UNIX was there before. UNIX (and I recognize there are other pricing factors involved) was selected in many cases because its file systems and general naming conventions were too complex for many entry-level purchasers. I'm going to go grep something on my Macintosh. Makes me feel that I'm a member of the secret club. :-) From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:24:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25044; Thu, 14 Jul 1994 02:24:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02784; Thu, 14 Jul 1994 02:24:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02769; Thu, 14 Jul 1994 02:13:39 +1000 Precedence: list Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24540; Thu, 14 Jul 1994 02:13:37 +1000 (from day@BBN.COM) Message-Id: <9407131613.24540@munnari.oz.au> From: John Day Subject: Re: the H-ratio To: mo@uunet.uu.net Cc: big-internet@munnari.OZ.AU In-Reply-To: Date: Wed, 13 Jul 94 12:19:44 EST Mail-System-Version: Does anyone have info on phone numbers world wide? Here is a name space that has multiple levels hierarchy, not all at the same depth, and variable length overall and variable length at the various level of hierarchy. Take care John From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:25:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22682; Thu, 14 Jul 1994 01:24:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02590; Thu, 14 Jul 1994 01:24:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02573; Thu, 14 Jul 1994 01:09:00 +1000 Precedence: list Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22231; Thu, 14 Jul 1994 01:08:55 +1000 (from swb1@cornell.edu) Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.5/8.6.5) with SMTP id LAA06917 for ; Wed, 13 Jul 1994 11:08:50 -0400 Message-Id: <199407131508.LAA06917@postoffice3.mail.cornell.edu> X-Sender: swb1@postoffice3.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Jul 1994 11:08:50 -0500 To: Big-Internet@munnari.OZ.AU From: Scott W Brim Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Christian's analysis of real-life practice is a breath of fresh air. From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:25:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22800; Thu, 14 Jul 1994 01:26:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02620; Thu, 14 Jul 1994 01:26:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02587; Thu, 14 Jul 1994 01:10:23 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21465; Thu, 14 Jul 1994 00:45:16 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwyjr20451; Wed, 13 Jul 1994 10:45:13 -0400 Date: Wed, 13 Jul 1994 10:45:13 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: big-internet@munnari.OZ.AU Subject: the H-ratio anyone else have any info on large allocations for which we can calculate the "H-ratio"??? seems like collecting the values for a number of different things is an interesting bounds-check. -mo ps - anyone have the SMSA data that would give us the info to compute the H-ratio for zip-codes??? (both 7 & 11 digit) From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 02:45:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21463; Thu, 14 Jul 1994 00:45:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02523; Thu, 14 Jul 1994 00:44:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02452; Thu, 14 Jul 1994 00:27:48 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16618; Wed, 13 Jul 1994 22:22:56 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id IAA01079; Wed, 13 Jul 1994 08:22:38 -0400 From: Howard Berkowitz Message-Id: <199407131222.IAA01079@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: paul@vix.com (Paul A Vixie) Date: Wed, 13 Jul 1994 08:22:38 -0400 (EDT) Cc: big-Internet@munnari.OZ.AU In-Reply-To: from "Paul A Vixie" at Jul 12, 94 10:55:52 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3732 > > >Consider this 16-byte address: > > > > 192.26.92.75.72.96.180.125.135.66.32.69.237.59.250.195 > > When I saw my first 32-bit address in a VAX hex dump, I thought those 8-digit > numbers were monsters and that I'd never get used to them. > > When I saw my first 64-bit address in an Alpha hex dump, '' '' '' '' etc. > > History shows that we get used to this stuff after a while. > -- > Paul Vixie > Redwood City, CA > decwrl!vixie!paul > > I think Paul just put his finger on an implementation/operational issue that has been bothering me in the address length/format debate. [Nyaaah, Nyaaah. Yes, this is an ARCHITECTURAL debate. However, I believe it was Goethe that described architecture as frozen music. I am concerned that we develop an architecture that, when it thaws into products, does not flow as avant-garde jazz to people who are used to working with the Nitty Gritty Dirt Band]. Paul spoke of seeing his first 32 and 64 bit addresses in hex dumps. I think many of us have such a model in mind. Paul also, and correctly, said we got used to this stuff after a while. The problem, unfortunately, is with the meaning of us. Hex dumps are things that are perfectly usable to PROGRAMMERS and/or computer scientists (whatever the latter are :-; ). I strongly suspect that if I polled the last hundred or so router administration students I've had, I would find 10% or so have had programming experience. Of the remainder, most have never seen a dump, have marginal skills in working with hex, and even more marginal skills in masking and boolean logic/arithmetic in general. What does this have to do with the address issue? I see the market as driven by user requirements, and then cost-differentiated by service providers. Given that legacy products and networks are not going to convert overnight, and that they use hex or dotted decimal configuration and display mechanisms, they represent some reality. In order to gain market share for IPng, and minimize the conversion effort, I am trying to avoid extensive needs for masking and manimpulation of addresses. I don't insist things be on byte boundaries, but I lean in the direction of nibble alignment. Now, this will certainly lead to more sparse assignment than a bit string with fields of arbitrary length. It will increase overhead for the provider relays in their address decoding. But, unless I see more discussion of how this all relates to the operational configuration and fault analysis interface, I want to make the addresses somewhat more understandable. We have the RFC1597 vs. RFC1627 debate on whether private network numbers are a good thing. The reality I see is that users increasingly use private addresses, or, even worse, arbitrarily chosen real addresses, because they are not willing to deal with moderately complex subnetting. At some mercenary level, don't get me wrong. The more complex the address structure, the more consulting business I get. I recognize that we are at an early stage of the discussion, and that I am mentioning issues that are later in the product life cycle. But I plead with people to look at what the more naive user organizations are using. They are frightened of non-octet aligned subnet masks, they are avoiding OSPF and CIDR when those would be optimal technical solutions, and they like things like IPX. I know we have a revolution vs. improvement debate. I am concerned we will have a violent revolution vs. peaceful revolution, because more users may stay with the simpler mechanisms such as IPX until they collapse utterly. Of course, then we will see hacks on IPX to give it extended life. We will see CIPXDR. We will see IPXng.... Howard From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:02:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24273; Thu, 14 Jul 1994 02:04:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02717; Thu, 14 Jul 1994 02:04:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02712; Thu, 14 Jul 1994 01:59:36 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21152; Thu, 14 Jul 1994 00:37:58 +1000 (from skh@merit.edu) Received: from merit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06487 Thu, 14 Jul 1994 00:37:26 +1000 (from skh@merit.edu) Received: from localhost (skh@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA01973; Wed, 13 Jul 1994 10:32:13 -0400 Message-Id: <199407131432.KAA01973@merit.edu> To: Craig Metz Cc: Susan Hares , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 15:28:50 EDT." Date: Wed, 13 Jul 1994 10:32:11 -0400 From: Susan Hares Criag: Thanks for your note. I too look forward to autoconfiguration and discover algorithms coming into full play. CIDR does also have more ground to gain in the next year. As to the timeframe of the change, I was unclear. If we are wildly succesful maybe my home will have more electronics. A cable connection will be to a router that will branch to the rest of home computer equipment. I've had for 6 years my lights controlled by an now ancient X-10 device that allow computer control of electrical circuits. With that explosion, a 10 year revision may cause address. My concern is how much of the code in the stack will change. I sent a note to Mike O'Dell about percentage of change of code base. I think with your seemless and auto-configuration ideas, that my questions about the fact that only the address code changes are germane. I would to a migrating protocol, not a jump. Hence my VL ( variable) thoughts. Perhaps, you can respond to the query I sent to Mike with numbers from your code base. I'd be really interested. Thanks for your note. I Sue Hares From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:03:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25080; Thu, 14 Jul 1994 02:26:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02810; Thu, 14 Jul 1994 02:26:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02766; Thu, 14 Jul 1994 02:13:20 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22524; Thu, 14 Jul 1994 01:17:09 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14442(6)>; Wed, 13 Jul 1994 08:16:58 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 13 Jul 1994 08:16:48 -0700 To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: brian's message of Wed, 13 Jul 94 05:32:45 -0800. <9407131232.AA27331@dxcoms.cern.ch> Date: Wed, 13 Jul 1994 08:16:34 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul13.081648pdt.12171@skylark.parc.xerox.com> Brian, > ... > Which prejudices me in favour of topologically meaningful, > hierarchical locators. Nobody is arguing for anything other than topologically meaningful, hierarchical locators. If you think that my arguments are based on *not* having topologically meaningful, hierarchical locators, you need to do a reset. Steve From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:03:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24332; Thu, 14 Jul 1994 02:06:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02736; Thu, 14 Jul 1994 02:06:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02699; Thu, 14 Jul 1994 01:55:15 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20515; Thu, 14 Jul 1994 00:18:23 +1000 (from skh@merit.edu) Received: from localhost (skh@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA00296; Wed, 13 Jul 1994 10:18:04 -0400 Message-Id: <199407131418.KAA00296@merit.edu> To: "Mike O'Dell" Cc: Susan Hares , Jon Crowcroft , big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Tue, 12 Jul 1994 13:54:08 EDT." Date: Wed, 13 Jul 1994 10:18:03 -0400 From: Susan Hares Mike: Thanks for your note. I loved your comment on the future. I've never been convinced if I could see the future that people would want to hear about. I suspect the bad new and the good news would be mixed. Something about a prophet not being wanted in His own home town. Your nice note indicated that we really have two different viewpoints about the usage of Variable length. I think that when VL came in use in 5, 10, 15 years for the 1st growth need, we would as you said debug the "Variable length" and there would be some "Whammo!". BUT... I think there would be a lack of the "BIFF Sock ZAMM", of the rest of the code. Perhaps a way to help you and discuss this is to ask a question: How much of the BSD 4.4 or BSDI BSD 486 code base deals with length of packets or address, and how much of the IP handling code deals with other things. A percentage of the code lines could give a number on your WHAMMO of variable length code, and my "BIFF Sock Zamm" of the rest of the code. So, I suspect you might have some experience with this code base and could give us the answer of code lines. That would give us the answer of the VL code alone. As to the other pieces of the IP NG code, I would hope the IPng would look at other pieces of the header some variable length fields to allow new features to phased in. So.. more differences in our viewpoint. Again, your experience in code could greatly help us. What changes have been made to the IP header in the last 10-15 years? How many have been made in an incremental fashion? How many lines of code have been change per feature? My thought is the modular approach, a little at time please. Again, thanks for sending your comments to me. I'd love any numbers on code lines or development times you can send. Best wishes, Sue Hares From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:04:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26496; Thu, 14 Jul 1994 03:04:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02913; Thu, 14 Jul 1994 03:04:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02905; Thu, 14 Jul 1994 03:01:03 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25373; Thu, 14 Jul 1994 02:34:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01708; Wed, 13 Jul 94 12:34:01 -0400 Date: Wed, 13 Jul 94 12:34:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407131634.AA01708@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Steve Deering > Which prejudices me in favour of topologically meaningful, hierarchical > locators. Nobody is arguing for anything other than topologically meaningful, hierarchical locators. If you think that my arguments are based on *not* having topologically meaningful, hierarchical locators ... Err, I'm not sure what meaning you two are using for "locator", but Frank K came up with the word to describe something which i) was not necessarily present in all packets, and ii) did not identify a transport level entity. Since I'm pretty sure neither one of those corresponds with your thinking, I doubt you are in favor of "locators". :-) Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:04:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25113; Thu, 14 Jul 1994 02:28:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02829; Thu, 14 Jul 1994 02:27:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02779; Thu, 14 Jul 1994 02:17:50 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22656; Thu, 14 Jul 1994 01:23:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01085; Wed, 13 Jul 94 11:22:56 -0400 Date: Wed, 13 Jul 94 11:22:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407131522.AA01085@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, hcb@clark.net Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Howard Berkowitz >> Any set of assumptions that imply that people will handle 10 layers of >> hierarchies ... is bogus, because people will not handle them, because >> they cannot. > Really? People seem to be able to handle quite a few layers of hierarchy > in Unix file systems without blowing out. The principle is just the same; > it's a way of organizing lots and lots of stuff. if traditional file systems were as easy to handle as you suggest, the market would not have developed for the Mac user interface, Windows, etc. Ah, pardon me, I was being unclear. Mac folders are just a nice graphical representation of a multi-level hierarchical file system. The principle that your data is organized in a multi-level hierarchy is still the same. (I wonder how deep the average person gets with Mac folders, anyway? I imagine there are probably people with them nested 10 deep...) Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:06:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26548; Thu, 14 Jul 1994 03:06:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02928; Thu, 14 Jul 1994 03:06:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02902; Thu, 14 Jul 1994 02:56:41 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24320; Thu, 14 Jul 1994 02:06:20 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA20455; Wed, 13 Jul 94 11:07:48 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id bx01493; 13 Jul 94 16:02 GMT Date: Wed, 13 Jul 94 10:44 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Big Internet Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <31940713154413/0003858921NA3EM@mcimail.com> Steve Deering said: > (Maybe I am less concerned than many people with byte-aligned > address fields because I work for a company that has divided > its class A IP address space into 14 bits of subnet and 10 bits > of host. As far as I can tell, the lack of byte-aligned > field boundaries has not had a significant negative impact on > our bottom line.) I second this. I've said in a number of places on how Chrysler is bit twiddling all over the place, and our bottom line seems pretty good these days, in a fair measure to our network support of business goals. A good human interface to an agreed upon address format will allow the masses to not even realize that they too are spliting the address all over the place. Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:07:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26715; Thu, 14 Jul 1994 03:07:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02945; Thu, 14 Jul 1994 03:07:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02908; Thu, 14 Jul 1994 03:02:07 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24165; Thu, 14 Jul 1994 01:59:19 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id LAA04731; Wed, 13 Jul 1994 11:59:12 -0400 From: Howard Berkowitz Message-Id: <199407131559.LAA04731@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Jul 1994 11:59:10 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, hcb@clark.net, jnc@ginger.lcs.mit.edu In-Reply-To: <9407131522.AA01085@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 13, 94 11:22:56 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2816 > > From: Howard Berkowitz > > >> Any set of assumptions that imply that people will handle 10 layers of > >> hierarchies ... is bogus, because people will not handle them, because > >> they cannot. > > > Really? People seem to be able to handle quite a few layers of hierarchy > > in Unix file systems without blowing out. The principle is just the same; > > it's a way of organizing lots and lots of stuff. > > if traditional file systems were as easy to handle as you suggest, the > market would not have developed for the Mac user interface, Windows, etc. > > Ah, pardon me, I was being unclear. Mac folders are just a nice graphical > representation of a multi-level hierarchical file system. The principle that > your data is organized in a multi-level hierarchy is still the same. I agree that the Macintosh Hierarchical File System underlies the desktop metaphor. But, as you suggested, the average person doesn't build that complex a hierarchy. Unfortunately, those average persons are the ones being assigned in industry to manage routers. Again, my plea in architecture is occasionally to stop and get some sense whether a human interface metaphor can be developed to let the naive system administrator cope with the complex routing architecture we really need, or, if there is no clear metaphor, whether we can define requirements and strategy for expert systems/autoconfiguration/whatever to generate the necesary configuration. Let's return to your UNIX metaphor. The average user is unaware of the existence of a true root directory rather than $HOME. The average user, if on a system with NFS, is unaware of the mount protocol and the portmapper. But these things are really involved in the addressing of file objects. If I saved this editor session, it would simply go into my local directory. I could retrieve it with a single, non-hierarchical name. That name is what a naive user sees. In like manner, if we need to use complex 8- or 16-octet addresses with variable bit-oriented fields, we are going to have to have naming structures that can hide the details from the user, unless you need expect them also to handle the real addresses in distributed file systems. Taking UNIX a bit further, how straightforward is the hierarchical model when we start aliasing? Multihoming, etc., in network topology is even worse! Howard (I wonder > how deep the average person gets with Mac folders, anyway? I imagine there > are probably people with them nested 10 deep...) > > Noel Without real detailed analysis, I know I've got some about 7 deep, although I usually access those with UNIX scripts. Those that know me will not be surprised to see that I pile it very deep, especially when they see my physical desktop. :-) From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:08:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25177; Thu, 14 Jul 1994 02:29:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02844; Thu, 14 Jul 1994 02:29:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02772; Thu, 14 Jul 1994 02:15:17 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22257; Thu, 14 Jul 1994 01:09:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00972; Wed, 13 Jul 94 11:08:57 -0400 Date: Wed, 13 Jul 94 11:08:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407131508.AA00972@ginger.lcs.mit.edu> To: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU Subject: How many bits are enough? Cc: jnc@ginger.lcs.mit.edu From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > log (number of objects) > ----------------------- > available bits The globally-connected physics/space science DECnet (Phase IV) stopped growing at about 15K nodes ... Since the design goal is 10**12 networks ~= 10**15 nodes, we need 75 bits... I've just realized what's totally wrong with all these interminable calculations of how many bits/bytes we need. They all assume that the addressing hierarchy is going to have the same depth everywhere. Put another way, you need some sort of authority to create an address structure which has this kind of uniformity. One thing a world-wide internet is certainly *not* going to have is some sort of global authority which can assure that the tree is regular. So, these calculations about how many layers we need, at so many bits per layer are all pretty much useless, since they are talking about the *average* case, not the *worst* case. It would be interesting to know how much variance there is in the current internet; a sprawling, giant, world-wide network would almost certainly have more variance between min and max. This host is using three (site, wire, host), but I gather five (region, provider, site, wire, host) is fairly common. I imagine there would be growth (i.e. the curve would shift to the right) as the network gets larger, too. You can argue that we are getting these layers in a fixed size address now, but the inevitability is that more layers in a fixed size means less bits for each layer, and that's a dead-end street. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:08:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25222; Thu, 14 Jul 1994 02:32:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02861; Thu, 14 Jul 1994 02:32:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02763; Thu, 14 Jul 1994 02:10:39 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21535; Thu, 14 Jul 1994 00:50:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00827; Wed, 13 Jul 94 10:50:04 -0400 Date: Wed, 13 Jul 94 10:50:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407131450.AA00827@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, cmetz@thor.tjhsst.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Craig Metz > if IPv4 had longer addresses, do you think there would be any significant > pressure to change it? What make you so sure that a 30-year lifetime is > infeasible? If there is no reason to change it, then why are the IPng proposals on the table so radically different than just an IPv4 header with bigger addresses thrown in? Y'all can't have it both ways. Here I have the SIPP architect himself saying, in so many words, that SIPP is just IPv4 cleaned up some, with longer addresses. (Steve, if you feel that this is a misrepresentation, please adjust it.) Now, you're trying to tell me it's radically different. You can't both be right, and I (for once :-) side with Steve. Taking out the header checksum, TOS, and fragmentation, and all the other minor tweaks to speed processing, etc, is not radical change. The closest thing to a radical change in SIPP is the "flow" field. (I'm only talking about SIPP since, to be realistic, it's the only contender; as, I note, did you.) if IPv4 would be just fine with bigger addresses, then why are these changes necessary? They look like useful improvements to me Sure, they are useful improvements. Anytime you have a blank piece of paper, you might as well make minor cleanups as well as fix the big ones (for example, we could have added the flow field to IPv4 in an option). But, be serious; if SIPP had, say, header checksums, would it really affect the future one darn bit? I challenge you to find one thing in that list you gave which, if not changed, would make SIPP radically different. Sorry, Steve called this one right. SIPP is not radical change. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:24:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27276; Thu, 14 Jul 1994 03:24:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02980; Thu, 14 Jul 1994 03:24:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02977; Thu, 14 Jul 1994 03:19:38 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27152; Thu, 14 Jul 1994 03:19:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02052; Wed, 13 Jul 94 13:19:27 -0400 Date: Wed, 13 Jul 94 13:19:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407131719.AA02052@ginger.lcs.mit.edu> To: 0003858921@mcimail.com, Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: "Robert G. Moskowitz" <0003858921@mcimail.com> A good human interface to an agreed upon address format will allow the masses to not even realize that they too are spliting the address all over the place. Yes, but not even a good human interface will enable you to get 7 bits into a 5-bit field when that field fills up. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 03:26:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27300; Thu, 14 Jul 1994 03:26:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA03008; Thu, 14 Jul 1994 03:26:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02974; Thu, 14 Jul 1994 03:16:37 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26927; Thu, 14 Jul 1994 03:15:41 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 13 Jul 1994 13:15:38 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 13 Jul 1994 13:15:38 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA10854; Wed, 13 Jul 94 13:13:33 EDT Date: Wed, 13 Jul 94 13:13:33 EDT Message-Id: <9407131713.AA10854@mailserv-D.ftp.com> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: The right numbers (was Re: IPng ADs Wish to Gauge...) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU Content-Length: 1505 > > 35 years. It has a dial > >(remember them?). > > Frank > > one minor difference: > the internet is soft. a phone with a dial isn't It has nothing to do with hardware vs software. It has to do with the cost (in $, people's time, lost productivity, probability of introducing errors (and their effects), disruptions, etc etc etc) of making such a global change. We can not, today, require that people all change their hosts 'immediately' to support IPng. Many people are already admitting that IPv4 will be around for many years after IPng starts being fielded. I do not see how this will get any better. > we can re-program hosts and routers without having to write off their > bitmaps displays and qwerty keyboards Yes. We can. However, that does not mean that the new software will be fielded. There are many system administrators who do not upgrade the software on their machines when new releases come up unless they absolutely have to; specifically, the new release of the software is known to fixe a bug that is significant to them. I strongly believe that the next IP that gets developed will be the last one that gets globally fielded. By the time it starts breaking down it will be impossible to replace it. We will end up requiring a balkanized, multilingual internetwork. I would like to put this day off as long as possible... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 04:04:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28586; Thu, 14 Jul 1994 04:04:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03092; Thu, 14 Jul 1994 04:04:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03089; Thu, 14 Jul 1994 04:02:39 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28430; Thu, 14 Jul 1994 04:02:36 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id OAA10341; Wed, 13 Jul 1994 14:02:34 -0400 Date: Wed, 13 Jul 1994 14:02:34 -0400 From: Vadim Antonov Message-Id: <199407131802.OAA10341@titan.sprintlink.net> To: big-Internet@munnari.OZ.AU, paul@vix.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Paul Vixie wrote: >History shows that we get used to this stuff after a while. Yep. Some people even managed to get used to MS Windows. --vadim From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 04:25:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29326; Thu, 14 Jul 1994 04:25:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03134; Thu, 14 Jul 1994 04:24:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03126; Thu, 14 Jul 1994 04:15:14 +1000 Precedence: list From: daniel@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28957; Thu, 14 Jul 1994 04:15:06 +1000 (from daniel@ISI.EDU) Received: from dza.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 13 Jul 1994 11:15:03 -0700 Date: Wed, 13 Jul 94 11:14:55 PDT Posted-Date: Wed, 13 Jul 94 11:14:55 PDT Message-Id: <9407131814.AA00399@dza.isi.edu> Received: by dza.isi.edu (4.1/4.0.3-4) id ; Wed, 13 Jul 94 11:14:55 PDT To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU In-Reply-To: Noel Chiappa's message of Wed, 13 Jul 94 12:34:01 -0400 <9407131634.AA01708@ginger.lcs.mit.edu> Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: daniel@ISI.EDU From Noel Chiappa > From: Steve Deering >> Which prejudices me in favour of topologically meaningful, hierarchical >> locators. > Nobody is arguing for anything other than topologically meaningful, > hierarchical locators. If you think that my arguments are based on > *not* having topologically meaningful, hierarchical locators ... > Err, I'm not sure what meaning you two are using for "locator", but Frank K > came up with the word to describe something which i) was not necessarily > present in all packets, and ii) did not identify a transport level entity. > Since I'm pretty sure neither one of those corresponds with your thinking, > I doubt you are in favor of "locators". :-) > Noel And here all along I thought you had taken the IPv4 "address" and split it into two parts, "locator" and "EID", with the locator being the part that tells you where something is and the EID being the part that tells you what something is. Now you tell us that locators are also not necessarily present in all packets. Ok, so what is the name for a locator that *is* in every packet?? I try really hard not to use the dreaded word "address", but it is hard to keep up with your terminology. Daniel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 04:26:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29413; Thu, 14 Jul 1994 04:26:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03160; Thu, 14 Jul 1994 04:26:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03129; Thu, 14 Jul 1994 04:21:45 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29190; Thu, 14 Jul 1994 04:21:39 +1000 (from barney@databus.databus.com) Date: Wed, 13 Jul 94 14:23 EDT Message-Id: <9407131423.AA09018@databus.databus.com> From: Barney Wolff To: kasten@ftp.com Cc: Big-Internet@munnari.OZ.AU Subject: Re: The right numbers (was Re: IPng ADs Wish to Gauge...) Content-Length: 1480 Content-Type: text > Date: Wed, 13 Jul 94 09:54:32 EDT > From: kasten@ftp.com (Frank Kastenholz) > > If the Internet becomes the Global Information Super-Infra-Bahn- > Highway-Structure-thing then its technology will last forever. My > parents have a telephone that they've had for 35 years. It has a dial > (remember them?). It still works with the phone network just fine. I > have an old phone from the 1920s -- you know, the kind with the > separate microphone and speaker? A few years ago I jury-rigged it up > and it worked just fine. Pulse dialing and 70 year-old technology > still work on the phone network. If and when the Internet becomes as > ubiquitous as the phone network, our equivalent of pulse dialing and > analog voice lines will be around for a long long long long time. This seems to be the reasoning of the variable folks, that the address space must last literally forever. But there is another incompatible assumption being made at the same time: that the number of devices and networks will be doubling every year, at least for the next 25 years. That's implied by the 1e12 nets & 1e15 devices target. But if that growth rate is real, compatibility issues have a strictly limited scope, as after 7 years less than 1% of the total population is the "old" style. The reason pulse dialing still works today is that the growth rate in phones is low enough that there is still a significant proportion of the total which is pulse-only. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 05:04:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00756; Thu, 14 Jul 1994 05:04:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA03211; Thu, 14 Jul 1994 05:04:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA03204; Thu, 14 Jul 1994 05:01:45 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00690; Thu, 14 Jul 1994 05:01:41 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty11.jvnc.net. (franklin-tty11.jvnc.net) by tigger.jvnc.net with SMTP id AA16059 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Wed, 13 Jul 1994 15:01:34 -0400 Message-Id: Date: Wed, 13 Jul 94 15:00:34 EDT From: "David M. Piscitello" Subject: Clarification on definition of red herring... Reply-To: dave@corecom.com To: "Big Internets" X-Mailer: VersaTerm Link v1.1.1 Are they fixed or variable length? David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 05:06:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00815; Thu, 14 Jul 1994 05:06:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA03234; Thu, 14 Jul 1994 05:06:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA03201; Thu, 14 Jul 1994 05:01:40 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00688; Thu, 14 Jul 1994 05:01:38 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty11.jvnc.net. (franklin-tty11.jvnc.net) by tigger.jvnc.net with SMTP id AA15997 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Wed, 13 Jul 1994 15:00:48 -0400 Message-Id: Date: Wed, 13 Jul 94 14:59:48 EDT From: "David M. Piscitello" Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: dave@corecom.com To: "Steve Deering" , "Noel Chiappa" Cc: big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 "Systems" don't squander the address space; the term "squandering" is pejorative and misleading, especially if you are using it in juxtaposition to "densely assigned". For both good and bad reasons, folks choose to populate various levels of addressing hierarchy "loosely". >As I said, there are lots of ways of squandering address space. It's also >possible to design a system that does *not* squander address space, which >is what I am advocating. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 05:24:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01541; Thu, 14 Jul 1994 05:24:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA03261; Thu, 14 Jul 1994 05:24:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA03210; Thu, 14 Jul 1994 05:04:41 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00748; Thu, 14 Jul 1994 05:04:33 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id PAA11052; Wed, 13 Jul 1994 15:04:25 -0400 Date: Wed, 13 Jul 1994 15:04:25 -0400 From: Vadim Antonov Message-Id: <199407131904.PAA11052@titan.sprintlink.net> To: mo@uunet.uu.net, skh@merit.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Sue Harris wrote: > My thought is the modular approach, a little at time please. The modular approach is something different from the "little at time" which is better known as creeping featurism. The *real* modular approach assumes functionally complete modules which never have to be changed again (at least interface-wise). Transport level is reasonably close to be such a complete module -- we need to define *function* and make sure the protocol takes care of all cases with no exception and then make it as simple as possible. Adding features step-by-step is the best way to produce a monster. OS people are consistently getting into that trap up to the point that modern systems reached the point where dealing with them requires super-human abilities or, alternatively, deliberate castration of the systems :-( --vadim From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 05:26:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01571; Thu, 14 Jul 1994 05:26:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA03289; Thu, 14 Jul 1994 05:26:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA03220; Thu, 14 Jul 1994 05:05:13 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00770; Thu, 14 Jul 1994 05:05:10 +1000 (from jdemarco@ftp.com) Received: by ftp.com ; Wed, 13 Jul 1994 15:05:06 -0400 Received: by ftp.com ; Wed, 13 Jul 1994 15:05:06 -0400 Date: Wed, 13 Jul 1994 15:05:06 -0400 From: jdemarco@ftp.com (Jim DeMarco) Message-Id: <9407131905.AA18574@ftp.com> To: vjs@rhyolite.denver.sgi.com Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Vernon Schryver's message of Wed, 13 Jul 94 08:18:19 -0600 <9407131418.AA22414@rhyolite.denver.sgi.com> Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: jdemarco@ftp.com >Please explain why it is that IPng should be following the path that >lead to disaster. Please explain why OSI's failure was unrelated to >what ISO tried to do and how they tried to do it. Otherwise, please >explain why doing things the ISO way (cover all bases until the end of >time) will work for IPng when it failed for OSI. >[...some comments deleted...] >I don't mean to imply that everyone who favors giant, variable IPng >addresses is an escapee from the ISO directorate. I would like to >point out that the philosphies and design principles that failed for >the ISO seem likely to fail for the IETF, and that it would be prudent >for people who do not want an OSI-outcome to do things differently. FWIW, although I personally happen to agree with your main point (which, I believe, is to fanatically adhere to the K.I.S.S. principle), I also believe that a couple of factors greatly benefitted TCP/IP's rise and acceptance. In no particular order, (a) The US DoD funded a good, inexpensive, and accessible, implementation of the TCP/IP suite (vis-a-vis the BSD code). Having a reference implementation to start with, many people could then go about improving on it. (b) The specifications for all the protocols were and are reasonably simple, but more importantly FREELY AVAILABLE. Anyone could get a hold of the specs without spending a fortune, and their availability ON-LINE in electronic form was and is invaluable. (c) People started implementing, testing, debugging, revising (i.e. INTEROPERATING) from the beginning. If those who are designing IPng were FORCED to use it NOW instead of IPv4 for their day-to-day work, a preliminary IPng would be working within a week :-) --Jim From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 05:48:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27933; Thu, 14 Jul 1994 03:44:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA03043; Thu, 14 Jul 1994 03:44:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA03019; Thu, 14 Jul 1994 03:28:11 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27348; Thu, 14 Jul 1994 03:28:01 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id KAA07038; Wed, 13 Jul 1994 10:27:53 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA22334; Wed, 13 Jul 94 07:55:02 -0600 Date: Wed, 13 Jul 94 07:55:02 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407131355.AA22334@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs request >From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > ... >Remember, the original IP address format had 256 network numbers; the class >A/B/C stuff was in itself a relatively *late* kludge, post '80, and subnets >are even late than that. The Xerox Altos only date from the mid-70's, and >before that it was all timesharing; millions of workstations weren't even a >gleam in Jobs'/Gates'/etc eyes back then. Etc, etc. > >Certainly, when I joined the IP effort back then, if you'd told us that within >20 years the Internet would be the practical basis of the worldwide data >network, and you'd be able to send email to the NBC Nightly News, we'd have >rolled on the floor laughing, wondering what drugs (or neuro-transmitter >disorder :-) you were on. That's strange. As an user of the ARPANET in the early 1970's, I had the impression that a world-wide network with connections to the NBC Nightly News was exactly what was envisioned. I and many of my friends had terminals at home that we used to send email around and read and search the wire service news. Perhaps few thought that those clunky, bulky IMP's and TIP's would have anything to do with the distant future. Perhaps dumb terminals, modems, and timesharing machines with network links were what people thought of. It's hard to say what time scale people were thinking of. In any case, what's your point? Somehow, I doubt that you are saying that since the very simple addressing scheme choosen 15 or 20 years ago was wildly successful for almost 30 years (1970s' to 2000's), and since the design lifetime of IPng is about 20 years, we should therefore use a simple, fixed length address, something just as much longer that 32-bits was compared to the number of hosts at the time. If you were saying that, then you would be arguing for a fixed length of at most 16 bytes. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 05:48:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27982; Thu, 14 Jul 1994 03:46:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA03062; Thu, 14 Jul 1994 03:46:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA03016; Thu, 14 Jul 1994 03:27:54 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27339; Thu, 14 Jul 1994 03:27:44 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id KAA06911; Wed, 13 Jul 1994 10:27:36 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA22414; Wed, 13 Jul 94 08:18:19 -0600 Date: Wed, 13 Jul 94 08:18:19 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407131418.AA22414@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements >From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > > From: "Mike O'Dell" > > I don't believe having variable length address available will solve the > kind of dislocation which one should expect in 30 years of technology > evolution ... In general, I think it is NUTS to actually believe that any > decision we make now is going to be "right" 30 years from now without > significant revision. ... it's hard to imagine that simply being able to > increase the address size alone will keep IPng viable for 20 or 30 years - > in that timeframe, SOMETHING else about the protocol will need to change > and almost certainly significantly. > >IP was initially done in the mid-70's. It's now basically 20 years later, and >if IPv4 had longer addresses, do you think there would be any significant >pressure to change it? What make you so sure that a 30-year lifetime is >infeasible? There were two sets of protocols designed in the 70's and early 80's. 1. One was quick and dirty, and will have lasted at least 30 years (70's to 2000's). 2. The other was a big committee effort that tried to cover all of the bases, be flexible, complete, and design for a long time. In that pair: a. which was completed and deployed in less than 15 years? b. which is dead, never having been important? c. which had variable length addresses? d. which had very long addresses? e. which was able to change and evolve to meet changing circumstances? (eg. CIDR, subnets, TCP-LW) f. which performs better (eg. what's the fastest TP4 speed over HIPPI or any other medium you've heard of?) Please explain why it is that IPng should be following the path that lead to disaster. Please explain why OSI's failure was unrelated to what ISO tried to do and how they tried to do it. Otherwise, please explain why doing things the ISO way (cover all bases until the end of time) will work for IPng when it failed for OSI. Have you ever worked at a successful computer company, seen a bunch of people hired from less successful or dieing competators? Ever notice that while those people were very glad to get away from the bad organization, they want desparately to do things the way they were done at their bad old company instead of the way they were done at the new, better company? I don't mean to imply that everyone who favors giant, variable IPng addresses is an escapee from the ISO directorate. I would like to point out that the philosphies and design principles that failed for the ISO seem likely to fail for the IETF, and that it would be prudent for people who do not want an OSI-outcome to do things differently. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 06:49:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03034; Thu, 14 Jul 1994 06:05:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03335; Thu, 14 Jul 1994 06:04:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA03319; Thu, 14 Jul 1994 05:49:40 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00679; Thu, 14 Jul 1994 05:01:16 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty11.jvnc.net. (franklin-tty11.jvnc.net) by tigger.jvnc.net with SMTP id AA16007 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Wed, 13 Jul 1994 15:00:56 -0400 Message-Id: Date: Wed, 13 Jul 94 14:59:56 EDT From: "David M. Piscitello" Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: dave@corecom.com To: "Steve Deering" , "Noel Chiappa" Cc: big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 >Hmm. I think I was also bold to specify fixed-length, 8-byte addresses. :-) >Steve You among others. I seem to recall a proposal from (UCL?) that was never given its due that basically suggested stretching the address fields of the IPv4 packet to accommodate 8 octets. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 07:42:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05141; Thu, 14 Jul 1994 07:05:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03470; Thu, 14 Jul 1994 07:05:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03448; Thu, 14 Jul 1994 06:56:54 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03191; Thu, 14 Jul 1994 06:12:54 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id QAA00967; Wed, 13 Jul 1994 16:12:38 -0400 From: Howard Berkowitz Message-Id: <199407132012.QAA00967@clark.net> Subject: Re: Clarification on definition of red herring... To: dave@corecom.com Date: Wed, 13 Jul 1994 16:12:35 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "David M. Piscitello" at Jul 13, 94 03:00:34 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 160 > > Are they fixed or variable length? > David M. Piscitello Not sure, but whenever they reach a certain length, they spawn lots of little mobile processes. From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 07:43:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05122; Thu, 14 Jul 1994 07:04:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03453; Thu, 14 Jul 1994 07:04:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03406; Thu, 14 Jul 1994 06:46:00 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03044; Thu, 14 Jul 1994 06:05:23 +1000 (from brian@dxcoms.cern.ch) Received: from dxmint.cern.ch by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09979 Thu, 14 Jul 1994 05:50:42 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26210; Wed, 13 Jul 1994 21:48:18 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA06973; Wed, 13 Jul 1994 21:47:59 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407131947.AA06973@dxcoms.cern.ch> Subject: Re: Clarification on definition of red herring... To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 13 Jul 1994 21:47:59 +0200 (MET DST) In-Reply-To: from "David M. Piscitello" at Jul 13, 94 03:00:34 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 101 > > Are they fixed or variable length? > David M. Piscitello Flexible, in my experience Brian From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 07:43:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04546; Thu, 14 Jul 1994 06:44:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03395; Thu, 14 Jul 1994 06:44:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03379; Thu, 14 Jul 1994 06:39:30 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04382; Thu, 14 Jul 1994 06:39:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03919; Wed, 13 Jul 94 16:39:24 -0400 Date: Wed, 13 Jul 94 16:39:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407132039.AA03919@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, daniel@isi.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: daniel@isi.edu And here all along I thought you had taken the IPv4 "address" and split it into two parts, "locator" and "EID", with the locator being the part that tells you where something is and the EID being the part that tells you what something is. Now you tell us that locators are also not necessarily present in all packets. Ok, so what is the name for a locator that *is* in every packet?? To be honest, I don't have a name for that particular concept (I never was interested in that possibility :-). Feel free to create one! For those who are wondering what on earth the difference is, an "address" a la IPv4 does 3 things: i) it serves to indentifier the tranport level entity, ii) it's the field in every packet which the says where it is going, and iii) it tells you where in the network the thing is. I decided I wanted to be able to think about these threee functions separately, and split the three up. The jargon for each of them, in order above, is i) TLEN (of which the EID is an example), ii) selector, and iii) locator. (My assumption at the time was that everyone would recognize that the "locator", by definition, doesn't have to be in every packet since the "selector" is; I realize this isn't very obvious, and my apologies.) Anyway, the difference between an "address" (as used in IPv4, since I'm not sure there is an agreed on definition) and this new thing (which is both a "locator" and a "selector", using the terminology above) would be that the address is *also* a TLEN, whereas this new thing would not be. I try really hard not to use the dreaded word "address", but it is hard to keep up with your terminology. Sorry. Every so often I try and set things straight, but not everybody likes the definitions I give, so it's an ongoing debacle. I apologized for any lack of clarity in my explanations of what all these things are.... Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 07:44:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05164; Thu, 14 Jul 1994 07:07:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03487; Thu, 14 Jul 1994 07:06:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03409; Thu, 14 Jul 1994 06:46:05 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03048; Thu, 14 Jul 1994 06:05:33 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10013 Thu, 14 Jul 1994 05:55:40 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA06295; Wed, 13 Jul 94 15:52:52 EDT Message-Id: <9407131952.AA06295@tipper.oit.unc.edu> To: dave@corecom.com Cc: "Big Internets" Subject: Re: Clarification on definition of red herring... In-Reply-To: Your message of "Wed, 13 Jul 94 15:00:34 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Jul 94 15:52:49 -0400 From: Simon E Spero I don't know. The ISO variation (the Pink Herring) is variable length, but profiles may impose restrictions. However, herrings do offer a useful precedent for deciding contentious issues. In 1989, Oxford and Cambridge had competing bids for the 1990 UNICON. We were able to resolve the issue by having the two parties nominate a champion, who then engaged in a duel of honour, armed only with their native cunning, and a brace of fresh herring. Simon From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 07:45:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04583; Thu, 14 Jul 1994 06:46:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03418; Thu, 14 Jul 1994 06:46:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03374; Thu, 14 Jul 1994 06:33:12 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04127; Thu, 14 Jul 1994 06:33:08 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Wed, 13 Jul 1994 10:07:28 -0400." <9407131407.AA00584@ginger.lcs.mit.edu> Date: Thu, 14 Jul 1994 06:33:03 +1000 Message-Id: <27904.774131583@munnari.OZ.AU> From: Robert Elz Date: Wed, 13 Jul 94 10:07:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9407131407.AA00584@ginger.lcs.mit.edu> Now, extend the graph; you need to draw an even larger circle to enclose the whole thing; you have extended the address on the left after they were all assigned. A few messages sent to me off the list made the same point (using several different terminologies, but that doesn't matter). Its also not useful in general, except in the rare case where you want to join together two networks and unify their addressing - adding a prefix that says "this was from A" and "this was from B" then leaving the rest of the addresses alone works well provided the two nets remain mostly disjoint. Upon reading the several notes that suggested this, I have come to realise that what is wanted isn't a super-circle around the outside, but lots more circles inside some existing circle(s). That is... Even better would be the ability to also insert bytes in the middle of addresses - we don't know how to make that work either. except rather than "even better", I now say "essential" to make variable addressing feasible to grow the address space in a way that's actually useful. With fixed CIDR-like bit-packing, it is basically impossible. Which is why I prefer a syntax for locators which has some "markers" in it to delineate the fields; you can extend one field without having a big hassle. Yes, something with explicit labels inside delineating the address sub-fields would work. It also breaks longest match type routing totally. I don't think we're ready for this yet. This is something that still needs more work. That is, I don't think its currently feasible for anyone to build a forwarding engine that can process useful variable length addreesses - because we don't know what they look like. The effect of this is that if/when we want/need variable length addressing (perhaps when nimrod, or something similar is ready for the world) we're going to have to redefine the net layer. Or rather, we're going to have to reimplement the all of the network layer code everywhere - if we had a variable length field in the packet we may not need to change the bit layouts, but I don't see that that buys us anything if every node has to be altered anyway. This is also why I believe (you can't imagine how strongly, or maybe you can Noel, but many others don't) that we simply must divorce node (endpoint) identification from addressing. If we do that we can (not easily, but feasibly) connect together regions of old and new net layer technology, allowing transport to flow from one to the other without grief. kre From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 07:45:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05186; Thu, 14 Jul 1994 07:08:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03504; Thu, 14 Jul 1994 07:08:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03434; Thu, 14 Jul 1994 06:48:12 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03050; Thu, 14 Jul 1994 06:05:38 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from SGI.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09975 Thu, 14 Jul 1994 05:50:10 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id MAA17241; Wed, 13 Jul 1994 12:47:23 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA23480; Wed, 13 Jul 94 13:46:39 -0600 Date: Wed, 13 Jul 94 13:46:39 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407131946.AA23480@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: hcb@clark.net (Howard Berkowitz) > ... > Paul spoke of seeing his first 32 and 64 bit addresses in hex dumps. > I think many of us have such a model in mind. > Paul also, and correctly, said we got used to this stuff after a while. Both you and Paul are wrong. There was a qualitative difference between dealing with 16 bit and 32 bit computer addresses. We could and did talk about 4-digit hex. addresses and 6 digit octal addresses. (The computers I programmed in my first 8 years in the business used 22, 24, 16, 12, 8, 48, and 60 bit words). However, 8 digit hex addresses are too long for conversation. The only 8 digit addresses people use in conversation do not have 8 significant digits. They have lots of 0's, f's, or a fixed prefix. No one, NO ONE! can handle 64-bit addresses, except in trivial cases where most of the digits are 0's or f's. It is no accident that U.S. phone numbers are only 7 digits long, with occassional 3, 8, and 10 digit prefixes. Humans short term memory does not handle more than about 6 or 7 things at a time. What you cannot remember, you cannot talk about or deal with. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 08:25:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07769; Thu, 14 Jul 1994 08:25:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA03647; Thu, 14 Jul 1994 08:24:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA03630; Thu, 14 Jul 1994 08:07:00 +1000 Precedence: list Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07150; Thu, 14 Jul 1994 08:06:52 +1000 (from news@vix.com) Received: by gw.home.vix.com id AA01234; Wed, 13 Jul 94 15:06:49 -0700 Date: Wed, 13 Jul 94 15:06:49 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: big-Internet@munnari.OZ.AU From: paul@vix.com (Paul A Vixie) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Organization: Vixie Enterprises Message-Id: References: <9407131946.AA23480@rhyolite.denver.sgi.com> Nntp-Posting-Host: office.home.vix.com In-Reply-To: vjs@rhyolite.denver.sgi.com's message of 13 Jul 1994 14:37:46 -0700 >No one, NO ONE! can handle 64-bit addresses, except in trivial cases >where most of the digits are 0's or f's. > >It is no accident that U.S. phone numbers are only 7 digits long, with >occassional 3, 8, and 10 digit prefixes. > >Humans short term memory does not handle more than about 6 or 7 things >at a time. What you cannot remember, you cannot talk about or deal with. Hey, I know what we can do. I mean, Vern's right as usual. So let's design a system whereby the average user doesn't need to know about addresses or talk about them. We'll let them use symbolic names for their hosts and other net objects. We could organize the names into hierarchies. Let's call those hierarchy levels "domains". Hmmm. Let's call the whole thing the "domain name system". Would it help if I wrote up an RFC for this? Oh, sh*t, someone named PVM@ISI.EDU has beaten me to it. Do you suppose his stuff will work? -- Paul Vixie Redwood City, CA decwrl!vixie!paul From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 08:27:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07896; Thu, 14 Jul 1994 08:27:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA03677; Thu, 14 Jul 1994 08:27:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA03644; Thu, 14 Jul 1994 08:19:24 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07471; Thu, 14 Jul 1994 08:19:08 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:big-internet@munnari.oz.au> id PAA15089; Wed, 13 Jul 1994 15:18:58 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:big-internet@munnari.oz.au id AA24032; Wed, 13 Jul 94 16:18:22 -0600 Date: Wed, 13 Jul 94 16:18:22 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407132218.AA24032@rhyolite.denver.sgi.com> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > ... > I would like to point out that the philosphies and design principles that > failed for the ISO seem likely to fail for the IETF, and that it would be > prudent for people who do not want an OSI-outcome to do things differently. > > Your apparent vendetta against the "OSI mentality" (not your phrase, I know) > is interesting in an odd sort of what; makes me curious as to why. I mean, I > sued to have some pretty hard things to say about them, but it's time to move > on, don't you think? > > Sure, there were serious strategic defects in their goals and methods, but > that doesn't mean every single thing they did was wrong. In fact, I'd be > pretty astonished if every single thing was wrong; that's only slightly less > likely than getting everything right. Rather than beat up on them for some > strange internal reason, maybe you should study what they did, and come to > independent technical conclusions as to what's right and wrong in their > designs, and why. The problem in the ISO was not in the technical details designs, but in what they wanted to do and how they went about it. What they did technically right or wrong is a red herring. Unless the IETF avoids the ISO style of development, IPng will have the same fate as the OSI protocols. Style begats substance when you are dealing with committees, whether the IETF or the ISO. The ISO people set out to Solve The Problem For the Foreseeable Future. Instead of quick hacks that would work for a while and get some information for the next step (i.e. TCP), they had larger and more "professional and operational" ambitions. Goal inflation is almost inevitiably with committees. Every committee tries to do as much as possible, making as many members happy on as many subjects for as long as possible. Members think of themselves not as mere programmers and observers but as Network Architects, or at least Apprentice Network Architects. Thus, the ISO had TP0 through TP4 and CONS as well as CLNS, to satisfy all constinuencies and contingencies forever, all in a Correct 7-Layer Architecture. Thus, every time someone says "IPng should last X years," someone else says "no, the transition will be painful; it must be X+5 years". Every time someone says "N hosts with E addressing efficiency in L levels," someone else says "no, N*10 hosts and E/10 efficiency and support 2L levels." Every time someone says "this'll work", someone else says "yes, but that's not good enough because we must have a proper architecture." Thus, both the ISO and the IETF burn years of the original, declared design life of their protocols with little to show and nothing to deploy. Yes, the ISO blew about 15 years, while the IETF has so far spent only 4 years. (It is only 4, isn't it?) The problem of the OSI protocols was not that they were irredeamably bad, but that by the time they were ready to be implemented, they had bloated beyond belief and few cared to solve the problems they were intended to solve. Both of those are beginning to happen to IPng. IPng has already bloated beyond the anyone's belief a few years ago, and threatens to go all the OSI way. (Consider the note today in this mailing list advocating making more fields than the addresses variable.) 4 years is a long time for a protocol that is only intended to last 20 or 30 years. By the way, I'm irritated by some recent statements. The fate of the OSI protocols had nothing to do with - who funded them--The DoD spent far more on OSI code than Berekley ever conceived of asking for. - whether the documents had to be bought at $100/copy from ANSI or Global Engineering Documents, Inc., or FTP'ed "for free" over $20,000/year Internet connections. - electronic communication--committees are committees. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 09:58:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10854; Thu, 14 Jul 1994 09:45:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03771; Thu, 14 Jul 1994 09:44:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03743; Thu, 14 Jul 1994 09:28:19 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05668; Thu, 14 Jul 1994 07:29:35 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA07053; Wed, 13 Jul 94 16:31:22 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id cb21169; 13 Jul 94 21:25 GMT Date: Wed, 13 Jul 94 15:41 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: "Brian.Carpenter" To: bigi Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <92940713204129/0003858921NA1EM@mcimail.com> Deering said: > And if everyone really does decide that EIDs are indispensible, I > hope you'll consider making them be the low-order 8 bytes of a > 16-byte address, rather than additional header fields. > Carpenter said: >I have to push back a bit on this. If 8-byte EIDs become a mandatory >part of the address (=locator+EID), then as far as I can see 16 bytes are >no longer sure to be enough, because there would only be 8 bytes of >locator (which IMHO is insufficient for the long term). So mandatory EIDs >would actually change my vote in the Directorate sraw poll that Scott >posted. Would you still say this in a situation where locator gets you to the segment that the system resides on an EID is still needed to get to the actual system. Thus locator + EID is the full access path, EID is all you need for local traffic, and locator somehow indicates a router interface (of course the router has its own EID). Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 09:58:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11079; Thu, 14 Jul 1994 09:49:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03786; Thu, 14 Jul 1994 09:49:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03746; Thu, 14 Jul 1994 09:28:24 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05669; Thu, 14 Jul 1994 07:29:35 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA07068; Wed, 13 Jul 94 16:31:30 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ce21169; 13 Jul 94 21:26 GMT Date: Wed, 13 Jul 94 15:41 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <24940713204142/0003858921NA1EM@mcimail.com> Jon Crowcroft said: >the only thing i konw of tha argues for variable is the requirement of >_low bandwidthj_ to not incur the header overhead (i.e. the >requirement to not use the 'longest so far'). >however, if most the low bandwidth is mobile, it needs the biggest >address space and most flexibility, and probably multicast and TOS >etc etc, and so the largest fixed length better also be the biggest >the worst case can tolerate.... I had an interesting thought about these big addresses and their effect on mobile bandwidth. The locator part of a mobile user is really the locator for their network attachment point. Thus in practice, it might not have to flow over the link except on setup time and it can be stripped out of the packet. Only the EID is required to pass over the link. Now more experienced hands might point out to me that the overhead of recalculating CRC checks does not benefit the slow connection, but 8 bytes per packet (or more) is 8 bytes less to send. We still have a lot that is slower than V.32bis... Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 09:58:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11107; Thu, 14 Jul 1994 09:50:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03805; Thu, 14 Jul 1994 09:50:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03752; Thu, 14 Jul 1994 09:36:28 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06729; Thu, 14 Jul 1994 07:58:00 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA06497; Wed, 13 Jul 1994 14:57:50 -0700 Message-Id: <199407132157.OAA06497@Mordor.Stanford.EDU> To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Cc: Big-Internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 13 Jul 94 13:46:39 -0600. <9407131946.AA23480@rhyolite.denver.sgi.com> Date: Wed, 13 Jul 94 14:57:50 -0700 From: Dave Crocker X-Mts: smtp To underscore some of Vernon's comments... ---- Included message: It is no accident that U.S. phone numbers are only 7 digits long, with occassional 3, 8, and 10 digit prefixes. Humans short term memory does not handle more than about 6 or 7 things at a time. What you cannot remember, you cannot talk about or deal with. It is important to note that telephone numbers are represented with partitioning. The short-term memory limit (7 plus/minus 2) refers to a single string of serially-related digits. The technique we use to handle longer strings is to 'chunk' them. That said, there is a worse limit on 'hierarchy' which seems to be two- or three-deep for average folk. Worse, the limit of 7 for serial is statistical; if you want to improve the statistics on the number of people who remember or process the string, you need to drop it to 5. The point, here, is that this is all very, very well-understood psychology and human factors stuff. We should be careful to factor in those considerations before making assertions of what is easy/feasible and we should be very, very careful about our sampling technique when we cite capabilties from our personal knowledge. For example, programmers seem to be dramatically better at juggling arbitrary detail than are average folks. Dave From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 09:59:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11150; Thu, 14 Jul 1994 09:51:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03822; Thu, 14 Jul 1994 09:51:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03749; Thu, 14 Jul 1994 09:29:42 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05281; Thu, 14 Jul 1994 07:13:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04120; Wed, 13 Jul 94 17:13:43 -0400 Date: Wed, 13 Jul 94 17:13:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407132113.AA04120@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) c. which had variable length addresses? d. which had very long addresses? Are you trying to imply that if the entire ISO stack (which included a lot make than CLNP, remember) had used short, fixed-length addresses, it would have succeeded? I'm sure you know that would be a ridiculous assertion. (I have this vision of all the people who worked on ISO smacking their foreheads, saying "Gee, if only we'd used fixed length addresses we'd have blown those TCP/IP amateurs away". Right.) The ISO stack failed to catch on for a number of reasons, but variable length addresses had next to nothing to do with it. Please explain why it is that IPng should be following the path that lead to disaster. You seem to be suffering from the delusion that CLNP's use of variable length addresses is what caused it to fail. As an intellectual exercise, try listing all the reasons it failed (nothing that big fails for a single reason), and putting them in importance order. Please explain why OSI's failure was unrelated to what ISO tried to do and how they tried to do it. Are you sure you don't want me to also prove that 2+2 is not equal to 4? Of course ISO's failure was related to what they tried to do, and how they tried to do it. I would like to point out that the philosphies and design principles that failed for the ISO seem likely to fail for the IETF, and that it would be prudent for people who do not want an OSI-outcome to do things differently. Your apparent vendetta against the "OSI mentality" (not your phrase, I know) is interesting in an odd sort of what; makes me curious as to why. I mean, I sued to have some pretty hard things to say about them, but it's time to move on, don't you think? Sure, there were serious strategic defects in their goals and methods, but that doesn't mean every single thing they did was wrong. In fact, I'd be pretty astonished if every single thing was wrong; that's only slightly less likely than getting everything right. Rather than beat up on them for some strange internal reason, maybe you should study what they did, and come to independent technical conclusions as to what's right and wrong in their designs, and why. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 09:59:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11194; Thu, 14 Jul 1994 09:52:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03837; Thu, 14 Jul 1994 09:52:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03755; Thu, 14 Jul 1994 09:36:40 +1000 Precedence: list Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04581; Thu, 14 Jul 1994 06:46:37 +1000 (from news@vix.com) Received: by gw.home.vix.com id AA28962; Wed, 13 Jul 94 13:46:25 -0700 Date: Wed, 13 Jul 94 13:46:25 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: big-Internet@munnari.OZ.AU From: paul@vix.com (Paul A Vixie) Subject: Re: why not variable length? Organization: Vixie Enterprises Message-Id: References: Nntp-Posting-Host: office.home.vix.com In-Reply-To: cmetz@thor.tjhsst.edu's message of 13 Jul 1994 05:34:29 -0700 (Checking in from the home for recalcitrant middle aged punks) > The reasons I can think of for sixteen bytes are: > > * MAC-based local use addresses (putting, for instance, the IEEE > 6-byte MAC address space inside an 8-byte address space > eats 1/65536th of your address space right there. These > are big chunks being taken out of your address space, and > they add up quickly) Use ARP. Don't glop up a global addressing paradigm by trying to use it as a container for ... oh, geez ... another global addressing paradigm. There is no reason to encode MAC-level addresses, either IEEE 48-bit ones, Appletalk ones, or any other kind. Use ARP. Encoding IPv4 addresses inside IPng ones is also backwards, for approximately but not exactly the same reasons. IPv4 will be tunnelled, but still routed in a virtual kind of way. I can say that with authority because I know the way the implementation has to happen in the BSD reference implementation. If you guys specify address encapsulation, reachability will still be established with tunnelling whenever people get around to actually implementing this stuff. Why not go with the flow? Use ARP. > * Extra space for heirarchial routing (which should help to > lessen the amount of routing information individual > routers need to carry -- a big win when you think about > the kind of growth we expect and the kind of performance > that will be expected of future routers) I challenge anyone -- ANYONE -- on this list (or any other list?) to please show me some hierarchy which has stood the test of time without having to have layers inserted or appended to it. The closest thing I can think of was the US Postal System, but then I remembered ZIP codes, and ZIP+4 codes. Whatever hierarchy you can come up with, the real world will stretch in ways you cannot anticipate. Therefore unless address assignment is 100% dynamic, coming from the service providers and other "core" nets, with no name binding except the dynamic kind, your plans for hierarchy are necessarily shortsighted. What this means in practice is that we will always have routing protocols but that as time goes on, fewer and fewer end hosts will have enough virtual memory or network bandwidth to actually speak them; GDP's and static exit gateways will become the "only" way rather than the "common" way for hosts (and leaf nets) to interconnect. We're seeing that already with BGP-4 and CIDR's. Hierarchical routing is not just a bad idea -- it's criminally foolish to design an addressing paradigm around the assumption of having hierarchy for more than the first few years of roll-out. As soon as you decide on a hierarchy, the providers will start shifting around, buying each other, merging, splitting apart, forming supernets, requiring more levels in the hierarchy, requiring customer net numbers to change every time this happens. (Check to see how multiple-provider ISO users suffer, before you decide on the same fate for multiple-provider IPng users.) CIDR has some of these same disadvantages but you can still publish exceptions for multiple-provider nets. Guess how many there are and how many more are coming? > * Even farther minimized chance of the address space running > out before the protocol becomes obselete. (see my last > message or just pull out a good pocket calculator and > start playing with numbers. There is no doubt in my > mind that the safety margins built into any sane > allocation of 16-byte addresses are plenty) We won't run out of IPv4 addresses. RFC 1597 is going to be a lot less of a temporary hack than folks here seem to think; proxy network technology is getting better, there are commercial and noncommercial implementations out here *now* and they *must* become successes just to be able to last through this mythically short period before IPng supposedly saves us from drought. What do you think these proxy net vendors are going to do when IPng comes out? What do you think RFC 1597 users are going to do when IPng comes out? As someone else has pointed out, IPng will (in 20 years) be so widely implemented that it will not be possible to supercede it except by means of hacks like CIDR and RFC 1597 have been to IPv4. We won't run out of address space, with 8 _or_ 16 (or 4) byte addresses. > * As compressed links become more popular/practical, the information > in a 16-byte address is similar to that in an 8-byte > one and will occupy a similar number of compressed bits. That's because the entire address compresses out as (src,dst) tuples are replaced with stream identifiers. But this is not practical on wider area nets in quite the same way it works for home CSLIP customers. > [...] People are being almost deliberately wasteful of > address space from the start. If we divided up and used space efficiently, > I can see very practical ways we could handle the needs of the next twenty > years on a redone 32-bit address space (magic words being local use networks > and application gateways -- even in the most paranoid scenario where every > electronic device in your home would be on The Net, do you want and need > direct, global addressability for every one of them? I don't *want* anyone > outside my house to be able to access my toaster, and I don't *want* it to > be able to talk to every other toaster in the world). I am in total agreement with the above paragraph. > This is another big win of fixed-length addresses -- you have a finite > amount of space, so now you really do have to manage it. With variable length > addresses, you just make them bigger and avoid dealing with the real problem. Very much agreed. -- Paul Vixie Redwood City, CA decwrl!vixie!paul From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 10:44:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13540; Thu, 14 Jul 1994 10:44:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA03924; Thu, 14 Jul 1994 10:44:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA03910; Thu, 14 Jul 1994 10:25:53 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12737; Thu, 14 Jul 1994 10:25:37 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA07440; Wed, 13 Jul 1994 17:25:21 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Jul 1994 17:25:24 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: What's it all about? Cc: big-internet@munnari.OZ.AU At 2:13 PM 7/13/94, Noel Chiappa wrote: >Are you trying to imply that if the entire ISO stack (which included a lot >make than CLNP, remember) had used short, fixed-length addresses, it would >have succeeded? I'm sure you know that would be a ridiculous assertion. (I And your certainty is well-founded Noel. Your question is a flat-out distortion of Vernon's message and I cannot imagine how you would think that sending it is in any way helpful. For that matter, having now watched this exchange for days (weeks, months, years) I have to ask the primary contributors: What is being accomplished here? I don't see any output and I don't see debate based on specifications. We've had multiple threads pursuing multiple religious topics. While it might be resulting in a transcendent experience for some, the goal here is to FINISH the IPng process. We have specs on the table. We have rather strong convergence towards the fixed/16-byte alternative -- and yes, I'm quite sure there are several of you who disagree with that assessment, so please spare me and us the automatic reaction challenging my assertion -- but the messages over the last few days seem unconcerned with making any effort to reach closure. If there are technical proposals, concrete analyses, or the like, fine. Present them. (E.g., Kastenholz has offered a direct challenge based on a specific analysis and it needs a direct response.) Otherwise, how about moving the exchanges into private space? Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 11:24:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15001; Thu, 14 Jul 1994 11:24:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA03970; Thu, 14 Jul 1994 11:24:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA03965; Thu, 14 Jul 1994 11:15:40 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14773; Thu, 14 Jul 1994 11:15:30 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA20639; Wed, 13 Jul 94 19:14:26 MDT Received: from [130.57.64.145] (spurcell.wc.novell.com) by WC.Novell.COM (4.1/SMI-4.1) id AA11475; Wed, 13 Jul 94 18:10:09 PDT Date: Wed, 13 Jul 94 18:10:07 PDT Message-Id: <9407140110.AA11475@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Peter S. Ford" , Jon Crowcroft From: Greg Minshall Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: Susan Hares , big-internet@munnari.OZ.AU Apologies (being 20 hours behind in my big-i reading) if this has already been asked... Of all the people who *say* variable length, it is clear some mean *infinitely variable*, and some mean *some maximum size, but variable up to that*. 32-bytes is one maximum size that has been thrown around. Would these *variable* (-leaning) people do me a favor and reply, TO ME ALONE ('R', or option-command-r, or whatever!), which camp they are in and, if in the "maximum size" camp, what their personal favorite maximum size is? I will summarize to the list (end of the week, say). Greg From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 13:14:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11814; Thu, 14 Jul 1994 10:05:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA03869; Thu, 14 Jul 1994 10:04:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03866; Thu, 14 Jul 1994 09:57:17 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06718; Thu, 14 Jul 1994 07:57:47 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id RAA19039; Wed, 13 Jul 1994 17:57:40 -0400 From: Howard Berkowitz Message-Id: <199407132157.RAA19039@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Date: Wed, 13 Jul 1994 17:57:40 -0400 (EDT) Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9407131946.AA23480@rhyolite.denver.sgi.com> from "Vernon Schryver" at Jul 13, 94 01:46:39 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3500 > > > From: hcb@clark.net (Howard Berkowitz) > > > ... > > Paul spoke of seeing his first 32 and 64 bit addresses in hex dumps. > > I think many of us have such a model in mind. > > Paul also, and correctly, said we got used to this stuff after a while. > > Both you and Paul are wrong. I think I am being quoted a bit out of context here. I am saying that competent programmers were able to get used to 32 bit addresses and MAY be able to deal with 64 bit. Competent programmers, however, are NOT the people who operationally manage networks in firms without a large networking organization, in all too few cases. I do NOT see the end user administrator being able to deal with understanding 8 or 16 byte addresses. In day-to-day dealing with operations people, I find that three levels of hierarchy and anything not byte aligned (for IP) is overwhelming for a significant number of people. I am advocating that any serious new addressing model has at least to suggest human interface requirements that fit the typical router administrator, OR to suggest expert system or other approaches that hide the details of addressing. > > There was a qualitative difference between dealing with 16 bit and 32 > bit computer addresses. We could and did talk about 4-digit hex. > addresses and 6 digit octal addresses. (The computers I programmed in > my first 8 years in the business used 22, 24, 16, 12, 8, 48, and 60 bit > words). Well, I'll take your words, and raise you to 16, 36, 32, 1*, 16, 18, and 8. [* The 1 bit machine was the one we used as the machine more reliable than the 36 bit machine to which we were converting. THe former computer was made by the U.S. Mint). > > However, 8 digit hex addresses are too long for conversation. The only > 8 digit addresses people use in conversation do not have 8 significant > digits. They have lots of 0's, f's, or a fixed prefix. > > No one, NO ONE! can handle 64-bit addresses, except in trivial cases > where most of the digits are 0's or f's. > > It is no accident that U.S. phone numbers are only 7 digits long, with > occassional 3, 8, and 10 digit prefixes. > > Humans short term memory does not handle more than about 6 or 7 things > at a time. What you cannot remember, you cannot talk about or deal > with. > I don't disagree. What I am challenging people to suggest is either improved human interface metaphors, or strategies for automatic addressing. I want these strategies to be robust enough to deal with the real world. Not to pick on your firm, since I can think of several others with the same problem, I was told recently of someone who was doing a return on an SGI workstation, and the repair center was helpfully shipping a new one. The repair people asked for the serial numberof the old machine, so they could set the MAC address of the replacement to be the same, and to be transparent to other applications. Unfortunately, the user misread the MAC address and gave them the serial/MAC address of a DIFFERENT machine. They received the workstation, plugged it in, and had the network go crazy with a duplicate MAC address. The story may be inaccurate, but it is a good approximation of the things that go on in the real world. Other vendors have done things that cause duplicate software license numbers, etc. Just an address structure isn't enough. As my Navy friends say, it isn't enough to be foolproof, it has to be sailor-proof. Howard From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 16:21:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22264; Thu, 14 Jul 1994 14:05:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA04142; Thu, 14 Jul 1994 14:04:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA04128; Thu, 14 Jul 1994 13:50:39 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21570; Thu, 14 Jul 1994 13:50:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05682; Wed, 13 Jul 94 23:49:20 -0400 Date: Wed, 13 Jul 94 23:49:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407140349.AA05682@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: What's it all about? Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) > Are you trying to imply that if the entire ISO stack (which included a > lot make than CLNP, remember) had used short, fixed-length addresses, it > would have succeeded? Your question is a flat-out distortion of Vernon's message Really? It seemed pretty clear to me that part of the thrust of his message was along the lines of i) CLNP had variable length addreses, and ii) CLNP failed: therefore, variable length addresses are a failure. Inverting one of the terms seems like a good way to show that this reasoning is faulty. Since we've been discussing fixed versus variable addresses here for several days, I don't think it's confusion on my part to think that was the basic point of his message. What *was* the point of his message, if that wasn't it? Parenthetically, the fact that pro-fixed-length people are coming up with such poor arguments in support of their position indicates to me it's technically untenable. Still, I don't expect that will make any difference to the outcome. I cannot imagine how you would think that sending it is in any way helpful. Well, here we agree. This particular subthread is incredibly stupid. If it wasn't such an important topic, I'd just ignore it. I don't see debate based on specifications. Maybe, but not for lack of specs. What do you call the Big-10 proposal? Have you read it? Is there *any* possible set of specification that include fixed-length addresses that you'd like? Why do I have the feeling the answer to that is "no"? We have rather strong convergence towards the fixed/16-byte alternative A preponderance, sure. I wouldn't call it strong convergence, since numerous members of the IPng directorate have clearly expressed a preference for variable-length. the messages over the last few days seem unconcerned with making any effort to reach closure. This whole thing was set in motion by the incredibly half-wit decision on the part of the IETF to "pick an IPng". Vernon's right on this part; we are acting a lot like the ISO here. We're trying to pick paper designs. Of course, TCP/IP wasn't exactly tried and tested when it was set down for implementation either, so maybe that's not so bad. If there are technical proposals, concrete analyses, or the like, fine. Present them. Again, they abound. Tuba, Big-10, etc. You know this, yet you continue to try and raise this demonstrably wrong point. One wonders why. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 17:05:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00231; Thu, 14 Jul 1994 17:05:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA04412; Thu, 14 Jul 1994 17:04:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04396; Thu, 14 Jul 1994 16:51:12 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29651; Thu, 14 Jul 1994 16:51:03 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10348; Thu, 14 Jul 1994 08:50:32 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16677; Thu, 14 Jul 1994 08:50:13 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407140650.AA16677@dxcoms.cern.ch> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: big-internet@munnari.OZ.AU (bigi) Date: Thu, 14 Jul 1994 08:50:13 +0200 (MET DST) In-Reply-To: <92940713204129/0003858921NA1EM@mcimail.com> from "Robert G. Moskowitz" at Jul 13, 94 03:41:00 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1552 Bob, > > Deering said: > > > And if everyone really does decide that EIDs are indispensible, I > > hope you'll consider making them be the low-order 8 bytes of a > > 16-byte address, rather than additional header fields. > > > > Carpenter said: > > >I have to push back a bit on this. If 8-byte EIDs become a mandatory > >part of the address (=locator+EID), then as far as I can see 16 bytes are > >no longer sure to be enough, because there would only be 8 bytes of > >locator (which IMHO is insufficient for the long term). So mandatory EIDs > >would actually change my vote in the Directorate sraw poll that Scott > >posted. > > Would you still say this in a situation where locator gets you to the > segment that the system resides on an EID is still needed to get to the > actual system. Thus locator + EID is the full access path, EID is all you > need for local traffic, and locator somehow indicates a router interface (of > course the router has its own EID). > I think you are asking whether 8 bytes is enough to route to a subnet. If we take the design goal as 10**12 networks, the Huitema ratio is 12/64 = 0.19 so the answer is yes. However this assumes an ES-IS-like model, not an ARP-like model. If you obey Paul Vixie's exhortation "Use ARP" then locators that identify subnets are not enough, are they? Not that I want to use ARP myself, but many people seem to like it. [Noel: I don't see that the discussion of the necessary length of locators is affected by whether they are carried in every packet.] Brian From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 18:08:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26334; Thu, 14 Jul 1994 15:45:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA04251; Thu, 14 Jul 1994 15:44:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA04237; Thu, 14 Jul 1994 15:34:18 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16843; Thu, 14 Jul 1994 12:03:11 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id WAA25763; Wed, 13 Jul 1994 22:00:18 -0400 From: Howard Berkowitz Message-Id: <199407140200.WAA25763@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: 0003858921@mcimail.com (Robert G. Moskowitz) Date: Wed, 13 Jul 1994 22:00:15 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <24940713204142/0003858921NA1EM@mcimail.com> from "Robert G. Moskowitz" at Jul 13, 94 03:41:00 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1303 > > Jon Crowcroft said: > > >the only thing i konw of tha argues for variable is the requirement of > >_low bandwidthj_ to not incur the header overhead (i.e. the > >requirement to not use the 'longest so far'). > > >however, if most the low bandwidth is mobile, it needs the biggest > >address space and most flexibility, and probably multicast and TOS > >etc etc, and so the largest fixed length better also be the biggest > >the worst case can tolerate.... > > I had an interesting thought about these big addresses and their effect on > mobile bandwidth. > > The locator part of a mobile user is really the locator for their network > attachment point. Thus in practice, it might not have to flow over the link > except on setup time and it can be stripped out of the packet. Only the EID > is required to pass over the link. > > Now more experienced hands might point out to me that the overhead of > recalculating CRC checks does not benefit the slow connection, but 8 bytes > per packet (or more) is 8 bytes less to send. We still have a lot that is > slower than V.32bis... > Sounds very much like RFC1144 TCP header compression. Perhaps it would be useful to rerun Van Jacobson's performance calculations for IPng and EID values, including various alternative address sizes. Howard From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 18:08:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28551; Thu, 14 Jul 1994 16:24:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04321; Thu, 14 Jul 1994 16:24:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04304; Thu, 14 Jul 1994 16:08:40 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22435; Thu, 14 Jul 1994 14:10:32 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id VAA08870; Wed, 13 Jul 1994 21:10:15 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Jul 1994 21:10:25 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: What's it all about? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 8:49 PM 7/13/94, Noel Chiappa wrote: >A preponderance, sure. I wouldn't call it strong convergence, since numerous >members of the IPng directorate have clearly expressed a preference for "Preference". Important word. I'd "prefer" all sorts of things that are not practical or healthy or... The fact of the matter is that the vast majority of the directorate finds the fixed/16 proposal acceptable. Believe it or not, Noel, the art of making progress in the IETF is in accepting what is acceptable, rather than waiting for the ideal. >This whole thing was set in motion by the incredibly half-wit decision on the >part of the IETF to "pick an IPng". My, but you DO like beating a dead horse, don't you? This one is beyond dead. We've even already used up the resultant glue. Noel, I again ask what possible benefit you are trying to achieve with this sort of submission? You cannot possibly think that you will have a constructive effect? (For reference, I'm sending this publicly very much with the intent of triggering some reactions in others. Either the community does want resolution or it doesn't. The community feels that your sort of thrashing approach is constructive will somehow, eventually be productive, or it doesn't. Given that we are due for a public decision on IPng in about 10 days, it does not seem premature to try to get you and us off the merry-go-round.) Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 18:09:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28597; Thu, 14 Jul 1994 16:26:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04349; Thu, 14 Jul 1994 16:26:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04318; Thu, 14 Jul 1994 16:18:08 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23153; Thu, 14 Jul 1994 14:24:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05823; Thu, 14 Jul 94 00:24:12 -0400 Date: Thu, 14 Jul 94 00:24:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407140424.AA05823@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, paul@vix.com Subject: Re: why not variable length? Cc: jnc@ginger.lcs.mit.edu There is no reason to encode MAC-level addresses, either IEEE 48-bit ones, Appletalk ones, or any other kind. Use ARP. This is not so. Specification of local addresses indirectly, through small numbers which have to be mapped into the relevant IEEE hardware, etc, addresses has two costs. Number one, you have to allocate those small numbers, and two you have to have a translation mechanism. ARP and a file in the network guru's machine may work for an Ethernet, but on a large WAN these are serious problems. Direct inclusion of the hardware address is the way to go. IP orginally depended on this direct inclusion of local hardware addresses in the IP address on all the networks it ran on, and did so for many years. When 10M Ethernet first appeared, this broke down due to space limits. ARP is a bag on the side of IP that Dave Plummer and I hacked together to squeeze 5 pounds of refuse into a 2 pound bag. I challenge anyone ... to please show me some hierarchy which has stood the test of time without having to have layers inserted or appended to it. Exactly. Which is why we need an addressing scheme that allows layers to be added, or expanded in size, neither of which is anything but incredibly painful with fixed-width masks systems. (Ironically enough, masks are another historical kludge I helped perpetrate, and now have to listen to people who think it has been transmuted from manure to ice cream. I guess I'm being punished for all the hacks I've helped perpetrate. :-( We won't run out of IPv4 addresses. ... they *must* become successes just to be able to last through this mythically short period before IPng supposedly saves us from drought. If so, why are we doing IPng anyway? (No, Dave, I'm not trying to reopen that question, just being sarcastic. :-) Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 18:09:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27242; Thu, 14 Jul 1994 16:04:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04283; Thu, 14 Jul 1994 16:04:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA04269; Thu, 14 Jul 1994 15:52:20 +1000 Precedence: list Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17337; Thu, 14 Jul 1994 12:12:39 +1000 (from vaf@Valinor.Stanford.EDU) Received: (from vaf@localhost) by Valinor.Stanford.EDU (8.6.8/8.6.6) id TAA17202; Wed, 13 Jul 1994 19:14:47 -0700 Date: Wed, 13 Jul 94 19:14:47 PDT From: Vince Fuller To: big-internet@munnari.OZ.AU, mankin@cmf.nrl.nay.mil, sob@harvard.edu Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Message-Id: I would like to express my heartfelt agreement with Yakov's message - any discussion of variable vs. fixed "addresses" and the length of same is meaningless until we make a clean split of topology-based address (what some have been calling a "locator") and endpoint-ID. The overload of these two, distinct functions onto a single addressing/naming quantity was a mistake in IPv4 that needs to be fixed in the new architecture. With fully dynamic and transparent routing and renumbering, 8-bytes should be plenty for representing topology addresses. Likewise, an 8-byte quantity which need not be sliced and diced into a pre-planned hierarchy should be adequate to assign endpoint-IDs (in fact, a strong argument can be made that 4-byte IPv4 addresses can be used for the purpose for a long time to come). --Vince --------------- From: yakov@watson.ibm.com Date: Sun, 10 Jul 94 11:05:06 EDT To: big-internet@munnari.oz.au, mankin@cmf.nrl.nay.mil, sob@harvard.edu Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <9407101506.14430@munnari.oz.au> Ref: Your note of Thu, 7 Jul 1994 14:07:10 -0400 Folks, The following quote is from "Realizing the Information Future -- the Internet and Beyond" (NRENAISANNCE Committee Report): "The migration to a new address space will be a major upheaval that will affect users, network providers, and vendors. Unifying the various network communities, the Internet, the cable industry, and the telecommunications industry is an additional complex undertaking that will not happen unless there is a clear and explicit advantage. An effort to define a single overarching architecture is the only context in which this integration can be motivated. It will take careful consideration to plan and implement a scheme that properly resolves such major concerns as an appropriate addressing scheme, interim management actions, and migration plans. This implies that overarching architectural decisions for the NII, such as addressing, must be made in a context with an appropriate long-term vision and architectural overview. Wide-ranging discussion is needed on the requirements for next-generation integrated addressing, with the goal of determining what the scope of this coming address space should be. It is critical that the requirements be appropriately specified." Correct me if I am wrong, but I don't think that *today* we have "a single overarching architecture". Correct me if I am wrong, but I don't think that *today* we have "the requirements for next-generation integrated addressing". In absence of *both* the architecture *and* the requirements for next-generation intergrated addressing, the only way to define the IPng packet format *without* waiting for the architecture and the requirements is to make a guess. The guess needs to factor in the uncertainty about the architecture and the requirements. The guess suggested by Scott and Allison -- fixed length 16 bytes for all address types (unicast, cluster, multicast) that carries both EID and locator semantics seems to be too rigid and too constrained in view of the above. I think that a better (more flexible and less constrained) guess is the following: (a) Separate unicast EID from unicast locators, with unicast EID of fixed length and unicast locators of variable length (perhaps multiple of 8). (b) Cluster locators of variable length (perhaps multiple of 8). Yakov. P.S. Let me suggest that we'll pay a serious attention to the NRENAISSANCE committee report. The committee membership represents the top experts in networking (Leonard Kleinrock, Cynthia Braddon, Dave Clark, William Emery, Dave Farber, A.G. Fraser, Russell Hensley, Lawrence Landweber, Robert Lucky, Susan Nutter, Radia Perlman, Susanna Schweizer, Chales Taylor, Thomast West, Robert Kahn). From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 18:09:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28623; Thu, 14 Jul 1994 16:27:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04368; Thu, 14 Jul 1994 16:27:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04301; Thu, 14 Jul 1994 16:07:42 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19708; Thu, 14 Jul 1994 12:55:25 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id WAA03602; Wed, 13 Jul 1994 22:55:16 -0400 From: Howard Berkowitz Message-Id: <199407140255.WAA03602@clark.net> Subject: Configurability Requirements (was IPng ADs wish....) To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Wed, 13 Jul 1994 22:55:14 -0400 (EDT) Cc: vjs@rhyolite.denver.sgi.com, Big-Internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu In-Reply-To: <199407132157.OAA06497@Mordor.Stanford.EDU> from "Dave Crocker" at Jul 13, 94 02:57:50 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3014 Dave Crocker wrote, > > To underscore some of Vernon's comments... > ---- Included message: > It is no accident that U.S. phone numbers are only 7 digits long, with > occassional 3, 8, and 10 digit prefixes. > > Humans short term memory does not handle more than about 6 or 7 things > at a time. What you cannot remember, you cannot talk about or deal > with. > > It is important to note that telephone numbers are represented with partitioning. > The short-term memory limit (7 plus/minus 2) refers to a single string of > serially-related digits. The technique we use to handle longer strings is > to 'chunk' them. > > That said, there is a worse limit on 'hierarchy' which seems to be two- or > three-deep for average folk. Worse, the limit of 7 for serial is statistical; > if you want to improve the statistics on the number of people who remember or > process the string, you need to drop it to 5. > > The point, here, is that this is all very, very well-understood psychology > and human factors stuff. We should be careful to factor in those considerations > before making assertions of what is easy/feasible and we should be very, very > careful about our sampling technique when we cite capabilties from our > personal knowledge. For example, programmers seem to be dramatically better at > juggling arbitrary detail than are average folks. Maybe we can try to cool things down by trying to state some of these interface vis-a-vis address structure issues by stating a set of requirements for an IPng system. Let me throw out a few strawmen, and let's try to assess how they could be written for the various address lengths, structures, etc. Might even be nice to define them in terms of SIPP, TUBA, etc. and supporting protocol capabilities. 1. The maximum number of hierarchical levels that MUST be configured in a node shall not be greater than three(5). It MAY be possible manually to configure additional levels. 2. Mechanisms MUST be defined that permit the implementation to obtain additional levels above three. These may learned dynamically (e.g., ES-IS or DHCP), or additional configuration files/commands MAY be used, but no single configuration file/command should specify more than three (five) levels. The idea here is to have the higher-level stuff be treatable as a discrete object. 3. If fields in the address are not octet (nibble?) aligned, the user SHALL NOT be required to do bit mask computations to configure the device. 4. If a device dynamically acquires part of its address, it should retain (MIB variable) the source of each dynamically learned address component. MIB variables should also include indications of which address components were manually configured, and the time of configuration. Just strawmen now. I am not trying to solve the mechanisms by which address information is configured, but see if there is some consensus on requirements. Howard From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 18:10:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02163; Thu, 14 Jul 1994 18:04:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA04489; Thu, 14 Jul 1994 18:04:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA04471; Thu, 14 Jul 1994 17:45:43 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01570; Thu, 14 Jul 1994 17:45:28 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Jul 1994 08:45:19 +0100 To: Big-Internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Wed, 13 Jul 94 13:46:39 MDT." <9407131946.AA23480@rhyolite.denver.sgi.com> Date: Thu, 14 Jul 94 08:45:16 +0100 Message-Id: <618.774171916@cs.ucl.ac.uk> From: Jon Crowcroft >It is no accident that U.S. phone numbers are only 7 digits long, with >occassional 3, 8, and 10 digit prefixes. the phone system is 14 decimal digits max typically, to dial anywhere, you get country code: 3 digits area code/city: 2-3 exchange: 3-4 EID (my handset: 4 if there;s around 4 bits per digit with some wastage, this is 4*14=56 bits with the _current_ utilisation (600M end systems) do we think the phone people are wrong? that leaves us inside 64 bits with an extra 8 bits of what used to be quaiontly called 'subaddressing' jon From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 18:45:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03647; Thu, 14 Jul 1994 18:45:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA04547; Thu, 14 Jul 1994 18:44:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA04517; Thu, 14 Jul 1994 18:24:49 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25187; Thu, 14 Jul 1994 15:15:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06042; Thu, 14 Jul 94 01:14:46 -0400 Date: Thu, 14 Jul 94 01:14:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407140514.AA06042@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, vjs@rhyolite.denver.sgi.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Unless the IETF avoids the ISO style of development, IPng will have the same fate as the OSI protocols. Style begats substance when you are dealing with committees, whether the IETF or the ISO. This much I can agree with. The ISO people set out to Solve The Problem For the Foreseeable Future. Instead of quick hacks that would work for a while and get some information for the next step (i.e. TCP) But TCP didn't evolve from NCP in quick hacks, or small steps. In fact, I've always felt that a big problem with CLNP was that it wasn't *bold enough*. I mean, what's the real difference between CLNP and IPv4? Larger addresses, right? They changed the addresses because they thought IPv4 addresses were too small. Hard to fault their thinking there, right? :-) Other than that, they left things alone; it was an incremental improvement on IPv4. (They even copied the fragmentation and header checksum stuff! :-) Of course, the ISO stack contained a lot more than CLNP... Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 18:47:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03856; Thu, 14 Jul 1994 18:47:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA04564; Thu, 14 Jul 1994 18:47:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA04531; Thu, 14 Jul 1994 18:38:24 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26825; Thu, 14 Jul 1994 15:57:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06273; Thu, 14 Jul 94 01:57:52 -0400 Date: Thu, 14 Jul 94 01:57:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407140557.AA06273@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: What's it all about? Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) Believe it or not, Noel, the art of making progress in the IETF is in accepting what is acceptable, rather than waiting for the ideal. Sure, but I just don't feel that fixed-length addresses are even minimally acceptable, technically. I'm really not thrilled to be wasting all this time on this dumb issue; I'm doing it because I think it's critical. > This whole thing was set in motion by the incredibly half-wit decision > on the part of the IETF to "pick an IPng". My, but you DO like beating a dead horse, don't you? ... Noel, I again ask what possible benefit you are trying to achieve with this sort of submission? You cannot possibly think that you will have a constructive effect? Ah, I've given up trying to fix that particular piece of braindamage. Every so often something triggers the reaction, though. For reference, I'm sending this publicly very much with the intent of triggering some reactions in others. ... The community feels that your sort of thrashing approach is constructive will somehow, eventually be productive, or it doesn't. I've got more people telling me to keep pushing on variable-length than I do telling me to go away, not that that's the only thing I'd take into account. I'm not hopeful that my efforts will be successful, mind you. I learned in the IAB IPv7 fiasco the exact taste of when people have made up their minds, and don't want to be bothered with any attempts to insert reality. Given that we are due for a public decision on IPng in about 10 days, it does not seem premature to try to get you and us off the merry-go-round. I'd have thought the fact that we're getting ready to make the decision indicates it's still appropriate to raise this. After the decision is made, a reassessment is in order, of course. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 19:57:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04365; Thu, 14 Jul 1994 19:04:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA04597; Thu, 14 Jul 1994 19:04:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA04594; Thu, 14 Jul 1994 19:04:02 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02710; Thu, 14 Jul 1994 18:17:11 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Jul 1994 09:16:40 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU Subject: Re: How many bits are enough? In-Reply-To: Your message of "Wed, 13 Jul 94 11:08:57 EDT." <9407131508.AA00972@ginger.lcs.mit.edu> Date: Thu, 14 Jul 94 09:16:37 +0100 Message-Id: <899.774173797@cs.ucl.ac.uk> From: Jon Crowcroft >So, these calculations about how many layers we need, at so many bits per >layer are all pretty much useless, since they are talking about the *average* >case, not the *worst* case. the law of large numbers (and we are talking really large numbers) makes me beleive that averae and worst will be similar. we are talking about how many levels deviate from a typical level size....it would take a concerted effort for a number of different authorities to do something stupid....as the Internet grows, the number of layers of authorities is not growing very much....in fact, as far as i can tell it has been static for around 54 years jon From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 19:57:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04399; Thu, 14 Jul 1994 19:06:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA04614; Thu, 14 Jul 1994 19:05:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA04591; Thu, 14 Jul 1994 19:02:39 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02169; Thu, 14 Jul 1994 18:05:25 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Jul 1994 08:54:55 +0100 To: Howard Berkowitz Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Wed, 13 Jul 94 22:00:15 EDT." <199407140200.WAA25763@clark.net> Date: Thu, 14 Jul 94 08:54:53 +0100 Message-Id: <755.774172493@cs.ucl.ac.uk> From: Jon Crowcroft >> >the only thing i konw of tha argues for variable is the requirement of >> >_low bandwidth_ to not incur the header overhead (i.e. the >> >requirement to not use the 'longest so far'). >Sounds very much like RFC1144 TCP header compression. Perhaps it would be >useful to rerun Van Jacobson's performance calculations for IPng >and EID values, including various alternative address sizes. given TCP+IP Header compression maps the state into a virtual circuit id, and that the EID+Locator don't change much except each time a host moves, the compression on TCPng+IPng will reduce to the _same_ 5 bytes you get with TCP+IPv4, ecept the state refresh messages each time you lose synch will be huger if the 16byte (or possibly huge if variable length) people have their way.... so van, as usual, will largely save us frm our foolish selves:-) jon From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 21:25:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08512; Thu, 14 Jul 1994 21:25:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA04746; Thu, 14 Jul 1994 21:24:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA04741; Thu, 14 Jul 1994 21:10:16 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07673; Thu, 14 Jul 1994 20:45:22 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11876; Thu, 14 Jul 1994 12:45:33 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21683; Thu, 14 Jul 1994 11:48:37 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407140948.AA21683@dxcoms.cern.ch> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: big-internet@munnari.OZ.AU (bigi) Date: Thu, 14 Jul 1994 11:48:36 +0200 (MET DST) In-Reply-To: <618.774171916@cs.ucl.ac.uk> from "Jon Crowcroft" at Jul 14, 94 08:45:16 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 888 Jon, > the phone system is 14 decimal digits max ... > if there;s around 4 bits per digit with some wastage, this is 4*14=56 bits Bogus! You're not allowed to include wastage. You have to use 3.3 bits/digit as Christian did, i.e 46.2 bits total. This strengthens your case. > with the _current_ utilisation (600M end systems) Gives a Huitema ratio of 0.19 > do we think the phone people are wrong? If we believe all this, it just means that France and North America have allocated phone #s more efficiently than the world as a whole. But they are addressing a mere 10**9 end systems and our design goal is 10**15 (1 million nodes per telephone line !-). > that leaves us inside 64 bits with an extra 8 bits of what used to be > quaiontly called 'subaddressing' > Yes. I think your data indeed prove that 64 bits is sufficient to address 256 nodes per telephone line. Brian From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 21:54:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09142; Thu, 14 Jul 1994 21:45:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA04790; Thu, 14 Jul 1994 21:44:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA04762; Thu, 14 Jul 1994 21:25:13 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08513; Thu, 14 Jul 1994 21:25:02 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA03707; Thu, 14 Jul 94 06:26:58 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac14767; 14 Jul 94 11:22 GMT Date: Thu, 14 Jul 94 06:23 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: bigi Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <53940714112335/0003858921NA4EM@mcimail.com> Brian.Carpenter said: >I think you are asking whether 8 bytes is enough to route to a subnet. >If we take the design goal as 10**12 networks, the Huitema ratio >is 12/64 = 0.19 so the answer is yes. >However this assumes an ES-IS-like model, not an ARP-like model. >If you obey Paul Vixie's exhortation "Use ARP" then locators that >identify subnets are not enough, are they? Not that I want to use >ARP myself, but many people seem to like it. I don't see that last message. I would think that ARP would work just fine. Basically, if the locators are the same, then the devices are on the same 'subnet' and use ARP. Otherwise, figure out how to route... Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 21:54:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09161; Thu, 14 Jul 1994 21:45:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA04807; Thu, 14 Jul 1994 21:45:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA04776; Thu, 14 Jul 1994 21:37:28 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08930; Thu, 14 Jul 1994 21:37:18 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA04036; Thu, 14 Jul 94 06:39:09 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id al15254; 14 Jul 94 11:34 GMT Date: Thu, 14 Jul 94 06:36 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <00940714113600/0003858921NA2EM@mcimail.com> I said: >>>the only thing i konw of tha argues for variable is the requirement of >>>_low bandwidth_ to not incur the header overhead (i.e. the >>>requirement to not use the 'longest so far'). Howard Berkowitz said: >>Sounds very much like RFC1144 TCP header compression. Perhaps it would be >>useful to rerun Van Jacobson's performance calculations for IPng >>and EID values, including various alternative address sizes. Jon Crowcroft said: >given TCP+IP Header compression maps the state into a virtual circuit >id, and that the EID+Locator don't change much except each time a host >moves, the compression on TCPng+IPng will reduce to the _same_ 5 bytes >you get with TCP+IPv4, ecept the state refresh messages each time you >lose synch will be huger if the 16byte (or possibly huge if variable >length) people have their way.... >so van, as usual, will largely save us frm our foolish selves:-) I kind of thought so. This should also work with the roving workstaion according to the MMobile IP concepts, correct? Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 22:04:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09699; Thu, 14 Jul 1994 22:04:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04841; Thu, 14 Jul 1994 22:04:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA04825; Thu, 14 Jul 1994 21:54:21 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08933; Thu, 14 Jul 1994 21:37:18 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA04040; Thu, 14 Jul 94 06:39:11 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ag15405; 14 Jul 94 11:34 GMT Date: Thu, 14 Jul 94 06:36 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Big Internet Subject: Re: IPng ADs Wish To Gauge Consensus on Address Length Requirements Message-Id: <31940714113613/0003858921NA2EM@mcimail.com> Jack Dietz said: >The only possible hitch is that colocated EIDs cannot have the same >1's complement checksum, or that source and destination EID pairs for >open connections cannot have the same checksum. An enlarged checksum >field in the new versions of TCP and UDP would reduce the occurence of >this, and an extra check against the valid TCP sequence numbers during >demultiplexing would allow misdirected packets to be identified and >run through the EID determination process again. However, it is >possible that two UDP applications, speaking with the same port on the >same other machine, listening on the same port, and with EIDs that >have the same 1's complement checksum, could receive each others >packets by mistake. Services provided by servers on mobile EIDs may >need to ensure that they are using unique ports. This is a rather big hitch with either humanly or autoconfigured EIDs. So I think this is a not-workable-solution. Anyway, I was expecting the EID to be the local subnet address and thus very important to have... Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 14 22:59:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10306; Thu, 14 Jul 1994 22:25:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04873; Thu, 14 Jul 1994 22:24:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04868; Thu, 14 Jul 1994 22:13:18 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09948; Thu, 14 Jul 1994 22:13:11 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA05094; Thu, 14 Jul 94 07:15:07 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id av17320; 14 Jul 94 12:10 GMT Date: Thu, 14 Jul 94 07:10 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Big Internet Subject: Thoughts on Autoconfiguration Message-Id: <51940714121015/0003858921NA3EM@mcimail.com> Had another bad dream last night while you all were busy trying to crash kre's machine again :) Noel and Masataka have helped me with the locator+EID and IP+TCP state machines. Basically, I had it right but missed a few details :( Now about this autoconfiguration thing.... We have two pieces to autoconfigure, the locator and EID. And we have the DNS to update. The locator is easy. A router on the subnet tells an interface what its locator is. If there is no router (the dentist office problem), the locator is all 0s or something like that. Next the EID. If we allow MAC addresses as EID possiblities this could get fun. There would have to be some high level bit in the EID to designate the TYPE of EID: MAC, serial port, process, whatever. I might think that a 'cool' way to start the EID autoconfigure would be something in the locator notify record. The router would inform the device how it would go about selecting an EID. Of course if the router on one interface says: "use your MAC address, and the router on another interface says: "use this address from my table" we've got a problem. Perhaps a rule would be that a multi-homed device can NEVER use a MAC address as an EID, but it would still have to make a choice. The device could ask one of the routers to query an EID server on its behalf too. This seems a little more workable? And the device would have to tell the router how many EIDs to get? Or maybe this mechinism would get the EID for the device and then the device would get EIDs for all of the processes that need them? Messy. Finally after all locators and EIDs are obtained by the device, it would have to inform the DNS of its state. The DNS would then have to update this information immediately (or some reasonable approximation of this) to all secondaries and all caches? YUCK! So I think that autoconfigure, really on the fly autoconfigure won't fly. I have another idea, maybe an old idea. When a device first comes up it is told its configuration that it saves somewhere. This state has all of its locators and EIDs and is timestamped. Every time the device comes up it broadcasts that timestamp to neighboring devices (or maybe only the routers or maybe a unicast to the EID server, but this might not be reachable if state has changed!). If something responds that there has been a timestamp change, only then would the autoconfigure process kick in. Thus DNS changes are more controled. The only time that a device autoconfigures is when it is new (or has some new interfaces or processes) or the network adminstrator had given a 'kick' to his network in terms of a new topology or a new provider. This is really messy. We do indeed need autoconfigure, but I wonder if we will like the results. Kind of reminds my of one BIG computer company that DOES give its customers what they asked for, even if they will then be sorry that they asked for it and that the BIG company then never ends up selling that feature, but the development was worth it to quite the rabble.... Methinks that once we sort out the basic address, that there will have to be a whole side effort to figure out how to autoconfigure it. And if it cannot be autoconfigured, then what? Do we act like the executive wing and throw it back to congress? Good Morning! Bob From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 00:02:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12982; Thu, 14 Jul 1994 23:45:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA04963; Thu, 14 Jul 1994 23:44:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA04947; Thu, 14 Jul 1994 23:25:19 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12421; Thu, 14 Jul 1994 23:25:14 +1000 (from yakov@watson.ibm.com) Message-Id: <9407141325.12421@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2453; Thu, 14 Jul 94 09:25:14 EDT Date: Thu, 14 Jul 94 09:22:28 EDT To: dcrocker@mordor.stanford.edu Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: What's it all about? Ref: Your note of Wed, 13 Jul 1994 21:10:25 -0700 Dave, >the art of making progress in the IETF is in accepting what is >acceptable, rather than waiting for the ideal. The art of developing successful technical solutions in presence of multiple design choices is in constructive criticism for the purpose of getting a better understanding. >Noel, I again ask what possible benefit you are trying to achieve with this >sort of submission. You cannot possibly think that you will have >a constructive effect. As far as I can see, Noel's (as well as other people's) postings to the Big-I mailing list are essential to understand the set of the open issues and to initiate a dialogue on how to resolve these open issues. Trying to sweep open issues under the carpet is certainly *not* constructive. Trying to expose the open issues and initiate a dialoge for the purpose of resolving these issues is *highly* constructive. As far as I can see the IETF community, as a whole, is working together to produce a *good* technical solution to the IPng problem. I view Noel's participation as being part of this effort. Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 00:57:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15351; Fri, 15 Jul 1994 00:45:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA05311; Fri, 15 Jul 1994 00:44:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA05295; Fri, 15 Jul 1994 00:30:27 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14869; Fri, 15 Jul 1994 00:30:20 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04393; Thu, 14 Jul 94 08:29:40 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB12388; Thu, 14 Jul 94 07:25:20 PDT Date: Thu, 14 Jul 94 07:25:20 PDT Message-Id: <9407141425.AB12388@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Elz From: Greg Minshall Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU Robert, >This is also why I believe (you can't imagine how strongly, or >maybe you can Noel, but many others don't) that we simply must >divorce node (endpoint) identification from addressing. If >we do that we can (not easily, but feasibly) connect together >regions of old and new net layer technology, allowing transport >to flow from one to the other without grief. Could you say more on this? Could you, for example, explain how, aside from either a mapping table or a simple injection, you would connect together the old and new net layer? Why aren't we doing *that* today for IPv4? (In particular, in your mind, how do you prevent *old net layer* machines from being precluded from talking to some growing subset of *new net layer* machines?) Greg From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 00:57:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15376; Fri, 15 Jul 1994 00:46:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA05326; Fri, 15 Jul 1994 00:45:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA05291; Fri, 15 Jul 1994 00:29:51 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14840; Fri, 15 Jul 1994 00:29:37 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04368; Thu, 14 Jul 94 08:29:20 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB12388; Thu, 14 Jul 94 07:25:00 PDT Date: Thu, 14 Jul 94 07:25:00 PDT Message-Id: <9407141425.AB12388@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Howard Berkowitz From: Greg Minshall Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-Internet@munnari.OZ.AU I mean, there's not anything like *enough* traffic on this list... At 8:22 AM 7/13/94 -0400, Howard Berkowitz wrote: >In order to gain market share for IPng, and minimize the >conversion effort, I am trying to avoid extensive needs for >masking and manimpulation of addresses. I don't insist things >be on byte boundaries, but I lean in the direction of nibble >alignment. In support of what Howard is asking for, let me list, again, my list of three things i'd like for IPng: 1. Totally trivial (stateless, auto-) configuration of end systems. 2. Make router configuration significantly easier than it is today for IPv4. 3. Ease discovery of *local* (campus, say) services (like DNS, etc.) in a way which is extensible (in terms of adding new services). Howard (and Brian C. and Eric F., i think) is arguing for the *features* of #2. (I, personally, am not sure i know how best to achieve #2.) Greg From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 00:57:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14793; Fri, 15 Jul 1994 00:25:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA05245; Fri, 15 Jul 1994 00:24:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA05016; Fri, 15 Jul 1994 00:11:13 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11777; Thu, 14 Jul 1994 23:05:25 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id JAA23318; Thu, 14 Jul 1994 09:05:11 -0400 From: Howard Berkowitz Message-Id: <199407141305.JAA23318@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Thu, 14 Jul 1994 09:05:11 -0400 (EDT) Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <618.774171916@cs.ucl.ac.uk> from "Jon Crowcroft" at Jul 14, 94 08:45:16 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2946 > > > >It is no accident that U.S. phone numbers are only 7 digits long, with > >occassional 3, 8, and 10 digit prefixes. Jon Crowcroft wrote: > > the phone system is 14 decimal digits max > > typically, to dial anywhere, you get > country code: 3 digits > area code/city: 2-3 > exchange: 3-4 > EID (my handset: 4 > > if there;s around 4 bits per digit with some wastage, this is 4*14=56 bits > with the _current_ utilisation (600M end systems) > > do we think the phone people are wrong? > that leaves us inside 64 bits with an extra 8 bits of what used to be > quaiontly called 'subaddressing' > Ah, but the telephone people have a somewhat more constrained problem than we do. Multihoming and policies are usually known from context. Examples: The long distance carrier of choice is a default for a given telephone number. So, if I want to place a call from a number using a different provider: 1-0- preamble for alternate provider access 5 digits for provider code 0 to indicate alternate billing now the 14 digits Jon cites # delimiter if I want to speed 3rd party billing 10 digits or so for a credit card number another # for speed. From the user perspective, we have something along the lines of 23 digits for a user to do limited source routing in the telephone network. OK. This is the network address plus some provider policies, etc. Now. Transport level protocols. What, there's no such thing as a transport level protocol for a telephone? A skit on "Saturday Night Live" shows there are many additional levels of EID, if you are calling all too many an American government organization or large business: RING..RING...You have reached Police Emergency. If you are calling to report a murder, press 1. If you are calling to report a fire, press 2... If you are being murdered, press 1. If someone else is being murdered, press 2. If you are murdering someone, press 3. If your murderer is shooting you, press 1. If your murderer is strangling you, press 2.... Also remember that telephony, especially the modern sort, has additional management communications channels. If I have a mechanism that give me the "source address" of an incoming call, it is conveyed either as an analog signal interspersed with ringing, or as ISDN Q.922 supplemental information. So, the telephone model works up to a point. As a telecommuter, I am constantly making errors in punching in credit card numbers, or finding that various autocalling routines cannot deal with the complexity of real-world phone numbers. If we can constrain network addresses with the amount of high-level context information that the telephone switch knows about a subscriber, we are closer to "autoconfiguration." Unfortunately, the telephone model really isn't that clean; it deals with a fairly simple unicast structure within a strict hierarchy. Variations become complex. From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 00:58:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14802; Fri, 15 Jul 1994 00:26:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA05273; Fri, 15 Jul 1994 00:25:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA05019; Fri, 15 Jul 1994 00:18:08 +1000 Precedence: list Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13143; Thu, 14 Jul 1994 23:49:47 +1000 (from perk@watson.ibm.com) Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2787; Thu, 14 Jul 94 09:49:45 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 0163; Thu, 14 Jul 1994 09:49:43 EDT Received: from np2.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Thu, 14 Jul 94 09:48:39 EDT Received: by np2.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA33792; Thu, 14 Jul 1994 09:48:35 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9407141348.AA33792@np2.watson.ibm.com> To: big-internet@munnari.OZ.AU Subject: Using IPng options for more "address" bits Date: Thu, 14 Jul 94 09:48:34 -0500 While reading Steve Deering's recent contributions to this list, I realized how heavily dependent his estimation was on modeling the address space as something which was filled up by "things". These "things" are what need to have at least locally unique identifiers, which are what I believe are called EIDs. Maybe there are multiple EIDs per "network interface", but the network interface need not be identical to what goes in the address space. Anyway, I think it's almost certain that the thing which goes in the IPng header will be used by routers, and that locator thing currently has a little bit of EID in it too. I reckon I am still in favor of using 8 bytes of (mask-defined locator + EID) in the IPng header, as is done now with 4 bytes in IPv4, but defining options for extending the length of either one. I like this idea, because it would work right away with a fixed length field. When people want more, they could buy an end system which has more, which is the same as saying that the end system knows how to interpret more IP options than previous ones. For instance, why not allow systems to pass their MAC address as an IPng option, effectively extending their EID? Other EID extensions could be passed as options also. I don't see how we can mandate all the possible ways for EIDs to be allocated and used right now, so this seems to be a case for options, instead of saying that we have to have unbelievable numbers of extra "address bits" to take care of the unknown and unknowable future. I think that doing things this way would require extra initial care in building name servers and other support software. Similarly, perhaps the needs for longer locators could be met by future options. In the unlikely event that we ever need more than (56, say) bits for locators, additional (on the left) bits of the locator could be situated in an IPng option. By the time this becomes relevant, I expect that routers will be superfast, so the additional time for assembling the locator from two different bit sources will be irrelevant. I vote for 8 bytes fixed "address" in the IPng header, because it's easy to understand and implement now. I think that the use of options can solve the needs of future expansion, especially given the likelihood of additional router sophistication and speed in the future. I admit to being heavily biased by wanting to have something that fits in with my current model of internetworking, which "is" IPv4. If 8 bytes is out, then of course I vote for the next smallest available number. I also think that if address packing density is an issue, there would be more than enough interest to charter a new IPng Working Group to develop and deploy cheap software to solve the problem. I cannot believe it's _that_ hard a problem to solve. The important thing is to make sure that address allocation starts off with the goal of dense packing in mind, instead of just consigning huge chunks of address space to whoever asks for it. Which brings up the point that we don't even know who owns the address space, no matter _how_ big it is. One final point: If it really is going to be 5 years before IPng starts to make a dent, isn't that long enough to have lots of interoperability testing, even for less-used option fields? The IPng directorate could strive to make this an important consideration for implementors. Thanks. Now I should read the Big-10 proposal :-) Charlie P. PS. If I've misunderstood basics of the debate, please let me know via private mail instead of battering the list with the explanations. Thanks again. From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 00:58:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15388; Fri, 15 Jul 1994 00:47:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA05343; Fri, 15 Jul 1994 00:47:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA05289; Fri, 15 Jul 1994 00:29:50 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14843; Fri, 15 Jul 1994 00:29:47 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04371; Thu, 14 Jul 94 08:29:25 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB12388; Thu, 14 Jul 94 07:25:06 PDT Date: Thu, 14 Jul 94 07:25:06 PDT Message-Id: <9407141425.AB12388@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) From: Greg Minshall Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: Big-Internet@munnari.OZ.AU Vernon, > f. which performs better (eg. what's the fastest TP4 speed over HIPPI > or any other medium you've heard of?) In general, i've tended to believe that most of the OSI rot was experienced at the upper levels. It would be interesting, however, to have people who've implemented TCP over CLNP to run some random experiments and give us answers to TCP/CLNP speed compared to TCP/IP speed. (Yes, i know "lies, damn lies, statistics, and benchmarks", but, still.) >Please explain why it is that IPng should be following the path that >lead to disaster. Please explain why OSI's failure was unrelated to >what ISO tried to do and how they tried to do it. Otherwise, please >explain why doing things the ISO way (cover all bases until the end of >time) will work for IPng when it failed for OSI. What i am about to say is philosophy. Most people should tune out now. TCP/IP won because it won. Berkeley released it. It garnered critical mass. People (like you and me presumably) put a fair amount of energy into it in a way which helped lots of people. It had some luck. Some other stuff. A couple of people i know started (or were in at the start) of two computer companies. One was an astonishing success. The other burned bright for a while and lost. One was Sun; one was Apollo. This was not all, or even mostly, a technical issue. (People at the time were queuing up to buy Sun machines, back in the bad early days, because, among other reasons, "any guy that can write vi is going to keep on producing products i want to be in on". Slave graduate student labor, indeed!; on the other side, Apollo had some very good technology.) 3Com started; Novell started. Among other things, 3Com worked on server products which competed with Novell's. In this arena, Novell won. This was not all, or even mostly, a technical issue. There was substantial non-technical issues, including large doses of luck, involved. Now, the people at Sun could say "oh, what Apollo did, that was crud; forget a network file system; forget a uniform name space; that has been *proven* wrong!". The people at Novell could say similar things. They won't. One of the *real* dangers of success is feeling like you (totally) earned it on technical merit alone (we *do*, ultimately, believe in a technocracy, after all). It is just very seldom true. Greg (Images of engineers starting companies with no thought to marketing, sales, etc.) From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 01:25:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16705; Fri, 15 Jul 1994 01:25:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA05438; Fri, 15 Jul 1994 01:24:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA05426; Fri, 15 Jul 1994 01:15:44 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16384; Fri, 15 Jul 1994 01:15:39 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA11739; Thu, 14 Jul 1994 08:15:32 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Jul 1994 08:15:36 -0700 To: yakov@watson.ibm.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: What's it all about? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 6:22 AM 7/14/94, yakov@watson.ibm.com wrote: >Ref: Your note of Wed, 13 Jul 1994 21:10:25 -0700 > >>the art of making progress in the IETF is in accepting what is >>acceptable, rather than waiting for the ideal. > >The art of developing successful technical solutions in presence >of multiple design choices is in constructive criticism for the >purpose of getting a better understanding. Yakov, we are about 10 days from a final decision, after roughly 2 years of work. We have thrashed 'multiple design choices' throughout that time. The current round of discussion is NOT serving to reach conclusion, it is serving to destablize things. >As far as I can see, Noel's (as well as other people's) postings to >the Big-I mailing list are essential to understand the set of the Wrong. We ain't achieving any greater understanding. All we are doing is re-hashing material that was old a year ago. Take a look at the content of the recent messages. They really are not saying anything new. They really are not triggering focused discussion towards a constructive conclusion. All they are doing is facilitating group fear,uncertainty,and doubt. It's time to stop. >Trying to sweep open issues under the carpet is certainly *not* constructive. Wrong assessment. Making a decision after long, hard, open, thorough discussion is not a matter of sweeping things under the rug. It is a matter of making a decision and choosing to live with it. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 01:26:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16730; Fri, 15 Jul 1994 01:26:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA05466; Fri, 15 Jul 1994 01:25:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA05429; Fri, 15 Jul 1994 01:17:26 +1000 Precedence: list Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16511; Fri, 15 Jul 1994 01:17:17 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27052; Thu, 14 Jul 94 11:14:20 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA22894; Thu, 14 Jul 94 11:11:59 EDT Date: Thu, 14 Jul 94 11:11:59 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9407141511.AA22894@pobox.wellfleet> To: hcb@clark.net Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: Big-Internet@munnari.OZ.AU The long distance carrier of choice is a default for a given telephone number. So, if I want to place a call from a number using a different provider: 1-0- preamble for alternate provider access 5 digits for provider code 0 to indicate alternate billing now the 14 digits Jon cites # delimiter if I want to speed 3rd party billing 10 digits or so for a credit card number another # for speed. >From the user perspective, we have something along the lines of 23 digits for a user to do limited source routing in the telephone network. For us "north americans" who have recently been shocked to find prices of $300 per hour and up to call home from hotels overseas, and who have therefore gotten an (ATT or MCI or ...) calling card, this same scenario is of course very familiar. To me this implies two things: (i) In some cases, actually used today in the phone network, folks do use considerably more than 14 digits of phone number (ie, "locator"); (ii) However, in all cases, in fact the additional address bits are really creating the functions of a source route (or the functions of authentication, or billing, which really *should* have been kept separate from addressing). I can think of other cases (from a data communications point of view rather than a phone company point of view) where you need more than 16 bytes of address. However, again every case that I have been able to think of is actually handled *better* by source routing, rather than by addresses longer than 16 bytes. This is the thinking which has led me (who once might have been called a variable address advocate) to feel that 16 byte fixed length addresses, plus an efficient source route mechanism, is a sensible solution. The trick is to make sure that the source route mechanism really is efficient enough that folks will be willing to use it (in contrast with the current IP and CLNP source routing). Ross From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 01:56:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15945; Fri, 15 Jul 1994 01:05:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA05382; Fri, 15 Jul 1994 01:04:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA05372; Fri, 15 Jul 1994 00:55:56 +1000 Precedence: list Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15438; Fri, 15 Jul 1994 00:49:22 +1000 (from day@BBN.COM) Message-Id: <9407141449.15438@munnari.oz.au> From: John Day Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: J.Crowcroft@cs.ucl.ac.uk Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <618.774171916@cs.ucl.ac.uk> Date: Thu, 14 Jul 94 10:54:27 EST Mail-System-Version: > >the phone system is 14 decimal digits max > correct. >typically, to dial anywhere, you get >country code: 3 digits actually 1 - 3. >area code/city: 2-3 actually 1 - 3 >exchange: 3-4 >EID (my handset: 4 > correct, although it isn't an EID. Or if it is only as a degenerate case since there are no multi-homed phones. The problem is that are going to be many more hosts than phones. Phones really do require a mapping (most of the time) to humans. Computers much less often. John From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 02:05:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18240; Fri, 15 Jul 1994 02:05:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05520; Fri, 15 Jul 1994 02:04:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05515; Fri, 15 Jul 1994 02:01:37 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18049; Fri, 15 Jul 1994 02:01:34 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29474; Thu, 14 Jul 1994 18:01:48 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07421; Thu, 14 Jul 1994 18:01:27 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407141601.AA07421@dxcoms.cern.ch> Subject: Truce? To: big-internet@munnari.OZ.AU (bigi) Date: Thu, 14 Jul 1994 18:01:27 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 398 I'd like to nominate the thread "Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements" for the 1994 Monster Mail Thread Hall of Fame award and to suggest that we call a truce. I think everybody has fairly thoroughly dumped their brains. If you continue, please change to a more specific subject for each sub-loop of this discussion. See you at the BOFs in Toronto? Brian From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 02:24:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18753; Fri, 15 Jul 1994 02:24:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05589; Fri, 15 Jul 1994 02:24:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05557; Fri, 15 Jul 1994 02:07:59 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18303; Fri, 15 Jul 1994 02:07:54 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEP0970MPC00028N@FNAL.FNAL.GOV>; Thu, 14 Jul 1994 11:07:44 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA14846; Thu, 14 Jul 94 11:07:18 CDT Date: Thu, 14 Jul 1994 11:07:18 -0500 From: Matt Crawford Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Thu, 14 Jul 94 08:50:13 +0100. <9407140650.AA16677@dxcoms.cern.ch> To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU Message-Id: <9407141607.AA14846@munin.fnal.gov> Content-Transfer-Encoding: 7BIT I think you are asking whether 8 bytes is enough to route to a subnet. If we take the design goal as 10**12 networks, the Huitema ratio is 12/64 = 0.19 so the answer is yes. Whoa there. I understood the log in the formula to be a log to base 2. That makes the ratio about 40/64=0.62. Is the answer still yes, or a little more hazy? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 02:58:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16044; Fri, 15 Jul 1994 01:06:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA05399; Fri, 15 Jul 1994 01:06:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA05375; Fri, 15 Jul 1994 00:57:41 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15307; Fri, 15 Jul 1994 00:44:45 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id KAA14649; Thu, 14 Jul 1994 10:44:22 -0400 From: Howard Berkowitz Message-Id: <199407141444.KAA14649@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: Greg_Minshall@Novell.COM (Greg Minshall) Date: Thu, 14 Jul 1994 10:44:21 -0400 (EDT) Cc: hcb@clark.net, big-Internet@munnari.OZ.AU In-Reply-To: <9407141425.AB12388@WC.Novell.COM> from "Greg Minshall" at Jul 14, 94 07:25:00 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2581 > At 8:22 AM 7/13/94 -0400, Howard Berkowitz wrote: > >In order to gain market share for IPng, and minimize the > >conversion effort, I am trying to avoid extensive needs for > >masking and manimpulation of addresses. I don't insist things > >be on byte boundaries, but I lean in the direction of nibble > >alignment. I am willing even to relax the nibble requirement, if the new version of the Gateway Requirements Document makes it MANDATORY that the user should be able to avoid doing bit mask calculations. There was some discussion a while back of defining things that a Certified Novell Engineer (CNE) could set up. The context of the discussion was that a CNE is a technician with a relatively low level of required theory. The market reality, however, is that the CNE level of knowledge (and this is controversial, because the certification is based on passing multiple choice tests) is relatively elite among user system administrators. If the user has to construct the address, hex is the least unfriendly way to do things. That is why I might not go below the nibble level. If, however, the market demands, in a consistent way (hence the Requirements Document) a configuration capability that lets the user specify "host 3 on this LAN" rather than its address, use the address bits any way that makes technical sense > > In support of what Howard is asking for, let me list, again, my list of > three things i'd like for IPng: > > 1. Totally trivial (stateless, auto-) configuration of end systems. And that raises all sorts of operational issues about the trust- worthiness of the MAC address, if that is used. > > 2. Make router configuration significantly easier than it is today for IPv4. > Some of my own research is directed at this, and it's not easy... every time I think I have a decent prototype for my IP address setup, I think of more rules. The "friendly" configuration builders available assume that the addressing plan has been designed. I just finished beating up on one of our sales people who wanted to offer a fixed price consulting package, or fixed based on number of nodes, to "review your naming and addressing plan." > 3. Ease discovery of *local* (campus, say) services (like DNS, etc.) in a > way which is extensible (in terms of adding new services). > > Howard (and Brian C. and Eric F., i think) is arguing for the *features* of > #2. (I, personally, am not sure i know how best to achieve #2.) > > Greg From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 03:02:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18298; Fri, 15 Jul 1994 02:07:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05538; Fri, 15 Jul 1994 02:07:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA05498; Fri, 15 Jul 1994 01:50:16 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17684; Fri, 15 Jul 1994 01:50:09 +1000 (from sob@hsdndev.harvard.edu) Date: Thu, 14 Jul 94 11:49:56 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407141549.AA09308@hsdndev.harvard.edu> To: Greg_Minshall@Novell.COM, vjs@rhyolite.denver.sgi.com Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: Big-Internet@munnari.OZ.AU > It would be interesting, however, to have people who've implemented TCP > over CLNP to run some random experiments and give us answers to TCP/CLNP > speed compared to TCP/IP speed. data points Cisco 7000 with ssp 15 stream test (30 ports) - 64 byte packets throughput (manimum zero loss rate) IP - 104955 pps OSI - 112800 pps maximuim forwarding rate (without regard to loss) IP - 222821 pps OSI - 184376 pps 3Com Netbuilder II ( two year old test ) 4 stream ( 8 port ) - 64 byte packets throughput (manimum zero loss rate) IP - 50647 pps OSI - 25679 pps maximuim forwarding rate (without regard to loss) IP - 57986 pps OSI - 25994 pps Scott From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 03:04:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18314; Fri, 15 Jul 1994 02:08:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05555; Fri, 15 Jul 1994 02:07:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA05501; Fri, 15 Jul 1994 01:52:36 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17818; Fri, 15 Jul 1994 01:52:30 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEOZP0R6AO00020K@FNAL.FNAL.GOV>; Thu, 14 Jul 1994 10:52:15 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA14774; Thu, 14 Jul 94 10:51:48 CDT Date: Thu, 14 Jul 1994 10:51:47 -0500 From: Matt Crawford Subject: Re: What's it all about? In-Reply-To: Your message of Wed, 13 Jul 94 17:25:24 PDT. To: big-internet@munnari.OZ.AU Message-Id: <9407141551.AA14774@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Thank you, Dave, for that cold water in the hot faces. Whenever someone says "Here's how we can/will/should divide up a fixed address of N bytes," another camp claims that some portion will get used up too fast. My own reaction, FWIW, is to fix on 16 but define the address fields with lots of wide-open spaces. That way the rebuttal to the above snipe is, "Fine. We have room for that." (Although I find Steve D's 8 Is Enough argument persuasive, I don't think 8 bytes would fly politico-socially.) On EIDs (or other fashionable names): There's no earthly reason for them to appear in every packet, since the flow ID + source address subsumes their function for packet forwarding and demultiplexing. If the transport layer wants to see it for every datagram, the internetwork layer can cache it and attach it. Therefore let them not use up any of the address bytes. With no EID (and no AFI or NSEL), a 16 byte IPng address is bigger than an OSI NSAP. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 03:06:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18868; Fri, 15 Jul 1994 02:26:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05617; Fri, 15 Jul 1994 02:25:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05522; Fri, 15 Jul 1994 02:04:56 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18234; Fri, 15 Jul 1994 02:04:47 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id MAA25632; Thu, 14 Jul 1994 12:04:38 -0400 From: Howard Berkowitz Message-Id: <199407141604.MAA25632@clark.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: rcallon@pobox.wellfleet.com (Ross Callon) Date: Thu, 14 Jul 1994 12:04:37 -0400 (EDT) Cc: hcb@clark.net, Big-Internet@munnari.OZ.AU In-Reply-To: <9407141511.AA22894@pobox.wellfleet> from "Ross Callon" at Jul 14, 94 11:11:59 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2093 Ross Callon commented on my observation: > >From the user perspective, we have something along the > lines of 23 digits for a user to do limited source > routing in the telephone network. > > For us "north americans" who have recently been shocked to find prices > of $300 per hour and up to call home from hotels overseas, and who > have therefore gotten an (ATT or MCI or ...) calling card, this same > scenario is of course very familiar. > > To me this implies two things: (i) In some cases, actually used today > in the phone network, folks do use considerably more than 14 digits > of phone number (ie, "locator"); (ii) However, in all cases, in fact > the additional address bits are really creating the functions of a > source route (or the functions of authentication, or billing, which > really *should* have been kept separate from addressing). I agree completely with (ii). However, this is an example of (a) That people are forced to deal with >5 digit "thingies" (b) That the market will force awkward human interfaces if some goal must be met. > > I can think of other cases (from a data communications point of view > rather than a phone company point of view) where you need more than > 16 bytes of address. However, again every case that I have been able > to think of is actually handled *better* by source routing, rather > than by addresses longer than 16 bytes. I can't think of a counterexample. > > This is the thinking which has led me (who once might have been > called a variable address advocate) to feel that 16 byte fixed > length addresses, plus an efficient source route mechanism, is a > sensible solution. The trick is to make sure that the source route > mechanism really is efficient enough that folks will be willing to > use it (in contrast with the current IP and CLNP source routing). I agree strongly. Again, I do hold out for either holding fields in the 16 octet string to nibble alignment, or to come up with firm requirements for human interfaces to hide the bit twiddling. Howard From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 03:12:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20249; Fri, 15 Jul 1994 03:05:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA05663; Fri, 15 Jul 1994 03:04:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05647; Fri, 15 Jul 1994 02:50:48 +1000 Precedence: list Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19717; Fri, 15 Jul 1994 02:50:44 +1000 (from day@BBN.COM) Message-Id: <9407141650.19717@munnari.oz.au> From: John Day Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: vjs@rhyolite.denver.sgi.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407132218.AA24032@rhyolite.denver.sgi.com> Date: Thu, 14 Jul 94 12:57:26 EST Mail-System-Version: > >The problem in the ISO was not in the technical details designs, but in >what they wanted to do and how they went about it. What they did >technically right or wrong is a red herring. Unless the IETF avoids >the ISO style of development, IPng will have the same fate as the OSI >protocols. Style begats substance when you are dealing with >committees, whether the IETF or the ISO. > This is trure but not how you think. The ISO process failed because the Europeans and their PTTS came to it with a political agenda. The battle lines were computer vendors vs telephone companies and Europe vs US vs Japan. Remember the days of the "level playing field." Europe would not accept any solution that was already underway in the US. And even more to the point, connection-oriented networking was to be the only means of doing anything. CLNP was tolerated but was viewed as a mostly lead US effort. If Europe had had their way there would be no connectionless at all in OSI. X.25 was all you should ever want. Given experience with the PTTs they felt that they could legislate the answer and everyone would just follow. But the world was changing. Markets were not that docile. The US understood this and tried to move things in other directions, but the US only has one vote. The failure with the process was not technical, nor was that they were pushing a political agenda over a technical one. The failure was that the European computer and telecom industry couldn't implement the legislation fast enough or well enough. > >Thus, the ISO had TP0 through TP4 and CONS as well as CLNS, to satisfy >all constinuencies and contingencies forever, all in a Correct 7-Layer >Architecture. Sorry, but TP0 - 4 was not trying to solve all contingencies. Once again it was politics that ended up with that crap. Most of us knew that only TP4 was necessary, that it was implementable in all situations and ran well. But many of the Europeans believed that you didn't need a transport protocol at all because the X.25 was reliable and they wanted Teletex to be OSI hence TP0 as insisted on by CCITT SGVIII; Believed you needed something but no multiplexing so customers can't avoid charges for connections and X.25 is more or less reliable, TP1as insisted on by CCITT SGVII; allowed multiplexing, but X.25 was somewhat reliable, TP2as insisted on by CCITT SGVII users; etc. When in fact TP4 is just as fast and no more overhead under the same error conditions and the implementations are not that much different. But they did not want to hear that. Finally it had to come down to taking all 5 and assuming that the market would decide. It did. Now I think you are right about trying to do too much at once when it comes to X.400 and X.500 I think you are right. There is too much initial functionality. There is no small core to bring it up. In particular, X.500 was designed for e-mail and then statement was made that if it was good for this it was good for everything. It is a case of doing Release 3 before Release 1. > >By the way, I'm irritated by some recent statements. The fate of the >OSI protocols had nothing to do with > - who funded them--The DoD spent far more on OSI code than > Berekley ever conceived of asking for. This statement is true. But the amount spent by the DoD on TCP started back about 1973 and was considerably more than DoD ever spent on OSI. > - whether the documents had to be bought at $100/copy from > ANSI or Global Engineering Documents, Inc., > or FTP'ed "for free" over $20,000/year Internet connections. > - electronic communication--committees are committees. Agreed. There are many reasons for the lack of adoption of OSI. I have not even touched on some of the political games played by various computer and workstation manufactures to lower the probability. But the primary reasons are attempts to legislate the solution without the ability to follow it through by either fast product sales or building a network like the Net. Contrary to what you may like to believe, a basically free network and free software probably had more to do with it than anything else. One must take cognizances of Noel's comments. Not every thing that OSI did was bad. It did learn from some mistakes that we made in the net fairly early on. (And for good reason, we were still sorting all of this stuff out.) Things like: network addresses shouldn't name interfaces; the routing framework, i.e. a protocol for managing net-address to subnet-address mapping, a protocol for intra-domain routing and inter-domain routing is a good start, the necessity of application-names and not well-known sockets, an simple recursive application architecture. TP4 has several advantages over TCP, etc. There were a lot of forces pulling at OSI. Few of them technical. There is much to be learned from it some of it technical. The telephone companies are now much more receptive to connectionless than they were 10 years ago. The IETF has been saved some pretty ugly battles. And maybe able to avoid some pretty bad pitfalls, if they are willing to look carefully and understand what was really going on. Take care John From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 03:59:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20869; Fri, 15 Jul 1994 03:24:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA05693; Fri, 15 Jul 1994 03:24:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA05679; Fri, 15 Jul 1994 03:08:32 +1000 Precedence: list Received: from netcom4.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20296; Fri, 15 Jul 1994 03:08:28 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id KAA16585; Thu, 14 Jul 1994 10:08:42 -0700 Date: Thu, 14 Jul 1994 10:08:42 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407141708.KAA16585@netcom4.netcom.com> To: big-internet@munnari.OZ.AU Subject: Re: What's it all about? >>As far as I can see, Noel's (as well as other people's) postings to >>the Big-I mailing list are essential to understand the set of the > >Wrong. We ain't achieving any greater understanding. All we are doing is >re-hashing material that was old a year ago. Take a look at the content of >the recent messages. They really are not saying anything new. They really >are not triggering focused discussion towards a constructive conclusion. >All they are doing is facilitating group fear,uncertainty,and doubt. It's >time to stop. While I almost agree with this statement Dave has made, I would like to make one comment about the decision that has been reached after 2 years of debate (as mentioned earlier in the note ((which was deleted))). If you believe that the SIPP model is the clear winner (as Noel stated yesterday in one of his postings) then the fact that we have come to closure on 16 bytes is a bit bizzaire. I mean SIP, PIP and SIPP all seemed to be based on 8 byte addresses for so long. They were published to the general public as such. The non-IETF'ers out there read and beleive that if {P,S}IP{P} is the next IP, then addresses will be 8 bytes. (I know of companies that are making allowances for the IP address to grow, to 8 bytes). It seemed that this was the address size agreed upon for a long time and yet it was changed, in the SIPP context, in a small meeting, with limited participants!! So I must agree with Noel that this issue needs some discussion, even if we are 2 weeks away from Toronto! What surprises me a little is that if Noel really beleived SIPP is/was the clear winner, then why isn't he fighting to keep the original 8 byte addresses. This seems obvious, by changing the size after all of this time the door to redebate has been opened and this allows all to have new or old opinions. I realize that SIPP had options for extending the address but this was being done via options. I tend to like this since it puts off the need of carrying larger addresses for 20-30 years and it can still be used to support auto-configuration using the old IEEE addresses. >>Trying to sweep open issues under the carpet is certainly *not* constructive. > >Wrong assessment. Making a decision after long, hard, open, thorough >discussion is not a matter of sweeping things under the rug. It is a >matter of making a decision and choosing to live with it. Right! Make a decision and live with it. I would even go as far as saying make a decision and implement it. Have we done this? >Dave -rich From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 04:05:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22019; Fri, 15 Jul 1994 04:05:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05756; Fri, 15 Jul 1994 04:04:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA05734; Fri, 15 Jul 1994 03:48:38 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21553; Fri, 15 Jul 1994 03:48:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09804; Thu, 14 Jul 94 13:48:29 -0400 Date: Thu, 14 Jul 94 13:48:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407141748.AA09804@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kck@netcom.com Subject: Re: What's it all about? Cc: jnc@ginger.lcs.mit.edu From: kck@netcom.com (Richard Fox) If you believe that the SIPP model is the clear winner (as Noel stated yesterday in one of his postings) Well, to be more precise, I was really indicating that Tuba, Catnip, etc are clearly not going to be the choice. It's vanilla SIPP, or modified SIPP, or something like that. I mean SIP, PIP and SIPP all seemed to be based on 8 byte addresses for so long. Huh? PIP *never* had fixed length addresses. Perhaps you are thinking of the source and destination "identifiers" (which are EID's, in the original definition of "EID". What surprises me a little is that if Noel really beleived SIPP is/was the clear winner, then why isn't he fighting to keep the original 8 byte addresses. Hey, just because I think some variant of SIPP is going to be the winner, that doesn't mean I like the design. I'd no more argue for 8 byte addresses than I'd argue, say, well, I can't think of an outrageous enough simile. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 04:06:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22053; Fri, 15 Jul 1994 04:06:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05771; Fri, 15 Jul 1994 04:06:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA05751; Fri, 15 Jul 1994 04:02:36 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21966; Fri, 15 Jul 1994 04:02:33 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA12812; Thu, 14 Jul 1994 11:00:08 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Jul 1994 11:00:12 -0700 To: kck@netcom.com (Richard Fox) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: What's it all about? Cc: big-internet@munnari.OZ.AU At 10:08 AM 7/14/94, Richard Fox wrote: >deleted))). If you believe that the SIPP model is the clear winner (as >Noel stated yesterday in one of his postings) then the fact that we >have come to closure on 16 bytes is a bit bizzaire. I mean SIP, PIP >and SIPP all seemed to be based on 8 byte addresses for so long. They Rich, while it might be strange to have the change from 8 to 16 this late, the reason, I think is straightforward. There has long been discomfort with 8 bytes. It's been expressed by many and frequently, starting within the original SIP (actually, then it was IPAE) working group debates. Holding on to 8 so long has come at least for 3 reasons: Steve Deering has been tenacious; Steve offered solid analysis for the reason that 8 was enough; and the community didn't focus on this particular and discrete question. Around the time of -- or at -- the Chicago IPng Directorate meeting (I am told) the question of 8 was one of the highlighted sticking points. To responsd to this, an alternate proposal was formulated. This all sounds like just the right process to me. Take a position. Defend it carefully. Give in when the force of group pressure requires a specific change. The beauty of the IETF is just this sort of sequence, IMO. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 04:07:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22164; Fri, 15 Jul 1994 04:07:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05793; Fri, 15 Jul 1994 04:07:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA05748; Fri, 15 Jul 1994 03:58:18 +1000 Precedence: list Received: from ietf.cnri.reston.va.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20502; Fri, 15 Jul 1994 03:14:30 +1000 (from cclark@CNRI.Reston.VA.US) Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04948; 14 Jul 94 11:27 EDT To: big-internet@munnari.OZ.AU, mankin@cmf.nrl.navy.mil, sob@harvard.edu Cc: cclark@CNRI.Reston.VA.US, osterman1@llnl.gov Subject: RE: Re: Does LLNL care about IPng address sizes? Date: Thu, 14 Jul 94 11:27:45 -0400 From: Cynthia Clark Message-Id: <9407141127.aa04948@IETF.CNRI.Reston.VA.US> Folks, Upon Dave Osterman's request, I'm just forwarding his response below. Kind Regards, Cynthia Clark ------- Forwarded Message Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11477; 8 Jul 94 19:18 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27704; 8 Jul 94 19:18 EDT Received: from popcorn.llnl.gov by IETF.CNRI.Reston.VA.US id aa11470; 8 Jul 94 19:18 EDT Received: from [128.115.54.30] (buchanan.llnl.gov) by popcorn.llnl.gov (4.1/LLNL-1.19) id AA03691; Fri, 8 Jul 94 16:16:24 PDT Message-Id: <9407082316.AA03691@popcorn.llnl.gov> X-Sender: e672965@popcorn.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Jul 1994 16:18:14 -0800 To: ietf-request@IETF.CNRI.Reston.VA.US From: Dave Osterman Subject: Re: Does LLNL care about IPng address sizes? >Therefore, this message is to ask people what present or future rationale >they see for one of: > > 8 byte fixed length address. > > 16 byte fixed length address. > > longer than 16 byte fixed length address now. > > only 16 byte length addresses now but ability > to lengthen the address later. > >To amplify a bit more, we are especially interested in your views >on the address length's ability to offer: > > routing aggregation power > > topological flexibility > > adminstrative manageability > Although it is almost impossible for me to conceive of a need for an address longer than 8 bytes I vote for 16 byte fixed length address now which can be extended to a longer address later. Considering the number of machines that will be affected on my networks (~8000) what I would prefer is that the machines on my nets would stay at 4 bytes and the extra 12 bytes would be handled by routing systems that knew how to map to the extended addresses, but that I'm sure is too much to hope for. Dave Osterman LLNL Network Manager osterman1@llnl.gov 510-422-3499 ------- End of Forwarded Message From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 04:25:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22737; Fri, 15 Jul 1994 04:25:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05827; Fri, 15 Jul 1994 04:24:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA05776; Fri, 15 Jul 1994 04:06:25 +1000 Precedence: list Received: from research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22047; Fri, 15 Jul 1994 04:06:05 +1000 (from smb@research.att.com) Message-Id: <9407141806.22047@munnari.oz.au> From: smb@ninet.research.att.com Received: by gryphon; Thu Jul 14 13:57:22 EDT 1994 To: kck@netcom.com (Richard Fox) Cc: big-internet@munnari.OZ.AU Subject: Re: What's it all about? Date: Thu, 14 Jul 94 13:57:20 EDT I realize that SIPP had options for extending the address but this was being done via options. I tend to like this since it puts off the need of carrying larger addresses for 20-30 years and it can still be used to support auto-configuration using the old IEEE addresses. One of the outcomes of the Big 10 meeting was the realization that using SIPP's source routing for address space extension -- as opposed to any other needs for source routing -- didn't work well. At least, it didn't work well in combination with other things, such as local addresses. To have enough headroom for the future, and to support autoconfiguration of globally-unique addresses, 16 bytes seemed (to most of us) to work a lot better. I agree, though, that it would be useful if someone would write an informational RFC on the exact points that went into that decision. --Steve Bellovin P.S. I do agree that most of the discussion on this topic has been a lot of noise. I agree with Paul Francis: let's all shut up unless we have (a) hard data, such as Scott Bradner posted, (b) a new analysis (Christian Huitema's ratios were fascinating and useful), or (c) a concrete example of something that one proposal or the other *cannot do*. In that line, I'll add my own small observation: that it is valuable to extend the address space on the right, because I forsee a need for many IP(ng) addresses per host. I wrote up my ideas (which were partially based on converations with Matt Blaze) in an IPng White Paper; if you care, you can snarf draft-bellovin-ipng-addr-per-host-00.txt from your favorite internet-drafts directory. From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 05:25:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24472; Fri, 15 Jul 1994 05:25:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05896; Fri, 15 Jul 1994 05:24:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA05880; Fri, 15 Jul 1994 05:05:21 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23978; Fri, 15 Jul 1994 05:05:18 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA14007; Thu, 14 Jul 94 13:05:01 MDT Received: from [130.57.64.151] by WC.Novell.COM (4.1/SMI-4.1) id AA13504; Thu, 14 Jul 94 12:00:41 PDT Date: Thu, 14 Jul 94 12:00:40 PDT Message-Id: <9407141900.AA13504@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: big-internet@munnari.OZ.AU From: Greg Minshall Subject: VL length A *small* observation: There are very *few* things that need to be in a packet as addressed by a host to get end-to-end communications between any two arbitrary hosts. It is *possbile* that the only real thing is a destination address (to get it there) and a source address (to get something back). Hop counts can be forged by the routing system. Transport demultiplexing can either be the same on each end, or can be mapped (mainly because there aren't that many transports). Probably the ends need to agree on maximum internet datagram length. I *think* that the argument on variable vs. fixed length addresses is, in part, a question of future connectivity. When we move to IPng, IPv4 systems will continue to be able to communicate with "all" other IPv4 systems, as well as with IPng systems that have "IPv4 compatible" addresses. But, they won't be able to communicate with IPng systems that have non-IPv4 compatible addresses. Think about that for a while. ... Even though IPng will have new *features* (flows, for one), it will transport IPv4 semantic datagrams. Likely as not, even though IPngng will have new features, it will transport IPng semantic datagrams. But, it can only transport these datagrams as far as the sending system can address them. If the IPngng address is larger (content clearly, not necessarily form) than the IPng address, there are going to be connectivity issues. VL now (to repeat myself) is really a question of the IPng->IPngng transition requirements. Greg (not holding a fixed opinion on the VL question) ps - Which is to say, yes, Mike O'Dell, before 30 years has expired, there will be *plenty* of reason to have different format headers on the wires. The question is, do you want to continue to support IPng semantics and what scope of connectivity do you want to have, at IPng semantics, of IPng hosts into the IPngng internet? pps - People know i never have original thoughts. This is one of those non-original thoughts. From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 06:05:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25796; Fri, 15 Jul 1994 06:05:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA05951; Fri, 15 Jul 1994 06:04:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA05946; Fri, 15 Jul 1994 05:59:58 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24861; Fri, 15 Jul 1994 05:38:00 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id PAA18845; Thu, 14 Jul 1994 15:37:43 -0400 Date: Thu, 14 Jul 1994 15:37:43 -0400 From: Vadim Antonov Message-Id: <199407141937.PAA18845@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, mankin@cmf.nrl.nay.mil, sob@harvard.edu, vaf@Valinor.Stanford.EDU >I would like to express my heartfelt agreement with Yakov's message - any >discussion of variable vs. fixed "addresses" and the length of same is >meaningless until we make a clean split of topology-based address (what some >have been calling a "locator") and endpoint-ID. The overload of these two, >distinct functions onto a single addressing/naming quantity was a mistake in >IPv4 that needs to be fixed in the new architecture. For the time being nobody explained why it is necessary to have EIDs in the packet headers and *why* EIDs cannot be identical with domain names. Can anybody *prove* that EIDs in headers are necessary? Before that it is nothing more than yet another "feature" designed to complicate the life of network administrators. Being an administrator of a large network myself i definitely would prefer the project which assumes the least amount of required manual configuration. Also, it is my opinion that autoconfiguration should be *mandatory*, not an option. I'm sick of tracking down bogus routes created by human configuration mistakes. Internet (as it is now) can be killed with a couple of strategically injected bogus routes. With the general level of user cluelessness going up we're lucky the whole thing is still working. --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 09:01:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28197; Fri, 15 Jul 1994 07:25:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA06030; Fri, 15 Jul 1994 07:24:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA06025; Fri, 15 Jul 1994 07:17:08 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27997; Fri, 15 Jul 1994 07:16:58 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA00194; Thu, 14 Jul 94 16:18:54 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ao22533; 14 Jul 94 21:14 GMT Date: Thu, 14 Jul 94 16:12 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Christian Huitema Cc: Big Internet Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Message-Id: <65940714211256/0003858921NA5EM@mcimail.com> Christian Huitema said: >This whole business of estimating efficiency, numbers of levels, etc, is >difficult to assert. When I try to do this assertion myself, I come to the >conclusion that figures like "margin of 1.0E+3" are misleading, because >they don't take into account the number of levels. I would suggest that we >measure the efficiency on a logarithmic scale: > > log (number of objects) > ----------------------- > available bits > >I will use base 10 logs in what follows, because they are easier to compute >mentally. >The advantage here is that the ratio does not depend too much of the number >of levels. Now, we can take existence proofs from existing numbering plans. >What is especially interesting is to consider the moment where the plans >broke, i.e. when people were forced to add digits to phone number, or to >add bits to computer addresses. I have a number of such figures handy, I finally got to this message. I am swamped! If Christian is correct in his math, then we either bite into 128 bits today and pay the price, or do 64 today with the option of easily expanding to 128 'tomorrow'. It also raises an interesting side question as to when MAC addresses will outgrow its 6 byte size! Or actually a 3+3 address. I really think that we can do something really creative with addressing, using some good server based configuration systems. That EIDs can be stuffed into 8 bytes, fairly densely. The question then remains can we do topology with 64 bits; gee that is 10 levels, 6 bits each and four bits left over for identifing the type of address! (remember 6 bit, i.e. OCTAL numbers? Or how about those 7 bit DEC systems?). So, based on Christian's analysis, I'm staying with 64 bit addresses as more than adequate for our needs. Next we need to divy them up in such a way that all of our great plans for addressing are met.... Bob From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 09:17:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01609; Fri, 15 Jul 1994 09:05:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06146; Fri, 15 Jul 1994 09:04:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06119; Fri, 15 Jul 1994 08:50:35 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01112; Fri, 15 Jul 1994 08:50:29 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA29992; Thu, 14 Jul 94 15:52:42 -0700 Date: Thu, 14 Jul 94 15:52:42 -0700 From: Eric Fleischman Message-Id: <9407142252.AA29992@atc.boeing.com> To: Greg_Minshall@novell.com, hcb@clark.net Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-Internet@munnari.OZ.AU >In support of what Howard is asking for, let me list, again, my list of >three things i'd like for IPng: > >1. Totally trivial (stateless, auto-) configuration of end systems. > >2. Make router configuration significantly easier than it is today for IPv4. > >3. Ease discovery of *local* (campus, say) services (like DNS, etc.) in a >way which is extensible (in terms of adding new services). > >Howard (and Brian C. and Eric F., i think) is arguing for the *features* of >#2. (I, personally, am not sure i know how best to achieve #2.) Dear Greg, Not at all: I *fully* agree with YOU: I want all three of these things too. More to the point, I would like IPng to have the same ease of use from the user's point-of-view as XNS, AppleTalk, some versions of NetBIOS, and IPX/SPX. I also want IPng to be as easy to administer and support and to be as robust as XNS. I realize this is a very tall order, but this is what I think that all of us users really would like to see. Of course, (here's a killer) the solution also needs to be fully secure as well and provide an "over-ride mode" for hand configuration in super-secure environments. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 09:17:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01662; Fri, 15 Jul 1994 09:07:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06163; Fri, 15 Jul 1994 09:07:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06133; Fri, 15 Jul 1994 08:55:27 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27797; Fri, 15 Jul 1994 07:05:21 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwyoi13204; Thu, 14 Jul 1994 17:05:13 -0400 Message-Id: To: Vadim Antonov Cc: big-internet@munnari.OZ.AU Subject: re: prove you need EIDs in the header.... In-Reply-To: Your message of "Thu, 14 Jul 1994 15:37:43 EDT." <199407141937.PAA18845@titan.sprintlink.net> Date: Thu, 14 Jul 1994 17:05:05 -0400 From: "Mike O'Dell" in this game "proving" much of anything is pretty tricky. what I will assert is: given our current transport protocols, tcp & udp, to build mobile IP which can do inter-fabric roaming (intra-fabric is handled by the fabric) REQUIRES an identifying bit-string to put in the transport protocol control blocks which is INVARIANT of the instantaneous topological path between the communicating parties. The requirement is for transport associations to survive transitions between individual mobility fabrics, regardless of how large or small the service area might be. It has been suggested here and elsewhere that one might introduce a "shim" in the IPng interface to negotiate a "temporary EID" to use for this purpose, but this would seem to induce state and all kinds of other complexity into the IPng layer. I find this alternative a Bad Idea. Therefore, given that reinventing transport protocols is currently out of scope, I cannot see how to get real, scalable mobility to work (ie, without "3 cushion shot" routing) unless there is some part of the "address" that identifies the endpoints and which has this property of Invariance with respect to changing network connectivity topology. NOTE: this invariant does not have to be so for all space and time, but it DOES have to be invariant for the duration of the surviving TCP connections, so the duration is on the scale of at least hours and thousands of miles. -Mike O'Dell From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 09:18:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01684; Fri, 15 Jul 1994 09:08:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06178; Fri, 15 Jul 1994 09:07:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06139; Fri, 15 Jul 1994 08:58:22 +1000 Precedence: list Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28167; Fri, 15 Jul 1994 07:23:53 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AB03582; Thu, 14 Jul 94 17:18:07 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA03589; Thu, 14 Jul 94 17:15:46 EDT Date: Thu, 14 Jul 94 17:15:46 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9407142115.AA03589@pobox.wellfleet> To: big-internet@munnari.OZ.AU, kck@netcom.com Subject: Re: What's it all about? While I almost agree with this statement Dave has made, I would like to make one comment about the decision that has been reached after 2 years of debate (as mentioned earlier in the note ((which was deleted))). If you believe that the SIPP model is the clear winner (as Noel stated yesterday in one of his postings) then the fact that we have come to closure on 16 bytes is a bit bizzaire. I mean SIP, PIP and SIPP all seemed to be based on 8 byte addresses for so long. They were published to the general public as such. The non-IETF'ers out there read and beleive that if {P,S}IP{P} is the next IP, then addresses will be 8 bytes. (I know of companies that are making allowances for the IP address to grow, to 8 bytes). It seemed that this was the address size agreed upon for a long time and yet it was changed, in the SIPP context, in a small meeting, with limited participants!! So I must agree with Noel that this issue needs some discussion, even if we are 2 weeks away from Toronto! What surprises me a little is that if Noel really beleived SIPP is/was the clear winner, then why isn't he fighting to keep the original 8 byte addresses. This seems obvious, by changing the size after all of this time the door to redebate has been opened and this allows all to have new or old opinions. Rich; The fact that SIPP might be viewed as the winner in many ways does not necessarily mean that *every* aspect of the original SIPP design was perfect. The ability to improve designs is part of the way that the IETF succeeds. Two years ago some of us (myself included) were saying that the two problems with SIPP were the small addresses (8 bytes) and the transition scheme. Now, with 16 byte addresses, efficient source routing, and SST, these problems are fixed (modulo the need to flesh out some of the details of SST). I think that the willingness to fix SIPP is part of what makes it acceptable/attractive to many folks. If there is a company out there which is planning on 8 byte addresses for IPng, then that company would be better off to fix their plans now, rather than later. Ross From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 09:21:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01713; Fri, 15 Jul 1994 09:09:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06197; Fri, 15 Jul 1994 09:08:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06136; Fri, 15 Jul 1994 08:55:31 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26728; Fri, 15 Jul 1994 06:28:59 +1000 (from sob@hsdndev.harvard.edu) Date: Thu, 14 Jul 94 16:28:44 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407142028.AA17956@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU Subject: summary of Big-Internet messages Thanks very much to Bill Simpson who sent us this summary of the traffic on the big-i list since we made our request. We thought that it would be of interest and Bill agreed to let us send it out. Bill also suggested as has Yakov and others that we further clarify our question and we shall do so soon. Allison & Scott (note that this is from July 12th and there have been more than 100 messages since then ) ------- From bill.simpson@um.cc.umich.edu Tue Jul 12 19:58:52 1994 Received: from pm002-14.dialip.mich.net (pm002-14.dialip.mich.net [35.1.48.95]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA03967 for ; Tue, 12 Jul 1994 19:58:26 -0400 Date: Tue, 12 Jul 94 23:37:16 GMT From: "William Allen Simpson" Message-Id: <2818.bill.simpson@um.cc.umich.edu> To: sob@hsdndev Cc: mankin@cmf.nrl.navy.mil Reply-To: bsimpson@morningstar.com Subject: big-internet results Status: RO Looking at the 177 messages since your request: "IPng ADs Wish to Gauge Consensus on Address Length Requirements" Unfortunately, although there was a very large number of postings, when totalled, they were from a surprisingly small number of people. It seems to me that there are some items of general consensus: Splitting Identifiers from Locators: Pro: (me, of course) Dave Bridgham Richard Carlson Masataka Ohta kasten@ftp.com (Frank Kastenholz) Robert Elz mo@uunet.uu.net (Mike O'Dell) bound@zk3.dec.com jnc@ginger.lcs.mit.edu (Noel Chiappa) yakov@watson.ibm.com (a big surprise to me) Robert G. Moskowitz <0003858921@mcimail.com> "We really need the EID-Locator paradigm." "Richard L. Harris (206) 865-4922" (another surprise, no unanimity at Boeing) To this you should add just about everybody on the Nimrod list, and all the PIP adherents, since PIP also had the FTIF split. Con: Vadim Antonov Lixia Zhang Steve Deering (except that he likes clusters and source routing, which is approximately the same thing) I can't tell: Christian Huitema estrin@usc.edu daniel@ISI.EDU Smallest fixed-size address size possible, with a very complete "proof" rationale for needing more than 8 bytes: Pro: (me) "Daniel L. McDonald" Vadim Antonov vjs@rhyolite.denver.sgi.com (Vernon Schryver) fbaker@acc.com (Fred Baker) kck@netcom.com (Richard Fox) Robert Elz Jon Crowcroft "still not convinced." Paul Mockapetris Steve Deering 16 bytes minimum, plus extensible: Eric Fleischman hcb@clark.net (Howard Berkowitz, PSC International) Tony Li brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Tired of talking about it, and will settle on 16 bytes if that will stop the variable folks: Pro: "Daniel L. McDonald" kck@netcom.com (Richard Fox) Bob.Hinden@eng.sun.com (Bob Hinden) Steve Deering Con: (me) jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) "If you are going to argue based on CPU designs then the network should support "fixed length" 4, 8, and 16 byte address formats. We could refer to these sizes as old, new, and silly. :-)" From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 09:45:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03059; Fri, 15 Jul 1994 09:45:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06252; Fri, 15 Jul 1994 09:44:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA06236; Fri, 15 Jul 1994 09:28:38 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02487; Fri, 15 Jul 1994 09:28:35 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-06.dialip.mich.net (pm002-06.dialip.mich.net [35.1.48.87]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA28013 for ; Thu, 14 Jul 1994 19:28:27 -0400 Date: Thu, 14 Jul 94 22:06:07 GMT From: "William Allen Simpson" Message-Id: <2831.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Whither 8 bytes (64 bits) > From: dcrocker@mordor.stanford.edu (Dave Crocker) > There has long been discomfort with 8 bytes. It's been expressed by many > and frequently, starting within the original SIP (actually, then it was > IPAE) working group debates. Holding on to 8 so long has come at least for > 3 reasons: Steve Deering has been tenacious; Steve offered solid analysis > for the reason that 8 was enough; and the community didn't focus on this > particular and discrete question. > Dave, while I have privately agreed with you pretty much so far, I just happen to have the complete IPAE/SIP/SIPP archives here on the desktop, and did a quick perusal. According to the archives, we _did_ extensively debate how large to make the addresses. We also debated the TOS, the Packet Length, we even debated how large to make the hop count. There were months of debate! Then, as now, Noel, Ross Callon, and Brian Carpenter were the primary advocates for big fields. Noel said (on big-internet): "Bandwidth is going to be dirt cheap; all fields should be *ridiculously* big." Then, as now, Steve, Jon Crowcroft, myself, and others (even *you*), were advocating choosing minimal size. We held a BOF, and we decided not to make them bigger. We made choices, based on the information at hand, and the engineering constraints. To quote the minutes: "The discussion showed that the working group did not believe that the NSAP size was justified or needed, and that there is virtue in keeping the addresses compact." Steve and I both made lots of tables showing that all the routing and administration could be done in 8 bytes. I even redid everything (twice) to accomodate suggestions by Yakov and Tony. > Around the time of -- or at -- the Chicago IPng Directorate meeting (I am > told) the question of 8 was one of the highlighted sticking points. To > responsd to this, an alternate proposal was formulated. > To quote Steve, "Despite my belief that 8 bytes is the perfect trade-off between all the conflicting demands imposed on IPng addresses, I am willing to go along with 16-byte addresses for SIPP, ... I am getting darned tired of arguing ...." > This all sounds like just the right process to me. Take a position. > Defend it carefully. Give in when the force of group pressure requires a > specific change. The beauty of the IETF is just this sort of sequence, > IMO. > The players haven't changed. The information hasn't changed. The engineering constraints haven't changed. In point of fact, several more persons have expressed a preference for 8 bytes, but indicated in the past week that they are tired of arguing. This is not a good technical reason for "consensus". Why is this "beauty"? Moreover, it isn't really group pressure. It is the vociferous laments of a very few people. Despite the more than one MEGABYTE of email on this list in the past WEEK, the same people have actually participated. Of those asking for the smallest fixed-size address/identifier thing_in_every_packet possible, with a very complete "proof" rationale for why it can't be smaller, and mentioned a preference for 8 bytes at least once: "Daniel L. McDonald" Vadim Antonov vjs@rhyolite.denver.sgi.com (Vernon Schryver) fbaker@acc.com (Fred Baker) kck@netcom.com (Richard Fox) Richard Carlson Masataka Ohta Robert Elz mo@uunet.uu.net (Mike O'Dell) jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) Jon Crowcroft "Robert G. Moskowitz" <0003858921@mcimail.com> perk@watson.ibm.com (Charlie Perkins) Paul Mockapetris Steve Deering Matt Crawford (me) 16 bytes fixed-size: Bob.Hinden@eng.sun.com (Bob Hinden) rcallon@pobox.wellfleet.com (Ross Callon) 16 bytes minimum, extensible: Eric Fleischman hcb@clark.net (Howard Berkowitz, PSC International) Tony Li brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Lixia Zhang I can't figure out: jnc@ginger.lcs.mit.edu (Noel Chiappa) Dave Bridgham kasten@ftp.com (Frank Kastenholz) bound@zk3.dec.com yakov@watson.ibm.com Christian Huitema estrin@usc.edu daniel@ISI.EDU (you) Now, what would _you_ say is the rough consensus? The best quote of the week goes to jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) "If you are going to argue based on CPU designs then the network should support "fixed length" 4, 8, and 16 byte address formats. We could refer to these sizes as old, new, and silly. :-)" Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 10:05:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03893; Fri, 15 Jul 1994 10:05:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA06287; Fri, 15 Jul 1994 10:04:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA06268; Fri, 15 Jul 1994 09:49:03 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03248; Fri, 15 Jul 1994 09:48:51 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty12.jvnc.net. (franklin-tty12.jvnc.net) by tigger.jvnc.net with SMTP id AA03595 (5.65c/IDA-1.4.4 for Big-Internet@munnari.oz.au); Thu, 14 Jul 1994 09:15:08 -0400 Message-Id: Date: Thu, 14 Jul 94 09:14:07 EDT From: "David M. Piscitello" Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Reply-To: dave@corecom.com To: "Jon Crowcroft" , Big-Internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 E.164 won't make it to the next millenium; E.something will have to be longer. It's no accident, but it is a shame... Also, to respond to an earlier post regarding how long a number people are capable of remembering, folks who frequently dial international telephony numbers plus calling card number plus pin have the astonishing capacity to deal with between 30-40 digits. Remarkable... > >It is no accident that U.S. phone numbers are only 7 digits long, with > >occassional 3, 8, and 10 digit prefixes. > >the phone system is 14 decimal digits max > >typically, to dial anywhere, you get >country code: 3 digits >area code/city: 2-3 >exchange: 3-4 >EID (my handset: 4 > >if there;s around 4 bits per digit with some wastage, this is 4*14=56 bits >with the _current_ utilisation (600M end systems) > >do we think the phone people are wrong? >that leaves us inside 64 bits with an extra 8 bits of what used to be >quaiontly called 'subaddressing' > > jon > > David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 10:07:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04069; Fri, 15 Jul 1994 10:07:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA06304; Fri, 15 Jul 1994 10:07:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA06282; Fri, 15 Jul 1994 10:02:28 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03788; Fri, 15 Jul 1994 10:02:22 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA15056; Thu, 14 Jul 1994 17:01:53 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Jul 1994 17:01:56 -0700 To: "Mike O'Dell" From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: re: prove you need EIDs in the header.... Cc: Vadim Antonov , big-internet@munnari.OZ.AU Mike, First, I want to stress your reference to 'intra-fabric' mobility. You might not have intended to make a big deal about it, but I am concerned that we all think in terms of SOME part of the mobility problem getting solved by "local" mobility tools, rather than burdening the Internet suite in all cases. Having said that, At 2:05 PM 7/14/94, Mike O'Dell wrote: >It has been suggested here and elsewhere that one might introduce a "shim" >in the IPng interface to negotiate a "temporary EID" to use for this >purpose, but this would seem to induce state and all kinds of other complexity >into the IPng layer. I find this alternative a Bad Idea. I want to stress that my own suggestion is NOT a modification to the IP(ng) layer. It rather pointedly tries to keep the IP(ng) layer blissfully unaware of mobility. Really! (I don't recall who used the term 'shim' but I did rather like it.) My suggestion is, in effect, to the transport layer, since it requires that transport "collaborate" in the use of multiple ip addresses (for source, dest, or both) to send a single, logical transport stream. In my own mind, I do model this as a layer between transport and internet, but really believe that it constitutes a mod to transport rather than a pure, transparent mini-layer. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 11:05:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06385; Fri, 15 Jul 1994 11:05:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA06371; Fri, 15 Jul 1994 11:04:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA06366; Fri, 15 Jul 1994 11:04:29 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04687; Fri, 15 Jul 1994 10:26:12 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA15171; Thu, 14 Jul 1994 17:25:56 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Jul 1994 17:25:59 -0700 To: dave@corecom.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: "Jon Crowcroft" , Big-Internet@munnari.OZ.AU At 6:14 AM 7/14/94, David M. Piscitello wrote: >Also, to respond to an earlier post regarding how long a >number people are capable of remembering, folks who frequently dial >international telephony numbers plus calling card number plus pin >have the astonishing capacity to deal with between 30-40 digits. >Remarkable... Dave, those are heavily-used strings. The limit that is usually cited is for short-term memory. I.e., what can most folks grok with a relatively brief glance. If you expand to include arbitrary learning effort, I'm sure there is no real limit, since people have been known to memorize books. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 11:25:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06993; Fri, 15 Jul 1994 11:25:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA06403; Fri, 15 Jul 1994 11:24:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA06387; Fri, 15 Jul 1994 11:08:15 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04361; Fri, 15 Jul 1994 10:17:42 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA15105; Thu, 14 Jul 1994 17:17:22 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Jul 1994 17:17:25 -0700 To: bsimpson@morningstar.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Whither 8 bytes (64 bits) Cc: big-internet@munnari.OZ.AU Bill, (This could get interesting. Both you and I prefer smaller addresses. Neither you nor I were at Chicago. Nonetheless...) There is a reason we refer to our consensus process as rough. (Yeah, I know, we don't usually say that the PROCESS is rough, only the result. But I like to note that the presence, position and possible ambiguity in use of the term 'rough' is really quite important.) Essentially what you are saying is that primary opponents and proponents haven't changed. That matches my sense, though I appreciate your doing such a thorough check of the archives. But my own view is that a major reason for having the IPng directorate is to have a body that can -- at least to some extent -- serve as a sample of the larger community. Since my background is in psychology, let's bypass questions of sample validity. That, too, will have to suffice as 'rough'. The word from Chicago was that there was a core set of discomforts among a reasonable subset of the group. My own guess is that there's no way to please everybody. Had the word from Chicago been that we needed to try, I'd simply have laughed. But I read the "community" discomfort with 8bytes as quite substantial. It doesn't matter that I think 16 is silly. (My own view is that 12 is plenty but other notes that it's an "odd" length.) Ultimately, no amount of rational argument sways such folks, not because they are right or wrong, but because we are trying to do crystal ball gazing. As I keep harping about the Lifetime Expectancy work, we simply cannot use straightforward analytic techniques for making our estimates -- including our estimates of length sufficiency -- since this is very much an unstable market with unknown growth possibilities. 8 bytes has enough growth padding for some folks. For others, it simply doesn't. Ultimately, we MUST achieve a reasonable degree of community comfort. 16 bytes does that. 8 doesn't. I, for one, feel that this windmill has been tilted at enough, not because a few plaintive voices have been unwilling to get still, but because an undercurrent of discomfort from a broader base of folks seems to require this. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 12:20:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07735; Fri, 15 Jul 1994 11:45:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA06446; Fri, 15 Jul 1994 11:44:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA06430; Fri, 15 Jul 1994 11:31:25 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03784; Fri, 15 Jul 1994 10:02:05 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-26.dialip.mich.net (pm002-26.dialip.mich.net [35.1.48.107]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id UAA00249; Thu, 14 Jul 1994 20:01:11 -0400 Date: Thu, 14 Jul 94 23:44:36 GMT From: "William Allen Simpson" Message-Id: <2832.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Cc: internet-drafts@cnri.reston.va.us Reply-To: bsimpson@morningstar.com Subject: Mobility White Paper Network Working Group W A Simpson Internet Draft Daydreamer expires in six months July 1994 IPng Mobility Considerations draft-simpson-ipng-mobility-00.txt Status of this Memo This document was submitted to the IPng Area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This document specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. Simpson expires in six months [Page i] DRAFT IPng Mobility July 1994 1. Introduction Current versions of the Internet Protocol make an implicit assumption that a node's point of attachment remains fixed. Datagrams are sent to a node based on the location information contained in the node's IP address. If a node moves while keeping its IP address unchanged, its IP network number will not reflect its new point of attachment. The routing protocols will not be able to route datagrams to it correctly. A number of considerations arise for routing these datagrams to a Mobile Node. 2. Addressing Each Mobile Node must have at least one Home-Address which identifies it to other nodes. This Home-Address must be globally unique. 2.1. Ownership The presence of ownership information in the Home-Address would be beneficial. A Mobile Node will be assigned a Home-Address by the organization that owns the machine, and will be able to use that Home-Address regardless of the current point of attachment. The ownership information must be organized in such a fashion to facilitate "inverse" lookup in the Domain Name Service, and other future services. Ownership information could be used by other nodes to ascertain the current topological location of the Mobile Node. Ownership information could also be used for generation of accounting records. 2.2. Topology There is no requirement that the Home-Address contain topological information. Indeed, by the very nature of mobility, any such topological information is irrelevant. Simpson expires in six months [Page 1] DRAFT IPng Mobility July 1994 Topological information in the Home-Address must not hinder mobility, whether by prevention of relocation, or by wasting bandwidth or processing efficiency. 2.3. Manufacturer There is no requirement that the Home-Address contain manufacturer information. Manufacturer information in the Home-Address must not hinder mobility, whether by prevention of relocation, or by wasting bandwidth or processing efficiency. 2.4. Numbering The number of mobile nodes is expected to be constrained by the population of users within the lifetime of the IPng protocol. The maximum world-wide sustainable population is estimated as 16e9, although during the lifetime of IPng the population is not expected to exceed 8e9. Each user is assumed to be mobile, and to have a maximum combined personal mobile and home network(s) on the order of 4e3 nodes. The expectation is that only 46 bits will be needed to densely number all mobile and home nodes. The size of addressing elements is also constrained by bandwidth efficiency and processing efficiency, as described later. 2.5. Configuration Since the typical user would be unlikely to be aware of or willing and able to maintain 4e3 nodes, the assignment of Home-Addresses must be automatically configurable. Registration of the nodes must be dynamic and transparent to the user, both at home and away from home. Simpson expires in six months [Page 2] DRAFT IPng Mobility July 1994 3. Communication A Mobile Node must continue to be capable of communicating directly with other nodes which do not implement mobility functions. No protocol enhancements are required in hosts or routers that are not serving any of the mobility functions. Similarly, no additional protocols are needed by a router (that is not acting as a Home Agent or a Foreign Agent) to route datagrams to or from a Mobile Node. A Mobile Node using its Home-Address must be able to communicate with other nodes after having been disconnected from the Internet, and then reconnected at a different point of attachment. A Mobile Node using its Home-Address must be able to communicate with other nodes while roaming between different points of attachment, without loss of transport connections. 3.1. Topological Changes In order that transport connections be maintained while roaming, topological changes must not affect transport connections. For correspondent nodes which do not implement mobility functions, topological changes should not be communicated to the correspondent. For correspondent nodes which implement mobility functions, the correspondent should be capable of determining topological changes. Topological change information must be capable of insertion and removal by routers in the datagram path, as well as by the correspondent and Mobile Node. 3.2. Routing Updates Mobile Nodes are expected to be able to change their point of attachment no more frequently than once per second. Changes in topology which occur more frequently must be handled at the link layer transparently to the internetwork layer. It is further noted that engineering margins may require the link layer to handle all changes at a frequency in the neighborhood of 10 seconds. Changes in topology which occur less frequently must be immediately Simpson expires in six months [Page 3] DRAFT IPng Mobility July 1994 reflected in the mobility updates. This may preclude the use of the Domain Name Service as the repository of mobility topological information. It must be noted that global routing updates do not operate at this frequency. As old topological information may be obsoleted faster than global routing updates, access to the repository of mobility topological information must be independent of prior topological information. The mobility specific repository should use ownership information in the Home-Address for access to the repository. 3.3. Path Optimization Optimization of the path from a correspondent to a mobile node is not required. However, such optimization is desirable. For correspondent nodes which implement mobility functions, the correspondent should be capable of determining the optimal path. The optimization mechanism is also constrained by security, bandwidth efficiency and processing efficiency, as described later. 3.4. At Home Mobile Nodes do not require special "virtual" home network addresses. The assumption that extra addresses or multiple routers are available is unwarranted in small networks. Mobile Nodes must operate without special assistance from routers in order to communicate directly with other nodes on the home subnetwork link. 3.5. Away From Home When a router is present, and the correspondent does not implement mobility functions, the router must be capable of redirecting the correspondent to communicate directly with the Mobile Node. When no router is present, Mobile Nodes must be capable of communicating directly with other nodes on the same link. Simpson expires in six months [Page 4] DRAFT IPng Mobility July 1994 4. Security Mobility must not create an environment which is less secure than the current Internet. Changes in topology must not affect internode security mechanisms. 4.1. Authentication Mobility registration messages must be authenticated between the home topological repository and Mobile Node. When the correspondent implements mobility functions, redirection or path optimization must be authenticated between the correspondent and Mobile Node. 4.2. Anonymity The capability to attach to a foreign administrative domain without the awareness of the foreign administration is not prohibited. However, any mobility mechanism must provide the ability to prevent such attachment. 4.3. Location Privacy The capability to attach to a foreign administrative domain without the awareness of correspondents is not prohibited. However, any mobility mechanism must provide the ability for the home administration to trace the current path to the point of attachment. 4.4. Content Privacy Security mechanisms which provide content privacy must not obscure or have a dependency on the topological location of Mobile Nodes. Simpson expires in six months [Page 5] DRAFT IPng Mobility July 1994 5. Bandwidth Mobility must operate in the current link environment, and must not be dependent on bandwidth improvements. The Mobile Node's directly attached link is likely to be bandwidth limited. In particular, radio frequency spectrum is already a scarce commodity. Higher bandwidth links are likely to continue to be scarce in the mobile environment. Current applications of mobility using radio links include HF links which are subject to serious fading and noise constraints, VHF and UHF line of sight radio between ships or field sites, and UHF Satellite Communications links. The HF radio bandwidth is fixed at 1200 or 2400 bps by international treaty, statute, and custom, and is not likely to change. The European standard for cellular radio is 2400 bps GSM. The most prevalent deployed analog cellular and land-line modulation used by mobile nodes is 2400 bps. Current digital cellular deployment is 19,200 bps CDPD shared among many users. At early installations, under light loads, effective FTP throughput has been observed as low as 200 bps. Future digital cellular deployment is 9,600 and 14,400 bps CDMA, which is shared between voice and data on a per user basis. Effective FTP throughput has been measured as low as 7,200 bps. Future Personal Communications Services (PCS) will also have relatively little bandwidth. In industrialized nations, the bandwidth available to each user is constrained by the density of deployment, and is commensurate with planned digital cellular deployment. It appears likely that satellite-based PCS will be widely deployed for basic telephony communications in many newly-industrialized and lesser-developed countries. There is already significant PCS interest in East and SouthEast Asia, India, and South America. Van Jacobson header prediction is widely used, and essential to making the use of such links viable. Simpson expires in six months [Page 6] DRAFT IPng Mobility July 1994 5.1. Administrative Messages The number of administrative mobility messages sent or received by the Mobile Node must be limited to as few as possible. In order to meet the frequency requirement of changing point of attachment once per second, registration of changes must not require more than a single request and reply. The size of administrative mobility messages must be kept as short as possible. In order to meet the frequency requirement of changing point of attachment once per second, the registration messages must not total more than 120 bytes for a complete transaction, including link and internet headers. 5.2. Response Time For most mobile links in current use, the typical TCP/IPv4 datagram overhead of 40 bytes is too large to maintain an acceptable typing response of 200 milliseconds round trip time. Therefore, the criteria for IPng mobility is that the response time not be perceptably worse than IPv4. This allows no more than 6 bytes of additional overhead per datagram to be added by IPng. This was a primary concern in the design of mobility forwarding headers. Larger headers were rejected outright, and negotiation is provided for smaller headers than the default method. Topological headers are removed by the Foreign Agent prior to datagram transmission over the slower link to the Mobile Node, which also aids header prediction, as described below. 5.3. Header Prediction Header prediction can be useful in reducing bandwidth usage on multiple related datagrams. It requires a point-to-point peer relationship between nodes, so that a header history can be maintained between the peers. Header prediction is less effective in mobile environments, as the header history is lost each time a Mobile Node changes its point of attachment. The new Foreign Agent will not have the same history as the previous Agent. Simpson expires in six months [Page 7] DRAFT IPng Mobility July 1994 In order for header prediction to operate successfully, changing topological information must be removed from datagram overhead prior to transmission of the datagram on any final hop's directly attached link. This applies to both the Mobile Node peering with a Foreign Agent, and also the final link to a Correspondent. Otherwise, header prediction cannot be relied upon to improve bandwidth utilization on low-speed Mobile and Correspondent links. Since the changing topological information cannot be removed in the forwarding path of the datagram, header prediction will also be affected at any other pair of routers in the datagram path. Each time that a Mobile Node moves, the topological portion of the header will change, and header history used at those routers will be updated. Unless topological information is limited to as few headers as possible, this may render header prediction ineffective as more Mobile Nodes are deployed. 6. Processing Mobility must operate in the current processor environment, and must not be dependent on hardware improvements. Common hardware implementations of Mobile Nodes include lower speed processors, and highly integrated components. These are not readily upgradable. The most prevalent mobile platform is a low speed i86, i286 or i386. The most common ASIC processor is a low speed i186. 6.1. Fixed Location The processing limitations require that datagram header fields which are frequently examined by Mobile Nodes, or used for datagram forwarding to or from Mobile Nodes, are in a fixed location and do not require lengths and offsets. Varied number of fields was explicitly rejected in the design of mobility registration and forwarding headers. Simpson expires in six months [Page 8] DRAFT IPng Mobility July 1994 6.2. Simple Fields The processing limitations require that datagram header fields which are frequently examined by Mobile Nodes, or used for datagram forwarding to or from Mobile Nodes, are simple and fixed size. Varied length of fields was explicitly rejected in the design of mobility forwarding headers. 6.3. Simple Tests Because the most prevalent processors are "little-endian", while network protocols are in practice "big-endian", the field processing must primarily use simple equality tests, rather than variable shifts and prefix matches. 6.4. Type, Length, Value Fields which are not frequently examined, whether due to infrequent transmission or content that is not relevant in every message, must be of the Type, Length, Value format. Acknowledgements This compilation is primarily based on the work in progress of the IETF Mobile IP Working Group. Author's Address Questions about this memo can also be directed to: William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Simpson expires in six months [Page 9] DRAFT IPng Mobility July 1994 Table of Contents 1. Introduction .......................................... 1 2. Addressing ............................................ 1 2.1 Ownership ....................................... 1 2.2 Topology ........................................ 1 2.3 Manufacturer .................................... 2 2.4 Numbering ....................................... 2 2.5 Configuration ................................... 2 3. Communication ......................................... 3 3.1 Topological Changes ............................. 3 3.2 Routing Updates ................................. 3 3.3 Path Optimization ............................... 4 3.4 At Home ......................................... 4 3.5 Away From Home .................................. 4 4. Security .............................................. 5 4.1 Authentication .................................. 5 4.2 Anonymity ....................................... 5 4.3 Location Privacy ................................ 5 4.4 Content Privacy ................................. 5 5. Bandwidth ............................................. 6 5.1 Administrative Messages ......................... 7 5.2 Response Time ................................... 7 5.3 Header Prediction ............................... 7 6. Processing ............................................ 8 6.1 Fixed Location .................................. 8 6.2 Simple Fields ................................... 9 6.3 Simple Tests .................................... 9 6.4 Type, Length, Value ............................. 9 ACKNOWLEDGEMENTS ............................................. 9 AUTHOR'S ADDRESS ............................................. 9 From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 13:25:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11288; Fri, 15 Jul 1994 13:25:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA06546; Fri, 15 Jul 1994 13:24:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA06543; Fri, 15 Jul 1994 13:19:27 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11083; Fri, 15 Jul 1994 13:19:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12779; Thu, 14 Jul 94 23:19:20 -0400 Date: Thu, 14 Jul 94 23:19:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407150319.AA12779@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: re: prove you need EIDs in the header.... Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) my own suggestion is NOT a modification to the IP(ng) layer. ... tries to keep the IP(ng) layer blissfully unaware of mobility ... In my own mind, I do model this as a layer between transport and internet, but really believe that it constitutes a mod to transport rather than a pure, transparent mini-layer. As I recall your scheme, the downsides were that i) any application that wanted to be mobile would have to be redone to use your teardown/setup mechanism, and ii) this worked for TCP, but not for other transport protocols. A single shim on top of the internet layer kills all the birds with one stone. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 13:27:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11383; Fri, 15 Jul 1994 13:27:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA06574; Fri, 15 Jul 1994 13:27:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA06540; Fri, 15 Jul 1994 13:15:30 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10843; Fri, 15 Jul 1994 13:15:23 +1000 (from pvm@ISI.EDU) Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 14 Jul 1994 20:12:29 -0700 Message-Id: <199407150312.AA19203@zephyr.isi.edu> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Reply-To: pvm@isi.edu Subject: Re: Whither 8 bytes (64 bits) In-Reply-To: Your message of Thu, 14 Jul 1994 22:06:07 +0000. <2831.bill.simpson@um.cc.umich.edu> Date: Thu, 14 Jul 94 20:09:01 PDT From: Paul Mockapetris Rather than two factions by length, I belive there are two factions by extensibility. 1) Those who believe that N-bytes are enough but aren't willing to forclose the possibility that more will be needed. 2) Those who believe that a fixed length N-byte address is the most important issue, regardless of N. So while Steve Deering and I are listed in your column as being aligned in belief in 8 bytes, I would feel comfortable about 8 only if it comes with a safety valve so I can go to 16/24/32... IFF I NEED TO. (I should point out to all the variable-challenged folks that you tell me I never will have to exercise this odious device, so why does it scare you? We could prohibit the IANA from allocating longer addresses, if you like.) I prefer an excessive size to a correct size that lacks extensibility. Steve (I assume) prefers an excessive size to a variable one which starts at the correct size. I suppose 16 byte addresses share the pain fairly. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 14:25:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13711; Fri, 15 Jul 1994 14:25:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA06632; Fri, 15 Jul 1994 14:24:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06627; Fri, 15 Jul 1994 14:12:37 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13112; Fri, 15 Jul 1994 14:12:21 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id AAA24110; Fri, 15 Jul 1994 00:12:12 -0400 Date: Fri, 15 Jul 1994 00:12:12 -0400 From: Vadim Antonov Message-Id: <199407150412.AAA24110@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, sob@hsdndev.harvard.edu Subject: Re: summary of Big-Internet messages >Splitting Identifiers from Locators: >Con: Vadim Antonov Beg pardon; my position is that EIDs have no business to appear in data packet headers. Hence, i'm *for* separating EIDs from TLAs but *against* using any form of EID different from the domain names. --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 15:24:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15052; Fri, 15 Jul 1994 15:05:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06695; Fri, 15 Jul 1994 15:04:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06674; Fri, 15 Jul 1994 14:47:58 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14511; Fri, 15 Jul 1994 14:47:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13251; Fri, 15 Jul 94 00:47:22 -0400 Date: Fri, 15 Jul 94 00:47:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407150447.AA13251@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: Whither 8 bytes (64 bits) Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) As I keep harping about the Lifetime Expectancy work, we simply cannot use straightforward analytic techniques for making our estimates -- including our estimates of length sufficiency -- since this is very much an unstable market with unknown growth possibilities. Just out of interest, do you see any ramifications from this for the estimates of how long addresses need to be? Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 15:25:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15071; Fri, 15 Jul 1994 15:06:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06710; Fri, 15 Jul 1994 15:06:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06670; Fri, 15 Jul 1994 14:44:43 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14354; Fri, 15 Jul 1994 14:44:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13196; Fri, 15 Jul 94 00:43:55 -0400 Date: Fri, 15 Jul 94 00:43:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407150443.AA13196@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: summary of Big-Internet messages Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov Beg pardon; my position is that EIDs have no business to appear in data packet headers. Hence, i'm *for* separating EIDs from TLAs but *against* using any form of EID different from the domain names. I'm getting lost in other people's definitions. I assume that by "EID" here, you mean a name for a transport entity? (Strictly speaking, DNS names couldn't be EID's since EID's are defined to be shortish, and fixed length.) If so, then I'm lost as to what a TLA is (since it can't be "transport layer address"). Does it stand for "topological address"? Noel PS: It's clearly a Three Letter Acronym, but I doubt that's what you meant! From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 15:27:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15093; Fri, 15 Jul 1994 15:07:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06728; Fri, 15 Jul 1994 15:07:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06679; Fri, 15 Jul 1994 14:52:44 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14637; Fri, 15 Jul 1994 14:52:39 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id AAA24466; Fri, 15 Jul 1994 00:52:24 -0400 Date: Fri, 15 Jul 1994 00:52:24 -0400 From: Vadim Antonov Message-Id: <199407150452.AAA24466@titan.sprintlink.net> To: avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: summary of Big-Internet messages From jnc@ginger.lcs.mit.edu Fri Jul 15 04:44:05 1994 Received: from tiny.sprintlink.net (tiny.sprintlink.net [199.0.55.90]) by titan.sprintlink.net (8.6.9/8.6.8) with ESMTP id AAA24360 for ; Fri, 15 Jul 1994 00:44:05 -0400 Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id AAA24881 for ; Fri, 15 Jul 1994 00:44:03 -0400 Received: by ginger.lcs.mit.edu id AA13196; Fri, 15 Jul 94 00:43:55 -0400 Date: Fri, 15 Jul 94 00:43:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407150443.AA13196@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.oz.au Subject: Re: summary of Big-Internet messages Cc: jnc@ginger.lcs.mit.edu Status: R From: Vadim Antonov Beg pardon; my position is that EIDs have no business to appear in data packet headers. Hence, i'm *for* separating EIDs from TLAs but *against* using any form of EID different from the domain names. I'm getting lost in other people's definitions. I assume that by "EID" here, you mean a name for a transport entity? (Strictly speaking, DNS names couldn't be EID's since EID's are defined to be shortish, and fixed length.) If so, then I'm lost as to what a TLA is (since it can't be "transport layer address"). Does it stand for "topological address"? Noel PS: It's clearly a Three Letter Acronym, but I doubt that's what you meant! Ok, what i meant by TLA is what you call "locator". --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 15:45:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16565; Fri, 15 Jul 1994 15:45:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06829; Fri, 15 Jul 1994 15:44:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA06824; Fri, 15 Jul 1994 15:40:41 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16345; Fri, 15 Jul 1994 15:40:29 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id BAA24849; Fri, 15 Jul 1994 01:40:20 -0400 Date: Fri, 15 Jul 1994 01:40:20 -0400 From: Vadim Antonov Message-Id: <199407150540.BAA24849@titan.sprintlink.net> To: avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets Noel wrote: >> Can anybody *prove* that EIDs in headers are necessary? >Let me put it to you this way. If a process with a TCP connection open on port >X moves from host A to host B, and a process on B already has a connection >open on X, how do you tell which one TCP packets to port X go to, without >something in the packet to indentify which endpoint (process) the packets are >for? Can you do it efficiently and reasonably without something in the header? It IS trivial. Kill the concept of *well known ports* which is a kludge from the very beginning and start treating distribution of packets between processes as a kind of network -- i.e. include "port numbers" into locators! There should be Well Known Names -- like $FTP.ftp.uu.net $TELNET.telnet.uu.net etc -- and the equivalent of DNS should do *dynamic* mapping between the names and host addresses/ports. I.e. ports become isomorphic to sockets, and no two connections on the same host have identical source or destination port numbers. Then the migration of a process becomes identical to migration of a host! The scheme has an additional advantage of allowing things like $FTP.uu.net CNAME $FTP.ftp.uu.net $TELNET.uu.net CNAME $TELNET.rodan.uu.net So, as you can see your rationale for having EIDs has obvious logical gaps in it. I have reasons to think that other "proven" things about EIDs are as suspicious as this particular one. Any mathematicans/logicists out there? :-) :-) :-) Can anybody find a hole in my reasoning? --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 17:05:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19849; Fri, 15 Jul 1994 17:05:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA06953; Fri, 15 Jul 1994 17:04:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA06937; Fri, 15 Jul 1994 16:46:40 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19112; Fri, 15 Jul 1994 16:46:07 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Jul 94 15:37:22 +0900 From: Masataka Ohta Message-Id: <9407150637.AA21840@necom830.cc.titech.ac.jp> Subject: Re: summary of Big-Internet messages To: avg@sprint.net (Vadim Antonov) Date: Fri, 15 Jul 94 15:37:21 JST Cc: avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <199407150602.CAA24969@titan.sprintlink.net>; from "Vadim Antonov" at Jul 15, 94 2:02 am X-Mailer: ELM [version 2.3 PL11] > >As the pair: (EID, flow ID) is a handy thing to identify a flow, I > >think we need fixed length EID. > > This statement is emotional. No. > "Handy" is not "necessary". No, of course. As I stated earlier, (DNS hostname, flow ID) is OK, if variable length address is OK. Thus, I said "Handy". Though I don't want to get evolved in variable vs. fixed debate, everyone knows fixed length is handy. > >It should be noted that looking up domain name from "locator" just does > >not work, as DNS update, even the most dynamic one, can not be assured to > >be so fast. > > This statement is also purely emotional. No. > Why do you think that > updating DNS cannot be made as fast as propagation of route? First of all, I wrote "can not be assured to be so fast". OK? Because packets, which propagates the change, may be lost. Unlike routing propagation, there is no reason to notify DNS change forever. DNS is designed to run for period, even if change is not propagated. Even if DNS change packets are not lost, updating DNS cannot be made simultaneously with propagation of route. There is some jitter. In short, your plan lacks consideration of engneering details to be a technical proposal. > Also, ever heard of host routes? No, but it may be similar to what people in mobile WG is doing, which has nothing to do with DNS. > We used that neat trick to > sustain continuous operation of a very important migrated host > (the largest 822<->X.400 gateway) until the change got propagated > in the (old, timeout-based) DNS. You didn't need any trick, neither neat nor dirty, though "neat" is purely emotional word. You should have run both gateways during the transition, which is what I'm doing once for every year or two. The size of the server does not matter. So, you should have solved a simple problem in a very complex way. > I definitely won't support any proposal based on emotions and > old prejudices instead of logics. Fine to hear you don't support yourself. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 17:10:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15738; Fri, 15 Jul 1994 15:25:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06760; Fri, 15 Jul 1994 15:24:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA06721; Fri, 15 Jul 1994 15:07:01 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13003; Fri, 15 Jul 1994 14:06:41 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id AAA04876; Fri, 15 Jul 1994 00:06:28 -0400 From: Howard Berkowitz Message-Id: <199407150406.AAA04876@clark.net> Subject: Re: prove you need EIDs in the header.... To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 15 Jul 1994 00:06:28 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu In-Reply-To: <9407150319.AA12779@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 14, 94 11:19:20 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 181 > > A single shim on top of the internet layer kills all the birds with one stone. > > Noel > > So let him that is without shim cast the first stone? Sorry, couldn't resist. From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 17:19:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15773; Fri, 15 Jul 1994 15:26:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06793; Fri, 15 Jul 1994 15:26:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA06757; Fri, 15 Jul 1994 15:15:43 +1000 Precedence: list Received: from olivea.atc.olivetti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13494; Fri, 15 Jul 1994 14:19:36 +1000 (from jerry@strobe.ATC.Olivetti.Com) Received: by olivea.ATC.Olivetti.Com (5.65/1.34) id AA17901; Thu, 14 Jul 94 21:18:56 -0700 Received: from strobe.ATC.Olivetti.Com by olivea.ATC.Olivetti.Com (4.1/SMI-4.1) id AA17898; Thu, 14 Jul 94 21:18:54 PDT Received: by strobe.ATC.Olivetti.Com (4.1/SMI-4.1) id AA27773; Thu, 14 Jul 94 21:18:53 PDT Date: Thu, 14 Jul 94 21:18:53 PDT From: jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) Message-Id: <9407150418.AA27773@strobe.ATC.Olivetti.Com> To: bsimpson@morningstar.com, pvm@isi.edu Subject: Re: Whither 8 bytes (64 bits) Cc: big-internet@munnari.OZ.AU Quoting: Paul Mockapetris >So while Steve Deering and I are listed in your column as being >aligned in belief in 8 bytes, I would feel comfortable about 8 only if >it comes with a safety valve so I can go to 16/24/32... IFF I NEED TO. >(I should point out to all the variable-challenged folks that you tell >me I never will have to exercise this odious device, so why does it >scare you? We could prohibit the IANA from allocating longer >addresses, if you like.) If multiple sizes are options then I suggest that rather than never be exercised that they should be forced to be used. Just allocate a few of the root DNS servers, or other common resources, from each of the different sizes. So the first time someone's code goes on the internet it will have to handle them. Better that the code should be exercised early in the product cycle than +10 years down the line when no one is around to support it. "Bug report #1297 - Zolaris 7.1u panics when accessing NS.NIC.DDN.MIL. Error code 0x99f2: "Silly length address, add code for this later" From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 17:25:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20457; Fri, 15 Jul 1994 17:25:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA06993; Fri, 15 Jul 1994 17:24:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA06983; Fri, 15 Jul 1994 17:10:12 +1000 Precedence: list Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20014; Fri, 15 Jul 1994 17:10:06 +1000 (from news@vix.com) Received: by gw.home.vix.com id AA12254; Fri, 15 Jul 94 00:09:58 -0700 Date: Fri, 15 Jul 94 00:09:58 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: big-Internet@munnari.OZ.AU From: paul@vix.com (Paul A Vixie) Subject: Re: EID's in the packets Organization: Vixie Enterprises Message-Id: References: <199407150540.BAA24849@titan.sprintlink.net> Nntp-Posting-Host: office.home.vix.com In-Reply-To: avg@sprint.net's message of 14 Jul 1994 23:38:21 -0700 Killing off well known ports is a good idea, but it has nothing to do with IP. Let's finish extending IP first and then deal with the higher level issues. If we are going to start this debate over again assuming that the process/stream/ connection identifier has to be part of the IPng packet level addresses, a lot of good people are going to be found face down on their mouse pads. -- Paul Vixie Redwood City, CA decwrl!vixie!paul From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 17:26:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20485; Fri, 15 Jul 1994 17:26:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA07024; Fri, 15 Jul 1994 17:26:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA06986; Fri, 15 Jul 1994 17:17:57 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20184; Fri, 15 Jul 1994 17:17:50 +1000 (from barney@databus.databus.com) Date: Fri, 15 Jul 94 03:19 EDT Message-Id: <9407150320.AA14276@databus.databus.com> From: Barney Wolff To: jnc@thyme.LCS.MIT.EDU (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too Content-Length: 1225 Content-Type: text > Date: Fri, 15 Jul 94 00:27:05 EDT > From: jnc@thyme.LCS.MIT.EDU (Noel Chiappa) > > - It's much more complicated; you have to have the ESEL table, and all the > hair to assign ESEL's, find out what some endpoint's ESEL is, deal with > collisions when you move, etc, etc. If we combined it with the transport-level port #, the result would be an OSI-style srcref/dstref field, which I always rather liked just because it made it so easy to find the connection control block. > I'm sure there are ones I have missed; please send them to me. The latter > is the one that bothers me the most; it is more complex. On the other hand, > it avoids building an EID allocation hierarchy, which may make it worth it. Datagram-type conversations, which are more than 1 packet each way but have no formal connection setup or teardown, beg the question of how long I can trust the ESEL I was told, and how either end detects ESEL re-use when the interval between packets is long. Do we simply say that's some other layer's problem? Or just time out ESELs like ARP cache entries? If the EID wasn't going in every packet anyway, there does seem little reason to compress the DNS name into it. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 17:27:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20516; Fri, 15 Jul 1994 17:27:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA07041; Fri, 15 Jul 1994 17:27:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA06958; Fri, 15 Jul 1994 17:05:22 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15191; Fri, 15 Jul 1994 15:09:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13412; Fri, 15 Jul 94 01:09:11 -0400 Date: Fri, 15 Jul 94 01:09:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407150509.AA13412@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov For the time being nobody explained why it is necessary to have EIDs in the packet headers Nonsense. I've explained this several times. You may not agree with my rationale (and if not, I'd love to hear why not), but one has been given. To say it again briefly, if you have more than one endpoint at a given interface/host, you need something in the incoming packets to tell you which endpoint (and thus, which TCP, say) the packets belong to. It doesn't have to be an EID; it could be an endpoint selector (which I finally got around to describing), or something else. But, I think there does have to be some indication in the packet. Having multiple endpoints at a single interface/host is not unreasonable; mobile processes are but one example. (Someone suggested that we compute the checksum for all possible endpoints and see which matched; this is theoretically possible, but doesn't seem practical. There are other arcane problems I won't bore you all with as well, having to do with protocol multiplexing, and varying transport checksums.) Can anybody *prove* that EIDs in headers are necessary? Gads, I don't know what constitutes a proof to this crowd! :-) Let me put it to you this way. If a process with a TCP connection open on port X moves from host A to host B, and a process on B already has a connection open on X, how do you tell which one TCP packets to port X go to, without something in the packet to indentify which endpoint (process) the packets are for? Can you do it efficiently and reasonably without something in the header? i definitely would prefer the project which assumes the least amount of required manual configuration. This certainly is an excellent, nay critical, goal. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 17:32:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17456; Fri, 15 Jul 1994 16:05:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA06884; Fri, 15 Jul 1994 16:05:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA06866; Fri, 15 Jul 1994 15:51:13 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16729; Fri, 15 Jul 1994 15:50:57 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Jul 94 14:41:55 +0859 From: Masataka Ohta Message-Id: <9407150542.AA21542@necom830.cc.titech.ac.jp> Subject: Re: summary of Big-Internet messages To: avg@sprint.net (Vadim Antonov) Date: Fri, 15 Jul 94 14:41:53 JST Cc: avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <199407150452.AAA24466@titan.sprintlink.net>; from "Vadim Antonov" at Jul 15, 94 12:52 am X-Mailer: ELM [version 2.3 PL11] > Beg pardon; my position is that EIDs have no business to appear in data > packet headers. Hence, i'm *for* separating EIDs from TLAs but *against* > using any form of EID different from the domain names. > Ok, what i meant by TLA is what you call "locator". So, you think, EID, part of address, should be of variable length. As the pair: (EID, flow ID) is a handy thing to identify a flow, I think we need fixed length EID. Masataka Ohta PS It should be noted that looking up domain name from "locator" just does not work, as DNS update, even the most dynamic one, can not be assured to be so fast. From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 17:42:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16615; Fri, 15 Jul 1994 15:46:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06850; Fri, 15 Jul 1994 15:46:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA06782; Fri, 15 Jul 1994 15:25:39 +1000 Precedence: list Received: from thyme.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13811; Fri, 15 Jul 1994 14:26:53 +1000 (from jnc@thyme.LCS.MIT.EDU) Received: by thyme.LCS.MIT.EDU id AA24471; Fri, 15 Jul 94 00:27:05 EDT Date: Fri, 15 Jul 94 00:27:05 EDT From: jnc@thyme.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9407150427.AA24471@thyme.LCS.MIT.EDU> To: big-internet@munnari.OZ.AU Subject: Endpoint Selectors, or, Having Your Cake and Eating it Too Cc: jnc@thyme.LCS.MIT.EDU As I mentioned, I was thinking about Dave Crocker's message of some weeks back proposed we use DNS names to identify transport entities (which I'll refer to for brevity as endpoints). This idea, in the form that he put it, had issues which I saw as making it unacceptable. However, while musing about it, I had an idea for a thing that sort of allows us to have some cake and eat it too. It's probably a waste of time sending this in, but here goes anyway. I'd always had a sneaking sympathy with the concept of using DNS names to name endpoints, since it would would avoid the necessity to create a separate allocation hierarchy (e.g. for EID's). Rather, it would use one we've already got, one that also has most of the right *allocation* characteristics. The bug, of course, is that the representation was not good for extensive low-level use. (Remember, one of the characteristics of EID's, as endpoint names, was that they were shortish, and fixed length; DNS names are neither!) Dave's idea was to pass the DNS endpoint name once, at connection startup. My problem with this is that it didn't allow suceeding incoming packets to be disambiguated, in the case where there was more than one endpoint on a given machine. You need something in each packet you can look at when you get it, to tell you which endpoint (and thus, which TCP) it belongs to. The DNS name obviously is not the best thing to include for this purpose (although EID's would fit the bill just fine.) At that point, my mind made the semi-obvious leap. Suppose that packets do contain something to indicate which endpoint the packet is for, but this indication is a small number; the "endpoint selector" (ESEL). The ESEL is *not* a globally unique name for the endpoint (as the EID is). Instead, it's a locally unique name for the endpoint, unique only within that machine. It's thus effectively an index into a small table, which translates from the ESEL to i) the true full endpoint name, which *is* a DNS name, and ii) an indication of which endpoint on the machine the ESEL names (e.g. a process identification if you have mobile processes). Now, clearly you need some way to get assign ESEL's, get them back and forth, etc, but this is all pretty obvious. You could store ESEL's in the DNS, for endpoints which aren't changing the ESEL value often; this avoids any extra packets. For ones which are chaning ESEL value, which are, you could send an ICMP message to the destination, with the full endpoint DNS name, and get back the ESEL. Etc, etc. There's also the issue of how you create DNS endpoint names for things like mobile processes. I suppose you could prepend unique numbers to the creating host's DNS name, or something, but then you've always got the problem of how to translate from that name to things like addresses/whatever, in the case where the process has moved on. There are other obscure issues (e.g. a mobile process may have to change ESEL's if there's a collision at the destination of a move), but I'm too tired to type them all in. Anyway, this ESEL idea has a certain charm; it does have some good points. As far as my tired brain can reconstruct the analysis I did of this, the pros are: - It minimizes the size of the packets; ESEL's could be quite short, probably 16 bits; it's hard to imagine having more than 2^16 endpoints in a single machine. You could make them 32 bits, which has got to be more than enough for all time, and still be saving bits. - Use of the DNS pretty much gets rids of the ensuring uniqueness problem. If your host isn't in the one in the DNS entry, you just don't exist, basically. - It allows us to reuse the existing DNS hierarchy, and not have to create a whole new allocation hierarchy (e.g. for EID's). This is a *really* big win. - Use of DNS names means that we're *never* going to run out of endpoint names, since DNS names are variable length. The cons are: - The packets don't contain a globally unique endpoint name. I'm not sure how critical this is. - It makes autoconfig harder, since you don't have an endpoint name until you're in the DNS. - It's much more complicated; you have to have the ESEL table, and all the hair to assign ESEL's, find out what some endpoint's ESEL is, deal with collisions when you move, etc, etc. I'm sure there are ones I have missed; please send them to me. The latter is the one that bothers me the most; it is more complex. On the other hand, it avoids building an EID allocation hierarchy, which may make it worth it. I can't decide whether I think ESEL's are better than EID's or not. There are strong points both ways. Anyway, there they are. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 18:25:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22624; Fri, 15 Jul 1994 18:25:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA07146; Fri, 15 Jul 1994 18:24:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA07130; Fri, 15 Jul 1994 18:09:14 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19723; Fri, 15 Jul 1994 16:59:39 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Jul 94 15:47:44 +0900 From: Masataka Ohta Message-Id: <9407150647.AA21907@necom830.cc.titech.ac.jp> Subject: Re: EID's in the packets To: avg@sprint.net (Vadim Antonov) Date: Fri, 15 Jul 94 15:47:42 JST Cc: avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <199407150540.BAA24849@titan.sprintlink.net>; from "Vadim Antonov" at Jul 15, 94 1:40 am X-Mailer: ELM [version 2.3 PL11] > It IS trivial. Sure. > Kill the concept of *well known ports* which is a kludge > from the very beginning and start treating distribution of packets > between processes as a kind of network -- i.e. include "port numbers" > into locators! That's just a waste of resource. As a port moves with a host, hostwise locator is enough. There should be Well Known Names -- like > Then the migration of a process becomes > identical to migration of a host! The difficulty of process migration is in consistent maintenance of states, which can not be solved by your trivial proposal. > Any mathematicans/logicists out there? :-) :-) :-) Therea are a lot. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 18:26:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21122; Fri, 15 Jul 1994 17:45:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA07079; Fri, 15 Jul 1994 17:44:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA07057; Fri, 15 Jul 1994 17:32:16 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18223; Fri, 15 Jul 1994 16:26:27 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA21001; Fri, 15 Jul 1994 08:26:35 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA18884; Fri, 15 Jul 1994 08:26:15 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407150626.AA18884@dxcoms.cern.ch> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: big-internet@munnari.OZ.AU (bigi) Date: Fri, 15 Jul 1994 08:26:14 +0200 (MET DST) In-Reply-To: <9407141607.AA14846@munin.fnal.gov> from "Matt Crawford" at Jul 14, 94 11:07:18 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 572 No, he used log base 10 ('cos it's easier) >--------- Text sent by Matt Crawford follows: > > I think you are asking whether 8 bytes is enough to route to > a subnet. If we take the design goal as 10**12 networks, the > Huitema ratio is 12/64 = 0.19 so the answer is yes. > > Whoa there. I understood the log in the formula to be a log to base 2. > That makes the ratio about 40/64=0.62. Is the answer still yes, or a > little more hazy? > _________________________________________________________ > Matt Crawford crawdad@fnal.gov Fermilab > From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 18:27:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21134; Fri, 15 Jul 1994 17:46:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA07094; Fri, 15 Jul 1994 17:45:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA07009; Fri, 15 Jul 1994 17:25:07 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17282; Fri, 15 Jul 1994 16:03:19 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id CAA24969; Fri, 15 Jul 1994 02:02:55 -0400 Date: Fri, 15 Jul 1994 02:02:55 -0400 From: Vadim Antonov Message-Id: <199407150602.CAA24969@titan.sprintlink.net> To: avg@sprint.net, mohta@necom830.cc.titech.ac.jp Subject: Re: summary of Big-Internet messages Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu >So, you think, EID, part of address, should be of variable length. Not. Let's not use the dreaded word "address". EID is ENTITY identifier and as such remains unchanged during the lifetime of the entity. Locator is something used to route the packet from source to destination and can change when the entity migrates or for other reasons (not excluding changes in overall topology of the network or routing policy). >As the pair: (EID, flow ID) is a handy thing to identify a flow, I >think we need fixed length EID. This statement is emotional. "Handy" is not "necessary". I don't think it's handy *for me*. >It should be noted that looking up domain name from "locator" just does >not work, as DNS update, even the most dynamic one, can not be assured to >be so fast. This statement is also purely emotional. Why do you think that updating DNS cannot be made as fast as propagation of route? Also, ever heard of host routes? We used that neat trick to sustain continuous operation of a very important migrated host (the largest 822<->X.400 gateway) until the change got propagated in the (old, timeout-based) DNS. I definitely won't support any proposal based on emotions and old prejudices instead of logics. --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 21:45:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28912; Fri, 15 Jul 1994 21:45:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA07468; Fri, 15 Jul 1994 21:45:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA07452; Fri, 15 Jul 1994 21:32:39 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27738; Fri, 15 Jul 1994 21:06:22 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA01275; Fri, 15 Jul 94 06:06:23 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad14969; 15 Jul 94 11:01 GMT Date: Fri, 15 Jul 94 06:02 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: How many bits are enough? Message-Id: <55940715110255/0003858921NA2EM@mcimail.com> Noel Chiappa said: >You can argue that we are getting these layers in a fixed size address now, >but the inevitability is that more layers in a fixed size means less bits >for each layer, and that's a dead-end street. Ah, but if we support unmanaged levels, ie you choose your own poison, you might go with a deep skinny tree and thus use 5 bits per level (32 nodes per level) or 6 levels in 8 bytes. Someone else could go with a fatter tree of 6 bits (64 nodes) or 5 levels. And someone else might have very skinny top, a fat middle and then a skinny bottom (4 bits first few levels, 7 bits in the middle, and then 4 again at the bottom). That is what we have to allow for in this locator stuff. Not some fix idea of what everyone can live with. Bob From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 22:25:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29977; Fri, 15 Jul 1994 22:25:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA07512; Fri, 15 Jul 1994 22:25:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07496; Fri, 15 Jul 1994 22:08:01 +1000 Precedence: list Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29439; Fri, 15 Jul 1994 22:08:00 +1000 (from smart@mel.dit.csiro.au) Received: from koel.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA03916 (5.65c/IDA-1.4.4/DIT-1.3 for big-internet@munnari.oz.au); Fri, 15 Jul 1994 22:07:58 +1000 Message-Id: <199407151207.AA03916@shark.mel.dit.csiro.au> To: big-internet@munnari.OZ.AU Cc: smart@mel.dit.csiro.au Subject: baby omnibus Date: Fri, 15 Jul 1994 22:07:57 +1000 From: Bob Smart Some of the good ideas from the IPng process: From SIP and IPAE: encapsulation for fast option processing. From AEIOU: address extension on the right not the left. From Christian Huitema: A distinct security layer between the network layer and the transport layer. I was amazed that this got mentioned and forgotten. There has been a lot of talk about security implications of the way the network layer conveys information about the other end to the transport layer. Sometimes it doesn't matter and sometimes we need cryptographic security. A layer in there seemed like the right way to protect the network and transport layers from having to deal with this area which doesn't logically belong to either. From various places including PIP: separate transport end-point identifier from network locators. And now that I realize that transport end-point identification belongs in the security layer everything "feels" neater. I don't mean that transport identification is necessarily in the security layer part of the packet: the simplest security layer type will deduce the transport identification from the network address as we do now. From owner-Big-Internet@munnari.OZ.AU Fri Jul 15 22:55:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00784; Fri, 15 Jul 1994 22:45:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA07555; Fri, 15 Jul 1994 22:45:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07539; Fri, 15 Jul 1994 22:33:41 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00357; Fri, 15 Jul 1994 22:33:37 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA03752; Fri, 15 Jul 94 07:34:59 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id as20505; 15 Jul 94 12:30 GMT Date: Fri, 15 Jul 94 07:30 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Scott Bradner To: big internet Subject: Re: summary of Big-Internet messages Message-Id: <12940715123021/0003858921NA1EM@mcimail.com> >Tired of talking about it, and will settle on 16 bytes if that will stop >the variable folks: >Pro: > "Daniel L. McDonald" > kck@netcom.com (Richard Fox) > Bob.Hinden@eng.sun.com (Bob Hinden) > Steve Deering Count me in this group. If we have math that shows that 8 is enough, but we have strong arguments for more, then lets get on with 16 and do a couple of smart things like the locator+EID concept. Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 00:01:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01321; Fri, 15 Jul 1994 23:05:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07593; Fri, 15 Jul 1994 23:05:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07588; Fri, 15 Jul 1994 23:02:55 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01178; Fri, 15 Jul 1994 23:02:51 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA04781; Fri, 15 Jul 94 08:04:36 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ae22546; 15 Jul 94 12:59 GMT Date: Fri, 15 Jul 94 08:01 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: I did it, I caught up! Message-Id: <72940715130127/0003858921NA3EM@mcimail.com> I spent 2.5 hours today to finally get caught up with BIG-I. Maybe now I can stay even. Of course all of my other mail amounts to over 1100 unread messages..... Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 00:10:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01347; Fri, 15 Jul 1994 23:06:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07610; Fri, 15 Jul 1994 23:06:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07582; Fri, 15 Jul 1994 22:55:08 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29163; Fri, 15 Jul 1994 21:56:16 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA02711; Fri, 15 Jul 94 06:58:06 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ai18193; 15 Jul 94 11:53 GMT Date: Fri, 15 Jul 94 06:53 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Why EIDs should be in headers. Message-Id: <43940715115334/0003858921NA1EM@mcimail.com> Vadim Antonov said: >For the time being nobody explained why it is necessary to have >EIDs in the packet headers and *why* EIDs cannot be identical with >domain names. >Can anybody *prove* that EIDs in headers are necessary? Before that >it is nothing more than yet another "feature" designed to complicate >the life of network administrators. >Being an administrator of a large network myself i definitely would >prefer the project which assumes the least amount of required manual >configuration. I am one of the support people of a large, rapidly growing network (3k nodes in 7-93, 10k nodes in 7-94, similar planned growth next year). One of our on-going challenges is to GUESS the number of devices in a subnet to set the mask. And we can and do throw router hardware at the problem! I want a routing mechanism that does not pre-determine the segment setup. With global 'EIDs' coupled with 'locators' I get that. Greater minds than me could show how flow IDs would replace locator+EID in most packets, but it seems like there are strong arguments against this; I am open. Autoconfig proponents can argue that the 'mask' can be changed at will. I respond that this would have to be dynamic while the device is running as I have 7x24 systems up on lots of segments. Taking some of these down takes a VP signed authorization! (Or a software bug :) Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 00:10:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01352; Fri, 15 Jul 1994 23:07:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07625; Fri, 15 Jul 1994 23:07:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07585; Fri, 15 Jul 1994 22:55:49 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00867; Fri, 15 Jul 1994 22:50:37 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA04342; Fri, 15 Jul 94 07:52:26 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ag21730; 15 Jul 94 12:47 GMT Date: Fri, 15 Jul 94 07:47 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Vadim Antonov To: big internet Subject: Re: EID's in the packets Message-Id: <75940715124757/0003858921NA4EM@mcimail.com> >It IS trivial. Kill the concept of *well known ports* which is a kludge >from the very beginning and start treating distribution of packets >between processes as a kind of network -- i.e. include "port numbers" >into locators! There should be Well Known Names -- like > $FTP.ftp.uu.net > $TELNET.telnet.uu.net >etc -- and the equivalent of DNS should do *dynamic* mapping between >the names and host addresses/ports. I.e. ports become isomorphic to >sockets, and no two connections on the same host have identical source >or destination port numbers. Then the migration of a process becomes >identical to migration of a host! >The scheme has an additional advantage of allowing things like > $FTP.uu.net CNAME $FTP.ftp.uu.net > $TELNET.uu.net CNAME $TELNET.rodan.uu.net >So, as you can see your rationale for having EIDs has obvious logical gaps in it. I have reasons to think that other "proven" >things about EIDs are as suspicious as this particular one. Ah, to be able to do BOTH internet and transport again at one time .... I want this SO BAD! This is what mobility of a process is all about. "The process you want is on one or more of the following addresses:" So instead we assign EIDs not only to systems but to processes to kudge around this. A process should not have an EID, I think. But as you say the process ID as a part of some address structure. Oh, and BTW, to me $TELNET is not enough. I need $ACE.TELNET, where ACE is the actual application.... Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 00:29:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03703; Sat, 16 Jul 1994 00:05:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA07708; Sat, 16 Jul 1994 00:05:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA07703; Sat, 16 Jul 1994 00:00:32 +1000 Precedence: list Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01095; Fri, 15 Jul 1994 22:56:36 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA02330; Fri, 15 Jul 94 08:01:46 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA29927; Fri, 15 Jul 94 07:56:27 CDT Date: Fri, 15 Jul 94 07:56:27 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9407151256.AA29927@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too One point I'd like to make here is that DNS names are not necessarily public, at this point. Some folks feel that making them public amounts to publishing details of your internal topology, and have no interest in doing so. I think it's a perfectly reasonable position, and it's not obvious to me that it will be unreasonable in future. Now, some people have their servers hacked up so that doing a reverse lookup on 1.2.3.4 returns 1_2_3_4.foo.com, which (from a 'let's use DNS names as EIDs' viewpoint) looks a lot like assigning EIDs internally and using them as the externally viewable DNS name. This seems viable, I suppose. If it is to be decreed that DNS names shall serve for EIDs, some support for doing internal EIDClassic numbering plans, and exporting those to an externaly visible DNS, should be provided. On the other hand, if quite a few networks are going to be doing internal EIDClassic schemes, maybe the DNS-name-as-EID scheme isn't quite as neat. Andrew From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 01:04:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04286; Sat, 16 Jul 1994 00:25:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA07933; Sat, 16 Jul 1994 00:25:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA07724; Sat, 16 Jul 1994 00:07:28 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03735; Sat, 16 Jul 1994 00:07:25 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwyqy04770; Fri, 15 Jul 1994 10:07:18 -0400 Message-Id: To: Vadim Antonov Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets In-Reply-To: Your message of "Fri, 15 Jul 1994 01:40:20 EDT." <199407150540.BAA24849@titan.sprintlink.net> Date: Fri, 15 Jul 1994 10:07:17 -0400 From: "Mike O'Dell" Vadim, the problem isn't in your reasoning - the problem is that the proposal is out of scope. the charter is NOT to re-engineer the entire protocol stack, which is what you are proposing. I think what you propose has merit, and is a fine thing to experiment with, but wholesale changes to the transport protocols is simply not in the feasible region. (at least the way I read the charter) -mo From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 01:07:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04832; Sat, 16 Jul 1994 00:45:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA07976; Sat, 16 Jul 1994 00:45:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA07960; Sat, 16 Jul 1994 00:27:14 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04310; Sat, 16 Jul 1994 00:27:05 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id KAA28286; Fri, 15 Jul 1994 10:26:50 -0400 From: Howard Berkowitz Message-Id: <199407151426.KAA28286@clark.net> Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too To: amolitor@anubis.network.com (Andrew Molitor) Date: Fri, 15 Jul 1994 10:26:49 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407151256.AA29927@anubis.network.com> from "Andrew Molitor" at Jul 15, 94 07:56:27 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1377 aAndrew Molitor wrote, > > One point I'd like to make here is that DNS names are not necessarily > public, at this point. Some folks feel that making them public amounts to > publishing details of your internal topology, and have no interest in doing > so. I think it's a perfectly reasonable position, and it's not obvious to me > that it will be unreasonable in future. > > Now, some people have their servers hacked up so that doing a reverse > lookup on 1.2.3.4 returns 1_2_3_4.foo.com, which (from a 'let's use DNS names > as EIDs' viewpoint) looks a lot like assigning EIDs internally and using them > as the externally viewable DNS name. > > This seems viable, I suppose. If it is to be decreed that DNS names > shall serve for EIDs, some support for doing internal EIDClassic numbering > plans, and exporting those to an externaly visible DNS, should be provided. > On the other hand, if quite a few networks are going to be doing internal > EIDClassic schemes, maybe the DNS-name-as-EID scheme isn't quite as neat. I just posted a note about EID compression and address size requirements, which, by Murphy's Law of Propagation, will probably reach everyone after this message. Would it suffice to meet these requirements to do a public key encryption on the DNS and use the encrypted DNS (or compressed DNS, as I discuss in my other note) as the EID? Howard From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 01:25:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06172; Sat, 16 Jul 1994 01:25:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA08032; Sat, 16 Jul 1994 01:25:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08026; Sat, 16 Jul 1994 01:17:02 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05924; Sat, 16 Jul 1994 01:16:50 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: big-internet@munnari.OZ.AU In-Reply-To: Noel Chiappa's message of Fri, 15 Jul 94 00:27:05 EDT <9407150427.AA24471@thyme.LCS.MIT.EDU> Subject: Endpoint Selectors, or, Having Your Cake and Eating it Too Date: Fri, 15 Jul 94 11:15:37 -0400 Message-Id: <9407151115.aa13592@quern.epilogue.com> Date: Fri, 15 Jul 94 00:27:05 EDT From: Noel Chiappa The cons are: - The packets don't contain a globally unique endpoint name. I'm not sure how critical this is. If there's not a globally unique endpoint name in the packet what are you using for the selector? Dave From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 01:27:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06249; Sat, 16 Jul 1994 01:27:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA08059; Sat, 16 Jul 1994 01:27:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08023; Sat, 16 Jul 1994 01:15:47 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05861; Sat, 16 Jul 1994 01:15:26 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: dcrocker@mordor.stanford.edu Cc: big-internet@munnari.OZ.AU In-Reply-To: Dave Crocker's message of Thu, 14 Jul 1994 17:17:25 -0700 Subject: Whither 8 bytes (64 bits) Date: Fri, 15 Jul 94 11:14:31 -0400 Message-Id: <9407151114.aa13589@quern.epilogue.com> Date: Thu, 14 Jul 1994 17:17:25 -0700 From: Dave Crocker But I read the "community" discomfort with 8bytes as quite substantial. It doesn't matter that I think 16 is silly. (My own view is that 12 is plenty but other notes that it's an "odd" length.) Actually I like this. I had some discomfort with 8 bytes (not that it's really too small, just that I don't trust how dense our allocation can be) and 16 does seem excessive. 12 bytes of EID and a 4 byte Flow-ID gives a 16 byte selector and the selector is really what I want to be an "even" length anyway. So for Bill Simpson's list, that's what I vote for. And variable length locators that don't go in every packet of course. But the original question from the IPng Area Directors was about addresses, not EIDs. That's a much harder question since I don't think addresses work very well. Especially when the Internet grows to be a large net. Dave From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 01:28:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06339; Sat, 16 Jul 1994 01:28:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA08076; Sat, 16 Jul 1994 01:27:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08006; Sat, 16 Jul 1994 01:05:06 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04182; Sat, 16 Jul 1994 00:23:35 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id KAA27841; Fri, 15 Jul 1994 10:23:22 -0400 From: Howard Berkowitz Message-Id: <199407151423.KAA27841@clark.net> Subject: Re: EID's in the packets To: 0003858921@mcimail.com (Robert G. Moskowitz) Date: Fri, 15 Jul 1994 10:23:21 -0400 (EDT) Cc: avg@sprint.net, big-internet@munnari.OZ.AU In-Reply-To: <75940715124757/0003858921NA4EM@mcimail.com> from "Robert G. Moskowitz" at Jul 15, 94 07:47:00 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2021 It occurred that an interesting experiment might be to see how many bits (ducking) are needed to contain a compressed domain name. That I am interested in compression here might surprise some people that are including me firmly in the extensible 16 octet camp; I am less in one of the specific camps that looks at "how many bits are enough for routing" as a traveling minstrel traveling among the camps, singing the song that asks how is the farmer going to encode all this once the IPng is back on the farm. [I offer this one to the mixed metaphor of the week contest]. I have a special interest in character compression at the moment, because the 'e' key on my keyboard seems to be dying. I am not trying to design the representation here, but merely to make some observations that illustrate another point. That point is the sort of thing I can live with in an address: if it's not a nibble-aligned field with a value that is meanningful to an unsophisticated end user, then the value MUST be computed by an algorithm required to be implemented as part of the human interface of a configurable IPng host. Domain names can be up to 63 characters long, containing letters, numbers, periods, and hyphens (i.e., 38 symbols, so that they can be encoded in 6 bits each, not considering Huffman coding or other compression schemes). A maximum length name trivially compresses, using 6 bit symbols, into 48 bytes. Not being a coding expert, I suspect we can do better than 6 bits per symbol; I understand Huffman but get hazy on the more complex algorithms. I would suspect that one saving would be to allocate a byte that has a bit string or binary value that says how many levels are in the string. Assuming that the average domain name has four levels and thus three periods, we drop the length to 60 characters or so. If we worked with a more realistic maximum length (e.g., 32 or 48 octets in a name), used better compression, etc., we could probably get DNS-derived EIDs to a reasonable length. Howard From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 02:45:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08987; Sat, 16 Jul 1994 02:45:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08291; Sat, 16 Jul 1994 02:45:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08286; Sat, 16 Jul 1994 02:40:16 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08820; Sat, 16 Jul 1994 02:40:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17012; Fri, 15 Jul 94 12:40:07 -0400 Date: Fri, 15 Jul 94 12:40:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407151640.AA17012@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dab@epilogue.com Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too Cc: jnc@ginger.lcs.mit.edu From: Dave Bridgham - The packets don't contain a globally unique endpoint name. I'm not sure how critical this is. If there's not a globally unique endpoint name in the packet what are you using for the selector? (I should warn people that DAB and I are using JNC-speak, in which "selector" is the name for the field(s) in the packet which the router(s) look at to forward the packets. :-) Two options. First, all packets contain a locator, which is the selector. Second, packets contain either a flow-id, or a locator, which is the selector. I prefer the second, of course! Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:05:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09761; Sat, 16 Jul 1994 03:05:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08347; Sat, 16 Jul 1994 03:05:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08344; Sat, 16 Jul 1994 03:00:44 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09655; Sat, 16 Jul 1994 03:00:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17188; Fri, 15 Jul 94 13:00:38 -0400 Date: Fri, 15 Jul 94 13:00:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407151700.AA17188@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, smart@mel.dit.csiro.au Subject: Re: baby omnibus Cc: jnc@ginger.lcs.mit.edu From: Bob Smart From various places including PIP: separate transport end-point identifier from network locators. If I may correct the attribution, I feel that the basic idea came from Jerry Saltzer in his 1982 paper (repub'd as RFC-1498). A tip of the hat is also owed to Dave Oran, who pointed out to me at the San Diego IETF that these second names should name what we now call endpoints, not physical machines. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:16:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07831; Sat, 16 Jul 1994 02:05:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08197; Sat, 16 Jul 1994 02:05:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08190; Sat, 16 Jul 1994 01:56:06 +1000 Precedence: list Received: from eagle.es.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07432; Sat, 16 Jul 1994 01:55:50 +1000 (from alh@es.net) Received: from localhost by eagle.es.net; (5.65/1.1.8.2/18May94-0333PM) id AA16687; Fri, 15 Jul 1994 08:55:30 -0700 Message-Id: <9407151555.AA16687@eagle.es.net> To: jnc@thyme.LCS.MIT.EDU (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, alh@es.net Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too In-Reply-To: Your message of "Fri, 15 Jul 94 00:27:05 EDT." <9407150427.AA24471@thyme.LCS.MIT.EDU> Date: Fri, 15 Jul 94 08:55:29 -0700 From: "Tony Hain" X-Mts: smtp Noel, If you combine Dave's idea with yours you can get dynamic ESEL without registering each of them in DNS. >>Dave's idea was to pass the DNS endpoint name once, at connection >>startup. > >The ESEL is *not* a globally unique name for the endpoint (as the EID is). >Instead, it's a locally unique name for the endpoint, unique only within >that machine. If the connection setup included the endpoint name once, a local ESEL table could pass back the mapped value. This would allow full autoconfig for services since they would have access to a local table at install time on the endpoint system. Tony From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:16:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06464; Sat, 16 Jul 1994 01:29:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA08091; Sat, 16 Jul 1994 01:29:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08009; Sat, 16 Jul 1994 01:06:56 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04345; Sat, 16 Jul 1994 00:30:23 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Fri, 15 Jul 1994 10:29:40 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 15 Jul 1994 10:29:40 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02062; Fri, 15 Jul 94 10:27:31 EDT Date: Fri, 15 Jul 94 10:27:31 EDT Message-Id: <9407151427.AA02062@mailserv-D.ftp.com> To: big-internet@munnari.OZ.AU Cc: bsimpson@MorningStar.Com, pvm@isi.edu Subject: Re: Whither 8 bytes (64 bits) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 2778 Bill Simpson writes: >I can't figure out [what address length is desired]: > > ... > kasten@ftp.com (Frank Kastenholz) > ... And Paul Mockapetris writes: > 1) Those who believe that N-bytes are enough but aren't willing to > forclose the possibility that more will be needed. > > 2) Those who believe that a fixed length N-byte address is the most > important issue, regardless of N. > > ... I would feel comfortable about 8 only if > it comes with a safety valve so I can go to 16/24/32... IFF I NEED TO. Perhaps the reason that Bill can't figure out where I stand on the address size issue (and presumably others, though I'm sure that they'll speak for themselves), and why Paul divides up the address- size war parties as he did is that there are some people who have thought about the routing issues of the 'future' internet for a while and have come to a couple of conclusions: 1. The topologically significant information that 'lives' at the IP layer is the 'raw data' used by the routing and path selection subsystems of the Internet Layer. 2. The IPng effort is giving us the opportunity to replace all parts of the IP layer; from packet headers to forwarding algorithms to routing subsystems to addressing/locatoring/... schemes to ... 3. Since we _can_ develop a completely new structure for addressing, 'locatoring', endpoint identification, flows, etc etc etc, we should first develop the subsystems that use this data and then figure out what the optimal data are for those subsystems, taking into account all the elements of the system. 4. I believe that the needs of the Internet over the next 20-30 years will be very very different from what we have done in the past. That is, we really can't take what was done in the past, increase the size of the fields, or whatever, and assume that it will work for the future. Since (point 4) I think that we should rebuild some of the subsystems of the Internet layer, it makes sense to me that we should figure out what subsystems such as routing and path-selection are going to look like for these future needs and _then_ figure out what the best 'data' (such as locators, addresses, eids, etc) are for those subsystems. And someone else (I'm sorry, I forget who and didn't save the message so you'll have to claim credit yourself) writes something along the lines of: > This whole argument about address sizes is akin to arguing about > the size and shape of a container before we know what we are going > to put in the container or how big that thing is... Which is what some people are really advocating -- let's first figure out what it is we wish to contain and _then_ figure out the size and shape of the container(s). -- Frank Kastenholz From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:16:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07846; Sat, 16 Jul 1994 02:06:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08216; Sat, 16 Jul 1994 02:05:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08171; Sat, 16 Jul 1994 01:46:40 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07107; Sat, 16 Jul 1994 01:46:31 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA18560; Fri, 15 Jul 1994 08:46:17 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Jul 1994 08:46:22 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: re: prove you need EIDs in the header.... Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 8:19 PM 7/14/94, Noel Chiappa wrote: >As I recall your scheme, the downsides were that i) any application that >wanted to be mobile would have to be redone to use your teardown/setup >mechanism, and ii) this worked for TCP, but not for other transport protocols. Hosts need to be modified, but it's not clear to me that applications do. Some trickiness with name/address resolution code could hide things from the applications. (The only reason this is an issue is because we have applications know about addresses, rather than just giving the domain name to the transport layer. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:18:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07873; Sat, 16 Jul 1994 02:07:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08233; Sat, 16 Jul 1994 02:07:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08187; Sat, 16 Jul 1994 01:55:13 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07398; Sat, 16 Jul 1994 01:55:09 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-16.dialip.mich.net (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA28847 for ; Fri, 15 Jul 1994 11:55:05 -0400 Date: Fri, 15 Jul 94 15:12:55 GMT From: "William Allen Simpson" Message-Id: <2843.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: The "unsure" group > From: kasten@ftp.com (Frank Kastenholz) > > This whole argument about address sizes is akin to arguing about > > the size and shape of a container before we know what we are going > > to put in the container or how big that thing is... > > Which is what some people are really advocating -- let's first figure > out what it is we wish to contain and _then_ figure out the size and > shape of the container(s). > Thank you for bringing up an important point, Frank. There are a significant number of folks who think we should hold off on making any decisions until we have had more time to experiment. There are some others who are still defining their terminology and architecture. There are others (the old TP/IX group, and now a few on this list), who would like to re-open what a datagram really does for us, and how it relates to transport. The question could be "does taking more time to think deep architectural thoughts have a widespread consensus"? My view is that there has been a resounding "NO" to taking more time. My count is that there are a lot of people who have come to understand that these issues need to be addressed. Well over half of the group agrees we need to separate Identifier from Locator, for example. A significant fraction, although probably less than half, agrees we need some kind of Flow setup. But very few people are saying we can't move to a new packet format which includes these features now, even if they aren't used until later. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:24:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09842; Sat, 16 Jul 1994 03:07:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08369; Sat, 16 Jul 1994 03:07:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08330; Sat, 16 Jul 1994 02:54:20 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09337; Sat, 16 Jul 1994 02:54:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17136; Fri, 15 Jul 94 12:53:54 -0400 Date: Fri, 15 Jul 94 12:53:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407151653.AA17136@ginger.lcs.mit.edu> To: amolitor@anubis.network.com, big-internet@munnari.OZ.AU Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too Cc: jnc@ginger.lcs.mit.edu From: amolitor@anubis.network.com (Andrew Molitor) If it is to be decreed that DNS names shall serve for EIDs OK, I surrender. You can all have "EID" to mean "endpoint name". Now, can somebody please give me a term I can use to mean "endpoint name which is shortish, fixed length, and not topolgically dependent"? :-( While we're at it, can I have a term for "topologically sensitive internetwork destination name which is not an end point name and is not in all packets", since "locator" seems to have been redefined as "topologically sensitive internetwork destination name which is not an end point name". This is not a joke. I'm serious. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:26:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09169; Sat, 16 Jul 1994 02:47:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08311; Sat, 16 Jul 1994 02:47:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08272; Sat, 16 Jul 1994 02:34:23 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08484; Sat, 16 Jul 1994 02:34:20 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA18787; Fri, 15 Jul 1994 09:34:13 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Jul 1994 09:34:17 -0700 To: big-internet@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: MULTIP control (was: re: prove you need EIDs in the header) >At 8:19 PM 7/14/94, Noel Chiappa wrote: >>As I recall your scheme, the downsides were that i) any application that >>wanted to be mobile would have to be redone to use your teardown/setup >>mechanism Just had an additional thought about this. (Always fun to do design on the fly.) I've assumed that the both hosts start with a domain name for each other and then build a list of valid IP addresses, using the set for sending through more than one "spigot" for the same connection. Given the way applications tend to be responsible for the name/address mapping and for choosing a particular address, this WOULD suggest the need to modify applications. But another mode of operation occured to me: First, don't change the apps. What follows keeps the service interface above the transport layer unchanged. However, participating hosts DO still need to change at the transport layer. A host that is mobile or that otherwise wants to establish multiple IP "paths" between itself and another host begins by establishing a regular, vanilla transport connection/association with some other host. (I.e., it does whatever it does today.) The first host then initiates a parallel conversation with the other host, doing a MULTIP control exchange. (This is the 'other' protocol I've mentioned. There is a single one of these control channels between the two hosts.) In the initial exchange, the first host TELLs the other host what its own domain name is and then provides a starting set of IP addresses that are associated with it. The other host then does the same thing, about itself, in return. Hence, unique domain names are used. Applications are not changed. And the list of parallel IP-to-IP "paths" is built up. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:26:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09899; Sat, 16 Jul 1994 03:09:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08386; Sat, 16 Jul 1994 03:09:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08319; Sat, 16 Jul 1994 02:48:54 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09191; Sat, 16 Jul 1994 02:48:49 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA16058; Fri, 15 Jul 94 11:50:34 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ei05718; 15 Jul 94 16:45 GMT Date: Fri, 15 Jul 94 11:21 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too Message-Id: <01940715162110/0003858921NA4EM@mcimail.com> Andrew Molitor said: > One point I'd like to make here is that DNS names are not necessarily >public, at this point. Some folks feel that making them public amounts to >publishing details of your internal topology, and have no interest in doing >so. I think it's a perfectly reasonable position, and it's not obvious to >me that it will be unreasonable in future. That is our position here. Thus thanks for the wakeup call, I would not want my DNS naming to get all over the INTERNET. We are busy configuring our mail systems so that only aliases for a few internal systems will be publically know. So for Chrysler: EID <> DNS or EID never goes out in any packet (or maybe only on the segment). Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:55:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10036; Sat, 16 Jul 1994 03:11:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08414; Sat, 16 Jul 1994 03:11:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08299; Sat, 16 Jul 1994 02:46:04 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08996; Sat, 16 Jul 1994 02:45:57 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id MAA26748; Fri, 15 Jul 1994 12:45:49 -0400 Date: Fri, 15 Jul 1994 12:45:49 -0400 From: Vadim Antonov Message-Id: <199407151645.MAA26748@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, jnc@thyme.LCS.MIT.EDU Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too > At that point, my mind made the semi-obvious leap. Suppose that >packets do contain something to indicate which endpoint the packet is for, >but this indication is a small number; the "endpoint selector" (ESEL). The >ESEL is *not* a globally unique name for the endpoint (as the EID is). >Instead, it's a locally unique name for the endpoint, unique only within >that machine. .... Congratulations! You just discovered what we used to call "ports" :-) Seriously, you're not far from my point of view. I would prefer ports/ESEL's to be a part of a fixed-length address (12 bytes -- 8 for host + 4 for port). The rationale for allocating a fixed-size part of the address to ports/ESELs is that from the point of view of the network only first part is significant; the port is interpreted exclusively by host software. Then, the new host addresses are not likely to appear and disappear as fast as "active" ports. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:55:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10693; Sat, 16 Jul 1994 03:26:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08444; Sat, 16 Jul 1994 03:25:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08430; Sat, 16 Jul 1994 03:16:49 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10192; Sat, 16 Jul 1994 03:16:39 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU In-Reply-To: Noel Chiappa's message of Fri, 15 Jul 94 12:40:07 -0400 <9407151640.AA17012@ginger.lcs.mit.edu> Subject: Endpoint Selectors, or, Having Your Cake and Eating it Too Date: Fri, 15 Jul 94 13:15:29 -0400 Message-Id: <9407151315.aa14323@quern.epilogue.com> Date: Fri, 15 Jul 94 12:40:07 -0400 From: Noel Chiappa Two options. First, all packets contain a locator, which is the selector. Second, packets contain either a flow-id, or a locator, which is the selector. I prefer the second, of course! Then the flow-id has to be globally unique. With the EID missing, how do you create globally unique flow-ids? Dave From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 03:55:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10754; Sat, 16 Jul 1994 03:28:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08461; Sat, 16 Jul 1994 03:27:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08361; Sat, 16 Jul 1994 03:06:49 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09822; Sat, 16 Jul 1994 03:06:39 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id NAA26888; Fri, 15 Jul 1994 13:06:36 -0400 Date: Fri, 15 Jul 1994 13:06:36 -0400 From: Vadim Antonov Message-Id: <199407151706.NAA26888@titan.sprintlink.net> To: big-Internet@munnari.OZ.AU, paul@vix.com Subject: Re: EID's in the packets Paul Vixie wrote: >Killing off well known ports is a good idea, but it has nothing to do with IP. >Let's finish extending IP first and then deal with the higher level issues. Well, it *is* the case when the old historical crud makes us to make the IP level deliberately worse. It is like that -- get away from well-known ports and you no longer need EIDs ==> significantly smaller IP headers with different layout. We have a good chance to clean up a lot of old things; why limit ourselves? It is not a big change compared with what IPng will do with routing and applications, after all. Don't forget about "backwards" in "backwards compatible". --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 04:07:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12354; Sat, 16 Jul 1994 04:07:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08521; Sat, 16 Jul 1994 04:05:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08494; Sat, 16 Jul 1994 03:54:38 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10796; Sat, 16 Jul 1994 03:28:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17547; Fri, 15 Jul 94 13:28:04 -0400 Date: Fri, 15 Jul 94 13:28:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407151728.AA17547@ginger.lcs.mit.edu> To: dab@epilogue.com, jnc@ginger.lcs.mit.edu Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Dave Bridgham Then the flow-id has to be globally unique. With the EID missing, how do you create globally unique flow-ids? I'm not sure you need to have them be globally unique. I just posted somethign about that on "flows", let's move this there. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 04:09:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12385; Sat, 16 Jul 1994 04:09:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08544; Sat, 16 Jul 1994 04:08:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08508; Sat, 16 Jul 1994 03:55:15 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10776; Sat, 16 Jul 1994 03:28:18 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty19.jvnc.net. (franklin-tty19.jvnc.net) by tigger.jvnc.net with SMTP id AA17205 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Fri, 15 Jul 1994 13:26:52 -0400 Message-Id: Date: Fri, 15 Jul 94 13:25:52 EDT From: "David M. Piscitello" Subject: Re: The "unsure" group Reply-To: dave@corecom.com To: bsimpson@morningstar.com, big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 To increase the number (or vote twice, can't tell...), I'll suggest that we are likely to supplant IPv4 "baggage" with new baggage if we don't have a clue what we want in the header but will include "placeholders" -- especially fixed length ones -- in the IPng header. >But very few people are saying we can't move to a new packet format which >includes these features now, even if they aren't used until later. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 04:12:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12422; Sat, 16 Jul 1994 04:12:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08572; Sat, 16 Jul 1994 04:12:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08491; Sat, 16 Jul 1994 03:50:49 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11619; Sat, 16 Jul 1994 03:50:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17766; Fri, 15 Jul 94 13:48:37 -0400 Date: Fri, 15 Jul 94 13:48:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407151748.AA17766@ginger.lcs.mit.edu> To: 0003858921@mcimail.com, big-internet@munnari.OZ.AU Subject: Re: How many bits are enough? Cc: jnc@ginger.lcs.mit.edu From: "Robert G. Moskowitz" <0003858921@mcimail.com> Ah, but if we support unmanaged levels, ie you choose your own poison, you might go with a deep skinny tree and thus use 5 bits per level (32 nodes per level) or 6 levels in 8 bytes. Someone else could go with a fatter tree of 6 bits (64 nodes) or 5 levels. Sure. But what happens to the first person when they need to extend one of those fields, because of growth in an area? How about if they need to add a level in the middle? If we had a format with some sort of internal separators, it would be trivial. Fixed-length and mask can be really painful, no matter how good you make the user interface. That is what we have to allow for in this locator stuff. Not some fix idea of what everyone can live with. I couldn't agree more. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 04:15:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12490; Sat, 16 Jul 1994 04:15:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08589; Sat, 16 Jul 1994 04:14:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08511; Sat, 16 Jul 1994 03:55:37 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10695; Sat, 16 Jul 1994 03:26:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01399 Sat, 16 Jul 1994 03:24:46 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17469; Fri, 15 Jul 94 13:20:39 -0400 Date: Fri, 15 Jul 94 13:20:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407151720.AA17469@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov Kill the concept of *well known ports* which is a kludge from the very beginning You have exactly the same problem even if you don't have well-known ports. The issue is a collision caused by non-coordinated allocation, which can happen in any demultiplexing scheme. start treating distribution of packets between processes as a kind of network -- i.e. include "port numbers" into locators! This is an interesting idea. Hmmm. If you make the port part of the locator, then is there any invariant which "names" the *connection* (not the host, since the DNS name does that) which stays the same if the connection moves? The topology part of the "locator" always could change, but now the port part can too, since you can still get a collision (but you can renumber the port now). Part of the concept of a TLEN (such as an EID) is that it+protocol+port uniquely identifies one end of connection, in a location invariant way. Your scheme doesn't seem to have any equivalent. I guess you could negotiate some unique ID at the time the connection is opened, and refer to it by that name? But what about connectionless applications that use UDP ports? This in an interesting radical proposal, but one that requires a lot of thinking about. So, as you can see your rationale for having EIDs has obvious logical gaps in it. Err, you mean the rational for having EID's in packets, right? You still have location-invariant names for transport entities, right? I have reasons to think that other "proven" things about EIDs are as suspicious as this particular one. Can you provide any details? Do you not like the location invariance? How about the fixed length? (I can't think of anything else about EID's!) Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 06:14:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13668; Sat, 16 Jul 1994 04:45:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08643; Sat, 16 Jul 1994 04:45:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08638; Sat, 16 Jul 1994 04:40:50 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13550; Sat, 16 Jul 1994 04:40:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18323; Fri, 15 Jul 94 14:40:37 -0400 Date: Fri, 15 Jul 94 14:40:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407151840.AA18323@ginger.lcs.mit.edu> To: alh@es.net, big-internet@munnari.OZ.AU Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too Cc: jnc@ginger.lcs.mit.edu From: "Tony Hain" you can get dynamic ESEL without ... registering each of them in DNS. If the connection setup included the endpoint name once, a local ESEL table could pass back the mapped value. Yes, this would work too, but it has one aspect that will surely make people throw up. :-) To make it work in a general way, across all protocols and transports, you'd want to pass the DNS name at a level below the transport. I.e, we'd have DNS names in the internetwork header on the initial packet. Maybe this isn't so crazy, actually. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 06:20:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13707; Sat, 16 Jul 1994 04:47:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08658; Sat, 16 Jul 1994 04:47:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08624; Sat, 16 Jul 1994 04:35:44 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13244; Sat, 16 Jul 1994 04:35:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18296; Fri, 15 Jul 94 14:35:32 -0400 Date: Fri, 15 Jul 94 14:35:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407151835.AA18296@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: re: prove you need EIDs in the header.... Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) Hosts need to be modified, but it's not clear to me that applications do. ... we have applications know about addresses, rather than just giving the domain name to the transport layer. Ah, this reminds me of another idea I heard, richocheting off ESEL's, about how to do transition to IPng and retain binary compatability for the applications. (If the people doing transition have already got this, my apologies for trying to teach them to suck eggs, but I don't recall hearing about it.) It's sort of like NAT, except localized to a host (which reduces the barf factor considerably, I reckon). When you do a DNS lookup, you get back a 32-bit thing, but instead of it being a globally unique IPv4 address, it's really just an "index" into a local table which maps to an IPng . So, future system calls (to open connections, send data) etc can just pass that along, and the network software in the host converts that the relevant IPng . You can think of the 32-bit thing as an ESEL, but one used at the traffic source, not the destination. This keeps binary compatabilty for the applications, at least the ones which aren't constructing IPv4 packets themselves. I suppose you could work out a transmogrification algorithm to take care of those, too. You have to have two different DNS interfaces, and you have to tie the DNS software closer to the rest of the OS, but other than that it's not bad, and keeping binary compability with apps is probably a Good Thing. It works with either address or locator/TLEN's version of IPng, as far as I can see. I'm not really a host user-interface wizard, but perhaps those who are can tell me if this has any merit? Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 06:25:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17062; Sat, 16 Jul 1994 06:25:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA08764; Sat, 16 Jul 1994 06:25:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08748; Sat, 16 Jul 1994 06:20:21 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14359; Sat, 16 Jul 1994 05:12:39 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14578(10)>; Fri, 15 Jul 1994 12:12:27 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 15 Jul 1994 12:12:22 -0700 To: avg@sprint.net Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, deering@parc.xerox.com Subject: Re: EID's in the packets In-Reply-To: jnc's message of Fri, 15 Jul 94 10:20:39 -0800. <9407151720.AA17469@ginger.lcs.mit.edu> Date: Fri, 15 Jul 1994 12:12:10 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul15.121222pdt.12171@skylark.parc.xerox.com> > start treating distribution of packets between processes as a kind of > network -- i.e. include "port numbers" into locators! That's the way XNS (and its offspring, IPX) works. Basically, XNS demuxes on port number first, then protocol type, while the IP architecture does it the other way around. In XNS, both port numbers and protocol are carried in the internet header. The XNS approach has advantages with respect to fast dispatching to separate address spaces on receivers and delivery of error messages to senders (e.g., it avoids the ICMP kludge of including enough of a transport header to figure out what process should receive an error message). (No, I'm *not* suggesting that that's what we should do in IPng -- I don't think the benefits would be worth the upper-layers upheaval that such a change would entail.) Steve From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 07:05:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18074; Sat, 16 Jul 1994 07:05:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA08808; Sat, 16 Jul 1994 07:05:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08803; Sat, 16 Jul 1994 07:01:19 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18001; Sat, 16 Jul 1994 07:01:09 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA02947; Fri, 15 Jul 94 16:02:49 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af23010; 15 Jul 94 20:58 GMT Date: Fri, 15 Jul 94 15:55 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too Message-Id: <60940715205506/0003858921NA4EM@mcimail.com> Howard Berkowitz said: >Would it suffice to meet these requirements to do a public key encryption >on the DNS and use the encrypted DNS (or compressed DNS, as I discuss >in my other note) as the EID? No. My DNS names are not for public consumption... Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 07:45:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19159; Sat, 16 Jul 1994 07:45:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA08926; Sat, 16 Jul 1994 07:45:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08921; Sat, 16 Jul 1994 07:44:57 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18328; Sat, 16 Jul 1994 07:20:12 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEQPFT510G000CSS@FNAL.FNAL.GOV>; Fri, 15 Jul 1994 16:20:04 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA21244; Fri, 15 Jul 94 16:19:38 CDT Date: Fri, 15 Jul 1994 16:19:38 -0500 From: Matt Crawford Subject: Re: summary of Big-Internet messages In-Reply-To: Your message of Fri, 15 Jul 94 14:41:53 +0800. <9407150542.AA21542@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Message-Id: <9407152119.AA21244@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > PS > It should be noted that looking up domain name from "locator" just does > not work, as DNS update, even the most dynamic one, can not be assured to > be so fast. Agreed. I think the proper way to find out identity, given location, is to send a query to the location. This requires that the destination identifier not be a mandatory part of all packets. If you need assurance of a truthful answer to the query, use some authentication mechanism. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 07:49:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18412; Sat, 16 Jul 1994 07:25:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA08854; Sat, 16 Jul 1994 07:25:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08841; Sat, 16 Jul 1994 07:21:31 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18362; Sat, 16 Jul 1994 07:21:26 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA24945; Fri, 15 Jul 94 15:21:02 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA18514; Fri, 15 Jul 94 14:16:39 PDT Date: Fri, 15 Jul 94 14:16:38 PDT Message-Id: <9407152116.AA18514@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jnc@ginger.lcs.mit.edu (Noel Chiappa), avg@sprint.net From: Greg Minshall Subject: Re: EID's in the packets Cc: big-internet@munnari.OZ.AU > start treating distribution of packets between processes as a kind of > network -- i.e. include "port numbers" into locators! > >This is an interesting idea. Hmmm. If you make the port part of the locator, >then is there any invariant which "names" the *connection* (not the host, >since the DNS name does that) which stays the same if the connection moves? Wake up, folks! The destination port != connection. Connection == (src addr, src port, dest addr, dest port). Unless you are claiming "if we move *one* connection of a service, we want to move them all" (and, clearly that is NOT the case for, say, load balancing)... Greg From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 07:49:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18539; Sat, 16 Jul 1994 07:27:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA08872; Sat, 16 Jul 1994 07:27:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08835; Sat, 16 Jul 1994 07:14:47 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18204; Sat, 16 Jul 1994 07:14:38 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA03553; Fri, 15 Jul 94 16:16:27 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id al24078; 15 Jul 94 21:11 GMT Date: Fri, 15 Jul 94 16:10 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: IPng and .... Firewalls! Message-Id: <25940715211052/0003858921NA2EM@mcimail.com> Some of you might have noticed that I am 'hung up on locator+EID. I like the idea. It addresses a lot of issues in my mind. I can't, yet, sort out how things like flow ids would fix this, but recently something gelled in my mind. Firewalls ain't going away with IPng. Sorry folks. This time the proof is in on the otherside. My auditors will have to be shown the unassiableness of IPng based systems from all attacks. Basically a non-solvable problem, much like the 4 color map problem. So I plan on having my own internal locator structure that will have nothing to do with the public's locator. But MOST of my EIDs will be publicly unique. I think what will happen is the firewall becomes a locator proxy of some sort. I don't have time to go into it now. Shabbos is a few hours away and time to head for home. Sunday is the 9th of AV, so I doubt if I will have the strength to log on (I don't fast easily), and monday is a special Chrysler offsite planning meeting, so I would get much done then (ie. behind the BIG-I 8-ball again :( ). But think about this. I still think I need locator and EID. Am I just not flying as high as the rest of you eagles? (i.e. I'm just a hawk?) Well, back to the turkeys here for a little while and then home :) Bob From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 07:50:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18608; Sat, 16 Jul 1994 07:30:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA08891; Sat, 16 Jul 1994 07:29:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08838; Sat, 16 Jul 1994 07:17:12 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18267; Sat, 16 Jul 1994 07:17:06 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEQPBJYFQO000CRW@FNAL.FNAL.GOV>; Fri, 15 Jul 1994 16:16:38 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA21223; Fri, 15 Jul 94 16:16:12 CDT Date: Fri, 15 Jul 1994 16:16:12 -0500 From: Matt Crawford Subject: Re: Endpoint Selectors, or, Having Your Cake and Eating it Too In-Reply-To: Your message of Fri, 15 Jul 94 00:27:05 EDT. <9407150427.AA24471@thyme.LCS.MIT.EDU> To: jnc@thyme.LCS.MIT.EDU (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Message-Id: <9407152116.AA21223@munin.fnal.gov> Content-Transfer-Encoding: 7BIT I don't like little bitty endpoint selectors. To me, one important function of an endpoint identifier is to help a THING prove that it is the same THING I was talking to a minute ago, even though the way I talk to the THING has now changed. With a globally unique endpoint identifer (GUEID? or maybe a globally unique identifier of endpoint would have a better acronym) I can choose to trust the THING's claim. Or the THING can pass me some authentication which I can verify by looking up some security association previously created between me and the THING. If the identifier has some administratively derived hierarchical structure, I can use it to look up information which lets the THING prove its claim. Such an identifier needn't be in every packet, as the above purpose only needs the identifier when the method of reaching the THING changes. As long as the THING always knows knows when its network location has changed, it can take responsibility for informing me of that change, and I can assume between times that packets from a given [network address + transport demultiplexor] are from the same THING. (This presumes that something like TCP's 2*MSL TIME_WAIT before re-use of a given transport demultiplexor on the host applies when a THING has migrated away as well as when it has closed its connection.) Hostname-derived endpoint identifiers are attractive for their parsimony, but problematic when applied to mobile processes which are smaller than a computer but which move over a range larger than a computer. Endpoint identifierss in the DNS namespace will be often orthogonal to names of systems, even though the common case will probably be that a system's name is the same as, or a suffix of, the identifier of every endpoint hosted by that system. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 08:56:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19187; Sat, 16 Jul 1994 07:47:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA08943; Sat, 16 Jul 1994 07:47:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08907; Sat, 16 Jul 1994 07:39:11 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19037; Sat, 16 Jul 1994 07:39:06 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEQQ4269GW000CXZ@FNAL.FNAL.GOV>; Fri, 15 Jul 1994 16:38:51 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA21314; Fri, 15 Jul 94 16:38:24 CDT Date: Fri, 15 Jul 1994 16:38:24 -0500 From: Matt Crawford Subject: Re: EID's in the packets In-Reply-To: Your message of Fri, 15 Jul 94 01:09:11 EDT. <9407150509.AA13412@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, avg@sprint.net Message-Id: <9407152138.AA21314@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Can anybody *prove* that EIDs in headers are necessary? Gads, I don't know what constitutes a proof to this crowd! :-) Let me put it to you this way. If a process with a TCP connection open on port X moves from host A to host B, and a process on B already has a connection open on X, how do you tell which one TCP packets to port X go to, without something in the packet to indentify which endpoint (process) the packets are for? Can you do it efficiently and reasonably without something in the header? What constitutes disproof to this crowd? Maybe this will ... Endpoint E on (host H, port P) is talking to endpoint F on (host G, port Q). E moves to host H', where port P might already be in use. Until F learns of the move, H' will not receive packets for E on any port. So when E informs F of the move to H' (or when some entity informs F on E's behalf), F can also be informed of the new port P', if necessary. Thus, during intervals of non-migration, the usual locating-address plus port are sufficient to deliver packets to the right process. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 08:58:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19792; Sat, 16 Jul 1994 08:05:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA08984; Sat, 16 Jul 1994 08:05:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08965; Sat, 16 Jul 1994 07:54:08 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19297; Sat, 16 Jul 1994 07:49:08 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA25859; Fri, 15 Jul 94 15:48:52 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA18644; Fri, 15 Jul 94 14:44:29 PDT Date: Fri, 15 Jul 94 14:44:28 PDT Message-Id: <9407152144.AA18644@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Robert G. Moskowitz" <0003858921@mcimail.com> From: Greg Minshall Subject: Re: Why EIDs should be in headers. Cc: big internet Bob, >One of our on-going challenges is to GUESS the number of devices in a subnet >to set the mask. And we can and do throw router hardware at the problem! Absolutely a problem! And, i'm sure our friends at Cisco, Wellfleet, us, etc., are all approving of your solution! >I want a routing mechanism that does not pre-determine the segment setup. >With global 'EIDs' coupled with 'locators' I get that I'm not sure how EIDs are going to help you here. >Autoconfig proponents can argue that the 'mask' can be changed at will. I >respond that this would have to be dynamic while the device is running as I >have 7x24 systems up on lots of segments. Taking some of these down takes a >VP signed authorization! (Or a software bug :) I assume that (eventually at least) your VP authorized 7x24 will have multiple interfaces? I would think that the rate of "oops - we need to re-do the mask [no masks in IPng!!!!!], so let's re-locate" should be small enough that dropping one interface, re-locating it, and bringing it up again should not be that big of a deal. On the other hand, maybe you have *very* long running transport connections? (Weeks, months...) Greg From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 08:58:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19884; Sat, 16 Jul 1994 08:10:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09018; Sat, 16 Jul 1994 08:09:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08951; Sat, 16 Jul 1994 07:48:48 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18380; Sat, 16 Jul 1994 07:23:16 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id RAA29626; Fri, 15 Jul 1994 17:23:13 -0400 Date: Fri, 15 Jul 1994 17:23:13 -0400 From: Vadim Antonov Message-Id: <199407152123.RAA29626@titan.sprintlink.net> To: avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets >I guess you could negotiate some unique ID at the time the connection is >opened, and refer to it by that name? But what about connectionless >applications that use UDP ports? This in an interesting radical proposal, >but one that requires a lot of thinking about. Well, the idea is rather trivial -- to get the network semantics identical to programmer's interface semantics. Eliminate the semantic gap. If you don't have fixed port numbers you can change the locator for UDP port on-the-fly. It's no different from connection-oriented protocols. >> So, as you can see your rationale for having EIDs has obvious >> logical gaps in it. > Err, you mean the rational for having EID's in packets, right? You still have > location-invariant names for transport entities, right? Yes. Let's use "EID" as a term for globally-unique location invariant host identifier *in the packets*. The term "name" is something very much like EIDs but names aren't expected to be known in the transport fabric; i.e. they do not appear in packet headers. >Can you provide any details? Do you not like the location invariance? How >about the fixed length? (I can't think of anything else about EID's!) I feel ok about function-name binding invariance :-) If the names aren't used for making routing decisions by intermediate systems there is no problems with having them variable-length. Names shouldn't be associated with pieces of hardware. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 08:58:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19844; Sat, 16 Jul 1994 08:07:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09001; Sat, 16 Jul 1994 08:07:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08968; Sat, 16 Jul 1994 07:54:11 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19308; Sat, 16 Jul 1994 07:49:20 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA25877; Fri, 15 Jul 94 15:49:03 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB18644; Fri, 15 Jul 94 14:44:40 PDT Date: Fri, 15 Jul 94 14:44:40 PDT Message-Id: <9407152144.AB18644@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Greg Minshall Subject: Re: EID's in the packets Cc: big-internet@munnari.OZ.AU Friend Noel, friend world, >To say it again briefly, if you have more than one endpoint at a given >interface/host, you need something in the incoming packets to tell you which >endpoint (and thus, which TCP, say) the packets belong to. It doesn't have to >be an EID; it could be an endpoint selector (which I finally got around to >describing), or something else. But, I think there does have to be some >indication in the packet. Having multiple endpoints at a single interface/host >is not unreasonable; mobile processes are but one example. I feel a bit silly entering into this discussion, since my basic stand is that no one actually knows what the blank an EID really is, anyway. However... Look, an EID identifies a name space. What "layer" it is in depends on when you run into it. If at the end of parsing an IP address and deciding "hey, this is for me! yuck, yuck!", IP *then* encounters an EID, then the EID names the name space in which to interpret protocol types. I.e., to determine which "(transport) process" is bound to which "protocol type". If at the end of parsing the IP address, IP encounters a protocol type, and *then* encounters an EID, then the *protocol type* has identified a name space in which the EID has meaning; the EID, in turn, identifies a name space (interpreted by the transport protocol instance bound to that EID) in which ports have meaning. Or, something like that. Greg From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 09:04:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20874; Sat, 16 Jul 1994 08:45:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09093; Sat, 16 Jul 1994 08:45:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09074; Sat, 16 Jul 1994 08:26:33 +1000 Precedence: list Received: from primus.cstp.umkc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20398; Sat, 16 Jul 1994 08:26:28 +1000 (from lee@PRIMUS.CSTP.UMKC.EDU) Received: by PRIMUS.CSTP.UMKC.EDU (MX V4.0-1 AXP) id 3; Fri, 15 Jul 1994 17:26:25 CST Date: Fri, 15 Jul 1994 17:26:25 CST From: Sung Jong Lee (David) Reply-To: LEE@vax2.cstp.umkc.edu To: big-internet@munnari.OZ.AU Message-Id: <0098178F.1A622AA6.3@PRIMUS.CSTP.UMKC.EDU> Subject: help Hi all, Does anybody know what is going on this mailing list? I am receiving the same mail three times even. And I cannot unsubcribe it. Whom should I contact personally. Any comment or tips will be appreciated. Thanks From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 09:04:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21018; Sat, 16 Jul 1994 08:48:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09108; Sat, 16 Jul 1994 08:48:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09077; Sat, 16 Jul 1994 08:36:14 +1000 Precedence: list From: jim@Tadpole.COM Received: from tadpole.Tadpole.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20694; Sat, 16 Jul 1994 08:36:10 +1000 (from jim@Tadpole.COM) Received: from chiba (chiba.Tadpole.COM) by tadpole.tadpole.com (4.1/SMI-4.1-jim) id AA04683; Fri, 15 Jul 94 17:35:48 CDT Received: by chiba (5.x/SPARCbook_POP1.3) id AA09326; Fri, 15 Jul 1994 17:35:57 -0500 Date: Fri, 15 Jul 1994 17:35:57 -0500 Message-Id: <9407152235.AA09326@chiba> To: big-Internet@munnari.OZ.AU, paul@vix.com Subject: Re: EID's in the packets While SIP was about more than sizeof(ip address)*2, I have to agree with Paul, wishing that we had just adopted SIP in close to the version that Steve presented at the IETF meeting in Washington D.C. two years ago. By now, we might actually have some deployment going. Jim From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 09:05:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21553; Sat, 16 Jul 1994 09:05:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09150; Sat, 16 Jul 1994 09:05:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09126; Sat, 16 Jul 1994 08:53:50 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19551; Sat, 16 Jul 1994 07:59:22 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: big-internet@munnari.OZ.AU In-Reply-To: "Robert G. Moskowitz"'s message of Fri, 15 Jul 94 16:10 EST <25940715211052/0003858921NA2EM@mcimail.com> Subject: IPng and .... Firewalls! Date: Fri, 15 Jul 94 17:58:32 -0400 Message-Id: <9407151758.aa16195@quern.epilogue.com> Date: Fri, 15 Jul 94 16:10 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> Firewalls ain't going away with IPng. Sorry folks. This time the proof is in on the otherside. My auditors will have to be shown the unassiableness of IPng based systems from all attacks. Basically a non-solvable problem, much like the 4 color map problem. An interesting analogy. The four color map problem was solved a few years ago. Maybe there's hope that people will secure their machines after all? Dave From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 09:05:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19925; Sat, 16 Jul 1994 08:12:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09046; Sat, 16 Jul 1994 08:12:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA08962; Sat, 16 Jul 1994 07:50:18 +1000 Precedence: list Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18799; Sat, 16 Jul 1994 07:36:25 +1000 (from news@vix.com) Received: by gw.home.vix.com id AA29343; Fri, 15 Jul 94 14:36:22 -0700 Date: Fri, 15 Jul 94 14:36:22 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: big-Internet@munnari.OZ.AU From: paul@vix.com (Paul A Vixie) Subject: Re: EID's in the packets Organization: Vixie Enterprises Message-Id: References: <199407151706.NAA26888@titan.sprintlink.net> Nntp-Posting-Host: office.home.vix.com In-Reply-To: avg@sprint.net's message of 15 Jul 1994 10:57:00 -0700 Checking in again from the home for recalcitrant implementors... | Well, it *is* the case when the old historical crud makes us to make the IP | level deliberately worse. It is like that -- get away from well-known | ports and you no longer need EIDs ==> significantly smaller IP headers with | different layout. Actually I'm expecting larger IP headers if we include full endpoint info, since we will have to include what the "port number" does now. However, the UDP and TCP equivilents in the IPng world could have _smaller_ headers since they would get more endpoint info from IPng than they get from IP now. | We have a good chance to clean up a lot of old things; why limit ourselves? Ummm. Is that a trick question? We have to limit ourselves or we will never get anything accomplished. A lot of folks (not you nec'ily, Vadim) on this list seem to have missed the significance of IP, and what made IP "special". I can't think of a pithy way to say it, except that IP "exists" and has been implemented (and installed) on more computers than any other protocol stack in history. No single-vendor solution could stand in its way, though some tried (you know who you are :-)). If we're to duplicate that success, we have to do what IP did -- get something that works and get it done NOW. Ease of correct implementation is much more important than overall technogoodness. | It is not a big change compared with what IPng will do with routing and | applications, after all. I am going to take a big chance here, and admit my own biases. I like SIP. The original, straight from the bottle SIP as proposed several years ago by Steve Deering. I wish that we had "just done it" instead of quibbling over whether it had this or that feature or whether the right number of bits could dance on the head of its pins. Deering's original proposal had warts, but no more than IP, and it would have been easy to just implement the damned thing and get out of the inning and on to the next one. It would have solved the fundamental address field size problems we're having. And existing TCP and UDP protocols could just live on top of it _with_no_changes_. Now here we are talking about EID's, ESEL's, variable width addresses, hierarchical addresses, and a whole lot of other _really_cool_ stuff that would be "great to have". But correct implementations of these will be a long time coming. And the definition of what we actually _want_ has ALREADY been a long time coming. This is definitely one of those times when it would have been better to have 20 million addresses by Friday than to have 20 million addresses per second. It's not too late to roll back the clock, shoot all the architects, bulldoze the prototypes, multiply all the field sizes by N, and DO IT. -- Paul Vixie Redwood City, CA decwrl!vixie!paul From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 09:10:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21577; Sat, 16 Jul 1994 09:07:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09167; Sat, 16 Jul 1994 09:07:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09140; Sat, 16 Jul 1994 08:57:58 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21417; Sat, 16 Jul 1994 08:57:54 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14599(7)>; Fri, 15 Jul 1994 15:57:42 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 15 Jul 1994 15:57:37 -0700 To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Why EIDs should be in headers. In-Reply-To: 0003858921's message of Fri, 15 Jul 94 04:53:00 -0800. <43940715115334/0003858921NA1EM@mcimail.com> Date: Fri, 15 Jul 1994 15:57:28 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul15.155737pdt.12171@skylark.parc.xerox.com> > One of our on-going challenges is to GUESS the number of devices in a subnet > to set the mask. Bob, With SIPP-16, that problem would go away: each LAN gets 48 bits of node ID space (in which IEEE 802 addresses can be used for autoconfig) and each point-to-point link gets 2 bits of node ID space (00 = cluster address for link, 01 = node at one end, 10 = node at other end, 11 = unused). That's one of the few compensating benefits of making SIPP addresses "silly" size. I don't know what this has to do with EIDs, though. Steve From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 09:58:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21728; Sat, 16 Jul 1994 09:09:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09182; Sat, 16 Jul 1994 09:09:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09145; Sat, 16 Jul 1994 09:02:02 +1000 Precedence: list Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20983; Sat, 16 Jul 1994 08:46:32 +1000 (from clynn@BBN.COM) Message-Id: <9407152246.20983@munnari.oz.au> Date: Fri, 15 Jul 94 18:44:12 EDT From: Charles Lynn To: Matt Crawford Cc: Noel Chiappa , big-internet@munnari.OZ.AU, avg@sprint.net Subject: Re: EID's in the packets Matt, > Endpoint E on (host H, port P) is talking to > endpoint F on (host G, port Q). As I understand things, the "connection", usng the traditional quad is . > E moves to host H', where port P might already be in use. But NOT by endpoint E - E is a fate sharing region so all hosts that contain parts of E know which protocols/ports identified by E are in use. > Until F learns of the move, H' will not receive packets for E on any port. Ok. > So when E informs F of the move to H' (or when some entity informs F on > E's behalf), F can also be informed of the new port P', if necessary. If H' already has an , it is the SAME one that was on H. If H' has some where ? is not E, there is no need for a new port. > Thus, during intervals of non-migration, the usual locating-address plus > port are sufficient to deliver packets to the right process. No, there might be more than one EID associated with the port P in a host. One needs the EID to demux. Charlie From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 10:05:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23538; Sat, 16 Jul 1994 10:05:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA09254; Sat, 16 Jul 1994 10:05:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09246; Sat, 16 Jul 1994 09:58:24 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23096; Sat, 16 Jul 1994 09:49:52 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id TAA01565; Fri, 15 Jul 1994 19:49:49 -0400 Date: Fri, 15 Jul 1994 19:49:49 -0400 From: Vadim Antonov Message-Id: <199407152349.TAA01565@titan.sprintlink.net> To: big-Internet@munnari.OZ.AU, paul@vix.com Subject: Re: EID's in the packets Paul, the name of the game is "mobility". To solve the addressing problem increasing address to 8 bytes is enough. BUT -- if you do that other things like routing table bloat and route flap will get you. In this sense the original IP is rather well-balanced -- it starts to fall apart in several places simultaneously. If we're doing mobility/dynamic addressing the old IP will no longer work no matter how fat the fields are. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 10:09:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23651; Sat, 16 Jul 1994 10:09:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA09269; Sat, 16 Jul 1994 10:09:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09249; Sat, 16 Jul 1994 09:58:41 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22984; Sat, 16 Jul 1994 09:45:09 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id TAA01552; Fri, 15 Jul 1994 19:45:04 -0400 Date: Fri, 15 Jul 1994 19:45:04 -0400 From: Vadim Antonov Message-Id: <199407152345.TAA01552@titan.sprintlink.net> To: Greg_Minshall@Novell.COM, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets Cc: big-internet@munnari.OZ.AU >If at the end of parsing the IP address, IP encounters a protocol type, and >*then* encounters an EID, then the *protocol type* has identified a name >space in which the EID has meaning; the EID, in turn, identifies a name >space (interpreted by the transport protocol instance bound to that EID) in >which ports have meaning. On the second thought, if ports are 1:1 to sockets there is NO need to carry protocol number in the packets! Simply because all (sane) packets arriving to a port will all have the same protocol. Killing well-known port numbers will also kill assigned protocol numbers and the associated headache. No EIDs, no assinged protocol numbers, straightforward support for process mobility and connection forwarding -- i think it worth some further consideration. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 11:45:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26478; Sat, 16 Jul 1994 11:45:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA09395; Sat, 16 Jul 1994 11:45:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA09358; Sat, 16 Jul 1994 11:29:34 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26051; Sat, 16 Jul 1994 11:29:28 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA02738; Fri, 15 Jul 94 21:29:24 EDT Message-Id: <9407160129.AA02738@tipper.oit.unc.edu> To: big-internet@munnari.OZ.AU Subject: Re: help In-Reply-To: Your message of "Fri, 15 Jul 94 17:26:25 CST." <0098178F.1A622AA6.3@PRIMUS.CSTP.UMKC.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Jul 94 21:29:24 -0400 From: Simon E Spero Sung Jong Lee (David) writes: >Does anybody know what is going on this mailing list? >I am receiving the same mail three times even. And I cannot I thought this was happening to me-then I discovered that people were just making the same points over and over again. If you look closely, you may notice that some of the words are different, or that the words are the same, but the definition of the words has changed. Simon IP-NG Tote Bets accepted in Zorkmids only ---------- SIPP 7-2 on No decision 3-1 TUBA 25-1 100-1 Bar From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 13:05:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29007; Sat, 16 Jul 1994 13:05:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA09515; Sat, 16 Jul 1994 13:05:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA09510; Sat, 16 Jul 1994 13:04:22 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28996; Sat, 16 Jul 1994 13:04:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20801; Fri, 15 Jul 94 23:04:04 -0400 Date: Fri, 15 Jul 94 23:04:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407160304.AA20801@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: help Cc: jncjnc@ginger.lcs.mit.edu From: Sung Jong Lee (David) Does anybody know what is going on this mailing list? This is undoubtly the most apt summary of Big-I I have ever seen. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 14:25:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01533; Sat, 16 Jul 1994 14:25:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09605; Sat, 16 Jul 1994 14:25:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09578; Sat, 16 Jul 1994 14:06:40 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01047; Sat, 16 Jul 1994 14:06:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20996; Sat, 16 Jul 94 00:06:28 -0400 Date: Sat, 16 Jul 94 00:06:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407160406.AA20996@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, clynn@bbn.com Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Charles Lynn If H' already has an , it is the SAME one that was on H. If H' has some where ? is not E, there is no need for a new port. ... No, there might be more than one EID associated with the port P in a host. One needs the EID to demux. People are thinking about systems in which you can modify the port numbers, as an alternative to including the EID in the packets. You can make this work, at least in protocols with ports. My intuition says you're better off having an invariant name *somewhere* for a connection. Anything else sounds much like a hire-wire act with no net; yes, if you're good it's OK, but the Lord help you if something goes wrong. My "robustness meter" is giving me an indeterminate reading on this... Also, my intuition still says that when you have multiple endpoints on a host, you're better off having something in the packet which identifies the endpoint. The reasons are much the same. One aspect which isn't being thought about here is "what uses do we have for being able to name the whole endpoint with a single name". I'm too burned out to think that through; maybe someone has some ideas. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 14:45:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02310; Sat, 16 Jul 1994 14:45:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09637; Sat, 16 Jul 1994 14:45:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09619; Sat, 16 Jul 1994 14:28:48 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01650; Sat, 16 Jul 1994 14:28:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21076; Sat, 16 Jul 94 00:28:31 -0400 Date: Sat, 16 Jul 94 00:28:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407160428.AA21076@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov The term "name" is something very much like EIDs but names aren't expected to be known in the transport fabric; i.e. they do not appear in packet headers. Pick a different term. I prefer the RFC-1498 sense of "name"; i.e. a label for an object. IPv4 addresses, EID's, DNS names, etc; they are all "names". If the names aren't used for making routing decisions by intermediate systems there is no problems with having them variable-length. When you say "routign decisions", are you speaking of path selection, or packet forwarding? Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 15:05:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02848; Sat, 16 Jul 1994 15:05:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09670; Sat, 16 Jul 1994 15:05:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09667; Sat, 16 Jul 1994 14:59:03 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00503; Sat, 16 Jul 1994 13:51:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20949; Fri, 15 Jul 94 23:50:55 -0400 Date: Fri, 15 Jul 94 23:50:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407160350.AA20949@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov Killing well-known port numbers will also kill assigned protocol numbers and the associated headache. It would also make the test for the correct connection shorter. Right now we have to check (lport, dport) since if it's a server, there will be many connections with the same lport. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 15:11:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02886; Sat, 16 Jul 1994 15:08:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09687; Sat, 16 Jul 1994 15:08:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09653; Sat, 16 Jul 1994 14:49:21 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02377; Sat, 16 Jul 1994 14:49:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21154; Sat, 16 Jul 94 00:49:11 -0400 Date: Sat, 16 Jul 94 00:49:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407160449.AA21154@ginger.lcs.mit.edu> To: Greg_Minshall@novell.com, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Greg Minshall my basic stand is that no one actually knows what the blank an EID really is, anyway. Well, I do, but I guess there is some lack of universal agreement. :-) Look, an EID identifies a name space. Well, not really (at least not to me). I started off with an RFC-1498 type vision, where you had a name for the *machine* which was different from the names for the interfaces. There are various good reasons for doing this. Then, it was pointed out that I should be naming end-end/fatesharing entities, not machines. That definition has stood from then, but since people seem to have a hard time wrapping their minds around that concept, I started calling them "transport level entity names". This had the feature that a few more people seemed to grasp approximately what was going on, but the bug that people get diverted into thinking about particular transport levels, and the detailed mechanics of demultiplexing. Oh well. Win some, lose some. Anyway, to get back to the point, there are good reasons for having names for the fundamental things you are dealing with. An endpoint is a fundamental thing, and an EID is one kind of name for it. If at the end of parsing an IP address ... IP *then* encounters an EID, then the EID names the name space in which to interpret protocol types. ... If at the end of parsing the IP address, IP encounters a protocol type, and *then* encounters an EID, then the *protocol type* has identified a name space in which the EID has meaning; the EID, in turn, identifies a name space ... in which ports have meaning. If that's all an EID did, you'd be right on target; it would name a name space. But that's just one of the things it does (albeit an inportant thing). It really names something larger, an entire end-end entity, of which the name spaces are just part. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 16:25:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05237; Sat, 16 Jul 1994 16:25:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA09819; Sat, 16 Jul 1994 16:25:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA09803; Sat, 16 Jul 1994 16:24:34 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05218; Sat, 16 Jul 1994 16:24:25 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id CAA02576; Sat, 16 Jul 1994 02:24:21 -0400 Date: Sat, 16 Jul 1994 02:24:21 -0400 From: Vadim Antonov Message-Id: <199407160624.CAA02576@titan.sprintlink.net> To: avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets > The term "name" is something very much like EIDs but names aren't expected > to be known in the transport fabric; i.e. they do not appear in packet > headers. >Pick a different term. I prefer the RFC-1498 sense of "name"; i.e. a label >for an object. IPv4 addresses, EID's, DNS names, etc; they are all "names". I guess we should held an open contest. Entries are accepted until 25th -- then i buy a beer of choice to the winner (in Toronto). :-) > If the names aren't used for making routing decisions by intermediate > systems there is no problems with having them variable-length. >When you say "routign decisions", are you speaking of path selection, or >packet forwarding? Primarily packet forwarding; but i definitely wouldn't like using names in the already overtaxed global routing system. The ideal "name" should not be known to the transport fabric. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 16:59:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03960; Sat, 16 Jul 1994 15:45:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09764; Sat, 16 Jul 1994 15:45:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09759; Sat, 16 Jul 1994 15:44:40 +1000 Precedence: list Received: from uu6.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03929; Sat, 16 Jul 1994 15:44:36 +1000 (from root@isci.com) Received: from isci.com by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA27983 for big-internet@munnari.oz.au; Sat, 16 Jul 94 01:46:15 -0400 Message-Id: <9407160546.AA27983@uu6.psi.com> Date: Sat, 16 Jul 1994 01:38:36 +0000 From: Operator Subject: Re: EID's in the packets To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU, clynn@bbn.com, jdavis@radiomail.net Naming requires a flexible yet consistent id, to add integrity, A Fingerprint.. (isn't this what an EID is?) Can be replicated in a transformed state eg. "hashed". This EID ("...being able to name the whole endpoint with a single name...") Has security implications. Peace, Eric Eric D. Williams Open Systems Technology Inc. OST ewilliams@isci.com or guru@isci.com - Fax +1(202)331-4049 or +1(202)872-0896 1899 L Street NW. Suite 500 - Washington, DC 20036-3804 - Voice +1(202)331-1262 From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 17:02:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03357; Sat, 16 Jul 1994 15:25:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09732; Sat, 16 Jul 1994 15:25:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09695; Sat, 16 Jul 1994 15:09:27 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02647; Sat, 16 Jul 1994 14:58:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21218; Sat, 16 Jul 94 00:58:27 -0400 Date: Sat, 16 Jul 94 00:58:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407160458.AA21218@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, crawdad@munin.fnal.gov Subject: Re: summary of Big-Internet messages Cc: jnc@ginger.lcs.mit.edu I think the proper way to find out identity, given location, is to send a query to the location. This requires that the destination identifier not be a mandatory part of all packets. Either that, or you use an "all IP hosts" multicast identifier with a specific locator, and send an ICMP Send Back ID, or whatever. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 16 21:14:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09277; Sat, 16 Jul 1994 18:45:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA09945; Sat, 16 Jul 1994 18:45:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA09931; Sat, 16 Jul 1994 18:30:03 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08664; Sat, 16 Jul 1994 18:26:37 +1000 (from kre@munnari.OZ.AU) To: Greg Minshall Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Thu, 14 Jul 1994 07:25:20 PDT." <9407141425.AB12388@WC.Novell.COM> Date: Sat, 16 Jul 1994 18:26:34 +1000 Message-Id: <28363.774347194@munnari.OZ.AU> From: Robert Elz Date: Thu, 14 Jul 94 07:25:20 PDT From: Greg Minshall Message-ID: <9407141425.AB12388@WC.Novell.COM> [me...] >If we do that we can (not easily, but feasibly) connect together >regions of old and new net layer technology, allowing transport >to flow from one to the other without grief. Could you say more on this? Probably... Could you, for example, explain how, aside from either a mapping table or a simple injection, you would connect together the old and new net layer? No. A mapping table may be exactly how its done, as I said, not easy, but feasible. Please don't expect the EID concept to be a complete ready made solution to any particular problem, its not. EIDs don't solve mobility, they don't solve security, they don't solve resource management, they don't solve upgrading the net protocol. What they are is an extremely useful building block that has (sometimes small, sometimes larger) impacts on very many areas. To me that indicates that its something worth having, it doesn't have to be a solution for any particular real world problem in itself. If that was the criteria, we would not want IP, IP solves nothing by itself, it needs higher level protocols, then applications, to actually be useful for anything. EIDs are a similar basic building block - they can be used to assist in solving many other problems. Those problems still need to be solved however, adding an EID to the pot and stiring doesn't create the solution via magic. Why aren't we doing *that* today for IPv4? We almost could, if only the EID concept was adopted. Unfortunately both current proposals with real implementations that people can play with chose not to use EIDs. The aim here is to get transport level connectivity (connections for TYCP, just datagram delivery for UDP) between end sites. Network connectivity is just a tool to make that happen. If we were to assume that IPng contendor X (any of them) used EIDs, and that the EID space is defined as including the IPv4 allocated addresses with zero padding, then IPv4 and IPngX users (both using native mode) should be able to communicate. An IPv4 packet arriving at a gateway between the two worlds can have its IPv4 header stripped, with the addresses retained to use as EIDs, and an IPngX header constructed. The IPngX addresses might come from looking up a directory using the EID (formed from the IPv4 addr and zeroes). When the packet arrives at the IPngX host the IPngX header is discarded (nothing new in this), the transport endpoints and pseudo-header checksum are done using the EIDs - the zero padding makes the IPv4 pseudo header checksum evaluate to the same value. In the other direction, an IPngX packet arrives at a gateway, has its IPngX header stripped, and an IPv4 header constructed. The addresses for IPv4 are easy they can be taken directly out of the EIDs. Yes, this means that only IPngX hosts with IPv4 based EIDs can communicate - using EIDs doesn't magically make the IPv4 address space get larger, its that that is the limiting factor. However the real benefit isn't for transitioning from IPv4, its for allowing IPngX and IPngY to interoperate when we need something new in the future. The mechanism is similar, except that all the transport stuff is using EIDs for identification and checksum purposes. We assume the EID space is a constant across all IPng implementations, and we architect it now to be big enough that it will never run out - it contains no topological info, so can be allocated very densely. Addressing from one domain to the other can be handled by looking up the EID in each domain's EID->address directory. This can work - it might not be ideal, but it would allow pockets (at least) of IPngY to be developed, and IPngZ... and run in native mode to test their capabilities, see how well they perform, before being deployed if they look good. If we had a "router desired option" option in IPng we may even get throughput reasonably effecient - that would be an option added to packets by the gateway as it translated from one protocol to the other, and would simply be returned to the gateway (to any gateway) by the host. In this particular case it would contain the information needed to build the IPngY header on packets sent from IPngX hosts and vice versa. With this, the gateway would only need to go through the slow directory lookup path (even using a local cache of recent lookups) on the first packet of a dialogue (including UDP exchanges). The host would need to know nothing of the format of the internals of the option, this would be by agreement amongst the IPngX<->IPngY gateways. Note this option wouldn't be added (in this case anyway) to packets on the fly, only where format conversion was happening anyway, however there may be other applications where the ability of a router to send data to the destination host to be returned again in packets tracing the reverse path may be useful, so I wouldn't rule that out. (In particular, in your mind, how do you prevent *old net layer* machines from being precluded from talking to some growing subset of *new net layer* machines?) This is only an issue where the name space of one protocol is different from the other - the idea with EIDs would be that all IPng protocols in the future would adopt the same namespace. Frankly, I'm getting very tired with two forms of arguments against EIDs - one is the "if it doesn't perform magic its no good" argument, the other "I can solve my particular problem without EIDs, so they're useless". Both of those are so unbelievably bogus its a wonder to me that anyone would ever bother to make them. On the other hand, if you can argue that EIDs make some particular problem harder, that is worth putting. I've heard just two arguments along those lines - one relates to the extra namespace to be managed, and yes, that certainly is more work. Personally I treat the EID namespace as being the outgrowth of the IPv4 namespace, the new namespace is going to be the new form of topologically sensitive names (locators, addresses, selectors, whatever they are) that we know we have to have. Those need a new assignment structure, as well as the ability to be reallocated quickly, effeciently, and automatically. If they can be renumbered automatically, then they should be able to be assigned automatically as well, so this wouldn't really be a new namespace to manage (in the sense of requiring some human effort, costs, etc), and overall we'd be no worse off than we are now - probably better, as with less semantics, EIDs would be easier to assign. The second relates to security, if only EIDs are used for identification we have even less ability to trust what the net is telling us than we do now (which isn't much). This one could be solved short term by temporarily giving up some of the flexibility, and bonding IPng locators (whatever) to EIDs and checking they match what we have seen before, which returns us to our current pathetic security level. Long term we need real security, for which EIDs may provide a nice stable identity field, but which EIDs don't magically solve... kre From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 00:09:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13364; Sat, 16 Jul 1994 21:25:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA10119; Sat, 16 Jul 1994 21:25:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA10103; Sat, 16 Jul 1994 21:14:50 +1000 Precedence: list Received: from chsun.eunet.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12590; Sat, 16 Jul 1994 20:44:33 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id MAA22995; Sat, 16 Jul 1994 12:48:54 +0200 Message-Id: <199407161048.MAA22995@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <09998-0@magnolia.eunet.ch>; Sat, 16 Jul 1994 12:42:56 +0200 Subject: Re: EID's in the packets To: paul@vix.com (Paul A Vixie) Date: Sat, 16 Jul 1994 12:42:54 +0200 (MET DST) Cc: big-Internet@munnari.OZ.AU In-Reply-To: from "Paul A Vixie" at Jul 15, 94 02:36:22 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1541 From: Simon Poole Sender: poole@magnolia.eunet.ch > > Checking in again from the home for recalcitrant implementors... > > | Well, it *is* the case when the old historical crud makes us to make the IP > | level deliberately worse. It is like that -- get away from well-known > | ports and you no longer need EIDs ==> significantly smaller IP headers with > | different layout. > > Actually I'm expecting larger IP headers if we include full endpoint info, > since we will have to include what the "port number" does now. However, the > UDP and TCP equivilents in the IPng world could have _smaller_ headers since > they would get more endpoint info from IPng than they get from IP now. Isn't this the point where the current discussion is getting very sidetracked? Aren't EID's a feature useful for the transport layer, for TCPng and UDPng? That are -not- being designed right now? Not to say that we shouldn't be giving some thought to useful features in the network layer for future transport protocols, but IPng with all probabillty will mainly be a protocol for the transport of the -current- TCP. I do think that EID's might be a useful concept for TCPng and UDPng, however I believe this is a discussion that can be defered to -later-. Which at the same time means that I vote for making the IPng addresses/locators or what ever -independent- of any EID notion (8 bytes EID's would seem to be to small in any case). -- EUnet Switzerland Simon Poole Zweierstrasse 35 Tel: +41 1 291 45 80 poole@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=poole;P=EUnet;A=EUnet;C=CH From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 00:16:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17072; Sat, 16 Jul 1994 23:45:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA10258; Sat, 16 Jul 1994 23:45:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA10243; Sat, 16 Jul 1994 23:42:36 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17011; Sat, 16 Jul 1994 23:42:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25781; Sat, 16 Jul 94 09:42:16 -0400 Date: Sat, 16 Jul 94 09:42:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407161342.AA25781@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, poole@magnolia.eunet.ch Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Simon Poole Aren't EID's a feature useful for the transport layer, for TCPng and UDPng? ... I do think that EID's might be a useful concept for TCPng and UDPng, however I believe this is a discussion that can be defered to -later-. Well, the bug with this thought is that one of the reasons to have a name for the end-end entity which is topolgically invariant (such as an EID) is to provide a constant name for mobile applications. I note that mobility support is currently being worked on at the internetwork layer, in part, perhaps, because people don't want to change the current TCP. Plus to which, if you do decide you need an invariant name below the transport layer, so they all share the same one, it'll be too late to add it later. Noel From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 00:16:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17195; Sat, 16 Jul 1994 23:49:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA10277; Sat, 16 Jul 1994 23:49:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA10229; Sat, 16 Jul 1994 23:31:25 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16780; Sat, 16 Jul 1994 23:31:10 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id JAA06560; Sat, 16 Jul 1994 09:30:49 -0400 From: Howard Berkowitz Message-Id: <199407161330.JAA06560@clark.net> Subject: Re: EID's in the packets To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sat, 16 Jul 1994 09:30:49 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, clynn@BBN.COM, jnc@ginger.lcs.mit.edu In-Reply-To: <9407160406.AA20996@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 16, 94 00:06:28 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1653 > One aspect which isn't being thought about here is "what uses do we have for > being able to name the whole endpoint with a single name". I'm too burned > out to think that through; maybe someone has some ideas. > > Noel > In network operations, having a name for the endpoint as a whole is extremely useful in error messages, etc. Assume a multiported host of some sort. The message "Port 1 of The Critical Node is down" is an annoyance, while the message "The Critical Node is down. It is an ex-node. It is pushing up daisies in the graveyard...." indicates a crisis. I'm not sure, Noel, if this "single name" truly applies to a single platform, or it could apply to a set of interfaces that form a cluster providing some application service. If the latter, then the status of the global name is the status of availability of the service. Some people will suggest that what I am talking about could be described by a single management interface, port, whatever, on the endpoint. I don't think so, because that doesn't give me the appropriate management point for a distributed or multiported service. Another issue is that if the interface level uses some sort of hardware-level autoconfiguration (e.g., MAC address), the whole-endpoint-name is the invariant if there are hardware changes. IMHO, there is a value to having a "box-level" invariant if one is doing ES-IS style autoconfiguration, since ES-IS style lets me locate interfaces relative to a higher-level network address construct, but not the box that containst the interfaces. Howard PS--It just occurred to me--will we test network reachability of IPng with pingng? From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 00:55:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19290; Sun, 17 Jul 1994 00:45:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA10530; Sun, 17 Jul 1994 00:45:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA10514; Sun, 17 Jul 1994 00:39:32 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19087; Sun, 17 Jul 1994 00:39:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25923; Sat, 16 Jul 94 10:39:00 -0400 Date: Sat, 16 Jul 94 10:39:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407161439.AA25923@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: What are we goign to use "addresses" for anyway? Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov > If the ["names"] aren't used for making routing decisions by intermediate > systems there is no problems with having them variable-length. > When you say "routign decisions", are you speaking of path selection, or > packet forwarding? Primarily packet forwarding; but i definitely wouldn't like using ["names"] in the already overtaxed global routing system. This has tickled another thought I've been having. There is all this tremendous fight over whether "addresses" should be fixed or variable length, with one of the big arguments against variable being that it's claimed to be more inefficient to forward packets if you have to look at a variable length "address". The assumption here is that path selection, and forwarding, in the network is going to look basiclly the same in the future as it has in the past. I think this is a badly wrong assumption. In IPv4, the destination address is the principle input to the path selection algorithm. This algorithm operates (effectively) on every hop independently, and looks at a *very* carefully synchronized and consistent set of databases. In other words, the address in the packet is the data item which identifies the path for the packet. This model does not appear to be where routing is going down the line. Rather, the path selection algorithm willi ncreasingly operate on many more inputs, and will increasingly not be done on a hop by hop basis. A while back, there was a thread where it was stated, in part, that: From: estrin@usc.edu (Deborah Estrin) Source routing is needed for other services related to ToS and finding routes that can grant reservation requests...THESE are the dominant demand drivers longer term...in my opinion of course... I agree with this prediction (although I think that provider selection type issues will also be a big driver). The implication is clear. The "address", by itself, will increasingly not be the the single input to the path selection, and that selection algorithm will be run more and more in a unitary, not distributed, way. Having the address in the packets isn't going to be very useful. What the packets really need in them is something to identify the path, not just *part* of the input to the path selection. This happens to fit together nicely with the painful corner reality is pushing us into, which is that a hierarchical address in a real, large, de-centralized network is inherently and fundamentally a variable length item. You can try and struggle to work with these addresses in a way that looks like the old way of doing business, or you can see if there's some alternative way to proceed. The above point provides a perfect out. The address isn't *really* what you want in the packet anyway; you want something that identifies the path. That you can make nice and *short* and fixed length. I'm sure I needn't remind everyone that a 16-byte IPng address is little short of the maximum length NSAP, a length that used to be derided as hopelessly long. Clearly, this is a fundamental change, a scary thing. Also, not all traffic will want to use this path-selection mechanism, and will want to keep the address in the packet, as opposed to a path identifier. However, the more traffic that uses this new mechanism, the less the *overall* cost of variable-length addresses for packets that do retain the address. We live with variable length DNS nanes because only very few packets carry them.... Addresses are just data used by the routing and forwarding. Unless we understand what they want to see in addresses going down the line, all our arguments about what ought to be in addresses, and what they should look like, are pretty much a waste of time. Assuming that the future will look exactly like the past in these areas is probably the worst possible assumption to make, as it often is. Noel From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 03:25:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23664; Sun, 17 Jul 1994 03:25:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA10683; Sun, 17 Jul 1994 03:25:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA10669; Sun, 17 Jul 1994 03:12:11 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22316; Sun, 17 Jul 1994 02:40:09 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id MAA03645; Sat, 16 Jul 1994 12:39:59 -0400 Date: Sat, 16 Jul 1994 12:39:59 -0400 From: Vadim Antonov Message-Id: <199407161639.MAA03645@titan.sprintlink.net> To: Greg_Minshall@Novell.COM, kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU >Please don't expect the EID concept to be a complete ready >made solution to any particular problem, its not. EIDs don't >solve mobility, they don't solve security, they don't solve >resource management, they don't solve upgrading the net protocol. ...and in fact do evetything more complicated. Bzzt. Thank you for playing. >We almost could, if only the EID concept was adopted. "Almost?" Like OSI crowd -- they almost got it working. *Nobody* needs almost flying airplanes. >Unfortunately both current proposals with real implementations >that people can play with chose not to use EIDs. Or fortunately. Depends on point of view. >Frankly, I'm getting very tired with two forms of arguments >against EIDs - one is the "if it doesn't perform magic its >no good" argument, the other "I can solve my particular problem >without EIDs, so they're useless". Dunno whose opinion you misinterpreted as the fisrt, *my* opinion was that "i can solve *any* problem without EIDs with no loss of efficiency, so they're useless" or to put it differently "there is no problem which cannot be solved without EIDs". So far, nobody told me that i'm wrong by giving an example. >Both of those are so >unbelievably bogus its a wonder to me that anyone would ever >bother to make them. Deliberate twising of people's positions is so unbelievably bogus its a wonder to me that anyone would ever bother to use it as an argument in discussion. >On the other hand, if you can argue that EIDs make some >particular problem harder, that is worth putting. They take at least 12 bytes in headers. Isn't it enough? >I've heard just two arguments along those lines - one relates >to the extra namespace to be managed, and yes, that certainly >is more work. It is enough for me to be opposed to it. Try to run a real network someday -- where existing registration crap is requiring several people full-time to handle. >Those need a new assignment structure... More forms to file, then government will decide to take care of it to prevent people from gobbling enormous blocks -- and then we'll end up with the same bullshit as we have now with IP when i have to call Postel to get the space i need. Just say NO. Eevry allocation which is not completely automatic is evil. And if you do completely automatic allocation you may always do it in the topologically meaningful way -- i.e. to make "EIDs" equivalent to locators. >The second relates to security, if only EIDs are used for >identification we have even less ability to trust what the >net is telling us than we do now (which isn't much). Sure, yeah, as if it wasn't obvious from the very beginning that any information in incoming packets can be forged. If you can take this as an argument cons EIDs you got real low opinion of mental abilities of your opponents, don't you? Want another argument? EIDs are violating privacy. If you base EIDs on hardware MAC addresses you then can always track movements of the particular box -- i personally don't want the entire Internet to know that i sold that particular box of mine to Joe Random. If you do dynamic assignment of EIDs we're back to square 1 -- for that problem is as hard algorithmically as dynamic binding of DNS names to transport addresses. --vadim From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 04:45:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25977; Sun, 17 Jul 1994 04:45:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA10770; Sun, 17 Jul 1994 04:45:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA10756; Sun, 17 Jul 1994 04:38:27 +1000 Precedence: list Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB25625; Sun, 17 Jul 1994 04:38:12 +1000 (from kre) Date: Sun, 17 Jul 1994 04:38:12 +1000 From: Robert Elz Message-Id: <9407161838.25625@munnari.oz.au> To: Greg_Minshall@Novell.COM, avg@sprint.net Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU Date: Sat, 16 Jul 1994 12:39:59 -0400 From: Vadim Antonov Message-Id: <199407161639.MAA03645@titan.sprintlink.net> *my* opinion was that "i can solve *any* problem without EIDs with no loss of efficiency, so they're useless" or to put it differently "there is no problem which cannot be solved without EIDs". So far, nobody told me that i'm wrong by giving an example. OK, how do I make a transport connection that spans multiple different network layers, with radically different addressing & forwarding structure? (Say IPv4, Nimrod, original PIP, SIPP, and TUBA. Maybe even raw X.25 (CONS)) It has to work with current TCP - that is, without any more changes than are required by a switch to IPng, as we know we're not getting radically new TCP technology anytime soon, and quite possibly never - but even if we do, cuirrent TCP will remain around for a very long time. kre From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 04:48:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26045; Sun, 17 Jul 1994 04:48:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA10787; Sun, 17 Jul 1994 04:47:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA10753; Sun, 17 Jul 1994 04:31:53 +1000 Precedence: list Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25486; Sun, 17 Jul 1994 04:31:40 +1000 (from kre) Date: Sun, 17 Jul 1994 04:31:40 +1000 From: Robert Elz Message-Id: <9407161831.25486@munnari.oz.au> To: Greg_Minshall@Novell.COM, avg@sprint.net Subject: Globally visible MAC addreses Cc: big-internet@munnari.OZ.AU I have changed the Subject: on this response as this is a new thread... Date: Sat, 16 Jul 1994 12:39:59 -0400 From: Vadim Antonov Message-Id: <199407161639.MAA03645@titan.sprintlink.net> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Want another argument? EIDs are violating privacy. If you base EIDs on hardware MAC addresses you then can always track movements of the particular box -- I came to my terminal right now to say something quite like this, though not identical - decided to glance at pending mail before I did, and saw this ... My entire message was going to be ... Has anyone considered that globally visible MAC addresses are really no different than globally visible HINFO records (with some more, some less detail) that many people choose to refuse to use? To that now I will add that I have absolutely never wanted to use MAC addresses for anything other than delivering packets to the correct MAC station, they should be visible on the appropriate wire, and no place else at all. I most certainly do not want to see them in EIDs. Any autocomfig strategy (for addresses, EIDs, anything) that is based upon appending the MAC address to some local constant is going to have to deal with this problem somehow. kre From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 05:25:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26806; Sun, 17 Jul 1994 05:25:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA10846; Sun, 17 Jul 1994 05:25:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA10830; Sun, 17 Jul 1994 05:14:30 +1000 Precedence: list Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26508; Sun, 17 Jul 1994 05:14:06 +1000 (from kre) Date: Sun, 17 Jul 1994 05:14:06 +1000 From: Robert Elz Message-Id: <9407161914.26508@munnari.oz.au> To: Greg_Minshall@Novell.COM, avg@sprint.net Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU Date: Sat, 16 Jul 1994 12:39:59 -0400 From: Vadim Antonov Message-Id: <199407161639.MAA03645@titan.sprintlink.net> I just can't force myself to stop replying to this message... I have tried, and failed, to touch on just the most blatant bits. Oh well... >Please don't expect the EID concept to be a complete ready >made solution to any particular problem, ...and in fact do evetything more complicated. Not at all, a fixed, unchanging identifier makes most things simpler. Even (most of) the EID opponents admit that, they're just not convinced that this simplification is worth the costs imposed. In isolated cases they're probably right, the problem is that people are multiplying the cost of EIDs by the number of problems they simplify. If EIDs were to be a help to mobility alone then offsetting the costs of EIDs against the benefits would be valid. But EIDs have lots of other potential, you can't offset the full cost against every one of them. On overall balance, with all the (smallish) benefits that EIDs bring, the costs of EIDs to me at least seem worth the investment. >On the other hand, if you can argue that EIDs make some >particular problem harder, that is worth putting. They take at least 12 bytes in headers. Isn't it enough? No. It looks as if addresses are going to be 16 bytes. That's 32 bytes of header space. No-one has been able to show me anything that can't be solved without the source address - assuming we have EIDs. Take away one 16 byte source address, and substitute an 8 byte source EID, and an 8 byte destination EID, and I think (if my arithmetic is correct) that we're all square. Not having a source address would require EIDs in every packet. On the other hand if we want to keep the source addr for sentimental reasons, then it might be possible to avoid sticking the EID inside every packet. Try to run a real network someday -- where existing registration crap is requiring several people full-time to handle. This is (yet another) example of overreacting to the problems of today by outlawing whatever seems to be the cause problem without looking deeper. Certainly today's IP registration stuff is absurdly tedious - and you've probably noticed that its been getting more tedious. This has something to do with address space depletion. Its complicated by the need to allocate sane addresses that CIDRise well, which makes them even more complex. Getting an IPv4 address (of whatever size was needed) used to be very simple, allocating EID spaces can be even simpler (and should be able to be handled by automated servers that a process on your system would connect to, no need for human involvement at all for net connected sites). More forms to file, Not necessarily at all. This is scare mongering. then government will decide to take care of it to prevent people from gobbling enormous blocks But with EIDs there is no reason for anyone to want an enormous block. Anyone at all. There's absolutely nothing to be gained from consecutive EIDs for a group of systems (and as your "privacy" comment indicates, that I replied to in another message, with a different Subject for those who want to go looking, lots of reasons to avoid any such scheme). EIDs can be allocated by automated servers, in small blocks, that you can request (from your local assignment process) as often as is required with no bureaucracy. And if you do completely automatic allocation you may always do it in the topologically meaningful way -- i.e. to make "EIDs" equivalent to locators. Of course you could do it that way, except that you smultaneously throw away one of the most important advantages of EIDs, and make their assignment process much more complex - then huge blocks would be wanted, and that is likely to provoke bureaucratic responses. Sure, yeah, as if it wasn't obvious from the very beginning that any information in incoming packets can be forged. Incoming information can, certainly, but if the accuracy of that information is a requirement for the incoming information to be useful, as it is with the IPv4 source address (if I can't reply I can't get a connection, and there's not a lot of harm, other than denial of service stuff, that can be done). If you can take this as an argument cons EIDs you got real low opinion of mental abilities of your opponents, don't you? This argument has been made, almost exactly as I put it, and its the BEST argument against the use of EIDs I have heard. Its certainly the only one that has caused me to sit back and think about this a bit. Its certainly true that we need real security, not this botched stuff, but we don't have real security yet. We need some way to fill the gap until real security appears, we certainly can't afford to make things even more open than they are now. kre From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 09:25:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03230; Sun, 17 Jul 1994 09:25:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA11063; Sun, 17 Jul 1994 09:25:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA11029; Sun, 17 Jul 1994 09:09:31 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28225; Sun, 17 Jul 1994 06:12:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26400; Sat, 16 Jul 94 16:11:50 -0400 Date: Sat, 16 Jul 94 16:11:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407162011.AA26400@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov *my* opinion was that "i can solve *any* problem without EIDs with no loss of efficiency, so they're useless" or to put it differently "there is no problem which cannot be solved without EIDs". So what? The only gate you really need to build any logic circuit is a NAND gate. Doesn't mean there isn't a use for other gates, in providing clearer simpler circuitry. Same thing for Turing machines; I don't see to many commerical chips with that minimal instruction set. You may theoretically be able to do anything, perhaps painfully, without a transport name. However, you can do many things in a simpler, clearer, more robust way with an invariant name for transport entities. > On the other hand, if you can argue that EIDs make some > particular problem harder, that is worth putting. They take at least 12 bytes in headers. Isn't it enough? That's not an argument, that's a statement of part of the costs. You have to figure out how to quantify what you get for that cost, and see if it's worth it. Since this is an inherently subjective process, and you've already made up your mind that EID's are a bad idea, I have no doubt that your answer to that will come out "no". if you do completely automatic allocation you may always do it in the topologically meaningful way -- i.e. to make "EIDs" equivalent to locators. The whole point of EID's is that they *aren't* topologically meaningful, for a variety of reasons I won't belabor. (E.g. multi-interfaced hosts mean there is no such thing as a single topologically meaningful name for a transport entity.). The IPv4 address *already* is a topologically sensitive name for transport entities, and the problems of that approach are well known. Noel From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 09:30:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03329; Sun, 17 Jul 1994 09:30:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA11080; Sun, 17 Jul 1994 09:30:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA11043; Sun, 17 Jul 1994 09:10:34 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29738; Sun, 17 Jul 1994 07:04:01 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id RAA04118; Sat, 16 Jul 1994 17:03:55 -0400 Date: Sat, 16 Jul 1994 17:03:55 -0400 From: Vadim Antonov Message-Id: <199407162103.RAA04118@titan.sprintlink.net> To: Greg_Minshall@Novell.COM, avg@sprint.net, kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU > *my* opinion was that "i can solve *any* problem without EIDs with no > loss of efficiency, so they're useless" or to put it differently > "there is no problem which cannot be solved without EIDs". > So far, nobody told me that i'm wrong by giving an example. >OK, how do I make a transport connection that spans multiple different >network layers, with radically different addressing & forwarding structure? >(Say IPv4, Nimrod, original PIP, SIPP, and TUBA. Maybe even raw X.25 (CONS)) All those architectures have transport-level addresses (locators) which are bit strings. As such they're sufficient to deliver data to the destination. Where do you see the necessity of EIDs? I'm not aware of network architectures *not* using locators. And then, i had an impression that we're talking about IPng, not X.25ng. >It has to work with current TCP - that is, without any more changes than >are required by a switch to IPng, as we know we're not getting radically new >TCP technology anytime soon, and quite possibly never - but even if we do, >cuirrent TCP will remain around for a very long time. Nobody talks about radically new anything. You *HAVE* to change TCP specs just to accomodate different headers -- for example algorithms for checksums have to be changed to include building pseudo-headers. So far, there is no evidence that EIDs are necessary to preserve TCP "unchanged". And then, i do not understand what the buzz is about -- an IPng-capable software is NEW software anyway so making minor cleanups in TCP is *free* -- you have to upgrade software on all machines anyway. The only rationale i've heard (in private communications) for not doing that is that "it is out of scope of the IPng group chapter". How compelling; are all engineers in the world decided to become lawyers or is it a particluarly American development? --vadim From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 09:33:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03547; Sun, 17 Jul 1994 09:33:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA11099; Sun, 17 Jul 1994 09:33:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA11049; Sun, 17 Jul 1994 09:13:29 +1000 Precedence: list Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00697; Sun, 17 Jul 1994 07:44:35 +1000 (from hcb@clark.net) Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id RAA02904; Sat, 16 Jul 1994 17:44:29 -0400 From: Howard Berkowitz Message-Id: <199407162144.RAA02904@clark.net> Subject: Re: Globally visible MAC addreses To: kre@munnari.OZ.AU (Robert Elz) Date: Sat, 16 Jul 1994 17:44:29 -0400 (EDT) Cc: Greg_Minshall@Novell.COM, avg@sprint.net, big-internet@munnari.OZ.AU In-Reply-To: <9407161831.25486@munnari.oz.au> from "Robert Elz" at Jul 17, 94 04:31:40 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2776 > > I have changed the Subject: on this response as this is a new thread... Whoa, everyone. Real world operations intrude here. We have been making the assumption that a MAC address is invariant, which is not a reasonable assumption in a multiprotocol world. Yes, if the U/L bit of a MAC address is set to global, one should expect that it will be unique, but this is not necessarily true. If that bit is set to show the address is locally administered, then is that MAC address ineligible to be use as an EID? Some MAC issues to address: 1. XNS copies the MAC address of a first router LAN interface to all other interfaces. If that first address is global, it still will appear on each router interface. 2. DECnet manipulates the MAC address to reflect the DECnet area/node network layer address. 3. MAC addresses get duplicated because someone fouls up entering what _should_ be an unique address in the ROM, or in jumpers/ DIP switches. 4. Especially in token ring, source bridge environments, it is quite common for users to use local administration so the address reflects the ring topology. 5. Other users will assign a MAC address so they have an invariant PING target in cases where other protocols modify MAC addresses. 6. Several workgroup protocols allow PC-level users to set their own MAC address. There are other real world considerations here; these are the ones that my typing fingers can quickly think of. > > Want another argument? > > EIDs are violating privacy. If you base EIDs on hardware MAC addresses > you then can always track movements of the particular box -- So locally administer them. Then deal with local administration issues. > > I came to my terminal right now to say something quite like this, though > not identical - decided to glance at pending mail before I did, and saw > this ... > > My entire message was going to be ... > > Has anyone considered that globally visible MAC addresses > are really no different than globally visible HINFO records > (with some more, some less detail) that many people choose > to refuse to use? > > To that now I will add that I have absolutely never wanted to use MAC > addresses for anything other than delivering packets to the correct MAC > station, they should be visible on the appropriate wire, and no place > else at all. I most certainly do not want to see them in EIDs. > > Any autocomfig strategy (for addresses, EIDs, anything) that is based upon > appending the MAC address to some local constant is going to have to deal > with this problem somehow. I understand kre is not proposing use of MAC addresses. Others should remember they are not as trustworthy as they might seem. Howard From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 09:36:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03606; Sun, 17 Jul 1994 09:36:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA11116; Sun, 17 Jul 1994 09:36:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA11046; Sun, 17 Jul 1994 09:11:39 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00154; Sun, 17 Jul 1994 07:28:46 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id RAA04170; Sat, 16 Jul 1994 17:28:41 -0400 Date: Sat, 16 Jul 1994 17:28:41 -0400 From: Vadim Antonov Message-Id: <199407162128.RAA04170@titan.sprintlink.net> To: Greg_Minshall@Novell.COM, avg@sprint.net, kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: big-internet@munnari.OZ.AU >Not at all, a fixed, unchanging identifier makes most things simpler. >Even (most of) the EID opponents admit that, they're just not convinced >that this simplification is worth the costs imposed. Sorry, i do not "admit" that additional entity makes thing simplier. The only example of "necessity" of EIDs was provided by Noel (thanks) and i think i managed to present an alternative scheme which is not more complicated or inefficient and has quite a few side advantages. >In isolated cases they're probably right, the problem is that people are >multiplying the cost of EIDs by the number of problems they simplify. Then please stop religious rants and give an example of a "not isolated" case. >But EIDs have lots of other >potential, you can't offset the full cost against every one of them. Other potential? What exactly? >On overall balance, with all the (smallish) benefits that EIDs bring, >the costs of EIDs to me at least seem worth the investment. 30% of header size and quite a lot of overhead on CPU side of things. Plus allocation bureaucracy. Thanks, i will need a really compelling reason to sign up for that. >Take away one 16 byte source address, and substitute an 8 byte source >EID, and an 8 byte destination EID, and I think (if my arithmetic is correct) >that we're all square. Not having a source address would require EIDs in >every packet. That's plain old header compression. Works well until you need to switch something at 100Mbps. >On the other hand if we want to keep the source addr for sentimental >reasons, then it might be possible to avoid sticking the EID inside >every packet. The necessity to keep the source address is also somehow unclear but i can find at least few reasons why i would like to have source addresses in regular data packets, though killing fixed port numbers will allow to avoid that in many cases as well (i think that's obvious why). >This is (yet another) example of overreacting to the problems of today >by outlawing whatever seems to be the cause problem without looking deeper. Deeper where? Any additional allocation system complicates the network. Since there are no proven advantages in having it i fail to understand the desire to keep with the not-exactly-good idea. >But with EIDs there is no reason for anyone to want an enormous block. There is no reason for anyone to go out in the street and start killing innocent bystanders. So what? There are companies who got class As only for "prestige" of having it. > And if you do completely automatic allocation you may always > do it in the topologically meaningful way -- i.e. to make > "EIDs" equivalent to locators. >Of course you could do it that way, except that you smultaneously throw >away one of the most important advantages of EIDs, and make their assignment >process much more complex - then huge blocks would be wanted, and that is >likely to provoke bureaucratic responses. What huge blocks if we talk about *automatic* allocation? You agreed that manual allocation is evil; you also seem to agree that in case of automatic allocation EIDs can be made isomorphous to locators. Now why do you wahnt to include identical information into the headers TWICE? [Using EIDs for authentication] >This argument has been made, almost exactly as I put it, and its the BEST >argument against the use of EIDs I have heard. Sorry, i didn't meant to insult you. --vadim From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 17:25:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15665; Sun, 17 Jul 1994 17:25:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA11531; Sun, 17 Jul 1994 17:25:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA11515; Sun, 17 Jul 1994 17:13:18 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15353; Sun, 17 Jul 1994 17:13:11 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 17 Jul 94 16:05:44 +0900 From: Masataka Ohta Message-Id: <9407170705.AA00233@necom830.cc.titech.ac.jp> Subject: Re: summary of Big-Internet messages To: crawdad@munin.fnal.gov (Matt Crawford) Date: Sun, 17 Jul 94 16:05:43 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407152119.AA21244@munin.fnal.gov>; from "Matt Crawford" at Jul 15, 94 4:19 pm X-Mailer: ELM [version 2.3 PL11] > > It should be noted that looking up domain name from "locator" just does > > not work, as DNS update, even the most dynamic one, can not be assured to > > be so fast. > > Agreed. I think the proper way to find out identity, given location, > is to send a query to the location. 1: And you will receive another query asking your identity. Goto 1). BTW. Locators are not assured to be reversible. Most UDP users don't want to have extra exchanges of packkets for any reason. > This requires that the > destination identifier not be a mandatory part of all packets. It will be useful to locate a destination within a subnet. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 18:12:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16160; Sun, 17 Jul 1994 17:45:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA11563; Sun, 17 Jul 1994 17:45:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA11547; Sun, 17 Jul 1994 17:37:56 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15928; Sun, 17 Jul 1994 17:37:42 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 17 Jul 94 16:31:06 +0900 From: Masataka Ohta Message-Id: <9407170731.AA00320@necom830.cc.titech.ac.jp> Subject: Constructive Proof on why 8 byte EID is enough To: big-internet@munnari.OZ.AU Date: Sun, 17 Jul 94 16:31:05 JST X-Mailer: ELM [version 2.3 PL11] Let me construct an EID assignment mechanism to constructively proof that 8 bytes are more than enough for EID. The assumption is that EID is location independent and does not need locational hierarchy. We need hierarchy in EID to delegate EID assignment job to large organizations. NICs, somehow, should be able to handle EID assignmnet job for individuals. Even if all the large organization in the world is assembled together, they are only as large as all the individuals in the world. The amount of EID needed by all the large organization in the world is only as many as the amount of EID needed by all the individuals in the world, possibly with a small constant factor diffrence. NICs should be able to handle EID assignmnet job for large organazations. NICs do not have to delegate EID assignment. Then, the mechanism is: 1) Upper 4 bytes of EID is managed by Internic to national NICs with 100% utilization. Thus, 2^32 (nearly the world's population) EIDs are assigned with 100% efficiency. 2) The next 2 bytes of EID is managed by national NICs with 100% utilization. A national NIC may use a single byte to make sub-delegation, if it thinks the sub-deligatee use the space efficiently. So far, 2^48 EIDs are assigned with nearly 100% efficiency, which almost satisfies 10^15 requirements which already contained a lot of safety factors. So, we don't need more efficiency. Now, 3) The last 2 bytes is managed by individual applicants freely, which may or may not efficient. A single byte may be used for sub-delegation. A large company having a lot of equipments or a branch of it may apply for a lot of EID sub-spaces, of course. But, no delegation is necessary. Are there any flaw in the proof? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 18:25:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17292; Sun, 17 Jul 1994 18:25:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA11623; Sun, 17 Jul 1994 18:25:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA11604; Sun, 17 Jul 1994 18:14:18 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16106; Sun, 17 Jul 1994 17:43:19 +1000 (from kre@munnari.OZ.AU) To: Vadim Antonov Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Sat, 16 Jul 1994 17:28:41 -0400." <199407162128.RAA04170@titan.sprintlink.net> Date: Sun, 17 Jul 1994 17:43:15 +1000 Message-Id: <28430.774430995@munnari.OZ.AU> From: Robert Elz Date: Sat, 16 Jul 1994 17:28:41 -0400 From: Vadim Antonov Message-ID: <199407162128.RAA04170@titan.sprintlink.net> >In isolated cases they're probably right, the problem is that people are >multiplying the cost of EIDs by the number of problems they simplify. Then please stop religious rants and give an example of a "not isolated" case. You are misreading what I said - "isolated" means when considered alone, that is, in most cases the cost of using EIDs may not justify using EIDs for that one particular case. However, there are many such cases, add up the benefits from using EIDs in all of those cases and I believe the sum exceeds the cost of adding EIDs (which doesn't increase, which was the point). >Take away one 16 byte source address, and substitute an 8 byte source >EID, and an 8 byte destination EID, and I think (if my arithmetic is correct) >that we're all square. Not having a source address would require EIDs in >every packet. That's plain old header compression. Works well until you need to switch something at 100Mbps. Its not header compression at all, its changing the format of the header so it doesn't contain a source address, ever. >This is (yet another) example of overreacting to the problems of today >by outlawing whatever seems to be the cause problem without looking deeper. Deeper where? Deeper into what is the actual problem, which isn't so much allocation itself, but the complication of the type of thing that's being allocated, which imposes conflicting constraints, which ends up requiring human judgement - that makes it complex and slow. If allocation is no more complex than "ask and ye shall receive" the problem is much more tractable. >But with EIDs there is no reason for anyone to want an enormous block. So what? It means that we don't have to have any concept at all of large blocks, no mechanism to create them, no mechanism to assign them - companies can't get large blocks for the prestige value, as there are simply no large blocks to allocate. >Of course you could do it that way, except that you smultaneously throw >away one of the most important advantages of EIDs, and make their assignment >process much more complex - then huge blocks would be wanted, and that is >likely to provoke bureaucratic responses. What huge blocks if we talk about *automatic* allocation? Identifiers that have topological significance need to allow room for growth, so more systems can be added that are topologically close. Organisations that are likely to grow to have large networks, or who think they might, or even hope they might, will need, with some justification, a large block so all the systems they intend to one day have can be numbered in a topologically sane manner. EIDs have no such constraints, companies that merely hope to grow large can start with just enough EIDs for their current needs, if they do then grow they can simply obtain more from anywhere in the number space. Its also worth noting that this problem with locators is lessened if EIDs exist, as with them automatic renumbering is feasible, as connections don't depend on the locators for identification. Without EIDs, that is, with locators serving to identify connections as in current plans (and IPv4) renumbering automatically is hard - has to be planned for a time when a major disruption is possible. That means it doesn't happen in practice - and managers demand large address spaces so they won't run out and have to renumber. You agreed that manual allocation is evil; I said nothing of the kind - I said that automatic allocation where possible is better. you also seem to agree that in case of automatic allocation EIDs can be made isomorphous to locators. I certainly do not agree to anything even remotely like that. Sorry, i didn't meant to insult you. You didn't, however I suspect that you may have insulted the person who put the argument I quoted... kre From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 19:18:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17423; Sun, 17 Jul 1994 18:30:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA11638; Sun, 17 Jul 1994 18:30:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA11607; Sun, 17 Jul 1994 18:21:19 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17163; Sun, 17 Jul 1994 18:21:06 +1000 (from kre@munnari.OZ.AU) To: Vadim Antonov Cc: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of "Sat, 16 Jul 1994 17:03:55 -0400." <199407162103.RAA04118@titan.sprintlink.net> Date: Sun, 17 Jul 1994 18:21:02 +1000 Message-Id: <28437.774433262@munnari.OZ.AU> From: Robert Elz Date: Sat, 16 Jul 1994 17:03:55 -0400 From: Vadim Antonov Message-ID: <199407162103.RAA04118@titan.sprintlink.net> >OK, how do I make a transport connection that spans multiple different >network layers, with radically different addressing & forwarding structure? >(Say IPv4, Nimrod, original PIP, SIPP, and TUBA. Maybe even raw X.25 (CONS)) All those architectures have transport-level addresses (locators) which are bit strings. As such they're sufficient to deliver data to the destination. Where do you see the necessity of EIDs? You have again not looked at what I said. I wish you'd take a few minutes to read and understand, rather than simply reacting. One more time - the idea is that a connection could be established from Australia, where we might be using IPv4, via the US (which might be using SIPP), to a destination in Europe where TUBA may be the network protocol of choice. (In practice I care more about what comes after IPng than these pre and candidate IPng's, but all that affects is the names). If we're using locators as TCP connection identifiers, and pseudo-header checksum input, then we can't change the locator as the packet moves from network to network can we? We're pretty stuck with what we define now, forever. However if the locator (or selector) is used only to get packets to the destination then at boundary points along the route it can be changed with impunity (which doesn't necessarily mean easily, however it can be done). Nobody talks about radically new anything. You do (your proposal for TCP is certainly that). You *HAVE* to change TCP specs just to accomodate different headers Yes, however all current plans call for the most minimal changes possible to TCP. That basically just means substituting the IPv4 address currently used with something else. The question here is "what else". Personally, as I have said before, I would prefer to delay the IPng process enough to bundle in all the fundamental changes we need to all the basic protocols, and suffer just one upgrade. We have been working on the IP upgrade now for about 2 years, and are probably close to some kind of decision. Beyond that more time will be neaded to finalise things. TCP is more complex than IP, its reasonable to assume that any general review of TCP would take at least another 2 years. I suspect we could afford to take the time to do that. However I also believe that current community consensus is that a delay of this magnitude is simply unacceptable. That means we're not going to have any general TCP changes now, and that means, probably never. We will still be using well known ports (integers), and identifying TCP connections using something provided (somehow) by the network layer. So far, there is no evidence that EIDs are necessary to preserve TCP "unchanged". No, of course not, in fact there's plenty of evidence exactly to the contrary, anyone who suggested otherwise would be deluding themselves. One thing EIDs do is add stability to TCP, they insulate it from future changes to the network layer, and especially changes to the addressing there. For example its clear that nimrod isn't going to be IPng, but we may want to use it, or something like it, in the future, or at least experiment with it. That is very likely going to want different kinds of locators (almost certainly variable length). We may also want to ressurect PIP and see whether that could be made to work. That certainly has a totally different addressing structure. EIDs allow all those to exist, at once, and to communicate. And then, i do not understand what the buzz is about -- an IPng-capable software is NEW software anyway so making minor cleanups in TCP is *free* -- you have to upgrade software on all machines anyway. I agree. I don't see what you have suggested doing to TCP as being a minor cleanup however. Richard Carlson's suggestion is a more minor adjustment, I don't see that being made either. The only rationale i've heard (in private communications) for not doing that is that "it is out of scope of the IPng group chapter". How compelling; The reason for that rationale is the time factor. "Out of scope" really means "we have to limit what we attempt to do so we have a chance to get it done". kre From owner-Big-Internet@munnari.OZ.AU Sun Jul 17 19:55:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18869; Sun, 17 Jul 1994 19:25:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA11705; Sun, 17 Jul 1994 19:25:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA11691; Sun, 17 Jul 1994 19:18:28 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17933; Sun, 17 Jul 1994 18:44:28 +1000 (from kre@munnari.OZ.AU) To: Simon Poole Cc: big-Internet@munnari.OZ.AU Subject: Re: EID's in the packets In-Reply-To: Your message of "Sat, 16 Jul 1994 12:42:54 +0200." <199407161048.MAA22995@chsun.eunet.ch> Date: Sun, 17 Jul 1994 18:44:25 +1000 Message-Id: <28443.774434665@munnari.OZ.AU> From: Robert Elz Date: Sat, 16 Jul 1994 12:42:54 +0200 (MET DST) From: Simon Poole Message-ID: <199407161048.MAA22995@chsun.eunet.ch> Aren't EID's a feature useful for the transport layer, for TCPng and UDPng? That are -not- being designed right now? Oh, now I see the argument - any feature that's useful for the transport layer shouldn't be considered now, and shouldn't be in the IP layer, right? So, we just leave out the data part of IPng packets, that's only useful for the transport layer, and its by far the biggest bit of the IP packet, we'll save lots of bandwidth that way... Face it, the sole purpose of the net layer is to serve the needs of the transport (and its purpose is to serve the applications). Anything that's generically useful to transport layers is reasonable at the network layer, the minimalist approach is silly, the effect is to cause each transport layer to define its own versions of that functionality that should be common, but was omitted because it wasn't strictly necessary to packet forwarding. Node identification is a perennial need - all transport layers will need it (or all that are likely to be very useful). Having the net layer provide node identification as a common service seems totally reasonable to me. I don't believe that we can rely on locators (addresses) as identifiers - one simple reason is that by the time you decide to check the identity using a locator it may have been reassigned to some other node, and the original given a new one, for all kinds of reasons. Identity needs to be stable, locators need to be transient. Putting EIDs at the net level also has the pragmatic reason that we can do it now. Its a small simple change, and one that will easily fit into IPng without pain. On the other hand, unless we make changes to transport protocols now, which doesn't look to be going to happen, its very unlikely that we will ever make them. We may invent new protocols, but we'll still be using TCP as its delivered with IPng for some applications until the net is switched off. There simply won't be a carrot & stick big enough to get everyone to change. kre From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 00:45:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27184; Mon, 18 Jul 1994 00:45:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA12064; Mon, 18 Jul 1994 00:45:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA12044; Mon, 18 Jul 1994 00:26:53 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25359; Sun, 17 Jul 1994 23:52:29 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 17 Jul 94 22:45:55 +0859 From: Masataka Ohta Message-Id: <9407171346.AA01353@necom830.cc.titech.ac.jp> Subject: Re: EID's in the packets To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 17 Jul 94 22:45:54 JST Cc: poole@magnolia.eunet.ch, big-Internet@munnari.OZ.AU In-Reply-To: <28443.774434665@munnari.OZ.AU>; from "Robert Elz" at Jul 17, 94 6:44 pm X-Mailer: ELM [version 2.3 PL11] > Aren't EID's a feature useful for the transport layer, for TCPng and UDPng? > That are -not- being designed right now? Of course, by definition, the internetworking layer is useful for the transport layer. So, don't repeat bogus arguments, again and again. EID is at the internetwork layer. EID is useful for the transport layer in exactly the same manner as anything in the internetwork layer is useful for the transport layer. PERIOD. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 02:05:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28767; Mon, 18 Jul 1994 02:05:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12152; Mon, 18 Jul 1994 02:05:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12129; Mon, 18 Jul 1994 01:50:41 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28492; Mon, 18 Jul 1994 01:50:37 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-16.dialip.mich.net (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA00332 for ; Sun, 17 Jul 1994 11:49:18 -0400 Date: Sun, 17 Jul 94 14:49:18 GMT From: "William Allen Simpson" Message-Id: <2864.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Identifiers used for Security > From: Vadim Antonov > >The second relates to security, if only EIDs are used for > >identification we have even less ability to trust what the > >net is telling us than we do now (which isn't much). > > Sure, yeah, as if it wasn't obvious from the very beginning that > any information in incoming packets can be forged. If you can > take this as an argument cons EIDs you got real low opinion of > mental abilities of your opponents, don't you? > Basing network security solely on the packet source is so utterly ridiculous that words fail me. Any security mechanism will be based on further headers which contain security information. Read the SIPP Security Architecture. Basing security on the topological information in packet headers completely breaks mobility, which is an IPng requirement. Identifiers without topological information _enhance_ security! The security relationship is completely and easily identified between any pair of systems. That means fewer tables to maintain, thus security is more likely to be implemented. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 02:54:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28894; Mon, 18 Jul 1994 02:09:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12172; Mon, 18 Jul 1994 02:09:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12132; Mon, 18 Jul 1994 01:50:43 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28489; Mon, 18 Jul 1994 01:50:35 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-16.dialip.mich.net (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA00329 for ; Sun, 17 Jul 1994 11:49:16 -0400 Date: Sun, 17 Jul 94 14:30:42 GMT From: "William Allen Simpson" Message-Id: <2863.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Globally visible MAC addreses > From: Robert Elz > From: Vadim Antonov > EIDs are violating privacy. If you base EIDs on hardware MAC addresses > you then can always track movements of the particular box -- > > I came to my terminal right now to say something quite like this, though > not identical - decided to glance at pending mail before I did, and saw > this ... > > My entire message was going to be ... > > Has anyone considered that globally visible MAC addresses > are really no different than globally visible HINFO records > (with some more, some less detail) that many people choose > to refuse to use? > I agree that Identifiers should be completely separate from MAC addresses, and reassigned by new owners. Worse, MAC addresses change on a single system. They move to another system (after an upgrade, for example). They are not globally unique. They are worthless for security. On the other hand, his objection is to Identifiers. They _DO_ violate location privacy. They move without changing. That's the whole point! I certainly won't allow you into my network without _some_ method of knowing who or what you are. There is not, and should not be, location privacy in a network. This is a silly contradiction in terms. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 02:54:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28946; Mon, 18 Jul 1994 02:12:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12200; Mon, 18 Jul 1994 02:12:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12135; Mon, 18 Jul 1994 01:54:06 +1000 Precedence: list Received: from [18.26.0.82] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28182; Mon, 18 Jul 1994 01:38:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28390; Sun, 17 Jul 94 11:38:53 -0400 Date: Sun, 17 Jul 94 11:38:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407171538.AA28390@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Robert Elz I don't believe that we can rely on locators (addresses) as identifiers ... Identity needs to be stable, locators need to be transient. Yah. I'm fairly impressed with Vadim's arguments that we can do it without TLEN's by simply altering bindings, (his arguments against separate TLEN's are about the best I've heard so far), but as I mentally try out his mechanisms in other scenarios they don't work always work so well. For instance, multi-homed hosts have a problem if you're trying to use more than one interface for a given connection; you get name thrash. The more I think about it, the more I like having an invariant name for endpoints, and, derived from that, for protocols (TLEN+prot) and ports (TLEN+prot+port). All the stuff about geting rid of well known ports, and doing ports *before* protocol, are all interesting ideas, but they are mostly orthagonal to the main issue, of whether we have long-lived names for things, or just transient ones. My sense continues to be that long-lived names are a good idea. Part of why I think this is that I simply don't think I can predict what people are going to want to do with the network 30 years down the road. If I knew in detail what was going to happen, I'd be a little happier designing less general mechanism, and substituting more focused ones. Sure, a lot of the mechanisms I've talked about may well be more general than it turns out we need, and that excess and unneeded generality has costs, but I think that's less of a cost than the costs of designing a limited mechanism that we can't adapt. Invariant names for endpoints seem to me to be such a very useful mechanism; the range of problems they help with *today* indicates they will continue to be useful, in decades to come, in ways we don't even begin to see yet. Putting EIDs at the net level also has the pragmatic reason that we can do it now. Its a small simple change, and one that will easily fit into IPng without pain. On the other hand, unless we make changes to transport protocols now, which doesn't look to be going to happen, its very unlikely that we will ever make them. We may invent new protocols, but we'll still be using TCP as its delivered with IPng for some applications until the net is switched off. Yup. Exactly. Noel From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 02:54:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28996; Mon, 18 Jul 1994 02:15:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12217; Mon, 18 Jul 1994 02:15:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12138; Mon, 18 Jul 1994 01:54:16 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28487; Mon, 18 Jul 1994 01:50:34 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-16.dialip.mich.net (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA00326 for ; Sun, 17 Jul 1994 11:49:12 -0400 Date: Sun, 17 Jul 94 13:48:55 GMT From: "William Allen Simpson" Message-Id: <2862.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Constructive Proof on why 8 byte EID is enough > From: Masataka Ohta > Let me construct an EID assignment mechanism to constructively > proof that 8 bytes are more than enough for EID. > Thank you. Very good. > The assumption is that > > EID is location independent and does not need locational > hierarchy. > Yes. > We need hierarchy in EID to delegate EID assignment job > to large organizations. > Yes. > NICs, somehow, should be able to handle EID assignmnet job for > individuals. > No. The NICs want to delegate that work to the providers, who are closer to the problem. When a first-time subscriber gets a connection, they will also get a block. It's just more practical, less paperwork. The key is that the providers don't OWN the block, and you can take it to another provider (or multiple providers) at any time. > Even if all the large organization in the world is assembled > together, they are only as large as all the individuals in the > world. > Correct. > The amount of EID needed by all the large organization in > the world is only as many as the amount of EID needed by > all the individuals in the world, possibly with a small > constant factor diffrence. > Correct. > NICs should be able to handle EID assignmnet job for > large organazations. > Sure. But somebody has to do it for small ones. > NICs do not have to delegate EID assignment. > No. They should delegate the paperwork. All they need to do it maintain the root nameserver for their block, and coordinate among providers (and big organizations). Otherwise, the _people_ work won't scale. (Harder than making a network scale.) So, "draft-simpson-sipp-64-bit-plan-00.txt" has: 1) Upper 2 bytes reserved for geographic (not national) NICs (and other uses like legacy addresses). Not all nations are as big as the USA. Europe is likely to have one NIC for many countries. 2) The next 2 bytes are allocated to the providers in that geography, with allowance for sliding the bit boundary for smaller geographies (no fixed boundaries). The providers do the real administrative task of delegation. So far, the effect is the same as yours. There is no reason to give big blocks to any provider. The blocks should be based on the amount of administrative work the provider is doing, and be adjustable. I still like Paul Francis' plan for assigning from the middle for this. 3) Like yours, the next 2 or so bytes are for the organizations. Again, no truly fixed boundaries. 4) Like yours, the last 2 or less bytes administered by individuals freely. I don't think individuals will be personally capable of administering so many, so I'd probably give these out in single bytes, but that's up to the administrative body. But, I have one special provision: 5) To ease administration, we need automatic dissemination of the upper bytes. Just in case the administration is screwed up at some level, we must provide for automatic changes to be propagated by the same mechanisms. After all, the delegation heirarchy is not topological, but the server mechanisms need to be at convenient topological locations. The organizations may change. We may have more or fewer servers, or a new distributed server mechanism. We may make bad assumptions. So, we need to plan for server changes in the future. > Are there any flaw in the proof? > No flaws in the proof that I know of. I don't see how we can do better than a premise that the number of entities will be population based. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 02:54:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29279; Mon, 18 Jul 1994 02:25:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12246; Mon, 18 Jul 1994 02:25:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA12163; Mon, 18 Jul 1994 02:08:43 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28830; Mon, 18 Jul 1994 02:08:34 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id JAA04919; Sun, 17 Jul 1994 09:08:28 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA10807; Sun, 17 Jul 94 10:07:55 -0600 Date: Sun, 17 Jul 94 10:07:55 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407171607.AA10807@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: EID stuff (was IPng ADs Wish) >From: kre@munnari.oz.au (Robert Elz) > From: Vadim Antonov > ... > That's plain old header compression. Works well until > you need to switch something at 100Mbps. I don't really want to get involved in something that seems to lack an awful lot of concrete detail for so many words and so much heat, but I don't agree with the assumptions behind that passing statement. I think I could do Van Jacobson header compression on up to 200 TCP/IP connections running minimum length packets at 100Mbit/sec using a 33 MHz AMD 29030 and less than 64Bytes of data in inexpensive SRAM chips. As the TCP/IPng header bloats, the job becomes easier. Increasing the number of simultaneous connections does not make the jobs harder or slower, but does require more SRAM. Instead of counting MIPS R3000/R4000 cycles in my variant of Van Jacobson's code in my PPP and SLIP implementations, I'm basing this claim on my nearly 6 year old 29000 code that handles FDDI CLAIM and BEACON frames with a 16MHz 29000 and a brain damaged memory system. By handle I mean take an interrupt and poke a simplistic DMA engine every few usec when sourcing them, and run promiscuously watching them whiz by when some other station is sourcing them. While BEACONing or CLAIMing, an FDDI ring has a continuous stream of back-to-back 21-byte frames, a lot more p/s than TCP/IP. I'd prefer a 29030 to a 29000 because the I-cache is more effective for my code than the BTC--if you're careful you can keep the whole system in the I-cache. I'd probably pick an R3000 for a router or VJ-(de)compressor instead of a 29K for a bunch of reasons, including cost, higher available clock speeds, and the future utility of comparing 64-bits chunks of headers at a time (assuming if R4000 get cheap enough). If you don't believe that is relevant, then read Van Jacobson's cycle counts of his header compression efforts from about 1987. Data speeds 10 times faster than 100Mbps and unchanged CPU speeds would need hardware help. However, it is not hard to build a fly-by checksummer that lets slow 29K's handle at least one medium that is a lot faster than 100Mbps. I think a fly-by header hasher is also easy. The cycles needed to header compress or decompress packets after the initial packets in a TCP/IP connection seem to me fewer than those needed to do IP routing. Besides, you could cache routing decisions in the VJ-(de)compression state, so that (de)compression might speed up routing nearly as much as it slows down the overall work. A lot of UDP/IP traffic is as header-compressible as TCP/IP. One could easily and profitably recognize and compress 28 byte headers of streams of UDP/IP packets for things like DNS when UDP/IP is a significant load. Maybe queries to the roots? If you are willing to violate another layer or two, you can easily compress much of the RPC/XDR stuff in NFS/UDP/IP packets. If you look at it right, NFS is really nearly as connection oriented as any TCP/IP application. No one now compresses UDP/IP headers for PPP and SLIP, because no one lets UDP/IP headers be a significant consumer of low speed bandwidth. Many in the IETF seem to be prejudiced against header compression. I hope those prejudices are not based on layering religions. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 03:05:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00307; Mon, 18 Jul 1994 03:05:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA12290; Mon, 18 Jul 1994 03:05:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA12276; Mon, 18 Jul 1994 02:50:56 +1000 Precedence: list Received: from chsun.eunet.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29913; Mon, 18 Jul 1994 02:50:50 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id SAA05449; Sun, 17 Jul 1994 18:55:15 +0200 Message-Id: <199407171655.SAA05449@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <20202-0@magnolia.eunet.ch>; Sun, 17 Jul 1994 18:49:14 +0200 Subject: Re: EID's in the packets To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 17 Jul 1994 18:49:12 +0200 (MET DST) Cc: poole@magnolia.eunet.ch, big-Internet@munnari.OZ.AU In-Reply-To: <28443.774434665@munnari.OZ.AU> from "Robert Elz" at Jul 17, 94 06:44:25 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1126 From: Simon Poole Sender: poole@magnolia.eunet.ch Robert Elz writes: > Node identification is a perennial need - all transport layers > will need it (or all that are likely to be very useful). > Having the net layer provide node identification as a common > service seems totally reasonable to me. The question is should EID's be simple node id's or shouldn't we take the model further? As has been suggested: "the telnet process on node X", or "the telnet process on node X owned by user Y" being allocated an EID? In the end, these are the objects we are really interested in, and the objects between which the transport layer sets up VC's. > I don't believe that we can rely on locators (addresses) as > identifiers - one simple reason is that by the time you decide > to check the identity using a locator it may have been reassigned > to some other node, and the original given a new one, for all > kinds of reasons. Identity needs to be stable, locators need > to be transient. Did I say anything else? I do not believe that identification of a specific node is a particulary useful definition of "identity" in a networking context. Simon From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 04:05:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01725; Mon, 18 Jul 1994 04:05:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA12357; Mon, 18 Jul 1994 04:05:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12343; Mon, 18 Jul 1994 03:53:57 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01466; Mon, 18 Jul 1994 03:53:39 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id NAA08603; Sun, 17 Jul 1994 13:53:36 -0400 Date: Sun, 17 Jul 1994 13:53:36 -0400 From: Vadim Antonov Message-Id: <199407171753.NAA08603@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements >You are misreading what I said - "isolated" means when considered >alone, that is, in most cases the cost of using EIDs may not >justify using EIDs for that one particular case. However, there >are many such cases, add up the benefits from using EIDs in all >of those cases and I believe the sum exceeds the cost of adding >EIDs (which doesn't increase, which was the point). Sorry, i still didn't hear an *example* of what cannot be implemented w/o EIDs as "cheap" as with EIDs. So far it's only vague beliefs. >Take away one 16 byte source address, and substitute an 8 byte source >EID, and an 8 byte destination EID, and I think (if my arithmetic is correct) >that we're all square. Not having a source address would require EIDs in >every packet. I definitely would like to have source addresses -- it is a matter of reporting problems back to the originator. Sure, if you have source EIDs it takes care of the problem (but requires intermediate systems to do EID->locator lookups). And, then, i also am of the camp which believes that 8 bytes for *locators* is enough. > What huge blocks if we talk about *automatic* allocation? >Identifiers that have topological significance need to allow >room for growth, so more systems can be added that are >topologically close. Organisations that are likely to grow >to have large networks, or who think they might, or even hope >they might, will need, with some justification, a large block >so all the systems they intend to one day have can be numbered >in a topologically sane manner. Sorry, we're talking of automatic allocation on as-needed basis. Since the only reason to do EIDs is to make mobility easier it is assumed that IPng supports mobility (otherwise we only needed to keep thing as they are and extend addresses) so renumbering in order to get a bigger block is not a problem ==> no humans are in the loop. >EIDs have no such constraints, >companies that merely hope to grow large can start with just >enough EIDs for their current needs, if they do then grow they >can simply obtain more from anywhere in the number space. The "constraints" are purely fictitious, see before. >Its also worth noting that this problem with locators is lessened >if EIDs exist, as with them automatic renumbering is feasible, >as connections don't depend on the locators for identification. It is as feasible without them as connections may use network entity names for identification. It is only a matter of implementation. Using names for identification instead of EIDs has an additional advantage of allowing "virtual" mobility -- i.e. when the physical machine stays in place but one particular service moves to another. >Without EIDs, that is, with locators serving to identify From false premises you can make any conclusion so the rest of the reasoning derived from "locators serving to identify" is skipped. > You agreed that manual allocation is evil; >I said nothing of the kind - I said that automatic allocation >where possible is better. The same but expressed little less emotionally. > you also seem to agree that in case of automatic allocation > EIDs can be made isomorphous to locators. >I certainly do not agree to anything even remotely like that. Well, you didn't object and then you lack any proof (namely an example) that they can't. I do not want to explore "positive" proofs on useability of networks w/o EIDs simply because "negative" proof is much easier in this case; i.e. if somebody will come up with an example of a situation where EIDs bring an unquestionable advantage over the EID-less scheme the question with EID-less schemes will be closed. Let's think like engineers, not like politicans. --vadim PS I would be willing to engage in exploring positive proofs as well if somebody will come up with a formal definition of the required functionality. From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 04:25:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02238; Mon, 18 Jul 1994 04:25:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA12407; Mon, 18 Jul 1994 04:25:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12391; Mon, 18 Jul 1994 04:18:34 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02043; Mon, 18 Jul 1994 04:18:23 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id OAA08731; Sun, 17 Jul 1994 14:18:20 -0400 Date: Sun, 17 Jul 1994 14:18:20 -0400 From: Vadim Antonov Message-Id: <199407171818.OAA08731@titan.sprintlink.net> To: kre@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp Subject: Re: EID's in the packets Cc: big-Internet@munnari.OZ.AU, poole@magnolia.eunet.ch >EID is at the internetwork layer. EID is useful for the transport >layer in exactly the same manner as anything in the internetwork layer >is useful for the transport layer. PERIOD. Providing they're useful at all which is yet left to be proven. Regards, --vadim From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 05:05:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03270; Mon, 18 Jul 1994 05:05:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12456; Mon, 18 Jul 1994 05:05:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12435; Mon, 18 Jul 1994 04:47:58 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02851; Mon, 18 Jul 1994 04:47:53 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-15.dialip.mich.net (pm002-15.dialip.mich.net [35.1.48.96]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA08662 for ; Sun, 17 Jul 1994 14:47:49 -0400 Date: Sun, 17 Jul 94 18:22:29 GMT From: "William Allen Simpson" Message-Id: <2866.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: When is rough consensus reached? I had thought with great confidence several times that we had reached consensus on a couple of issues, particularly when we have a 2:1 ratio in favor. But, I got a private message saying -- we have a plurality, not a consensus. When do we reach rough consensus? Do we _have_ to convince everyone? If some people simply aren't convincable, then we do nothing? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 05:54:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04257; Mon, 18 Jul 1994 05:45:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12551; Mon, 18 Jul 1994 05:45:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA12535; Mon, 18 Jul 1994 05:33:27 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03940; Mon, 18 Jul 1994 05:33:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28848; Sun, 17 Jul 94 15:33:19 -0400 Date: Sun, 17 Jul 94 15:33:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407171933.AA28848@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: When is rough consensus reached? Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" When do we reach rough consensus? Hmm, good question. I don't think it was ever defined. Well, I guess we need to reach rough consenus on the definition of "rough consensus"! :-) Do we _have_ to convince everyone? No, that's why we say "rough" consensus (i.e. not complete consensus). Noel From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 06:09:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03698; Mon, 18 Jul 1994 05:25:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12514; Mon, 18 Jul 1994 05:25:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA12500; Mon, 18 Jul 1994 05:13:04 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03356; Mon, 18 Jul 1994 05:12:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28734; Sun, 17 Jul 94 15:12:37 -0400 Date: Sun, 17 Jul 94 15:12:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407171912.AA28734@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements Cc: jnc@ginger.lcs.mit.edu Since the only reason to do EIDs is to make mobility easier No. There are a number of other *obvious* examples of things EID's can help you with (such as multi-homed hosts), and that doesn't even count stuff we don't see yet. However, since you're mind's obviously made up, I won't bother to list them. Using names for identification instead of EIDs has an additional advantage of allowing "virtual" mobility -- i.e. when the physical machine stays in place but one particular service moves to another. I don't think that this kind of thing is a good application for endpoint names, be they DNS names *or* EID's. Somehow I doubt it really does what you want. Probably some sort of dymanic service-locating protocol is needed. > Without EIDs, that is, with locators serving to identify From false premises you can make any conclusion so the rest of the reasoning derived from "locators serving to identify" is skipped. Really? You don't check incoming packets to make sure they have your locator on them, or include the locators in the transport checksum? Either use of them I would called "identifying". What guards against misdirected packets, then? Do you use DNS names as endpoint names, and include then in the transport checkum? If I now understand your whole scheme (including the port-renumbering) correctly, you have endpoint names, they're just DNS names, and aren't in every packet. Your scheme thus has the peculiar property that the connection is named by a combination of i) the DNS name, which doesn't change, together with a port number, which can change. At least if you identified the connection by the locator and the port, both of which could change, it would be consistent! I would be willing to engage in exploring positive proofs as well if somebody will come up with a formal definition of the required functionality. Using this reasoning, no programming language would have "if-then-else", since you can *prove* you can do all the same stuff with "test-skip-goto" (which is in fact basically the mechanism all hardware processors use). Noel From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 06:09:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03333; Mon, 18 Jul 1994 05:08:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12471; Mon, 18 Jul 1994 05:08:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12438; Mon, 18 Jul 1994 04:53:57 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02853; Mon, 18 Jul 1994 04:47:55 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-15.dialip.mich.net (pm002-15.dialip.mich.net [35.1.48.96]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA08665 for ; Sun, 17 Jul 1994 14:47:51 -0400 Date: Sun, 17 Jul 94 18:26:42 GMT From: "William Allen Simpson" Message-Id: <2867.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Constructive Proof ... In regard to proof that 8 bytes is enough, I present the argument I made in regard to mobile nodes on the SIPP list earlier. Note that this is not just Identifiers, but everything, including routing (by adding the numbering of extra nodes which handle the Locator when away from home). Again, the limiting factor is not really the mobiles thenselves, but the immensity of administrations to support the effort. > From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > I don't buy it. The biggest need for bandwidth economy is for mobiles. > You can't convince me that 8 bytes are guaranteed to be enough to identify > all world-wide mobiles for the next 20 or 30 years, as well as to do > all the other things the address space has to do. > That seems like a challenge to me.... Here goes: To examine whether 8 bytes is guaranteed to be enough for to identify all world-wide mobiles in 30 years, we need to estimate: 1) the number of mobiles, 2) the address space requirements for each mobile, 3) and the address space requirements to support mobility. Part 1. We can estimate the number of mobiles based on the maximum population. The number of mobiles will be of the same order of magnitude as the population, whether it is 1, 2, 3 or 4 mobiles per person. The US Central Intelligence Agency estimates that the world population in 30 years will be 8.5 * 10**9 persons. ["World Fact Book", Central Intelligence Agency, public affairs office] This is a credible source for such statistics. I know of no better funded source. Part 2. Such an estimate will leave 2**30 (1 * 10**9) for administering the mobiles. Note that this should be enough to have a 2nd or 3rd address for moving the mobiles about. Let us assume that every mobile is assigned a transient identifier. We can in fact do better than this. In the Mobile-IP WG, the current plan uses tunnels to Foreign Agents to avoid assigning _any_ additional transient identifiers. Part 3. Assuming the worst case of 3 transient addresses for a rapidly moving mobile (the one it left, the one it is at, and the next one), this leaves 2**28 numbers for supporting mobility. In order to support mobility, you need at least 2 administrative heirarchies -- the heirarchy for the owners of mobiles, and the separate heirarchy for the locus of communication for the mobiles. This leaves 2**27 for administrative slop. Assume 7/8 is lost to administrative inefficiency. There is no reason to expect we can't do better (even the phone companies do better). Will we have routers capable of flat routing 2**24 entries? At the rate of electronic growth, probably. Will we be able to create and manage 2*24 administrative entities? Probably not! Therefore, the extent of the Internet is not bounded by the the number of mobiles, but rather by the immense task to manage such a large number of administrations. Scaling: Let us assume for true extravagance that some persons will have a mobile for every organ and bone in their bodies, or about 1,000 mobiles per person, and that each such person will also have a fully instrumented mobile home, 1,000 per person, and a fixed home, for another 2,000 per person -- 4,096 total. That each mobile person will need a mobile router is lost in the noise, and no extra numbers need be assigned. That leaves only 2**15 administrations. While the current world-wide number of cities, townships, and other forms of governmental administration are orders of magnitude smaller, and we already feel there is too much government, this is a size that is _possibly_ managable politically. Conclusion: Yes, 8 bytes is enough to identify, route and administer all world-wide mobiles for 30 years, and likely for all time. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 06:09:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04294; Mon, 18 Jul 1994 05:48:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12566; Mon, 18 Jul 1994 05:48:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA12519; Mon, 18 Jul 1994 05:25:41 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03696; Mon, 18 Jul 1994 05:25:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28799; Sun, 17 Jul 94 15:25:29 -0400 Date: Sun, 17 Jul 94 15:25:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407171925.AA28799@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, poole@magnolia.eunet.ch Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Simon Poole The question is should EID's be simple node id's or shouldn't we take the model further? ... "the telnet process on node X" ... In the end, these are the objects we are really interested in, and the objects between which Here is where it becomes painful to have explained EID's as transport names. If you go back to the original reasoning, they name "fate-sharing" regions, but although this is the fundmental principle of TCP, many people seemed to have a hard time grokking these concepts, so I switched to "transport name" as an easier thing to understand. This has had the bad side-effect of making the reasoning for EID's murkier. If you will recall, the basic architectural principal of TCP (which distinguished it from NCP) was that all the "critical" state for a connection was co-located with the application; the "fate-sharing principle". I reckon that it is the regions of fate-sharing that we need to name, since they are *the* fundamental objects of end-end communication. (End-end and fate-sharing are really just two sides of one coin.) Seen through this perception, it's really only useful, at this level, to name a given process separately *if it is a fatesharing region*. If my Unix box crashes, all the processes are going to go together, so there's no reason to name them separately to the network, at this level. It may well be useful to name "the Telnet process on node X", but this is an *application level* name, and needs to be *translated* to lower-level names (such as address, port, etc) to be useful. None of which is going to change anyone's mind, of course. Noel From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 09:10:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB05730; Mon, 18 Jul 1994 06:25:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA12621; Mon, 18 Jul 1994 06:25:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA12596; Mon, 18 Jul 1994 06:09:58 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04569; Mon, 18 Jul 1994 05:56:18 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-22.dialip.mich.net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA12016 for ; Sun, 17 Jul 1994 15:56:12 -0400 Date: Sun, 17 Jul 94 18:56:08 GMT From: "William Allen Simpson" Message-Id: <2868.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Proofs for Vadim > From: Vadim Antonov > Sorry, i still didn't hear an *example* of what cannot be implemented > w/o EIDs as "cheap" as with EIDs. So far it's only vague beliefs. > Then you have been listening, instead of reading. This is a mailing list. (That is an attempt at critical levity.) Nobody has been terribly vague. I, for one, have pointed out that identifying a mobile node with a value that contains useless and outdated location information wastes bandwidth. Bandwidth is expensive. Minimizing bandwidth is a mobility requirement. Using locatorless Identifiers reduces bandwidth. (QED) > >Its also worth noting that this problem with locators is lessened > >if EIDs exist, as with them automatic renumbering is feasible, > >as connections don't depend on the locators for identification. > > It is as feasible without them as connections may use network > entity names for identification. It is only a matter of implementation. > Automatic renaming (I'm assuming you are speaking about Domain Names) is very, very hard. The lifetime of DNS names is very long compared to almost anything, particularly connections and mobility, which must change on the order of milliseconds and seconds respectively. DNS names are printable and are often published on paper. Updating paper would be an nearly impossible feat. It is much easier to renumber a subordinate value at any speed. (QED) Again, DNS names are typically much larger than 8 byte Identifiers. Bandwidth is expensive. Minimizing bandwidth is a mobility requirement. Using short fixed-size Identifiers reduces bandwidth. (QED) > Using names for identification instead of EIDs has an additional > advantage of allowing "virtual" mobility -- i.e. when the physical > machine stays in place but one particular service moves to another. > This makes no sense. Assuming that you are talking about services such as FTP, the current method of associating a DNS name with a service -- such as ftp.foo.bar with IPv4 address 1.2.3.4 -- allows the service to move from machine to machine without changing the name. Also, having the name separate from the Identifier allows the actual Identifier to to to changed more easily. Adding an indirection provides flexibility. (QED) > > you also seem to agree that in case of automatic allocation > > EIDs can be made isomorphous to locators. > > >I certainly do not agree to anything even remotely like that. > > Well, you didn't object and then you lack any proof (namely an example) > that they can't. > I'll object. The Identifier is rooted in an administrative heirarchy, and changes rarely. The Locator is rooted in a topological mesh, and changes frequently. There is little or no similarity in structure or relationship (isomorphism) between the Identifier and the Locator. Specific examples would certainly be hard to come by, lacking deployment. However, I can give one that would be applicable. M-Net.ann-arbor.mi.us. (a community service in Ann Arbor) has an IPv4 address of 35.208.17.4. That would make it seem to be administratively part of Merit, although it is a separate organization. In fact, M-Net is connected to Merit for MichNet use. Merit is also connected to AN_S and CICnet. But, M-Net's primary connection for external use is through MSEN, which is connected to PSI. So, we have a clear case where the administrative heirarchy is not at all isomorphic to the topological heirarchy. (QED) > I do not want to explore "positive" proofs on useability of networks w/o > EIDs simply because "negative" proof is much easier in this case; i.e. > if somebody will come up with an example of a situation where EIDs > bring an unquestionable advantage over the EID-less scheme the question > with EID-less schemes will be closed. Let's think like engineers, > not like politicans. > Negatives are not possible to prove. Identifiers bring an unquestionable advantage over other techniques in the above named cases, and there is no other known technique for solving the problems. That does not mean that such a solution doesn't exist. > PS I would be willing to engage in exploring positive proofs as well > if somebody will come up with a formal definition of the required > functionality. > The required functionality has been clearly spelled out in previous notes to this list. Thank you, and I will happily consider the question closed 5 times. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 09:56:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10261; Mon, 18 Jul 1994 09:26:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA12795; Mon, 18 Jul 1994 09:25:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12770; Mon, 18 Jul 1994 09:10:25 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07970; Mon, 18 Jul 1994 08:03:04 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id SAA09152; Sun, 17 Jul 1994 18:03:01 -0400 Date: Sun, 17 Jul 1994 18:03:01 -0400 From: Vadim Antonov Message-Id: <199407172203.SAA09152@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: When is rough consensus reached? >I had thought with great confidence several times that we had reached >consensus on a couple of issues, particularly when we have a 2:1 ratio >in favor. Technology is not a democracy. The majority is not automatically right. >When do we reach rough consensus? Do we _have_ to convince everyone? There is a regular way accepted in the "real" science -- to have all theories to pass public review when everybody tries to find faulty logics or unfounded assumptions. With time, the general confidence is growing as more and more people find that they cannot break the theory or design. Consensus-building is deadly for science and engineering; as everybody knows the ideal consensus is found only at graveyards. Am i the first to try to apply that to IPng? I hope not. >If some people simply aren't convincable, then we do nothing? There are definitely some clinical cases; the rest can be convinced by "evidence beyond the reasonable doubt". Cheers, --vadim From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 09:56:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10414; Mon, 18 Jul 1994 09:29:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA12810; Mon, 18 Jul 1994 09:29:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12779; Mon, 18 Jul 1994 09:14:23 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09040; Mon, 18 Jul 1994 08:41:51 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id SAA09214; Sun, 17 Jul 1994 18:41:48 -0400 Date: Sun, 17 Jul 1994 18:41:48 -0400 From: Vadim Antonov Message-Id: <199407172241.SAA09214@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: Proofs for Vadim >I, for one, have pointed out that identifying a mobile node with a value >that contains useless and outdated location information wastes bandwidth. Yeah, so what? I didn't propose identifying anything with the useless and outdated information, did i? >Bandwidth is expensive. Minimizing bandwidth is a mobility requirement. Agreed. >Using locatorless Identifiers reduces bandwidth. (QED) This statement needs to be proven -- by providing an example of usage of locatorless identifier which reduces the bandwidth as compared to the other scheme. >Automatic renaming (I'm assuming you are speaking about Domain Names) >is very, very hard. The lifetime of DNS names is very long compared >to almost anything, particularly connections and mobility, which must >change on the order of milliseconds and seconds respectively. Ok, why can't it be made much shorter? Where's the difference between propagating the routing information based on EIDs and propagating the same information related to domain names? >DNS names are printable and are often published on paper. Updating >paper would be an nearly impossible feat. Nobody speaks about updating *DNS names* when a host moves from one net to another. The only thing which needs to be updates is mapping from DNS to the locator which is not the same as changing name. Hence, the rest makes no sense "QED" notwithstanding. > It is much easier to renumber > a subordinate value at any speed. (QED) >Again, DNS names are typically much larger than 8 byte Identifiers. So what? As long as they aren't present in packet headers the cost is marginal. And then, you still *have* to do conversion from DNS named into EIDs and then to locators. >Bandwidth is expensive. Minimizing bandwidth is a mobility requirement. >Using short fixed-size Identifiers reduces bandwidth. (QED) Removing any entity *identifiers* from headers will reduce bandwidth even more. No QEDs will help if there is no logic. >> Using names for identification instead of EIDs has an additional >> advantage of allowing "virtual" mobility -- i.e. when the physical >> machine stays in place but one particular service moves to another. > >This makes no sense. Assuming that you are talking about services such >as FTP, the current method of associating a DNS name with a service -- >such as ftp.foo.bar with IPv4 address 1.2.3.4 -- allows the service to >move from machine to machine without changing the name. Please explain how can i move FTP from my machine to another leaving TELNET in place and *not changing the names*. You know, using "mathematically-looking" terminology is not equivalent to actually using logics. >Also, having >the name separate from the Identifier allows the actual Identifier to >to to changed more easily. Sure. Having a pet crocodile makes feeding it easier -- you don't need to go to Africa to feed a crocodile. The question is why do i need to feed crocodile at all? >Adding an indirection provides flexibility. (QED) I illustrated exactly opposite on specific examples. So far nobody presented faults in the examples. >I'll object. >The Identifier is rooted in an administrative heirarchy, and changes >rarely. The Locator is rooted in a topological mesh, and changes >frequently. There is little or no similarity in structure or >relationship (isomorphism) between the Identifier and the Locator. In my practice administrative hierarchies change faster than physical topology. And then, you still need to argue why identifiers should be based on administrative hierarchies. The example is skipped as irrevelant. (It was provided to illustrate what? That topological info is not always useful to determine administrative affiliation? Anybody agrued with *that*?) >Specific examples would certainly be hard to come by, lacking >deployment. ... or understanding. I didn't ask for example "from life" but rather for some realistic model situation. >So, we have a clear case where the administrative heirarchy is not at >all isomorphic to the topological heirarchy. (QED) GREAT NEWS! MOON IS NOT MADE FROM CHEESE! (QED) >Negatives are not possible to prove. Sorry, take a refresher 101 math course. --vadim PS. I *will* keep that style until we finally get into constructive discussion where arguments have better quality and relevance that that moony-cheesy babble. From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 09:57:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10511; Mon, 18 Jul 1994 09:31:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA12827; Mon, 18 Jul 1994 09:31:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12773; Mon, 18 Jul 1994 09:12:52 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07673; Mon, 18 Jul 1994 07:51:29 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id RAA09122; Sun, 17 Jul 1994 17:51:27 -0400 Date: Sun, 17 Jul 1994 17:51:27 -0400 From: Vadim Antonov Message-Id: <199407172151.RAA09122@titan.sprintlink.net> To: avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements >No. There are a number of other *obvious* examples of things EID's can help >you with (such as multi-homed hosts), and that doesn't even count stuff we >don't see yet. However, since you're mind's obviously made up, I won't bother >to list them. Pray, list them. I definitely won't argue that 2x2 does not equal 4. > Using names for identification instead of EIDs has an additional > advantage of allowing "virtual" mobility -- i.e. when the physical > machine stays in place but one particular service moves to another. >I don't think that this kind of thing is a good application for endpoint >names, be they DNS names *or* EID's. Somehow I doubt it really does what you >want. Probably some sort of dymanic service-locating protocol is needed. "Somehow doubt" or have the good argument? :-) I generally see too many things in modern computing done in a rather inefficient and ugly way just because it is "common wisdom" to do it like that. > > Without EIDs, that is, with locators serving to identify > From false premises you can make any conclusion so the rest of > the reasoning derived from "locators serving to identify" is skipped. >Really? You don't check incoming packets to make sure they have your locator >on them, or include the locators in the transport checksum? Either use of >them I would called "identifying". Not. It is verification. It does not have to have the property of unambiguity -- i.e. it is sufficient if verification will catch 1-1/(10^n) misdirected packets but it is unacceptable for transport address -> network entity name conversion. >What guards against misdirected packets, >then? You may explicitly check source and destination locators associated with the port. >Do you use DNS names as endpoint names, and include then in the >transport checkum? It is an interesting idea -- to calculate some kind of checksum on names and XOR it with the packet checksums :-) There's a problem with multiple names for the same entity, though. >If I now understand your whole scheme (including the port-renumbering) >correctly, you have endpoint names, they're just DNS names, and aren't in >every packet. "Port-renumbering" is only incidental to the geral idea of including port numbers into locators and allowing mobility of network entities. If you allow mobility you then can easily avoid the port-collision problem. I see no reason to draw a strict boundary between hosts and networks -- every host has a network inside! Just think how flexible and generic this scheme is. >Your scheme thus has the peculiar property that the connection >is named by a combination of i) the DNS name, which doesn't change, together >with a port number, which can change. DNS name is a unique global identifier of a network entity. In a typical situation, such name translates into locator pointing to the port that entity uses to accept new connections. It happily recieves SYN packets, creates new port (on the different host or interface maybe!) and returns the locator for the connection. The same semantic as in sockets interface as you can see. >At least if you identified the >connection by the locator and the port, both of which could change, it would >be consistent! See before, it is :-) >Using this reasoning, no programming language would have "if-then-else", since >you can *prove* you can do all the same stuff with "test-skip-goto" (which is >in fact basically the mechanism all hardware processors use). In case of programming languages it is proven that the control constructions can be translated 1:1 with no loss of efficiency. The analogy is thus incorrect. In this case *EIDs* is the new concept and i'm merely being conservative and question the rationale after creating an additional layer of name->locator conversion and creating a whole bunch of new structures (protocols, allocation system, etc) with still unclear advantages over the existing one-stage scheme. What i'm proposing is not a radical change but rather a minor clean-up of already sound design. Instead of introducing new notions (like EIDs) i simply propose to fix the implementations to remove the semantical gap between programmer's interface and the actual network by adding an option to TCP to allow the party accepting the connection reply "ok, i'm accepting at the such and such". Don't you see you're building a monstrosity in one place just to avoid a trivial fix in another? --vadim From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 09:57:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10564; Mon, 18 Jul 1994 09:34:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA12846; Mon, 18 Jul 1994 09:34:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12776; Mon, 18 Jul 1994 09:14:18 +1000 Precedence: list Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08384; Mon, 18 Jul 1994 08:17:28 +1000 (from @www.bbn.com:jcurran@nic.near.net) Received: from www.bbn.com by nic.near.net id aa00369; 17 Jul 94 18:17 EDT To: big-internet@munnari.OZ.AU Subject: Transport Endpoint Identifiers Date: Sun, 17 Jul 1994 18:16:17 -0400 From: John Curran Message-Id: <9407171817.aa00369@nic.near.net> I've been away for a week or so, and it appears as though the Big-Internet mailing list has rediscovered endpoint identifiers with a vengeance... :-) Having just waded through the 400+ messages, it doesn't look like consensus is in the immediate future. There's quite a few folks who feel that some form of transport-level endpoint identifiers "seem" to be a good thing, but it's true that there is no problem which can _only_ be solved by EIDs. (This shouldn't surprise anyone; I've never seen a problem which could be solved by one, and only one, type of solution.) I've been a fan of separating network locator information from transport endpoint identification for some time (some might even remember the expired TCP & UDP with Network-independent Endpoints (TUNE) ID that I did a while back). I'd like to share the three reasons why I think EID's are very good mechanism to incorporate into the TCP and UDP that we use with IPng and in addition note why I honestly don't expect the IETF to adopt EIDs in the near future. Reason 1 for EIDs: "Homeless" Mobility I feel that the future (tomorrow to 30+ years) is going to have a great number of mobile devices, and that many of these mobile devices are not going to be "anchored" to a single network topology location for any duration. My PDA is going to connect to the local wireless data net as soon as I walk out of the store and it's going to keep roaming around the network (acquiring new locators) until I cut it in half and throw it out. I really don't care whether transport connections to my PDA are identified by short, unique, numeric id's or by DNS names, but I know it shouldn't be based on some arbitrary network locator which I had for 12 minutes one afternoon. Problem: How does one create highly dynamic (EID or DNS name)-to-locator mapping system? Oh, yes, I would like authentication as well... Reason 2 for EIDs: Scalable Provider-based Routing In order to provide cost-effective global Internet connectivity, it's necessary to minimize the number of routing entries in the global routing tables. While many organizations may desire to have "addressing autonomy" (whereby their locator prefix is globally known to every transit-provider on the planet), there will be distinct costs for maintaining such visibility. The alternative will involve organizations using provider-based addresses for their internal networks. Such addresses are prone to change as organizations change Internet service providers, so again it would be best if transport connections could survive the underlying change in network locators. Problem: How does one provide for autoconfiguration of (EID or DNS-name) to locator mappings? Where does the host get its EID or DNS name from? Oh, yes, how does the host authenticate itself during autoconfiguration? Reason 3 for EIDs: Sane Network Administration Today, organizations are discovering that their internal networks are becoming bandwidth intensive. I'm not referring to those folks doing PC-to-PC videoconferencing (but that's coming :-); I'm referring to folks with ordinary client-server networks which are being increasingly loaded as more and more applications move in that direction. These sites are receiving very diverse input as to how to handle their scaling problems: "use smart bridges", "no, add routers and subnet", "no, move to switching technology", etc. What the networks administrators really want to be able to do is to rapidly add more network segments and to move servers, clients, printers, etc. _without_ having to worry about which addresses are valid on which wire. Again, the ability to dynamic assign locators and simply update the (EID or DNS)-to-locator mapping would be highly valued. Problem: How does one provide for authenticated, dynamic transport EID (or DNS name)-to-locator services? My perspective is that mobility, portability, autoregistration, and authentication need to be assumed as the "normal" case for IPng. If one considers that every host is going to be mobile, and require authentication, and make use of autoregistration, then the need to separate network locator information from transport layer connection identification seems obvious. I don't really care much whether DNS names or short, numeric labels are used for transport connection identification, as long as locators _aren't_ used for this purpose. The reason that I don't expect the IETF to adopt EIDs is simply because we aspire to set of base features in IPng which is very minimal, and as good engineers we're required to eliminate anything and everything which is not required to get the job done. Transport-level EIDs are not absolutely required to get a segment from point A to point B, so they'll be left out. If there was an architecture which provided each host with autoregistration, mobility and authentication, then we might have a stronger need to separate locator from EID functionality. /John p.s. No, I don't believe in EID's being carried explicitely as part of the internetwork header; I expect to find them in the first few bytes of transport header. p.p.s. Yes, I understand how large the resulting (network+transport) header is, and the net impact on performance. No, I don't care, and honestly believe that 98% of corporate america would be pleased if you told them that you traded the performance impact for features 1, 2, and 3 above. From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 11:39:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14963; Mon, 18 Jul 1994 11:39:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA12960; Mon, 18 Jul 1994 11:39:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA12955; Mon, 18 Jul 1994 11:25:19 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14458; Mon, 18 Jul 1994 11:25:08 +1000 (from barney@databus.databus.com) Date: Sun, 17 Jul 94 21:27 EDT Message-Id: <9407172127.AA19221@databus.databus.com> From: Barney Wolff To: "Robert G. Moskowitz" <0003858921@mcimail.com>, big internet Subject: Re: IPng and .... Firewalls! Content-Length: 831 Content-Type: text > Date: Fri, 15 Jul 94 16:10 EST > From: "Robert G. Moskowitz" <0003858921@mcimail.com> > > Firewalls ain't going away with IPng. Sorry folks. This time the proof is > in on the otherside. My auditors will have to be shown the unassiableness > of IPng based systems from all attacks. Basically a non-solvable problem, > much like the 4 color map problem. > > So I plan on having my own internal locator structure that will have nothing > to do with the public's locator. But MOST of my EIDs will be publicly > unique. > > I think what will happen is the firewall becomes a locator proxy of some > sort. If EID==DNSname, a system can have a "public" name and a "private" one, and the firewall's job just got *much* easier - it just lets members of public.chrysler.com talk to the goyim. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 12:55:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16692; Mon, 18 Jul 1994 12:25:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA13025; Mon, 18 Jul 1994 12:25:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA13011; Mon, 18 Jul 1994 12:11:58 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15843; Mon, 18 Jul 1994 12:04:29 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 18 Jul 94 10:57:13 +0900 From: Masataka Ohta Message-Id: <9407180157.AA03743@necom830.cc.titech.ac.jp> Subject: Re: Transport Endpoint Identifiers To: jcurran@nic.near.net (John Curran) Date: Mon, 18 Jul 94 10:57:12 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407171817.aa00369@nic.near.net>; from "John Curran" at Jul 17, 94 6:16 pm X-Mailer: ELM [version 2.3 PL11] > it's true that there is no problem which can _only_ be solved by EIDs. Provider-independent ID so that you can change providers without much pain. > p.s. No, I don't believe in EID's being carried explicitely as part > of the internetwork header; I expect to find them in the first > few bytes of transport header. Read text books on layering. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 13:45:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19262; Mon, 18 Jul 1994 13:45:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13169; Mon, 18 Jul 1994 13:45:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA13166; Mon, 18 Jul 1994 13:45:12 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19242; Mon, 18 Jul 1994 13:45:09 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-22.dialip.mich.net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id XAA05217 for ; Sun, 17 Jul 1994 23:44:35 -0400 Date: Mon, 18 Jul 94 03:04:52 GMT From: "William Allen Simpson" Message-Id: <2870.bill.simpson@um.cc.umich.edu> To: John Curran Cc: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Transport Endpoint Identifiers Thank you John, for one of the best big-internet messages of '94. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 13:49:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19347; Mon, 18 Jul 1994 13:49:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13190; Mon, 18 Jul 1994 13:48:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA13163; Mon, 18 Jul 1994 13:45:02 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19174; Mon, 18 Jul 1994 13:44:47 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-22.dialip.mich.net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id XAA05221 for ; Sun, 17 Jul 1994 23:44:37 -0400 Date: Mon, 18 Jul 94 03:05:52 GMT From: "William Allen Simpson" Message-Id: <2871.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Proofs for Vadim > From: Vadim Antonov > This statement needs to be proven -- by providing an example of > usage of locatorless identifier which reduces the bandwidth as compared > to the other scheme. > I'm sorry that you haven't read my other work. I do not intend to educate you on a public mailing list. > In my practice administrative hierarchies change faster than > physical topology. Hmmm, I thought we were talking about the Internet, not your practice. I see the Internet change minute by minute. What kind of practice to you have? Dentistry? Music? Yoga? Clearly not anything related to networking. > And then, you still need to argue why identifiers > should be based on administrative hierarchies. > I'm sorry that you haven't read my other work. I do not intend to educate you on a public mailing list. > You know, using > "mathematically-looking" terminology is not equivalent to actually > using logics. > ... or understanding. I didn't ask for example "from life" but > rather for some realistic model situation. > I see. If we provide you a model, you say you don't understand, and ask for an example. If we provide an example, you ask for another model. It has become apparent that you have some problem with the language we are using, and often use words that you don't understand. For example, "isomorphic". I do not intend to educate you on a public mailing list. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 13:56:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17828; Mon, 18 Jul 1994 13:05:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13074; Mon, 18 Jul 1994 13:05:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA13055; Mon, 18 Jul 1994 12:46:13 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17245; Mon, 18 Jul 1994 12:45:58 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA05920; Sun, 17 Jul 94 22:45:51 EDT Message-Id: <9407180245.AA05920@tipper.oit.unc.edu> To: big internet Subject: Re: IPng and .... Firewalls! In-Reply-To: Your message of "Sun, 17 Jul 94 21:27:00 EDT." <9407172127.AA19221@databus.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 17 Jul 94 22:45:50 -0400 From: Simon E Spero I tap one island and block your fireball with a Blue Elemental Blast. Oh, firewall. Never mind... Simon // This list has gotten so nasty in the past few weeks it's an easy mistake to make. From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 13:57:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18411; Mon, 18 Jul 1994 13:25:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13134; Mon, 18 Jul 1994 13:25:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA13120; Mon, 18 Jul 1994 13:15:18 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18071; Mon, 18 Jul 1994 13:15:05 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id XAA09849; Sun, 17 Jul 1994 23:13:50 -0400 Date: Sun, 17 Jul 1994 23:13:50 -0400 From: Vadim Antonov Message-Id: <199407180313.XAA09849@titan.sprintlink.net> To: 0003858921@mcimail.com, barney@databus.com, big-internet@munnari.OZ.AU Subject: Re: IPng and .... Firewalls! >If EID==DNSname, a system can have a "public" name and a "private" one, >and the firewall's job just got *much* easier - it just lets members of >public.chrysler.com talk to the goyim. And if you can "migrate" TCP connections between hosts implementing efficient proxies becomes possible (i.e. proxy's job is authenticate and open the connection and "transfer" it to the actual server). --vadim From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 14:06:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20055; Mon, 18 Jul 1994 14:06:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA13222; Mon, 18 Jul 1994 14:05:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA13219; Mon, 18 Jul 1994 14:04:24 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19899; Mon, 18 Jul 1994 14:04:13 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 18 Jul 94 12:56:28 +0900 From: Masataka Ohta Message-Id: <9407180356.AA04468@necom830.cc.titech.ac.jp> Subject: Re: Constructive Proof on why 8 byte EID is enough To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Date: Mon, 18 Jul 94 12:56:26 JST Cc: bsimpson@morningstar.com, big-internet@munnari.OZ.AU In-Reply-To: <9407180213.AA03838@necom830.cc.titech.ac.jp>; from "Masataka Ohta" at Jul 18, 94 11:13 am X-Mailer: ELM [version 2.3 PL11] > > All they need to do it maintain > > the root nameserver for their block, and coordinate among providers (and > > big organizations). Otherwise, the _people_ work won't scale. (Harder > > than making a network scale.) > > If you delegate, the amount of work of the NIC decreases. > > But, even if you delegate, the amount of work of the society as a whole > does not decrease. > > So, instead of trying to make NIC small, give enough fund to NIC. Let me add a little more explanation on why provider based hierarchy is harmful for EID. If users change proviers, the original provider don't want to spend money to support the delegated DNS subtree. What if a provider bankrupts? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 15:09:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17913; Mon, 18 Jul 1994 13:09:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13093; Mon, 18 Jul 1994 13:09:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA13069; Mon, 18 Jul 1994 12:55:16 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16474; Mon, 18 Jul 1994 12:20:22 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 18 Jul 94 11:13:24 +0900 From: Masataka Ohta Message-Id: <9407180213.AA03838@necom830.cc.titech.ac.jp> Subject: Re: Constructive Proof on why 8 byte EID is enough To: bsimpson@morningstar.com Date: Mon, 18 Jul 94 11:13:22 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <2862.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Jul 17, 94 1:48 pm X-Mailer: ELM [version 2.3 PL11] > > NICs, somehow, should be able to handle EID assignmnet job for > > individuals. > > > No. The NICs want to delegate that work to the providers, who are > closer to the problem. You are talking about locators. > When a first-time subscriber gets a connection, > they will also get a block. It's just more practical, less paperwork. Not necessarily a block. A provider having 1,000 customers may act as an agency of EID assignment and be preallocated 1,00 EIDs (which may not be consequetive) from a national NIC. The provider may preallocated cryptographical keys to dynamically update the DNS data of preallocated EIDs once. > The key is that the providers don't OWN the block, and you can take it > to another provider (or multiple providers) at any time. The key is to achieve near 100% efficiency at first 6 bytes of EID. > > NICs do not have to delegate EID assignment. > > > No. They should delegate the paperwork. Call the entire organization of agencies NIC. > All they need to do it maintain > the root nameserver for their block, and coordinate among providers (and > big organizations). Otherwise, the _people_ work won't scale. (Harder > than making a network scale.) If you delegate, the amount of work of the NIC decreases. But, even if you delegate, the amount of work of the society as a whole does not decrease. So, instead of trying to make NIC small, give enough fund to NIC. > So, "draft-simpson-sipp-64-bit-plan-00.txt" has: > 3) Like yours, the next 2 or so bytes are for the organizations. No, mine is not. Anyway, the purpose of my proposal is to proof that 8 byte is enough. So, don't be botherd with the details. > No flaws in the proof that I know of. I don't see how we can do better > than a premise that the number of entities will be population based. As 2^64 is too large, you don't have to worry about it. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 16:26:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25036; Mon, 18 Jul 1994 16:26:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA13385; Mon, 18 Jul 1994 16:25:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA13369; Mon, 18 Jul 1994 16:13:52 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24467; Mon, 18 Jul 1994 16:13:16 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA07819; Mon, 18 Jul 94 01:14:16 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ae12984; 18 Jul 94 6:09 GMT Date: Mon, 18 Jul 94 01:10 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: EIDs and 2 cards on a segment... Message-Id: <44940718061044/0003858921NA3EM@mcimail.com> Here I was, thinking that the locator+EID was really neat. With it, I could have an indeterminate number of devices on one segment, all with one locator. My house could just be one wire unit with lots (thousands even!) of devices on it, all with one locator. Or I could get smart and have different provider locations all converging on that one segment: Electric company, Gas Company, Telephony service, (no video for me, except for conferencing), etc. Each would reference their 'secured' devices on my segment. Thus my home wiring costs would be kept to a miniumum. In the office, we could go to those ATM hubs and set up a building as one segment with lots of devices (in theory :) ). But then I remembered that some of those devices have two interfaces on one segment... Yes, with IPv4, this does not always work. Motorola 88000 Delta systems with 5.3 go bonkers. RS/6000 at 3.11 get 'RIPed' up as does MVS/TCP 2.1.1. Sun Solaris 2.2 and NCR 5.4 seems to handle it ok. The problem with IPng were EID identifies the system and locator the segment, these two interfaces would be undistiguisable. I'd ASSUME only one would be in the ARP tables of other devices on the segment, but which one? Also how would the internal machine decide which interface to use? HOw common is two interfaces on one segment? And how does IPng handle this? Bob From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 16:56:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24209; Mon, 18 Jul 1994 16:05:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA13342; Mon, 18 Jul 1994 16:05:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA13337; Mon, 18 Jul 1994 16:01:36 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22930; Mon, 18 Jul 1994 15:33:40 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id BAA10233; Mon, 18 Jul 1994 01:33:19 -0400 Date: Mon, 18 Jul 1994 01:33:19 -0400 From: Vadim Antonov Message-Id: <199407180533.BAA10233@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: Proofs for Vadim >I'm sorry that you haven't read my other work. I do not intend to >educate you on a public mailing list. You could provide a reference in private e-mail. I cannot read everything just because it was written. >What kind of practice to you have? Dentistry? Music? Yoga? Clearly >not anything related to networking. Bzzt. Thanks for playing. I'm currently running engineering and development at one of the largest Internet service providers. Also, i am one of founders of an international TCP/IP and UUCP network with POPs in 17 countries and crossing 11 timezones. Also, my resume includes 12 years of Unix kernel and application design -- i started from v6 and my own revision of unix was the most popular unix-like in my native country for years. Clearly, i don't do anything related to networking. >It has become apparent that you have some problem with the language we >are using, and often use words that you don't understand. For example, >"isomorphic". FYI -- i have MS degree in math from one of the best math depts in the world. Go argue with profs who gave me As. >I do not intend to educate you on a public mailing list. I do not intend to engage in discussions with people who prefer to throw insults instead of providing real arguments. --vadim From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 18:25:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29145; Mon, 18 Jul 1994 18:25:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA13542; Mon, 18 Jul 1994 18:25:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA13528; Mon, 18 Jul 1994 18:14:21 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26496; Mon, 18 Jul 1994 17:03:34 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id DAA10329; Mon, 18 Jul 1994 03:03:26 -0400 Date: Mon, 18 Jul 1994 03:03:26 -0400 From: Vadim Antonov Message-Id: <199407180703.DAA10329@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, jcurran@nic.near.net Subject: Re: Transport Endpoint Identifiers Thanks, John. You finally moved the discussion to the real issues. Please note that i'm agruing not against EIDs per se since it is more less obvious that some form of identification is necessary but rather the against idea of having one more entity in between DNS names and transport locators. >Reason 1 for EIDs: "Homeless" Mobility > Problem: How does one create highly dynamic (EID or DNS name)-to-locator > mapping system? Oh, yes, I would like authentication as well... There are known techniques for building replicated databases. Since DNS servers are generally located in well-connected places and run on the hosts (i.e. not constrained CPU-wise) even complicated algorithms for maintaining consistency are feasible. The more interesting question is how to force expiration of name->locator map entries on hosts. Several techniques can be used: - special ICMP (host has moved) message which forces the immediate expiration of correspronding entries in the recipient's caches. It is probably a good idea *not* to supply new loactor in the message but have the host to query (already updated) domain name servers A router issuing the ICMP can also forward the packet to the new address. - explicit "change-of-address" notification from the host to be moved to DNS servers and all peers (i.e. all hosts who had established some kind of connection to the mobile host). - If a host has several consequtive timeouts trying to reach the destination in the middle of a session it may be a good idea to check with the name server before declaring the host unreacheable - DNS server on receipt of change-of-address request may send notifications to all hosts who had obtained the locator for the mobile host recently. I'm not sure this method is good, though. Also, DNS servers should actively maintain consistency (for example periodical mutual checks can be used). There is a big volume of literature on how to solve problems like that; and the single table case is rather trivial if compared to what distributed database people do when they need to maintain integrity and consistency of multiple simultaneously updated relations. >Reason 2 for EIDs: Scalable Provider-based Routing > In order to provide cost-effective global Internet connectivity, it's > necessary to minimize the number of routing entries in the global routing > tables. Probably the only way to do that is to use "optimal CIDR" -- i.e. maintain allocation of transport addresses to be as closely related to toplogy as possible. In ideal case one routing domain should announce only one route. Support for mobility in IPng automatically includes suppport for renumbering so changing from addresses obtained from one service provider to another's should not be a problem. (There is one small detail -- some provisions should be made to prevent large numbers of hosts from "moving" simultaneously. Probably something like secondary addresses can be used to maintain the connectivity during the transition period.) > While many organizations may desire to have "addressing autonomy" > (whereby their locator prefix is globally known to every transit-provider on > the planet), there will be distinct costs for maintaining such visibility. That's what we have now... Forcing people to renumber is practically impossible and movements of customes between service providers erode aggregation and greatly contribute to administrative headache (for example if some customer takes few networks out of our blocks and leaves for a different service provider i have to modify the filter lists at all exits to allow his specific routes to go thru; normally the specific routes existing inside the routing domain are blocked and only aggregates are allowed to leave). > The alternative will involve organizations using provider-based addresses > for their internal networks. Such addresses are prone to change as > organizations change Internet service providers, so again it would be best > if transport connections could survive the underlying change in network > locators. Right. > Problem: How does one provide for autoconfiguration of (EID or DNS-name) > to locator mappings? I guess in the same way as in case of changing locators for mobile hosts. > Where does the host get its EID or DNS > name from? Host knows his name -- actually it the only "state" the disconnected host should maintain. When host connects at the new place the first thing it does is to get a new locator from the closest address allocation server and then to contact his DNS server(s) and provide his new locator. > Oh, yes, how does the host authenticate itself during > autoconfiguration? Depends on the level of security. There can be some sort of challenge-reply protocol using strong cryptography. > Reason 3 for EIDs: Sane Network Administration > What the networks administrators really want to be able > to do is to rapidly add more network segments and to move servers, clients, > printers, etc. _without_ having to worry about which addresses are > valid on which wire. Again, the ability to dynamic assign locators and > simply update the (EID or DNS)-to-locator mapping would be highly valued. > Problem: How does one provide for authenticated, dynamic transport EID > (or DNS name)-to-locator services? Again, the problem is the same as in case of mobility -- and the solution should be the same. >My perspective is that mobility, portability, autoregistration, >and authentication need to be assumed as the "normal" case for IPng. I would say they should be *mandatory* part of IPng implementation. >If one considers that every host is going to be mobile, and require >authentication, and make use of autoregistration, then the need to >separate network locator information from transport layer connection >identification seems obvious. "Obvious" is a shorthand for "we don't really know". I'm trying to look closely at obvious things -- often they aren't. >I don't really care much whether DNS >names or short, numeric labels are used for transport connection >identification, as long as locators _aren't_ used for this purpose. What exactly do you mean by "transport connection identification"? If hosts maintain name-to-locator binding tables and those tables are updated when locator changes one way or another the locators aren't worse than any fixed identifiers. >The reason that I don't expect the IETF to adopt EIDs is simply because >we aspire to set of base features in IPng which is very minimal, and as >good engineers we're required to eliminate anything and everything which is >not required to get the job done. Yes, it is the good engineering (at least good software engineering). Minimalist approach is hard but is shown to produce better results. >Transport-level EIDs are not absolutely >required to get a segment from point A to point B, so they'll be left out. Given the dominant belief in EIDs i somehow doubt it. >If there was an architecture which provided each host with autoregistration, >mobility and authentication, then we might have a stronger need to separate >locator from EID functionality. This is the real problem -- to build a coherent architecture -- the actual format of the frames doesn't really matter much. >p.s. No, I don't believe in EID's being carried explicitely as part > of the internetwork header; I expect to find them in the first > few bytes of transport header. Well. i don't believe them present in headers at all. >p.p.s. Yes, I understand how large the resulting (network+transport) > header is, and the net impact on performance. No, I don't care, > and honestly believe that 98% of corporate america would be pleased > if you told them that you traded the performance impact for features > 1, 2, and 3 above. It still remains to be proven that mobility will require larger headers. I would rather say that with a careful design it should come nearly free in terms of impact on wasted bandwidth. Thanks. --vadim From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 19:18:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00672; Mon, 18 Jul 1994 19:05:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA13591; Mon, 18 Jul 1994 19:05:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA13583; Mon, 18 Jul 1994 18:55:29 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28666; Mon, 18 Jul 1994 18:13:42 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14723(1)>; Mon, 18 Jul 1994 01:13:27 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 18 Jul 1994 01:13:17 -0700 To: sipp@sunroff.eng.sun.com, ipng@cmf.nrl.navy.mil, big-internet@munnari.OZ.AU Cc: deering@parc.xerox.com Subject: SIPP-16 draft Date: Mon, 18 Jul 1994 01:13:15 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul18.011317pdt.12171@skylark.parc.xerox.com> I have submitted a new version of the SIPP spec, with 16-byte addresses, as an Internet Draft. If you want to grab a copy before it shows up in the official directories, you can get it from: ftp://parcftp.xerox.com/pub/sipp/draft-ietf-sipp-spec-01.txt Besides the change of address size, a number of other changes were made, arising from the implementors' meeting in Seattle and subsequent events. Be sure to read through Appendix B to find out everything that changed since the last draft. Steve From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 19:21:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00703; Mon, 18 Jul 1994 19:07:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA13606; Mon, 18 Jul 1994 19:07:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA13586; Mon, 18 Jul 1994 19:00:06 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00434; Mon, 18 Jul 1994 18:59:53 +1000 (from kre@munnari.OZ.AU) To: Vadim Antonov Cc: big-internet@munnari.OZ.AU Subject: On the matter of proofs In-Reply-To: Your message of "Sun, 17 Jul 1994 13:53:36 -0400." <199407171753.NAA08603@titan.sprintlink.net> Date: Mon, 18 Jul 1994 18:59:49 +1000 Message-Id: <28535.774521989@munnari.OZ.AU> From: Robert Elz Date: Sun, 17 Jul 1994 13:53:36 -0400 From: Vadim Antonov Message-ID: <199407171753.NAA08603@titan.sprintlink.net> I do not want to explore "positive" proofs on useability of networks w/o EIDs simply because "negative" proof is much easier in this case; i.e. if somebody will come up with an example of a situation where EIDs bring an unquestionable advantage over the EID-less scheme the question with EID-less schemes will be closed. Let's think like engineers, not like politicans. And in another message ... Date: Sun, 17 Jul 1994 18:03:01 -0400 From: Vadim Antonov Message-Id: <199407172203.SAA09152@titan.sprintlink.net> There are definitely some clinical cases; the rest can be convinced by "evidence beyond the reasonable doubt". The problem we're having (or a problem) is that you're thinking like neither an engineer nor a politician (and not a lawyer either) - you're thinking like the mathemetician you say that you are (and I believe). Unfortunately the world is not always (or even often) like mathematics, and proofs are almost never available. Lets take a real world example, on an entirely different example. Assume we're planning an outdoor party for next weekend, we have to send out the invitations today. If its going to rain next weekend then the party would be a total waste, and we shouldn't have it, on the other hand if its not going to rain, then it will be a great event and a lot of fun. Now we have three approaches to take in deciding whether we are going to send the invitations today. 1) Prove it won't rain next weekend, if we can't do that then we should abandon the idea, the party will cost us, whether we have it or not, if we don't know for certain that it will happen, then the cost is too much. 2) Prove it will rain next weekend, if we can't do that, then go ahead and hold the party, as even though it will cost, the benefits in frienship, buttering up the boss, convincing the neighbours not to object to the new shed, ... 3) Ignore all this proof nonsense, take a look at the probabilities, evaluate the risk, set that off against the potential benefits, and come to a decision based on all the available information, without expecting anything to be beyond a reasonable doubt. wrt EIDs you're adopting approach 1. I (and others) could easily adopt approach 2, and demand that you prove that EIDs aren't useful. We know you can't, or you would have, and ended all the arguments. Instead, most of us on this list, and others, instead adopt the more reasonable approach 3. We sometimes differ on our opinions of the result of the evaluation, but most of us approach it upon a reasonable basis. Proofs are demanded by mathemeticians, and by petulant children who don't want to accept something, but can't think of a good reason why not ("prove it to me"). I won't reply in detail to your messages today, others have done that already. I do wonder however why you didn't make any comment about the example regated to making transport connections acorss multiple network layers, while you still demand examples on where EIDs are useful, which seems odd. kre From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 19:57:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01241; Mon, 18 Jul 1994 19:26:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA13654; Mon, 18 Jul 1994 19:25:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA13635; Mon, 18 Jul 1994 19:19:27 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00903; Mon, 18 Jul 1994 19:15:10 +1000 (from kre@munnari.OZ.AU) To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Subject: Re: Globally visible MAC addreses In-Reply-To: Your message of "Sun, 17 Jul 1994 14:30:42 GMT." <2863.bill.simpson@um.cc.umich.edu> Date: Mon, 18 Jul 1994 19:15:06 +1000 Message-Id: <28547.774522906@munnari.OZ.AU> From: Robert Elz Date: Sun, 17 Jul 94 14:30:42 GMT From: "William Allen Simpson" Message-ID: <2863.bill.simpson@um.cc.umich.edu> On the other hand, his objection is to Identifiers. They _DO_ violate location privacy. They move without changing. That's the whole point! No, they *can* move without changing, they don't have to. The amount of privacy with respect to someone wanting to track your movements is under your control. You can change you identity often, and keep better privacy if you wish, which would have a cost, including the inability to retain connections acorss identity changes (but that would be a requirement anyway, or the other ends of your connections would know you had moved and where). Or you can allow others to see your movements. kre From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 19:57:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01331; Mon, 18 Jul 1994 19:28:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA13669; Mon, 18 Jul 1994 19:28:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA13638; Mon, 18 Jul 1994 19:19:49 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00729; Mon, 18 Jul 1994 19:10:46 +1000 (from kre@munnari.OZ.AU) To: Simon Poole Cc: big-Internet@munnari.OZ.AU Subject: Re: EID's in the packets In-Reply-To: Your message of "Sun, 17 Jul 1994 18:49:12 +0200." <199407171655.SAA05449@chsun.eunet.ch> Date: Mon, 18 Jul 1994 19:10:22 +1000 Message-Id: <28541.774522622@munnari.OZ.AU> From: Robert Elz Date: Sun, 17 Jul 1994 18:49:12 +0200 (MET DST) From: Simon Poole Message-ID: <199407171655.SAA05449@chsun.eunet.ch> The question is should EID's be simple node id's or shouldn't we take the model further? As has been suggested: "the telnet process on node X", or "the telnet process on node X owned by user Y" being allocated an EID? The nice thing about EIDs as proposed, is that they name the most general entity that can reasonably be named. Given that name its easy, if and when we should want to, and after the details are worked out, to name any more specific things that need names - perhaps even using the EID for nothing more than forming other names in the long term. Those names can be names of specific processes, names of transactions, names of database records. If we construct as the basic name the name of (say) a particular connection then there's no reasonable way to go from that to the name of some unrelated object - we'd have to construct a whole new namespace. [On a comment I made...] Did I say anything else? Probably not, and I don't think I claimed that you did, however I rarely waste the opportunity to spread as much of the good word as I can possibly cram into every message... I do not believe that identification of a specific node is a particulary useful definition of "identity" in a networking context. "Node" isn't quite what EIDs name, however that aside, I disagree, for the same reason above. While the identity of a node may not be very useful of itself, it provides a frame of reference for identifying the objects whose identity is intrinsically useful. kre From owner-Big-Internet@munnari.OZ.AU Mon Jul 18 21:05:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03923; Mon, 18 Jul 1994 21:05:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA13764; Mon, 18 Jul 1994 21:05:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA13746; Mon, 18 Jul 1994 20:54:25 +1000 Precedence: list Received: from chsun.eunet.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02698; Mon, 18 Jul 1994 20:16:52 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id MAA26193; Mon, 18 Jul 1994 12:21:00 +0200 Message-Id: <199407181021.MAA26193@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <26449-0@magnolia.eunet.ch>; Mon, 18 Jul 1994 11:24:31 +0200 Subject: Re: EID's in the packets To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 18 Jul 1994 11:24:28 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU, poole@magnolia.eunet.ch, jnc@ginger.lcs.mit.edu In-Reply-To: <9407171925.AA28799@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 17, 94 03:25:29 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1301 From: Simon Poole Sender: poole@magnolia.eunet.ch Noel writes: > If you will recall, the basic architectural principal of TCP (which > distinguished it from NCP) was that all the "critical" state for a connection > was co-located with the application; the "fate-sharing principle". I reckon > that it is the regions of fate-sharing that we need to name, since they are > *the* fundamental objects of end-end communication. (End-end and fate-sharing > are really just two sides of one coin.) > > Seen through this perception, it's really only useful, at this level, to name > a given process separately *if it is a fatesharing region*. If my Unix box > crashes, all the processes are going to go together, so there's no reason to > name them separately to the network, at this level. It may well be useful > to name "the Telnet process on node X", but this is an *application level* > name, and needs to be *translated* to lower-level names (such as address, > port, etc) to be useful. It would seem as if the first and second paragraphs are somewhat at odds with eachother. By associating the EID with a specific part of hardware, you are actually -defining- a minimal fate-sharing region at the granularity of that specific machine, by -not- doing this, you could actually allow process to be migrated from machine to machine and so on. Simon From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 00:11:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07320; Mon, 18 Jul 1994 23:05:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA13878; Mon, 18 Jul 1994 23:05:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA13873; Mon, 18 Jul 1994 23:04:37 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06751; Mon, 18 Jul 1994 22:48:05 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 18 Jul 94 21:39:07 +0900 From: Masataka Ohta Message-Id: <9407181239.AA06427@necom830.cc.titech.ac.jp> Subject: Re: EID's in the packets To: poole@magnolia.eunet.ch (Simon Poole) Date: Mon, 18 Jul 94 21:39:05 JST Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, poole@magnolia.eunet.ch In-Reply-To: <199407181021.MAA26193@chsun.eunet.ch>; from "Simon Poole" at Jul 18, 94 11:24 am X-Mailer: ELM [version 2.3 PL11] > > Seen through this perception, it's really only useful, at this level, to name > > a given process separately *if it is a fatesharing region*. If my Unix box > > crashes, all the processes are going to go together, so there's no reason to > > name them separately to the network, at this level. It may well be useful > > to name "the Telnet process on node X", but this is an *application level* > > name, and needs to be *translated* to lower-level names (such as address, > > port, etc) to be useful. > > It would seem as if the first and second paragraphs are somewhat > at odds with eachother. By associating the EID with a specific > part of hardware, you are actually -defining- a minimal fate-sharing > region at the granularity of that specific machine, Agreed. A host is a fate sharing region in a sense that if the host crashes, all the application processes running on it also crashes. An application process is also a fate sharing region in a sense that if the process crashes, all the transport level connections of the application also crashes. A subnet is also a fate sharing region in a sense that if the routing information to the subnet is lost, all the connections to hosts in the subnet also crashes. So, in his case, Noel should say "location sharing region" than "fate sharing region", which clarifys the relationship between EID and locator. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:04:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10350; Tue, 19 Jul 1994 00:25:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA14113; Tue, 19 Jul 1994 00:25:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA13969; Tue, 19 Jul 1994 00:14:59 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09985; Tue, 19 Jul 1994 00:14:54 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA04636; Mon, 18 Jul 1994 16:14:21 +0200 Message-Id: <199407181414.AA04636@mitsou.inria.fr> To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Subject: Re: EID's in the packets In-Reply-To: Your message of "Mon, 18 Jul 1994 21:39:05 +0200." <9407181239.AA06427@necom830.cc.titech.ac.jp> Date: Mon, 18 Jul 1994 16:14:20 +0200 From: Christian Huitema => A subnet is also a fate sharing region in a sense that if the routing => information to the subnet is lost, all the connections to hosts in the => subnet also crashes. No sir. And that is precisely the point of the end to end argument. If the host is multi-homed, the connection can survive. If waiting a minute or two for the network to come back is acceptable, the connection can survive. Your mention of the "process" as a unit is interesting. If the process could actually survive a crash of the host, e.g. if process migration techniques and other distributed systems tools were adopted, then we should use the process, rather than the host, as the unit of "fate sharing". Christian Huitema From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:13:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10375; Tue, 19 Jul 1994 00:27:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA14132; Tue, 19 Jul 1994 00:27:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA13966; Tue, 19 Jul 1994 00:14:42 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08704; Mon, 18 Jul 1994 23:55:05 +1000 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id GAA14123; Mon, 18 Jul 1994 06:54:56 -0700 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA14310; Mon, 18 Jul 94 07:54:23 -0600 Date: Mon, 18 Jul 94 07:54:23 -0600 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9407181354.AA14310@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: On the matter of proofs >From: kre@munnari.oz.au (Robert Elz) > ... > I do wonder however why you didn't make any >comment about the example [related] to making transport connections >acorss multiple network layers, while you still demand examples >on where EIDs are useful, which seems odd. Perhaps he is as unconvinced of the practical utility of the example as I am. Converting among protocols as you proposed strikes me as unlikely to work in real life. My impression is that the few cases where people have done such things have "proven" more about why it's not a good idea in practice than anything else. I substantially have more than 1 or 2 years of graduate math training from a solid school. (I was most interested in algebraic topology and foundations). I have been amused by the talk of proofs in this mailing list. Some have started with lists of assumptions that seem generally plausible to me but that seem contrary to the assumptions of other writers in this mailing list, and thus unlikely to change many minds. The talk of proofs with explicit references to math seems too similar to ancient computer "science" foolishness like proofs of (program) correctness. Those were simply mechanically generated arguments (not math proofs) that two programs compute approximately the same answers, one in a more or less standard computer language and other a hard to read or write "specification." For decades I grumbled that if the spec is so wonderful, then just compile and run it, and forget the standard representation. Math graduate school (at least for a research doctorate) is supposed to give you two things. First is an acquaintance with the major results in most of math. Second is "mathematical maturity." That is the skill to recognize what is almost certainly true ("truth" only as agreed by your peers), or equivalently, to know what needs to be written down in your proofs and what is "obvious" and should be omitted or at most mentioned in passing. Math maturity depends in part on that first thing, an acquaintance with much of math to help inform your sense of what is obvious. Mature mathematicians know that a math "proof" is only a careful piece of rhetoric that follows a bunch of rigid but unwritten rules and whose purpose is to convince other mature mathematicians. Math maturity is simply the result of an apprenticeship in reading and writing that special rhetoric (and perhaps a little talent). A real math proof is not something you can feed to your favorite thereom proving program. A math proof is a political tract, sort of an honest legal brief--honest because you cannot ignore unfavorable precedents. Math rhetoric includes explicitly listing some of your assumptions at the start, but only the "interesting" assumptions. For example, very rarely is the axiom of choice explicitly assumed or not used, despite the fact that it is an idea that some respected people say is nonsense. Listing assumptions is the main virtue of math "proofs" in non-technical discussions such as this. (Non-technical as far as math is concerned.) Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:16:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12233; Tue, 19 Jul 1994 01:25:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA14211; Tue, 19 Jul 1994 01:25:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA14192; Tue, 19 Jul 1994 01:22:28 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12071; Tue, 19 Jul 1994 01:22:13 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEUJSRKE2O000KUI@FNAL.FNAL.GOV>; Mon, 18 Jul 1994 10:21:53 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA26995; Mon, 18 Jul 94 10:21:25 CDT Date: Mon, 18 Jul 1994 10:21:25 -0500 From: Matt Crawford Subject: Re: EID's in the packets In-Reply-To: Your message of Fri, 15 Jul 94 18:44:12 EDT. <9407152246.AA21504@munin.fnal.gov> To: Charles Lynn Cc: big-internet@munnari.OZ.AU Message-Id: <9407181521.AA26995@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Charlie, I must have obfuscated my point. I was trying to show that EIDs do not have to be in all packets. To establish this point I was assuming that a port number (or its equivalent) would be in all packets, and could change when an endpoint moved to a different location. Here's another argument why we should not want EIDs in all packets. Since we have gotten along without EIDs so far, then for some considerable time after IPng deployment, most applications will not need EIDs. (Pardon my analogy, but after the discovery of relativity, Newtonian mechanics remained adequate for most purposes.) If you accept the argument that this bit-consuming feature will usually not be exercised, then it doesn't belong in all packets, any more than fragmentation or source-routing information does. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:16:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12262; Tue, 19 Jul 1994 01:27:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA14228; Tue, 19 Jul 1994 01:27:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA14189; Tue, 19 Jul 1994 01:14:39 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11946; Tue, 19 Jul 1994 01:14:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02674; Mon, 18 Jul 94 11:14:12 -0400 Date: Mon, 18 Jul 94 11:14:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407181514.AA02674@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Simon Poole By associating the EID with a specific part of hardware, you are actually -defining- a minimal fate-sharing region at the granularity of that specific machine, by -not- doing this, you could actually allow process to be migrated from machine to machine and so on. That was just an example. It doesn't make sense to name processes if they can't migrate. In my reply to Christian, I said that fate-sharing-regions are networking concepts, which you have to map to concepts from other areas of information systems work. Exactly which mappings will make sense vary depending on the circumstances. From: Masataka Ohta An application process is also a fate sharing region in a sense that if the process crashes, all the transport level connections of the application also crashes. In a sense, yes. But what good does it do to give it a separate name, as opposed to having it share a name (and a demultiplexing space) with other similar entities? One of the points of names for these things is to allow the binding from that name, to other names such as locators, to be changed. If I have N names of type A which are all bound to 1 name of type B, and I rebind them all to a different name of type B, and they always get changed together like that, there's little use there to having N names, I could have just had one. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:18:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12298; Tue, 19 Jul 1994 01:28:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA14243; Tue, 19 Jul 1994 01:28:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA14195; Tue, 19 Jul 1994 01:23:32 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12089; Tue, 19 Jul 1994 01:23:24 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA04813; Mon, 18 Jul 1994 17:24:11 +0200 Message-Id: <199407181524.AA04813@mitsou.inria.fr> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: EID's in the packets In-Reply-To: Your message of "Mon, 18 Jul 1994 10:57:46 EDT." <9407181457.AA02574@ginger.lcs.mit.edu> Date: Mon, 18 Jul 1994 17:24:09 +0200 From: Christian Huitema Noel, => A fate-sharing region is a *networking* concept. You can map it (either => conceptually, or in real systems) to other information system concepts, but => it's just a mapping. It doesn't *make* a FSR one of those other concepts. A lot of the research on new transmission control protocols (i.e. mine :-) pushes towards "states and decisions in the process" rather than "states in decision in a separate transport machine". An example of state which is well kept in the project is whether packet number 25 has been acknowledged or not; the decision to retransmit or not is taken by the process (do I really need the answer?). I dont see why I should disallow process mobility by requiring that the connections are identified by a "host ID". This does not mean that I need "internet addresses per process" or that we should do away with the "host" concept. After all, there is pretty little process mobility in today's systems. I could imagine that if the process moves it becomes awareof its new "locator", or whatever this is. This to say that the "end point identifier" concept depends a lot of what is the end point (process, host). IMHO this is still a fuzzy concept. We believe it will be used to identify "transport connections" (lets not dig the "what is transport anyway" rathole now), independently of the "position in the network. Looks like a transport level concept. But we don't know when you need it (all packets or some), nor where (an IP option, a security layer, a TCP option). Until this usage is precised and quantified, how could we decide that "short binary" is better than e.g. "DNS name"? Christian Huitema From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:25:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16220; Tue, 19 Jul 1994 03:25:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14447; Tue, 19 Jul 1994 03:25:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14430; Tue, 19 Jul 1994 03:23:18 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16041; Tue, 19 Jul 1994 03:23:13 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA02987; Mon, 18 Jul 1994 10:21:28 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Jul 1994 10:21:31 -0700 To: Barney Wolff From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPng and .... Firewalls! Cc: "Robert G. Moskowitz" <0003858921@mcimail.com>, big internet At 6:27 PM 7/17/94, Barney Wolff wrote: >If EID==DNSname, a system can have a "public" name and a "private" one, I'm not sure I understand the willingness to have IP addresses known but DNS names not. Nonetheless, the revised DNS-based transport control exchange that I described over the weekend very much lets the users of the control protocol choose any name they want. It does not have to be in the public DNS, though it had better be unique. Hence, Barney's assertion is quite true. ----- Dave Crocker +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:26:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16238; Tue, 19 Jul 1994 03:26:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14464; Tue, 19 Jul 1994 03:26:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14404; Tue, 19 Jul 1994 03:06:04 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11379; Tue, 19 Jul 1994 00:59:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02574; Mon, 18 Jul 94 10:57:46 -0400 Date: Mon, 18 Jul 94 10:57:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407181457.AA02574@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Christian Huitema If the process could actually survive a crash of the hos ... then we should use the process, rather than the host, as the unit of "fate sharing". I think this is going down the wrong path. A process is a concept from a whole different area of information systems, and it doesn't make sense to try and use it to describe a networking concept; it's sort of like trying to decide whether to make a process the unit of stream connectivity. A fate-sharing region is a *networking* concept. You can map it (either conceptually, or in real systems) to other information system concepts, but it's just a mapping. It doesn't *make* a FSR one of those other concepts. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:27:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16275; Tue, 19 Jul 1994 03:27:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14481; Tue, 19 Jul 1994 03:27:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14424; Tue, 19 Jul 1994 03:19:37 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13446; Tue, 19 Jul 1994 02:11:49 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Jul 94 01:01:59 +0859 From: Masataka Ohta Message-Id: <9407181602.AA07242@necom830.cc.titech.ac.jp> Subject: Re: EID's in the packets To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Date: Tue, 19 Jul 94 1:01:58 JST Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199407181524.AA04813@mitsou.inria.fr>; from "Christian Huitema" at Jul 18, 94 5:24 pm X-Mailer: ELM [version 2.3 PL11] > Until this usage is precised and quantified, how could we decide that > "short binary" is better than e.g. "DNS name"? Until you have precised understanding on the internetwork and the transport layer, it is impossible, of course. > We believe > it will be used to identify "transport connections" (lets not dig the "what is > transport anyway" rathole now), independently of the "position in the > network. Your misunderstanding is that the internetwork layer is only for locating something. So, don't think everything with location independece is automatically above the internetwork layer. Actually, the internetwork layer has two roles, to locate hosts and to identify hosts. The fact is exemplified by the current proposal of mobile WG, where mobile host address does have location independence. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:28:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16341; Tue, 19 Jul 1994 03:28:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14503; Tue, 19 Jul 1994 03:28:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14421; Tue, 19 Jul 1994 03:18:25 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13094; Tue, 19 Jul 1994 01:59:01 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEUL3NP3B4000L6I@FNAL.FNAL.GOV>; Mon, 18 Jul 1994 10:58:55 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA27120; Mon, 18 Jul 94 10:58:26 CDT Date: Mon, 18 Jul 1994 10:58:25 -0500 From: Matt Crawford Subject: Re: summary of Big-Internet messages In-Reply-To: Your message of Sun, 17 Jul 94 16:05:43 +0200. <9407170705.AA00233@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Message-Id: <9407181558.AA27120@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > > I think the proper way to find out identity, given location, > > is to send a query to the location. > > 1: And you will receive another query asking your identity. Goto 1). Why will you receive another query? Maybe the target doesn't care who I am before giving out its identifier. Or maybe I included my own identifier (possibly with authenticating information) in the query. > BTW. Locators are not assured to be reversible. What does this mean? That you can't send your reply to the locator that appears in my request? Barring the possibility that I did a migration while my request was outstanding, why would this be so? And even the possibility of migration during an outstanding request can be solved if something provides forwarding for a short interval following the migration. > > This requires that the > > destination identifier not be a mandatory part of all packets. > > It will be useful to locate a destination within a subnet. Will it? This is not at all obvious to me. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 03:29:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14813; Tue, 19 Jul 1994 02:46:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA14372; Tue, 19 Jul 1994 02:45:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14308; Tue, 19 Jul 1994 02:27:16 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13886; Tue, 19 Jul 1994 02:27:13 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEUM3LIEKW000I6D@FNAL.FNAL.GOV>; Mon, 18 Jul 1994 11:27:06 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA27226; Mon, 18 Jul 94 11:26:38 CDT Date: Mon, 18 Jul 1994 11:26:38 -0500 From: Matt Crawford Subject: Re: Constructive Proof on why 8 byte EID is enough In-Reply-To: Your message of Sun, 17 Jul 94 16:31:05 +0800. <9407170731.AA00320@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Message-Id: <9407181626.AA27226@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > Are there any flaw in the proof? Yes. Flaw #1 -- You have not stated any assumption about what an EID names. Thus I don't know if we agree on how many will be needed. I say a separate EID is needed for each group of processes whose location may change independently of other groups. A system which never migrates processes out to other systems needs, in my view, just one EID. But a system which can originate 2^10 process-groups, each of which could be migrated independently, needs at least 2^10 EIDs. (And if those processes live a long time after migration, the originating system may be starved for more EIDs for new processes.) It doesn't take many such systems to blow away your two-byte bottom level space. Flaw #2 -- "Upper 4 bytes of EID is managed by Internic to national NICs with 100% utilization." Show me how this is feasible. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 04:01:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16928; Tue, 19 Jul 1994 03:47:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14583; Tue, 19 Jul 1994 03:46:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14492; Tue, 19 Jul 1994 03:28:17 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16307; Tue, 19 Jul 1994 03:28:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04091; Mon, 18 Jul 94 13:27:57 -0400 Date: Mon, 18 Jul 94 13:27:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407181727.AA04091@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, poole@magnolia.eunet.ch Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu >> By associating the EID with a specific part of hardware, you are >> actually -defining- a minimal fate-sharing region at the granularity of >> that pecific machine, by -not- doing this, you could actually allow >> process to be migrated from machine to machine and so on. > That was just an example. It doesn't make sense to name processes if they > can't migrate. Circular argument? Either we have an EID concept that allows this and then we can potentially migrate processes* or we tie EID's to a internetwork (or if you wish: transport layer) abstraction that doesn't allow it. Sorry, we're apparently not communicating clearly, and having yet another violent agreement. (Occupational disease on Big-I...) I was just trying to say that you don't *have* to associate the EID with a specific piece of hardware; you would only do so *if* it made sense for your particular situation. In other situations (e.g. mobile processes), it might make sense to associate the EID with a process. Etc, etc. Through all this, machines and processes are things which exist, *whether or not they have EID's*. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 04:06:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17599; Tue, 19 Jul 1994 04:06:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA14616; Tue, 19 Jul 1994 04:05:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14610; Tue, 19 Jul 1994 03:58:50 +1000 Precedence: list Received: from [146.228.10.15] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15945; Tue, 19 Jul 1994 03:18:05 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id TAA16225; Mon, 18 Jul 1994 19:21:01 +0200 Message-Id: <199407181721.TAA16225@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <06102-0@magnolia.eunet.ch>; Mon, 18 Jul 1994 19:15:01 +0200 Subject: Re: EID's in the packets To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 18 Jul 1994 19:14:58 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9407181514.AA02674@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 18, 94 11:14:12 am X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 910 From: Simon Poole Sender: poole@magnolia.eunet.ch > From: Simon Poole > > By associating the EID with a specific part of hardware, you are actually > -defining- a minimal fate-sharing region at the granularity of that > specific machine, by -not- doing this, you could actually allow process to > be migrated from machine to machine and so on. > > That was just an example. It doesn't make sense to name processes if they > can't migrate. Circular argument? Either we have an EID concept that allows this and then we can potentially migrate processes* or we tie EID's to a internetwork (or if you wish: transport layer) abstraction that doesn't allow it. We can then add YALI (yet another layer of indirection) with a application layer EID to get the functionallity to do this and argue another two years about the correct size. Simon * this is just one application where I can see the usefulness of an EID. From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 04:07:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17694; Tue, 19 Jul 1994 04:07:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA14633; Tue, 19 Jul 1994 04:07:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14613; Tue, 19 Jul 1994 03:59:39 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17375; Tue, 19 Jul 1994 03:59:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04517; Mon, 18 Jul 94 13:58:12 -0400 Date: Mon, 18 Jul 94 13:58:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407181758.AA04517@ginger.lcs.mit.edu> To: 0003858921@mcimail.com, big-internet@munnari.OZ.AU Subject: Re: EIDs and 2 cards on a segment... Cc: jnc@ginger.lcs.mit.edu From: "Robert G. Moskowitz" <0003858921@mcimail.com> But then I remembered that some of those devices have two interfaces on one segment... Yes, with IPv4, this does not always work. ... The problem with IPng were EID identifies the system and locator the segment, these two interfaces would be undistiguisable. I'd ASSUME only one would be in the ARP tables of other devices on the segment, but which one? Also how would the internal machine decide which interface to use? Yup. Which is why I don't like using EID's to name *interfaces*, which is what you are trying to name there. Interfaces deserves full names (i.e. complete locators, including interface name) of their own, so the last-hop router can send packets to them without a lot of foo-far-ah. To my mind, this also includes having the physical address in the locator, *especially*in the cases where it's an ATM E.164 address; the thought of having to do ARP, or something ARP-like, for things like that is ludicrous. Just put the physical address in the locator and be done with it. No "small number allocation" hassles, no "lookup directory" hassles, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 05:58:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16360; Tue, 19 Jul 1994 03:29:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14518; Tue, 19 Jul 1994 03:29:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14427; Tue, 19 Jul 1994 03:20:16 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13756; Tue, 19 Jul 1994 02:19:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03129; Mon, 18 Jul 94 12:19:17 -0400 Date: Mon, 18 Jul 94 12:19:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407181619.AA03129@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, crawdad@munin.fnal.gov Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Matt Crawford Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14535; Tue, 19 Jul 1994 03:30:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14407; Tue, 19 Jul 1994 03:06:30 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10823; Tue, 19 Jul 1994 00:41:35 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 18 Jul 94 23:33:08 +0900 From: Masataka Ohta Message-Id: <9407181433.AA06858@necom830.cc.titech.ac.jp> Subject: Re: EID's in the packets To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Date: Mon, 18 Jul 94 23:33:05 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <199407181414.AA04636@mitsou.inria.fr>; from "Christian Huitema" at Jul 18, 94 4:14 pm X-Mailer: ELM [version 2.3 PL11] > => A subnet is also a fate sharing region in a sense that if the routing > => information to the subnet is lost, all the connections to hosts in the > => subnet also crashes. > > No sir. And that is precisely the point of the end to end argument. If the > host is multi-homed, the connection can survive. If waiting a minute or two > for the network to come back is acceptable, the connection can survive. OK. To be more precise, A subnet is also a fate sharing region in a sense that if the routing information to the subnet is lost for a considerable amount of time, all the connections to hosts inside the subnet also crashes. So, a multi-homed host which is located on the surface of a subnet may be able to survive. But, then, if the multi-homed host is acting as a router (why not?), the routing information won't be lost. So, I think your point is not so interesting. Anyway, I think an EID may belong to an interface, not necessarily to a host. But I want to be neutral here. > Your mention of the "process" as a unit is interesting. If the process could > actually survive a crash of the host, e.g. if process migration techniques and > other distributed systems tools were adopted, then we should use the process, > rather than the host, as the unit of "fate sharing". What is important with "process migration" is "application rubustness". An application may consists of multiple processes and a process may have multiple transport connections (I intentionally said "an application process" for simplicity). From the end user's point of view, identity of applications should be assured. Difference of identities of "fate sharing" processes can and should be absorbed by the application layer. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 05:59:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16427; Tue, 19 Jul 1994 03:32:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14552; Tue, 19 Jul 1994 03:32:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14433; Tue, 19 Jul 1994 03:25:00 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14606; Tue, 19 Jul 1994 02:41:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03361; Mon, 18 Jul 94 12:40:57 -0400 Date: Mon, 18 Jul 94 12:40:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407181640.AA03361@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Christian Huitema > A fate-sharing region is a *networking* concept. You can map it ... to > other information system concepts, but it's just a mapping. A lot of the research on new transmission control protocols ... pushes towards "states and decisions in the process" ... I dont see why I should disallow process mobility by requiring that the connections are identified by a "host ID". I think we're having a violent agreement. I'm not trying to do that; in fact, process mobility is one of the potential applications I see for a name for fate-sharing entities (endpoints). A mobile process would have its own distinct endpoint name, and wherever it goes, it takes that with it. What those names look like, and what goes in what packets, I'm still musing about, but I am sure we need to name these things, and that end-end tranport connections (which are, by definition, between endpoints) should use those endpoint names as part of the name of the connection. (KRE's message of Mon, 18 Jul 1994 19:10:22 +1000 said this last part better than I have! :-) Looks like a transport level concept. No. It lives in between the toplogical internetwork-level names, and transport; it indetifies a thing that can have many different tranport thigns running at the same time. I packaged it in with the internetwork layer since that is the one *ubiquitous* layer that everything else is built on, and this concept is similarly fundamental. But we don't know when you need it ... Until this usage is precised and quantified, how could we decide that "short binary" is better than e.g. "DNS name"? Well, again, I agree. Unfortunately, we are under a lot of pressure to i) pick one design, instead of experimenting with several (which would provide invaluable *real* experience, as opposed to just thinking about it, something that makes me nervous), and ii) do so in a hurry. Those are the ground-rules we have to work with, though. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 06:06:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22062; Tue, 19 Jul 1994 06:06:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA14756; Tue, 19 Jul 1994 06:05:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA14751; Tue, 19 Jul 1994 06:01:17 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21935; Tue, 19 Jul 1994 06:01:09 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEUTJVHDKW000N06@FNAL.FNAL.GOV>; Mon, 18 Jul 1994 15:01:03 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA28022; Mon, 18 Jul 94 15:00:31 CDT Date: Mon, 18 Jul 1994 15:00:30 -0500 From: Matt Crawford Subject: Re: EID's in the packets In-Reply-To: Your message of Mon, 18 Jul 94 12:19:17 EDT. <9407181619.AA03129@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Message-Id: <9407182000.AA28022@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > Since we have gotten along without EIDs so far, then for some > considerable time after IPng deployment, most applications will not > need EIDs. > > Nope. For *example* (and I stress that this is just an *example* of a use of > EID's), any existing application which is talking to a mobile machine might > need EID's as part of a mobility mechanism, if such a mechanism used EID's. OK, I should have said either "most applications won't need EIDs most of the time," or, more succinctly, "most packets won't need EIDs." Now if you want to say "most packets don't need locators" and your argument depends on having EIDs present, while I say most packets don't need EIDs and my argument depends on locators, we could both be right, but our schemes are incompossible. If we can omit both by exploiting some other field(s), then maybe ... > One of the charms of EID's is that they allow you to add all this stuff > without massive upheavals to TCP. Ah, but I can get all those charms if + EIDs are optionally passed in the SYN phase, or other analogous setup time. No EID passed implies one is concocted by the receiver (based on the locator perhaps) and certain capabilities are not available during the lifetime of the connection. + The internet layer, or some shim between internet and transport, caches the EID and provides it to the transport layer with each received packet. + This layer can handle whatever messages go along with change of location, making that as invisible as desired to the upper layers. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 07:04:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22708; Tue, 19 Jul 1994 06:25:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA14799; Tue, 19 Jul 1994 06:25:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA14783; Tue, 19 Jul 1994 06:21:16 +1000 Precedence: list Received: from [128.162.19.7] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19619; Tue, 19 Jul 1994 05:00:09 +1000 (from dab@berserkly.cray.com) Received: from frenzy.cray.com (frenzy-eth.cray.com) by cray.com (Bob mailer 1.3) id AA13783; Mon, 18 Jul 94 13:58:43 CDT Received: by frenzy.cray.com id AA05648; 4.1/CRI-5.6; Mon, 18 Jul 94 14:01:06 CDT Date: Mon, 18 Jul 94 14:01:06 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9407181901.AA05648@frenzy.cray.com> To: avg@sprint.net, Greg_Minshall@novell.com, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets Cc: big-internet@munnari.OZ.AU > >If at the end of parsing the IP address, IP encounters a protocol type, and > >*then* encounters an EID, then the *protocol type* has identified a name > >space in which the EID has meaning; the EID, in turn, identifies a name > >space (interpreted by the transport protocol instance bound to that EID) in > >which ports have meaning. > > On the second thought, if ports are 1:1 to sockets there is NO need > to carry protocol number in the packets! Simply because all > (sane) packets arriving to a port will all have the same protocol. This only works if you assume that all protocols will have the same type of port number, and that all port numbers from all protocols will be allocated out of the same address space. That kind of hampers future expansion and addition of new protocols... Keep the port number space up in the transport protocol where it belongs, on an end-to-end basis. > Killing well-known port numbers will also kill assigned protocol > numbers and the associated headache. And instead you get to manage assigned protocol names. You need *something* that is well known, it's just a question of at which layer you want to have it. Today we all agree that File Transfer can be found on TCP port 21. Without well-known port numbers, we'd have to all agree, for instance, that the well known name for File Transfer is the string "FTP". And then my machine would have to find out what port number your machine has assigned to "FTP" so that I can talk to it. The only advantage of well-known names versus well-known ports is that the range of well-known ports (in TCP and UDP) is limited, where as well-known names wouldn't be bound by that limit. > No EIDs, no assinged protocol numbers, straightforward support for > process mobility and connection forwarding -- i think it worth > some further consideration. And now in addition to going to the DNS to get the address for your machine, I then need to talk to your machine to find out what port to use to access the service that I want, or else I have to go to a DNS like system to get that mapping. But I might not be able to use DNS, because I'd expect the volitilty of dynamic name to port assignment to be at least an order of magnitude higher than that of host name to address bindings. Or if you don't like the overhead of having a name->protocol server, perhaps we could just all have one well-known port. Every one would connect to it, send across the well-known name, and then both sides would switch over to the designated protocol. Oh, that's what RFC 1078 does, and it only works for TCP... ;-) > --vadim Let's just leave transport layer addressing out of the internet layer. There's more than enough items to argue about without adding that to the mix... -David Borman, dab@cray.com From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 07:05:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23920; Tue, 19 Jul 1994 07:05:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA14843; Tue, 19 Jul 1994 07:05:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA14838; Tue, 19 Jul 1994 07:01:18 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23805; Tue, 19 Jul 1994 07:01:15 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA04662; Mon, 18 Jul 1994 14:01:06 -0700 Message-Id: <199407182101.OAA04662@Mordor.Stanford.EDU> To: Matt Crawford Cc: big-internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: EID's in the packets... NOT Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 18 Jul 94 15:00:30 -0500. <9407182000.AA28022@munin.fnal.gov> Date: Mon, 18 Jul 94 14:01:06 -0700 From: Dave Crocker X-Mts: smtp In the distinction between big, basic issues versus small (but relevant) details, I suspect this in the realm of small, but... There is an emerging line of thought which keeps the IP layer unchanged. It's job is to use an IP address (for IPng it will be, one with more bits but still the same functional orientation) that moves a packet to an interface. There is then some mechanism which maps it to a process (or use your favorite, trendy term) for a given transport connection. This line of thought attempts to allow mapping multiple such IP addresses into the same transport connection. Data packets for the connection look like they look today. There is no special "EID" field in them. Any inter-host transactions about the EID are done on an occasional basis. So much for the big and basic description for which a constituency seems to be emerging. (Note for the careless reader: I said consituency; I'm not asserting consensus yet.) (Side comment. After all this time, I'm still not sure I understand why we don't just refer to these interface thingy's as addresses or interface addresses; they specifically say WHERE the thing is. And why we don't call the EID types of things names or host names, since they specifically say WHAT the things is and not where. In other words I think we are getting no value added from the terms locator and EID.) Now for the smaller part. ---- Included message: Ah, but I can get all those charms if + EIDs are optionally passed in the SYN phase, or other analogous setup time. No EID passed implies one is concocted by the receiver (based on the locator perhaps) and certain capabilities are not available during the lifetime of the connection. For mobility, we need to pass the thing and its association list of addresses at various times during the life of the connection. For that matter, it may well be the same set of associations for multiple connections. (If I have multiple connections between the same two hosts, it is reasonable that they use the same set of 'paths' though I suppose we don't want to require it.) In any event, I suspect that the association control mechanism needs to be parallel to the data connection, rather than part of it. + The internet layer, or some shim between internet and transport, caches the EID and provides it to the transport layer with each received packet. + This layer can handle whatever messages go along with change of location, making that as invisible as desired to the upper layers. I'm sympathetic with the attempt to provide such transparency to the transport connection, but I suspect it isn't worth the effort. The juggling act involves some complexity and probably some inefficiency. Given that this is all "kernel" stuff anyhow and that (most of the time) if you can add the 'shim' you can also modify TCP, then I suspect it's better to just mess with the lower part of TCP directly. Besides, I believe that proper exploitation of the multiple IP addresses will require careful manipulation of the TCP retransmission algorithm, so that it both knows of the multiple "paths" and uses them cleverly. (Remember that I'm trying to attend to the "quick recovery" reliability problem, as well as to mobility.) Dave From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 07:25:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24508; Tue, 19 Jul 1994 07:25:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA14886; Tue, 19 Jul 1994 07:25:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA14870; Tue, 19 Jul 1994 07:16:10 +1000 Precedence: list Received: from uu6.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24150; Tue, 19 Jul 1994 07:15:56 +1000 (from eric@isci.com) Received: from isci.com by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00315 for big-internet@munnari.oz.au; Mon, 18 Jul 94 17:17:22 -0400 Message-Id: <9407182117.AA00315@uu6.psi.com> Date: Mon, 18 Jul 1994 17:10:15 +0000 From: Eric "D." Williams Subject: Re: EID's in the packets To: Matt Crawford Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Organization: Open Systems Technology, Inc. Ufn: Eric Williams, OST, District of Columbia, US Dn: @c=US@o=OST%st=District of Columbia@cn=Eric Williams Date: Mon, 18 Jul 1994 15:00:30 -0500 From: Matt Crawford > + The internet layer, or some shim between internet and transport, > caches the EID and provides it to the transport layer with each > received packet. > And when/how should we decide to do cache updates/synchronization? How would the locator be cached for "mobile end points" - In a router/IPng? Wouldn't a new connection have to be set-up for each move, to transfer new locator info.? The EID will not change so what is the purpose of a cache? Sounds like some quirky form of ARP cache. > + This layer can handle whatever messages go along with change of > location, making that as invisible as desired to the upper > layers. > This I can get my teeth into. But, I am cloudy on the reason to cache an EID that does not change on a per-connection basis (or do EIDs change with the creation of a FSR?) My think dictates an EID is: An immutable identification for an end point entity (e.g. process, host), that may be utilized in the identification of fate sharing connections. AM I MISSING SOMETHING IN THIS THREAD? It seems to me an EID equates to something unique in any name space, which can be further qualified by connection i.e. locators, to identify fate sharing connections between EIDs (so we don't have to throw out ports, yes?). A Fingerprint, right, and some other qualifying feature - like whose finger and which hand. Peace, Eric Eric D. Williams Open Systems Technology Inc. OST ewilliams@isci.com or guru@isci.com - Fax +1(202)331-4049 or +1(202)872-0896 1899 L Street NW. Suite 500 - Washington, DC 20036-3804 - Voice +1(202)331-1262 From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 09:22:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25808; Tue, 19 Jul 1994 08:05:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA14930; Tue, 19 Jul 1994 08:05:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA14914; Tue, 19 Jul 1994 07:46:48 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25210; Tue, 19 Jul 1994 07:46:43 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id RAA02448; Mon, 18 Jul 1994 17:46:10 -0400 Date: Mon, 18 Jul 1994 17:46:10 -0400 From: Vadim Antonov Message-Id: <199407182146.RAA02448@titan.sprintlink.net> To: Christian.Huitema@sophia.inria.fr, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets >A fate-sharing region is a *networking* concept. You can map it (either >conceptually, or in real systems) to other information system concepts, but >it's just a mapping. It doesn't *make* a FSR one of those other concepts. Well, there are machines which can drop *some* processes in case of hardware problems :-) --vadim From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 09:46:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29819; Tue, 19 Jul 1994 09:46:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA15044; Tue, 19 Jul 1994 09:45:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA15039; Tue, 19 Jul 1994 09:45:15 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25972; Tue, 19 Jul 1994 08:10:51 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id SAA02753; Mon, 18 Jul 1994 18:09:22 -0400 Date: Mon, 18 Jul 1994 18:09:22 -0400 From: Vadim Antonov Message-Id: <199407182209.SAA02753@titan.sprintlink.net> To: Greg_Minshall@novell.com, avg@sprint.net, dab@berserkly.cray.com, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets Cc: big-internet@munnari.OZ.AU > On the second thought, if ports are 1:1 to sockets there is NO need > to carry protocol number in the packets! Simply because all > (sane) packets arriving to a port will all have the same protocol. >This only works if you assume that all protocols will have the same >type of port number, and that all port numbers from all protocols will >be allocated out of the same address space. That kind of hampers >future expansion and addition of new protocols... The absense of well-known ports is necessary if you do process migration and do not attach EIDs or ESELs to *processes*. Otherwise what you do if your process migrates to a machine where the port is already busy? >Keep the port number space up in the transport protocol where it >belongs, on an end-to-end basis. Why is should belong there? Because it is something "everybody does"? As everybody knows, a million lemmings can't be wrong. >And instead you get to manage assigned protocol names. You need >*something* that is well known, it's just a question of at which >layer you want to have it. Yes, and managing *names* is much easier. Then, how do you do things like having FTP.domain and TELNET.domain to go to port 21 on host1.domain and port 23 on host2.domain respectively? The fixed ports are equivalent of host tables of old -- every machine has the full table and all have to be synchronized. >The only advantage of well-known names versus well-known ports is that >the range of well-known ports (in TCP and UDP) is limited, where as >well-known names wouldn't be bound by that limit. That also figures. People already started to use non-standard ports for things like MUDs which is rather ugly. >And now in addition to going to the DNS to get the address for >your machine, I then need to talk to your machine to find out >what port to use to access the service that I want, or else I >have to go to a DNS like system to get that mapping. You can get it from the same DNS in the same query. >But I might >not be able to use DNS, because I'd expect the volitilty of >dynamic name to port assignment to be at least an order of >magnitude higher than that of host name to address bindings. Not at all. If we introduce the concept of "listening" and "data" ports (similar to the sockets) we may have rather static ports for well-known services. After opening the connection the server side simply tells the client the new locator (including port number) -- it doesn't even have to be on the same host. >Let's just leave transport layer addressing out of the internet >layer. There's more than enough items to argue about without >adding that to the mix... Why not to clean up the things as we got the chance. Well-known ports are a historical kludge i see no reason to preserve. --vadim From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 12:08:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05947; Tue, 19 Jul 1994 12:08:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15230; Tue, 19 Jul 1994 12:07:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA15201; Tue, 19 Jul 1994 11:58:53 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05492; Tue, 19 Jul 1994 11:58:41 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Jul 94 10:48:52 +0859 From: Masataka Ohta Message-Id: <9407190149.AA09057@necom830.cc.titech.ac.jp> Subject: Re: EID's in the packets To: crawdad@munin.fnal.gov (Matt Crawford) Date: Tue, 19 Jul 94 10:48:51 JST Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9407182000.AA28022@munin.fnal.gov>; from "Matt Crawford" at Jul 18, 94 3:00 pm X-Mailer: ELM [version 2.3 PL11] > OK, I should have said either "most applications won't need EIDs most of the > time," or, more succinctly, "most packets won't need EIDs." > Now if you want to say "most packets don't need locators" If you assume purely connection oriented PVC without dynamic routing change, no, most of the packets don't need them. You need identification or location infomation only at the initial path setup. But, we are talking not about X.25 but IP. OK? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 12:12:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06048; Tue, 19 Jul 1994 12:12:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15275; Tue, 19 Jul 1994 12:12:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15204; Tue, 19 Jul 1994 12:02:07 +1000 Precedence: list Received: from [132.250.92.89] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01361; Tue, 19 Jul 1994 10:16:05 +1000 (from atkinson@sundance.itd.nrl.navy.mil) To: vjs@rhyolite.denver.sgi.com Subject: Re: EID stuff (was IPng ADs Wish) In-Reply-To: <9407171607.AA10807@rhyolite.denver.sgi.com> Organization: Naval Research Laboratory, DC Cc: big-Internet@munnari.OZ.AU Date: Tue, 19 Jul 94 1:13:13 GMT From: Ran Atkinson Sender: atkinson@sundance.itd.nrl.navy.mil Message-Id: <9407190113.aa26122@sundance.itd.nrl.navy.mil> In article <9407171607.AA10807@rhyolite.denver.sgi.com> Vernon Schryver wrote: >A lot of UDP/IP traffic is as header-compressible as TCP/IP. One could >easily and profitably recognize and compress 28 byte headers of streams >of UDP/IP packets for things like DNS when UDP/IP is a significant >load. Maybe queries to the roots? If you are willing to violate >another layer or two, you can easily compress much of the RPC/XDR stuff >in NFS/UDP/IP packets. If you look at it right, NFS is really nearly >as connection oriented as any TCP/IP application. No one now >compresses UDP/IP headers for PPP and SLIP, because no one lets UDP/IP >headers be a significant consumer of low speed bandwidth. Man, I'd be plenty psyched about an IETF spec on UDP/IP header compression. I'm not as concerned about the RPC/XDR stuff, but generic UDP/IP header compression would be a big win. I'd draft someone hereabouts to implement it and give away our code if a reasonable spec appeared as an I-D. >Many in the IETF seem to be prejudiced against header compression. I >hope those prejudices are not based on layering religions. I am strongly in favour of header compression. Our existing 2400 baud radio (HF/VHF/UHF/UHF SATCOM) links could all use it yesterday. There IS a commercial customer base for UDP/IP compression (namely users of PCS and CDPD and Data over Cellular Phone). I recently heard of a new commercial data-only LEO SATCOM service that will be providing 2400 baud UHF SATCOM links worldwide for data collection purposes; count them in as well. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 12:28:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03254; Tue, 19 Jul 1994 11:05:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA15137; Tue, 19 Jul 1994 11:05:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA15121; Tue, 19 Jul 1994 10:48:13 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02538; Tue, 19 Jul 1994 10:46:53 +1000 (from kre@munnari.OZ.AU) To: ietf-announce@IETF.CNRI.Reston.VA.US, Big-Internet@munnari.OZ.AU Subject: July '94 IETF: EID BOF Date: Tue, 19 Jul 1994 10:46:51 +1000 Message-Id: <28568.774578811@munnari.OZ.AU> From: Robert Elz BOF Name: Endpoint Identifier BOF (eid) IETF Area: IPNG Date/Time: Monday 25th July, 1994, 16:00 - 18:00 A BOF will be held at the Toronto IETF to discuss the concept of the End Point Identifier (EID), what is it, how is it allocated, what will it be used for, and what might it be used for, but only at the end if time permits whether EIDs should exist at all - because that's a rat hole question that could consume the whole two hours if it was allowed. The question of whether a working group should be formed to continue EID work will also be considered. Proposed Agenda 0. Administrative tedium (5 minutes) 1. EIDs - definition (20) 2. Terminology - what name should these things have (10) 3. Uses - certain, likely, and possible (20) 4. Structure, (15) - including or excluding manufacturer provided tags (eg: MAC addresses) - structure for directory lookups 5. Allocation (incl autoconfiguration) (10) 6. Is a WG required (5) 7. Draft Charter if so (15) 8. Are EIDs useful? Do we need them? (20) (If time hasn't run over on other issues) From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 12:36:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05873; Tue, 19 Jul 1994 12:05:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15215; Tue, 19 Jul 1994 12:05:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15210; Tue, 19 Jul 1994 12:04:15 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05706; Tue, 19 Jul 1994 12:03:56 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Jul 94 10:57:07 +0900 From: Masataka Ohta Message-Id: <9407190157.AA09180@necom830.cc.titech.ac.jp> Subject: Re: summary of Big-Internet messages To: crawdad@munin.fnal.gov (Matt Crawford) Date: Tue, 19 Jul 94 10:57:06 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407181558.AA27120@munin.fnal.gov>; from "Matt Crawford" at Jul 18, 94 10:58 am X-Mailer: ELM [version 2.3 PL11] > > BTW. Locators are not assured to be reversible. > > What does this mean? Who pays the return trip? How is his policy? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 13:46:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09155; Tue, 19 Jul 1994 13:46:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA15390; Tue, 19 Jul 1994 13:45:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA15374; Tue, 19 Jul 1994 13:29:56 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08522; Tue, 19 Jul 1994 13:29:34 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id XAA04960; Mon, 18 Jul 1994 23:29:26 -0400 Date: Mon, 18 Jul 1994 23:29:26 -0400 From: Vadim Antonov Message-Id: <199407190329.XAA04960@titan.sprintlink.net> To: Big-Internet@munnari.OZ.AU, ietf-announce@IETF.CNRI.Reston.VA.US, kre@munnari.OZ.AU Subject: Re: July '94 IETF: EID BOF Objection -- the question 8 should go first :-) >8. Are EIDs useful? Do we need them? (20) --vadim From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 13:54:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05997; Tue, 19 Jul 1994 12:10:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15260; Tue, 19 Jul 1994 12:10:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15207; Tue, 19 Jul 1994 12:03:03 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05634; Tue, 19 Jul 1994 12:02:42 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Jul 94 10:55:31 +0900 From: Masataka Ohta Message-Id: <9407190155.AA09156@necom830.cc.titech.ac.jp> Subject: Re: Constructive Proof on why 8 byte EID is enough To: crawdad@munin.fnal.gov (Matt Crawford) Date: Tue, 19 Jul 94 10:55:29 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407181626.AA27226@munin.fnal.gov>; from "Matt Crawford" at Jul 18, 94 11:26 am X-Mailer: ELM [version 2.3 PL11] > > Are there any flaw in the proof? > > Yes. Flaw #1 -- You have not stated any assumption about what an EID > names. Thus I don't know if we agree on how many will be needed. I stated several times that EID is a provider (and location maybe) independent identification of hosts. Flaw #1, you haven't read anything. > I say a separate EID is needed for each group of processes whose > location may change independently of other groups. Wrong. A process is not a concept useful on networks. > Flaw #2 -- "Upper 4 bytes of EID is managed by Internic to national > NICs with 100% utilization." Show me how this is feasible. It's automatic. Show me how can't it be possible? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 14:01:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07262; Tue, 19 Jul 1994 12:46:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15321; Tue, 19 Jul 1994 12:45:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15316; Tue, 19 Jul 1994 12:40:10 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07070; Tue, 19 Jul 1994 12:40:04 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB07199; Mon, 18 Jul 94 19:39:54 PDT Received: from jurassic.Eng.Sun.COM by Eng.Sun.COM (8.6.9/SMI-4.1) id TAA08084; Mon, 18 Jul 1994 19:36:56 -0700 Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA13583; Mon, 18 Jul 1994 19:37:41 -0700 Date: Mon, 18 Jul 1994 19:37:41 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9407190237.AA13583@jurassic.Eng.Sun.COM> To: big-Internet@munnari.OZ.AU Subject: [New SIPP Addressing Draft] FYI ------- Start of forwarded message ------- From: hinden (Bob Hinden) To: sipp@sunroof.Eng.Sun.COM Cc: hinden Subject: New SIPP Addressing Draft Date: Mon, 18 Jul 1994 19:33:55 -0700 I have submitted a new version of the SIPP addressing document, supporting 16-byte SIPP addresses, as an Internet Draft. If you want to grab a copy before it shows up in the official directories, you can get it from: ftp://parcftp.xerox.com/pub/sipp/draft-ietf-sipp-rout-addr-02.txt This version reflects the change to SIPP to support 16byte addresses (from 8byte addresses) and the change made to the SIPP transition mechanisms (to remove the C-bit). Bob ------- End of forwarded message ------- From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 15:50:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09886; Tue, 19 Jul 1994 14:05:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA15420; Tue, 19 Jul 1994 14:05:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA15417; Tue, 19 Jul 1994 14:02:49 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09793; Tue, 19 Jul 1994 14:02:31 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id AAA05075; Tue, 19 Jul 1994 00:00:51 -0400 Date: Tue, 19 Jul 1994 00:00:51 -0400 From: Vadim Antonov Message-Id: <199407190400.AAA05075@titan.sprintlink.net> To: Greg_Minshall@novell.com, avg@sprint.net, dab@berserkly.cray.com, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets Cc: big-internet@munnari.OZ.AU >As has already been said on the list, getting rid of well-known ports >only *reduces* the probability of migrating a process to another >machine where the port is already busy, it doesn't eliminate it. Sorry, it does not parse. Migration of processes is either possible or not. What "probability" means in this context? If you meant "reduces need to move processes around" (to which i agree) then i'd rather say it is a good property. >Unless, perhaps, you are advocating that processes have unique port >numbers across the entire internet. ;-) Correction -- unique locators. Imagine Internet containing small machines, one process at each one. Sure, locator in this case includes the "port number". > >Keep the port number space up in the transport protocol where it > >belongs, on an end-to-end basis. > > Why is should belong there? Because it is something "everybody does"? > As everybody knows, a million lemmings can't be wrong. >The internet layer has the addressing necessary to get packets >through the network between two end hosts. The transport layer >then has additional addressing information so that the end hosts >know what to do with that data once it gets there. It's nice >clean protocol layering. Removing artificial division between multiplexing in hardware (LAN level) and in software (by port numbers) only makes the entire structure cleaner and simplier (not to mention more efficient). Now, time for phylosophy -- where the "network" ends and "machine" starts? Is a VAX cluster a "network" or a "machine"? Yes, it is in one rack with common power supply -- but can run IP between its parts. >Don't muddy that up in the specification. Beauty is in the eye of beholder. >I adheare to the viewpoint that Dave Clark said some time ago, that >strict protocol layering is a wonderful way to design protocols, but >a terrible way to implement them. ... and at the same time you opt to preserve the division between "hosts" and "network entities (aka sockets)". >I have nothing against an >implementation of the internet layer knowing about the ports of the >transport layer above it, but that doesn't mean that the ports belong >in the spec of the internet layer, it belongs in spec for the >transport layer. Specs, not being a legal entity cannot own anything. It's people who imagine non-existing "axioms". > >And now in addition to going to the DNS to get the address for > >your machine, I then need to talk to your machine to find out > >what port to use to access the service that I want, or else I > >have to go to a DNS like system to get that mapping. > > You can get it from the same DNS in the same query. >Only as an optimization. Without well-known ports, then the only >reliable source for the port-name to port-number mapping is the >host itself. Reducing that argument ad absurdum -- the only "reliable" source of information about the host is the host itself, isn't it? So DNS is only an "optimization". Wake up -- people do not need to name machines, they name *services*. The linkage between machine names and service names is only a remnant of old misconception; and there is no need to perpetuate it. >You have to have at least one well known port to >provide a starting point for doing the inquiries for all the other >mappings. The same applies to obtaining host names. You have to have a hard-wired "starting point" which is a list of locators of root DNS servers. It *is* enough to find host names/port numbers from names. > Why not to clean up the things as we got the chance. Well-known > ports are a historical kludge i see no reason to preserve. >This is not the time to get rid of well-known ports in TCP and UDP. Would you please describe what is the time T when it should happen? >You can get rid of them in TCPng and UDPng, totally disjoint from >the IPng discussions. The only changes to TCP and UDP that should >happen due to IPng is to define what is in the new pseudo-header (and >note that port numbers are *not* in the pseudo header). Is it the God's will? Was it written in sacred scriptures? Then why do you insist on now allowing ourselves to take a look at the larger picture? Or we go ahead chanting "it is out of chapter, hari Krishna, hari"? >The transport layer is end-to-end, so well-known ports only matter >on an end-to-end basis. Sorry, there are also multicasts and simply connectionless protocols. >Intermediate routers/hosts don't (and >shouldn't) care about them, so port addressing doesn't belong in IPng. How having port numbers in locators affect the intermediate routers? Answer: It doesn't, they simply ignore that part of locators (probably together with host numbers on LANs and aggregated specifics). So what is the logic of the "conclusion"? If all rationale is at that level i don't wonder there still is no understanding (and "rough consensus") on IPng. --vadim From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 15:56:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11501; Tue, 19 Jul 1994 14:45:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA15477; Tue, 19 Jul 1994 14:45:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA15463; Tue, 19 Jul 1994 14:27:36 +1000 Precedence: list Received: from [128.162.19.7] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07906; Tue, 19 Jul 1994 13:09:10 +1000 (from dab@berserkly.cray.com) Received: from berserkly.cray.com by cray.com (Bob mailer 1.3) id AA14288; Mon, 18 Jul 94 22:07:43 CDT Received: by berserkly.cray.com id AA21376; 5.64/CRI-4.9; Mon, 18 Jul 94 22:07:17 -0500 Date: Mon, 18 Jul 94 22:07:17 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9407190307.AA21376@berserkly.cray.com> To: avg@sprint.net, dab@berserkly.cray.com, Greg_Minshall@novell.com, jnc@ginger.lcs.mit.edu Subject: Re: EID's in the packets Cc: big-internet@munnari.OZ.AU > The absense of well-known ports is necessary if you do process > migration and do not attach EIDs or ESELs to *processes*. Otherwise > what you do if your process migrates to a machine where the port > is already busy? As has already been said on the list, getting rid of well-known ports only *reduces* the probability of migrating a process to another machine where the port is already busy, it doesn't eliminate it. Unless, perhaps, you are advocating that processes have unique port numbers across the entire internet. ;-) > >Keep the port number space up in the transport protocol where it > >belongs, on an end-to-end basis. > > Why is should belong there? Because it is something "everybody does"? > As everybody knows, a million lemmings can't be wrong. The internet layer has the addressing necessary to get packets through the network between two end hosts. The transport layer then has additional addressing information so that the end hosts know what to do with that data once it gets there. It's nice clean protocol layering. Don't muddy that up in the specification. I adheare to the viewpoint that Dave Clark said some time ago, that strict protocol layering is a wonderful way to design protocols, but a terrible way to implement them. I have nothing against an implementation of the internet layer knowing about the ports of the transport layer above it, but that doesn't mean that the ports belong in the spec of the internet layer, it belongs in spec for the transport layer. > >And now in addition to going to the DNS to get the address for > >your machine, I then need to talk to your machine to find out > >what port to use to access the service that I want, or else I > >have to go to a DNS like system to get that mapping. > > You can get it from the same DNS in the same query. Only as an optimization. Without well-known ports, then the only reliable source for the port-name to port-number mapping is the host itself. You have to have at least one well known port to provide a starting point for doing the inquiries for all the other mappings. If that information is relativly static, then it can be cached in the DNS so that your inquiry to the DNS could be handed the hostname, the transport layer, and the the port-name. It would return the host-addr/port-number if it had it, otherwise just the host-addr, and then you'd have to go to host-addr/well-known-port to get the real host-addr/port-number (which may indeed point off to another host). > >Let's just leave transport layer addressing out of the internet > >layer. There's more than enough items to argue about without > >adding that to the mix... > > Why not to clean up the things as we got the chance. Well-known > ports are a historical kludge i see no reason to preserve. This is not the time to get rid of well-known ports in TCP and UDP. You can get rid of them in TCPng and UDPng, totally disjoint from the IPng discussions. The only changes to TCP and UDP that should happen due to IPng is to define what is in the new pseudo-header (and note that port numbers are *not* in the pseudo header). The transport layer is end-to-end, so well-known ports only matter on an end-to-end basis. Intermediate routers/hosts don't (and shouldn't) care about them, so port addressing doesn't belong in IPng. -David Borman, dab@cray.com From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 16:06:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15034; Tue, 19 Jul 1994 16:06:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA15564; Tue, 19 Jul 1994 16:05:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA15545; Tue, 19 Jul 1994 15:48:11 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14254; Tue, 19 Jul 1994 15:46:28 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 19 Jul 94 14:32:20 +0900 From: Masataka Ohta Message-Id: <9407190532.AA10208@necom830.cc.titech.ac.jp> Subject: Re: EID's in the packets To: dab@berserkly.cray.com (David Borman) Date: Tue, 19 Jul 94 14:32:18 JST Cc: avg@sprint.net, dab@berserkly.cray.com, Greg_Minshall@novell.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9407190307.AA21376@berserkly.cray.com>; from "David Borman" at Jul 18, 94 10:07 pm X-Mailer: ELM [version 2.3 PL11] > I adheare to the viewpoint that Dave Clark said some time ago, that > strict protocol layering is a wonderful way to design protocols, but > a terrible way to implement them. Agreed. But you have little confusion on the issue. That is, > I have nothing against an > implementation of the internet layer knowing about the ports of the > transport layer above it, There is "implementation of the entire protocol", but there may not be such thing as "implementation of the internet layer". Implementation may have several layers. Some implementaion layer may strong connection to some specification layer. But some specification layer may not have corresponding implementation layers. Thus, by saying "implementation of the internet layer", you are somewhat forcing a terrible implementation. > but that doesn't mean that the ports belong > in the spec of the internet layer, it belongs in spec for the > transport layer. Exactly. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 16:08:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15122; Tue, 19 Jul 1994 16:08:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA15584; Tue, 19 Jul 1994 16:08:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA15548; Tue, 19 Jul 1994 15:48:25 +1000 Precedence: list Received: from [192.52.71.4] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11180; Tue, 19 Jul 1994 14:40:43 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa10711; 19 Jul 94 0:39 EDT To: Robert Elz Cc: Big-Internet@munnari.OZ.AU Subject: Re: July '94 IETF: EID BOF In-Reply-To: Your message of Tue, 19 Jul 1994 10:46:51 +1000. <28568.774578811@munnari.OZ.AU> Date: Tue, 19 Jul 1994 00:38:03 -0400 From: John Curran Message-Id: <9407190039.aa10711@nic.near.net> -------- ] From: Robert Elz ] Subject: July '94 IETF: EID BOF ] Date: Tue, 19 Jul 1994 10:46:51 +1000 ] BOF Name: Endpoint Identifier BOF (eid) ] IETF Area: IPNG ] Date/Time: Monday 25th July, 1994, 16:00 - 18:00 ] ] A BOF will be held at the Toronto IETF to discuss the ] concept of the End Point Identifier (EID), what is it, ] how is it allocated, what will it be used for, and what ] might it be used for, but only at the end if time permits ] whether EIDs should exist at all - because that's a rat hole ] question that could consume the whole two hours if it was allowed. Regretfully, there are so many different views on what EIDs should (or should not) be, it's hard to be optimistic regarding the outcome of a "general" EID discussion. Might it be more useful (and much more challenging :-) to coordinate several dissenting viewpoints on what an EID might be? There's at least at least 3 positions on the topic: 1) EIDs are transport-level identifiers for communication endpoints. 2) EIDs are network-level identifiers for communication endpoints. 3) EIDs are a nuisance created by folks with too much spare time. For some reason, I imagine that the BOF would be more fruitful if it focused on only one or two of the above positions. Perhaps dividing the time up for discussion of particular proposals might be useful? /John From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 16:26:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15844; Tue, 19 Jul 1994 16:26:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA15635; Tue, 19 Jul 1994 16:25:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA15572; Tue, 19 Jul 1994 16:08:01 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15091; Tue, 19 Jul 1994 16:07:49 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA10978; Mon, 18 Jul 94 22:38:13 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id cq02322; 19 Jul 94 3:33 GMT Date: Mon, 18 Jul 94 15:58 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: IPng and .... Firewalls! Message-Id: <53940718205835/0003858921NA2EM@mcimail.com> Dave Bridgham said: >An interesting analogy. The four color map problem was solved a few >years ago. Maybe there's hope that people will secure their machines >after all? That is why I chose that example. It was not mathematically proved, but proved by exhaustion. Now apply that approach to security; fun! Bob From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 16:28:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15916; Tue, 19 Jul 1994 16:28:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA15650; Tue, 19 Jul 1994 16:28:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA15593; Tue, 19 Jul 1994 16:09:08 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15123; Tue, 19 Jul 1994 16:08:50 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA10991; Mon, 18 Jul 94 22:38:45 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id cs02322; 19 Jul 94 3:33 GMT Date: Mon, 18 Jul 94 15:59 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: WHy not DNS names. Message-Id: <00940718205900/0003858921NA2EM@mcimail.com> >>No. My DNS names are not for public consumption... >IP addresses ARE for public consumption, but DNS names are NOT?? Please >explain. Let me TRY to explain.... IP addresses are just numbers. They convey no information about the internal structure of an organization. DNS names often indicate the make of computer, the organizational structure for computing resources. This is considered restricted information. Vendors have been known to acuire lists of competing products in our company and to then target product push. Competitors have been know to use associated information to learn who is doing what.... Bob From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 16:30:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16026; Tue, 19 Jul 1994 16:30:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA15670; Tue, 19 Jul 1994 16:30:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA15596; Tue, 19 Jul 1994 16:09:38 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15198; Tue, 19 Jul 1994 16:09:26 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA10981; Mon, 18 Jul 94 22:38:14 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id cr02322; 19 Jul 94 3:33 GMT Date: Mon, 18 Jul 94 15:58 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Why EIDs should be in headers. Message-Id: <94940718205849/0003858921NA2EM@mcimail.com> Greg Minshall said: >>Autoconfig proponents can argue that the 'mask' can be changed at will. I >>respond that this would have to be dynamic while the device is running as >>I have 7x24 systems up on lots of segments. Taking some of these down >>takes a VP signed authorization! (Or a software bug :) >I assume that (eventually at least) your VP authorized 7x24 will have >multiple interfaces? I would think that the rate of "oops - we need to >re-do the mask [no masks in IPng!!!!!], so let's re-locate" should be small >enough that dropping one interface, re-locating it, and bringing it up >again should not be that big of a deal. I used 'mask' a little symbolically. What I ment was 'someway to change the addressing structure to allow for more devices on a subnet'. So perhaps the IPng kernel writers will make it so I can vary do an interface, reconfig it and bring it back up, like we do in VTAM. But we seem to find that when we try that with our UNIX systems, we have to restart INETD which breaks all of the connections going on other interfaces :( >On the other hand, maybe you have *very* long running transport >connections? (Weeks, months...) We do our best to discourage anything longer than a couple of hours. Bob From owner-Big-Internet@munnari.OZ.AU Tue Jul 19 22:05:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26982; Tue, 19 Jul 1994 22:05:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA16074; Tue, 19 Jul 1994 22:05:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA16058; Tue, 19 Jul 1994 21:54:39 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25328; Tue, 19 Jul 1994 21:18:38 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA26989; Tue, 19 Jul 94 06:20:29 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab08919; 19 Jul 94 11:15 GMT Date: Tue, 19 Jul 94 06:16 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Masataka Ohta To: big internet Subject: Re: Constructive Proof on why 8 byte EID is enough Message-Id: <53940719111635/0003858921NA3EM@mcimail.com> Masataka Ohta said: >A large company having a lot of equipments or a branch of it may apply >for a lot of EID sub-spaces, of course. But, no delegation is necessary. >Are there any flaw in the proof? More involved than my EID assignment methodology but quite concise. Thank you again Ohta, I've learned to count on you for sound mathematical approaches to our debates.... Bob From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 00:09:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25535; Tue, 19 Jul 1994 21:26:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA15992; Tue, 19 Jul 1994 21:25:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA15978; Tue, 19 Jul 1994 21:18:42 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25329; Tue, 19 Jul 1994 21:18:39 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA26997; Tue, 19 Jul 94 06:20:31 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac08919; 19 Jul 94 11:15 GMT Date: Tue, 19 Jul 94 06:16 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Constructive Proof on why 8 byte EID is enough Message-Id: <64940719111646/0003858921NA3EM@mcimail.com> Bill Simpson said: >No. The NICs want to delegate that work to the providers, who are >closer to the problem. When a first-time subscriber gets a connection, >they will also get a block. It's just more practical, less paperwork. >The key is that the providers don't OWN the block, and you can take it >to another provider (or multiple providers) at any time. So my block assignments are permanent? I can change my provider to suit my corporate goals ( or for smaller corps that relocate to a new area and thus end up with a new provier). That is what I expect. Bob From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 00:19:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29414; Tue, 19 Jul 1994 23:26:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA16168; Tue, 19 Jul 1994 23:25:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA16152; Tue, 19 Jul 1994 23:11:10 +1000 Precedence: list Received: from [153.39.128.10] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28948; Tue, 19 Jul 1994 23:11:05 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET id QQwzfo03257; Tue, 19 Jul 1994 09:09:40 -0400 Message-Id: To: big-internet@munnari.OZ.AU Subject: "Process Migration" Date: Tue, 19 Jul 1994 09:09:39 -0400 From: "Mike O'Dell" How in the world did process migration get added to the list of things to worry about in doing IPng????? That is so far out of scope as to be laughable. Trying to formulate IP mobility as some insane version of "process migration" is like buying a Ferrari F40 for a 3 year-old who just wanted a tricycle. Get real, folks. The job of IPng is NOT to solve all the problems of "distributed computing" that Operating Systems Research has been unable to convincingly solve in the last 25 years of work. -Mike O'Dell Resident Crank From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 01:11:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02013; Wed, 20 Jul 1994 00:26:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA16390; Wed, 20 Jul 1994 00:25:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA16235; Wed, 20 Jul 1994 00:16:51 +1000 Precedence: list Received: from norge.unet.umn.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29548; Tue, 19 Jul 1994 23:31:10 +1000 (from fin@unet.umn.edu) Received: by norge.unet.umn.edu (5.65c) id AA10120; Tue, 19 Jul 1994 08:31:03 -0500 Date: Tue, 19 Jul 1994 08:31:03 -0500 From: "Craig A. Finseth" Message-Id: <199407191331.AA10120@norge.unet.umn.edu> To: 0003858921@mcimail.com Cc: big-internet@munnari.OZ.AU In-Reply-To: "Robert G. Moskowitz"'s message of Mon, 18 Jul 94 15:59 EST <00940718205900/0003858921NA2EM@mcimail.com> Subject: WHy not DNS names. From: "Robert G. Moskowitz" <0003858921@mcimail.com> >>No. My DNS names are not for public consumption... >IP addresses ARE for public consumption, but DNS names are NOT?? Please >explain. Let me TRY to explain.... IP addresses are just numbers. They convey no information about the internal structure of an organization. DNS names often indicate the make of computer, the organizational structure ... So call them (IP address 1.2.3.4): x1-2-3-4. or something. Properly registered, but useless. Everyone's happy. (We gave up on naming PCs, etc., years ago. We use x3-4..umn.edu as a default name, but we're not paranoid about anyone knowing that our English department has a PC.) Craig A. Finseth Craig.A.Finseth-1@umn.edu University Networking Services fin@unet.umn.edu University of Minnesota +1 612 624 3375 desk 130 Lind Hall +1 612 625 0006 problems 207 Church St SE +1 612 626 1002 fax Minneapolis MN 55455-0134, USA member, LPF "A ship is safe in a harbor, but that's not what a ship is for" -- unknown From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 02:45:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07436; Wed, 20 Jul 1994 02:45:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16632; Wed, 20 Jul 1994 02:45:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16616; Wed, 20 Jul 1994 02:34:04 +1000 Precedence: list Received: from [18.26.0.82] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06908; Wed, 20 Jul 1994 02:33:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10417; Tue, 19 Jul 94 12:33:28 -0400 Date: Tue, 19 Jul 94 12:33:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407191633.AA10417@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mo@uunet.uu.net Subject: Re: "Process Migration" Cc: jnc@ginger.lcs.mit.edu From: "Mike O'Dell" How in the world did process migration get added to the list of things to worry about in doing IPng????? ... The job of IPng is NOT to solve all the problems of "distributed computing" that Operating Systems Research has been unable to convincingly solve in the last 25 years of work. It was just being used as an example. Let me take this excuse to rant and rave a bit. There are two kinds of designers in the world, be it buildings or networks. There are the kind who turn out designs, which do what you asked for perfectly well, but whose designs don't show a lot of long-term flexibility. Then there are designers who turn out things (like the Panama Canal, or the Brooklyn Bridge) that function perfectly well under conditions which the designers couldn't have had the slightest imagination of. The automobile wasn't even *invented* when the Brooklyn Bridge was built, but it carries thousands of them every day. Some of this is luck, as I will cheerfully admit. Some of it's not. I personally have no idea what the Internet is going to look like in 30 years. We have people telling us we can't even predict growth for 7 years based on the past, with some merit to their argument. I'm very reluctant to think we can predict what the Internet is going to look like after several times that long. I reckon I'm fairly clever, but I'm not hubristic enough to think I know what the Internet is going to look like a ways out. What this leads me to is producting designs that contain more flexibility, adaptability, and generality. This generality, of course, has costs. Is there almost certainly some useless extra generality there? Of course. However, I'll bet that the costs of the extra generality that turns out not to be needed are less than the costs of not having any generality that you cannot *at this point in time* predict the need for. I don't expect to convince anyone with this. I just want to make it plain that there's some method to my grandiose "second system" madness. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 03:05:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05886; Wed, 20 Jul 1994 02:06:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16558; Wed, 20 Jul 1994 02:05:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16552; Wed, 20 Jul 1994 02:00:48 +1000 Precedence: list Received: from [128.89.1.209] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03743; Wed, 20 Jul 1994 01:12:15 +1000 (from clynn@BBN.COM) Message-Id: <9407191512.3743@munnari.oz.au> Date: Tue, 19 Jul 94 11:01:03 EDT From: Charles Lynn To: David Borman Cc: avg@sprint.net, dab@berserkly.cray.com, Greg_Minshall@novell.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Folks, > This is not the time to get rid of well-known ports in TCP and UDP. The last I knew, there was an IPng requirement that IPng not be hostile to firewalls. Filters that I've seen make use of well known ports and the firewall administrators complain a lot about "dynamic" ports. My conclusion is that elimination of well known ports is hostile to firewalls and thus out of bounds for IPng. Is my conclusion correct? Charlie From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 03:05:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08175; Wed, 20 Jul 1994 03:05:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16670; Wed, 20 Jul 1994 03:05:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16648; Wed, 20 Jul 1994 02:51:36 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07598; Wed, 20 Jul 1994 02:51:31 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA10615; Tue, 19 Jul 94 11:53:20 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa27080; 19 Jul 94 16:48 GMT Date: Tue, 19 Jul 94 11:50 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: EID's in the packets Message-Id: <41940719165014/0003858921NA2EM@mcimail.com> Christian Huitema said: >Your mention of the "process" as a unit is interesting. If the process >could actually survive a crash of the host, e.g. if process migration >techniques and other distributed systems tools were adopted, then we should >use the process, rather than the host, as the unit of "fate sharing". take it a step farther. Say that there are two copies of the process running for load balancing (and fall back). If one 'crashes' the other might automatically pick up the load without losing a connection (provided max connect # not exceeded). Bob From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 03:06:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08215; Wed, 20 Jul 1994 03:06:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16687; Wed, 20 Jul 1994 03:06:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16665; Wed, 20 Jul 1994 03:05:34 +1000 Precedence: list Received: from [128.162.19.7] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06253; Wed, 20 Jul 1994 02:16:54 +1000 (from dab@berserkly.cray.com) Received: from berserkly.cray.com by cray.com (Bob mailer 1.3) id AA11370; Tue, 19 Jul 94 11:15:28 CDT Received: by berserkly.cray.com id AA21838; 5.64/CRI-4.9; Tue, 19 Jul 94 11:14:59 -0500 Date: Tue, 19 Jul 94 11:14:59 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9407191614.AA21838@berserkly.cray.com> To: dab@berserkly.cray.com, mohta@necom830.cc.titech.ac.jp Subject: Re: EID's in the packets Cc: avg@sprint.net, big-internet@munnari.OZ.AU, Greg_Minshall@novell.com, jnc@ginger.lcs.mit.edu > There is "implementation of the entire protocol", but there may not be > such thing as "implementation of the internet layer". > > Implementation may have several layers. Some implementaion layer may > strong connection to some specification layer. But some specification > layer may not have corresponding implementation layers. > > Thus, by saying "implementation of the internet layer", you are > somewhat forcing a terrible implementation. Sorry if you misunderstood me. By saying "implementation of the internet layer" I did not mean that the internet layer had to be implemented as a separate layer. Quite the opposite, it may very well be imbedded in a single level of code that spans multiple protocol layers. The point is that the specificiations should have clear and distinct protocol layering, but when you do an implementation you can play fast and loose with the boundries between the different layers. -David Borman, dab@cray.com From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 03:08:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05950; Wed, 20 Jul 1994 02:09:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16577; Wed, 20 Jul 1994 02:09:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16555; Wed, 20 Jul 1994 02:02:23 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03311; Wed, 20 Jul 1994 01:01:55 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEVX9XIL9C000PIT@FNAL.FNAL.GOV>; Tue, 19 Jul 1994 09:58:22 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA03218; Tue, 19 Jul 94 09:57:50 CDT Date: Tue, 19 Jul 1994 09:57:49 -0500 From: Matt Crawford Subject: Re: Constructive Proof on why 8 byte EID is enough In-Reply-To: Your message of Tue, 19 Jul 94 10:55:29 +0200. <9407190155.AA09156@necom830.cc.titech.ac.jp> To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Message-Id: <9407191457.AA03218@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > > Yes. Flaw #1 -- You have not stated any assumption about what an EID > > names. Thus I don't know if we agree on how many will be needed. > I stated several times that EID is a provider (and location maybe) > independent identification of hosts. You did not state this in your "consructive proof" message. Am I at fault for not memorizing everything you ever wrote? > Flaw #1, you haven't read anything. This is clearly untrue. Let's not incite a flame war by throwing around provable falsehoods. > > I say a separate EID is needed for each group of processes whose > > location may change independently of other groups. > Wrong. A process is not a concept useful on networks. If you call a process a service, is it then useful? > > Flaw #2 -- "Upper 4 bytes of EID is managed by Internic to national > > NICs with 100% utilization." Show me how this is feasible. > It's automatic. Show me how can't it be possible? Come now. Automatic? You presume a lot. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 03:08:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08276; Wed, 20 Jul 1994 03:08:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16702; Wed, 20 Jul 1994 03:08:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16651; Wed, 20 Jul 1994 02:53:02 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07620; Wed, 20 Jul 1994 02:53:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10731; Tue, 19 Jul 94 12:52:56 -0400 Date: Tue, 19 Jul 94 12:52:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407191652.AA10731@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp Subject: Re: Support for aggregated flows Cc: jnc@ginger.lcs.mit.edu From: Masataka Ohta > I've been thinking about aggregating flows ... > What am I missing here? You should have thought about why you need flow aggregation, which is totally missing. Sorry, I wasn't explicit enough with my disclaimers! I'm simply thinking about the mechanisms what would result if we did aggregate flows. I'm not assuming that we do, or don't aggregate (I would personally lean to not aggregating them, actually). (Perhaps I should explain that I don't do design by a purely "top-down" process. I like to think about what the practical implications are of any choice, and how efficient it will be to implement, etc. Then I go back and look at my proposed high-level design again, with an understanding of the implications in terms of the low-level mechanisms.) When it comes to aggregating flows, we're going to have to decide whether we even want to try, as an experiment, aggregating flows. Aggregated flows have certain costs, and certain benfits. I'd like to make sure I understand all these, as well as you can from purely desk thinking, (and the costs include things like this), before I make up my mind as to what path I'd like to recommend. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 04:06:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10489; Wed, 20 Jul 1994 04:06:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA16789; Wed, 20 Jul 1994 04:05:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16786; Wed, 20 Jul 1994 04:00:03 +1000 Precedence: list Received: from netcom11.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08762; Wed, 20 Jul 1994 03:24:15 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id KAA25557; Tue, 19 Jul 1994 10:22:38 -0700 Date: Tue, 19 Jul 1994 10:22:38 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407191722.KAA25557@netcom11.netcom.com> To: big-internet@munnari.OZ.AU Subject: Re: WHy not DNS names. >>>No. My DNS names are not for public consumption... >>IP addresses ARE for public consumption, but DNS names are NOT?? Please >>explain. >Let me TRY to explain.... >IP addresses are just numbers. They convey no information about the >internal structure of an organization. >DNS names often indicate the make of computer, the organizational structure >for computing resources. This is considered restricted information. >Vendors have been known to acuire lists of competing products in our company >and to then target product push. Competitors have been know to use >associated information to learn who is doing what.... >Bob Not that I think this topic is germain to the problem at hand, but I thought I would add my 2 cents since I think what has been tossed around is wrong. Yes IP addresses are just numbers. And DNS names are just names that equate to numbers. There is nothing magic about DNS names. A name suggests nothing about the make of the computer. If you are worried about somebody finding out about the make, then do not make that info available. Or at least authenticate who can get that info. The idea of organizational structure is another who cares. If you are really that sensitive, then don't use the names you use. If you do not want people to know your address you do not have it put in the phone book. The idea behind DNS names was to allow for easy mappings between things humans remember (ascii names) to things we do not remember well (numbers). If you are trying to build more into stop! If you really do not want the DNS names to convey orginizational info then use 2 sets of names (one internal and one external). -rich From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 04:06:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08790; Wed, 20 Jul 1994 03:26:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16747; Wed, 20 Jul 1994 03:25:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16731; Wed, 20 Jul 1994 03:13:19 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08393; Wed, 20 Jul 1994 03:13:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10349; Tue, 19 Jul 94 12:19:10 -0400 Date: Tue, 19 Jul 94 12:19:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407191619.AA10349@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, clynn@bbn.com Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Charles Lynn Filters that I've seen make use of well known ports and the firewall administrators complain a lot about "dynamic" ports. My conclusion is that elimination of well known ports is hostile to firewalls and thus out of bounds for IPng. Is my conclusion correct? Hmm, good point. It certainly makes life more difficult. But first, an related, and even more important, thought. In a way, it's silly that firewall databases are in terms of the immediate numbers in the packets, rather than some indirect form. I'm always peeved by the fact that filter lists (and other routing control databases, such as gated) contain IPv4 addresses. The consequences are unbelievably painful. It makes reassigning addresses, something we talk about blithely, almost impossible; I know of no IPng candidate which has really thought about this. Instead of information about what addreseses a site is using being restricted to the machines on that site, and the DNS, it is spread across the Internet, to all sites which have configuration info with that site in them. We have no way of knowing where such info is; you may not even realize that some distant site you interact with has you in an access control database! We thus have no way of tracking it down and changing it. About all you can do is change the address of some of your machines, and see what stops working, and get them all fixed before you change the rest, and even then you may not get it all, since some machine may have an idiosyncratic relationship you don't know about until it stops working. Anyway, back to the current point. The initial connection protocols would have to be done in a way which was easy for the firewall to understand, so it could block connections to disallowed services from starting, or allow through only those which are authorized, as the case may be. E.g. no storing a service's port in the DNS, so it takes an AI program to watch DNS transactions to find a connection starting; or services that pass port numbers in some other out-of-band way. Some sort of "service location port", or an ICP which passes a string service name, or something, would be more or less the way to go. The firewall would then have to to be able to find ICP packets, and understand the ICP, obviously. Also, if some uniform ICP is not used across all transport layers, that means more work there. None of this is impossible, of course, but it's something to think about. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 04:26:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11359; Wed, 20 Jul 1994 04:26:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA16839; Wed, 20 Jul 1994 04:25:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16823; Wed, 20 Jul 1994 04:21:59 +1000 Precedence: list From: smb@research.att.com Received: from [192.20.225.3] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11179; Wed, 20 Jul 1994 04:21:52 +1000 (from smb@research.att.com) Message-Id: <9407191821.11179@munnari.oz.au> Received: by gryphon; Tue Jul 19 14:08:16 EDT 1994 To: Charles Lynn Cc: David Borman , avg@sprint.net, Greg_Minshall@novell.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Date: Tue, 19 Jul 94 14:08:13 EDT Folks, > This is not the time to get rid of well-known ports in TCP and UDP. The last I knew, there was an IPng requirement that IPng not be hostil e to firewalls. Filters that I've seen make use of well known ports and the firewall administrators complain a lot about "dynamic" ports. My conclusion is that elimination of well known ports is hostile to firewalls and thus out of bounds for IPng. Is my conclusion correct? Yes. Well, I'm exagerating slightly. Eliminating well-known ports is hostile to packet filter firewalls, which are popular because they're cheap and easy. I don't like them much myself, since they're too easy to get wrong, but lots of other folks do. The real question is whether there can be an IPng alternative that's at least as easy, and far more secure. I don't know the answer yet; I'm going to be working on finding one. --Steve Bellovin From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 06:19:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12638; Wed, 20 Jul 1994 05:05:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA16885; Wed, 20 Jul 1994 05:05:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA16880; Wed, 20 Jul 1994 05:02:10 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11714; Wed, 20 Jul 1994 04:40:05 +1000 (from valdis@black-ice.cc.vt.edu) Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id OAA17111; Tue, 19 Jul 1994 14:35:31 -0400 Message-Id: <199407191835.OAA17111@black-ice.cc.vt.edu> To: kck@netcom.com (Richard Fox) Cc: big-internet@munnari.OZ.AU Subject: Re: WHy not DNS names. In-Reply-To: Your message of "Tue, 19 Jul 1994 10:22:38 EDT." <199407191722.KAA25557@netcom11.netcom.com> From: Valdis.Kletnieks@vt.edu Date: Tue, 19 Jul 1994 14:35:31 +22306356 Sender: valdis@black-ice.cc.vt.edu On Tue, 19 Jul 1994 10:22:38 EDT, you said: > equate to numbers. There is nothing magic about DNS names. A name > suggests nothing about the make of the computer. If you are worried A DNS name sure as hell *does* suggest something, if you call your machine 'big-hairy-ibm.payroll.corporate.headquarters.com'. I suppose you *could* call the machine 'xv45er2.blort.com', but that's defeating the idea of DNS. ;) > book. The idea behind DNS names was to allow for easy mappings between > things humans remember (ascii names) to things we do not remember > well (numbers). If you are trying to build more into stop! If you > really do not want the DNS names to convey orginizational info then > use 2 sets of names (one internal and one external). Right. People can remember 'ibm3090.payroll.corp.com', they can't remember xv45er2.corp.com. If you're trying to defeat the purpose of DNS by assigning names that don't reflect reality, stop! The idea of 2 sets of names, one internal and one external, is a loser if you are trying to use a DNS name as an identifier. Think about the implications of going through a firewall, or the fun&games trying to identify "do these two names refer to the same machine?" /Valdis From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 07:06:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17308; Wed, 20 Jul 1994 07:06:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16997; Wed, 20 Jul 1994 07:05:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA16994; Wed, 20 Jul 1994 06:58:03 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15996; Wed, 20 Jul 1994 06:29:27 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id QAA01115; Tue, 19 Jul 1994 16:29:16 -0400 Date: Tue, 19 Jul 1994 16:29:16 -0400 From: Vadim Antonov Message-Id: <199407192029.QAA01115@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, mo@uunet.uu.net Subject: Re: "Process Migration" >Get real, folks. The job of IPng is NOT to solve all the problems of >"distributed computing" that Operating Systems Research has been >unable to convincingly solve in the last 25 years of work. The IPng group should *not* make engineering decisions which will kill the *possibility* of impelmenting process mobility in the future. Besides, the "connection forwarding" has straightforward applications in building firewalls and load balancing. Part of the inability of Operating Systems Research (with all capitals) to solve anything in the last 25 years of work is due to the desire to make a difference without actually changing anything. --vadim Resident Alien Crank From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 08:26:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20171; Wed, 20 Jul 1994 08:26:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA17107; Wed, 20 Jul 1994 08:25:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA17093; Wed, 20 Jul 1994 08:23:16 +1000 Precedence: list Received: from netcom3.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20105; Wed, 20 Jul 1994 08:23:09 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id PAA16438; Tue, 19 Jul 1994 15:23:22 -0700 Date: Tue, 19 Jul 1994 15:23:22 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407192223.PAA16438@netcom3.netcom.com> To: Valdis.Kletnieks@vt.edu, kck@netcom.com Subject: Re: WHy not DNS names. Cc: big-internet@munnari.OZ.AU >A DNS name sure as hell *does* suggest something, if you call your >machine 'big-hairy-ibm.payroll.corporate.headquarters.com'. Not to belabor the point but if I send US mail to accounting regarding payroll stuff it gets to accounting. If I send payroll info to accounting using the account name above it gets to accounting. If I send a bomb in the US mail to the same place either some authenticating entity (ie: dogs at airport) intercept the bomb or there are dead people at that company. If I send an email bomb to the account above it will be intercepted by some authenticating entity or the bomb goes off. Requiring the Internet to provide name hiding is silly! If you want it then do it, but please do not require the protocols I use to provide it. But since I do not think DNS names are really being considered for EIDs (which is how this thread began) I think this is all moot. >/Valdis --rich From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 09:15:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19637; Wed, 20 Jul 1994 08:05:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA17064; Wed, 20 Jul 1994 08:05:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA17050; Wed, 20 Jul 1994 07:49:22 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18759; Wed, 20 Jul 1994 07:49:10 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id RAA02122; Tue, 19 Jul 1994 17:48:33 -0400 Date: Tue, 19 Jul 1994 17:48:33 -0400 From: Vadim Antonov Message-Id: <199407192148.RAA02122@titan.sprintlink.net> To: clynn@BBN.COM, dab@berserkly.cray.com Subject: Re: EID's in the packets Cc: Greg_Minshall@novell.com, avg@sprint.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu > > This is not the time to get rid of well-known ports in TCP and UDP. >The last I knew, there was an IPng requirement that IPng not be hostile >to firewalls. Filters that I've seen make use of well known ports and >the firewall administrators complain a lot about "dynamic" ports. My >conclusion is that elimination of well known ports is hostile to >firewalls and thus out of bounds for IPng. Is my conclusion correct? Not. Because "mobility of ports" eliminates possibility to do port-based filtering BUT creates a way to do *efficient* proxies -- i.e. a proxy firewall host opens and authenticates the connection and then "forwards" it to the actual server; after that all data transfer is done between the real server and the the client. The firewall router simply does not allow SYN packets in... Also, you may prefer not to advertise your services' locators to the outside world; with randomly-assigned 32-bit port numbers it will be sufficient deterrent to most attackers -- and no firewall hosts etc are required. A trivial code in the host software may effectively discover attempts to poll service port numbers and nail the attacker. (And note that this approach allows to provide security to the *mobile* hosts, something no firewall can do). It is generally a much cleaner way to do things than port-based filtering which practically nobody can set up properly (i deal with that kind of stuff on a daily basis...). --vadim From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 10:06:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24417; Wed, 20 Jul 1994 10:06:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA17226; Wed, 20 Jul 1994 10:05:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17207; Wed, 20 Jul 1994 09:48:09 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23575; Wed, 20 Jul 1994 09:48:00 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm012-16.dialip.mich.net (pm012-16.dialip.mich.net [35.1.48.217]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA20085 for ; Tue, 19 Jul 1994 19:47:51 -0400 Date: Tue, 19 Jul 94 23:12:37 GMT From: "William Allen Simpson" Message-Id: <2879.bill.simpson@um.cc.umich.edu> To: big-Internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: IPng Header Compression > From: Ran Atkinson > Man, I'd be plenty psyched about an IETF spec on UDP/IP header > compression. I'm not as concerned about the RPC/XDR stuff, but > generic UDP/IP header compression would be a big win. I'd draft > someone hereabouts to implement it and give away our code if a > reasonable spec appeared as an I-D. > I started a SIPP header compression 6 to 8 months ago or more. It includes UDP over other constant headers over SIPP. It is based on the Compressed IPX [RFC 1553] techniques, rather than VJ 1144, since CIPX also has IPX-only compression as well as NCP/IPX compression. However, the damn headers and details keep changing. I told Steve I would send it out right after he finished the SIPP Header revisions, which he promised at Christmas -- and got out in March. I added more bits for your new security headers (which are non-constants in the middle of constant fields). Etc, etc. Whenever we finally decide something, there will be a compression draft within a couple of weeks. OK? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 10:29:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23547; Wed, 20 Jul 1994 09:46:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA17190; Wed, 20 Jul 1994 09:45:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17174; Wed, 20 Jul 1994 09:31:03 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21687; Wed, 20 Jul 1994 09:07:10 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from Mordor.Stanford.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA21779 Wed, 20 Jul 1994 09:05:26 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA12119; Tue, 19 Jul 1994 16:02:52 -0700 Message-Id: <199407192302.QAA12119@Mordor.Stanford.EDU> To: Vadim Antonov Cc: big-internet@munnari.OZ.AU, mo@uunet.uu.net Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: "Process Migration" Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 19 Jul 94 16:29:16 -0400. <199407192029.QAA01115@titan.sprintlink.net> Date: Tue, 19 Jul 94 16:02:51 -0700 From: Dave Crocker X-Mts: smtp Vadim & Noel, ---- Included message: The IPng group should *not* make engineering decisions which will kill the *possibility* of impelmenting process mobility in the future. Even if that means that IPng will be delayed past the time of usable IPv4 assignment? In other words, this is all a matter of tradeoffs and it is esential that we balance what we MUST have with what we must have NOW. In other words, we need to distinguish engineering from research. Process migration is an appealing research construct. To the extent that we can allow IPng to provide for a way to do it -- i.e., a way that looks feasible, but who know whether it will really be useful? -- then fine. To the extent that providing for possible application of long-term research constructs gets in the way of near-term, real-world requirements, it wouldn't be so smart to stick with the research requirement. To the extent that a "requirement" is stated only in terms of an "example" it would help many of us to hear that it is an example. To the extent that it is a research topic, it would help manyh of us to hear it so labeled. d/ From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 12:17:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24443; Wed, 20 Jul 1994 10:07:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA17243; Wed, 20 Jul 1994 10:06:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17198; Wed, 20 Jul 1994 09:48:01 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23571; Wed, 20 Jul 1994 09:47:57 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm012-16.dialip.mich.net (pm012-16.dialip.mich.net [35.1.48.217]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA20088 for ; Tue, 19 Jul 1994 19:47:53 -0400 Date: Tue, 19 Jul 94 23:26:58 GMT From: "William Allen Simpson" Message-Id: <2880.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Constructive Proof on why 8 byte EID is enough > From: Masataka Ohta > > Yes. Flaw #1 -- You have not stated any assumption about what an EID > > names. Thus I don't know if we agree on how many will be needed. > > I stated several times that EID is a provider (and location maybe) > independent identification of hosts. > > Flaw #1, you haven't read anything. > Actually, it is clear that he has read some things. It is more accurate to say that he hasn't read _everything_! And he sometimes misuses terms we have all come to understand to be meaningful, and so don't include in every note. A latecomer to the debate. > > I say a separate EID is needed for each group of processes whose > > location may change independently of other groups. > > Wrong. A process is not a concept useful on networks. > I agree. And others have already argued this point on this list. I sincerely doubt that mobile processes will be assigned separate Locators, either -- same as machines within a bridged environment, or cellular radios in a cellular system. > > Flaw #2 -- "Upper 4 bytes of EID is managed by Internic to national > > NICs with 100% utilization." Show me how this is feasible. > > It's automatic. Show me how can't it be possible? > I think he wants you to explain that you will assign all the numbers in that field sequentially, with no holes, thus achieving a 100% ratio of meaningful use of the allocated space. In this, I think he is just being deliberately obstructionist, although I don't know why. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 12:20:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24481; Wed, 20 Jul 1994 10:08:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA17260; Wed, 20 Jul 1994 10:07:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17204; Wed, 20 Jul 1994 09:48:07 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23569; Wed, 20 Jul 1994 09:47:53 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm012-16.dialip.mich.net (pm012-16.dialip.mich.net [35.1.48.217]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA20082 for ; Tue, 19 Jul 1994 19:47:48 -0400 Date: Tue, 19 Jul 94 22:31:15 GMT From: "William Allen Simpson" Message-Id: <2878.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Revised NSAPA mapping (fwd) > Subject: Revised NSAPA mapping > Date: Mon, 18 Jul 1994 14:10:51 +0200 (MET DST) > Reply-To: Brian.Carpenter@cern.ch > > [Acknowledgements for useful comments: Scott Bradner, John Curran, > Bob Hinden, Yakov Rekhter. And for the main improvement: Cyndi Jung.] > > BTW, I haven't bothered to write down a mapping for NSAPAs inside > the BigTen 24-byte address format, but it is clearly trivial. > > Brian > > 1. NSAPAs inside a 16-byte IPng address > > The main goal of this embedding is to allow pre-existing NSAPA > allocations, profiled for CLNP, to be re-used for IPng routing. It does > not offer a mapping for arbitrary NSAPAs. > I don't understand why this is useful. This needs a lot more explanation. What TCP over CLNP with NSAPs applications are out there widely deployed which need NSAPA translation? What foo over CLNP applications do we care about? How will these interoperate with IP applications. When we say that other protocols should migrate to IPng, I don't see why we care what their old allocations have been. We should just throw them away when we throw away the old, useless TPx transport. > 2. 16-byte IPng addresses inside a 20-octet NSAPA > > The main goal of this embedding is to allow CLNP packets that encapsulate > IPng packets to be routed in a CLNP network using the IPng address > architecture. An arbitrary number of bytes of the IPng address can be > used as a CLNP routing prefix. > > The first three octets are an IDP meaning "this NSAPA embeds a > 16 byte IPng address" and the last octet is a dummy selector. > Sorry about the alignment, but it seems very risky to overload > the selector octet. > Again, I don't see why this is useful. More explanation, please. Where are the CLNP routed networks? My understanding is that there are more IP over X.25 links, than any CLNP over anything. And doesn't the "official" ISO IDRP already route IP and IPng, alongside CLNP? Convergence means ISO should converge on IPng, not we start using CLNP for our routing! Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 12:27:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00312; Wed, 20 Jul 1994 12:27:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA17406; Wed, 20 Jul 1994 12:25:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17403; Wed, 20 Jul 1994 12:25:19 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27999; Wed, 20 Jul 1994 11:35:54 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id VAA04118; Tue, 19 Jul 1994 21:35:06 -0400 Date: Tue, 19 Jul 1994 21:35:06 -0400 From: Vadim Antonov Message-Id: <199407200135.VAA04118@titan.sprintlink.net> To: avg@sprint.net, dcrocker@mordor.stanford.edu Subject: Re: "Process Migration" Cc: big-internet@munnari.OZ.AU, mo@uunet.uu.net >As I said. It's fine to avoid a limitation when the cost is low. It is >NOT fine to avoid a limitation when the cost is high, particularly when the >the limitation being avoided is of such uncertain benefit. First of all, nobody provided even shaky argument that the "cost is high". Second, process mobility is only incidential to the design -- it also have quite a lot of other advantages, simplicity being the most important. > We simply do >not really know how such a facility really will get used. Remember the >original SNMP security field. So may be we should go ahead and test different implementations before actually committing to any. It would be The Internet Way (tm) :-) --vadim From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 12:30:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00569; Wed, 20 Jul 1994 12:30:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA17428; Wed, 20 Jul 1994 12:30:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17389; Wed, 20 Jul 1994 12:20:50 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26466; Wed, 20 Jul 1994 10:54:51 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA12654; Tue, 19 Jul 1994 17:54:31 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Jul 1994 17:54:34 -0700 To: Vadim Antonov From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: "Process Migration" Cc: avg@sprint.net, big-internet@munnari.OZ.AU, mo@uunet.uu.net At 5:22 PM 7/19/94, Vadim Antonov wrote: >We have at least 10 years to get it deployed. Quite a lot of time -- some >of us will retire by then :-) 10 years to get IPng deployed? I don't think so. You must be taking the ALE estimate seriously. Don't. >And then, we do not design mobile processes right now -- we just are >trying to avoid possible problems in the future. As I said. It's fine to avoid a limitation when the cost is low. It is NOT fine to avoid a limitation when the cost is high, particularly when the the limitation being avoided is of such uncertain benefit. We simply do not really know how such a facility really will get used. Remember the original SNMP security field. ----- Dave Crocker +1 408 246 8253; fax: +1 408 249 6205 From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 12:46:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01433; Wed, 20 Jul 1994 12:46:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA17474; Wed, 20 Jul 1994 12:45:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17414; Wed, 20 Jul 1994 12:29:15 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00417; Wed, 20 Jul 1994 12:29:02 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEWLDWFVQO000Z1S@FNAL.FNAL.GOV>; Tue, 19 Jul 1994 21:28:45 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA06203; Tue, 19 Jul 94 21:28:17 CDT Date: Tue, 19 Jul 1994 21:28:16 -0500 From: Matt Crawford Subject: Re: Constructive Proof on why 8 byte EID is enough In-Reply-To: Your message of Tue, 19 Jul 94 23:26:58 -0100. <2880.bill.simpson@um.cc.umich.edu> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Message-Id: <9407200228.AA06203@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > In this, I think he is just being deliberately obstructionist, although > I don't know why. more REDuctionist than OBSTRuctionist, I hope, and here's why. Everyone's entitled to an opinion, and most people's may be better than mine on most of these topics, but I can tell the difference between Mach-2 handwaving and a proof. And I shudder when the former tries to pass itself off as the latter. From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 13:00:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00680; Wed, 20 Jul 1994 12:31:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA17443; Wed, 20 Jul 1994 12:31:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17386; Wed, 20 Jul 1994 12:12:21 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25118; Wed, 20 Jul 1994 10:23:07 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id UAA03683; Tue, 19 Jul 1994 20:22:59 -0400 Date: Tue, 19 Jul 1994 20:22:59 -0400 From: Vadim Antonov Message-Id: <199407200022.UAA03683@titan.sprintlink.net> To: avg@sprint.net, dcrocker@mordor.stanford.edu Subject: Re: "Process Migration" Cc: big-internet@munnari.OZ.AU, mo@uunet.uu.net >Even if that means that IPng will be delayed past the time of usable IPv4 >assignment? In other words, this is all a matter of tradeoffs and it is >esential that we balance what we MUST have with what we must have NOW. We have at least 10 years to get it deployed. Quite a lot of time -- some of us will retire by then :-) I don't understand spending several years on talking and when time comes to seriously evaluate the existing ideas we're in sudden rush. >In other words, we need to distinguish engineering from research. Process >migration is an appealing research construct. To the extent that we can >allow IPng to provide for a way to do it -- i.e., a way that looks feasible, >but who know whether it will really be useful? -- then fine. There are two engineering designs -- one allows to do migration, one doesn't. There is no proven advantage of "non-migrating" one in terms of complexity, efficiency or reliability. Which one do you prefer? And then, we do not design mobile processes right now -- we just are trying to avoid possible problems in the future. --vadim From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 15:06:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07027; Wed, 20 Jul 1994 15:06:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA17629; Wed, 20 Jul 1994 15:05:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA17621; Wed, 20 Jul 1994 15:00:07 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06787; Wed, 20 Jul 1994 14:59:59 +1000 (from bill.simpson@um.cc.umich.edu) 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 AAA06663 for ; Wed, 20 Jul 1994 00:59:54 -0400 Date: Wed, 20 Jul 94 03:46:23 GMT From: "William Allen Simpson" Message-Id: <2882.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: "Process Migration" > From: "Mike O'Dell" > How in the world did process migration get added to the list of things > to worry about in doing IPng????? That is so far out of scope as to be > laughable. Thanks for injecting a little reality. Let's just try to solve the problems we spent 2 years considering, which are very nicely documented in our "criteria". Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 15:06:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07128; Wed, 20 Jul 1994 15:06:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA17646; Wed, 20 Jul 1994 15:06:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA17624; Wed, 20 Jul 1994 15:00:10 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06794; Wed, 20 Jul 1994 15:00:06 +1000 (from bill.simpson@um.cc.umich.edu) 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 AAA06666 for ; Wed, 20 Jul 1994 00:59:56 -0400 Date: Wed, 20 Jul 94 03:51:11 GMT From: "William Allen Simpson" Message-Id: <2883.bill.simpson@um.cc.umich.edu> To: big internet Reply-To: bsimpson@morningstar.com Subject: Re: WHy not DNS names. > From: "Robert G. Moskowitz" <0003858921@mcimail.com> > Vendors have been known to acuire lists of competing products in our company > and to then target product push. Competitors have been know to use > associated information to learn who is doing what.... > Interesting. Then we definitely SHOULD NOT allow IEEE 802 numbers in globally routed IPng packets. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 16:04:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06363; Wed, 20 Jul 1994 14:46:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA17594; Wed, 20 Jul 1994 14:45:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA17578; Wed, 20 Jul 1994 14:39:33 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06015; Wed, 20 Jul 1994 14:38:42 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Jul 94 12:29:41 +0900 From: Masataka Ohta Message-Id: <9407200329.AA14770@necom830.cc.titech.ac.jp> Subject: Re: Constructive Proof on why 8 byte EID is enough To: crawdad@munin.fnal.gov (Matt Crawford) Date: Wed, 20 Jul 94 12:29:39 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407191457.AA03218@munin.fnal.gov>; from "Matt Crawford" at Jul 19, 94 9:57 am X-Mailer: ELM [version 2.3 PL11] > > > Yes. Flaw #1 -- You have not stated any assumption about what an EID > > > names. Thus I don't know if we agree on how many will be needed. > > I stated several times that EID is a provider (and location maybe) > > independent identification of hosts. > > You did not state this in your "consructive proof" message. Instead, I presented reasoning process, which is enough. > > > I say a separate EID is needed for each group of processes whose > > > location may change independently of other groups. > > Wrong. A process is not a concept useful on networks. > > If you call a process a service, is it then useful? Wrong. I call "each group of processes" "each service" which is an application layer entity and your point disappears. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 16:06:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09452; Wed, 20 Jul 1994 16:06:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA17719; Wed, 20 Jul 1994 16:05:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA17712; Wed, 20 Jul 1994 15:59:16 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06364; Wed, 20 Jul 1994 14:46:42 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Jul 94 13:28:32 +0900 From: Masataka Ohta Message-Id: <9407200428.AA14989@necom830.cc.titech.ac.jp> Subject: Re: EID's in the packets To: dab@berserkly.cray.com (David Borman) Date: Wed, 20 Jul 94 13:28:31 JST Cc: dab@berserkly.cray.com, avg@sprint.net, big-internet@munnari.OZ.AU, Greg_Minshall@novell.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9407191614.AA21838@berserkly.cray.com>; from "David Borman" at Jul 19, 94 11:14 am X-Mailer: ELM [version 2.3 PL11] > Sorry if you misunderstood me. By saying "implementation of the > internet layer" I did not mean that the internet layer had to be > implemented as a separate layer. Quite the opposite, it may very > well be imbedded in a single level of code that spans multiple > protocol layers. I'm glad and sorry to hear that. I just wanted to make sure that there is no "implementation of the internet layer" separate from the rest of the implementation. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 17:27:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13823; Wed, 20 Jul 1994 17:27:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA17810; Wed, 20 Jul 1994 17:25:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA17782; Wed, 20 Jul 1994 17:06:24 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09911; Wed, 20 Jul 1994 16:20:18 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15762; Wed, 20 Jul 1994 08:20:04 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13396; Wed, 20 Jul 1994 08:20:03 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407200620.AA13396@dxcoms.cern.ch> Subject: Re: Revised NSAPA mapping (fwd) To: bsimpson@morningstar.com Date: Wed, 20 Jul 1994 08:20:03 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <2878.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Jul 19, 94 10:31:15 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 972 Bill, > > > I don't understand why this is useful. This needs a lot more explanation. > I posted this on tuba for comments from NSAPA experts and on sipp as an FYI since there is an older version in the new ROAD draft. I didn't post it on big-i because I specifically don't see any point in re-starting a discussion we had a few weeks ago. I posted a whole set of arguments why mappings are necessary at that time. You don't accept them; that's fine, this is the IETF. Since we seem to be heading towards a 128-bit consensus and since without an NSAPA mapping large chunks of the real world will ignore IPng, it seems like a constructive idea to look for the best mapping of NSAPAs into 128 bits. Whether this mapping ever gets used, the market will tell. The inverse mapping is trivial, so whether it is useful seems of no importance to me. In both cases, it is much better to have an agreed mapping than to leave it open to potential implementors' fantasy. Brian From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 18:25:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14049; Wed, 20 Jul 1994 17:30:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA17829; Wed, 20 Jul 1994 17:30:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA17796; Wed, 20 Jul 1994 17:20:44 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13652; Wed, 20 Jul 1994 17:20:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16742; Wed, 20 Jul 94 03:18:28 -0400 Date: Wed, 20 Jul 94 03:18:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407200718.AA16742@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: EID's in the packets Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov > A fate-sharing region is a *networking* concept. You can map it (either > conceptually, or in real systems) to other information system concepts, > but it's just a mapping. Well, there are machines which can drop *some* processes in case of hardware problems :-) If all the state about the tranport connections of the process were in the process, it would be a more direct application. Still, most OS's respond to the death of a process by closing all its connections. But this is a flip answer. The serious answer is "why give something a name unless there's a use for it"? What good does it do to give it a separate name, as opposed to having it share a name (and a demultiplexing space) with other similar entities? One of the points of names for endpoints is to allow the binding from that name, to other names such as locators, to be changed. If I have N names of processes which are all bound to locators, and I rebind them all to a different locator, and they always get changed together like that, there's no use there to having N names for all the individual processes, I could have just had one for the entire system. These points bring out two reasons I don't like your "rebinding ports" idea. First, it is useful to have the endpoint name refer not just to an area of state, but an area of naming; i.e. a demultiplexing context. Sure, I can go through and rebind all the names (ports), but it's a major aggravation. Second, the demux thing is one instance of a more general thing, which is that having a layer of binding is useful. Your idea gets rid of one, and this is something that's sure to bite us in the long run. For instance, if you need to change the "thing" you've got, instead of changing the name of the "thing" in one place (the binding), you have to go through and change it in all the places that know about the underlying thing. For another, one thing you *can't* do, lacking that layer of binding, is to have many-to-one bindings, such as a TCP connection which can accept packets to multiple locators. (If you think I'm making this application up, the IP over FDDI WG got most of the way done defining a multi-interface ARP which would allow dual-MAC FDDI interfaces to accept traffic through both interfaces.) Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 18:26:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16127; Wed, 20 Jul 1994 18:26:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA17951; Wed, 20 Jul 1994 18:25:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA17917; Wed, 20 Jul 1994 18:19:52 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15911; Wed, 20 Jul 1994 18:19:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17156; Wed, 20 Jul 94 04:19:31 -0400 Date: Wed, 20 Jul 94 04:19:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407200819.AA17156@ginger.lcs.mit.edu> To: avg@sprint.net, big-internet@munnari.OZ.AU Subject: Re: "Process Migration" Cc: jnc@ginger.lcs.mit.edu From: Vadim Antonov I don't understand spending several years on talking and when time comes to seriously evaluate the existing ideas we're in sudden rush. Ah, but we've wasted so much time talking, we have to make up for it. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 18:31:09 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16246; Wed, 20 Jul 1994 18:31:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08850 Wed, 20 Jul 1994 18:29:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA17972; Wed, 20 Jul 1994 18:27:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA17914; Wed, 20 Jul 1994 18:14:54 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15666; Wed, 20 Jul 1994 18:14:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17104; Wed, 20 Jul 94 04:14:38 -0400 Date: Wed, 20 Jul 94 04:14:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407200814.AA17104@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: "Process Migration" Cc: jnc@ginger.lcs.mit.edu From: Dave Crocker In other words, we need to distinguish engineering from research. Process migration is an appealing research construct. ... To the extent that providing for possible application of long-term research constructs gets in the way of near-term, real-world requirements, it wouldn't be so smart to stick with the research requirement. I'm sorry I ever mentioned mobile processes. I brought it up as an example, since many people don't seem happy dealing at a very abstact level like "this is good since it provides another layer of binding", or "this is good since it provides a namespace for a fundamental class of object". To the extent that a "requirement" is stated only in terms of an "example" it would help many of us to hear that it is an example. I have explained repeatedly that it is an example. Here's a sample: From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407191633.AA10417@ginger.lcs.mit.edu> From: "Mike O'Dell" How in the world did process migration get added to the list of things to worry about in doing IPng????? It was just being used as an example. How many times do I need to say something? Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 20 18:56:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16863; Wed, 20 Jul 1994 18:46:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA18006; Wed, 20 Jul 1994 18:45:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA17990; Wed, 20 Jul 1994 18:34:42 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16451; Wed, 20 Jul 1994 18:34:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17385; Wed, 20 Jul 94 04:34:10 -0400 Date: Wed, 20 Jul 94 04:34:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407200834.AA17385@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: "Process Migration" Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) 10 years to get IPng deployed? I don't think so. Well, it's going to take 4-5 at least, so don't think it's going to happen much sooner than 10. It's fine to avoid a limitation when the cost is low. It is NOT fine to avoid a limitation when the cost is high I guess I'm having a hard time understanding how an extra 16 bytes in the header to make fixed length addresses hopefully long enough is a low cost, and worth the benefit, whereas the same 16 bytes to provide a whole extra binding layer for a whole new object class is not. (Vadim's scheme is even cheaper; it's much like your TCP-level scheme, and has no per-packet overhead). particularly when the the limitation being avoided is of such uncertain benefit. We simply do not really know how such a facility really will get used. Exactly. You're trying to quantify something that cannot be quantified. You see this attempt to include something which cannot be quantified as bad design, and I see it as good. There's a gap there that cannot be bridged. Time will tell which approach is the right one. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 21 07:06:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07437; Thu, 21 Jul 1994 07:06:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA18817; Thu, 21 Jul 1994 07:06:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA18812; Thu, 21 Jul 1994 07:01:00 +1000 Precedence: list Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07200; Thu, 21 Jul 1994 07:00:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by shark.mel.dit.csiro.au with SMTP id AA03636 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 20 Jul 1994 19:38:04 +1000 Received: by ginger.lcs.mit.edu id AA17642; Wed, 20 Jul 94 05:33:52 -0400 Date: Wed, 20 Jul 94 05:33:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407200933.AA17642@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bill.simpson@um.cc.umich.edu Subject: Re: "Process Migration" Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" Let's just try to solve the problems we spent 2 years considering, which are very nicely documented in our "criteria". I mentioned the Brooklyn Bridge. There's a great book about the building of the bridge, "The Great Bridge", by David McCullough. It was principally the result of the work of the Roeblings, father and son, who exercised complete control over the design. The son said something so incredibly apropos that I can't bear to not repeat it: "of what benfit has it been to erect this bridge at a vast expense unless we use it for every possible purpose to which the structure will lend itself." Speaking of apropos quotes, I was remindind someone that the phrase "second system effect" is from "Mythical Man Month". Everyone takes it to mean adding on every feature one can think of, to produce a massive pile, but the book has more. There's an amusing (in the IPng context, if you have the right fatalistic sense of humor) line in the book, about SSE. It goes: The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumptions. I will leave it to the observers to muse about the degree to which this applies to the various IPng designs, and how. It will be a fine jest it, in an attempt to avoid one class of SSE, we pick a design that suffes from another. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 21 07:20:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06446; Thu, 21 Jul 1994 06:49:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA18785; Thu, 21 Jul 1994 06:46:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA18769; Thu, 21 Jul 1994 06:33:32 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05310; Thu, 21 Jul 1994 06:33:27 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA08687; Wed, 20 Jul 94 15:34:33 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af12459; 20 Jul 94 20:28 GMT Date: Tue, 19 Jul 94 14:54 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: MCIMail - INTERNET access in the tanks Message-Id: <60940719195406/0003858921NA2EM@mcimail.com> MCI Mail's INTERNET gateway has been flaky since 4pm the 18th. Being down more than up. I am attempting to find out if they are just not accepting mail or if they are dropping it on the floor. If the later, I will need a pointer to an archive :( Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 21 07:30:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08371; Thu, 21 Jul 1994 07:30:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA18860; Thu, 21 Jul 1994 07:26:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA18844; Thu, 21 Jul 1994 07:18:24 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05719; Thu, 21 Jul 1994 06:37:32 +1000 (from bill.simpson@um.cc.umich.edu) Received: from shark.mel.dit.CSIRO.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15019 Thu, 21 Jul 1994 06:37:20 +1000 (from bill.simpson@um.cc.umich.edu) Received: from merit.edu by shark.mel.dit.csiro.au with SMTP id AA08476 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 21 Jul 1994 03:10:05 +1000 Received: from pm002-19.dialip.mich.net (pm002-19.dialip.mich.net [35.1.48.100]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA22444 for ; Wed, 20 Jul 1994 13:05:01 -0400 Date: Wed, 20 Jul 94 15:42:45 GMT From: "William Allen Simpson" Message-Id: <2889.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: The current 64-bit consensus > From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > Since we seem to be heading towards a 128-bit consensus and since > without an NSAPA mapping large chunks of the real world will ignore > IPng, it seems like a constructive idea to look for the best > mapping of NSAPAs into 128 bits. Whether this mapping ever gets > used, the market will tell. > Warning: I saw red on this claim, and had to pace for 1/2 hour before I could bring myself to sit down at the keyboard. We are not heading toward a 128-bit consensus. We have a clear 64-bit consensus, with over 2:1 preference. The appeal for 128 bits comes from only 4 persons, less even than NSAPs. In fact, most of those 4 are on record historically as supporting IPng using NSAPs. If we had wanted CLNP-sized headers, we would have adopted CLNP when the IAB put the proposal forward. Instead, we had a coup. "Large chunks of the real world" have completely ignored NSAPs. These chunks are so much bigger than the tiny, miniscule, infintessimal size of the NSAP adherents that powers of ten normally used for measuring astronomical distances have to be employed. The mapping could only get used in a fractional proportion of the NSAPs currently used, since only a fraction of the NSAP applications will be moved to IPng. I invite those NSAP drudges to continue ignoring IPng, as they have ignored IP. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jul 21 09:56:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11725; Thu, 21 Jul 1994 09:56:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA18986; Thu, 21 Jul 1994 09:46:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA18972; Thu, 21 Jul 1994 09:28:04 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05722; Thu, 21 Jul 1994 06:37:36 +1000 (from bill.simpson@um.cc.umich.edu) Received: from shark.mel.dit.CSIRO.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15023 Thu, 21 Jul 1994 06:37:27 +1000 (from bill.simpson@um.cc.umich.edu) Received: from merit.edu by shark.mel.dit.csiro.au with SMTP id AA08480 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 21 Jul 1994 03:10:09 +1000 Received: from pm002-19.dialip.mich.net (pm002-19.dialip.mich.net [35.1.48.100]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA22456 for ; Wed, 20 Jul 1994 13:05:04 -0400 Date: Wed, 20 Jul 94 16:07:59 GMT From: "William Allen Simpson" Message-Id: <2890.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Revised NSAPA mapping (fwd) > From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > I posted this on tuba for comments from NSAPA experts and on sipp > as an FYI since there is an older version in the new ROAD draft. > I didn't post it on big-i because I specifically don't see any point > in re-starting a discussion we had a few weeks ago. I posted a whole > set of arguments why mappings are necessary at that time. > You don't accept them; that's fine, this is the IETF. > I don't know how such an "older version" could be in the SIPP drafts, since there was no previous request from you on the SIPP list. I do not much care for private go-arounds when your idea was previously rejected in a broader forum. That is why I brought it back to the forum in which it belongs. Based on your claim, I searched for your posting "a few weeks ago". You have no such postings in the past 3 weeks. However, you did have a _single_ B-I posting on mapping 6 weeks ago: > Date: Wed, 15 Jun 1994 08:23:28 +0200 (MET DST) Your request for algorithmic mapping correctly identifies a number of serious pitfalls. We seemed to agree (within a remarkably short series of messages for B-I) that your algorithmic mapping would not work "unless a complete set of routing protocols exist to support it," and would be limited to "a small set of consenting subscribers." Your request for algorithmic mapping does not even _mention_ any of the points I questioned. So, I will answer them myself. 1) There are no widely deployed TCP over CLNP applications. 2) There are no foo over CLNP applications that cannot be better done as TCP/IP, with the same or less effort of creating a new CLNP mapping/translating infrastructure. 3) There are no CLNP-based applications that interoperate with TCP/IP applications. All such require application gateways. Therefore, we have no interest wasting IPng address space for mapping NSAPs to support these non-existant applications. 4) So-called "integrated" routing protocols such as IDRP already support routing NSAPs separately from IP. There is no need to develop "a complete set of routing protocols" to map and route NSAPs together with IPng. 5) Algorithmic mapping is not required for tunnelling between "a small set of consenting subscribers." The same configuration tables used by BGP should suffice. Therefore, we have no interest wasting IPng bandwidth and development effort for mapping NSAPs to support these non-existant routing needs. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jul 21 20:39:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27432; Thu, 21 Jul 1994 18:47:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA19447; Thu, 21 Jul 1994 18:46:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA19442; Thu, 21 Jul 1994 18:41:26 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20895; Thu, 21 Jul 1994 16:12:19 +1000 (from 0003858921@mcimail.com) Received: from shark.mel.dit.CSIRO.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25828 Thu, 21 Jul 1994 16:11:42 +1000 (from 0003858921@mcimail.com) Received: from gatekeeper.mcimail.com by shark.mel.dit.csiro.au with SMTP id AA17015 (5.65c/IDA-1.4.4/DIT-1.3); Thu, 21 Jul 1994 13:38:42 +1000 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA05045; Wed, 20 Jul 94 22:35:37 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ae13766; 21 Jul 94 3:30 GMT Date: Wed, 20 Jul 94 11:50 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big Internet To: Robert Elz Subject: Problems with big_I or me? Message-Id: <00940720165000/0003858921NA1EM@mcimail.com> I have not seen any BIG-I messages for a little while now. That is unnatural! MCIMail was having some extended internet access problems. Did this get me bounced from the list? I need my hourly fix of BIG-I events!!!! Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 21 21:31:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00696; Thu, 21 Jul 1994 20:06:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA19529; Thu, 21 Jul 1994 20:06:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA19521; Thu, 21 Jul 1994 19:57:39 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21922; Thu, 21 Jul 1994 16:37:38 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA16600; Thu, 21 Jul 94 01:39:04 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id az26265; 21 Jul 94 6:33 GMT Date: Wed, 20 Jul 94 16:22 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Archives? Message-Id: <42940720212224/0003858921NA1EM@mcimail.com> I suspect that I lost 2 days worth of mail on this list. Either that or things were very quite. Thank you, MCIMail.... How can I get archives for 7-18 around 2pm EDT to 7-20 4pm? Bob From owner-Big-Internet@munnari.OZ.AU Thu Jul 21 21:31:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00741; Thu, 21 Jul 1994 20:09:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA19548; Thu, 21 Jul 1994 20:08:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA19525; Thu, 21 Jul 1994 20:01:27 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21827; Thu, 21 Jul 1994 16:34:42 +1000 (from 0003858921@mcimail.com) Received: from shark.mel.dit.CSIRO.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27586 Thu, 21 Jul 1994 16:34:15 +1000 (from 0003858921@mcimail.com) Received: from gatekeeper.mcimail.com by shark.mel.dit.csiro.au with SMTP id AA13562 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 21 Jul 1994 10:16:30 +1000 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA20886; Wed, 20 Jul 94 19:14:37 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ca01223; 21 Jul 94 0:09 GMT Date: Wed, 20 Jul 94 05:41 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: WHy not DNS names. Message-Id: <02940720104120/0003858921NA2EM@mcimail.com> >>Vendors have been known to acuire lists of competing products in our >>company and to then target product push. Competitors have been know to >>use associated information to learn who is doing what.... >Interesting. Then we definitely SHOULD NOT allow IEEE 802 numbers in >globally routed IPng packets. That is right. I am not interested in getting calls saying why product X is better for my networks than product Y. I get enough calls like that from lurkers on lists after I mention some product I've worked with :( Bob From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 00:24:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03777; Thu, 21 Jul 1994 21:48:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA19679; Thu, 21 Jul 1994 21:46:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA19665; Thu, 21 Jul 1994 21:35:31 +1000 Precedence: list Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03041; Thu, 21 Jul 1994 21:20:10 +1000 (from ihanson@pcs.dec.com) Received: from [16.186.80.5] by inet-gw-3.pa.dec.com (5.65/27May94) id AA15137; Thu, 21 Jul 94 04:15:53 -0700 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA11818; Thu, 21 Jul 94 13:15:08 +0200 Message-Id: <9407211115.AA11818@cssec4.pcs.dec.com> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: big internet , ihanson@cssec4.pcs.dec.com Subject: Re: Archives? In-Reply-To: Your message of "Wed, 20 Jul 94 16:22:00 EST." <42940720212224/0003858921NA1EM@mcimail.com> Date: Thu, 21 Jul 94 13:15:08 +0200 From: "Iain K. Hanson" X-Mts: smtp Bob, I have the messages for the 18th and 19th and the 11 for the 20th that I've already mailed you about. If you have not already got copy from somewhere else ( there is a horrible time lag on your message ) I can mail them to you. /ikh From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 00:25:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03825; Thu, 21 Jul 1994 21:50:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA19698; Thu, 21 Jul 1994 21:50:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA19662; Thu, 21 Jul 1994 21:35:09 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00761; Thu, 21 Jul 1994 20:09:42 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 21 Jul 94 19:01:16 +0900 From: Masataka Ohta Message-Id: <9407211001.AA22242@necom830.cc.titech.ac.jp> Subject: Re: The current 64-bit consensus To: bsimpson@morningstar.com Date: Thu, 21 Jul 94 19:01:14 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <2889.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Jul 20, 94 3:42 pm X-Mailer: ELM [version 2.3 PL11] > We are not heading toward a 128-bit consensus. We have a clear 64-bit > consensus, with over 2:1 preference. I don't mind if 16 byte address is used, as long as the lower 8 byte is a provider independent ID of a host. I don't mind, either, if 8 byte address is used with variable length 8 byte unit routing header. > If we had wanted CLNP-sized headers, we would have adopted CLNP when the > IAB put the proposal forward. Instead, we had a coup. CLNP address structure is designed for monopoly without freedom of provider selection, where identification and locating may be mixed. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 00:33:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03842; Thu, 21 Jul 1994 21:51:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA19713; Thu, 21 Jul 1994 21:51:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA19659; Thu, 21 Jul 1994 21:34:44 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21992; Thu, 21 Jul 1994 16:38:20 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27424; Thu, 21 Jul 1994 08:37:09 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA08096; Thu, 21 Jul 1994 08:37:09 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407210637.AA08096@dxcoms.cern.ch> Subject: Address mapping (long) To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 15 Jun 1994 08:23:28 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6536 Sender: brian@dxcoms.cern.ch Why is address mapping useful? ============================== 1. Convergence and multiprotocol networking ------------------------------------------- There has been quite some discussion of "convergence" of other Level 3 protocols onto IPng. Nobody has defined the goal of convergence. I will assume it is the provision of mechanisms for multiprotocol coexistence at Level 3 in the Internet, with later non-disruptive replacement of various older protocols by IPng. Another meaning of convergence is the insertion of a convergence sub-layer between two protocol layers. This is not discussed here. Here a number of mechanisms for convergence and/or multiprotocolism: CONVERGENCE BY REPLACEMENT: Here one simply avoids all intermediate steps. The next versions of several currently used protocols would all be identical, e.g. IPng should also be "IPXng", "AppleTalk Phase 3", "DECnet Phase VI", and "CLNP++". This is presumably the ultimate goal in any case. HEADER TRANSLATION: This is a CATNIP-like, or IPAE-translator-like, scheme where packet headers are translated on the fly. Then hosts running level 3 protocol X can communicate over a network running level 3 protocol Y. SHIPS IN THE DAY: One method is to move from the current ships-in-the-night (SIN) approach (routers support multiple Level 3 protocols, and multiple routing and addressing architectures), to a ships-in-the-day (SID) approach. In SID, routers support multiple Level 3 protocols but a unified routing and addressing architecture. (Note: "and addressing"!) SID is short of convergence but would considerably simplify network planning and management compared to SIN. ENCAPSULATION: (Or tunnels. If anyone sees a difference between encapsulation and tunnels please tell me. I never write "tunnelling" because I get upset when I see it spelt in American :-) Historically, the trouble with tunnels is the need for manual configuration, which does not scale. If the addressing architecture for encapsulated protocols could be made the same as that for the encapsulating protocol, mechanisms for automatic configuration of tunnels could be devised. (One can argue that in this case, tunnels and header translation are logically equivalent.) 2. The address mapping paradigm ------------------------------- I suggest that all of the above mechanisms are made possible if the address space of each existing protocol can be algorithmically mapped into the IPng address space, but not otherwise. If the IPng address format has the generic form (prefix,suffix) where the prefix locates the subscriber (site, campus or corporate network) and the suffix conveys the subscriber's internal host locator (and possibly EID), the most straightforward address mapping paradigm is to ensure that the suffix is big enough to cover all of the existing address spaces as well as new IPng hosts. onsidering address spaces in common use (but ignoring SNA/APPN because I know nothing about it), we find: 1. Eight bytes are precisely sufficient to map the useful bits of a DECnet/OSI NSAPA, i.e., 2 bytes for the area number and 6 bytes for the IEEE address. (The AFI is treated as a no-op in this analysis. It assumed that the IPng prefix fulfils the role of the AFI.) 2. Ten bytes are sufficient for an IPX address (4 bytes network number and 6 bytes IEEE address). 3. Three bytes suffice for Appletalk addresses (2 bytes network number and one byte host number). 4. Four bytes are enough for IPv4 addresses including RFC1597 addresses. One can conclude that the subscriber address space must be a minimum of 11 bytes (a code point byte plus the largest of the above), regardless of considerations affecting IPng itself. In this case algorithmic address mapping is trivial (attach or remove the prefix and the code point byte). This enables any of the mechanisms listed above. 3. Pitfalls ----------- The (prefix,suffix) model assumes that the mapped address is entirely contained in the suffix part. This is sufficient to ensure uniqueness of the total address (which is why RFC 1597 addresses can be migrated readily to IPng addresses). However it does not perfectly match the case where a non-IPng network is split into two or more parts interconnected only by the IPng Internet. To be concrete, let's consider a DECnet Phase V address space split between three sites called C, A and B (CERN, Argonne and Brookhaven if you want to be even more concrete.) They have three different DECnet area numbers NC, NA and NB and hosts within each area are identified by "IEEE" addresses which are actually their DECnet Phase IV addresses in disguise. They are (at some future date) connected to three different IPng service providers, so they have three different address prefixes PC, PA and PB. Then DECnet addresses at C will be in the form (NC,host) and when mapped into IPng address space will be (PC,DECnet,NC,host) where DECnet is the code point used for DECnet addresses within IPng address space. A DECnet router at C will need to know that to send a packet to (NA,host) it must actually be sent to (PA,DECnet,NA,host), but to send it to (NB,host) it must actually be sent to (PB,DECnet,NB,host). Thus instead of knowing how to route to NA and NB, it must know how to rewrite addresses by adding the appropriate prefix. This is error-prone, unless a complete set of routing protocols exist to support it. Now the main pitfall: in DECnet Phase V as defined today, the "prefix" is an OSI AFI which has simply been removed in the above discussion. Because AFIs are unique, and are an integral part of the address, any number of DECnets can coexist and interwork in OSI address space, each with its own AFI. In the paradigm discussed here, any number of DECnets can coexist in IPng address space, and each site has a unique prefix, but two subscribers using the same area number cannot interwork. Address mapping does not necessarily generate unambiguous addresses. No doubt a similar analysis could be made for IPX and AppleTalk: if network numbers (cf. area numbers in DECnet) are not globally unique then mapping them into IPng space may not be unambiguous. This does not matter as long as address mapping is used within a subscriber's network or between a small set of consenting subscribers. This is acceptable as an interim convergence or transition tool, but not as a long-term solution. (Thanks to Ran Atkinson for suggesting that I wrote this.) Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 01:07:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11149; Fri, 22 Jul 1994 01:07:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA19960; Fri, 22 Jul 1994 01:06:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA19931; Fri, 22 Jul 1994 00:49:37 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10456; Fri, 22 Jul 1994 00:49:34 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HEYPJG3FV40016PP@FNAL.FNAL.GOV>; Thu, 21 Jul 1994 09:49:21 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA11518; Thu, 21 Jul 94 09:48:44 CDT Date: Thu, 21 Jul 1994 09:48:44 -0500 From: Matt Crawford Subject: Re: The current 64-bit consensus In-Reply-To: Your message of Wed, 20 Jul 94 15:42:45 -0100. <2889.bill.simpson@um.cc.umich.edu> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Message-Id: <9407211448.AA11518@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > We are not heading toward a 128-bit consensus. We have a clear 64-bit > consensus, with over 2:1 preference. You count me in the 64 bit camp, with some correctness. However, while I think that IPng would probably be a technically better replacement for IPv4 if it has 64 bit locating addresses (with no EID in those bits), I think it stands a better chance of conquering the world with 128 bits. Forward the byte brigade -- Oh what a bloat they made From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 01:46:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12693; Fri, 22 Jul 1994 01:46:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA20082; Fri, 22 Jul 1994 01:46:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA20064; Fri, 22 Jul 1994 01:39:38 +1000 Precedence: list Received: from mail.physics.ox.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12522; Fri, 22 Jul 1994 01:39:26 +1000 (from j.macallister1@physics.oxford.ac.uk) Received: from av1.physics.ox.ac.uk by mail.physics.ox.ac.uk with SMTP (5.65c+/IDA-1.4.4-UK-t for ) id AA14045; Thu, 21 Jul 1994 16:37:10 +0100 Date: Thu, 21 Jul 1994 16:40:00 +0100 (BST) From: John Macallister To: big-internet@munnari.OZ.AU Cc: MACALLSTR@v1.ph.ox.ac.uk Message-Id: <940721164000.2780a25e@v1.ph.ox.ac.uk> Subject: Re: 64-bits 64-bit addressing is only a stop-gap measure and will be seen as such by people outside this group. Anyone planning for the long term will want long term stability for addressing. If IP doesn't give that they will look elsewhere. 64, 128, ... bits : each bridges a longer gap. However, each also guarantees another upheaval down the line. If software is to be modified, wouldn't it be sensible to commit to variable length addressing now and so avoid another upheaval? John From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 03:06:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15671; Fri, 22 Jul 1994 03:06:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA20201; Fri, 22 Jul 1994 03:06:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20196; Fri, 22 Jul 1994 03:01:08 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15557; Fri, 22 Jul 1994 03:01:03 +1000 (from yakov@watson.ibm.com) Message-Id: <9407211701.15557@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7303; Thu, 21 Jul 94 13:00:41 EDT Date: Thu, 21 Jul 94 12:59:30 EDT To: j.macallister1@physics.oxford.ac.uk, big-internet@munnari.OZ.AU Subject: 64-bits Ref: Your note of Thu, 21 Jul 1994 16:40:00 +0100 (BST) John, >64, 128, ... bits: each bridges a longer gap. However, each also guarantees >another upheaval down the line. > >If software is to be modified, wouldn't it be sensible to commit to >variable length addressing now and so avoid another upheaval ? That seems sensible to some, but not all. The following lists some of the views expressed on this topic: - 128 bits is enough, and there never be another upheaval. - By the time 128 bits wouldn't be enough there will be other problems with IPng, so we'll go through another upheaval in any case. - 128 bits is enough for 30 years, and it is ok if after 30 years we'll have another upheaval. Most of the arguments against variable length addresses are focused on performance implications -- it was *asserted* that there is a non-negligible performance impact associated with variable length addresses. Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 03:25:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11608; Fri, 22 Jul 1994 01:17:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA20032; Fri, 22 Jul 1994 01:16:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA19945; Fri, 22 Jul 1994 01:01:27 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10948; Fri, 22 Jul 1994 01:01:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26654; Thu, 21 Jul 94 11:01:11 -0400 Date: Thu, 21 Jul 94 11:01:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407211501.AA26654@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bill.simpson@um.cc.umich.edu Subject: Re: The current 64-bit consensus Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" If we had wanted CLNP-sized headers, we would have adopted CLNP when the IAB put the proposal forward. Instead, we had a coup. Pardon me, but this is a gross simplification of what happpened (and I was in the middle of it, so I recall it all quite well :-(. The upset was not so much over any particular technical detail of CLNP, as over i) the perception that the IAB was trying to cram something down the IETF's throat, and ii) over the notion of using an already standardized and implemented (i.e. hard to modify) protocol, done by another standards body whose working style was not meldable with the IETF, i.e. a loss of control by the IETF. There was also a certain amount of anti-OSI bias, a hangover from the bad old days (may they never come again) when *some* OSI proponents tried to kill off TCP/IP. Finally, there was some unhappiness with the technical details of CLNP, but I wouldn't draw any broad conclusions about that from pure opposition to CLNP. For instance, I was certainly upset about the IAB's move, and CLNP as a choice, but I don't think you can conclue from that that I don't like variable-length addresses! I will thank you to refrain from rewriting history in your zeal to make your case. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 03:36:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13390; Fri, 22 Jul 1994 02:06:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA20114; Fri, 22 Jul 1994 02:06:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA20109; Fri, 22 Jul 1994 02:05:57 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13375; Fri, 22 Jul 1994 02:05:22 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 21 Jul 1994 17:04:48 +0100 To: John Macallister Cc: big-internet@munnari.OZ.AU Subject: Re: 64-bits In-Reply-To: Your message of "Thu, 21 Jul 94 16:40:00 BST." <940721164000.2780a25e@v1.ph.ox.ac.uk> Date: Thu, 21 Jul 94 17:04:46 +0100 Message-Id: <1605.774806686@cs.ucl.ac.uk> From: Jon Crowcroft >64, 128, ... bits : each bridges a longer gap. However, each also guarantees > another upheaval down the line. upheavals are a fact of life. i do not believe we are engineering the addressing to extend beyond our lifetimes, since we do not understand how the technology will change in that time - the phone system people didn't and we would be arrogant to think we can your phrasing 'bridges another gap' hints at the common misunderstanding of exponentiation another 64bits of address is not just twice the address space another bit (my 2 bits worth) is twice the address space do you believe we need more than 2*64 internets worth of address space, and are prepared to pay 5-15% network performance hit, all the time, in all your machines that are networked, and everyone else you network too? also, the change in software is significant - all those checks you have to do at runtime instead of compile time - any one missed and systems crash etc etc....every routing table structure, host interface structure, TCP/UDP PCB lookup code etc etc.... sorry, i just dont trust people to get it right.... another point: software engineering and relase mechanisms may scl;ae much better in IPng with resource control, multicast and security - we may be able to update large numbers of systems simulataenously, securley, quickly, reliably etc.... then the arguments about built in obsolescence are obsolete. cheers jon From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 03:37:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14147; Fri, 22 Jul 1994 02:26:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA20155; Fri, 22 Jul 1994 02:26:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA20141; Fri, 22 Jul 1994 02:13:10 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13692; Fri, 22 Jul 1994 02:13:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27419; Thu, 21 Jul 94 12:09:30 -0400 Date: Thu, 21 Jul 94 12:09:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407211609.AA27419@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, j.macallister1@physics.oxford.ac.uk Subject: Re: 64-bits Cc: MACALLSTR@v1.ph.ox.ac.uk, jnc@ginger.lcs.mit.edu From: John Macallister 64-bit addressing is only a stop-gap measure and will be seen as such by people outside this group. ... each bridges a longer gap. However, each also guarantees another upheaval down the line. ... wouldn't it be sensible to commit to variable length addressing now and so avoid another upheaval? An elgantly simple argument, one which one would think would be accessible to the meanest intelligence, but you're wasting your time. I have been convinced that there is no argument that will convert those who favor fixed-length addresses. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 03:46:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17082; Fri, 22 Jul 1994 03:46:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA20259; Fri, 22 Jul 1994 03:46:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20254; Fri, 22 Jul 1994 03:41:49 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15571; Fri, 22 Jul 1994 03:02:06 +1000 (from ihanson@pcs.dec.com) Received: from cssec4.pcs.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA13004; Thu, 21 Jul 94 09:52:12 -0700 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA13915; Thu, 21 Jul 94 18:51:53 +0200 Message-Id: <9407211651.AA13915@cssec4.pcs.dec.com> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU, ihanson@cssec4.pcs.dec.com Subject: Re: The current 64-bit consensus In-Reply-To: Your message of "Wed, 20 Jul 94 15:42:45 GMT." <2889.bill.simpson@um.cc.umich.edu> Date: Thu, 21 Jul 94 18:51:52 +0200 From: "Iain K. Hanson" X-Mts: smtp >We are not heading toward a 128-bit consensus. We have a clear 64-bit >consensus, with over 2:1 preference. >The appeal for 128 bits comes from only 4 persons, less even than NSAPs. >In fact, most of those 4 are on record historically as supporting IPng >using NSAPs. Many more people than you suggest, have said that they would accept 16 bytes as a compromise, in order to reach rough consensus. I do not currently support any particular IPng ( I'm not sure that I sufficiently understand all the issues to make a choice :-(. ). I do know that I favoured TUBA over PIP & SIP because I did not and still do not beleive that address allocation can form a dense tree and therefore I do not believe that 8 bytes is enough. The best evidence that I can sight for this beleif is history and the Huitema Index. Given the uncertainty regarding whether an address consists of a Locator & EID in every packet or not and the as yet unknown size of a locator, I find your apparent certainty the 64 bits is enough, somewhat supprising. /ikh From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 03:49:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17137; Fri, 22 Jul 1994 03:49:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA20274; Fri, 22 Jul 1994 03:48:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20240; Fri, 22 Jul 1994 03:38:38 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15076; Fri, 22 Jul 1994 02:49:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27727; Thu, 21 Jul 94 12:49:28 -0400 Date: Thu, 21 Jul 94 12:49:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407211649.AA27727@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: 64-bits Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft There's no point in rehashing all the old arguments about how hierarchical addresses are inherently variable length things, and how in a decentralized Internet the depth of various branches will vary (as opposed to centrally administered systems like phone networks), and how nobody knows what the variance will look like, so you can't predict how much space it will take to represent that variable thing, and how our predictions of Internet growth can't even be trusted for 7 years, let along 30, etc, etc, etc. None of this changed any minds before, and it won't now. However, my eye was caught by one part of your message: software engineering and relase mechanisms may sclae much better in IPng with resource control, multicast and security - we may be able to update large numbers of systems simulataenously, securley, quickly, reliably etc.... then the arguments about built in obsolescence are obsolete. If you think you have an idea how to do this, I suggest you work out the details, patent it (the US patent office will patent almost anything softwary these days :-), and retire to a life of idle luxury... :-) Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 04:07:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17729; Fri, 22 Jul 1994 04:07:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA20326; Fri, 22 Jul 1994 04:07:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20306; Fri, 22 Jul 1994 03:59:54 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15935; Fri, 22 Jul 1994 03:16:15 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 21 Jul 1994 18:15:20 +0100 To: yakov@watson.ibm.com Cc: j.macallister1@physics.oxford.ac.uk, big-internet@munnari.OZ.AU Subject: Re: 64-bits In-Reply-To: Your message of "Thu, 21 Jul 94 12:59:30 EDT." <9407211701.15557@munnari.oz.au> Date: Thu, 21 Jul 94 18:15:16 +0100 Message-Id: <345.774810916@cs.ucl.ac.uk> From: Jon Crowcroft >Most of the arguments against variable length addresses >are focused on performance implications -- it was *asserted* >that there is a non-negligible performance impact associated >with variable length addresses. and software complexity is against variable length.... noel just said that fixed+varialble mask is variable. sure, but i can at least write guaranteed-to-never-break code, unless i am really worried about memory requirements etc etc. i just don't trust all those C "hackers" out there who might think you can test whether you've got to the end of a sockaddr_ipng by testing for NULL...(an error i've seen quite a few engineering and computing graduates make...) in fact, another aspect of software engineering will be the ease of using the same code to do IPng and IPv4 for all the dual stack machines - 2 different fixed sizes will encode in the socket type quite easily - you can't encode fixed+variable in C type languages....you need smarter polymorphic typing... jon From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:11:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17719; Fri, 22 Jul 1994 04:06:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA20309; Fri, 22 Jul 1994 04:06:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20292; Fri, 22 Jul 1994 03:51:01 +1000 Precedence: list Received: from netcom2.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17146; Fri, 22 Jul 1994 03:50:58 +1000 (from kck@netcom.com) Received: by netcom2.netcom.com (8.6.8.1/SMI-4.1/Netcom) id KAA22488; Thu, 21 Jul 1994 10:51:15 -0700 Date: Thu, 21 Jul 1994 10:51:15 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407211751.KAA22488@netcom2.netcom.com> To: big-internet@munnari.OZ.AU Subject: Re: 64-bits >The following lists some of the views expressed on this topic: > >- 128 bits is enough, and there never be another upheaval. > >- By the time 128 bits wouldn't be enough there will be >other problems with IPng, so we'll go through another >upheaval in any case. > >- 128 bits is enough for 30 years, and it is ok >if after 30 years we'll have another upheaval. > These seem like the same arguments I have heard for 64 bits as well. Hmm... >Yakov. rich From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:16:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19136; Fri, 22 Jul 1994 04:46:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA20406; Fri, 22 Jul 1994 04:46:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA20403; Fri, 22 Jul 1994 04:40:12 +1000 Precedence: list Received: from OSI.NCSL.NIST.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18953; Fri, 22 Jul 1994 04:40:05 +1000 (from colella@osi.ncsl.nist.gov) Received: from emu.ncsl.nist.gov.noname by osi.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA02723; Thu, 21 Jul 94 14:37:17 EDT Date: Thu, 21 Jul 94 14:37:16 EDT Message-Id: <9407211837.AA02723@osi.ncsl.nist.gov> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: 64-bits Cc: yakov@watson.ibm.com, j.macallister1@physics.oxford.ac.uk, big-internet@munnari.OZ.AU From: colella@nist.gov Reply-To: colella@nist.gov Jon, > and software complexity is against variable length.... > .... > i just don't trust all those C "hackers" out there who > might think you can test whether you've got to the end of a > sockaddr_ipng by testing for NULL...(an error i've seen quite a few > engineering and computing graduates make...) There're also people who've never programmed in their lives -- I wouldn't let *them* near the software either :^). --Richard From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:16:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18448; Fri, 22 Jul 1994 04:26:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA20374; Fri, 22 Jul 1994 04:26:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA20355; Fri, 22 Jul 1994 04:10:54 +1000 Precedence: list Received: from mail.physics.ox.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17796; Fri, 22 Jul 1994 04:10:33 +1000 (from j.macallister1@physics.oxford.ac.uk) Received: from av1.physics.ox.ac.uk by mail.physics.ox.ac.uk with SMTP (5.65c+/IDA-1.4.4-UK-t for ) id AA14688; Thu, 21 Jul 1994 19:09:00 +0100 Date: Thu, 21 Jul 1994 19:11:47 +0100 (BST) From: John Macallister To: big-internet@munnari.OZ.AU Cc: MACALLSTR@v1.ph.ox.ac.uk Message-Id: <940721191147.278092dc@v1.ph.ox.ac.uk> Subject: Re: 64-bits. If it's the general consensus that those writing the new code can only be relied upon to write code for fixed-length addresses, that doesn't say much for the software engineering of this new project. It will be perceived as another great hack (in the old sense of the word) and commercial customers won't touch it with a barge pole for several years until the bugs have been ironed out... and then it may be too late for IPng. The other argument of processing overheads appears to me to be a bit dubious too especially with fast processors at the users' systems where a couple of extra instructions nowadays has no significant impact on performance and code in routers will normally be implemented in firmware or hardware. Those closer to the action may feel that realism dictates fixed length records. It's difficult for us outside to fully comprehend how a modern network can be developed this way. 30 years? I'll give it 10 maximum from date of release before minds turn again to expanding the address space but that will only happen if IPng is widely adopted. With limited fixed length addressing, I have grave doubts about the level of adoption of IPng. I'm sure many people will adapt existing IP configurations with 'hidden networks' rather than move to something with a limited life. Remember that if IPng is not widely adopted, support will be poor simply because things don't get tested thoroughly (i.e. widely used - the best way to test any software is with real users). I don't really expect to be able to influence IPng at this stage but I think it's worthwhile recording my views on the proposed addressing scheme. John From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:25:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21194; Fri, 22 Jul 1994 05:50:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA20475; Fri, 22 Jul 1994 05:46:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA20461; Fri, 22 Jul 1994 05:32:24 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20501; Fri, 22 Jul 1994 05:32:17 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id PAA13768; Thu, 21 Jul 1994 15:31:46 -0400 Date: Thu, 21 Jul 1994 15:31:46 -0400 From: Vadim Antonov Message-Id: <199407211931.PAA13768@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, j.macallister1@physics.oxford.ac.uk Subject: Re: 64-bits Cc: MACALLSTR@v1.ph.ox.ac.uk >64, 128, ... bits : each bridges a longer gap. However, each also guarantees > another upheaval down the line. There is a serious doubt about "guarantees". There can be so much neutrons in the Universe. There is a difference between pessimistic and paranoid. --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:26:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22168; Fri, 22 Jul 1994 06:26:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20545; Fri, 22 Jul 1994 06:26:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20536; Fri, 22 Jul 1994 06:25:03 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21634; Fri, 22 Jul 1994 06:07:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02772; Thu, 21 Jul 94 16:07:30 -0400 Date: Thu, 21 Jul 94 16:07:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407212007.AA02772@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: 64-bits Cc: jnc@ginger.lcs.mit.edu > An elgantly simple argument, one which one would think would be > accessible to the meanest intelligence It has been pointed out to me that this was inappropriate, and unwise. I suppose there's a lot of truth to the former, and I do agree it wasn't very helpful. However, it is an accurate expression of what I think, and no amount of sugar-coating, politeness, or apology can change that. As to the latter, I'm pretty much past caring what anyone thinks anyway. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:28:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22239; Fri, 22 Jul 1994 06:28:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20562; Fri, 22 Jul 1994 06:28:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20542; Fri, 22 Jul 1994 06:25:15 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21574; Fri, 22 Jul 1994 06:04:14 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id NAA23866; Thu, 21 Jul 1994 13:04:01 -0700 Message-Id: <199407212004.NAA23866@Mordor.Stanford.EDU> To: "Iain K. Hanson" Cc: big-internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: The current 64-bit consensus Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 21 Jul 94 18:51:52 +0200. <9407211651.AA13915@cssec4.pcs.dec.com> Date: Thu, 21 Jul 94 13:04:00 -0700 From: Dave Crocker X-Mts: smtp Folks, This recent exchange is a bit confusing. SIPP has been modified in the most recent spec to suppor 128-bit addresses. Based on a note to the TUBA list from Knopper&Ford, the IPng ADs & directorate will be recommending that IPng be based on that SIPP-16 spec. This leaves me confused about the purpose of the recent exchange and debate. Dave ---- Included message: >The appeal for 128 bits comes from only 4 persons, less even than NSAPs. >In fact, most of those 4 are on record historically as supporting IPng >using NSAPs. Many more people than you suggest, have said that they would accept 16 bytes as a compromise, in order to reach rough consensus. From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:30:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22263; Fri, 22 Jul 1994 06:30:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20581; Fri, 22 Jul 1994 06:30:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20539; Fri, 22 Jul 1994 06:25:05 +1000 Precedence: list Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21493; Fri, 22 Jul 1994 05:59:57 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA15620 (5.65c/IDA-1.4.4nsd for ); Thu, 21 Jul 1994 12:59:52 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA02135 (5.65c/IDA-1.4.4-910725 for ); Thu, 21 Jul 1994 12:59:50 -0700 Message-Id: <199407211959.AA02135@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: Re: 64-bits In-Reply-To: Your message of "Thu, 21 Jul 94 12:59:30 EDT." <9407211701.15557@munnari.oz.au> Date: Thu, 21 Jul 94 12:59:50 -0700 From: tracym@NSD.3Com.COM > > Most of the arguments against variable length addresses > are focused on performance implications -- it was *asserted* > that there is a non-negligible performance impact associated > with variable length addresses. > > Yakov. [for completeness] Performance is an important concern for some, but not all, of the opponents of variable length addresses. Please also include the possibly significant costs of variable address formats for higher level software: hosts, routing protocols, DNS etc. (Jim Bound has said a lot in this area.) [on the other hand] I, for one, am not very concerned with the performance problems, and think that both the performance and host-side problems can be made tractable by constraining the variable length options. Tracy From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:32:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22287; Fri, 22 Jul 1994 06:32:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20596; Fri, 22 Jul 1994 06:32:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20522; Fri, 22 Jul 1994 06:24:58 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21203; Fri, 22 Jul 1994 05:50:38 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from [129.213.128.4] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04938 Fri, 22 Jul 1994 05:50:26 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA15351 (5.65c/IDA-1.4.4nsd for ); Thu, 21 Jul 1994 12:47:38 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA02100 (5.65c/IDA-1.4.4-910725 for ); Thu, 21 Jul 1994 12:47:36 -0700 Message-Id: <199407211947.AA02100@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: Re: The current 64-bit consensus In-Reply-To: Your message of "Thu, 21 Jul 94 18:51:52 +0200." <9407211651.AA13915@cssec4.pcs.dec.com> Date: Thu, 21 Jul 94 12:47:35 -0700 From: tracym@NSD.3Com.COM [I'm not sure why I've not been included on any of the favorite address-flavor counting lists as I've sent lots of notes indicating my position. I've been much too busy to do the mail these past four weeks.] However, for the record, 1) I prefer variable with a constrained set of sizes: either 8,16,24,32, or 8,16,32,64 OR -> 1,2,4,8,16,32,64 (try to bring back the embedded folks) 2) I think 16-only may be ok IF wholesale renumbering works 3) I am NOT in favor of, or in any way comfortable with, 8-only I'll not repeat my variable length proposal, which I've pitched both publicly and privately, and for which I've received few negative comments. I do accept Jim Bound's concern with development costs, though I believe my proposal would minimize the up-front requirements. Tracy Mallory 3Com Corporation From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:35:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22326; Fri, 22 Jul 1994 06:35:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20615; Fri, 22 Jul 1994 06:35:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20519; Fri, 22 Jul 1994 06:24:39 +1000 Precedence: list Received: from emory.mathcs.emory.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20042; Fri, 22 Jul 1994 05:15:37 +1000 (from sale@paradox.sware.com) Received: by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.0) via UUCP id AA06581 ; Thu, 21 Jul 94 15:15:24 -0400 Received: by shlep.sware.com (5.65/2.0) from paradox.sware.com id AA16196; Thu, 21 Jul 94 15:13:16 -0400 Sender: Received: from (localhost) by paradox.sware.com with SMTP (5.59/ CMW+ v2.3-eef) id AA06682; Thu, 21 Jul 94 15:15:06 EDT Date: Thu, 21 Jul 94 15:15:06 EDT Message-Id: <9407211915.AA06682@paradox.sware.com> From: Ed Sale X-Mailer: InterMail/CMW [1.3 (alpha)] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jon Crowcroft Cc: big-internet@munnari.OZ.AU Subject: Re: 64-bits In-Reply-To: Your message of Thu, 21 Jul 94 17:04:46 +0100. <1605.774806686@cs.ucl.ac.uk> Jon Crowcroft writes: > > also, the change in software is significant - all those checks you > have to do at runtime instead of compile time - any one missed and > systems crash etc etc....every routing table structure, host interface > structure, TCP/UDP PCB lookup code etc etc.... > > sorry, i just dont trust people to get it right.... > and this too: > > and software complexity is against variable length.... > > noel just said that fixed+varialble mask is variable. sure, but i can > at least write guaranteed-to-never-break code, unless i am really > worried about memory requirements etc etc. > > i just don't trust all those C "hackers" out there who > might think you can test whether you've got to the end of a > sockaddr_ipng by testing for NULL...(an error i've seen quite a few > engineering and computing graduates make...) > > in fact, another aspect of software engineering will be the ease of > using the same code to do IPng and IPv4 for all the dual stack > machines - 2 different fixed sizes will encode in the socket type > quite easily - you can't encode fixed+variable in C type > languages....you need smarter polymorphic typing... > Jon, SNMP has used variable length object ID's from its inception. Dealing with a variable length IPng address should not be any harder than that is. Yeah, there are a lot of people that can't read a spec or write a correct implementation. They probably wouldn't be able to write a correct IPng implementation with fixed-length addresses either. These programmers and/or the companies that employ them will not remain economically viable for long. Having bad implementations around is unavoidable. I don't believe that your point is a valid reason not to pursue variable length IPng addresses. If you're that worried about it you could have someone that you DO trust donate a "correct" implementation to the public domain. We could even put one in the specification itself. Allowing variable length IPng addresses means that we won't have to address this issue again, hopefully for all time. In that case implementors have a long time to get it right! ;-) -- Ed P.S. How long is it going to take the world to figure out that the "consensus" 16-byte IPng address isn't going to fit into most sockaddr structures defined today? From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 06:37:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22380; Fri, 22 Jul 1994 06:37:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20632; Fri, 22 Jul 1994 06:37:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20516; Fri, 22 Jul 1994 06:17:11 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18452; Fri, 22 Jul 1994 04:26:25 +1000 (from rharris@espresso.rt.cs.boeing.com) Received: by atc.boeing.com (5.57) id AA28257; Thu, 21 Jul 94 11:27:54 -0700 Received: from spook.network-b by espresso.rt.cs.boeing.com (4.1/SMI-4.1) id AA01213; Thu, 21 Jul 94 11:25:14 PDT Date: Thu, 21 Jul 94 11:25:14 PDT From: "Richard L. Harris (206) 865-4922" Message-Id: <9407211825.AA01213@espresso.rt.cs.boeing.com> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: The current 64-bit consensus Bill, There is not a current consensus on 64 bits. At least it is not apparent on the list or to me. If there is a consensus it appears to be for 128 bits. Some of the members of the consensus seem to prefer either 64 bits or variable but are willing to come together at 128 in order to build a consensus. > > > From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > > Since we seem to be heading towards a 128-bit consensus and since > > without an NSAPA mapping large chunks of the real world will ignore > > IPng, it seems like a constructive idea to look for the best > > mapping of NSAPAs into 128 bits. Whether this mapping ever gets > > used, the market will tell. > > > Warning: I saw red on this claim, and had to pace for 1/2 hour before I > could bring myself to sit down at the keyboard. > I see red about 80% of the time that you post anything. I have learned to mostly ignore your posting that rant or are unreasonable in order to save myself from 30 minutes of high blood pressure a couple of times a day. By the way, your other 20% of posting includes some realy good stuff, but I'm afraid I probably miss some of the good stuff embedded in the rant. > We are not heading toward a 128-bit consensus. We have a clear 64-bit > consensus, with over 2:1 preference. > Where did you get this? I saw a plurality, not a consensus, for 128 bits. I see more favor for variable than 64 bits. > The appeal for 128 bits comes from only 4 persons, less even than NSAPs. > In fact, most of those 4 are on record historically as supporting IPng > using NSAPs. > So, this means they should be automatically opposed? Your extreme bias at the other end of the spectrum is better? I think this is oversimplifying again and a misstatement just to make your point. > If we had wanted CLNP-sized headers, we would have adopted CLNP when the > IAB put the proposal forward. Instead, we had a coup. > This is not true except as a gross oversimplification focused on one factor that might have been on some peoples minds. > "Large chunks of the real world" have completely ignored NSAPs. These > chunks are so much bigger than the tiny, miniscule, infintessimal size Your biases and prejudice are showing. This is not a reasoned arguement nor true. > of the NSAP adherents that powers of ten normally used for measuring > astronomical distances have to be employed. > > The mapping could only get used in a fractional proportion of the NSAPs > currently used, since only a fraction of the NSAP applications will be > moved to IPng. > Some for very good reasons which you seem to be trying to reinforce. > I invite those NSAP drudges to continue ignoring IPng, as they have > ignored IP. Drudges? Now you have to call names? > > Bill.Simpson@um.cc.umich.edu > Am I misreading the list? Does a majority believe in everything Bill posts so repeatedly and often? I hope that this message doesn't annoy too many list participants but I felt it was time to counter at least one of Bills postings, and I did wait a while to see if others would do so sufficiently so I didn't have to. If you feel that I am out of line I would appreciate private or list addressed responses to this. Rich Harris rharris@atc.boeing.com 206-865-4922 The opinions expressed are of course mine and not my employeers. From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 07:06:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22912; Fri, 22 Jul 1994 07:06:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA20682; Fri, 22 Jul 1994 07:06:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20660; Fri, 22 Jul 1994 06:49:09 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22604; Fri, 22 Jul 1994 06:48:59 +1000 (from louie@uunet.uu.net) Received: by rodan.UU.NET id QQwzod24756; Thu, 21 Jul 1994 16:48:56 -0400 Message-Id: To: big-internet@munnari.OZ.AU From: "Louis A. Mamakos" Subject: Re: 64-bits Date: Thu, 21 Jul 1994 16:48:55 -0400 Sender: louie@uunet.uu.net Oh no, not again. - Hitchhiker's Guide to the Galaxy Douglas Adams From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 07:09:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22952; Fri, 22 Jul 1994 07:09:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA20699; Fri, 22 Jul 1994 07:09:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA20677; Fri, 22 Jul 1994 07:01:01 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22826; Fri, 22 Jul 1994 07:00:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03235; Thu, 21 Jul 94 17:00:53 -0400 Date: Thu, 21 Jul 94 17:00:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407212100.AA03235@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, sale@paradox.sware.com Subject: Re: 64-bits Cc: jnc@ginger.lcs.mit.edu How long is it going to take the world to figure out that the "consensus" 16-byte IPng address isn't going to fit into most sockaddr structures defined today? That's easy enough to get around. Use the hack I mentioned where your DNS call returns a 32-bit quantity which is only locally unique (there's an internal table which maps it into an IPng address), and stick that in the sockaddr. Yeah, you do have to do another level of indirection, but that's less work than changing everything that knows about sockaddr's. Anyway, if you make the 32-bit thingy a pointer to the mapping table entry, it's pretty cheap. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 07:11:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22965; Fri, 22 Jul 1994 07:11:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA20725; Fri, 22 Jul 1994 07:10:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20663; Fri, 22 Jul 1994 06:49:28 +1000 Precedence: list Received: from eagle.es.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22619; Fri, 22 Jul 1994 06:49:23 +1000 (from alh@es.net) Received: from localhost by eagle.es.net; (5.65/1.1.8.2/18May94-0333PM) id AA22176; Thu, 21 Jul 1994 13:48:27 -0700 Message-Id: <9407212048.AA22176@eagle.es.net> To: Jon Crowcroft Cc: John Macallister , big-internet@munnari.OZ.AU, alh@es.net Subject: Re: 64-bits In-Reply-To: Your message of "Thu, 21 Jul 94 17:04:46 BST." <1605.774806686@cs.ucl.ac.uk> Date: Thu, 21 Jul 94 13:48:26 -0700 From: "Tony Hain" X-Mts: smtp >>sorry, i just dont trust people to get it right.... All of your arguments are transition related and apply to any length address, including fixed 64 bit. People won't get it right in any case for some time, so drop the crap and get to the real issues. Way too many people are looking at this transition from the perspective of now and 'how to make the frist step' rather than 'where to end up'. The easy thing to do is to try and grow a bigger version of the past rather than take a radical step. These are times that call for a radical step if we are to generate any reason for people to leave IPv4. Short sighted limits on growth will cause major investors to look elsewhere (like CLNP) to insure long term stability. It is way too easy to ride out IPv4 with hidden networks and end up with a real mess in 5 years. This whole argument about 'how many bits' is silly without some plan for how to use them. I can take the IPv4 address and stick it behind a DCC in an 8 byte NSAP and end up with several of today's scale Internet's and something current routers can handle. I don't think that is a good plan but it is useful to show how limited the 8 byte plans are. When you try and insert some global structure there is little room left for local structure. There will be both! Think about how the bits will get used in the long term rather than worrying about minor short term performance hits. There needs to be a clear LONG TERM plan now and effort to get there. Tony From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 07:26:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23243; Fri, 22 Jul 1994 07:26:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA20757; Fri, 22 Jul 1994 07:26:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA20745; Fri, 22 Jul 1994 07:25:02 +1000 Precedence: list Received: from olivea.atc.olivetti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23213; Fri, 22 Jul 1994 07:24:39 +1000 (from jerry@strobe.ATC.Olivetti.Com) Received: by olivea.ATC.Olivetti.Com (5.65/1.34) id AA29757; Thu, 21 Jul 94 14:22:35 -0700 Received: from strobe.ATC.Olivetti.Com by olivea.ATC.Olivetti.Com (4.1/SMI-4.1) id AA29754; Thu, 21 Jul 94 14:22:33 PDT Received: by strobe.ATC.Olivetti.Com (4.1/SMI-4.1) id AA05522; Thu, 21 Jul 94 14:22:32 PDT Date: Thu, 21 Jul 94 14:22:32 PDT From: jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) Message-Id: <9407212122.AA05522@strobe.ATC.Olivetti.Com> To: big-internet@munnari.OZ.AU, j.macallister1@physics.oxford.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: 64-bits Cc: MACALLSTR@v1.ph.ox.ac.uk Regarding variable length addresses: jnc@ginger.lcs.mit.edu (Noel Chiappa) >An elgantly simple argument, one which one would think would be accessible to >the meanest intelligence, but you're wasting your time. I have been convinced >that there is no argument that will convert those who favor fixed-length >addresses. But there seem to be two extreme camps operating here. One wants fixed, preferably the smallest possible size, addresses. The other seems to be advocating very variable length. While the proponents don't specify exactly the impression I receive is that a byte in the header specifies the address size from 1-256 bytes long. The only other proposal was one were the multiples were of 64 bits. I still say that a few, perhaps three, sizes would be more reasonable. Consider three sizes, 32, 64, and 128 bits. (All right, reserve the forth size for 256 bits.) This would provide for only a limited number of code paths to handle the different sizes. Moreover the arguments for efficiency can be used to support this choice. Over the initial lifetime of the code virtually ALL the addresses being handled will be from the existing base of 32 bit IP. Thus it could handle these efficiently without toteing around an extra 32 bits of useless information. The argument against this seems to be twofold. First is the efficiency of routing. But it is fairly simple to have three code paths each handling a "fixed size" address from its point of view. So only the branch to the three paths is extra overhead. The other is that the code for the different size will not be tested and will fail when the new addresses are deployed. So just deploy a few immediatly to force any connected host to deal with them. Of course this is no guarante that as 64 bit addresses proliferate that lots of code won't overflow tables and such but fixed lenght addresses havn't prevented that from happening in the past either. Jerry Aguirre From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 14:26:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04555; Fri, 22 Jul 1994 14:26:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA21122; Fri, 22 Jul 1994 14:26:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA21106; Fri, 22 Jul 1994 14:14:37 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04100; Fri, 22 Jul 1994 14:14:32 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-27.dialip.mich.net (pm002-27.dialip.mich.net [35.1.48.108]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id AAA09442 for ; Fri, 22 Jul 1994 00:14:28 -0400 Date: Fri, 22 Jul 94 01:26:41 GMT From: "William Allen Simpson" Message-Id: <2907.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: The current 64-bit consensus > From: "Richard L. Harris (206) 865-4922" > There is not a current consensus on 64 bits. At least it is not apparent > on the list or to me. > Where did you get this? I saw a plurality, not a consensus, for 128 bits. > I see more favor for variable than 64 bits. > By counting. The results were posted. You were included. Please list the email addresses that were overlooked in the responses to the subject "IPng ADs wish to gauge consensus". Posting large numbers of messages does not get you more favor. > > The appeal for 128 bits comes from only 4 persons, less even than NSAPs. > > In fact, most of those 4 are on record historically as supporting IPng > > using NSAPs. > > > So, this means they should be automatically opposed? Your extreme bias > at the other end of the spectrum is better? I think this is > oversimplifying again and a misstatement just to make your point. > By the word "misstatement", you are calling me a liar. This seems to be the prevalent rhetorical technique from Boeing. If you believe the statement is untrue, then, you should say which of these 4 did not historically support NSAPs for IPng. There is a long history of politicians salting the opposition to stall them. Ask the Democratic Party about Wallace winning Michigan in '72. Just because you are naive, does not vitiate the truth and relevance. > > "Large chunks of the real world" have completely ignored NSAPs. These > > chunks are so much bigger than the tiny, miniscule, infintessimal size > > Your biases and prejudice are showing. This is not a reasoned arguement > nor true. > Again, you state it is not "true" that NSAPs are a minor fraction of the deployed network software. Show me the sales figures. Your level of argument "liar, liar, your pants are on fire" is less than salubratory. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 16:06:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08342; Fri, 22 Jul 1994 16:06:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA21285; Fri, 22 Jul 1994 16:06:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA21280; Fri, 22 Jul 1994 15:56:55 +1000 Precedence: list Received: from relay3.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07935; Fri, 22 Jul 1994 15:56:45 +1000 (from blkcat!org!fidonet!z1!n109!f417!Paul.Robinson@uunet.uu.net) Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQwzpn18462; Fri, 22 Jul 1994 01:56:29 -0400 Received: from blkcat.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 22 Jul 1994 01:56:29 -0400 Received: by blkcat.fidonet.org (GIGO 0.99 pl1) id AA04529; 22 Jul 94 00:17:44 -0500 From: Paul.Robinson@f417.n109.z1.fidonet.org (Paul Robinson) Date: 21 Jul 94 20:08:57 -0500 Subject: Re: IPng ADs request Message-Id: <123_9407220017@blkcat.fidonet.org> Organization: Fidonet: X-Mail-Agent: GIGO+ sn 28 at blkcat vsn 0.99 pl1 To: big-internet@munnari.OZ.AU Masataka Ohta writes: >> Looking ahead, I can just imagine the supervisor telling the >> building manager "Sorry Sir, but your newly installed internet- >> capable elevator refuses to start until XYZ Corp overseas repairs >> their internal network". > > IMHO, it's better than "Sorry Sir, but your newly installed > internet-capable elevator is hijacked." There is a recent report that Schindler Elevator Company is being sued because they refuse to give the password to access the maintenance mode on computers used to operate elevators they maintain, because then the building owner can get any company to do the maintenance. This incident is being referred to as "The problem with Schindler's Lifts." --------- Fidonet: Paul Robinson 1:109/417 Internet: Paul.Robinson@f417.n109.z1.fidonet.org From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 16:48:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06676; Fri, 22 Jul 1994 15:26:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA21238; Fri, 22 Jul 1994 15:26:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA21209; Fri, 22 Jul 1994 15:23:44 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05828; Fri, 22 Jul 1994 15:02:19 +1000 (from kre@munnari.OZ.AU) To: John Macallister Cc: big-internet@munnari.OZ.AU Subject: Re: 64-bits In-Reply-To: Your message of "Thu, 21 Jul 1994 16:40:00 +0100." <940721164000.2780a25e@v1.ph.ox.ac.uk> Date: Fri, 22 Jul 1994 15:02:15 +1000 Message-Id: <29011.774853335@munnari.OZ.AU> From: Robert Elz Date: Thu, 21 Jul 1994 16:40:00 +0100 (BST) From: John Macallister Message-ID: <940721164000.2780a25e@v1.ph.ox.ac.uk> If software is to be modified, wouldn't it be sensible to commit to variable length addressing now and so avoid another upheaval? The problem with variable addressing (with 2 exceptions I will mention) is that its almost useless, it really dosn't gain you what you expect. First the exceptions. One is if you're Noel. If you're Noel you're asking for a different thing to almost everyone else, it just happens that both include the "variable" word. The second is if you want to design a packet format (eg: CONS, or CLNP) but you don't want to work out addressing yet, but leave it to later. Designing a variable length field into the packet headers in those circumstances makes lots of sense, as it allows the addressing structures to be designed in a way that makes sense (but how did they end up with NSAPs?) without being constrained by a fixed field. Once the addressing is designed its likely that a fixed field width (eg: 20 bytes) will be picked, and the supposed variablility essentially unused. The fact that the packet format would allow for different address widths is pretty meaningless in these circumstances. However, if you're designing the addressing structure along with the packet format, the packets may just as well be designed for the particular fixed size that the addressing is assuming and be done with it. As Lixia pointed out, and I tried to say before, to make variable addressing realy workable, the variable bit has to be in the middle of the address, not at the left end, and certainly not at the right end. The "middle" means at any arbitrary bit (perhaps byte if you want to waste space). Of course that includes growth at either end, but isn't restricted to that. The problem with this is that at the minute we have absolutely nothing that is working with this kind of address. Simply sticking in a variable field, and hoping to use it without software updates won't work, as basic code like "is this packet for me" need to know how this kind of addressing works. That is, to make use of meaningful variable length addresses we're going to have to have host level software changes anyway, again, designing in a variable length field in the hope that it will assist in some way doesn't seem useful. Unless you're Noel, I think that most of the "I prefer variable" is based upon the "obvious" assumption that "If I can make it longer, I can make more addresses", which I don't think is realistic. Its an example of something that is so obvious its broken. Now if you are Noel, you understand all of this, and have a plan for how to actually make all of this work, and I believe that the plan is a good one, and can really work. I don't think it can work with any kind of unchanged use of the host software we're building right now however, so building the infrastructure to support Noel's architecture now doesn't seem likely to be reasonable. If we could wait a bit longer ("bit" -> couple of years) it very well might be. Now no. What we should be building however is the mechanisms that will allow graceful transition to Noel's vision (or someone else's yet to be discovered) if and when that looks like the right thing to do. We need the ability to simultaneously run multiple different network levels in different parts of the internet, with (all) transport protocols running seamlessly over that. kre From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 19:13:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12547; Fri, 22 Jul 1994 17:47:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA21387; Fri, 22 Jul 1994 17:46:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA21371; Fri, 22 Jul 1994 17:36:21 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12126; Fri, 22 Jul 1994 17:36:11 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Jul 1994 08:35:55 +0100 To: John Macallister Cc: big-internet@munnari.OZ.AU Subject: Re: 64-bits. In-Reply-To: Your message of "Thu, 21 Jul 94 19:11:47 BST." <940721191147.278092dc@v1.ph.ox.ac.uk> Date: Fri, 22 Jul 94 08:35:51 +0100 Message-Id: <382.774862551@cs.ucl.ac.uk> From: Jon Crowcroft >If it's the general consensus that those writing the new code can only be > relied upon to write code for fixed-length addresses, that doesn't say > much for the software engineering of this new project. it isn't the 90% of people who have to get it right - it is the effect in networking of 1 person getting it wrong.... in 15 years research&development, i can certainly say that designing for dumbness is the right way to go when dealing with multi-vendor systems - that is why IPv4 happend to work right... there is a design principle in IP (another of those neat phrases like rough consensus and working code) that went somethign like: be conservative in what you send and liberal in what you accept. this could be applied just as easily to the IPv4->IPng design process. >The other argument of processing overheads appears to me to be a bit dubious > too especially with fast processors at the users' systems where a couple of > extra instructions nowadays has no significant impact on performance and code > in routers will normally be implemented in firmware or hardware. it is the server performance that is the problem, not the routers - there are 2 orders of magnitude more hosts than routers, and they have a write-off period that is typically 2-3 times as long and given a total TCP+IPv4 processing loop takes ~40 instrutions, adding per packet overhead without very good excuse is a bad idea - especially since it happens - craig partridge and others hashed out this debate a couple of minths ago. >I don't really expect to be able to influence IPng at this stage but I think > it's worthwhile recording my views on the proposed addressing scheme. & a good thing to have as many views as possible.... the problem is that each view has to be set against the range of knowledge of the expresser - what views to you have on PONS, ASSDM or other technologies just over the horizon aimed at the global information superhighway by the telcos? how will pico-cell mobile and vsat terminal useage vary? etc etc.... these are other things people in the IPng WG are worried about jon From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 20:49:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18478; Fri, 22 Jul 1994 20:49:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA21551; Fri, 22 Jul 1994 20:46:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA21535; Fri, 22 Jul 1994 20:27:55 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17740; Fri, 22 Jul 1994 20:27:49 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28830 Fri, 22 Jul 1994 20:27:24 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Jul 1994 11:24:15 +0100 To: Tony Hain Cc: John Macallister , big-internet@munnari.OZ.AU Subject: Re: 64-bits In-Reply-To: Your message of "Thu, 21 Jul 94 13:48:26 PDT." <9407212048.AA22176@eagle.es.net> Date: Fri, 22 Jul 94 11:24:10 +0100 Message-Id: <1460.774872650@cs.ucl.ac.uk> From: Jon Crowcroft >It is way too easy to ride out IPv4 with hidden networks and end up with >a real mess in 5 years. ALE predict IPv4 is good til 2005. 32to64bit migration would allow exponential growth with CIDR aggregation for a futher 32 years are you telling me you think IPng will be around in 2037 and not require another radical overhaul before then for other reasons? lets look back 43 years ago, to 1953. what kind of networking did people do then? >Think about how the bits will get used in the long term rather than worrying >about minor short term performance hits. There needs to be a clear LONG TERM >plan now and effort to get there. the 8byte locator+ 8 byte EID allocatrion plans for SIPP are perfectly adequate for anything anyone has imagined. I have yet to see a single hint of a reason why you want more as i've said several times you may want less, but as i also said, Van's header compression will work fine for those situations...and other people have UDP+IPng header compression techniques in the pipeline... william of occam says why have another length field in the packet and a bunch of code to test it when we have a mask&match procedure which noel keeps telling us does the same job, but the only extra things that are exchanged are in the routing updates instead of every packet... jon From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 22:53:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22297; Fri, 22 Jul 1994 22:53:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA21667; Fri, 22 Jul 1994 22:47:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA21651; Fri, 22 Jul 1994 22:39:56 +1000 Precedence: list Received: from access1.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21803; Fri, 22 Jul 1994 22:39:45 +1000 (from tdarcos@access.digex.net) Received: by access1.digex.net id AA00965 (5.67b8/IDA-1.5 for Big-Internet@munnari.oz.au); Fri, 22 Jul 1994 08:38:09 -0400 Newsgroups: tdr.paul.private.mail Date: Fri, 22 Jul 1994 08:38:09 -0400 (EDT) From: Paul Robinson Sender: Paul Robinson Reply-To: Paul Robinson Subject: About running IPv4 once IPng is created To: Big-Internet@munnari.OZ.AU, IETF List Message-Id: <01.1994Jul22.06h10m50s.PAUL-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA Followups-To: Big-internet@munnari.oz.au ----- I think an issue which needs to be considered is the method for mapping the "new" address system - whatever that is, 8-byte, 16-byte, 20-byte, or variable, or factor-x - into an "old" system address for equipment which is used in the old environment. Please excuse my not using the precise terms for some items; I'm not an engineer and I don't have the exact port addresses on hand, but that is trivial; I think the ideas I am raising here are important. This idea I am bouncing off people in this missive may duplicate one or more of the suggestions already out there or it may have been thought of already, but I thought I would raise the issue. Internet is not a dictatorship or a commercial enterprise where those who want to connect can be forced to switch, e.g. when a country changes its telephone system, such as Japan did when it added an extra digit to phone numbers in Tokyo, or as the U.S. is doing now by changing area codes to allow the second digit of an area code to be 0-9 instead of only 0 and 1. In the U.S., for example, those wanting to connect PBX systems to the Public Switched Telephone Network (PSTN) have no alternative; if they want to place calls over the PSTN, they have to be able to make calls to the new style area codes, which may (probably) conflict with prefixes codes in their switches, e.g. dialing 9-1-NN (where "N" is 2-9) indicates a call within the same area code, e.g. 9-1-520-555-1140 will try to connect to local number 520-5551 rather than dialing a long distance number, rather than what is new: dialing a long distance number in the new area code 520. There is going to be some period - perhaps years, perhaps forever - when there will need to be some means to allow those who are totally on the IPNG - whatever it is decided to be - to be reached by, and reach out to, those still on IPV4. And also to support those who have to run both IP stacks on their gateways and firewalls. Therefore, whatever method is chosen, there are two things that *should* be done to make the conversion less painful: 1. IPng addresses should be different appearing from IPv4, such that some part of the identifier should be clear and obvious as being IPng as opposed to IPv4. This would allow a gateway to know the difference immediately, often with as little as 8 bits being read. There are myriad ways of doing this: - Perhaps, we take some group of the first 4 bits of IPv4 that have been reserved and any address starting with that 4-bit sequence is an IPng address. Is there a 4-bit sequence that is available? Or perhaps 8 consecutive class A numbers to support both the new addresses and the conversion codes as indicated in (2) below? - One way is to have all IPng addresses start with one or several of the high-bytes in class "A" of IPv4 that is not used by customers and is reserved by IANA. This one would not be hard, as many whole first octets are reserved. - Another would be to use a few of the high numbers, e.g. 255 or something, but that, also, conflicts with multicast or internal routing or something else. Same thing as borrowing some octets from Class A. Whether you take from the front, or from the back, is irrelevant as long as it's consistent. - Another would be factor "X" - an idea I haven't thought of as yet, but someone will suggest. 2. There must be a method to allow an IPng address to receive a temporary mapping from IPng *down* to IPv4. One way to do this is to use part of the suggestion in (1). Some part of the address space that is set up to distinguish IPng from IPv4 will also be used to indicate a temporary address that has a short "time to live" that is dependent upon the type of transaction. An SMTP dialog can be held to "live" for perhaps 5 minutes. An FTP connection might have to "live" for at least 10 minutes, perhaps longer. An IRC or Telnet connection might have to stay around a longer time, perhaps 3-12 hours, and so on. It depends on the type of transaction and what is being done. This could be the "minimum" time, perhaps it could be set at 4 hours, but an application can specify either a shorter or longer TTL. A corollary to this is how these addresses are going to be allocated, and how do we set them up? The simplest way I can think of is that there will have to be many "reverse lookup servers" set up for this purpose, just like the root servers. We will need a new assigned port address for this purpose, or we will have to use the DNS / Reverse DNS lookup port. A new port number would be available for requesting a number that has a longer TTL duration, and the standard port number would return a "default" duration based on some metric of usual and customary connection times, plus some fudge factor, e.g. if your average transaction lasts 20 minutes, the "default" might be 40 minutes or an hour or two, or some number people feel comfortable with. Each server will be assigned a segment of the address block in the conversion address pool, and will assign addresses from its pool of free addresses. One way to increase the "time to live" is to reuse old addresses on a "circular" basis, e.g. old addresses that were used before are reused after all other addresses owned by that server are exhausted. For example, Let's say that Class A addresses starting with 48-64 are assigned to us for IPng: any address starting with binary 00110000 thru 00111111 is an IPng address. Now, let's say that blocks 63 and 64, e.g. 00111110 through 00111111 are used for conversion, e.g. 63.0.0.0 through 64.255.255.255 would be used, minus the usual reserved codes of all 0 or all 255 etc. Now, each of the 512 blocks of addresses could be assigned to various servers either in one or more blocks for them to use for IPv4 assignments; a program would call up a server and ask for a DNS translation of a name into a number, or a new format program would ask for an IPv4 address to talk to an IPv4 site. Any organization that has its own Class A address might be assigned one of the blocks themselves since if they have that many addresses, they will need their own conversion tables and thus may want to provide their own connections for their own sites. Let's take a typical transaction: A. Someone at site 48.1588.2101.3012.3400 (house.49334.domain-park.svc) asks for a connection to ftp.games.tdr.com (198.133.86.10) to get a copy of some game from my ftp site. B. Since they need a return path - which may not be the same as the path to them - they need a return address to send back the file data. C. His machine asks for a temporary IPv4 number for 10 minutes. His nearest IPng proxy ID server assigns the number 63.24.11.5 to be the IPv4 equivalent for 48.1588.2101.3012.3400 (I'll call it "'3400 from now on) and marks 63.24.11.5 as in use. Next request would be assigned 63.24.11.6, and so on. Eventually, when it gets to the end of its assignments, it would start over at the lowest number that is not still in use. D. '3400 makes a connection, and tells 198.133.86.10 (I'll use "'10" from now on) that its name is house.49334.domain-park.svc and its IPv4 number is 63.24.11.5 (I'll use "'5" from now on) with a TTL of 10 minutes. E. '10 does a lookup of house.36021.domain-park.svc with the server handling DNS for 63.24 and discovers this is a valid address. F. '3400 asks '10 for a file. G. '10 starts throwing packets out to '5. H. Connections along the way are getting a new request address, ('5) so they query the server handling that. If an IPng server sees the address, it knows it's a proxy, and can ask for both the IPv4 and IPng address of the connecting site(s) for '3400, and route accordingly. I. As each router along the way has the address of the next router in line, it doesn't need to do any more IPng/IPv4 lookups, and the transaction will go along quickly once all the addresses are established. The nice thing about this is that it doesn't matter whether you are using an IPv4 provider or IPng provider; when an IPng site wants to connect with an IPv4 address, it gets a temporary number; each IPng site along the way that doesn't have a permanent one will also get temporary numbers. A faster method - probably necessary - would be for some sites to have permanent IPv4 AND IPng site numbers - the proxy IP servers will have to be dual ID for obvious reasons - and thus the providers running connections will have IDs for both numbers. Another possibility is to create a class of number that is automatically "dual provider" - for example, 64.128.0.1 through 64.255.255.254 might be assigned in both IPv4 and IPng to point to the same sites, each being the identifier for a router, bridge, proxy server or other device that requires a permanent dual identifier. Thus the identifier is identical in both IPng and IPv4. Perhaps some "standard" number - perhaps 64.255.255.254 - can be set up as a "return nearest IPv4 proxy server". This would be a ficticious ID that returns different sites depending on where the caller is. Or maybe this isn't needed, I'm not sure. In thinking about this, I have just converted myself and reached the conclusion that we will have to have variable length IPng numbers because we should, from this method, be able to support both IPng and IPv4 within the same numbering scheme with as little change to existing equipment as possible. This means that we can support a "variable" sized number by using something in the number, perhaps the first 4 bits, to indicate the number of octets that follow, allow a variable length number from 1 to 16 bytes in length, or however many bits we want to reserve for size of identifier. In my case, I am making the numbers obviously NON IPv4 in order to make it clear; each field is a 12-bit number. It can be done any way desired, either in byte, byte plus fraction, or multibyte, as long as the field is some integral number of bytes. So, any comments? --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Fortune Cookie was selected only for this message: "Wer'e going to blast through the Internet like the Four Horsemen of the Apocalypse!" - Sonny Harari, Tekwar: "TekJustice" From owner-Big-Internet@munnari.OZ.AU Fri Jul 22 23:06:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23004; Fri, 22 Jul 1994 23:06:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA21699; Fri, 22 Jul 1994 23:06:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA21694; Fri, 22 Jul 1994 23:03:51 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22885; Fri, 22 Jul 1994 23:03:38 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Jul 1994 14:03:23 +0100 To: Big-Internet@munnari.OZ.AU Subject: Re: About running IPv4 once IPng is created In-Reply-To: Your message of "Fri, 22 Jul 94 08:38:09 EDT." <01.1994Jul22.06h10m50s.PAUL-0100000@TDR.COM> Date: Fri, 22 Jul 94 14:03:21 +0100 Message-Id: <2160.774882201@cs.ucl.ac.uk> From: Jon Crowcroft please unsubscribe jon :-) From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 00:14:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23644; Fri, 22 Jul 1994 23:26:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA21742; Fri, 22 Jul 1994 23:26:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA21726; Fri, 22 Jul 1994 23:18:33 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23323; Fri, 22 Jul 1994 23:18:27 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET id QQwzqr07533; Fri, 22 Jul 1994 09:18:17 -0400 Message-Id: To: big-internet@munnari.OZ.AU Subject: what breaks when and what it means Date: Fri, 22 Jul 1994 09:18:17 -0400 From: "Mike O'Dell" Whether the choice is 8 or 16 bytes doesn't really matter, I don't believe, because neither will save us from the next dragon to be slain. Assertion: the current routing and forwarding model will not scale to anywhere near exhaustion of an 8-byte address, much less a 16-byte address. Solving this problem will require some fundamental changes to routing and forwarding - I happen to think Nimrod is on the right track. Consider: the current Internet is alive and working because DNS removes the requirement for every host in the universe to know the IP address of every other one. Delegation - the secret to scaling. THe current routing structure requires a large number of routers to do "full routing", ie, to contain next-hop information for EVERY network connected to the Internet. How many networks did we say we wanted to support? 10E9 10E12? I forget, but its more memory than I'll be able to put in very many routers.... CIDR certainly helps a LOT - it gives us compression and information hiding, the other two magic bullets needed for scaling, but it doesn't address Delegation in a way that avoids pure hierarchical routing (something the Phone Companies tried but abandoned). So, somewhere in the next 10 years, we will have to do a major overhaul of the routing and forwarding mechanisms in the Internet. I believe that most of it can be done in routers, and not even all routers at that, but it will have to be done. Given that such a change is coming, and given the shape of Nimrod machinery, I believe 8 byte addresses will easily last long enough to get to Nimrod, and at that point, they essentially become names and you don't care anymore about how densely you allocate them. That unsupportable prediction made, however, I'll support 16-byte addresses if that's the nucleus of condensation for the consensus. If we believe 16 *really* gives us more wiggle room for or after slaying the next dragon, then full speed ahead. -Mike O'Dell Resident Crank and Blind Seer From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 00:26:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25960; Sat, 23 Jul 1994 00:26:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA21942; Sat, 23 Jul 1994 00:26:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA21810; Sat, 23 Jul 1994 00:12:49 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24433; Fri, 22 Jul 1994 23:48:37 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Jul 94 22:38:55 +0859 From: Masataka Ohta Message-Id: <9407221339.AA29119@necom830.cc.titech.ac.jp> Subject: Re: what breaks when and what it means To: mo@uunet.uu.net (Mike O'Dell) Date: Fri, 22 Jul 94 22:38:53 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: ; from "Mike O'Dell" at Jul 22, 94 9:18 am X-Mailer: ELM [version 2.3 PL11] > Assertion: the current routing and forwarding model will not scale to > anywhere near exhaustion of an 8-byte address, much less a 16-byte > address. Solving this problem will require some fundamental changes > to routing and forwarding - I happen to think Nimrod is on the right > track. Why do you think you can't do Nimrod like routing with fixed length 8 byte locator + fixed length 8 byte EID? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 00:27:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25970; Sat, 23 Jul 1994 00:27:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA21959; Sat, 23 Jul 1994 00:27:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA21796; Sat, 23 Jul 1994 00:09:36 +1000 Precedence: list Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22730; Fri, 22 Jul 1994 22:59:30 +1000 (from tdarcos@access.digex.net) Received: from access1.digex.net by shark.mel.dit.csiro.au with SMTP id AA09968 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 22 Jul 1994 22:49:02 +1000 Received: by access1.digex.net id AA01341 (5.67b8/IDA-1.5 for Big-Internet@munnari.oz.au); Fri, 22 Jul 1994 08:44:00 -0400 Newsgroups: tdr.paul.private.mail Date: Fri, 22 Jul 1994 08:43:59 -0400 (EDT) From: Paul Robinson Sender: Paul Robinson Reply-To: Paul Robinson Subject: New V. Old Bake-Off To: Big-Internet@munnari.OZ.AU Message-Id: <01.1994Jul22.08h38m40s.PAUL-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- I think a test comparison of some working implementation of whatever people want to try, run in a simulation of operating conditions, of the various designs, would be appropriate. A cooperative test run by the various vendors in an environment where all of the people involved can discuss the issues privately would be fine. One thing that might be necessary might include an antitrust waiver to prevent legal issues from being waived. U.S. Copyright law has one for organizations which are setting up or negotiating copyright licenses or royalty schedules. We might want to get one specifically to cover the development of engineering protocols. --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: Wethern's Law: Assumption is the mother of all screw-ups. From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 00:28:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25983; Sat, 23 Jul 1994 00:28:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA21976; Sat, 23 Jul 1994 00:28:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA21813; Sat, 23 Jul 1994 00:14:48 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25385; Sat, 23 Jul 1994 00:05:34 +1000 (from ihanson@pcs.dec.com) Received: from cssec4.pcs.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA29786; Fri, 22 Jul 94 06:44:09 -0700 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA17671; Fri, 22 Jul 94 15:43:31 +0200 Message-Id: <9407221343.AA17671@cssec4.pcs.dec.com> To: Paul Robinson Cc: Big-Internet@munnari.OZ.AU, IETF List , ihanson@cssec4.pcs.dec.com Subject: Re: About running IPv4 once IPng is created In-Reply-To: Your message of "Fri, 22 Jul 94 08:38:09 EDT." <01.1994Jul22.06h10m50s.PAUL-0100000@TDR.COM> Date: Fri, 22 Jul 94 15:43:30 +0200 From: "Iain K. Hanson" X-Mts: smtp Paul Robinson wrote: >1. IPng addresses should be different appearing from IPv4, such that > some part of the identifier should be clear and obvious as being IPng > as opposed to IPv4. This would allow a gateway to know the > difference immediately, often with as little as 8 bits being read. I bveleive this is the job of the version field in the header! >2. There must be a method to allow an IPng address to receive a > temporary mapping from IPng *down* to IPv4. One way to do this is > to use part of the suggestion in (1). Some part of the address > space that is set up to distinguish IPng from IPv4 will also be used > to indicate a temporary address that has a short "time to live" that > is dependent upon the type of transaction. This email must have taken some time and effort to construct. Can I respectfully suggest that the time and effort might have been put to better use by reading one of the proposed transition strategies such as draft-ietf-sipp-ipae-transition-01.txt. /ikh p.s. I've also been foolish enough to be caught not having RTM From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 01:51:53 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29031; Sat, 23 Jul 1994 01:51:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03700 Sat, 23 Jul 1994 01:49:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA22151; Sat, 23 Jul 1994 01:47:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA22115; Sat, 23 Jul 1994 01:38:59 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28564; Sat, 23 Jul 1994 01:38:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09466; Fri, 22 Jul 94 11:38:51 -0400 Date: Fri, 22 Jul 94 11:38:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407221538.AA09466@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mo@uunet.uu.net Subject: Re: what breaks when and what it means Cc: jnc@ginger.lcs.mit.edu From: "Mike O'Dell" Assertion: the current routing and forwarding model will not scale to anywhere near exhaustion of an 8-byte address, much less a 16-byte address. Solving this problem will require some fundamental changes to routing and forwarding ... CIDR certainly helps a LOT - it gives us compression and information hiding, the other two magic bullets needed for scaling I'm not sure I see your point here. You can represent a variable-length hierarchical address in a fixed field, *until you run out of bits*. The fixed-length field doesn't prevent you from deploying whatever scaling mechanisms you want, it just limits the size and shape of the address tree. The latter may of course prove fatal (and I think it will), but that's different... but it doesn't address Delegation in a way that avoids pure hierarchical routing (something the Phone Companies tried but abandoned). Again, I'm not sure I see this. CIDR doesn't mandate pure hierarchical routing, it all depends on what routing info you let flow where, and it also does allow address assignment delegation (although in an inflexible, top-down fashion). I believe 8 byte addresses will easily last long enough ... at that point, they essentially become names and you don't care anymore about how densely you allocate them. Yes, is is a possible transition strategy for IPv4 too; treat the 32-bit things as names, and translate them to something else that the routing uses. That unsupportable prediction made, however, I'll support 16-byte addresses if that's the nucleus of condensation for the consensus. If your previous point was correct, and 8 bytes is large enough to *number* all the hosts for quite some time (not *address*, which is a different set of rules altgether on usage), then 16-bytes is unfortunate, since it does mean a lot more header overhead. Yes, it can be reduced by header compression, so you have state in routers, and a small field in the packets, but all of a sudden this sounds awful familiar. :-( The bug is that the header compression solution, like mobility in NSAP's, is a local solution, when the same general approach, if you're brave enough to apply it globally, gets you a much nicer system. One of the things I always liked about the flow model was that it had the potential to produce really short headers, and the routers only had to look at a single, short field. Oh well. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 02:55:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28119; Sat, 23 Jul 1994 01:26:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA22097; Sat, 23 Jul 1994 01:26:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA22072; Sat, 23 Jul 1994 01:07:33 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27451; Sat, 23 Jul 1994 01:07:29 +1000 (from yakov@watson.ibm.com) Message-Id: <9407221507.27451@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0825; Fri, 22 Jul 94 11:07:27 EDT Date: Fri, 22 Jul 94 11:06:27 EDT To: kre@munnari.OZ.AU, j.macallister1@physics.oxford.ac.uk Cc: big-internet@munnari.OZ.AU Subject: 64-bits Ref: Your note of Fri, 22 Jul 1994 15:02:15 +1000 Robert, >The problem with variable addressing (with 2 exceptions I will mention) >is that its almost useless, it really doesn't gain you what you expect. One more exception -- it allows different types of addresses to be of different length. For example, it allows cluster addresses to be shorter (e.g. 8 octets) than unicast addresses (e.g. 16 octets). This way, if you use cluster addresses for source routing, you may get more efficient encoding (fewer bits). >The second is if you want a design a packet format (eg: CONS or CLNP) >but you don't want to work out addressing yet, but leave it to later Or you may work out addressing, but want to allow in the future to change it. This way, once the addressing is design, it doesn't have to stay the same for the lifetime of the packet format itself. Or to put it differently, once you'll discover that the addressing designed doesn't work any more, you can redesign your addressing without requiring to change packet format. Yakov. From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 02:59:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29589; Sat, 23 Jul 1994 02:06:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA22183; Sat, 23 Jul 1994 02:06:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA22167; Sat, 23 Jul 1994 01:54:46 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28045; Sat, 23 Jul 1994 01:23:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09362; Fri, 22 Jul 94 11:22:56 -0400 Date: Fri, 22 Jul 94 11:22:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407221522.AA09362@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: 64-bits Cc: jnc@ginger.lcs.mit.edu when we have a mask&match procedure which noel keeps telling us does the same job Don't be to quick to cite me as an authority; I mean, if I'm wrong about needing variable length addresses, how do you know I'm not wrong here too? Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 03:01:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28940; Sat, 23 Jul 1994 01:46:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA22134; Sat, 23 Jul 1994 01:46:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA22129; Sat, 23 Jul 1994 01:41:25 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28648; Sat, 23 Jul 1994 01:41:15 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA00512; Fri, 22 Jul 94 08:43:23 -0700 Date: Fri, 22 Jul 94 08:43:23 -0700 From: Eric Fleischman Message-Id: <9407221543.AA00512@atc.boeing.com> To: big-internet@munnari.OZ.AU Subject: Re: The current 128 bit consensus >From: "William Allen Simpson" >We are not heading toward a 128-bit consensus. We have a clear 64-bit >consensus, with over 2:1 preference. > >The appeal for 128 bits comes from only 4 persons, less even than NSAPs. >In fact, most of those 4 are on record historically as supporting IPng >using NSAPs. Dear Bill, I am surprised by your statements above. It is my belief that the community has come to a consensus position on SIPP. That consensus is for 128 bit addresses. This seems to be a very strong "rough consensus" opinion on the several lists I read. Now I must admit that I did find your poll interesting. You undertook to do the difficult job of abstracting from postings -- some of them quite lengthy and rambling about differing topics -- opinion summaries of roughly 20 people. The fact that at least one person subsequently posted that you put him in the wrong camp and that others complained that you did not count them in your poll despite their clear statements is not surprising: It is VERY difficult to do what you were trying to do. However, I did note two things: 1) The person who was wrongly identified and subsequently notified the list of the fact was counted by you as an 8 byte supporter and turned out really to be one of the more outstanding variable length advocates. Similarly, all of the ones complaining about not being counted were variable length advocates. 2) You are perhaps the most dedicated SIPP-8 supporter that I have encountered on any of the lists I regularly read. Now mind you, abstracting opinions is difficult. However, your posted results would have been more believable had they been compiled by someone who was less "well known" as an advocate or had the errors not been consistently in favor of the conclusion you were advocating. As it is, it looks like the fox guarding the chicken coop. However, none of this is really material. What is material is that the community as a whole has formed a rough consensus position upon fixed 128 bit addresses. The fact that neither you nor I particularly desire this conclusion is immaterial. What is material is that it is time for us all to begin working together as a community upon this consensus. It took us literally years to arrive at this consensus. Now let's move on. Sincerely yours, --Eric Fleischman , From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 03:06:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01507; Sat, 23 Jul 1994 03:06:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA22263; Sat, 23 Jul 1994 03:06:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA22260; Sat, 23 Jul 1994 02:59:44 +1000 Precedence: list Received: from monk.proteon.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00200; Sat, 23 Jul 1994 02:28:39 +1000 (from avri@proteon.com) Received: from rockford.proteon.com by monk.proteon.com (4.1/Proteon-1.5) id AA17292; Fri, 22 Jul 94 12:28:31 EDT Received: by rockford.proteon.com (4.1/SMI-4.1) id AA05761; Fri, 22 Jul 94 12:28:30 EDT Date: Fri, 22 Jul 94 12:28:30 EDT From: avri@proteon.com (Avri Doria) Message-Id: <9407221628.AA05761@rockford.proteon.com> To: ericf@atc.boeing.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407221543.AA00512@atc.boeing.com> (message from Eric Fleischman on Fri, 22 Jul 94 08:43:23 -0700) Subject: Re: The current xxx bit consensus Reply-To: avri@proteon.com i love to see people arguing over having reached rough consensus. it truly helps me understand the meaning of the term. how many different consensi can you have and have rough consensus. or does rough consensus mean the bigger consensus wins. then we can have a contest to see who has the bigger consensus. - is it possible, that there is no consensus as of yet? just asking, don't know the answer myself. avri From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 03:08:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01533; Sat, 23 Jul 1994 03:08:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA22282; Sat, 23 Jul 1994 03:08:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA22257; Sat, 23 Jul 1994 02:58:03 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29298; Sat, 23 Jul 1994 01:55:13 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 23 Jul 94 00:45:45 +0859 From: Masataka Ohta Message-Id: <9407221546.AA29552@necom830.cc.titech.ac.jp> Subject: Re: 64-bits To: yakov@watson.ibm.com Date: Sat, 23 Jul 94 0:45:43 JST Cc: kre@munnari.OZ.AU, j.macallister1@physics.oxford.ac.uk, big-internet@munnari.OZ.AU In-Reply-To: <9407221507.27451@munnari.oz.au>; from "yakov@watson.ibm.com" at Jul 22, 94 11:06 am X-Mailer: ELM [version 2.3 PL11] > >The problem with variable addressing (with 2 exceptions I will mention) > >is that its almost useless, it really doesn't gain you what you expect. > > One more exception -- it allows different types of addresses to be > of different length. For example, it allows cluster addresses > to be shorter (e.g. 8 octets) than unicast addresses (e.g. 16 octets). > This way, if you use cluster addresses for source routing, you may > get more efficient encoding (fewer bits). If fixed length 8+8 locator/EID format is used, source route may consists of fixed length 8 byte locator, I think. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 03:09:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01555; Sat, 23 Jul 1994 03:09:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA22297; Sat, 23 Jul 1994 03:09:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA22237; Sat, 23 Jul 1994 02:46:20 +1000 Precedence: list Received: from netcom2.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00804; Sat, 23 Jul 1994 02:46:16 +1000 (from kck@netcom.com) Received: by netcom2.netcom.com (8.6.8.1/SMI-4.1/Netcom) id JAA01673; Fri, 22 Jul 1994 09:46:35 -0700 Date: Fri, 22 Jul 1994 09:46:35 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407221646.JAA01673@netcom2.netcom.com> To: big-internet@munnari.OZ.AU, j.macallister1@physics.oxford.ac.uk Subject: Re: 64-bits >>It is way too easy to ride out IPv4 with hidden networks and end up with >>a real mess in 5 years. > >ALE predict IPv4 is good til 2005. 32to64bit migration would allow >exponential growth with CIDR aggregation for a futher 32 years > >are you telling me you think IPng will be around in 2037 and not >require another radical overhaul before then for other reasons? > >lets look back 43 years ago, to 1953. what kind of networking did >people do then? This is an excellent point. Instead of looking back to 1953 I would like to predict that new types of MAC networks will make it harder and harder to continue with tradional type IP. At a minimum these networks will be called large clouds. We are starting to see these types of networks come into play and the algorithms to route IP in these networks is anything but optimal. As more and more of these networks get deployed who knows what other real limitations of IP are going to be found. Whats the next generation network after the large cloud type going to be? And how off in the future are they? 10 years? 15 at the most? Bottom line is I think you have given a good argument for keeping the addresses small (64 bits) so as not to pay the penalty per packet today, but wait 20 years or so before the penalty is needed, since it will be needed for other reasons (not just the address size). >jon --rich From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 03:10:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01577; Sat, 23 Jul 1994 03:10:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA22325; Sat, 23 Jul 1994 03:10:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA22254; Sat, 23 Jul 1994 02:57:23 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27594; Sat, 23 Jul 1994 01:08:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09193; Fri, 22 Jul 94 11:08:52 -0400 Date: Fri, 22 Jul 94 11:08:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407221508.AA09193@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: 64-bits Cc: jnc@ginger.lcs.mit.edu From: Robert Elz The problem with variable addressing (with 2 exceptions I will mention) is that its almost useless ... First the exceptions. One is if you're Noel. If you're Noel you're asking for a different thing to almost everyone else, it just happens that both include the "variable" word. I know what you're getting at, but it turns out that's not accurate. I'd be in favor of variable length addresses even if they really were addresses (i.e. the fields the routers looked at to forward every packet, or selectors). Here's why. The chief use of addresses is to the routing, to get the data where you want it to go. There's no use at all forwarding packets fast if they don't wind up where you want them. When I think about what the routing wants to see in an address, for various reasons I won't rehash here, I think it wants to see a variable length address. Not everybody agrees with this, and I'm not going to try and convince them here, but for the rest of this note, let's assume it's true, and follow the reasoning from there. As far as I'm concerned, that's life, and we have to deal with it, not stick our heads in the sand and hope this unpleasant fact goes away. Now it turns out that for a number of happily interlocking reasons (such as thinking about how to produce a routing architecture with certain characteristics, along with a nice mesh with other things that want to put state in routers), the best way I can see to do that is with flows. However, if flows didn't exist, I'd just sit down and figure out some other way to deal with these things, not wail that they had a characteristic I didn't like. Reality is what it is, and you just have to deal with it. (E.g. Entropy isn't going to go away because you don't like it.) For instance, I would probably arrange things so that there was additional information stored in the packets, which made processing the variable length address as fast as possible. I'd also optimize the syntax of the VLA for processing speed, not space efficiency. You can think of any number of ways to do this, once you've accepted that you have to. Anyway, just for accuracy's sake, that's what I think. if you're designing the addressing structure along with the packet format, the packets may just as well be designed for the particular fixed size that the addressing is assuming and be done with it. Tilt. We aren't designing the addressing structure, and I don't think there is any way to, up front like this. That is, to make use of meaningful variable length addresses we're going to have to have host level software changes anyway This makes no sense at all to me. You just write the code to deal with opaque variable length byte sgrings, and it works. Now if you are Noel, you understand all of this, and have a plan for how to actually make all of this work Please, I wish people wouldn't personalize all this. I have some ideas, they may be right, they may be wrong, but I wish people would think about the ideas, not who has them. There are plenty of people in the IETF who are smarter than me, the main advantage I have here is that I started thinking about large-scale routing in about 1978. With that kind of lead, even someone as slow as me can figure a lot out! So, please let's take me out of it, OK? The ideas are right or wrong in and of themselves. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 04:06:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03426; Sat, 23 Jul 1994 04:06:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA22403; Sat, 23 Jul 1994 04:06:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22384; Sat, 23 Jul 1994 03:56:09 +1000 Precedence: list Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02247; Sat, 23 Jul 1994 03:31:55 +1000 (from perk@watson.ibm.com) Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3277; Fri, 22 Jul 94 13:31:56 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 3493; Fri, 22 Jul 1994 13:31:56 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 22 Jul 94 13:31:55 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA37790; Fri, 22 Jul 1994 13:31:51 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9407221731.AA37790@hawpub1.watson.ibm.com> To: big-internet@munnari.OZ.AU Subject: A question about options Date: Fri, 22 Jul 94 13:31:51 -0500 I made a suggestion earlier that maybe it would be a good idea to relegate the specification of EIDs, and possibly even more address bits, to some new IPng options. I thought this was a great idea. I was also hoping that if it was not such a great idea, someone would tell me about it in a private piece of return mail. Instead, I got utter silence, which on this list is almost beyond belief. So, if anyone remembers my previous note and has an idea why options aren't a good idea for taking care of future needs for EIDs or more address bits, could you let me know? Charlie P. PS. I also thought that future routers could if necessary be built to process options quickly, especially those routers which are being built so far into the future that 8 bits are not enough (let alone 16!). I am under the impression that EIDs are only useful on the final segment, so any intermediate routers could ignore the EID options. From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 04:46:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04915; Sat, 23 Jul 1994 04:46:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA22511; Sat, 23 Jul 1994 04:46:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22506; Sat, 23 Jul 1994 04:46:16 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04908; Sat, 23 Jul 1994 04:46:13 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET id QQwzrm26643; Fri, 22 Jul 1994 14:44:26 -0400 Message-Id: To: Masataka Ohta Cc: mo@uunet.uu.net (Mike O'Dell), big-internet@munnari.OZ.AU Subject: Re: 8+8 again..... In-Reply-To: Your message of "Fri, 22 Jul 1994 22:38:53 +0200." <9407221339.AA29119@necom830.cc.titech.ac.jp> Date: Fri, 22 Jul 1994 14:44:26 -0400 From: "Mike O'Dell" Masataka Ohta asked: Why do you think you can't do Nimrod like routing with fixed length 8 byte locator + fixed length 8 byte EID? >>> To which I reply...... I don't see a problem with it. it just means that having 8-byte routing goobies to tack on the front would be more light-weight than 16-byte routing goobies. -mo From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 04:59:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04160; Sat, 23 Jul 1994 04:26:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA22479; Sat, 23 Jul 1994 04:26:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22450; Sat, 23 Jul 1994 04:13:24 +1000 Precedence: list Received: from localhost by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03668; Sat, 23 Jul 1994 04:13:23 +1000 (from kre@munnari.OZ.AU) Message-Id: <9407221813.3668@munnari.oz.au> To: Big-Internet@munnari.OZ.AU From: Robert Elz Subject: Big-Internet on semi-autopilot for a week (and a few days) Date: Sat, 23 Jul 1994 04:13:21 +1000 Sender: kre@munnari.OZ.AU Big-Internet is now on auto-pilot... I will watch my mailbox as best I can from Toronto, if you need to send administrative messages, send them to Big-Internet-Request@munnari.OZ.AU as usual, it will help a lot if you put "B-I" at the start of the subject line, that way I have a better chance of finding the right things to act upon. I will try to delete people as soon as possible after I see the request, however acknowledgements may not happen until I return to Australia. Additions (for all those people not seeing this message) will probably wait for a week and a bit from now. Apologies for the halt a couple of days ago, our local FDDI ring went into bozo state, and it took close to 24 hours to string together enough pits of fibre that happened to be running between various buildings to make an ethernet link from where we are to where we need to be for outside connectivity... kre From owner-Big-Internet@munnari.OZ.AU Sat Jul 23 09:06:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12942; Sat, 23 Jul 1994 09:06:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA22739; Sat, 23 Jul 1994 09:06:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA22734; Sat, 23 Jul 1994 09:03:52 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12704; Sat, 23 Jul 1994 09:03:42 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-20.dialip.mich.net (pm002-20.dialip.mich.net [35.1.48.101]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA24926 for ; Fri, 22 Jul 1994 19:03:37 -0400 Date: Fri, 22 Jul 94 22:29:54 GMT From: "William Allen Simpson" Message-Id: <2923.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: big (CLNP) addresses unacceptable > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > From: "William Allen Simpson" > > If we had wanted CLNP-sized headers, we would have adopted CLNP when the > IAB put the proposal forward. Instead, we had a coup. > > Pardon me, but this is a gross simplification of what happpened (and I was > in the middle of it, so I recall it all quite well :-(. > It is a simplification, but not overly so. > The upset was not so much over any particular technical detail of CLNP, as > over i) the perception that the IAB was trying to cram something down the > IETF's throat, and ii) over the notion of using an already standardized and > implemented (i.e. hard to modify) protocol, done by another standards body > whose working style was not meldable with the IETF, i.e. a loss of control > by the IETF. There was also a certain amount of anti-OSI bias, a hangover > from the bad old days (may they never come again) when *some* OSI proponents > tried to kill off TCP/IP. Finally, there was some unhappiness with the > technical details of CLNP, but I wouldn't draw any broad conclusions about > that from pure opposition to CLNP. > I respectfully disagree. - If the technical details had been acceptable, we wouldn't have had a coup. There had been previous problems where IAB fiat had not conformed to technical details, and this was the straw that broke the camel's back. - If the technical details had been acceptable, we wouldn't have really cared much about change control. Do we care about change control for Ethernet? FDDI? No, we just use them, they work, or we document workarounds. - If the technical details had been acceptable, anti-OSI bias would have caused a minor amount of grumbling. After all, Dave Piscatello was an author of CLNP, and he is now "one of us", right? I conclude that it was the technical details that were the problem. We really do care about such things more than process, change control, or OSI bias. Amazing. I agree that the fix was to change the process to prevent IAB from ever again "trying to cram something down our throats". But that was because they had gotten out of touch with the technical details, and more involved in "outreach" and "internationalism". > I will thank you to refrain from rewriting history in your zeal to make > your case. > Rather, as any historian will try to do, putting history in perspective. Think of what would have happened if the IAB had decreed that all IETF breaks would include Belgian chocolates. Would we have had a coup? Would we care that they weren't made from Wisconsin milk? Now think of what would have happened if the IAB had decreed that all IETF breaks would have mineral water and no coffee. Yes, those pesky technical details matter. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sun Jul 24 05:27:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20440; Sun, 24 Jul 1994 05:27:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA23828; Sun, 24 Jul 1994 05:26:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA23823; Sun, 24 Jul 1994 05:25:28 +1000 Precedence: list Received: from ub4b.eunet.be by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20319; Sun, 24 Jul 1994 05:25:24 +1000 (from old@sunbim.be) Received: from sunbim.sunbim.be by ub4b.eunet.be (5.65c/ub4b_05) id AA03566; Sat, 23 Jul 1994 21:26:45 +0200 Received: from amadeus.sunbim.be by sunbim.sunbim.be (4.1/SMI-4.1) id AA06900; Sat, 23 Jul 94 21:20:55 +0200 Received: from bizet.sunbim.be by amadeus.sunbim.be (4.1/SMI-4.1) id AA05322; Sat, 23 Jul 94 21:25:44 +0200 Date: Sat, 23 Jul 94 21:25:44 +0200 From: old@sunbim.be (Olivier Dubois) Message-Id: <9407231925.AA05322@amadeus.sunbim.be> To: Big-Internet@munnari.OZ.AU Subject: variable length and address masks Hello all, concerning the lengthy discussion on fixed vs variable length addresses, I would like to make one point. Fixed length addresses assiciated with an address mask are in fact one forgetted instance of variable length addresses. In this case, the full length address is always used, propagated in routing table along the meaningfull length. This mean that in fact, two times the worst case address length is distirbuted (once for the address and once for the address mask). I know that I use some short cuts in stating this but once confronted to whats the moost attracting feature of expected IPng addressing scheme: address prefix aggregation, the OSI scheme of prefix propagation such as in IDRP is very ttracting. In this view and address is not always synonimous with an end point but can also represent a subnet hierarchy. Therefore the praralle variable size addresses/ address mask is relevant. just to add some salt to the discussion. Oliver Dubois. From owner-Big-Internet@munnari.OZ.AU Sun Jul 24 06:27:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22570; Sun, 24 Jul 1994 06:27:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA23895; Sun, 24 Jul 1994 06:26:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA23879; Sun, 24 Jul 1994 06:11:42 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21997; Sun, 24 Jul 1994 06:11:35 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA29145; Sat, 23 Jul 94 15:11:27 CDT Date: Sat, 23 Jul 94 15:11:27 CDT Message-Id: <9407232011.AA29145@achilles.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: Where and When is the EID needed? Cc: RACarlson@anl.gov From: "Richard Carlson" Forgive me for entering this thread at this late date. I have been on travel and I'm just now trying to recover (before heading for Torono tomorrow). >dcrocker@mordor.stanford.edu (Dave Crocker) writes: >Again, the primary problem with the conclusion you keep reaching is not >that it is wrong to want the final functionality you cite, but it does not >seem to be necessary to achieve it by burdening every packet and by >creating yet-another administrative effort to assign a new and extra >string. As I see things, the value of EID is that a form of data abstraction will be built into networking. The database people have found this concept to be extremely beneficial. Why do networking people think the opposite? I, for one, am having a major problem seeing how any IPng protocol will be deployed. The dual stack approach of backword compatibility completely baffles me. As I see it, you tell people we are running out of IPv4 addresses so they need a new IPng. Then you turn around and assign an IPv4 address to the node so it can communicate with all those old IPv4 nodes. If you need to assign an IPv4 address, why bother with the IPng one? Yes I know the goal is to delete the IPv4 address, and existing nodes already have them, BUT how do new nodes communicate with old nodes if you don't assign IPv4 address to the new nodes. How does this fix the address exhaustion problem? This is where I see EID's making a difference. If the TCP stopped using the IP address as the global identifier, but used an EID instead, then we would have the level of data abstraction we need to allow multiple IP layers. The burden on each packet is more than offset by the benefits of data abstraction. So I am strongly against simply replacing IPv4 addresses with IPng addresses and continuing on as before. We now have the opportunity to fix TCP/IP so it will handle future growth. IMHO just making the IP address longer means that we are squandering this opportunity. Rich Carlson From owner-Big-Internet@munnari.OZ.AU Sun Jul 24 07:46:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24739; Sun, 24 Jul 1994 07:46:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA23998; Sun, 24 Jul 1994 07:46:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA23982; Sun, 24 Jul 1994 07:30:08 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24429; Sun, 24 Jul 1994 07:30:03 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA04524; Sat, 23 Jul 1994 14:29:53 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 23 Jul 1994 14:29:57 -0700 To: "Richard Carlson" From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Where and When is the EID needed? Cc: big-internet@munnari.OZ.AU, RACarlson@anl.gov Rich, Unfortunately, you ask reasonable questions. (It would be sooo much easier if you didn't.) My guess is that your questions come from our not having described things well enough to you, so allow me yet-another feeble attempt... At 1:11 PM 7/23/94, Richard Carlson wrote: >As I see things, the value of EID is that a form of data abstraction will >be built into networking. The database people have found this concept to >be extremely beneficial. Why do networking people think the opposite? Simply stated: HUH? We like abstractions, too. We also like performance. While one needs to be very careful not to make the wrong optimizations, one also needs to be careful to make the important ones. For example, if you've been tracking this thread, a number of us seem to be gravitating towards use of the domain name (plus some other strings, like protocol and port) to forumlate an EID, by using EXISTING strings, rather than new ones. The critical requirement for such a beast is that it not go in every packet. Clearly, the DNS string is much too long for that. So, I'd claim that we are very much interested in an EID abstraction, but also with being careful how it is used. >I, for one, am having a major problem seeing how any IPng protocol will >be deployed. The dual stack approach of backword compatibility completely Transition is the concern that got me involved in starting the IPAE effort, which eventually turned into SIP (and eventually SIPP and eventually...) The current SST proposal is a simplification of IPAE. My assessment of the sequence is that IPAE invented a massive set of tools and the public simply couldn't see how to use all of it -- and was quite certain that not all nodes needed to implement all features -- so that SST specifies a more restricted and more "core" set of functionality. >baffles me. As I see it, you tell people we are running out of IPv4 >addresses so they need a new IPng. Then you turn around and assign an >IPv4 address to the node so it can communicate with all those old IPv4 Assingment of new IPv4 addresses is intended only to happen as long as they are available. (Now THAT sounds like a dumb statement.) That is, we want to allow as much overlap as we can. But eventually there will be IPng nodes that do NOT have globally unique IPv4 addresses. > BUT how do new nodes communicate with old nodes >if you don't assign IPv4 address to the new nodes. How does this fix the >address exhaustion problem? Eventually, only nodes with IPng addresses will be certain of global routing. At that point, however, it is intended that they will STILL be able to communicate with "local" IPv4 nodes, even though those IPv4 nodes do not have global uniqueness. >This is where I see EID's making a difference. If the TCP stopped using >the IP address as the global identifier, but used an EID instead, then Well, you are postulating a major change to TCP, as well as to IP. We are trying to limit the number of things that have to change all at once. And we are trying to retain as much operating style and code (perhaps) as we can. At the least, EIDs are NOT being considered for use in the core IPv4-to-IPng transition. Most of the claimed requirements pertain to such interesting enhancements as mobility. >we would have the level of data abstraction we need to allow multiple >IP layers. The burden on each packet is more than offset by the benefits >of data abstraction. Ultimately, what I'd like to suggest to you is that you are holding a particular view of the utility of EIDs. For all I know, you might be exactly right. The test of that is the production of a spec. Ideas can be good or bad. Some SOUNDS good or bad but might be quite the opposite of the way they sound. Only by going through all the details of proeducing a spec -- or at least a solid outline of a spec -- can the idea get enough flesh on it to see what species it belongs to. d/ ----- Dave Crocker +1 408 246 8253; fax: +1 408 249 6205 From owner-Big-Internet@munnari.OZ.AU Sun Jul 24 08:07:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23248; Sun, 24 Jul 1994 06:47:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA23927; Sun, 24 Jul 1994 06:46:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA23911; Sun, 24 Jul 1994 06:39:15 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22937; Sun, 24 Jul 1994 06:39:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18696; Sat, 23 Jul 94 16:39:04 -0400 Date: Sat, 23 Jul 94 16:39:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407232039.AA18696@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, old@sunbim.be Subject: Re: variable length and address masks Cc: jnc@ginger.lcs.mit.edu From: old@sunbim.be (Olivier Dubois) Fixed length addresses assiciated with an address mask are in fact one forgetted instance of variable length addresses. ... This mean that in fact, two times the worst case address length is distirbuted (once for the address and once for the address mask). ... In this view and address is not always synonimous with an end point but can also represent a subnet hierarchy. In other words, with the IPv4 style of addressing (i.e. without any internal bits devoted to formatting), the only thing you can name with a single fixed length address is a single entity, and not a topology aggregate? This is true, and interesting, but I'm not sure what the point is. The overhead, in the routing protocols, amounts to having to carry around somewhere between twice and 2N times (where N is the size of the address in the address size quantum) the amount of data you would have to with an address with internal formatting. (It doesn't matter whether the addresses are fixed of variable length, only whether they carry internally enough formatting info to tell you how many bits there are. E.g. EGP carries a class A address in one byte, even though IPv4 has fixed length addresses.) This doesn't seem to me to be like enough overhead, in the grand scheme of things, to really be an issue. What am I missing? Noel From owner-Big-Internet@munnari.OZ.AU Sun Jul 24 09:22:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25747; Sun, 24 Jul 1994 08:27:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA24055; Sun, 24 Jul 1994 08:26:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA24028; Sun, 24 Jul 1994 08:08:30 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23866; Sun, 24 Jul 1994 07:10:16 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA02158; Sat, 23 Jul 94 16:10:12 CDT Date: Sat, 23 Jul 94 16:10:12 CDT Message-Id: <9407232110.AA02158@achilles.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements From: "Richard Carlson" >Jon Crowcroft Writes: >whatever an EID is for, it is something that is implicit in a number >of features of an IPng packet. I disagree with this. The EID is in no way implicit. It is real, facutal you can write it down and forget it .-) Making it implicit is called an IPv4 address. We have found that while it makes for a very efficient protocol suite, it impedes growth. An EID must be explicit. >the 'transport entity' stuff is a red herring - we are not at liberty >in _this_ debate to change the use of TCP ports, and probably can't >sensibly say any more than use TCP port plus low least changing >(i.e. most like EID) bits of the IPng locator for the PCB key/pseudo >checksum. I don't understand this. I don't remember anyone saying that TCP ports should ever be changed. I claim that we should replace the IPv4 address with an EID when calculating the checksum. The EID becomes the globally unique 'thing' that is used instead of globally unique IPv4 addresses. I think that the best place for locating the EID value is in the transport layer. I can see how nodes would communicate with them their. If someone can explain how EID's can live in the internetwork layer, *without being used to perform some routing function* then we have something to discuss. I wouldn't accept IPng addresses that function like bigger IPv4 addresses. >sipp with 8+8 represented the height of compromise...which is as good >as we can hope for... I don't see what the SIPP address structure has to do with EID's? The whole point of EID's is that they are assigned from a flat space. There is little or no hierarchical information in them. How SIPP breakes up it's address space is an entirely separate issue. Rich Carlson From owner-Big-Internet@munnari.OZ.AU Sun Jul 24 12:17:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29503; Sun, 24 Jul 1994 10:27:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24173; Sun, 24 Jul 1994 10:26:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24157; Sun, 24 Jul 1994 10:15:32 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28971; Sun, 24 Jul 1994 10:15:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19117; Sat, 23 Jul 94 20:15:20 -0400 Date: Sat, 23 Jul 94 20:15:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407240015.AA19117@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: Where and When is the EID needed? Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) a number of us seem to be gravitating towards use of the domain name ... to forumlate an EID ^^^ An EID is a fixed length binary identifier. (No matter how many times this is repeated, you don't seem to ingest it. Please take the time this time.) If you're using DNS names to indentify endpoints, then I'd suggest "endpoint name" is the correct term. > If the TCP stopped using the IP address as the global identifier, but > used an EID instead Well, you are postulating a major change to TCP, as well as to IP. We are trying to limit the number of things that have to change all at once. And we are trying to retain as much operating style and code (perhaps) as we can. At the least, EIDs are NOT being considered for use in the core IPv4-to-IPng transition. In other words, it's not going to happen. You know as well as I do that when TCP is converted to run over IPng, nobody is going to change it to use the DNS name in the pesudo-header, instead of the SIPP address. If it isn't done to begin with, it's not going to get added later. For all I know, you might be exactly right. The test of that is the production of a spec. Ideas can be good or bad. Some SOUNDS good or bad but might be quite the opposite of the way they sound. Only by going through all the details of proeducing a spec -- or at least a solid outline of a spec -- can the idea get enough flesh on it to see what species it belongs to. Tell me, Dave, what about the PIP specs (which included what was exactly an EID, as far as I could see) doesn't count? I've pointed these specifications out to you several times before, but that doesn't seem to have stopped you making the same demonstrably incorrect point. One wonders exactly why. Noel From owner-Big-Internet@munnari.OZ.AU Sun Jul 24 15:13:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08572; Sun, 24 Jul 1994 15:07:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA24413; Sun, 24 Jul 1994 15:06:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA24408; Sun, 24 Jul 1994 15:03:09 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08446; Sun, 24 Jul 1994 15:03:06 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id WAA05221; Sat, 23 Jul 1994 22:02:47 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 23 Jul 1994 22:02:49 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Where and When is the EID needed? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 5:15 PM 7/23/94, Noel Chiappa wrote: >An EID is a fixed length binary identifier. (No matter how many times this is >repeated, you don't seem to ingest it. Please take the time this time.) >If you're using DNS names to indentify endpoints, then I'd suggest "endpoint >name" is the correct term. Noel, it's always interesting to find out that something which has been the subject of fuzzy discussion for two years is now firm and fixed. While it well might have been that way all along for you, you are entirely missing my own point by your choosing to focus on the particular level of detail that distinguishes fixed-length-binary from variable-length-text. This is, of course, an extremely important distinction in some contexts. Too bad you choose to exercise the distinction in the wrong context. Once again, Noel: There is a function to be performed, pertaining to the identification of an end-point entity. In order to determine the low-level details of it we need to understand how it will be used. Choosing to employ something long and gross like a text string is an artifact of asserting that the thing is exchanged only occasionally and that we can get away with re-using an existing string. >You know as well as I do that when TCP is converted to run over IPng, nobody >is going to change it to use the DNS name in the pesudo-header, instead of the You might be right. Dunno. I DO know that part of my reason for being interested in the DNS-based "out of band" scheme for multiplexing one TCP stream over multiple IP-host-address pairs is because it can be done on a pairwise basis, without awaiting effort by the infrastructure. Hence, it can be incrementally adopted. d/ ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA) From owner-Big-Internet@munnari.OZ.AU Mon Jul 25 12:47:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19855; Mon, 25 Jul 1994 12:47:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA25664; Mon, 25 Jul 1994 12:47:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA25659; Mon, 25 Jul 1994 12:46:36 +1000 Precedence: list Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19817; Mon, 25 Jul 1994 12:46:31 +1000 (from vaf@Valinor.Stanford.EDU) Received: (from vaf@localhost) by Valinor.Stanford.EDU (8.6.8/8.6.6) id TAA16478; Sun, 24 Jul 1994 19:47:35 -0700 Date: Sun, 24 Jul 94 19:47:34 PDT From: Vince Fuller To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: "Richard Carlson" , big-internet@munnari.OZ.AU, RACarlson@anl.gov Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: Where and When is the EID needed? In-Reply-To: Your message of Sat, 23 Jul 1994 14:29:57 -0700 Message-Id: >This is where I see EID's making a difference. If the TCP stopped using >the IP address as the global identifier, but used an EID instead, then Well, you are postulating a major change to TCP, as well as to IP. We are trying to limit the number of things that have to change all at once. And we are trying to retain as much operating style and code (perhaps) as we can. At the least, EIDs are NOT being considered for use in the core IPv4-to-IPng transition. Most of the claimed requirements pertain to such interesting enhancements as mobility. >we would have the level of data abstraction we need to allow multiple >IP layers. The burden on each packet is more than offset by the benefits >of data abstraction. Ultimately, what I'd like to suggest to you is that you are holding a particular view of the utility of EIDs. For all I know, you might be exactly right. The test of that is the production of a spec. Ideas can be good or bad. Some SOUNDS good or bad but might be quite the opposite of the way they sound. Only by going through all the details of proeducing a spec -- or at least a solid outline of a spec -- can the idea get enough flesh on it to see what species it belongs to. If Rich's view of the utility of EIDs is "particular", then I would have to say that a number of other share that "particular" view - the de-overloading of transport endpoint identification from addressing is *explicitly* one of the purposes of EIDs, though it is certainly not the only benefit that is obtained by using EIDs. And if, perchance those who make the IPng decision turn out to not be omniscient, then this decoupling inside of TCP will make it infinitely easier to do another transition in the future. --Vince From owner-Big-Internet@munnari.OZ.AU Mon Jul 25 13:07:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20401; Mon, 25 Jul 1994 13:07:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA25698; Mon, 25 Jul 1994 13:07:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA25691; Mon, 25 Jul 1994 13:01:01 +1000 Precedence: list Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19393; Mon, 25 Jul 1994 12:35:00 +1000 (from vaf@Valinor.Stanford.EDU) Received: (from vaf@localhost) by Valinor.Stanford.EDU (8.6.8/8.6.6) id TAA16423; Sun, 24 Jul 1994 19:36:20 -0700 Date: Sun, 24 Jul 94 19:36:19 PDT From: Vince Fuller To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, mo@uunet.uu.net, jnc@ginger.lcs.mit.edu Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: what breaks when and what it means In-Reply-To: Your message of Fri, 22 Jul 94 11:38:51 -0400 Message-Id: If your previous point was correct, and 8 bytes is large enough to *number* all the hosts for quite some time (not *address*, which is a different set of rules altgether on usage), then 16-bytes is unfortunate, since it does mean a lot more header overhead. This is an interesting point and one with which I agree. And in case I was incorrectly counted in Bill's analysis as being in the "128-bits is enough" camp, I would say that I tend to agree with Yakov and Noel in that 8-bytes is plenty for EID's but that some sort of variable-length "thing", which will probably look sort of like a source route in a future, policy-full world, will be needed for addressing (locator). In a previous message, I suggested that 8-bytes is adequate to describe network topology *if* that topology is allowed to be highly variable and renumbering happens transparently, but that doesn't consider the policies which may be imposed on the flows across that topology. --Vince From owner-Big-Internet@munnari.OZ.AU Tue Jul 26 13:39:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01812; Tue, 26 Jul 1994 08:48:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA26788; Tue, 26 Jul 1994 08:47:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA26772; Tue, 26 Jul 1994 08:36:57 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01322; Tue, 26 Jul 1994 08:36:54 +1000 (from dcrocker@mordor.stanford.edu) Received: from [142.1.1.204] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA13001; Mon, 25 Jul 1994 15:36:45 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Jul 1994 15:36:47 -0700 To: Vince Fuller From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Where and When is the EID needed? Cc: big-internet@munnari.OZ.AU Vince, First, it's quite clear that Rich is not alone in his view that EIDs need to be in the IP-level header. My point was merely that that requirement comes from a belief that it needs to be used a certain way. I was, in fact, trying to assert that the stated functions for such an EID can be satisfied in ways that do NOT need it to be carried in every packet. d/ At 7:47 PM 7/24/94, Vince Fuller wrote: >If Rich's view of the utility of EIDs is "particular", then I would have to >say that a number of other share that "particular" view - the de-overloading >of transport endpoint identification from addressing is *explicitly* one of >the purposes of EIDs, though it is certainly not the only benefit that is >obtained by using EIDs. And if, perchance those who make the IPng decision >turn out to not be omniscient, then this decoupling inside of TCP will make it >infinitely easier to do another transition in the future. ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA) From owner-Big-Internet@munnari.OZ.AU Wed Jul 27 00:12:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29767; Tue, 26 Jul 1994 23:08:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA27584; Tue, 26 Jul 1994 23:07:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA27568; Tue, 26 Jul 1994 22:51:31 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29351; Tue, 26 Jul 1994 22:51:26 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA09763; Tue, 26 Jul 94 07:51:22 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:big-internet@munnari.oz.au id AA00864; Tue, 26 Jul 94 07:51:21 -0500 Date: Tue, 26 Jul 94 07:51:21 -0500 Message-Id: <9407261251.AA00864@benedick.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: Where and When is the EID needed? From: "Richard Carlson" > dcrocker@mordor.stanford.edu (Dave Crocker) Writes: >First, it's quite clear that Rich is not alone in his view that EIDs need >to be in the IP-level header. Just to be clear about this. I think the EID needs to be in the Transport level (TCP/UDP) layer. It goes in every packet because that's how I can see how it works. If there is some method that will allow the communicating nodes to know each others EID's without sending them every time, I would be willing to discuss the issue. Rich Carlson Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Wed Jul 27 00:28:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02656; Wed, 27 Jul 1994 00:28:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA27714; Wed, 27 Jul 1994 00:27:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA27672; Wed, 27 Jul 1994 00:11:13 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29600; Tue, 26 Jul 1994 23:00:45 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 26 Jul 1994 06:00:39 -0700 Date: Tue, 26 Jul 1994 06:00:39 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199407261300.AA13811@zephyr.isi.edu> To: RACarlson@anl.gov, big-internet@munnari.OZ.AU Subject: Re: Where and When is the EID needed? From owner-Big-Internet@munnari.OZ.AU Wed Jul 27 11:08:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21951; Wed, 27 Jul 1994 11:08:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA28348; Wed, 27 Jul 1994 11:08:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA28343; Wed, 27 Jul 1994 11:05:24 +1000 Precedence: list Received: from usage.csd.unsw.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20909; Wed, 27 Jul 1994 10:34:33 +1000 (from paul@atlas.dev.abccomp.oz.au) Received: by usage.csd.unsw.OZ.AU id AA07062 (5.65c/IDA-1.4.4 for big-internet%munnari.oz.au); Wed, 27 Jul 1994 10:34:39 +1000 Received: by atlas (4.1/1.35) id AA08374; Wed, 27 Jul 94 10:00:21 EST Message-Id: <9407270000.AA08374@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 27 Jul 1994 10:00:20 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: big-internet@munnari.OZ.AU Subject: Re: Where and When is the EID needed? Thus expounded "Richard Carlson" on Jul 26, 7:51am: /-------------------- |> dcrocker@mordor.stanford.edu (Dave Crocker) Writes: | |>First, it's quite clear that Rich is not alone in his view that EIDs need |>to be in the IP-level header. | |Just to be clear about this. I think the EID needs to be in the Transport |level (TCP/UDP) layer. It goes in every packet because that's how I can |see how it works. If there is some method that will allow the communicating |nodes to know each others EID's without sending them every time, I would |be willing to discuss the issue. Thinking about it, something just crystallised for me. I see EIDs allowing the same function at the TCP|UDP <-> IP layer boundary that ARP performs at the IP <-> link-level boundary. Basically, they allow everything at the transport layer and above to refer to a destination by a label, which never changes (at least, until the destination entity stops existing). They are the things which should be embedded in the FTP PORT command, etc. The network (IP) layer resolves them into location-dependent addresses - oops, locators, and these location-dependent bits are never seen in the transport layers or above. The locators can change, but everything in TCP,UDP and above is insulated from those changes. The entire addressing and routing fabric can then be changed, and only the IP-equivalent layer needs to be updated, as the location/ addressing info in invisible to anything above it. TCP and UDP pass EIDs to IP, and are passed EIDs from IP for incoming datagrams. They need not actually be transmitted over the link in every packet if each host keeps a cache of current EID<->locator mappings in the same way they currently keep an IP<->link-layer cache. The IPng packets themselves may well not all have the EIDs in them - EIDs then are used basically as 'handles' passed across the transport<->IP boundary. This doesn't seem to be a complicated concept, nor does it appear to be much different from other 'visions' put forward here. Anyone care to tell me whether I've got something fundamentally wrong ? -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From owner-Big-Internet@munnari.OZ.AU Wed Jul 27 14:14:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25461; Wed, 27 Jul 1994 12:48:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA28455; Wed, 27 Jul 1994 12:48:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA28439; Wed, 27 Jul 1994 12:37:01 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25108; Wed, 27 Jul 1994 12:36:50 +1000 (from dcrocker@mordor.stanford.edu) Received: from [142.1.1.176] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id TAA18391; Tue, 26 Jul 1994 19:36:02 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Jul 1994 19:36:04 -0700 To: paul@atlas.abccomp.oz.au From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Where and When is the EID needed? Cc: big-internet@munnari.OZ.AU At 8:00 AM 7/27/94, paul@atlas.abccomp.oz.au wrote: > >TCP and UDP pass EIDs to IP, and are passed EIDs from IP for incoming >datagrams. They need not actually be transmitted over the link in every packet >if each host keeps a cache of current EID<->locator mappings in the same way >they currently keep an IP<->link-layer cache. The IPng packets themselves >may well not all have the EIDs in them - EIDs then are used basically as >'handles' passed across the transport<->IP boundary. At this stage of discussion, we are discussing basic concepts. I think that your summary is a reasonable and concise summary of what I've been suggesting. In fact, during a conversation this afternoon -- proving once again that useful work CAN get done during IETF week and even during a formal IETF meeting -- I finally gravitated on the view that a transport "association" such as a TCP connection needs a label which is independent of the underlying network information. That is, we need network-independent transport context identification. This, then, can allow cooperating end-points to map their transport context onto various (one or more) specific network channels (paths, ...). d/ ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA) From owner-Big-Internet@munnari.OZ.AU Wed Jul 27 15:55:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01095; Wed, 27 Jul 1994 14:07:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA28530; Wed, 27 Jul 1994 14:06:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA28514; Wed, 27 Jul 1994 13:52:19 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00508; Wed, 27 Jul 1994 13:52:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28280; Tue, 26 Jul 94 23:51:46 -0400 Date: Tue, 26 Jul 94 23:51:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407270351.AA28280@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, paul@atlas.abccomp.oz.au Subject: Re: Where and When is the EID needed? Cc: jnc@ginger.lcs.mit.edu From: paul@atlas.abccomp.oz.au I see EIDs allowing the same function at the TCP|UDP <-> IP layer boundary that ARP performs at the IP <-> link-level boundary. Well, actually, that IPv4 addresses perform at that boundary; i.e. they remain the same even if the MAC adddress changes. Basically, they allow everything at the transport layer and above to refer to a destination by a label, which never changes Yes, exactly. The network (IP) layer resolves them into location-dependent addresses Well, this part I'm not sure about; I'd think you get both from the DNS when you look up the DNS name, actually. these location-dependent bits are never seen in the transport layers or above. Yes, exactly. The locators can change, but everything in TCP,UDP and above is insulated from those changes. The entire addressing and routing fabric can then be changed, and only the IP-equivalent layer needs to be updated, as the location/ addressing info in invisible to anything above it. This is an additional possible benefit, but I'm not sure it would be as much use as it might seem; if that layer changes, every host is going to have to change anyway.... This doesn't seem to be a complicated concept, nor does it appear to be much different from other 'visions' put forward here. Anyone care to tell me whether I've got something fundamentally wrong ? Seems pretty much on to me. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jul 27 16:02:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02073; Wed, 27 Jul 1994 14:26:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA28571; Wed, 27 Jul 1994 14:26:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA28546; Wed, 27 Jul 1994 14:13:38 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01424; Wed, 27 Jul 1994 14:13:29 +1000 (from kck@netcom.com) Received: from [192.100.81.100] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02020 Wed, 27 Jul 1994 14:13:23 +1000 (from kck@netcom.com) Received: by netcom.netcom.com (8.6.8.1/Netcom) id VAA04171; Tue, 26 Jul 1994 21:10:22 -0700 Date: Tue, 26 Jul 1994 21:10:22 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199407270410.VAA04171@netcom.netcom.com> To: RACarlson@anl.gov, big-internet@munnari.OZ.AU Subject: Re: Where and When is the EID needed? >> dcrocker@mordor.stanford.edu (Dave Crocker) Writes: > >>First, it's quite clear that Rich is not alone in his view that EIDs need >>to be in the IP-level header. > >Just to be clear about this. I think the EID needs to be in the Transport >level (TCP/UDP) layer. It goes in every packet because that's how I can >see how it works. If there is some method that will allow the communicating >nodes to know each others EID's without sending them every time, I would >be willing to discuss the issue. One of the reasons I see EIDs being useful is in multi-homing and/or multi-interfaced devices. The fact that a device has more than one interface should provide the network layer more flexibility or ability to deliver packets when an interface/network/link is down. By placing the EID in the transport do we lose this functionality without grossly breaking layering? --rich From owner-Big-Internet@munnari.OZ.AU Wed Jul 27 20:48:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15931; Wed, 27 Jul 1994 20:07:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA28864; Wed, 27 Jul 1994 20:06:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA28859; Wed, 27 Jul 1994 20:03:04 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15692; Wed, 27 Jul 1994 20:02:56 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 27 Jul 94 18:55:04 +0900 From: Masataka Ohta Message-Id: <9407270955.AA13908@necom830.cc.titech.ac.jp> Subject: Re: Where and When is the EID needed? To: paul@atlas.abccomp.oz.au Date: Wed, 27 Jul 94 18:55:03 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9407270000.AA08374@atlas>; from "paul@atlas.abccomp.oz.au" at Jul 27, 94 10:00 am X-Mailer: ELM [version 2.3 PL11] > Thinking about it, something just crystallised for me. I see EIDs allowing > the same function at the TCP|UDP <-> IP layer boundary that ARP performs at > the IP <-> link-level boundary. Basically, they allow everything at the Wrong. EID is for ARP also. > This doesn't seem to be a complicated concept, nor does it appear to be much No, unless you wronglythink the only functionality of the Internetwork layer is routing. As exemplified with ARP, it does host (more precisely, interface) identification. > different from other 'visions' put forward here. Anyone care to tell me > whether I've got something fundamentally wrong ? See a picture on layering I posted about a week ago. MO From owner-Big-Internet@munnari.OZ.AU Thu Jul 28 02:53:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00263; Thu, 28 Jul 1994 02:53:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA29440; Thu, 28 Jul 1994 02:52:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29431; Thu, 28 Jul 1994 02:50:57 +1000 Precedence: list From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29760; Thu, 28 Jul 1994 02:42:44 +1000 (from jcjones@MIT.EDU) Received: from W20-575-16.MIT.EDU by MIT.EDU with SMTP id AA06652; Wed, 27 Jul 94 12:42:39 EDT Received: by w20-575-16.MIT.EDU (5.0/4.7) id AA23212; Wed, 27 Jul 94 12:42:37 EDT Message-Id: <9407271642.AA23212@w20-575-16.MIT.EDU> To: Big-Internet@munnari.OZ.AU Subject: Packet Header Size Date: Wed, 27 Jul 94 12:42:36 EDT Content-Length: 186 I'd like to know what people think about packet header sizes. Is 32 bytes asking too much? Is there anything to gain by limiting the size to 24 bytes? -J.C. Jones- (617) 494-1034 From owner-Big-Internet@munnari.OZ.AU Thu Jul 28 04:48:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04207; Thu, 28 Jul 1994 04:48:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA29619; Thu, 28 Jul 1994 04:46:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA29603; Thu, 28 Jul 1994 04:38:53 +1000 Precedence: list From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00362; Thu, 28 Jul 1994 02:57:02 +1000 (from jcjones@MIT.EDU) Received: from W20-575-16.MIT.EDU by MIT.EDU with SMTP id AA07553; Wed, 27 Jul 94 12:56:49 EDT Received: by w20-575-16.MIT.EDU (5.0/4.7) id AA23233; Wed, 27 Jul 94 12:56:48 EDT Message-Id: <9407271656.AA23233@w20-575-16.MIT.EDU> To: Big-Internet@munnari.OZ.AU Subject: Source Routing Date: Wed, 27 Jul 94 12:56:48 EDT Content-Length: 390 I hate to keep bringing this up, but you guys insisted on having it in IPng... I would like to know if it is necessary to specify source routes on a per-packet basis. Would it not be more efficient to specify the source route at the time when the connection is established? That way, you don't have to bloat every packet header with the path to take. -J.C. Jones- (617) 494-1034 From owner-Big-Internet@munnari.OZ.AU Thu Jul 28 12:41:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20184; Thu, 28 Jul 1994 11:47:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA29984; Thu, 28 Jul 1994 11:47:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA29968; Thu, 28 Jul 1994 11:37:54 +1000 Precedence: list Received: from usage.csd.unsw.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13706; Thu, 28 Jul 1994 09:18:45 +1000 (from paul@atlas.dev.abccomp.oz.au) Received: by usage.csd.unsw.OZ.AU id AA10464 (5.65c/IDA-1.4.4 for big-internet%munnari.oz.au); Thu, 28 Jul 1994 09:17:39 +1000 Received: by atlas (4.1/1.35) id AA12867; Thu, 28 Jul 94 09:33:42 EST Message-Id: <9407272333.AA12867@atlas> From: paul@atlas.abccomp.oz.au Date: Thu, 28 Jul 1994 09:33:42 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Masataka Ohta , paul@atlas.abccomp.oz.au Subject: Re: Where and When is the EID needed? Cc: big-internet@munnari.OZ.AU Thus expounded Masataka Ohta on Jul 27, 6:55pm: /-------------------- |> Thinking about it, something just crystallised for me. I see EIDs allowing |> the same function at the TCP|UDP <-> IP layer boundary that ARP performs at |> the IP <-> link-level boundary. Basically, they allow everything at the | |Wrong. EID is for ARP also. I beg your pardon? Could you expand on this sentence please? I've been lurking on this for a while, and all this time I've been of the impression that the whole reason EIDs were proposed is that in IPv4, the IP address is used at both the transport <-> IP layer interface (and in layers above to identify the host to communicate with) and the IP <-> link layer interface, effectively forcing transports like UDP and TCP to be hamstrung, and only able to send packets to be delivered to a single interface even when multiple interfaces are available. |See a picture on layering I posted about a week ago. I don't recall the picture, but somehow I don't think your concept of 'layering' is common! Using EIDs for ARP is an even worse layering violation than using the same identifier for both upper and lower boundaries of IP, as is done presently. ARP is used on LANs ata purely local interface-specific level, only after a packet has found its way to the correct subnet - it is used to map locators, not EIDs, to MAC addresses. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From owner-Big-Internet@munnari.OZ.AU Thu Jul 28 16:27:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26495; Thu, 28 Jul 1994 14:07:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA00229; Thu, 28 Jul 1994 14:07:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA00224; Thu, 28 Jul 1994 14:06:09 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26315; Thu, 28 Jul 1994 14:05:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00918; Thu, 28 Jul 94 00:05:09 -0400 Date: Thu, 28 Jul 94 00:05:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407280405.AA00918@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, jcjones@mit.edu Subject: Re: Source Routing Cc: jnc@ginger.lcs.mit.edu From: jcjones@mit.edu I would like to know if it is necessary to specify source routes on a per-packet basis. Would it not be more efficient to specify the source route at the time when the connection is established? That way, you don't have to bloat every packet header with the path to take. Gee, that's pretty clever. We never thought of that. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jul 28 17:11:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01006; Thu, 28 Jul 1994 15:47:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA00341; Thu, 28 Jul 1994 15:47:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA00318; Thu, 28 Jul 1994 15:36:49 +1000 Precedence: list Received: from access1.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24216; Thu, 28 Jul 1994 13:19:48 +1000 (from tdarcos@access.digex.net) Received: by access1.digex.net id AA16544 (5.67b8/IDA-1.5 for big-internet@munnari.oz.au); Wed, 27 Jul 1994 23:19:26 -0400 Newsgroups: tdr.paul.private.mail Date: Wed, 27 Jul 1994 23:19:26 -0400 (EDT) From: Paul Robinson Sender: Paul Robinson Reply-To: Paul Robinson Subject: Whither 8 bytes? To: big-internet@munnari.OZ.AU Message-Id: <01.1994Jul27.22h49m40s.PAUL-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- The issues here seem to boil down to those who want variable sized IP addresses, those who want variable but will settle for some larger number, such as 16, and those who want to stop at 8. Has anyone realized how large a number 8 bits is? 2^64. That is a number equal to the square of the current Internet, e.g (2^32)^2. This is *not* double the size of the current Internet, this is equivalent to creating a set of networks of the size of the current Internet, each being the size of the current Internet. It hit me just recently. Common equipment being used for packet routing and such is often nothing more than 80286 PCs with software for that purpose. Perhaps 80386s if they need to use lots of memory for storing routing addresses. An AMD 80386 DX 33 is considered to be old technology in terms of what someone would put on their desk (It's what I have) but the raw processor speed is supposed to be equivalent of an IBM 360/30 mainframe from twenty years ago. Why is there such a belief that doing the equivalent of the current Class addressing system used now - where a network provider is assigned a certain size in bytes for local addresses, so that there could be a certain number of addresses in each group of bytes, e.g. a very small number of huge providers would get 1 byte network and 7 byte local numbers - perhaps Bob Moscowitz' Chrysler and competitors so they can assign a new IP number to each automobile as it is made, then there would be 2-byte network and 6 byte local, all the way down to 7-byte network and 1-byte local, being used for individual houses if needed. A 7-byte network and 1-byte local allows hundreds of billions networks of local addresses. No, correction, more than a trillion networks. Even 4+1 allows 4 billion local networks of 256 local addresses. Even with the current IPv4 we are not running out of addresses; take a look at my RFC1275. We could, if we broke granularity at 4 bits instead of 8, create several million tiny networks. But routing would be a nightmare. I concur with another point made: if you have two sizes, e.g. the current 4 byte address and an expanded fixed-sized address - whether it be 8 or 16 bytes - code can be written to handle both easily. Supporting varying length addresses is going to be a pain. Does anyone expect to see growth that requires that we have 18.4 million billion network addresses exhausted in the lifespan that IPng is likely to see? Even if we have 50% address leakage, that's still the equivalent of two IPng addresses for every man, woman and child on this planet. If you make this too large, it's going to encourage waste and cause a problem in routing as addresses get huge. 8 Bytes is a smaller multiple of the 4 byte size in use now, and is easily manipulated by current code. Moving to 16 bytes means many systems cannot handle this size using common assembly language instructions. IBM Mainframes can't; they can handle any operand up to about 8 bytes in a register, which means fast performance. Moving beyond 8 bytes means manipulation of addresses using temporary storage. Let's put some sense back into the arguments. Using 8 bytes means you can expand the current internet simply by widening the size of the current fields from 4 octets of 256, to 4 octets having some combination of numbers up to, say, 2048. Using 16 bytes is huge. It may be so large as to be excessive. If you think that's not possibly a valid analysis, consider this: would a 32-byte or 64-byte address be excessive? Who could remember it? On the other hand, 16-byte IP addresses would solve one problem: it would make people stop using them in favor of DNS addresses since they would certainly always be larger than the DNS name. --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: Gravity is a myth, the Earth sucks. From owner-Big-Internet@munnari.OZ.AU Fri Jul 29 04:07:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27156; Fri, 29 Jul 1994 04:07:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA01114; Fri, 29 Jul 1994 04:07:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA01109; Fri, 29 Jul 1994 04:06:07 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26953; Fri, 29 Jul 1994 04:05:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02551; Thu, 28 Jul 94 14:05:33 -0400 Date: Thu, 28 Jul 94 14:05:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407281805.AA02551@ginger.lcs.mit.edu> To: PAUL@tdr.com, big-internet@munnari.OZ.AU Subject: Re: Whither 8 bytes? Cc: jnc@ginger.lcs.mit.edu From: Paul Robinson The issues here seem to boil down to those who want variable sized IP addresses ... Supporting varying length addresses is going to be a pain. ... Does anyone expect to see growth that requires that we have 18.4 million billion network addresses exhausted in the lifespan that IPng is likely to see? ... If you make this too large, it's going to encourage waste and cause a problem in routing as addresses get huge. ... Moving to 16 bytes means many systems cannot handle this size using common assmbly language instructions. ... Let's put some sense back into the arguments. ... Using 16 bytes is huge. It may be so large as to be excessive. ... would a 32-byte or 64-byte address be excessive? Who could remember it? Exactly which planet are you on? Do you think there is *anything* at all to be said on this topic which hasn't been said 5 times over already? I suggest we disband this list, since the topic it was set up to handle, the growth of the Internet, has been effectively answered with the choice of SIPP-16 as IPng. Also, you're off base in practically every point you make (e.g. I haven't noticed that the fact that nobody remembers IEEE addresses makes them useless), but there are so many, and it's so pointless, that I won't bother pointing them out. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jul 29 06:26:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28425; Fri, 29 Jul 1994 04:47:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA01177; Fri, 29 Jul 1994 04:47:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA01172; Fri, 29 Jul 1994 04:45:48 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28372; Fri, 29 Jul 1994 04:45:43 +1000 (from valdis@black-ice.cc.vt.edu) Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id OAA11606; Thu, 28 Jul 1994 14:45:34 -0400 Message-Id: <199407281845.OAA11606@black-ice.cc.vt.edu> To: Paul Robinson Cc: big-internet@munnari.OZ.AU Subject: Re: Whither 8 bytes? In-Reply-To: Your message of "Wed, 27 Jul 1994 23:19:26 EDT." <01.1994Jul27.22h49m40s.PAUL-0100000@TDR.COM> From: Valdis.Kletnieks@vt.edu Date: Thu, 28 Jul 1994 14:45:34 +22306356 Sender: valdis@black-ice.cc.vt.edu On Wed, 27 Jul 1994 23:19:26 EDT, you said: > It hit me just recently. Common equipment being used for packet routing > and such is often nothing more than 80286 PCs with software for that > purpose. Perhaps 80386s if they need to use lots of memory for storing > routing addresses. An AMD 80386 DX 33 is considered to be old technology > in terms of what someone would put on their desk (It's what I have) but > the raw processor speed is supposed to be equivalent of an IBM 360/30 > mainframe from twenty years ago. Gaak. I always knew that the x86 were brain dead, but I never suspected they were THIS dumb. A /30 came with your choice of 4K to 64K of memory in increments of 4K, and the CPU was a 8-bit (so handling any 32-bit register meant at least 4 clock cycles), with either a 1200ns or 1500ns clock. I won't even discuss what a /30 did on floating point.. ;) I'm pretty sure a dx33 can add 2 32-bit quantities in under 4800ns. ;) > 8 Bytes is a smaller multiple of the 4 byte size in use now, and is > easily manipulated by current code. Moving to 16 bytes means many > systems cannot handle this size using common assembly language > instructions. IBM Mainframes can't; they can handle any operand up to > about 8 bytes in a register, which means fast performance. Moving beyond > 8 bytes means manipulation of addresses using temporary storage. Umm.. What IBM mainframe is 64-bit? The S/360, S/370, 43xx, 30xx, and S/390 are all essentially 32-bit designs, where only the floating point registers are 64/128 bit - and there are restrictions on what you can do in those registers (for instance, you can't do logical bit operations, which would be kind of handy for masking, etc). Yes, internally the larger machines may have 128 or even 256 bit busses, but this stuff isn't accessible to the average programmer. The RS/6000 is also basically a 32-bit machine for general purpose registers. Many of the same caveats apply here as well... What "IBM Mainframe" were you thinking of? /Valdis (who thinks that this level of technical howler makes the rest of the points suspect...) From owner-Big-Internet@munnari.OZ.AU Fri Jul 29 12:39:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12349; Fri, 29 Jul 1994 11:27:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA01547; Fri, 29 Jul 1994 11:27:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA01528; Fri, 29 Jul 1994 11:14:38 +1000 Precedence: list Received: from access1.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09743; Fri, 29 Jul 1994 10:17:17 +1000 (from tdarcos@access.digex.net) Received: by access1.digex.net id AA28749 (5.67b8/IDA-1.5 for big-internet@munnari.oz.au); Thu, 28 Jul 1994 20:16:46 -0400 Date: Thu, 28 Jul 1994 20:16:46 -0400 (EDT) From: Paul Robinson Subject: Re: Whither 8 bytes? To: Noel Chiappa Cc: PAUL@tdr.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9407281805.AA02551@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 28 Jul 1994, Noel Chiappa wrote: > > Exactly which planet are you on? This one, living in reality. Unlike you. (I can throw insults back just as well.) > Do you think there is *anything* at all to be > said on this topic which hasn't been said 5 times over already? As much as people said the world was flat thousands of times. > I suggest we disband this list, since the topic it was set up to handle, the > growth of the Internet, has been effectively answered with the choice of > SIPP-16 as IPng. Which is going to be a waste and a ridiculous overshoot, an excess of humongous proportions. Since you seem to feel that my opinions are pointless, I will ignore further comments from you. From owner-Big-Internet@munnari.OZ.AU Fri Jul 29 12:39:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12430; Fri, 29 Jul 1994 11:30:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA01565; Fri, 29 Jul 1994 11:29:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA01531; Fri, 29 Jul 1994 11:16:49 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10236; Fri, 29 Jul 1994 10:29:35 +1000 (from barney@databus.databus.com) Date: Thu, 28 Jul 94 20:27 EDT Message-Id: <9407282027.AA24423@databus.databus.com> From: Barney Wolff To: Valdis.Kletnieks@vt.edu Cc: big-internet@munnari.OZ.AU Subject: Re: Wither 8 bytes :-) Content-Length: 1145 Content-Type: text > From: Valdis.Kletnieks@vt.edu > Date: Thu, 28 Jul 1994 14:45:34 +22306356 > > Umm.. What IBM mainframe is 64-bit? The S/360, S/370, 43xx, 30xx, and > S/390 are all essentially 32-bit designs, where only the floating > point registers are 64/128 bit - and there are restrictions on what > you can do in those registers (for instance, you can't do logical bit > operations, which would be kind of handy for masking, etc). Yes, > internally the larger machines may have 128 or even 256 bit busses, > but this stuff isn't accessible to the average programmer. You've been living the riscy life too long. Remember CLC? (For the rest of you youngsters, that's compare logical characters - variable length, memory to memory.) On the 360/95, for which I was writing kernel code in 1968, this got done 8 bytes at a time because that's what the memory width was. Who needs registers? Yeah, it could only address 16MB, but 5MB filled a room and 1MB of 60ns storage cost IBM 30 million 1967 dollars to produce. If we were still building machines like that, I would have happily acquiesced to variable-length. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Sat Jul 30 03:27:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15721; Sat, 30 Jul 1994 03:27:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02609; Sat, 30 Jul 1994 03:27:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02593; Sat, 30 Jul 1994 03:12:55 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15234; Sat, 30 Jul 1994 03:12:51 +1000 (from valdis@black-ice.cc.vt.edu) Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id NAA13216; Fri, 29 Jul 1994 13:12:41 -0400 Message-Id: <199407291712.NAA13216@black-ice.cc.vt.edu> To: Barney Wolff Cc: big-internet@munnari.OZ.AU Subject: Re: Wither 8 bytes :-) In-Reply-To: Your message of "Thu, 28 Jul 1994 20:27:00 EDT." <9407282027.AA24423@databus.databus.com> From: Valdis.Kletnieks@vt.edu Date: Fri, 29 Jul 1994 13:12:41 +22306356 Sender: valdis@black-ice.cc.vt.edu On Thu, 28 Jul 1994 20:27:00 EDT, Barney Wolff said: > length, memory to memory.) On the 360/95, for which I was writing > kernel code in 1968, this got done 8 bytes at a time because that's > what the memory width was. Who needs registers? Barney: Yeah, but my point was that the /65 and up did it 8 bytes at a time, some of the newer machines do it 16 bytes at a time, the smaller 360's did it 1, 2, or 4 bytes at a time - all off the same opcode CLC, not under programmer control. And let's face it, even *with* all the nice Storage-Storage instructions, and even all the odd stuff like MVN and MVZ, most stuff worked with RX and RR instructions, which *were* 32 bits (unless you did COBOL packed decimal, but at that point, you're beyond hope ;) Let's face it - the 360 and followons are a 32-bit design. You want a *real* variable-length machine, go back and look at some of IBM's pre-360 boxen like the 1401 ;) /Valdis (who admits not knowing if a /95's CPU did a pipeline stall on a SS instruction....)