Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03136; 1 May 93 13:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03132; 1 May 93 13:43 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa14417; 1 May 93 13:42 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12439; Sun, 2 May 1993 02:04:04 +1000 (from owner-Big-Internet) Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12428; Sun, 2 May 1993 02:03:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11228; Sat, 1 May 93 12:03:51 -0400 Date: Sat, 1 May 93 12:03:51 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9305011603.AA11228@ginger.lcs.mit.edu> To: dkatz@cisco.com, jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EIDs Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Hardly new technology; this is exactly how OSI first-hop routing works. Pretty much. It also would have the same operating mode if no routers are present; you assume the destination is local and try and send to it. Sure, this model looks a lot like the OSI model. That's not a big deal to me. I never said that the OSI architecture was awful, or that it didn't have some places in which it had minor advantages over TCP/IP. This is such a place. However, that's not saying I think we should switch protocols, which is a whole different argument (and not one we can settle, so let's not start that again, OK? :-). There are a number of differences in the model, though. For one, I think that in the long run Redirects (in their current form) are headed for the ash-heap. As we routing gets more and more policy based, routes from a source to a destination will be set up as the result of some negotiation between the client and a "route generator"; routers simply won't be able to look at a destination address and say "oh, X is a better first hop router to that". However, that's still to come. Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09553; 2 May 93 19:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09549; 2 May 93 19:12 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa15791; 2 May 93 19:12 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07593; Mon, 3 May 1993 08:18:27 +1000 (from owner-Big-Internet) Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07589; Mon, 3 May 1993 08:18:17 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA00395; Sun, 2 May 93 15:18:11 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA22436; Sun, 2 May 93 15:18:26 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25505; Sun, 2 May 93 15:18:09 PDT Date: Sun, 2 May 93 15:18:09 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Hinden Message-Id: <9305022218.AA25505@bigriver.Eng.Sun.COM> To: Bob Braden Cc: big-internet@munnari.oz.au In-Reply-To: <199304301853.AA29415@zephyr.isi.edu> Subject: Re: expansion on my note about IPv7 and EIDs Content-Length: 721 I agree with Bob Braden's message. I was at the front of the room at the IPoverATM meeting when the issue of changing the architecture came up. My response was of the form that if there was a good reason to relax the architecture (allow hosts on one IP network to send directly to host on a different IP network without going through a router) and a well engineered mechanism was developed to use it, then I didn't think it would be difficult to have the changes adopted. Work in this area in the recent past has desired the former but has been lacking in the latter. If the current work going on in the IPoverATM develops a workable solution, then I don't think the architectural issues will be insurmountable. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11351; 2 May 93 22:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11347; 2 May 93 22:44 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa19797; 2 May 93 22:44 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16492; Mon, 3 May 1993 12:00:45 +1000 (from owner-Big-Internet) Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16432; Mon, 3 May 1993 11:59:19 +1000 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB06142; Sun, 2 May 93 18:57:08 PDT Date: Sun, 2 May 93 18:57:08 PDT Message-Id: <9305030157.AB06142@wc.novell.com> To: bhatiani@jpmorgan.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com Subject: Re: EID Visibility... Cc: big-Internet@munnari.oz.au OK, i'm a bit confused by your questions. > EID's are a networking concept and separate current naming and routing > functions. EID's perform naming and routing will be left to something else. > right? Unlike IP addresses, a process/thread can have multiple EID's. I don't know what it means for a process/thread to "have" an IP address or an EID. A process/thread can certainly have open various "sockets" (in the general networking sense, not in the BSD sense), each with a different IP address assigned to it (or different EID in some people's vision of the future). > > My question is, what is the normal scope of an EID created by a >process. Processes don't create EID's. Processes (whatever a process is...) create things (endpoints, sockets, whatever you would like to call them) which are bound to EID's (or to IP addresses). Greg Minshall minshall@wc.novell.com Novell, Inc. +1 510 975-4507   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20976; 3 May 93 14:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20969; 3 May 93 14:04 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa12514; 3 May 93 14:04 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02554; Tue, 4 May 1993 03:12:46 +1000 (from owner-Big-Internet) Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02551; Tue, 4 May 1993 03:12:32 +1000 (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 AA01044; Mon, 3 May 93 10:12:27 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA24524; Mon, 3 May 93 13:12:26 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA17144; Mon, 3 May 93 13:12:25 EDT Date: Mon, 3 May 93 13:12:25 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank T Solensky Message-Id: <9305031712.AA17144@fenway.andr.UB.com> To: big-internet@munnari.oz.au Subject: Re: New "growth" charts I've been correctly reminded by Terry Gray (gray@cac.washington.edu) that there's an important distinction one must keep in mind when using these graphs: the numbers being plotted represent the "network numbers" as opposed to "number of networks". If an individual organization has sixteen Class C network numbers, it would represent 16 numbers on this chart rather than the single network. In the beginning of April, I had estimated the actual number of networks then to be 7333 nets in 10693 numbers. At that ratio, there would be about 7716 connected networks. -- Frank   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23373; 3 May 93 15:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23365; 3 May 93 15:34 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa16479; 3 May 93 15:34 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05806; Tue, 4 May 1993 04:35:22 +1000 (from owner-Big-Internet) Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05800; Tue, 4 May 1993 04:35:09 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA00232; Mon, 3 May 93 11:34:58 PDT Date: Mon, 3 May 93 11:34:58 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Message-Id: <9305031834.AA00232@saffron.acc.com> To: solensky@andr.ub.com Subject: Re: New "growth" charts Cc: big-internet@munnari.oz.au >> I've been correctly reminded by Terry Gray (gray@cac.washington.edu) >> that there's an important distinction one must keep in mind when >> using these graphs: the numbers being plotted represent the >> "network numbers" as opposed to "number of networks". If an >> individual organization has sixteen Class C network numbers, it >> would represent 16 numbers on this chart rather than the single >> network. From a very technical perspective, this is probably right. However, now we are measuring two different things: attached "customers", and network numbers that the routers need to store and maintain routes to. From a marketing perspective, customer count is interesting. But from a "to what requirements do I need to engineer my router and my routing protocols" perspective, actual network numbers is what's interesting. Fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08059; 4 May 93 12:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08055; 4 May 93 12:59 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14489; 4 May 93 12:59 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08042; 4 May 93 12:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08033; 4 May 93 12:59 EDT Received: from ftp.com by CNRI.Reston.VA.US id aa14484; 4 May 93 12:59 EDT Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA15450; Tue, 4 May 93 12:59:27 -0400 Date: Tue, 4 May 93 12:59:27 -0400 Message-Id: <9305041659.AA15450@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EIDs X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: stev knowles Cc: big-internet@munnari.oz.au, jmh@anubis.network.com, iesg@CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu X-Orig-Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com > In the IP over ATM working group, when discussion of support for what > Robert is calling the Loose Catanet Model comes up, the IESG representative > has repeated said that if we want to consider that, we should ask upstairs > (from the IAB) for permission to violate (or change) the architecture. > >I don't think we need to get the IAB to formally OK this. This is the kind of >thing the IETF can perfectly well decide, although I certainly would bring >the IAB in at an early stage. However, let's ignore the politics and focus >on the technical. this "IESG representative" was me. while i have a great deal of respect for noel's opinions, i woul dsuggest he is *wrong* here. the IAB is the group responsible for the purity of the IP protocol suite. any RFC that violates this that is submitted to the Internet Area *must* get signoff from the IAB. this can happen early in the process, before alot of work is done, or it can happen late in the process, when people arent as interested in waiting around for more cerebal ruminations. note that the IAB voting thumbs down will not necessarily cause the work to die, but it will cause it to be presented to the IESG for PROPOSED standard status with a no vote from at least myself, and probably from the other internet AD. the battle to get a document with this handicap thru the process will be exceptionally great. >It's really a routing issue this states it all, clearly and succinctly. >I've felt for a while that we should change the host IP layer so that it no >longer includes the "mask and match" test to route outgoing packets. Rather, >I'd rather see the hosts rely *entirely* on the routers to know where things >are. I.e., whenever you go to send packets to an IP destination which is not >in the cache on the host, it sends the packet to one of the routers which it >can reach directly. The router will then reply (if necessary) with a redirect >packet. This would allow us to hide a migration from the "strict" model to >the "loose" model in the routers. is this "nimrod"? >What does the IESG say? A new WG to write this RFC, or should IPLPDN do it? where did IPLPDN come into it? ATM is the one interested currently. i could see a new WG, but the IAB will have something to say about the charter (as is allowed in the "new world order(tm)".   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09175; 4 May 93 14:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09171; 4 May 93 14:00 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa16502; 4 May 93 14:00 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00976; Wed, 5 May 1993 02:50:08 +1000 (from owner-big-internet) Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26790; Wed, 5 May 1993 01:07:08 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11731>; Tue, 4 May 1993 08:06:32 PDT Received: by redwing.parc.xerox.com id <57154>; Tue, 4 May 1993 08:06:16 -0700 Date: Tue, 4 May 1993 08:06:10 PDT X-Orig-Sender: Lixia Zhang Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lixia Zhang To: Noel Chiappa Cc: big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: EID lookups In-Reply-To: Your message of Thu, 22 Apr 1993 18:42:11 -0700 Message-Id: > For host EIDs, (my naive thinking says) > - the EID space would be at least a few orders of magnitude larger > than SSN space. > - the info in EID database would be at least a few orders of magnitude > more dynamic than info in SSN databse. > - a centralized EID database will not do the job, has to be highly > distributed. > - thus an EID must contain adequate information/hint about where to > obtain info for this EID within the next few msec or sec. > > > I agree with the first three points, but I'm wondering about the fourth. I > would think that the speed needed for EID lookups would be related to how > often and how integral to normal operation those lookups are. I.e. if you do > them all the time, in the normal course of things, it would need to be fast, > but if you only do them in rare circumstances (like on some error conditions) > it could be slower. > > My model is that you wouldn't often (except in a transitional mode for > reinterpreting the 32-bit files in IPv4 headers as EID's) be looking up EID's > to translate them into something else; you'd do the DNS name -> (EID, address) > tuple translation once, and then pass them around together to everyone who > needs them. If you wanted to change the binding from EID to address (e.g. for > a mobile host) you'd use an explicit transaction (e.g. ICMP) to do so. Noel, enlighten me a bit more on this one: say we use EID for mobile host support, when I want to send to a mobile host and I know its EID, shouldn't this lookup of (EID -> current adrress) be fast? (no matter what transaction you use, ICMP or whatever). > So, what model for the use of EID's do you have where you need to look them up > a lot, and quickly? I need to know this before I know if I agree with your > fourth point. I must confess that I'm not a regular big-internet reader, just peek in now and then. Do I recall discussions about using EIDs for security purpose, or for accounting purpose? both would need authentication, need to verify whether the supplied EID is a valid one, right? And if I'm yet to be convinced that everything in the future would be long-lasting flows, I have to worry about doing this sort of lookups for short-lived transfers or datagrams. So, how could I not demand a fast EID lookup speed? I'd like to repeat my earlier point again: yes our SSN system is in a flat space, but one cannot derive a conclusion that computer EIDs can also live in a flat space. We need a proof, and I have not seen one.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12500; 4 May 93 16:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12496; 4 May 93 16:37 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa23735; 4 May 93 16:37 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07978; Wed, 5 May 1993 05:50:55 +1000 (from owner-Big-Internet) Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07975; Wed, 5 May 1993 05:50:47 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA29369 (5.65c/IDA-1.4.4nsd for ); Tue, 4 May 1993 12:50:39 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA09633 (5.65c/IDA-1.4.4-910725); Tue, 4 May 1993 12:50:37 -0700 Message-Id: <199305041950.AA09633@remmel.NSD.3Com.COM> To: Lixia Zhang Cc: big-Internet@munnari.oz.au Subject: Re: EID lookups In-Reply-To: Your message of "Tue, 04 May 93 08:06:10 PDT." Date: Tue, 04 May 93 12:50:36 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: tracym@nsd.3com.com > Noel, enlighten me a bit more on this one: say we use EID for mobile > host support, when I want to send to a mobile host and I know its EID, > shouldn't this lookup of (EID -> current adrress) be fast? > (no matter what transaction you use, ICMP or whatever). > I must confess that I'm not a regular big-internet reader, just peek > in now and then. Do I recall discussions about using EIDs for > security purpose, or for accounting purpose? both would need > authentication, need to verify whether the supplied EID is a valid > one, right? > > And if I'm yet to be convinced that everything in the future would be > long-lasting flows, I have to worry about doing this sort of lookups > for short-lived transfers or datagrams. > So, how could I not demand a fast EID lookup speed? > > I'd like to repeat my earlier point again: yes our SSN system is in a > flat space, but one cannot derive a conclusion that computer EIDs can > also live in a flat space. We need a proof, and I have not seen one. Is it really an all or nothing issue? Why must ALL lookups be fast? My expectations fall near the middle of those expressed in recent messages. I expect/hope to use EIDs relatively frequently for many purposes (that's why I included the second paragraph above), BUT I expect that the actual lookup will normally only be slow once in a while, usually when I want to reach a host with whom I haven't conversed in a while. Having looked up the EID in the recent past, either I or the directory service I'm using should be able to optimize following lookups for the same EID so long as I use it often enough and don't otherwise interfere, for instance by changing my own location too rapidly, or changing directory servers, etc. I can imagine a flat space working. I can also imagine the utility of 64-bit EID's with some structure, but I think that the main purpose of the structure should be to support allocation mechanisms that would guarantee uniqueness. Regards, Tracy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15034; 4 May 93 19:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15030; 4 May 93 19:35 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa29168; 4 May 93 19:35 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14652; Wed, 5 May 1993 08:48:31 +1000 (from owner-big-internet) Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09171; Wed, 5 May 1993 06:29:51 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA24591; Tue, 4 May 93 13:21:10 -0700 To: Big-Internet@munnari.oz.au Reply-To: Vernon Schryver X-Approved: newsmail@sgi.sgi.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vernon Schryver Subject: Re: expansion on my note about IPv7 and EIDs Message-Id: Date: Tue, 4 May 1993 20:19:36 GMT stev@ftp.com (stev knowles) writes: > ... > >I've felt for a while that we should change the host IP layer so that it no > >longer includes the "mask and match" test to route outgoing packets. Rather, > >I'd rather see the hosts rely *entirely* on the routers to know where things > >are. I.e., whenever you go to send packets to an IP destination which is not > >in the cache on the host, it sends the packet to one of the routers which it > >can reach directly. The router will then reply (if necessary) with a redirect > >packet. This would allow us to hide a migration from the "strict" model to > >the "loose" model in the routers. > > is this "nimrod"? I must be missing something. Besides IS-ES and maybe nimrod, isn't this "router discovery" of blessed status, as evidenced by an holy RFC? For that matter, how does this differ from the ancient "default static route" beloved by system administrators the world around? Vernon Schryver, vjs@sgi.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03952; 5 May 93 9:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03947; 5 May 93 9:32 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa08942; 5 May 93 9:32 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26648; Wed, 5 May 1993 22:47:37 +1000 (from owner-big-internet) Received: from dkuug.dk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24897; Wed, 5 May 1993 21:58:37 +1000 (from kbe@sony.craynet.dk) Received: from mips.uucp by dkuug.dk with UUCP id AA19076 (5.65c8/IDA-1.4.4j for big-internet@munnari.oz.au); Wed, 5 May 1993 13:58:19 +0200 Received: from sony by craynet.dk (5.61/SMI-4.1) id AA23896; Wed, 5 May 93 14:53:51 +0200 Received: by sony.craynet.dk (4.0/SMI-4.1) id AA17379; Wed, 5 May 93 13:53:44 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kjeld Borch Egevang Message-Id: <9305051253.AA17379@sony.craynet.dk> Subject: help To: big-internet@munnari.oz.au Date: Wed, 5 May 1993 13:53:43 +0100 (WET DST) Organization: Cray Networks A/S - Denmark X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1 X-Charset: ASCII X-Char-Esc: 29   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21074; 5 May 93 14:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21070; 5 May 93 14:01 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa18808; 5 May 93 14:00 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06960; Thu, 6 May 1993 03:04:51 +1000 (from owner-Big-Internet) Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06952; Thu, 6 May 1993 03:04:38 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA15244; Wed, 5 May 93 13:06:13 -0400 Date: Wed, 5 May 93 13:06:13 -0400 Message-Id: <9305051706.AA15244@worldlink.worldlink.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Piscitello" To: Bob Hinden Cc: big-internet@munnari.oz.au Subject: clarification Hey, folks, let's not dump on Stev as the fall guy for this statement, and let's get the record straight. I was equally mortified at the direction the conversation was taking precisely because (as some mail long deleted so aptly indicated) that we were suggesting a change based on a single network technology rather than looking at this problem and how it affected or might affect IP networking in general. (Stev, this is a tardy acknowledgement of your mention that "the other Internet AD"--a.k.a. bastard #2, and of course, a title I'll long cherish, "IP bigot"-- agreed) Let's examine the issue in the broad context, and fix the architecture if it is indeed broken.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21864; 5 May 93 14:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21859; 5 May 93 14:28 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19840; 5 May 93 14:28 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21851; 5 May 93 14:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21847; 5 May 93 14:28 EDT Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa19835; 5 May 93 14:28 EDT Received: by ginger.lcs.mit.edu id AA08692; Wed, 5 May 93 14:28:43 -0400 Date: Wed, 5 May 93 14:28:43 -0400 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9305051828.AA08692@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: expansion on my note about IPv7 and EID Cc: iesg@CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu From: stev@ftp.com (stev knowles) the IAB is the group responsible for the purity of the IP protocol suite. any RFC that violates this that is submitted to the Internet Area *must* get signoff from the IAB. Sigh, I don't think the IAB has an eternal veto on changes the IETF wants, but I don't want to re-run Ethernet_MIB/Kobe_IPv7/etc. Let's just take the path of least uproar, and involve them early then. > I 've felt for a while that we should change the host IP layer so that > it no longer includes the "mask and match" test to route outgoing > packets. Rather, I'd rather see the hosts rely *entirely* on the routers > to know where things are. I.e., whenever you go to send packets to an IP > destination which is not in the cache on the host, it sends the packet > to one of the routers which it can reach directly. The router will then > reply (if necessary) with a redirect packet. This would allow us to hide > a migration from the "strict" model to the "loose" model in the routers. is this "nimrod"? Not really (and I'm speaking here of getting rid of the "match and mask" test in the hosts). The name 'Nimrod' covers several distinct things, including a) a routing architecture, and b) a *particular* deployment plan for a) in the context of IPv4 which reinterprets the 32-bit fields in IP packets as EID's. That particuular deployment plan would be marginally more pleasant with this change, but it's not necessary. > What does the IESG say? A new WG to write this RFC, or should IPLPDN do > it? where did IPLPDN come into it? ATM is the one interested currently. i could see a new WG, but the IAB will have something to say about the charter (as is allowed in the "new world order(tm)". Oh, sorry, I was slightly confused. I was thinking of the "Directed ARP" document (RFC1433) which does pretty much the same thing, and that document came from the IPLPDN group. That document makes a change to the way routing is done in the host IP layer, just doesn't call it out explicitly as a change to the basic IP architeture. (The actual mechanism in that document I'm not too thrilled about, since I think it mixes together inter-network->local-network address resolution and inter-network level packet routing a little too tightly, at least if I understood it correctly, but that's a different debate.) I think perhaps a new WG is the right thing; that way the charter can be tightly drawn to handle just i) whether to change what the architectural model of what an IP (sub)network says about the addresses which are part of that (sub)network, and ii) how that would affect the host routing. Once that is done, the WG can be rechartered (or a new one formed, or IPLPDN can be told to do it) to consider what actual mechanism to use to get the needed info to the host. From: David M. Piscitello we were suggesting a change based on a single network technology rather than looking at this problem and how it affected or might affect IP networking in general. ... Let's examine the issue in the broad context, and fix the architecture if it is indeed broken. Well, that was to some degree the whole concept of IPLPDN, to examine generic WAN issues like address resolution and provide mechanisms which could (within the limits of practicality) be used across them all. For a number of reasons (and I have to take part of the blame here, for not starting all the needed 'IP over ' groups) IPLPDN never focused in on this. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) I must be missing something. Besides IS-ES and maybe nimrod [sic], isn't this "router discovery" of blessed status, as evidenced by an holy RFC? For that matter, how does this differ from the ancient "default static route" beloved by system administrators the world around? Neither RD nor DSR proposes getting rid of the step that says (in effect) "check to see if the destination is on the local network, and in that case *only* send it directly to the destination". There is no individual step which does this, but the treatment of incoming ICMP Redirects in Host Requirements (RFC1122) - "A Redirect message SHOULD be silently discarded if the new gateway address it specifies is not on the same connected (sub-)net through which the Redirect arrived ..., or if the source of the Redirect is not the current first-hop gateway for the specified destination" - together with the outbound packet routing algorithm - "If the destination is on a connected network, the datagram is sent directly to the destination host; otherwise, it has to be routed to a gateway on a connected network. ... To decide if the destination is on a connected network, the following algorithm MUST be used..." - effectively make this the current standard. Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04031; 6 May 93 10:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04027; 6 May 93 10:32 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11515; 6 May 93 10:32 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04006; 6 May 93 10:32 EDT Received: from nsco.network.com by IETF.CNRI.Reston.VA.US id aa04000; 6 May 93 10:31 EDT Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA24534; Thu, 6 May 93 09:34:23 -0500 Received: from petunia.network.com by anubis.network.com (4.1/SMI-4.1) id AA11461; Thu, 6 May 93 09:30:58 CDT Date: Thu, 6 May 93 09:30:58 CDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9305061430.AA11461@anubis.network.com> To: atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US Subject: A Proposal for consideration In the course of the ongoing work in the IP over Large Public Data Networks (IPLPDN) working group and the IP over ATM (IP/ATM) working group, certain needs have become clear. In particular, there are two coupled problems of wide applicability which need to be addressed. 1) It is taken as a given that large switched virtual circuit networks will exist. These may be Frame Relay, ATM, a combination of both, or even X.25. In these networks, it is envisioned that the economics will be such that there is a significant advantage if two entities (routers or end stations) attached to the switched fabric can communicate directly. Most analysis shows advantages in cost, performance, and resource usage. However, in such a large network, it is neither feasible nor desirable to insist that there be one common network number for everyone. Therefore, to permit this mode of operation, it is necessary to permit direct communication between peer IP entities which do not have a common network number. Rather than blithely permitting this and going on our way, it is recommended that sufficient time and energy be spent exploring the implications of this, so as to satisfy all interested participants that the problem has been addressed properly. Among the demonstrations that some work is needed is that fact that address resolution in such a network bears a striking similarity to proxy ARP. While proxy ARP is widely used, it is also widely known as somewhat dangerous. Therefore, we must address how the address resultion will tie in with routing (see item 2 below) so as to avoid the pitfalls that have been found. 2) Given such a large switched virtual fabric, there is the open question of how, in a logical and protocol sense, routing should be performed. Our current model assumes that two routers who can exchange data will be exchanging routing protocol. Obviously, every router in a large topology can not peer with every other router. Nor can we treat the entire network as one lan, and use a single designated router. Note that the problem being addressed here is the IP routing one, not the VC Routing. That is the question to be asked is, given a host/router on the switched network, and a destination IP address, how will the host/router pick a peer over the switched network to establish a circuit with, for this traffic. This is distinct from the VC routing problem of what path the circuit should take within the cloud. There are some approaches available to this problem, but they need refinement and analysis. Can BGP servers use BGP next hop information to handle this? Can IDRP work similarly? How can we facilitate end-points which have a lower connectivity requirement, and do not wish to buffer the entire topology description? Clearly, the routing work here, the address resolution, and the architectural changes to enhance direct communication are closely related. These items should be considered as either a focussed topic for an existing working group, or as the agenda for a new working group (in which case this proposal could be redrafted into the form of a proposed charter with deliverables identified).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05739; 6 May 93 12:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05735; 6 May 93 12:20 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa14633; 6 May 93 12:20 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29786; Fri, 7 May 1993 01:33:49 +1000 (from owner-Big-Internet) Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29783; Fri, 7 May 1993 01:33:43 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA01753; Thu, 6 May 93 06:41:27 -0400 Date: Thu, 6 May 93 06:41:27 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Hitchcock Message-Id: <9305061041.AA01753@er.doe.gov> To: big-internet@munnari.oz.au, hugh@csis.dit.csiro.au From hughf@csis.dit.csiro.au Mon May 3 01:17:19 1993 Received: from algol.csis.dit.csiro.au by lynx (4.1/1.4S) id AA18716; Mon, 3 May 93 15:21:26 EST Received: by algol.csis.dit.csiro.au (4.1/1.3C) id AA23489; Mon, 3 May 93 15:21:24 EST From: hughf@csis.dit.csiro.au Message-Id: <9305030521.AA23489@algol.csis.dit.csiro.au> Subject: Re: EIDs for app programmers To: hitchcoc@oerv01.er.doe.gov Date: Mon, 3 May 93 15:21:23 EST X-Face: %Y=q|_=@?d$0;1u<%JiKdr~y6W.j4EUl6/>UNBRsq:ZYde6!><;G#F(-qY7CGW0H(^?x1Nv iVV0I,N]qeX35pkh/X7i1!+v668\'j#^Fv)GT=YIyKM)?iCA;U=w5_j#^.P!}O'~[1~F\j`.U[ X-Mailer: ELM [version 2.3 PL11] Status: RO You wrote on 27 April: >The EID discussion seems to be now wandering into new directions such as what >services could be location independantly defined. I agree that this is a useful >discussion and that these ideas are important. > >However, the EID discussion began with the conceptually simple idea that it might be >useful to separate the two concepts of the identity of the endpoint and the topologically significant address of the endpoint's network connection. ... Your concept of an EID seems much more practical than what I've been reading on the list lately. My perspective is that of an application programmer and Unix system administrator rather than a networking guru. Currently I tend to regard IP addresses as EIDs: they uniquely identify a host, and at least 95% of the time a host will have only one address. To clear up my confusion about the "semantics of EIDs", could you answer these questions with respect to your idea of how they would work? Just yes or no would do fine if you don't want to repeat earlier discussions - I can dig those out. Would EIDs be assigned dynamically when a session/connection (Telnet, AFS link, socket) is opened? Or would they be relatively permanent as are IP addresses? Would a sysadmin below the level of a campus/building network administrator need to use addresses in addition to EIDs - to install a newly purchased host? - for simple troubleshooting? (ie ping) address binding might get fouled up you would probably need to sometimes use the address too.> Would EIDs replace IP addresses in the DNS - for application routines such as gethostbyname? - for nslookup and similar 'domain browsing' tools? Would mapping from EID to domain name - be possible, but slow? - be fast enough for frequent use? Would reverse mappping from network address to EID - be possible, but slow? - be fast enough for frequent use? I understand that EIDs would allow the network topology outside the local subnet to be changed without affecting "live" connections. < I think this is major point of attractiveness> Would EIDs also allow portable hosts to be shut down, moved, and reattached to a different network? Would EIDs also allow mobile hosts to move around on the local subnet without connections being disrupted? Oh, a comment on assignment: if end host installers have to be responsible for two sets of unique numbers, I suspect the scheme isn't going to work. The easiest and most reliable way to get unique EIDs will be to use the network address or some derivation of. It will work wonderfully until the service provider changes and your old numbers get assigned to someone new. Hugh Fisher   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08463; 6 May 93 14:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08459; 6 May 93 14:49 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa19162; 6 May 93 14:48 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05657; Fri, 7 May 1993 03:50:42 +1000 (from owner-big-internet) Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23649; Thu, 6 May 1993 23:22:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27980; Thu, 6 May 93 09:22:25 -0400 Date: Thu, 6 May 93 09:22:25 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9305061322.AA27980@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, lixia@parc.xerox.com Subject: Re: EID lookups Cc: big-Internet@munnari.oz.au From: Lixia Zhang > My model is that you wouldn't often ... be looking up EID's to translate > them into something else; you'd do the DNS name -> (EID, address) tuple > translation once, and then pass them around together to everyone who > needs them. Noel, enlighten me a bit more on this one: say we use EID for mobile host support, when I want to send to a mobile host and I know its EID, shouldn't this lookup of (EID -> current adrress) be fast? (no matter what transaction you use, ICMP or whatever). Hmm, we aren't communicating; I thought my paragraph above was a possible answer, but clearly not. Let me try this again. You are trying to communicate with a mobile host. In what circumstances would you have the EID of the endpoint for that mobile host, and nothing else? As far as I can see, in communicating with a mobile host, you either a) have an open connection or b) do not. In the former circumstance, the mobile host knows you are there, and when it moves, it will advise you (via an ICMP 'new address for endpoint' message or a base station, or some other easily imagined mechanism) that the endpoint has moved to a new address. In the latter I imagine you'd have a DNS name; when you look that up, you get back both the EID of the endpoint, and the address the endpoint is currently at. (I don't know of too many people or applications which go around using IP addresses instead of DNS names now. I'm darned if I know the IP address of *anything* I currently use... I mean, I know ginger is 18.something, but that's about it.) Do I recall discussions about using EIDs for security purpose, or for accounting purpose? both would need authentication, need to verify whether the supplied EID is a valid one, right? Yes, but exactly the same thing is true of IP addresses. Look, take EID's out of the picture: presumably in the circumstances about which you enquire above in which you would have only had an EID, in the model without EID's you would have only an IP address. How are the problems associated with doing any of the above with EID's any worse than doing them with IP addresses? And if I'm yet to be convinced that everything in the future would be long-lasting flows, I have to worry about doing this sort of lookups for short-lived transfers or datagrams. If you don't believe in flows, that just makes it slightly less useful to have EID's in all packets, since you'd pretty much have to have an address in every packet as well. It doesn't mean that endpoints or EID's are any less useful in all the other ways they are good ideas. yes our SSN system is in a flat space, but one cannot derive a conclusion that computer EIDs can also live in a flat space. Well, the SSN is not a truly flat space (i.e. they don't hand the numbers out randomly). There is structure there (I'm not positive of what it all is, but I think some of it is related to which office you get your SSN from), but it is not visible to most *users* of the SSN. They only care about its *unique*, and to a much lesser degree, *fixed-length* properties. I maintain the same thing will be true of EID's. End-end protocols such as TCP *won't care* about how we allocate EID's, or look them up if and when we need to; they will simply care that they are unique and of a shortish, fixed length, and identify the endpoint no matter where it is, which interface you get to it through, etc, etc. So, how could I not demand a fast EID lookup speed? Again, I'm trying to see in what *common* circumstances you'd have *only* an EID, and need to do a fast lookup of something else associated with it. (If it's not common, it won't kill us if it's not fast, right?) I maintain that we should, and can easily, engineer things in the complete system so that anytime you need something *other* than the EID, it's already there. From: tracym@nsd.3com.com Is it really an all or nothing issue? Why must ALL lookups be fast? ... I expect that the actual lookup will normally only be slow once in a while, usually when I want to reach a host with whom I haven't conversed in a while. Having looked up the EID in the recent past, either I or the directory service I'm using should be able to optimize following lookups for the same EID... Another good point. I can imagine a flat space working. I can also imagine the utility of 64-bit EID's with some structure, but I think that the main purpose of the structure should be to support allocation mechanisms that would guarantee uniqueness. Exactly. Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12808; 6 May 93 16:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12804; 6 May 93 16:54 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa23633; 6 May 93 16:54 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09530; Fri, 7 May 1993 05:43:04 +1000 (from owner-Big-Internet) Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09519; Fri, 7 May 1993 05:42:48 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA28394; Thu, 6 May 93 12:42:39 -0700 Message-Id: <9305061942.AA28394@Mordor.Stanford.EDU> To: Noel Chiappa Cc: lixia@parc.xerox.com, big-Internet@munnari.oz.au Subject: Re: EID lookups Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 06 May 93 09:22:25 -0400. <9305061322.AA27980@ginger.lcs.mit.edu> Date: Thu, 06 May 93 12:42:38 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Noel, et al, Small point: Social Security Numbers are not unique. Collisions occasionally happen. d/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13360; 6 May 93 17:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13356; 6 May 93 17:18 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa24431; 6 May 93 17:18 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10505; Fri, 7 May 1993 06:09:45 +1000 (from owner-Big-Internet) Message-Id: <9305062009.10505@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10500; Fri, 7 May 1993 06:09:26 +1000 (from ULLMANN@PROCESS.COM) Date: Thu, 6 May 1993 16:06 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert L Ullmann To: ipv7@world.std.com Cc: big-internet@munnari.oz.au Subject: Amsterdam WG query Hi, I have been asked to determine more accurately the interest level in a (proposed) WG meeting in Amsterdam for IPv7 (and RAP, initially). Please send me a note if you are planning on attending Amsterdam and are interested in the WG meeting. If you are one of the people already involved in the project, please respond anyway (i.e. don't assume I will count you) because I don't know yet if you are going to the IETF. Following is the DRAFT charter that has been submitted to the Area Directorate. Best Regards, Robert Ullmann Ariel@Process.COM Intl: +1 508 879 2960 x226 in US: (800) 722-7770 x226 ----------------------------------------------------------------------------- Internet Protocol Version 7 (ipv7) Charter Chair: Vladimir Sukonnik Internet Area Directors: Stev Knowles David Piscitello Mailing List: Discussion: ipv7@world.std.com To Subscribe: ipv7-request@world.std.com Archive: world.std.com:/pub/ipv7/... Description of Working Group: Internet Version 7 is a new version of the IP and TCP/UDP protocols, to advance the Internet technology to the scale and performance of the next generation of internetwork technology. The IPv7 project was started in 1988 to speculate on what a new version might look like, as it was becoming clear that version 4 would presently be reaching its limits. The specification (including RAP, TCP extensions, and the AD plan now in separate drafts) was circulated informally in late 1989, and again in 1990 and 1991. It was then issued as an internet-draft in August 1992. The Working Group is chartered to evaluate issues arising during product development and deployment planning, and to document problems and explanations for any parts of the coexistance with IPv4 not covered directly in the IPv7-IPv4 interoperation design. The WG will also be the initial forum for development of the RAP protocol while it is experimental; this work will need to be moved to the Routing Area when it is to be advanced. The WG is also chartered to provide an open industry forum for coordination of commercial deployment plans. Goals and Milestones: Mar 93 (26th IETF) Issue revised internet drafts, plenary presentation. (completed) Apr 93 Issue Experimental RFCs for IPv7 and RAP. (Approved by IESG, sent to RFC editor) Jun 93 Start of RAP deployment. Jul 93 (27th IETF, first WG meeting) Discuss additional definitions needed, e.g. TCP SACK and TS options, LSRR and others for IP layer. Possible AD allocation plan. Report on ongoing experimentation. Either recommend to IESG that IPv7 be advanced to Proposed Standard, or determine detailed criteria to be met prior to recommendation. Nov 93 (28th IETF) Preliminary vendor deployment coordination. Review advancement criteria, make recommendation to IESG. Revised I-Ds for options and planning due prior to IETF. Review status and WG assignment of RAP protocol. Jan 94 Start of IPv7 deployment. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------ Aug 92 Mar 93 TCP/IP: Internet Version 7 Feb 93 Mar 93 RAP: Route Access Protocol   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14282; 6 May 93 18:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14278; 6 May 93 18:36 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26437; 6 May 93 18:37 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14270; 6 May 93 18:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14266; 6 May 93 18:36 EDT Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa26427; 6 May 93 18:36 EDT Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Thu, 6 May 1993 15:36:46 -0700 Date: Thu, 6 May 1993 15:36:46 -0700 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Braden Message-Id: <199305062236.AA09340@zephyr.isi.edu> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EID Cc: iesg@CNRI.Reston.VA.US *> *> - together with the outbound packet routing algorithm - *> *> "If the destination is on a connected network, the datagram is sent *> directly to the destination host; otherwise, it has to be routed to a *> gateway on a connected network. ... To decide if the destination is on a *> connected network, the following algorithm MUST be used..." *> *> - effectively make this the current standard. *> *> *> Noel *> *> Yes, RFC-1122 did intend to mandate the mask-and-match algorithm, which was considered part of the current architecture. I agree that it is appropriate to reconsider this requirement. Bob Braden   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15031; 6 May 93 20:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15027; 6 May 93 20:55 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29645; 6 May 93 20:55 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15019; 6 May 93 20:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15015; 6 May 93 20:55 EDT Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa29640; 6 May 93 20:55 EDT Received: by ginger.lcs.mit.edu id AA15191; Thu, 6 May 93 20:55:00 -0400 Date: Thu, 6 May 93 20:55:00 -0400 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9305070055.AA15191@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, braden@isi.edu, jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EID Cc: iesg@CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu Yes, RFC-1122 did intend to mandate the mask-and-match algorithm, which was considered part of the current architecture. I agree that it is appropriate to reconsider this requirement. Mmmm, any guesses on what the attitude of the IAB as a whole would be? You want to ask at their next telecon? Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16732; 6 May 93 23:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16728; 6 May 93 23:47 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa02978; 6 May 93 23:47 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26764; Fri, 7 May 1993 12:36:28 +1000 (from owner-Big-Internet) Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA26756; Fri, 7 May 1993 12:36:16 +1000 (from myron@ktxc3.kentrox.com) Received: from kentrox (via kentrox.kentrox.com) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25204; Thu, 6 May 93 22:28:06 -0400 Received: from ktxc3.ktxnet by kentrox (4.1/SMI-4.1) id AA10189; Thu, 6 May 93 09:47:55 PDT Received: by ktxc3.ktxnet (4.1/SMI-4.1) id AA04284; Thu, 6 May 93 09:47:53 PDT Date: Thu, 6 May 93 09:47:53 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Myron Hattig Message-Id: <9305061647.AA04284@ktxc3.ktxnet> To: big-internet@munnari.oz.au Subject: information Hello, Could someone please give me information about this list (big-internet@munnari.oz.au) including some combination of the purpose of the list, FAQs, and the administrative address. Thank you, Myron Hattig - myron@kentrox.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00858; 7 May 93 4:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00854; 7 May 93 4:37 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02473; 7 May 93 4:37 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00846; 7 May 93 4:37 EDT Received: from dxmint.cern.ch by IETF.CNRI.Reston.VA.US id aa00842; 7 May 93 4:35 EDT Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26258; Fri, 7 May 1993 10:35:21 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA21810; Fri, 7 May 1993 10:35:18 +0200 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9305070835.AA21810@dxcern.cern.ch> Subject: Re: A Proposal for consideration To: Joel Halpern Date: Fri, 7 May 1993 10:35:18 +0200 (MET DST) Cc: atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US In-Reply-To: <9305061430.AA11461@anubis.network.com> from "Joel Halpern" at May 6, 93 09:30:58 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 643 Joel, You ask where we should discuss 2 questions, how are IP addresses resolved to physical addresses in a switched network (a network in which the classical catenet model does not apply), and how is IP routing information exchanged in such a network. This problem is not limited to ATM so it seems to me that iplpdn is the right place. Maybe Juha's NBMA ARP should move to iplpdn? I think there is a third question, how can we move to the use of an individual switched circuit per transaction (TONIC, TCP over nonexistent IP connection). Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03184; 7 May 93 9:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03180; 7 May 93 9:27 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08966; 7 May 93 9:27 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03172; 7 May 93 9:27 EDT Received: from NR-TECH.CIT.CORNELL.EDU by IETF.CNRI.Reston.VA.US id aa03167; 7 May 93 9:26 EDT Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB28006; Fri, 7 May 93 09:24:31 EDT Message-Id: <9305071324.AB28006@mitchell.cit.cornell.edu> Date: Fri, 7 May 1993 09:24:56 -0500 To: Brian Carpenter CERN-CN , Joel Halpern X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott_Brim@cornell.edu X-Sender: swb@132.236.199.25 (Unverified) Subject: Re: A Proposal for consideration Cc: atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US On the other hand every working group and every person has its own style, its own focus, and ironically things often get done faster in multiple meetings (with information exchange between them) than they would in one big meeting. These are complex issues, and based on past observation I think the individual working groups should keep their own identities even if their discussions overlap a lot. You need occasional joint meetings, and frequent communication between the chairpersons, but I don't think any topic should be limited a priori to just one WG. IETFers just don't work that way. Scott At 10:35 AM 5/7/93 +0200, Brian Carpenter CERN-CN wrote: >Joel, > >You ask where we should discuss 2 questions, how are IP addresses >resolved to physical addresses in a switched network (a network >in which the classical catenet model does not apply), and how is >IP routing information exchanged in such a network. > >This problem is not limited to ATM so it seems to me >that iplpdn is the right place. Maybe Juha's NBMA ARP should >move to iplpdn? > >I think there is a third question, how can we move to the use >of an individual switched circuit per transaction >(TONIC, TCP over nonexistent IP connection). > >Regards, > Brian Carpenter CERN, brian@dxcern.cern.ch > voice +41 22 767 4967, fax +41 22 767 7155   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05791; 7 May 93 10:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05787; 7 May 93 10:34 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11527; 7 May 93 10:34 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05765; 7 May 93 10:34 EDT Received: from dxmint.cern.ch by IETF.CNRI.Reston.VA.US id aa05761; 7 May 93 10:33 EDT Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18812; Fri, 7 May 1993 16:34:09 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA26762; Fri, 7 May 1993 16:34:05 +0200 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9305071434.AA26762@dxcern.cern.ch> Subject: Re: A Proposal for consideration To: Scott_Brim@cornell.edu Date: Fri, 7 May 1993 16:34:05 +0200 (MET DST) Cc: jmh@anubis.network.com, atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US In-Reply-To: <9305071324.AB28006@mitchell.cit.cornell.edu> from "Scott_Brim@cornell.edu" at May 7, 93 09:24:56 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1768 It occurs to me that a focussed joint meeting of atm and iplpdn at Amsterdam might lead to a conclusion on where to handle this. It's very kind of Joel to volunteer to write a draft paper :-) Brian >--------- Text sent by Scott_Brim@cornell.edu follows: > > On the other hand every working group and every person has its own style, > its own focus, and ironically things often get done faster in multiple > meetings (with information exchange between them) than they would in one > big meeting. These are complex issues, and based on past observation I > think the individual working groups should keep their own identities even > if their discussions overlap a lot. You need occasional joint meetings, > and frequent communication between the chairpersons, but I don't think any > topic should be limited a priori to just one WG. IETFers just don't work > that way. > Scott > > At 10:35 AM 5/7/93 +0200, Brian Carpenter CERN-CN wrote: > >Joel, > > > >You ask where we should discuss 2 questions, how are IP addresses > >resolved to physical addresses in a switched network (a network > >in which the classical catenet model does not apply), and how is > >IP routing information exchanged in such a network. > > > >This problem is not limited to ATM so it seems to me > >that iplpdn is the right place. Maybe Juha's NBMA ARP should > >move to iplpdn? > > > >I think there is a third question, how can we move to the use > >of an individual switched circuit per transaction > >(TONIC, TCP over nonexistent IP connection). > > > >Regards, > > Brian Carpenter CERN, brian@dxcern.cern.ch > > voice +41 22 767 4967, fax +41 22 767 7155 >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06049; 7 May 93 10:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06044; 7 May 93 10:39 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11682; 7 May 93 10:39 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06037; 7 May 93 10:39 EDT Received: from NR-TECH.CIT.CORNELL.EDU by IETF.CNRI.Reston.VA.US id aa06032; 7 May 93 10:38 EDT Received: from [132.236.199.71] (SLUF.CIT.CORNELL.EDU) by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA01407; Fri, 7 May 93 10:37:36 EDT Message-Id: <9305071437.AA01407@mitchell.cit.cornell.edu> Date: Fri, 7 May 1993 10:38:43 -0500 To: Brian Carpenter CERN-CN X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott_Brim@cornell.edu X-Sender: swb@132.236.199.25 Subject: Re: A Proposal for consideration Cc: jmh@anubis.network.com, atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US Great idea. See you there. At 10:34 AM 5/7/93 -0400, Brian Carpenter CERN-CN wrote: >It occurs to me that a focussed joint meeting of atm and iplpdn >at Amsterdam might lead to a conclusion on where to handle this. >It's very kind of Joel to volunteer to write a draft paper :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09846; 7 May 93 12:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09842; 7 May 93 12:59 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16921; 7 May 93 12:59 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09834; 7 May 93 12:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09829; 7 May 93 12:59 EDT Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16916; 7 May 93 12:59 EDT Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Fri, 7 May 1993 09:59:14 -0700 Date: Fri, 7 May 1993 09:59:14 -0700 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Braden Message-Id: <199305071659.AA22112@zephyr.isi.edu> To: big-internet@munnari.oz.au, braden@isi.edu, jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EID Cc: iesg@CNRI.Reston.VA.US *> From jnc@ginger.lcs.mit.edu Thu May 6 17:55:26 1993 *> Date: Thu, 6 May 93 20:55:00 -0400 *> From: jnc@ginger.lcs.mit.edu (Noel Chiappa) *> To: big-internet@munnari.oz.au, braden@ISI.EDU, jnc@ginger.lcs.mit.edu *> Subject: Re: expansion on my note about IPv7 and EID *> Cc: iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu *> Content-Length: 314 *> X-Lines: 8 *> *> Yes, RFC-1122 did intend to mandate the mask-and-match algorithm, which *> was considered part of the current architecture. *> I agree that it is appropriate to reconsider this requirement. *> *> Mmmm, any guesses on what the attitude of the IAB as a whole would be? You *> want to ask at their next telecon? *> *> Noel *> As a matter of fact, Noel, it has already been brought up in the IAB, by Yakov Rekhter. There was no disagreement with the view I expressed above, and Yakov, John Romkey, and I took an action to write down something about it. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09406; 11 May 93 1:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09402; 11 May 93 1:41 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa08352; 11 May 93 1:40 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29012; Tue, 11 May 1993 13:53:52 +1000 (from owner-big-internet) Message-Id: <9305110353.29012@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24992; Tue, 11 May 1993 12:27:03 +1000 (from ULLMANN@PROCESS.COM) Date: Mon, 10 May 1993 22:26 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert L Ullmann To: big-internet@munnari.oz.au Subject: just when you thought it was safe to go outside ... Hi, At the request of Stev Knowles, AD for the Internet area, the name of the IPv7 project has been changed to TP/IX. This was an old acronym for the project (one tributary of it), that hasn't been used in several years; but will serve. The mail-list and archive names will stay the same for the moment; watch for announcements. I apologize for any confusion this may cause. If you need a press contact, please refer them to me. With My Best Regards, Robert Ullmann   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29540; 24 May 93 14:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29536; 24 May 93 14:24 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa11513; 24 May 93 14:23 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11816; Tue, 25 May 1993 03:28:44 +1000 (from owner-Big-Internet) Received: from dkuug.dk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11755; Tue, 25 May 1993 03:28:12 +1000 (from kbe@sony.craynet.dk) Received: from mips.uucp by dkuug.dk with UUCP id AA21056 (5.65c8/IDA-1.4.4j for Big-Internet@munnari.OZ.AU); Mon, 24 May 1993 19:27:51 +0200 Received: from sony by craynet.dk (5.61/SMI-4.1) id AA12596; Mon, 24 May 93 20:26:18 +0200 Received: by sony.craynet.dk (4.0/SMI-4.1) id AA23179; Mon, 24 May 93 19:26:17 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kjeld Borch Egevang Message-Id: <9305241826.AA23179@sony.craynet.dk> Subject: experimental network To: Big-Internet mailing list Date: Mon, 24 May 1993 19:26:16 +0100 (WET DST) Organization: Cray Networks A/S - Denmark X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 289 X-Charset: ASCII X-Char-Esc: 29 I believe I read somewhere that 89.0.0.0 was reserved as an experimental network. Can anybody confirm this? -- Kjeld Borch Egevang kbe@craynet.dk Research & Development Voice: +45 44530100 Cray Networks A/S - Denmark Fax: +45 44531415   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03127; 24 May 93 17:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03123; 24 May 93 17:32 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa18760; 24 May 93 17:32 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18365; Tue, 25 May 1993 06:47:06 +1000 (from owner-Big-Internet) Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18360; Tue, 25 May 1993 06:46:58 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA02032); Mon, 24 May 93 15:46:52 CDT Received: by sabine.is.rice.edu (AA01711); Mon, 24 May 93 15:46:51 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Manning Message-Id: <9305242046.AA01711@sabine.is.rice.edu> Subject: Re: experimental network To: Kjeld Borch Egevang Date: Mon, 24 May 93 15:46:50 CDT Cc: Big-Internet@munnari.oz.au In-Reply-To: <9305241826.AA23179@sony.craynet.dk>; from "Kjeld Borch Egevang" at May 24, 93 7:26 pm X-Mailer: ELM [version 2.3 PL11] Kjeld Borch Egevang > > I believe I read somewhere that 89.0.0.0 was reserved as an experimental > network. Can anybody confirm this? > Don't know for sure about that one. 192.0.2.0 has been reserved for that purpose by IANA though. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19986; 26 May 93 22:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19982; 26 May 93 22:33 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa02920; 26 May 93 22:33 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15438; Thu, 27 May 1993 11:35:49 +1000 (from owner-big-internet) Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03375; Thu, 27 May 1993 07:38:56 +1000 (from dee@skidrow.ljo.dec.com) Received: by inet-gw-2.pa.dec.com; id AA25234; Wed, 26 May 93 14:38:50 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA24281 for Big-Internet@munnari.OZ.AU; Wed, 26 May 93 17:39:57 -0400 Message-Id: <9305262139.AA24281@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Kjeld Borch Egevang Cc: Big-Internet mailing list Subject: Re: experimental network In-Reply-To: Your message of "Mon, 24 May 93 19:26:16 BST." <9305241826.AA23179@sony.craynet.dk> Date: Wed, 26 May 93 17:39:57 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: kbe@sony.craynet.dk (Kjeld Borch Egevang) To: Big-Internet@munnari.OZ.AU (Big-Internet mailing list) Organization: Cray Networks A/S - Denmark >I believe I read somewhere that 89.0.0.0 was reserved as an experimental >network. Can anybody confirm this? 192.0.2.* is assigned for experimental use only and in general routers (unless they are involved in the experiment) are justified is dropping any packed addressed to that net. The last domain name survey found the following hosts in 89.*.*.*: 89.0.0.1 tgateway.nat.com 89.0.0.111 brg1.nat.com 89.0.0.112 brg2.nat.com 89.0.0.125 mtr5.nat.com 89.0.0.157 rb9d.nat.com 89.0.0.209 mtr.nat.com 89.0.0.209 rarpmtr.nat.com 89.0.0.219 natbrg.nat.com 89.0.0.220 engsvrbrg.nat.com 89.0.0.221 nat0.nat.com 89.0.0.224 mtr1.nat.com 89.0.0.226 mtr2.nat.com 89.0.0.227 mtr3.nat.com 89.0.0.228 colmtr.nat.com 89.0.0.233 mtr4.nat.com 89.0.0.240 rbf0.nat.com 89.0.0.251 brg.nat.com 89.0.0.252 trbg1.nat.com 89.0.0.3 tmpbrg.nat.com 89.0.0.44 opus.as.utexas.edu 89.0.0.49 engmtr.nat.com 89.0.0.67 rb43.nat.com 89.0.0.69 rb45.nat.com 89.0.0.70 rb46.nat.com 89.0.1.100 mtr164.nat.com 89.0.1.100 natmeter.nat.com 89.0.1.101 aphpa150.nat.com 89.0.1.110 tstmtr.nat.com 89.0.1.43 rb12b.nat.com 89.0.1.72 rb148.nat.com 89.0.13.111 dupbrg.nat.com 89.0.2.1 ice250.nat.com 89.0.2.2 rand.nat.com 89.0.255.255 tmpnode.nat.com 89.0.3.250 engsalebrg.nat.com 89.0.4.25 bbb.nat.com 89.0.4.25 lobrg.nat.com 89.0.5.209 mmtr.nat.com 89.0.83.111 dupmtr.nat.com 89.0.85.95 natrt.nat.com 89.0.9.12 capture.nat.com 89.1.4.1 b250.nat.com 89.111.0.40 rmeng.nat.com 89.111.12.20 c3po.nat.com 89.111.22.22 jedi.nat.com 89.144.0.232 rmeter1.nat.com 89.144.0.99 remotemtr.nat.com 89.16.32.53 austin.practic.com 89.160.1.30 mtr109.nat.com 89.168.0.131 alpha250.nat.com 89.168.0.181 b155.nat.com 89.168.0.221 alpha155.nat.com 89.168.0.34 v230x.nat.com 89.22.33.44 tbrg2.nat.com 89.254.254.1 rt.nat.com 89.254.254.2 rt2.nat.com 89.3.10.7 ilc250.nat.com 89.7.254.1 henry.nat.com 89.7.254.10 simon.nat.com 89.7.254.11 mitchell.nat.com 89.7.254.12 phil.nat.com 89.7.254.13 ldyer.nat.com 89.7.254.14 cheng.nat.com 89.7.254.15 shu.nat.com 89.7.254.16 bille.nat.com 89.7.254.17 jimh.nat.com 89.7.254.18 dicks.nat.com 89.7.254.19 test1.nat.com 89.7.254.2 yang.nat.com 89.7.254.20 test2.nat.com 89.7.254.21 test3.nat.com 89.7.254.22 test4.nat.com 89.7.254.23 ram.nat.com 89.7.254.25 jeffc.nat.com 89.7.254.250 mftlab.nat.com 89.7.254.254 d135.nat.com 89.7.254.26 ernie.nat.com 89.7.254.27 celeste.nat.com 89.7.254.28 cindy.nat.com 89.7.254.29 jennifer.nat.com 89.7.254.3 david.nat.com 89.7.254.30 ashan.nat.com 89.7.254.31 toshiko.nat.com 89.7.254.32 audrey.nat.com 89.7.254.33 davidl.nat.com 89.7.254.34 holly.nat.com 89.7.254.35 jean.nat.com 89.7.254.36 mike.nat.com 89.7.254.37 janique.nat.com 89.7.254.38 bon.nat.com 89.7.254.39 doris.nat.com 89.7.254.4 ycw.nat.com 89.7.254.40 susan.nat.com 89.7.254.41 harvey.nat.com 89.7.254.42 billp.nat.com 89.7.254.43 billc.nat.com 89.7.254.44 homer.nat.com 89.7.254.46 lissu.nat.com 89.7.254.5 maurice.nat.com 89.7.254.6 hanna.nat.com 89.7.254.7 honda.nat.com 89.7.254.8 jane.nat.com 89.7.254.9 constance.nat.com 89.7.7.7 i960.nat.com 89.7.8.9 apollo.nat.com >-- >Kjeld Borch Egevang kbe@craynet.dk >Research & Development Voice: +45 44530100 >Cray Networks A/S - Denmark Fax: +45 44531415 Donald   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22087; 26 May 93 23:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22083; 26 May 93 23:17 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa03701; 26 May 93 23:17 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17771; Thu, 27 May 1993 12:27:49 +1000 (from owner-Big-Internet) Received: from world.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17766; Thu, 27 May 1993 12:27:27 +1000 (from ariel@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA25599; Wed, 26 May 1993 22:27:21 -0400 Date: Wed, 26 May 1993 22:27:21 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert L Ullmann Message-Id: <199305270227.AA25599@world.std.com> To: big-internet@munnari.oz.au, staff@world.std.com Hi, As I said previously, the IPv7 project is now named TP/IX, its original name 5 years ago. (pronounced TEE-PICKS, in case that wasn't obvious :-) The mail list is now: tpix@world.std.com to subscribe, send to tpix-request@world.std.com The ipv7 address still works, but not ipv7-request or owner-ipv7. The archive is world.std.com:/pub/tpix/... and, of course, the ipv7 path still works. The TP/IX working group charter is on the IESG agenda, awaiting a final decision. If you have any items for the Amsterdam agenda, please send a note to me or the tpix list. Aside: in case you are wondering why the list and archive are based on World, and not some system at Process Software; the answer is real simple: World is an AWESOME service provider, and it is both easier and more cost-effective to use it than to do it ourselves. (Yes, you read that right: MORE CHEAPER.) This shows, BTW, that commercial networking is coming into its own; it ought to be less expensive to buy services than to do them yourselves. After all, we rent green plants, and pay people to vacuum the carpets; why not pay someone to run anon-FTP and mail on a 24x7 basis? It is MUCH more cost effective than having anyone on staff at Process have to spend time on it. (But just watch: STD will raise my rates now ... ;-) Of course, this is just dissembling (though true); the real reason is that most people read world.std.com as World Standard (for) Computing. (STD = "Software Tool & Die") Best Regards, Robert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00698; 27 May 93 3:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00694; 27 May 93 3:32 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa01703; 27 May 93 3:32 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28606; Thu, 27 May 1993 16:28:11 +1000 (from owner-Big-Internet) Received: from oliveb.ATC.Olivetti.Com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28597; Thu, 27 May 1993 16:27:22 +1000 (from roode@arezzo.oas.olivetti.com) Received: by oliveb.ATC.Olivetti.Com (5.65/1.34) id AA14579; Wed, 26 May 93 23:27:02 -0700 Received: by oliveb.ATC.Olivetti.Com (5.51/smail2.5/12-18-87) id AA14576; Wed, 26 May 93 23:26:59 PDT Received: by arezzo.oas.olivetti.com (4.1/SMI-3.2) id AA00877; Wed, 26 May 93 23:26:54 PDT Date: Wed, 26 May 93 23:26:53 BST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Roode To: dee@skidrow.ljo.dec.com Cc: Kjeld Borch Egevang , Big-Internet mailing list Subject: Re: experimental network In-Reply-To: Your message of Wed, 26 May 1993 14:39:57 -0700 Message-Id: Interesting, because the Internic network number registry lists class A 89 as being unassigned and reserved: whois -h rs.internic.net 89.0.0.0 IANA (RESERVED-7) Netname: Reserved Netblock: 64.0.0.0 - 95.0.0.0 Coordinator: Reynolds, Joyce K. (JKR1) JKRey@ISI.EDU (310) 822-1511 Record last updated on 03-Apr-92. The InterNIC Registration Services Host ONLY contains Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01077; 27 May 93 4:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01073; 27 May 93 4:32 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa02604; 27 May 93 4:32 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01890; Thu, 27 May 1993 17:37:39 +1000 (from owner-Big-Internet) Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01880; Thu, 27 May 1993 17:37:11 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA05233; Thu, 27 May 93 00:36:52 -0700 Date: Thu, 27 May 93 0:36:51 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vince Fuller To: David Roode Cc: dee@skidrow.ljo.dec.com, Kjeld Borch Egevang , Big-Internet mailing list Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: experimental network In-Reply-To: Your message of Wed, 26 May 93 23:26:53 BST Message-Id: Interesting, because the Internic network number registry lists class A 89 as being unassigned and reserved: whois -h rs.internic.net 89.0.0.0 IANA (RESERVED-7) Netname: Reserved Netblock: 64.0.0.0 - 95.0.0.0 Look closer - ALL of the class-A's above 63 are reserved. --Vince   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01698; 27 May 93 6:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01694; 27 May 93 6:59 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa04864; 27 May 93 6:59 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08394; Thu, 27 May 1993 20:16:55 +1000 (from owner-Big-Internet) Message-Id: <9305271016.8394@munnari.oz.au> Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08390; Thu, 27 May 1993 20:16:44 +1000 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (16.8/16.2) id AA07465; Thu, 27 May 93 20:16:40 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Darren Reed Subject: Re: experimental network To: big-internet@munnari.oz.au Date: Thu, 27 May 1993 20:16:40 +1000 (EST) In-Reply-To: from "Vince Fuller" at May 27, 93 00:36:51 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 483 > > Interesting, because the Internic network number registry lists class A > 89 as being unassigned and reserved: > > whois -h rs.internic.net 89.0.0.0 > IANA (RESERVED-7) > > Netname: Reserved > Netblock: 64.0.0.0 - 95.0.0.0 > > Look closer - ALL of the class-A's above 63 are reserved. Does anyone know why this was done ? Other class A's are also reserved.... 10.0.0.0 (old .arpa network) is just one other I have noticed... Darren   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05049; 27 May 93 9:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05045; 27 May 93 9:29 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa09405; 27 May 93 9:29 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13387; Thu, 27 May 1993 22:44:17 +1000 (from owner-Big-Internet) Received: from dkuug.dk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13323; Thu, 27 May 1993 22:43:47 +1000 (from kbe@sony.craynet.dk) Received: from mips.uucp by dkuug.dk with UUCP id AA02780 (5.65c8/IDA-1.4.4j for Big-Internet@munnari.OZ.AU); Thu, 27 May 1993 14:43:22 +0200 Received: from sony by craynet.dk (5.61/SMI-4.1) id AA16896; Thu, 27 May 93 15:41:26 +0200 Received: by sony.craynet.dk (4.0/SMI-4.1) id AA05600; Thu, 27 May 93 14:41:25 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kjeld Borch Egevang Message-Id: <9305271341.AA05600@sony.craynet.dk> Subject: Internet Draft on NAT To: Big-Internet mailing list Date: Thu, 27 May 1993 14:41:25 +0100 (WET DST) Organization: Cray Networks A/S - Denmark X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2126 X-Charset: ASCII X-Char-Esc: 29 In the January issue of ACM SIGCOMM, Computer Communication Review, Paul Francis (formerly Tsuchiya) and Tony Eng had an article about IP NAT. NAT refers to Network Address Translators, a topic that has been discussed a lot on this mailing-list. It seems NAT has been reinvented several times, so no surprise: I invented it too. I wrote to Paul and asked him if he would put out an RFC. He said he didn't have time and suggested me to do it. I think the idea deserves to get out to more people, so, I've written an Internet Draft, based on Paul's article. You can get it as big-internet/IP-NAT on munnari.OZ.AU [128.250.1.21]. Here's the abstract: "The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses. It is possible that CIDR will not be adequate to maintain the IP internet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons." -- Kjeld Borch Egevang kbe@craynet.dk Research & Development Voice: +45 44530100 Cray Communications A/S - Denmark Fax: +45 44531415   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14672; 27 May 93 17:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14668; 27 May 93 17:26 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa26122; 27 May 93 17:26 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01325; Fri, 28 May 1993 06:40:18 +1000 (from owner-big-internet) Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22696; Fri, 28 May 1993 02:53:47 +1000 (from dee@skidrow.ljo.dec.com) Received: by inet-gw-2.pa.dec.com; id AA00844; Thu, 27 May 93 09:50:13 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA26795 for big-internet@munnari.oz.au; Thu, 27 May 93 12:51:17 -0400 Message-Id: <9305271651.AA26795@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Darren Reed Cc: big-internet@munnari.oz.au Subject: Re: experimental network In-Reply-To: Your message of "Thu, 27 May 93 20:16:40 +1000." <9305271016.8394@munnari.oz.au> Date: Thu, 27 May 93 12:51:17 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: Darren Reed To: big-internet@munnari.oz.au In-Reply-To: from "Vince Fulle r" at May 27, 93 00:36:51 am >> Interesting, because the Internic network number registry lists class A >> 89 as being unassigned and reserved: >> >> whois -h rs.internic.net 89.0.0.0 >> IANA (RESERVED-7) >> >> Netname: Reserved >> Netblock: 64.0.0.0 - 95.0.0.0 >> >> Look closer - ALL of the class-A's above 63 are reserved. > >Does anyone know why this was done ? I remember seeing something from the IAB or IESG saying they were reserving half of the Class A space in case they were needed as a transition resource in connection with the exhaustion of the IP address space. The idea would be that they could be used by some kind of dynamic address translations scheme where IP addresses in that range were temporarily bound to some IPng address. >Other class A's are also reserved.... 10.0.0.0 (old .arpa network) is >just one other I have noticed... > >Darren Donald   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01019; 28 May 93 4:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01015; 28 May 93 4:41 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa02944; 28 May 93 4:41 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27893; Fri, 28 May 1993 17:25:04 +1000 (from owner-Big-Internet) Received: from lux.levels.unisa.edu.au (via mulga) by munnari.oz.au with SunIII (5.83--+1.3.1+0.50) id AA27882; Fri, 28 May 1993 17:24:50 +1000 (from ccdps%lux.levels.unisa.edu.au@lux.levels.unisa.edu.au) Received: by lux.levels.unisa.edu.au (4.1/SMI-4.1) id AA09497 for big-internet@munnari.oz Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Shearer Message-Id: <9302160320.AA09497@lux.levels.unisa.edu.au> Subject: Big Internet To: big-internet@munnari.oz.au Date: Tue, 16 Feb 1993 13:50:26 +1030 (GMT+1030) X-Mailer: ELM [version 2.4 PL6] Content-Type: text Content-Length: 544 After numerous attempts to get off this list with the -request address, I am in desperation posting to the list itself. Please please please please pretty-please remove me. Like the previous poster I am willing to ascribe every possible virtue to the contributers and maintainers of this list, so long as I get off it. :-) Kindest regards, -- Dan Shearer email: Dan.Shearer@UniSA.edu.au Information Technology Branch Phone: +61 8 302 3479 University of South Australia Fax : +61 8 302 3385   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02962; 28 May 93 8:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02958; 28 May 93 8:47 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa07637; 28 May 93 8:47 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08236; Fri, 28 May 1993 21:37:52 +1000 (from owner-big-internet) Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20158; Fri, 28 May 1993 14:20:15 +1000 (from VALDIS@vtvm1.cc.vt.edu) Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 2474; Fri, 28 May 93 00:19:54 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.10 ptf000) with BSMTP id 0963; Fri, 28 May 93 00:19:53 EDT Date: Fri, 28 May 93 00:16:55 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: experimental network To: Darren Reed Cc: big-internet@munnari.oz.au In-Reply-To: <9305271651.AA26795@skidrow.ljo.dec.com> Message-Id: <930528.001655.EDT.VALDIS@vtvm1.cc.vt.edu> On Thu, 27 May 93 12:51:17 -0400 you said: > Interesting, because the Internic network number registry lists class A > 89 as being unassigned and reserved: > > whois -h rs.internic.net 89.0.0.0 > IANA (RESERVED-7) > > Look closer - ALL of the class-A's above 63 are reserved. Is anybody besides me feeling just a *little* concerned that ZEALOT (or whatever they call the DNS walker) found a bunch of .com nodes in a reserved net? Do you suppose these people are in for a surprise? Or are we for thinking the space is reserved? Are there any *other* "reserved" net with squatters in them? Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11149; 28 May 93 14:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11145; 28 May 93 14:04 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa17780; 28 May 93 14:04 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22761; Sat, 29 May 1993 03:23:21 +1000 (from owner-Big-Internet) Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22756; Sat, 29 May 1993 03:23:04 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 28 May 93 13:22:58 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 28 May 93 13:22:56 EDT Date: Fri, 28 May 93 13:22:56 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Message-Id: <9305281722.AA07959@tsuchiya.bellcore.com> To: big-internet@munnari.oz.au Subject: Re: Internet Draft on NAT I want to mention that the main reason Kjeld and I have put out this draft at this time is not because we propose to replace CIDR, but because Kjeld has implemented it (independent of my previous work....) and so now there is something to play with. I have considered NAT something of last-ditch fix for the case where we don't have an IPng before CIDR crashes. I think Kjeld has more confidence in NAT than that, however, which is interesting since he built it and is running it. Anyway, I think it would be good if we have experience with NAT just in case we *need* to use it, if for no other reason. PX ps. A description from Kjeld on his implementation is attached. ____________ It is not a product (yet), just a little experiment I made when I had some spare time. I implemented it in our remote routers equipped with an R33000 and 4 MByte RAM. The router has 5 slots where you can have several kinds of cards. We have Ethernet, X21, V24, V35, V36 and Token Ring (maybe a few more I haven't worked with). The setup I made looked like this: +---+ V.24 zero-modem cable +---+ |RT1|-----------------------|RT2| +---+ ^ NAT here +---+ | | ============== ============== | 89.0.0.0 | 156.13.0.0 (simulates global net) | | +-+ +-+ +-+ +-+ /___\ PC running FTP /___\ PC running FTPD I translate addresses on the WAN line so I don't have to deal with ARP. If you switch who is running FTP (client) and FTPD (server) you don't have to translate PORT commands.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16850; 26 May 93 18:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16846; 26 May 93 18:23 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa27833; 26 May 93 18:23 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02124; Thu, 27 May 1993 07:16:53 +1000 (from owner-Big-Internet) Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02115; Thu, 27 May 1993 07:16:36 +1000 (from news@freenet.carleton.ca) Received: from freenet.carleton.ca by ux1.cso.uiuc.edu with SMTP id AA23697 (5.67a8/IDA-1.5 for ); Wed, 26 May 1993 16:16:12 -0500 Received: by freenet.carleton.ca (4.1/SMI-4.0) id AA03463; Wed, 26 May 93 17:15:49 EDT Newsgroups: info.big-internet Path: Freenet.carleton.ca!aa158 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Les Casey Subject: Bombing Run Message-Id: X-Orig-Sender: News Administrator Organization: National Capital Freenet, Ottawa, Canada Date: Wed, 26 May 1993 21:15:44 GMT Lines: 12 Apparently-To: info-big-internet@ux1.cso.uiuc.edu Problem: I have a mailing list of approx. 30 people that I wish to send email to, but not let each person know who else is on my list. Presently, I use the "cc:" feature, but this lists all of the others who receive the same email message. I think the feature I am looking for is called a "bombing run". Any suggestions? -- y