From owner-Big-Internet@munnari.oz.au Wed Mar 3 22:56:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26082; Wed, 3 Mar 1993 22:56:25 +1100 (from owner-Big-Internet) Return-Path: Received: from relay.surfnet.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26077; Wed, 3 Mar 1993 22:56:05 +1100 (from dixon@rare.nl) Received: from erasmus.rare.nl by relay.surfnet.nl with SMTP (PP) id <01940-0@relay.surfnet.nl>; Wed, 3 Mar 1993 12:35:23 +0100 Received: from DialupEudora (eata.ncl.ac.uk) by erasmus.rare.nl (5.65c/4.31) with SMTP id AA00199; Wed, 3 Mar 1993 12:35:01 +0100 Message-Id: <199303031135.AA00199@erasmus.rare.nl> Date: Wed, 3 Mar 1993 11:31:44 +0000 To: tuba@lanl.gov, sip@caldera.usc.edu, pip@thumper.bellcore.com, big-internet@munnari.oz.au From: dixon@rare.nl (Tim Dixon) X-Sender: dixon@erasmus.rare.nl Subject: FYI - IPv7 Pilots: European Activities To assist in the establishment of piloting activities for the proposed IP version 7 protocols and in the dissemination of the resulting experience, a number of activities have been established in Europe: SIP: RIPE will provide a discussion forum for SIP pilot activities. Further information from Christian Huitema. (Christian.Huitema@sophia.inria.fr) TUBA: The RARE CLNS pilot project will also encompass TUBA pilots. Contact Victor Reijs (Victor.Reijs@SURFnet.nl) for more information. PIP: Zheng Wang will co-ordinate PIP pilots within Europe. He can be contacted at Z.Wang@cs.ucl.ac.uk. All of these activities aim to provide a regional discussion of the issues involved whilst forming part of a global piloting activity. Also, by providing local focal points for discussion, it is hoped that co-ordination of activities can be improved. Anyone planning to participate in IPv7 pilots in Europe is encouraged to register their intentions with one of the above. Tim Dixon, Project Development Officer RARE, Amsterdam From owner-Big-Internet@munnari.oz.au Thu Mar 4 02:11:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02423; Thu, 4 Mar 1993 02:12:13 +1100 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02411; Thu, 4 Mar 1993 02:11:59 +1100 (from kasten@ftp.com) Received: by ftp.com id AA10829; Wed, 3 Mar 93 10:11:42 -0500 Date: Wed, 3 Mar 93 10:11:42 -0500 Message-Id: <9303031511.AA10829@ftp.com> To: big-internet@munnari.oz.au Subject: [Forwarded: Assigned Network Numbers on Internet] From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com To: ietf@CNRI.Reston.VA.US Cc: iab@isi.edu, iesg@CNRI.Reston.VA.US, isocmembers:;@ietf.nri.reston.va.us, isoc-interest@relay.sgi.com, fnc@fnc.gov Subject: Assigned Network Numbers on Internet Date: Wed, 03 Mar 93 09:22:29 -0500 From: "Vinton G. Cerf" Forgive the duplicates, please! According to the DDN NIC as of this morning: Class A - 115 reserved or assigned Class B - 8361 assigned Class C - 128,709 assigned If this doesn't motivate us to find the solution to scaling the routing and address space, nothing will! Vint From owner-Big-Internet@munnari.oz.au Thu Mar 4 03:53:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05592; Thu, 4 Mar 1993 03:54:11 +1100 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05570; Thu, 4 Mar 1993 03:53:57 +1100 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA03187; Wed, 3 Mar 93 08:53:50 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA20082; Wed, 3 Mar 93 11:53:48 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA00230; Wed, 3 Mar 93 11:52:48 EST Date: Wed, 3 Mar 93 11:52:48 EST From: Frank T Solensky Message-Id: <9303031652.AA00230@fenway.andr.UB.com> To: big-internet@munnari.oz.au, kasten@ftp.com Subject: Re: [Forwarded: Assigned Network Numbers on Internet] >According to the DDN NIC as of this morning: > >Class A - 115 reserved or assigned >Class B - 8361 assigned >Class C - 128,709 assigned > >If this doesn't motivate us to find the solution to scaling the routing >and address space, nothing will! I might add an explanation here for the extended delay in the monthly "growth charts" I've been generating.. Fitting the logistic curve to the data uses an iterative algorithm -- one needs to start off with a good guess at the parameters before one can zero in (so to speak..) on more precise values. It's generally been enough to use the previous month's model as the starting point for fitting the curve, but recently the actual number of networks had exceeded the projected by such a large margin that this approach is no longer working. I hope that I can get a large enough block of time reserved before the IETF, but can't guarentee it right now.. -- Frank From owner-Big-Internet@munnari.oz.au Sat Mar 6 13:20:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24564; Sat, 6 Mar 1993 13:20:41 +1100 (from owner-Big-Internet) Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24561; Sat, 6 Mar 1993 13:20:36 +1100 (from kre@munnari.OZ.AU) Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23326; Sat, 6 Mar 1993 12:24:15 +1100 (from solensky@andr.UB.com) Return-Path: Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA25011; Fri, 5 Mar 93 17:24:07 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA07966; Fri, 5 Mar 93 20:24:06 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA05260; Fri, 5 Mar 93 20:23:01 EST Date: Fri, 5 Mar 93 20:23:01 EST From: Frank T Solensky Message-Id: <9303060123.AA05260@fenway.andr.UB.com> To: kre@munnari.oz.au Subject: New growth charts; Ten Thousand networks Resent-To: Big-Internet@Munnari.OZ.AU Resent-Date: Sat, 06 Mar 1993 13:20:05 +1100 Resent-Message-Id: <22138.731384405@munnari.OZ.AU> Resent-From: Robert Elz New growth charts have just been installed and can be copied via anonFTP from "munnari.oz.au:big-internet/nsf-netnumbers.9303.ps". It includes data up to and including February 23rd -- I'm still trying to get the March 2nd data point to fit without causing the programs to crash. I've plotted the regular graphs using both "N" and "log N" scales for the net counts this time. The reasons will be obvious once you print them out, especially the "max" graph. As always, the graph consists of a least-squared fit of the number of networks announced on the backbone over time. The final data point was 9349 networks, up from 4775 at the end of last February. The announcement this morning, March 5, was a total of 10017 nets. The trend line now levels off at over 1.9 millon networks. -- Frank From owner-big-internet@munnari.oz.au Sat Mar 20 12:11:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25059; Sat, 20 Mar 1993 12:11:13 +1000 (from owner-big-internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19814; Sat, 20 Mar 1993 09:18:43 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA06723; Fri, 19 Mar 93 18:18:31 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9303192318.AA06723@wizard.gsfc.nasa.gov> Subject: Suggestion for New DNS AD Record (for SIP, PIP, TUBA) To: big-internet@munnari.oz.au Date: Fri, 19 Mar 1993 18:18:30 -0500 (EST) X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 729 I would like to suggest a new DNS AD record of the form: name IN AD address_family address For example: name IN AD IP IP-style-address name IN AD SIP SIP-style-address name IN AD PIP PIP-style-address name IN AD CLNP CLNP-style-address Specifically, the form: name IN AD IP address Would be equivalent to the existing: name IN A address The reason I am suggesting this now is I see each IPv7 group defining its own A record extension, and I think it makes much more sense to define a more generic extension that could be used by all. I also think this extension could be useful independent of the IPv7 efforts, for example by certain ISODE applications for mapping names to ISO CLNP addresses. -Bill From owner-Big-Internet@munnari.oz.au Sat Mar 20 14:01:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28214; Sat, 20 Mar 1993 14:01:16 +1000 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28211; Sat, 20 Mar 1993 14:01:02 +1000 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA06257); Fri, 19 Mar 93 22:00:54 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9303200400.AA06257@is.rice.edu> Subject: Re: Suggestion for New DNS AD Record (for SIP, PIP, TUBA) To: bill@wizard.gsfc.nasa.gov (Bill Fink) Date: Fri, 19 Mar 93 22:00:54 CST Cc: big-internet@munnari.oz.au In-Reply-To: <9303192318.AA06723@wizard.gsfc.nasa.gov>; from "Bill Fink" at Mar 19, 93 6:18 pm X-Mailer: ELM [version 2.3 PL11] I think we can get this talked about next week if enough DNS hacks are about in Ohio. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Mon Mar 22 12:56:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12654; Mon, 22 Mar 1993 12:56:18 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12641; Mon, 22 Mar 1993 12:56:10 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 21 Mar 93 21:55:59 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 21 Mar 93 21:55:58 EST Date: Sun, 21 Mar 93 21:55:58 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9303220255.AA03166@chiya.bellcore.com> To: big-internet@munnari.oz.au Subject: provider-rooted addresses..... The promised description of provider-rooted address assignment for the bigAddr bof on Monday night is done. It's available at: thumper.bellcore.com:pub/tsuchiya/providerAddresses.txt I've submitted it as an internet-draft..... PX From owner-Big-Internet@munnari.oz.au Tue Mar 23 00:45:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06547; Tue, 23 Mar 1993 00:45:51 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06535; Tue, 23 Mar 1993 00:45:40 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Mon, 22 Mar 93 09:45:23 EST Received: by chiya.bellcore.com (4.1/4.7) id for bmanning@is.rice.edu; Mon, 22 Mar 93 09:45:22 EST Date: Mon, 22 Mar 93 09:45:22 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9303221445.AA03544@chiya.bellcore.com> To: bill@wizard.gsfc.nasa.gov, bmanning@is.rice.edu Subject: Re: Suggestion for New DNS AD Record (for SIP, PIP, TUBA) Cc: big-internet@munnari.oz.au > > I think we can get this talked about next week if enough DNS hacks > are about in Ohio. > I'm all for discussing issues common to all of the IPv7's in common forums...... Which meeting should this issue get discussed at? Name-droppers? PX From owner-big-internet@munnari.oz.au Fri Mar 26 01:15:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB27296; Fri, 26 Mar 1993 01:15:20 +1000 (from owner-big-internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22375; Thu, 25 Mar 1993 22:19:24 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA07086); Thu, 25 Mar 93 06:18:40 CST Received: by sabine.is.rice.edu (AA06621); Thu, 25 Mar 93 06:18:36 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9303251218.AA06621@sabine.is.rice.edu> Subject: Re: Suggestion for New DNS AD Record (for SIP, PIP, TUBA) To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Date: Thu, 25 Mar 93 6:18:35 CST Cc: bill@wizard.gsfc.nasa.gov, bmanning@is.rice.edu, big-internet@munnari.oz.au In-Reply-To: <9303221445.AA03544@chiya.bellcore.com>; from "Paul Tsuchiya" at Mar 22, 93 9:45 am X-Mailer: ELM [version 2.3 PL11] Yes, I've sent mail to Rob to see if this can get on the agenda. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-big-internet@munnari.oz.au Fri Mar 26 18:10:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28159; Fri, 26 Mar 1993 18:10:15 +1000 (from owner-big-internet) Return-Path: Received: from sunic.sunet.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27059; Fri, 26 Mar 1993 01:08:37 +1000 (from rafal@fuw.edu.pl) Received: from cocos.fuw.edu.pl by sunic.sunet.se (5.65c8-/1.28) id AA03056; Thu, 25 Mar 1993 16:07:18 +0100 Received: from zorro.fuw.edu.pl by cocos.fuw.edu.pl (4.1/SMI-4.1) id AA12175; Thu, 25 Mar 93 16:06:27 +0100 From: rafal@fuw.edu.pl (Rafal Pietrak) Message-Id: <9303251506.AA12175@cocos.fuw.edu.pl> Received: by zorro.fuw.edu.pl (NX5.67c/NX3.0X) id AA03770; Thu, 25 Mar 93 16:06:25 +0100 Date: Thu, 25 Mar 93 16:06:25 +0100 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: big-internet@munnari.oz.au Subject: address vs. EID, revisited... Hi all, I would like to present an 'unorthodox' approach to the address vs. EID dilemma. But first, I must apologize if my proposition is neither that new, nor that interesting. I could see it appearing in various contexts in newIP proposals, but it doesn't seem to be truly recognized. Still, I'm not that much of an expert to judge. The reason I bring this up is that browsing though these proposals I realized, that what routers would like to route is addresses reflecting the network topology (and rather provider, then geography oriented). On the other hand, transport layer likes to have the other party in conversation verified (or verifiable), so it needs EID. Now, by introduction of a layer (and this is the 'unorthodoxy' about this idea) between network and transport layer -- we allow the transport layer to select the destination for packets based on their EIDs, and this is what the transport layer likes most. EID-layer would then resolve such EID into a net address -- preferred by routers -- in a similar meaner as net address is resolved into the physical address between network and link layers, but based on DNS technilogy. One of the advantages is that we allow for EID verification not only based on address<->EID translation, but possibly on other schemes, too. One such scheme is what is proposed for PEM (privacy enhanced mail) --- DES encryption serving secure token passing to/from a hierarchy of authorities. And more; the mobile host problem can be turned into an address resolution problem (as opposed to the address update problem) and this should be simpler to implement. What would be required, is that address resolution yields an address with a wildcard _in_the_middle_ of the address -- a wildcard between local, and global address parts, actually within the provider part. Then such wildcard address would be resolved by a more_or_less_ordinary ARP, and a valid address returned by RARP. When mobile host moves, and changes its address, EID layer could then verify the host at the new address as being the very same host as the one talking from previous address. A protocol for that can be defined. Transport layer never notices the change, while routers can optimize routes because they have new address better reflecting host's new 'attachment point'. So, how about the following layer responsibility: 1) physical 2) link -ARP 3) network -- best effort delivery. -DNS 4) EID -- validation, or not of the destination identity. 5) transport -- validation (TCP), or not (UDP) of datastream (or message) consistency. 6) whatever Of course there are other advantages (in my opinion) of having the new EID layer introduced, but let me save the bandwidth if its feasibility has already been discussed and the idea is discarded. -Rafal From owner-big-internet@munnari.oz.au Sat Mar 27 10:49:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25400; Sat, 27 Mar 1993 10:50:01 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08790; Sat, 27 Mar 1993 00:31:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14799; Fri, 26 Mar 93 09:30:59 -0500 Date: Fri, 26 Mar 93 09:30:59 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9303261430.AA14799@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, rafal@fuw.edu.pl Subject: Re: address vs. EID, revisited... Cc: jnc@ginger.lcs.mit.edu Now, by introduction of a layer (and this is the 'unorthodoxy' about this idea) between network and transport layer This exact model has been discussed previously on this list. I mentioned then that prefer a slightly different model, where the 'network' layer (i.e. the end-end unreliable datagram layer) is composed of two sub-layers, the lower of which uses topological addresses, and the higher uses endpoint ID's. I prefer to do it this way since the functionality (end-end unreliable datagram) which is provided by the two sub-layers is almost the same, and I like a full layer to provide a major increment of function. (Also, it allows us to escape learning a new 8 layer model! :-) Of course there are other advantages (in my opinion) of having the new EID layer introduced Absolutely. In fact, I'm willing to wager that we don't yet know all the advantages, and only over time will it become clear how good an idea this is. let me save the bandwidth if its feasibility has already been discussed and the idea is discarded. Sigh, there seem to be two kinds of people in the world; those who think EID's are absolutely the Right Thing (which should be added without delay), and those who just can't see what use they are. Prolonged argument on this point seems to have reached the point of substantially diminshing returns, so I don't think a long (or any, for that matter :-) debate will be useful! Noel From owner-big-internet@munnari.oz.au Sat Mar 27 11:34:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26467; Sat, 27 Mar 1993 11:34:27 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10685; Sat, 27 Mar 1993 01:37:48 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA05250; Fri, 26 Mar 93 07:37:42 -0800 Message-Id: <9303261537.AA05250@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: Mobile hosts (was: Re: address vs. EID, revisited... ) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 25 Mar 93 16:06:25 +0100. <9303251506.AA12175@cocos.fuw.edu.pl> Date: Fri, 26 Mar 93 07:37:42 -0800 From: Dave Crocker X-Mts: smtp Mobile hosts. Moblile hosts are definitely an important concern. But I have yet to hear an explanation for making the entire Internet community incur the expense of supporting that capability in the network layer (or thereabouts). It seems to me that there are two, very different, kinds of mobility. One is local and the other is distant. Local mobility happens in real time, during data transfers. Distant happens less frequently and does not require real-time maintenance of connections. Cellular telephony has exactly this dual requirement and it solves them in very different ways. My own feeling is that local changes should/must be handled by an appropriate link-level mechanism which hides the mobility from the network layer. The network layer sees a constant address. Distant mobility requires changes to the Domain Name Service, to allow dynamic update to a host's address record. The constant, then, is the domain name for the host. Dave From owner-big-internet@munnari.oz.au Sat Mar 27 15:12:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01796; Sat, 27 Mar 1993 15:12:37 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28213; Sat, 27 Mar 1993 12:59:58 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA11213; Fri, 26 Mar 93 18:59:44 -0800 Message-Id: <9303270259.AA11213@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, rafal@fuw.edu.pl Subject: Re: address vs. EID, revisited... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 26 Mar 93 09:30:59 -0500. <9303261430.AA14799@ginger.lcs.mit.edu> Date: Fri, 26 Mar 93 18:59:43 -0800 From: Dave Crocker X-Mts: smtp Noel, This isn't intended to throw gasoline on the fire, though I fear it might have that effect: ---- Included message: Sigh, there seem to be two kinds of people in the world; those who think EI D's are absolutely the Right Thing (which should be added without delay), and t hose who just can't see what use they are. There is a third kind of person: Those who believe they DO understand the intent and feel that hostnames serve that purpose just fine... d/ From owner-big-internet@munnari.oz.au Sun Mar 28 00:14:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14234; Sun, 28 Mar 1993 00:14:53 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01917; Sat, 27 Mar 1993 15:19:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18806; Sat, 27 Mar 93 00:18:50 -0500 Date: Sat, 27 Mar 93 00:18:50 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9303270518.AA18806@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au There is a third kind of person: Those who believe they DO understand the intent and feel that hostnames serve that purpose just fine... First, let me apologize for using loose language and restate it more exactly. "The set of all people can be divided into two sets; the first includes all those who think EID's are absolutely the Right Thing (which should be added without delay), and the second includes those who are in the set of all people but aren't in the first set." I don't believe this allows for the existence of a third set, at least not of humans. To answer your technical point, there are a number of reasons to think that DNS names are not the answer. First (and most important to me, although I'll bet very few people agree with that priority), it was never defined *exactly* what a DNS name names, whereas what an EID names *is* defined exactly (at least by the person who coined the name "endpoint", i.e. me). Second, I want to put EID's in *all* packets, and DNS names (even in compressed form) are not suitable for that. Third, there might be a use to have a mapping from one DNS name to many endpoints; e.g. if a service was available on many servers. There are probably more if I stop to think. Noel From owner-big-internet@munnari.oz.au Sun Mar 28 01:53:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18789; Sun, 28 Mar 1993 01:53:24 +1000 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12651; Sat, 27 Mar 1993 23:36:43 +1000 (from kre@munnari.OZ.AU) To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) In-Reply-To: Your message of "Fri, 26 Mar 1993 07:37:42 PST." <9303261537.AA05250@Mordor.Stanford.EDU> Date: Sat, 27 Mar 1993 23:36:32 +1000 Message-Id: <6667.733239392@munnari.OZ.AU> From: Robert Elz Date: Fri, 26 Mar 93 07:37:42 -0800 From: Dave Crocker Message-ID: <9303261537.AA05250@Mordor.Stanford.EDU> Mobile hosts. This seems to be a rather dramatic topic shift - EID's may provide a useful support mechanism for mobile hosts, but they can do much much more than that. Their support for mobile hosts is just a special case of support for address changing, which in itself has more ramifications than just mobile hosts (trivial guaranteed simple address change support could mean a rather different policy of address allocation than is required when addresses are close to cast in concrete once assigned). Much as I know that what Noel said is correct, and there's little point opening up this debate once again ... An EID layer (eg: TUNE - see the B-I archives for details of John Curran's proposal) would provide an insulating layer between the network layer (or lower half of the network layer, that's just semantic drivel) and the transport layer, ie: TCP and UDP. That means that some of the current pain being undergone as we're trying to find a new network layer wouldn't need to be undergone next time - details of exactly what goes in the pseudo-header for checksums, etc, would have been decided and wouldn't need to change. This also allows the possibility of trivial gatewaying between different network layers during an upgrade process - only network layer info needs to be altered, at the minute such a gateway requires knowledge of how each network layer layers TCP (etc) on it, so that it can alter the checksum to account for differences in teh pseudo-header - not a nice thought. It would also help now, with multiple competing potential replacements about to be unleashed upon us - as it would really allow market forces to choose the eventual winner based on which gains greatest acceptance, with everyone free to choose the protocol they believe is truly better (for technical or political reasons, it doesn't matter). Though some noise is being made about letting the market decide, the "market" that currently will have the ability to decide is a very small one, end user sites are likely to very little opportunity to make a choice, they'll have to take whatever their provider, and then basically the backbone nets, want to supply, that and what has been chosen by their major peer sites - any opinion on which protocol is better is unlikely to factor much in the choice at all. Still, however useful it would have been, it seems its probably too late now, as the competing protocols are all directly layering TCP (etc) directly on top of their proposed IP replacement - even PIP which has EID's (or last I heard) is doing it that way. kre ps: for anyone who doesn't know, the B-I archives are to be found on munnari.oz.au [128.250.1.21] in big-internet/list-archives. You'll find TUNE in 1992-10-Oct. I do strongly recommend perusal of the archives by everyone with an interest in Big-Internet topics, there's a lot there that's true, but reading there first should save at least some of the tail chasing that is likely otherwise, when every idea is re-invented yet again. From owner-Big-Internet@munnari.oz.au Sun Mar 28 03:32:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22957; Sun, 28 Mar 1993 03:34:09 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22938; Sun, 28 Mar 1993 03:32:56 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA29327; Sat, 27 Mar 93 09:32:29 -0800 Message-Id: <9303271732.AA29327@Mordor.Stanford.EDU> To: John Curran Cc: big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sat, 27 Mar 93 12:20:06 -0500. <9303271720.AA29105@Mordor.Stanford.EDU> Date: Sat, 27 Mar 93 09:32:29 -0800 From: Dave Crocker X-Mts: smtp John, I don't take the scenario you describe as wild-eyed. I wish, in fact, we had a series of scenarios (ok, class. can we all say 'requirements analysis'?) on which to base discussions like these. It would give us focus and allow us to consider the REAL services and constraints that are needed. Dave From owner-big-internet@munnari.oz.au Sun Mar 28 03:55:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23535; Sun, 28 Mar 1993 03:55:41 +1000 (from owner-big-internet) Return-Path: Message-Id: <9303271755.23535@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22597; Sun, 28 Mar 1993 03:20:42 +1000 (from jcurran@nic.near.net) To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) In-Reply-To: Your message of Fri, 26 Mar 93 07:37:42 -0800. <9303261537.AA05250@Mordor.Stanford.EDU> Date: Sat, 27 Mar 93 12:20:06 -0500 From: John Curran -------- ] From: Dave Crocker ] Subject: Mobile hosts (was: Re: address vs. EID, revisited... ) ] Date: Fri, 26 Mar 93 07:37:42 -0800 ]... ] It seems to me that there are two, very different, kinds of mobility. ] One is local and the other is distant. Local mobility happens in ] real time, during data transfers. Distant happens less frequently and ] does not require real-time maintenance of connections. Cellular telephony ] has exactly this dual requirement and it solves them in very different ways. ] ] My own feeling is that local changes should/must be handled by an ] appropriate link-level mechanism which hides the mobility from the ] network layer. The network layer sees a constant address. We should encourage use of lower-layer (e.g. link layer over network layer) mechanisms wherever possible. It is less clear, to me, that there will not be a need for network-layer mobility in the future. I imagine someone with a laptop commuting with a cellular data link (with the cellular system handling data-link mobility just fine) who then walks into work and wants to "plug" into the office lan/man/wan for performance or cost reasons. If we're willing to sacrifice existing communications, then two domain names (or one domain name and dynamic updating) will suffice. It seems to me that the number of network transport services is going to increase dramatically over the next few years, and we're setting our sights fairly low if we think that people are not going to want conveniant mobility between these network services. It is also quite possible that mobility will simply administration by providing support for system portability and network layer autoconfiguration. This is not a wild-eyed cry for forcing mobility into the the network layer; to do so without determining the implications would be irresponsible. On the other hand, I don't think that mobility in the network layer can be simply dismissed as "not needed". I would suggest instead that it may lie too close to research to be included in this revision of the Internet network procotol. /John From owner-Big-Internet@munnari.oz.au Sun Mar 28 10:06:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29503; Sun, 28 Mar 1993 10:07:52 +1000 (from owner-Big-Internet) Return-Path: Received: from cs.columbia.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29478; Sun, 28 Mar 1993 10:06:58 +1000 (from ji@close.cs.columbia.edu) Received: from close.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA17693; Sat, 27 Mar 1993 19:06:22 -0500 Message-Id: <199303280006.AA17693@cs.columbia.edu> Received: by close.cs.columbia.edu (15.11/15.6) id AA21322; Sat, 27 Mar 93 19:06:03 est Date: Sat, 27 Mar 93 19:06:03 est From: John Ioannidis To: dcrocker@mordor.stanford.edu, owner-big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Cc: big-internet@munnari.oz.au I have argued for network-level (rather than datalink-level) mobility in my thesis. Some of the arguments are: the ability to switch between heterogeneous interfaces (e.g., from wireless to ethernet to slip, etc.), the ability to have a common mechanism for "local" and "global" mobility (and being able to stay online while switching providers), plus the argument that routing should be done cleanly at the network layer rather than kludged at the data-link layer (which is what bridging really is). /ji From owner-big-internet@munnari.oz.au Sun Mar 28 12:37:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02452; Sun, 28 Mar 1993 12:38:00 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25471; Sun, 28 Mar 1993 06:14:53 +1000 (from tsuchiya@thumper.bellcore.com) Received: by thumper.bellcore.com (4.1/4.7) id for kre@munnari.OZ.AU; Sat, 27 Mar 93 15:14:19 EST Date: Sat, 27 Mar 93 15:14:19 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9303272014.AA06271@thumper.bellcore.com> To: dcrocker@Mordor.Stanford.EDU, kre@munnari.OZ.AU Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Cc: big-internet@munnari.oz.au > > An EID layer (eg: TUNE - see the B-I archives for details > of John Curran's proposal) would provide an insulating layer > between the network layer (or lower half of the network layer, > that's just semantic drivel) and the transport layer, ie: TCP > and UDP. That means that some of the current pain being > undergone as we're trying to find a new network layer wouldn't > need to be undergone next time - details of exactly what goes > in the pseudo-header for checksums, etc, would have been decided > and wouldn't need to change. > Pip essentially does this. The "initial part" and "transit parts" are cleanly separated, and the transit part even host its own version number! Thus, an old Pip host can receive a packet even if the transit part (ie, the inside-the-network network layer part) is completely redefined..... > > Still, however useful it would have been, it seems its probably > too late now, as the competing protocols are all directly > layering TCP (etc) directly on top of their proposed IP > replacement - even PIP which has EID's (or last I heard) is > doing it that way. > Given the above statement, I think that even though strictly speaking TCP/UDP is on top of Pip, Pip has the characteristics you're looking for..... PX From owner-big-internet@munnari.oz.au Sun Mar 28 14:55:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06495; Sun, 28 Mar 1993 14:56:04 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB25797; Sun, 28 Mar 1993 06:37:08 +1000 (from tsuchiya@thumper.bellcore.com) Received: by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sat, 27 Mar 93 15:36:36 EST Date: Sat, 27 Mar 93 15:36:36 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9303272036.AA07290@thumper.bellcore.com> To: big-internet@munnari.oz.au, dcrocker@Mordor.Stanford.EDU Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) > > Moblile hosts are definitely an important concern. But I have yet to > hear an explanation for making the entire Internet community incur the > expense of supporting that capability in the network layer (or thereabouts). Who is saying that the entire internet community must encur expense for supporting internet-layer mobility? (This is not a rhetorical question). It seems to me we can do it in such a way that only the systems belonging to the same administration as the mobile host incur any overhead..... > > My own feeling is that local changes should/must be handled by an > appropriate link-level mechanism which hides the mobility from the > network layer. The network layer sees a constant address. I generally agree, but as it is impossible to assume that the local link layer has the right capability, it is good to have this capability in the internet layer. But, in the case of local mobility, you still don't need internet layer address changes, you must spread routing info about the individual (mobile) host in the local area..... > > Distant mobility requires changes to the Domain Name Service, to allow > dynamic update to a host's address record. The constant, then, is the > domain name for the host. > If you put the distant mobility function in DNS, then you really may cause the entire internet to incur the expense of mobility, because you may end up reducing the caching characteristics of DNS..... Your conclusion here seems to be that mobility does not belong in the internet layer, which I strongly disagree with..... PX From owner-big-internet@munnari.oz.au Sun Mar 28 15:59:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08039; Sun, 28 Mar 1993 15:59:37 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB00508; Sun, 28 Mar 1993 10:56:44 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA05425; Sat, 27 Mar 93 16:56:22 -0800 Message-Id: <9303280056.AA05425@Mordor.Stanford.EDU> To: John Ioannidis Cc: big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sat, 27 Mar 93 19:06:03 -0500. <199303280006.AA17693@cs.columbia.edu> Date: Sat, 27 Mar 93 16:56:22 -0800 From: Dave Crocker X-Mts: smtp John, I would, of course, be interested in getting a copy of your thesis. My reason for copying the list: Do you discussin/analysis of the costs to implement/operate such schemes? dave From owner-big-internet@munnari.oz.au Sun Mar 28 16:47:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09112; Sun, 28 Mar 1993 16:47:42 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00310; Sun, 28 Mar 1993 10:49:48 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA05115; Sat, 27 Mar 93 16:47:02 -0800 Message-Id: <9303280047.AA05115@Mordor.Stanford.EDU> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: kre@munnari.OZ.AU, big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sat, 27 Mar 93 15:14:19 -0500. <9303272014.AA06271@thumper.bellcore.com> Date: Sat, 27 Mar 93 16:47:02 -0800 From: Dave Crocker X-Mts: smtp Paul, I haven't been tracking PIP development and progress for the last few months. Is there yet any performance data for its various features? (And I'm intrigued to find myself, a SIP guy, asking you, a PIP guy, about this on a TUBA list. But the question is triggered by a generic issues, EID's.) d/ From owner-big-internet@munnari.oz.au Sun Mar 28 17:56:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10519; Sun, 28 Mar 1993 17:56:37 +1000 (from owner-big-internet) Return-Path: Message-Id: <9303280756.10519@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01629; Sun, 28 Mar 1993 11:59:58 +1000 (from jcurran@nic.near.net) To: Robert Elz Cc: Dave Crocker , big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) In-Reply-To: Your message of Sat, 27 Mar 93 23:36:32 +1000. <6667.733239392@munnari.OZ.AU> Date: Sat, 27 Mar 93 20:59:37 -0500 From: John Curran -------- From: Robert Elz Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Date: Sat, 27 Mar 1993 23:36:32 +1000 An EID layer (eg: TUNE - see the B-I archives for details of John Curran's proposal) would provide an insulating layer between the network layer (or lower half of the network layer, that's just semantic drivel) and the transport layer, ie: TCP and UDP. That means that some of the current pain being undergone as we're trying to find a new network layer wouldn't need to be undergone next time - details of exactly what goes in the pseudo-header for checksums, etc, would have been decided and wouldn't need to change. Yep. (fyi -- You can get TUNE as ID draft-curran-tune-00.txt, but you'd best hurry as it's due to expire shortly... ;-) ... Still, however useful it would have been, it seems its probably too late now, as the competing protocols are all directly layering TCP (etc) directly on top of their proposed IP replacement - even PIP which has EID's (or last I heard) is doing it that way. Don't give up all hope: while PIP may be using the full address as for transport service calls, the ID's are used for connection endpoints. (in the case of PIP systems speaking to PIP systems). This means that many of the benefits of EID-based transport are present. Should a scalable mapping function from ID-to-pip_address become available, one could create a revised transport interface which only needed endpoint ids in applications. (Look over the latest pip near-term architecture document for specifics.) /John From owner-big-internet@munnari.oz.au Sun Mar 28 18:34:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11226; Sun, 28 Mar 1993 18:35:16 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01954; Sun, 28 Mar 1993 12:14:03 +1000 (from tsuchiya@thumper.bellcore.com) Received: by thumper.bellcore.com (4.1/4.7) id for kre@munnari.OZ.AU; Sat, 27 Mar 93 21:13:37 EST Date: Sat, 27 Mar 93 21:13:37 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9303280213.AA16360@thumper.bellcore.com> To: dcrocker@Mordor.Stanford.EDU, tsuchiya@thumper.bellcore.com Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Cc: big-internet@munnari.oz.au, kre@munnari.OZ.AU > > Paul, > > I haven't been tracking PIP development and progress for the last > few months. Is there yet any performance data for its various > features? We have performance measures on the forwarding engine. These will be shown at the plenary talk. I'm not sure what you mean by performance data for various features. Do you mean scaling characteristics or something? Most of that we can write on paper now given assumptions that may turn out to be realistic or not, and only experience will tell..... > > (And I'm intrigued to find myself, a SIP guy, asking you, a PIP > guy, about this on a TUBA list. But the question is triggered by > a generic issues, EID's.) > I didn't even know this discussion was on the tuba list...... :-) PX From owner-big-internet@munnari.oz.au Sun Mar 28 20:54:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14670; Sun, 28 Mar 1993 20:55:12 +1000 (from owner-big-internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07472; Sun, 28 Mar 1993 15:31:02 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA14373; Sun, 28 Mar 93 00:30:16 -0500 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA00832; Sun, 28 Mar 93 00:31:26 EST Message-Id: <9303280531.AA00832@tipper> X-Really-To: gibbs.oit.unc.edu To: big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Mar 93 00:31:25 -0500 From: Simon Spero [ sorry if people get this twice; I read this list via news, and the gateway screwed up. ] From: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Newsgroups: info.big-internet Date: 27 Mar 93 17:32:15 GMT John, I don't take the scenario you describe as wild-eyed. I wish, in fact, we had a series of scenarios (ok, class. can we all say 'requirements analysis'?) on which to base discussions like these. It would give us When I think of Nomadic IP and EID/addressing, I have a mental image of a few scenarios. Imagine this situation: I'm getting ready to go to Amsterdam for the IETF. I sit down and write a quick note to a list on my "Air Newton" personal digital basketball shoe, which is connected via ISDN to CONCERT (open channel B). I start an FTP going, but before it finishes, the taxi to the airport arrives. I disconnect the isdn cable, and go the taxi. In the meantime, the PDBS has switched over to it's build in cellular telephone (hell, I smoke, so I'm going to die of cancer anyway). The FTP finishes, and I arrive at the airport. The flight is delayed, so I go to a connection point in the airport and jack in connecting to (say) the Murphy Brown backbone, which is cheaper than the cellular rates. I log in to my computer at work and start some program running. My flight is called, so I board the plane. I can't use the cell phone on the plane, and GTE seat-net is unbelievably expensive, so I just tell it where I'm sitting, so that I can be reached if urgent email arrives. Take off occurs, and the plane leaves North America, switching from a local network to a more exensive atlantic satellite net. Passengers in 1st class can afford to keep their netnews flowing in; back here in geek class, a couple of kids have strung a porta-fiber link and are playing an annoyingly loud game of net-trek. I stuff the free earplugs into the appropriate orifices, drain the last of the minature scotch, and doze off. Just as I get to sleep, the PDBS buzz gently, informing me that a report from back home is ready for downloading when I get to a cheaper connection. Finally, we touch down at Schipol. As I step into the terminal, the cellphone configures itself for the local service, and establishes a connection. the PDBS grabs some important, but non urgent mail which has been waiting for me; the connection charge is still too high to grab the report. Finally I make it to the hotel. I stagger to the terminal room and hook into the show net, taking advantage of the free bits to catch up on all the backed up traffic. Now it's time to sleep. Upstairs to the hotel room, where I set the shoes for a wakeup call, and let them connect to Hyatt-net. During this night, the program I started back at the airport completes and prints the result (42) to the waiting telnet session. Simon Hackers Local 42- National Union of Computer Operatives, Chapel Hill section - ------------------------------------------------------------------------------ "Arise you users of compression, though the | WAIS/Z39.50 spoken here tarfiles hold you down" - The Internetworkale | DoD #612 | Tel: +1-919-962-9107 ------- End of Forwarded Message From owner-Big-Internet@munnari.oz.au Mon Mar 29 00:11:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07748; Mon, 29 Mar 1993 00:11:32 +1000 (from owner-Big-Internet) Received: from scslwide.sony.co.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07694; Mon, 29 Mar 1993 00:11:17 +1000 (from tera@csl.sony.co.jp) Received: from socslgw.csl.sony.co.jp by scslwide.sony.co.jp with SMTP (4.2/Sony4.2MX) id AA20360; Sun, 28 Mar 93 23:11:07 JST Received: from tera.csl.sony.co.jp by socslgw.csl.sony.co.jp with SMTP (4.2/Sony4.2MX) id AA19055; Sun, 28 Mar 93 23:10:51 JST Received: by tera.csl.sony.co.jp (4.2/6.4J.4) id AA10724; Sun, 28 Mar 93 23:10:51 JST Return-Path: Message-Id: <9303281411.AA10724@tera.csl.sony.co.jp> To: rafal@fuw.edu.pl (Rafal Pietrak) Cc: big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) In-Reply-To: Your message of "Thu, 25 Mar 93 16:06:25 +0100." <9303251506.AA12175@cocos.fuw.edu.pl> Date: Sun, 28 Mar 93 23:10:50 +0900 From: TERAOKA Fumio > From: rafal@fuw.edu.pl (Rafal Pietrak) > Message-Id: <9303251506.AA12175@cocos.fuw.edu.pl> > Date: Thu, 25 Mar 93 16:06:25 +0100 > > Now, by introduction of a layer (and this is the 'unorthodoxy' about this > idea) between network and transport layer -- we allow the transport layer to > select the destination for packets based on their EIDs, and this is what > the transport layer likes most. EID-layer would then resolve such EID into a > net address -- preferred by routers -- in a similar meaner as net address is > resolved into the physical address between network and link layers, but based > on DNS technilogy. I proposed such an architecture in a paper ("A Network Architecture Providing Host Migration Transparency", in Proc. of SIGCOMM'91) and developed VIP (Virutal IP) by applying it to IP. In my architecture, the conventinal network layer is divided into two sublayers, the virtual network sublayer and the physical network sublayer. The virtual network sublayer provides the transport layer with migration independent IDs of hosts, called 'virtual network addresses'. The virtual network sublayer also resolves virtual network addresses into 'physical network addresses' which represent location of hosts. VIP is running in my test network. My dissertation describes the architecture in detail and shows the measured performance of VIP. ------------------------------------------------------------------- TERAOKA, Fumio e-mail: tera@csl.sony.co.jp Sony Computer Science Laboratory Inc. phone: +81-3-3448-4380 From owner-Big-Internet@munnari.oz.au Mon Mar 29 01:21:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26166; Mon, 29 Mar 1993 01:21:24 +1000 (from owner-Big-Internet) Return-Path: Received: from sunic.sunet.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26102; Mon, 29 Mar 1993 01:21:09 +1000 (from rafal@fuw.edu.pl) Received: from cocos.fuw.edu.pl by sunic.sunet.se (5.65c8-/1.28) id AA19917; Sun, 28 Mar 1993 17:20:25 +0200 Received: from zorro.fuw.edu.pl by cocos.fuw.edu.pl (4.1/SMI-4.1) id AA16483; Sun, 28 Mar 93 17:19:53 +0200 From: rafal@fuw.edu.pl (Rafal Pietrak) Message-Id: <9303281519.AA16483@cocos.fuw.edu.pl> Received: by zorro.fuw.edu.pl (NX5.67c/NX3.0X) id AA01359; Sun, 28 Mar 93 17:19:41 +0200 Date: Sun, 28 Mar 93 17:19:41 +0200 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au > Date: Fri, 26 Mar 93 09:30:59 -0500 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Now, by introduction of a layer (and this is the 'unorthodoxy' about > this idea) between network and transport layer > > This exact model has been discussed previously on this list. I mentioned > then that prefer a slightly different model, where the 'network' layer (i.e. > the end-end unreliable datagram layer) is composed of two sub-layers, the > lower of which uses topological addresses, and the higher uses endpoint > ID's. I prefer to do it this way since the functionality (end-end unreliable > datagram) which is provided by the two sub-layers is almost the same, and I > like a full layer to provide a major increment of function. (Also, it allows > us to escape learning a new 8 layer model! :-) Well, I didn't now that. In fact this is why I was so cautious about statements in my proposal. Anyway, the reason I called my proposal 'unorthodox' is precisely this: I believe that it would be beneficial to start thinking in 8 layer model ;-). And the reasoning is the following: - simplicity within router design - end points (hosts) of communication session are the ones who have control on the address selection (policy 'routing') - allowing different ID assignment architecture in both cases -- they (EID and address) deserve it. - one relay doesn't need dynamic DNS update in this new environment. And the trick to clearity to design is that there is no routing done on EIDs and there is no 'comminicating party validation' done on address. How does it sound? The good point about it is that advances in routing technology (network layer) may occur independently of advances in speaker validation technology (EID layer). > Of course there are other advantages (in my opinion) of having the new > EID layer introduced > > Absolutely. In fact, I'm willing to wager that we don't yet know all the > advantages, and only over time will it become clear how good an idea this > is. Ditto. > Prolonged argument on this point seems to have reached the point of > substantially diminshing returns, so I don't think a long (or any, for that > matter :-) debate will be useful! Ok, few comments on response I received an I'm off... > Date: Fri, 26 Mar 93 18:59:43 -0800 > From: Dave Crocker > Sigh, there seem to be two kinds of people in the world; those who think > EID's are absolutely the Right Thing (which should be added without > delay), and those who just can't see what use they are. > > There is a third kind of person: Those who believe they DO understand > the intent and feel that hostnames serve that purpose just fine... In fact, thinking about EID I have domain names in mind -- although I believe, that putting it into every packet (which may be desirable at certain point for statistics purpose for example) may demand 'digitization' of it. On the other hand I think that a simple scheme like that devised for SNMP IDs, may by used in the beginning , DNS servers would only be required to provide a unique number for every name defined within their authority zone. > Date: Sat, 27 Mar 93 19:06:03 est > From: John Ioannidis > I have argued for network-level (rather than datalink-level) mobility > in my thesis. Some of the arguments are: the ability to switch between > heterogeneous interfaces (e.g., from wireless to ethernet to slip, > etc.), the ability to have a common mechanism for "local" and "global" > mobility (and being able to stay online while switching providers), > plus the argument that routing should be done cleanly at the network > layer rather than kludged at the data-link layer (which is what > bridging really is). Although I didn't know your work, it is precisely this functionality I had in mind when devising this EID-layer frame of thinking. > Date: Sat, 27 Mar 93 15:14:19 EST > From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) > Pip essentially does this. The "initial part" and "transit > parts" are cleanly separated, and the transit part even host > its own version number! Thus, an old Pip host can receive a packet > even if the transit part (ie, the inside-the-network network > layer part) is completely redefined..... Well, but the point is, that I believe this EID functionality is ill-placed in network layer. Routing should not be done based on EIDs. > Date: Sat, 27 Mar 93 15:36:36 EST > From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) > > Distant mobility requires changes to the Domain Name Service, to allow > > dynamic update to a host's address record. The constant, then, is the > > domain name for the host. > If you put the distant mobility function in DNS, then you really > may cause the entire internet to incur the expense of mobility, > because you may end up reducing the caching characteristics of > DNS..... Yup, and the trick here is to have mobile hosts defined _staticaly_ in DNS (with a kind of w wildcard in address), and have it _resolved_ dynamically, not dynamically updated. > Date: Sun, 28 Mar 93 00:31:25 -0500 > From: Simon Spero > When I think of Nomadic IP and EID/addressing, I have a mental image of a > few scenarios. Imagine this situation: > I'm getting ready to go to Amsterdam for the IETF. [...deleted] In fact the background of my reasoning is an image of an internet, that reaches your home (that is your family premices ;-) by means of 3-5 providers and your TV selects it's address (and according provider) based on a profile of your desire, while still remaining your_oun_TV. The image of a mobile host is a car traversing Europe with navigational tool changing relays every 30-50 km, and your onboard phone doing the same, but possibly with different relays (PTT, not telemetric stations). And I'd prefer that the communicating host have control over the actual selection. Eventually I believe that with separate EID layer this should be possible. > Date: Sun, 28 Mar 93 23:10:50 +0900 > From: TERAOKA Fumio > I proposed such an architecture in a paper ("A Network Architecture > Providing Host Migration Transparency", in Proc. of SIGCOMM'91) and > developed VIP (Virutal IP) by applying it to IP. In my architecture, > the conventinal network layer is divided into two sublayers, the virtual As I said, I'm not that much of an expert to judge whether my concept was new or not. I apologize to all, that had developed scenarios based on similar assumptions -- PIP developers for example. Still, I believe that there is some 'fresh air' in having an idea of 4 layers below transport layer instead of ISO classical 3. And I do believe, that mixing EIDs into network layer is a bad idea. -Rafal From owner-Big-Internet@munnari.oz.au Mon Mar 29 05:59:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25746; Mon, 29 Mar 1993 06:00:04 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25589; Mon, 29 Mar 1993 05:59:40 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11781>; Sun, 28 Mar 1993 11:59:20 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 28 Mar 1993 11:59:14 -0800 To: rafal@fuw.edu.pl (Rafal Pietrak) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: address vs. EID, revisited... In-Reply-To: Your message of "Sun, 28 Mar 93 07:19:41 PST." <9303281519.AA16483@cocos.fuw.edu.pl> Date: Sun, 28 Mar 1993 11:59:13 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Mar28.115914pst.12171@skylark.parc.xerox.com> > How does it sound? The good point about [an EID layer] is that advances in > routing technology (network layer) may occur independently of advances > in speaker validation technology (EID layer). Here we go again... The bad point about it is that it introduces another, unnecessary naming space into the Internet, along with all the management headaches that entails. There are good schemes for supporting mobile hosts that do not require adding an EID layer to the architecture -- several of them have been presented to the IETF Mobile IP WG. In each of those schemes, packets to mobile hosts end up sometimes carrying two "destination" addresses. (The second address appears in an encapsulating header or an IP souce route option.) One address serves the purpose of identifying the host (the "home" address) and one is used for routing (the "current" address). The fact that the host identifier is itself a real address is very benificial -- it enables it to be used for routing towards something that knows the current location of the mobile host, i.e., a server or router of some sort in the home domain. One benefit of these schemes is that only those packets that actually need separate "location" and "identification" thingies incur the overhead of the extra thingy. Steve From owner-Big-Internet@munnari.oz.au Tue Mar 30 03:22:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13042; Tue, 30 Mar 1993 03:23:03 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13039; Tue, 30 Mar 1993 03:22:53 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Mon, 29 Mar 1993 09:22:39 -0800 Date: Mon, 29 Mar 1993 09:22:39 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199303291722.AA09225@zephyr.isi.edu> To: big-internet@munnari.oz.au, dcrocker@Mordor.Stanford.EDU Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) *> *> Mobile hosts. *> *> Moblile hosts are definitely an important concern. But I have yet to *> hear an explanation for making the entire Internet community incur the *> expense of supporting that capability in the network layer (or thereabouts). Dave, I want to try out on you a philosophical idea about this. Taking a very broad view of the Internet architecture and its origins in Dod-sponsored research, you may note that a key issue in the design of TCP/IP was robustness. During 1977-1981 TCP/IP design meetings, we talked a lot about the military "robustness" requirement on the protocols. Always present in the background was the doomsday (ie nuclear warfare) scenario, and the need to get the message across no matter how many network resources had "vanished". I believe that one of the charming ironies of history is that this emphasis led rather accidentally to a major strength of the protocols in the civilian world -- their ability to plug-and-play, to work right out of the box, with minimal tuning or complex configuration. That's background. Now, I wnat to float an analogous hypothesis about mobile hosts. Suppose we DID make mobility a fundamental requirement of a follow-on architecture. I suggest that this would have an unintended (?) consequence: it would force us to remove the architecturally-undesirable dependence on IP addresses from our software. This in turn might VERY MUCH simplify the management of IPvX addresses in the future. Bob Braden From owner-big-internet@munnari.oz.au Tue Mar 30 05:12:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16687; Tue, 30 Mar 1993 05:14:19 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06570; Tue, 30 Mar 1993 00:29:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06310; Mon, 29 Mar 93 09:26:31 -0500 Date: Mon, 29 Mar 93 09:26:31 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9303291426.AA06310@ginger.lcs.mit.edu> To: deering@parc.xerox.com, rafal@fuw.edu.pl Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Here we go again... Sigh. I should just cut my hands off... The bad point about it is that it introduces another, unnecessary naming space into the Internet, along with all the management headaches that entails. The good point about it is that it introduces another, necessary naming space into the Internet, along with all the power and flexibility that entails. Lest you think I'm being flip, I a) mean this seriously, and b) mean to show that statements of this sort aren't much use. There are good schemes for supporting mobile hosts that do not require adding an EID layer to the architecture I wish people would stop thinking that supporting mobile hosts is the reason for adding EID's. It's not, it's just an *example* of the *kind of thing* EID's allow you to do. The next person who makes this error I am going to seriously flame (so when it happens, don't say you weren't warned :-). One [name] serves the purpose of identifying the host ... and one is used for routing ... One benefit of these schemes is that only those packets that actually need separate "location" and "identification" thingies incur the overhead of the extra thingy. Exactly. Now, let's see where that thought, applied rigorously, leads us. If you think about the communication substrate of the future, I reckon it's going to look a lot like ATM. Dave Clark invented "flows" as a basic paradigm at the *internetworking* layer because he saw that pure 'packet' and 'virtual circuit' models are the ends of a spectrum, each with advantages and disadvantages. You can get a system with the advantages of both, and the disadvantages of neither, if you have a model which is intermediate: flows. They have state in the network, but it's not *critical* (i.e. non-replaceable) state. The critical state is all co-located with the application; i.e. "fate- sharing", the key design principal of the original TCP/IP architecture. They all go together if they go! However, if you think about it, this analysis also applies at the *physical network* layer. ATM is the first widespread physical network technology that looks like this; it's neither fish nor fowl - it has packet aspects, and circuit aspects, since that's the way to get the best system. Probably most future networking technology will share these characteristics. So, at both physical network and internetwork layers, the network of the future is going to have flows. I.e., we won't be doing a route selection or computation ot whatever for each packet. Most packets will travel along already set up flows. I agree with you that we should not have the "location" and "identification" names in each packet. Since we aren't doing any routing for most packets, it's clearly pointless to have the "location" name (i.e. the address) in each packet. The one you want (if any) is the "identification", i.e. the EID. Then, only the packets which are not part of a flow need the extra overhead of the "location" name; i.e. the address. Noel From owner-big-internet@munnari.oz.au Tue Mar 30 05:48:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17903; Tue, 30 Mar 1993 05:50:05 +1000 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15095; Tue, 30 Mar 1993 04:22:38 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11633>; Mon, 29 Mar 1993 10:21:53 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 29 Mar 1993 10:21:43 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... In-Reply-To: Your message of "Mon, 29 Mar 93 06:26:31 PST." <9303291426.AA06310@ginger.lcs.mit.edu> Date: Mon, 29 Mar 1993 10:21:26 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Mar29.102143pst.12171@skylark.parc.xerox.com> > I wish people would stop thinking that supporting mobile hosts is the reason > for adding EID's. It's not, it's just an *example* of the *kind of thing* > EID's allow you to do. The next person who makes this error I am going to > seriously flame (so when it happens, don't say you weren't warned :-). Yes, Noel, I am perfectly aware that you believe that EIDs belong in the architecture to satisfy some fundamental law of Computer Science, and not just to support mobile hosts. However, the bulk of the discussion in this thread has been about using EIDs to support mobile hosts, and I felt it was important point out that EIDs are not needed for that purpose. You will have to come up with a better example to justify EIDs. > ... One benefit of these schemes is that only those packets that > actually need separate "location" and "identification" thingies incur > the overhead of the extra thingy. > > Exactly. Now, let's see where that thought, applied rigorously, leads us. > > If you think about the communication substrate of the future, I reckon it's > going to look a lot like ATM. ... Exactly what rigorous thinking led to you the conclusion that the future substrate is going to look a lot like ATM? > ...Dave Clark invented "flows" as a basic paradigm at the *internetworking* > layer because he saw that pure 'packet' and 'virtual circuit' models are > the ends of a spectrum, each with advantages and disadvantages. You can get > a system with the advantages of both, and the disadvantages of neither, if > you have a model which is intermediate: flows. They have state in the > network, but it's not *critical* (i.e. non-replaceable) state. The critical > state is all co-located with the application; i.e. "fate-sharing", the key > design principal of the original TCP/IP architecture. They all go together > if they go! I agree with most of that, but it's not at all like ATM. ATM is strictly at the virtual circuit end of the spectrum. > However, if you think about it, this analysis also applies at the *physical > network* layer. ATM is the first widespread physical network technology that > looks like this; it's neither fish nor fowl - it has packet aspects, and > circuit aspects, since that's the way to get the best system. What *are* you talking about? X.25 has packet aspects and circuit aspects. So does Frame Relay. All that distinguishes ATM is it's fixed cell size. Steve From owner-Big-Internet@munnari.oz.au Tue Mar 30 06:13:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18613; Tue, 30 Mar 1993 06:14:21 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18581; Tue, 30 Mar 1993 06:13:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09253; Mon, 29 Mar 93 15:12:46 -0500 Date: Mon, 29 Mar 93 15:12:46 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9303292012.AA09253@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu You will have to come up with a better example to justify EIDs. Providing an example of the need for X is not a balanced analysis of the need for X. You can't justify something with examples. Exactly what rigorous thinking led to you the conclusion that the future substrate is going to look a lot like ATM? Well, the next couple of paragraphs of that message is my reasoning, actually. ATM is strictly at the virtual circuit end of the spectrum. Huh? ATM does not guarantee delivery, does it? (I guess I'm glossing over here the difference between the ATM substrate and the various AAL's, but I find my mind has (mercifully :-) forgotten the details.) Perhaps the problem lies with mismatched definitions of "virtual circuit"; I don't think developing one everyone can agree with is a useful goal, but perhaps you could tell me if your definition differs from mine, which is *roughly*: - i) the only service model offered to the user is a circuit setup - ii) critical state is stored in the network - iii) the burden of reliable delivery is borne by the network substrate, not the end-points X.25 has packet aspects and circuit aspects. So does POTS, if you look inside the network, what with stat muxes, etc. However, by the measures I used above, X.25 is pretty much on the VC end of things. So does Frame Relay. All that distinguishes ATM is it's fixed cell size. Frame relay is roughly contemporaneous with ATM, and seems to have many of the same properties. (I forget whether it is reliable or not; I seem to recall that it isn't.) I didn't mean to exclude it; I gues I should have used "ATM/FR" every place I said "ATM" in the original note. Having dispensed with all these minor, surface, points, I don't see any debate about my basic argument; i.e. i) that the future belongs to "flows", at both the physical network layer as well as the internetwork, ii) if that's so, we won't be "routing" each packet, and iii) if so, we don't need the "location" name in every packet. Could you please point out which of these steps is in error, and what is wrong with it? Noel From owner-Big-Internet@munnari.oz.au Wed Mar 31 02:05:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03942; Wed, 31 Mar 1993 02:06:08 +1000 (from owner-Big-Internet) Return-Path: Received: from SIUCVMB.SIU.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03936; Wed, 31 Mar 1993 02:05:55 +1000 (from @SIUCVMB.SIU.EDU:namag_c@zeus.c-engr2.siu.edu) Received: from zeus.c-engr2.siu.edu by SIUCVMB.SIU.EDU (IBM VM SMTP V2R1) with TCP; Tue, 30 Mar 93 10:06:58 CST Received: from isis.c-engr2.siu.edu.tech by zeus.c-engr2.siu.edu (4.1/SMI-4.1) id AA27411; Tue, 30 Mar 93 10:02:53 CST Date: Tue, 30 Mar 93 10:02:53 CST From: namag_c@zeus.c-engr2.siu.edu (Chandrashekar Namagondlu) Message-Id: <9303301602.AA27411@zeus.c-engr2.siu.edu> Apparently-To: sub -please include me in yr mailing list. I ma told this group is for discussions on routing. bye From owner-Big-Internet@munnari.oz.au Wed Mar 31 03:32:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07058; Wed, 31 Mar 1993 03:32:16 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07055; Wed, 31 Mar 1993 03:32:08 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA18225; Tue, 30 Mar 93 09:31:53 -0800 Message-Id: <9303301731.AA18225@Mordor.Stanford.EDU> To: Simon Spero Cc: big-internet@munnari.oz.au Subject: Re: Mobile hosts (was: Re: address vs. EID, revisited... ) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sat, 27 Mar 93 23:38:37 -0500. <930328043 8.AA00449@SunSite.unc.edu> Date: Tue, 30 Mar 93 09:31:53 -0800 From: Dave Crocker X-Mts: smtp Dammit, Simon, When I asked for scenarios, I didn't expect anything nearly that complete or well-written. Yikes, what a fantasy. The part that bothers me the most is that it sounds attainable -- and even likely -- before I retire. If we could assemble a couple of equally plausible and well-written descriptions of the data-comm life we envision, I'd strongly suggest publishing them at least as an RFC, to give the community some sort of common framework for thinking about stuff. Dave P.S. I still don't think the fantasy requires EID's. P.P.S. Sure hope the Scotch miniatures include a good single malt. d/