From owner-Big-Internet@munnari.oz.au Mon Jun 1 04:01:54 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12468; Mon, 1 Jun 1992 04:02:02 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9205311802.12468@munnari.oz.au> Received: from MC8.MACH.CS.CMU.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12465; Mon, 1 Jun 1992 04:01:54 +1000 (from Christopher.Maeda@MC8.MACH.CS.CMU.EDU) From: Christopher Maeda Date: Sun, 31 May 92 14:01:42 EDT To: rayan@cs.toronto.edu Cc: Big-Internet@munnari.OZ.AU Subject: Comparison of rfc1335 with supernetting proposal Reply-To: cmaeda@cs.cmu.edu From: rayan@cs.toronto.edu Dynamic address assignment is vile! In other words, if I'm snooping on the wire, I need to know exactly which addresses correspond to which hosts at all times, at both ends Forced access control is what keeps big bureaucracies going. It has no place in the Internet society [sic]. Can you please be less precise? From owner-Big-Internet@munnari.oz.au Tue Jun 2 08:35:25 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA23030; Tue, 2 Jun 1992 08:35:47 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA23025; Tue, 2 Jun 1992 08:35:25 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA09139; Mon, 1 Jun 92 15:34:32 -0700 Date: Mon, 1 Jun 92 14:38:53 EDT From: "William Allen Simpson" Message-Id: <377.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: T > From: kasten@europa.clearpoint.com (Frank Kastenholz) > > From P.Tsuchiya@cs.ucl.ac.uk Thu May 28 02:59:57 1992 > > > > > > +--------+--------+-------------------------+ > > > |Protocol|HopCount| Handling Directive | > > > +--------+--------+-------------------------+ > > > > Why is the above easier to parse than: > > > > +--------+---------------------+----------+ > > |Protocol| Handling Directive | HopCount | > > +--------+---------------------+----------+ > > my only answer is gut feeling. i do not like splitting the > HD across 16-bit boundaries. taking what could be treated > as a 16 bit number (the HD) and splitting it across a 16 > bit boundary just feels wrong. i do not know why. i can't > prove it. > Some of us have implemented on 16-bit processors. Having 16-bit fields split across 16-bit boundaries is a real pain! Let's keep 8 bit fields on 8-bit boundaries, 16-bit on 16-bit boundaries, etc, etc. Sometimes this is impractical (32-bit values with a preceeding 8-bit code and 8-bit length, for example), but that is not the case here. But, I like the concept of simple decrement of the HopCount, so an additional rule of "put frequently modified fields in the low order of 32-bit boundaries" would seem useful, yielding: +----------------------+--------+--------+ | Handling Directive |Protocol|HopCount| +----------------------+--------+--------+ > should be 4, 8, 16, 32, ... bits long, but the important element > is to have a way of changing things in "our" protocol without > having to go to someone else (e.g. IEEE for enet) and get > another type number for the "new" version.... > There was plenty of relevant experience within PPP. The OSI and DECnet protocols are encapsulated within a single protocol number, so that those groups can assign thier numbers independently. This was an attempt to avoid many fights (some of which are still going on). Speaking of PPP, also remember that there are nearly as many organizations to get numbers from as there are link-layer encapsulations. As the experiment goes on, this could be quite time-consuming. Remember that the IP versions 5 & 6 were already "stolen" to avoid having to get new enet numbers. > > I thought about this quite a bit. The thing I don't like about > > encapsulating goes back to ATM. If you encapsulate, then you have to > > create a bunch of new cells on the fly and stick them in front of your > > current stream. In general (ATM or not), it is very quick and easy to > > set the Tunnel field vs. creating a new header. Other opinions? > > this is true. but on the otherhand, what is the 90% case? i imagine > that more packets will not be tunneled than will be tunneled. if i > correctly understand the parts of the spec that i have read, the > tunneling will basically be done only for packets that are > crossing domains, etc, etc. i imagine that more packets stay > within a domain than leave it. thus, relative to the number of > pip packets generated in the world, tunneled ones will be rare > (though quite common in things like backbones). > And tunneled packets will probably have other header modifications at the same time, so generating/stripping an outer header before queuing may actually be easier/faster than mucking with fields within the header (just move a pointer). My vote would be separate tunnelling headers. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Wed Jun 3 00:14:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20384; Wed, 3 Jun 1992 00:14:41 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20381; Wed, 3 Jun 1992 00:14:38 +1000 (from kre) To: big-internet@munnari.oz.au From: Big-Internet-Request@munnari.oz.au Subject: New NSFnet numbers predictions from Frank Date: Wed, 03 Jun 92 00:14:31 +1000 Message-Id: <10057.707494471@munnari.oz.au> Sender: kre@munnari.oz.au ------- Forwarded Message From: solensky@animal.clearpoint.com (Frank T. Solensky) Date: Mon, 1 Jun 92 15:09:06 EDT To: kre@munnari.oz.au Subject: New logistic graph Robert -- I just ftp'd a new postscript graph of the NSFNet growth rates, using data as recent as last Friday AM. As before, it consists of two graphs: the first is the actual data and projected best-fit using a logistic curve, the second is a time series of where the curve maxes out each month: it's now at 15,208 nets (as compared to 10158 nets in March and 4923 nets last November: the actual number of nets has already exceeded that level by almost 600). -- Frank ------- End of Forwarded Message The postscript file (10206 bytes) is available in the big-internet directory on munnari.oz.au [128.250.1.21] Its name is nsf-netnumbers-9206.ps I have renamed the previous file from "pix.ps", which was a little under-informative, to nsf-netnumbers-9203.ps kre From owner-Big-Internet@munnari.oz.au Wed Jun 3 01:05:55 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21568; Wed, 3 Jun 1992 01:06:06 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206021506.21568@munnari.oz.au> Received: from MC8.MACH.CS.CMU.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA21558; Wed, 3 Jun 1992 01:05:55 +1000 (from Christopher.Maeda@MC8.MACH.CS.CMU.EDU) From: Christopher Maeda Date: Tue, 2 Jun 92 11:05:12 EDT To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au In-Reply-To: William Allen Simpson's message of Mon, 1 Jun 92 14:38:53 EDT <377.bsimpson@angband.stanford.edu> Subject: T Reply-To: cmaeda@cs.cmu.edu Date: Mon, 1 Jun 92 14:38:53 EDT From: William Allen Simpson Reply-To: bsimpson@angband.stanford.edu > From: kasten@europa.clearpoint.com (Frank Kastenholz) > > From P.Tsuchiya@cs.ucl.ac.uk Thu May 28 02:59:57 1992 > > > > > > +--------+--------+-------------------------+ > > > |Protocol|HopCount| Handling Directive | > > > +--------+--------+-------------------------+ > > > > Why is the above easier to parse than: > > > > +--------+---------------------+----------+ > > |Protocol| Handling Directive | HopCount | > > +--------+---------------------+----------+ > > my only answer is gut feeling. i do not like splitting the > HD across 16-bit boundaries. taking what could be treated > as a 16 bit number (the HD) and splitting it across a 16 > bit boundary just feels wrong. i do not know why. i can't > prove it. > Some of us have implemented on 16-bit processors. Having 16-bit fields split across 16-bit boundaries is a real pain! I'm currently implementing tcp/ip on a 32bit risc chip (mips r3000). Having any 16 or 32 bit field not aligned on a 16 or 32 bit boundary makes the protocol extremely hard to do. This is because the mips chip has separate instructions for aligned and unaligned loads and stores. If you use the aligned load to load an unaligned address, you take a hardware exception. ANSI C requires pointers to structures to be aligned so it's perfectly legal for C compilers to ignore the unaligned case. From owner-Big-Internet@munnari.oz.au Wed Jun 3 01:24:57 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22002; Wed, 3 Jun 1992 01:25:22 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA21992; Wed, 3 Jun 1992 01:24:57 +1000 (from kre) To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au Subject: Re: T In-Reply-To: Your message of Mon, 01 Jun 92 14:38:53 -0400. <377.bsimpson@angband.stanford.edu> Date: Wed, 03 Jun 92 01:24:47 +1000 Message-Id: <10095.707498687@munnari.oz.au> From: Robert Elz Date: Mon, 1 Jun 92 14:38:53 EDT From: "William Allen Simpson" Message-ID: <377.bsimpson@angband.stanford.edu> But, I like the concept of simple decrement of the HopCount, so an additional rule of "put frequently modified fields in the low order of 32-bit boundaries" would seem useful, yielding: Both this comment, and a comment in the PIP draft, assume that you're using big-endian processors. While I have no objection at all to mandating, or at least, greatly favouring, big-ended processors (the one true way), I'm kind of surprised that no-one has pointed that out before. In reply to that message, From: Christopher Maeda Date: Tue, 2 Jun 92 11:05:12 EDT (a message with no original message-id that I could find, tsk, tsk) ANSI C requires pointers to structures to be aligned so it's perfectly legal for C compilers to ignore the unaligned case. C also says nothing about padding between fields of a structure, so unless you have control of your compiler (in which case you can make it do whatever is appropriate - including unaligned loads without taking traps) you can't rely on C structs mapping into anything related very closely to a packet header. Correct, portable, analysis of byte streams in C just has to be done by considering the stream to be an unstructured array of bytes, then picking up the fields required. No - I don't do it that way either, I doubt almost anyone does, and I certainly would prefer (even insist on) fields being aligned on their natural boundaries, but if you're going to quote C rules in support of this, please use caution. kre From owner-Big-Internet@munnari.oz.au Thu Jun 4 00:24:01 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA29562; Thu, 4 Jun 1992 00:24:21 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206031424.29562@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA29555; Thu, 4 Jun 1992 00:24:01 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 3 Jun 1992 15:23:31 +0100 To: big-internet@munnari.oz.au Subject: Re: New NSFnet numbers predictions from Frank In-Reply-To: Your message of "Wed, 03 Jun 92 00:14:31 +0900." <10057.707494471@munnari.oz.au> Date: Wed, 03 Jun 92 15:23:13 +0100 From: Paul Tsuchiya > > Robert -- > I just ftp'd a new postscript graph of the NSFNet growth rates, > using data as recent as last Friday AM. As before, it consists of two > graphs: the first is the actual data and projected best-fit using a > logistic curve, the second is a time series of where the curve maxes out > each month: it's now at 15,208 nets (as compared to 10158 nets in > March and 4923 nets last November: the actual number of nets has already > exceeded that level by almost 600). > -- Frank > I just looked at that graph. The point at which the curve of allocated addresses gets steeper coincides exactly with the formation of the road group. Is it possible that the publicity concerning IP address space has created a run on the bank, or does the increase in slope represent a change in policy of the nic to assign multiple class C's in lieu of a single class B? PT From owner-Big-Internet@munnari.oz.au Thu Jun 4 03:09:57 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA03337; Thu, 4 Jun 1992 03:10:09 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA03330; Thu, 4 Jun 1992 03:09:57 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA00409; Wed, 3 Jun 92 13:06:11 EDT Date: Wed, 3 Jun 92 13:06:11 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206031706.AA00409@animal.clearpoint.com> To: P.Tsuchiya@cs.ucl.ac.uk Subject: Re: New NSFnet numbers predictions from Frank In-Reply-To: Mail from 'Paul Tsuchiya ' dated: Wed, 03 Jun 92 15:23:13 +0100 Cc: big-internet@munnari.oz.au >I just looked at that graph. The point at which the curve of allocated >addresses gets steeper coincides exactly with the formation of the road >group. Is it possible that the publicity concerning IP address space has >created a run on the bank, or does the increase in slope represent a >change in policy of the nic to assign multiple class C's in lieu of a >single class B? > >PT Though I haven't seen any hard numbers to confirm this, it appears to be the latter: the reports for additions to the database are including runs of similar contact addresses for consecutively numbered net numbers. -- Frank From owner-Big-Internet@munnari.oz.au Thu Jun 4 04:07:27 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA04453; Thu, 4 Jun 1992 04:07:32 +1000 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA04450; Thu, 4 Jun 1992 04:07:27 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA05763; Wed, 3 Jun 92 12:07:18 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA11742; Wed, 3 Jun 92 12:07:17 MDT Message-Id: <9206031807.AA11742@goshawk.lanl.gov> To: Paul Tsuchiya Cc: big-internet@munnari.oz.au Subject: Re: New NSFnet numbers predictions from Frank In-Reply-To: Your message of Wed, 03 Jun 92 15:23:13 +0100. <9206031424.29562@munnari.oz.au> Date: Wed, 03 Jun 92 12:07:17 MST From: peter@goshawk.lanl.gov Paul, The formation of the ROAD group also closely postdated some very large requests hitting the NIC and the NSF routing policy database maintainers. Most of these large requests are due to large entities using the Internet to interconnect sites, such as NCR. cheers, peter From owner-Big-Internet@munnari.oz.au Thu Jun 4 10:00:52 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12756; Thu, 4 Jun 1992 10:00:58 +1000 (from owner-Big-Internet) Return-Path: Received: from jatz.aarnet.edu.au by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12753; Thu, 4 Jun 1992 10:00:52 +1000 (from pte900@jatz.aarnet.edu.au) Received: by jatz.aarnet.edu.au id AA02740 (5.65+/IDA-1.3.5 for big-internet@munnari.oz.au); Thu, 4 Jun 92 10:00:00 +1000 Date: Thu, 4 Jun 92 10:00:00 +1000 From: Peter Elford Message-Id: <9206040000.AA02740@jatz.aarnet.edu.au> To: P.Tsuchiya@cs.ucl.ac.uk, solensky@animal.clearpoint.com Subject: Re: New NSFnet numbers predictions from Frank Cc: big-internet@munnari.oz.au >From: solensky@animal.clearpoint.com (Frank T. Solensky) > >>I just looked at that graph. The point at which the curve of allocated >>addresses gets steeper coincides exactly with the formation of the road >>group. Is it possible that the publicity concerning IP address space has >>created a run on the bank, or does the increase in slope represent a >>change in policy of the nic to assign multiple class C's in lieu of a >>single class B? >> >>PT > >Though I haven't seen any hard numbers to confirm this, it appears to be >the latter: the reports for additions to the database are including runs >of similar contact addresses for consecutively numbered net numbers. In my experience acting as a conduit for number requests in this country, this is certainly a factor. Geoff (Huston) suggested another very likely source of growth; the very rapid deployment of IP technology outside the US. Essentially what is happening is the 10-odd years of IP growth within the US is being compressed into 12-18 months of growth in Europe, the Pacific, etc. (since we don't have to develop anything - we just buy it off the shelf). No doubt the (un)fortunate demise of the OSI suite (in Europe particularly) is also fuelling the demand for IP numbers ... Peter Elford, AARNet From owner-Big-Internet@munnari.oz.au Thu Jun 4 18:23:23 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA27388; Thu, 4 Jun 1992 18:23:37 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206040823.27388@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA27381; Thu, 4 Jun 1992 18:23:23 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Jun 1992 09:22:25 +0100 To: rrv@cody.cso.uiuc.edu (Ross Veach) Cc: big-internet@munnari.oz.au Subject: Re: RFC1335 on Two-Tier Address Structure for the Internet In-Reply-To: Your message of "Wed, 03 Jun 92 07:48:43 CDT." <9206031248.AA35027@cody.cso.uiuc.edu> Date: Thu, 04 Jun 92 09:21:57 +0100 From: Paul Tsuchiya > > Now, has anyone looked into where we would be if we applied PT's algorithm > for allocating variable length subnets (RFC 1219) to the entire IP address > space? Seed that algorithm assuming that all host bits of all allocated > network numbers are used, how much address space is still left? > You can't apply it to the whole IP address space, because 1219 works only in the context of 2 levels of hierarchy. At more than two levels, it becomes kampai, which causes you to end up with non-contiguous masks. It might be useful to consider using 1219 twice over, once at the subnet-host boundary, and once at the backbone-network boundary, assuming that we start doing backbone-oriented address assignment as discussed in the Rehkter/Li I-D (draft-rekhter-ipaddress-guide-00.txt). The thing is, I don't think the win of using 1219 at the backbone-network boundary is all that great, because, as mentioned in the I-D, the gains in aggregation diminish as you go up the hierarchy. I would be nice if you could do 1219 once at the subnet-host boundary, and once at the network-subnet boundary, but this doesn't work. PT From owner-Big-Internet@munnari.oz.au Fri Jun 5 03:50:29 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12260; Fri, 5 Jun 1992 03:50:45 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12257; Fri, 5 Jun 1992 03:50:29 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA07881; Thu, 4 Jun 92 10:50:16 -0700 Received: by us1rmc.mso.dec.com; id AA04826; Thu, 4 Jun 92 13:48:01 -0400 Message-Id: <9206041748.AA04826@us1rmc.mso.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 4 Jun 92 13:48:02 EDT Date: Thu, 4 Jun 92 13:48:02 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 04-Jun-1992 1350" To: p.elford@aarnet.edu.au, p.tsuchiya@cs.ucl.ac.uk, solensky@animal.clearpoint.com Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, solensky@animal.clearpoint.com, p.tsuchiya@cs.ucl.ac.uk, p.elford@aarnet.edu.au Subject: C#, ROAD Hi, (1) I have looked at the C# draft and I think it is an excellent proposal to gain breathing room while coming up with IP7 or whatever. What would be the best thing to do to expedite its adoption? Should I send an encouraging message to the IETF mailing list? I expect to be at the upcoming IETF gathering in Cambridge. Would there be something particularly beneficial to C# to do there? (2) I have seen various references to the ROAD group. Is there a mailing list I can get on or is this a closed group? Donald From owner-Big-Internet@munnari.oz.au Fri Jun 5 04:35:14 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13702; Fri, 5 Jun 1992 04:35:36 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13692; Fri, 5 Jun 1992 04:35:14 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA00349; Thu, 4 Jun 92 14:27:57 EDT Date: Thu, 4 Jun 92 14:27:57 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206041827.AA00349@animal.clearpoint.com> To: dee@ranger.enet.dec.com Subject: Re: C#, ROAD In-Reply-To: Mail from '"Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 04-Jun-1992 1350" ' dated: Thu, 4 Jun 92 13:48:02 EDT Cc: big-internet@munnari.oz.au, p.elford@aarnet.edu.au, p.tsuchiya@cs.ucl.ac.uk >(1) I have looked at the C# draft and I think it is an excellent proposal to >gain breathing room while coming up with IP7 or whatever. You may want to also get a copy of the supernetting proposal that was created by some of the people in the ROAD group ("draft-fuller-supernet-00.txt" on nri.reston.va.us, directory internet-drafts: I think the one on munnari.oz.au is an earlier draft). Basically, this includes an approach to deal with the problems associated with the growing size of the routing tables by aggregating routing updates with BGP. >What would be the best thing to do to expedite its adoption?.. I _believe_ that the current status is that IESG has picked someone to study the issue (if the two proposals are an either/or decision to be made; if so, which of the two better, uh, addresses the issue; etc.) Can someone with more authoritative info update the list if I'm wrong or has some knowledge when a recommendation is to be made? >(2) I have seen various references to the ROAD group. Is there a mailing >list I can get on or is this a closed group? The "ROuting and ADdressing" group was created as a result of some ideas that were formed within the BGP meeting at the Sante Fe IETF: these eventually became the supernetting proposal. The group was offically disbanded at San Diego and further discussion were directed towards this list.. -- Frank From owner-big-internet@munnari.oz.au Fri Jun 5 12:15:15 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26210; Fri, 5 Jun 1992 12:15:40 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20318; Fri, 5 Jun 1992 09:08:30 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA18644; Thu, 4 Jun 92 16:07:27 PDT Message-Id: <9206042307.AA18644@Mordor.Stanford.EDU> To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: RFC1335 Two-Tier Address -> Big Internet Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 04 Jun 92 09:08:24 +0100. <9206040808.AA12384@Mordor.Stanford.EDU> Date: Thu, 04 Jun 92 16:07:26 -0700 From: Dave Crocker Jon, Per yours and other suggestions, I'm responding on the big-internet list, primarily to pursue the larger issue I was trying to imply in my original note. Date: Thu, 04 Jun 92 09:08:24 BST To: Dave Crocker cc: ietf@ISI.EDU From: Jon Crowcroft Subject: RFC1335 Two-Tier Address -> Big Internet >current Internet architecture, I'd have to disagree with your >assessment. I think you *are* proposing a change to the architecture. >Also, your insistance that this is only interim causes me some concern, >due to the costs of installing *any* changes to Internet hosts and >routers. Dave, as i persist in saying, without change, the Internet _will_ still change in that it will abruptly stop growing and several modest organisations (like the UK NHS with 1 million employees) will be rather upset when they dont get access Please understand that I wasn't trying to criticise your proposal. My note was trying to challenge your _categorization of it_. You specify a permanent operational change to the service. I can't imagine viewing that as anything but architectural. Hence, the cost/benefit analysis of it ought to be in the larger context. My own suspicion is that any change we do that touches end-systems or interior routers _must_ be viewed as basic and long-term. The operational impact of making such changes is so large, given the current numbers of the installed base, that it probably is infeasible to accomplish anything in a short term. however, if you would prefer me to insist on the simplest proposal which, if we are prepared to Mandate change on 4-1-1993 would solve the problem for some time, it is to go for IP version 5, reusing the 16 bits of Identification as further address space... i mean, how many people actually change the IP packet when they retransmit and need the ID to help re-assemble? Cute idea. But I thought that a number of implementations _do_ change the ID field. Dave From owner-Big-Internet@munnari.oz.au Fri Jun 5 19:19:54 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA08176; Fri, 5 Jun 1992 19:20:02 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206050920.8176@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA08173; Fri, 5 Jun 1992 19:19:54 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Jun 1992 10:19:31 +0100 To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: RFC1335 Two-Tier Address -> Big Internet In-Reply-To: Your message of "Thu, 04 Jun 92 16:07:26 PDT." <9206042307.AA18644@Mordor.Stanford.EDU> Date: Fri, 05 Jun 92 10:19:04 +0100 From: Jon Crowcroft > however, if you would prefer me to insist on the simplest proposal > which, if we are prepared to Mandate change on 4-1-1993 would solve > the problem for some time, it is to go for IP version 5, reusing the > 16 bits of Identification as further address space... > i mean, how many people actually change the IP packet when they > retransmit and need the ID to help re-assemble? > >Cute idea. But I thought that a number of implementations _do_ change >the ID field. Dave in fact, they not only change it, but reassembly has to use it to match fragemnts from re-ordered packets...shame - i just looked at the code however, since fragementation is considered harmful, maybe we should say IP version 5 mandates for MTU discovery, and can reuse the ID, flags and fragment offset to increase the IP adress space, 16 bits for source, and 16 bit s for destination... then you can run almost unmodified code in hosts...maybe use the 16 bits for area addressing or something... jon hack hack hack... From owner-Big-Internet@munnari.oz.au Fri Jun 5 19:19:17 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA08170; Fri, 5 Jun 1992 19:19:27 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206050919.8170@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA08167; Fri, 5 Jun 1992 19:19:17 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Jun 1992 10:18:51 +0100 To: Dave Crocker Cc: Jon Crowcroft , big-internet@munnari.oz.au Subject: Re: RFC1335 Two-Tier Address -> Big Internet In-Reply-To: Your message of "Thu, 04 Jun 92 16:07:26 PDT." <9206042307.AA18644@Mordor.Stanford.EDU> Date: Fri, 05 Jun 92 10:18:27 +0100 From: Zheng Wang >My own suspicion is that any change we do that touches end-systems or >interior routers _must_ be viewed as basic and long-term. The operational >impact of making such changes is so large, given the current numbers of >the installed base, that it probably is infeasible to accomplish anything >in a short term. As a short-term solution, rfc1335 does not requre any changes to the existing networks. The networks that will be set up after we run out of class B may use this scheme (I agree it is unfair to them but is an option if they want a big internal network). Cheers Zheng From owner-Big-Internet@munnari.oz.au Sat Jun 6 00:25:39 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA15498; Sat, 6 Jun 1992 00:26:01 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206051426.15498@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA15495; Sat, 6 Jun 1992 00:25:39 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Jun 1992 15:23:57 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: RFC1335 Two-Tier Address -> Big Internet In-Reply-To: Your message of "Fri, 05 Jun 92 10:07:38 EDT." <9206051407.AA10447@ginger.lcs.mit.edu> Date: Fri, 05 Jun 92 15:23:32 +0100 From: Jon Crowcroft > Look, this a totally bogus idea. Using the ID field will not work Noel sure, you are right - i missed a ;-) PIP will do... jon From owner-Big-Internet@munnari.oz.au Sat Jun 6 01:51:41 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17497; Sat, 6 Jun 1992 01:51:46 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA17493; Sat, 6 Jun 1992 01:51:41 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA23016; Fri, 5 Jun 92 08:51:34 PDT Message-Id: <9206051551.AA23016@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: Re: RFC1335 Two-Tier Address -> Big Internet Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 05 Jun 92 10:18:27 +0100. <9206050919.AA20901@Mordor.Stanford.EDU> Date: Fri, 05 Jun 92 08:51:33 -0700 From: Dave Crocker Date: Fri, 05 Jun 92 10:18:27 BST From: Zheng Wang Subject: Re: RFC1335 Two-Tier Address -> Big Internet ... As a short-term solution, rfc1335 does not requre any changes to the existing networks. The networks that will be set up after we run out of class B may use this scheme (I agree it is unfair to them but is an option if they want a big internal network). There are a number of schemes which are likely to assist with very near-term difficulties. Some involve new backbone routing protocols, or changes to existing ones; some involve playing games with address assignment; and others involve address-mapping, either by algorithm or by table lookup. To the extent that they are invisible to the end-system networks and administrations, I suppose that their efficiency in operation and administration should be the base criteria. To the extent that any of them is to be applied for anything longer term, then I claim that they should in no way be viewed as short term and that their operational characteristics -- in particular the effort needed to conduct a transition and the feasibility of large-scale operation. The only experience that we have in large-scale mapping is the Domain Name Service. Many think it is a great success since we rely on it -- but deeper analysis of its operations suggests that puting such a service at a lower layer, given current implementation and operation experience -- looks very risky. Dave From owner-big-internet@munnari.oz.au Sat Jun 6 02:56:44 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19176; Sat, 6 Jun 1992 02:56:58 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA15182; Sat, 6 Jun 1992 00:08:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10447; Fri, 5 Jun 92 10:07:38 -0400 Date: Fri, 5 Jun 92 10:07:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206051407.AA10447@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, dcrocker@mordor.stanford.edu Subject: Re: RFC1335 Two-Tier Address -> Big Internet Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Look, this a totally bogus idea. Using the ID field will not work unless you change the interpretation of this field in the hosts which are generating the packets. (I.e. if the 32 bits of address set by an unmodified source host don't completely specify the destination, from where in the packet does some hypothetical intermediate 'packet-frobber' get the extra bits from?) If you are going to radically change the way the hosts handle IP packets (particularly the address fields, which are the heart of the whole protocol) why stick to the existing packet format (which has other problems)? Noel From owner-Big-Internet@munnari.oz.au Sat Jun 6 06:48:56 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA24737; Sat, 6 Jun 1992 06:49:12 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA24722; Sat, 6 Jun 1992 06:48:56 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA28993; Fri, 5 Jun 92 16:48:39 -0400 Message-Id: <9206052048.AA28993@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 5322; Fri, 05 Jun 92 16:46:52 EDT Date: 5 Jun 92 16:49:00 EDT To: From: Pierre (P.) Fortin Subject: IPn...? Sender: Pierre (P.) Fortin Please excuse my ignorance in this matter, but I see references to "IP7" and have to wonder if this is directly related to "IP version 4" which is the norm today. If so, what happened to IP5 and IP6? Are there any documents on IP[5-6]? Many thanks, Pierre Fortin fortinp@bnr.ca (613)763-2598 fax: (613)763-3283 From owner-Big-Internet@munnari.oz.au Sat Jun 6 07:31:41 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25786; Sat, 6 Jun 1992 07:31:57 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA25777; Sat, 6 Jun 1992 07:31:41 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA02310; Fri, 5 Jun 92 17:28:16 EDT Date: Fri, 5 Jun 92 17:28:16 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206052128.AA02310@animal.clearpoint.com> To: Pierre@animal.clearpoint.com, Subject: Re: IPn...? In-Reply-To: Mail from 'Pierre (P.) Fortin ' dated: 5 Jun 92 16:49:00 EDT >Please excuse my ignorance in this matter, but I see references to "IP7" and >have to wonder if this is directly related to "IP version 4" which is the >norm today. If so, what happened to IP5 and IP6? Are there any documents >on IP[5-6]? IPv6, more commonly know as ST-II, is the Experimental Internet Stream Protocol, version 2. It can be found in RFC 1190 (CIP Working Group, Claudio Topolcic, editor; Oct. 1990). It updates IPv5, ST, described in IEN-119 (Jim Forgie, 1979). From owner-Big-Internet@munnari.oz.au Sat Jun 6 07:37:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25898; Sat, 6 Jun 1992 07:37:52 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA25890; Sat, 6 Jun 1992 07:37:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14454; Fri, 5 Jun 92 17:37:24 -0400 Date: Fri, 5 Jun 92 17:37:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206052137.AA14454@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, FORTINP@bnr.ca Subject: Re: IPn...? Cc: jnc@ginger.lcs.mit.edu They are ST versions I and II. Noel From owner-Big-Internet@munnari.oz.au Sat Jun 6 08:00:16 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26444; Sat, 6 Jun 1992 08:00:24 +1000 (from owner-Big-Internet) Return-Path: Received: from venera.isi.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26436; Sat, 6 Jun 1992 08:00:16 +1000 (from postel@ISI.EDU) Received: from bel.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 5 Jun 1992 15:01:18 -0700 Date: Fri, 5 Jun 92 15:00:01 PDT From: postel@ISI.EDU Posted-Date: Fri, 5 Jun 92 15:00:01 PDT Message-Id: <9206052200.AA24890@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Fri, 5 Jun 92 15:00:01 PDT To: Big-Internet@munnari.oz.au Subject: Re: IPn...? From "Assigned Numbers" VERSION NUMBERS In the Internet Protocol (IP) [45,105] there is a field to identify the version of the internetwork general protocol. This field is 4 bits in size. Assigned Internet Version Numbers Decimal Keyword Version References ------- ------- ------- ---------- 0 Reserved [JBP] 1-3 Unassigned [JBP] 4 IP Internet Protocol [105,JBP] 5 ST ST Datagram Mode [49,JWF] 6-14 Unassigned [JBP] 15 Reserved [JBP] From owner-Big-Internet@munnari.oz.au Sun Jun 7 04:27:46 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25114; Sun, 7 Jun 1992 04:27:53 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA25111; Sun, 7 Jun 1992 04:27:46 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA07893 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sat, 6 Jun 1992 14:27:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 6 Jun 1992 14:27:31 -0400 Message-Id: <199206061827.AA16208@home.ans.net> To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: RFC1335 Two-Tier Address -> Big Internet In-Reply-To: (Your message of Fri, 05 Jun 92 10:19:04 N.) <9206050920.8176@munnari.oz.au> Date: Sat, 06 Jun 92 14:27:47 -0500 From: Phill Gross ...maybe use the 16 bits for area addressing or something... Presumably, you would allocate 8 bits each to the source and dest addresses? That's probably not enough to make a difference. It wouldn't even be able to carry the AS# for both source and dest. Phill From owner-Big-Internet@munnari.oz.au Sun Jun 7 09:28:04 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA29689; Sun, 7 Jun 1992 09:28:09 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA29684; Sun, 7 Jun 1992 09:28:04 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA07585 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sun, 7 Jun 1992 09:28:02 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA10183; Sun, 7 Jun 92 09:28:01 EST Message-Id: <9206062328.AA10183@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: CNAT and RFC1335 transition strategies Date: Sun, 07 Jun 92 09:28:01 +1000 From: Bob Smart Here is another way to look at the difference between CNAT and rfc1335 transition to a NewIP format. In the following I assume that the NewIP format is PIP. That's just because I prefer PIP because it does something (the right thing) about policy based routing. The following is just as independent of PIP as CNAT is of CLNP. One day in the not too distant future a network manager who has applied for a Class B network gets his reply: "Sorry we've run out. However here is a large [infinite!] chunk of PIP address space. We realise that you won't be able to run PIP on all your computers for a while. We suggest you use Class A network 2.0.0.0 for your internal network, as it has been reserved for such internal use." At this point we are identical to CNAT, but with RFC1335 we would continue "At this early stage in the transition to PIP there are many IP destinations that don't have translation to PIP working. So we are also providing you with one globally unique Class C IP address 194.71.229.0. Using the recommendations in RFC1335++ you will be able to allow your hosts to contact those hosts also, but only 254 of you hosts will be able to do so at any one time. If you are seriously inconvenienced by this then additional Class C networks may be allocated to you." One assumption is that initially and for a long time the backbones will run PIP and IP together [CNAT seems to assume that the backbone will switch to only running CLNP, but I'm not sure why]. All hosts on the network will fit in a 2x2 matrix: They either support PIP directly or not; and they either have a globally unique IP address or a local one [or both, which we count as the former]. I don't consider the case of hosts which only do PIP: that won't happen for a long time and it will not have any problems by then. Now when 2 hosts are trying to talk we have the following 4x4 matrix. In the following the host on the left is trying to solve the problem of talking to the host across the row: PIP+global PIP+local noPIP+global noPIP+local PIP+global (1) (2) (1) (2) (3) PIP+local (1) (1) (3) (3) noPIP+global (2) (5) (2) (5) noPIP+local (4) (5) (4) (5) (1) The two hosts talk to each other in PIP no problem. (2) The two hosts talk to each other by their globally unique IP address no problem. (3) Actually the top half is no problem. If I have PIP I can talk to any other host by its globally unique PIP address. Getting it translated to/from IP is somebody else's problem. We want to make this rule to encourage PIP host software installation. However hosts with PIP can behave more efficiently by choosing option 5 when it discovers that the other end doesn't support PIP. (4) If the other end has a global address then I just talk IP to that. The boundary to my domain has to do something to make my address global. If it changes the packet to PIP then the boundary to the other end has to also get involved by turning my PIP address into an IP address. The rfc1335 alternative is to change the address locally. Either way it has to be changed, so why not make just one change and keep the packet as IP? This is a significant performance win in the early stages. The disadvantage is that we might not have any of our 254 Class C addresses available at the time to allocate, but for many places that will never be a problem. (5) If we are an IP-only host and we want to talk to something that doesn't have a global IP address then somebody has to give it one. The CNAT proposal is that our domain give it one. This means that the host we are talking to has no way to find out what we think its IP address is. The rfc1335+ proposal is that we (or our nameservers on our behalf) first talk to a global-address allocation process in the domain of the host we are trying to connect to and get them to give it a unique address. The rfc1335+-style proposal has a number of advantages over cnat-style. Applications that like to put their IP address in data can learn to ask their local address allocator what their temporary global address is when talking to something outside the local domain. Better still some hosts can learn to sometimes have a second IP address which they use to talk to the world. [If the second interface is IP over IP then you easily find out what temporary address they've given you by looking at the destination field of incoming udp packets to the IPIP port.] This avoids all the nastiness of packet translation, and is strongly favoured by the rfc1335 authors. However the really important advantage of RFC1335-style is that it will work when the network down-stream of you still only supports IP, so your router can not receive PIP packets at all. This is going to be very common for a long time: plenty of networks are on the ends of serial lines with slip and other host based protocols, or with routers which won't be upgraded at the drop of a hat. What happens when a PIP host tries to use your globally unique PIP address: PIPhostA ---- PIProuterA ----- PIProuterB ---- nonPIProuterC ---- nonPIPhostC When PIPhostA sends a PIP packet to nonPIPhostC a "PIP not implemented" ICMP packet will come back from PIProuterB. PIProuterA should intercept this and send a request in an IP packet to the global-address-allocator(GAA) for domainC. The GAA's IP address should be directly deducible from the PIP address of nonPIPhostC [I believe this is quite easy to do with PIP, It's more of a squeeze with CLNP, and the alternative is to store the information in the DNS as described in the original rfc1335+ proposal]. PIProuterA should thenceforth do translation of the PIP address into IP for PIPhostA. Alternatively PIProuterB could do the enquiry followed by translation on behalf of the downstream domain that doesn't support PIP. Either way this preserves the nice rule that if the host understands PIP then it can talk to anyone with PIP without having to work out if they also understand it yet. Bob Smart From owner-Big-Internet@munnari.oz.au Mon Jun 8 07:29:04 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19616; Mon, 8 Jun 1992 07:29:34 +1000 (from owner-Big-Internet) Return-Path: Received: from nikhefh.nikhef.nl by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA19564; Mon, 8 Jun 1992 07:29:04 +1000 (from a38@nikhef.nl) Received: by nikhefh.nikhef.nl; Sun, 7 Jun 92 23:28:57 +0200 Message-Id: <9206072128.AA02244@nikhefh.nikhef.nl> Date: Sun, 7 Jun 92 23:28:57 +0200 From: James Barr Organisation: NIKHEF-H (National Institute for Nuclear and High Energy Physics) Address: Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands Phone: +31 20 592 5104 (office) Telefax: +31 20 592 5155 To: big-internet@munnari.oz.au Subject: IP address space running out Cc: ripe-org@ripe.net Hi, just a small, possibly hypothetical, comment on IP address space and a couple of questions. The idea that because the internet is growing so fast means that IP numbers will run out soon does not take into account developments in operating systems. One of the main things is the use of low level kernel IPC (using OS specific protocols) which would make a network of computers look like one logical computer. The IP model uses the idea of one IP address per host so this logical computer (collection of computers) would only require one IP address instead of one per computer. This means that a site would probably require the same number of host addresses as it currently requires network numbers. A class B network could be used instead of a class A net, and a class C network instead of a class B. In effect the address space is extended by 8 bits. (What is happening is a two layer heirarchy of addresses). Instead of each ethernet having an IP network number it would have one (or maybe more) IP host addresses which would be converted by the router into the OS specific protocol. This is very attractive because IP software would not need changing, the number of IP networks may actually decrease and it would simplify inter-network management because it would ignore end-systems and only cover networks and routers. The above model is fairly realisitic, for instance the Mach kernel which upon which OSF/1 and Gnu/Hurd are being built uses this style of IPC (although I don't know the ipc details). The questions are: how realistic is the above. will operating systems change before the class B address space runs out. is there anything the networking community can do to encourage the use of new operating systems. regards, james From owner-Big-Internet@munnari.oz.au Mon Jun 8 08:19:04 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20189; Mon, 8 Jun 1992 08:19:10 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206072219.20189@munnari.oz.au> Received: from MC8.MACH.CS.CMU.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20186; Mon, 8 Jun 1992 08:19:04 +1000 (from Christopher.Maeda@MC8.MACH.CS.CMU.EDU) From: Christopher Maeda Date: Sun, 7 Jun 92 18:18:45 EDT To: James.Barr@nikhef.nl Cc: big-internet@munnari.oz.au In-Reply-To: James Barr's message of Sun, 7 Jun 92 23:28:57 +0200 <9206072128.AA02244@nikhefh.nikhef.nl> Subject: IP address space running out Reply-To: cmaeda@cs.cmu.edu Date: Sun, 7 Jun 92 23:28:57 +0200 From: James Barr [description of how a network of machines could appear as one ip address] The above model is fairly realisitic, for instance the Mach kernel which upon which OSF/1 and Gnu/Hurd are being built uses this style of IPC (although I don't know the ipc details). No. Mach Network IPC is usually layered on top of an Internet transport protocol (eg UDP, TCP, VMTP, etc. UDP is the current favorite). This is done because IP gives you internetwork routing and fragmentation/reassembly for free. You could theoretically do your own IPC protocol on top of the network medium but you'd still need to duplicate the functionality of IP. These stopgap schemes really seem to be more trouble than they're worth. Why can't we just develop and deploy a new version of IP with 64 bit addresses and a sane header layout before the 32 bit address space is exhausted? Are we absolutely sure it can't be done? From owner-Big-Internet@munnari.oz.au Mon Jun 8 10:08:03 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21849; Mon, 8 Jun 1992 10:08:06 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA21846; Mon, 8 Jun 1992 10:08:03 +1000 (from smart@mel.dit.csiro.au) Received: from manta.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA12631 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 8 Jun 1992 10:08:01 +1000 Received: by manta.mel.dit.CSIRO.AU (4.1/SMI-4.0.1) id AA04633; Mon, 8 Jun 92 10:08:00 EST Message-Id: <9206080008.AA04633@manta.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: CNAT and RFC1335 transition strategies In-Reply-To: Your message of "Sun, 07 Jun 92 09:28:01 +1000." <9206062328.AA10183@wanda.mel.dit.CSIRO.AU> Date: Mon, 08 Jun 92 10:07:59 +1000 From: Bob Smart It's a poor mailing list where you have to argue both sides of the case, however my previous matrix was flawed and should be: PIP+global PIP+local noPIP+global noPIP+local PIP+global (1) (2) (1) (2) (3) PIP+local (1) (1) (3) (3) noPIP+global (2) (5) (6) (2) (5) noPIP+local (4) (6) (5) (6) (4) (5) ... (6) Where the host we are trying to contact speaks PIP directly and if the router that connects us to the world speaks PIP then it is a win if our router converts the packet to PIP. The problem with that is that the noPIP hosts in our domain still need an IP address to talk to. Later on in the transition there will be networks in which all hosts talk PIP, and they won't forever run a Global Address Allocator for the dwindling number of noPIP hosts. Not only that but we will eventually (maybe) run out of Class C IP networks to allocate. One of my previous arguments for a Global Address Allocator was that it made it easier for hosts running protocols that put IP addresses in data: they can ask a local GAA what address they should use. However it is not much harder to ask a Local Address Allocator associated with your partner the same question. I'm beginning to think it will be necessary to do both in the long run. The key advantage of having a local GAA in the short run is that it works even when the router that connects you to the world doesn't talk PIP(/CLNP/whatever is chosen). The key advantage of allocating a local address for your partner is that you don't have the 254 host limit of simultaneous external links. The two approaches are not incompatible, it is just a question of Occam's razor: we want to do everything that is necessary but no more. Bob Smart From owner-Big-Internet@munnari.oz.au Mon Jun 8 13:06:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA24761; Mon, 8 Jun 1992 13:06:42 +1000 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA24758; Mon, 8 Jun 1992 13:06:38 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA29071; Sun, 7 Jun 92 21:06:28 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA27218; Sun, 7 Jun 92 21:06:28 MDT Message-Id: <9206080306.AA27218@goshawk.lanl.gov> To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 04-Jun-1992 1350" Cc: big-internet@munnari.oz.au Subject: Re: C#, ROAD In-Reply-To: Your message of Thu, 04 Jun 92 13:48:02 -0400. <9206041748.AA04826@us1rmc.mso.dec.com> Date: Sun, 07 Jun 92 21:06:27 MST From: peter@goshawk.lanl.gov >>> I have seen various references to the ROAD group. Is there a mailing list >>> I can get on or is this a closed group? Discussions of the Internet getting big are on the big-internet list. The ROAD group "kicked off" several activities which are reflected in a wide range of IETF directorates (ORAD, Routing, etc.). I expect as these discussions progress and specialize (and hence speciate) we will see other mailing lists announced on this list. To date there has been an attempt to keep the discussions on big-internet. cheers, peter From owner-Big-Internet@munnari.oz.au Mon Jun 8 19:02:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA01322; Mon, 8 Jun 1992 19:02:44 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206080902.1322@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA01319; Mon, 8 Jun 1992 19:02:38 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 8 Jun 1992 10:02:04 +0100 To: cmaeda@CS.CMU.EDU Cc: big-internet@munnari.oz.au Subject: Re: IP address space running out In-Reply-To: Your message of "Sun, 07 Jun 92 18:18:45 EDT." <9206072219.20189@munnari.oz.au> Date: Mon, 08 Jun 92 10:01:39 +0100 From: Paul Tsuchiya > > These stopgap schemes really seem to be more trouble than they're > worth. Why can't we just develop and deploy a new version of IP with > 64 bit addresses and a sane header layout before the 32 bit address > space is exhausted? Are we absolutely sure it can't be done? > This has certainly been thought about by a lot of people, and is the preferred approach by some. But, a common line of reasoning is that if we are going to change formats, why not just go ahead and change to CLNP, since there is already a large amount of work already done. A counter-argument to this is that CLNP doesn't give us anything beyond the capabilities of IP except scaling, so as long as we are going to go through the pain of transition, why not go to something that will advance the state-of-the-art. Noel Chiappa has been the strongest proponent of this, but lacking a clear statement of what that advanced thing was, I for one wasn't ready to give up on CLNP. Well, I guess I'm still not giving up on CLNP, but I hope a lot of folks will take a close look at Pip as a way to get out of the current mess in such a way that we can both take advantage of existing work (such as existing routing protocols) while still advancing us substantially beyond what we currently can do. I know that the current document is a bit hard to read. I am just about (meaning one or two days from now, I'm just getting some final reviews done) to post a high-level description of Pip that should make it more accessible. I'll post on this list as soon as its ready. PT From owner-big-internet@munnari.oz.au Tue Jun 9 00:35:45 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA08694; Tue, 9 Jun 1992 00:35:54 +1000 (from owner-big-internet) Return-Path: Received: from nikhefh.nikhef.nl by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA08182; Tue, 9 Jun 1992 00:05:00 +1000 (from a38@nikhef.nl) Received: by nikhefh.nikhef.nl; Mon, 8 Jun 92 16:04:45 +0200 Message-Id: <9206081404.AA17144@nikhefh.nikhef.nl> Date: Mon, 8 Jun 92 16:04:45 +0200 From: James Barr Organisation: NIKHEF-H (National Institute for Nuclear and High Energy Physics) Address: Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands Phone: +31 20 592 5104 (office) Telefax: +31 20 592 5155 To: Christopher Maeda , James.Barr@nikhef.nl Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au -- In the message of Jun 7, you write : -- /* * * Date: Sun, 7 Jun 92 23:28:57 +0200 * From: James Barr * * [description of how a network of machines could appear as one ip address] * * The above model is fairly realisitic, for instance the Mach kernel * which upon which OSF/1 and Gnu/Hurd are being built uses this style * of IPC (although I don't know the ipc details). * * No. Mach Network IPC is usually layered on top of an Internet * transport protocol (eg UDP, TCP, VMTP, etc. UDP is the current * favorite). This is done because IP gives you internetwork routing and * fragmentation/reassembly for free. You could theoretically do your * own IPC protocol on top of the network medium but you'd still need to * duplicate the functionality of IP. Sorry, I was actually using mach to illustrate I wasn't talking about purely research systems rather than say this is precisely what mach does. I was thinking of the logical host being implemented by physical hosts on the same LAN, in which case internetwork routing and fragmentation/ reassembly would be mute. The router would translate between TCP/UDP port/address pairs and mach ports. The lan would look and act like one IP host. This would not limit the computing system to one lan because a server could translate local port numbers into the ip address for a remote system (suggested by tanenbaum for use with ameoba). * These stopgap schemes really seem to be more trouble than they're I don't think it is a stopgap measure because it's a solution not something to put the problem off a few years. * worth. Why can't we just develop and deploy a new version of IP with * 64 bit addresses and a sane header layout before the 32 bit address * space is exhausted? Are we absolutely sure it can't be done? * Why make routing tables and the DNS much larger and slower by using 64bits? Most traffic is local and doesn't need even 32bits, why should it suffer? To my understanding Mach/Chorus etc are more concerned with addressing services than hosts. How does 64 bit addressing help? It may hinder, because it prevents a service migrating to another host. Globally addressing everything isn't even desirable because it exposes the toplogy of end systems and sites. More importantly internetwork-admin has to concern itself with a lot more numbers. End systems should only be the concern of the local administration. If the use of a standard protocol is limited to the internet, then local systems can use whatever is convenient and efficient locally; debate about IP/OSI/IP++ is limited to internetworking instead of every computer; also it means new protocols can be introduced earlier because end systems would not be so affected. regards, james  From owner-Big-Internet@munnari.oz.au Tue Jun 9 03:09:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12026; Tue, 9 Jun 1992 03:09:46 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12023; Tue, 9 Jun 1992 03:09:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19599; Mon, 8 Jun 92 13:08:16 -0400 Date: Mon, 8 Jun 92 13:08:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206081708.AA19599@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, cmaeda@cs.cmu.edu Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Noel Chiappa has been the strongest proponent of this.. Since Paul has mentioned my opposition, but gotten the exact thrust of it wrong, to clearly convey to you all my arguments against a CLNP conversion, I'll include a section of a previous message (slightly modified for clarity) I sent to a smaller group. Noel -------- Let me try and express myself clearly about my views on this conversion issue. I am not utterly *convinced* that conversion to CLNP is wrong, but it definitely *is not* the choice I would make. I *am* absolutely and utterly certain that in the long run, the architecture will need completely separate namespaces for network attachment points (i.e. network interfaces) and packet consumer/producers (i.e. sort of like hosts). Holding that view, conversion to CLNP looks like a giant leap sideways (backward, actually) to me. A happy accident has left us with a network layer (IP) which has almost what I'd ask for if I were given a clean slate; a shortish, fixed length field for producer/consumer identification by an (effectively random) binary identifier. (TCP2 or whatever did have variable length fields, but they were diked for efficiency!) The fields are too short, true, but it's the right basic idea. It is clearly more efficient to press forward from there, than go what is clearly backward to CLNP. As I say, I can't prove with mathematical logic that conversion to CLNP is *wrong*, the same way I can about the eventual design, since clearly there can be several paths that come to the same point eventually. Even going backward to CLNP, we could get from there to where we need to be eventually. However, why go backward rather than forward? From owner-Big-Internet@munnari.oz.au Tue Jun 9 03:25:35 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12339; Tue, 9 Jun 1992 03:25:54 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12329; Tue, 9 Jun 1992 03:25:35 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA09047; Mon, 8 Jun 92 13:22:04 EDT Date: Mon, 8 Jun 92 13:22:04 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206081722.AA09047@animal.clearpoint.com> To: fortinp@bnr.ca Subject: Re: IPn...? -- correction Cc: big-internet@munnari.oz.au I seem to have propagated a popular misconception. Charles Rose from BBN points out that RFC-1190 (ST-II) uses IP version 5 datagrams, not version 6 as I had previously stated.. sorry for the confusion. Version 6 is still unassigned (as per Jon Postel's quote from the assigned numbers RFC).. -- Frank From owner-Big-Internet@munnari.oz.au Tue Jun 9 03:28:45 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12484; Tue, 9 Jun 1992 03:28:51 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12476; Tue, 9 Jun 1992 03:28:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19817; Mon, 8 Jun 92 13:28:30 -0400 Date: Mon, 8 Jun 92 13:28:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206081728.AA19817@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, cmaeda@cs.cmu.edu Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu A counter-argument to this is that CLNP doesn't give us anything beyond the capabilities of IP except scaling, so as long as we are going to go through the pain of transition, why not go to something that will advance the state-of-the-art. Actually, there is something else I can say about this and Nimrod. Nimrod is *not* the final, complete, new 'state-of-the-art' packet protocol. I don't think we know enough yet (in areas such as how to do resource allocation and reservation) to do a final design yet. To explain what Nimrod is, I like to use the nautical analogy of someone working on a chart with a pair of dividers. They put the dividers down with one leg where they are, and the other leg in an intermediate place; they then lift the first leg, pivot around the second leg, and put the first leg down at their destination. I see Nimrod as the intermediate point we pivot around. Nimrod is simply a routing and addressing architecture; it's not a complete packet architecture. I feel that Nimrod is very close to the 'ultimate answer' on addressing and routing, and I see it as a commonality between the existing IP and some new future protocol. I think it would be included in more or less the deployed form in a new protocol, and form the interoperabilty link between the two. However, Nimrod is not the final answer in all areas. Noel From owner-Big-Internet@munnari.oz.au Tue Jun 9 03:48:45 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12904; Tue, 9 Jun 1992 03:48:55 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12901; Tue, 9 Jun 1992 03:48:45 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA09092; Mon, 8 Jun 92 13:45:00 EDT Date: Mon, 8 Jun 92 13:45:00 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206081745.AA09092@animal.clearpoint.com> To: James.Barr@nikhef.nl, Christopher Maeda Subject: Re: IP address space running out In-Reply-To: Mail from 'James Barr ' dated: Mon, 8 Jun 92 16:04:45 +0200 Cc: big-internet@munnari.oz.au Just a few random thoughts.. >I was thinking of the logical host being implemented by physical hosts >on the same LAN, in which case internetwork routing and fragmentation/ >reassembly would be mute. The router would translate between TCP/UDP >port/address pairs and mach ports. The lan would look and act like >one IP host. But wouldn't this also limit you to about 65k sockets being in use on your LAN? True, it may seem like more than enough, but it may also create a bottleneck on the systems that are servicing well-known port numbers.. >Why make routing tables and the DNS much larger and slower by using 64bits? >Most traffic is local and doesn't need even 32bits, why should it suffer? > It's shouldn't be too much longer before 64-bit processors are in general use: thus, 32-bit addresses might take more work on the CPU to access them than the 64-bit address. -- Frank Solensky From owner-Big-Internet@munnari.oz.au Tue Jun 9 04:31:00 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13875; Tue, 9 Jun 1992 04:31:22 +1000 (from owner-Big-Internet) Return-Path: Received: from nikhefh.nikhef.nl by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13859; Tue, 9 Jun 1992 04:31:00 +1000 (from a38@nikhef.nl) Received: by nikhefh.nikhef.nl; Mon, 8 Jun 92 20:30:24 +0200 Message-Id: <9206081830.AA23220@nikhefh.nikhef.nl> Date: Mon, 8 Jun 92 20:30:24 +0200 From: James Barr Organisation: NIKHEF-H (National Institute for Nuclear and High Energy Physics) Address: Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands Phone: +31 20 592 5104 (office) Telefax: +31 20 592 5155 To: solensky@animal.clearpoint.com (Frank T. Solensky), James.Barr@nikhef.nl, Christopher Maeda Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au -- In the message of Jun 8, you write : -- /* * * Just a few random thoughts.. * * >I was thinking of the logical host being implemented by physical hosts * >on the same LAN, in which case internetwork routing and fragmentation/ * >reassembly would be mute. The router would translate between TCP/UDP * >port/address pairs and mach ports. The lan would look and act like * >one IP host. * * But wouldn't this also limit you to about 65k sockets being in use on * your LAN? True, it may seem like more than enough, but it may also create * a bottleneck on the systems that are servicing well-known port numbers.. There are mainframe unix's running hundreds of users, besides any central systems seem to run with 10's of users with no problems. Basically, its a balance between Ip address and Tcp/Udp ports - with large systems less addresses and more ports in use - with workstations more addresses and less ports. Small atomic requests would be serviced faster since well-known services would be distributed on different processors. Rather than use IP, processes could always use unix domain (or equivalent) sockets since it would be one logical computer. A network of 50 users is not an unusual load for a central machine. If the problem really did arise then the system could be split in two, a saving in Ip addresses of several 1000% is still pretty significant * >Why make routing tables and the DNS much larger and slower by using 64bits? * >Most traffic is local and doesn't need even 32bits, why should it suffer? * > * * It's shouldn't be too much longer before 64-bit processors are in general * use: thus, 32-bit addresses might take more work on the CPU to access them * than the 64-bit address. It's not the word size, it is the number of addresses; your routing tables and DNS/host tables need to increase in size (a lot at the current growth in host count) and so there is more network traffic, lookup is slower and administration becomes more difficult. There is of course the usual answer - get faster machines, ie hardware*10, software/10 :-) But perhaps more significantly local comms requires IP address translation. This is not necessary since on a LAN the link layer address could be used directly with a small header indicating protocol type and (os specific) destination port number. Any overhead becomes significant if a lot of IPC is going on, as would probably be the case in such a shared system. Being able to transparently optimise out the IP might make a lot of difference. Since most comms is local this is a big advantage. * -- Frank Solensky regards, james From owner-Big-Internet@munnari.oz.au Tue Jun 9 05:11:22 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA14782; Tue, 9 Jun 1992 05:11:43 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA14779; Tue, 9 Jun 1992 05:11:22 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA07408; Mon, 8 Jun 92 12:10:45 -0700 Received: by us1rmc.mso.dec.com; id AA25095; Mon, 8 Jun 92 13:45:20 -0400 Message-Id: <9206081745.AA25095@us1rmc.mso.dec.com> Received: from bigfut.enet; by us1rmc.enet; Mon, 8 Jun 92 13:47:20 EDT Date: Mon, 8 Jun 92 13:47:20 EDT From: Ross Callon To: smart@mel.dit.csiro.au, cmaeda@cs.cmu.edu Cc: big-internet@munnari.oz.au Apparently-To: cmaeda@cs.cmu.edu, big-internet@munnari.oz.au Subject: re: IP address space running out > > One assumption is that initially and for a long time the backbones will > run PIP and IP together [CNAT seems to assume that the backbone will > switch to only running CLNP, but I'm not sure why]. > (Bob Smart) > This was based on discussions with folks who manage the NSFNET backbone and some regionals, who were complaining that they were drowning under the load of unmanageable piles of routing information. The problem of storing the information and of updating the routers continuously to add memory seemed to be serious, but less critical than the problem of trying to have a human keep things working correctly (you can put more memory and CPU in routers, but it is harder to put more CPU into the human who is trying to manage it all). Thus the assumption that we had to find a way to make life easier for the regionals and backbones. However, other schemes (CIDR, encapsulation, C#, ...) seem to be able to keep the backbones going for a bit longer than we had originally assumed (still not indefinitely). > > These stopgap schemes really seem to be more trouble than they're > worth. Why can't we just develop and deploy a new version of IP with > 64 bit addresses and a sane header layout before the 32 bit address > space is exhausted? Are we absolutely sure it can't be done? > (cmaeda@cs.cmu.edu) > I agree with most of this. Also, if we are going to require ANY update to Internet hosts for the purposes of improving scaling, then we better require an update which will scale to as large an Internet as we can possibly imagine. There are two details with which I disagree: (i) If you look very hard at the problem, then even 64 bits will probably *EVENTUALLY* be too small. Thus if we move to 64 bit addresses, then 10 or 15 years from now we will be facing the same problem, except that by then the Internet will be REALLY BIG. (ii) It would take a very long time to define, standardize, implement, test, and deploy a new IP. I have had a number of conversations over the last year about what a new IP should look like, and have discovered that nearly everyone has a strong opinion on this, and they all differ. Also, once you have the protocol, the amount of time it takes to get the software debugged and operating and deployed on a "commercial-you-can- count-on-it" basis is larger than we tend to remember. (Also as the IETF gets bigger and more important, it certainly does NOT speed up the IETF's operation). However, we already have a datagram internet protocol being deployed, which has much larger addresses (known as CLNP). It's not perfect, but it is good enough, available in products, is being deployed, and will scale to truely enormous networks. Why don't we use it, by just running existing Internet applications over TCP and/or UDP over CLNP? This was the idea behing CNAT, except that CNAT ended up with a too complex migration scheme (this was primarily based on the initial assumption that IP was going to collapse rather soon -- but other proposals appear to be able to postpone the collapse for a number of years, which allows a much simpler migration). Based on the comments received at the last IETF, I have put together a MUCH simpler migration scheme. This basic scheme looks like the following: A. Use CIDR, C#, encapsulation, or whatever else you can to keep IP working for as long as is feasible. B. Update routers and the Internet backbones to forward both IP and CLNP independently (i.e., continue to forward IP everywhere, simultaneously start forwarding CLNP everywhere -- there is no need for translation between the two). C. Update hosts and DNS servers, such that - IP hosts talk to any host just like today. - When an updated (Internet host that can do IP and CLNP) host wants to talk to another host, it looks up the other host's address in the normal way (using DNS, or /etc/hosts, or whatever other means it normally uses to find an address). If it gets back a 32-bit address, then it runs Internet applications over IP. If it gets back a longer address (meaning the other end is also updated), it runs over CLNP. D. Someday, when 32-bit addresses just don't allow for global communication, the IP-only hosts which never got updated either need to be updated, or become "for local use within the domain in which 32-bits is meaningful". Part D sort of requires part A, since it will take several years before we can get the majority of Internet hosts updated. Part D is the major difference from CNAT, and results in an ENORMOUS simplification relative to CNAT (90% of the CNAT scheme was trying to deal with what to do if we can't update all hosts before the IP Internet breaks). Ross From owner-Big-Internet@munnari.oz.au Tue Jun 9 06:12:18 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16182; Tue, 9 Jun 1992 06:12:25 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16179; Tue, 9 Jun 1992 06:12:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20656; Mon, 8 Jun 92 16:12:01 -0400 Date: Mon, 8 Jun 92 16:12:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206082012.AA20656@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, cmaeda@cs.cmu.edu Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu A counter-argument to this is that CLNP doesn't give us anything beyond the capabilities of IP except scaling.... Oh, a section of one other previous message (sent to a smaller group) which bears on the point here: Also, the fact that CLNP has bigger addresses *in the packets* is to me totally beside the point. I don't think the address of the network port to which the destination is currently attached belongs in each packet anyway, any more than the route to that address belongs in each packet. Every time I hear someone say "but it has bigger addresses" I want to tear my hair out, because to me it just indicates that the person (apologies in advance to everyone, whom this is going to offend) hasn't really thought hard about what the network layer out to be doing. As an (lengthy, theoretical, skip if you don't care about this) aside, I did sit down and think for a while about exactly what we should be putting in the packet as the source and destination identifiers. It clearly shouldn't be the address (which I see as long, unruly, and not needed in every packet anyway), but some shorter thing. Was I right in making it the producer/consumer identifier (P/C-id hereinafter), or not? After all, this was sort of an accidental choice, driven by the goals of keeping the hosts unmodified, and allowing mobile TCP connections. Should it have been some of unique identifier for the network attachment point (NAP hereinafter) [a third naming space, to go along with the structured namespace for NAP's, which we call addresses, and the effectively unstructured P/C-id's] instead, since these are really the things the network layer deals with. In some sense the P/C-id's are most useful to the transport layer; why put them in the network layer? [Parenthetically, I need a better name for these P/C things. For those of you who aren't familiar with P/C-id's, think of them as very similar to what you now think of as a host. They are actually autonomous entities which communicate, with the difference that they might migrate from machine to machine, e.g. if they are mobile processes, and there might be more than one in what we think of as a host; e.g. each processor in a reliable multi-processor might have one. Looked at another way, the are end-to-end boundaries, or fate-sharing boundaries (everything inside the boundary lives or dies together). Replies to me *only* if you have a suggestion, please!] I decided after some cogitation that I had accidentally made the right choice, but I don't yet feel strongly confident that it is correct, and would love to hear counterpoints. True, the network layer does not care about end-to-end entities, and in some cases (e.g. if you want to speak to everyone who is attached to a network interface) having the P/C-id in the packet is the wrong thing. However, having a third namespace, with the attendant mappings to and fro to the other two, does not seem to buy us enough to make it worthwhile. A problem we identified in writing the Host Requirements is that when a mechanism is not provided at a low enough level in the TCP/IP stack, each application has to reinvent that wheel. (For example, since TCP does not include the concept "send this data, and if we don't get back N bytes of data within Q RTT's, timeout", every query-response application such as SMTP, FTP, etc, etc has to have its own application level timeout; the TCP on the far end may accept the data even though the application is looping and will never respond to the command you just sent.) It seems that the P/C-id is just such a mechanism. If the network layer did not supply it, then every transport layer would have to have its own. That would be more flexible, but more complex; since most traffic will need one, it is best done at a common level. Also, having the P/C-id in the packet does allow you the flexibility with having P/C's move around in the network without the neccessity of notifying the other end. Given this analysis, it seems clear that the P/C-id has to be in each packet anyway. Given that, the extra utility of having an NAP identifier in each packet seems minimal. It might be *useful) to the routing and addressing architecture to have such a namespace (and Martha and I have discussed this), so each NAP has a (short) name which is constant, but as long you have flexibilty in the mapping from P/C-id's to addresses (i.e. the structured NAP names), I can't see that it is *necessary*. I.e. if you can have a single P/C-id reachable through multiple addresses (for multi-homing), or change its address (for mobile hosts), or have many PC-id's at a single address (for movable processes), etc, it's hard to see how more than a single layer of mapping is useful. Given that, unless you have a demonstrated use for a name for NAP's which is short and constant, it hard to see that you need a NAP identifier namespace at all, let alone one intermediate between NAP addresses and P/C-id's. Noel From owner-Big-Internet@munnari.oz.au Tue Jun 9 06:15:41 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16267; Tue, 9 Jun 1992 06:15:54 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16262; Tue, 9 Jun 1992 06:15:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20695; Mon, 8 Jun 92 16:15:35 -0400 Date: Mon, 8 Jun 92 16:15:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206082015.AA20695@ginger.lcs.mit.edu> To: cmaeda@mc8.mach.cs.cmu.edu, solensky@animal.clearpoint.com Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu It's shouldn't be too much longer before 64-bit processors are in general use: thus, 32-bit addresses might take more work on the CPU to access them than the 64-bit address. I seem to recall, from talking to people working on Cray's some years back, that they already had problems then, parsing TCP packets quickly, because of the word length on the Cray's! Noel From owner-Big-Internet@munnari.oz.au Tue Jun 9 06:36:10 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16724; Tue, 9 Jun 1992 06:36:27 +1000 (from owner-Big-Internet) Return-Path: Received: from TSX-11.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16721; Tue, 9 Jun 1992 06:36:10 +1000 (from tytso@ATHENA.MIT.EDU) Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA10751; Mon, 8 Jun 92 16:33:50 -0400 Date: Mon, 8 Jun 92 16:33:50 -0400 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9206082033.AA10751@tsx-11.MIT.EDU> To: mo@gizmo.bellcore.com Cc: Paul Tsuchiya , cmaeda@CS.CMU.EDU, big-internet@munnari.oz.au, mo@gizmo.bellcore.com In-Reply-To: mo@gizmo.bellcore.com's message of Mon, 08 Jun 92 10:30:16 -0400, <9206081430.AA17527@bellcore.bellcore.com> Subject: Re: CLNP Reply-To: tytso@athena.mit.edu Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 08 Jun 92 10:30:16 -0400 From: mo@gizmo.bellcore.com the biggest reason to not do CLNP is because the headers are the size of a small state! while *some* networks are getting faster, some of us are VERY interesting in using network technology over reasonably slow networks, like 32kbit fast-burst TDMA piggy-backed over PCS channels (to pick a bell-shaped example), or IR links, or other media. the size of CLNP headers makes this a preposterous alternative. Well, there's always header compression; to quote from RFC1144, "Compressing TCP/IP Headers", by Van Jacobson: Figure 2 shows a typical (and minimum length) TCP/IP datagram header. The header size is 40 bytes: 20 bytes of IP and 20 of TCP. Unfortunately, since the TCP and IP protocols were not designed by a committee, all these header fields serve some useful purpose and it's not possible to simply omit some in the name of efficiency. It sounds like it should be very easy to do header compression on CNLP. :-) - Ted From owner-Big-Internet@munnari.oz.au Tue Jun 9 07:00:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17208; Tue, 9 Jun 1992 07:00:49 +1000 (from owner-Big-Internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA17205; Tue, 9 Jun 1992 07:00:38 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA06809; Mon, 8 Jun 92 13:59:30 PDT Date: Mon, 8 Jun 92 13:59:30 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206082059.AA06809@saffron.acc.com> To: mo@gizmo.bellcore.com Subject: Re: CLNP Cc: P.Tsuchiya@cs.ucl.ac.uk, big-internet@munnari.oz.au, cmaeda@CS.CMU.EDU >> the biggest reason to not do CLNP is because the headers are the >> size of a small state! while *some* networks are getting faster, >> some of us are VERY interesting in using network technology over >> reasonably slow networks, like 32kbit fast-burst TDMA piggy-backed >> over PCS channels (to pick a bell-shaped example), or IR links, or >> other media. the size of CLNP headers makes this a preposterous >> alternative. IP/TCP IDP/SPP CLNS/TP4 20+20=40 30+12=42 48+7=55 I'm not a great fan of CLNS, or of CLNS addressing (the major component in CLNS's header size), but in perspective, I'm not sure the total message unit's size changed so drastically. Fred From owner-big-internet@munnari.oz.au Tue Jun 9 13:23:52 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26550; Tue, 9 Jun 1992 13:23:59 +1000 (from owner-big-internet) Return-Path: Received: from cody.cso.uiuc.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA24672; Tue, 9 Jun 1992 12:14:57 +1000 (from rrv@cody.cso.uiuc.edu) Received: by cody.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA17301; Mon, 8 Jun 1992 21:14:41 -0500 Date: Mon, 8 Jun 1992 21:14:41 -0500 From: rrv@cody.cso.uiuc.edu (Ross Veach) Message-Id: <9206090214.AA17301@cody.cso.uiuc.edu> To: P.Tsuchiya@cs.ucl.ac.uk Subject: generalized RFC-1219 Cc: big-internet@munnari.oz.au > It would be nice if you could do 1219 once at the subnet-host boundary, > and once at the network-subnet boundary, but this doesn't work. That's exactly what I was suggesting. I think something very similar to 1219 can work. The AddSubnet() algorithm can easily be modified to preallocate a given number of host bits. One is inclined to want to do that anyway to superimpose 1219 or anything like it onto an existing address space. In fact, one has to go further and write SetSubnet(address,hbits) and SetHost(address) functions before using 1219 on an existing address space. One could easily enough write AddNetwork(nbits) and SetNetwork(address,nbits) that operate on the entire 32-bit address space. If you make that kind of provision for preallocating address space for the next lower level, 1219 like algorithms can be applied recursively. When one level runs out of bits, it requests another high-order bit from the next higher level. The generalized function becomes something like AddSpace(lbits,rbits) where lbits is the number of bits on the left that you can't touch without going to a higher authority and rbits is the number of bits on the right that you want to allocate. Allocating a class B sized network would be a call to AddSpace(0,16), and allocating an 8-bit subnet in a class B network would be a call to AddSpace(16,8). As for routing table size, we could allocate large chunks of address space to the service providers and let them sub-divide it to their clients. Their clients could sub-divide it further to their sub-clients, etc. We'd have hierarchical addresses and the whole set of routing problems and opportunities that come with them. We could start allocating 12-bit chunks (or 13-bit chunks, or whatever) of address space tomorrow if we wanted to. For right now they'd have to be in the class B part of the address space and we wouldn't be able to use the other 15/16 of that class B. All we have to do is tell people what address range they're permitted to use and stop talking about class [ABC] networks. Improved inter-AS routing protocols that carry both an address and a mask and that are already being worked on will take care of the restrictions. Ross ------------ Please, don't get the idea that I've written useful code to implement 1219 or anything like it. I did write some awk scripts to play with the concepts, but awk was the wrong language. Had I played in C or some other language with bit-wise logical operators, I might have something to offer, but I didn't. We are using variable length subnets and we are using mirror-image counting to allocate them, but we don't have an implementation of 1219, so don't ask. From owner-Big-Internet@munnari.oz.au Tue Jun 9 18:15:33 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA04742; Tue, 9 Jun 1992 18:15:50 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206090815.4742@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA04721; Tue, 9 Jun 1992 18:15:33 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 9 Jun 1992 09:13:15 +0100 To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: IP address space running out In-Reply-To: Your message of "Mon, 08 Jun 92 13:47:20 EDT." <9206081745.AA25095@us1rmc.mso.dec.com> Date: Tue, 09 Jun 92 09:12:41 +0100 From: Jon Crowcroft >Based on the comments received at the last IETF, I have put together a >MUCH simpler migration scheme. This basic scheme looks like the following: i subscribe to the view that the problem is not with hosts/routers that change - whenever there is any change at host, we are probably in a position to make sure it is to sometyhing that scales for a while - also anything that changes can continue to also run the old version. The problem is with the things that dont change - i.e. how can a system that can only address around 1 million machines with current allocation continue to talk to the new systems which talk a different format packet, and a larger address space...unless these new systems can fall back on a NEED to TALK basis hence 1335... > A. Use CIDR, C#, encapsulation, or whatever else you can to keep IP > working for as long as is feasible. these mainly temporarily deal with the routing scaling problem rather than the new and old host problem... > C. Update hosts and DNS servers, such that > - IP hosts talk to any host just like today. > - When an updated (Internet host that can do IP and CLNP) host the UK Name Service (Name Registration Scheme) had an excellent solution to this which goes something like the following (i've slightly modified it) a Name to End System resolution query is made in two "Contexts", one for source (end system making query) and one for destination (end system we want an ES address for and context for communication protocol preferred by querier). The DNS/NRS then does a Best Match - if it can't it gives a NAT or tells systems to do a rfc1335 temp allocation etc etc.. e.g.s I ask for A record as an IP, wanting to do IP get normal answer or i ask as a PIP wanting to do PIP, get PIP addr or i ask as PIP wanting to do PIP but get IP (not a problem unless i've discarded old software... etc etc (in fact, NRS contexts could be smarter as they could be application contexts, in which case, you could be referred MX-wise, to a relay...) hmmm...what a mess:-( jon From owner-big-internet@munnari.oz.au Wed Jun 10 02:46:30 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16279; Wed, 10 Jun 1992 02:46:38 +1000 (from owner-big-internet) Return-Path: Received: from bellcore.bellcore.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA14308; Wed, 10 Jun 1992 00:49:33 +1000 (from mo@gizmo.bellcore.com) Received: from gizmo.bellcore.com by bellcore.bellcore.com (5.61/1.34) id AA12053; Tue, 9 Jun 92 10:48:40 -0400 Message-Id: <9206091448.AA12053@bellcore.bellcore.com> To: tytso@athena.mit.edu Cc: Paul Tsuchiya , cmaeda@CS.CMU.EDU, big-internet@munnari.oz.au Subject: Re: header compression as a saviour for bad design... In-Reply-To: Your message of "Mon, 08 Jun 92 16:33:50 EDT." <9206082033.AA10751@tsx-11.MIT.EDU> Date: Tue, 09 Jun 92 10:48:28 -0400 From: mo@gizmo.bellcore.com header compression works only when the packet stream is highly correlated and only running on a single link. as services become more transaction-based, and as more services need to share the same slow link efficiently, header compression cannot be relied upon to solve the problem of gargantuan headers. -Mike From owner-Big-Internet@munnari.oz.au Wed Jun 10 03:40:21 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17828; Wed, 10 Jun 1992 03:40:27 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206091740.17828@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA17825; Wed, 10 Jun 1992 03:40:21 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from theydon.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 9 Jun 1992 16:26:48 +0100 To: big-internet@munnari.oz.au Subject: another pip read...... Date: Tue, 09 Jun 92 16:26:15 +0100 From: Paul Tsuchiya Gang, Another Pip document has been posted. This document contains an overview of Pip (about 10 pages) and some examples (another 10 pages), but not as detailed as the examples in the last thing I posted. The overview stands alone, so you can get a basic idea of what Pip is without a lot of pain. So, for those of you who balked at wading through the last posting, or those of you who haven't even looked at it, you might want to give this overview a try. It is in both text and postscript, and the text is complete. I've posted it as an internet-draft, and have put copies of it in: thumper.bellcore.com:pub/tsuchiya/pip.overview.txt, .ps, .ps.Z PT From owner-Big-Internet@munnari.oz.au Wed Jun 10 04:22:37 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19132; Wed, 10 Jun 1992 04:22:41 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206091822.19132@munnari.oz.au> Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19129; Wed, 10 Jun 1992 04:22:37 +1000 (from kre) Date: Wed, 10 Jun 1992 04:22:37 +1000 From: Robert Elz To: big-internet@munnari.oz.au Subject: Re: another pip read...... Date: Tue, 09 Jun 92 16:26:15 +0100 From: Paul Tsuchiya It is in both text and postscript, and the text is complete. I've posted it as an internet-draft, and have put copies of it in: thumper.bellcore.com:pub/tsuchiya/pip.overview.txt, .ps, .ps.Z There are now also copies in the big-internet directory on munnari.oz.au The internet draft will appear there as well when it gets through the system. kre From owner-Big-Internet@munnari.oz.au Wed Jun 10 05:06:35 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20123; Wed, 10 Jun 1992 05:06:53 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20120; Wed, 10 Jun 1992 05:06:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26166; Tue, 9 Jun 92 15:05:54 -0400 Date: Tue, 9 Jun 92 15:05:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206091905.AA26166@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, rrv@cody.cso.uiuc.edu Subject: Re: generalized RFC-1219 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Huh? How is this substantially better (i.e. more than one order of magnitude) than CIDR? You are still stuck with 32 bits, and even if you use every single possible address (and I think you get a minimum of 25% wastage, if I remember by memory allocation theory), you still only get 4x10^9 hosts.... Noel From owner-Big-Internet@munnari.oz.au Wed Jun 10 18:56:54 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13052; Wed, 10 Jun 1992 18:57:01 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.64+1.3.1+0.50) id AA13049; Wed, 10 Jun 1992 18:56:54 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04835; Wed, 10 Jun 92 04:33:47 -0400 Message-Id: <9206100833.AA04835@relay1.UU.NET> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Jun 1992 09:33:14 +0100 To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: IP address space running out In-Reply-To: Your message of "Mon, 08 Jun 92 13:47:20 EDT." <9206081745.AA25095@us1rmc.mso.dec.com> Date: Wed, 10 Jun 92 09:32:32 +0100 From: Zheng Wang >(i) If you look very hard at the problem, then even 64 bits will >probably *EVENTUALLY* be too small. Thus if we move to 64 bit addresses, >then 10 or 15 years from now we will be facing the same problem, except >that by then the Internet will be REALLY BIG. I cannot think of any reasons why we would need more than 64-bit. The Internet will not grow like now forever- there is an ultimate limit. With 64-bit space, we would have over 1800000000 addresses for each person on the earth. Bear in mind the consumption of resource is uneven as people have discovered in Rio Summit:-) > D. Someday, when 32-bit addresses just don't allow for global communication, > the IP-only hosts which never got updated either need to be updated, or > become "for local use within the domain in which 32-bits is meaningful". Then the updated hosts have to run both IP and CLNP forever if they want to comminucate with old IPs. Cheers Zheng From owner-Big-Internet@munnari.oz.au Wed Jun 10 19:20:16 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13623; Wed, 10 Jun 1992 19:20:28 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13620; Wed, 10 Jun 1992 19:20:16 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 10 Jun 92 02:19:54 -0700 Date: Wed, 10 Jun 92 02:19:54 -0700 From: Tony Li Message-Id: <9206100919.AA22154@lager.cisco.com> To: Z.Wang@cs.ucl.ac.uk Cc: callon@bigfut.enet.dec.com, big-internet@munnari.oz.au In-Reply-To: Zheng Wang's message of Wed, 10 Jun 92 09:32:32 +0100 <9206100833.AA04835@relay1.UU.NET> Subject: IP address space running out I cannot think of any reasons why we would need more than 64-bit. The Internet will not grow like now forever- there is an ultimate limit. With 64-bit space, we would have over 1800000000 addresses for each person on the earth. Bear in mind the consumption of resource is uneven as people have discovered in Rio Summit:-) If you want to do hierarchical addressing, then 64 bits is probably not nearly enough. Unless you are very careful, you will not be able to use the address space in a very dense fashion. Once political realities intrude, and people start having address space wars, it will really get bad. In fact, I'll go even farther out. Take a look at your 20 byte NSAP. I can envision ways in which the current NSAP (even after all the reserved bytes are used) will be too small. Think about what happens when each and every house is an area.... Radical idea: We know that there are an uncountable number of numbers on the real number line in the interval [0,1). Let an address be a binary representation of a number in this interval. Initially, we allocate some prefix to each addressing authority, and addresses within that authority are some number of bits long. As this address space is used up, we now subdivide it: take an existing address, remove the host that is using it, and now use that as a prefix and add more address bits on the right hand side. I believe that Noel mentioned doing this, but I don't recall for certain. Anyhow, parsing arbitrary length addresses will certainly be an interesting task. Ross, can you get me some of those 200Mhz Alpha chips? ;-) Tony From owner-Big-Internet@munnari.oz.au Wed Jun 10 19:36:51 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13891; Wed, 10 Jun 1992 19:36:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206100936.13891@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13888; Wed, 10 Jun 1992 19:36:51 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Jun 1992 10:36:26 +0100 To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: IP address space running out In-Reply-To: Your message of "Wed, 10 Jun 92 02:19:54 PDT." <9206100919.AA22154@lager.cisco.com> Date: Wed, 10 Jun 92 10:35:43 +0100 From: Jon Crowcroft > an ultimate limit. With 64-bit space, we would have over 1800000000 > addresses for each person on the earth. Bear in mind the > consumption of resource is uneven as people have discovered in Rio > Summit:-) > >If you want to do hierarchical addressing, then 64 bits is probably >not nearly enough. Unless you are very careful, you will not be able >to use the address space in a very dense fashion. these are end systems - why do you want to do hierarchical addressing within end systems - Pip solves that separately...so does nimrod unless i've completely missed noel's point... if you think about the "how to get there" routing problem and abstraction/management of routing info sdeparately from the "distinguising end systems" addressing problem, then what's your problem?:-) jon p.s. >to use the address space in a very dense fashion. What a very apt description of some NSAP allocation schemes:-) From owner-Big-Internet@munnari.oz.au Wed Jun 10 21:35:02 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16715; Wed, 10 Jun 1992 21:35:06 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206101135.16715@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16712; Wed, 10 Jun 1992 21:35:02 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Jun 1992 12:34:40 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: IP address space running out In-Reply-To: Your message of "Mon, 08 Jun 92 13:08:16 EDT." <9206081708.AA19599@ginger.lcs.mit.edu> Date: Wed, 10 Jun 92 12:34:09 +0100 From: Zheng Wang > A happy accident has left us with a network layer (IP) which has >almost what I'd ask for if I were given a clean slate; a shortish, fixed >length field for producer/consumer identification by an (effectively >random) binary identifier. (TCP2 or whatever did have variable length >fields, but they were diked for efficiency!) The fields are too short, >true, but it's the right basic idea. It is clearly more efficient to press >forward from there, than go what is clearly backward to CLNP. A fixed ID is certainly useful for mobile IPs but the benefit may not be so great for most of the fixed IPs. An alternative may be to allocate some of the addresses (unstructured) to mobile IPs and treate these addresses as IDs rather than interface addresses. The mapping to the actual interface addresses can be done at the destination network. Cheers Zheng From owner-Big-Internet@munnari.oz.au Thu Jun 11 03:36:22 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26080; Thu, 11 Jun 1992 03:36:29 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26073; Thu, 11 Jun 1992 03:36:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02057; Wed, 10 Jun 92 13:35:14 -0400 Date: Wed, 10 Jun 92 13:35:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206101735.AA02057@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, tli@cisco.com Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com, jnc@ginger.lcs.mit.edu I believe that Noel mentioned doing this Noel has had many wild ideas in his day, but this wasn't one of them! It is an interesting idea, I will admit. If you want to do hierarchical addressing, then 64 bits is probably not nearly enough. Yes, 64 bits is a joke as an address. I'm not even sure it's long enough for a UID. Yes, it's a lot of numbers, but let's assume we discover tachyons and want to extend the Internet off-planet. (I'm serious here, .) My approach would be to make it 64 bits for now, but make sure there are 64 bit MBZ fields just in front of the source and destination fields in the new packet format when we define it 5-10 years down the road. In fact, I'll go even farther out. Take a look at your 20 byte NSAP. I can envision ways in which the current NSAP (even after all the reserved bytes are used) will be too small. Oh, absolutely; this is one of the 17 things I think are wrong with CLNP addressing. 20 bytes sounds like a lot, but by the time you deduct for the AFI, etc, etc, and then 6 bytes for the 48-bit interface UID, there ain't much room left. You are basically left with a field so small you have to statically divide it into fields, as opposed to using some sort of encoding to provide a variable number of variable length fields (sort of like the encoding of IP options). This, by the way, is what I think addresses ought to be; basically unlimited length strings, where each level contains its own length field. They would start at the bottom (i.e. physical assets would be level 0), and be numbered up, to allow trivial joining of network systems which were not numbered out of a common address space. You just add another layer on top, give each system a different number out of that, and hey presto, you are done. Yes, it's a lot of work to parse, but remeber, you don't do it often, since they aren't in the average packet. Noel From owner-Big-Internet@munnari.oz.au Thu Jun 11 04:19:27 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA27049; Thu, 11 Jun 1992 04:19:33 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA27044; Thu, 11 Jun 1992 04:19:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02371; Wed, 10 Jun 92 14:19:16 -0400 Date: Wed, 10 Jun 92 14:19:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206101819.AA02371@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu A fixed ID is certainly useful for mobile IPs but the benefit may not be so great for most of the fixed IPs. An alternative may be to allocate some of the addresses (unstructured) to mobile IPs and treate these addresses as IDs rather than interface addresses. Maybe I'm confused, but I think you may have missed the point of my scheme. There's a good reason I don't want to take one namespace and split it up into two segments, which is what you seem to be alluding to. I explicitly propose to take what is now one namespace (host addresses) and make two separate ones: endpoint identifiers (what I call P/C id's), and network interface addresses. You would then have mappings back and forth. There's a computer science aphorism (due to Butler Lampson) that goes: "all problems in computer science can be solved by one more level of indirection". In other words, the flexibilty that the attendant mapping between the two (now separated) levels gives you is what you need to solve problems. Yes, we could map from one namespace back into the same namespace (which is what you propose, and which is what things like 800 numbers and mobile phones in roam mode do), but this is not nearly as powerful as two separate namespaces. In general, in computer science, any time you have two very different classes of things being named with the same kind of names, you have a system which in the long run is not as flexible, powerful and adaptable. Flexibilty and adaptabilty are probably two of the most important attributes we should be looking for in a new routing and addressing architecture. They mean that the lifetime, and power, will be maximized. For a large, service, system, these are golden goals! They minimize the lifetime cost of the system by maximizing the lifetime, and minizing the cost of changes. About the only other thing I can think of that comes in the same range, to me, is robustness. To me, these are the key reasons to prefer source routed link state systems; that approach is the golden road to maximum flexibility, adaptabilty, and robustness. If efficiency were as important as people sometimes assume, we'd all be programming in assembler. The fact that we don't should tell you something about what's really important. Noel From owner-big-internet@munnari.oz.au Thu Jun 11 05:10:17 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA28014; Thu, 11 Jun 1992 05:10:20 +1000 (from owner-big-internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA27410; Thu, 11 Jun 1992 04:32:27 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA18113; Wed, 10 Jun 92 11:31:50 -0700 Date: Wed, 10 Jun 92 12:12:06 EDT From: "William Allen Simpson" Message-Id: <414.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Focus: address translating server I believe we have come to a decision point in the discussion. I would like to focus on the server translation part of the various proposals, to see if there is agreement on the feasability of this approach. - Is this something we want for the short or long term? - Does this affect the host, or the router, or both? - How does this fit in with other servers; DNS, whitepages, etc? - When are the updates? - What administrative model does this require? - How hard is this? CNAT requires a server to translate to/from NSAP addresses. - goes away when the entire internet has converted to CLNP. - done at host? - could use DNS (new record type?) - static, updates as DNS does. Interdomain Encapsulation (IP-IP or otherwise) requires a server to locate the other administrative domain. - goes away when entire internet has converted to next version of IP. - done at boarder router. - could use DNS (new record type). - static, updates as DNS does. RFC1335 requires a server for the assignment of and translation between local and global addresses. - will always be needed. - done at boarder router, may need host cooperation? - completely new server; DNS used to locate server (new record type). - dynamic, updates when session idle (frequent). Nimrod may require a server to translate global host addresses to path addresses. - will always be needed. - done at every router, no change to hosts (new IP is separate). - completely new server, massive routing changes. - dynamic, updates when path changes (presumed infrequent). None of the other proposals (CIDR, C#, PIP) requires such a server. However, of these only PIP is a long term solution, and PIP could be done in conjunction with encapsulation and Nimrod. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Thu Jun 11 10:00:30 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA04931; Thu, 11 Jun 1992 10:00:38 +1000 (from owner-Big-Internet) Return-Path: Received: from cody.cso.uiuc.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA04928; Thu, 11 Jun 1992 10:00:30 +1000 (from rrv@cody.cso.uiuc.edu) Received: by cody.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA18437; Wed, 10 Jun 1992 19:00:25 -0500 Date: Wed, 10 Jun 1992 19:00:25 -0500 From: rrv@cody.cso.uiuc.edu (Ross Veach) Message-Id: <9206110000.AA18437@cody.cso.uiuc.edu> To: jnc@ginger.lcs.mit.edu Subject: Re: generalized RFC-1219 Cc: big-internet@munnari.oz.au Noel, I didn't jump into this discussion to advance the art of representing more than 2**32 values in 32 binary digits. I jumped in because I have some experience with representing way more than 2**16 values in 16 binary digits and want to do my part of steering the IP Internet away from going down that same road again. I was directed here after reacting negatively to RFC 1335 "A Two-Tier Address Structure for the Internet" in the main IETF mailing list. That proposal is all too similar to what has already been done in the DECnet Phase IV world. There has to be another way to extend the life of the IP Internet as we know it today. The fabric of the Internet is learning how to switch packets that contain 160 bit addresses. It's my view any long term solution to our address space problem will have to take advantage of that simple fact. I don't have any opinion of the currently defined higher level protocols that use those 160 bit addresses. If the current ones aren't good enough, someone will implement ones that are good enough. I don't think anyone can stop that process. I haven't read all of this group's work yet. I may be wrong about what you're trying to accomplish here. I think you're trying to figure out how to get a few more years out of our 32 bit address space. I think we can easily make at least an order of magnitude better use of that address space by allocating it wisely, and buy ourselves a few more years to implement useful protocols that make use of the bigger address space provided for in the fabric of the global Internet. > you still only get 4x10^9 hosts Four thousand million hosts. Let's aim for 10% of that. If we keep wasting address space the way we do today, we won't even reach 1%, and we'll be all washed up by this time next year. Throw away those stupid artificial class distinctions, leave the IP architecture alone, and spend the rest of the decade learning how to do global routing for two million networks and how to use those 160 bit addresses. Ross "Dual Network Addressing (DNA)" --- I thought DNA stood for "DECnet Architecture". Those who forget history are condemned to repeat it. From owner-big-internet@munnari.oz.au Thu Jun 11 13:57:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA11259; Thu, 11 Jun 1992 13:57:42 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA10786; Thu, 11 Jun 1992 13:43:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04156; Wed, 10 Jun 92 23:43:45 -0400 Date: Wed, 10 Jun 92 23:43:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206110343.AA04156@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, rrv@cody.cso.uiuc.edu Subject: Re: generalized RFC-1219 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I think I may have been a little too cryptic in my comments, since I didn't say what I think you are responding to! I absolutely, completely, agree with you that trying to get more than 2^N addresses out of an N bit address field is a Bad Idea of the First Water. What I was doing was responding to your suggestions about generalizing RFC-1219; RFC-1335 was not the issue. I will note in passing (people can skip this paragraph of Noel's "addresses_in_packets_are_a_bad_idea" flaming) that I don't agree that the long term solution to our addressing and routing problems (which are more than simply an 'address space problem') is very large addresses in the packets. Addresses should not be in packets anyway, any more than routes are. To steal a line from a message to another group: If you take my point that network addresses aren't the things we should have in the packets, but rather some sort of host identifier - and nobody has ... come up with a good argument [against this point of view] - then the fact that CLNP has *larger* addresses is clearly totally irrelevant. I see it as sort of like saying "my car design is better 'cause it has larger tail-fins". Anyway, some people may be trying to get more years out of a 32 bit address space, and I can't speak for them. That's not the way I am proceeding. Nimrod (an joke name for my scheme) is a basic look at what a routing and addressing architecture ought to be, and a long range plan for same; it just happens that the first phase of an interoperable deployment plan for it has the nice side-effect that happens to get the maximum lifetime out of the *existing* 32-bit space by allowing close to 100% utilization of that space. The current very short term plan (CIDR, which I alluded to, and which is *not* Nimrod, and has nothing to do with it) is to do basically what you suggest; throw away the class distinctions and leave everything else alone; think of it as variable width contiguous subnet masks all the way up the address field. My original note was to question whether the elaborate mechanism proposed in RFC-1219 (and extended by you to the whole address) was really much better than CIDR. Noel From owner-Big-Internet@munnari.oz.au Thu Jun 11 18:37:30 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19504; Thu, 11 Jun 1992 18:37:36 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206110837.19504@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA19501; Thu, 11 Jun 1992 18:37:30 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 11 Jun 1992 09:37:08 +0100 To: rrv@cody.cso.uiuc.edu (Ross Veach) Cc: big-internet@munnari.oz.au Subject: Re: generalized RFC-1219 In-Reply-To: Your message of "Wed, 10 Jun 92 19:00:25 CDT." <9206110000.AA18437@cody.cso.uiuc.edu> Date: Thu, 11 Jun 92 09:36:33 +0100 From: Zheng Wang >"Dual Network Addressing (DNA)" --- I thought DNA stood for "DECnet >Architecture". Those who forget history are condemned to repeat it. DNA is more widely known as something that everyone has in his/her body (actually billons of billons of it). I picked up this name because they have similarity in structure:-). Cheers Zheng From owner-Big-Internet@munnari.oz.au Thu Jun 11 19:08:14 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20191; Thu, 11 Jun 1992 19:08:19 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206110908.20191@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20188; Thu, 11 Jun 1992 19:08:14 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 11 Jun 1992 10:07:38 +0100 To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au Subject: Re: Focus: address translating server In-Reply-To: Your message of "Wed, 10 Jun 92 12:12:06 EDT." <414.bsimpson@angband.stanford.edu> Date: Thu, 11 Jun 92 10:07:00 +0100 From: Zheng Wang >RFC1335 requires a server for the assignment of and translation between >local and global addresses. Not accurate. RFC1335 does not require the server to translate. > - done at boarder router, may need host cooperation? Incorrect. Allocation and de-allocation are done by the server, probably integrated into the DNS server. The routers are not aware of the translation. > - completely new server; DNS used to locate server (new record type). See above. > - dynamic, updates when session idle (frequent). allocation and deallocation at the beginning and the end of a session. Cheers Zheng From owner-Big-Internet@munnari.oz.au Thu Jun 11 20:43:55 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22852; Thu, 11 Jun 1992 20:44:00 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206111044.22852@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA22849; Thu, 11 Jun 1992 20:43:55 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 11 Jun 1992 11:43:28 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: IP address space running out In-Reply-To: Your message of "Mon, 08 Jun 92 16:12:01 EDT." <9206082012.AA20656@ginger.lcs.mit.edu> Date: Thu, 11 Jun 92 11:42:52 +0100 From: Paul Tsuchiya > Every time I hear someone say "but it has bigger addresses" I want > to tear my hair out........ I'm not going to touch this. > > As an (lengthy, theoretical, skip if you don't care about this) > aside, I did sit down and think for a while about exactly what we should be > putting in the packet as the source and destination identifiers. It clearly > shouldn't be the address (which I see as long, unruly, and not needed in > every packet anyway), but some shorter thing. Was I right in making it the > producer/consumer identifier (P/C-id hereinafter), or not? Noel, I don't see how you can so neatly rule out putting addresses in packets. I mean, it's the classic trade-off between big headers and big routing tables, isn't it? How can you ever say that for all eternity the trade-off should be made in favor of big routing tables? I think Yakov recently did a study to see how be the routing tables would have to be in the backbones, and it was pretty bad (Yakov?). As for having IDs in packets that identify end points and not network access points, I absolutely agree. Pip does this, but it ALSO has addresses (or not. It can have VCIs--it is completely flexible on this point). And, the Pip addresses are not long (usually a bit longer than IP addresses, but nowhere near as long as NSAPs). And, Pip addresses are not at all unruly. They are quite polite and orderly, always behave as expected. The forwarding engine has a quite easy time dealing with them. Further, they can hold all kinds of policy info, still without getting too long (unless you have a really long policy source route), and without getting the least bit unruly. You should have a look at the Pip overview, if you haven't already. It was just posted as an ID. PT From owner-Big-Internet@munnari.oz.au Thu Jun 11 20:46:42 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22914; Thu, 11 Jun 1992 20:46:46 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206111046.22914@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA22911; Thu, 11 Jun 1992 20:46:42 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 11 Jun 1992 11:46:26 +0100 To: big-internet@munnari.oz.au Subject: What we really need is ... Date: Thu, 11 Jun 92 11:45:53 +0100 From: Zheng Wang The current IP has problems and has to be replaced. A completely new "IP" would take massive efforts to make it work. Even with CLNP, we still need considerable efforts. The fact is that IP really is the cornerstone of the current Internet, replacing it with any new "IP" requires fundamental changes to all aspects of the Internet. Take CLNP for example, it is very similar to IP. But apart from those that have been addressed in the papers (ie. NAT for global communication, dual IP/CLNP for hosts for interoperaility, modifications to TCP/UDP/FTP/DNS), there are other issues that have to be addressed: 1) subnet routing: subnet routers have to be updated and deal with both old and new protocols. 2) ARP/RARP: have to be updated, and hosts/routers have to deal with both the old and the new. 3) ICMP: have to be updated/replaced. To replace IP, you have to also replace other IP-layer protocols and modify upper protocols that violate the layering rules. Migrating to a new "IP" in effect creates a new "Internet". What we really need is a "IP" which solves the problems yet maintains some degreee of backward compatibility with current IP. Is that possible? The answer is yes. Cheers Zheng From owner-Big-Internet@munnari.oz.au Fri Jun 12 02:24:30 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA02189; Fri, 12 Jun 1992 02:24:37 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA02186; Fri, 12 Jun 1992 02:24:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06814; Thu, 11 Jun 92 12:24:03 -0400 Date: Thu, 11 Jun 92 12:24:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206111624.AA06814@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Paul: I don't rule out putting addresses in packets *in all cases*, any more than I rule out putting routes in packets *in all cases*. The IP SR option has places were it is perfectly valid and useful. On the other hand, you don't put them in every packet. Similarly, there are places - to prevent dependency loops, etc - where you would would to put addresses in the packets. (See sections 5.6 and 6.2 of the Nimrod document for some examples of this.) It's an option, though, not the basic means of identification. The issue of state size is not negligible, I admit. I guess I'm thinking that here in the future, we are going to need flow state information in the routers anyway for resource allocation reasons, and the routing stuff will just piggyback on it. However, I will fall back on something I said before; efficicency is not the only goal in system design. I happen to think that what you get out of flows is worth the cost. I have the latest PIP spec, and find it interesting (one of the few things which does sit back and think about what ought to be where). I will comment when I have absorbed it all. Noel From owner-Big-Internet@munnari.oz.au Fri Jun 12 03:04:17 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA03076; Fri, 12 Jun 1992 03:04:30 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206111704.3076@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA03061; Fri, 12 Jun 1992 03:04:17 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 11 Jun 1992 18:03:53 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: IP address space running out In-Reply-To: Your message of "Thu, 11 Jun 92 12:24:03 EDT." <9206111624.AA06814@ginger.lcs.mit.edu> Date: Thu, 11 Jun 92 18:03:18 +0100 From: Paul Tsuchiya > The issue of state size is not negligible, I admit. I guess I'm > thinking that here in the future, we are going to need flow state information > in the routers anyway for resource allocation reasons, and the routing stuff > will just piggyback on it. However, I will fall back on something I said > before; efficicency is not the only goal in system design. I happen to think > that what you get out of flows is worth the cost. > But it isn't necessarily so that a router needs to keep per host pair flow information just because it is doing resource reservation. For instance, the router can get by with cumulative figures about its current reserved resources. I don't think you should assume that just because we'll be doing flows means that every router in the world must keep track of every host pair that currently happens to be sending stuff through it. PT From owner-Big-Internet@munnari.oz.au Fri Jun 12 04:52:42 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA05716; Fri, 12 Jun 1992 04:52:50 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA05713; Fri, 12 Jun 1992 04:52:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07918; Thu, 11 Jun 92 14:52:16 -0400 Date: Thu, 11 Jun 92 14:52:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206111852.AA07918@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: IP address space running out Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu ... every router in the world must keep track of every host pair that currently happens to be sending stuff through it. But I don't think you absolutely have to have a flow set up for every host pair. See section 6, "Possible Optimizations", particularly 6.1, which deals with this topic. Noel From owner-Big-Internet@munnari.oz.au Fri Jun 12 05:17:50 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA06298; Fri, 12 Jun 1992 05:17:58 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206111917.6298@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA06295; Fri, 12 Jun 1992 05:17:50 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 11 Jun 1992 20:17:19 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: IP address space running out In-Reply-To: Your message of "Thu, 11 Jun 92 14:52:16 EDT." <9206111852.AA07918@ginger.lcs.mit.edu> Date: Thu, 11 Jun 92 20:16:47 +0100 From: Paul Tsuchiya > > ... every router in the world must keep track of every host > pair that currently happens to be sending stuff through it. > > But I don't think you absolutely have to have a flow set up for > every host pair. See section 6, "Possible Optimizations", particularly > 6.1, which deals with this topic. > > Noel Hmmm. I hope everybody understands that the context from which Noel is quoting me above is that I don't think it is necessary for every router to keep track of every host pair. Ie, prepend the words "I don't believe that..." to the quote. Anyway Noel, it seems we are generally agreeing about the need to at least sometimes have full addresses (or policy routes) in headers. I don't think that there is much point in discussing whether packets will have full addresses most of the time or rarely, because with Pip either option is equally accessible. PT From owner-Big-Internet@munnari.oz.au Fri Jun 12 09:20:17 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12670; Fri, 12 Jun 1992 09:20:24 +1000 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12667; Fri, 12 Jun 1992 09:20:17 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA13456; Thu, 11 Jun 92 17:20:10 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA22408; Thu, 11 Jun 92 17:20:09 MDT Message-Id: <9206112320.AA22408@goshawk.lanl.gov> To: big-internet@munnari.oz.au Subject: Re: CLNP Date: Thu, 11 Jun 92 17:20:09 MST From: peter@goshawk.lanl.gov I am curious about this CLNP header size issue. Are people worried about burning bandwidth, or are they worried about handling and looking up the address? Some of the latter issue might be handled by doing a good job of ``profiling'' the address to facilitate address handling in routers. cheers, peter From owner-Big-Internet@munnari.oz.au Fri Jun 12 09:36:25 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13228; Fri, 12 Jun 1992 09:36:33 +1000 (from owner-Big-Internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13224; Fri, 12 Jun 1992 09:36:25 +1000 (from dino@cisco.com) Received: by regal.cisco.com; Thu, 11 Jun 92 16:36:13 -0700 Date: Thu, 11 Jun 92 16:36:13 -0700 From: Dino Farinacci Message-Id: <9206112336.AA07433@regal.cisco.com> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au In-Reply-To: peter@goshawk.lanl.gov's message of Thu, 11 Jun 92 17:20:09 MST <9206112320.AA22408@goshawk.lanl.gov> Subject: CLNP >> I am curious about this CLNP header size issue. Are people >> worried about burning bandwidth, or are they worried about >> handling and looking up the address? A maximum size source and destination NSAP address is equal to the length of an IP header with no options. What's left in a CLNP header is 9 bytes (without options/segmentation). I hope we are not quibbling over 9 bytes. When doing a CLNP prefix route table lookup, the cost is equivalent as doing an IP route table lookup when variable length subnets exist. This is noise guys. Dino From owner-Big-Internet@munnari.oz.au Fri Jun 12 13:59:06 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20572; Fri, 12 Jun 1992 13:59:16 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20564; Fri, 12 Jun 1992 13:59:06 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA01517; Thu, 11 Jun 92 20:58:28 -0700 Date: Thu, 11 Jun 92 14:22:13 EDT From: "William Allen Simpson" Message-Id: <416.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: ReFocus: address translating server I'm getting replies to this summary, when the summary itself hasn't yet arrived! Some of you have much faster pipes from munnari than I have? Unfortunately, the comments all focus on the terminology, rather than the feasability of the server process. Here is a revised summary, based on those comments. ---- I believe we have come to a decision point in the discussion. I would like to focus on the server translation part of the various proposals, to see if there is agreement on the feasability of this approach. - Is this something we want for the short or long term? - Where does the translation for the mapping occur? - Who accesses the server? - Does this require host changes? - How much routing changes? - How does this fit in with other servers; DNS, whitepages, etc? - When are the updates? - What administrative model does this require? - How hard is this? CNAT required a server to translate to/from NSAP addresses. However, Ross is now saying that we won't need such a server -- all hosts will have both IP and CLNP addresses and co-exist until every one has changed to the new scheme. - goes away when the entire internet has converted to CLNP. - no translation at routers, but router must understand both routing schemes. - search for alternative addresses done by host. - requires every IP host to change (eventually). - requires every router to add CLNS routing (which is happening anyway). - uses DNS. - static, updates as DNS does. Interdomain Encapsulation (IP-IP or otherwise) requires a server to locate the other administrative domain. - goes away when entire internet has converted to next version of IP. - mapping at boarder router. - server access from boarder router. - requires minor host changes. - requires minor router changes, but no new protocol. - could use DNS (new record type). - static, updates as DNS does. RFC1335 requires a server for the assignment of local and global addresses. The server will also need to do translation from global to internal addresses, but this was not adequately addressed in the proposal. - will be needed forever. - mapping will be done at the host, and at every router. - server access by host (and possibly every router). - massive host changes, including the requirement of mapping multiple IP addresses to a single interface, and the detection of external addresses on every TCP connection opening, and every UDP packet. - massive routing changes, since the internal net will likely be subnetted, but the external access addresses will not be. Also very rapid address routing changes will need to be supported, since the assigned address can move from machine to machine. - completely new server; DNS used to locate server (new record type). - dynamic, updates when session opens and closes (frequent). For UDP packets, this may be extremely frequent. Nimrod may require a server to translate global host addresses (PC-id's) to network interface addresses (flows, the instantiations of routes). - will be needed forever. - mapping will be done in stages, first boarder routers, then first hop routers, then hosts. - server access from the mapping agent; no more than once per "conversation". - no immediate change to hosts (new IP is separate). - massive routing changes. "That's not a bug, that's a feature!" - can use current DNS. - may be static or dynamic; the "flows" need not change when the path changes. None of the other proposals (CIDR, C#, PIP) requires such a server. However, of these only PIP is a long term solution, and PIP could be done in conjunction with encapsulation or Nimrod. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Fri Jun 12 14:25:58 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21315; Fri, 12 Jun 1992 14:26:28 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA21304; Fri, 12 Jun 1992 14:25:58 +1000 (from kre) To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au Subject: Re: ReFocus: address translating server In-Reply-To: Your message of Thu, 11 Jun 92 14:22:13 -0400. <416.bsimpson@angband.stanford.edu> Date: Fri, 12 Jun 92 14:25:44 +1000 Message-Id: <12754.708323144@munnari.oz.au> From: Robert Elz Date: Thu, 11 Jun 92 14:22:13 EDT From: "William Allen Simpson" Message-ID: <416.bsimpson@angband.stanford.edu> Some of you have much faster pipes from munnari than I have? Its not the pipe that's the problem - munnari has just been overloaded the past few days (unrelated to the big-internet list which contributes just a trivial part). The effect has been though that for some recipients the list is running at up to 3 days behind. I had (even before your emssage arrived) extracted the big-internet messages from our general mail queue (which is quite huge at the minute, courtesy of a site which has some internal mail loop going, but insists on routing all their messages via munnari) and am pushing it all through as quickly as I can. Unfortunately, some of you have anything up to 40 messages to receive and plough through... kre From owner-big-internet@munnari.oz.au Fri Jun 12 21:59:53 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA02666; Fri, 12 Jun 1992 22:00:00 +1000 (from owner-big-internet) Return-Path: Message-Id: <9206121200.2666@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26648; Fri, 12 Jun 1992 17:34:21 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 12 Jun 1992 08:34:00 +0100 To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au Subject: Re: ReFocus: address translating server In-Reply-To: Your message of "Thu, 11 Jun 92 14:22:13 EDT." <416.bsimpson@angband.stanford.edu> Date: Fri, 12 Jun 92 08:33:21 +0100 From: Zheng Wang If rfc1335 needs so many changes as you have described, I would have proposed it in the first place:-) >RFC1335 requires a server for the assignment of local and global >addresses. The server will also need to do translation from global to >internal addresses, but this was not adequately addressed in the >proposal. I dont understand why on earth a server is needed to translate global addresses to internal addresses. > - will be needed forever. > - mapping will be done at the host, and at every router. Mapping is done at the host only. (maybe you are looking at rfc1335++, which I dont think it is a very good idea as it introduces extra changes). > - server access by host (and possibly every router). Why routers? > - massive host changes, including the requirement of mapping multiple > IP addresses to a single interface, and the detection of external > addresses on every TCP connection opening, and every UDP packet. What is this to do with TCP/UDP? We are talking about IP. RFC1335 requires a dual interfaces to receive IP packets with both extern and intern addresses (as if it is multi-homed IP). > - massive routing changes, since the internal net will likely be subnetted, > but the external access addresses will not be. Also very rapid address > routing changes will need to be supported, since the assigned address > can move from machine to machine. If external addresses are also subnetted, there is no need for any changes in subnet routers/routing > - completely new server; DNS used to locate server (new record type). The server is likely to co-locate with DNS. RFC1335 is really a simple idea: obtain an external address only when you need to use it. When you have had an external address, you are no different from any current IP host. You solve the problem yourself instead waiting for changes from the top. >None of the other proposals (CIDR, C#, PIP) requires such a server. >However, of these only PIP is a long term solution, and PIP could be >done in conjunction with encapsulation or Nimrod. Surely Pip needs NAT! see Pip docs section 6.0. Cheers Zheng From owner-big-internet@munnari.oz.au Sat Jun 13 01:23:57 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA09186; Sat, 13 Jun 1992 01:23:59 +1000 (from owner-big-internet) Return-Path: Message-Id: <9206121523.9186@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA05613; Fri, 12 Jun 1992 23:33:08 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 12 Jun 1992 14:22:00 +0100 To: big-internet@munnari.oz.au Subject: EIP - a long-term solution for the Internet addressing Date: Fri, 12 Jun 92 14:21:19 +0100 From: Zheng Wang Can we design an internet protocol which provides maximum flexibility to accommodate any addressing schemes (eg. fixed length node id, backbone-based hierarchical NSAP, policy route or routing directive etc), at the mean time, maintains maximum backward compatibility with current IP (so that the transition can be easy)? EIP described in the following note is such an attempt to achieve this. Your comments would be appraciated. Cheers Zheng The Extended Internet Protocol (EIP) So far, three proposals have been put forward as the long-term solutions for Internet adressing and routing: Nimrod, Pip and CLNP. All of the them require that the current IP to be replaced by a completely new "IP". However, as I have said in a previous message that IP really is the cornerstone of the current Internet, replacing it with a new "IP" requires fundamental changes to all aspects of the Internet (eg. routing, routers, hosts, ARP, RARP, ICMP, TCP, UDP, DNS, FTP). Migrating to a new "IP" in effect creates a new "Internet". The development and deployment of such a new "Internet" would take a very large amount of time and effort. To ensure interoperability between old and new systems during the transition period, the updated hosts and subnet routers have to run two sets of protocols in parallel. An updated host also has to determine whether the destination host has been updated or not at the beginning of a connection. Here we present a solution called Extended Internet Protocol (EIP). EIP does not propose any new addressing schemes but a framework in which any addressing schemes, such as those proposed in Nimrod, Pip, NSAP, and CityCodes, can be accommodated. The goal of EIP is to maintain maximum backward compatibility with current IP. It can substantially reduce the modifications to current systems and ease the difficulties in transition. EIP has a number of very desirable features: 1) EIP expands the address space, yet maintains maximum backward compatibility with current IP. 2) EIP can accommodate different addressing and routing architec- tures such as fixed or variable length addresses, multi-level addressing, hierarchical routing and policy routing. It cane be used as a vehicle for any new addressing and routing architec- tures. 3) EIP requires minor modification to the host IP software (ie. a new option), to the DNS (ie. a new resource record type), and to FTP (ie. a command). 4) EIP requires no changes to all assigned IP addresses and subnet structures in local are networks. 5) EIP requires no modifications to ARP, RARP, ICMP, TCP/UDP check- sum. In the note, IP refers to the current Internet Protocol and EIP refers to the Extended Internet Protocol (EIP is pronounced as "ape" - a step forward in the evolution:-). The goal of EIP is to provide maximum flexibility to accommodate any new addressing scheme and at the meantime maintain maximum backward compatibility with current IP. EIP can be viewed as an extended version of IP. Before we describe the EIP header format, let us first look at the evolution from IP to EIP. EIP is developed from IP by: 1) Creating a new IP option to hold the Source and Destination Net- work IDs. 2) Treating the current IP Source and Destination Addresses as the Source and Destination Host IDs. 3) Using Host IDs only for communications within the same network. An EIP addresses have two parts: the EIP Host ID and the EIP Network ID. The Network ID identifies a particular network and the Host ID identifies a particular host on the network. The current 32-bit IP address space is used for the Host ID only. A new IP option called "EIP Option" is created to hold the Network ID. Using an option to encode the Network ID is the key idea behind the EIP; it provides a flexible way of accommodating arbitrary addressing schemes while maintaining maximum backward compatibility. Because EIP follows the syntax of IP, the modifications required to current Internet systems are greatly reduced. The semantics of the Network ID encoded in the EIP Option are deter- mined by the addressing scheme used and is not discussed in this paper. Since EIP Option has a variable length, the Network ID can accommodate any addressing schemes. It can be a fixed length node ID, or a fixed length path ID, or a variable length backbone-oriented hierarchical address, or a variable length policy source route, or a routing directive. In fact, it allows multiple addressing schemes co-existence, which may be used for experimenting new addressing schemes in the future. The EIP Option format is illustrated in Figure 1. COPY CLASS NUMBER LENGTH DESCRIPTION ---- ----- ------ ------ ----------- 1 0 10 var EIP EIP Option: Type=138 +--------+--------+--------+--------//---------+----------//------------+ |10001010| length | type | Source Network ID | Destination Network ID | +--------+--------+--------+--------//---------+----------//------------+ Figure 1: EIP Option Format The field "type" specifies the addressing scheme used thus determines how the Network IDs should be interpreted. The fields "Source Net- work ID" and "Destination Network ID" hold the Source Network ID and the Destination Network ID. The EIP packet header consists of the minimal IP header, the EIP Option and other Options. The actual format is shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Host ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Host ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EIP Option | Other Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: EIP Header Format The EIP header differs from the IP header in only two aspects. First, the EIP header has the EIP Option which always follows the minimal IP header. The "Source Network ID" and the "Destination Net- work ID" fields in the EIP Option are used to identify the source and the destination networks. Second, the "Source Host ID" and "Destina- tion Host ID" fields in the EIP header, which correspond to the "Source Address" and "Destination Address" fields in the IP header, are only used to identify the the source and the destination hosts on the respective networks. Other fields in the EIP headers are identi- cal to the corresponding fields in the IP header. For communications within the same network, there is no need to include the Network IDs in the packet. Therefore, the EIP Option which contains the Source Network ID and the Destination Network ID is included in the packet only when the packet is destined to a remote network. In other words, in EIP, when the Source Network ID and the Destination Network ID are omitted in the packet header, it is assumed, by default, that they are both equal to the local net- work. This is an important feature of EIP which ensures the compati- bility of IP and EIP within one network. When EIP is in place, an IP host si able to communicate with any hosts within the same network without any changes. In fact, IP and EIP have a identical header when they are used within one network. The IP header can be viewed as a special case of the EIP header, ie. when communications take place within one network. A full EIP address consists of a Network ID and a Host. However, Network IDs and Host IDs are always manipulated in separate forms. The clear separation of the Network ID and the Host ID in EIP has its advantages: 1) It maintains full compatibility between IP hosts and EIP hosts for communications within one network. Any IP hosts can communi- cate with any EIP hosts in the same network without any modifi- cations 2) It allows the Network IDs to be manipulated more easily When a backbone-based hierarchical addressing scheme is used, a network may have to change its Network ID when its higher level backbone network has been changed and the hosts have to determine which Network ID should be used when their networks have access to more than one backbone network. Now let us look at the modifications to the IP systems that are needed for transition to EIP. Because of the similarity between the EIP and IP, the amount of modifications needed to current systems are substantially reduced. 1) Network Numbers: Each network has to be assigned a new EIP Network ID based on the addressing scheme used. The mapping between the IP network numbers and the EIP Network IDs can be used for translation service (see below). 2) Host Numbers: There is no need for assigning EIP Host IDs. All existing hosts can use their current IP addresses as their EIP Host IDs. New machines may be allocated any number from the 32-bit Host ID space since the structure posed on IP addressing is no longer necessary. However, during the transition, allocation of EIP Host IDs should still follow the IP addressing rule, so that the EIP Host IDs are still globally unique and can still be interpreted as IP addresses. This will allow a more gradual transition to EIP (see below). 3) Translation Service: During the transition period when the EIP Host IDs are still unique, an address translation service can be pro- vided to IP hosts that need communicate with hosts in other net- works. All IP hosts should use the translation server as their default router to outside world. When the translation server receives a packet, it obtains the Destination Network ID by looking up in the mapping table between IP network numbers and EIP Network IDs. The translation server then adds the EIP option with Source and Destination Network IDs into the packet and forwards to the border router. The translation service only applies to out-going packets from IP hosts. There is no need for translation for any in-coming packets. The border routers may act as the translation servers (see below). 4) Border Routers: The new EIP Option has to be implemented and rout- ing has to be done based on the Network ID in the EIP Option. The border routers may be used to provide the translation service dur- ing the transition period. When a border router receive a packet without EIP Option, it looks up the Destination Network ID from the mapping table between IP network numbers and EIP Network IDs. The border router then adds the EIP Option and forwards the packet. 5) Subnet Routers: No modifications are required during the transition period when EIP Host IDs (which equals to the IP addresses) are still globally unique. A subnet router can still determine, by treating the EIP Host ID as the IP addresses, whether a packet is destined to remote networks or not and forward correctly. However, subnet routers eventually have to implement the EIP Option and carry out routing based on Network IDs when EIP Host IDs are no longer globally unique. 6) Hosts: The new EIP Option has to be implemented and routing has to be done based on the Network ID in the EIP Option, or based on the Host ID and subnet mask if subnetting is used. 7) DNS: A new resource record (RR) type "N" has to be added for EIP Network IDs. The RR type "A", currently used for IP addresses, can still be used for EIP Host IDs. RR type "N" entries have to be added and RR type "PTR" to be updated. All other entries remain unchanged. 8) ARP/RARP: No modifications are required. The ARP and RARP are used for mapping between EIP Host IDs and physical addresses. 9) ICMP: No modifications are required. 10) TCP/UDP Checksum: No modifications are required. The pseudo header includes the EIP Source and Destination IDs instead of the source and destination IP addresses. 11) FTP: The "DATA Port (Port)" command has to pass both the EIP Net- work and Host IDs. This command, which specifies a data port other than the default one, is not needed under normal circumstances thus it may be possible to disable this command. From owner-Big-Internet@munnari.oz.au Sat Jun 13 01:36:23 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA09453; Sat, 13 Jun 1992 01:36:42 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA09448; Sat, 13 Jun 1992 01:36:23 +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 AA06932; Fri, 12 Jun 92 08:35:56 PDT Received: from chestnut.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA21928; Fri, 12 Jun 92 08:35:57 PDT Received: by chestnut.Eng.Sun.COM (5.0/SMI-SVR4) id AA06050; Fri, 12 Jun 92 08:35:10 PDT Date: Fri, 12 Jun 92 08:35:10 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9206121535.AA06050@chestnut.Eng.Sun.COM> To: Dino Farinacci Cc: peter@goshawk.lanl.gov, big-internet@munnari.oz.au In-Reply-To: <9206112336.AA07433@regal.cisco.com> Subject: CLNP Content-Length: 197 Dino, It was my understanding that the NSAP addresses were 20 bytes each. Also you should not count out the fragmentation fields. In today's internet LAN's do have different segment sizes. Bob From owner-Big-Internet@munnari.oz.au Sat Jun 13 04:17:03 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13399; Sat, 13 Jun 1992 04:17:19 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13392; Sat, 13 Jun 1992 04:17:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13532; Fri, 12 Jun 92 14:16:33 -0400 Date: Fri, 12 Jun 92 14:16:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206121816.AA13532@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: Re: EIP - a long-term solution for the Internet addressing Cc: jnc@ginger.lcs.mit.edu any addressing schemes (eg. fixed length node id Fixed length node (endpoint's, I call them now) ID's are *not* an addressing scheme! How many times do I have to say this? You can't tell a *damn* thing about where the damn thing is by looking at the ID. That's why it's called an ID! Can we design an internet protocol which provides maximum flexibility to accommodate any addressing scheme... [and] at the [same] time, maintains maximum backward compatibility with current IP (so that the transition can be easy)? This is one of the things that Nimrod can do for you. Some advances in analysis of large scale routing since the time the document was written indicate it might be useful to allow a single phsyical network interface to have multiple addresses (for reasons I don't want to go into here). Since in Nimrod, the address is a whole separate namespace from the network interface address, this turned out to be trivial to do (proving to me the worth of the second namespace). This is the *whole point* of the separate endpoint namespace. This feature, intended to allow parallel operation of two similar address spaces, just with differente area boundaries, etc, could easily be used to allow parallel operation of two entirely separate address spaces. The routing would be sort of SIN like; routers which grok the new address format would efectively form a subset topology, just like the subset of multi-protocol routers which run protocol X for a subset connectivity topology for that protocol. As long as we have the hosts deal only in endpoint id's, we can add on, and swap onto, a whole new addressing and routing system without major upheaval to the hosts (yes, hosts which do fancy policy stuff might be effected, but since we don't know what the policy interface looks like yet, it is hard to say). Since Nimrod phase 0 keeps the current packet formats exactly, and doesn't immediately mandate any changes to the hosts (although see section 7.2 of the Nimrod document), it should match the second part of your wish (backward compatability) completely. Noel PS: Detailed EIP comments to follow. Looks similar to Nimrod (especially the locally significant UID's at the start of 7.3), but the advantage of Nimrod is that you don't have to modify the packet to add the option, which is slow. The flow state in the routers in Nimrod is going to take space, yes, but once it's set up things fly. Memory is cheap, and getting cheaper. We have huge routing tables now, and nobody thinks that is fundamentally wrong. We will be ditching those entirely, replacing them with routes computed on demand, and cached in the flow state. The setup won't be as bad as everyone think; the old ARPANet did setup internally (even though it was offered basically a reliable datagram service), and it was pretty quick. The setup was piggybacked on the first data, which speeded things up. From owner-big-internet@munnari.oz.au Sat Jun 13 04:35:53 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13758; Sat, 13 Jun 1992 04:35:58 +1000 (from owner-big-internet) Return-Path: Message-Id: <9206121835.13758@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA09866; Sat, 13 Jun 1992 01:54:37 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 12 Jun 1992 16:54:00 +0100 To: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Cc: big-internet@munnari.oz.au Subject: Re: CLNP In-Reply-To: Your message of "Fri, 12 Jun 92 08:35:10 PDT." <9206121535.AA06050@chestnut.Eng.Sun.COM> Date: Fri, 12 Jun 92 16:53:28 +0100 From: Jon Crowcroft >It was my understanding that the NSAP addresses were 20 bytes each. Also >you should not count out the fragmentation fields. In today's internet >LAN's do have different segment sizes. Bob and there are as many NSAP allocation schemes as i've had hot dinners... jon ---------> From: Paul Bryant Subject: So you like NSAPS? To: iptag@UK.AC.JNT PB660 IPTAG/92/23 SCIENCE AND ENGINEERING RESEARCH COUNCIL RUTHERFORD APPLETON LABORATORY CENTRAL COMPUTING DEPARTMENT NSAPs P Bryant May 19, 1992 -------------------------------------------------------------- 1 NSAPS This paper surveys how NSAPS are being/will be/may be used with a view to deciding on the use of NSAPS within the CLNS project. The survey is not exhaustive and in some cases the documents may be out of date. Comments are invited and a definitive scheme will follow. 2 Notes on the tables Field lengths suffixed by "x" are in octets otherwise they are decimal digits. Values are enclosed in "(" ")" and are in hexadecimal or decimal depending on the field length suffix. 3 Notes on the use of NSAPs in CLNS NSAPs are used for routing (ISO DP 10589). For this purpose the ID or identifier field is used for ES-IS (end system to router) routing and the preceding 2 octets (area field) is recommended to be left unallocat- ed and eventually used for optimising routing within a routing domain. The NSAP up to the area field is used for IS-IS routing. ISO DP 10589 requires binary encoding. The above two requirements mean that the UK JNT scheme for CONS cannot be used. First, it uses decimal encoding and secondly it does not re- quire the structure demanded by ISO DP 10589. In the case of Rutherford, where the NSAP address for CONS is highly structured and spread over the available NSAP space, there is no hope of utilising it for CNLS. ISO TR 9575 defines 3 levels of routing: * Area - a set of ESs and ISs - this is routed using the ID octets which may well be a MAC address. * Routing Domain - a set of areas connected with IS-IS connections but sharing the same intra-domain routing protocol. This could be a site or a country depending on organisational considerations. * Administrative domain - a set of Routing Domains under single manage- ment. This could be a set of sites or a set of countries. 4 US Gosip US Gosip defines the format below. +-----------+--------------------------------------+ |IDP | DSP | +----+------+----------------------------+----+----+ |AFI | IDI | HO-DSP | ID | SEL| +----+------+----+----+------+----+------+ | | | | |DFI | AA | Rsvd | RD | Area | | | +----+------+----+----+------+----+------+----+----+ | 1x | 2x | 1x | 3x| 2x | 2x| 2x | 6x| 1x| |(47)|(0005)|government wide us | |(47)|(0006)|delegated for DOD use only | +-----+-----+----+----+------+----+------+----+----+ IDP - Initial Domain Part DSP - Domain specific Part AFI - Authority and Format Identifier - defined by OSI IDI - Initial Domain Identifier - allocated by BSI HO - High Order DFI - DSP Format identifier - defined by GOSSIP AA - Administrative Authority - allocated by owner of the IDI Rsvd- Always useful in time of trouble RD - Routing Domain Identifier - allocated by owner of the AA Area- Area identifier - used to help routing ID - System Identifier - follows ISO DP 10589 SEL - NSAP Selector - follows ISO DP 10598 5 ISO 3848/Addendum 2 ISO 3848 defines the format below which is the basis for most schemes of interest. +--------------------------------------------+ |IDP | DSP | +-----------+-------------------+------+-----+ |AFI | IDI | HO-DSP | ID | SEL | +----+------+-------------------+------+-----+ |1x |2x | ? |1-8x | 1x | +----+------+-------------------+------+-----+ All elements in a Routing Domain have the same length ID. All elements in an area usually have the same area address (IDP+HO-DSP) and thus IS systems can easily identify destinations within the area which are routed on ID. If not in the area then the maximum number of digits from the IDP+HO-DSP are matched to route to another IS. (There is some doubt as to whether this statement is true and that a complete match is required). IDP+HO-DSP must be globally unique. 6 OSI NSAP Allocation in the Internet (RFC 1237) The Internet proposal follows US Gosip. +-----------+--------------------------------------+ |IDP | DSP | +----+------+----------------------------+----+----+ |AFI | IDI | HO-DSP | ID | SEL| +----+------+----+----+------+----+------+ | | | | |DFI | AA | Rsvd | RD | Area | | | +----+------+----+----+------+----+------+----+----+ | 1x | 2x | 1x | 3x| 2x | 2x| 2x | 6x| 1x| |(47)|(0005)|(80)| | | | | | | +-----+-----+----+----+------+----+------+----+----+ I have not found out the use of the Domain Format Identifier but suspect that it allows alternative encodings. 7 ANSI X3S3.3 The ANSI formal follows US Gosip apart from the IDP and IDI. +----+------+----------------------------------------+ |IDP | IDI | DSP | +----+------+-----+-----+------+----+------+----+----+ | | | DFI | ORG | Rsvd | RD | Area | ID | Sel| +----+------+-----+-----+------+----+------+----+----+ | 1x | 2x | 1x | 3x | 2x | 2x| 2x | 6x| 1x| |(39)|(840F)| | | | | | | | +----+------+-----+-----+------+----+------+----+----+ This is identical to US GOSSIP apart from IDP/IDI and the renaming of AA as ORG. I do not know what the significance of renaming AA (administra- tive Authority) as ORG (organisation) is. 8 ECMA TR/44, RFC 1195 These documents define the 9 low order octets of the DSP +--------+-----------+--------+ | SNID | SNADD | NSEL | +--------+-----------+--------+ | 2x | 6x | 1x | +--------+-----------+--------+ NSEL=Network Selector - indicates transport layer to select for a given TPDU and is used in OSI IS-IS routing protocol. Why "area" is renamed as SNID, ID as SNADD and SEL as NSEL is not known but NSAPS seem to be a topic where renaming of fields is a popular activity. 9 RARE WG4 recommendations RARE WG4 have defined the formal below. +---------+----------------------------+ |IDP | DSP | +----+----+--------------+-------------+ |AFI | IDI| CDP | CDSP| +----+----+------+-------+-------------+ | | | CFI | CDI | | +----+----+------+-------+-------------+ |1x | 3 |1 (1) | 3 | <=31| |(38)| | (2) | 5 | <=29| | | | (3) | 9 | <=25| | | | | | | |1x | 2x |1 (1) | 3 | <=12x| |(39)| | (2) | 5 | <=11x| | | | (3) | 7 | <=10x| +----+----+------+-------+-------------+ CDP - Country Domain Part CDSP- Country Domain Specific Part CFI - Country Format Identifier CDI - Country Domain identifier Note: it is unclear why the (39) DSP is limited to 14 rather than 17 octets. A second WG4 paper defines the DSP as being a pure addressing hierarchy and omits mention of the CI and CDI. Both papers were written in late 1990 before CLNS became a cult and may be out of date. This paper also mentions the use of ISO DP 10589 as being under develop- ment. 10 Norway CLNS project +-----------+---------------------------------------+ |IDP | DSP | +----+------+--------------+------------------------+ |AFI | IDI | CDP | CDSD | +----+------+------+-------+-------------+-----+----+ | | | CFI | CDI | |ID |NSEL| +----+------+------+-------+-------------+-----+----+ |1x | 2x |1 (1) | 3 | rest |6x |1x | |(39)|(578F)| (2) | 5 | | | | | | | (3) | 7 | | | | | | | (4) | 1 | | | | +----+------+------+-------+-------------+-----+----+ Norway follows WG4 with the addition of a CFI of 4 with CDI of 1. AFI is 39. The terminal 7 octets are 6 for a LAN address and 1 for a network selector NSEL which follows US GOSSIP. 11 Holland CLNS project +-----------+--------------------------------------+ |IDP | DSP | +----+------+-------------+------------------------+ |AFI | IDI | CDP | CDSD | +----+------+------+------+----+----+------+-------+ | | | CFI +CDI | SFI| SDI| ASDI| | +----+------+------+------+----+----+------+-------+ |1x | 3 | 4 | 1 | 4 | 1 | rest | |(38)|(528) | (1 100) | | | (0) | | |1x | 2x | | | | | | |(39)|(528F)| (1 100) | | | (0) | | +----+------+-------------+----+----+------+-------+ SFI -SURFnet format identifier allocated by SURFnet. SDI -SURFnet domain identifier (site) allocated by SURFnet. ASDI - Additional SURFnet domain identifier allocated by SURnet - re- served. If SFI=0 SDI maps an organisation to a number. If SFI=1 SDI is a number that maps onto a network (?). The "rest" is allocated locally. 12 UK CONS +----------+--------------------------------------------+ |IDP | DSP | +----+-----+--------------+----+---------+--------------+ |AFI | IDI | CFI | CDI | ID | SiteCode|SiteAllocation| +----+-----+------+-------+----+---------+--------------+ |1x | 3 |1 | 3 | 2 | 3-6 | rest | |(38)|(826)|(1) | (100) |(00)| | | +----+-----+------+-------+----+---------+--------------+ UK follows roughly WG4 with AFI of 38, CFI of 1 digit containing 1 and CDI of 3 digits containing 100. The CDSD contains 3 fields. First a 2 digit reserved for future use. Second is a variable length site code of between 3 and 6 digits. Third a variable length field allocated by the site. 13 Germany CLNS project +----+------+----------------------------------------------+ |IDP | IDI | DSP | +----+------+------+-----+-----+-----+----+------+----+----+ | | |DE-BT | FI1 | RI |Rsvd | RD | Area | ID | Sel| +----+------+------+-----+-----+-----+----+------+----+----+ | 1x | 2x | 2x | 1x | 1x | 2x | 2x| 2x | 6x| 1x| |(39)|(376F)|(3100)|(01) | | | | | | | +----+------+------+-----+-----+-----+----+------+----+----+ | | |DE_BT | FI1 | RI | RD |FI2 | | +----+------+------+-----+-----+-----+----+----------------+ | 1x | 2x | 2x | 1x | 1x | 2x | 1x | 10x | |(39)|(376F)|(3100)|(02) | | | | | +----+------+------+-----+-----+-----+----+------+----+----+ FI - Format Identifier RI - Regional Identifier RD - Routing Identifier Germany defines two formats The first follows ANSI X3S3.3 with the exception that the DFI and ORG fields are replaced with DE-BT of two octets containing 3100, FI1 of one octet of 01 and R1 of one octet which is a region code. Rsvd is 0. RD defines the site (presumably within the region. The second is for CONS where Rsvd, ID, Sel are replaced by a single field presumably allocated by the site. 14 DECNET Phase V NSAP used for transition. One assumes that after transition this format will become redundant. +-----------+--------------------------------+ |IDP | | +----+------+--------------------------------+ |AFI | IDI | DSP | +----+------+----------------------+----+----+ | | | Loc Area | ID | Sel| +----+------+----------------------+----+----+ | 1x | 4x | 2x | 6x| 1x| |(47)|(0020)|(0013) area 19 | DA |(20)| +----+------+----------------------+----+----+ NSAP for DECNET Phase V after transition (proposal from Dave Kelsey). DA = DECNET phase IV address = AA000400nnnn nnnn = area*1024+node number SEL = 20 hex DECNET transport and session control = 21 OSI transport +-----------+------------------------------------+ |IDP | | +----+------+------------------------------------+ |AFI | IDI | DSP | +----+------+------------------+-----------------+ | | |Pre-DSP | CDSP | +----+------+---+-----+----------------+---+-----+ | | |CFI|CDI | |LocArea|ID | Sel | +----+------+---------+--------+-------+---+-----+ | 1x | 2x | 1 |3 | 0-6x | 2x | 6x| 1x | |(39)|(826F)|(1)|(107)| | | |(21) | +----+-----+----+-----+--------+-------+---+-----+ The CDSP is converted between CFI - Country Format Identifier CDI - Country Domain Identifier ID is recommended to be the ethernet address In this scheme each site or ISO CLNS routing domain is defined by up to 6 octets. This should probably be a site code and could follow the current JNT CONS scheme although codes with odd numbers of digits would have to be padded to an even number. Alternatively all codes could be 3 octets - but see discussion below. 15 NORDUNET Follows US GOSSIP and Internet draft OSI NSAP address format. +-----------+------------------------------------------------+ |IDP | | +----+------+------------------------------------------------+ |AFI | IDI | DSP | +----+------+----+---------+------+---------+----+------+----+ | | |DFI | AA |Revd |RD |Area|System|NSEL| +----+------+----+---------+------+---------+----+------+----+ | 1x | 4x | 1x | 3x | 2x | 2x | 2x| 6x | 1x | |(47)|(0023)|(00)| (00000n)|(0000)| | | | | |NORDUnet backbone (000001)| | (0001) |(01)|MacAdd| | |DK (UNI-C) (000002)| | | |IPAddr| | |FI (FUNET) (000003)| | | |or | | |IS (SURIS) (000004)| | site | |some- | | |NO (UNINETT) (000005)| | | |thing | | |SE (SUNET) (000006)| | | |else | | |NORDUnet DECnet transition| | | | | | | (000007)| | (0001) |DA |MacAdd|SEL | +--------------------------+------+---------+----+------+----+ 16 Switzerland (SWITCH/WG2/DP-91-1)) Switzerland uses the ISO DCC scheme +----------+----------------------------+ |IDP | DSP | +----+-----+--------------+-------------+ |AFI | IDI | CHDP | CHDSP| +----+-----+------+-------+-------------+ | | | CHFI |CHDI | | +----+-----+------+-------+-------------+ |1x | 3 |2 (11)| 2 | <=31| Large organisations |(38)|(756)|2 (21)| 4 | <=29| Intermediate | | |2 (31)| 8 | <=25| Small | | | | | | |1x | 2x |1x(11)| 1x | <=15x| Large organisations |(39)|(756)|1x(21)| 2x | <=14x| Intermediate | | |1x(31)| 4x | <=12x| Small | | |1x(80)| 3x | <=13x| US Gosip DSP users +----+-----+------+-------+-------------+ CHDI - Swiss Domain Identifier CHFI - Swiss Format Identifier The format is compatible with the use of the 9 low order octets with ECMA 117. Switch expect to use CHFI = 11 and CHDI = 11 17 Practical considerations DEC recommend that the ID field is the MAC address of the ES. Their routers provide a means for an ES indicating its MAC address to the IS thus requiring no table maintenance for ESs. Indications are that ISs from other suppliers may not include this facility. A network can be split into a set of "routing domain confederations" within a routing domain. The significance is that the structure within such a confederation is private to the confederation. This reduces the size of the tables needed within the ISs and reduces routing information traffic. In the case of Europe you could consider a department being a confederation within a site, a site being a confederation within a country and a country being a confederation within European. It would appear that there is advantage in a confederation equating with a single IDP HO-DSP combination although there will be many exceptions - for example to take account of DECNET phase IV. A corollary is that a "site code" will be needed for the backbone. The code 0000 is suggested. Apologies to those familiar with JIPS who may find such a comment obvious. Extending this concept a "site code" will be needed (or rather exists) for the European backbone. This code has been donated/loaned from the NORUNET 47 series and GB will need to obtain such a site code for its international IS. The code in use in the CLNS WG4 pilot is: 47.0023.0000.0001.0000.0001.0001.xxxx.xxxx.xxxx.00 Practical experience with JIPS and the above considerations indicate that the CLNS project should follow the JIPS structure with a site being a confederation with a single connection to a backbone confederation of completely interconnected ISs. There should be an international IS form- ing part of an international confederation which may or may not be completely interconnected depending on topological considerations. 18 Comment The options for NSAPs for the CLNS project are limited. The use of an AFI of 47 is essential if the DECNET community is to be accommodated. The use of the AFI should be on an interim basis pending the completion of the transition from DECNET phase IV to phase V. A very rough estimate is that it will be needed for two years. On the longer term an AFI of 47 or 39 could be used. 39 has advantages as it follows the philosophy of NSAPs being structured on a country basis. The use of 47 would involve the application for an address space on the lines adopted by NORDUnet. On a world wide basis this would merely lead to an alternative set of country codes. The reason for NORDUnet's decision is to follow RFC1237 which in turn follows US Gosip. However Country Code (DCC) subdomain will be common in the international Inter- net." and goes on to refer to the ANSI X3 proposal. It is an interesting argument as to whether 47 or 39 should be used and on balance I prefer 39. The choice will only be apparent in retrospect when we see if products depend on which is chosen. There is no option but to follow ISO DP 10598 in structuring the NSAP into essentially two parts - AFI+IDI+HO-DSP for IS-IS routing and ID for ES-IS routing. Routers are unlikely to work with any other scheme. The SEL field does not take part in routing. An "area" would seem to relate best to a site although there seems no good reason why a site should not be composed of a number of areas - it probably depends on local circumstances. The "routing domain" and "administrative domain" could relate to GB although it could be argued that the world wide academic networks (or just European networks) could be an administrative domain. In principle the structure of the ID field is a local matter except that its length has to be uniform within the routing domain. The popular choice for the length of ID (1<=ID<=8) is 6 octets since it is antici- pated that this will contain the MAC address of the end system. This goes counter to the view that an NSAP should be independent of the underlying protocols - but ISO DP 10598 already undermines this philoso- phy by overtly using the structure of the NSAP for routing. To go against this may be to put the UK in a unique and lonely position. We have the situation where the best choice depends on the availability of products. Thus it is recommended that the ID should be 6 octets and a weak recommendation that it contain the MAC address. It is understood that JNT has obtained an allocation for the binary DCC scheme (39 region) which is 1107 hex (2 octets). Thus we cannot follow UK Gosip and are left with 2 octets for the site (or AA field) rather than 3. The current site JNT codes defined in "UK Academic Community OSI Requirements Note 6" could be used which, apart from 4 or so codes, are 4 or less digits which may be padded to 2 octets. Following US GOSSIP the next 2 octets are reserved and the RD field of 1 octet could be used for subdividing a site into several routing domains. This leads to the structure illustrated below. +-----------+-------------------------------------------+ |IDP | | +----+------+-------------------------------------------+ |AFI | IDI | DSP | +----+------+-------------------------+-----------------+ | | |Pre-DSP | CDSP | +----+------+---+-----+----+------+---+----+-------+----+ | | |CFI|CDI |site|Rsvd |RD |Area|ID |Sel | +----+------+---------+----+------+---+----+-------+----+ | 1x | 2x | 1 |3 | 2x| 2x |2x | 2x | 6x | 1x | |(39)|(826F)|(1)|(107)| |(0000)| | |MAC add|(21)| +----+-----+----+-----+----+------+---+----+-------+----+ This proposal follows closely the DECNET proposal from Dave Kelsey. From owner-Big-Internet@munnari.oz.au Sat Jun 13 12:03:29 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA24369; Sat, 13 Jun 1992 12:03:38 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA24365; Sat, 13 Jun 1992 12:03:29 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA06526 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 13 Jun 1992 12:03:27 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA00711; Sat, 13 Jun 92 12:03:26 EST Message-Id: <9206130203.AA00711@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: ReFocus: address translating server In-Reply-To: Your message of "Fri, 12 Jun 92 08:33:21 +0100." <9206121200.2666@munnari.oz.au> Date: Sat, 13 Jun 92 12:03:25 +1000 From: Bob Smart >I dont understand why on earth a server is needed to translate >global addresses to internal addresses. > > > - will be needed forever. > > - mapping will be done at the host, and at every router. > >Mapping is done at the host only. (maybe you are looking at >rfc1335++, which I dont think it is a very good idea as it >introduces extra changes). rfc1335+ was a note I wrote about how to extend rfc1335 so that: (a) outsiders can call in to a host that doesn't currently have an external IP address allocated; and (b) external people can find out the domain name of a machine masquerading behind a dynamically allocated address. It is orthogonal to whether you do dynamic address allocation by conversion or by hosts acquiring second IP addresses or both. Either way if you do dynamic address allocation you have to have a server to allocate the dynamic addresses. Even though the idea of using IP-over-IP for the second IP address makes rfc1335 quite easy to implement, still there are many machines that will never get that software. I guess the question is: how much backward compatibility do we demand. If its 100% then bare rfc1335 won't cut it. If it's less then perhaps we don't need anything like rfc1335. By the way I now think that all IP-to-IP address translation is a bad idea. The reason I thought it was necessary was that many sites, particularly new ones, are and will be at the ends of links which are IP links and won't be upgraded quickly to multi-protocol. However this was dumb since we can (temporarily) run any other new protocol using an IP-based link layer (encapsulation). NewIP-to-IP translation is necessary. It is also sufficient. So let's not do more. Of course we still need to give new sites a Class C so we can link them into the Internet even if all we do with it is run NewIP-over-IP to get to them to do NewIP-to-localIP address translation. Given that the site will have the Class C there is nothing to stop them using RFC1335 or simpler schemes as well, but it is not a crucial element. Bob Smart From owner-Big-Internet@munnari.oz.au Sun Jun 14 03:32:40 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13744; Sun, 14 Jun 1992 03:32:52 +1000 (from owner-Big-Internet) Return-Path: Received: from SPECTRUM.CMC.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13712; Sun, 14 Jun 1992 03:32:40 +1000 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA15220; Sat, 13 Jun 92 09:56:36 PDT Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: EIP - a long-term solution for the Internet addressing Message-Id: <1992Jun13.165627.15182@spectrum.CMC.COM> Organization: CMC (a Rockwell Company), Santa Barbara, California, USA References: <9206121523.9186@munnari.oz.au> Date: Sat, 13 Jun 92 16:56:27 GMT Apparently-To: Big-Internet@munnari.OZ.AU In article <9206121523.9186@munnari.oz.au> Z.Wang@cs.ucl.ac.uk (Zheng Wang) writes: >11) FTP: The "DATA Port (Port)" command has to pass both the EIP Net- > work and Host IDs. This command, which specifies a data port other > than the default one, is not needed under normal circumstances thus > it may be possible to disable this command. The port command is used by every UNIX implementation that I know of, during every "get" (RETR) command. Since this is a problem for every proposed migration scheme, it would behoove each of us to immediately schedule a fix for this problem in all the software implementations over which we have control. I think that the PORT command is required for the three-party FTP model to work right. Whether the correct fix for this is a renamed PORT command with extended syntax, or it is a new application protocol altogether, I leave to others to discuss. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 From owner-Big-Internet@munnari.oz.au Mon Jun 15 19:34:23 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA03815; Mon, 15 Jun 1992 19:34:29 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206150934.3815@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA03812; Mon, 15 Jun 1992 19:34:23 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 15 Jun 1992 10:33:54 +0100 To: Big-Internet@munnari.oz.au Subject: FTP PORT command Date: Mon, 15 Jun 92 10:33:10 +0100 From: Zheng Wang >The port command is used by every UNIX implementation that I know of, >during every "get" (RETR) command. Since this is a problem for every >proposed migration scheme, it would behoove each of us to immediately >schedule a fix for this problem in all the software implementations over >which we have control. I have not looked at the UNIX code so I dont know that details of the usual implementation. From the FTP spec, the command is used to surpress the default port and is not used in normal operation. Sections from FTP spec RFC 959: DATA PORT (PORT) The argument is a HOST-PORT specification for the data port to be used in data connection. There are defaults for both the user and server data ports, and under normal circumstances this command and its reply are not needed. ^^^^^^^^^ If this command is used, the argument is the concatenation of a 32-bit internet host address and a 16-bit TCP port address. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A port command would be: PORT h1,h2,h3,h4,p1,p2 where h1 is the high order 8 bits of the internet host address. From owner-Big-Internet@munnari.oz.au Mon Jun 15 20:25:20 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA04932; Mon, 15 Jun 1992 20:25:49 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA04908; Mon, 15 Jun 1992 20:25:20 +1000 (from kre) To: Zheng Wang Cc: Big-Internet@munnari.oz.au Subject: Re: FTP PORT command In-Reply-To: Your message of Mon, 15 Jun 92 10:33:10 +0100. Date: Mon, 15 Jun 92 20:25:11 +1000 Message-Id: <13105.708603911@munnari.oz.au> From: Robert Elz Date: Mon, 15 Jun 92 10:33:10 +0100 From: Zheng Wang From the FTP spec, the command is used to surpress the default port and is not used in normal operation. It is used - the reason is that if its not used then you need to delay in TIME-WAIT state (for 2 minutes or something) between transfers, as otherwise they could appear to be part of the same transfer (possible late delayed packets, see the TCP spec). To avoid this, all sane FTP's use "PORT" for all data transfers so that the same port number isn't used for successive file transfers, so the tcp connections are distinguishable, and there is consequently no need to delay. Making PORT work is essential. That or somehow find some way around it, which would probably mean changing TCP, which I assume is not on the agenda right now. kre From owner-Big-Internet@munnari.oz.au Mon Jun 15 22:00:50 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA07099; Mon, 15 Jun 1992 22:01:14 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA07094; Mon, 15 Jun 1992 22:00:50 +1000 (from kre) To: Zheng Wang Cc: big-internet@munnari.oz.au Subject: Re: ReFocus: address translating server In-Reply-To: Your message of Fri, 12 Jun 92 08:33:21 +0100. Date: Mon, 15 Jun 92 22:00:39 +1000 Message-Id: <13131.708609639@munnari.oz.au> From: Robert Elz Date: Fri, 12 Jun 92 08:33:21 +0100 From: Zheng Wang I have rearranged the order of the following two quotes, (which are widely separated in this message). I don't think it alters the nature of the quotes, and it makes this reply easier... I have also not commented on rfc1335 earlier, as while I consider it a good idea to look for ways to enable the internet to survive longer with no radical changes, so that we have more time to properly consider the BIG step, I don't think this one has any realistic hope, or is worth spending a lot of errort on. > - will be needed forever. > - mapping will be done at the host, and at every router. Mapping is done at the host only. (maybe you are looking at rfc1335++, which I dont think it is a very good idea as it introduces extra changes). Probably he was - but that's because Bob Smart's rfc1335+ is the only thing that has a hope of working. Lets assume both a realistic local net (I will use the one here at the University of Melbourne as an example), and the original rfc1335 where the host (only) is aware of the remapping. Now lets assume that my workstation (which would not have a global class C address) wants to send outside my local net. To do that, my workstation talks to the EASS server, has a global address allocated, and sends from that address to the remote host. So far, all fine - but to be useful, the remote server is probably going to need to send something back - now in theory, this is not difficult, it has my workstation's new global address, and either has that net number in its routing tables, or can use a default route to get to it - the packet will get back to the university's external gateway without any problems. But now we have a difficulty - we have this number, and perhaps one of a hundred or so internal nets, connected via a myriad of routers of one kind or another. Just how do you expect the external gateway to locate my workstation in all that mess? It would be easy if we had just one giant bridged ethernet, and the gateway could simply ARP for the address, but we don't, and as that isn't an attractive model for building a net, one shouldn't assume that that's the way the world should look. There is simply no way to divide up a class C net number to allow routing on it in our environment - to subnet it, and allocate internal subnets would allow at most 62 subnets, with just 2 addresses available on each of the subnets (doing traditional subnetting, using traditional IP rules, so we don't have to make extensive changes, which is the aim of this). Variable length subnetting could trade off some subnets for extra allocatable numbers on some of the subnets, but its still simply not enough - so there's simply no way that internally routing parts of a class C could work. 254 numbers is probably enough - I doubt more than that number of hosts here would ever want to be talking to the world at one time - perhaps if the subnets were allocated dynamically, we could manage it that way - but that would mean teaching the routers to learn about "pseudo-subnets" that come and go at short notice. A solution to this is to have the external router be the one that knows about the external addresses - either alone (which gets tricky with things like the ftp port command) or in conjunction with the host - then the router either translates the addresses, and routes within the university using our notional local class A net, or it encapsulates the packets using the global IP address inside ones using the internal address, so they can be routed though our internal net to my workstation. Others have said this all before, though perhaps more briefly, but you don't seem to have addressed this problem at all. If there's a sloution to this that we have all missed, I'm sure we'd all love to hear it. I dont understand why on earth a server is needed to translate global addresses to internal addresses. One easy answer, is that people want to know who is talking to them - logging some meaningless class C address only, one that is likely be reassigned, is no use at all - in an environment like the one you propose, you'd want to log both the class C address (which identifies the owned of the net), and the internal address using it at the time - perhaps as well as the name (though if you control an in-addr.arpa zone, PTR records can be made to say anything - you need the addresses for any kind of reliable logging). But apart from that, which it would be possible to survive without, with some difficulty, if we assume that we are going to have the external router involved in managing the translation, we acquire a new problem. That is, we don't have just one external gateway, and there's no guarantee that the external router selected by external routing policy to return packets to our class C net will be the same one we selected to use to transmit packets based on our internal routing policy. Without that, the router, when it sees an incoming packet addressed to the internal class C net is going to need a way to translate that into our internal class A address in order to forward the packet to us. Restricting connections to have only one external router is not a viable option, any site seriously interested in conenctivity is likely to want some kind of hot standby in case the "usual" router crashes, even if there is only one usual point of entry. Personally I suspect that its not really worth the effort to even begin to think of solutions to these problems, using the time on something more likely to both succeed, and be politically acceptable, would be considerably more useful. kre From owner-Big-Internet@munnari.oz.au Mon Jun 15 22:57:09 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA08769; Mon, 15 Jun 1992 22:57:13 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA08765; Mon, 15 Jun 1992 22:57:09 +1000 (from kre) To: Big-Internet@munnari.oz.au Subject: Where are we at with C# ? Date: Mon, 15 Jun 92 22:57:00 +1000 Message-Id: <13178.708613020@munnari.oz.au> From: Robert Elz There have been no comments on that proposal for some time now. I suspect that means that its as done as it ever will be. For this to be useful, it needs to be pushed through the standards process as soon as possible. Noel - what's the next step, can this be made into a proposed standard RFC relatively quickly? kre From owner-Big-Internet@munnari.oz.au Tue Jun 16 00:17:35 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA11694; Tue, 16 Jun 1992 00:17:53 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206151417.11694@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA11676; Tue, 16 Jun 1992 00:17:35 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 15 Jun 1992 14:36:33 +0100 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: ReFocus: address translating server In-Reply-To: Your message of "Mon, 15 Jun 92 22:00:39 +0900." <13131.708609639@munnari.oz.au> Date: Mon, 15 Jun 92 14:35:50 +0100 From: Zheng Wang >Lets assume both a realistic local net (I will use the one >here at the University of Melbourne as an example), and the >original rfc1335 where the host (only) is aware of the remapping. Your concern over subnet routing was raised by Denis and discussed in the ietf list. The solution is: 1) If your network would like a Class C number but it has run out, you could use a Class C# number and rfc 1335. You can do similar subnetting to both the Class C# number and the internal number to make the subnet routing easier. 2) If your network would like a Class C# number, you may request a Class C# number. But if you dont do subnetting, you may also use a Class C number and rfc1335. >One easy answer, is that people want to know who is talking >to them - logging some meaningless class C address only, one >that is likely be reassigned, is no use at all - in an >environment like the one you propose, you'd want to log The DNS needs to be modified to provide EASS service and to update DNS mapping when an address is alloocated and de-allocated. The question is when we can get a long term solution in place. If we can have a long term solution in place before 32-bit space runs out, C# and supernetting offers solutions to make good use of the remaining IP addresses the 32-bit space. If we cannot have a long term solution in place before 32-bit space runs out. RFC1335 offers an option to extend the space beyond the 32-bit space. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Jun 16 00:42:33 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12211; Tue, 16 Jun 1992 00:42:54 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12208; Tue, 16 Jun 1992 00:42:33 +1000 (from kre) To: Zheng Wang Cc: big-internet@munnari.oz.au Subject: Re: ReFocus: address translating server In-Reply-To: Your message of Mon, 15 Jun 92 14:35:50 +0100. Date: Tue, 16 Jun 92 00:42:24 +1000 Message-Id: <13218.708619344@munnari.oz.au> From: Robert Elz Date: Mon, 15 Jun 92 14:35:50 +0100 From: Zheng Wang The DNS needs to be modified to provide EASS service and to update DNS mapping when an address is alloocated and de-allocated. Yes, I know that you can do that - the point was that logging reversed mapped names is often not enough - its OK if all you want is a clue, but if you want real information you have to log the remote IP address, and with rfc1335 that would mean both the global (class C, and meaningless) address, and the local internal one inside the remote site - as with that one you can tell the remote management just which node is the one that is really bothering you. The question is when we can get a long term solution in place. Oh - I think I have mis-understood the purpose of rfc1335. I had assumed that it was intended to be something to allow the net to survive past class B's running out. If you're assuming to make it work then we need C# to exist as well, which I think now that you're doing, and that rfc1335 is to survive past complete exhaustion of the 32 bit address space, then I really don't think we need to worry about it. There will be lots of C# addresses available, enough to last for a long time, and as long as we get them out into the world quickly enough (ie: support starts to be rumoured in products at least sometime this year, so it starts appearing sometime next year) we should still have enough B's left to last for a long time for the sites that really need them. With the current work in progress, finding a replacement for IP within the lifetime of the 32 bit space should be possible. If it doesn't happen, I suspect the net will have collapsed due to routing overload - that's likely with the current architecture well before we ever get very close to running out of 32 bits - and 1335 doesn't help at all with that. kre From owner-Big-Internet@munnari.oz.au Tue Jun 16 00:47:14 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12400; Tue, 16 Jun 1992 00:47:22 +1000 (from owner-Big-Internet) Return-Path: Received: from nsco.network.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12396; Tue, 16 Jun 1992 00:47:14 +1000 (from jmh@anubis.network.com) Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA11611; Mon, 15 Jun 92 09:48:52 -0500 Received: from petunia.network.com by anubis.network.com (4.0/SMI-4.0) id AA26372; Mon, 15 Jun 92 09:46:13 CDT Date: Mon, 15 Jun 92 09:46:13 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9206151446.AA26372@anubis.network.com> To: big-internet@munnari.oz.au Subject: Re: EIP I have three immediate reactions to the EIP proposal: 1) Option processing is expensive and slow in most routers. As such, requiring every backbone packet to have special options, and have all of the routing process based on them, is going to slow down the backbone routers. 2) EIP is only useful primarily useful when host ids have only local significance. It will be very important that ALL routers have been cut over before that date, since due to the migration approach, problems will occur otherwise which are strange and difficult to diagnose. In fact, it is not clear that you can transition to local addresses for anyone until everyone has the EIP router support everywhere. 3) Having routers add options is a very bad idea. It is extremely slow, and very error-prone. It also violates much of the spirit of IP. I would rather encapsulate, and I hate encapsulation. Joel M. Halpern jmh@network.com Network Systems Corporation From owner-Big-Internet@munnari.oz.au Tue Jun 16 01:14:21 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12991; Tue, 16 Jun 1992 01:14:39 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206151514.12991@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12977; Tue, 16 Jun 1992 01:14:21 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 15 Jun 1992 15:32:31 +0100 To: Robert Elz Cc: Big-Internet@munnari.oz.au Subject: Re: FTP PORT command In-Reply-To: Your message of "Mon, 15 Jun 92 20:25:11 +0900." <13105.708603911@munnari.oz.au> Date: Mon, 15 Jun 92 15:31:48 +0100 From: Zheng Wang >It is used - the reason is that if its not used then you need >to delay in TIME-WAIT state (for 2 minutes or something) >between transfers, as otherwise they could appear to be >part of the same transfer (possible late delayed packets, >see the TCP spec). Yes, you are right. The DATA PORT (PORT) is used in two circumstances: 1) the user wants the file transfer to involve a third party host. This use of the DATA PORT command requires both IP address and port number. 2) reuse of the connection. This use of DATA PORT command does not use the the IP address. I think the new FTP should separate this two functions: 1) use DATA PORT (PORT) to change the port only (and ignore the first 4 octetsof the replies from old host). 2) use a new command DATA NHOST (ADD+PORT) to set up the third party connection. (this is not widely used, I guess). Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Jun 16 02:06:49 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA14483; Tue, 16 Jun 1992 02:06:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206151606.14483@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA14476; Tue, 16 Jun 1992 02:06:49 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 15 Jun 1992 16:45:28 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: EIP - a long-term solution for the Internet addressing In-Reply-To: Your message of "Fri, 12 Jun 92 14:16:33 EDT." <9206121816.AA13532@ginger.lcs.mit.edu> Date: Mon, 15 Jun 92 16:44:40 +0100 From: Zheng Wang > any addressing schemes (eg. fixed length node id > > Fixed length node (endpoint's, I call them now) ID's are *not* an >addressing scheme! How many times do I have to say this? You can't tell a >*damn* thing about where the damn thing is by looking at the ID. That's >why it's called an ID! Noel, this is only a terminology problem. By addressing schemes, I mean all methods for identifying hosts/host interfaces. Does "any naming and addressing scheme" sound better? Whether we should use Nimrod's endpoint_id/route_setup approach or CLNP/PIP's source_router_in_packet approach is open for debate. Note EIP does not have any implications as to which above approach or any other scheme should be used. It is a vehicle for any naming and addressing schemes. The actual scheme depends on how you interpret the Host ID fileds in the EIP option. > Since Nimrod phase 0 keeps the current packet formats exactly, and >doesn't immediately mandate any changes to the hosts (although see section >7.2 of the Nimrod document), it should match the second part of your wish >(backward compatability) completely. I am looking at a long term solution which should expand the 32-bit space. The Nimrod Phase 0 is a short term solution since it does not expand the 32-bit space. >PS: Detailed EIP comments to follow. Looks similar to Nimrod (especially >the locally significant UID's at the start of 7.3), but the advantage of >Nimrod is that you don't have to modify the packet to add the option, which >is slow. I dont agree that EIP is similar to Nimrod: 1) The core of Nimrod is essentially the endpoind_id/route_set_up scheme. EIP does not touch any addressing/naming schemes. 2) EIP proposes a way of reducing the difficulties of transition. Nimrod does not address this adequately. I have carefully read the Nimrod section 7.3, the transition plan to a long Node ID does not offer any compatibility to current IP. Since it proposed to use a new packet format, it suffers the same problems as other proposals which use new format: 1) run two protocols in parallel 2) have to update the subnet routers along border routers 3) have to update ARP/RARP and run old and new version in parallell. 4) have to update ICMP and run old and new version 5) TCP/UDP pseudo checksum Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Jun 16 02:07:00 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA14497; Tue, 16 Jun 1992 02:07:09 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206151607.14497@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA14484; Tue, 16 Jun 1992 02:07:00 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 15 Jun 1992 17:03:41 +0100 To: jmh@anubis.network.com (Joel Halpern) Cc: big-internet@munnari.oz.au Subject: Re: EIP In-Reply-To: Your message of "Mon, 15 Jun 92 09:46:13 CDT." <9206151446.AA26372@anubis.network.com> Date: Mon, 15 Jun 92 17:02:51 +0100 From: Zheng Wang >1) Option processing is expensive and slow in most routers. As such, > requiring every backbone packet to have special options, > and have all of the routing process based on them, is going > to slow down the backbone routers. The EIP Option is an option from the IP point of view. From the EIP point of view, it is not an option. To make expanded the space look like an option to IP host is to maintain compatibility with IP hosts. Since the EIP Option (I have a terminolgy problem again, maybe I should call it EIP expansion in the EIP terminology) follows the minimal IP header, it can be extracted as efficiently as other fixed field. >2) EIP is only useful primarily useful when host ids have only local > significance. It will be very important that ALL routers have > been cut over before that date, since due to the migration > approach, problems will occur otherwise which are strange and > difficult to diagnose. In fact, it is not clear that you can > transition to local addresses for anyone until everyone has the > EIP router support everywhere. I think this is not a property of EIP. All long term schemes proposed so far require updating all router. What is special with EIP is that it only requires updating border routers initally. If you use a new format, you have to update subnet routers as well to make it work. Cheers Zheng From owner-big-internet@munnari.oz.au Tue Jun 16 02:33:22 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA15361; Tue, 16 Jun 1992 02:33:35 +1000 (from owner-big-internet) Return-Path: Message-Id: <9206151633.15361@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA14828; Tue, 16 Jun 1992 02:18:19 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 15 Jun 1992 17:17:38 +0100 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: ReFocus: address translating server In-Reply-To: Your message of "Tue, 16 Jun 92 00:42:24 +0900." <13218.708619344@munnari.oz.au> Date: Mon, 15 Jun 92 17:16:51 +0100 From: Zheng Wang >Yes, I know that you can do that - the point was that logging >reversed mapped names is often not enough - its OK if all you >want is a clue, but if you want real information you have to >log the remote IP address, and with rfc1335 that would mean >both the global (class C, and meaningless) address, and the >local internal one inside the remote site - as with that one >you can tell the remote management just which node is the one >that is really bothering you. The mapping of internal address and name is invisible to hosts in other network. If you send a request to a remote DNS server, the mapping you get is always the mapping between the domain name and external address. The DNS will have two entries for a host with a temp extern address. It responds with the mapping of internal/name to alocal request (ie. from a host with the reseved internal number), and responds with the mapping of external/name to request to remote request. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Jun 16 03:07:48 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16381; Tue, 16 Jun 1992 03:07:56 +1000 (from owner-Big-Internet) Return-Path: Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16370; Tue, 16 Jun 1992 03:07:48 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA18039; Mon, 15 Jun 92 10:07:42 -0700 Date: Mon, 15 Jun 92 10:07:41 PDT From: Vince Fuller To: Robert Elz Cc: Zheng Wang , big-internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: ReFocus: address translating server In-Reply-To: Your message of Mon, 15 Jun 92 22:00:39 +1000 Message-Id: Now lets assume that my workstation (which would not have a global class C address) wants to send outside my local net. To do that, my workstation talks to the EASS server, has a global address allocated, and sends from that address to the remote host. So far, all fine - but to be useful, the remote server is probably going to need to send something back - now in theory, this is not difficult, it has my workstation's new global address, and either has that net number in its routing tables, or can use a default route to get to it - the packet will get back to the university's external gateway without any problems. But now we have a difficulty - we have this number, and perhaps one of a hundred or so internal nets, connected via a myriad of routers of one kind or another. Just how do you expect the external gateway to locate my workstation in all that mess? It would be easy if we had just one giant bridged ethernet, and the gateway could simply ARP for the address, but we don't, and as that isn't an attractive model for building a net, one shouldn't assume that that's the way the world should look. At the risk of being labelled a supported of RFC1355 (I'm not) I'll just mention that this is only a minor issue and can be solved with well-known technology - host routes. Use of host routes removes any need to subdivide the class-C at all. --Vince From owner-Big-Internet@munnari.oz.au Tue Jun 16 03:12:33 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16502; Tue, 16 Jun 1992 03:12:40 +1000 (from owner-Big-Internet) Return-Path: Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16498; Tue, 16 Jun 1992 03:12:33 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA18043; Mon, 15 Jun 92 10:12:23 -0700 Date: Mon, 15 Jun 92 10:12:23 PDT From: Vince Fuller To: Robert Elz Cc: Big-Internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: Where are we at with C# ? In-Reply-To: Your message of Mon, 15 Jun 92 22:57:00 +1000 Message-Id: There have been no comments on that proposal for some time now. I suspect that means that its as done as it ever will be. For this to be useful, it needs to be pushed through the standards process as soon as possible. Noel - what's the next step, can this be made into a proposed standard RFC relatively quickly? I am opposed to C# on the basis that if we're going to go to the major effort of change routing protocols and router configurations which C# requires, we might as well go ahead and implement CIDR, since its changes are not that much more difficult and provide a much more general solution to the IP address allocation problem. This was a large part of why I (and others in the ROAD group) came up with CIDR after looking at Noel's "class-E" proposal from long ago. --Vince From owner-Big-Internet@munnari.oz.au Tue Jun 16 04:11:07 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17940; Tue, 16 Jun 1992 04:11:25 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206151811.17940@munnari.oz.au> Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17936; Tue, 16 Jun 1992 04:11:07 +1000 (from kre) Date: Tue, 16 Jun 1992 04:11:07 +1000 From: Robert Elz To: vaf@Valinor.Stanford.EDU Subject: Re: ReFocus: address translating server Cc: Z.Wang@cs.ucl.ac.uk, big-internet@munnari.oz.au Date: Mon, 15 Jun 92 10:07:41 PDT From: Vince Fuller Message-Id: this is only a minor issue and can be solved with well-known technology - host routes. I was half expecting a comment like that - but doing this assumes you're using a routing protocol in which host routes work, and routers that are prepared to pass on houst routes and not ignore them (remembering that the idea is to make minimal changes) - but more importantly, it would require that the host involved start emiting packets belonging to some routing protocol, which isn't something I'd like mevery workstation on my net to be doing at the drop of a hat. No thanks. kre From owner-Big-Internet@munnari.oz.au Tue Jun 16 06:46:47 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21859; Tue, 16 Jun 1992 06:46:53 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206152046.21859@munnari.oz.au> Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21856; Tue, 16 Jun 1992 06:46:47 +1000 (from kre) Date: Tue, 16 Jun 1992 06:46:47 +1000 From: Robert Elz To: vaf@Valinor.Stanford.EDU Subject: Re: Where are we at with C# ? Cc: Big-Internet@munnari.oz.au Date: Mon, 15 Jun 92 10:12:23 PDT From: Vince Fuller Message-Id: I am opposed to C# on the basis that if we're going to go to the major effort of change routing protocols and router configurations which C# requires, I don't believe that C# requires changes to routing protocols - in fact I see this as the major difference between it and CIDR ... C# requires some (minor) changes to the implementations of most routing protocols, but no changes to the protocols themselves. On the other hand, for CIDR we need changes to BGP, EGP, IDPR (maybe, I don't know it), and we need RIP II working. All of that is going to take time, not to implement, but to get through the relevant WG's in a form everyone is happy with. That's time I don't think we have right now. we might as well go ahead and implement CIDR, since its changes are not that much more difficult and provide a much more general solution to the IP address allocation problem. I agree that doing the code to make it work isn't hard, and I certainly agree with a message Tony Li sent back in March that in any case whatever the coding costs are, they are dwarfed by the costs of getting new code out into the world. However, the delay in being able to start on CIDR, waiting for the other WG's do come up with something they're happy with, and then the really big hurdle, or convincing management that implementing new versions of all these protocols is really something that should be done right now - even if its just going to take a couple of days - currently there's no-one else to test the new implementatins against, so yet another bake-off to attend, ... On the other hand, C# is a few changes to a few tests in the code, nothing in any way new, nothing that needs independant testing (local testing will tell if it works or not) - a much easier thing to get management to swallow doing, and releasing, tomorrow, rather than next year I would have thought. Part of the problem is that all this discussion was last March/April, its mid June now, nothing has happened for 2 months at least. Or nothing seems to have happened - with the usage rate of B addresses we just can't afford to wait any longer than is absolutely necessary. Personally, I'd quite like it if there was some way to by-pass the standards process, and make C# a "must implement" full standard at the July IETF, though somehow I don't see the IAB quite jumping on that one. Note - I have no objections at all to CIDR - in fact, just the opposite, I think its a necessary thing to do, I just think it will take too long to get started, and that we can't affort to wait till then. kre From owner-Big-Internet@munnari.oz.au Tue Jun 16 07:39:40 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA23018; Tue, 16 Jun 1992 07:39:55 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA23015; Tue, 16 Jun 1992 07:39:40 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA16241; Mon, 15 Jun 92 17:36:01 EDT Date: Mon, 15 Jun 92 17:36:01 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206152136.AA16241@animal.clearpoint.com> To: kre@munnari.oz.au, vaf@valinor.stanford.edu Subject: Re: Where are we at with C# ? In-Reply-To: Mail from 'Robert Elz ' dated: Tue, 16 Jun 1992 06:46:47 +1000 Cc: Big-Internet@munnari.oz.au >However, the delay in being able to start on CIDR, waiting for the other WG's >do come up with something they're happy with, and then the really big hurdle, >or convincing management that implementing new versions of all these protocols >is really something that should be done right now - even if its just going >to take a couple of days - currently there's no-one else to test the new >implementatins against, so yet another bake-off to attend, ... Another factor that needs to be considered is that CIDR also places the responsibility for handing out addresses with the regionals rather than one organization. I honestly don't know if this major factor or not, but it does incur organizational changes rather than just coding changes. There was also a technical point on supernetting raised by Steve Knowles a while back that I don't recall being resolved (his note was dated Apr 15, I may have simply missed a subsequent message on it): if his company is connected to two different regional, he would want one regional (the backup) to advertise high metric values while his primary would advertise low values. Thus, the two regionals would have to cooperate in some manner for this to be accomplished. >Part of the problem is that all this discussion was last March/April, its >mid June now, nothing has happened for 2 months at least. Or nothing seems >to have happened -... Last I had heard, the IAB had picked someone to study the situation and report back: this was just after the San Diego IETF. >... with the usage rate of B addresses we just can't afford >to wait any longer than is absolutely necessary. While the growth of Class B network numbers may have leveled off a bit, the apparent alternate strategy of assigning multiple C's is causing the routing tables to explode much faster than before. The latter seems to be the more pressing problem right now: the number of nets almost doubled from last May to this (2763 nets vs. 5515). From owner-Big-Internet@munnari.oz.au Tue Jun 16 07:48:52 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA23230; Tue, 16 Jun 1992 07:49:03 +1000 (from owner-Big-Internet) Return-Path: Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA23226; Tue, 16 Jun 1992 07:48:52 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA18685; Mon, 15 Jun 92 14:48:35 -0700 Date: Mon, 15 Jun 92 14:48:34 PDT From: Vince Fuller To: solensky@animal.clearpoint.com (Frank T. Solensky) Cc: kre@munnari.oz.au, Big-Internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: Where are we at with C# ? In-Reply-To: Your message of Mon, 15 Jun 92 17:36:01 EDT Message-Id: Another factor that needs to be considered is that CIDR also places the responsibility for handing out addresses with the regionals rather than one organization. I honestly don't know if this major factor or not, but it does incur organizational changes rather than just coding changes. To paraphrase Milo, this depends on ifyou are talking about "CIDR the book" or "CIDR the movie". By "CIDR the book" I mean full buy-in by regional networks. By "CIDR the movie" I mean just the ability to aggregate network numbers. See below for more details. There was also a technical point on supernetting raised by Steve Knowles a while back that I don't recall being resolved (his note was dated Apr 15, I may have simply missed a subsequent message on it): if his company is connected to two different regional, he would want one regional (the backup) to advertise high metric values while his primary would advertise low values. Thus, the two regionals would have to cooperate in some manner for this to be accomplished. I don't understand how this is any different than the situation now for a multiply-connected site. While the growth of Class B network numbers may have leveled off a bit, the apparent alternate strategy of assigning multiple C's is causing the routing tables to explode much faster than before. The latter seems to be the more pressing problem right now: the number of nets almost doubled from last May to this (2763 nets vs. 5515). CIDR with a single level of hierarchy (i.e. no special handling by regionals) fixes this if the numbering authority is smart enough to hand out multiple class-C's in power-of-two blocks which are bit-boundary oriented. Also, if the NIC does this *now*, CIDR promises a sudden *decrease* in routing information when it becomes deployed (because all of the multiple-class-C cases get collapsed at that point). CIDR may also not be as far off as you think. As we speak, some smart people are already working on at least one router implementation of BGP4 and classless addressing (I can't name names, but maybe they'll volunteer the information). --Vince From owner-big-internet@munnari.oz.au Tue Jun 16 10:37:46 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA28409; Tue, 16 Jun 1992 10:37:53 +1000 (from owner-big-internet) Return-Path: Received: from cruskit.aarnet.edu.au by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26766; Tue, 16 Jun 1992 09:44:47 +1000 (from gih900@cruskit.aarnet.edu.au) Received: by cruskit.aarnet.edu.au id AA12208 (5.65+/IDA-1.3.5 for Big-Internet@munnari.oz.au); Tue, 16 Jun 92 09:44:44 +1000 From: Geoff Huston Message-Id: <9206152344.AA12208@cruskit.aarnet.edu.au> Subject: Re: Where are we at with C# ? To: kre@munnari.oz.au (Robert Elz) Date: Tue, 16 Jun 92 9:44:44 EST Cc: vaf@Valinor.Stanford.EDU, Big-Internet@munnari.oz.au In-Reply-To: <9206152046.21859@munnari.oz.au>; from "Robert Elz" at Jun 16, 92 6:46 am X-Mailer: ELM [version 2.3 PL11] kre writes... > Note - I have no objections at all to CIDR - in fact, just the opposite, I think > its a necessary thing to do, I just think it will take too long to get started, > and that we can't affort to wait till then. I'd strongly agree with the last part of kre's statement - we just simply cannot afford to wait .. but I'd also add the viewpoint that CIDR does not offer any real benefits to us at all. (pause to gather together thoughts..) CIDR assumes a hierarchy of aggregation ability from the local provider up to a regional (continental?) aggregations of such providers - BUT CIDR is a provider oriented tool to reduce the number of routed entries. From the provider perspective this is a step forward. However the Internet works differently from that. My typical experience is that there is a significant time lag (12 - 24 months) between initial request for an Internet network number and a purchasing decision to connect to a wider Internet domain via a provider. In CIDR you are in effect asking the entity to make a purchase decision at the time they request their network number. Now I know that there was some notion of a space provided in the aggregation papers I've read which allows for client acrtions where they wish to delay the decision to select a provider and gt a "neutral" net numbet - BUT the entire aggregation scheme assumed that these cases would be a small fraction of the requested network numbers, and the majority of number requests would be within a provider aggregation space from day 1. I'd contend that the exact opposite is the case. The overall majority of network number allocation requests are coming from entities who in the first instance are wanting to "do the right thing" by using an allocated net number, and at the time of the net request have made NO provider decision. Furthermore the provider decision, when it is made, will be made some months or even 1 / 2 years hence - when in all likelihood the provider environment will be radically different from that which we see today. The overall conclusion I see is that there is no opportunity to use aggregation techniques to simplify the providers' lives. What we will be seeing over the next 12 months is that a significant number of the 40,000 allocated but not currently connected networks will (somehow) enter into the overall Internet routing domain, and a small fraction of the soon to be allocated numbers rather than a large fraction will also enter the domain. Where does this leave CIDR? I would suggest that we have to address the routing issue assuming the current collection of 47,000 already allocated network numbers together with additional nets coming in in an unordered fashion. To sugest that you can address the routing issue by altering our network number allocation mechanisms does not seem to be a reasonable position. From that perspective we have to look at the net number space as a distinct issue, and for that reason it is reasonable to suggest that c# is a provider-neutral allocation mechanism which does have the capability to provide us with (just) enough breathing space to progress into a larger address domain. Geoff Huston From owner-Big-Internet@munnari.oz.au Tue Jun 16 12:43:32 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA02255; Tue, 16 Jun 1992 12:43:44 +1000 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA02244; Tue, 16 Jun 1992 12:43:32 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA04246; Mon, 15 Jun 92 20:43:17 -0600 Received: by goshawk.lanl.gov (4.1/5.17) id AA12924; Mon, 15 Jun 92 20:43:16 MDT Date: Mon, 15 Jun 92 20:43:16 MDT From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9206160243.AA12924@goshawk.lanl.gov> To: big-internet@munnari.oz.au Subject: FTP and RFC 1335 FTP is only one example of where address remapping and passing IP addresses around is in conflict. You also need to look at ONC RPC, OSF RPC, ... Now these are not really part of the Internet Suite of protocols but I bet people are going to get a bit hot under the collar when they can only be used in their local addressing domain. peter From owner-Big-Internet@munnari.oz.au Tue Jun 16 17:51:47 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA11046; Tue, 16 Jun 1992 17:51:54 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206160751.11046@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA11042; Tue, 16 Jun 1992 17:51:47 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 16 Jun 1992 08:51:31 +0100 To: peter@goshawk.LANL.GOV (Peter S. Ford) Cc: big-internet@munnari.oz.au Subject: Re: FTP and RFC 1335 In-Reply-To: Your message of "Mon, 15 Jun 92 20:43:16 MDT." <9206160243.AA12924@goshawk.lanl.gov> Date: Tue, 16 Jun 92 08:50:52 +0100 From: Zheng Wang >FTP is only one example of where address remapping and passing >IP addresses around is in conflict. You also need to look at >ONC RPC, OSF RPC, ... Now these are not really part of the >Internet Suite of protocols but I bet people are going to get a bit >hot under the collar when they can only be used in their local addressing >domain. I dont quite understand what FTP has to do with RFC1335. I see no changes needed to make rfc 1335 work. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Jun 16 19:11:31 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13431; Tue, 16 Jun 1992 19:11:49 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206160911.13431@munnari.oz.au> Received: from sun2.nsfnet-relay.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13416; Tue, 16 Jun 1992 19:11:31 +1000 (from Denis.Russell@newcastle.ac.uk) Via: newcastle.ac.uk; Tue, 16 Jun 1992 10:10:35 +0100 Date: Tue, 16 Jun 92 10:10:18 +0100 Received: from pudding.ncl.ac.uk by ncl.ac.uk; Tue, 16 Jun 92 10:10:18 +0100 To: Zheng Wang , Robert Elz From: Denis.Russell@newcastle.ac.uk Subject: Re: ReFocus: address translating server Cc: big-internet@munnari.oz.au > >Lets assume both a realistic local net (I will use the one > >here at the University of Melbourne as an example), and the > >original rfc1335 where the host (only) is aware of the remapping. > >Your concern over subnet routing was raised by Denis and >discussed in the ietf list. The solution is: > >1) If your network would like a Class C number but it has run out, ^^^^^^^ B, presumably >you could use a Class C# number and rfc 1335. You can do >similar subnetting to both the Class C# number and the internal >number to make the subnet routing easier. > >2) If your network would like a Class C# number, you may >request a Class C# number. But if you dont do subnetting, >you may also use a Class C number and rfc1335. Its not quite as easy as that. The problem is that if you're subnetting internally already, the present routing architecture (in my understanding) means that if any address for external use, C or C#, is to be used across the internal network, then it needs to be subnetted similarly. This devours bits from the smaller C or C#, and leaves little over for "real use". With getting on for 100 departments/subnets as on our campus, that means you need 7 bits for a subnet mask in whatever network you're subnetting. In discussions directly with Jon Crowcroft, I proposed splitting up a class-C into 64 2-bit networks, and then allocating each whole 2-bit network dynamically to an internal host. The hosts would become a router for that 2-bit network as far as the rest of the LAN was concerned. The aim was to use current internal backbone routers with zero modifications. At first I thought it would work, but then I realized that the 2-bit networks are actually subnets, and thus could not be properly routed internally because of the strictly heirarchical relationship of networks and subnetworks. If internal routers could be persuaded to treat these 2-bit networks as full networks rather than as subnets, then I think this would be a reasonable way of handling this internal (to the LAN) problem. Denis PS The above explanation is a little superficial - I could elaborate more if folks were actually interested. Denis Russell email: Denis.Russell@Ncl.AC.UK Computing Laboratory Tel: (+44) 91 222 8243 The University Fax: (+44) 91 222 8232 Claremont Road Telex: 53 65 4 UNINEW G Newcastle upon Tyne NE1 7RU ENGLAND From owner-Big-Internet@munnari.oz.au Tue Jun 16 22:23:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17553; Tue, 16 Jun 1992 22:23:55 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA17541; Tue, 16 Jun 1992 22:23:38 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA25343; Tue, 16 Jun 92 05:23:24 -0700 Received: by us1rmc.bb.dec.com; id AA27402; Tue, 16 Jun 92 08:24:44 -0400 Message-Id: <9206161224.AA27402@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 16 Jun 92 08:24:47 EDT Date: Tue, 16 Jun 92 08:24:47 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 15-Jun-1992 1454" To: "kre@munnari.oz.au"@56585.enet.dec.com, jnc@lcs.mit.edu Cc: dee@ranger.enet.dec.com, big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jnc@lcs.mit.edu Subject: Praise for C#, + Ab suggestion kre, Noel, etc. I think C# is an excellent plan and the best step that can be taken to hold off the router table explosion and extend the life of IP4 while IP6 or whatever is being designed. It should be implemented as soon as practical if not sooner. However, as long as a change is being made in the "Class" structure of current IP addresses, I would like to suggest an additional change that I think would help provide further extension of the life of IP4. In the current climate of a shortage of Class B addresses, it would be probably be almost impossible to get a new Class A address assigned to a network. Yet there are large organizations that could legitimately use a large address space. (The United Kingdom National Health Service, which has over a million employees, has been mentioned in this regard.) Assuming half of the Class A network numbers have been assigned and number 127 is used up as the local loop code, that leaves 63 Class A addresses that might never be used because of arguments about or fear of it being "unfair" to assign such a large part of the address space to any particular applicant (see draft- karrenberg-proposal-00.txt as an example of the extent to which "fairness" is now being raised as an issue). Even if a couple of Class A addresses are permanently held back for potential use as part of various IP/routing transition schemes, that would be 24% of the address space being wasted. By subdiving these Class A network numbers into blocks of 16 Ab (A flat) network numbers, you would get approximately 1000 realisticly assignable network numbers each of which could have up to 2**20-2 hosts. I realize that this change is not as elegant as the C# addition. A C# net can simply be repesented as 16 C nets whereas the situtation is reversed for Ab making it much harder, if possible at all, to get old routers to work directly with Ab nets. Still, if Ab's were allocated so that all those from each block of 16 were on the same backbone and the routers that talked to them understood, things should work. Distant nets that didn't understand would just route to the appropriate backbone based of the A address and the backbone could split up traffic based on the Ab address. There are obviously some difficulties here and I don't want to slow down C#, but I still think Ab would be better than wasting such a hugh fraction of the IP4 address space. Donald -------------- From: 56585::"kre@munnari.oz.au" "Robert Elz" 15-JUN-1992 10:32 To: Big-Internet@munnari.oz.au Subj: Where are we at with C# ? There have been no comments on that proposal for some time now. I suspect that means that its as done as it ever will be. For this to be useful, it needs to be pushed through the standards process as soon as possible. Noel - what's the next step, can this be made into a proposed standard RFC relatively quickly? kre From owner-Big-Internet@munnari.oz.au Wed Jun 17 00:51:15 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22302; Wed, 17 Jun 1992 00:51:27 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA22295; Wed, 17 Jun 1992 00:51:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29292; Tue, 16 Jun 92 10:51:04 -0400 Date: Tue, 16 Jun 92 10:51:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206161451.AA29292@ginger.lcs.mit.edu> To: kre@munnari.oz.au, vaf@valinor.stanford.edu Subject: Re: Where are we at with C# ? Cc: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu after looking at Noel's "class-E" proposal from long ago. Whoa, it's not 'my' class-E proposal; I simply led a discussion at the Atlanta IETF, and brought together some suggestions that had been on the IETF mailing list shortly before. (I'm not trying to escape the blame, merely avoiding snarfing the credit, if any! :-) Noel From owner-Big-Internet@munnari.oz.au Wed Jun 17 02:13:35 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA24218; Wed, 17 Jun 1992 02:13:50 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA24214; Wed, 17 Jun 1992 02:13:35 +1000 (from dee@mosaic.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA09289; Tue, 16 Jun 92 09:13:22 -0700 Received: by us1rmc.bb.dec.com; id AA01659; Tue, 16 Jun 92 12:14:46 -0400 Message-Id: <9206161614.AA01659@us1rmc.bb.dec.com> Received: from mosaic.enet; by us1rmc.enet; Tue, 16 Jun 92 12:14:47 EDT Date: Tue, 16 Jun 92 12:14:47 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 16-Jun-1992 1215" To: rcoltun@ni.umd.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, rcoltun@ni.umd.edu Subject: RE: Re: Praise for C#, + Ab suggestion Rob, Yes, but I think it will take a lot longer to put CIDR into place than such simple class oriented changes as C# and Ab. It's great that they also will work well if/when CIDR is in place but a crisis is rapidly approaching and things need to be done quickly with the KISS (keep it simple) principle in mind. Donald -------------- From: US1RMC::"rcoltun@ni.umd.edu" "Rob Coltun" 16-JUN-1992 10:11 To: ranger::dee Subj: Re: Praise for C#, + Ab suggestion >I realize that this change is not as elegant as the C# addition. A C# net can >simply be repesented as 16 C nets whereas the situtation is reversed for Ab >making it much harder, if possible at all, to get old routers to work directly >with Ab nets. Still, if Ab's were allocated so that all those from each block >of 16 were on the same backbone and the routers that talked to them understood, >things should work. Distant nets that didn't understand would just route to >the appropriate backbone based of the A address and the backbone could split >up traffic based on the Ab address. Hi Donald, The CIDR proposal does not exclude this - in fact works quite well with your proposal. ---rob From owner-Big-Internet@munnari.oz.au Wed Jun 17 03:13:55 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26084; Wed, 17 Jun 1992 03:14:05 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26077; Wed, 17 Jun 1992 03:13:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01513; Tue, 16 Jun 92 13:13:52 -0400 Date: Tue, 16 Jun 92 13:13:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206161713.AA01513@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, kre@munnari.oz.au Subject: Re: Where are we at with C# ? Cc: iesg@nri.reston.va.us, jnc@ginger.lcs.mit.edu It seems (since this was supposed to have been done a while ago, but hasn't yet) that I shall have to break the news that the IESG has decided to recommend against C#, and to go straight on to CIDR. I want emphasize that this is a draft recommendation, and the general consensus of the IETF will, as always, be the last word, but this is what the IESG is going to recommend; a document is in preparation now, to be circulated shortly. I personally can see the arguments of both sides. CIDR is more general, but whereas a single 32 bit quantity used to be sufficient in some cases for carrying routing info, now a full 64 bits will be needed everywhere; this is obviously a substantial change. C# needed a limited number of small changes; CIDR (because of the mask issue) will be more widespread. At this point in time, I cannot personally say I feel, on an engineering basis, that I agree or disagree with the decision between the two options (or even to do one, rather than both). Each scheme has good and bad points, has different goals, and different costs, and it is has to evaluate which is better in an engineering sense, especially as both are intended as only temporary patches anyway. I do feel strongly that it is far more important that we decide on one, and *DO IT*, than continue to debate the merits for an extended period. Leadtimes are long, even for the simplest fix, and needs are becoming pressing. So, I want to see us *quickly* decide (agreement is probably too much to ask for :-) on *one* of the three options and *get on with it*! Even if C# is in fact not deployed, work on it has pointed out a number of the problems that CIDR will face, such as the IN-ADDRR issue. I will say that I am extremely, deeply, personally, upset with the process that encouraged the creation of the C# effort, then stalled it for months while the Road group educated themselves, leaving the C# workers in the dark, etc, etc. The whole original concept of C# was something *very* quick and easy. Yes, it wouldn't be great, but it in no way would have conflicted with the later deployment of CIDR, S-CLNP, CNAT, Nimrod, or anything else. Had it been allowed to proceed to completion as planned, without being derailed by Road and the associated navel-staring, we'd probably have something deployed by now. As things stand, we have squat. Noel From owner-Big-Internet@munnari.oz.au Wed Jun 17 03:35:33 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26838; Wed, 17 Jun 1992 03:35:46 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206161735.26838@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26831; Wed, 17 Jun 1992 03:35:33 +1000 (from jcurran@nic.near.net) To: Geoff Huston Cc: Robert Elz , vaf@valinor.stanford.edu, Big-Internet@munnari.oz.au Subject: Re: Where are we at with C# ? In-Reply-To: Your message of Tue, 16 Jun 92 09:44:44 -0500. <9206152344.AA12208@cruskit.aarnet.edu.au> Date: Tue, 16 Jun 92 13:35:06 -0400 From: John Curran -------- Geoff, Interesting perspective on the implications for an organization trying to obtain an IP address in advance the the connection. I think the situation will come up frequently, but disagree on the overall impact to CIDR's value. See the attached comments. /John From: Geoff Huston Subject: Re: Where are we at with C# ? Date: Tue, 16 Jun 92 9:44:44 EST kre writes... > Note - I have no objections at all to CIDR - in fact, just the > opposite, I think its a necessary thing to do, I just think it > will take too long to get started, and that we can't affort to > wait till then. I'd strongly agree with the last part of kre's statement - we just simply cannot afford to wait .. but I'd also add the viewpoint that CIDR does not offer any real benefits to us at all. (pause to gather together thoughts..) CIDR assumes a hierarchy of aggregation ability from the local provider up to a regional (continental?) aggregations of such providers - BUT CIDR is a provider oriented tool to reduce the number of routed entries. From the provider perspective this is a step forward. However the Internet works differently from that. My typical experience is that there is a significant time lag (12 - 24 months) between initial request for an Internet network number and a purchasing decision to connect to a wider Internet domain via a provider. This is sometimes the case; note that many sites also use any-old-ip-network network until they connect and then seek an official one at that time. In CIDR you are in effect asking the entity to make a purchase decision at the time they request their network number. Now I know that there was some notion of a space provided in the aggregation papers I've read which allows for client acrtions where they wish to delay the decision to select a provider and gt a "neutral" net numbet - BUT the entire aggregation scheme assumed that these cases would be a small fraction of the requested network numbers, and the majority of number requests would be within a provider aggregation space from day 1. I'd contend that the exact opposite is the case. The overall majority of network number allocation requests are coming from entities who in the first instance are wanting to "do the right thing" by using an allocated net number, and at the time of the net request have made NO provider decision. Furthermore the provider decision, when it is made, will be made some months or even 1 / 2 years hence - when in all likelihood the provider environment will be radically different from that which we see today. The best source of this information would be the DDN NIC; a simple comparsion of individual IP network requests versus block IP network requests would indicate what the maximum aggregation could be. I can say that NEARnet has allocated 121 network numbers to members in the last 12 months, and these would only be seen as 7 distinct route entries if CIDR were in place today. /John From owner-Big-Internet@munnari.oz.au Wed Jun 17 07:07:23 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA01823; Wed, 17 Jun 1992 07:07:47 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA01800; Wed, 17 Jun 1992 07:07:23 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA22911; Tue, 16 Jun 92 17:07:08 -0400 Message-Id: <9206162107.AA22911@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 8603; Tue, 16 Jun 92 17:05:19 EDT Date: 16 Jun 92 17:07:00 EDT To: Big-Internet@munnari.oz.au From: Pierre (P.) Fortin Subject: IP address exhaustion... Sender: Pierre (P.) Fortin Greetings all, I have been trying to follow the various discussions on the impending exhaustion of the current IP address scheme. Unfortunately, I have not yet obtained a copy of the Nimrod or CLNP documents... Where can they be found...? For what it's worth, here are some off-the-wall ideas I've been toying with, but would like to toss into the fray prior to spending too much time on them. Hopefully, they'll result in: a) "what a heap of sh*t!", or b) "we discarded them three months ago", or c) "why didn't we think of that...?", or d) "not quite; but that gives me another idea...", or e) other... In any event, I would appreciate knowing which path these are best sent down... Hopefully, they are simple enough to be usable almost immediately... I realize that some of the following may be similar or even identical to previously discussed schemes, but there is just too much information flying around for me to keep it all straight... after all, I only learned to spell TCP/IP less than four years ago... :^) I just read Paul T's Nat document. He goes into much more detail than I do (and for obvious reasons (to me :^)); but I did propose an address translation gateway to my router vendor almost 2 years ago which I have modified for the purposes of this discussion. Originally, I wanted such a gateway for security reasons... Here goes... My idea is slightly different from Paul's, but this may be due to my naivete on certain issues. My experience is limited to one large Class A, a few Class B (being converted to our Class A) and some miscellaneous Class C addresses; all of which interoperate via IGPs vs EGPs... The discussions to date seem to address Class B and C addresses. Being one of the fortunate (of course time will tell if this is true :^) owners of a Class A network, I risk little in making the following suggestions... I note that Class B's, in particular, are being gobbled up, while C# has been proposed with some concerns about the resulting explosion in routing table sizes due to C#... not to mention the eventual exhaustion of even these... Isn't the root of the problem that there are many new organizations wanting to become part of the Internet while AT THE SAME TIME (usually) wanting to be somewhat secure...? Isn't it also true that for every network out there, there is a VERY small subset of users on those networks who need Internet access CONCURRENTLY? It seems to me that, in a perfect world, new members of the Internet could have a Class A address and have a secure or limited gateway (performance comes after functionality in importance; at least from where I sit...). In fact, as John Curran just noted: "many sites also use any-old-ip-network network until they connect and then seek an official one at that time."; in our case, we used Class A network 98 until we obtained our official 47 number... but, we did *want* a Class A address space. I can't believe every reader hasn't dreamt of having a legit Class A at least once... and since one rarely knows for certain how big one's internet will become, why start with a size which will probably require re-addressing down the road...? So the real problem, as I see it, is to grant each organization the LARGEST address space (to be carved up as they see fit and their needs grow) while minimizing the VISIBLE address space that organization needs to present onto the Internet. I say this as the owner of a Class A network which is front-ended by a Class C onto the Internet... This is also in keeping with the fact that new Class A addresses will likely not be assigned; so why not re-use this portion of the address space by enticing people to move there and meet their external connectivity requirements separately... Scanning the "Anonymous FTP List" posted to comp.misc, comp.sources.wanted, alt.sources.wanted, & news.answers produced the following list of Class A addresses currently visible: hp.com 15. dec.com 16. mit.edu 18. harris-atd.com 26. merit.edu 35. stanford.edu 36. I'm sure there are probably others, but there is no way for me to determine precisely which ones are really out there since our routing to others is through default routing... Our own Class A (47) is not, nor will it ever be, advertised to the Internet community. If the same is true of the other Class A networks which are assigned, but not visible (assuming the above six is the *complete* list of VISIBLE Class A nets); then these ideas could be workable... In the current IP address space, Class A nets have the first bit set to zero (0) while all other classes are set to one (1). What would happen if it was decided that addresses with a high-order bit=0, currently called "Class A", were to be treated as "local" addresses? - new users could just pick one "out-of-the-air"; no administration of these addresses would be needed - IP routers, as they are today, would still work (both within and without the organization) - Class A nets would NEVER be advertised on the Internet; so they could be used by anyone. - This should solve the scalability problems *within* an organization. (Even multiple Class A nets could be used...) Future requestors of addresses would not be "stuck" due to the lack of Class B's... - The "localhost" address would still be in the "local" address space. - Routing advertisements of the now local Class A addresses can be restricted via re-distribution access-lists - Routing within the now local Class A networks uses EXISTING router technology (i.e., NO changes). - Removing a few Class A networks from the existing routing tables is NOT going to change the routing-table-size problem - The C# plan could be delayed (or maybe even avoided); this would slow the growth of the routing tables. As can be seen below, the number of Internet visible networks will not change appreciably with this scheme, but the size of individual internets will be humongous when compared to what they have today... - etc... So, HOW do we communicate between machines in different "local" (previously Class A) networks which are not visible on the Internet...? Aside: On our Class A, we have nearly 600 subnets which contain up to 1000 hosts each. With over 30,000 hosts, the average number of *concurrent* sessions to the Internet is about 20-30; well within the constraints of today's Class C-sized network... (Someone has already talked about the issue of a small number of PBX lines serving a larger user population...) I don't think that our needs can be categorically called either typical or atypical; but it seems to me that most organizations would not be constrained by one (or even a few) Class-C-sized address space(s) as their connection to the Internet (then again, I've been wrong before... :^) In that case, use a Class B... Assume that the [now local] Class A users need access to the Internet, their Class A address cannot be used directly, but must be translated to a Class C (now global) address. Crystal-ball: While I refer mainly to Class C addresses, I find it conceivable that over time, Class B addresses _could_ be reclaimed as organizations expand into the new-found space of a "local" Class A network... Also, if work on Dynamic Host Addressing were to proceed in parallel, the reclamation of Class B network numbers could be done by the time *this* idea runs out of Class C space so that the Class B space could be re-allocated as Class C addresses (or a combination of B/C), taking us to a point [on the technology continuum] where addressing as we know it today might no longer be necessary... Besides, with this scheme (assuming no major killers), Class B network addresses could be freed up by simply hiding them behind a [set of] Class C addresses... Back to reality... For the following, imagine that certain Class C addresses only exist WITHIN the confines of specially coded/configured gateways. In other words, this Class C is not subnetted and does not have real nodes outside this gateway. These particular networks need not be separately identifyable from other networks; their only (externally undiscernible) distinguishing feature is that they are virtual in nature. The actual act of translation could be static, dynamic, or a combination of the two... STATIC: This would typically apply to a paranoid organization (like mine) which would predefine which nodes could communicate with the Internet. The translation could be accomplished by a gateway capable of supporting the following configuration (or equivalent) commands: interface ethernet 0 /* "local" network */ ip address 47.104.125.141 255.255.240.0 remap interface [ethernet 1 | serial 0] /* "external" network */ ip address 123.123.123.123 255.255.255.0 remap remap-table 195.104.125.142 192.1.1.[1-71] 47.123.168.60 remap-table 132.111.111.1 192.1.1.[72-74] 47.123.123.130 remap-table 131.147.192.77 192.1.1.75 47.123.123.133 remap-table 131.166.64.18 192.1.1.76 47.123.123.133 This would cause datagrams with: source = 47.104.125.152 and dest = 192.1.1.11 to become source = 192.1.1.11 and dest = 123.123.168.70 on their way out the Internet side of the gateway. Responses from 123.123.168.70 would come in with a destination of 192.1.1.11, but these datagrams would become source = 192.1.1.11 and dest = 47.104.125.142 on their way out the ethernet 0 port. Similarly, 132.111.111.3 (a remote external network) would be remapped via 192.1.1.74 (third in the cluster of 3) to 47.123.123.132... Note that the fourth entry in the remap table has the same internal network address as the third entry; this provides a many to one mapping. DYNAMIC: This would require some additional work, but the gateway configuration would consist of: interface ethernet 0 /* "local" network */ ip address 47.104.125.141 255.255.255.0 remap interface [ethernet 1 | serial 0] /* "external" network */ ip address 123.123.123.123 255.255.255.0 remap remap-table dynamic 192.1.1.[77-254] 47.123.168.60 [The dynamic addresses were chosen so that both "static" and "dynamic" addresses could be allowed to co-exist in these examples...] The problem then becomes: how do we actually do the dynamic mapping? Since we don't want to have the gateway look into DNS response packets, a (modified) DNS server will need to reside within/adjacent to the re-mapping gateway. Actually, this modified DNS server might have to straddle the translation gateway. In addition to responding to the requestor with a pseudo address, the address-translation function needs to be auto-configured with the external/internal address mapping (by a special function in a modified DNS server...?) [Paul covers the DNS issues much better than I can... He also addresses the issue of idle sessions...] Obviously, the "other" end would be a mirror-image of this end... 1.1.1.1-->192.1.1.1---------------->192.2.2.2-->2.2.2.2 1.1.1.1<--192.1.1.1<----------------192.2.2.2<--2.2.2.2 A_T Internet A_T Since the address-translation can be done quickly by caching the address part of the headers, there should not be too much overhead on the gateway... I realize that the above does not address the issue of routing table size; but if there is interest in these comments, and if I am not too far off the mark: the size of the total task would be more manageable. At any rate, even if this was possible for just the "new" Internet members, they would not have to suffer from the lack of Class B space as they would under the current proposals I've seen to date (please don't assume I've seen all proposals; I'm just trying to help...) Just some random thoughts which are hopefully of _some_ use... Best Regards, Pierre Fortin fortinp@bnr.ca (613)763-2598 fax: (613)763-3283 From owner-Big-Internet@munnari.oz.au Wed Jun 17 09:25:01 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA05673; Wed, 17 Jun 1992 09:25:16 +1000 (from owner-Big-Internet) Return-Path: Received: from cruskit.aarnet.edu.au by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA05662; Wed, 17 Jun 1992 09:25:01 +1000 (from gih900@cruskit.aarnet.edu.au) Received: by cruskit.aarnet.edu.au id AA12988 (5.65+/IDA-1.3.5 for big-internet@munnari.oz.au); Wed, 17 Jun 92 09:24:40 +1000 From: Geoff Huston Message-Id: <9206162324.AA12988@cruskit.aarnet.edu.au> Subject: Re: Where are we at with C# ? To: jcurran@nic.near.net (John Curran) Date: Wed, 17 Jun 92 9:24:39 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9206161735.26838@munnari.oz.au>; from "John Curran" at Jun 16, 92 1:35 pm X-Mailer: ELM [version 2.3 PL11] John Curran writes... > The best source of this information would be the DDN NIC; a simple comparsion > of individual IP network requests versus block IP network requests would > indicate what the maximum aggregation could be. I can say that NEARnet has > allocated 121 network numbers to members in the last 12 months, and these > would only be seen as 7 distinct route entries if CIDR were in place today. (discussing the general behaviour of net number allocation and subsequent connection) yes, the best source of information on this would be the NIC. It would be very instructive to see the timelines between allocating a network number to an entity and thhe connection of that network through any provider. I would offer the view that the perspective of Australia and the perspective of Eurpoe may be helpful here, simply because in these cases we see the entire spectrum of network requests - including immediate connection motivated requests and a longer path from establishment of a local IP network and subsequent connection in 12 - 24 months. In tyhe US the latter category would be handled directly by the NIC rather than requesting via a provider in the first instance. SO - more data here would clarify the situation (and yes this may all be too late - but if this is a significant factor then the gains through a general provider-based CIDR hierarchy structure may be far far less than is assumed - the pain may produce little if any benefit to get us through the next 36 months :-( Geoff Huston From owner-Big-Internet@munnari.oz.au Wed Jun 17 12:48:42 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA11295; Wed, 17 Jun 1992 12:48:58 +1000 (from owner-Big-Internet) Return-Path: Received: from jatz.aarnet.edu.au by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA11292; Wed, 17 Jun 1992 12:48:42 +1000 (from pte900@jatz.aarnet.edu.au) Received: by jatz.aarnet.edu.au id AA19824 (5.65+/IDA-1.3.5 for big-internet@munnari.oz.au); Wed, 17 Jun 92 12:48:34 +1000 From: Peter Elford Message-Id: <9206170248.AA19824@jatz.aarnet.edu.au> Subject: Address Translation To: big-internet@munnari.oz.au Date: Wed, 17 Jun 92 12:48:34 EST X-Mailer: ELM [version 2.3 PL11] I have never been involved with the SPAN/HEPnet work that had to struggle with the limitations of DECnet Phase IV addressing to establish a global DECnet, but most of the people that *have* been through this process don't seem to think that it was (is) much fun. Perhaps history has a message for us there ... Peter From owner-big-internet@munnari.oz.au Wed Jun 17 14:03:50 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13402; Wed, 17 Jun 1992 14:03:58 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA11053; Wed, 17 Jun 1992 12:39:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05368; Tue, 16 Jun 92 22:39:17 -0400 Date: Tue, 16 Jun 92 22:39:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206170239.AA05368@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, FORTINP@bnr.ca Subject: Nimrod documents Cc: jnc@ginger.lcs.mit.edu I've had a number of requests for the 'latest' Nimrod documents. Here's a copy (slightly modified) of a message I sent recently on this topic to another list: -------- A number of people have asked me about the status of documents about my Nimrod plan for large scale routing and addressing in the Internet. I was taking the position that I was going to rework the existing document (available as an Internet-Draft) into two smaller and more easily digestable documents, and that people might want to wait until that is done. Also, I have had some more recent thoughts on the general topic of large scale routing and addressing, prompted by conversations with various people, which deserve treatment, but the implications for the Nimrod architecture itself are not large. The existing document was long and complex because it did two only vaguely related things; it contained 1) an analysis of fundamental issues in large scale routing and addressing, and 2) a plan, (including listing possible optimizations and deployment issues) for a particular new routing and addressing architecture for the IP family. I concluded that the length and complexity of the paper could be reduced if I split these two apart. I have now, after starting work on this, concluded that this idea, although good, is not going to reduce the bulk of the Nimrod plan document substantially. The bulk of the existing document is Nimrod material, and it's not going to get much shorter. So, people who want something to read about Nimrod should go back to the existing I-D (draft-chiappa-routing-00.txt). To save extra reading, you can concentrate on sections 3 (particular 3.2 and 3.3*), 4 and skim sections 5, 6, and 7. Noel From owner-Big-Internet@munnari.oz.au Wed Jun 17 16:44:23 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19143; Wed, 17 Jun 1992 16:44:33 +1000 (from owner-Big-Internet) Return-Path: Received: from SPECTRUM.CMC.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA19138; Wed, 17 Jun 1992 16:44:23 +1000 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA19289; Tue, 16 Jun 92 23:43:00 PDT Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: IP address exhaustion... Message-Id: <1992Jun17.064251.19251@spectrum.CMC.COM> To: FORTINP@BNR.CA Organization: CMC (a Rockwell Company), Santa Barbara, California, USA References: <9206162107.AA22911@gateway.bnr.ca> Date: Wed, 17 Jun 92 06:42:51 GMT In article <9206162107.AA22911@gateway.bnr.ca> FORTINP@BNR.CA (Pierre (P.) Fortin) writes: >For what it's worth, here are some off-the-wall ideas I've been toying >with, but would like to toss into the fray prior to spending too much >time on them. [ List of 6 visible class A nets ] There are a couple more. These are the ones, packets from which have been seen on my network in the last couple of months (for each network, I list the lowest IP address from which we have seen traffic): 13.1.64.93 alpha.Xerox.COM : SUN-4/65:UNIX::IpRmt: 15.254.48.2 hpfcla.fc.hp.com : hp9000/375:HP-UX_7.03::IpGwRmt: 16.1.0.2 gatekeeper.dec.com : :::IpGwRmt: 18.24.0.11 EXPO.LCS.MIT.EDU : SUN-3:UNIX::IpRmt: 26.0.0.24 NADC.NAVY.MIL : :::IpRmt: Good old MILNET !! 31.1.0.1 melvyl.ucop.edu : IBM-3090:MVS::IpRmt: 35.1.1.22 melville.merit.edu : :::IpRmt: 36.1.0.2 sweet-gateway.Stanford.EDU : CSC-3:cisco::IpGwRmt: 38.145.32.1 dc.nyc1.pop.psi.net : :::IpGwRmt: 45.0.1.20 dns.shownet.net : :::IpRmt: Twice a year: INTEROP !! But your point remains: There are very few of these visible. I am convinced that if we fix FTP's PORT command, address translation is a viable way to address IP number exhaustion. And the preparatory steps that must be initiated at once (getting IP addresses out of upper-level protocols) are the same that must be taken for a migration to CNLP, or to IP-7. The routing table explosion must be dealt with by some form of hierachy; I think someone used the term "zip code routing". How to encode the "zip code" seems unclear. My favorite candidate is in a source route option. The majority of traffic in the US will travel on a default route to a router on a backbone NAP (network access point). The backbones should only have to know these landmarks. The landmark routers would have to know the internals of their own domain and a nearby routing server should be able to tell you for any IP address which landmark is nearest. For efficiency, the end host should look up the route at connection setup time, and route it through the local landmark and the destination landmark; then the destination host could just invert the source route when responding. For easier migration, the landmark router could insert the source route for any packets that it gets that don't have it already. When I first heard IDPR described, this is what I thought it consisted of. I still think this would be an easy solution. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 From owner-Big-Internet@munnari.oz.au Thu Jun 18 06:34:20 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA10424; Thu, 18 Jun 1992 06:35:32 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA10412; Thu, 18 Jun 1992 06:34:20 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA05106; Wed, 17 Jun 92 16:33:40 -0400 Message-Id: <9206172033.AA05106@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 9044; Wed, 17 Jun 92 16:31:51 EDT Date: 17 Jun 92 16:34:00 EDT To: lars@CMC.COM, From: Pierre (P.) Fortin Subject: IP address exhaustion... a myth? Sender: Pierre (P.) Fortin Lars, [stuff about visible Class A nets] > But your point remains: There are very few of these visible. > I am convinced that if we fix FTP's PORT command, address translation > is a viable way to address IP number exhaustion. And the preparatory > steps that must be initiated at once (getting IP addresses out of > upper-level protocols) are the same that must be taken for a migration > to CNLP, or to IP-7. I guess I must be dense... :^) In the method I posted, I don't see that ANY changes are needed on the existing hosts; from their perspective, they don't even know that *address[only]* translation is occuring at a gateway... > The routing table explosion must be dealt with by some form of hierachy; > I think someone used the term "zip code routing". How to encode the "zip > code" seems unclear. My favorite candidate is in a source route option. I agree about the "routing table explosion", but if a method like the one I posted yesterday is useable, we could at least avoid the additional burden caused by the C# method... > The majority of traffic in the US will travel on a default route to a > router on a backbone NAP (network access point). The backbones should > only have to know these landmarks. The landmark routers would have to > know the internals of their own domain and a nearby routing server > should be able to tell you for any IP address which landmark is nearest. Let's take my posted method a step further... what if there were intermediate address translation gateways (I'm trying to avoid acronyms...) to do yet more address translation...? In the scheme I posted, address translation can occur: - nowhere - at my gateway only - at both my gateway and yours - at our gateways plus N intermediate gateways... Let's see... from RFC1335: Total Allocated Allocated (%) Class A 126 48 54% Class B 16383* 7006 43% Class C 2097151* 40724 2% ----- 47778 * should be 16382 and 2097150 :^) Class A = 16,777,214 hosts max Class B = 65,524 hosts max Class C = 254 hosts max Now, if we ignore the 48 Class A's, we have 47,730 B/C networks allocated for a maximum of 85,519,108,892 hosts. If we assumed that each network, for purposes of communicating to the outside, only needed a Class C sized gateway, but had a Class A internally; then the maximum number of hosts jumps up to 47,730 * 16,777,214 = 800,776,424,220 Just think about it... that's nearly 10 TIMES the currently allocated address space! Then, if we just look at the Class C's ONLY: 2,097,150 * 16,777,214 = 35,184,334,340,100 possible hosts without even invoking the Class B space... Granted there are networks which might need more than 254 gateway addresses but on the whole, can anyone even come with just ONE example network where ALL the hosts talk to ALL the other hosts concurrently? In real life, when I post the traffic numbers from my ~600 subnets to spreadsheet, I have to first sort the traffic numbers in descending packet counts and dynamically build the spreadsheet just to eliminate most of the BLANK cells (at ~A1..Z26) which make up MOST of the subnet-to-subnet traffic. Imagine how many BLANK cells I'd have if I did the same for host-to-host traffic... The point is that, while there are MANY hosts in the Internet, it is not possible for even ONE to communicate with up to 0.01% (generous :^) of the other hosts concurrently. This is why I think that my simplified address translation scheme is workable with very little effort... (almost) > For efficiency, the end host should look up the route at connection > setup time, and route it through the local landmark and the destination > landmark; then the destination host could just invert the source route > when responding. For easier migration, the landmark router could insert > the source route for any packets that it gets that don't have it > already. Sure, source routing is an option, but with intermediate address translation gateways, the Internet itself could be reduced to a collection of gatewayed systems where the IP addresses become nothing more than transient session IDs. Billing? Well, unless I'm missing something here, a modified DNS server (to take care of the address translation setup (or router auto-configuration)) could also snatch the IP accounting data at tear-down... I know : there are problems to be solved re idle/dead sessions; but ain't that why we have academics...? :^) > When I first heard IDPR described, this is what I thought it consisted > of. I still think this would be an easy solution. Oooops, gotta read this one... :^) Well, that's enough squeezing of blood outta this stone for today... :^) :^) > / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM > CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 > Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 Cheers, Pierre Fortin fortinp@bnr.ca (613)763-2598 fax: (613)763-3283 From owner-Big-Internet@munnari.oz.au Thu Jun 18 08:21:49 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12466; Thu, 18 Jun 1992 08:23:15 +1000 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12431; Thu, 18 Jun 1992 08:21:49 +1000 (from swb@nr-tech.cit.cornell.edu) Received: from FALCON.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA27263; Wed, 17 Jun 92 18:21:12 EDT Message-Id: <9206172221.AA27263@mitchell.cit.cornell.edu> To: Phill Gross Cc: big-internet@munnari.oz.au, road@lanl.gov, iesg@nri.reston.va.us, iab@isi.edu Reply-To: swb@nr-tech.cit.cornell.edu Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Phill Gross's message of Wed, 17 Jun 92 18:00:05 -0600. <199206172200.AA25780@home.ans.net> Date: Wed, 17 Jun 92 18:21:10 -0400 From: Scott Brim Phill, personally I think this is downright respectable. I have a couple of small nits with the way the IESG apparently thought things through, but not with the result, and I don't have any details, only this report -- so forget them. A couple of comments: (1) I believe we were tasked with scaling up to 10^9 *domains* not networks (sometimes confusion arises when "network" is used to mean something under a common administration). The difference can be quite significant. (2) please leave vast amounts of time for presentations. For example I can see Ross Callon taking an hour and a half with all the questions he is going to get, and it's very important that everyone get a *thorough* understanding of the alternatives. How about we take a full day, say Tuesday? Maybe even Tuesday and Wednesday. That way there's some time to prepare beforehand and lots of time to work things out afterwards. Scott From owner-big-internet@munnari.oz.au Thu Jun 18 13:41:39 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20571; Thu, 18 Jun 1992 13:42:57 +1000 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12009; Thu, 18 Jun 1992 08:01:02 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA10897 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Wed, 17 Jun 1992 17:59:58 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 17 Jun 1992 17:59:58 -0400 Message-Id: <199206172200.AA25780@home.ans.net> To: big-internet@munnari.oz.au, road@lanl.gov Cc: iesg@nri.reston.va.us, iab@isi.edu Subject: Draft IESG recommendation on ROAD activities Date: Wed, 17 Jun 92 18:00:05 -0500 From: Phill Gross Folks, Below is a draft IESG recommendation on how to follow-up the ROAD activities in the IETF. Please comment. Thanks, Phill Internet-Draft Phill Gross June 1992 IESG Chair IESG Deliberations on Routing and Addressing CONTENTS 1. ABSTRACT 2. ACKNOWLEDGEMENTS 3. BACKGROUND 3.1 The IAB Architecture Retreat 3.2 The Santa Fe IETF 3.3 The ROAD Group 3.4 The San Diego IETF 4. SETTING DIRECTIONS FOR THE IAB/IETF 4.1 Course of Action for CIDR 4.2 Regarding "Bigger Internet Addresses" 4.3 Information and Criteria For "Bigger Internet Addresses" 4.4 Milestones And Timetable For Making a Recommendation for "Bigger Internet Addresses" 5. SUMMARY 6. FOR MORE INFORMATION 7. BIBLIOGRAPHY 1. ABSTRACT This note gives preliminary results from IESG deliberations on Internet routing and addressing issues. It provides a brief background of the ROAD group and related activities in the IETF. It also provides a preliminary report on how the IESG will recommend various routing and addressing issues be pursued in the IAB/IETF. A more complete IESG report and set of recommendations is in preparation. 2. ACKNOWLEDGEMENTS This note draws principally from two sources: the output from the ROAD group, as reported at the San Diego IETF meeting, and on numerous detailed discussions in the IESG following the San Diego IETF meeting. In particular, this preliminary note draws heavily from the fuller IESG report (in preparation, Philip Almquist Editor), which will serve as a recommendation to the IAB. Bob Hinden supplied the original text for the "Criteria For Bigger Internet Addresses" section below. I used an annotated bibliography prepared by Lyman Chapin as the basis for the bibliography in this note. 3. BACKGROUND 3.1 The IAB Architecture Retreat In July 1991, the IAB held a special workshop to consider critical issues in the IP architecture. Of particular concern were problems related to growth and scaling. The IAB felt the issues were of sufficient concern to begin organizing a special group to explore the issues and to explore possible solutions. 3.2 The Santa Fe IETF At the November 1991 Santa Fe IETF meeting, the BGP WG began a concerted exploration of the issues of route aggregation using address masks in BGP. The BGP WG decided to form a separate subgroup to pursue solutions. 3.3 The ROAD Group At the Santa Fe IETF, the initially separate IAB and IETF activities were combined into a special effort, the "Routing and Addressing (ROAD) Group", to look at the key IP issues of scaling in routing and addressing. In brief, the issues involved: - Class B address exhaustion - Routing table explosion - IP address space exhaustion The ROAD group was instructed to report back to the IETF at the San Diego (March 1992). The specific guidelines included minimizing changes to hosts, must be incrementally deployable, and must provide support for 10^^9 networks. The ROAD group was not a traditional open IETF working group. It was always presumed that this one-time special group would lead to the formation of other IETF WGs after its report in San Diego. The ROAD group held several face-face meetings between the November 1991 (Santa Fe) and March 1992 (San Diego) IETF meetings (including several times at the Santa Fe IETF meeting, December 1991 in Reston Va, January 1992 in Boston, and January 1992 in Arizona). There was also much discussion by electronic mail. The group produced numerous documents, which will be made available as Internet-Drafts or RFCs (see Bibliography below. These documents are currently available by anonymous FTP from gated.cornell.edu in directory pub/road.). 3.4 The San Diego IETF As follow-up, the ROAD co-chairs (Peter Ford/LANL and Phill Gross/ANS) reported to the IETF plenary in March 1992 in San Diego. Plus, several specific ROAD-related activities took place during the IETF meeting that week. The Ford/Gross presentation served as a preliminary report from the ROAD group, pending a more complete report still in preparation (Brim92). The basic thrust was: 1) The Internet community needs a better way to deal with current addresses (e.g., hierarchical address assignments for routing aggregation to help slow class B exhaustion and routing table explosion). Classless Inter-Domain Routing (CIDR; also called "supernetting") was recommended. CIDR calls for: - A plan for hierarchical IP address assignment for aggregation in routing - Enhanced "classless" Inter-domain protocols (i.e., carry address masks along with IP addresses) - Inter-Domain routing "Usage documents" for using addressing and routing plan with the enhanced inter- domain protocols, and for interacting with IGPs 2) The Internet community needs bigger addresses for the Internet to stem IP address exhaustion. The ROAD group explored several approaches in some depth. These included "Simple CLNP" (Callon92a), "IP Encaps" (Hinden92), "CNAT" (Callon92b), and "Nimrod" (Chiappa91). Some of these approaches were discussed at the San Diego IETF. However, a final recommendation of a single approach did not emerge. 3) The Internet community needs to focus more effort on future directions for Internet routing and advanced features. Other ROAD-related activities at the San Diego IETF meeting included: - Monday, 8:00 - 9:00 am, Presentation by Peter Ford and Phill Gross, "Internet Routing and Addressing Considerations" - Monday, 9:30-12:00pm, Geographical Addressing and Routing (during NOOP WG session) - Monday, 1:30-3:30pm, Preliminary discussion of a CIDR routing and addressing plan (during ORAD session) - Tuesday, 1:30-6:00pm, Internet Routing and Addressing BOF (to discuss ROAD results and to explore approaches for bigger Internet address space) - Wednesday, 1:30-3:30pm, CIDR Supernetting BOF (joint with BGP WG) - Thursday, 4:00-6:00pm, Summary of ROAD activities in San Diego (by Phill Gross), followed by open plenary discussion. The slides for the Monday presentation (Ford92), slides for the Thursday summary (and notes in the Chair's message) (Gross92), and notes for the other sessions are contained in the Proceedings of the Twenty-Third IETF (San Diego). 4. SETTING DIRECTIONS FOR THE IAB/IETF 4.1 Course of Action for CIDR The IESG accepted ROAD's endorsement of CIDR. The IESG felt that other alternatives (eg, C#, see Solen92) not did provide both aggregation and Class B conservation at comparable effort. The IESG recommends the following course of action to pursue CIDR in the IETF: a. Publish the CIDR overview and guidance document (Fuller92) b. Hold a BOF at the Boston IETF meeting in July 1992 (and, if necessary, form a followup WG) to develop a plan for "IP Address Assignment Guidelines". The IESG considered the creation of an addressing plan to be an operational issue. Therefore, the IESG asked Bernhard Stockman (IESG Operational Requirements Area Co-Director) to lead an effort to develop such a plan. Bernhard Stockman is in a position to bring important international input (Stockman92) into this effort because he is a key player in RIPE and EBONE and he is a co-chair of the Intercontinental Engineering Planning Group (IEPG). Stockman will lead a BOF at the July IETF. This BOF will factor in discussions and proposals at prior RIPE and IEPG meetings. A specific proposal (Rekhter92) has now become the focus of this effort. c. Pursue CIDR extensions to BGP in the BGP WG This activity has already begun at the San Diego IETF meeting. A document has been distributed on the BGP WG mailing list, and should be released as an Internet-Draft prior to the Boston IETF meeting. d. Form a new WG to consider CIDR-related extensions to IDRP (eg, specify how run IDRP for IP inter-domain routing) A proposal for this WG has already been submitted to the IESG. The IESG expects this WG to be able to hold its first meeting at the Boston IETF. e. Give careful consideration to how CIDR will be deployed in the Internet This includes issues such as how to maintain address aggregation across non-CIDR domains and how CIDR and various IGPs will need to interact. Some of these issues will be considered in the WGs already mentioned. However, depending on the outcome of the combined CIDR activities at the Boston IETF, the IESG may recommend forming a "CIDR Deployment WG", along the same lines as the current BGP Deployment WG. 4.2 Regarding "Bigger Internet Addresses" The IESG reviewed the various approaches described by the ROAD group -- e.g., "Simple CLNP" (Callon92a), "IP Encaps" (Hinden92), "CNAT" (Callon92b), and "Nimrod" (Chiappa91). The "Simple CLNP" approach has potential advantages and perhaps enjoyed more support than other approaches. However, the consensus view in the IESG was that the full impact of transition to "Simple CLNP" (or to any of the proposed approaches) had not yet been explored in sufficient detail to make a final recommendation at this time. The feeling in the IESG was that such important issues as - impact on operational infrastructure, - deployment of new routing protocols, - assignment of new addresses, - effect of supporting new protocols, such as for addres resolution, - effect on network management and security, and - the costs to network operators and network users who must be trained in the architecture and specifics of any new protocols needed to be explored in more depth before a decision of this magnitude should be made. At first the question seemed to be one of timing. At the risk of oversimplifying some very wide ranging discussions, many in the IESG felt that if a decision *had* to be made immediately, then "Simple CLNP" might be their choice, but they would feel much more comfortable if more detailed information was part of the decision. Then, after exploring Simple CLNP in more depth, an attempt to develop a better understanding, the IESG became concerned that the significant changes required in hosts would make the transition complex, not "simple". For example, an ostensibly simple transition scheme has been proposed for Simple CLNP -- install dual stacks in all new hosts and eventualy decommision the IP stack. But the IESG was concerned that this lack of support for the very large installed base of older unconverted IP hosts might lead to partitioning the Internet into 2 classes -- the newer CLNP-only hosts and older IP-only hosts. Given this limited understanding of the potential complexity, the IESG felt that additional information was needed about Simple CLNP. During the period to gather more information about Simple CLNP, we felt that we have everything to gain by also exploring other alternatives than might, in fact, turn out to be simpler or longer lasting. We need to evaluate any proposed new routing and addressing architecture to insure that there is a thorough understanding of the impact to changing from the current IP architecture to a new one. We need to be confident that we understand which approach has the most benefits for long term internet growth and the least impact on the current Internet. The IESG considered what additional information and criteria was needed to choose between alternative approaches. We also considered the time needed for gathering this additional information and the amount of time remaining before it was absolutely imperative to make this decision (i.e., how much time do we have before we are in danger of running out of IP addresses *before* we could deploy a new architecture?). This led the IESG to propose a specific course of action for choosing the approach for bigger Internet addresses by the November IETF meeting. The next section describes the selection criteria, and the following section describes the milestones and timetable for making an IESG recommendation at the November 1992 IETF. 4.3 Information and Selection Criteria For "Bigger Internet Addresses" This section describes the information and criteria which the IESG felt that any new routing and addressing proposal should supply. 4.3.1 Description of Proposed Scheme A complete description of the proposed routing and addressing architecture should be supplied. This should be at the level of detail where the functionality and complexity of the scheme can be clearly understood. 4.3.2 Changes Required All changes to existing protocols should be documented and new protocols which need to be developed and/or deployed should be specified and described. This should enumerate all protocols which are not currently in widespread operational deployment in the Internet. Changes should also be grouped by the devices and/or functions they affect. This should include at least the following: - Host Changes - Exterior Router Changes - Interior Router Changes - Domain Name System Changes - Network Management Changes - Operations Tools Changes 4.3.4 Performance Impact The performance impact of the new routing and addressing architecture should be evaluated. It should be compared against the current state of the art. The performance evaluation for routers and hosts should include packets-per-second and memory usage projections, and bandwidth usage for networks. Performance should be projected based on the following projected data points: -Domains 10^^3 10^^4 10^^5 10^^6 10^^7 10^^8 -Networks 10^^4 10^^5 10^^6 10^^7 10^^8 10^^9 -Hosts 10^^6 10^^7 10^^8 10^^9 10^^9 10^^10 4.3.5 Large Internet Support The proposal should describe how it will scale to support a large internet of 10^^9 networks. It should describe how the proposed routing and addressing architecture will work to support an internet of this size. This should include, as appropriate, a description of the routing hierarchy, how the routing and addressing will be organized, how different layers of the routing interact (e.g., interior and exterior, or L1, L2, L3, etc), and relationship between addressing and routing. The addressing proposed should include a description of how addresses will be assigned and who owns the addresses (e.g. user or service provider). 4.3.6 Support for TCP/IP hosts than do not support the new architecture The proposal should describe how hosts which do not support the new architecture will be supported -- whether they receive full services and can communicate with the whole internet, or if they will receive limited services. 4.3.7 Deployment Plan Description The proposal should include a deployment plan. It should include the steps required to deploy it. Each step should include the devices and protocols which are required to change and what benefits are derived at each step. A schedule should be included, with justification showing that the schedule is realistic. 4.4 Milestones And Timetable For Making a Recommendation for "Bigger Internet Addresses" The IESG recommends that a call for proposals be made, with initial activities to begin at the July IETF and with a very strict timetable for reaching a recommendation coming out of the November IETF meeting. A working group will be formed for each proposed approach. The charter of each WG will be to explore the criteria described in section 4.3 and develop a detailed plan for IESG consideration. The WGs will have their first meeting at the July 1992 IETF meeting in Boston. The WGs will be asked to submit an Internet-Draft prior to the November IETF, and to make presentations at the November IETF. The IESG and the IETF will review all submitted proposals and then the IESG will make a recommendation to the IAB by December 1992. Therefore, the firm milestones and timetable for the IESG to reach a recommendation on bigger Internet addresses are: June 1992 -- Issue a call for proposals to form working groups to explore separate approaches for bigger Internet addresses. Distribute the "selection criteria" for public review. July 1992 -- Convene proposed WGs at the Boston IETF meeting. The "selection criteria" will be discussed publicly, and modified as appropriate. July-November 1992 -- WGs continue deliberations by email and/or face- face meetings. October 1992 -- Each WG will be required to submit a written description of the approach and how the criteria are satisfied. These documents must be distributed as Internet-Drafts for public review 30 days prior to the November IETF meeting to be considered. November 1992 -- Each WG will be given an opportunity to present its findings in detail at the November 1992 IETF meeting. December 1992 -- Based on the written documents, the presentations, and public discussions (by email and at the IETF), the IESG will forward a recommendation to the IAB. 5. SUMMARY The problems of Internet scaling and address exhaustion are fundamentally important to the continued health of the Internet, and to the long-term success of such programs as the U.S. NREN and the European EBONE. Finding and embarking on a course of action is critical. However, the problem is so important that we need the depth of information described in section 4.3 before a decision is made. Pending the outcome of further discussion of this note (eg, in the IESG, the big-internet list, and in the IAB), the IESG will move CIDR forward as described in section 4.1, and will issue a call for proposals for a bigger Internet address space with the intent to begin immediately implementing the timetable in section 4.4. 6. FOR MORE INFORMATION To become better acquainted with the issues and/or to follow the progress of these activities: - Please see the documents in the Bibliography below (the ROAD group documents will soon be issued as Internet-Drafts or RFCs). - Join the Big-Internet mailing list (big-internet-request@munnari.oz.au), where the general issues have been, and will continue to be, discussed. - Each separate new WG formed will have an open mailing list. Please feel free to join each as they are announced on the IETF mailing list. - Attend the July IETF in Boston (where the WGs will first meet) and the November IETF in Washington DC (where the WGs will report and the IESG recommendation will be formulated). Note: In order to receive announcements of: - future IETF meetings and agenda, - new IETF working groups, and - the posting of Internet-Drafts and RFCs, please send a request to join the IETF mailing list (ietf-request@isi.edu). 7. BIBLIOGRAPHY -Documents and Information from IETF/IESG: [Ford92] "Routing And Addressing Considerations", Peter Ford and Phill Gross, Proceedings of the Twenty-Third IETF, March 1992. [Gross92] Chair's Message and Minutes of the Open IETF Plenary, Phill Gross, Proceedings of the Twenty-Third IETF, March 1992. [Almq92] "IESG Recommendations on Routing and Addressing", IESG (Philip Almquist editor), in preparation, (current draft May 3, 1992) -Documents directly resulting from the ROAD group [Fuller92] "Supernetting: an Address Assignment and Aggregation Strategy", Vince Fuller, Tony Li, Jessica Yu, and Kannan Varadhan (March 9, 1992). [Hinden92] "New Scheme for Internet Routing and Addressing (ENCAPS)", Bob Hinden (March 16, 1992). [Callon92a] "A Simple CLNP-based Proposal for Internet Addressing and Routing", Ross Callon (April 2, 1992). [Deering92] "City Codes: An Alternative Scheme for OSI NSAP Allocation in the Internet", Steve Deering (January 7, 1992). [Brim92] "Summary Report from the Routing and Addressing (ROAD) Group", Scott Brim (Editor), preliminary draft (April 3, 1992) [Callon92b] CNAT -Related Documents [Stockman92] "A Proposal for a Global Internet Addressing Scheme", Daniel Karrenberg and Bernhard Stockman, Internet-Draft (May 28, 1992). [Rekhter92] "Guidelines for IP Address Allocation", Y. Rekhter and T. Li, Internet-Draft (May 1992). [Solen92] "A Revision to IP Address Classifications", F. Solensky and F. Kastenholz (March 1992). [Wang92] "A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion", Z. Wang and J. Crowcroft, RFC 1335 (May 1992). [Callon91] "Guidelines for OSI NSAP Allocation in the Internet", Ross Callon, Ella Gardner, and Richard Colella, RFC 1237 (July 1991). [Tsuchiya92a] NAT, Internet-Draft [Tsuchiya92b] "The P Internet Protocol (PIP)", Internet-Draft. [Chiappa91] "NIMROD", Internet-Draft From owner-Big-Internet@munnari.oz.au Thu Jun 18 16:07:53 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA24505; Thu, 18 Jun 1992 16:08:00 +1000 (from owner-Big-Internet) Return-Path: Received: from SPECTRUM.CMC.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA24502; Thu, 18 Jun 1992 16:07:53 +1000 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA07733; Wed, 17 Jun 92 23:06:30 PDT Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: IP address exhaustion... a myth? Message-Id: <1992Jun18.060620.7693@spectrum.CMC.COM> Organization: CMC (a Rockwell Company), Santa Barbara, California, USA References: <9206172033.AA05106@gateway.bnr.ca> Date: Thu, 18 Jun 92 06:06:20 GMT Apparently-To: Big-Internet@munnari.OZ.AU In article <9206172033.AA05106@gateway.bnr.ca> FORTINP@BNR.CA (Pierre (P.) Fortin) writes: >I guess I must be dense... :^) In the method I posted, I don't see that >ANY changes are needed on the existing hosts; from their perspective, they >don't even know that *address[only]* translation is occuring at a gateway... Because an FTP client sends out command lines of the form PORT 131.143.16.1.10.24 containing a text encoding of its own address, either (1) the host software must be changed to not do that (such as by a protocol amendment stating that "if the first four bytes of the argument to the port command are 0.0.0.0 the server should open the data connection to the same host as where the control connection is coming from") .. or (2) the address translation gateway must intercept and modify these commands. I think it is easier to amend the protocol. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 From owner-Big-Internet@munnari.oz.au Thu Jun 18 17:27:57 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26697; Thu, 18 Jun 1992 17:28:00 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26694; Thu, 18 Jun 1992 17:27:57 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA28982 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 18 Jun 1992 17:27:55 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA19399; Thu, 18 Jun 92 17:27:54 EST Message-Id: <9206180727.AA19399@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of "Wed, 17 Jun 92 18:00:05 EST." <199206172200.AA25780@home.ans.net> Date: Thu, 18 Jun 92 17:27:53 +1000 From: Bob Smart > > December 1992 -- Based on the written documents, the presentations, >and public discussions (by email and at the IETF), the IESG will forward a >recommendation to the IAB. One of the keys to the success of the Internet is a standardization process which does IMPLEMENTATION first STANDARDIZATION second. Let's not get distracted from that by the urgency of the situation. I would like to see the above section changed to: December 1992 -- 2 proposals will be chosen for experimental implementation. June 1993 -- Based on ... AND experience of experimental implementations the IESG will forward a recommendation to the IAB. In fact of course I would hope that experimental implementations would start before December 1992, but it is impossible to see implementations covering all the important issues being done before then. Do we lose anything by setting aside an implementation period? No: that work will have to be done anyway. The cost in wasted work to the losing side is well worth paying if it improves the decision process. There is a good chance that come December there will be 2 proposals: a "safe" proposal that only handles the address space problem; and a more radical proposal that will handle the new problems we are facing like policy based routing and high performance requirements. Making the decision in December weights the decision in favour of the conservative decision for no significant gain. In many ways the most difficult and challenging area will be handling the existing IP hosts during the transition [estimate at least 5 years]. This transition work will be relatively independent of the NewIP chosen. Bob Smart From owner-Big-Internet@munnari.oz.au Thu Jun 18 19:40:18 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA29644; Thu, 18 Jun 1992 19:40:29 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206180940.29644@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA29641; Thu, 18 Jun 1992 19:40:18 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 18 Jun 1992 10:39:57 +0100 To: Phill Gross Cc: big-internet@munnari.oz.au, road@lanl.gov, iesg@nri.reston.va.us, iab@isi.edu Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of "Wed, 17 Jun 92 18:00:05 CDT." <199206172200.AA25780@home.ans.net> Date: Thu, 18 Jun 92 10:39:05 +0100 From: Zheng Wang I think we need to be more specific about which protocols/tools should be included in the list. >4.3.2 Changes Required > >All changes to existing protocols should be documented and new protocols >which need to be developed and/or deployed should be specified and >described. This should enumerate all protocols which are not currently in >widespread operational deployment in the Internet. > >Changes should also be grouped by the devices and/or functions they >affect. This should include at least the following: > > - Host Changes this should include not only IP level, but also TCP/UDP, FTP etc. > - Exterior Router Changes > - Interior Router Changes > - Domain Name System Changes > - Network Management Changes this should also include ICMP. > - Operations Tools Changes > Also should be considered: - Adminstrative Changes whether we have to re-assign host id to current IP hosts, whether we have to change the subnet structure - Additions to the system translation service for IP hosts. Cheers Zheng From owner-Big-Internet@munnari.oz.au Fri Jun 19 00:58:52 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA07653; Fri, 19 Jun 1992 00:59:00 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA07650; Fri, 19 Jun 1992 00:58:52 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA02834; Thu, 18 Jun 92 10:58:33 -0400 Message-Id: <9206181458.AA02834@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 9246; Thu, 18 Jun 92 10:56:45 EDT Date: 18 Jun 92 10:59:00 EDT To: lars@cmc.com, From: Pierre (P.) Fortin Subject: Re: IP address exhaustion... a myth? Sender: Pierre (P.) Fortin Lars, Thanks for the ftp PORT clarification (as I change to my other foot... :^) Sounds to me like this might be worked around (if ftp has to change anyway) by changing ftp to use "PORT .10.24"... What my suggestion is intended to do is to move from a flat address space to a name-based addressing scheme which uses session IDs (if I'm using the correct term) between hosts (with 0 to N address translation gateways)... Isn't ftp's use of the IP address, in this case, a layering violation (or minor abuse...)? Of course, I'm not advocating removing the ability to "ftp 1.2.3.4"; but in this case, it would likely be restricted to the "local" network (unless a static or currently active dynamic mapping was available at an address translation gateway). Other than this ftp issue, can I assume that my suggestion still has some merit? I've not had anyone say it was "a heap of sh*t"... _yet_... Regards, Pierre From owner-Big-Internet@munnari.oz.au Fri Jun 19 01:33:28 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA08361; Fri, 19 Jun 1992 01:33:35 +1000 (from owner-Big-Internet) Return-Path: Received: from venera.isi.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA08358; Fri, 19 Jun 1992 01:33:28 +1000 (from postel@ISI.EDU) Received: from bel.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 18 Jun 1992 08:34:27 -0700 Date: Thu, 18 Jun 1992 08:32:54 -0700 From: postel@ISI.EDU Posted-Date: Thu, 18 Jun 1992 08:32:54 -0700 Message-Id: <199206181532.AA13720@bel.isi.edu> Received: by bel.isi.edu (5.65c/4.0.3-4) id ; Thu, 18 Jun 1992 08:32:54 -0700 To: FORTINP@BNR.CA Subject: Re: IP address exhaustion... a myth? Cc: Big-Internet@munnari.oz.au Pierre: Currently, FTP is in no way dependent on DNS. Your suggestion would introduce a dependency betweeen two applications that does not now exist. The general principle of "least mechanism" suggest that this extra dependency is an undesirable thing. --jon. From owner-Big-Internet@munnari.oz.au Fri Jun 19 02:11:48 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA09166; Fri, 19 Jun 1992 02:11:57 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA09161; Fri, 19 Jun 1992 02:11:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17911; Thu, 18 Jun 92 12:11:33 -0400 Date: Thu, 18 Jun 92 12:11:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206181611.AA17911@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au Subject: Re: IP address exhaustion... a myth? Cc: jnc@ginger.lcs.mit.edu I can't believe that I am hearing all this drivel (and I refer to the last week's worth of material, not just the last few hours) out of what claims to be a group of reputable, competent computer scientists. First, this discussion seems to be proceeeding along the lines of "how to cram 5 pounds into a 1 pound sack", by attempting to keep going with the 32 bit space after we have used all 2^32 combinations. Not the most elegant of approaches to dealing with the problem, but I understand, we have a large installed base. So, fine, let's consider it, but if we are going to think about this, let's think (and talk) about it like trained computer scientists, not a bunch of teenage high-school dropouts who are patching their third Basic program into semi-funtionality, huh? I.e. let's talk about it at a reasonably abstact level, not which bits go where, right? What you are all basically saying is that the 32-bit quantities, which are used to be globally unique, are going to only be locally unique, right? All the schemes being discussed here have this characteristic, right? So, all the schemes are going to have to have to have two things, one of which has been totally ignored, as far as I can tell. First, you are going to have areas of local name uniqueness, and boundaries between these areas. If the local names for a certain object differ across that boundary, then you are going to have to make translations between all instances of those two local names in all packets flowing across that boundary, wherever they appear. This is called the NAT (name address translation) problem, and the Road group looked at it for a while. It has a lot of problems (as people who have experience with these things in practise have tried to advise you). A number of NAT schemes were put forth (and I don't know if these schemes are all available as ID's - perhaps others can point out locations), but everyone ought to read up on them. Paul Tsuchiya has one called SNAT, and Van Jacobsen has one called LNAT. I prepared two separate notes, one a taxonomy of NAT schemes, and one a list of generic problems with all NAT schemes. I will post them (separately) so they go in the Big-I archives, at least. The second issue is that YOU STILL NEED A GLOBAL ROUTING SYSTEM! Along with this, you probably need a global addressing system, since addresses are the data that routing systems manipulate. In words of (almost) one syllable, given a very large bunch of these local naming areas, and the translating boxes between them, you still need some system that can tell you which areas to go through to get from where you are to where you want to go. NAT doesn't give you any of this; it just gives you an extremely complicated system that allows you to avoid changing the packet format. The problems of routing and addressing in very large networks remain, untouched. Without such a scheme, NAT boxes are as much use as the proverbial rearranging of deckchairs on the Titanic. Noel From owner-Big-Internet@munnari.oz.au Fri Jun 19 02:16:27 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA09361; Fri, 19 Jun 1992 02:17:02 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA09332; Fri, 19 Jun 1992 02:16:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18215; Thu, 18 Jun 92 12:16:13 -0400 Date: Thu, 18 Jun 92 12:16:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206181616.AA18215@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Taxonomy of NAT variants An Introduction To NAT J. Noel Chiappa NAT (network address translator) refers to a class of schemes for solving 2 of the three problems of Internet routing and addressing, as laid out in [Chiappa90]. The two in question are the exhaustion of class B IP network numbers, and the eventual exhaustion of the IP 32-bit address space itself. In considering NAT, it is necessary to bear in mind that when the second happens, there are only two possible solutions: switch to a larger addresses, which means a different packet format (which might be CLNP), or make the addresses non-globally unique, which is NAT. This note contains a general discussion of NAT, and an etymology of potential NAT variants. There are many, many different variations on the NAT idea. The common theme in all of them is that the each packet no longer contains, throughout the lifetime of the packet, a single, globally unique, network address. In other words, the IP address in the packet is no longer globally unique, but has to be interpreted in some local context. The general idea is that the IP address space is partitioned into a "local" and "global" portions, the meaning of addresses within each being local to any given AS. In any given AS, physical networks and hosts inside the AS are assigned addresses from the local portion in the existing way, and existing IGP's route traffic among them. Hosts outside the AS which need to communicate with hosts inside the AS are temporarily assigned addresses within the global portion on a demand basis. Border routers on the boundary of each AS must contain mapping tables which translate from the address assignments in one AS to those in the neighbouring addresses; these translations must be made not only on addresses in packet headers, but in addresses carried as data in packets (a moderately long list of cases). The mechanism whereby these mapping tables get created is not discussed here, but usually involves wire-tapping DNS transactions and modifying the contents. However, all this low level mechanism is far from a complete solution to the problem, and must be accompanied by yet more mechanism at a higher level, as pointed out in [Chiappa90]. Given a system consisting of a large number of AS's, there must still be some way to pass around information as to the topological relationship of these AS's, and to make choices as to how to route traffic through the mesh of AS's. This system is what we call routing. Large routing systems generally need structured names for the places where hosts can be attached to the network; we call these names addresses. They need the names for obvious reasons; it's hard to get traffic to a place if you don't have some way of indicating which place you want the traffic to go to. The structure is necessary to make the job of routing easier in a large network. [Chiappa91] Thus, it is clear that a large scale routing and addressing system must exist above the NAT boxes in order to make them actually useful in a large system. Many of the different variations in the basic NAT idea come from the different routing and addressing systems that people 'mix in' to come up with a workable overall system. There are several axes along which NAT schemes can be divided. In one, what is important is whether the addresses are local only in the end-AS's (i.e. where the hosts are), or in all AS's, including transit. Divided this way, there are two main classes of NAT schemes. In the first, the packets contain a locally significant address only in the end-AS, and contains (somewhere in the packet) a globally significant one elsewhere (i.e. in the backbones). In the second, none of the addresses in the packet is globally unique, but only local to each AS (even where the packet only transits three, a source, long-haul and destination). I call these the "end-map" and "hop-map" variations. Some schemes could be deployed in either variant, and are called "all-map". From the security aspect, end-map is preferable, since for all of its lifetime outside the source AS, the packet contains a globally unique ID, which security mechansims will find extremely useful. Another important dividing line is whether what the 32-bit address in the end-AS's is mapped into in transit AS's is the same size or not. The importance here is obvious; if it is the same length, all addresses in the packet, including those carried as data, can be modified in situ; if the length is different, a more complex scheme is needed. Systems which map straight across from 32 bits to 32 bits I will call "flat-map", systems which map into a larger space are called "large-map", and systems which can use either scheme are called "vari-map". An apparent advantage of doing large-map is that it removes the 32-bit limit on the maximum number of destinations that can be simultaneously active in a transit AS. Realize, however, that if the mappings operate on source-destination pairs, instead of source and destination separately, then this effectively increases the address space to 64 bits [actually, the size is (64 - log2(average_number_destinations_active_per_source))], removing the 32-bit limit. However, large-map is almost certainly required for end-map variants, since 32-bit addresses will soon be non-globally unique, and global dynamic allocation of 64-bit pairs is probably infeasible. For hop-map, flat-map is easier, particularly since the 64-bit pair system would make large transit nets feasible, albeit probably at the cost of making aggregation more difficult. The following is a brief survey of all the variants I have been able to think up, broken down into the three classes mentioned in the first classification scheme; i.e. end-map, hop-map, and all-map. Some include the routing and high level addressing architecture which would go with them, others do not. Those which do not would obviously need one. Note also that these are simply general classifications; many contain sub-variations, usually of flat-map and large-map. Time does not permit exploring the subvariants in detail at this point. End-Map Variants E-NAT: Class E addresses are introduced, and assigned to various networks in the system. Clearly, within AS's which contain these numbers, the hosts have to be able to deal with them. In other AS's, however, these class E addresses may prove a problem to some hosts; a NAT box could translate them into a range of acceptable addresses within the existing A, B or C space. The overall routing and addressing uses the existing system. A-NAT: Very similar to the one above, but the new address type introduced is the A# variant. This variant is probably not useful, since all hosts can already deal with A# addresses, and only old internal routers, a negligible population, would benefit. M-NAT: Another similar variant, where the overall routing system is modified to use either arbitrary masks, or kempei addresses, or any system where the allocation of addresses does not conform to the existing A, B and C classes. S-NAT: In this variant, introduced by Paul Tsuchiya, each local AS boundary router attached to the backbone is assigned a static piece of the global part of the address space, and inbound addresses for traffic to this end-AS uses addresses in that reserved space. C-NAT: This is one possible way CLNP might be deployed. There is a clear deployment path for CLNP with straight mapping between IP addresses and CLNP addresses, but when the IP address space is used up this variant would map from locally assigned IP addresses to globally unique CLNP addresses. I-NAT: This variant would use the Open Routing routing protocol to route among AS's; the high level addressing structure would simply be AS number, and the high level address scheme would simply be the local IP address extended by the AS number. Hop-Map Variants L-NAT: In this variant, introduced by Van Jacobsen, the global unique identifier is the domain name. Since this identifier is not a topological address, suitable for routing, perhaps another address might also be defined which takes over this role. As the packet passes from AS to AS, the bottom bits of the asssigned address in the destination AS remain the same, allowing aggregation of translations, reducing the potential for 'hot-spots' in 32-bit translation tables. All-Map Variants N-NAT: This version was postulated in [Chiappa91]. The existing IP address field explicitly becomes a host identifier, and an entirely new routing and addressing system is deployed. When the 32-bit identifier space is used up, NAT translations are used to make the 32-bit identifiers local. There are two sub-variants; one flat-map and one large-map. In the flat-map variant, the mapping would probably be be from end-end, as opposed to hop by hop, and in the middle the packet would be identified by a mapping from the source-destination pair to a flow. In the large-map variant, the local 32-bit identifer would map into a larger (perhaps 64-bit) B-NAT: This is very similar to the system above, except instead of using Nimrod for the routing system, BGP (or ISO descendant thereof) is used. An extended address format would have to be defined. U-NAT: Again, very similar to the system above, except instead of using Nimrod for the routing system, the Unified Routing scheme of Estrin, et al would be used. As that document defines no extended address, an extended address format would have to be defined. From owner-big-internet@munnari.oz.au Fri Jun 19 03:04:58 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA10624; Fri, 19 Jun 1992 03:05:01 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA09360; Fri, 19 Jun 1992 02:16:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18392; Thu, 18 Jun 92 12:16:45 -0400 Date: Thu, 18 Jun 92 12:16:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206181616.AA18392@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: NAT problems I have been thinking about NAT a lot and have come up with a list of problems with NAT that I'd like to set down for people to think about. I have arranged them in what I feel is the order of difficulty. Embedded Addresses There are a number of places where NAT boxes have to examine the contents of packets, as well as the IP headers, to map addresses, and I'm not sure we've found them all. Among the ones I've though of are the contents of SNMP packets, and ICMP messages which contain packet headers which are returned as the data of some messages (such a Destination Unreachable, etc). X.500 Impact To the extent that X.500 comes into use for mapping from host names, etc, to IP addresses, we will have to tie into the X.500 system in the same way that we tap into DNS. Thus, we will have a large ball of string, consisting of the following four components: DNS, X.500, routing and address mapping. Instead of the completely separate systems we do now, we have a giant lump. This is obviously not impossible, but it is very distasteful, and will almost certainly lead to trouble down the road. Backbone Address Exhaustion: In end-map systems which do not actually transform the packet on the backbone into a packet with a larger address, it is probable that the system as a whole will fairly quickly grow so large as to exhaust the entire 2^32 address space, even if not all the addresses in the end-AS's are simultaneously addressible in the backbone. Full-map systems with large backbone AS's have a similar problem; enough destinations may be active simultaneously on all the connected end-AS's to exhaust the 2^32 address space. If the backbone is using a time-based allocation system (i.e. only a small percentage of the addresses is in use at any time, to avoid having to track which ones are free) the problem will occur even faster. A number of solutions are available to this problem, such as making the addresses only significant in a pairwise fashion (i.e. each 64 bit quantity will identify a source-destination pair). Address Only Packets I Normally, to allocate a mapping, the system depends on tapping into DNS transactions and modifying the contents, thereby providing an effective DNS name -> non-global address mapping. There are a number of circumstances where this is not possible. First, packets may arrive from sites which are not identified by a DNS name. A prime example is the source address for ICMP packets from routers outside the AS. When these packets are seen, no name is available, since the knowledge of the name is only available at the source router, and that device does not normally provide that information. It turns out that this is not an insolvable problem, nor is it one that necessarily has to be solved, but there may be other instances of a similar problem. For the ICMP case, messages either do not depend on the source (such as MTU discovery or Destination Unreachable), or can only come from local sources (such as Redirects), and no great harm is done if the source address of the ICMP message is invalid, as long as the contents are correct. Encrypted Traffic Paul Tsuchiya found this one. For encrypted traffic, particularly traffic which wants to avoid traffic analysis, the packets will contain encrytped addresses. This also applies to the packets in Embedded Addresses, above. I can't see any way for the NAT boxes to deal with these unless you use an end-map variant where the NAT boxes on the ends know the encryption key. Address Only Packets II The most serious problem is similar to the one above, in that packets arrive without a preceding DNS transaction. This happens all the time, from hosts which are using addresses which they did not get from the DNS, for whatever reason; either they lack DNS implementations and are using host tables, or some bootstrap or other code has been given addresses directly. This is a fairly serious problem, which as far as I can see, cannot be solved without creating permanent mappings in the NAT boxes for all AS-external addresses which any host in the system has, either in host tables or whatever. If there were any other way to solve it, it would allow us to deply NAT without having to tap into the DNS system, which would be a real feature. From owner-Big-Internet@munnari.oz.au Fri Jun 19 03:19:37 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA11022; Fri, 19 Jun 1992 03:19:47 +1000 (from owner-Big-Internet) Return-Path: Received: from gizmo.bellcore.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA11015; Fri, 19 Jun 1992 03:19:37 +1000 (from mo@gizmo.bellcore.com) Received: by gizmo.bellcore.com (5.61/1.34) id AA11212; Thu, 18 Jun 92 13:19:30 -0400 Date: Thu, 18 Jun 92 13:19:30 -0400 From: mo@gizmo.bellcore.com (Michael O'Dell) Message-Id: <9206181719.AA11212@gizmo.bellcore.com> To: big-internet@munnari.oz.au Subject: network number and addresses Cc: dcrocker@Mordor.Stanford.EDU One of the features I've always liked about the XNS protocol suite is that address did not include network numbers. An XNS address uniquely identifies a host, NOT an interface, and independent of which wire to which it connects. The address is 48 bits (no surprise) and the network number is 32 bits. The XNS version of IP contains the network number, but it is only a "hint." Note that it is a hint which had better well be correct if you want your packets to arrive, but it is not part of the address and hence isn't used for actual host identification and so it doesn't get included in protocol control blocks. This is a BIG DEAL for mobile hosts which may move between networks with some fequency. The current mobility scheme results in pretty non-optimal worm-hole routes for traffic because of the requirement that IP host addresses not change if you want to keep connections alive. Likewise, even protocols like FTP or various RPC protocols don't break if the locally-attached network changes because the network number is clearly distinct from the actual "address" - maybe more correctly called a "Host Identifier." one can argue that this is just one particular partitioning of an 80-bit address, but again, the fact that the network number isn't part of the host identification in the upper-level protocols is the important part. how one structures and interprets the 32 bits of network number is orthogonal, and I certainly believe that one might choose 48 bits of network number if one had it to do over. The reason I bring this up is that one important thing I'd like to see in any New IP definition is some way to move toward the XNS scheme where identity is independent of location. Admittedly, DNS would have to return the current network number as well as the actual host identifier, and in that sense it looks like an 80-bit or 96-bit address, but the payoff in the long run is large: much easier support for mobility much better routing of mobile traffic readily supports topology-based routing/network number assignment flat address space allows dense assignment So, that's my two cents worth. -Mike O'Dell Bellcore?? Bellcore isn't allowed opinions - these be mine. From owner-Big-Internet@munnari.oz.au Fri Jun 19 03:39:51 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA11616; Fri, 19 Jun 1992 03:39:59 +1000 (from owner-Big-Internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA11608; Fri, 19 Jun 1992 03:39:51 +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 3535; Thu, 18 Jun 92 13:38:41 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 0379; Thu, 18 Jun 92 13:38:40 EDT Date: Thu, 18 Jun 92 13:11:13 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: IP address exhaustion... a myth? To: "Pierre (P.) Fortin" , Big-Internet@munnari.oz.au Message-Id: <920618.131113.EDT.VALDIS@vtvm1.cc.vt.edu> In-Reply-To: <9206172033.AA05106@gateway.bnr.ca> On 17 Jun 92 16:34:00 EDT Pierre Fortin said: >Billing? Well, unless I'm missing something here, a modified DNS server (to >take care of the address translation setup (or router auto-configuration)) >could also snatch the IP accounting data at tear-down... [Am assuming that we're talking network-level accounting, as host-level accounting should *NOT* involve the DNS - if the host can't tell how many bytes one of its processes sent/received, nobody ELSE will know either] You need to modify more than just DNS. Remember - the DNS server only translates addresses - which presumably has to be done *only* at connection startup. Then at teardown, the DNS *might* have to (under some schemes) remove a temporary mapping. However, for a fairly long-lived connection, gathering the accounting data may prove interesting - the physical route may have changed several times due to mid-level network crashes, and it's possible (for instance) that an FTP session originating here at Virginia Tech may have been partly handled by our ANS provider, partly over VerNET links, and partly over SuraNET, all depending what the minute-to-minute routing wobbles do. The routers are going to have *enough* work to do dealing with 40,000 routes, and possibly dynamic address translation - let's *not* make them keep around per-connection information on accounting until some DNS server decides to ask for it. And the DNS will have a hard time identifying all the routers involved. I'll overlook the security issues involved - right now, we don't have a DNS that can even provide a truly trustable IP4 name->address mapping. This is *NOT* a good base to use for handling accounting and billing data. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Fri Jun 19 04:40:33 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12877; Fri, 19 Jun 1992 04:40:41 +1000 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12874; Fri, 19 Jun 1992 04:40:33 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA20915; Thu, 18 Jun 92 12:40:20 -0600 Received: by goshawk.lanl.gov (4.1/5.17) id AA26732; Thu, 18 Jun 92 12:40:19 MDT Date: Thu, 18 Jun 92 12:40:19 MDT From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9206181840.AA26732@goshawk.lanl.gov> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Contribution to NAT glossary Noel, In discussing rfc 1335 we came up with the name 'D-NAT' where the D stands for distributed. In a D-NAT system the address translation takes place at the end system (hosts). The advantage of D-NAT systems is that intermediate systems do not have to maintain state which is then used to rewrite the contents of packets (such as rewriting FTP port commands). peter From owner-Big-Internet@munnari.oz.au Sat Jun 20 02:40:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15749; Sat, 20 Jun 1992 02:41:11 +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 AA15745; Sat, 20 Jun 1992 02:40:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26160; Fri, 19 Jun 92 12:40:28 -0400 Date: Fri, 19 Jun 92 12:40:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206191640.AA26160@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, peter@goshawk.lanl.gov Subject: Re: Contribution to NAT glossary Cc: jnc@ginger.lcs.mit.edu Wow, you mean that all hosts have to do the mapping between globally unique addresses and the locally unique ones? Probably I'm just very confused, and am missing some important point here, but if all hosts have to be modified to do the mapping, why not just modify them to use the new addresses? Noel From owner-Big-Internet@munnari.oz.au Sat Jun 20 04:22:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17813; Sat, 20 Jun 1992 04:22:44 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17808; Sat, 20 Jun 1992 04:22:15 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA22624; Fri, 19 Jun 92 13:29:16 -0400 Received: by easynet.crl.dec.com; id AA28681; Fri, 19 Jun 92 14:18:38 -0400 Message-Id: <9206191818.AA28681@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Fri, 19 Jun 92 14:18:42 EDT Date: Fri, 19 Jun 92 14:18:42 EDT From: Ross Callon To: mo@gizmo.bellcore.com Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: mo@gizmo.bellcore.com, big-internet@munnari.oz.au Subject: re: network number and addresses > > One of the features I've always liked about the XNS protocol suite > is that address did not include network numbers. An XNS address > uniquely identifies a host, NOT an interface, and independent of > which wire to which it connects. The address is 48 bits (no > surprise) and the network number is 32 bits. The XNS version of > IP contains the network number, but it is only a "hint." > > > > how one structures and interprets the 32 bits of network number > is orthogonal, and I certainly believe that one might > choose 48 bits of network number if one had it to do over. > > The reason I bring this up is that one important thing I'd like to > see in any New IP definition is some way to move toward the XNS > scheme where identity is independent of location. Admittedly, > DNS would have to return the current network number as well > as the actual host identifier, and in that sense it looks like > an 80-bit or 96-bit address, but the payoff in the long run > is large: > > much easier support for mobility > much better routing of mobile traffic > readily supports topology-based routing/network number > assignment > flat address space allows dense assignment > > So, that's my two cents worth. > > -Mike O'Dell > I agree with this. One of the arguements that I made at the last IETF (although, perhaps I didn't word it well enough) is that big addresses are not **just** for routing and addressing. One of the reasons that you need addresses larger than 32 bits is so that you can have a big enough address so that you can split the "ID" part of the address (the part that uniquely identifies the host) from the "Location" part of the address (the part that says where the host is). If a host moves, then the ID part stays the same, but the location part changes. Naturally, this implies that if you are talking to a host that moves, and if you have the capability of noticing that the ID is the same but the location is different, then the return message can be sent directly to the new location, and doesn't have to be encapsulated or forwarded by any special "mobile host server". Also, the location part will obviously need to be capable of being sub-divided so as to aid routing (although the hosts may not need to know what the sub-division is). The TCP over CLNP proposal (which I am calling TUBA, "TCP and UDP with Bigger Addresses"), should either be already out as an RFC, or just about to come out (I am a few hundred messages behind in my mail, so I am not sure whether the announcement is out yet). It proposes that if CLNP is used to replace IP, then we need to produce several documents including: (i) A CLNP profile for the Internet, and (ii) A specification for how to run TCP (and UDP) over CLNP. I didn't give the details of these two specifications since these would properly be the subject for future work, and there seemed to be a limit to how much it made sense to put in one paper. However, I would personally recommend that the addressing explicitly separates the ID from the location (the rest of the address -- this is already done in the address format used by US GOSIP, ANSI, OSINET, and several other CLNP networks). Also, I would propose that the ID has to be globally unique (probably using IEEE 48 bit IDs) and that TCP use only the ID field to identify the remote system, not the entire address. Ross From owner-Big-Internet@munnari.oz.au Sun Jun 21 05:02:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13294; Sun, 21 Jun 1992 05:02:33 +1000 (from owner-Big-Internet) Return-Path: Received: from ray.lloyd.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13291; Sun, 21 Jun 1992 05:02:23 +1000 (from brian@lloyd.com) Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02573; Sat, 20 Jun 92 12:00:57 PDT Date: Sat, 20 Jun 92 12:00:57 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206201900.AA02573@ray.lloyd.com> To: callon@bigfut.enet.dec.com Cc: mo@gizmo.bellcore.com, big-internet@munnari.oz.au, callon@bigfut.enet.dec.com In-Reply-To: Ross Callon's message of Fri, 19 Jun 92 14:18:42 EDT <9206191818.AA28681@easynet.crl.dec.com> Subject: network number and addresses Reply-To: brian@lloyd.com For what it is worth, Phil Karn's KA9Q implementation of IP works just fine with only a single address for the "node" and does not require an address per interface as is more common convention. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From owner-Big-Internet@munnari.oz.au Mon Jun 22 19:02:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26825; Mon, 22 Jun 1992 19:02:33 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206220902.26825@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26821; Mon, 22 Jun 1992 19:02:25 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jun 1992 10:00:52 +0100 To: mo@gizmo.bellcore.com (Michael O'Dell) Cc: big-internet@munnari.oz.au Subject: Re: network number and addresses In-Reply-To: Your message of "Thu, 18 Jun 92 13:19:30 EDT." <9206181719.AA11212@gizmo.bellcore.com> Date: Mon, 22 Jun 92 10:00:51 +0100 From: Paul Tsuchiya From Mike O'Dell......... > scheme where identity is independent of location. Admittedly, > DNS would have to return the current network number as well > as the actual host identifier, and in that sense it looks like > an 80-bit or 96-bit address, but the payoff in the long run > is large: > > much easier support for mobility > much better routing of mobile traffic > readily supports topology-based routing/network number > assignment > flat address space allows dense assignment I agree with all of this, but this latter point is a bit moot since you need to still have an "address" somewhere in the packet header, so although the "ID" field is dense, the address still may not be. But I would like to add that separating the ID and "address" allows one to do all kinds of nice things with the address space, for instance like allowing border routers to "fill in" the interdomain parts of the address when a packet exits the stub domain, so that internal routers and hosts can operate completely independently of inter-domain address conventions. Please see Pip overview document, which lists of few of the things one can do when the ID and address are separated. From Ross Callon.............. > I didn't give the details of these two specifications since these > would properly be the subject for future work, and there seemed to > be a limit to how much it made sense to put in one paper. However, > I would personally recommend that the addressing explicitly separates > the ID from the location (the rest of the address -- this is already > done in the address format used by US GOSIP, ANSI, OSINET, and several > other CLNP networks). Also, I would propose that the ID has to be None of these formats "explicitly separates the ID from the location". They all suggest putting a 48-bit ieee address in the 6-octet "ID" field, but none of them state that this field should be treated as though it were globally unique. > globally unique (probably using IEEE 48 bit IDs) and that TCP use only > the ID field to identify the remote system, not the entire address. So, we are changing CLNP? It seems to me that the main argument behind going with CLNP is that it is "all ready to deploy", even if it isn't every- thing we would like it to be. This argument goes away if we start changing CLNP. I wonder, once we open this can of worms (well, maybe it will not turn out to be worms but escargot instead, but you know what I mean), where will it end? Will someone else say "as long as we are changing CLNP, let's change this bit and that bit"? I think this is a dangerous road (changing CLNP now). If we are not happy with CLNP, and we think that we have time to start making changes to it, let's scrap it and go with something really useful, like Pip. PT From owner-Big-Internet@munnari.oz.au Mon Jun 22 23:59:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03154; Mon, 22 Jun 1992 23:59:54 +1000 (from owner-Big-Internet) Return-Path: Received: from mts-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03148; Mon, 22 Jun 1992 23:59:46 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA27616; Mon, 22 Jun 92 06:59:37 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA04866; Mon, 22 Jun 92 09:59:35 -0400 To: Peter Elford Subject: Re: Address Translation In-Reply-To: <9206170248.AA19824@jatz.aarnet.edu.au> References: <9206170248.AA19824@jatz.aarnet.edu.au> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: Dave Oran Date: Mon, 22 Jun 92 09:59:32 -0400 Message-Id: <920622095932.2987@sneezy.lkg.dec.com> > I have never been involved with the SPAN/HEPnet work that > had to struggle with the limitations of DECnet Phase IV > addressing to establish a global DECnet, but most of the people > that *have* been through this process don't seem to think > that it was (is) much fun. > > Perhaps history has a message for us there ... > Yes, it does. The lesson is not to wait until the address space is nearly exhausted before you transition to the larget address space. Nearly all of the really difficult problems came from not being able to use a large chunk of the existing address space as a transitionary tool. From owner-Big-Internet@munnari.oz.au Tue Jun 23 02:24:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07232; Tue, 23 Jun 1992 02:24:27 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206221624.7232@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07229; Tue, 23 Jun 1992 02:24:21 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jun 1992 17:23:45 +0100 To: Ross Callon Cc: big-internet@munnari.oz.au Subject: TUBA Date: Mon, 22 Jun 92 17:23:42 +0100 From: Jon Crowcroft some TUBA notes: 1. if you replace IP, most machines i know about (and most vendors) are quite happy to roll in/bundle TP4, so why TCP on CLNP? 2. What do we query the DNS with, UDP on CLNP, UDP on IP or do all DNSs have to support both, if not, how do we know which to ask? (i know, its configuration, but how do we find out...) 3. the cost of calcualyting the pseudoheader checlksumn on 2*20 byte NSAPs and 2*2 bytes length is quite a lot more than on though i spose senders could pre-calculate the sumn on the IDP etc that stay the same - still, the receiver has to do another 10 adds PER packet - why not restrict it to the ID part, so its only 6 octets src + 6 dst instead of 4 each, that still protects against misdelivering... cheers j. From owner-Big-Internet@munnari.oz.au Tue Jun 23 03:03:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08107; Tue, 23 Jun 1992 03:06:04 +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 AA08056; Tue, 23 Jun 1992 03:03:50 +1000 (from kre) To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: TUBA In-Reply-To: Your message of Mon, 22 Jun 92 17:23:42 +0100. Date: Tue, 23 Jun 92 03:03:40 +1000 Message-Id: <15003.709232620@munnari.oz.au> From: Robert Elz Date: Mon, 22 Jun 92 17:23:42 +0100 From: Jon Crowcroft 1. if you replace IP, most machines i know about (and most vendors) are quite happy to roll in/bundle TP4, so why TCP on CLNP? Because the applications we use assume TCP and its semantics. CLNP and IP are quite similar, TCP and TP4 aren't really. kre From owner-Big-Internet@munnari.oz.au Tue Jun 23 03:48:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09150; Tue, 23 Jun 1992 03:48:54 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09135; Tue, 23 Jun 1992 03:48:45 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA12920; Mon, 22 Jun 92 12:47:54 -0400 Received: by easynet.crl.dec.com; id AA29758; Mon, 22 Jun 92 13:46:09 -0400 Message-Id: <9206221746.AA29758@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Mon, 22 Jun 92 13:46:12 EDT Date: Mon, 22 Jun 92 13:46:12 EDT From: Ross Callon To: p.tsuchiya@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: p.tsuchiya@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: re: network number and addresses (are we changing CLNP??) > >From Ross Callon.............. > > > I didn't give the details of these two specifications since these > > would properly be the subject for future work, and there seemed to > > be a limit to how much it made sense to put in one paper. However, > > I would personally recommend that the addressing explicitly separates > > the ID from the location (the rest of the address -- this is already > > done in the address format used by US GOSIP, ANSI, OSINET, and several > > other CLNP networks). Also, I would propose that the ID has to be... > > None of these formats "explicitly separates the ID from the location". > They all suggest putting a 48-bit ieee address in the 6-octet "ID" field, > but none of them state that this field should be treated as though it > were globally unique. > The GOSIP, ANSI, OSINET format has space for the ID, and IS-IS requires that the ID be unique in the area. I am proposing that we go just a little further and explicitly state that the ID will be chosen from the IEEE identifier space (this proposal is not an implicit part of TUBA, but is a further restriction that could be part of the IETF CLNP profile). Thus what I am proposing is compatible with CLNP and with these other address formats, but is more restrictive. > > So, we are changing CLNP? It seems to me that the main argument behind > going with CLNP is that it is "all ready to deploy", even if it isn't every- > thing we would like it to be. This argument goes away if we start changing CLNP. > The main point of using CLNP is that it allows us to make use of the installed CLNP base, including existing specifications, implementations, deployment plans, deployed routers, etc. Probably the most important part of this is that CLNP is current available in products. Using CLNP also means that we don't have to sit down and argue about the design of a new protocol, and that we will be sticking with a basic communications paradigm that we understand and know works (given that CLNP design is based on IP). We should make a distiction between **changing** CLNP, versus **profiling** CLNP. By profiling, I mean specifying the way that we will use CLNP in a manner which is compatible with existing standards and implementations. Thus, for example, we might specify that for Internet use we will always use 20 byte addresses (CLNP allows variable length addresses, with 20 bytes being the maximum size), and that the ID portion of the address will always be 6 bytes long and make use of globally unique IEEE identifiers. Thus we would be setting Internet requirements that are compatible with existing equipment, and which are compatible with existing standards, although slightly more restrictive. Ross From owner-Big-Internet@munnari.oz.au Tue Jun 23 04:16:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09801; Tue, 23 Jun 1992 04:16:43 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09777; Tue, 23 Jun 1992 04:16:29 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA14753; Mon, 22 Jun 92 13:15:21 -0400 Received: by easynet.crl.dec.com; id AA00605; Mon, 22 Jun 92 14:13:46 -0400 Message-Id: <9206221813.AA00605@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Mon, 22 Jun 92 14:13:47 EDT Date: Mon, 22 Jun 92 14:13:47 EDT From: Ross Callon To: j.crowcroft@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: j.crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: re: TUBA > > 1. if you replace IP, most machines i know about (and most vendors) are > quite happy to roll in/bundle TP4, so why TCP on CLNP? > Given that TCP and TP4 both work well, the question is: Which would be easier to run Internet Applications over? We would probably need to update TP4 to include graceful close if we wanted to run over TP4. However, I expect that this would be a perfectly reasonable thing to do (we could either push the required update to TP4 through ANSI and ISO, or just publish an Internet standard of how to run Internet applications over TP4, which included an update to TP4 to include graceful close). I would be quite open to doing this either way, and think that we should do whichever turns out to be (i) easiest to do; and (ii) most efficient. (But, if we use TP4 instead of TCP, do I have to think of a new acronym??) > > 2. What do we query the DNS with, UDP on CLNP, UDP on IP or do all DNSs > have to support both, if not, how do we know which to ask? > (i know, its configuration, but how do we find out...) > Given that IP will continue to be useful locally for a very long time or forever, I would think that we would start by querying DNS using IP as the protocol for communications between the host and DNS server. More generally, one major philosophy or TUBA is that you continue to lookup the address in the normal way, and then run over either IP or CLNP based on the size of the address. The host already needs to have some way to find the address used to reach the DNS server. Thus it would continue to use the same method, and would run over IP if the address of the DNS server was 32 bits, and would run over CLNP if the address of the DNS server was 20 bytes. Yes, this means that the DNS servers need to support both IP and CLNP. > > 3. the cost of calculating the pseudoheader checksum on 2*20 byte > NSAPs and 2*2 bytes length is quite a lot more than on ... > though i supose senders could pre-calculate the sum on the IDP etc > that stay the same - still, the receiver has to do another 10 adds PER > packet - > > why not restrict it to the ID part, so its only 6 octets src + 6 dst > instead of 4 each, that still protects against misdelivering... > I think that this is a good point. Also, if the ID is the part really used to identify the other host, and if the rest of the address can change if the other host moves, then the ID would seem to be the obvious thing that really ought to be part of the TCP pseudoheader. I don't think that we need the length in the pseudoheader if we always require that the length be 20 bytes. Ross From owner-Big-Internet@munnari.oz.au Tue Jun 23 05:11:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13758; Tue, 23 Jun 1992 05:11:16 +1000 (from owner-Big-Internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13747; Tue, 23 Jun 1992 05:11:02 +1000 (from mm@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA10338; Mon, 22 Jun 92 15:09:19 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA04327; Mon, 22 Jun 92 15:09:16 EDT Date: Mon, 22 Jun 92 15:09:16 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9206221909.AA04327@cannibal.gandalf.ca> To: callon@bigfut.enet.dec.com Subject: re: TUBA Cc: big-internet@munnari.oz.au >We would probably need to update >TP4 to include graceful close if we wanted to run over TP4. However, I >expect that this would be a perfectly reasonable thing to do (we could >either push the required update to TP4 through ANSI and ISO This would help IDRP, as it would be able to use a TP? connection instead of trying to emulate TCP on top of CLNP. It could become that much more similar to BGP. -Chris Sullivan From owner-Big-Internet@munnari.oz.au Tue Jun 23 06:08:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15109; Tue, 23 Jun 1992 06:09:08 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15102; Tue, 23 Jun 1992 06:08:49 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA21511; Mon, 22 Jun 92 15:07:43 -0400 Received: by easynet.crl.dec.com; id AA02603; Mon, 22 Jun 92 16:06:25 -0400 Message-Id: <9206222006.AA02603@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Mon, 22 Jun 92 16:06:26 EDT Date: Mon, 22 Jun 92 16:06:26 EDT From: Ross Callon To: p.tsuchiya@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au Apparently-To: p.tsuchiya@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: re: Re: network number and addresses > >>From Mike O'Dell......... >> >> scheme where identity is independent of location. Admittedly, >> DNS would have to return the current network number as well >> as the actual host identifier, and in that sense it looks like >> an 80-bit or 96-bit address, but the payoff in the long run >> is large: >> >> much easier support for mobility >> much better routing of mobile traffic >> readily supports topology-based routing/network number >> assignment >> flat address space allows dense assignment > > From Paul Tsuchiya.... > > I agree with all of this, but this latter point is a bit moot since you > need to still have an "address" somewhere in the packet header, so although > the "ID" field is dense, the address still may not be. > > But I would like to add that separating the ID and "address" allows one to > do all kinds of nice things with the address space, for instance like allowing > border routers to "fill in" the interdomain parts of the address when a > packet exits the stub domain, so that internal routers and hosts can operate > completely independently of inter-domain address conventions. Please see Pip > overview document, which lists of few of the things one can do when the ID > and address are separated. > I agree with the general gist of Paul's comment (the value of separating ID from "location", which Paul calls "address"). However, I am a bit nervous about the specific example. In particular, if the border routers only have the ID, then they will need to do a non-trivial lookup to determine what the rest of the address is. If the ID is really a flat identifier (such as the 48 bit IEEE Identifier), then finding the location where the ID-to-address lookup is maintained might be a difficult task. There will (at least as the Internet grows) be too many IDs to keep the lookup table all in one place, implying that the table will need to be distributed. If it is distributed according to where the system actually is, then you can't tell from looking at the ID where the lookup information is. If it is distributed according to what the ID is, they there is no guarantee that the information is located anywhere near where the system is. If it is in both locations, then you have to worry about keeping a replicated distributed database up to date, etc.. I would recommend that the packet must contain the complete address, and that the address needs to be "correct". However, the separation of ID from location allows very simple autoconfiguration and auto- reconfiguration of addresses, and potentially may allow simple algorithms for mobile hosts (if a host moves, then the definition of what constitutes a "correct" address may, for a small period of time, give a choice of more than one correct address -- such as the old address and the new address). Ross From owner-Big-Internet@munnari.oz.au Tue Jun 23 07:11:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16314; Tue, 23 Jun 1992 07:12:03 +1000 (from owner-Big-Internet) Return-Path: Received: from gatekeeper.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16301; Tue, 23 Jun 1992 07:11:54 +1000 (from Chuck_Semeria@3mail.3com.com) Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA21841 (5.65c/IDA-1.4.4-910725 for ); Mon, 22 Jun 1992 14:10:28 -0700 Received: by gw.3Com.COM id AA17614 (5.65c/IDA-1.4.4 for Big-Internet@munnari.oz.au); Mon, 22 Jun 1992 14:10:27 -0700 Date: Mon, 22 Jun 92 14:08 PDT From: Chuck_Semeria@3mail.3com.com Subject: Please add my name to this list To: Big-Internet@munnari.oz.au Message-Id: <920622.140903@3Mail.3Com.COM> From owner-Big-Internet@munnari.oz.au Tue Jun 23 08:10:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17571; Tue, 23 Jun 1992 08:11:10 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17564; Tue, 23 Jun 1992 08:10:58 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA29141; Mon, 22 Jun 92 17:09:38 -0400 Received: by easynet.crl.dec.com; id AA04306; Mon, 22 Jun 92 18:08:37 -0400 Message-Id: <9206222208.AA04306@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Mon, 22 Jun 92 18:08:39 EDT Date: Mon, 22 Jun 92 18:08:39 EDT From: Ross Callon To: fortinp@bnr.ca Cc: big-internet@munnari.oz.au Apparently-To: fortinp@bnr.ca, big-internet@munnari.oz.au Subject: re: IP address exhaustion... (CLNP document) > > Greetings all, > > I have been trying to follow the various discussions on the impending > exhaustion of the current IP address scheme. Unfortunately, I have > not yet obtained a copy of the Nimrod or CLNP documents... Where can > they be found...? > I was a bit slow responding to this because I knew the answer was about to come out. Have you picked up a copy of RFC 1347 (just released Friday)? It gives a basic overview of the TCP and UDP over CLNP proposal. Ross PS: The standard boilerplate in the announcement specifies that the postscript version is to be preferred. However, for those of you who prefer text, in this case the ASCII text does not lose much. From owner-Big-Internet@munnari.oz.au Tue Jun 23 12:59:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25536; Tue, 23 Jun 1992 12:59:09 +1000 (from owner-Big-Internet) Return-Path: Received: from MrBill.CAnet.CA by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25533; Tue, 23 Jun 1992 12:59:01 +1000 (from dennis@MrBill.CAnet.CA) Received: by MrBill.CAnet.CA id <105502>; Mon, 22 Jun 1992 22:58:40 +0100 From: Dennis Ferguson To: callon@bigfut.enet.dec.com Subject: re: network number and addresses (are we changing CLNP??) Cc: big-internet@munnari.oz.au Message-Id: <92Jun22.225840bst.105502@MrBill.CAnet.CA> Date: Mon, 22 Jun 1992 22:58:39 +0100 > We should make a distiction between **changing** CLNP, versus > **profiling** CLNP. By profiling, I mean specifying the way that we will > use CLNP in a manner which is compatible with existing standards and > implementations. Thus, for example, we might specify that for Internet use > we will always use 20 byte addresses (CLNP allows variable length addresses, > with 20 bytes being the maximum size), and that the ID portion of the > address will always be 6 bytes long and make use of globally unique IEEE > identifiers. Thus we would be setting Internet requirements that are > compatible with existing equipment, and which are compatible with existing > standards, although slightly more restrictive. I am coming to agree that a globally-unique host identifier which is separate from (though perhaps carried in) the address used for routing is a useful commodity. In the case of NSAPs for CLNP, however, I think the suggestion of using 6 byte IEEE identifiers for this purpose is stretching an idea which at its inception was dubious at best, into performing a function where it is truly inappropriate. My understanding is that the idea of using IEEE identifiers as IDs in NSAPs stemmed from a desire to be able to do complete autoconfiguration of OSI hosts, with the guiding principle being that it shouldn't matter what your NSAP is so this should be a bit of information you shouldn't have to configure. A host with no configuration can determine its area prefix automatically from adjacent ISes, but needs a number which is unique within the area to form a complete, globally unique NSAP. Since most (but not all) hosts will have an IEEE ID, either associated with the CPU or with network hardware installed in the machine, this made the IEEE ID a handy source for a semi-random, but guaranteed-unique-within-the-area number with which to form a complete NSAP. There are at least a couple of catches associated with this. One is that not all hosts necessarily have an IEEE ID available for use (e.g. a host whose only network interface was to a point-to-point serial link might not have one). In the original scheme one would deal with this by perhaps configuring hosts in this predicament with a locally-administered IEEE-format ID, since there would be relatively few such hosts and manually maintaining uniqueness of the IDs within a single area would not be a large problem. The other difficulty is that using the IEEE ID tied your NSAP to particular bits of hardware in the host. If a CPU or ethernet card failed and the repairman came in and replaced it, the host's NSAP would change. I think the party line response to this is that this was okay since there would also be some standard, lean, mean, name-to-address translation software (X.500?) which would immediately tell the rest of the world of the NSAP change as soon as the host came back up, and all would be well again. Of course this piece of software is currently, in general, vapourware. Current Internet name service is also not really up to tracking an address which is a moving target. Now while there are no doubt people out there who actually use IEEE ID's to form NSAPs, I think problems caused by attaching your NSAP to something as changeable as hardware, coupled with the current lack of software to deal with such changes, makes large scale use of this technique for obtaining a host ID rather undesireable for at least the near term. Of course this currently isn't a problem since there is nothing which forces you to use IEEE ID's for your NSAPs. I think that configuring hosts with ID's which you maintain yourself, manually ensuring uniqueness within areas, is probably a pragmatic way to avoid all problems with the scheme and is certainly no more onerous than allocating IP addresses is now. Now if you require CLNP ID's to be globally unique IEEE ID's life isn't so pleasant. About the only way one can then guarantee one's NSAPs won't move around, and the only way one can deal with hosts with no IEEE ID of their own, is to go out and buy one's own block of IEEE ID's, or buy a chunk of someone else's block. It seems to me that the use of IEEE ID's, which was originally intended only as a convenience (and a strictly unnecessary convenience at that, since there are other ways to do dynamic address assignment which would be equally satisfactory), is going to become decidedly inconvenient if it is required. Further I don't see any reason why people interested in running network protocols should be competing with hardware vendors for ID space. These should be orthogonal. Let's leave the IEEE ID's to the hardware vendors. I thus think that, if CLNP ID's are going to be required to be globally unique on the Internet then trying to overload this function onto IEEE ID's has few advantages and a lot of disadvantages. Far more satisfactory would be to create and maintain a separate ID space for the purpose. This does raise lots of questions about how this would best be done, however. For example, who should be responsible for assigning such numbers? Is 6 bytes actually a good length for the ID's, or would another length be better? Should the ID space be flat (i.e. assigned as blocks, creating only one administrative hierarchical division) or should a more complex administrative structure be defined to perhaps allow the ID's themselves to be used as keys for DNS lookups without requiring that they be associated with particular area prefixes? Can we make sure that any ID space which is created makes everyone who is thinking about network protocols which might potentially carry a host ID happy, so we only need think about this once? And while I agree that requiring CLNP NSAPs to carry a globally unique ID if they are to be used for IP does not by itself constitute a change to CLNP, I think the fact that this puts constraints on the format of foreign as well as local NSAPs does make this more than a profiling exercise. I don't think there is any current software which assumes anything about the semantics of non-local unrecognized NSAPs. A requirement that all NSAPs used on the Internet contain a unique ID in some fixed location inside the NSAP will eliminate a lot of otherwise perfectly legal NSAPs from being used on the Internet. And since this will no doubt result in the development and implementation of software which depends on that ID being there, software which will be useful on networks which aren't attached to the Internet, I think the practical result of this will be that all networks anywhere which use CLNP will realistically be required to constrain the format of the NSAPs in use as well. Which is fine with me, but which is something of a larger change than your comments above suggest (to me at least). Dennis Ferguson From owner-big-internet@munnari.oz.au Tue Jun 23 15:01:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29632; Tue, 23 Jun 1992 15:01:13 +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 AA28318; Tue, 23 Jun 1992 14:27:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09099; Tue, 23 Jun 92 00:27:28 -0400 Date: Tue, 23 Jun 92 00:27:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206230427.AA09099@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, p.tsuchiya@cs.ucl.ac.uk Subject: re: Re: network number and addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu If the ID is really a flat identifier (such as the 48 bit IEEE Identifier), then finding the location where the ID-to-address lookup is maintained might be a difficult task. Ross, this doesn't make me that nervous. We do mappings of this sort now, with the IN-ADDR domain in DNS. A distributed and replicated database (I agree that it needs these characteristics) to do flat, relatively static, mapping, even on a large namespace, is a far easier problem than routing in a dynamic topology on such a namespace! For every problem you can come up with (such the issue of the root overloading in the DNS), there is a relatively (compared to the difficulty of routing :-) solution (such as replicated roots and caching at intermediate levels for the root overloading). Noel From owner-Big-Internet@munnari.oz.au Tue Jun 23 16:02:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01782; Tue, 23 Jun 1992 16:02:39 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206230602.1782@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01779; Tue, 23 Jun 1992 16:02:34 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jun 1992 07:02:17 +0100 To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) In-Reply-To: Your message of "Mon, 22 Jun 92 13:46:12 EDT." <9206221746.AA29758@easynet.crl.dec.com> Date: Tue, 23 Jun 92 07:02:13 +0100 From: Paul Tsuchiya > > We should make a distiction between **changing** CLNP, versus > **profiling** CLNP. By profiling, I mean specifying the way that we will > use CLNP in a manner which is compatible with existing standards and > implementations. Thus, for example, we might specify that for Internet use > we will always use 20 byte addresses (CLNP allows variable length addresses, > with 20 bytes being the maximum size), and that the ID portion of the > address will always be 6 bytes long and make use of globally unique IEEE > identifiers. Thus we would be setting Internet requirements that are > compatible with existing equipment, and which are compatible with existing > standards, although slightly more restrictive. > It is one thing to *profile* CLNP such that octets 1-7 are a globally unique IEEE number, and another to start depending on that fact in protocol mechanisms, for instance, calculating the TCP pseudo-header checksum on 6 bytes instead of 21, or, using those 6 bytes to track mobile hosts. I would call the latter a *change*, although I can see that it would be largely compatible with pre-change systems, so not particularly a problem in this case. PT From owner-big-internet@munnari.oz.au Tue Jun 23 17:08:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03673; Tue, 23 Jun 1992 17:08:44 +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 AA27961; Tue, 23 Jun 1992 14:19:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09016; Tue, 23 Jun 92 00:18:54 -0400 Date: Tue, 23 Jun 92 00:18:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206230418.AA09016@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Subject: re: network number and addresses (are we changing CLNP??) Cc: jnc@ginger.lcs.mit.edu I am proposing that we go just a little further and explicitly state that the ID will be chosen from the IEEE identifier space Ross, glad to see that you've gotten on the endpoint identifier bandwagon! There are a number of minor difficulties with use of IEEE numbers, as our learned colleague Dennis Ferguson has pointed out, but I wanted to talk about two different points. First, it's not clear to me that 20 byte ISO 'addresses' are long enough to handle real topological addresses in a giga-inter-net. As I have mentioned previously, the only way you even have a hope is to allocate the available space into a small number of short fixed length fields. If there is one thing which 40+ years of computer science ought to have taught us, it's that fixed length addresses are a lose. Sooner or later some field fills up, or you need more levels, or something. I'll bet every Lotus I own that in my lifetime this address is not long enough. The *only* realistic format, to my mind, is an indefinite length with a variable number of variable length fields, which grows from the lowest level up, with no limit. Complex, but powerful. If we can avoid parsing them all the time, the complexity should not be fatal. In any case, you only get 9 bytes for the real address. You have to take off 7 bytes at the end (6 bytes for the ID, and 1 for the 'sel', which seems to correspond to protocol), and then 4 bytes at the beginning (AFI, DFI, etc). You may argue that you can make some use of the first 4 bytes (as indicated in your previous message with the calculation of 10,000 providers), but I don't think so. These first bytes are divided up in complex ways having to do with numbering administrations and political boundaries. Necessary things in this world, perhaps, but unrelated to network topology, and in addressing, topology *must be king*. Political boundaries (and geographic location) take no account of network topology; networks which are next to each other in connectivity terms may be in separate countries (if they are part of a corporate network), and networks which are geographically colocated may be a long way apart in the topology if they connect to different service providers, and not to each other. No, I doubt very much you'll be able to use those 4 bytes for anything useful at all. 9 bytes is it. You've also got a problem with non-IEEE networks. Ideally, you'd like to get rid of that stupid abortion, ARP. The address should contain *everything* you need to get packets to the host. On IEEE networks, this is OK; the address gets you to the right hardware network, and you can cheat and overload the interpretation of the ID field. (As Dennis pointed out, this doesn't work if you change you interface card, though...) However, if you are not on an IEEE network, but something else, you've either a) got to make room for the local address in those 9 bytes (going to be hard in SMDS networks, etc), or b) give up and live with ARP. Personally, the latter option fills me with hatred and loathing. Given all these points, I can't really believe that you're going to really give us WorldNet with these miniscule little 20 byte 'addresses'. 9 useful bytes simply is not enough to give us heirarchical addresses powerful enough to handle the long term. An indefinite length address, and a separate pure ID space which did nothing but identify endpoints (to get rid of the IEEE overload and the problems of swapped interface cards), would allow us to get rid of ARP and simply carry around the complete local hardware address (no matter how crazily formatted) in the real address. Much cleaner, yes? The main point of using CLNP is that it allows us to make use of the installed CLNP base, including existing specifications, implementations, .... Probably the most important part of this is that CLNP is current available in products. The other point I want to make has to do with this subset profiling idea. This is not a bad concept, but I'm not sure that's what you are really doing here. For instance, if you really want to make use of the fact that this 6 byte part of the field labelled 'address' is in fact an endpoint identifier, you are going to have to change the semantics of that field. I.e., software is oging to have to treat that field specially if you want it to *do* anything for you. In other words, generic OSI software won't understand the special meaning of this field, and can't be expected to interoperate with software which does treat this field specially. I'll bet that if I think for a while, I can find other instances. (E.g. I'll bet generic ISO routers which don't grok your special allocation of fields within the middle part of the 'address' won't be too useful as interdomain routers, either.) Thus, the perceived advantage of being able to use off the shelf ISO products is incompatible with your assertion that we can fix any problems with the ISO architecture by appropriate local extensions or restrictions. Noel From owner-Big-Internet@munnari.oz.au Tue Jun 23 17:23:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03947; Tue, 23 Jun 1992 17:23:17 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206230723.3947@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03941; Tue, 23 Jun 1992 17:23:09 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jun 1992 08:22:55 +0100 To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: network number and addresses In-Reply-To: Your message of "Mon, 22 Jun 92 16:06:26 EDT." <9206222006.AA02603@easynet.crl.dec.com> Date: Tue, 23 Jun 92 08:22:51 +0100 From: Paul Tsuchiya > > I agree with the general gist of Paul's comment (the value of separating > ID from "location", which Paul calls "address"). However, I am a bit > nervous about the specific example. In particular, if the border routers > only have the ID, then they will need to do a non-trivial lookup to > determine what the rest of the address is. If the ID is really a flat > identifier (such as the 48 bit IEEE Identifier), then finding the > location where the ID-to-address lookup is maintained might be a > difficult task. There will (at least as the Internet grows) be too Ross, The example in the Pip overview has the border router only filling in the "inter-domain" part of the "address" (damn, we have to come up with better language here. Soon, we'll start putting every other word in quotes). Hosts know the "intra-domain" parts of their addresses, as they must for internal communications. So, the border routers only need to know the set of valid prefixes for the backbones they are attached to, a very small bit of information. PT From owner-Big-Internet@munnari.oz.au Tue Jun 23 18:00:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05095; Tue, 23 Jun 1992 18:00:19 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206230800.5095@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05086; Tue, 23 Jun 1992 18:00:12 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jun 1992 08:58:47 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) In-Reply-To: Your message of "Tue, 23 Jun 92 00:18:54 EDT." <9206230418.AA09016@ginger.lcs.mit.edu> Date: Tue, 23 Jun 92 08:58:39 +0100 From: Paul Tsuchiya Well, I do believe a miracle has occured. A relatively long message from Noel, and I think I agree with everything he wrote! Imagine how difficult it is typing this message while prostrate on my knees! > There are a number of minor difficulties with use of IEEE numbers, as > our learned colleague Dennis Ferguson has pointed out, but I wanted to talk > about two different points. I also want to comment that Dennis' comments were very good ones. > I'll bet every Lotus I own that in my lifetime this address is not > long enough. The *only* realistic format, to my mind, is an indefinite length > with a variable number of variable length fields, which grows from the lowest > level up, with no limit. Complex, but powerful. If we can avoid parsing them > all the time, the complexity should not be fatal. Noel, you've described the Pip "routing hints" to a tee. And, Pip avoids parsing them all the time, because the "routing hint offset" tells the router which in the string of fields is the one to route on. (Or, perhaps I should say that it avoids parsing ALL of them all the time. It only has to parse the one the routing hint offset is pointing to, plus maybe one or two after that if the router is acting at multiple levels of the hierarchy.) PT From owner-Big-Internet@munnari.oz.au Tue Jun 23 18:28:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05849; Tue, 23 Jun 1992 18:28:59 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206230828.5849@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05845; Tue, 23 Jun 1992 18:28:50 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jun 1992 09:28:39 +0100 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: TUBA In-Reply-To: Your message of "Tue, 23 Jun 92 03:03:40 +0900." <15003.709232620@munnari.oz.au> Date: Tue, 23 Jun 92 09:28:33 +0100 From: Jon Crowcroft > 1. if you replace IP, most machines i know about (and most vendors) are > quite happy to roll in/bundle TP4, so why TCP on CLNP? > >Because the applications we use assume TCP and its semantics. >CLNP and IP are quite similar, TCP and TP4 aren't really. kre blimey - you mean you think its too hard to do an inverse RFC1006 - its about 20 lines of code - you need reliable close and map a record stream onto a byte stream - i have my undergrad students do this in term 1...:-) in fact, if you lok in the ISODE release, there is a version of X that runs on an ISO transport service (and DECNET and TCP) the code i did for that was very very simple... CLNP to IP is 1.3 times harder! jon From owner-Big-Internet@munnari.oz.au Tue Jun 23 21:35:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10013; Tue, 23 Jun 1992 21:35:39 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206231135.10013@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10009; Tue, 23 Jun 1992 21:35:31 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jun 1992 12:35:11 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: network number and addresses In-Reply-To: Your message of "Tue, 23 Jun 92 00:27:28 EDT." <9206230427.AA09099@ginger.lcs.mit.edu> Date: Tue, 23 Jun 92 12:35:07 +0100 From: Zheng Wang > Ross, this doesn't make me that nervous. We do mappings of this sort >now, with the IN-ADDR domain in DNS. A distributed and replicated database (I >agree that it needs these characteristics) to do flat, relatively static, >mapping, even on a large namespace, is a far easier problem than routing in >a dynamic topology on such a namespace! If the IDs are completely flat, the mappings will be difficult. Without some structure, it is not possible to do it hierarchically. (imagine you are trying to find a host with a particular ethernet MAC addresss). Conceptually, the domain name is equivalent to the endpoint id that identifies uniquely a host in the Internet, though it was not invented for use in packet header thus not fixed size binary. But it is straightforward if we assign an unique binary for each domain name for use in packet header. But this binary id has to has some structure otherwise the reverse mapping will be difficult. Cheers Zheng From owner-Big-Internet@munnari.oz.au Wed Jun 24 02:10:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20224; Wed, 24 Jun 1992 02:11:08 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20216; Wed, 24 Jun 1992 02:10:55 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA23780; Tue, 23 Jun 92 11:07:08 -0400 Received: by easynet.crl.dec.com; id AA14016; Tue, 23 Jun 92 12:08:03 -0400 Message-Id: <9206231608.AA14016@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Tue, 23 Jun 92 12:08:06 EDT Date: Tue, 23 Jun 92 12:08:06 EDT From: Ross Callon To: dennis@mrbill.canet.ca Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: dennis@mrbill.canet.ca, big-internet@munnari.oz.au Subject: re: re: network number and addresses (are we changing CLNP??) > > My understanding is that the idea of using IEEE identifiers as IDs in > NSAPs stemmed from a desire to be able to do complete autoconfiguration > of OSI hosts, with the guiding principle being that it shouldn't matter > what your NSAP is so this should be a bit of information you shouldn't > have to configure. > The notion was to do autoconfiguration of the host NSAP address. Clearly the host name (X.500 or DNS name) will need to be human-sensible, so this cannot be autoconfigured. Clearly, it *does* matter what the NSAP is. What I think that you meant here is "...It shouldn't matter than the ID part of the NSAP is, so long as it is unique in the area..." > > A host with no configuration can determine its area > prefix automatically from adjacent ISes, but needs a number which is > unique within the area to form a complete, globally unique NSAP. Since > most (but not all) hosts will have an IEEE ID, either associated with > the CPU or with network hardware installed in the machine, this made the > IEEE ID a handy source for a semi-random, but guaranteed-unique-within-the-area > number with which to form a complete NSAP. > This is correct. > > There are at least a couple of catches associated with this. One is that > not all hosts necessarily have an IEEE ID available for use (e.g. a host > whose only network interface was to a point-to-point serial link might > not have one).... > In this case you just assign a normal IEEE ID to this host, just as if it has an IEEE interface (you don't have to actually have an interface on an IEEE network in order to have an IEEE ID assigned to you). This could either be done via manual configuration, or the manufacturer could assign an IEEE ID to the host even though it does not necessarily have a LAN interface. > > The other difficulty is that using the IEEE ID tied your NSAP to particular > bits of hardware in the host. If a CPU or ethernet card failed and the > repairman came in and replaced it, the host's NSAP would change.... > As long as the old Address Prom (or whatever hardware the address is tied to) is not re-used in a different system, and if the system has the option of manually configuring the ID, then you *could* manually configure the old ID into the new system. This is a tradeoff between making configuration easier, versus tieing the address to hardware (if you have an ID, then you have to get it from somewhere -- options are tie it to the hardware or configure it). > > Now while there are no doubt people out there who actually use IEEE ID's > to form NSAPs, I think problems caused by attaching your NSAP to something > as changeable as hardware, coupled with the current lack of software to deal > with such changes, makes large scale use of this technique for obtaining > a host ID rather undesireable for at least the near term. Of course this > currently isn't a problem since there is nothing which forces you to use > IEEE ID's for your NSAPs. I think that configuring hosts with ID's which > you maintain yourself, manually ensuring uniqueness within areas, is > probably a pragmatic way to avoid all problems with the scheme and is > certainly no more onerous than allocating IP addresses is now. > Manually ensuring uniqueness within areas is certainly a possibility. However, this breaks the notion that the ID is globally unique, which hurts in other ways. This is a tradeoff -- do we want the advantages of globally unique IDs, or do we want the advantages of locally administered IDs?? It would be valuable to make address configuration less onerous than it is now -- as the Internet grows, a growing percentage of the Internet users will not be computer wizzards. > > Now if you require CLNP ID's to be globally unique IEEE ID's life isn't > so pleasant. About the only way one can then guarantee one's NSAPs won't > move around, and the only way one can deal with hosts with no IEEE ID of > their own, is to go out and buy one's own block of IEEE ID's, or buy > a chunk of someone else's block. > Is it really such a big deal to have computer manufacturers obtain a block of IEEE IDs? If we want to have globally unique IDs, then someone has to administer them. IEEE is already doing this, and the cost of obtaining a block is not large (my understanding is that it is just enough to cover the IEEE's cost of doing the administration and is not a moneymaker, although I am not certain about this). > > I thus think that, if CLNP ID's are going to be required to be globally > unique on the Internet then trying to overload this function onto IEEE ID's > has few advantages and a lot of disadvantages. Far more satisfactory > would be to create and maintain a separate ID space for the purpose. This > does raise lots of questions about how this would best be done, however. > For example, who should be responsible for assigning such numbers? > Given that there are already a number of OSI systems out there using IEEE IDs as the (globally unique) ID, if we use a different way to generate IDs, then (i) We might collide (unless we coordinate our IDs with IEEE IDs), and (ii) A system which does both OSI and Internet protocols may need two different IDs. Perhaps we should ask Jon Postel and Joyce Reynolds how hard this task would be. I think that setting up a separate ID space would be extra work, and would not buy us anything. The point is that if we want globally unique IDs, then we need some way to generate them, and we already have a way to generate them, so why not use it? Realistically, I think that there are only two choices: (i) Use IEEE IDs, or (ii) Give up on the idea of having the ID be globally unique. Each choice has different advantages and disadvantages. > > Is 6 bytes actually a good length for the ID's, or would another length > be better? > We need an ID space large enough so that it won't run out (during the lifespan of the technology). This implies that 4 bytes is not quite enough, but 6 bytes is enough. > > Should the ID space be flat (i.e. assigned as blocks, creating only one > administrative hierarchical division) or should a more complex administrative > structure be defined to perhaps allow the ID's themselves to be used as keys > for DNS lookups without requiring that they be associated with particular area > prefixes? Can we make sure that any ID space which is created makes > everyone who is thinking about network protocols which might potentially > carry a host ID happy, so we only need think about this once? > Well, there is one BIG question: If you move a system around and plug it in somewhere else in the Internet, will its ID change? If so, then you need to manually configure the system. If not, then the IDs will become "flat" from the point of view of which ID is located where in the global Internet. If you want a structure which makes DNS lookups based on ID (only) convenient, then you end up with IDs that change when systems move. > > And while I agree that requiring CLNP NSAPs to carry a globally unique > ID if they are to be used for IP does not by itself constitute a change > to CLNP, I think the fact that this puts constraints on the format of foreign > as well as local NSAPs does make this more than a profiling exercise. > We need to check with the address structure used in existing CLNP networks. It is possible that there might already be enough variety of ID lengths deployed to make any fixed ID length awkward (we need to check this). > > I don't think there is any current software which assumes anything about > the semantics of non-local unrecognized NSAPs. > There isn't any existing software which runs TCP over CLNP (or at least not a significant amount of such software in common use). > > A requirement that all > NSAPs used on the Internet contain a unique ID in some fixed location > inside the NSAP will eliminate a lot of otherwise perfectly legal NSAPs > from being used on the Internet. And since this will no doubt result in > the development and implementation of software which depends on > that ID being there, software which will be useful on networks which aren't > attached to the Internet, I think the practical result of this will be > that all networks anywhere which use CLNP will realistically be > required to constrain the format of the NSAPs in use as well. Which is > fine with me, but which is something of a larger change than your comments > above suggest (to me at least). > Yes. I think that practically if we constrain NSAPs to use globally unique IDs for the purpose of running TCP over CLNP, then we will end up putting pressure on the OSI guys to do the same thing for any other application running over CLNP. I see the possible use of globally unique IDs as a tradeoff, involving a constraint on the manner in which IDs are assigned (including a constraint that IDs have to be the same length everywhere), versus the advantages of autoconfiguration and easier and more efficient handling of mobile hosts (yes -- I agree that I need to talk with the mobile host folks about how this might work). I feel that autoconfiguration and (particularly) auto-reconfiguration of addresses is a big win when and if addresses have to change. This is true even if manual configuration is needed to fix the routers and name servers (just having the hosts autoconfigure is a win). I would not want to bet against the possible future importance of mobile hosts (particularly laptops). Ross From owner-Big-Internet@munnari.oz.au Wed Jun 24 02:56:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21240; Wed, 24 Jun 1992 02:56:32 +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 AA21227; Wed, 24 Jun 1992 02:56:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12161; Tue, 23 Jun 92 12:55:27 -0400 Date: Tue, 23 Jun 92 12:55:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206231655.AA12161@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, callon@bigfut.enet.dec.com Subject: Re: network number and addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the "inter-domain" part of the "address" (damn, we have to come up with better language here. Soon, we'll start putting every other word in quotes) Paul, we may need some new terms for new concepts (I've tried a number for the concept I am now calling the 'endpoint identifier', better suggestions welcome :-), but I think that the term 'address' is a good, clearly definable, and useful one. If we stick to the meaning "structured name for a network attachment point" for 'address', I think it's a good meaning which corresponds pretty well to people's intuitive model for what 'address' means. It also tightly enough drawn to be useful in detailed abstract conversations about the fundamentals of routing. (The structure, of course, is imposed to make the addresses more (hopefully maximally) useful to routing.) Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 03:02:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21372; Wed, 24 Jun 1992 03:02:38 +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 AA21368; Wed, 24 Jun 1992 03:02:20 +1000 (from kre) To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: TUBA In-Reply-To: Your message of Tue, 23 Jun 92 09:28:33 +0100. Date: Wed, 24 Jun 92 03:02:07 +1000 Message-Id: <15458.709318927@munnari.oz.au> From: Robert Elz Date: Tue, 23 Jun 92 09:28:33 +0100 From: Jon Crowcroft blimey - you mean you think its too hard to do an inverse RFC1006 - its about 20 lines of code - you need reliable close and map a record stream onto a byte stream - i have my undergrad students do this in term 1...:-) You also need urgent data, crossing-opens (I forget the right term, I mean when each end independantly sends a SYN to the other at the same time), and probably an ability to close the window while still ack'ing the data received. Plus more trivial things like mapping port numbers into TSAP's etc of course. Maybe even PUSH. there is a version of X that runs on an ISO transport X makes very few demands on TCP - it can't really, as it wants to be transport independant. Do a telnet that works over ISO transport and you'll be closer to what's really required. Do something that uses crossing SYN's and you'll be much closer. CLNP to IP is 1.3 times harder! The real difference is that all CLNP is needed for here (that is would be, I don't want to suggest that I believe the CLNP way is the right way to go) is to make TCP (and UDP) work. The CLNP only needs map as much of IP as is needed for that, not all of IP necessarily - ie: we know in advance what the demands are. On the other hand, there are lots of applications that use TCP in all kinds of ways, since that's the exposed layer you'd have to do a very complete emulation of all the TCP functionality, whether you consider it useful, or "good" or not - someone will be depending on it, when you consider it that way, I suspect that "TCP over CLNP" would answer Ross's "whichever is easier" test. This isn't to say that you couldn't also run a TP4 over CLNP stack ... 1006 over tcp over clnp does seem a little silly. Though don't you have problems with some ISO applications if all you have is TP4 .. doesn't X.400 (MHS) want TP0 really? (I haven't been keeping up with the ISO requirements lately, it all seems a bit of a waste of time these days). kre From owner-Big-Internet@munnari.oz.au Wed Jun 24 03:10:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21576; Wed, 24 Jun 1992 03:10:16 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206231710.21576@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21566; Wed, 24 Jun 1992 03:10:03 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jun 1992 18:09:42 +0100 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: TUBA In-Reply-To: Your message of "Wed, 24 Jun 92 03:02:07 +0900." <15458.709318927@munnari.oz.au> Date: Tue, 23 Jun 92 18:09:36 +0100 From: Jon Crowcroft > blimey - you mean you think its too hard to do an inverse RFC1006 - > its about 20 lines of code - you need reliable close and map a > record stream onto a byte stream - i have my undergrad students do > this in term 1...:-) > >You also need urgent data, crossing-opens (I forget the right >term, I mean when each end independantly sends a SYN to the >other at the same time), and probably an ability to close the half open stuff - not hard... >window while still ack'ing the data received. Plus more trivial >things like mapping port numbers into TSAP's etc of course. trivial >Maybe even PUSH. == EOM > there is a version of X that runs on an ISO transport >X makes very few demands on TCP - it can't really, as it >wants to be transport independant. Do a telnet that works true... >over ISO transport and you'll be closer to what's really >required. Do something that uses crossing SYN's and you'll >be much closer. still easy... >This isn't to say that you couldn't also run a TP4 over CLNP >stack ... 1006 over tcp over clnp does seem a little silly. time to write rfc6001:-) thanks for reminding me of other ISO TP-isms cheers jon From owner-Big-Internet@munnari.oz.au Wed Jun 24 03:11:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21628; Wed, 24 Jun 1992 03:11:56 +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 AA21624; Wed, 24 Jun 1992 03:11:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12260; Tue, 23 Jun 92 13:11:44 -0400 Date: Tue, 23 Jun 92 13:11:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206231711.AA12260@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, postel@isi.edu Subject: re: Re: network number and addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Well, having the routing procedure depend on finding things in the DNS (or an equivalent database) does make me nervous. Well, depending on exactly how it's done, it might make me nervous too! Having to do a lookup in a distributed, replicated, dynamic database to communicate with another host (in the normal case) shouldn't bother you, since we do this now with DNS. We depend on this to work pretty heavily, too; I can't recall the last time I typed a numeric address! In fact, I imagine that in the future, host software will look up both the endpoint identifier and the address in the same DNS transaction. We only have to have the first hop routers do the lookup to allow for interoperability with unmodified hosts, which are presumably a diminishing group over time. I think the critical thing is making sure we don't have any dependancy loops; i.e. places where you have to do the mapping before you can do the mapping, etc. There are a number of scenarios where this could happen, which is why I think it's wise to include the address, probably as an IP option, (along with the endpoint identifier) in some types of packets, such as ICMP packets. Just as the system allows you to bypass the current name to address DNS mapping to prevent dependancy loops, it should also allow you to bypass the endpoint identifier to address mapping, for the exact same reason. Normal data packets (e.g. part of a TCP stream) would not have to have the address, which saves a lot of complex address parsing, since these are the bulk of the traffic. Do I have a complete design, with a list of all places that need to carry the address? No, sorry, I admit I don't. I hope a detailed design effort will be starting shortly, though. Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 03:15:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21722; Wed, 24 Jun 1992 03:15:59 +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 AA21719; Wed, 24 Jun 1992 03:15:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12284; Tue, 23 Jun 92 13:15:48 -0400 Date: Tue, 23 Jun 92 13:15:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206231715.AA12284@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, postel@isi.edu Subject: re: Re: network number and addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Also, realize that in most schemes (I only know Nimrod well :-), the routing (i.e. distribution of connectivity information, and deciding, given a destination address, how to get traffic there) is all done in terms of addresses (although the endpoint identifier may be used to identify nodes in the LS map), and the mapping facility is not used by the routing at all. I think by "routing procedure" you mean the entire process of getting packets from one host to another, though, right? Yes, at this level, you do have to have to find the address, which may involve a lookup. Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 03:18:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21820; Wed, 24 Jun 1992 03:19:02 +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 AA21808; Wed, 24 Jun 1992 03:18:41 +1000 (from kre) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) In-Reply-To: Your message of Tue, 23 Jun 92 00:18:54 -0400. <9206230418.AA09016@ginger.lcs.mit.edu> Date: Wed, 24 Jun 92 03:18:27 +1000 Message-Id: <15474.709319907@munnari.oz.au> From: Robert Elz Date: Tue, 23 Jun 92 00:18:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9206230418.AA09016@ginger.lcs.mit.edu> Ideally, you'd like to get rid of that stupid abortion, ARP. The address should contain *everything* you need to get packets to the host. I disagree with this - there's nothing wrong (in principle) with ARP, as long as its kept in its place. Apart from some minor implementation details (ARP would be better if it sent to a multicast address derived from the protocol address the request is seeking, rather than broadcasting) ARP is just fine when used on the media for which its intended. What can be done with large addreses, is encode completely eevrything you need to get packets to a host that's on a net where addresses are administratively assigned to endpoints (X.25, SMDS, ...) and hence change very rarely, and even more rarely without some good reason and lots of advance notice. Attempts to bend ARP, or ARP like protocols into those nets tend to turn into disasters, and avoiding that need would be nice. You really don't want to encode addresses with components that change randomly with little advance notice - like MAC addresses on IEEE 802 type networks. Those are better confined to the domain of the local cable, and determined dynamically (somehow, needn't necessarily be ARP) locally. Encoding those kinds of addresses into network addresses in order to gain some kind of simplified dispatching once you arrive at thge correct 802 cable would be rather like encoring the serial number of my telephone in my telephone number (so you could distinguish which of my modem, fax machine, answering machine, or phone you wanted to contact) - not something that seems useful. Apart from that I agree with everything that you say. kre From owner-Big-Internet@munnari.oz.au Wed Jun 24 03:55:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22524; Wed, 24 Jun 1992 03:55:22 +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 AA22515; Wed, 24 Jun 1992 03:55:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12460; Tue, 23 Jun 92 13:54:59 -0400 Date: Tue, 23 Jun 92 13:54:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206231754.AA12460@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: network number and addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu If the IDs are completely flat, the mappings will be difficult. Without some structure, it is not possible to do it hierarchically... Balderdash. If you have to have a translation table from a large, randomly assigned namespace to another namespace, there are ways to do it which do not involve every translation server having a copy of the entire translation table. You can "divide and conquer". There is an exact tradeoff between the size of the tables in each server, and the number of servers. Look at the IN-ADDR domain. Sequential Class B addresses are assigned basically totally randomly (blocks excepted). 128.1 has no relationship whatsoever to 128.2 (I hope, for the purposes of argument :-). That doesn't stop the authoritative servers for IN-ADDR.128 from have a table of 256 entries which point to the servers for IN-ADDR.128.1, IN-ADDR.128.2, etc, etc. Using a similar system, recursively applied, even if endpoint ID a.b.c.d.e.f.g.7 (assuming a dotted byte by byte notation for 64 bit ID's) was totally unrelated to enpoint ID a.b.c.d.e.f.g.8, you could still have a limited number of servers which are authoritative for a.b.c.d.e.f.g which contain 256 entry tables giving the mapping for all a.b.c.d.e.f.g.N. Let's look at the numbers on some examples. First, a ludicrous example which minimzes the size of the tables in each server, and thus maximizes the number of servers, and also maps the entire 2^64 space; i.e. over 10^19 entries! If each 256 entry translation table is replicated 3 times for reliability, and each server held only a single 256 entry table, you could map the entire 2^64 namespace with (3 + 3*2^8 + 3*(2^8)^2 + ... 3*(2^8)^7) servers, or approximately 2^58 servers. This is almost two orders of magnitude (2^6, actually) less than the number of endpoints, not an unreasonable server/endpoint ratio, and each server only has a single 256 entry table. For a more reasonable example, if we allowed the servers to have single 2^16 entry tables, not exactly a large table, a complete mapping with triple redundancy would require about 2^50 servers (3 + 3*2^16 + .... 3*(2^16)^3). If we only had 10^9 active hosts, with 2^16 entry tables in triply redundant servers, we'd need 2^30 mappings, 2^16 per server, or 3*2^14 servers, or about 45K servers for 1000M hosts. Yes, hosts from different administrative and topological locations would be intermingled in the servers, but this is not an insoluble policy or technical problem. We have telephone white pages now which intermingle people randomly, and which we trust. We could do the mapping securely by signing the mapping entries with private keys, if you must. This is not a hard problem (where by hard I compare with *routing* in a system of that size)! Yes, there's a lot of bookkeeping, table updating, etc, etc, but it is not unreasonable. Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 04:14:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22952; Wed, 24 Jun 1992 04:14:29 +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 AA22948; Wed, 24 Jun 1992 04:14:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12663; Tue, 23 Jun 92 14:14:14 -0400 Date: Tue, 23 Jun 92 14:14:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206231814.AA12663@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu You really don't want to encode addresses with components that change randomly with little advance notice - like MAC addresses on IEEE 802 type networks. You may have a point here. I guess it all depends on how easy it is to change the 'hostname->address' (or 'identifier->address') mapping, and how quickly that change propogates to everyone who needs to know. I think that if it easy to change that mapping, I'd rather ditch ARP and include the 802 address directly in the NAP address as the last element. Get rid of some extra mechanism which doesn't buy you anything. If the mapping is not easy to change, then there is a user for another level of mapping, i.e. ARP. ("All problems in computer science can be solved by another level of indirection." - Lampson :-) However, if we expect to do mobile hosts and similar things well, I think the mapping better be easy to change, and if the mapping is easy to change, the extra layer of mapping ARP gives you becomes suspect (see below). When it comes to speed of propogation of changes, remember that even now we have problems with stuff hanging around in ARP caches! Power down a machine, power it back on with a different Ethernet card, and half the machines out there won't be able to talk to you! to gain some kind of simplified dispatching once you arrive at thge correct 802 cable The issue isn't so much simplified dispatching as it is minimizing useless complexity, and the opportunities for bad engineering. How many disgusting kludges have we seen stuck into (or porposed to stick into) the ARP layer "because it's there". ("Perfection has been attained, not when there is nothing left to add, but when there is nothing left to take away." - St. Exupery :-) Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 04:36:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23457; Wed, 24 Jun 1992 04:37:15 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23440; Wed, 24 Jun 1992 04:36:48 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA01097; Tue, 23 Jun 92 14:36:04 -0400 Received: by easynet.crl.dec.com; id AA14361; Tue, 23 Jun 92 12:39:51 -0400 Message-Id: <9206231639.AA14361@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Tue, 23 Jun 92 12:39:55 EDT Date: Tue, 23 Jun 92 12:39:55 EDT From: Ross Callon To: z.wang@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: z.wang@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: re: network number and addresses (ID to ... mapping) > > > Ross, this doesn't make me that nervous. We do mappings of this sort > > now, with the IN-ADDR domain in DNS. A distributed and replicated database (I > > agree that it needs these characteristics) to do flat, relatively static, > > mapping, even on a large namespace, is a far easier problem than routing in > > a dynamic topology on such a namespace! > > If the IDs are completely flat, the mappings will be difficult. > Without some structure, it is not possible to do it > hierarchically. (imagine you are trying to find a host with a > particular ethernet MAC addresss). > > Conceptually, the domain name is equivalent to the endpoint id that > identifies uniquely a host in the Internet, though it was > not invented for use in packet header thus not fixed size > binary. But it is straightforward if we assign an unique binary > for each domain name for use in packet header. But this binary > id has to has some structure otherwise the reverse mapping > will be difficult. > > Cheers > Zheng > Yes, Zheng has put his finger on my point more clearly. Basically, you have a choice: Either the ID changes when the host moves, or it doesn't. If the ID stays the same regardless of where the host moves worldwide, then we are going to find ourselves with an ID space which has NO RELATIONSHIP between what the ID is and where the host is. This is quite different from IN-ADDR, since current IP addresses have topological structure. Ross From owner-Big-Internet@munnari.oz.au Wed Jun 24 05:27:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24514; Wed, 24 Jun 1992 05:27:26 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24503; Wed, 24 Jun 1992 05:27:04 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA05876; Tue, 23 Jun 92 12:26:57 -0700 Received: by us1rmc.bb.dec.com; id AA13207; Tue, 23 Jun 92 15:28:13 -0400 Message-Id: <9206231928.AA13207@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 23 Jun 92 15:28:14 EDT Date: Tue, 23 Jun 92 15:28:14 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 23-Jun-1992 1529" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) My initial mind set on all this was just to go to a bigger fixed size address. Gradually I have been convinced that having a "ID" name space separate from addressing/routing is very useful for most applications. And that if one is designing a system "to last the ages", then it probably has to be variable length. I'm still unconvinced of the necessity for an indefinite number of levels in hierarchial addresses. You could get to the 10**9 original mandate with 4 or 5 levels. Certainly 8 would be adequate and 16 seems like too many. I see a danger of over-reacting to routing table problems caused by a hierarchy with too broad a branching at each level and replacing it with a system where it's so easy to increase the number of layers that you end up with things 20 or 30 or more deep and have excessively long inefficient addresses for little reason. Anyway, in the context of the above, using CLNP addresses with 48bit IEEE ID's seems like an enormous step backwards. Besides the arguments that have already been made, what about putting more than one logical endpoint in the same machine with one network interface? What about low earth orbit satellite systems that may be coming along with 64 bit station IDs? And the rigid, non- extensible nature of the remaining address bytes isn't very attractive either. A new system of ID's (probably also variable length) would not be that much work at the center as assignments out of sub-blocks would be delegated. You would need some such structure for the look up by ID anyway. All the above having been said, I would add that I think the addressing scheme should provide for a much flexibility and expressive power as can be managed without undue cost (nice vague words, eh?). For example, it should be possible to directly address a "network". Say I am a LAN somewhere (actually, I am a possibly distributed process running on the router(s) that connect this LAN to the outside world) and I wish to speak hypothetical Internet standard network level security protocol messages to a second LAN to establish a situation where all traffic between us two LANs was encrypted but none of the hosts on either LAN knew anything of this and all local traffic was in the clear. Should I have to determine all the routers on the remote LAN or determine what particular local coordination/routing protocol is running between them? I don't think so. I should be able to just send a packet off addressed to the network (or Autonomous Domain or whatever) as an entity. At worst, it could be randomly delieverd to one of the border nodes that define the area addressed. Furthermore, getting back to IEEE addresses, I see nothing wrong as an option for maintenance or experimental use with allowing explicit addressing of hardware interfaces on a network. Why shouldn't I be able to give a network address and an interface serial number if I know it? This is less work for the local network than translating an ID to the interface. Such an option would probably be used mostly in local network management and bootstrapping. On mobility, there is a lot of concern for the mobile host but what about the mobil network? Say my trailer home is relatively primitive by 2010 standards and has less than 100 computers in it. Still, most of them are fixed and could could be addressed by a single byte relative to the network. But I drive around and plug my network in at various trailer camps. Can there be a fixed ID for my network that dynamically translates into various places in the hierarchy (maybe including via satellite when I'm in motion)? Does anyone have any reaction to these ideas? Donald From owner-Big-Internet@munnari.oz.au Wed Jun 24 05:56:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25285; Wed, 24 Jun 1992 05:56:27 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206231956.25285@munnari.oz.au> Received: from DUNGEON.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25272; Wed, 24 Jun 1992 05:56:04 +1000 (from tmallory@BBN.COM) To: Ross Callon Cc: big-internet@munnari.oz.au, tmallory@BBN.COM Subject: Re: network number and addresses (are we changing CLNP??) In-Reply-To: Your message of Tue, 23 Jun 92 12:08:06 -0400. <9206231608.AA14016@easynet.crl.dec.com> Date: Tue, 23 Jun 92 15:52:33 -0400 From: Tracy Mallory One thread that's been mostly lost (except for occasional grumbles from Noel) is that even the 48-bit IEEE space has limitations (a minor one is that it has only 46 available bits), and will have to be used with care. >> >> Now if you require CLNP ID's to be globally unique IEEE ID's life isn't >> so pleasant. About the only way one can then guarantee one's NSAPs won't >> move around, and the only way one can deal with hosts with no IEEE ID of >> their own, is to go out and buy one's own block of IEEE ID's, or buy >> a chunk of someone else's block. >> > >Is it really such a big deal to have computer manufacturers obtain a block >of IEEE IDs? If we want to have globally unique IDs, then someone has to >administer them. IEEE is already doing this, and the cost of obtaining a >block is not large (my understanding is that it is just enough to cover >the IEEE's cost of doing the administration and is not a moneymaker, >although I am not certain about this). It's not just computer manufacturers. I'll briefly drag up the "toasternet" scenario once again with an obviously incomplete list of networkable objects: my car for maintenance/service history, all of our personal computers including my Mac, my wife's PC and my son's Nintendo (new games over the net and networked games), all of our telephones (directory services), etc. to suggest that many unique IDs might be required for every member of my family. If we conservatively guess 8 per person (2^^3) and take 10 billion (2^^31) people, then you get 2^^34 IDs without blinking an eye, and that doesn't address business, government, etc. which probably doubles the long-term number of addresses (2^^35). A barely mentioned issue with the IEEE address space is that there is no way (as of now) to systematically reuse these addresses. An address assigned to a device is potentially lost when that device stops being used. From one of my few "Trivial Pursuits" encounters, I learned that the X billion species alive today represent less than one percent of the total number of species in the planet's history (1% ~ 2^^-7). I've reached 2^^42 IDs used up in x00 years. With only a 46 bit address space, we will certainly have to solve the problem of reuse by the 30th century unless we can achieve an almost perfect allocation strategy. Given that there are only 22 bits worth of address blocks available at the highest level (4 million), it can't be the case that every manufacturer simply gets a block of 2^^24 addresses. Four million is small enough that you can imagine running out of blocks if every company/address-authority got its own block without regard to the number of addresses it needed. Another layer of address management will be required. Exclaimer: All this notwithstanding, I'm in favor of using IEEE 48-bit addresses. The isues I've brought up are not short-term problems, unless the IEEE suddenly and gratutitously hands out huge chunks of the address space in the next few years. Reusing addresses could take a number of forms (how about standardized reusable address proms with a returnable deposit ;-). A more sophisticated registration system could be used to allow the brokerring of smaller address blocks, with a per-transaction registration cost rather than a per-address cost. The air is getting thinner and the hand-waving less and less productive. Cheers, Tracy From owner-big-internet@munnari.oz.au Wed Jun 24 06:29:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25886; Wed, 24 Jun 1992 06:29:33 +1000 (from owner-big-internet) Return-Path: Received: from europa.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24371; Wed, 24 Jun 1992 05:22:58 +1000 (from kasten@europa.clearpoint.com) Received: by europa.clearpoint.com (4.1/1.34) id AA07548; Tue, 23 Jun 92 15:13:25 EDT Date: Tue, 23 Jun 92 15:13:25 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206231913.AA07548@europa.clearpoint.com> To: callon@bigfut.enet.dec.com, jnc@ginger.lcs.mit.edu Subject: thoughts on "re: network number and addresses" In-Reply-To: Mail from 'Ross Callon ' dated: Tue, 23 Jun 92 12:08:06 EDT Cc: big-internet@munnari.oz.au hi i've sort of been following this discussion on and off over the past couple of days and have one or two observations... please excuse me if i go over something already addressed. 1) using an 802 number as the unique host system id is not all that good an idea. as was pointed out, lots of systems do not live on an 802 lan. for example, a host using slip or dial-up ppp. there is the problem. every pc has a serial port that can be used as a slip/ppp port. this leads to either: A) each pc built needs to have its own id number, which each vendor would need to get from the ieee. B) or host id's would be assigned via software and each copy of, e.g., pc/tcp would have a unique serial number from an 802 number that, e.g., ftp inc would obtain. also, what would be done about machines for which there is no 802 interface? i would suggest that the host id number be made 8 bytes long and that the first two bytes be assigned by iana as an "id assignment domain" (idad?) an idad of, e.g., 0x0802 would indicate that the remaining 6 bytes are an 802 number. lots of other machines have serial numbers of various types (maybe even pcs?) and idads could be provided for them... in general, i am also concerned about using a manufacturer assigned id number for the upgrade issue. suppose i have a node that does not have an 802 interface and was built before the new ip is invented. now the new-ip comes along and i have to put a host-id into my machine (suppose i get the new-ip software from some third party, or even write it myself) in order to run it on the new-ip internet. i do not want to have to go to the ieee and pay $1,000 for a block of numbers for 1 or 2 machines. iana should, must, also have some numbers to give out in small batches. 2) earlier today noel talked about some issues related to mapping host id numbers, addresses (i.e. 'attachment points'), mobile hosts, and so on. it seems to me that what you all are talking about is some method of having a host register itself with the network (e.g. when a host gets connected to the net at some point it sends a message to the local route/name/... server that says "hi, i'm here, my name is mumble, my id number is frotz"). a possible extension on this is that when the local server gets this message, it floods a message through all of the servers on the net that would flush any stale information with respect to the newly attached node. some intelligence is needed to prevent gratuitous flushing -- perhaps a node would include who its last server was when the node "signs on" and if the previous server is the same as the current server then there is no need to flush. 3) host id numbers really ought to be invariant. suppose that i have a some scheme that allows network service similar to a cellular phone system (i do not mean mobile hosts in the sense of unplugging my laptop here, putting it in my briefcase, flying to japan, and then plugging it into a different network attachment service provider). as i go roaming through this cellular network my machine may be on and i will be hopping from one network attachment service provider to another. i may want to keep my machine on and working through these hops -- sending and receiving traffic. if my "host id" changes each time i make such a hop, then the node at the other end of the tcp connection (it seems that a tcp connection will become the 4-tuple of local/remote hostid and local/remote port) will lose track of me. the other host used to know me as #123 and i become #456. i suppose that some message could be flooded through the network to the effect of "id number 123 is now known as 456" but that would have to be a broadcast throughout the entire internet and in general seems rather icky. furthermore, how are the host ids assigned? does each network attachment service provider have its own pool of assignable ids? would not the host id then start to have some topology information in it (e.g. nearnet is assgned the pool of ids 0-499 so if a host has id number 123 then i know that it is on nearnet....)? isn't this what the the ip address of today sort-of is? keep the host ids unique throughout all (internet) space and time. frank kastenholz From owner-big-internet@munnari.oz.au Wed Jun 24 06:29:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25887; Wed, 24 Jun 1992 06:29:36 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24924; Wed, 24 Jun 1992 05:41:40 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA06557; Tue, 23 Jun 92 12:40:59 -0700 Received: by us1rmc.bb.dec.com; id AA13998; Tue, 23 Jun 92 15:42:23 -0400 Message-Id: <9206231942.AA13998@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 23 Jun 92 15:42:23 EDT Date: Tue, 23 Jun 92 15:42:23 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 23-Jun-1992 1543" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: RE: re: network number and addresses (ID to ... mapping) It is not clear to me that you need to decide that the ID always changes when a host moves or never change. There is no particular reason that you could not have strictly hierarchial IDs (or bottom level addresses or whatever you want to call them) that would be very easy to route to, administered by a higher node in the hierarchy, short, etc., and also have globally unique IDs that would require look-up for routing, would be administered centrally or at least by a different hierarchy, long, more expensive (to pay for the look up mechanism), etc. Donald -------------- From: US1RMC::BIGFUT::CALLON "Ross Callon" 23-JUN-1992 15:34 To: z.wang@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu CC: big-internet@munnari.oz.au Subj: re: network number and addresses (ID to ... mapping) > > Ross, this doesn't make me that nervous. We do mappings of this sort > > now, with the IN-ADDR domain in DNS. A distributed and replicated database (I > > agree that it needs these characteristics) to do flat, relatively static, > > mapping, even on a large namespace, is a far easier problem than routing in > > a dynamic topology on such a namespace! > > If the IDs are completely flat, the mappings will be difficult. > Without some structure, it is not possible to do it > hierarchically. (imagine you are trying to find a host with a > particular ethernet MAC addresss). > > Conceptually, the domain name is equivalent to the endpoint id that > identifies uniquely a host in the Internet, though it was > not invented for use in packet header thus not fixed size > binary. But it is straightforward if we assign an unique binary > for each domain name for use in packet header. But this binary > id has to has some structure otherwise the reverse mapping > will be difficult. > > Cheers > Zheng Yes, Zheng has put his finger on my point more clearly. Basically, you have a choice: Either the ID changes when the host moves, or it doesn't. If the ID stays the same regardless of where the host moves worldwide, then we are going to find ourselves with an ID space which has NO RELATIONSHIP between what the ID is and where the host is. This is quite different from IN-ADDR, since current IP addresses have topological structure. Ross From owner-Big-Internet@munnari.oz.au Wed Jun 24 08:34:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28886; Wed, 24 Jun 1992 08:34:29 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28881; Wed, 24 Jun 1992 08:34:21 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA09684 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 24 Jun 1992 08:34:18 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA08129; Wed, 24 Jun 92 08:34:17 EST Message-Id: <9206232234.AA08129@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: meta matters Date: Wed, 24 Jun 92 08:34:16 +1000 From: Bob Smart I don't really understand the technical details. I've read the PIP Overview and think I understand it. I am convinced that we need to seize this opportunity to create an NewIP for the future which solves some additional problems, and not just go with bigger IP addresses. This seems to be a growing consensus. However we only have till December to define such a NewIP and prove that it will work. I would have thought the best way to do that was to build on the PIP work. As I understand it Paul Tsuchiya's message saying that he agreed with Noel meant that he was conceding: variable length address components and that the last address component should contain the local network-specific address. Did I get that right? What remaining aspects of PIP does Noel feel need changing? Is this the right forum for discussion of PIP? If so I'd love to see some comment from the experts. Or is all that being done in private conversations? It seems to me that PIP does hierarchical-address + separate-identifier in a very nice way. I really can't work out from the various comments by various people why PIP doesn't meet their needs. I look forward to people either discussing the problems with PIP or getting behind it at this late stage. Bob Smart From owner-Big-Internet@munnari.oz.au Wed Jun 24 16:17:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13351; Wed, 24 Jun 1992 16:17:40 +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 AA13346; Wed, 24 Jun 1992 16:17:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15056; Wed, 24 Jun 92 02:17:15 -0400 Date: Wed, 24 Jun 92 02:17:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206240617.AA15056@ginger.lcs.mit.edu> To: kasten@europa.clearpoint.com Subject: Re: thoughts on "re: network number and addresses" Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu host id numbers really ought to be invariant. ... keep the host ids unique throughout all (internet) space and time. Frank, I can't speak for other people's schemes, but it is the intention in Nimrod that endpoint identifiers will be unique, and will not change. The reasons you laid out are some of those which lead to this. In the normal case (i.e. no migrating processes, dynamically reconfigurable multi-processors, etc) each host computer would have one identifier, which would stay with that 'system' for ever. (I.e., if you plugged in a new 802.X interface, or even upgraded to a more powerful CPU, you'd always keep the same ID, as long as the "identity" of the system remained the same.) Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 16:49:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14570; Wed, 24 Jun 1992 16:49:57 +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 AA14561; Wed, 24 Jun 1992 16:49:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15121; Wed, 24 Jun 92 02:49:44 -0400 Date: Wed, 24 Jun 92 02:49:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206240649.AA15121@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dee@ranger.enet.dec.com Subject: Re: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) Cc: jnc@ginger.lcs.mit.edu Gradually I have been convinced that having a "ID" name space separate from addressing/routing is very useful for most applications. Ahah, another convert! And that if one is designing a system "to last the ages", then it probably has to be variable length. I understand your point, but I think a reasonable case can be made that the lifecycle engineering costs are such that a fixed length field which is not too long, but still long enough to provide ID's forever, is a better bet. It is an ID field, and we should be able to utilize it more densely than we can an address field. Whether 64 bits is enough, or whether we should go to 96, is an good question, but even I have a hard time imagining that we will run out of ID's with a 96 bit ID! This is, after all, almost 10^30, which is a darn big number! (I mean, even if we have wall-wall people on every planet in the galaxy, each with 10^5 computers, I think we have a hard time using up a 96 bit ID space!) Remember, these are the things which we are going to have to examine in *every* packet, and variable length things are just harder to deal with. This is true in hardware, not just software. (I remember all the problems with instruction lookahead for pipelining in the fast Vax, since the instructions were not fixed length.) You have to balance two costs; the large terminal costs in pain if you run out, versus the small incremental costs in efficiency. It's not an easy call, but my bet was for a reasonable length fixed field. I'm still unconvinced of the necessity for an indefinite number of levels in hierarchial addresses. Well, I agree, you probably wouldn't want extremely large numbers of levels, but I think you'd be surprised at the number of levels a real WorldNet could make use of. This is particularly true in a system where you assign numbers from the bottom up to avoid arguments over "who gets to be in the top level", and "who gets how much of the top level". However, to me, that's not the issue. The major reason I say indefinite is that I really think that once you get beyond a certain number, it's just as easy to handle an indefinite number as it is to fix a number like 16 (particularly if each level is a variable length). I think 8 would definitely be too few; the chances of needing more than that are just too high, and the pain level if you run out is too large. It's much harder to make predictions about the number of levels that will be useful 20 years down the road, than it is to make predictions about ID usage. It's not that much extra work to handle a variable number of address levels; why risk hitting a hard limit that you don't have any idea where it should be? For example, it should be possible to directly address a "network". I agree that this is an important capability for an addressing system. It's even more important in LS systems (such as Nimrod), since you need a descriptor language for the elements in your topology map, and in a heirarchical system, this may include nodes which are aggregates of large parts of the topology. You have to be able to name these aggregates. So, there are lots of good reasons to have the system be able to do this. I see nothing wrong as an option for maintenance or experimental use with allowing explicit addressing of hardware interfaces on a network. Again, I agree completely. I think the addresses should name individual network interfaces, and I think that the system has to have some way of allowing nodes to emit packets with the addresses already in them. On mobility, there is a lot of concern for the mobile host but what about the mobil[e] network? This is a very good point, which I have to go off and think about. My initial reaction is that you have to give that network a new address, since it's in a different place in the topology, and all the attached machines would also have to get new addresses (but would keep their ID's). What would be the utility of having the network have a name which is constant? (I'm not trying to be difficult, I'm genuinely at a loss as to what this would get you...) Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 17:30:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15763; Wed, 24 Jun 1992 17:30:28 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206240730.15763@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15759; Wed, 24 Jun 1992 17:30:20 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Jun 1992 08:29:55 +0100 To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Wed, 24 Jun 92 08:34:16 +0900." <9206232234.AA08129@wanda.mel.dit.CSIRO.AU> Date: Wed, 24 Jun 92 08:29:39 +0100 From: Jon Crowcroft >However we only have till December to define such a NewIP and prove that it >will work. PIP might as well reign until december :-) RIP IP i agree though the gist is use the nasty messy stuff to bail out the address space/routing table exhaustion/explosion in as unsupportable a possible way for about 2 years so that there is maximum gain from going to PIP/EIP/Nimrod or whatever ... jon From owner-Big-Internet@munnari.oz.au Wed Jun 24 17:36:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15926; Wed, 24 Jun 1992 17:36:33 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206240736.15926@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15919; Wed, 24 Jun 1992 17:36:19 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Jun 1992 08:35:55 +0100 To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Wed, 24 Jun 92 08:34:16 +0900." <9206232234.AA08129@wanda.mel.dit.CSIRO.AU> Date: Wed, 24 Jun 92 08:35:49 +0100 From: Paul Tsuchiya > I don't really understand the technical details. I've read the PIP Overview > and think I understand it. I am convinced that we need to seize this opportunity > to create an NewIP for the future which solves some additional problems, and > not just go with bigger IP addresses. This seems to be a growing consensus. > > However we only have till December to define such a NewIP and prove that it > will work. I would have thought the best way to do that was to build on the > PIP work. As I understand it Paul Tsuchiya's message saying that he agreed > with Noel meant that he was conceding: variable length address components > and that the last address component should contain the local network-specific > address. Did I get that right? What remaining aspects of PIP does Noel feel Hmmm. I think what I meant when I said I agreed with Noel is that what he was describing was ALREADY in Pip. So, there has been nothing said that would cause me to change Pip yet. (Except some good comments from folks about dumping the Tunnel field, but this is orthogonal to what is being discussed). And, why December? > need changing? Is this the right forum for discussion of PIP? If so I'd > love to see some comment from the experts. Or is all that being done in > private conversations? I think this is the right forum for Pip discussion. > > It seems to me that PIP does hierarchical-address + separate-identifier > in a very nice way. I really can't work out from the various comments > by various people why PIP doesn't meet their needs. I look forward to > people either discussing the problems with PIP or getting behind it at > this late stage. I think that people need a little more time with Pip. It is a bit of a departure from previous thinking, so will take some getting used to. Hopefully, the plenary talk and BOF at ietf will move a lot of people closer to an understanding of Pip, but in the end I think some prototype implementation will be necessary to convince many. I will start a Pip WG in Boston, and am agressively pursuing getting the various Pip components built in public-domain software (host, router, dns, and IP/Pip translation gateway). So, hopefully we'll have something real pretty soon. Anyway, thanks for your enthusiastic support. I am finding that much of what people are talking about these last few days is already in Pip (64-bit identifiers, variable-length addresses, VCI-type forwarding), plus a lot that hasn't been mentioned (policy routes, for instance). PT From owner-Big-Internet@munnari.oz.au Wed Jun 24 17:50:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16327; Wed, 24 Jun 1992 17:50:21 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206240750.16327@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16318; Wed, 24 Jun 1992 17:50:11 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Jun 1992 08:49:38 +0100 To: Robert Elz Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) In-Reply-To: Your message of "Wed, 24 Jun 92 03:18:27 +0900." <15474.709319907@munnari.oz.au> Date: Wed, 24 Jun 92 08:49:32 +0100 From: Zheng Wang > Ideally, you'd like to get rid of that stupid abortion, ARP. > The address should contain *everything* you need to get > packets to the host. > >I disagree with this - there's nothing wrong (in principle) with >ARP, as long as its kept in its place. Apart from the fact that MAC addresses change more frequently, the MAC addresses are only used in the last hop at the data link level. It does not make sense to look it up at the remote site and carry it across the network. Cheers Zheng From owner-Big-Internet@munnari.oz.au Wed Jun 24 18:05:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16849; Wed, 24 Jun 1992 18:05:51 +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 AA16842; Wed, 24 Jun 1992 18:05:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15502; Wed, 24 Jun 92 04:05:38 -0400 Date: Wed, 24 Jun 92 04:05:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206240805.AA15502@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: meta matters Cc: jnc@ginger.lcs.mit.edu Almost perfect timing. I was preparing a commentary on PIP, but it's not done yet. What remaining aspects of PIP does Noel feel need changing? Well, actually, I do and don't like PIP. Let me explain. My biggest single problem with PIP (and just about every other idea I've heard here) is that it puts the cart before the horse. Addresses are structured names for network attachment points; the structure is useful to the routing. A good definition, right? Well, think about what it says: the structure in the address is *useful to the routing*. Routing in a very large network, with policy requirements from both the users and providers, is a terribly hard problem. However, PIP (and most other proposals) explicitly pass on the routing. They then go on to design the addressex. This is *totally* backwards! The addresses should be damn near the *last* thing you design, not the first! That's why the Nimrod document goes on for pages and pages about fundamentals of routing on a very large scale, and has only a few paragraphs on what the addresses will look like. It also spends a lot of time (see section 3.3.2) thinking in detail about all the various things that the structure in addresses does for you, like "provid[ing] a framework for the abstraction process by which simplified graphs of the topology are created". You need to sit down and think (very hard :-) about how you are going to handle the tremedous problems posed by routing on such a large scale. When you have figured that out, the address design usually falls out; it is whatever makes the routing problem easiest! However, without thinking about issues like abstraction, how that leads to non-optimal routing, and how abstraction interacts with addresses, it's plain silly in my book to sit down and design addresses without knowing what the routing system looks like that will use them. Routing hasn't been a popular topic on this mailing list, probably because it's so hard. It's not susceptible to sitting up late one night and dashing off a quick draft plan. However, sticking our collective heads in the sand isn't going to make it go away. To be brutally blunt, I am reminded of an old military axiom: "Amateurs study tactics, professionals study logistics." I suspect the network analogue is "Amateurs design addressing schemes, professionals design routing architectures." So, PIP (and all other schemes) fail a very basic test for me. (Interesting to note, CLNP made the same mistake.) There are a couple of other (minor in comparison) problems I see with PIP, which I will mention briefly. It seems to be more work to deploy, as you have to go to the new packet format in the hosts to get any benefit from it. You can't do complete policy routing with fields you stick in packets, so rather than do it half-way with the fields in the PIP address, I think you need a separate mechanism. I think PIP tries to do too many things with the address field; see for example, Example 11; this would be better down with something like an ICMP message saying "I'm moving", rather than having to look at the address of each incoming packet to seeif the host has moved. I also think the assigment of addresses from the top down is the wrong way to go. Having said that, PIP in many ways is something I like; this should be no surprise, since it has many ideas (endpoint identifiers, variable length addresses) in common with Nimrod. However, I repeat my basic point; what is critical is the *routing architecture*; the addresses should fall out the bottom when this is done. A proposal without a complete routing architecture is no proposal at all, as far as I am concerned. Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 18:17:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17203; Wed, 24 Jun 1992 18:17:16 +1000 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17198; Wed, 24 Jun 1992 18:17:08 +1000 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA10048; Wed, 24 Jun 92 18:15:20 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9206240815.AA10048@coombs.anu.edu.au> Subject: Re: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) To: dee@ranger.enet.dec.com (Donald E. Eastlake III LJO2/I4 +1 508 486 2358 23-Jun-1992 1529) Date: Wed, 24 Jun 92 18:15:18 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9206231928.AA13207@us1rmc.bb.dec.com>; from "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 23-Jun-1992 1529" at Jun 23, 92 3:28 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Donald E. Eastlake, they wrote: [...] > On mobility, there is a lot of concern for the mobile host but what about the > mobil network? Say my trailer home is relatively primitive by 2010 standards > and has less than 100 computers in it. Still, most of them are fixed and could > could be addressed by a single byte relative to the network. But I drive > around and plug my network in at various trailer camps. Can there be a fixed > ID for my network that dynamically translates into various places in the > hierarchy (maybe including via satellite when I'm in motion)? > > Does anyone have any reaction to these ideas? > Assuming that you didn't subnet your 100 computers, there would be no need for them to communicate between each other using a network id. However, if you subnetted, you would most definately need a network number assigned to you for the trailer. If the connected hosts in your trailer used a variable length network id in addition to some hostid, you would still need a local id for your trailer, but when you connected yourself to another network, one scenario could have the 'greater network' id allocated to you in a dynamic fashion. To route packets, use of a default route and let the 'foreign' router build up the source address for packets from hosts in your trailer to other hosts. This would require you to plug into a router rather than attach yourself to the local network (a dangerous thing to let happen anyway). Going off on a limb, has anyone given much thought to removing the manual aspect of the assigning networks ids alltogether ? The general idea would be having a small local network connect to a router which assigns it an id based upon the number of branches that exist from that router. The local net need not have any idea about the id it has been given if the router updates the source address as it goes up the network tree. When connecting router-router and both are to be considered peers, either negotiation would be required to decide who is #1 or they would each treat each other as #2. Has anyone done a detailed look into building networks this way ? Darren. From owner-Big-Internet@munnari.oz.au Wed Jun 24 18:23:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17422; Wed, 24 Jun 1992 18:24:04 +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 AA17414; Wed, 24 Jun 1992 18:23:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15656; Wed, 24 Jun 92 04:23:30 -0400 Date: Wed, 24 Jun 92 04:23:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206240823.AA15656@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, kre@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the MAC addresses are only used in the last hop at the data link level. It does not make sense to look it up at the remote site and carry it across the network. Well, there is something to this. On the other hand, why not extend the principle? If something is in K-level area X, and you are in K-level area Y, you don't need to know its address below the K-level part (i.e. parts K-1 through 0); you can simply send the packet to the correct K-level entity, and let it fill in the lower parts, which are only useful, and known, local to that K-level area. This seems a little silly to me. However, if we are not going to do that in a general way, why make an exception for the lowest level? The host has to know which MAC address it is at; rather than continually be ARP'ing to find it, why not have the host simply tell its name server what its MAC address is? Then, you get it at the same time you get the rest of the address. I'm continually amazed at the way people treat things which were absolute hacks at the time they were done (ARP, the IGP/EGP split) as if they were inscribed on stone tablets by the Great God Networking him/her/itself! Come on, everyone, these things were kludges when they were done, and are not necessarily any better now! Let's make a clear analysis of what they do for us, and what they cost, and if they don't measure up, be brave, and throw them over the side! Noel From owner-Big-Internet@munnari.oz.au Wed Jun 24 18:32:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17791; Wed, 24 Jun 1992 18:33:08 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206240833.17791@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17784; Wed, 24 Jun 1992 18:32:59 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from wanstead.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Jun 1992 09:32:29 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) In-Reply-To: Your message of "Wed, 24 Jun 92 02:49:44 EDT." <9206240649.AA15121@ginger.lcs.mit.edu> Date: Wed, 24 Jun 92 09:32:24 +0100 From: Paul Tsuchiya At the risk of beginning to sound like a broken record (you young people out there may not catch this one, but we used to have these things called records that used to "skip", which would cause the same bit of music to be played over anto be played over anto be played over anto be played over...), but I'm going to start pointing out what Pip can do in the context of this ongoing discussion......... > > Gradually I have been convinced that having a "ID" name space separate > from addressing/routing is very useful for most applications. > > Ahah, another convert! > > > And that if one is designing a system "to last the ages", then it > probably has to be variable length. > > I understand your point, but I think a reasonable case can be made > that the lifecycle engineering costs are such that a fixed length field which > is not too long, but still long enough to provide ID's forever, is a better > bet. It is an ID field, and we should be able to utilize it more densely than > we can an address field. > Whether 64 bits is enough, or whether we should go to 96, is an good > question, but even I have a hard time imagining that we will run out of ID's > with a 96 bit ID! This is, after all, almost 10^30, which is a darn big > number! (I mean, even if we have wall-wall people on every planet in the > galaxy, each with 10^5 computers, I think we have a hard time using up a 96 > bit ID space!) Early version of Pip had variable length IDs up to 64 bits, but Kastenholz convinced me to make them fixed length, so now they are fixed at 64 bits. I'm willing to consider 96 bits, especially since the ID's don't need to be carried in every packet, but think 64 is enough. > > > I'm still unconvinced of the necessity for an indefinite number of > levels in hierarchial addresses. > > Well, I agree, you probably wouldn't want extremely large numbers of > levels, but I think you'd be surprised at the number of levels a real WorldNet > could make use of. This is particularly true in a system where you assign > numbers from the bottom up to avoid arguments over "who gets to be in the top > level", and "who gets how much of the top level". However, to me, that's not > the issue. The current Pip spec (the earlier, drafty paper) allows for 64 "Routing Hint Fields", where each RHF can be one level of a hierarchical address if you want, and the 64 must be split between source and destintation. But, the reason for having 64 RHFs is not because I think hierarchical addresses will ever be that deep, but because the RHF can also encode a policy route (among other things), so I wanted it to be fairly long. If your policy route is longer than 64 "things", then you will have to go with VCI setup. > > For example, it should be possible to directly address a "network". > > I agree that this is an important capability for an addressing system. > It's even more important in LS systems (such as Nimrod), since you need a > descriptor language for the elements in your topology map, and in a > heirarchical system, this may include nodes which are aggregates of large > parts of the topology. You have to be able to name these aggregates. > So, there are lots of good reasons to have the system be able to do > this. Pip is very explicit about addressing "aggregates". Each RHF indicates which level (of the hierarchy) it is operating at, and these RHFs naturally can represent aggregates of the "things" below them. > > > I see nothing wrong as an option for maintenance or experimental > use with allowing explicit addressing of hardware interfaces on a > network. > > Again, I agree completely. I think the addresses should name > individual network interfaces, and I think that the system has to have some > way of allowing nodes to emit packets with the addresses already in them. I don't think that "addresses" should be limited to individual network interfaces, and generally more rather like the idea of "addresses" describing hosts rather than interfaces. But with Pip, you can do either, because the "routing directive" is general and depends only on what routing protocols and semantics you wrap around it. So, with Pip, you can even address individual processors in a multi-processor host, or memory blocks within any host, or processes, or whatever (and without effecting operation of routers anywhere). PT From owner-Big-Internet@munnari.oz.au Wed Jun 24 19:52:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19595; Wed, 24 Jun 1992 19:53:05 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206240953.19595@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19576; Wed, 24 Jun 1992 19:52:41 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from wanstead.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Jun 1992 10:52:22 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Wed, 24 Jun 92 04:05:38 EDT." <9206240805.AA15502@ginger.lcs.mit.edu> Date: Wed, 24 Jun 92 10:52:17 +0100 From: Paul Tsuchiya > Almost perfect timing. I was preparing a commentary on PIP, but it's > not done yet. > > What remaining aspects of PIP does Noel feel need changing? > > Well, actually, I do and don't like PIP. Let me explain. My biggest > single problem with PIP (and just about every other idea I've heard here) > is that it puts the cart before the horse. > Addresses are structured names for network attachment points; the > structure is useful to the routing. A good definition, right? Well, think > about what it says: the structure in the address is *useful to the routing*. > Routing in a very large network, with policy requirements from both > the users and providers, is a terribly hard problem. However, PIP (and most > other proposals) explicitly pass on the routing. They then go on to design the > addressex. This is *totally* backwards! The addresses should be damn near the > *last* thing you design, not the first! But, Pip has not designed an address. Pip provides a general format within which many address types can be encoded (simultaneously in the network, if you like). The problem with designing a routing architecture, then designing an address to that architecture, is that when you want to change your architecture, you are stuck. You have to come up with backwards compatible hacks (for instance, subnetting) to make the new thing work in the context of the old address, and with each change, you find yourself deeper and deeper in hacks. Pip provides such a general "addressing" format that you can change architecures in the future and still have an ideal packet format to work with. As such, Pip doesn't "pass" on the routing. Pip recognizes that routing necessarily evolves, and that one doesn't have the luxury of changing the packet format every time routing evolves. To quote from your nimrod I-D: "To meet it it is first necessary to solve the problem of routing, and only then turn to addressing.........Addressing needs to be completely sublimated to the needs of the routing architecture; the form of addresses should be whatever is most useful to the routing." I agree with this sentiment COMPLETELY, and this in fact is the philosophical foundation for Pip. Pip allows the addressing to be sublimated to the needs of routing by creating a platform upon which multiple types of addresses can be encoded. As the routing architecture changes (which it MUST), a single internet protocol platform (Pip) can be used to support the new architecture. More qoute from your I-D: "First and foremost, the new architecture must be incrementally deployable with respect to the existing system." Absolutely, but since the Pip Routing Directive is so general, it can encode current routing architecture addresses just fine, while still allowing for future architectures (such as path setup or source-based policy route or something we haven't thought up yet). This of course is the whole point behind Pip--allows for evolution in routing. Now, it would be the limit in arrogance for me to claim absolutely that Pip is general enough to handle routing architectures that we haven't thought of. But I have applied EVERY routing technique I know of to the Pip header, and it works. On several occasions, people have asked me if Pip can do thing X or thing Y, which I hadn't thought of, and in each case it could. Now, what do you recommend, that we come up with the "perfect" routing architecture, and then design our address for it, and then we're done? What happens in 2 or 5 or 10 years when the routing architecture comes up short? We have to redefine our addresses--that is, our whole internet protocol. Now, of course, we might find that Pip doesn't handle some future requirement, but I think the notion of designing an internet header that is as general as possible (while still being fast and compact) is better than assuming that we can come up with the perfect routing architecture for all time. To use your analogy above (carts and horses), perhaps Pip is putting the cart before the horse, but only because we may decide later that a horse wasn't at all the right animal. Maybe we'll decide we needed a camel or a team of dogs. At least I'm designing a cart that different types of animals can pull. > > That's why the Nimrod document goes on for pages and pages about > fundamentals of routing on a very large scale, and has only a few paragraphs > on what the addresses will look like. It also spends a lot of time (see > section 3.3.2) thinking in detail about all the various things that the > structure in addresses does for you, like "provid[ing] a framework for the > abstraction process by which simplified graphs of the topology are created". > You need to sit down and think (very hard :-) about how you are going > to handle the tremedous problems posed by routing on such a large scale. When Please don't insult me Noel by implying that I haven't thought about routing. Pip is the result of knowing a damn lot about routing. > > There are a couple of other (minor in comparison) problems I see with > PIP, which I will mention briefly. It seems to be more work to deploy, as you > have to go to the new packet format in the hosts to get any benefit from it. > You can't do complete policy routing with fields you stick in packets, so > rather than do it half-way with the fields in the PIP address, I think you I'm sorry. Why can't you do complete policy routing with fields you stick in packets. You can stick a complete policy route in the Pip routing directive. Why doesn't this give you complete policy routing? > need a separate mechanism. I think PIP tries to do too many things with the Pip does not negate the possiblity of using a separate mechanism. > address field; see for example, Example 11; this would be better down with > something like an ICMP message saying "I'm moving", rather than having to > look at the address of each incoming packet to seeif the host has moved. I Fine. Pip doesn't prevent such a thing. The examples in the Pip overview are there to show the richness of the Pip header. Exactly how we do mobility or policy or whatever is an open topic, but Pip can support whatever we do. > However, I repeat my basic point; what is critical is the *routing > architecture*; the addresses should fall out the bottom when this is done. A > proposal without a complete routing architecture is no proposal at all, as far > as I am concerned. > A proposal that allows for multiple routing architectures or evolution in routing architectures is better than a single routing architecture that will find itself out of date some day. Anyway Noel, I publicly challange you to find an aspect of Nimrod or any other plausible routing architecture that results in data packets that can't be carried using the Pip header and forwarding function as it is now defined. (I recognize that some routing architectures that will require path setup packets or any number of other "control" packets that Pip does not define. The Pip header is for the purposes of carrying data packets.) Cease with these platitudes about carts and horses and amatuers and professionals and architectures and addresses. Instead, show me EXACTLY what Pip can't do. If you can't find anything, then please shut up and do something constructive like figuring out how Pip can serve as a vehicle for Nimrod. If you can find something, then all the better because that will add to all of our knowledge, and maybe result in a better Pip. PT From owner-Big-Internet@munnari.oz.au Wed Jun 24 19:59:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19797; Wed, 24 Jun 1992 19:59:39 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19791; Wed, 24 Jun 1992 19:59:32 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA21739 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 24 Jun 1992 19:59:29 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA10523; Wed, 24 Jun 92 19:59:28 EST Message-Id: <9206240959.AA10523@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Wed, 24 Jun 92 08:35:49 +0100." <199206240736.AA20186@shark.mel.dit.csiro.au> Date: Wed, 24 Jun 92 19:59:26 +1000 From: Bob Smart > >And, why December? Phil Gross wrote > The IESG and the IETF will review all submitted proposals and then the > IESG will make a recommendation to the IAB by December 1992. Or is that a figment of my mailbox. My call for a longer period was met with complete silence. >> It seems to me that PIP does hierarchical-address + separate-identifier >> in a very nice way. > >Anyway, thanks for your enthusiastic support. Well I think that niceness is encouraging, but I don't claim to be enough of an expert to know if it will really work. Addressing some of Noel Chiappa's comments: jnc> However, PIP (and most other proposals) explicitly pass on the routing. jnc> They then go on to design the addressex. This is *totally* backwards! jnc> The addresses should be damn near the *last* thing you design, not the jnc> first! Well I completely disagree with this characterization of PIP. To me it seems that the addresses follow from the routing philosophy (a word chosen to suggest "more general than architecture"). The claim that PIP is backwards in this area seems miles off. jnc> To be brutally blunt, I am reminded of an old military axiom: "Amateurs jnc> study tactics, professionals study logistics." I suspect the network jnc> analogue is "Amateurs design addressing schemes, professionals design jnc> routing architectures." Brutal to the point of playing the man not the ball (as they say in football around here). I gather this means that you have a routing architecture that is incompatible with PIP. PIP claims to be compatible with any reasonable routing architecture [I think], and seems to substantiate that claim with its examples. So I'd really like to understand your incompatible routing architecture. I'm sorry to ask you describe your scheme in terms an amateur like me can understand, but I am sure you will find the effort worthwhile since there a lot of people you will need to convince in the end, and while I may be below average in this mailing list I am probably above in the wider community in which this decision will ultimately be taken. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - One thing I can't understand is the push for a fixed length endpoint identifier. Since it only occasionally appears in packets I wouldn't have thought the efficiency of processing was a big deal. On the other hand the ability to do multi-level hierarchical allocation seems very desirable. It seems like an obvious application for the OSI object identifier (OID) or something similar (internet object identifier!). Bob Smart From owner-Big-Internet@munnari.oz.au Wed Jun 24 21:44:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22042; Wed, 24 Jun 1992 21:44:15 +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 AA22036; Wed, 24 Jun 1992 21:44:08 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA29498); Wed, 24 Jun 92 06:44:03 CDT Received: by san-miguel.is.rice.edu (AA07160); Wed, 24 Jun 92 06:44:02 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9206241144.AA07160@san-miguel.is.rice.edu> Subject: Re: thoughts on "re: network number and addresses" To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 24 Jun 92 6:44:01 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9206240617.AA15056@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 24, 92 2:17 am X-Mailer: ELM [version 2.3 PL11] Noel Chiappa > > In the normal case (i.e. no migrating processes, dynamically > reconfigurable multi-processors, etc) each host computer would have one > identifier, which would stay with that 'system' for ever. (I.e., if you > plugged in a new 802.X interface, or even upgraded to a more powerful CPU, > you'd always keep the same ID, as long as the "identity" of the system > remained the same.) > So, all we really need is a method to 1. Identify an end system without the benefit of tagging the id a component of the system. (where in the system do you embed the id?) 2. Map end system location as X,Y,Z coordinates, using latitude, longitude, and distance from the center of the earth (at least for now) This will be able to provide the basis for defining a routing architecture. The question that remains is what is the level of granularity. How small can the end systems be and do you measure the X,Y,Z coordinates in microns? -- 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 Thu Jun 25 03:00:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29941; Thu, 25 Jun 1992 03:16:55 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26961; Thu, 25 Jun 1992 00:15:08 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA20587; Wed, 24 Jun 92 07:14:52 -0700 Received: by us1rmc.bb.dec.com; id AA27027; Wed, 24 Jun 92 10:16:13 -0400 Message-Id: <9206241416.AA27027@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Wed, 24 Jun 92 10:16:15 EDT Date: Wed, 24 Jun 92 10:16:15 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 24-Jun-1992 1017" To: big-internet@munnari.oz.au Cc: kasten@europa.clearpoint.com Apparently-To: kasten@europa.clearpoint.com, big-internet@munnari.oz.au Subject: RE: thoughts on "re: network number and addresses" Frank, Allowing IEEE numbers (and IP4 addresses and any other convenient currently assigned numbers that will fit) within a new-IP ID is a fine idea. I think any thought of globally flooding some fact through the entire future internet is almost absurd on its face. When a host moves, you are going to have to accept that some parts of the internet will have a wrong old address cached for some length of time. Packets sent to the old address need to result in message(s) giving the new address. Just how routers near the old address get told about the new address, how long the cache time outs are (would have to be at least the IP4 standard 4 minutes I would think unless time-to-live is changed), whether packets sent to the old address are also forwarded to the new address, etc., can all be decided. But flooding the Internet with address updates is right out! I also believe there will be some mobile systems best handled within the system. Time scales do make a difference. Its very different if a host is unplugged from one place and plugged in elsewhere hours later compared to a host communicating by cellular phone while driving across Manahattan at night. Due to the density of cellular phones in parts of Manhattan, they are almost at the level of a cell per building. This works OK during the day but I understand that at night cross town traffic is fast enough that the analog cellular phone switching sometimes can't keep up. If a host is (or 10**N of them are) changing attachment point every few seconds in some sort of cellular system, you may want this handled entirely within that system rather than be constantly updating external databases. This would keep the "address" of the host constant. Donald -------------- From: US1RMC::"kasten@europa.clearpoint.com" "Frank Kastenholz" 23-JUN- 1992 17:26 To: bigfut::callon, jnc@ginger.lcs.mit.edu CC: big-internet@munnari.oz.au Subj: thoughts on "re: network number and addresses" hi ... i would suggest that the host id number be made 8 bytes long and that the first two bytes be assigned by iana as an "id assignment domain" (idad?) an idad of, e.g., 0x0802 would indicate that the remaining 6 bytes are an 802 number. lots of other machines have serial numbers of various types (maybe even pcs?) and idads could be provided for them... ... 2) earlier today noel talked about some issues related to mapping host id numbers, addresses (i.e. 'attachment points'), mobile hosts, and so on. it seems to me that what you all are talking about is some method of having a host register itself with the network (e.g. when a host gets connected to the net at some point it sends a message to the local route/name/... server that says "hi, i'm here, my name is mumble, my id number is frotz"). a possible extension on this is that when the local server gets this message, it floods a message through all of the servers on the net that would flush any stale information with respect to the newly attached node. ... 3) host id numbers really ought to be invariant. suppose that i have a some scheme that allows network service similar to a cellular phone system (i do not mean mobile hosts in the sense of unplugging my laptop here, putting it in my briefcase, flying to japan, and then plugging it into a different network attachment service provider). as i go roaming through this cellular network my machine may be on and i will be hopping from one network attachment service provider to another. i may want to keep my machine on and working through these hops -- sending and receiving traffic. if my "host id" changes each time i make such a hop, then the node at the other end of the tcp connection (it seems that a tcp connection will become the 4-tuple of local/remote hostid and local/remote port) will lose track of me. the other host used to know me as #123 and i become #456. i suppose that some message could be flooded through the network to the effect of "id number 123 is now known as 456" but that would have to be a broadcast throughout the entire internet and in general seems rather icky. furthermore, how are the host ids assigned? does each network attachment service provider have its own pool of assignable ids? would not the host id then start to have some topology information in it (e.g. nearnet is assgned the pool of ids 0-499 so if a host has id number 123 then i know that it is on nearnet....)? isn't this what the the ip address of today sort-of is? keep the host ids unique throughout all (internet) space and time. frank kastenholz From owner-Big-Internet@munnari.oz.au Thu Jun 25 03:34:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00684; Thu, 25 Jun 1992 03:34:44 +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 AA00681; Thu, 25 Jun 1992 03:34:37 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA04431; Wed, 24 Jun 92 10:34:20 PDT Message-Id: <9206241734.AA04431@Mordor.Stanford.EDU> To: Jon Crowcroft Cc: Robert Elz , big-internet@munnari.oz.au Subject: Re: TUBA Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 23 Jun 92 18:09:36 +0100. <9206231710.21576@munnari.oz.au> Date: Wed, 24 Jun 92 10:34:19 -0700 From: Dave Crocker >You also need urgent data, crossing-opens (I forget the right >term, I mean when each end independantly sends a SYN to the >other at the same time), and probably an ability to close the half open stuff - not hard... Jon, and everyone else, I'd like to suggest that we all be very careful when we declare someting "not hard." For most of the people on this list, I suspect a remarkably large number of new technical ideas and software changes are "not hard". I also suspect that this group is in no way representative of the rest of the world. Our job is to create change. Most of the rest of the world'd job is to keep things running or to sell things. This requires a very different type of person and they work in an organizational context that is very different from an engineering development environment. For one thing, we might want to track the number of "not hard" things that are being required for the various avenues of change that we are discussing. The aggregate effect of all those little changes turns out to be "quite hard." Dave From owner-Big-Internet@munnari.oz.au Thu Jun 25 03:43:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00922; Thu, 25 Jun 1992 03:43:54 +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 AA00916; Thu, 25 Jun 1992 03:43:44 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA04499; Wed, 24 Jun 92 10:42:23 PDT Message-Id: <9206241742.AA04499@Mordor.Stanford.EDU> To: Tracy Mallory Cc: Ross Callon , big-internet@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 23 Jun 92 15:52:33 -0400. <9206231956.25285@munnari.oz.au> Date: Wed, 24 Jun 92 10:42:22 -0700 From: Dave Crocker The more that people discuss using IEEE 48-bit numbers, the more I get confused about the administrative support that will assign these numbers to real users (more than 10**9) in any supportable fashion. Could your or someone else describe the administrative structure that is like to operate successfully with this scheme? Thanks. Dave From owner-Big-Internet@munnari.oz.au Thu Jun 25 04:20:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02808; Thu, 25 Jun 1992 04:20:28 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA02796; Thu, 25 Jun 1992 04:20:17 +1000 (from mm@cannibal.gandalf.ca) Received: from hobbit.gandalf.ca by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05386; Wed, 24 Jun 92 11:12:12 -0400 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA02419; Wed, 24 Jun 92 11:07:14 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA10986; Wed, 24 Jun 92 11:07:10 EDT Date: Wed, 24 Jun 92 11:07:10 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9206241507.AA10986@cannibal.gandalf.ca> To: big-internet@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) > Well, there is something to this. On the other hand, why not extend >the principle? If something is in K-level area X, and you are in K-level area >Y, you don't need to know its address below the K-level part (i.e. parts K-1 >through 0); you can simply send the packet to the correct K-level entity, and >let it fill in the lower parts, which are only useful, and known, local to >that K-level area. The final "hop" in a route *is* different from the rest, because that's the first time the packet is not delivered to a router (and the last time it is delivered to anything). I don't know, I thought ARP was the one piece of the puzzle that made the TCP/IP suite go farther than the rest, given the proliferation of (broadcast) hardware types in the local nets. On broadcast nets everybody doesn't need to know everybody else's hardware address most of the time, and it is sufficient to do a lookup when necessary. ARP lets hardware addresses come and go without involving any administration or affecting databases outside the local net. Less efficient to have to go to a possibly non-local name service for this locally relevant info. It's not just one new piece of information in the name service: it's both the h/w address and the mappings which contain it. Changing the mapping potentially affects a lot of copies outside the broadcast net. Routers have to know about all their neighbor routers' hardware addresses all the time, and going to a name service to get it when you acquire a new neighbor should not be a hardship, unless routing topology is changing very fast (mobile routers). I can remember an IP address, and sometimes even a mapping between an IP address and a host name. I can't remember IEEE addresses, so remembering mappings is out of the question. Comparisons to white pages are relevant, because part of the reason the system succeeds is that human memory, short and long term, can handle the names and numbers (and it doesn't look like complete gibberish when written down). In most cases the IP addresses I have in my head all have the same first digits too. That helps (it's like an area code). It's good to design routing that can scale up *really* big, but it has to work on the local level too. -Chris Sullivan From owner-Big-Internet@munnari.oz.au Thu Jun 25 04:34:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03863; Thu, 25 Jun 1992 04:34:23 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03830; Thu, 25 Jun 1992 04:34:05 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA20357; Wed, 24 Jun 92 14:33:52 -0400 Received: by easynet.crl.dec.com; id AA03139; Wed, 24 Jun 92 14:31:42 -0400 Message-Id: <9206241831.AA03139@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Wed, 24 Jun 92 14:31:45 EDT Date: Wed, 24 Jun 92 14:31:45 EDT From: Ross Callon To: dcrocker@mordor.stanford.edu Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: dcrocker@mordor.stanford.edu, big-internet@munnari.oz.au Subject: re: network number and addresses (administration of IEEE IDs) > > The more that people discuss using IEEE 48-bit numbers, the more I > get confused about the administrative support that will assign these > numbers to real users (more than 10**9) in any supportable fashion. > > Could your or someone else describe the administrative structure that > is like to operate successfully with this scheme? > Currently IEEE hands out large chunks of the space to computer manufacturers. Specfically, they hand you a 24 bit prefix, and the manufacturer is free to assign the remaining 24 bits. Generally, systems are "stamped at birth" with a particular value for the 48 bit ID field (for example, a very low cost PROM is added to the hardware, where the PROM encodes the ID). In some (most) cases, this means that a particular LAN interface is stamped with the ID. However, it is also possible to stamp a computer system with a unique ID (even if it doesn't have an interface to an 802 LAN). Thus, the notion is that new systems built in the future would have their globally unique system ID built into them, and would not **need** to have the IDs configured. Mostly likely, we would want the system to default the ID to the "stamped in hardware" value, but require the ability to manually configure an alternative value. This would, for example, be useful if you need to send your computer into the shop to be fixed, and want the temporary replacement to use the same address (including the same ID) as you have been using all along. If we use IEEE IDs as globally unique system IDs, then there will be some systems which do not have a ID stamped in their hardware but need an ID assigned to them. For example, existing systems may have software upgrades to implement an updated Internet suite, but not have any hardware upgrade. In order to deal with such systems, I believe that the IANA should obtain one or more blocks from IEEE, and assign smaller sub-blocks to network operators who could then configure systems under their control with the appropriate IDs. With the TUBA proposal, assuming that we use a globally unique ID as the "ID" field (this is not a requirement for the TUBA approach, but is one possible option), then the system could determine the rest of its own address by listening to the network to which it is attached. Hosts therefore would not require any manual configuration of their network addresses. Similarly, if addresses had to change (i.e., the ID could stay the same, but the higher order part of the address needed to change), then address re-configuration in the hosts would also be automatic (DNS servers and routers would require manual address re-configuration in this case). Ross From owner-Big-Internet@munnari.oz.au Thu Jun 25 04:47:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04787; Thu, 25 Jun 1992 04:47:31 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA04776; Thu, 25 Jun 1992 04:47:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11695; Wed, 24 Jun 92 11:48:30 -0400 Received: by ginger.lcs.mit.edu id AA18316; Wed, 24 Jun 92 11:44:25 -0400 Date: Wed, 24 Jun 92 11:44:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206241544.AA18316@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: meta matters Cc: jnc@ginger.lcs.mit.edu Well I completely disagree with this characterization of PIP. Huh? The PIP document itself says right up front it doesn't talk about routing. ("This paper does not discuss the dynamic algorithms such as routing ... that are required to make Pip work.") Actually, PIP does have some implied worldviews about routing (e.g. use of routing tables, and differing internal and external routing), both of which I disagree with, although since PIP is so general I suppose you can say that these aren't really fundamental to PIP. I gather this means that you have a routing architecture that is incompatible with PIP. I'm confused as to how you think an alternative routing architecture could be 'incompatible' with PIP, since PIP doesn't have a routing architecture (which Paul has just been pushing as an advantage of PIP :-), which was the basic substance of my complaint! I'd really like to understand your incompatible routing architecture. I can only give the merest gloss without producing a tome almost as long as the I-D, but briefly it is a source routed (with flow setup for effficiency in longer 'conversations'), link state heirarchical system with non-fixed abstraction (both incoming and outgoing). The abstraction mechanisms are where most of the wierd ideas are (e.g. unlike in conventional LS system, everyone can have a different map). One thing I can't understand is the push for a fixed length endpoint identifier. Since it only occasionally appears in packets... Huh? The whole point of endpoint identifiers is that they are in *every* packet. In the TUBA scheme, it is part of the extended TCP pseudo-checksum. Depending on whose scheme you are talking about, you may or may not have addresses in every packet (any more than you have routes in every packet now). Noel From owner-Big-Internet@munnari.oz.au Thu Jun 25 04:55:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05196; Thu, 25 Jun 1992 04:56:10 +1000 (from owner-Big-Internet) Return-Path: Received: from asherah.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05189; Thu, 25 Jun 1992 04:55:55 +1000 (from avri@asherah.clearpoint.com) Received: by asherah.clearpoint.com (4.1/1.34) id AA13104; Wed, 24 Jun 92 14:52:55 EDT Date: Wed, 24 Jun 92 14:52:55 EDT From: avri@asherah.clearpoint.com (Avri Doria) Message-Id: <9206241852.AA13104@asherah.clearpoint.com> To: dee@ranger.enet.dec.com Cc: big-internet@munnari.oz.au In-Reply-To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 24-Jun-1992 1017"'s message of Wed, 24 Jun 92 10:16:15 EDT <9206241416.AA27027@us1rmc.bb.dec.com> Subject: RE: thoughts on "re: network number and addresses" it seems that some sort of change of address notification to the previous neighboring gateway would be necessary. i.e. if a host is required to notify its prior neighboring gateway when it reattachs to the network, a redirection could result. if the system is off the net for a timeout period, there is no need for redirection. also, in the case of a place like nyc, i would assume that there would be a fixed point which would be defined to be the closest stable neighbor. avri From owner-Big-Internet@munnari.oz.au Thu Jun 25 06:36:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09236; Thu, 25 Jun 1992 06:36:16 +1000 (from owner-Big-Internet) Return-Path: Received: from gizmo.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09233; Thu, 25 Jun 1992 06:36:08 +1000 (from mo@gizmo.bellcore.com) Received: by gizmo.bellcore.com (5.61/1.34) id AA14721; Wed, 24 Jun 92 16:35:58 -0400 Date: Wed, 24 Jun 92 16:35:58 -0400 From: mo@gizmo.bellcore.com (Michael O'Dell) Message-Id: <9206242035.AA14721@gizmo.bellcore.com> To: big-internet@munnari.oz.au Subject: ARP and virtual IP addressing To take modest issue with Noel, In one sense, he is right - ARP was created on the spur of the moment by a pressing need. However, it introduced a new facility into the protocol pile which has proven incredibly useful - it made an IP address into a logical address. Once upon a time, when interface addresses fit in IP addresses, the assignment was algorithmic - do some kind of bit insert into a 32-bit constant primed with "the network number" and you got the IP address. ARP changed all that, and things now take great advantage of it. While there are other examples like Proxy ARP, which one might argue are hacks to paper over other architectural warts, a few stand out as really useful facilities. At least one system I know of uses ARP to help implement fail-soft file servers for read-only filesystems. The redundant servers conspire among themselves such that if one goes down, another one elects to start ARPing for the dead machine's address. The clients looking for their server soon time out their ARP cache entry (or a user daemon senses the server failing to respond sooner and flushes the ARP cache brute-force) and the clients happily rediscover the new server impersonating the old one. Grungy, maybe; incredibly valuable, yes. So, Noel, while I don't dispute the historical record you quote, the result over time has made ARP a "good idea", its humble beginnings not withstanding. -Mike From owner-Big-Internet@munnari.oz.au Thu Jun 25 07:34:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11729; Thu, 25 Jun 1992 07:34:14 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA11711; Thu, 25 Jun 1992 07:34:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05703; Wed, 24 Jun 92 11:24:11 -0400 Received: by ginger.lcs.mit.edu id AA18172; Wed, 24 Jun 92 11:23:50 -0400 Date: Wed, 24 Jun 92 11:23:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206241523.AA18172@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: meta matters Cc: big-internet@munnari.oz.au The problem with designing a routing architecture, then designing an address to that architecture, is that when you want to change your architecture, you are stuck. Well, I think the system is getting so big that we can't afford to change the routing architecture again, any more than we can afford to change the address structure. That's why a lot of time in Nimrod was spent trying to minimize the 'system-wide' part of the routing architecture, so that we could incrementally change it, without having to have a global change. To my mind, the biggest single advantage of the source routed link state systems is that it does allow you to minimize the core protocol; i.e. most things like routing algorithms, abstraction algorithms, etc, wind up as samples in appendixes, not part of the core spec. I agree with this sentiment COMPLETELY Ah, hoisting me upon my own whatsis with my own words! Excellent style! However, as I pointed out, "PIP in many ways is something I like". I don't disagree wildly with a lot of what is in the PIP address format. (It is worth pointing out that if hosts deal primarily with the endpoints identifiers, and treat the addresses as byte strings which they only handle for purposes of efficiency, but don't understand the format of, [e.g. when they do the 'string name' -> 'endpoint identifier' lookup, they can get and save the address at the same time], you get pretty much the same flexibility. Yes, if you define a new address format, you have to change all the routers, but presumably if you do have a new address format you are changing the routing [and hence all the routers] anyway. Handling new format addresses is probably minimal work compared to a whole new routing system.) Having said that, I still go back to my original point; I don't see it as likely that we will be able to change the routing architecture (and the address format) again..... If that's so, is the cost of the extra flexibility in PIP worth what we get? since the Pip Routing Directive is so general, it can encode current routing architecture addresses just fine, while still allowing for future architectures (such as path setup or source-based policy route or something we haven't thought up yet) Well, this is what worries me, actually. Is PIP so general that it has crossed the line into a second-system, kitchen sink approach to design? Coming from the minimalist school of design ("Perfection has been attained .. when there is nothing left to take away."), perhaps you can see why the extreme generality of PIP makes me nervous? Now, what do you recommend, that we come up with the "perfect" routing architecture, and then design our address for it, and then we're done? What happens in 2 or 5 or 10 years when the routing architecture comes up short? No, I don't think I (or anyone or collection of people) can design, in short order (i.e. less than 5 years), the perfect routing scheme, in all details. There are many years of research (on such issues as 'good approximation' pairwise path discovery, cost functions to evaluate abstraction algorithms, etc, etc) yet to come. (I've neither the talents, skills nor energy to do them.) The important goal from my perspective, again, is to create a routing architecture which will allow easy incremental deployment of advances in these areas. This much I think we *can* do. Why can't you do complete policy routing with fields you stick in packets. I can easily imagine policies which cannot be stated in anything less powerful than a general purpose programming language. E.g. "don't take any links which cost more than $.02 per Kbyte, except if you're going to cause a delay of more than 50msec by taking the cheaper path, when it's OK to pay up to $.05 per Kbyte, and pay as much as you need to make sure I get at least 1 Kbyte/sec of bandwidth". Since including a program with each packet seems a little excessive, I could leave it there. I will, however, also point out that you might have policies you *don't want* the rest of the world to know about. E.g., maybe you're mad at XYZ Corp, and want to boycott their (pay) networks, but don't want them to know. So, there are lots of examples of policies you basically can't put in packets. I publicly challange you to find an aspect of Nimrod or any other plausible routing architecture that results in data packets that can't be carried using the Pip header and forwarding function as it is now defined. This is not my problem with PIP. Clearly PIP can do all these things. My primary problem with PIP is that I see it as diverting us from what I see as the biggest issue we need to tackle; defining a routing architecture which has the flexibility to last indefinitely. We simply can't throw away *another* routing architecture; the system will be too big. Noel From owner-Big-Internet@munnari.oz.au Thu Jun 25 07:36:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11810; Thu, 25 Jun 1992 07:36:18 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA11802; Thu, 25 Jun 1992 07:36:09 +1000 (from callon@bigfut.enet.dec.com) Received: from crl.dec.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA15857; Wed, 24 Jun 92 12:08:35 -0400 Received: by crl.dec.com; id AA13174; Wed, 24 Jun 92 12:08:12 -0400 Received: by easynet.crl.dec.com; id AA00675; Wed, 24 Jun 92 12:05:54 -0400 Message-Id: <9206241605.AA00675@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Wed, 24 Jun 92 12:05:55 EDT Date: Wed, 24 Jun 92 12:05:55 EDT From: Ross Callon To: dee@ranger.enet.dec.com, big-internet@munnari.oz.au Cc: callon@bigfut.enet.dec.com Apparently-To: dee@ranger.enet.dec.com, big-internet@munnari.oz.au Subject: re: network number and addresses (possible source of confusion) > > Anyway, in the context of the above, using CLNP addresses with 48bit IEEE ID's > seems like an enormous step backwards. Besides the arguments that have already > been made, what about putting more than one logical endpoint in the same > machine with one network interface? What about low earth orbit satellite > systems that may be coming along with 64 bit station IDs? > It has occured to me that there is some confusion about the relationship between globally significant system IDs, and subnet addresses. In particular there shouldn't be any *required* relationship between the two. For example, suppose that we use IEEE identifiers as global system IDs. Also, lets suppose that there is some system which happens to have an interface to an IEEE 802 network, and which therefore has a subnetwork address on that network which is also a 48-bit IEEE identifier. In this case, the two identifiers (the global system ID, and the subnet address on that particular LAN) *might* happen by coincidence to be the same, but they don't have to be the same. In particular, the routers cannot assume that they are the same. For a system which is attached to networks which don't use IEEE addresses, then there again should be no confusion: The globally unique ID uses an IEEE address, the subnetwork addresses on local network(s) use whatever address conventions happen to be used on that subnet. Thus, the use of IEEE IDs as global system IDs does not need to have any dependence on which networks the system happens to be attached to. If a system is attached to a satellite network which uses 64 bit addresses, then this is fine -- the system has a 48-bit globally unique system ID, plus a (separate) 64-bit address on the satellite network. Similarly, if there are two "logical hosts" sharing the same network interface, then each logical host just has a different globally unique ID -- there is no need for the global ID to have any relationship with the network interface. > And the rigid, non- > extensible nature of the remaining address bytes isn't very attractive either. I don't know why you think the NSAP address structure is rigid. The NSAP structure is very extensible (some would say too extensible). Perhaps again there is a confusion between what is required to be a conformant NSAP address (and what we might require for use in the Internet), versus what folks happen to be using in some operational networks. The GOSIP format spells out a particular set of subfields which are being used currently as one way to divide the address. I think that we need to make a distinction here between what the hosts can assume about the address structure, what the routers can assume about the address structure, and how folks are actually going to assign addresses. My suggestion (to include a globally unique ID in the address) subdivides the address into three fields, which the host can assume exist: (1) a 13-byte "location"; (ii) a 6-byte ID; and (iii) a one-byte selector. In fact the 13- byte "location" (which corresponds to the "area-address" as described in ISO 10589, IS-IS), may have some substructure, but the host does not need to know what the substructure is. In fact, hosts should not be *allowed* to know what the substructure is. Similarly, routers will know that destinations in their routing domain use these three major address fields (location, ID, and selector) and would use the "location" (i.e., area-address) to determine which area the destination is in, and the ID to locate the host within the destination area. Routers will also know about address prefixes used to reach other destinations (particularly, destinations outside of the routing domain). However, the exact manner in which the "location" is subdivided is not "encoded" in the router implementation. Now, when we actually go to assign addresses, we need to use some specific format. Thus we assign sub-structure to the 13-byte location. We might, for initial use in the Internet, happen to use a sub-structure which is the same as the US GOSIP address format. However, this would not be encoded into router implementations, but rather would be implicit in the manner in which routing information is maintained (i.e., humans would know which address structure they are using, networks would be assigned addresses consistent with the address structure, inter-domain routing would be configured with reachable address prefixes consistent with the address structure, ...). Thus, suppose that in the future a different routing domain were set up using addresses based on Steve Deering's Geographic addressing proposal. Perhaps this network is one which serves households. In this case the systems which get newly hooked up in the house would get an address that is based on their geographic location, using an address format (i.e., an address sub-structure applied to the 13 byte "location"), which is different from the US GOSIP address structure. But this would still be compatible with the existing host and router implementations. Similarly, systems attached to a Public Data Network using E.164 addresses (or systems attached to small networks which are themselves attached to the public data network) might want to use the E.164 NSAP format (a format in which the high-order part of the "location" starts with a one byte "AFI" stating that the next thing is an E.164 address, followed by the globally unique E.164 address). In the case that there is a corporate network attached to the Public network (not just a single host), there is still enough flexibility in the NSAP address to allow the E.164 address to be followed by additional fields (again, a subfield of the "location" part of the address) to identify, for example, multiple areas within the corporate network. [Naturally, if the public data network uses a different address format, such as an X.121 address, then this is also handled with NSAP addresses.] Thus use of the NSAP address allows for a large amount of flexibility. Ross From owner-Big-Internet@munnari.oz.au Thu Jun 25 07:59:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12787; Thu, 25 Jun 1992 07:59:33 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12766; Thu, 25 Jun 1992 07:59:18 +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 AA25337; Wed, 24 Jun 92 14:57:48 PDT Received: from chestnut.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA18483; Wed, 24 Jun 92 14:57:51 PDT Received: by chestnut.Eng.Sun.COM (5.0/SMI-SVR4) id AA03423; Wed, 24 Jun 92 14:57:05 PDT Date: Wed, 24 Jun 92 14:57:05 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9206242157.AA03423@chestnut.Eng.Sun.COM> To: mo@gizmo.bellcore.com (Michael O'Dell) Cc: big-internet@munnari.oz.au In-Reply-To: <9206242035.AA14721@gizmo.bellcore.com> Subject: ARP and virtual IP addressing Content-Length: 212 I agree with Mike on this. I think the extra level of indirection provided by ARP in the mapping of an IP address to a physical address has been very useful. I would hate to see us loose that capability. Bob From owner-big-internet@munnari.oz.au Thu Jun 25 11:22:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18980; Thu, 25 Jun 1992 11:22:06 +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 AA13713; Thu, 25 Jun 1992 08:35:28 +1000 (from kre) To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of Wed, 24 Jun 92 19:59:26 +1000. <9206240959.AA10523@wanda.mel.dit.CSIRO.AU> Date: Thu, 25 Jun 92 08:35:18 +1000 Message-Id: <15939.709425318@munnari.oz.au> From: Robert Elz Date: Wed, 24 Jun 92 19:59:26 +1000 From: Bob Smart Message-ID: <9206240959.AA10523@wanda.mel.dit.CSIRO.AU> One thing I can't understand is the push for a fixed length endpoint identifier. Since it only occasionally appears in packets A later message from Noel may have made this obvious already, but as it was down near the end of at least a reasonably sized message I thought I might say it again... There's one large difference between Noel's and Paul's views of the use of ID's and addresses... Take the below as my reading of the state of things only ... Noel believes that every packet will contain the ID, and the ID will be at least part of what the routers use to route packets (somehow) to their destinations. The address only appears occasionally, routers remember the ID->address mappings. This allows for very long addresses, as they're not in many packets. Paul believes that ID's only occasionally appear in packets, and that routing is done based on the address which is in every packet - hosts remember the address -> ID mapping of incoming packets and use that to reconstruct the ID for packets that don't carry the ID in them - for this the nature of the ID is less important, but addresses want to be encoded quite effeciently. Now I've said this, I'm sure that if I have misrepresented anyone I will hear about it. kre From owner-big-internet@munnari.oz.au Thu Jun 25 11:38:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19600; Thu, 25 Jun 1992 11:38:52 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14325; Thu, 25 Jun 1992 08:56:22 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA28118 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 25 Jun 1992 08:56:18 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA00561; Thu, 25 Jun 92 08:56:17 EST Message-Id: <9206242256.AA00561@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Wed, 24 Jun 92 11:23:50 -0400." <9206241523.AA18172@ginger.lcs.mit.edu> Date: Thu, 25 Jun 92 08:56:16 +1000 From: Bob Smart > I publicly challange you to find an aspect of Nimrod or any other > plausible routing architecture that results in data packets that > can't be carried using the Pip header and forwarding function as > it is now defined. > > This is not my problem with PIP. Clearly PIP can do all these >things. Since you can do your Nimrod routing architecture with PIP, why not have a go at producing a document showing how that would work. THEN you can point out how PIP has all these extra features that you don't use, and since Nimrod is clearly the only routing architecture the world would ever need we can discuss whether PIP has too many features in the context of a concrete example. > I can only give the merest gloss without producing a tome almost as >long as the I-D, but briefly it is a source routed (with flow setup for >effficiency in longer 'conversations'), link state heirarchical system with >non-fixed abstraction (both incoming and outgoing). The abstraction mechanisms >are where most of the wierd ideas are (e.g. unlike in conventional LS system, >everyone can have a different map). Thanks for the description. If anyone (other than Noel) understands all this I'd be interested to hear: you don't have to explain it just to let me know your there. If anyone thinks that I should leave this list and leave it to the experts I'd be interested to hear that as well. However I've been in networking a long time and one thing I've noticed is that things I understand, like TCP/IP and its components, are doing a lot better than things I can't understand in detail. > > One thing I can't understand is the push for a fixed length endpoint > identifier. Since it only occasionally appears in packets... > > Huh? The whole point of endpoint identifiers is that they are in >*every* packet. In the TUBA scheme, it is part of the extended TCP >pseudo-checksum. Depending on whose scheme you are talking about, you may or >may not have addresses in every packet (any more than you have routes in every >packet now). Well this makes me wonder if you've read the PIP documents. Clearly you need a forward address (to get the packet there). You need a backward address for routers to send back ICMPs/etc without doing lookups which they don't (in general) have time to do. However the address<->identifier correspondence stays fixed for a long time so it is not necessary to have the identifier(s) in every packet. If you get a packet from an address for which you don't have a current identifier then you send back an ICMP saying "your address has changed so please send identifier in next packet". If the address for an identifier keeps changing you send an ICMP saying "if you're going to keep moving around like that you'd better send your identifier in every packet". This doesn't stop you using the identifier in the TCP checksum: you do always know the identifier for every packet you accept and use. Since the addresses are large, whether fixed or variable length, it is silly to put them in every packet. Bob Hinden writes: >I agree with Mike on this. I think the extra level of indirection >provided by ARP in the mapping of an IP address to a physical address has >been very useful. I would hate to see us loose that capability. Surely the meaning of that last address component is network specific. People writing the RFC for the specific low level mechanism will determine if it is best to use something like ARP. In the case of non-broadcast multi-host networks (like x.25, isdn) it is probably better to have the physical address in the NewIP address. In other cases it is less clear, but we don't have to decide that in this forum. Bob Smart From owner-Big-Internet@munnari.oz.au Thu Jun 25 12:59:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22511; Thu, 25 Jun 1992 12:59:44 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22507; Thu, 25 Jun 1992 12:59:40 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA03213 (5.65c/IDA-1.4.4/DIT-1.3); Thu, 25 Jun 1992 12:59:36 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA01337; Thu, 25 Jun 92 12:59:35 EST Message-Id: <9206250259.AA01337@wanda.mel.dit.CSIRO.AU> To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Thu, 25 Jun 92 08:35:18 +1000." <15939.709425318@munnari.oz.au> Date: Thu, 25 Jun 92 12:59:34 +1000 From: Bob Smart I wrote: > Since the addresses are large, whether ^^^^^^^^^ >fixed or variable length, it is silly to put them in every packet. I meant "identifiers". Perhaps we can standardize on "ID". Thanks to kre for a very clear description that explains a lot of my misunderstandings. >appears occasionally, routers remember the ID->address mappings. >This allows for very long addresses, as they're not in many >packets. I remember this now, perhaps from the Nimrod doc. I think I must have repressed it. It reminds me of X.25, with intermediate systems knowing about all the connections through them. Still PIP discusses something very like this with route setup creating appropriate logical routers. One of the reasons that IP works better than X.25 is that it makes the end-systems do much more of the work. I wouldn't like to see that philosophy change. The X.25 approach tends to make connections an expensive resource. I remember trying to survive with 5 virtual circuits to the outside world. And now we have (N)ISDN. Not much progress. Bob Smart From owner-Big-Internet@munnari.oz.au Thu Jun 25 14:59:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26104; Thu, 25 Jun 1992 14:59:34 +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 AA26095; Thu, 25 Jun 1992 14:59:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21265; Thu, 25 Jun 92 00:59:03 -0400 Date: Thu, 25 Jun 92 00:59:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250459.AA21265@ginger.lcs.mit.edu> To: kre@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Now I've said this, I'm sure that if I have misrepresented anyone I will hear about it. No, you've got my position almost exactly. About the only minor change I would make (and it's really semantics, since I think you meant what i think) is to say that "the ID will be at least part of what the routers use to *forward* packets (somehow) to their destinations." I distinguish between deciding what the next hop will be (which I call "routing", although I also apply this term to the distribution of routing information), and handling the packet through the router (which I call "forwarding"). In a system which does hop-by-hop routing, the two terms are synonomous, since each forwarding step includes a routing step, but in a system which is basically source-routed, you do have to distinguish between the two. Noel From owner-Big-Internet@munnari.oz.au Thu Jun 25 15:26:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26677; Thu, 25 Jun 1992 15:26:14 +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 AA26672; Thu, 25 Jun 1992 15:26:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21375; Thu, 25 Jun 92 01:26:00 -0400 Date: Thu, 25 Jun 92 01:26:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250526.AA21375@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, jnc@ginger.lcs.mit.edu, z.wang@cs.ucl.ac.uk Subject: re: network number and addresses (ID to ... mapping) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu If the ID stays the same regardless of where the host moves worldwide, then we are going to find ourselves with an ID space which has NO RELATIONSHIP between what the ID is and where the host is. In talking to Ross today, I discovered he is trying to say something valuable, but I don't think it came across as clearly as it might. Let me try clarifying it by giving an example. Let's say that company X in Japan builds workstations, and sells on to me and the next serial numbered one to the person in the office next to me. Now, let's assume that the enpoint->address mapping for these boxes is in a replicated server in Japan, where these boxes came from. Thus, every time I want to send packet to the next door box, it seems like I have to do a lookup on a translation server a long way away. The point here is that there is no natural topological colocation of translations with the users of those translations. (The same problem doesn't happen with name->address translations since typically you do most translations on names which are in your part of the administrative heirarchy, and typically the name server for your part of the AH is locally located, so that's why we don't see the problem now.) This is clearly Not Good. However, the situation is not necessarily as bad as it looks. One simple solution to this problem is to increase the replication rate of the endpoint->address translation servers, so that a copy of any translation is relatively near by. However, I think this is missing the point. In a fully operational system, I don't expect we will be doing endpoint->address translations (or endpoint->anything, for that matter) very often. Think about it; in what circumstances will you have a packet with only the endpoint, and nothing else? The circumstance where the first hop router has to do this is transitory, since we are only doing this as an incremental deployment measure, to allow interoperation without *requiring* host modifications. Hosts will be modified to get the address (as a byte string which they do not know how to parse) at the same time as they get the identifier, and pass it on to their router. As a (kludgy) efficiency measure, we could even do the interim more efficiently by having the routers wiretap name server traffic from hosts which aren't modified. I expect that in a fully operation system the places where you will *need* to do this translation are pretty few and far between; fault analysis, perhaps some error reporting, and similar cases. I just don't see a lot of places where you'd wind up with a packet to an identifier you've never heard of before. Still, it's a good point, and one we need to keep in mind. Noel From owner-Big-Internet@munnari.oz.au Thu Jun 25 16:00:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27675; Thu, 25 Jun 1992 16:00:38 +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 AA27672; Thu, 25 Jun 1992 16:00:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21713; Thu, 25 Jun 92 02:00:18 -0400 Date: Thu, 25 Jun 92 02:00:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250600.AA21713@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu First, it is one thing to change the routing algorithm, and another to have to change the forwarding engine. It would be nice if some day we could start putting the forwarding engine in hardware without the concern that we have to change it every few years. First, I was positing that we could not change the routing algorithm, let along the forwarding algorithm. I don't see how your comment relates to this (admittedly hypothetical) position? Next, are inflexible hardware forwarding engines really practical in a multi-protocol world? Most router vendors these days seems to sell boxes which handle 17 protocols. (I exclude hardware designs such as the Faswitch which have enough programmabilty built in to handle multiple protocols; they obviously could also handle a new address/routing scheme.) Finally, I have a hard time imagining a scheme which does hop-by-hop routing, changes the routing algorithm, and doesn't affect the forwarding algorithm. The whole point of hop-by-hop (which PIP seems to want to support, if I am not misreading the document) is that forwarding and routing (using the terminology I recently defined) are intermingled. How can you change one and not affect the other? Third, if we don't do Pip now, we'll do CLNP. I'm not sure I see the 'historical necessity' here. A number of schemes (including Encaps, Nimrod, etc) were proposed without benefit of PIP. Are you saying that PIP is the only realistic alternative to CLNP? Could you explain the chain of thought that leads you to this conclusion? Noel From owner-Big-Internet@munnari.oz.au Thu Jun 25 16:48:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29046; Thu, 25 Jun 1992 16:49:07 +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 AA29028; Thu, 25 Jun 1992 16:48:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21984; Thu, 25 Jun 92 02:48:51 -0400 Date: Thu, 25 Jun 92 02:48:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250648.AA21984@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, dcrocker@mordor.stanford.edu Subject: re: network number and addresses (administration of IEEE IDs) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Similarly, if addresses had to change (i.e., the ID could stay the same, but the higher order part of the address needed to change), then address re-configuration in the hosts would also be automatic (DNS servers and routers would require manual address re-configuration in this case). The current level of DNS technology would require manual changes, yes, but I would hope we could automate it, so that hosts could add/update the name entry automatically. Yes, we need policy and authorization tools, but this is not impossible. The Internet in general is reprehensibly lacking in automatic mechanisms. Appletalk is an order of magnitude better in this area, and we really need to study them. Probaly the biggest single selling point of Appletalk for naive users is you don't have to have a CS PhD to set it up. If IP, OSI, or anything is going to be WorldNet, it's going to have to get with the program on this axis. Noel PS: Some of my recent thinking about large scale routing indicates you'd want to automatically readdress portions of the topology (i.e. hosts, routers, networks, the lot) as the topological connectivity changes. This margin isn't big enough to explain why, but this would also clearly need automatic updating. From owner-Big-Internet@munnari.oz.au Thu Jun 25 17:47:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00719; Thu, 25 Jun 1992 17:47:13 +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 AA00713; Thu, 25 Jun 1992 17:47:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22171; Thu, 25 Jun 92 03:47:00 -0400 Date: Thu, 25 Jun 92 03:47:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250747.AA22171@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: meta matters Cc: jnc@ginger.lcs.mit.edu Since you can do your Nimrod routing architecture with PIP, why not have a go at producing a document showing how that would work. Well, first, there are a number of differences in world-view, some significant, some less so, which make this a little trickier. KRE's message made it plain I'd misunderstood something about PIP; I had taken the line "13. Pip simplifies handling mobile systems (by having flat network layer identifiers)" to mean that PIP had identifiers in every packet, but I now see on careful reading of section 3.2 that this is not so. So, that's a significant difference. Also, for what I feel are good reasons, Nimrod addresses build from the bottom up, not the top down (i.e. level 0 is the bottom, and there is no fixed 'top' level). PIP (if I am reading seciton 4.0 correctly) does things the other way around. Now admittedly, these are all easily changeable in the PIP spec. However, even assuming that, I don't see the value of showing how Nimrod could use PIP. Yes, it's obviously doable if you align the differences, but you don't need a paper to show that. Addresses in Nimrod do a limited number of things for you (see the second part of 3.3.2 for a list), and PIP tries to do so very much more there's an obvious mismatch. one thing I've noticed is that things I understand, like TCP/IP and its components, are doing a lot better than things I can't understand in detail I think it's common in the development of many field that as the field matures, things get more and more complicated (e.g. physics, medicine, etc). Networking has always had this nice attribute (which, frankly, I found very attractive, since I hate to sweat long complex learning cycles) that it was a new field, and you could get in and do things with little more than some common sense. Just as in the early days of computing (50's), where you could come in and make 3 fundamental discoveries before lunch because the field was so unharvested, you could do the same in networking. Sadly, I think those days are coming to a close. It took Van Jacobsen to make TCP work well, and if anyone thinks it was easy, I'd like to know why it wasn't done before he did it. Hell, I can barely understand how Van's stuff works when he explains it (no way I can remember why it works); it seems it took someone with a real familiarity with control theory to do it (remember what Van used to do; accelerator design :-)! The new round of work on resource allocation is even more complex. Routing is going the same way. DV algorithms are pretty much intuitively obvious; you look at the packet formats, and you can see how they work. LS algorithms are much hairier; damned if I can figure out how OSPF works from looking at the packets. Well, the next step is going to be that much worse. If RIP was 1, and OSPF was 10, the next step is going to be 100. Look at IDPR, and that doesn't have any of the hairy multi-level scaling and abstraction of Nimrod. Clearly you need a forward address (to get the packet there). You need a backward address for routers to send back ICMPs/etc without doing lookups which they don't (in general) have time to do. Yes, but these don't have to be in each packet of a flow. You do need these at the time you set up the flow; each router along the way has to cache all this stuff (and more) for sending error messages, doing local repair of flows when physical components of virtual links fail, etc. However the address<->identifier correspondence stays fixed for a long time so it is not necessary to have the identifier(s) in every packet. Turn this around; "so it's not necessary to have the *address* in every packet". The addresses is the long, complex, thing; the identifiers are the short, easy to process things which uniquely identify the source and destination. Which should be in every packet? Noel From owner-Big-Internet@munnari.oz.au Thu Jun 25 18:00:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01138; Thu, 25 Jun 1992 18:01:11 +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 AA01125; Thu, 25 Jun 1992 18:00:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22223; Thu, 25 Jun 92 04:00:49 -0400 Date: Thu, 25 Jun 92 04:00:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250800.AA22223@ginger.lcs.mit.edu> To: kre@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu One of the reasons that IP works better than X.25 is that it makes the end-systems do much more of the work. I wouldn't like to see that philosophy change. I think this is one principle probably everyone can agree on. The whole concept of fate-sharing which says that all the critical state is stored in the endpoints, not in the network, is one of the biggest wins in the whole architecture. I don't know of any proposals to change that. (In fact, my basic concept of what it is that an endpoint identifier names is a bounded end-end entity, or equally technically, a fate-sharing region.) However, the theory is that it might be useful to allow the routers to keep non-critical state. Most of what I'm hearing about how people want to do resource allocation involveds flows and a certain amount of state in the routers. Both IDPR and Nimrod (in 4.2.2) explicitly say that there is no critical state in the network, and that you can zap any router without having the end-end connection fail. Flows are big in these designs because it was felt that flows were the wave of the future for a number of reasons, resource allocation among them. Noel From owner-big-internet@munnari.oz.au Thu Jun 25 18:03:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01235; Thu, 25 Jun 1992 18:03:23 +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 AA29305; Thu, 25 Jun 1992 16:57:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22030; Thu, 25 Jun 92 02:57:16 -0400 Date: Thu, 25 Jun 92 02:57:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250657.AA22030@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, mo@gizmo.bellcore.com Subject: Re: ARP and virtual IP addressing Cc: jnc@ginger.lcs.mit.edu At least one system I know of uses ARP to help implement fail-soft file servers for read-only filesystems. The redundant servers conspire among themselves such that if one goes down, another one elects to start ARPing for the dead machine's address. See, just the kind of thing I was talking about! The system lacked flexibility through not having enough layers of naming (and indirection), so when ARP appeared... Again, this mechanism works fine on IEEE networks. Wouldn't it be much nicer to have something that worked on SMDS, ATM, etc, as well? Actually, this is a very interesting case, since really each server ought to have its own endpoint identifier. This would mean that when a server died, you'd have to go back to the place where you did the 'service name' -> 'endpoint/address' mapping, and get a new mapping. However, we don't have such mappings much now; mostly the only things we store in the DNS are host-names. Yes, you could kludge it by giving them all the same endpoint identifier, and if one died you'd redo the mapping from endpoint->address, and get a new one. This would work no matter what kind of net you were on. Still, I have this little voice that says each server should have a separate identifier, and you really need to do the remapping in this case one level further back. Noel From owner-big-internet@munnari.oz.au Thu Jun 25 18:15:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01591; Thu, 25 Jun 1992 18:16:02 +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 AA28781; Thu, 25 Jun 1992 16:40:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21947; Thu, 25 Jun 92 02:39:10 -0400 Date: Thu, 25 Jun 92 02:39:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250639.AA21947@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, mm@gandalf.ca Subject: Re: network number and addresses (are we changing CLNP??) Cc: jnc@ginger.lcs.mit.edu The final "hop" in a route *is* different from the rest, because that's the first time the packet is not delivered to a router Yes, that's so, but how does this relate to the conclusion that ARP is a good thing? (As Zheng pointed out in a private message to me, any intermediate hop may currently need to use ARP to get from one router to the next!) I thought ARP was the one piece of the puzzle that made the TCP/IP suite go farther than the rest Yes, but this was purely accidental. IP simply did not have enough layers of 'name' mapping; all it had was IP addresses and host DNS names, not enough to do some things you want to do. Given this context, when the extra layer of mapping represented byu ARP became available, everyone started using it to do their thing that the basic IP architecture wasn't rich enough to do. (Remember the Lampson aphorism; 'All problems in computer science can be solved by another level of indirection'). The big problem, of course, was that not all nets supported ARP, so all these mechanisms were not globally available. It was this line of reasoning that led to the realization that we needed another layer of naming (with mappings to and fro), and now we have identifiers. The right solution to a problem which is causing you to make kludges is to fix the system so you don't need the kludges, not to make the kludges elegant! (I'll admit, looking at all these kludges has probably prejudiced me against ARP, but I still think I've got a good case!) ARP lets hardware addresses come and go without involving any administration or affecting databases outside the local net Yes, but how often do hosts change their 48 bit addresses? How often will they change their SMDS/X.25/ATM/etc addresses? I'll bet they are about equally common. Since we have to have a lookup system which will handle the latter case, what is the use of a special mechanism which makes some cases (i.e. IEEE nets) easier? I can remember an IP address, and sometimes even a mapping between an IP address and a host name. I can't remember IEEE addresses, so remembering mappings is out of the question Aw, this is a non-starter. How many ISO addresses (which typically *include* a 48 bit address) do you remember? The fact that you already have to rely on a tool (as opposed to memory and other human builtins) to handle the IEEE mappings now doesn't seem to cramp most people. So, here in the future, we will all need better tools to hack the network since addresses aren't simply 32 bit quantities any more. So what? Noel From owner-big-internet@munnari.oz.au Thu Jun 25 18:27:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01790; Thu, 25 Jun 1992 18:27:46 +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 AA29672; Thu, 25 Jun 1992 17:09:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22078; Thu, 25 Jun 92 03:07:44 -0400 Date: Thu, 25 Jun 92 03:07:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206250707.AA22078@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, mo@gizmo.bellcore.com Subject: Re: ARP and virtual IP addressing Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I think the extra level of indirection provided by ARP in the mapping of an IP address to a physical address has been very useful. 'Useful'? 'Useful'! It's been the source of a lot of horrible kludges! Yes, we need more name mapping levels, but the identifier gives us one which is much more suited to what we are really trying to do in the network. I'm still not convinced that I have heard a better argument than Zheng's, which is that "the MAC addresses are only used in the last hop ... It does not make sense to look it up at the remote site and carry it across the network". This is a good point, but on balance I still think that carrying the entire address around in one dollop, including the local hardware address on the end (be it SMDS, X.25 or IEEE) is the way to go. No special cases! I go back to my favourite question; what does it get us, and what does it add in the way of costs (packet traffic) and complexity. ("Perfection ... nothing left to take away".) Noel From owner-Big-Internet@munnari.oz.au Thu Jun 25 19:38:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03469; Thu, 25 Jun 1992 19:38:44 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206250938.3469@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03466; Thu, 25 Jun 1992 19:38:36 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 25 Jun 1992 10:36:37 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Bob.Hinden@eng.sun.com, mo@gizmo.bellcore.com, big-internet@munnari.oz.au Subject: Re: ARP and virtual IP addressing In-Reply-To: Your message of "Thu, 25 Jun 92 03:07:44 EDT." <9206250707.AA22078@ginger.lcs.mit.edu> Date: Thu, 25 Jun 92 10:36:25 +0100 From: Zheng Wang > I'm still not convinced that I have heard a better argument than >Zheng's, which is that "the MAC addresses are only used in the last hop ... >It does not make sense to look it up at the remote site and carry it across >the network". Another point I made in the message is that MAC addresses are data-link level addresses(thus they only have point-to-point significance and are hardware dependent). In each hop from the source to the destination, there will be a translation from IP address to data-link level address. ARP is one of the mapping techniques. For example, you send a packet from src to dest via router1 and router2: ether WAN ether src----->router1------>router2------>dest src will need ARP to find the MAC address of router1! router1 will need ARP or other techniques, depending on wehther the WAN is point-to-point link, ISDN, x25, ATM or whatever, forward the packet to router2. router2 will need ARP to find the destination. I am not saying that you can't include the MAC address in the packet. In fact, you may include all data-link level addresses along with their IP addresses. But it would be better to leave the ARP or other network level address -> data-link level address mapping to deal with the translation. Cheers Zheng From owner-Big-Internet@munnari.oz.au Thu Jun 25 20:53:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05153; Thu, 25 Jun 1992 20:53:33 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206251053.5153@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05148; Thu, 25 Jun 1992 20:53:23 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from debden.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 25 Jun 1992 11:53:05 +0100 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Thu, 25 Jun 92 08:35:18 +0900." <15939.709425318@munnari.oz.au> Date: Thu, 25 Jun 92 11:52:57 +0100 From: Paul Tsuchiya > > Paul believes that ID's only occasionally appear in packets, > and that routing is done based on the address which is in > every packet - hosts remember the address -> ID mapping of > incoming packets and use that to reconstruct the ID for > packets that don't carry the ID in them - for this the nature > of the ID is less important, but addresses want to be encoded > quite effeciently. > > > Now I've said this, I'm sure that if I have misrepresented > anyone I will hear about it. > You got my bit exactly right. Probably I wouldn't mind if the IDs were in every packet. I may have a bit of an irrational attraction for small headers. Surely if a host is really mobile, then you will probably want the ID in every packet. But, I definately do not have routers looking at the ID field. It is expressly not for routing, only for identifying source and dest (although I suppose in this context, for billing or access control, a router could end up looking at the ID field, which is another argument for having them in every packet. But still, this is different from actually "routing" on the ID field). PT From owner-Big-Internet@munnari.oz.au Thu Jun 25 23:06:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07868; Thu, 25 Jun 1992 23:06:41 +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 AA07862; Thu, 25 Jun 1992 23:06:30 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA18410); Thu, 25 Jun 92 08:06:23 CDT Received: by san-miguel.is.rice.edu (AA07880); Thu, 25 Jun 92 08:06:22 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9206251306.AA07880@san-miguel.is.rice.edu> Subject: re: network number and addresses (administration of IEEE IDs) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 25 Jun 92 8:06:21 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9206250648.AA21984@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 25, 92 2:48 am X-Mailer: ELM [version 2.3 PL11] Noel Chiappa > > PS: Some of my recent thinking about large scale routing indicates you'd > want to automatically readdress portions of the topology (i.e. hosts, > routers, networks, the lot) as the topological connectivity changes. > This margin isn't big enough to explain why, but this would also clearly -------^^^^^^ > need automatic updating. > Sure it is. Why do you think we put in all these big pipes? Spill the beans. -- 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 Thu Jun 25 23:17:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08496; Thu, 25 Jun 1992 23:17:54 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206251317.8496@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08486; Thu, 25 Jun 1992 23:17:45 +1000 (from clynn@BBN.COM) Received: by CLYNN.BBN.COM id aa01865; 25 Jun 92 9:07 EDT Date: Thu, 25 Jun 92 8:36:43 EDT From: Charles Lynn To: Noel Chiappa Cc: big-internet@munnari.oz.au, smart@mel.dit.csiro.au, jnc@ginger.lcs.mit.edu Subject: Re: meta matters > However the address<->identifier correspondence stays fixed for > a long time so it is not necessary to have the identifier(s) in > every packet. > > Turn this around; "so it's not necessary to have the *address* > in every packet". The addresses is the long, complex, thing; the identifiers > are the short, easy to process things which uniquely identify the source > and destination. Which should be in every packet? However, if one accepts the definition that the addresses contain or specify path information derived from policy, then the address->identifier mapping is onto, assuming that traffic to a given destination (ID) is not restricted to all be using a single policy. Thus there is not a unique identifier->..->forwarding information mapping. This would seem to inply that additional information from the packet to disambiguate the various flows is automatically being identified and cached, for the "packets have an ID" scheme. This sub-problem may be tricky to solve in real-time as flows to an ID are being created and deleted. Charlie From owner-Big-Internet@munnari.oz.au Thu Jun 25 23:27:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08913; Thu, 25 Jun 1992 23:27:50 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA08904; Thu, 25 Jun 1992 23:27:45 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09575; Thu, 25 Jun 92 08:29:01 -0400 Message-Id: <9206251229.AA09575@relay1.UU.NET> Received: from triumph.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 25 Jun 1992 13:28:40 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Thu, 25 Jun 92 02:00:18 EDT." <9206250600.AA21713@ginger.lcs.mit.edu> Date: Thu, 25 Jun 92 13:28:34 +0100 From: Paul Tsuchiya > > First, I was positing that we could not change the routing algorithm, > let along the forwarding algorithm. I don't see how your comment relates to > this (admittedly hypothetical) position? I disagree with this posit. I'm inclined to think that, one way or another, networking will continue to evolve, just as the telephone system continues to evolve in spite of the enormous installed base. > Finally, I have a hard time imagining a scheme which does hop-by-hop > routing, changes the routing algorithm, and doesn't affect the forwarding > algorithm. The whole point of hop-by-hop (which PIP seems to want to support, > if I am not misreading the document) is that forwarding and routing (using the > terminology I recently defined) are intermingled. How can you change one and > not affect the other? With Pip, all of the different functions you get out of it (policy routes, plain old hierarchical addresses (poha), vci type routes, etc., derive from the same forwarding engine. It is simply a matter of what is in the forwarding tables. So, you need to change the contents of the forwarding table to instantiate a new routing style, but not the way the packet is parsed and handled. Presumably, any hardware-assisted engine for Pip will have the generality for changing the forwarding tables. > > Third, if we don't do Pip now, we'll do CLNP. > > I'm not sure I see the 'historical necessity' here. A number of > schemes (including Encaps, Nimrod, etc) were proposed without benefit of > PIP. Are you saying that PIP is the only realistic alternative to CLNP? > Could you explain the chain of thought that leads you to this conclusion? > Sure. First, I see Encaps as a weak alternative to CLNP, because it doesn't do anything that CLNP doesn't do, and CLNP has the advantage in terms of maturity. Nimrod has a long way to go, in my opinion (as does Pip, but I am working full time on Pip, and expect to get funding for other people to do implementations, whereas you do not seem to have the time to really bring Nimrod along. And, Pip can be installed without having to solve the big routing architecture problem. We can install it in the context of existing routing protocols (BGP, OSPF), and add advanced stuff later. Therefore, it should be possible to move quite fast on what I call "Basic" Pip. I don't see Nimrod moving that fast. Basically, I see Pip as the only serious contender to CLNP for the time frame we are working under. Also, it seems silly to compare Pip and Nimrod as alternatives, since they solve different problems and they are in fact mutually compatible. Nimrod is an architecture without a packet format (although of course once the architecture is done, coming up with the format is no big deal), and Pip is a packet format without an architecture (or, perhaps better put, with many architectures). So, Pip and Nimrod should be bed-fellows, not competitors. PT From owner-Big-Internet@munnari.oz.au Thu Jun 25 23:30:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09074; Thu, 25 Jun 1992 23:30:41 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA09071; Thu, 25 Jun 1992 23:30:36 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10466; Thu, 25 Jun 92 08:33:25 -0400 Message-Id: <9206251233.AA10466@relay1.UU.NET> Received: from triumph.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 25 Jun 1992 13:33:11 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: network number and addresses (administration of IEEE IDs) In-Reply-To: Your message of "Thu, 25 Jun 92 02:48:51 EDT." <9206250648.AA21984@ginger.lcs.mit.edu> Date: Thu, 25 Jun 92 13:33:05 +0100 From: Paul Tsuchiya From Noel........ > > PS: Some of my recent thinking about large scale routing indicates you'd > want to automatically readdress portions of the topology (i.e. hosts, > routers, networks, the lot) as the topological connectivity changes. Alright! Landmark Routing!!! Can we make landmark routing part of Nimrod? PT ps. Landmark routing works just fine on the Pip header :-) From owner-Big-Internet@munnari.oz.au Thu Jun 25 23:33:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09222; Thu, 25 Jun 1992 23:33:46 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA09219; Thu, 25 Jun 1992 23:33:42 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11921; Thu, 25 Jun 92 08:43:05 -0400 Message-Id: <9206251243.AA11921@relay1.UU.NET> Received: from triumph.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 25 Jun 1992 13:42:34 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Thu, 25 Jun 92 03:47:00 EDT." <9206250747.AA22171@ginger.lcs.mit.edu> Date: Thu, 25 Jun 92 13:42:23 +0100 From: Paul Tsuchiya > Well, first, there are a number of differences in world-view, some > significant, some less so, which make this a little trickier. > KRE's message made it plain I'd misunderstood something about PIP; I > had taken the line "13. Pip simplifies handling mobile systems (by having flat > network layer identifiers)" to mean that PIP had identifiers in every packet, > but I now see on careful reading of section 3.2 that this is not so. So, > that's a significant difference. Pip may or may not have IDs in every packet. The example I give merely shows that it is not necessary in all cases to put IDs in every packet. Obviously, if you want to put IDs in every packet, you can. > Also, for what I feel are good reasons, Nimrod addresses build from > the bottom up, not the top down (i.e. level 0 is the bottom, and there is no > fixed 'top' level). PIP (if I am reading seciton 4.0 correctly) does things > the other way around. Pip also does not fix the top level. You can add levels to the top, the middle, or the bottom, whatever you want. In my examples, I put the phrase "top-level" in the Logical Router field to imply that router's notion of what the highest level is. Every router determines from local routing information how many levels it cares about, and assigns values to those levels. If a new level is added somewhere, a new value is assigned. The value is completely a local matter (probably local to the domain, but strictly speaking, local to the router). I would have liked to explain this in the overview paper, but I had to leave quite a few details out, and this is one I chose to leave out. By the way Noel, since in Nimrod you number from the bottom, how do you add levels at the bottom? > Turn this around; "so it's not necessary to have the *address* > in every packet". The addresses is the long, complex, thing; the identifiers > are the short, easy to process things which uniquely identify the source > and destination. Which should be in every packet? > There is a certain cost to not puting addresses in every packet. The router has to cache a certain amount of information. There is a certain cost to not putting an ID in every packet. The host has to keep a certain amount of information. In high level backbones, the amount of information a router has to cache can be enormous. So, in some situations, it is very costly to not put the address in every packet. PT From owner-Big-Internet@munnari.oz.au Fri Jun 26 01:56:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14522; Fri, 26 Jun 1992 01:56:51 +1000 (from owner-Big-Internet) Return-Path: Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14515; Fri, 26 Jun 1992 01:56:44 +1000 (from postel@ISI.EDU) Received: from bel.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 25 Jun 1992 08:57:51 -0700 Date: Thu, 25 Jun 1992 08:55:35 -0700 From: postel@ISI.EDU Posted-Date: Thu, 25 Jun 1992 08:55:35 -0700 Message-Id: <199206251555.AA18670@bel.isi.edu> Received: by bel.isi.edu (5.65c/4.0.3-4) id ; Thu, 25 Jun 1992 08:55:35 -0700 To: jnc@ginger.lcs.mit.edu Subject: Re: network number and addresses (are we changing CLNP??) Cc: big-internet@munnari.oz.au Noel: The idea of including the MAC layer end-point address in the big-Internet address supposes that we are smart ennough now to allow for all possible future forms of MAC addresses. ARP is one technique for dynamically mapping between IP addresses and MAC address at just the places where the mapping is needed. Other types of physical networks might have different types of addresses, and require different mapping methods. I believe ARP, and the concept of mapping IP addresses to local MAC physical address at just the places where they are needed is a big win. --jon. From owner-Big-Internet@munnari.oz.au Fri Jun 26 02:01:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14686; Fri, 26 Jun 1992 02:01:53 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14678; Fri, 26 Jun 1992 02:01:39 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA19299; Thu, 25 Jun 92 12:01:31 -0400 Received: by easynet.crl.dec.com; id AA16514; Thu, 25 Jun 92 11:59:19 -0400 Message-Id: <9206251559.AA16514@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Thu, 25 Jun 92 11:59:22 EDT Date: Thu, 25 Jun 92 11:59:22 EDT From: Ross Callon To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: re: Re: meta matters > > First, it is one thing to change the routing algorithm, > and another to have to change the forwarding engine. > It would be nice if some day we could start putting the > forwarding engine in hardware without the concern that we > have to change it every few years. > (Paul T) > > ...Next, are inflexible hardware forwarding engines really practical in a > multi-protocol world? Most router vendors these days seems to sell boxes which > handle 17 protocols. (I exclude hardware designs such as the Faswitch which > have enough programmabilty built in to handle multiple protocols; they > obviously could also handle a new address/routing scheme.) > (Noel) I think that this is an interesting question. My feeling it that IP has been stable for quite a while, and we are likely to find that CLNP will be stable for quite a while. If we come up with a new IP, then it will take a few years before it becomes stable, but once it does it too will remain stable (or be rejected in the market). However, there is still the problems of new protocols, and new features (such as Multicast) in the old protocols. Generally, as the Internet gets bigger, I think that we are going to be forced to allow the Internet to become more stable. When the Internet is 10 or even 100 times bigger than it is today, we are going to find that even if all of the routing and forwarding is in (allegedly changeable) software, rather than (allegedly fixed) hardware, it will still be impractical to change a significant part of the Internet in anything less than multiple years. Thus I agree with Paul. I would hope, and expect, that over the years we will find some or all of the forwarding function put into hardware. I would From owner-big-internet@munnari.oz.au Fri Jun 26 02:04:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14750; Fri, 26 Jun 1992 02:04:57 +1000 (from owner-big-internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13916; Fri, 26 Jun 1992 01:37:04 +1000 (from mm@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA18620; Thu, 25 Jun 92 11:36:55 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA14917; Thu, 25 Jun 92 11:36:51 EDT Date: Thu, 25 Jun 92 11:36:51 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9206251536.AA14917@cannibal.gandalf.ca> To: big-internet@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) Aside: As IETF approaches this list's volume is getting to much for me to keep up with. >> The final "hop" in a route *is* different from the rest, because >> that's the first time the packet is not delivered to a router > Yes, that's so, but how does this relate to the conclusion that ARP >is a good thing? (As Zheng pointed out in a private message to me, any >intermediate hop may currently need to use ARP to get from one router to >the next!) If anything is made to go do a name service lookup it should be routers, because the frequency of router topology changes is so much less than the frequency of host topology changes (over the entire WorldNet). >> ARP lets hardware addresses come and go without involving any >> administration or affecting databases outside the local net > Yes, but how often do hosts change their 48 bit addresses? How >often will they change their SMDS/X.25/ATM/etc addresses? I'll bet they are >about equally common. > Since we have to have a lookup system which will handle the latter >case, what is the use of a special mechanism which makes some cases (i.e. >IEEE nets) easier? IEEE nets are much more common. The general applicability of ARP is to broadcast nets (i.e. it can be used to look up SMDS addresses too). I don't want the world to have to be told every time I swap NICs in a host. To me that wastes too much of the WorldNet`s bandwidth. Let me waste my local bandwidth with ARP. > Aw, this is a non-starter. How many ISO addresses (which typically >*include* a 48 bit address) do you remember? The fact that you already have >to rely on a tool (as opposed to memory and other human builtins) to handle >the IEEE mappings now doesn't seem to cramp most people. > So, here in the future, we will all need better tools to hack the >network since addresses aren't simply 32 bit quantities any more. So what? This is good, if here in the future I have the tools I need, and never have to remember or write down a name to address mapping again. The phone companies haven't been able to do it, but hey, I'd be happy if they did. Then again, people's names would have to be globally unique, so they'd probably be really hard to remember too :-) > The Internet in general is reprehensibly lacking in automatic >mechanisms. Appletalk is an order of magnitude better in this area, and >we really need to study them. Probaly the biggest single selling point of >Appletalk for naive users is you don't have to have a CS PhD to set it up. >If IP, OSI, or anything is going to be WorldNet, it's going to have to >get with the program on this axis. Yes. Appletalk's success in this area is traceable to dynamic address assignment. But they also do their own ARP on IEEE nets and SMDS. I don't know enough about it to know if it scales *really* big (what happens when you plug two Appletalk Internets together?). -Chris Sullivan From owner-Big-Internet@munnari.oz.au Fri Jun 26 02:07:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14844; Fri, 26 Jun 1992 02:07:46 +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 AA14828; Fri, 26 Jun 1992 02:07:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23734; Thu, 25 Jun 92 12:07:18 -0400 Date: Thu, 25 Jun 92 12:07:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206251607.AA23734@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, kre@munnari.oz.au Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu But, I definately do not have routers looking at the ID field. It is expressly not for routing, only for identifying source and dest Oh, I agree, you wouldn't (*can't*; that the whole point of them :-) want to route on the identifier fields. However, using the identifier field to assign them to flows for *forwarding* purposes; now, that's different. Noel From owner-Big-Internet@munnari.oz.au Fri Jun 26 02:21:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15236; Fri, 26 Jun 1992 02:21:44 +1000 (from owner-Big-Internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15222; Fri, 26 Jun 1992 02:21:28 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA14828; Thu, 25 Jun 92 09:20:39 PDT Date: Thu, 25 Jun 92 09:20:39 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206251620.AA14828@saffron.acc.com> To: P.Tsuchiya@cs.ucl.ac.uk Subject: Re: network number and addresses (administration of IEEE IDs) Cc: big-internet@munnari.oz.au >> Alright! Landmark Routing!!! Can we make landmark routing part of >> Nimrod? Paul: You're joking, of course, but I'm not. Landmark, stuctured so that network providers are the primary landmarks, would be a useful way to eliminate a lot of route clutter, and provide for mobile routing targets, something not well supported now. Of course, global identifiers would need to be translated into "current location" identifiers, but that is consistent with what you've been saying already. If it fits, I'd like to see it at least be a viable option. Fred From owner-Big-Internet@munnari.oz.au Fri Jun 26 02:25:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15376; Fri, 26 Jun 1992 02:25:35 +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 AA15369; Fri, 26 Jun 1992 02:25:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23863; Thu, 25 Jun 92 12:25:08 -0400 Date: Thu, 25 Jun 92 12:25:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206251625.AA23863@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the telephone system continues to evolve in spite of the enormous installed base Yes, but we've still got the same old namespace (not highly structured, admittedly) for naming telephone access points. Still, the basic semantics haven't changed since we invented the dial. I think this makes my point, that in a really big system, you simply can't change the basics (of routing in this case). You just work around their limits any way you can. Presumably, any hardware-assisted engine for Pip will have the generality for changing the forwarding tables. Beep, beep! Tilt! Wouldn't a hardware forwarder which has this sort of flexibility necessarily have the flexibility to handle different addressing structures (not that I think we'll have a different addressing structure :-)? Remember, forwarding and routing are in large part the same thing in hop-by- hop systems. E.g. if you built a forwarding chip which used the the RD to forward packets, and then, using the flexibility in PIP, decided to switch to an architecture like Nimrod, which tagged packets to flows with the ID (or ESI in PIPese), would that chip really still work? whereas you do not seem to have the time to really bring Nimrod along Exactly. (I know my own limits! :-) Which is why I put out a call for someone to take over Nimrod. I have some very high-powered potential people thinking about doing just this. Noel From owner-Big-Internet@munnari.oz.au Fri Jun 26 02:59:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16548; Fri, 26 Jun 1992 02:59:43 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA16545; Fri, 26 Jun 1992 02:59:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08829; Thu, 25 Jun 92 12:46:02 -0400 Received: by ginger.lcs.mit.edu id AA24948; Thu, 25 Jun 92 12:45:51 -0400 Date: Thu, 25 Jun 92 12:45:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206251645.AA24948@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Pip also does not fix the top level. You can add levels to the top, the middle, or the bottom, whatever you want. Well, now I'm really confused. The PIP document (4.0) says: Therefore, at least one (and hopefully just one) global Pip number authority is required. The global Pip number authority assigns top-level numbers only. Each recipient of a top-level number assigns numbers hierarchically subservient to that number. I understood this to mean that PIP addresses were numbered from the top down. I thought the line about multiple number authorities was speaking of totally disjoint numbering spaces. Let me ask a questions which will help clarify this. If I have two different 'top level' authorities, can they join together, and stick another layer on top, with different values to indicate addresses assigned by the two different authorities? By the way Noel, since in Nimrod you number from the bottom, how do you add levels at the bottom? The bottom level names physical things like interfaces. How can you have a layer below physical things? Maybe I'm just not understanding your question. Do you mean "what do you do when an address level (i.e. equivalent of directory in hierarchical file system) gets too large"? So, in some situations, it is very costly to not put the address in every packet. I admit the issue of large amounts of state in topology hot-spots is a big (probably the biggest) problem with source routed setup systems in general. I have a hand-wavy argument about that, but won't include it at the moment to prevent the debate getting even broader! However, why would you put an address in each packet if you don't use it in each packet? (I share your natural bias towards short headers. Long headers mean more information, and information takes work to process. I want to make header processing as cheap as possible, be it in hardware or software.) Noel From owner-Big-Internet@munnari.oz.au Fri Jun 26 03:08:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16999; Fri, 26 Jun 1992 03:08:28 +1000 (from owner-Big-Internet) Return-Path: Received: from bellcore.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16996; Fri, 26 Jun 1992 03:08:22 +1000 (from mo@gizmo.bellcore.com) Received: from gizmo.bellcore.com by bellcore.bellcore.com (5.61/1.34) id AA23211; Thu, 25 Jun 92 13:07:57 -0400 Message-Id: <9206251707.AA23211@bellcore.bellcore.com> To: P.Tsuchiya@cs.ucl.ac.uk Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: the telephone system continues to evolve... In-Reply-To: Your message of "Thu, 25 Jun 92 12:25:08 EDT." <9206251625.AA23863@ginger.lcs.mit.edu> Date: Thu, 25 Jun 92 13:07:56 -0400 From: mo@gizmo.bellcore.com Paul, The numbering plan folks certainly have their hands full with similar problems, and to claim there is unanimity in the industry over Bellcore's 10-digit plans is simply untrue based on the trade papers I read. And they haven't solved the problem of telling my dear Aunt Tillie that at some point she will have to dial 10 or 11 digits to get what she got with the 7 she has a hard time remembering... And let's not even mention routing for PCS. So I'd pick my analogies more carefully.... Cheers, -Mike From owner-Big-Internet@munnari.oz.au Fri Jun 26 03:15:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17199; Fri, 26 Jun 1992 03:15:08 +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 AA17188; Fri, 26 Jun 1992 03:15:01 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25641; Thu, 25 Jun 92 13:14:56 -0400 Date: Thu, 25 Jun 92 13:14:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206251714.AA25641@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, postel@isi.edu Subject: Re: network number and addresses (are we changing CLNP??) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The idea of including the MAC layer end-point address in the big-Internet address supposes that we are smart ennough now to allow for all possible future forms of MAC addresses. Well, an address format that allowed indefinite (not infinite, mind you :-) variable length items at the lowest level (actually, Nimrod proposes to allow this at all levels, to prevent a 'hard wall' problem if any space fills up) should be able to handle any conceivable MAC address. I believe ARP, and the concept of mapping IP addresses to local MAC physical address at just the places where they are needed is a big win. You, Zheng, and others are right, this is a useful idea. I need to go away and think about this for a while, to see what the true balance of costs/benefits really are. Noel From owner-big-internet@munnari.oz.au Fri Jun 26 03:15:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17210; Fri, 26 Jun 1992 03:15:21 +1000 (from owner-big-internet) Return-Path: Message-Id: <9206251715.17210@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15056; Fri, 26 Jun 1992 02:17:09 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 25 Jun 1992 17:16:59 +0100 To: big-internet@munnari.oz.au Subject: Re: network number and addresses (are we changing CLNP??) In-Reply-To: Your message of "Thu, 25 Jun 92 08:55:35 PDT." <199206251555.AA18670@bel.isi.edu> Date: Thu, 25 Jun 92 17:16:53 +0100 From: Jon Crowcroft >I believe ARP, and the concept of mapping IP addresses to local >MAC physical address at just the places where they are needed >is a big win. >--jon. I agree - i never understand why people think ARP is a hack - the idea of constraining traffic to be 1 request to inform everyone about src with 1 reply to inform me about dest, per boot time/cache idle timeout is a very powerful optimisation of traffic on a net with physical broadcast and multicast filtering in receivers ... the hack is that ARP used broadcast addresses orig because noone built multicast ethernet addr recongition properly...thats changing... no-one thinks television & radio broadcast is a hack...either... jon From owner-big-internet@munnari.oz.au Fri Jun 26 03:25:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17591; Fri, 26 Jun 1992 03:25:43 +1000 (from owner-big-internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15645; Fri, 26 Jun 1992 02:33:54 +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 9861; Thu, 25 Jun 92 12:32:29 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 7755; Thu, 25 Jun 92 12:32:29 EDT Date: Thu, 25 Jun 92 12:18:22 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: network number and addresses (are we changing CLNP??) To: Mississippi Mud , big-internet@munnari.oz.au Message-Id: <920625.121822.EDT.VALDIS@vtvm1.cc.vt.edu> In-Reply-To: <9206251536.AA14917@cannibal.gandalf.ca> On Thu, 25 Jun 92 11:36:51 EDT you said: >If anything is made to go do a name service lookup it should be routers, >because the frequency of router topology changes is so much less than the >frequency of host topology changes (over the entire WorldNet). Chris - Hmm.. I dunno.. We run the VMNET software here to layer Bitnet NJE traffic over TCP/IP. As such, we have a machine here that has connections open to about 20 other sites all over the world, 24 hours a day, 7 days a week. I've got some monitoring software in place, to let me know when something blows chow. I'd estimate that we average 50 or 60 "link blinks" a day, where a connection has gone away. This is partially because VMNET is relatively intolerant of dead routers, and will timeout and drop a connection rather than wait for the external routers figure out a new path. As such, these 50 or 60 "blinks" a day correspond to times when the router topology has changed. I'm *damned* sure that we're not adding/moving 50/60 hosts a day - if we were, over the past 2 years we'd have grown to some 30,000+ hosts on campus, rather than the 500 or so we have currently. As an extension - take the latest IETF figures on growth rates, and figure out what that amounts to in machines/hour. Then find some numbers on how often a router in the NSF T1 or T3 cores, or one of the regionals (Suranet, NEARnet, Nysernet, etc) gets confused, and multiply that by the average number of connections passing through the router at the instant of failure. A good estimate can be reached by looking at the NSF core traffic statistics, and seeing what percentage of the core traffic is just router topology updates. Remember that *one* router failure can cause quite a ripple, as many routers go to adapt.. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-big-internet@munnari.oz.au Fri Jun 26 04:01:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18826; Fri, 26 Jun 1992 04:01:06 +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 AA16853; Fri, 26 Jun 1992 03:05:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25447; Thu, 25 Jun 92 13:05:41 -0400 Date: Thu, 25 Jun 92 13:05:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206251705.AA25447@ginger.lcs.mit.edu> To: bmanning@is.rice.edu, jnc@ginger.lcs.mit.edu Subject: re: network number and addresses (administration of IEEE IDs) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu indicates you'd want to automatically readdress portions of the topology as the topological connectivity changes. Sure it is. Why do you think we put in all these big pipes? Spill the beans. Oh no! I don't think I could keep up with the resulting mail traffic; I'm just about going under now! (I apologise to everyone for filling you mailboxes with all this stuff.) Well, very briefly, in abstract language only for brevity (sorry), here it is. In a hierarchical routing system, there are two costs; the cost of distributing the routing information, and the costs of non-optimal routing. These two costs always exist. [You have non-optimal routing since *practical* heirarchical routing, whether LS or DV, will need thinning, not just compression, to do a useful amount of abstraction (using terminology from Nimrod seciont 3.0). Thinning creates non-optimal routes. It's not theoretically necessary, but as a practical matter it is. Sort of like thermodynamics; physics can run forwards or backwards, but practically it only runs forwards.] The sum of these two cost functions is in itself a cost function, which you want to minimize. (My strong guess is it's probably NP to find the absolute minimum, but you want to guess at minimizing it, or maybe some math wizard will find some non-polynomial algorithm which gets to within a bounded range.) Anyway, when you pick an addressing heirarchy for a given topology, you have picked a heirarchy which tries to minimize that sum of costs function. The addressing heirarchy is thus, in a distant sort of way, isomorphic to the topology. (I called this, to intense amusement from Martha, 'deeply isomorphic'. :-) Now, over time, the topology will change. The sum of costs function is no longer near the minimum. You now have a new pair of cost functions; the costs of running a non-optimal heirarchy, and the costs of revamping the heirarchy to be a better match to the new topology (i.e. redoing things to minimize the original sum of costs function). At some point, the former costs gets large enough to make it useful to do the latter. My argument is that this growing non-optimality is also a natural process in networks, and the renumbering will be attractive. However, if we make this a manual process, forget it. The total costs of doing the renumbering will be so large we'll let the first function get real large before we do it (if we ever do). However, an automatic system (with a place for human guidance and control, certainly), built in from day one, could slowly change numbers (i.e. keep the costs of running it to a low level, just like routing traffic is a small percentage of the traffic on the network) to keep up. Noel From owner-big-internet@munnari.oz.au Fri Jun 26 04:57:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20513; Fri, 26 Jun 1992 04:57:22 +1000 (from owner-big-internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18726; Fri, 26 Jun 1992 03:59:08 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA25192; Thu, 25 Jun 92 13:59:01 -0400 Received: by easynet.crl.dec.com; id AA18483; Thu, 25 Jun 92 13:56:50 -0400 Message-Id: <9206251756.AA18483@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Thu, 25 Jun 92 13:56:52 EDT Date: Thu, 25 Jun 92 13:56:52 EDT From: Ross Callon To: jnc@ginger.lcs.mit.edu Cc: callon@bigfut.enet.dec.com, big-internet@munnari.oz.au Apparently-To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: re: re: Re: meta matters (forwarding in hardware, and protocol stability). > Both my copies of this message (starts with "I think that this is an > interesting question", Message-Id: <9206251559.AA16514@easynet.crl.dec.com>) > were truncated. Can you resend? > > Noel > Sorry Noel. I hit the wrong button before I had quite finished editting the message (and thought I was close enough to done that folks would get the point). The properly editted message is below. Ross ======== > > First, it is one thing to change the routing algorithm, > and another to have to change the forwarding engine. > It would be nice if some day we could start putting the > forwarding engine in hardware without the concern that we > have to change it every few years. > (Paul T) > > ...Next, are inflexible hardware forwarding engines really practical in a > multi-protocol world? Most router vendors these days seems to sell boxes which > handle 17 protocols. (I exclude hardware designs such as the Faswitch which > have enough programmabilty built in to handle multiple protocols; they > obviously could also handle a new address/routing scheme.) > (Noel) I think that this is an interesting question. My feeling it that IP has been stable for quite a while, and we are likely to find that CLNP will be stable for quite a while. If we come up with a new IP, then it will take a few years before it becomes stable, but once it does it too will remain stable (or be rejected in the market). However, there is still the problems of new protocols, and new features (such as multicast) in the old protocols. Generally, as the Internet gets bigger, I think that we are going to be forced to allow the Internet to become more stable. When the Internet is 10 or even 100 times bigger than it is today, we are going to find that even if all of the routing and forwarding is in (allegedly changeable) software, rather than (allegedly fixed) hardware, it will still be impractical to change a significant part of the Internet in anything less than multiple years. Thus I agree with Paul. I would hope, and expect, that over the years we will find some or all of the forwarding function put into hardware. I would be interested in hearing other opinions on this. Ross PS: Noel, can you explain more about the Faswitch? From owner-Big-Internet@munnari.oz.au Fri Jun 26 05:20:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21171; Fri, 26 Jun 1992 05:20:18 +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 AA21159; Fri, 26 Jun 1992 05:20:01 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA05835); Thu, 25 Jun 92 14:19:47 CDT Received: by san-miguel.is.rice.edu (AA08063); Thu, 25 Jun 92 14:19:39 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9206251919.AA08063@san-miguel.is.rice.edu> Subject: Re: network number and addresses (administration of IEEE IDs) To: fbaker@acc.com (Fred Baker) Date: Thu, 25 Jun 92 14:19:38 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9206251620.AA14828@saffron.acc.com>; from "Fred Baker" at Jun 25, 92 9:20 am X-Mailer: ELM [version 2.3 PL11] Fred Baker > > You're joking, of course, but I'm not. > > Landmark, stuctured so that network providers are the primary > landmarks, would be a useful way to eliminate a lot of route clutter, > and provide for mobile routing targets, something not well supported > now. Of course, global identifiers would need to be translated into > "current location" identifiers, but that is consistent with what you've > been saying already. > Does this fit with the NAP concept in the current NREN flap? -- 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 Jun 26 07:00:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24458; Fri, 26 Jun 1992 07:00:25 +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 AA24455; Fri, 26 Jun 1992 07:00:18 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA21841; Thu, 25 Jun 92 14:00:11 PDT Message-Id: <9206252100.AA21841@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: IP Address Encapsulation Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Thu, 25 Jun 92 14:00:10 -0700 From: Dave Crocker Folks, Bob Hinden and I have been working with a few others to develop a proposal to support larger IP addresses while protecting the installed base of systems, software, training, etc., as much as possible. We had planned to develop a complete first-draft specification before subjecting it to general community review, but the metabolic rate of community discussion and pressure has increased too quickly. As a consequence, we've just submitted a draft of a preliminary proposal to the Internet Drafts directory. It should be accessible tomorrow. We feel that the proposal document contains the essential meat of the specification, although we all understand that it is the details that make a specification succeed or fail. We hope to release a version of the full specification in less than 2 weeks. To whet your appetites, I am including the Summary section of the proposal document. The full document is about 20 pages: draft-crocker-ip-encaps-00.txt. SUMMARY The Internet currently is seeking a means of providing for long-term growth by increasing the amount of address space that is available for hosts and by decreasing the amount of table storage that is required for routers. One solution to these problems is a direct upgrade to a new version of IP. Another is to switch to use of a new protocol such as CLNP which has provisions for a larger and more hierarchical address space. Both require very substantial disruption to the IP installed base. This proposal describes an alternative which minimizes overall disruption and, in fact, entirely eliminates a significant portion of it. A current IP addresss is defined to be used within its own 32-bit IP address space. This proposal labels such a space an _IP Addressing Commonwealth_. The proposed extension specifies a means of connecting such environments by using additional addressing bits, while retaining current usage of the original 32-bit format. The basic proposal is to define the addressing enhancements to IP so that they are carried as IP data and therefore are invisible to all current IP hosts and routers, except those that have been modified to understand the new format. Hence only participating end system hosts and special routers at the borders of Addressing Commonwealths need to understand the new formats. This scheme is called _IP Address Encapsulation_ (_IPAE_). Key benefits of this proposal are: Routers interior to Addressing Commonwealths _never_ need to be modified. Hosts do not have to change their 32-bit IP address _ever_. Hosts which communicate only within their local addressing commonwealth will require no changing _ever_. _All_ IP-related functionality, such as multicasting, is retained without modification. _All_ of the Internet's investment in staff training, including procedures, formats and terminology is retained. Changes to support IPAE only require acquisition of small amounts of additional procedures, formats and terminology. _All_ operational support software will continue to function within a commonwealth. The current routing table size problems and routing computation problems are alleviated as soon as the first transition step is deployed. Hosts are not required to support IPAE directly until the Internet is closer to running out of IP addresses, and then only for hosts wishing full Internet connectivity. That is, existing hosts will be supported without any changes for a long time. This document is in the form of a summary of a preliminary specification and represents work-in-progress to describe the new protocols and the changes needed to effect a transition to the new addressing and routing scheme. This version of the proposal is intended to provide detail about goals and framework, with enough specification to make the basis of the proposal concrete. However, most of the formal specification that ultimately will be required is left for a later version. From owner-big-internet@munnari.oz.au Fri Jun 26 07:16:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24807; Fri, 26 Jun 1992 07:16:32 +1000 (from owner-big-internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21598; Fri, 26 Jun 1992 05:32:17 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA02371; Thu, 25 Jun 92 15:32:03 -0400 Message-Id: <9206251932.AA02371@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 2057; Thu, 25 Jun 92 15:30:14 EDT Date: 25 Jun 92 15:33:00 EDT To: , jnc@ginger.lcs.mit.edu From: Pierre (P.) Fortin Subject: AppleTalk (was: network number and addresses (administration Sender: Pierre (P.) Fortin Noel, > Similarly, if addresses had to change (i.e., the ID could stay the > same, but the higher order part of the address needed to change), > then address re-configuration in the hosts would also be automatic > (DNS servers and routers would require manual address > re-configuration in this case). > > The current level of DNS technology would require manual changes, > yes, but I would hope we could automate it, so that hosts could add/update > the name entry automatically. Yes, we need policy and authorization tools, > but this is not impossible. > The Internet in general is reprehensibly lacking in automatic > mechanisms. Appletalk is an order of magnitude better in this area, and > we really need to study them. Probaly the biggest single selling point of > Appletalk for naive users is you don't have to have a CS PhD to set it up. I fully agree with your general concept of automatic mechanisms. However, while AppleTalk *is* easier to setup for the general user, this does NOT remain so as the network size increases. In fact, the auto-configure features are at the LAN level only. As soon as you start to build a MAN/WAN, it's human-configure-mode time... While ATalk initially looks great, one is lulled into a false sense of well-being; then [going off the cliff and slamming into the valley floor below...] WHAMMM!! Next, the general user (if not terminally maimed) will get up and try to climb the ATalk mountain which is now PhD (Piled higher & Deeper :^) :^) Seriously, have a look at the ATalk discussions; they're trying to move towards an IP-like solution... IMHO, the grass is is definitely NOT greener on the other side... Specific examples of how AppleTalk can bite you and/or require, well not quite, a CS PhD are: - in Feb 89, we presented Apple documented proof that their process of dynamically acquired addresses was risky; we had FOUR nodes with the _same_ network/host address on the _same_ LAN. Timer/LAN-topology issue. - AppleTalk is basically RIP-like (they call it RTMP) making it VERY difficult to build a large AT internet. We have many AT internets which we can not connect together for this and routing table size issues in the available routers (not to mention the problems of using routers from multiple vendors...) - I personally hate the perceived need for every AT router to know ALL zone names in the AT internet. Ever experienced a ZIP storm (network wide storm loosely similar to an IP ARP storm)? - most timers are hard-coded creating "interesting" WAAN problems - inability to see [full] contents of zones - zone contents fading in and out in Chooser The list goes on, but my point is: before holding up AppleTalk as an example of good (or better) networking, one should be aware that Apple has been severely beaten up by its large corporate customers for failing to fix what is considered to be a problem-prone and non-scalable architecture. And I say this as a user with the largest (within this company) ATalk internet, being 300+ nets with 6000+ nodes, over 3 continents (Japan, N.America, and Europe). I prefer to think that you meant to look at AT for ideas, but certainly not for things to import into IPn... I can't think of anyone who would even contemplate the possibility of such a humongous nightmare: a _teeny-weeny_ Internet... > If IP, OSI, or anything is going to be WorldNet, it's going to have to > get with the program on this axis. Agreed; but **DITTO-DITTO-DITTO** for ATalk... > Noel > > PS: Some of my recent thinking about large scale routing indicates you'd > want to automatically readdress portions of the topology (i.e. hosts, > routers, networks, the lot) as the topological connectivity changes. > This margin isn't big enough to explain why, but this would also clearly > need automatic updating. Now *this* really piques my interest... just remember to scratch ATalk surface a little deeper before holding it up as an example... Have you heard about the "AURP re-mapping to infinity" problem in a mesh network? [Hmmm... wonder what'll happen when a "general user" accidentally creates a mesh connection...? :^) ] You can take shots at me for my re-mapping comments of last week, you can take shots at other proposals; but I draw the line at you trying to tell us to look towards AppleTalk... YECHHHHHHHH!!!!! :^) :^) I've worked with _both_ protocols in a WAN environment for the last three years; I'll take IP (with all its warts) over AT 10:1... Regards, Pierre PS: If you don't feel comfortable with some of the other proposals here, just try reading a bit of "Inside AppleTalk"... [shudder] Some ideas may be fine, but a lot are not scaleable... An apple is a MUCH smaller globe than our planet... From owner-Big-Internet@munnari.oz.au Fri Jun 26 07:32:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25224; Fri, 26 Jun 1992 07:33:04 +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 AA25218; Fri, 26 Jun 1992 07:32:54 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA22481; Thu, 25 Jun 92 14:32:47 PDT Message-Id: <9206252132.AA22481@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: draft-crocker-ip-encaps-00.txt Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Thu, 25 Jun 92 14:32:46 -0700 From: Dave Crocker The efficiency of some people is just astonishing. The file is already accessible. I submitted it only about 1/2 hour ago. The file is not distributed to the show copies of the Internet Drafts directory. But if you are simply too eager to wait for it to appear at an I-D shadow near you, you can retrieve it from nri.reston.va.us Dave From owner-Big-Internet@munnari.oz.au Fri Jun 26 07:43:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25487; Fri, 26 Jun 1992 07:43:25 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206252143.25487@munnari.oz.au> Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25483; Fri, 26 Jun 1992 07:43:14 +1000 (from kre) Date: Fri, 26 Jun 1992 07:43:14 +1000 From: Robert Elz To: big-internet@munnari.oz.au, dcrocker@Mordor.Stanford.EDU Subject: Re: draft-crocker-ip-encaps-00.txt Date: Thu, 25 Jun 92 14:32:46 -0700 From: Dave Crocker But if you are simply too eager to wait for it to appear at an I-D shadow near you, you can retrieve it from nri.reston.va.us Its also (now) in the big-internet directory (but not internet-drafts yet) on munnari.oz.au kre From owner-Big-Internet@munnari.oz.au Fri Jun 26 15:22:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08339; Fri, 26 Jun 1992 15:22:53 +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 AA08336; Fri, 26 Jun 1992 15:22:35 +1000 (from kre) To: Paul Tsuchiya Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of Thu, 25 Jun 92 11:52:57 +0100. Date: Fri, 26 Jun 92 15:22:19 +1000 Message-Id: <16380.709536139@munnari.oz.au> From: Robert Elz Date: Thu, 25 Jun 92 11:52:57 +0100 From: Paul Tsuchiya But, I definately do not have routers looking at the ID field. It is expressly not for routing, only for identifying source and dest Given the first sentence above, I'm going to assume that your definition of "routing" includes Noel's "forwarding". Now, this raises an issue I've been pondering, slowly, over the past several days, which will be shared by any scheme which carries ID's in packets (always, or only occasionally), but which doesn't use them for forwarding. Uses for billing, accounting, or perhaps access control don't matter (or for now are assumed not to be relevant). Before I get to the point, let me take a few lines to define the terms and assumptions, so we avoid too much more of this routing/forwarding type of confusion... First, nodes (endpoints, hosts, whatever) are assumed to have an "ID" (one or more ID's) which are (sometimes or always) carried in packets from one node to another. The ID is used to identify the other node in a conversation - it would take the place of the IP address in the TCP connection identifying quadruple (src & dest ID's & port numbers). Second, there is assumed to be an "address", obtained by whatever means, carried in every packet, and used by the routers to forward packets from the source to the destination. The format of this isn't relevant here, however we do assume that packets will carry the source "address" as well as the destination, so return packets can be sent (ICMP type packets, or packets back from the destination). The important thing here is that the routers use the address, and not the ID, to forward packets. Given this, first I conclude that there is never any real point in putting the destination ID in a packet (we're assuming no use for accounting, etc, here recall). The routers won't be using it for anything, and the destination node certainly knows its own ID, no transporting that across the net is definitely a waste. So now we have just the source ID to deal with. The question is, does it make sense to carry that across the net? What use does it really have? To get specific briefly, PIP uses the ID to allow a mobile host to change its address - the destination will notice the source address has changed (the RH numbers in PIP) and update its idea of how to get to the source identified by the ID in the packet (PIP draft, section 4.4) But is this safe? To me it appears that this allows any random host to "borrow" the identity of another, simply by sending a packet, containing the victim host's ID as the source ID, and with the borrower host's address as the source addr. Is there something I'm missing here? In the IP internet, its reasonably simple to forge a packet, set the IP source address to anything you want - but its not so easy to cause reply packets to be sent back to your host. That's because the ID (the IP address) which is also the address, is used for forwarding. Without using the ID for forwarding, it would seem that there will need to be some authentication mechanism, some way for the destination host to use to verify that the source ID claimed is indeed correct. It may be that this is only needed when the source address changes - the destination could trust the source address as an authentication of the source ID, at least that would be no worse than the current scheme. But while I'm all for greater security, I'm not sure that some kind of public key, or something, authentication scheme of IP level headers is really justified, at any time. The combination of application level security, and forwarding based on the ID seems a more reasonable approach. I don't think any access controls can help here, not really - they may be able to drop packets with some ID's from going some places, but if you're really going to support mobile hosts there will be a lot that has to be left open. Also, as ID's will be (it has been assumed in much discussion here) assigned more or less randomly, the only kind of access control that could ever work on them would be an exhaustive list - there will not be any way to group them, as we do now with masks on the IP address. kre From owner-Big-Internet@munnari.oz.au Fri Jun 26 16:30:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10309; Fri, 26 Jun 1992 16:30:10 +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 AA10304; Fri, 26 Jun 1992 16:30:00 +1000 (from kre) To: Big-Internet@munnari.oz.au From: Big-Internet-Request@munnari.oz.au Subject: Dead issues Date: Fri, 26 Jun 92 16:29:47 +1000 Message-Id: <16467.709540187@munnari.oz.au> Sender: kre@munnari.oz.au In interests of trying to keep volume on this list to a somewhat reasonable level, can we consider the following issues dead, unless someone has something truly startling to say? ARP, and whether its a hack or a thing of beauty. Appletalk, and how crude it is ... bashing appletalk is easy. It has (had) a few worthwhile design aims, but that's about it, using bandwidth here to castigate it isn't doesn't help furthering the aims of this group (nor does defending it). Thanks, kre From owner-Big-Internet@munnari.oz.au Fri Jun 26 16:49:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10990; Fri, 26 Jun 1992 16:50:18 +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 AA10981; Fri, 26 Jun 1992 16:49:55 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12087>; Thu, 25 Jun 1992 23:49:37 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <22277>; Thu, 25 Jun 1992 23:49:28 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Mobile Hosts and IDs Date: Thu, 25 Jun 1992 23:49:18 PDT From: Steve Deering Message-Id: <92Jun25.234928pdt.22277@skylark.parc.xerox.com> It has been observed that, when sending to mobile hosts, packets need to contain two destination identifiers: a "current location" and an "ID". Some have suggested that a flat space of host IDs would make the job of supporting mobile hosts easier. I'd like to point out that the current work in mobile host support (e.g., the work of Ioannidis et al at Columbia and Teraoka et al at Sony) in fact relies on the "ID" being a real address (i.e., net+subnet+host), rather than a flat identifier. Those schemes work by assuming that every host has a "permanent" address on a "home" subnet, which is used as the host ID. Other hosts and routers initially send packets towards the home subnet, whence they may learn the current location of the destination host, if it happens to be elsewhere; a roaming host keeps the routers on its home subnet informed of its current location. (This does not necessarily imply that ALL traffic to a roaming host must be routed via the home subnet.) (Another way to think of this approach is that the "current location" is used as a "hint"; whenever the hint fails, the "truth" can be learned by sending to the "ID" address, at some additional cost.) Granted, there are other approaches to supporting host mobility that might benefit (or not suffer) from a flat ID space. But I suggest that it is unwise to claim that flat IDs will be useful for supporting mobile hosts until the actual mobile support architecture/protocols have been chosen. Steve From owner-Big-Internet@munnari.oz.au Fri Jun 26 17:34:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12571; Fri, 26 Jun 1992 17:34:58 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206260734.12571@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12555; Fri, 26 Jun 1992 17:34:47 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jun 1992 08:34:37 +0100 To: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Thu, 25 Jun 92 12:25:08 EDT." <9206251625.AA23863@ginger.lcs.mit.edu> Date: Fri, 26 Jun 92 08:34:27 +0100 From: Paul Tsuchiya > > the telephone system continues to evolve > in spite of the enormous installed base > > Yes, but we've still got the same old namespace (not highly > structured, admittedly) for naming telephone access points. Still, the basic > semantics haven't changed since we invented the dial. I think this makes my > point, that in a really big system, you simply can't change the basics (of > routing in this case). You just work around their limits any way you can. This not entirely true. The "name space" has, in a sense, been expanded to include the inter exchange carrier codes. That is, you can treat the iec code as another level of hierarchy above the area code. It is obviously not quite the same thing as another level of hierarchy, but not completely different either. In any event, I think the incorporation of iec codes to the phone system is as dramatic an event as changing the name space. > > Presumably, any hardware-assisted engine for Pip will have the > generality for changing the forwarding tables. > > Beep, beep! Tilt! Wouldn't a hardware forwarder which has this sort of > flexibility necessarily have the flexibility to handle different addressing > structures (not that I think we'll have a different addressing structure :-)? > Remember, forwarding and routing are in large part the same thing in hop-by- > hop systems. Yes. A Pip forwarding engine CAN deal with multiple addressing spaces. The SAME engine can deal with VCIs AND hierarchical addresses, for instance. It is just a matter of priming the forwarding tables properly. (The "Logical Router" field chooses the forwarding table, and the "Routing Hint" gets you the index into the forwarding table. If you want multiple address spaces, then you have multiple Logical Router values and multiple forwarding tables). > E.g. if you built a forwarding chip which used the the RD to forward > packets, and then, using the flexibility in PIP, decided to switch to an > architecture like Nimrod, which tagged packets to flows with the ID (or ESI in > PIPese), would that chip really still work? Yes. An "ID-to-flow tagging" packet would setup the flow info in the routers, and for data packets, the flow tag itself would be carried in a Routing Hints field, with the Logical Router field indicating that the Routing Hint is a "flow tag" and not a full address. In fact, both tagging and full addresses could both be used at the same time by the same hardware. PT From owner-Big-Internet@munnari.oz.au Fri Jun 26 18:13:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13681; Fri, 26 Jun 1992 18:13:44 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206260813.13681@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13678; Fri, 26 Jun 1992 18:13:39 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jun 1992 09:13:10 +0100 To: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Thu, 25 Jun 92 11:59:22 EDT." <9206251559.AA16514@easynet.crl.dec.com> Date: Fri, 26 Jun 92 09:13:01 +0100 From: Paul Tsuchiya > > I think that this is an interesting question. My feeling it that IP has > been stable for quite a while, and we are likely to find that CLNP will > be stable for quite a while. If we come up with a new IP, then it will > take a few years before it becomes stable, but once it does it too will > remain stable (or be rejected in the market). > How can you say that IP has been stable for quite a while? The change from non-subnetting to subnetting systems was dramatic, as was the change from non-variable-length subnetting to variable-length subnetting. In each of these cases, many routers had to modify their routing table lookup algorithm to deal with the new address semantics. If those systems had been built in hardware, then hardware changes would have been necessary. Even now, as I recall from the road group discussions, we have trouble going to certain supernetting schemes because there are hosts out there that base their decisions on class A/B/C structure. PT From owner-Big-Internet@munnari.oz.au Fri Jun 26 18:28:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14052; Fri, 26 Jun 1992 18:28:30 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206260828.14052@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14040; Fri, 26 Jun 1992 18:28:23 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jun 1992 09:26:40 +0100 To: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Thu, 25 Jun 92 12:45:51 EDT." <9206251645.AA24948@ginger.lcs.mit.edu> Date: Fri, 26 Jun 92 09:26:31 +0100 From: Paul Tsuchiya > > I understood this to mean that PIP addresses were numbered from the > top down. I thought the line about multiple number authorities was speaking > of totally disjoint numbering spaces. > Let me ask a questions which will help clarify this. If I have two > different 'top level' authorities, can they join together, and stick another > layer on top, with different values to indicate addresses assigned by the > two different authorities? It is true that AT ANY GIVEN TIME the "top-level" of the hierarchy (or of multiple hierarchies, if you've got them) must be recognized by routers. But, you can always add a level on top, thus producing a new top-level (or I guess more accurately, shoving everything down a level). Let me give an example that may clarify things a bit. Say initially we hand out "top-level" things to backbones. But, we decide at some point that there are too many backbones and the routing tables are getting too big, so we want to stick another level of hierarchy on top. We can take a number out of the "top-level" space, and assign that number to an existing group of backbones, no problem. The former "top-level" numbers that the backbones in the group had are now "top-level - 1" numbers, and everything under those backbones has an additional level of hierarchy in their "addresses". > > > By the way Noel, since in Nimrod you number from the bottom, how do > you add levels at the bottom? > > The bottom level names physical things like interfaces. How can > you have a layer below physical things? Maybe I'm just not understanding > your question. Do you mean "what do you do when an address level (i.e. > equivalent of directory in hierarchical file system) gets too large"? Well, say that you have a host with an address, and that host becomes a multi-processor system, and wants to give each processor an address. Or, I have a single box in my house, but then I install a LAN in my house, so now I need to add a level of hierarchy to the bottom (or nearly so). PT From owner-Big-Internet@munnari.oz.au Fri Jun 26 18:51:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14737; Fri, 26 Jun 1992 18:51:52 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206260851.14737@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14727; Fri, 26 Jun 1992 18:51:41 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jun 1992 09:51:05 +0100 To: big-internet@munnari.oz.au Subject: Re: network number and addresses (administration of IEEE IDs) In-Reply-To: Your message of "Thu, 25 Jun 92 13:05:41 EDT." <9206251705.AA25447@ginger.lcs.mit.edu> Date: Fri, 26 Jun 92 09:50:56 +0100 From: Paul Tsuchiya > > My argument is that this growing non-optimality is also a natural > process in networks, and the renumbering will be attractive. However, if > we make this a manual process, forget it. The total costs of doing the > renumbering will be so large we'll let the first function get real large > before we do it (if we ever do). > However, an automatic system (with a place for human guidance and > control, certainly), built in from day one, could slowly change numbers > (i.e. keep the costs of running it to a low level, just like routing > traffic is a small percentage of the traffic on the network) to keep up. > In X3S3.3, there is a piece of work that allows all hosts and routers in an ISIS area to automatically be assigned new prefixes. This work goes a long way in fulfilling your desire for an automatic system. I think a critical point in the above message is "with a place for human guidance". With Landmark routing, the re-numbering is completely automatic. This is ok for say a mobile packet radio network where everything changes so fast that human administrators cannot keep up, but I don't think it is appropriate for a basically stable internet where we can (to some extent) control the topology. So, really, I don't think we should be looking at Landmark routing in the current context. PT From owner-Big-Internet@munnari.oz.au Fri Jun 26 19:10:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15207; Fri, 26 Jun 1992 19:10:16 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206260910.15207@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15196; Fri, 26 Jun 1992 19:10:08 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jun 1992 10:08:57 +0100 To: bmanning@edu.rice.is (William Manning) Cc: fbaker@acc.com (Fred Baker), big-internet@munnari.oz.au Subject: NAP concept (was Re: network number and addresses) In-Reply-To: Your message of "Thu, 25 Jun 92 14:19:38 CDT." <9206251919.AA08063@san-miguel.is.rice.edu> Date: Fri, 26 Jun 92 10:08:48 +0100 From: Paul Tsuchiya > > Does this fit with the NAP concept in the current NREN flap? > What is this NAP thing anyway? I recently had a look at the NREN proposal and couldn't make heads nor tails of what they wanted to do with the NAP. PT From owner-big-internet@munnari.oz.au Fri Jun 26 19:26:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15518; Fri, 26 Jun 1992 19:27:05 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11779; Fri, 26 Jun 1992 17:14:30 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA28653 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 26 Jun 1992 17:14:27 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA06921; Fri, 26 Jun 92 17:14:27 EST Message-Id: <9206260714.AA06921@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Security concern (was Re: meta matters) In-Reply-To: Your message of "Fri, 26 Jun 92 15:22:19 +1000." <16380.709536139@munnari.oz.au> Date: Fri, 26 Jun 92 17:14:26 +1000 From: Bob Smart >Given this, first I conclude that there is never any real >point in putting the destination ID in a packet Good point. We should all, like kre, think carefully before we post, but then I wouldn't be me, so: >To get specific briefly, PIP uses the ID to allow a mobile >host to change its address It also allows a host to have different addresses for different purposes: this one is fast, this one costs less, this one has AUP restrictions. One problem is what to use for an ID. How about using an address. The address would be one which might be you or which might just know who you are. For example suppose 128.250.99.99 is a machine that looks after mobile hosts associated with Melbourne Uni. The ID for mobile host 17 would be 128.250.99.99.17. When a packet arrives at 128.250.99.99 destined for 128.250.99.99.17 the host would respond with an ICMP "valid recent addresses for 128.250.99.99.17 are ...". You could then pick one that meets your AUP/cost/performance requirements. It would be nice if the ICMP message had a message digest encoded with 128.250.99.99's private key! Also when you have an application with any security consideration about returning a packet to the putative return address you would send to the ID as an address first, and check the reply. All of which is not meant to suggest that you can get any significant level of security from trusting the addresses in packets, but as long as the NSA and the FBI are determined to suppress the use of encryption and other security technology we have to make do. A possible minor advantage of using an address as an ID is that in the common case where the ID and the source address are the same the ID could be left out of all packets (just set a flag saying ID is address). Using addresses as IDs might reduce flexibility. You would have to not reuse those addresses. If the host can no longer be reached at that address (but it remains his ID) then some router in the path to the now-defunct address would have to send an address redirect back. This is not such a problem in the new world: with an infinite quantity of addresses we aren't under pressure to reuse them. Bob Smart P.S. I just got Steve Deering's meesage in another window. I agree with him 100%. A flat ID space is a bad idea. Obviously my comments above are based on ideas that have been circulating about mobile hosts. From owner-Big-Internet@munnari.oz.au Fri Jun 26 19:58:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16479; Fri, 26 Jun 1992 19:58:40 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206260958.16479@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16471; Fri, 26 Jun 1992 19:58:31 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jun 1992 10:58:16 +0100 To: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Fri, 26 Jun 92 15:22:19 +0900." <16380.709536139@munnari.oz.au> Date: Fri, 26 Jun 92 10:58:06 +0100 From: Paul Tsuchiya > > To get specific briefly, PIP uses the ID to allow a mobile > host to change its address - the destination will notice > the source address has changed (the RH numbers in PIP) > and update its idea of how to get to the source identified > by the ID in the packet (PIP draft, section 4.4) Pip also takes advantage of the ID to play all kinds of tricks with the Routing Directive (address++). FOr instance, treating the routing directive as a VCI, meaning being able to modify the VCI hop-by-hop. Or, writing in the inter-domain part of the address when packets exit a stub domain. > > But is this safe? To me it appears that this allows any > random host to "borrow" the identity of another, simply > by sending a packet, containing the victim host's ID as > the source ID, and with the borrower host's address as > the source addr. Is there something I'm missing here? Extremely good point, and I don't think you're missing anything. But, this problem exists in any mobility situation, because you must be able to change address and still maintain the identity. Seems we'll need to solve it to make progress in this area, but this should not be a reason to not separate ID and address in packets for now (a host can always choose to only accept the address originally used). PT From owner-Big-Internet@munnari.oz.au Fri Jun 26 20:14:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16854; Fri, 26 Jun 1992 20:14:45 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206261014.16854@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16847; Fri, 26 Jun 1992 20:14:34 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jun 1992 11:14:11 +0100 To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: Mobile Hosts and IDs In-Reply-To: Your message of "Thu, 25 Jun 92 23:49:18 PDT." <92Jun25.234928pdt.22277@skylark.parc.xerox.com> Date: Fri, 26 Jun 92 11:14:02 +0100 From: Paul Tsuchiya > > Granted, there are other approaches to supporting host mobility that > might benefit (or not suffer) from a flat ID space. But I suggest > that it is unwise to claim that flat IDs will be useful for supporting > mobile hosts until the actual mobile support architecture/protocols > have been chosen. > > Steve > But, if the actual mobile suport architecture/protocols assume the IP model, then naturally they may not take advantage of the separate ID. So, I think it is useful that we think about the architecture both inside and outside the context of separate flat IDs. PT From owner-Big-Internet@munnari.oz.au Fri Jun 26 21:13:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18131; Fri, 26 Jun 1992 21:14:01 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206261114.18131@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18128; Fri, 26 Jun 1992 21:13:54 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jun 1992 12:13:24 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Para Meta Matters... In-Reply-To: Your message of "Tue, 23 Jun 92 13:54:59 EDT." <9206231754.AA12460@ginger.lcs.mit.edu> Date: Fri, 26 Jun 92 12:13:10 +0100 From: Jon Crowcroft we have on the table Nimrod (which i believe to be a useful description of where to go with routing) EIP & IPAE (which are very similar, but EIP is cleaner - both admit of minimal chages...) and PIP (which i believe admits of all the previous) for comparisons, let me say a) I agree with ID, addr/location separation b) you need to identify User Class of traffic as well as allow for source routing style policies... c) The minimal allowable change to the Internet must admit of MORE CHANGE in the future with LESS PAIN (see O'Malley and Tsuchiya - the foremost problem with the Internet is now logistics) d) There is a problem of Hierarchy Versus Abstraction (see Nakassis) Polocy and QoS guarantees are the 2 functions we started to cry out for in the late 80s... they (plus shear number of end systems) call for hierarchy to cope with scale, but hierarchy hides QoS and Internet Policies... this tradeoff needs to be engineered just right to make us believe the architecture... PIP is the right framework, EIP&IPAE give us food for thought only on minimal packet format changes, Nimrod gives us good input on which routing mechanisms to use... but the forwarding engine is where QoS work is important too... j. From owner-Big-Internet@munnari.oz.au Fri Jun 26 22:59:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20597; Fri, 26 Jun 1992 22:59:10 +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 AA20592; Fri, 26 Jun 1992 22:59:00 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA17507); Fri, 26 Jun 92 07:58:49 CDT Received: by san-miguel.is.rice.edu (AA08794); Fri, 26 Jun 92 07:58:48 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9206261258.AA08794@san-miguel.is.rice.edu> Subject: an aside To: big-internet@munnari.oz.au Date: Fri, 26 Jun 92 7:58:47 CDT X-Mailer: ELM [version 2.3 PL11] Paul, this is a pointer to what a NAP is. This is from a couple of months back, and may not represent current thinking, but should be basically correct. Now, for the information impaired, can you provide a pointer to Landmark and what it is or is supposed to do? ------------------------------ I have just returned from the Federal Network Council Advisory Committee Meeting, and thought I would convey a few of the highlights of the NSFNET recompetition as it was explained by Bob Aiken. With regard to the two cooperative agreements that are to be awarded by NSF to organizations to furnish and operate the telecommunications circuits required to transport NSFNET backbone traffic: -- 155 megabits per second capacity is the minimum that will be acceptable to NSF -- a promise to expeditiously upgrade capacity to 622 megabits per second is strongly encouraged -- backbone traffic, which will still be subject to the AUP, must be segregated in some manner from other traffic that might be carried by the same circuit provider, so that NSF can track the volume of research and education traffic flowing through the system. With regard to the cooperative agreement that is to be awarded by NSF for the operation and management of the NSFNET routing authority: -- the designated organization will also be responsible for setting up "network access points" that will be major nodes on the backbone. -- these NAPs will not be subject to the AUP, and thus available for a variety of purposes apart from access to the NSFNET backbone. For example, regional networks might choose to use the NAPs to inter- connect among themselves so that they can directly swap traffic. Commercial network providers (non-NSFNET) might use the NAPs to collect traffic from the regionals or from each other, or to pass qualified traffic onto the NSFNET backbone. If you meet certain minimum qualifications, anyone can connect to any NAP. -- the NAPs themselves will not be subsidized by NSF, and thus their operating costs must be split among users. Some users, such as the regional networks, might get a subsidy from NSF that can be applied to NAP charges. I recommend that you get the implementation plan from the NSF server, and refer any questions to Bob Aiken (raiken@nsf.gov), Peter Ford (peter@ goshawk.lanl.gov) or Hans-Werner Braun (hwb@sdsc.edu). Stephen Gould Congressional Research Service ---------------------------- -- 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 Sat Jun 27 01:46:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25912; Sat, 27 Jun 1992 01:46:20 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25906; Sat, 27 Jun 1992 01:46:00 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA05577; Fri, 26 Jun 92 11:45:38 -0400 Received: by easynet.crl.dec.com; id AA03132; Fri, 26 Jun 92 08:30:08 -0400 Message-Id: <9206261230.AA03132@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Fri, 26 Jun 92 08:30:14 EDT Date: Fri, 26 Jun 92 08:30:14 EDT From: Ross Callon To: p.tsuchiya@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au Apparently-To: p.tsuchiya@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: re: Re: meta matters > >> I think that this is an interesting question. My feeling it that IP has >> been stable for quite a while, and we are likely to find that CLNP will >> be stable for quite a while. If we come up with a new IP, then it will >> take a few years before it becomes stable, but once it does it too will >> remain stable (or be rejected in the market). >> > > How can you say that IP has been stable for quite a while? The change > from non-subnetting to subnetting systems was dramatic, as was the > change from non-variable-length subnetting to variable-length subnetting. > In each of these cases, many routers had to modify their routing table > lookup algorithm to deal with the new address semantics. If those > systems had been built in hardware, then hardware changes would have > been necessary. Even now, as I recall from the road group discussions, > we have trouble going to certain supernetting schemes because there are > hosts out there that base their decisions on class A/B/C structure. > > PT Well, I was thinking only of the forwarding path, and the time frame since subnetting was first introduced. One interesting speculation is, if someone had implemented forwarding in hardware after the subnetting RFC was published, would they have assumed that any one network number would always have a fixed subnet mask? I don't see how this assumption would have helped an implementation, although I can see how this assumption might have made an implementation more complex. To a large extent this is all moot, and the real question is whether the future is likely to be stable. Clearly if one believes that the answer is "yes" then one is anticipating some very specific solution to the routing, addressing, and scaling problems. Given that the final solution can't be decided until we have deployed and tested it, this would seem like an ambitious assumption. Ross PS: I won't be around to answer your response (going on vacation for two weeks). See you at the IETF. From owner-Big-Internet@munnari.oz.au Sat Jun 27 02:05:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26342; Sat, 27 Jun 1992 02:06:05 +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 AA26336; Sat, 27 Jun 1992 02:05:52 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA29389; Fri, 26 Jun 92 09:05:44 PDT Message-Id: <9206261605.AA29389@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: Getting the source correct Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Fri, 26 Jun 92 09:05:43 -0700 From: Dave Crocker This is a bit painful to type, since I've just had my knuckles very rightly rapped. My reference, last night, to your being able to get an early copy of the IP Address Encapsulation proposal from nri was intended to apply _only_ to last night, until the copy was replicated at the various shadow directories around the world. I know, for example, that it is already at the SRI site. So, please _do_ obtain a copy, but please obtain it from your local, neighborhood I-D provider. Dave From owner-Big-Internet@munnari.oz.au Sat Jun 27 02:18:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26821; Sat, 27 Jun 1992 02:18:25 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26812; Sat, 27 Jun 1992 02:18:13 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA07195; Fri, 26 Jun 92 12:18:02 -0400 Received: by easynet.crl.dec.com; id AA03735; Fri, 26 Jun 92 09:02:32 -0400 Message-Id: <9206261302.AA03735@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Fri, 26 Jun 92 09:02:34 EDT Date: Fri, 26 Jun 92 09:02:34 EDT From: Ross Callon To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: deering@parc.xerox.com, big-internet@munnari.oz.au Subject: re: Mobile Hosts and IDs > > ...Those (mobile host) schemes work by assuming that > every host has a "permanent" address > on a "home" subnet, which is used as the host ID. Other hosts and > routers initially send packets towards the home subnet, whence they > may learn the current location of the destination host, if it happens to be > elsewhere; a roaming host keeps the routers on its home subnet informed > of its current location. (This does not necessarily imply that ALL traffic > to a roaming host must be routed via the home subnet.) > > (Another way to think of this approach is that the "current location" is > used as a "hint"; whenever the hint fails, the "truth" can be learned by > sending to the "ID" address, at some additional cost.) > I had sort of being assuming that you had to do this (whether there was a global ID somewhere in the address or not). Thus I had thought that the differences between what you do if you have a global ID as part of the address and what you do if the entire address constitutes the ID is all within the context of the common stuff as you described it above. > > Granted, there are other approaches to supporting host mobility that > might benefit (or not suffer) from a flat ID space. But I suggest > that it is unwise to claim that flat IDs will be useful for supporting > mobile hosts until the actual mobile support architecture/protocols > have been chosen. > > Steve > I think that there is a chicken and egg issue here: If the mobile host work assumes that you need the entire address to identify a host, then it will be constrained to approaches which have no use for a unique ID buried somewhere in the address. Thus, I think that it might be useful to at least speculate on how the scheme might possibly be simplified if we had control of the new address format (given that we know that we are going to need a new address format, implying that we actually do have this control). To begin this speculation, suppose that you have a "normal" stationary host which sends a packet to a mobile host's "home" location, but that the mobile host is currently somewhere else. There are two issues: (i) Assuming that this first packet will get forwarded to the mobile host, how does it get there; (ii) How does the normal host eventually find out how to send packets directly to the mobile host, rather than indirectly via the mobile host's "home" location. I claim that if you have a globally unique ID buried within the address, then both of these can just be part of the normal protocol operation, with no need for any packets other than the normal data packets (no encapsulation, no error reports, ...). Let's discuss this at the IETF (I won't be able to discuss this in more detail before then). Ross From owner-Big-Internet@munnari.oz.au Sat Jun 27 02:31:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27217; Sat, 27 Jun 1992 02:31:18 +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 AA27205; Sat, 27 Jun 1992 02:31:11 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA29752; Fri, 26 Jun 92 09:31:06 PDT Message-Id: <9206261631.AA29752@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: ID ACTION:draft-crocker-ip-encaps-00.txt Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Fri, 26 Jun 92 09:31:05 -0700 From: Dave Crocker I seem to be getting I-D announcements about one day after they are sent, so this copy may get to you sooner. Dave ------- Forwarded Message To: IETF >From: Internet-Drafts@nri.reston.va.us Reply-to: Internet-Drafts@nri.reston.va.us Subject: ID ACTION:draft-crocker-ip-encaps-00.txt - --------- A New Internet Draft is available from the on-line Internet-Drafts directories. Title : A Proposal for IP Address Encapsulation (IPAE): A Compatible Version of IP with Large Addresses Author(s) : R. Hinden, D. Crocker Filename : draft-crocker-ip-encaps-00.txt Pages : 20 The Internet currently is seeking a means of providing for long-term growth by increasing the amount of address space that is available for hosts and by decreasing the amount of table storage that is required for routers. One solution to these problems is a direct upgrade to a new version of IP. Another is to switch to use of a new protocol such as CLNP which has provisions for a larger and more hierarchical address space. Both require very substantial disruption to the IP installed base. This proposal describes an alternative which minimizes overall disruption and, in fact, entirely eliminates a significant portion of it. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-crocker-ip-encaps-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: nnsc.nsf.net (128.89.1.178) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND internet-drafts/draft-crocker-ip-encaps-00.txt". For questions, please mail to internet-drafts@nri.reston.va.us. ------- End of Forwarded Message From owner-Big-Internet@munnari.oz.au Sat Jun 27 03:04:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28137; Sat, 27 Jun 1992 03:04:46 +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 AA28126; Sat, 27 Jun 1992 03:04:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05074; Fri, 26 Jun 92 13:04:04 -0400 Date: Fri, 26 Jun 92 13:04:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206261704.AA05074@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: Re: meta matters Cc: jnc@ginger.lcs.mit.edu We can take a number out of the "top-level" space, and assign that number to an existing group of backbones, no problem. I didn't quite fully catch this particular sentence, because I could see a number of ways to interpret it. Let me see if, from contextual sentences I got it right. As I undertand your scheme, you can take a group of the items which are in the top level space, allocate an as yet unused number out of the top-level space, and push that group down underneath that number? Well, say that you have a host with an address Hosts don't have addresses. Network interfaces have addresses. that host becomes a multi-processor system, and wants to give each processor an address There are several ways to handle this in the Nimrod paradigm. Which one you consider best depends on what you want the characteristics of the system to be. First, you could consider the multi-processor bus as a network, and the individual processors as hosts attached to that network. The processor which controls the network interface then becomes the 'router' which connects the 'bus-network' to the 'real-network.' The individual processors have 'addresses' on the 'bus-network'. Second, if each processor is an individual end-end, fate-sharing region, each could have a separate identifier, all of which would map to the same network address. Finally, if the entire system is so tightly coupled that it is a single fate-sharing region, then you could use ports and other existing internal demultiplexing. I know, ports are seen as a separate address space, but in a way they are just more packet demultiplexing. (I guess that I have a certain sympathy for an ISO/PUP/XNS-like view of the world where there is no demultiplexing above the network layer, and it's all in the layer three names. I must say, I'm not sure ISO got it right by making the protocol part of the address and leaving the ports separate; I'd have been more inclined to invert that!) I have a single box in my house, but then I install a LAN in my house This one you clearly handle by extending the topology, assigning a new level 1 network number in whatever level 2 area you are in, etc. You're just adding on another element in the topology graph, right? No need for more levels! Noel From owner-Big-Internet@munnari.oz.au Sat Jun 27 03:13:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28370; Sat, 27 Jun 1992 03:13:19 +1000 (from owner-Big-Internet) Return-Path: Received: from sadye.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28367; Sat, 27 Jun 1992 03:13:14 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.uvm.edu id AA01157 (5.65/1.23); Fri, 26 Jun 92 13:13:03 -0400 Date: Fri, 26 Jun 92 13:13:03 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9206261713.AA01157@sadye.uvm.edu> To: big-internet@munnari.oz.au Subject: Thoughts on PIP and ARP and ... After having read the PIP document, I think I've pretty much got it figured out, and that has led me to some thoughts... - PIP leaves a lot of configuration choices to the local installation. There should be some sort of protocol for obtaining information about these configuration choices from adjacent routers. This would also tell a system the MAC layer address of all the routers near it, and could also be used to tell a host what *its* address is. (Doesn't the IANA have a multicast 802 address assigned to it which means `to all routers'? If not, it should.) - In order to prevent this configuration from getting stale, there needs to be a way (through PIP's equivalent of ICMP, perhaps?) to inform hosts that they should re-configure themselves. Perhaps the existing control messages listed in Paul's proposal would be fine (i.e., when a host receives PCMP x, y, or z, it must do a re-configure). - I strongly believe that the configuration-discovery protocol should be a separate entity from the control-message protocol; no more ICMP Address Mask Request. I would think that the PCDP would oprerate at the same level as PIP, whereas PCMP would be transmitted inside of PIP packets. (Since you can't form a locally-valid PIP packet without this configuration information, I think this is obvious.) - In a scheme where PIP addresses are locally hierarchical (which I think is the most likely mode of operation), you can avoid using ARP. When you have a local address that you don't know the MAC address for, just use a broadcast MAC address, and if you receive a broadcast with a PIP address pointing at you, send an ARP-style reply. (Correct me if I'm wrong, but I think this sounds a bit like ESIS. Sorry.) - I don't think that PIP's enormous flexibility in address-component lengths is all that useful. I would probably prefer to implement a scheme where RHF+RFHR is an even multiple of 8 bits, which would mean only using RHF-length values of 3, 9, and 13. - For name service: I think we want to be able to do the following: EPID -> name Address -> name name -> ( EPID, Address ) Is there anything else which might be used a lot (and should therefo re be optimized to avoid the path through the host name)? -GAWollman PS: Let's have Paul to the address and packet format, Noel do the routing, and Ross do the transition plan... From owner-Big-Internet@munnari.oz.au Sat Jun 27 03:50:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29324; Sat, 27 Jun 1992 03:50:22 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29318; Sat, 27 Jun 1992 03:50:03 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA03766; Fri, 26 Jun 92 10:49:55 -0700 Received: by us1rmc.bb.dec.com; id AA00742; Thu, 25 Jun 92 18:20:56 -0400 Message-Id: <9206252220.AA00742@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 25 Jun 92 18:20:57 EDT Date: Thu, 25 Jun 92 18:20:57 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: meta matters ... Gee, sorry I was running errands today and could not participate in the mail maelstrom. A few things: === I'd like to give a pitch for minimizing state in routers and other intermediate systems and putting as much of the burden as is reasonable on the end systems. One of the important factors in the early success of IP was that you could take a pretty lame machine and have it do useful routing with the simple class based addresses. === On "stability" and the like, every comment I have seen so far on how long IP4 will continue to be used has been a *gross* underestimate. I can remember from the early ARPANET days when there were only hundreds of hosts and they were all US military or DoD contractors and directives would come down to switch to some new protocol by some deadline and nothing would happen. And new deadlines would be set and new edicts would come down and still nothing would happen. Changes universally considered improvements scheduled to be deployed in months would take years. Of course its different if something is bad enough that it really stops working. Sure, with address exhaustion, maybe new people can't get on board, but with the current investment in IP4, if NewIP were fully defined and approved today, there would still be a viable globally connection IP4 network for *at* *least* 10 years and probably significanly longer. === In a telepone conversation with Ross Callon, I mentioned that when I was still thinking of fixed length addresses, I came up with a scheme for subdividing 64 bits into various length hierarchial subfields. He was interested in seeing the details so I'll try to post it here soon on the theory that others might be interested. Donald From owner-Big-Internet@munnari.oz.au Sat Jun 27 03:57:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29600; Sat, 27 Jun 1992 03:57:15 +1000 (from owner-Big-Internet) Return-Path: Received: from asherah.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29591; Sat, 27 Jun 1992 03:57:06 +1000 (from avri@asherah.clearpoint.com) Received: by asherah.clearpoint.com (4.1/1.34) id AA15071; Fri, 26 Jun 92 13:56:12 EDT Date: Fri, 26 Jun 92 13:56:12 EDT From: avri@asherah.clearpoint.com (Avri Doria) Message-Id: <9206261756.AA15071@asherah.clearpoint.com> To: big-internet@munnari.oz.au In-Reply-To: Ross Callon's message of Fri, 26 Jun 92 08:30:14 EDT <9206261230.AA03132@easynet.crl.dec.com> Subject: re: Re: meta matters I don't quite understand the great need for long term protocol stability in terms of making hardware implementations. Many of the current router companies distribute their router code in EPROMS. It isn't that much greater a chore to change a socketed FPGA than it is to change socketed EPROMS. Nor is it really that great a chore to reprogram an FPGA. Going to an ASIC is perhaps a bit more time consuming but still not a herculean task. avri From owner-Big-Internet@munnari.oz.au Sat Jun 27 04:39:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00767; Sat, 27 Jun 1992 04:40:16 +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 AA00741; Sat, 27 Jun 1992 04:39:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08070; Fri, 26 Jun 92 14:39:31 -0400 Date: Fri, 26 Jun 92 14:39:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206261839.AA08070@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, kre@munnari.oz.au Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Yes, of course, if the ID is not used for anything by any of the switches between the source and destination host, there no reason *from their point of view* to put it in the packet. However, just because it's not used by the intermediate switches does not mean it is not used at the endpoints. The switches don't use the 'protocol' field in most cases, either, but that has to be there! The question (in this hypothetical case) is, do the hosts on the end have a use for it which means it has to be there? For protocols like TCP, it would implicitly be there, in the pseudo-header checksum, to make sure the packet is from who you think it is. However, there might be other reasons why the hosts would want to see it (in most or all packets). A real end-end security architecture might want it, for instance. (Those guys local globally unique ID's!) My brain is full of routing right now, so I can't offhand come up with any, but I'll bet there are more. (Less critical point follows, skip if you want.) To me it appears that this allows any random host to "borrow" the identity of another, simply by sending a packet, containing the victim host's ID as the source ID, and with the borrower host's address as the source addr. Yup. Without some sort of authentication on this transaction, it's subject to attack. (Recall that I mentioned the need to secure the equivalent transaction when done through a translation server, when I was discussing real time modification of the translation.) Moreover, it implies that the complexity cost of securing this mapping has to be borne by both the source and destintaion hosts. What I like about putting the mapping between address and identifier in a translation server is it provides a natural way to secure that translation in a flexible way. E.g., you can secure the source->server part of it without any mechanism in the source host by making the translation hand-entered, etc, etc. Of course, it might still be useful (for efficiency reasons, for example) to allow direct contact between the endpoints to change the address-identifier mapping. From owner-Big-Internet@munnari.oz.au Sat Jun 27 05:37:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02277; Sat, 27 Jun 1992 05:37:39 +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 AA02269; Sat, 27 Jun 1992 05:37:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08754; Fri, 26 Jun 92 15:37:14 -0400 Date: Fri, 26 Jun 92 15:37:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206261937.AA08754@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Mobile Hosts and IDs Cc: jnc@ginger.lcs.mit.edu Steve, while your point about not assuming particular mechanisms will help support mobile hosts until you know how you will support mobile hosts is a good one, I think there are a good reasons to look askance at the mechanism you mention, and to think that identifiers are the right approach. First, let us be frank and admit a good part of the reason they are taking this path is because they have to deal with an installed base, and they want to interoperate with vanilla hosts. They have to keep the original address both because of the TCP pseudo-checksum (if you wish to keep connections open), and because it is useful to have a least one constant 'name' for a host, and the address is the only non-DNS 'name' we've got. Now, I'll admit, within those constraints, they've got a relatively good answer, but let's analyse this from a more fundamental viewpoint. This is a legitimate thing to do, since we are discussing a whole new system, and how to do mobile hosts 'properly' is a legitimate topic of inquiry. You have three basic options in dealing with mobile hosts. First, you can somehow get the host on the other end (the 'static host') to cooperate and put something in the packets which makes them go to the new location. Second, you can have the routers into the home network keep track of the fact that the host has gone, and forward the traffic. This means the traffic may be taking a non-optimal route, though, if that matters. Third, you could have the routers in the network know that that destination has moved, and do the right thing. As soon as you think about this, you optimize it to having just the first hop routers near the static host know the mobile host moved, and doing the right thing. (Flooding the info is clearly unreasonable, and putting the information just along the path between the two is better, but just having the source know is best. In the first and third case, you do have options of slight differences of mechanism depending on whether you are moving already open connections, or trying to talk to a host which has moved, but generally these are just optimizations, and can be ignored for now. In any of these cases, you need some invariant name for the host which has moved. We have two options; we can use a name picked from the 'address' name space, and map from one address to another (the way the 800 systenm works), or we can make the invariant name be a separate namespace, the identifier. No matter which of these you use, you wind up with similar looking solutions, depending on which of the three approaches you used. This is not surprising; thing X needs piece of information Y to make a particular basic approach work, and it doesn't matter much which form it gets it in. However, it's a general principle of system design that the further you drag a mechanism from the purpose for which it was originally intended, the less well it functions in its new use. Addresses are names which are used by the routing, primarily to identify network attachment points. To use them to name something else (like hosts) will work, but the mechanism required to make them work in this new application will not be as clean as the mechanism you could have had if you had picked some more appropriate name. It's another general rule of system design that big systems don't break; they just get more and more hard to use and modify as the accrete more and more poorly integrated special purpose mechanisms. This applies to a network architecture (which is, after all, just a *giant* distributed program) just as well as it does to an operating system or any other big system. Yet another rule is that if you have an low-cost opportunity, at the design time of a new system, to fix one of these accretions to an old system by reforming the basic structure to do what you want cleanly, you should always do so. I know that not everyone out there treats system design rules of this sort with the same sort of respect that I do, but believe me, they are the result (like a lot of engineering rules) of hard experience, to be ignored at your peril. Engineers who ignore the unwritten rules of their profession usually wind up in a sticky end, like the Titanic, or Challenger. So, will it work to use addresses for something other than identifying network attachment points? Yes. Is it good system engineering practice to do that? No. Should we change it? Yes. Noel From owner-Big-Internet@munnari.oz.au Sat Jun 27 06:17:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03248; Sat, 27 Jun 1992 06:18:02 +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 AA03244; Sat, 27 Jun 1992 06:17:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09098; Fri, 26 Jun 92 16:17:48 -0400 Date: Fri, 26 Jun 92 16:17:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206262017.AA09098@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Security concern (was Re: meta matters) Cc: jnc@ginger.lcs.mit.edu >Given this, first I conclude that there is never any real >point in putting the destination ID in a packet Good point. Do recall that his conclusion is based on the premise that the routers aren't using the ID. Also, recall that the end hosts may have a need to see the ID in every packet. It also allows a host to have different addresses for different purposes: this one is fast, this one costs less, this one has AUP restrictions. People seem to really like this idea, and I guess in a DV/hop-by hop/routing table view of the world it does have a certain attraction. Since the computation and creation of the route is distributed, having different addresses does allow you naturally to pick different routes with different attributes. However, in a source routed link state view of the world, it is easier to see different subtly interrelated things that an address does for you (names an attachment point, provides a way of communicating network topology, provides a framework for the abstraction process, and thus, influences the routes - see 3.3.2 of Nimrod for a fuller discourse). I find that when you start to think about all the different tasks an address has to fulfil, overloading yet one more task on them (policy routing) really is the proverbial straw. The list of tasks that addresses have to tackle to handle abstraction is so important, and so hard, that I really think that doing policy routing with them is too big a stretch. There are other mechanisms avilable to do policy which are more flexible, and more powerful, and more closely attuned to the needs to policy routing. The comments I made in a previous message about dragging mechanisms further from their original purpose apply here as well. as long as the NSA and the FBI are determined to suppress the use of encryption and other security technology we have to make do. Well, not to defend their position on cryptographic protection of the *contents* of communication (which I happen not to agree with, since I think the horse has bolted), I think you will find that they are more relaxed about cryptographic *authentication* of communication. I would think we'd have a free hand (in fact, probably their willing support) on that end of things. Again, not to defend their position on contents, but let's not pick fights we don't need to (and my best wished to those who are fighting that particular fight). Noel From owner-Big-Internet@munnari.oz.au Sat Jun 27 06:31:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03616; Sat, 27 Jun 1992 06:32:03 +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 AA03610; Sat, 27 Jun 1992 06:31:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09189; Fri, 26 Jun 92 16:31:43 -0400 Date: Fri, 26 Jun 92 16:31:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206262031.AA09189@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: Para Meta Matters... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The minimal allowable change to the Internet must admit of MORE CHANGE in the future with LESS PAIN Well, yes, this is easy to agree with. However, I still don't think I've seen a refutation of my claim that in the future, the Internet will be so big that to even change the basic routing architecture will be impossible. If you can't change the routing architecture, then what use address structures which can support varying routing architectures? This also ignores my assertion that we should get hosts totally out of dealing with addresses anyway, except carrying them around as unparseable byte strings, as an optimization to prevent the routers having to do duplicate lookups. they (plus shear number of end systems) call for hierarchy to cope with scale, but hierarchy hides QoS and Internet Policies... this tradeoff needs to be engineered just right to make us believe the architecture... There *is* no tradeoff between these two incompatible goals of abstraction (needed to do scaling) and policy which is right for everyone. You have to have a structure which allows different people with different requirements to set the tradeoff knob where they want it. This is a major goal of Nimrod. Nimrod gives us good input on which routing mechanisms to use... Nimrod has some (hopefully fundamental) thoughts on framework. Nimrod deliberately avoided algorithms (e.g. for route ccomputation and topology abstraction, since algorithms are not my strong point), and also protocols (which the author is also not good at; last time I designed a protocol I re-invented Sorcerer's Apprentice Syndrome :-). Noel From owner-Big-Internet@munnari.oz.au Sat Jun 27 06:58:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04348; Sat, 27 Jun 1992 06:58:32 +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 AA04345; Sat, 27 Jun 1992 06:58:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09484; Fri, 26 Jun 92 16:58:18 -0400 Date: Fri, 26 Jun 92 16:58:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206262058.AA09484@ginger.lcs.mit.edu> To: Garrett.Wollman@uvm.edu, big-internet@munnari.oz.au Subject: Re: Thoughts on PIP and ARP and ... Cc: jnc@ginger.lcs.mit.edu - I strongly believe that the configuration-discovery protocol should be a separate entity from the control-message protocol; no more ICMP Address Mask Request. I would think that the PCDP would oprerate at the same level as PIP, whereas PCMP would be transmitted inside of PIP packets. (Since you can't form a locally-valid PIP packet without this configuration information, I think this is obvious.) Huh? You mean there's no way in PIP to say "hardware address X on this wire"? I would have thought that the PIP flexibility would encompass this capability, at least. I mean, even Nimrod can do that! I'd like to hear more justifcation on your ICMP point. My understanding (and a tip of the Hatly hat to BBN'ers, who convinced me when the world was young that ICMP and GGP needed to be separate protocols) was that ICMP is supposed to have all the low level functions which are necessary to make the host-host unreliable packet function work. From this point of view, configuration things like "what's my network address" are perfectly reasonable in ICMP. I mean, ICMP already includes i) error messages, ii) diagnostic tools, and iii) control messages. What's wrong with adding a fourth major area, network level configuration stuff (which is really the province of the routers and network infrastructure, not like host configuration)? When you have a local address that you don't know the MAC address for Tilt. How can you have a complete (i.e. unambigous) address for something, and not have the MAC address? Are you going to have a separate number space for hosts on the local wire which you map into the MAC addresses? This is what we have now, and it's a management headache of little worth, as far as I can see (people, please spare me the defense that it allows us ARP, whcich is so wonderful, please :-). Alternatively, are you using identifiers? (I'm losing track of who does and does not like identifiers!) Is there anything else which might be used a lot (and should therefore be optimized to avoid the path through the host name)? Depending on what you have for a deployment plan, it might be useful to have the EPID -> Address translation available. Nimrod uses this translation at the first hop routers to avoid the necessity of modifying the hosts before deployment can begin. Let's have Paul to the address and packet format, Noel do the routing I hope this is tongue in cheek! It's a rare day when Paul and I agree on much, and as you can tell, we have strongly different ideas on how to do the addressing. Noel From owner-Big-Internet@munnari.oz.au Sat Jun 27 07:07:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04568; Sat, 27 Jun 1992 07:07: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 AA04548; Sat, 27 Jun 1992 07:07:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09537; Fri, 26 Jun 92 17:06:54 -0400 Date: Fri, 26 Jun 92 17:06:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206262106.AA09537@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dee@ranger.enet.dec.com Subject: Re: meta matters ... Cc: jnc@ginger.lcs.mit.edu putting as much of the burden as is reasonable on the end systems This is directly in the other direction to the last 10+ years of Internet development, which tried to move the hosts out of the routing game as much as possible. There were (and remain) good reasons for this. One of the important factors in the early success of IP was that you could take a pretty lame machine and have it do useful routing Yah, and in the early days of computing (late 40's, early 50's) everyone built their own computers. Doesn't mean it's still a smart idea, though. (I'm not *that* old, but I can remember the days when application vendors - e.g. CAD/CAM - used to design and build their own CPU's - out of SSI/MSI, of course. Even though I was an undergrad then, I could tell *that* was a losing proposition.) As far as I'm concerned, the day of the homebrew router is over. We've got enough hard problems (scaling, abstraction, etc) to solve without having to support weekend lashups. Noel From owner-Big-Internet@munnari.oz.au Sat Jun 27 07:48:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05423; Sat, 27 Jun 1992 07:48:34 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05420; Sat, 27 Jun 1992 07:48:24 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA19904; Fri, 26 Jun 92 17:48:10 -0400 Message-Id: <9206262148.AA19904@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 2595; Fri, 26 Jun 92 17:46:19 EDT Date: 26 Jun 92 17:49:00 EDT To: , J.Crowcroft@cs.ucl.ac.uk From: Pierre (P.) Fortin Subject: TV (was: network number and addresses (are we changing CLNP? Sender: Pierre (P.) Fortin > no-one thinks television & radio broadcast is a hack...either... Depends... Ever look into why, when colo[u]r came to TV, the subcarrier was set at 3,579,545 Hz (if memory serves) in N.A.? Hint: scan, "combs" and "1 per cent". :^) I think the FM stereo subcarrier was a good design compared to the colo[u]r subcarrier... > jon Pierre ......end of TV/Radio subset tangent........ From owner-Big-Internet@munnari.oz.au Sat Jun 27 08:47:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06623; Sat, 27 Jun 1992 08:47:28 +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 AA06620; Sat, 27 Jun 1992 08:47:20 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA01960; Fri, 26 Jun 92 15:47:11 PDT Message-Id: <9206262247.AA01960@Mordor.Stanford.EDU> To: Ross Callon Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: meta matters (forwarding in hardware, and protocol stability). Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 25 Jun 92 13:56:52 -0400. <9206251756.AA18483@easynet.crl.dec.com> Date: Fri, 26 Jun 92 15:47:09 -0700 From: Dave Crocker Ross, Thank you for re-sending this. I had wanted to comment/ask about one point: I think that this is an interesting question. My feeling it that IP has been stable for quite a while, and we are likely to find that CLNP will be stable for quite a while. If we come up with a new IP, then it will take a few years before it becomes stable, but once it does it too will remain stable (or be rejected in the market). How long do we think IP has been stable? It turns out that one can give honestly different answers. The base spec hasn't changed in a very long time. On the other hand, people got different implementations of some of the options and it was not until relatively recently that things stabilized. (TCP Urgent Pointer handling was another prize. I think we got stable, interoperable implementations universally somewhere around 1988 or 89.) Why did it take so long? Did IP have subtle basic problems? I don't think so. I think that relying on highly independent and distributed development and support groups (i.e., a competitive product environment) means that we need a production, multi-vendor environment operating for awhile, before interoperability can be highly stable. It simply takes time for the engineering, operations and support infrastructure to develop a common understanding of a technology. So, when we start looking at making changes to the Internet, I hope we constantly ask about the _real_ experience that is already widely available and the _real_ effort it will take to make each and every piece of every change we require. For example, references to the stability of CLNP leave me somewhat confused. While there certainly are some implementations and some people using them, I have no feel for the scale of the usage or -- more importantly -- the amount of multi-vendor interoperability that is part of production-level usage. Since we have recently been hearing repeated reference to the reliance upon and the benefits of CLNP's installed base, I'd like to hear much more concrete information about the nature of the system-level shakeout that it has _already_ received. Discussion about deployment history, network configuration and operation experience, and assorted user-level items would also seem appropriate to flesh out the assertion that CLNP has a stable installed base upon which the Internet can rely. Dave From owner-Big-Internet@munnari.oz.au Sat Jun 27 11:47:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10532; Sat, 27 Jun 1992 11:47:34 +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 AA10529; Sat, 27 Jun 1992 11:47:24 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA07831); Fri, 26 Jun 92 20:47:17 CDT Received: by san-miguel.is.rice.edu (AA09514); Fri, 26 Jun 92 20:47:15 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9206270147.AA09514@san-miguel.is.rice.edu> Subject: Re: Mobile Hosts and IDs To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 26 Jun 92 20:47:14 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9206261937.AA08754@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 26, 92 3:37 pm X-Mailer: ELM [version 2.3 PL11] Noel, What happens when BOTH (or n) hosts are mobil? In all three of your basic starting points, you assume (at least you state overtly in one and three) one end is a static host. -- 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 Sat Jun 27 12:07:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11017; Sat, 27 Jun 1992 12:07:08 +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 AA09401; Sat, 27 Jun 1992 11:02:04 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA02953; Fri, 26 Jun 92 18:01:12 PDT Message-Id: <9206270101.AA02953@Mordor.Stanford.EDU> To: Jon Crowcroft Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: Para Meta Matters... Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 26 Jun 92 12:13:10 +0100. <9206261114.18131@munnari.oz.au> Date: Fri, 26 Jun 92 18:01:11 -0700 From: Dave Crocker Jon, This could get interesting, but might get childish... EIP & IPAE (which are very similar, but EIP is cleaner - both admit of minimal chages...) IPAE is better. No it isn't. Yes it is. no it isn't yes it is... Well! That was productive. I suggest that we try to refrain from sweeping and possibly simplistic assessments of other folks' work, given the lack of any existing discussion. When we've volleyed a few times, someone may be able to slam home a final assessment, but it strikes me as a bit early. For example: About 2 years ago, I thought that the approach that EIP is now proposing would do just fine. Add an IP option to specify some additional bits and you'd be done. Wrong! I was quickly informed that IP options kill router performance. Further, while they shouldn't, some systems roll over and die when they see an IP option they don't understand. You and I might bemoan such a state of affairs, but it represents reality. That is why I think that Bob Hinden's original attempt to encapsulate IP within IP is a fundamental win. Encapsulation buys the very basic benefit of hiding the upgrade from a substantial part of the existing infrastructure. Use of IP options does not. Further, the EIP proposal is a bit off the mark on some of its other assertions. It implies that only FTP needs to be modified. In fact, so do all other protocols that contain addressing information. (mo, I believe cites the various remote procedure call protocols.) By the way, some IP options currently specify IP addresses. How will they work for EIP? (No, IPAE doesn't cover that one, either. It came up during a design meeting we just had -- my point is that there is a great deal of ground to cover and we can't make informed choices about "superiority" until more of the covering is done.) On the other hand, I claim that any change to the address structure will require pretty much the same set of changes at the transport and application level, pretty much independent of the nature of the IP-level change. (The one exception is that any scheme, such as IPAE or EIP which specifies the new format to be a superset of the old format, with retention of the old-format semantics lets communication with the commonwealth continue unchanged _forever_. Big win.) Dave From owner-Big-Internet@munnari.oz.au Sat Jun 27 15:35:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15572; Sat, 27 Jun 1992 15:35:15 +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 AA15569; Sat, 27 Jun 1992 15:35:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11481; Sat, 27 Jun 92 01:33:30 -0400 Date: Sat, 27 Jun 92 01:33:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206270533.AA11481@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, dcrocker@mordor.stanford.edu Subject: Re: Para Meta Matters... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Dave, I always thought the biggest problem with this idea was not the router performance issue as much as it was the issue of 'where do the extra bits *come from*'? I.e., if you don't want to modify the hosts (which I think we'd all like to avoid as long as possible), you have the following problem: the hosts are emitting packets with only 32 bit 'names' in them, with every expectation that that is all the information the network needs to get the packet where the host wants it to go. There will come a day, no matter how well you use that 32-bit namespace, when 32 bits will not name everything in the universe. As far as I can see, you then have two awful choices: you can either modify the hosts to emit packets with longer 'names' in them, or make the 32 bit names non-globally unique, and do *something* on the boundaries of the local naming domains; i.e. NAT. Since the domain name is then the only globaly unique name, you more or less have to tie the routing and addressing system into the DNS, not a pleasant thought. The one exception is that any scheme .... which specifies the new format to be a superset of the old format, with retention of the old-format semantics lets communication with the commonwealth continue unchanged _forever_. By new format, you mean the new format for addresses, or packets? If the former, where do the extra bits come from if you want to talk to something which cannot be named in the smaller address, or do you just say 'that doesn't work' (like a short leader host trying to get to a long leader IMP). If the latter, if you are prepared to take the performance hit to have the first hop routers transmogrify packets from old to new format to allow backward compatability, don't you get the same thing? Noel From owner-Big-Internet@munnari.oz.au Sat Jun 27 15:37:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15626; Sat, 27 Jun 1992 15:37:41 +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 AA15622; Sat, 27 Jun 1992 15:37:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11503; Sat, 27 Jun 92 01:37:18 -0400 Date: Sat, 27 Jun 92 01:37:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206270537.AA11503@ginger.lcs.mit.edu> To: bmanning@is.rice.edu, jnc@ginger.lcs.mit.edu Subject: Re: Mobile Hosts and IDs Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu What happens when BOTH (or n) hosts are mobil[e]? Oh, I was just assuming one end was static for ease of discourse. I'd have to think a bit, but my assumption is that any reasonable mechanism that allows one end to be mobile should allow both ends to be mobile. (Of course, there are always unreasonable things in the world, but I'll bet you'd have to work at it to find a solution that only works with one end mobile.) Noel From owner-Big-Internet@munnari.oz.au Sat Jun 27 20:08:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20035; Sat, 27 Jun 1992 20:08:51 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20032; Sat, 27 Jun 1992 20:08:47 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA03653 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 27 Jun 1992 20:08:44 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA09939; Sat, 27 Jun 92 20:08:43 EST Message-Id: <9206271008.AA09939@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Mobile Hosts and IDs In-Reply-To: Your message of "Fri, 26 Jun 92 15:37:14 -0400." <9206261937.AA08754@ginger.lcs.mit.edu> Date: Sat, 27 Jun 92 20:08:42 +1000 From: Bob Smart > However, it's a general principle of system design that the further >you drag a mechanism from the purpose for which it was originally intended, >the less well it functions in its new use. > Addresses are names which are used by the routing, primarily to >identify network attachment points. To use them to name something else (like >hosts) will work, but the mechanism required to make them work in this new >application will not be as clean as the mechanism you could have had if >you had picked some more appropriate name. OK, my idea of using addresses as IDs was not good. It doesn't hurt to specify what we want from an ID: 1. It is unique. 2. It never has to change. 3. We would like it to be not too big. An address is a poor choice because it fails (2) [particularly if we are going to change things around at the top!]. We already have something unique for each end-system: the domain name. Unfortunately it fails (3). Here is a plan to generate a unique compact number from the domain name. It has an immediate advantage that it will be easy for network managers to run a simple program and generate all the forward and reverse ID<-->name zone file entries from the current zone files. It also means that Network Managers will not have to go to anyone else to generate the IDs for their machines in the future. Another advantage is political. I suspect there will be resistance to introducing a 3rd end-system denotation, but this method can be regarded as just an encoding of one of the existing two. That may be easier to sell. [Meanwhile those of you who want the ID to be unique and meaningless are welcome to ignore the algorithm and regard the result as just a unique heap of bits]. The idea is to give each component a number within its parent. For example the domain dit.csiro.au has 3 entries: syd, csis and mel; these would get numbers 1, 2 and 3. So here are possible, but worst case, numberings for the components of wanda.mel.dit.csiro.au: au csiro dit mel wanda 120 9 30 3 85 We now need some way to encode this sequence of numbers. A simple way to encode variable length numbers is with base-3 (ternary?) digits. So a number is represented as a sequence of 2-bit mini-nibbles: 00, 01 and 10 are base 3 digits, 11 is end-of-number. So the number of bits needed to represent different sized numbers is given in the following table: bits range 4 1-2 6 3-8 8 9-26 10 27-80 12 81-242 14 243-lots Example component: au. csiro. dit. mel. wanda index: 120 9 30 3 85 # of bits: 12+ 8+ 10+ 6+ 12 +2 for end of domain A number starting with an end-of-number marker (11) is 0. This is the 2 extra bits that marks end-of-domain. So we have 50 bits in all. In real life the component numbers would not be the worst possible, and the size would be 6-8 bits shorter. While I would favour a variable length ID, you can make this fixed length by padding it to 64 or 96 bits. Does anybody have a suggestion for a potential worst case in the current Internet: a domain name with a lot of components where most of the components have a lot of entries (giving a potentially large component index). Even so it is hard to imagine getting to 64 bits. With 6 levels you only have 14 wasted bits [end-of-something markers] leaving 40 bits which are 3/4 working. That's a lot of domains. Another screwy idea from the keyboard of Bob Smart. From owner-Big-Internet@munnari.oz.au Sat Jun 27 20:50:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20625; Sat, 27 Jun 1992 20:50:12 +1000 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20622; Sat, 27 Jun 1992 20:50:08 +1000 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA22683; Sat, 27 Jun 92 20:49:42 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9206271049.AA22683@coombs.anu.edu.au> Subject: Re: Thoughts on PIP and ARP and ... To: Garrett.Wollman@UVM.EDU Date: Sat, 27 Jun 92 20:49:41 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9206261713.AA01157@sadye.uvm.edu>; from "Garrett.Wollman@UVM.EDU" at Jun 26, 92 1:13 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Garrett.Wollman@UVM.EDU, they wrote: > [...] > - In order to prevent this configuration from getting stale, there > needs to be a way (through PIP's equivalent of ICMP, perhaps?) to > inform hosts that they should re-configure themselves. Perhaps the > existing control messages listed in Paul's proposal would be fine > (i.e., when a host receives PCMP x, y, or z, it must do a > re-configure). How much do you propose to allow for dynamic reconfiguration ? If, for example, you allow the host address to be changed, what happens to name servers which have a temporary cacha of such numbers ? And what for other, similar services or programs which use their own private cache ? Giving a new control protocol that sort of `power' over a subnet could be extremely danergous if `believable' fakes could be produced. ICMP is already faked to produce nasty situations, if a new Control Message Protocol is designed to go hand in hand with a new IP, careful consideration to this side would not be unwise. Darren. From owner-Big-Internet@munnari.oz.au Sat Jun 27 21:46:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21482; Sat, 27 Jun 1992 21:46:15 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21479; Sat, 27 Jun 1992 21:46:13 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA03973 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 27 Jun 1992 21:46:12 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA10116; Sat, 27 Jun 92 21:46:11 EST Message-Id: <9206271146.AA10116@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Para Meta Matters... In-Reply-To: Your message of "Fri, 26 Jun 92 18:01:11 MST." <9206270101.AA02953@Mordor.Stanford.EDU> Date: Sat, 27 Jun 92 21:46:11 +1000 From: Bob Smart >I was quickly informed that IP options kill router performance. Further, >while they shouldn't, some systems roll over and die when they see an >IP option they don't understand. Are we sure these concerns are still current? Any chance of shooting some EIP packets at a few routers and hosts and seeing what happens? I am very concerned about the potential fragmentation of the Internet implicit in IPAE. I'll bet America will be a Commonwealth, Europe will be another. We'll be allowed to talk old IP to New Zealand and to ourself, and we'll have to wait for IPAE implementations everywhere before we can get back to global connectivity. Network connectivity means more to us precisely because we are a long way for travel. Bob Smart From owner-Big-Internet@munnari.oz.au Sun Jun 28 03:23:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27436; Sun, 28 Jun 1992 03:23:38 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27433; Sun, 28 Jun 1992 03:23:28 +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 AA21765; Sat, 27 Jun 92 10:23:14 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA04599; Sat, 27 Jun 92 10:23:16 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA15865; Sat, 27 Jun 92 10:22:55 PDT Date: Sat, 27 Jun 92 10:22:55 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9206271722.AA15865@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA16350; Sat, 27 Jun 92 10:23:10 PDT To: Bob Smart Cc: big-internet@munnari.oz.au In-Reply-To: <9206271146.AA10116@wanda.mel.dit.CSIRO.AU> Subject: Re: Para Meta Matters... Bob, Firstly, I think the major decision the internet will need to make soon is to select one of three types of schemes: 1) An extension to IP (like IPAE or EIP), deploying a CLNP internet infrastructure and converting the hosts to use, or developing a new long term architecture (like Nimrod, PIP, etc.). I happen to think we need a solution which will keep the internet going (for a long time) until the long term solutions (and we understand what the requirements for them are) are clearer. There are many issues which need to be addressed in any new architecture (mobility, guarantees of service, security, policy, etc.) that I don't believe we have a good handle on today. > Are we sure these concerns are still current? Any chance of shooting > some EIP packets at a few routers and hosts and seeing what happens? I think they are still current. This is the major reason why IPAE choose to not use the options field. We wanted to minimize the impact of existing implementations (and in fact zero impact on interior routers and hosts in the first phase of deployment). But again the big decision to make is whether we choose to incrementally extend IP to support larger addresses and build upon the existing infrastructure or switch to a new infrastructure (CLNP, etc.). > I am very concerned about the potential fragmentation of the Internet > implicit in IPAE. I'll bet America will be a Commonwealth, Europe > will be another. We'll be allowed to talk old IP to New Zealand and > to ourself, and we'll have to wait for IPAE implementations everywhere > before we can get back to global connectivity. Network connectivity > means more to us precisely because we are a long way for travel. By the time that we run out of IP addresses (millions of networks) there will be many commonwealths. North America, South America, Australia, Europe, Asia, Africa each will have many commonwealths. Maybe Antarctica will only have one :-) Even if it was desirable (which it isn't!) there would be too many networks to route in a single commonwealths if they were orginizied around continents. Also, it is not until the time when 32-bit IP addresses run out that 32-IP addresses won't be globally unique. > to ourself, and we'll have to wait for IPAE implementations everywhere > before we can get back to global connectivity. Network connectivity > means more to us precisely because we are a long way for travel. In fact, it this was one of the concerns that lead us to develop IPAE in the first place. IMHO I don't think we can deploy CLNP fast enough to keep the internet from fragmenting into islands of IP. Bob From owner-Big-Internet@munnari.oz.au Sun Jun 28 04:55:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28653; Sun, 28 Jun 1992 04:55:56 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206271855.28653@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28650; Sun, 28 Jun 1992 04:55:47 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 27 Jun 1992 19:54:14 +0100 To: Garrett.Wollman@UVM.EDU Cc: big-internet@munnari.oz.au Subject: Re: Thoughts on PIP and ARP and ... In-Reply-To: Your message of "Fri, 26 Jun 92 13:13:03 EDT." <9206261713.AA01157@sadye.uvm.edu> Date: Sat, 27 Jun 92 19:54:05 +0100 From: Paul Tsuchiya Let me comment on Garrett's last comment first....... > > PS: Let's have Paul to the address and packet format, Noel do the > routing, and Ross do the transition plan... This is the best friggin idea I've seen in a long time. Really people, we probably agree on much more than we disagree on, and we've got to get some synergy going at some point. I know its still a bit premature for a lot of folks to jump on the Pip bandwagon, but really I hope that especially those folks with a vested ($$) interest in CLNP think hard about long term growth in this market and what CLNP can and cannot do compared to Pip. > > After having read the PIP document, I think I've pretty much got it > figured out, and that has led me to some thoughts... > > - PIP leaves a lot of configuration choices to the local installation. > There should be some sort of protocol for obtaining information about > these configuration choices from adjacent routers. This would also > tell a system the MAC layer address of all the routers near it, and > could also be used to tell a host what *its* address is. (Doesn't the > IANA have a multicast 802 address assigned to it which means `to all > routers'? If not, it should.) Yes. But in any event, there must be a mode of operation where a host can be completey dumb and be spoon-fed the Pip packet format, as a result of a domain query. This way, when you go to make real changes in the routing architecture, you can more easily bring old hosts along with you. So, for what I'm calling "basic" Pip (the minimum amount of stuff you need to do to current protocols to get Pip working), we will probably operate in dumb-host mode. > .....comments on host configuration left out...... I generally agree with your comments on host configuration. > > - I don't think that PIP's enormous flexibility in address-component > lengths is all that useful. I would probably prefer to implement a > scheme where RHF+RFHR is an even multiple of 8 bits, which would mean > only using RHF-length values of 3, 9, and 13. I'm certainly willing to discuss this, and I've waffled a bit on it myself. This detail doesn't change the fundamental notion of "addresses as source routes". I'm assuming that many many details will be worked out between boston and dc ietfs. Hopefully much of this working out will be done by a few interested folks willing to read the enormous amount of paper I intend to produce. > > - For name service: I think we want to be able to do the following: > > EPID -> name > Address -> name > name -> ( EPID, Address ) First one is tough, since EPID is purely flat field. Second one should return EPID as well as name. If nothing else, this would be one way that a host could check the validity of a received packet. PT From owner-Big-Internet@munnari.oz.au Sun Jun 28 05:01:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28719; Sun, 28 Jun 1992 05:01:42 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206271901.28719@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28716; Sun, 28 Jun 1992 05:01:36 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 27 Jun 1992 20:01:17 +0100 To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358" Cc: big-internet@munnari.oz.au Subject: Re: meta matters ... In-Reply-To: Your message of "Thu, 25 Jun 92 18:20:57 EDT." <9206252220.AA00742@us1rmc.bb.dec.com> Date: Sat, 27 Jun 92 20:01:08 +0100 From: Paul Tsuchiya > > > === I'd like to give a pitch for minimizing state in routers and other > intermediate systems and putting as much of the burden as is reasonable on the > end systems. One of the important factors in the early success of IP was that > you could take a pretty lame machine and have it do useful routing with the > simple class based addresses. I generally agree on this. The large majority of traffic should suffice with full addressing information in the packet. I think architectures/protocols that don't really do a good job with addressing won't serve well in the long run. > > === On "stability" and the like, every comment I have seen so far on how long > IP4 will continue to be used has been a *gross* underestimate. I can remember > from the early ARPANET days when there were only hundreds of hosts and they > were all US military or DoD contractors and directives would come down to > switch to some new protocol by some deadline and nothing would happen. And > new deadlines would be set and new edicts would come down and still nothing > would happen. Changes universally considered improvements scheduled to be > deployed in months would take years. Good point. It is probably wise to design "as though" we'll have IP forever, and hope that we don't. > > === In a telepone conversation with Ross Callon, I mentioned that when I was > still thinking of fixed length addresses, I came up with a scheme for > subdividing 64 bits into various length hierarchial subfields. He was > interested in seeing the details so I'll try to post it here soon on the theory > that others might be interested. > Yes please. PT From owner-Big-Internet@munnari.oz.au Sun Jun 28 05:18:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28931; Sun, 28 Jun 1992 05:18:22 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206271918.28931@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28928; Sun, 28 Jun 1992 05:18:16 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 27 Jun 1992 20:17:52 +0100 To: avri@asherah.clearpoint.com (Avri Doria) Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of "Fri, 26 Jun 92 13:56:12 EDT." <9206261756.AA15071@asherah.clearpoint.com> Date: Sat, 27 Jun 92 20:17:44 +0100 From: Paul Tsuchiya > > I don't quite understand the great need for long term protocol > stability in terms of making hardware implementations. Many of the > current router companies distribute their router code in EPROMS. It > isn't that much greater a chore to change a socketed FPGA than it is > to change socketed EPROMS. Nor is it really that great a chore to > reprogram an FPGA. Going to an ASIC is perhaps a bit more time > consuming but still not a herculean task. > But how fast does this stuff go? Fast enough? But probably I have emphasized the hardware point too much. Still, hardware stability or not, we need to be able to evolve our routing architectures with a minimum of changes all around. PT From owner-Big-Internet@munnari.oz.au Sun Jun 28 09:26:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02571; Sun, 28 Jun 1992 09:26:28 +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 AA02568; Sun, 28 Jun 1992 09:26:19 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA02983); Sat, 27 Jun 92 18:26:14 CDT Received: by san-miguel.is.rice.edu (AA10253); Sat, 27 Jun 92 18:26:13 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9206272326.AA10253@san-miguel.is.rice.edu> Subject: Re: Para Meta Matters... To: Bob.Hinden@eng.sun.com (Bob Hinden) Date: Sat, 27 Jun 92 18:26:12 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9206271722.AA15865@b5mail.Eng.Sun.COM>; from "Bob Hinden" at Jun 27, 92 10:22 am X-Mailer: ELM [version 2.3 PL11] Bob Hinden > > IPAE or EIP), deploying a CLNP internet infrastructure and converting the > > addresses and build upon the existing infrastructure or switch to a new > infrastructure (CLNP, etc.). > > In fact, it this was one of the concerns that lead us to develop IPAE in > the first place. IMHO I don't think we can deploy CLNP fast enough to > keep the internet from fragmenting into islands of IP. > > Bob > Pardon me, but I understood that there exists a CLNP infrastructure that currently overlays the existing IP base. Not as large I grant you, but its there. Switching to a new infrastructure (of any type) will require some change in host applications eventually. (I know this one is central to the topic under discussion and I am showing bias) What I am not clear on is what it takes to "deploy" CLNP. Can you elaborate just a bit here? -- 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 Sun Jun 28 10:24:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03350; Sun, 28 Jun 1992 10:24:52 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03340; Sun, 28 Jun 1992 10:24:43 +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 AA28678; Sat, 27 Jun 92 17:24:36 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA06846; Sat, 27 Jun 92 17:24:41 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA17033; Sat, 27 Jun 92 17:24:17 PDT Date: Sat, 27 Jun 92 17:24:17 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9206280024.AA17033@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA17250; Sat, 27 Jun 92 17:24:31 PDT To: bmanning@is.rice.edu (William Manning) Cc: Bob.Hinden@Eng.Sun.COM (Bob Hinden), big-internet@munnari.oz.au In-Reply-To: <9206272326.AA10253@san-miguel.is.rice.edu> Subject: Re: Para Meta Matters... Bill, > Pardon me, but I understood that there exists a CLNP infrastructure that > currently overlays the existing IP base. Not as large I grant you, but its > there. There does exist some pieces of an CLNP infrastructure, but not only is it much smaller than the IP infrastructure (by several orders of magnitude), but important pieces of that infrastructure are not deployed. For example the CLNP routing protocols IS-IS and IDRP are not widely deployed. ISIS (Intra-Domain routing protocol) is starting to become available from vendors, but IDRP (the ISO inter-domain routing protocol) is just coming out of ANSI. As far as I know there aren't any implementations yet. I believe that CLNP represents a good architecture. My concern is that the products that implement it are too far away for CLNP to be deployed fast enough to keep the current TCP/IP based internet from breaking. I just think there is too much to do. > change in host applications eventually. (I know this one is central to the > topic under discussion and I am showing bias) What I am not clear on is > what it takes to "deploy" CLNP. Can you elaborate just a bit here? A list would include: CLNP in all hosts and routers, IS-IS in interior routers, IDRP in border routers, significant network management changes (use SNMP to manage ISO?), ES-IS (ISO version of ARP) in hosts and interior routers, DNS changes, an agreement on format and content of NSAP addresses, documentation updates, and a lot of training of people. There is also capabilities missing in CLNP that exist in IP, such as Multicast that would have to be added. Bob From owner-Big-Internet@munnari.oz.au Sun Jun 28 10:44:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03653; Sun, 28 Jun 1992 10:44:47 +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 AA03647; Sun, 28 Jun 1992 10:44:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15044; Sat, 27 Jun 92 20:44:10 -0400 Date: Sat, 27 Jun 92 20:44:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206280044.AA15044@ginger.lcs.mit.edu> To: Garrett.Wollman@uvm.edu, P.Tsuchiya@cs.ucl.ac.uk Subject: Re: Thoughts on PIP and ARP and ... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > EPID -> name First one is tough, since EPID is purely flat field. Urrr, Zheng made the same claim. I don't think it's that hard. I sent him (and the list) a detailed reply (Date: Tue, 23 Jun 92 13:54:59 -0400, Subject: Re: network number and addresses) doing some numerical analysis which I believe showed that this is not necessarily so. (I can resend if you can't locate a copy.) I also sent another message (Date: Thu, 25 Jun 92 01:26:00 -0400, Subject: re: network number and addresses (ID to ... mapping)) about an issue that Ross raised about this mapping, which deals with the hardest problem I can see with doing this mapping. Of course, it is true that if we allocated ID's scattered through the number space (i.e. no two ID's are within say 2^16 of each other), then yes, it could produce a very large tree of servers very quickly, but I assume we won't be this silly! Noel From owner-Big-Internet@munnari.oz.au Sun Jun 28 10:49:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03726; Sun, 28 Jun 1992 10:49:37 +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 AA03723; Sun, 28 Jun 1992 10:49:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15077; Sat, 27 Jun 92 20:49:13 -0400 Date: Sat, 27 Jun 92 20:49:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206280049.AA15077@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, avri@asherah.clearpoint.com Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu we need to be able to evolve our routing architectures with a minimum of changes all around. No, we need a routing architecture in which we can incrementally deploy (i.e. with no large-scale coordination, in fact, preferably no coordination at all) new (and better :-) algorithms for all the important (and hard) components of the architecture (e.g. route creation, abstraction, etc, etc). I simply do not believe that you can deploy a new routing architecture (i.e. change your basic paradigms or models of how the world works) in a system the size the Internet is going to be in 10 years. Noel From owner-Big-Internet@munnari.oz.au Sun Jun 28 12:09:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04776; Sun, 28 Jun 1992 12:09:06 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04769; Sun, 28 Jun 1992 12:09:00 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA11781 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sat, 27 Jun 1992 22:08:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 27 Jun 1992 22:08:38 -0400 Message-Id: <199206280208.AA34062@home.ans.net> To: Dave Crocker Cc: Jon Crowcroft , jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au, wilder@ans.net, enger@ans.net Subject: Re: Para Meta Matters... In-Reply-To: (Your message of Fri, 26 Jun 92 18:01:11 MST.) <9206270101.AA02953@Mordor.Stanford.EDU> Date: Sat, 27 Jun 92 22:08:38 -0500 From: Phill Gross I was quickly informed that IP options kill router performance. Question -- is there any reason why modern routers couldn't put option processing in the microcode of their smart interface cards? Would that help? Phill P.S. BTW, Dave, speaking of being childish, or at least adolescent, I object to your use of the phrase "Wrong!", when in fact you would have been more fashionable to say "Not!". :-) From owner-Big-Internet@munnari.oz.au Sun Jun 28 14:48:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07552; Sun, 28 Jun 1992 14:48:24 +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 AA07549; Sun, 28 Jun 1992 14:48:19 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA04629); Sat, 27 Jun 92 23:48:12 CDT Received: by san-miguel.is.rice.edu (AA10332); Sat, 27 Jun 92 23:48:10 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9206280448.AA10332@san-miguel.is.rice.edu> Subject: Re: Para Meta Matters... To: Bob.Hinden@eng.sun.com (Bob Hinden) Date: Sat, 27 Jun 92 23:48:09 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9206280024.AA17033@b5mail.Eng.Sun.COM>; from "Bob Hinden" at Jun 27, 92 5:24 pm X-Mailer: ELM [version 2.3 PL11] Bob Hinden > >> topic under discussion and I am showing bias) What I am not clear on is >> what it takes to "deploy" CLNP. Can you elaborate just a bit here? > > A list would include: CLNP in all hosts and routers, IS-IS in interior > routers, IDRP in border routers, significant network management changes > (use SNMP to manage ISO?), ES-IS (ISO version of ARP) in hosts and > interior routers, DNS changes, an agreement on format and content of NSAP > addresses, documentation updates, and a lot of training of people. There > is also capabilities missing in CLNP that exist in IP, such as Multicast > that would have to be added. > Thanks. Just for the record, most vendors either have are will have (RSN) CLNP, ISIS, ESIS support for their products. IDRP is coming, although I agree with you that it is slower than I would like. I am working on DNS changes for just such use, and there are pieces of the managment puzzle being discussed. In theory, the new BSD should have CLNP and ESIS in the host code. The hard parts, documentation, training and extentions still need to be done. At least I think that this stuff is further along than some of the other proposals that are being discussed in this forum. (Good reading too...) IMHO, if time is of the essence, then I would/will back the lead horse, CLNP. (I reserve the right to change my opinion at any time...:-) -- 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 Sun Jun 28 14:53:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07635; Sun, 28 Jun 1992 14:53:14 +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 AA07629; Sun, 28 Jun 1992 14:53:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15791; Sun, 28 Jun 92 00:52:54 -0400 Date: Sun, 28 Jun 92 00:52:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206280452.AA15791@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, bmanning@is.rice.edu Subject: Re: Para Meta Matters... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I'd like to second what Bob said, and more. While I think the latest go-round of CLNP conversion (TUBA, which includes identifiers in all packets, with support for only GOSIP addresses) is a considerable improvement on early work, that still doesn't mean I think it is the way to go. In fact, I think a conversion to CLNP is definitely a bad idea, and will most strongly oppose, in this group, in the IETF, and in the IESG, any such proposal. Don't assume from this that that I think that IP is great. It's not. It's horribly wrong in many basic areas, lacking entirely in others, and in general utterly obsolete. If it weren't for the fact that we have a large, deployed, operational, base using it, I'd completely discard it instantly. My reasons for opposing CLNP follow. First, and most important, I think CLNP is not a long term solution. (Even some CLNP supporters have been heard to agree with that.) If it's not that, why are we doing it? It will be a tremendous amount of work to convert to it, and why, if we are going to have to supersede it down the road? Why is it not a long term solution? There are a number of reasons. When an effort to define a new packet format (IP-7) was originally proposed, almost 2 years ago, a number of people, principally Van Jacobsen, felt this was a bad idea. Their argument was that coming changes in the data infrastructure (e.g. ATM) mean that the world of data will look very different in 10 years, and they felt that any network layer designed now will be wrong in 10 years. Also, a key component of an advanced network layer, namely resource allocation, is still very much a research area. They thought the best approach was to put off any change as long as possible, until of vision of the future of the data communication system was clearer. These arguments made sense to me, and I changed my original plan (as Internet AD) to create such an effort, giving the reason. In the IESG "Internet Evolution Plan for the IETF" of July 1991, (available as an I-D, 'draft-ietf-iesg-evolutionplan-00.txt'), I indicated just this (in section 6.2.4). This plan was presented to the IETF both electronically, as an I-D, an in person at an IETF plenary. There was no major dispute with this observation. Looked at from this point of view, CLNP is no better than IP. For instance, it too predates the modern work on resource allocation, and has no provision for this. If a design that we could do today will be obsolete, how can OSI, which is almost 10 years old at this point, be any better? The OSI architecture (like IP) gives no thought to security. A truism in OS design is that if you don't design security in from the start, you'll never get it right. We are starting to learn the hard way in the Internet that the same is true of networks. The IP protocol suite has more holes than Swiss cheese, and we'll probably *never* secure it completely. A global network without first rate security is such a non-starter words fail me. It is incomprehensible to me that we recommend (or that the user community accept) such a thing. OSI (like IP) was not designed for 'plug and play' operation. Sure, we can improve things, but the network of the future has to work without a CS PhD to configure every router. Like security, if you don't think about this up front, it will always be shoddy and second rate. Again, the users will simply not stand for this. I also maintain that the addresses in OSI (as addresses) are too small. We've been over this ground, so I won't belabour it again, but I cannot believe that 9 bytes is a long enough address for reasonably small fan out needed to keep routing reasonably cheap in a global network. I also think the OSI routing architecture is utterly wrong. Again, we can't hash this out here, but a map based system is the way to go. Routing tables are obsolete; caches are the future of routing. (If you think this is wrong, what do you do to route yourself when you get into a car to drive a long way? Get out your giant list of what turn to take for every possible destination at each intersection, or look at the map. Maybe there's a reason we use maps for this?) I could go on, but it's pointless. If you aren't dubious (if not convinced) by now, nothing will faze you. The OSI architecture, well meant and reasonably competent though it may be, is simply not the wave of the future. It simply makes no sense to convert to something that is a giant leap sideways. Second, Bob's list of missing piece is almost certainly incomplete. We won't know until we actually try and make it work everything that is missing. There's *always* something missing; the best designers in the world miss things, and the Simple CLNP design has not even been fully worked out yet. Again, I could go on, but it's already pointless. A conversion of a large, deployed system which hundreds of thousands of people depend upon, a conversion of an unknown but certainly enormous magnitude, to a network protocol which does not (and cannot) have the capabilities the world will need in a decade or so, is clearly just not the right thing. Noel From owner-Big-Internet@munnari.oz.au Sun Jun 28 16:36:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09127; Sun, 28 Jun 1992 16:36:47 +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 AA09124; Sun, 28 Jun 1992 16:36:37 +1000 (from kre) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: meta matters In-Reply-To: Your message of Fri, 26 Jun 92 14:39:31 -0400. <9206261839.AA08070@ginger.lcs.mit.edu> Date: Sun, 28 Jun 92 16:36:28 +1000 Message-Id: <16848.709713388@munnari.oz.au> From: Robert Elz Date: Fri, 26 Jun 92 14:39:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9206261839.AA08070@ginger.lcs.mit.edu> However, just because it's not used by the intermediate switches does not mean it is not used at the endpoints. That's true, not sure that its relevant though. Note that my message was certainly not intended to suggest that separating ID's from addresses is a poor idea, or that ID's shouldn't exist, or anything like that. The switches don't use the 'protocol' field in most cases, Noel ... really! The receiver can't intuit the protocol used (as it can its own ID), nor does it need to trust it for anything - if the packet is sent to the wrong protocol stack, then the sender loses, big deal. I don't doubt that there are lots of reasons why one might want to demand that the ID be there, I just want consideration given to whether having the ID there necessarily provides useful information - does it make sense to rely on it providing the information it seems to provide. kre From owner-Big-Internet@munnari.oz.au Mon Jun 29 04:25:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19308; Mon, 29 Jun 1992 04:25:30 +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 AA19303; Mon, 29 Jun 1992 04:25:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17949; Sun, 28 Jun 92 14:25:19 -0400 Date: Sun, 28 Jun 92 14:25:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206281825.AA17949@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.oz.au Subject: Re: meta matters Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu >However, just because it's not used by the intermediate >switches does not mean it is not used at the endpoints. That's true, not sure that its relevant though. Huh? I thought your message was an analysis of why in certain hypothetical circumstances ID's were not needed in the network header. I was pointing out what I perceived as a flaw in that analysis. (If I misunderstood what you were saying, sorry! :-) You seemed to be assuming that if the routers didn't use the field, it shouldn't be there. I was saying that there are fields in that header that have to be there because the hosts use them, even though the routers don't. The 'protocol' field is an example of this kind of field. Note that my message was certainly not intended to suggest that separating ID's from addresses is a poor idea, or that ID's shouldn't exist, or anything like that. Understood. Noel From owner-Big-Internet@munnari.oz.au Mon Jun 29 04:55:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19822; Mon, 29 Jun 1992 04:56:09 +1000 (from owner-Big-Internet) Return-Path: Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19803; Mon, 29 Jun 1992 04:55:59 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for Big-Internet@munnari.oz.au id AA25183; Sun, 28 Jun 92 11:55:45 -0700 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.oz.au id AA26068; Sun, 28 Jun 92 12:55:41 -0600 Date: Sun, 28 Jun 92 12:55:41 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9206281855.AA26068@rhyolite.wpd.sgi.com> To: Big-Internet@munnari.oz.au Subject: Re: Para Meta Matters... bmanning@is.rice.edu (William Manning) writes: > > A list would include: CLNP in all hosts and routers,.... > Thanks. Just for the record, most vendors either have are will have (RSN) > CLNP, ISIS, ESIS support for their products.... > ... > In theory, the new BSD should have CLNP and ESIS in the host code. Depending on what you mean by RealSoonNow and InTheory, I think this may be a little optimistic. Maybe in another 5 years, CLNP and ES-IS will have made significant progress. Compare the availability of TCP/IP now and as it was at the first InterOP in 1986. The popularity of OSI implementations has a ways to go to reach TCP as it was in 1986. The end of the BSD--CSRG saga is being watched closely, at least on the left coast. It does not seem prudent to count on much in 4.4BSD. Perhaps you are refering to the world-wide activity in 386bsd or BSDI. I wouldn't count on much there very soon, because I think there are many things that most people with PC-AT's will find more pressing or interesting than OSI. No one I've met seems interested in converting applications from TCP/IP, and without FTP et al, won't a pure CLNP Internet be less fun? Yes, we have an OSI product like everyone else, but practically no one seems to want it or use it, except on a GOSIP checklist. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.oz.au Mon Jun 29 05:07:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19985; Mon, 29 Jun 1992 05:07:13 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206281907.19985@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19982; Mon, 29 Jun 1992 05:07:08 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 28 Jun 1992 20:06:51 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Para Meta Matters... In-Reply-To: Your message of "Fri, 26 Jun 92 16:31:43 EDT." <9206262031.AA09189@ginger.lcs.mit.edu> Date: Sun, 28 Jun 92 20:06:32 +0100 From: Paul Tsuchiya > Well, yes, this is easy to agree with. However, I still don't think > I've seen a refutation of my claim that in the future, the Internet will be so > big that to even change the basic routing architecture will be impossible. I beg you pardon. I put out a message indicating that even the phone system (which is a hell of a lot bigger than the internet) continues to undergo significant routing architecture changes, some of them involving end system operation. And I think somebody else supported my point. So, you can disagree with me if you like, but you can't say that you haven't seen a refutation of your claim. PT From owner-Big-Internet@munnari.oz.au Mon Jun 29 05:24:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20282; Mon, 29 Jun 1992 05:24:52 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206281924.20282@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20279; Mon, 29 Jun 1992 05:24:48 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 28 Jun 1992 20:24:34 +0100 To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: meta matters (forwarding in hardware, and protocol stability). In-Reply-To: Your message of "Fri, 26 Jun 92 15:47:09 PDT." <9206262247.AA01960@Mordor.Stanford.EDU> Date: Sun, 28 Jun 92 20:24:21 +0100 From: Paul Tsuchiya > It turns out that one can give honestly different answers. The base > spec hasn't changed in a very long time. On the other hand, people > got different implementations of some of the options and it was not > until relatively recently that things stabilized. (TCP Urgent Pointer > handling was another prize. I think we got stable, interoperable > implementations universally somewhere around 1988 or 89.) I still don't see how you can say things have been stable that long. There are still algorithms and systems that don't do variable length subnets. When were variable length subnets finally decided on? Are they in the previous router requirements? And now, we are talking about CIDR. So things are STILL unstable. It would be an interesting exercise (though I'm not going to do it) to see what is different from the current router requirements from the previous one. All those differences (and there must be plenty) to me represent unstability (and progress, of course, but unstability just the same). PT From owner-Big-Internet@munnari.oz.au Mon Jun 29 05:31:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20451; Mon, 29 Jun 1992 05:31:34 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20447; Mon, 29 Jun 1992 05:31:21 +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 AA12859; Sun, 28 Jun 92 12:31:13 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA11593; Sun, 28 Jun 92 12:31:16 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA18711; Sun, 28 Jun 92 12:30:55 PDT Date: Sun, 28 Jun 92 12:30:54 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9206281930.AA18711@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA23616; Sun, 28 Jun 92 12:31:09 PDT To: bmanning@is.rice.edu (William Manning) Cc: Bob.Hinden@Eng.Sun.COM, big-internet@munnari.oz.au In-Reply-To: <9206280448.AA10332@san-miguel.is.rice.edu> Subject: Re: Para Meta Matters... Bill, > Thanks. Just for the record, most vendors either have are will have (RSN) > CLNP, ISIS, ESIS support for their products. IDRP is coming, although I agree > with you that it is slower than I would like. I am working on DNS changes > for just such use, and there are pieces of the managment puzzle being discussed. > In theory, the new BSD should have CLNP and ESIS in the host code. > The hard parts, documentation, training and extentions still need to be done. Yes, but note that currently a lot (most?) CLNP is supplied by vendors as a check-off item to satisfy procurement requirements. I believe there is very little operational usage between multiple vendors. Bob From owner-Big-Internet@munnari.oz.au Mon Jun 29 05:38:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20559; Mon, 29 Jun 1992 05:38:40 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206281938.20559@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20556; Mon, 29 Jun 1992 05:38:35 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 28 Jun 1992 20:38:15 +0100 To: avalon@coombs.anu.edu.au Cc: big-internet@munnari.oz.au Subject: Re: Thoughts on PIP and ARP and ... In-Reply-To: Your message of "Sat, 27 Jun 92 20:49:41 EST." <9206271049.AA22683@coombs.anu.edu.au> Date: Sun, 28 Jun 92 20:38:02 +0100 From: Paul Tsuchiya > > How much do you propose to allow for dynamic reconfiguration ? > If, for example, you allow the host address to be changed, what > happens to name servers which have a temporary cacha of such numbers ? > And what for other, similar services or programs which use their > own private cache ? In Pip, there is an error message that one host sends to another when the received ID is not that of the host. Therefore, when there are stale dns caches, this message is designed to flush the "on demand". > > Giving a new control protocol that sort of `power' over a subnet > could be extremely danergous if `believable' fakes could be > produced. ICMP is already faked to produce nasty situations, if > a new Control Message Protocol is designed to go hand in hand with > a new IP, careful consideration to this side would not be unwise. > Good point, and worth thinking about. PT From owner-Big-Internet@munnari.oz.au Mon Jun 29 06:11:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21000; Mon, 29 Jun 1992 06:12:15 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206282012.21000@munnari.oz.au> Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20995; Mon, 29 Jun 1992 06:11:59 +1000 (from kre) Date: Mon, 29 Jun 1992 06:11:59 +1000 From: Robert Elz To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: Para Meta Matters... Cc: big-internet@munnari.oz.au Date: Sun, 28 Jun 92 20:06:32 +0100 From: Paul Tsuchiya I put out a message indicating that even the phone system (which is a hell of a lot bigger than the internet) Is it really? Sure there are more phones, but the phone companies have done nothing to obsolete any phone (since they learned how to dial rather than just attract the attention of an operator). To see which is bigger in the impact sense, you want to consider how many different parties will be affected (with the phone system its just the phone companies, and there aren't many of those, even less than regional nets & their equivs I sspect, let alone everyone else that runs routers, etc), and how much equipment neds to be upgraded, which would count exchanges vs routers, or at the minute with proposed changes, exchanges vs hosts. I wouldn't care to guess which of exchanges and routers is the bigger number. I would estimate that the number of routers in the internet is about the total number of cisco+proteon+ wellfleet+...(similar) [in the internet] multiplied by about 10 to allow for all the multi-homed hosts, pcroute's, etc, that exist. kre From owner-Big-Internet@munnari.oz.au Mon Jun 29 07:50:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22467; Mon, 29 Jun 1992 07:50:58 +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 AA22464; Mon, 29 Jun 1992 07:50:54 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA09916; Sun, 28 Jun 92 14:50:43 PDT Message-Id: <9206282150.AA09916@Mordor.Stanford.EDU> To: Paul Tsuchiya Cc: big-internet@munnari.oz.au Subject: Re: meta matters (forwarding in hardware, and protocol stability). Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sun, 28 Jun 92 20:24:21 +0100. <9206281924.AA09502@Mordor.Stanford.EDU> Date: Sun, 28 Jun 92 14:50:42 -0700 From: Dave Crocker Paul, One could argue that the Internet Suite has never been stable, since we keep making upgrades. (This would be an interesting lin e of "criticism" to pursue, since the Suite sometimes is criticised for being archaic, since it has been around for so long. Can't win, with some folks I guess...) But CIDR is part of the very recent discussion in response to the current address space and routing crisis and hasn't fully hit the streets, yet. So one could argue that life is "stable" at this moment in time and has been for some period. In this context, the life I care about is of the production IP network. Further, base implementations of IP, as opposed to related protocols such as for routing, were the restricted scope of my comment. (I was trying to make that pointed, by referencing TCP as a different protocol that has had its own history of only-recent stability.) As to the question of variable length subnet masks, I thought that they were not fully ingratiated into the operational service. Is this wrong? Dave From owner-Big-Internet@munnari.oz.au Mon Jun 29 08:10:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22788; Mon, 29 Jun 1992 08:10:17 +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 AA22785; Mon, 29 Jun 1992 08:10:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18771; Sun, 28 Jun 92 18:09:48 -0400 Date: Sun, 28 Jun 92 18:09:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206282209.AA18771@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: Para Meta Matters... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Well, I guess this is just too subjective an area; we just seem to have different standards as to what constitutes a case. I think we'd better just leave it at that. Also, since you (I would assume) know a lot more about the phone system than I do, can answer an information query? In what cases is the routing between administrative domains (i.e. in the US, between IEC's, between RBOC's and IEC's, and between RBOC's/IEC's and customers; between PTT's elsewhere; etc, etc) anything other than static configuration? Also, I have heard that ATT Long Lines, for instance, does some dynamic routing internal to their system; if you know anything about it, can you explain a bit of how it works? Noel From owner-Big-Internet@munnari.oz.au Mon Jun 29 08:26:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23057; Mon, 29 Jun 1992 08:26:20 +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 AA23054; Mon, 29 Jun 1992 08:26:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18839; Sun, 28 Jun 92 18:25:57 -0400 Date: Sun, 28 Jun 92 18:25:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206282225.AA18839@ginger.lcs.mit.edu> To: P.Tsuchiya@cs.ucl.ac.uk, avalon@coombs.anu.edu.au Subject: Re: Thoughts on PIP and ARP and ... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > if a new Control Message Protocol is designed to go hand in hand with > a new IP, careful consideration to this side would not be unwise. Good point, and worth thinking about. *Any* place in the *entire* network architecture, be it in the low level control, name mapping system, routing, management, server access, etc, etc that a message coming in from the network can change any state, that entry point has to have provisions for authenticating and controlling the entry of these messages. This is (once again) basic OS security theory, applied to the network as if it were a giant distributed program. In a good dynamic network architecture (i.e. where state can be changed by means other than walking over to hardwired console and typing it in), there will be hundreds of these entry points. Access to each and every one has to be correctly validated if security breaches are not to occur. Making 99% of them secure is a waste of time if the other 1% are open; again, straight out of the OS security book. To make things worse, as I mentioned before, secure OS people have found that unless you start your design with securability in mind, it is almost impossible to reach this goal. Doing the checking on an ad-hoc basis, one at a time, almost never works; people make mistakes. You more or less have to have an underlying security architecture which makes it a matter of course that these things are secured. (E.g., the ring/gate structure in Multics.) Of course, in a network, the problem is far harder, since instead of securing a single implementation, we will have to secure many, many implementations. Noel From owner-Big-Internet@munnari.oz.au Mon Jun 29 15:21:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06568; Mon, 29 Jun 1992 15:21:43 +1000 (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 AA06565; Mon, 29 Jun 1992 15:21:41 +1000 (from kre) Received: from [128.173.4.1] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22849; Mon, 29 Jun 1992 08:15:25 +1000 (from VALDIS@vtvm1.cc.vt.edu) Return-Path: Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 2858; Sun, 28 Jun 92 18:14:09 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 8573; Sun, 28 Jun 92 18:14:09 EDT Date: Sun, 28 Jun 92 18:07:42 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Para Meta Matters... To: Robert Elz In-Reply-To: <9206282012.21000@munnari.oz.au> Message-Id: <920628.180742.EDT.VALDIS@vtvm1.cc.vt.edu> Resent-To: Big-Internet@munnari.oz.au Resent-Date: Mon, 29 Jun 92 15:21:32 +1000 Resent-Message-Id: <17420.709795292@munnari.oz.au> Resent-From: Robert Elz On Mon, 29 Jun 1992 06:11:59 +1000 you said: > Date: Sun, 28 Jun 92 20:06:32 +0100 > From: Paul Tsuchiya > > I put out a message indicating that even the phone system > (which is a hell of a lot bigger than the internet) > >Is it really? Sure there are more phones, but the phone companies have >done nothing to obsolete any phone (since they learned how to dial rather >than just attract the attention of an operator). mknod /dev/sarcasm c 4 0 They obsoleted Captain Crunch... ;) rm -rf /dev/sarcasm Seriously - is there anybody from AT&T on the list, who can comment on the expense of converting essentially the entire long-haul infrastructure from analog to digital, eliminating the use of in-band audio tones in favor of out-of-band digital routing signals, and all the associated stuff? Include in the discussion the several collapses of the long-haul network in the recent past due to programming errors, and the cost to end users when private CBX equipment had to be upgraded, and all other "secondary" effects of the upgrade. I suspect that once all the ancillary costs are included, the change from analog to digital long-haul was a *LOT* more expensive than we might at first guess... And I'm sure that the change *we* are designing won't be small change either, so let's make sure we get our money's worth.... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Mon Jun 29 16:59:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09496; Mon, 29 Jun 1992 16:59:26 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09490; Mon, 29 Jun 1992 16:59:18 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Sun, 28 Jun 92 23:59:02 -0700 Date: Sun, 28 Jun 92 23:59:02 -0700 From: Tony Li Message-Id: <9206290659.AA04028@cider.cisco.com> To: pgross@ans.net Cc: dcrocker@Mordor.Stanford.EDU, J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, wilder@ans.net, enger@ans.net In-Reply-To: Phill Gross's message of Sat, 27 Jun 92 22:08:38 -0500 <199206280208.AA34062@home.ans.net> Subject: Para Meta Matters... I was quickly informed that IP options kill router performance. Question -- is there any reason why modern routers couldn't put option processing in the microcode of their smart interface cards? Would that help? There is no conceptual problem with having IP options processed more quickly than they are now. There are, of course, implementation difficulties... ;-) As always, this is something of a chicken and egg problem. Parts of any protocol will not be heavily optimized by vendors unless there is a substantial need for performance enhancements in that part of the protocol. Nontrivial performance enhancement is only worth its cost if it is of significant benefit to most users. Users will not accept a protocol which does not perform reasonably. So use IP options if you must.... But consider just creating a new network layer instead. It might be faster and easier to implement. Tony From owner-Big-Internet@munnari.oz.au Mon Jun 29 17:39:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10280; Mon, 29 Jun 1992 17:40:03 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206290740.10280@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10272; Mon, 29 Jun 1992 17:39:56 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 29 Jun 1992 08:39:43 +0100 To: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Cc: big-internet@munnari.oz.au Subject: Re: Para Meta Matters... In-Reply-To: Your message of "Sat, 27 Jun 92 10:22:55 PDT." <9206271722.AA15865@b5mail.Eng.Sun.COM> Date: Mon, 29 Jun 92 08:39:30 +0100 From: Paul Tsuchiya > > Firstly, I think the major decision the internet will need to make soon > is to select one of three types of schemes: 1) An extension to IP (like > IPAE or EIP), deploying a CLNP internet infrastructure and converting the > hosts to use, or developing a new long term architecture (like Nimrod, > PIP, etc.). I happen to think we need a solution which will keep the Please don't classify Pip as a long term architecture with Nimrod. While Pip is designed to last over the long term, it is also meant to be installable in the short term, and evolvable to long term solutions. It is not a routing architecture per se, but a protocol format and set of forwarding rules and "ICMP" type messages that allow multiple routing architectures to run. At this point, I would be inclined to create four categories for the various solutions: 1. Don't solve long-term scaling, but buy us a few years time. CIDR, etc. 2. Can be installed relatively short term, solve long-term scaling, but don't buy us anything else (such as policy routing). CLNP IPAE EIP 3. Can be installed relatively short term (but not as short term as category 2), solve long-term scaling, and buy us evolution into more advanced routing architectures. Pip EIP (when used as a means to evolve Pip from current IP headers) 4. New routing architectures (cannot be installed long-term, because so much work to be done). Nimrod Unified In other words, Pip attempts to give us the benefits of both 2 and 4. PT From owner-Big-Internet@munnari.oz.au Mon Jun 29 18:50:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11899; Mon, 29 Jun 1992 18:50:40 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206290850.11899@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11893; Mon, 29 Jun 1992 18:50:34 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 29 Jun 1992 09:50:09 +0100 To: Phill Gross Cc: Dave Crocker , big-internet@munnari.oz.au, wilder@ans.net, enger@ans.net Subject: Re: Para Meta Matters... PIP, IPIP and PIPI In-Reply-To: Your message of "Sat, 27 Jun 92 22:08:38 CDT." <199206280208.AA34062@home.ans.net> Date: Mon, 29 Jun 92 09:49:55 +0100 From: Jon Crowcroft > I was quickly informed that IP options kill router performance. >Question -- is there any reason why modern routers couldn't put option >processing in the microcode of their smart interface cards? Would >that help? Phill good question those of us still doing work in the swamps & trenches are using loose source routing options to build multicast topologies for ietf (and other) audio casts... we do not find the rumoured "kill" to performance, but the packets do take some hit (earlier, BBN T20s did badly destroy performance, but that was an oldish release, ciscos and proteons dont seem to appaling) let me also point out that, contrary to what one would like, the point where these packets are most likely to be heading is on inter-national links, which are all 1 order of magnitude slower than local links (would that the opposite were afgfordably true) the UK_US main router is CPU bound on ROUTING CALCULATION not on FORWARDING! so i concurr with noel that the routing better be fixed up soon... anything a bit more in the forwarding path isn't so bad...in just the places it is needed... this leads to something Paul & I were just chatting over waiting for a local Bridge to reboot... Encapsulation versus Translation so's new artchitectures can still talk to old... -------------------------------- AT borders between new fangled PIP and outmoded IP-Classic bits of Internet, we need to build some box of some kind... the question is should the new addr info be munged into options so its semi-painlessley traverses routers (and even enters end systems) in the IP-classic net and admits of sort of half way house machines, or should we bite the bullet and build a translator... i favour the latter - 1. coz we will have spare cylces in the border routers 2. it creates momentum for the new fangled PIP 3. the munging to get pip ideas into options is horrible to contemplate... jon From owner-Big-Internet@munnari.oz.au Mon Jun 29 19:15:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12340; Mon, 29 Jun 1992 19:15:14 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206290915.12340@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12330; Mon, 29 Jun 1992 19:15:09 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 29 Jun 1992 10:14:55 +0100 To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: Para Meta Matters... In-Reply-To: Your message of "Fri, 26 Jun 92 18:01:11 PDT." <9206270101.AA02953@Mordor.Stanford.EDU> Date: Mon, 29 Jun 92 10:14:40 +0100 From: Zheng Wang >I was quickly informed that IP options kill router performance. Further, Note that the EIP field only APPEARS to be an IP option to IP hosts. But it is NOT an option in EIP packet header - its position in the EIP header is fixed (so it does not differ from other fields such as Host ID). >Further, the EIP proposal is a bit off the mark on some of its other >assertions. It implies that only FTP needs to be modified. In fact, >so do all other protocols that contain addressing information. (mo, No matter what schemes are used, all upper layer protocols/applications which have addresses have to modified, unless the translation service is provided permanently. During the transition period when IP addresses have not yet run out, there is no need to change any of the applications/protocols that encode address since the subnet routers can still route by treating the Host ID as an IP address. The border routers can translate/appand the Network ID. Cheers Zheng From owner-Big-Internet@munnari.oz.au Mon Jun 29 19:57:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13241; Mon, 29 Jun 1992 19:57:55 +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 AA13227; Mon, 29 Jun 1992 19:57:40 +1000 (from kre) To: Phill Gross Cc: big-internet@munnari.oz.au, road@lanl.gov, iesg@nri.reston.va.us, iab@isi.edu Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 17 Jun 92 18:00:05 -0500. <199206172200.AA25780@home.ans.net> Date: Mon, 29 Jun 92 19:57:31 +1000 Message-Id: <17496.709811851@munnari.oz.au> From: Robert Elz Date: Wed, 17 Jun 92 18:00:05 -0500 From: Phill Gross Message-ID: <199206172200.AA25780@home.ans.net> I've been meaning to reply to this for ages... Below is a draft IESG recommendation on how to follow-up the ROAD activities in the IETF. Please comment. With one exception below, I generally agree with all of this. The aim: "for making an IESG recommendation at the November 1992 IETF" is, as Bob Smart said, probably too quick to decide on a long term future architecture, but that's OK, if I'm right you'll discover that in October or November, and not be able to make a recommendation. If I'm wrong then that's great, and we'll be much further along than seems likely now. The one exceeption is ... The IESG accepted ROAD's endorsement of CIDR. The IESG felt that other alternatives (eg, C#, see Solen92) not did provide both aggregation and Class B conservation at comparable effort. which I think is a disaster. Not in endorsing CIDR, which is just fine, but in assuming that CIDR and C# are contradictory, or competing in some way. C# could be being put in place right now, if only we would agree to do it, and while it might not have huge long term benefits, there's no way that it can fail to help in the very short term, both in conserving class Bs, and in keeping the routing table sizes down. I'd liken the situation facing the internet now to someone staring down the barrel of a gun, with a finger pulling the trigger. Facing that, we could embrace an effort to cure the ills of society that would cause someone to want to shoot at us. This is undoutably a good idea (and is akin to Nimrod, etc) but if this is all we do, we'll be dead before it happens. Or, we could yell for the police to come and protect us, keep the gunman away. This is also a good idea, not quite as good overall, but probably worth attempting (stretching things, this might be EIP or IPAE), but again, its too late to just do this alone. We could also get out our bullet-proof jacket and put that on. This might help a bit, no guarantees, but its certainly better than doing nothing (this might be CIDR). Its going to take a little time to get right though, and we don't really have that time to wait. Or, we could just duck. This isn't guaranteed to help at all, and if it does help, probably won't help for long, but it might just buy us enough time to get to the more productive steps above. (This is C#). In case its not obvious, from this and previous messages, I feel strongly that we should be doing C# right now. Its not new, and its not great, but its very easy - there's nothing involved that takes any research, any developments, or any agreements not made already - just say "go" and the developers can start getting this into the production systems, and out into the field. I don't think that CIDR can be done quite that quickly. In fact, we should have had a "go" on C# back at the San Diego IETF, at which time its clear that C# was just as ready as it is now (nothing has changed at all), but where CIDR was clearly not ready (the BGP drafts are just appearing, I don't know of any EGP support for it yet, RIP-2 is just about ready as a final draft, ...). For those who believe they can do CIDR now as well, then by all means do it as well, do both at once, the extra effort to support C# in a new release of your code will be trivial. Just do something - right now, with no more delay. No more waiting for anything at all that's not yet quite complete. kre From owner-Big-Internet@munnari.oz.au Tue Jun 30 01:27:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20414; Tue, 30 Jun 1992 01:27:50 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20406; Tue, 30 Jun 1992 01:27:44 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA05880; Mon, 29 Jun 92 08:27:26 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA02085; Mon, 29 Jun 92 07:55:22 PDT Date: Mon, 29 Jun 92 07:55:22 PDT Message-Id: <9206291455.AA02085@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: jnc@ginger.lcs.mit.edu Cc: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Sun, 28 Jun 92 18:09:48 -0400 <9206282209.AA18771@ginger.lcs.mit.edu> Subject: Re: Para Meta Matters... Reply-To: estrin@usc.edu The context of routing in the telephone network is VERY different. They do limited dynamic routing but since each of the 140-odd switches are directly interconnected an alternate path is at most 1 extra hop. As far as i understand it routes are more or less centrally computed and downloaded. This is long lines of course. I dont know about dynamic routing within LATAs and between LATAs VERY different context. From owner-Big-Internet@munnari.oz.au Tue Jun 30 02:39:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21977; Tue, 30 Jun 1992 02:39:41 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21974; Tue, 30 Jun 1992 02:39:30 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Mon, 29 Jun 92 09:39:23 -0700 Date: Mon, 29 Jun 92 09:39:23 -0700 From: Tony Li Message-Id: <9206291639.AA10620@cider.cisco.com> To: kre@munnari.oz.au Cc: pgross@ans.net, big-internet@munnari.oz.au, road@lanl.gov, iesg@nri.reston.va.us, iab@isi.edu In-Reply-To: Robert Elz's message of Mon, 29 Jun 92 19:57:31 +1000 <17496.709811851@munnari.oz.au> Subject: Draft IESG recommendation on ROAD activities In case its not obvious, from this and previous messages, I feel strongly that we should be doing C# right now. Its not new, and its not great, but its very easy - there's nothing involved that takes any research, any developments, or any agreements not made already - just say "go" and the developers can start getting this into the production systems, and out into the field. I don't think that CIDR can be done quite that quickly. I disagree. CIDR can be done just as quickly as C#. It is true that router development for C# is faster. Unfortunately, the development process is never on the critical path. The critical path is first constrained by the "standards" process (where CIDR is stuck right now -- waiting for an IP addressing plan) and then is later constrained by the deployment process (which is independent of _what_ is deployed). In fact, we should have had a "go" on C# back at the San Diego IETF, at which time its clear that C# was just as ready as it is now (nothing has changed at all), but where CIDR was clearly not ready (the BGP drafts are just appearing, I don't know of any EGP support for it yet, RIP-2 is just about ready as a final draft, ...). I know of no intent to support CIDR with EGP. Supporting CIDR with RIP-2 is either trivial or unnecessary, depending on how you feel about using RIP as an EGP. For those who believe they can do CIDR now as well, then by all means do it as well, do both at once, the extra effort to support C# in a new release of your code will be trivial. I disagree. The unresolved technical shortcomings of C# make it unsupportable. How do I tell customers that they must not use a class C# network in their network without subnetting it to at least class C sizes? Tony From owner-Big-Internet@munnari.oz.au Tue Jun 30 03:36:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23237; Tue, 30 Jun 1992 03:36:15 +1000 (from owner-Big-Internet) Return-Path: Received: from enet-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23233; Tue, 30 Jun 1992 03:36:05 +1000 (from dee@ranger.enet.dec.com) Received: by enet-gw.pa.dec.com; id AA29649; Mon, 29 Jun 92 10:35:53 -0700 Message-Id: <9206291735.AA29649@enet-gw.pa.dec.com> Received: from ranger.enet; by decwrl.enet; Mon, 29 Jun 92 10:35:54 PDT Date: Mon, 29 Jun 92 10:35:54 PDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 29-Jun-1992 1335" To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: RE: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) -------------- From: US1RMC::"jnc@ginger.lcs.mit.edu" "Noel Chiappa" 24-JUN-1992 02:52 To: big-internet@munnari.oz.au, ranger::dee CC: jnc@ginger.lcs.mit.edu Subj: Re: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) ... ... ... > On mobility, there is a lot of concern for the mobile host but what > about the mobil[e] network? > > This is a very good point, which I have to go off and think about. My >initial reaction is that you have to give that network a new address, since >it's in a different place in the topology, and all the attached machines would >also have to get new addresses (but would keep their ID's). > What would be the utility of having the network have a name which is >constant? (I'm not trying to be difficult, I'm genuinely at a loss as to what >this would get you...) > > Noel The main reason that comes to mind is as follows: If "networks" can negotiate things with each other and yet be mobile, then it seems a lot easier to have a constant network ID. Things that networks might want to negotiate with each other include encryption, authentication, and compression of traffic between them. It seems to me that it will be very common for people not to want to bother with such things on their local Ethernet/FDDI/whatever where all the hosts are in one physical area. In that case you can handle security with physical/personnel/administrative measures. And it might not be worth doing compression on vast amounts of local traffice. However, when if you had two separated sites you might very well want to encrypt/authenticate traffic between them and, depending on bandwidth/billing issues, you might want to compress the data. If the network is mobile (as in my example of a trailer home although other examples might be an airplane or low earth orbit space station), it seems to me that the problem is exactly the same as with a mobile host. You need to be told when the routing hierarchy above the net changes and it is very convenient to be able to address the network as a fixed named entity. Donald From owner-Big-Internet@munnari.oz.au Tue Jun 30 04:02:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23737; Tue, 30 Jun 1992 04:02:41 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23733; Tue, 30 Jun 1992 04:02:32 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA09603; Mon, 29 Jun 92 11:02:26 -0700 Received: by us1rmc.bb.dec.com; id AA05841; Mon, 29 Jun 92 14:00:54 -0400 Message-Id: <9206291800.AA05841@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 29 Jun 92 14:00:55 EDT Date: Mon, 29 Jun 92 14:00:55 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 29-Jun-1992 1402" To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: RE: Re: meta matters ... Perhaps I was too strong in my message. I still don't think some backbone router complex with a bunch of Sonet pipes coming into it should be worrying much about calculating routes. I think it should be possible for a host to worry about routing if it wants to. Although one has to be careful about generating rigidly separated protocol levels, I can't say that routing is an unreasonable thing to split off. Possibly a level of network hierarchy should be able to have a policy on whether, for example, it will accept packets with just IDs that have been defaulted up to it, so it has to look up addresses/routes, or require them to come in a more convenient to forward form. Donald PS: I don't see that I was talking about "homebrew" routers. Just that it seems like a useful test of a protocol proposal that simple cases (ie, a box that hooks just to two local Ethernets and, via a 56Kb line, is their only link to the rest of the world) be implementable without a whole lot of horsepower. -------------- From: US1RMC::"jnc@ginger.lcs.mit.edu" "Noel Chiappa" 26-JUN-1992 17:07 To: big-internet@munnari.oz.au, ranger::dee CC: jnc@ginger.lcs.mit.edu Subj: Re: meta matters ... putting as much of the burden as is reasonable on the end systems This is directly in the other direction to the last 10+ years of Internet development, which tried to move the hosts out of the routing game as much as possible. There were (and remain) good reasons for this. One of the important factors in the early success of IP was that you could take a pretty lame machine and have it do useful routing Yah, and in the early days of computing (late 40's, early 50's) everyone built their own computers. Doesn't mean it's still a smart idea, though. (I'm not *that* old, but I can remember the days when application vendors - e.g. CAD/CAM - used to design and build their own CPU's - out of SSI/MSI, of course. Even though I was an undergrad then, I could tell *that* was a losing proposition.) As far as I'm concerned, the day of the homebrew router is over. We've got enough hard problems (scaling, abstraction, etc) to solve without having to support weekend lashups. Noel From owner-Big-Internet@munnari.oz.au Tue Jun 30 05:08:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24884; Tue, 30 Jun 1992 05:08:44 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24881; Tue, 30 Jun 1992 05:08:25 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA13160; Mon, 29 Jun 92 12:08:18 -0700 Received: by us1rmc.bb.dec.com; id AA07676; Mon, 29 Jun 92 15:06:46 -0400 Message-Id: <9206291906.AA07676@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 29 Jun 92 15:06:47 EDT Date: Mon, 29 Jun 92 15:06:47 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 29-Jun-1992 1508" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: Options efficiency (was Re: Para Meta Matters... ) You know I've heard this about options being inefficient for routers from many sources. Apparently it is a great force against the definition of any more end to end options which tends to stiffle research/experimentation. It's always seemed to me that a big imporvement would be to have a single bit in the header of any new protocol design which says "router option present". If this bit is off, the routers don't bother to parse the options. In the simplest version, if this bit is on, then the router parses all the options. However, it would probably be worth while to have an "end of router options" single byte code. (I'm asssuming the typical TLVish byte stream structure of options in IP4 & CLNP1.) Then routers would need to look only at router options. If you wanted to, you could then use disjoint number spaces for router options and host options. Host would have to check this bit also but it should be fast for them to skip the router options if they want as they need just skip down using the options lengths looking for the end of router options code. Probably their are some additional subtleties. There may be options of interest to only a few routers. Such would best be put in the "host" category. Any router that really wants to can still look at all the options to check for such. Donald -------------- From: US1RMC::"pgross@ans.net" "Phill Gross" 27-JUN-1992 22:44 CC: Jon Crowcroft , jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au, wilder@ans.net, enger@ans.net Subj: Re: Para Meta Matters... I was quickly informed that IP options kill router performance. Question -- is there any reason why modern routers couldn't put option processing in the microcode of their smart interface cards? Would that help? Phill From owner-Big-Internet@munnari.oz.au Tue Jun 30 05:14:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24973; Tue, 30 Jun 1992 05:14:21 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206291914.24973@munnari.oz.au> Received: from att-out.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24969; Tue, 30 Jun 1992 05:14:04 +1000 (from tds@hoserve.att.com) Date: Mon, 29 Jun 92 15:13 EDT From: tds@hoserve.att.com Sender: Antonio_DeSimone@att.com To: estrin@usc.edu Cc: P.Tsuchiya@cs.ucl.ac.uk, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: routing in the telephone network In-Reply-To: <9206291455.AA02085@caldera.usc.edu> References: <9206282209.AA18771@ginger.lcs.mit.edu> <9206291455.AA02085@caldera.usc.edu> Reply-To: tds@hoserve.att.com >>>>> On Mon, 29 Jun 92 07:55:22 PDT, estrin@usc.edu (Deborah Estrin) said: Deborah> The context of routing in the telephone network is VERY different. Deborah> They do limited dynamic routing but since each of the 140-odd switches Deborah> are directly interconnected an alternate path is at most 1 extra hop. That's correct, but... Deborah> As far as i understand it routes are more or less centrally computed Deborah> and downloaded. ...this information is obsolete, at least for AT&T. See the last ITC proceedings from Copenhagen for papers on dynamic routing in our network. Deborah> This is long lines of course. I dont know about Deborah> dynamic routing within LATAs and between LATAs Deborah> VERY different context. Different objective---none of the discussion here has talked about making efficient use of transmission resources, which is the biggest motivation for dynamic routing in the telephone network. Once the resource reservation work gets coupled with routing there will be something to learn from the telephone company experience. Right now the Internet is too immature... (Better change the subject line so I can catch the flames from this...:-) From owner-Big-Internet@munnari.oz.au Tue Jun 30 05:40:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25621; Tue, 30 Jun 1992 05:41:03 +1000 (from owner-Big-Internet) Return-Path: Received: from boole.ece.cmu.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25618; Tue, 30 Jun 1992 05:40:51 +1000 (from hastings@boole.ece.cmu.edu) Received: by boole.ece.cmu.edu (5.54-ECE2/5.17) id AA00554; Mon, 29 Jun 92 15:40:24 EDT Date: Monday, 29 June 1992 15:40:23 EDT From: Gene.Hastings@boole.ece.cmu.edu To: Paul Tsuchiya Cc: big-internet@munnari.oz.au Subject: Re: NAP concept (was Re: network number and addresses) Message-Id: <1992.6.29.19.22.58.Gene.Hastings@boole> In-Reply-To: <9206260910.15207@munnari.oz.au> the appropriate references are: The presentation Peter Ford gave in San Diego at the BGP Utilization BOF; The Aiken-Braun-Ford paper on an IINREN implementation plan, online at expres.cise.nsf.gov in directory recompete. FILES: impl.ps -- postscript version of the implementation plan with figures impl.nofig.ps -- postscript version of the implementation plan without figures (Figures for document in separate postscript files) impl.ascii -- ascii version (using dvi2tty) net.num.ps -- graph of number of networks on NSFNET backbone newlevel.ps -- toplogy diagram showing the existing heirarchy of networks nex.ps -- Network access point based internetwork diagram nsfnet.ps -- NSF backbone MAP , provided by ANS -1991 A presentation given by Bob Aiken to an FNC Advisory Committee meeting on May 15th. Slides are also on expres.cise.nsf.gov in recompete. README.2 and Aiken_HPCC_NREN.ps. the NSF draft solicitation itself, also on expres.cise.nsf.gov in recompete. solicit_comment.ascii (straight ascii, no graphics) solicit_comment.ps (PostScript, with graphics) solicit_comment.ps.Z (Ditto, compressed) Gene A message which may also shed some light is one recently sent to com-priv by Bob Aiken. G. From owner-Big-Internet@munnari.oz.au Tue Jun 30 05:51:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25861; Tue, 30 Jun 1992 05:51:44 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25856; Tue, 30 Jun 1992 05:51:23 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA15450; Mon, 29 Jun 92 12:51:12 -0700 Received: by us1rmc.bb.dec.com; id AA08730; Mon, 29 Jun 92 15:49:39 -0400 Message-Id: <9206291949.AA08730@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 29 Jun 92 15:49:40 EDT Date: Mon, 29 Jun 92 15:49:40 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 29-Jun-1992 1551" To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: RE: Re: Para Meta Matters... I could expound briefly on how phone calls are switched in North America as of some years ago as I remember it. There was a hierarchy of offices as follows Regional Center Sectional Center Primary Outlet Toll Center There were 12 regional centers, 2 in Canada and 10 in the US, with lots of paths between *all* possible pairs. Lower levels in the hierarchy had some direct paths to any place their was enough traffic to warrant it plus a "final" with plenty of paths to the next level up. Levels could be skipped so it was quit possible for your local phone office to connect to a Toll Center that had a final direct to a Regional or Sectional Center. (Original plans had also called for a National Center but this was abandonded and enver built.) Assume a call somehow comes into a Primary Outlet. It would see if it had a direct path to the Toll Center, Primary Outlet, Sectional Center, or Regional Center of the destination (which might not all exist). They would be given preference in the order listed. Failing that, the call would be routed via the final to the next level up which would be a Sectional or Regional Center. If there are no paths toward the destination from a Regional Center, you get a circuits busy. I'm not sure what other sorts of reconfiguration were possible but it was common to manually change Regional Center routing. For example, in the morning of a business day, phone traffic up & down the east coast might be very heavy while most people are still asleep on the west coast. A call going between a source served by the Regional Center in White Plains NY and a destiantion served by the Regional Center Richmond VA (if I remember these places properly) would not normally be allowed to transit any other Regional Center but could be manually configured to permit it to go via one of the West Coast Regional Centers making use of the mostly idle transcontinental circuits. Donald -------------- From: US1RMC::"jnc@ginger.lcs.mit.edu" "Noel Chiappa" 28-JUN-1992 18:40 To: P.Tsuchiya@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu CC: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subj: Re: Para Meta Matters... ... Also, since you (I would assume) know a lot more about the phone system than I do, can answer an information query? In what cases is the routing between administrative domains (i.e. in the US, between IEC's, between RBOC's and IEC's, and between RBOC's/IEC's and customers; between PTT's elsewhere; etc, etc) anything other than static configuration? Also, I have heard that ATT Long Lines, for instance, does some dynamic routing internal to their system; if you know anything about it, can you explain a bit of how it works? Noel From owner-Big-Internet@munnari.oz.au Tue Jun 30 06:00:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26044; Tue, 30 Jun 1992 06:00:50 +1000 (from owner-Big-Internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26041; Tue, 30 Jun 1992 06:00:35 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Mon, 29 Jun 92 13:00:12 -0700 Date: Mon, 29 Jun 92 13:00:12 -0700 From: Dave Katz Message-Id: <9206292000.AA14554@regal.cisco.com> To: mm@gandalf.ca Cc: callon@bigfut.enet.dec.com, big-internet@munnari.oz.au In-Reply-To: Mississippi Mud's message of Mon, 22 Jun 92 15:09:16 EDT <9206221909.AA04327@cannibal.gandalf.ca> Subject: TUBA IDRP's early incarnation, BRP, called out the use of TP4, but this was shot down by the architectural purists, for what it's worth. One of the reasons for using TCP was that it was already present in most routers; this can't be said for TP4. Given the difference in complexity between TP4 and IDRP's reliability scheme, I'd much rather implement the latter (not having to handle reneging flow control credit helps a fair amount, not to mention upward/downward multiplexing, etc.) Date: Mon, 22 Jun 92 15:09:16 EDT From: mm@gandalf.ca (Mississippi Mud) >We would probably need to update >TP4 to include graceful close if we wanted to run over TP4. However, I >expect that this would be a perfectly reasonable thing to do (we could >either push the required update to TP4 through ANSI and ISO This would help IDRP, as it would be able to use a TP? connection instead of trying to emulate TCP on top of CLNP. It could become that much more similar to BGP. -Chris Sullivan From owner-Big-Internet@munnari.oz.au Tue Jun 30 06:36:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26706; Tue, 30 Jun 1992 06:36:26 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26703; Tue, 30 Jun 1992 06:36:13 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA18063; Mon, 29 Jun 92 13:36:04 -0700 Received: by us1rmc.bb.dec.com; id AA09926; Mon, 29 Jun 92 16:34:30 -0400 Message-Id: <9206292034.AA09926@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 29 Jun 92 16:34:32 EDT Date: Mon, 29 Jun 92 16:34:32 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 29-Jun-1992 1635" To: bmanning@is.rice.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: RE: Re: Mobile Hosts and IDs Packets can be floating around in IP4 for up to four minutes and presumably up to two minutes with CLNP1. It seems to me that as a practical matter, you have to keep forwarding information at the old address for a host (or network if you have the same sort of mobile networks), forward any packets that arrive at the old address (unless their TTL runs out), and send some sort of redirect to the source. As long as there is some traffic and the hosts don't move too fast, this should do it. It would also be a good idea for a host to tell people who have communicated with it recently when it moves. If hosts are moving too fast for the above strategy, then you really need a completely different strategy where the mobility is invisible to the outside world (ie, people outside the "network" or whatever it is that is handling this ultra-mobility). On handling lack of traffic, seems to me like the best thing is to have a mandatory time out of the cached address (which I believe is already provided for in DNS) which is shorter than the time out of the forwarding info at a mobile address minus four minutes. Then, after enough idle time, you are forced to get a new address anyway. Donald -------------- From: US1RMC::"bmanning@is.rice.edu" "William Manning" 26-JUN-1992 22:23 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) CC: big-internet@munnari.oz.au Subj: Re: Mobile Hosts and IDs Noel, What happens when BOTH (or n) hosts are mobil? In all three of your basic starting points, you assume (at least you state overtly in one and three) one end is a static host. -- 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 Tue Jun 30 06:40:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26791; Tue, 30 Jun 1992 06:41:13 +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 AA26782; Tue, 30 Jun 1992 06:40:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26132; Mon, 29 Jun 92 16:40:40 -0400 Date: Mon, 29 Jun 92 16:40:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206292040.AA26132@ginger.lcs.mit.edu> To: tds@hoserve.att.com Subject: Re: routing in the telephone network Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu (Better change the subject line so I can catch the flames from this...:-) What makes you think we all disagree with you? :-) none of the discussion here has talked about making efficient use of transmission resources, which is the biggest motivation for dynamic routing in the telephone network. Once the resource reservation work gets coupled with routing there will be something to learn from the telephone company experience. I agree, the interaction of resource allocation and routing has not been much considered in the Internet. The ARPANet did have some important experience with this; the original LS work cat BBN came out of a desire to stabilize their dynamic routing protocol under the effects of varying load. Also, it was considered by the Open Routing WG extensively. Their conclusion were reported in their report (Appendix A of RFC1126, section A.6.4 Load-Based Routing), but this document unfortunately did not mention some of the more advanced thoughts we had, which was that while in a very large system a scheme in which resource allocation and routing were *intimately* connected would be neither stable enough nor respond fast enough, there were ways to two the two together more loosely, particularly in the map based approach recommeded. Again, this margin is too small..... Right now the Internet is too immature... Gee, (tonque only partially in cheek :-), I would have said the same thing about learning lessons about routing from the telephone network! Noel From owner-Big-Internet@munnari.oz.au Tue Jun 30 07:00:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27128; Tue, 30 Jun 1992 07:01:05 +1000 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27119; Tue, 30 Jun 1992 07:00:49 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA06760; Mon, 29 Jun 92 15:00:31 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA25274; Mon, 29 Jun 92 15:00:30 MDT Message-Id: <9206292100.AA25274@goshawk.lanl.gov> To: estrin@usc.edu Cc: jnc@ginger.lcs.mit.edu, P.Tsuchiya@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: Re: Para Meta Matters... In-Reply-To: Your message of Mon, 29 Jun 92 07:55:22 -0700. <9206291455.AA02085@caldera.usc.edu> Date: Mon, 29 Jun 92 15:00:29 MST From: peter@goshawk.lanl.gov Following up on Deborah's comments. It is my understanding that several phone systems do their routing for their telephone network by precomputing with particular table driven dynamics which anticipates common failure/loading scenarios. These are hard coded with "hand tuning". On most days this seems to work. As Deborah said: a very different context. But then again, perhaps it is a good way to go, ditch this fully dynamic cruft, distribute the policy routing database by anon ftp and let it rip ... Now the issue is what to program this stuff in; where did I leave my Chill manual? From owner-Big-Internet@munnari.oz.au Tue Jun 30 07:12:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27412; Tue, 30 Jun 1992 07:12:54 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27403; Tue, 30 Jun 1992 07:12:45 +1000 (from estrin@jerico.usc.edu) Received: from excalibur.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA21147; Mon, 29 Jun 92 14:12:27 PDT Received: by excalibur.usc.edu (4.1/SMI-3.0DEV3) id AA11257; Mon, 29 Jun 92 14:06:00 PDT Date: Mon, 29 Jun 92 14:06:00 PDT Message-Id: <9206292106.AA11257@excalibur.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@jerico.usc.edu To: jnc@ginger.lcs.mit.edu Cc: tds@hoserve.att.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Mon, 29 Jun 92 16:40:40 -0400 <9206292040.AA26132@ginger.lcs.mit.edu> Subject: Re: routing in the telephone network Reply-To: estrin@usc.edu Certainly some of us are interested in the adaptive routing question (well, at least I am) but I think this is still in the research stage whereas I thought this list was focusing on solutions that could be engineered in the near future. If anyone on ths list is interested in the subject, I would appreciate feedbaack on a thus-far-simple scheme we have in mind to do adaptive routing. D. From owner-Big-Internet@munnari.oz.au Tue Jun 30 07:48:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28145; Tue, 30 Jun 1992 07:48:51 +1000 (from owner-Big-Internet) Return-Path: Received: from SPECTRUM.CMC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28142; Tue, 30 Jun 1992 07:48:39 +1000 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA07778; Mon, 29 Jun 92 14:48:15 PDT Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Maps ? Landmarks ? Message-Id: <1992Jun29.214806.7739@spectrum.CMC.COM> Organization: CMC (a Rockwell Company), Santa Barbara, California, USA References: <9206280452.AA15791@ginger.lcs.mit.edu> Date: Mon, 29 Jun 92 21:48:06 GMT Apparently-To: Big-Internet@munnari.OZ.AU Can somebody point me to an online article on each of the topics "Landmark Routing" and "Map Based Routing" ? -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 From owner-Big-Internet@munnari.oz.au Tue Jun 30 09:41:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00951; Tue, 30 Jun 1992 09:41:39 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00947; Tue, 30 Jun 1992 09:41:35 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA00539 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 30 Jun 1992 09:41:32 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA18002; Tue, 30 Jun 92 09:41:31 EST Message-Id: <9206292341.AA18002@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: routing in the telephone network In-Reply-To: Your message of "Mon, 29 Jun 92 14:06:00 PDT." <9206292106.AA11257@excalibur.usc.edu> Date: Tue, 30 Jun 92 09:41:30 +1000 From: Bob Smart Robert Elz wrote: >Is it really? Sure there are more phones, but the phone companies have >done nothing to obsolete any phone (since they learned how to dial rather >than just attract the attention of an operator). Clever of them to have variable length addresses from day 1. Now that we are moving towards variable length addresses we are considering adding in fixed length IDs. Well I guess we wouldn't want to leave our children without any technical challenges to exercise their minds. and more recently Deborah Estrin wrote: >Certainly some of us are interested in the adaptive routing question >(well, at least I am) but I think this is still in the research >stage whereas I thought this list was focusing on solutions >that could be engineered in the near future. A timely reminder. One of the bits of evidence that a proposal is "engineering" not "research"/"pie-in-the-sky" will be the existence of working code. However scalability will be a key descriminant and I don't see any plausible way of testing that characteristic in the available time frame. A key to scalability will be the operation of the DNS. Nearly all schemes depend on significant support from new and changed DNS behaviour. In particular support for old hosts often requires the DNS to give different answers depending on who asks the question. That's something we've needed in the DNS for a while for other reasons. One question that comes to mind is whether it is going to be practicable to just hack all this stuff into BIND, or whether a complete rewrite might be in order. On the other hand X.500 is getting ahead of the DNS in some crucial areas: namely support for modern authentication technology. Perhaps it is time to merge the two directory services. Oops, sounds like a research project. Bob Smart From owner-Big-Internet@munnari.oz.au Tue Jun 30 10:31:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02356; Tue, 30 Jun 1992 10:31:23 +1000 (from owner-Big-Internet) Return-Path: Received: from gizmo.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02348; Tue, 30 Jun 1992 10:31:16 +1000 (from mo@gizmo.bellcore.com) Received: by gizmo.bellcore.com (5.61/1.34) id AA03406; Mon, 29 Jun 92 20:31:07 -0400 Date: Mon, 29 Jun 92 20:31:07 -0400 From: mo@gizmo.bellcore.com (Michael O'Dell) Message-Id: <9206300031.AA03406@gizmo.bellcore.com> To: smart@mel.dit.csiro.au Subject: variable length addresses Cc: big-internet@munnari.oz.au Well, while the Fone Folks may have had vbl length addresses from day one, they have also had severe headaches from them as well. folks, running around trying to reinvent the genius of the fone kompanies is not the path to happiness. -Mike From owner-Big-Internet@munnari.oz.au Tue Jun 30 11:14:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03570; Tue, 30 Jun 1992 11:14:43 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03560; Tue, 30 Jun 1992 11:14:28 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws13.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA19068; Mon, 29 Jun 92 18:11:05 -0700 Date: Mon, 29 Jun 92 19:59:20 EDT From: "William Allen Simpson" Message-Id: <486.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: PIPE We're having some very long discussions here, but I haven't seen any proposal that does the few simple things that I would like to see. My last attempt to get the group to focus on practical details wasn't widely received. I was enthused last year by Noel's routing ideas. I haven't been able to get too excited by any of the other proposals, and was leaning toward DNAT because it seemed "practical". I finished a contract on June 15th, and set aside a some time to write a draft which is both practical and implements some of the "ideal" that Noel first brought to my attention. It may not get theoretical acclaim, but it should move us in the right direction. PRACTICAL INTERNET PROTOCOL EXTENSIONS (PIPE) Abstract Current IP addresses are used for both host identification and routing. This memo proposes a simple and practical migration to routes using a variable length "path", which is separate from the final host identifier. It extends the concept of "areas" already present in some routing protocols to reduce the size of current routing tables and provide for future expansion of the IP address space. To reduce the size of routing tables, a pair of IP4 header options is defined to implement area to area source routing. These variable length options will be present in both IP4 and future IP(n) headers. It is hoped that the simplicity of the extension will ease implementation. To deal with several perceived limitations with the current IP4 header, an IP(n) header is defined which is very similar to the IP4 header. The similarity should allow IP(n) routers to continue to route IP4 packets with very little effort. It is intended that this migration occur over a period of many years. The text of this proposal is preliminary, and it is hoped that comments and extensions will be offered to make this document more complete. Motivation This author is convinced that attempts to extend the IP address space by simply making it larger are outweighed by the explosion of routing table space needed for the larger size. Also, a fixed size address is still subject to future exhaustion, since the address is burdened with the need to carry the routing information. Such an address space is likely to be highly fragmented. Therefore, a scheme is proposed which separates the IP address from the IP routing at the inter-domain level, and can be extended into the intra-domain level. The proposed routing mechanism is extemely hierarchical, which facilitates route folding, and extensible, to adapt to future growth. In addition, any scheme which requires significantly more network resources for final implementation is doomed to failure. Current Domain Name Service consumes 10% of the bandwidth; doubling this would be a significant problem. This proposal requires no more DNS accesses than currently, and does not require new servers. New services such as inter-domain policy routing and mobile routes are handled entirely within the usual routing table update mechanism. Finally, this proposal does not require any immediate changes to current IP practices at any level, does not require deployment be universal, and provides an extremely gradual migration path to a new IP header. The new header is designed to be routed concurrently with older IP by maintaining most fields in their current relative offsets within the IP header. Terms and Concepts A "Internet Protocol System Address" (IP-SA) is the number associated with the end producer/consumer of packets. An actual host may have several numbers, perhaps corresponding to different network attachment points, but it is expected that eventually each system will have a single number. This number is also called the "IP address". A "Routing Area" is defined as a region in the internet routing space which is reachable with a common defined set of quality of service and security. The area may contain other areas. Several area numbers may be assigned to the same region when there are non-default quality of services or security provided. A "Routing Path" is a sequence of areas which defines the connectivity of an area to a designated root. The leaf areas in a path MUST NOT partially overlap with another leaf. Each set of quality of service or security creates a separate path. Consider the following topology: Backbone Router A ----------------------------------- Router B | | + Host 1.2.3.4 + Host 6.7.8.9 | | + Router AC ----+------------+---- Router BC + | | | + Host 4.3.2.1 -+ +- Host 9.8.7.6 The default path to these hosts would be defined as: 0:RA 0:RB A:RA B:RB A:1.2.3.4 B:6.7.8.9 A:4.3.2.1 B:RBC A:RAC B.C:RBC A.C:RAC B.C:9.8.7.6 A.C:4.3.2.1 B.C:4.3.2.1 A.C:9.8.7.6 Defining System Addresses In the example above, note that the System Address is used only in the final hop. It need not be subnetted, nor have any particular structure. This allows a very dense IP address space, and should extend the life of the current globally unique IP address. When fully deployed, it is only necessary that the IP-SA be unique within a routing area, and together with the complete routing path would provide unique identification of a host. However, to promote ease of migration and support for mobile routing and automatic partition repair, the IP-SA is required to be unique within the last three levels of the completely specified routing path. Defining Routing Areas Routing Areas will be defined from the hosts upward. A host which is attached to a single network is in the same area with others attached to the same network with the same policy. A host which is attached at two points is in both areas (has two routing paths), regardless of whether it also acts a router between the areas. Routing Areas are bounded by routers which are connected to more than one level of area or are separated by policy. The Area numbers range from 1 to 254. Area 0 means this level. Area 255 means all areas at this level. Defining Routing Paths Routing Paths will be defined from the root backbone downward. At each separation of level, and for each quality of service or security, an additional number is assigned to an area. In the above example, suppose that Host 4.3.2.1 was not participating in a security agreement with all of the other hosts. Even though Host 4.3.2.1 appears on the same network, it would simply not have an entry in the security Routing Paths, and would not be visible to Hosts 9.8.7.6 and 1.2.3.4 for that type of traffic. Automatic discovery of Routing Paths is possible, but would require cooperation between the hosts and the DNS for the automatic assignment to be propagated. Any host, including routers, would request the path at each point of attachment. As the routers discover their position in the path, they could assign area numbers and respond to the requests that appear on other points of attachment. The hosts could then inform the DNS of the current path(s). The path may be padded with area zero. When found at the beginning of the path, it means root. When found at the end of the path, it means this level. Area zero may never be found in the interior of a path. All zeroes may be removed from the path without a change in meaning. Final Hop Delivery This definition extends Routing Paths only to a particular area. Delivery to the final destination continues to be accomplished with current methods. One advantage of this design is that routing paths may be gradually and automatically extended as routing implementations are upgraded. The Routing Path may be specified at the source or the inter-domain router, and used until it is no longer recognized. From that point on, the routing takes place using the current subnet methods. The separation from local delivery mechanisms allows the design to adapt without change to all current and future link media, and to benefit from improvements in such things as automatic host configuration and router discovery without change to the overall routing scheme. Another advantage is that mobile systems may continue to receive traffic without changing the Routing Path, by specifying an incomplete path and relying on local routing to make the final delivery. This reduces propagation of changes and hides such details from the global internet. This feature also facilitates automatic repair of partitioned areas. The path can be locally shortened to a level which includes the partitioned area, and delivery can take place by internal means. Migration to Path Routing Initially, the path will simply be the Autonomous System number. These are centrally administered, and are already distributed to backbone routers. The AS number can easily be reorganized as a two level heirarchy with no effect on current backbone routing tables. Backbone routers will add the Routing Path (AS number) to IP4 datagrams, which will improve the speed of routing over subsequent backbone routers. Next, a new record must be added to the Domain Name System to maintain the default Routing Path for each SOA, and the Routing Path must be returned in the information part of every DNS access, including inverse address lookups. Eventually, all participating domains connecting to the backbone will be required to add the Routing Path when it is missing from IP4 datagrams. At that point, the massive backbone routing tables may be eliminated. The conversion tables in the border routers are likely to be considerably smaller than in the backbone routers, since most domains do not continuously send to all other domains. In the long term, every IP4 host will be converted to PIPE, and include the Routing Path in every datagram. After this is completed, system addresses will no longer need to be globally unique. New IP Header Note that each tick mark represents one bit position, and bits are numbered from most significant to least significant. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IHV | IHL | Path Level | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | Flags | Time to Live | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IHV: 3 bits Internet Header Version indicates the format of the internet header. This document describes version 011 binary. The IP4 Version is 0100 binary, but is encoded in a 4 bit field. Therefore, this choice is equivalent to IP4 Version 0110. IHL: 5 bits Internet Header Length is the length of the internet header in 32 bit words, and thus points to the beginning of the data. Note that the minimum value for a correct header is 5. The maximum header length is 124 octets, and a typical header is 28 octets. The IP4 IHL field occupied this location. The field was expanded in order to provide more option space. The minimum header size is always known by the Version field. Path Level: 8 bits The Path Level indicates the area level to which the sender is routing. A zero indicates the root backbone, a one indicates the first area in the path, etc. This field may be used as an index into the Path Option. The IP4 Type of Service field was removed, since TOS was rarely used, and is now encoded in the Routing Path. Total Length: 16 bits Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 1480 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 1480 octets if they have assurance that the destination is prepared to accept the larger datagrams. The number 1480 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information, and to allow typical lower-layer encapsulations room for thier respective headers. IP4 has maximum 65,535, minimum 576 octet datagrams. Over time, memory limitations have eased considerably, and there have been some indications that a larger minimum datagram size throughout the internet would be beneficial. Raising the maximum would primarily benefit those users whose entire path consists of high bandwidth, high delay transmission. This design trades off an increase in size of the Protocol field, instead. Identification: 16 bits An identifying value assigned by the sender to aid in assembling the fragments of a datagram. Flags: 8 bits Various Control Flags. CX: 0 = Not Congested, 1 = Congestion Experienced. DF: 0 = May Fragment, 1 = Don't Fragment. MF: 0 = Last Fragment, 1 = More Fragments. IT: 0 = default, 1 = Interactive Traffic. 2 6 7 8 9 0 1 2 3 +---+---+---+---+---+---+---+---+ | C | D | M | I | | | | | | X | F | F | T | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+ The IP4 Flags field was only 3 bits. The DF and MF flags are located in the same position. The CX bit is set by any router where congestion is experienced. The IT bit is set by the host or router to indicate interactive traffic within a particular quality of service or security. Time to Live: 8 bits This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed. This field is modified in internet header processing. The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime. The IP4 Fragment Offset field was removed, and replaced with an IP Option. The TTL field was moved to a new location, where it is easier to increment on most hardware. Protocol: 16 bits This field indicates the next level protocol used in the data portion of the internet datagram. The values for various protocols are specified in "Assigned Numbers" [9]. The size of the protocol field was increased, since there is concern that 255 numbers may be too few over the extended life of the IP protocol. Header Checksum: 16 bits A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed. The checksum algorithm is: The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. This is a simple to compute checksum and experimental evidence indicates it is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience. Source Address: 32 bits The source System Address. Destination Address: 32 bits The destination System Address. New Option Definitions Path +--------+--------+--------//--------+ | type | length | path | +--------+--------+--------//--------+ Type = ?? The Length is the number of octets in the option counting the type, length, and path. The length will always be a multiple of 4. The Path is a list of areas, as described above. The path may be padded with trailing zeroes to align on 32 bit boundaries. Must be copied on fragmentation. This option usually appears twice in a datagram. The first (destination) Path must always appear immediately after the fixed portion of the header. The second (source) Path must always appear after the first. The Path option is compatible with IP4. However, it MUST NOT be added to datagrams already containing the Loose Source Route or Strict Source Route options. Fragment +--------+--------+--------+--------+ | type | length |000 Offset | +--------+--------+--------+--------+ Type = ?? Length = 4 000 = currently zero Offset This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. Must be copied on fragmentation. Appears at most once in a datagram. This option provides for fragmentation and reassembly of PIPE datagrams in a similar fashion to IP4. Fragmentation handling requires expanding and contracting the header; adding an additional option at that time should not be difficult. Since many believe that fragmentation is evil, this option may not be necessary. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Tue Jun 30 13:58:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07962; Tue, 30 Jun 1992 13:59:04 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07950; Tue, 30 Jun 1992 13:58:46 +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 AA19927; Mon, 29 Jun 92 20:57:21 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA23752; Mon, 29 Jun 92 20:57:28 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA08971; Mon, 29 Jun 92 20:57:03 PDT Date: Mon, 29 Jun 92 20:57:03 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9206300357.AA08971@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA05289; Mon, 29 Jun 92 20:57:16 PDT To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 29-Jun-1992 1508" Cc: big-internet@munnari.oz.au In-Reply-To: <9206291906.AA07676@us1rmc.bb.dec.com> Subject: Options efficiency (was Re: Para Meta Matters... ) By the way, lest we forget, hosts also have to process options. Performance in hosts is also an important issue. Bob From owner-Big-Internet@munnari.oz.au Tue Jun 30 16:37:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12650; Tue, 30 Jun 1992 16:37:38 +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 AA12643; Tue, 30 Jun 1992 16:37:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00301; Tue, 30 Jun 92 02:37:16 -0400 Date: Tue, 30 Jun 92 02:37:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206300637.AA00301@ginger.lcs.mit.edu> To: dee@ranger.enet.dec.com, jnc@ginger.lcs.mit.edu Subject: RE: Re: Para Meta Matters... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Right, I'd heard about some of this. However, I think I recall hearing that at this point the routing was all manual/static, right? Noel From owner-Big-Internet@munnari.oz.au Tue Jun 30 16:46:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12877; Tue, 30 Jun 1992 16:46:42 +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 AA12869; Tue, 30 Jun 1992 16:46:09 +1000 (from kre) To: Tony Li Cc: pgross@ans.net, big-internet@munnari.oz.au, road@lanl.gov, iesg@nri.reston.va.us, iab@isi.edu Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Mon, 29 Jun 92 09:39:23 -0700. <9206291639.AA10620@cider.cisco.com> Date: Tue, 30 Jun 92 16:45:54 +1000 Message-Id: <17773.709886754@munnari.oz.au> From: Robert Elz Date: Mon, 29 Jun 92 09:39:23 -0700 From: Tony Li Message-ID: <9206291639.AA10620@cider.cisco.com> I disagree. CIDR can be done just as quickly as C#. I assume you mean you can get the code for it out in about the same amount of time (give or take the few extra days to write the code, which I agree is not worthy of consideration). The critical path is first constrained by the "standards" process (where CIDR is stuck right now -- waiting for an IP addressing plan) Exactly. This one is the problem - C# needn't be constrained by that, and that's where it gets its advantage. At the minute its being held up by the "political" process, people just aren't willing to say "do it". That's all it would take, nothing else is holding up C#. I suspect that if C# had been blessed back when the ID was finished cisco could probably have had C# support in release 9 of your code, but I doubt that even with CIDR known to be coming you're actively devoting much time to it yet, its still on hold, waiting other things to settle. I know of no intent to support CIDR with EGP. Does this assume that CIDR can't begin to have an effect until everyone has switched to BGP (and BGP 4 at that?) Anyone have any idea how far away that will be? Supporting CIDR with RIP-2 is either trivial or unnecessary, depending on how you feel about using RIP as an EGP. You're obviously only concerned with reducing backbone routing table size, which is certainly a major objective for both C# and CIDR - and maybe its CIDR's only goal, but C# does more than that, in that it allows sites that can't get a B netnumber to still have > 254 hosts on a cable if they're that way inclined. Without support for supernetting in the local environment, which includes in things like RIP (and IGRP I guess), then CIDR isn't going to do anything to help in that field, which makes it inferior to C# in this way. The unresolved technical shortcomings of C# make it unsupportable. Tell us more of them, maybe they can be resolved? If there really are so many that C# is truly unworkable then I'll shut up, but at the minute, apart from the genuine impurity of continuing to support classed addresses at all, rather than pure address/mask pairs eevrywhere, I don't see any technical shortcomings at all. How do I tell customers that they must not use a class C# network in their network without subnetting it to at least class C sizes? Why would you want to tell them that? Maybe I'm missing something, but I don't see any imperative to subnet a C# at all, any more than a B - obviously desireable, but certainly not mandatory. Maybe you're just considering interacting with hosts not upgraded to support C#? Note, there's no question that C# needs host support to work properly. That's OK with me, esp given that it can work with restrictions without it. If that's it, how to you tell customers that they have to set the broadcast address to 0's if they have old hosts? Or that they can't subnet at all if they have even older ones? (I finally turned off my last host that didn't understand subnetting just yesterday - though its ethernet board had broken about a month or so ago, which was the real impetus to get rid of it at last .. before then it had a class C just for itself for a few months, since the previous host that didn't support subnetting died). Supporting old, now sub-standard, implementations is a pain I admit, but its not going to go away. It would be nice to be able to avoid it, but I don't think that you can here. If we don't do C#, how are you going to tell customers that if they're not one of the lucky ones to get one of the few remaining class B numbers, that they can't, ever, have > 254 hosts on a net, as all that's left is class C's? That is, without one of those revolting "multiple nets on a cable" hacks (which would support C# subnetted with > 8 host bits and old hosts just as well). Aside: just how many host implementations don't allow the subnet mask to be set narrower than the "natural" mask for the class? I just tried my workstation, which lives on a class C net (for reasons unrelated to those related above), and ... le0: flags=63 inet 192.43.207.11 netmask fffffe00 broadcast 192.43.207.0 ether 8:0:20:1:f6:be which makes it look like I have effective C# host support already, if I had a C# number instead of an ordinary C. Second aside: Are there archives of the ROAD discussions that could be made available for the rest of us to read? kre From owner-Big-Internet@munnari.oz.au Tue Jun 30 16:49:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12954; Tue, 30 Jun 1992 16:49: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 AA12949; Tue, 30 Jun 1992 16:49:46 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00365; Tue, 30 Jun 92 02:49:40 -0400 Date: Tue, 30 Jun 92 02:49:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206300649.AA00365@ginger.lcs.mit.edu> To: tds@hoserve.att.com Subject: Re: routing in the telephone network Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the original LS work at BBN came out of a desire to stabilize their dynamic routing protocol under the effects of varying load I should have mentioned that this routing was load-affected; i.e. it would route around congested areas. Metrics were delay based, and included transmission and queueing delays. So, routes were constantly changing as the load on various links changed. The DV algorithms they were initially using didn't respond too well to this amount of dynamicity, and although they investigated alternatives, they came down to LS in the end. See BBN Report #3803, April '78, which talks about the problems in the old DV system, as well as possible fixes to that, and the new LS system. Noel From owner-Big-Internet@munnari.oz.au Tue Jun 30 17:08:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13546; Tue, 30 Jun 1992 17:09:52 +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 AA13516; Tue, 30 Jun 1992 17:08:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00603; Tue, 30 Jun 92 03:08:15 -0400 Date: Tue, 30 Jun 92 03:08:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206300708.AA00603@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, P.Tsuchiya@cs.ucl.ac.uk Subject: Re: Para Meta Matters... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Please don't classify Pip as a long term architecture with Nimrod. While Pip is designed to last over the long term, it is also meant to be installable in the short term, and evolvable to long term solutions. Please don't classify Nimrod as a solution that will take a decade to design and deploy. A lot of the ideas in Nimrod are being field tested as we speak, in IDPR. I would hope that we could deploy Nimrod by the time that CIDR started to creak. I mean, CIDR *ought* to give us a factor of ten in scale, minimum, and that's 3+ years at the current growth rate, right? Once Nimrod is deployed as the routing architecture, we could move as swiftly as needed to get the longer ID packet format out. The routing and addressing stuff will all be identical for both level 3 protocols. Arguing about whether this is true or not is almost certainly an utter waste of time. Some think one thing, others another. Let's leave it at that. Noel From owner-Big-Internet@munnari.oz.au Tue Jun 30 17:42:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14326; Tue, 30 Jun 1992 17:43:07 +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 AA14316; Tue, 30 Jun 1992 17:42:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00734; Tue, 30 Jun 92 03:42:32 -0400 Date: Tue, 30 Jun 92 03:42:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206300742.AA00734@ginger.lcs.mit.edu> To: kre@munnari.oz.au, pgross@ans.net Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, road@lanl.gov in assuming that CIDR and C# are contradictory, or competing in some way I don't think the IESG assumed that they were technically contradictory (as in, if we did one, you couldn't do the other); in fact, we explicity recognized that doing both was an option. They do compete for attention, though. C# could be being put in place right now, if only we would agree to do it, and while it might not have huge long term benefits, there's no way that it can fail to help in the very short term, both in conserving class Bs, Well, I agree with you completely there. As you no doubt noted from some earlier comments to Big-I, I was extremely upset at the way C# got stuck in the mud by various outside events, just when it was peaking. However, that's all water under the bridge. and in keeping the routing table sizes down. As far as I can tell, this only comes into play if you can allocate one C# instead of a number of C's, which is probably rare (unless you run out of B's, but C# was supposed to cure that too). I always thought that curing the B shortage was the goal of C#. we could embrace an effort to cure the ills of society... This is undoutably a good idea (and is akin to Nimrod, etc) Why does everyone keep assuming Nimrod is some giant, far off, Never-Never land? Every time I hear this I want to scream. Sure, it's not ready to start writing code, but it is ready to start writing a spec.... i.e. a few weeks behind TUBA. IDPR is giving us field experience with a lot of the basic concepts. Think of IDPR as Nimrod Phase 0. In fact, we should have had a "go" on C# back at the San Diego IETF, at which time its clear that C# was just as ready as it is now Well, really, at Santa Fe. We found the last problems (EGP updates, and IN-ADDR) about then. Wheels grinding off-stage.... I don't know of any EGP support for it yet I assume EGP will not support it. Just as well, EGP's a dog; it'll help put it out of our misery. Just do something - right now, with no more delay. Exactly. It's for that reason that I sighed, said a prayer for the soul of C#, and said let's get on with CIDR. Better to move than argue for another month. If we'd done C# at Santa Fe, we'd almost have it now ... and if pigs had wings, they could fly. It's just not that big a deal; we blew it, but there are more important things to worry about, and spend cycles on. Spilt milk. Also, to be realistic, CIDR can do some things C# can't, so that helps reconcile me too. Noel From owner-Big-Internet@munnari.oz.au Tue Jun 30 18:00:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14777; Tue, 30 Jun 1992 18:00:34 +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 AA14739; Tue, 30 Jun 1992 18:00:02 +1000 (from kre) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: pgross@ans.net, big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, road@lanl.gov Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Tue, 30 Jun 92 03:42:32 -0400. <9206300742.AA00734@ginger.lcs.mit.edu> Date: Tue, 30 Jun 92 17:59:47 +1000 Message-Id: <17860.709891187@munnari.oz.au> From: Robert Elz Date: Tue, 30 Jun 92 03:42:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9206300742.AA00734@ginger.lcs.mit.edu> I always thought that curing the B shortage was the goal of C#. Yes, but the other way to save Bs is to allocate lots of Cs and watch the routing tables explode. CIDR will keep the routing table sizes down, provided the Cs are allocated in the right kinds of groups (which means teaching the NIC about buddy systems, or best fit, or whatever the current theory is about how to avoid too much fragmentation). C# keeps the routing table size down by simply allocating only one externally visible number to those who need only one. Why does everyone keep assuming Nimrod is some giant, far off, Never-Never land? Sorry - I didn't mean to suggest that. TUBA, PIP, and everything else that's a radical departure from our current mindset was supposed to fit with that analogy, it was the departure from current ways of thought, to presumably better ways, that I was suggesting, together with the timeframe that any such radical change (either in network technology, or human political life) necessarily takes. CIDR can do some things C# can't, so that helps reconcile me too. Certainly - CIDR has my support, its an obvious thing to do (obvious now its suggested anyway). I just don't see it as any kind of alternative to C# at all, they're while the overall effects of both are similar, they achieve the result in such drastically different ways that doing both is worthwhile. I still think its necessary to start on C# now, as I don't see an imminent start on deploying CIDR, and even if that was right around the corner, C# is still worthwhile, C# and CIDR fit together quite well. kre From owner-big-internet@munnari.oz.au Tue Jun 30 18:01:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14786; Tue, 30 Jun 1992 18:01:12 +1000 (from owner-big-internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13419; Tue, 30 Jun 1992 17:05:36 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Tue, 30 Jun 92 00:05:20 -0700 Date: Tue, 30 Jun 92 00:05:20 -0700 From: Tony Li Message-Id: <9206300705.AA16942@cider.cisco.com> To: kre@munnari.oz.au Cc: pgross@ans.net, big-internet@munnari.oz.au, road@lanl.gov, iesg@nri.reston.va.us, iab@isi.edu In-Reply-To: Robert Elz's message of Tue, 30 Jun 92 16:45:54 +1000 <17773.709886754@munnari.oz.au> Subject: Draft IESG recommendation on ROAD activities The critical path is first constrained by the "standards" process (where CIDR is stuck right now -- waiting for an IP addressing plan) Exactly. This one is the problem - C# needn't be constrained by that, and that's where it gets its advantage. At this point there is no advantage. Both proposals are stuck in committee. Until there is agreement, no forward progress will occur on either. At the minute its being held up by the "political" process, people just aren't willing to say "do it". That's all it would take, nothing else is holding up C#. I suspect that if C# had been blessed back when the ID was finished cisco could probably have had C# support in release 9 of your code, but I doubt that even with CIDR known to be coming you're actively devoting much time to it yet, its still on hold, waiting other things to settle. Thanks, but our lead time is somewhat longer than you think. C# would not have made 9.0. I know of no intent to support CIDR with EGP. Does this assume that CIDR can't begin to have an effect until everyone has switched to BGP (and BGP 4 at that?) Anyone have any idea how far away that will be? It is not necessary that everyone upgrade to BGP4. Just those border routers that have a full routing table, plus those who wish to advertise an aggregate and accept default. Supporting CIDR with RIP-2 is either trivial or unnecessary, depending on how you feel about using RIP as an EGP. You're obviously only concerned with reducing backbone routing table size, which is certainly a major objective for both C# and CIDR - and maybe its CIDR's only goal, but C# does more than that, in that it allows sites that can't get a B netnumber to still have > 254 hosts on a cable if they're that way inclined. Assuming you don't change any host implementations, then you cannot make use of an unsubnetted C# address without confusing hosts. There are certainly some hacks that you can do, but they are just as bad as the current hacks which allow you to do multiple subnets per cable now. And by my thinking, the deployment of the long term solution is (by definition) the one time that we get to change all hosts. C# must not require that we change hosts. Without support for supernetting in the local environment, which includes in things like RIP (and IGRP I guess), then CIDR isn't going to do anything to help in that field, which makes it inferior to C# in this way. I disagree. Unless you are pushing around the full routing table in your IGP, there is no need for supernetting support in the IGP. The unresolved technical shortcomings of C# make it unsupportable. Tell us more of them, maybe they can be resolved? See the main one above. Given that there is no clear advantage to C#, and that CIDR is more flexible, I see no point in doing both. Maybe you're just considering interacting with hosts not upgraded to support C#? Note, there's no question that C# needs host support to work properly. That's OK with me, esp given that it can work with restrictions without it. I guess this is the sticking point. I do not think that we have the capability to change hosts in time for a short term solution. If we don't do C#, how are you going to tell customers that if they're not one of the lucky ones to get one of the few remaining class B numbers, that they can't, ever, have > 254 hosts on a net, as all that's left is class C's? That is, without one of those revolting "multiple nets on a cable" hacks (which would support C# subnetted with > 8 host bits and old hosts just as well). Revolting is in the eye of the beholder. ;-) In any case, I see this issue as actually decreasing over time. Putting more than 200 SS2's on a single Ether, for example, is a wonderful way to stress test your users. Tony From owner-Big-Internet@munnari.oz.au Tue Jun 30 18:06:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14917; Tue, 30 Jun 1992 18:06:56 +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 AA14905; Tue, 30 Jun 1992 18:06:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01029; Tue, 30 Jun 92 04:06:34 -0400 Date: Tue, 30 Jun 92 04:06:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206300806.AA01029@ginger.lcs.mit.edu> To: dee@ranger.enet.dec.com, jnc@ginger.lcs.mit.edu Subject: RE: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu You need to be told when the routing hierarchy above the net changes and it is very convenient to be able to address the network as a fixed named entity. Hmm, you've got an excellent point here. I have to go away and think about this. (I would change the word 'address' to 'name' in that sentence, though! 'address' is probably the most over-bound word we use, and it does sometimes confuse things.) Noel From owner-Big-Internet@munnari.oz.au Tue Jun 30 18:15:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15117; Tue, 30 Jun 1992 18:15:46 +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 AA15101; Tue, 30 Jun 1992 18:15:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01086; Tue, 30 Jun 92 04:15:19 -0400 Date: Tue, 30 Jun 92 04:15:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206300815.AA01086@ginger.lcs.mit.edu> To: dee@ranger.enet.dec.com, jnc@ginger.lcs.mit.edu Subject: RE: Re: meta matters ... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I think it should be possible for a host to worry about routing if it wants to. Rrr, depending on exactly what you mean here, I might agree with you. 'worry about routing' is pretty broad; could you give me some examples? Possibly a level of network hierarchy should be able to have a policy on whether, for example, it will accept packets with just IDs that have been defaulted up to it Again, I would think that the only time a router would see a packet with an ID and no sign (either in the packet, or already entered into a cache in the router) of the 'matching' address was when you are seeing packets from an unmodifed, existing, host; you only provide this capability to support incremental deployment with no mandated host changes. simple cases ... be implementable without a whole lot of horsepower. I agree, this is a good goal. Again, I'm not sure that Nimrod as I see it would not fit into such a device. Now, lots of fancy route creation algorithms, etc, etc, maybe not. On the other hand, memory is getting cheap, and it's hard to find even a PC without a 286 at least.... we have to remember to plan for technology down the road, even if it cramps our style a little bit now. Better to cramp now than be shortsighted, and run out of steam sooner than we would with a little foresight and pain now. Noel From owner-big-internet@munnari.oz.au Tue Jun 30 19:02:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16281; Tue, 30 Jun 1992 19:03:08 +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 AA15490; Tue, 30 Jun 1992 18:32:33 +1000 (from kre) To: Tony Li Cc: pgross@ans.net, big-internet@munnari.oz.au, road@lanl.gov, iesg@nri.reston.va.us, iab@isi.edu Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Tue, 30 Jun 92 00:05:20 -0700. <9206300705.AA16942@cider.cisco.com> Date: Tue, 30 Jun 92 18:32:21 +1000 Message-Id: <17881.709893141@munnari.oz.au> From: Robert Elz Date: Tue, 30 Jun 92 00:05:20 -0700 From: Tony Li Message-ID: <9206300705.AA16942@cider.cisco.com> At this point there is no advantage. Both proposals are stuck in committee. I agree here - the difference is, as I see it, that CIDR is actually waiting for good purpose, C# is just sitting there, and is "stuck" only because people seem to want it that way. And by my thinking, the deployment of the long term solution is (by definition) the one time that we get to change all hosts. C# must not require that we change hosts. Hosts are being changed all the time, changing them is OK, provided that the changes interoperate OK with unchanged hosts, or can be configured to do that. We can't require massive upgrades of everything, but we can allow upgraded hosts or nets full of upgraded hosts, to work better than old ones. There's nothing new about that. Recent useful changes have been subnetting, slow start in TCP, ... all changes in the hosts. Unless you are pushing around the full routing table in your IGP, there is no need for supernetting support in the IGP. You want it to allow some kind of larger than 254 net support. You probably even need it in hosts for this. In any case, I see this issue as actually decreasing over time. Putting more than 200 SS2's on a single Ether, for example, is a wonderful way to stress test your users. Sure - but the people who are likely to want to do this typically have 300 pc's, or macs, or something, which want IP addresses, though they mostly run spreadsheets, or word processing, or some garbage like that, and only actually use the IP stuff for 5 minutes a day or so while the user accesses his POP server to fetch mail, or perhaps for a little longer to read news. What's more, these people are often meaningless functionaries like managing directors (or their secretaries), or registrars, chancellors, etc, of universities - the kinds of people that you really don't want to be telling that they can get to use a dynamically allocated IP address, of which there aren't enough for everyone, but statistically they'll probably be able to read their mail when they want to. The more I think about this, the more important I think it is that we do C#, even if these political delays mean that it doesn't happen until after CIDR. kre