From owner-big-internet@munnari.oz.au Thu Mar 5 12:04:01 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26757; Thu, 5 Mar 1992 12:04:10 +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 AA25246; Thu, 5 Mar 1992 11:14:13 +1000 (from jch@nr-tech.cit.cornell.edu) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA27875; Wed, 4 Mar 92 20:13:48 EST Message-Id: <9203050113.AA27875@mitchell.cit.cornell.edu> To: big-internet@munnari.oz.au Subject: Scope of Class E In-Reply-To: Message from kasten@europa.clearpoint.com (Frank Kastenholz) on Mon, 16 Dec 91 10:24:14 -0500.<9112161524.AA20570@europa.clearpoint.com> Organization: Information Technologies/Network Resources; Cornell University, Ithaca, NY X-Mailer: MH [version 6.7] MH-E [version 3.7+] Date: Wed, 04 Mar 92 20:13:47 -0500 From: Jeffrey C Honig Is the Class E movement still alive? Need I worry about doing it correctly in gated? If so, what is the scope, is it 240.0.0-255.255.240? Or are there some addresses still reserved as experimental? Thanks. Jeff From owner-Big-Internet@munnari.oz.au Thu Mar 5 13:27:47 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA28871; Thu, 5 Mar 1992 13:27:59 +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 AA28868; Thu, 5 Mar 1992 13:27:47 +1000 (from swb@nr-tech.cit.cornell.edu) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA02274; Wed, 4 Mar 92 22:27:34 EST Message-Id: <9203050327.AA02274@mitchell.cit.cornell.edu> To: Jeffrey C Honig Cc: big-internet@munnari.oz.au Subject: Re: Scope of Class E In-Reply-To: Jeffrey C Honig's message of Wed, 04 Mar 92 20:13:47 -0500. <9203050113.AA27875@mitchell.cit.cornell.edu> Date: Wed, 04 Mar 92 22:27:34 -0500 From: Scott Brim Forget Class E. Too many problems with hosts, and even some routers. Instead we'll see "supernetting" where a single routing entry points to a cluster of class Cs and there are masks for each entry. From owner-Big-Internet@munnari.oz.au Fri Mar 6 01:29:39 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19289; Fri, 6 Mar 1992 01:30:14 +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 AA19278; Fri, 6 Mar 1992 01:29:39 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA07903; Thu, 5 Mar 92 10:28:07 EST Date: Thu, 5 Mar 92 10:28:07 EST From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9203051528.AA07903@animal.clearpoint.com> To: swb@nr-tech.cit.cornell.edu Subject: Re: Scope of Class E In-Reply-To: Mail from 'Scott Brim ' dated: Wed, 04 Mar 92 22:27:34 -0500 Cc: big-internet@munnari.oz.au >Forget Class E. Too many problems with hosts, and even some routers. >Instead we'll see "supernetting" where a single routing entry points to >a cluster of class Cs and there are masks for each entry. I'd agree -- the general consensus seems to be that C-sharp is the better place for it. The whole thing may be something of a moot point for the time being, since the logistic growth model has been predicting a level of between 10,500 and 11,000 class B nets consistantly over the last six months or so. From owner-Big-Internet@munnari.oz.au Sat Mar 7 07:24:52 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA04075; Sat, 7 Mar 1992 07:25:13 +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 AA04067; Sat, 7 Mar 1992 07:24:52 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA23309; Fri, 6 Mar 92 13:24:17 PST Date: Fri, 6 Mar 92 13:24:17 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9203062124.AA23309@saffron.acc.com> To: jch@nr-tech.cit.cornell.edu Subject: Re: Scope of Class E Cc: big-internet@munnari.oz.au Class E is variously reported. I would describe it as "languishing"; Some call it "dead". I personally would like to see it become "live and kicking". Fred From owner-Big-Internet@munnari.oz.au Sun Mar 15 16:42:04 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA03801; Sun, 15 Mar 1992 16:42:18 +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 AA03798; Sun, 15 Mar 1992 16:42:04 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA20527; Sun, 15 Mar 92 01:40:42 EST Date: Sun, 15 Mar 92 01:40:42 EST From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9203150640.AA20527@animal.clearpoint.com> To: Big-Internet@munnari.oz.au Subject: Draft Attached is a draft of the RFC describing the Class C# IP addresses. I'll bring some to San Diego as well. Besides dropping the idea of Class E numbers, it makes no mention of Class A# anymore -- very close to half of these numbers are already assigned. There's also a paragraph at the end making little more than a reference to the DNS problems: should we try to advocate a more specific solution, or let DNS-2 work on it? Anything else that should be discussed? ======================================================= Network Working Group F. Solensky INTERNET-DRAFT F. Kastenholz Updates: 791, 904, 1122 Clearpoint Research Corp. March 1992 A Revision to IP Address Classifications Status of this Memo This Internet Draft document will be submitted to the RFC editor as a standards document. Comments and suggestions are welcome and may be sent to the Big-Internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. Abstract This memo presents an extension to the method of classifying and assigning IP network numbers. It is intended to provide a work- around to the imminent exhaustion of assignable Class B network numbers by defining the format of Class C-sharp (C#) IP addresses, consuming the upper half of the existing Class C numbering space. The manner in which these changes impact existing systems is also discussed. It is a product of a "birds-of-a-feather" (BoF) discussion held on July 31, 1991 at the twenty-first IETF conference in Atlanta, GA and subsequent discussions on the mailing list. It should be noted that this document does NOT address the limitations inherent in the current routing architectures and technology that are discussed in [1] and [2]. These must wait until new architectures are developed. Specifically, the issue of scaling is not addressed. Background During the latter part of the 1980's, an ever-increasing number of organizations came to realize the advantage and importance of allowing their computer systems to interconnect with other systems and networks around the globe. This has both caused and reinforced the tremendous growth in the size of the Internet during this period. While this is usually seen as a positive trend, it has not been without its drawbacks. One of the more immediate problems that this sudden growth has presented is a continuing heavy demand for Class B network numbers. Of the three classes of IP network numbers, Class A (which can support up to 16,777,214 unique host identifier addresses within the Solensky, Kastenholz [Page 1] INTERNET DRAFT March, 1992 same network number), B (up to 65,532), and C (up to 254), the Class B network numbers are being assigned at the highest rate. While there are still a very large number of Class C network numbers available, few moderate-sized organizations expect that their connectivity needs will be satisfied within the limitations of 254 IP addresses, particularly if subnetting is being used. The level of demand for Class B address assignments can be illustrated by a short analysis of the data available. In the period between July 1990 and January 1992, the number of assigned Class B network numbers grew from 2533 to 6883 [4,9]; the latter figure representing just over 42% of the total available Class B network numbers. This increase averages out to an annual growth rate of over 73.7%. If this exponential trend were to continue, the pool of available Class B network numbers would be depleted by March 1993. While the authors acknowledge that a logistic or "s-shaped" curve would be a more realistic model, a projection based on this assumption would not be realistic until we have clearly passed the inflection point on the curve - the point at which the curve starts to climb less rapidly towards its upper limit. The data available at this time suggests that this leveling off has not yet occured to any significant degree: the annual growth rate in the allocation of Class B network numbers between 1983 and mid-1990 was a nearly identical 78% [8]. Whatever the exact shape of the curve, the conclusion that severe problems will erupt as a result of the exhaustion of the Class B network numbers is inescapable. The obvious corollary is that a short-term fix is necessary until the more fundamental problems referred to above can be solved. This document contains that fix. Class C-sharp Network Numbers The upper half of the Class C address space -- addresses with a prefix of '1101' -- will be used for the assignment of new Class C- sharp (C#) IP network numbers*. Within the 28 bits available in Class C# addresses, the first sixteen will define the network number and the remaining twelve will be the local address, as illustrated below. This would correspond to the IP address that fall into the range 208.0.0.0 through 223.255.255.255. * The musically inclined may appreciate the mnemonic device: the two address classes that are least likely to be further subdivided correspond to the white keys on a piano that do not have black keys a half-step above them: B and E. However, one needs to be careful not to read too much into these names since, as stated earlier, this methodology does not address the issue of scaling. Solensky, Kastenholz [Page 2] INTERNET DRAFT March, 1992 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class C-sharp address The Class C# network with an all-zero network field (IP addresses 208.0.0.0 through 208.0.15.255) will be reserved to indicate host addresses within the local network. It was felt that splitting the network and local address fields into these particular sizes met some of the more important design objectives: * The number of networks created by this division - over 65,000 - should be sufficient to meet the needs of the immediate future while other long-term solutions are being developed. The alternative of using fewer bits in the network portion of the address (including 4096 additional Class B-sized networks) had been considered but generally dismissed since the smaller count of new network numbers would allow proportionally less time to develop and deploy a replacement Internet architecture. * Many sites that are currently requesting Class B numbers do not come close to fully utilizing the address space and could easily use something a little smaller. The size of a local network in this address class - 4094 hosts in an unsubnetted environment - is large enough to be useful to many organizations without being so large that it becomes sparsely populated. It also provides a local field large enough to be separated into useful subnet and host numbers fields: the "regular" Class C addresses lack this feature. This is particularly important now that the use of variable-sized subnet masks within a given network is practical. * The creation of this new address class should sufficiently reduce the demand for the remaining Class B network numbers so that their assignment can be limited to larger sites. Another benefit of this division, while not of great import but nevertheless noteworthy, is that it keeps the division of the network and local addresses fields on nybble boundaries and thereby easier to pick out the individual fields when displayed in hexadecimal notation. The dotted-decimal notation used to express addresses does not need to be changed: one can simply refer to a block of addresses. The proposal to continue the current practice of allocating a space whose prefix started with all 1's and ended with a 0 (i.e. allocate Solensky, Kastenholz [Page 3] INTERNET DRAFT March, 1992 the prefix '11110' for Class E addresses and defining addresses with a prefix of '11111' as a reserved "Class F" space) had been considered. The problem with doing so, however, is that this practice demonstrates the law of diminishing returns: the processing overhead of separating any IP address into its network and local address fields gets increasingly complex while shrinking the reserved address space into a less useful portion - just over 3% - of the total. Another alternative that was discussed was to use the entire Class E address space in this manner and assign the upper halves of both Class A and C address spaces as new reserved address spaces. There are a number of compelling arguments against this approach: * Routers that do not explicitly recognize Class C# addresses would still be able to forward packets, since the destination address would be interpreted as belonging to a Class C network. Class E destination addresses would have to be ignored by these same routers, causing these new networks to be able to communicate with only those parts of the Internet that recognized the new address. * It had been argued that announcing the presence of a class C# address to an older router by announcing 16 consecutively-numbered Class C addresses will exacerbate the routing overhead problem in the backbone nets. However, the backbone routers can just as easily be modified to recognize the aggregatability of '1101' addresses as they can be to recognize '1111' addresses. by a trivial modification: they simply have to use a mask of FFFFF000 for the C# addresses. Routers that are not on the backbone and are not suffering from excessive numbers of routes need not be changed at all. * It has been argued that using the Class E space would be preferable to the C# space because it would be a greater incentive for vendors/authors to update their IP software to support classless routing. However, there are many boxes out there whose IP software is no longer supported, or whose owners will never get around to updating their software even if it is available. Using the Class C# address space is far more consistent with the dictum to "be conservative in what you send and liberal in what you accept from others" [6]. Exterior Gateway Protocol (EGP) The changes to the address formats described in this memo suggest some modifications to the Exterior Gateway Protocol [5]. We describe how the Class C# addresses are to be represented within the EGP messages and a methodology by which neighboring systems can reduce Solensky, Kastenholz [Page 4] INTERNET DRAFT March, 1992 the length of the routing table update messages. In order to keep the length of protocol messages down to a minimum, EGP generally represents the IP network and host numbers as variable length fields using the fewest number of bytes necessary. A Class A network number, for example, is stored in a one-byte field. The recipient of the message examines the first couple of bits of the field to determine the field's length. When a host address is specified in the message instead, the recipient will have already determined the network number; the length of this field is simply set to the number of bytes needed to complete the address. Within the EGP 'NR Poll' message, the IP Source Network number is always stored in a three-byte field. The original specification describes this field as a single byte network number followed by two bytes of zero when the network falls within the Class A address space and two bytes of network number followed by one byte of zero for Class B network numbers. This recommendation would simply rephrase the definition so that this field contains the network number, left justified and zero filled. The 'Network Reachability' (NR) message of EGP also needs to be modified when forwarding information about Class C# networks in a more substantial manner. The Gateway IP address field is long enough to hold the local portion of the address for the corresponding address class (three bytes for Class A addresses, two bytes within a Class B network, one byte for Class C). Similarly, the Network address field is of sufficient length to contain the network number that can be reached by the router whose indicated by the Gateway IP address. While keeping the message length down is desirable, it becomes far more difficult to parse the message if these fields were to become non-byte aligned. For this reason, the Gateway IP address field will, for Class C# addresses, be two full bytes in length, zero-filled on the right to maintain byte alignment. The Network address field for Class C# addresses will be three bytes long, zero filled on the left. This will remove the need for additional shift operations when reassembling a Class C# address from the message: the third byte of an address is restored through a logical OR operation between the final byte of the Gateway IP address field and the first byte of the Network address field Using these modifications, EGP neighbors that both recognize Class C# addresses will not have much trouble interoperating. However, it is desirable for the neighbor systems to be able to know beforehand if the other will be able to recognize the aggregation of the C# network numbers or if the destination network needs to be described to a less up-to-date router as sixteen separate Class C networks that happen to be consecutively numbered. Solensky, Kastenholz [Page 5] INTERNET DRAFT March, 1992 A reasonably straightforward means to determine this is to use a new code value in the Neighbor Acquisition message. A code value of 5 would indicate to the recipient that the sender recognizes this new address class. If the neighbor is cognizant of Class C# addresses, it responds with a Confirm response (type 3, code 1) and moves into "Down" state; otherwise, it is expected to send a Refuse response due to what it believes to be an invalid command (type 3, code 2, status 7) or an Error response on a bad EGP header (type 8, reason 1) and returns to the "Idle" state. Upon receiving this rejection, the originating system becomes aware that the receipent does not recognize the aggregation of Class C# addresses and can fall back on sending the traditional Request command (type 3, code 0). If this second attempt is successful, the Class C# networks that are to be announced into the neighboring autonomous system will have to be described as sixteen different Class C networks. This process of receiving an error indication and forming a new request has the effect of creating an additional state. It is labeled as "Aqsn-2" in the state-machine diagram that follows. +-------+ | |<--------------------------------+-------------+ +----->| Idle |-----------------------------+ A A | | |<---------------+ Request| | | | +-------+ A | | | | | A |Cease | |Cease |Cease | Start| |Cease |Refuse | | | | V | | V | | | +-------+ Refuse +-------+ +-------+ Up +-------+ | | |----------->| | | |------>| | | | Aqsn | |Aqsn-2 | | Down | Down | Up | | | |--------+ | | | |<------| | | +-------+ Confirm| +-------+ +-------+ +-------+ | | | | |Confirm A | | |Stop |Stop V | V | | | |Cease-ack V +-----(---+----------+ |Stop |Stop | +-------+ Stop| | | | | | V V V +------| Cease |<-------------+------------------+-------------+ | | +-------+ Domain Name Servers Another consideration that needs to be addressed is the impact this change will have on various Domain Name Servers. Current implementations make the assumption that the While it would take relatively little time to add sixteen individual NS records, this Solensky, Kastenholz [Page 6] INTERNET DRAFT March, 1992 could easily cause the files to become extraordinarily large shortly after this address class becomes official. This is not considered to be the optimal solution: more specific ones are beyond the scope of this document. Conclusions It must be emphasized that the use of Class C# network addresses is intended only to be a work-around to the immediate problem. It is by no means a solution. While it defines a new class of address numbers that allows four times the number of networks of the original Class B space, this scheme will survive less than three years if current growth rates continue. By that time, it is expected that the increased amount of network connectivity which has been exhibiting similar growth rates [7,8] will cause the computational intensity of keeping track of these routes to require an entirely different routing and addressing architecture for the Internet such as one of the solutions outlined in [1]. This change also points out the necessity of having hosts not pry into address formats. It is plausible to deploy a new network number format if only the routers have to be changed; doing so in a world where most types of host software have to be changed as well is clearly problematic. References: [1] "The IP Addressing Issue", J. Noel Chiappa, Internet Draft, October, 1990. [2] "Towards the Future Architecture", D. Clark, L. Chapin, V. Cerf, R. Braden, RFC 1287, SRI International, December 1991. [3] "Host Extentions for IP Multicasting", S. Deering, RFC 1112, SRI International, August 1989. [4] "Internet Numbers", S. Kirkpatrick, M. Stahl, M. Recker, RFC 1166, SRI International, July 1990. [5] "Exterior Gateway Protocol Formal Specification", D.L. Mills, RFC 904, SRI International, April 1984. [6] "Transmission Control Protocol", J. Postel, RFC 793, SRI International, August 1980. [6] "Growth of the Internet", Mike St. Johns, Proceedings of the Thirteenth Internet Engineering Task Force, April 11-14, 1989, pages 244-248. Solensky, Kastenholz [Page 7] INTERNET DRAFT March, 1992 [7] "Continued Internet Growth", Frank Solensky, Proceedings of the Eighteenth Internet Engineering Task Force, July 30-August 3, 1990. pages 59-61. [8] Internet Monthly Report, A. Westine [ed], September, 1991. Authors' Address: Frank Solensky Frank Kastenholz Clearpoint Research Corp. 35 Parkwood Drive Hopkinton, MA 01748 Phone: (508) 435-2000 Email: solensky@clearpoint.com, kasten@clearpoint.com Solensky, Kastenholz [Page 8] From owner-Big-Internet@munnari.oz.au Tue Mar 17 07:51:19 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26391; Tue, 17 Mar 1992 07:51:40 +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 AA26383; Tue, 17 Mar 1992 07:51:19 +1000 (from kre) To: big-internet@munnari.oz.au Subject: recent files on munnari Date: Tue, 17 Mar 92 07:50:59 +1000 Message-Id: <18708.700782659@munnari.oz.au> From: Robert Elz Frank Solensky's C# draft is in big-internet/rfc-bigip.txt Vince Fuller (et al)'s address assignment and aggregation draft is in big-internet/draft-fuller-addressing Both available via anon ftp of course, from munnari.oz.au [128.250.1.21]. kre From owner-Big-Internet@munnari.oz.au Wed Mar 18 23:17:55 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA01958; Wed, 18 Mar 1992 23:17:59 +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 AA01955; Wed, 18 Mar 1992 23:17:55 +1000 (from kre) To: big-internet@munnari.oz.au Subject: More files to fetch... Date: Wed, 18 Mar 92 23:17:41 +1000 Message-Id: <19215.700924661@munnari.oz.au> From: Robert Elz The "rfc-bigip.txt" file has been updated (about 18 hours or so ago actually, so if you have fetched it recently no need bother again). Apart from a few cosmetic changes, the following paragraph was added (by Frank)... Border Gateway Protocol (BGP) The Border Gateway Protocol (BGP) as currently defined allows the version number to be negotiated between neighboring systems when the session is first established. BGP version 4 would indicate that the system is able to recognize the Class C# address class. When a version 4 implementation wishes to announce a single Class C# address to a version 3 implementation, it would present it as sixteen consecutively numbered Class C networks. Simirly, a version 4 implementation would be able to aggregate the same sixteen Class C networks into a single Class C# network number. Any other extentions to the BGP protocol that may also be included in this new version (eg: netmasks) is beyond the scope of this document. Also, the file pix.ps is in the big-internet directory, Frank's message about it is appended... kre ------- Forwarded Message From: solensky@animal.clearpoint.com (Frank T. Solensky) Date: Wed, 18 Mar 92 01:24:49 EST To: kre@munnari.oz.au Subject: Pictures Robert -- I just sent over some postscript graphs that will be interesting to the big-internet list. (/tmp/pix.ps). It's a series of four graphs that paint a bleak picture if current trends continue. 1) A graph of the assignment of Class B addresses. There's also two separate trend lines projected onto it -- one reflects an exponential grouth curve (where there's a continued constant percentage growth every year), the other being a logistic growth curve (the growth rate is a function of the current population and tends to level off at a given maximum). 2) The good news. For the logistic model, how the predicted maximum number of class B nets change. It's dropped from a high of around 12,000 nets to a current level of about 10,500. This illustrates the benefits of the change in the NIC policy of assigning a set of Class C net numbers rather than a single class B number: this ceiling value has been holding steady for about six or eight months. 3) The bad news. Another logistic model -- the number of networks in the NSFNET routing tables. Note how the last three points jump over the predicted values and the rest of the actual data points. This corresponds to about the same time that groups of Class C net numbers are assigned instead of B's. 4) The really bad news: this corresponds to the second graph: the predicted "ceilings" given the data up to the time along the X-axis. It becomes very clear that fixing one problem is creating another much sooner -- Frank ------- End of Forwarded Message From owner-Big-Internet@munnari.oz.au Tue Mar 24 02:17:51 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12144; Tue, 24 Mar 1992 02:18:17 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9203231618.12144@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12133; Tue, 24 Mar 1992 02:17:51 +1000 (from ULLMANN@PROCESS.COM) Date: Mon, 23 Mar 1992 11:16 EST From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: ietf@isi.edu Cc: big-internet@munnari.oz.au Subject: re: routing vs ADs Hi, I had asked that this be taken to Big-Internet at the very start. Note that: "all service providers are ADs" does NOT imply "all ADs are service providers" (logical fallacy). I suppose I should have made this clearer. Most organizations big enough to be multi-homed will certainly not rely on one provider's AD; NRL, for example, would probably belong to a US goverment AD, not any provider's. Further: as I said several times: the AD implies at most default routing. If our routing technology is good enough, we may be able to _always_ route on AD+net (meaning: the AD is "just bits" in the net identifier.) With DNS routing, one can go to host level without any scaling problems (that we can see from here :-). Please reply to big-internet@munnari.oz.au or privately to ariel@process.com With my best regards, Robert Ullmann From owner-Big-Internet@munnari.oz.au Tue Mar 24 08:40:38 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21020; Tue, 24 Mar 1992 08:40:52 +1000 (from owner-Big-Internet) Return-Path: Received: from SGI.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA21014; Tue, 24 Mar 1992 08:40:38 +1000 (from probins@bubba.wpd.sgi.com) Received: from [192.26.75.178] by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for big-internet@munnari.oz.au id AA15366; Mon, 23 Mar 92 14:40:22 -0800 Received: by bubba.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:big-internet@munnari.oz.au id AA12839; Mon, 23 Mar 92 14:40:21 -0800 Date: Mon, 23 Mar 92 14:40:21 -0800 From: probins@bubba.wpd.sgi.com (Paul Robins) Message-Id: <9203232240.AA12839@bubba.wpd.sgi.com> To: big-internet@munnari.oz.au Subject: ADD to mailing list Please add me to the mailing list. Thanks. --Paul "hakuna matata" probins@sgi.com Paul Robins Mail Stop 9U-510 (415) 335-1282 Silicon Graphics Computer Systems 2011 N. Shoreline Blvd. (415) 969-2314 (fax) Mt. View, CA 94039 From owner-big-internet@munnari.oz.au Wed Mar 25 00:34:17 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16350; Wed, 25 Mar 1992 00:34:19 +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 AA15783; Wed, 25 Mar 1992 00:05:35 +1000 (from swb@nr-tech.cit.cornell.edu) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA05528; Tue, 24 Mar 92 09:04:27 EST Message-Id: <9203241404.AA05528@mitchell.cit.cornell.edu> To: ULLMANN@process.com (Robert L Ullmann) Cc: big-internet@munnari.oz.au Subject: Re: ToasterNet Part II In-Reply-To: Robert L Ullmann's message of Thu, 19 Mar 92 17:20:00 -0500. <199203192223.AA21926@venera.isi.edu> Date: Tue, 24 Mar 92 09:04:26 -0500 From: Scott Brim A somewhat short response... >Date: Thu, 19 Mar 1992 17:20 EST >From: ULLMANN@process.com (Robert L Ullmann) >To: ietf@ISI.EDU >Subject: ToasterNet Part II >Is 64 Bits Enough?: While it's true that if we were able to use all the theoretically available addresses, 8 bytes would be enough for a long time. However, you just can't. Remember we're trying to engineer for the Vint Cerf's vision of 10^9 domains and about 10^12 end addresses. 10^9 is about 2^30. In your plan you had just two levels above host. Suppose there are a few thousand domains at the top level, like now (O(10^3)) (this is likely -- the top level will be large carriers, right?). Then the middle level is going to have to handle *at least* 10^6 unaggregated routes??? First, the number would actually be much more than that because when the addresses are structured you have a *lot* of wasted addresses (it would only be exactly 10^6 routes if hosts were perfectly distributed across networks and networks were perfectly distributed across carriers). Also, even if you aggregate a' la CIDR, without any more structure than this you aren't going to get more than an order of magnitude of aggregation, so you still have O(10^5) routes. A router *could* handle this, but it just wouldn't be all that efficient. It's more reasonable to add *at least* one more level of structure to your addresses. That means more unused addresses and more restriction on how addresses are assigned, but more efficiency and manageability. However when you add that extra level and extra "wasted" addresses you can't fit into 64 bits anymore. Dave Oran says in his experience (in DEC networks???) that with three levels of hierarchy above host you're extremely lucky if you can even use 1% of the available addresses (0.01 = 2^-6.6). >(So why does OSI think it needs 160 bits? That's enough to count all >the hydrogen atoms, at least in the local globular cluster ...) First a bunch of the leading fields are not part of the address per se, for example the Address Format Indicator. Second, the last 7 bytes are the host address and the port selector. As far as I can tell (and I'm not an authority), above the level of an "area" you really only have 7 bytes of interesting stuff to route on, divided into three fields (three Administrative Authority bytes, two Reserved bytes, and two Routing Domain bytes). On the other hand this is just one way of carving up an NSAP. Personally, given the way address spaces are wasted when they are assigned hierarchically, I wonder whether even this would be enough space. What I'm told is that NSAPs are designed for extreme flexibility, including variable length, and hosts are supposed to run with dynamic prefix assignment, so if address formats are ever a problem we could just create a a new one and they would all coexist happily. Scott From owner-Big-Internet@munnari.oz.au Wed Mar 25 02:23:36 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA18760; Wed, 25 Mar 1992 02:23:56 +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 AA18757; Wed, 25 Mar 1992 02:23:36 +1000 (from swb@nr-tech.cit.cornell.edu) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA02994; Tue, 24 Mar 92 11:23:16 EST Message-Id: <9203241623.AA02994@mitchell.cit.cornell.edu> To: ULLMANN@process.com (Robert L Ullmann) Cc: big-internet@munnari.oz.au Subject: Re: routing vs ADs In-Reply-To: Robert L Ullmann's message of Mon, 23 Mar 92 11:16:00 -0500. <9203231618.12144@munnari.oz.au> Date: Tue, 24 Mar 92 11:23:16 -0500 From: Scott Brim Hi. I must have missed the message this one refers to. Could you explain a couple of things? >Date: Mon, 23 Mar 1992 11:16 EST >From: ULLMANN@PROCESS.COM (Robert L Ullmann) >To: ietf@isi.edu >Cc: big-internet@munnari.oz.au >Subject: re: routing vs ADs >Further: as I said several times: the AD implies at most default >routing. If our routing technology is good enough, we may be able Are you saying, perhaps, that routing information carried within a routing domain will be reduced by defaulting to sending to a higher-level AD? >With DNS routing, one can go to host level without any scaling >problems (that we can see from here :-). What's "DNS routing"? Translating directly from a name (a globally unique identifier with no coupling to topological relationships) to a route (not just an address) to the named destination?? Thanks ... Scott From owner-Big-Internet@munnari.oz.au Wed Mar 25 02:56:14 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19530; Wed, 25 Mar 1992 02:57:05 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9203241657.19530@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA19513; Wed, 25 Mar 1992 02:56:14 +1000 (from ULLMANN@PROCESS.COM) Date: Tue, 24 Mar 1992 11:53 EST From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: FWD: Re: routing vs ADs > From: Scott Brim Hi, I'll keep this shorter than the last. I think. > Hi. I must have missed the message this one refers to. Could you > explain a couple of things? [multiple >> elided] > Are you saying, perhaps, that routing information carried within a > routing domain will be reduced by defaulting to sending to a > higher-level AD? An AD is an administrative domain. It does not _necessarily_ have anything to do with routing. It _may_, of course, be a useful aggregate; useful enough that we _might_ require an AD to be able to route for all nets defined within it. But this is not built in. I have noticed a tendency (I'm not referring to you in particular Scott :-) to confuse _administrative_ assignments of what are really just number ranges, with _operational_ aggregation for routing. There may, of course, be some useful correlation, but it is NOT an imperative, and indeed is probably to be avoided whenever possible. (I.e. whenever our routing technology is good enough.) Just because I get my net number through JvNCnet today, doesn't mean it isn't _permanently_ mine; if in the future it is assigned out of JvNCnet's block, it may still be a permanent assignment. (other ADs, meaning the telcos, will insist that they "own" their blocks. Fine. For those blocks. Customers who want independence will get their numbers elsewhere, and won't use telco's IP layer service :-) If an organization really severs all relationship with the AD that provided its number(s), it probably should change. But if I am NRL, and got my net number from the US DoD AD, I won't expect to change. > What's "DNS routing"? Translating directly from a name (a globally > unique identifier with no coupling to topological relationships) to a > route (not just an address) to the named destination?? See RFC1183 3.3. The idea is to translate from a name to a preference list of routers to reach that host, very much like MXs are used for mail. To answer your question directly: yes. IP number -> host name -> RT records -> host -> A, X25 or ISDN rcords. Cheers, Rob From owner-big-internet@munnari.oz.au Wed Mar 25 03:52:22 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20553; Wed, 25 Mar 1992 03:52:35 +1000 (from owner-big-internet) Return-Path: Message-Id: <9203241752.20553@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA19131; Wed, 25 Mar 1992 02:40:17 +1000 (from ULLMANN@PROCESS.COM) Date: Tue, 24 Mar 1992 11:36 EST From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: FWD: Re: ToasterNet Part II > From: Scott Brim > Remember we're trying to engineer for the Vint Cerf's vision of 10^9 > domains and about 10^12 end addresses. 10^9 is about 2^30. In your > plan you had just two levels above host. Suppose there are a few > thousand domains at the top level, like now (O(10^3)) (this is likely -- > the top level will be large carriers, right?). Then the middle level is > going to have to handle *at least* 10^6 unaggregated routes??? First, > the number would actually be much more than that because when the > addresses are structured you have a *lot* of wasted addresses (it would > only be exactly 10^6 routes if hosts were perfectly distributed across > networks and networks were perfectly distributed across carriers). Hi Scott, Note (again :-) "all large carriers are ADs" does NOT imply "all (or even most) ADs are large carriers" (Why are so many people concluding this? Understand that we are going to be using several different allocation/routing/administration methods, just as we are now.) I also said "most organizations are not ADs". I.e. SOME organizations are ADs. Presumably large ones, particularily those with international operations. I would expect the number of ADs to be initially O(10^3) as you say, but to grow to order 10^5 or more in the visible future. Eventually there may be O(10^6) Also: I did NOT say that agggregation would not be used; I implied exactly the opposite, mentioning masks in the range (AD only) to (all but the last 2 bits), and pointing out that routers would use as much of AD+NET as possible. It would be using both aggregation and the multihomed routing methods of Fuller's Supernet. Some "middle levels" would have O(10^7) or more routes (e.g. the NANP-area example), but may very well have their own unique methods of doing it. (Mapping net to part of the E.164 address, again as in the example). Others may have many fewer nets. Remember that as you go (down) past each split in the hierarchy, there may be different methods used, just as one AS can use a different IGP from another today. Some ADs may actually define a (another) fixed division somewhere in the last 40 bits. And so forth. I'm not trying to exclude these other methods; I expect all of them to be brought to bear on the problem. An individual routing layer today can (just) handle O(10^5) routes (the low end of that magnitude); I don't think it is unreasonable at all to expect mid-level network routers 10 years from now to handle O(10^7). (I'm not talking about a single Wellfleet/cisco whatever box here; I'm talking about the kind of routing node that consists of one-each fast processor per line, linked in a Gbit rate ring, with a couple of more boxes for management and routing, that can handle 10's of DS3s :-) 10^9 (people) by 10^3 (boxes) < 10^5 (ADs) by 10^6 (nets) by 10^3 (boxes) As long as we make sure the number of ADs stays within the state of the routing art over time, and each AD can use its own methods to keep its net count within its capabilities, we don't break down. This is at worst; I expect routing to do a lot better than that, giving us a lot of flexibility. Methods of the BGP class could do very well with the kind of bandwidth and computrons needed to do (e.g.) HDTV video. I.e., just to play Devil's Advocate, suppose we just had ONE level of hierarchy, with all 10^9 nets. We run HyperBGP: Each net has (say) 16 bytes of information (net+route+metric) = 16 GBytes of state (no mask in this BGP, remember. Just one layer of routing :-) To initialize the route, we need, worst case, to send it _all_. At 1 Mbit: 128,000 seconds (1 1/2 days) At 100 Mbit: 1,280 seconds (21 minutes) At 1 Gbit: 128 seconds (2 minutes) The processor has to (at 1 Gbit) receive and store one entry every 128 nsec; with a 200 Mip processor, it has about 20 instructions to do it. (With this flat address space, we can use static or at least pre-assigned slots.) This is the initialization that takes this long. After the initialization, the changes will consume much less, and we'll be able to use some bandwidth for payload. (With full payload on the parallel circuits all the time, of course.) Given multiplexed channels and processors (Sequent Symmetry, separate channels on the fiber), it is somewhat less demanding. Or can be done even faster. This can be done on general purpose machines now (not cheaply, of course! Cray in your router sir?), with purpose-built hardware it is easier; with advances in technology it will only get easier still. Given a future Internet handling all of the world's data/voice/video on Gbit+ rate lines, the routing becomes simply a matter of telling all core routers everything .... >grin< British Telecom has done serious work on this, to try to assign everyone (presumably meaning everyone in the UK :-) a personal phone number, routed to wherever that person is at the moment. The implementation method suggested is simply to broadcast the entire route map on a fibre* channel in a continuous repeat. The switches do _not_ store it! They just grab what they need as it goes by. (Understanding that voice call setup can reasonably take a little longer than routing a packet.) (They use "fibre" there. I'm not sure how that is different from "fiber". Perhaps the bits are left handed. :-) Enough for one message. With my best regards, Robert Ullmann Process Software Corporation From owner-Big-Internet@munnari.oz.au Wed Mar 25 08:08:20 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26146; Wed, 25 Mar 1992 08:08:37 +1000 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26141; Wed, 25 Mar 1992 08:08:20 +1000 (from bsimpson@vela.acs.oakland.edu) Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA23718; Tue, 24 Mar 92 17:08:08 -0500 Date: Tue, 24 Mar 92 13:35:24 PST From: "William Allen Simpson" Message-Id: <9.bsimpson@vela.acs.oakland.edu> To: big-internet@munnari.oz.au Cc: ietf@isi.edu Reply-To: bsimpson@rigel.acs.oakland.edu Subject: automagic address assignment Recently, I saw an interesting program used by BARRnet to do address assignment. I suggest that it could be used remotely by the various other service providers to do their addresses *ONLINE*. This would greatly speed up the process, and quickly begin CIDR address assignment. 1) All address assignment would be moved to a primary server at BARRnet, which (unlike NIC.DDN.MIL) has T3 connectivity. 2) BARRnet would create the various access ids for the other providers, and (at the same time) apportion the B and C address blocks. 3) The NIC would be just another provider, responsible for its portion of the address space. 4) The NSF funding would be diverted to BARRnet to pay for the expense of running the database, and the extra time for oversight. I submit this would still be less expensive than the current effort, as the actual data entry would done by the providers. 5) This could be done in a very short time (days or weeks). 6) The initial address assignment, and future address changes, should be considerably improved, since we have closer contact with our providers than with the NIC. My experiences with the new NIC has been less than delightful. It took months to assign me a new address, and then they discovered that they had multiply assigned that address. Four months have passed, and nothing is yet available in the whois or network-contacts databases. Unfortunately, I am not a BARRnet customer, nor in any way affiliated with BARRnet, so I can't say how they would take this suggestion. But it seems a fast way to implement the suggestions from the last IETF. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From owner-big-internet@munnari.oz.au Thu Mar 26 02:54:01 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25396; Thu, 26 Mar 1992 02:54:08 +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 AA23211; Thu, 26 Mar 1992 01:18:33 +1000 (from kre) To: big-internet@munnari.oz.au Subject: Big-Internet list and latest draft rfc Date: Thu, 26 Mar 92 01:18:15 +1000 Message-Id: <22618.701536695@munnari.oz.au> From: Robert Elz Everyone receiving this message is on the Big-Internet mailing list (as are a few others who won't receive it because their mailers seem to be broken, or because they're on milnet which won't let (most of) Australia talk to it any more). That is just because there seem to be a few people who have forgotten ... yes, traffic has been light until quite recently. To be removed, or change the address this list is sent to, please send a message to big-internet-request@munnari.oz.au. Archives of past traffic are in the big-internet/list-archive directory on munnari.oz.au. There's a new C-sharp draft in the big-internet directory, as detailed below in a message I received from Frank (which I edited a little to include the file name, etc). kre ------- Forwarded Message From: solensky@animal.clearpoint.com (Frank T. Solensky) Date: Wed, 25 Mar 92 02:44:15 EST To: kre@munnari.oz.au Subject: New C-sharp draft. There's a new copy of the C-sharp draft RFC in big-internet/rfc-bigip.txt.2 on munnari.oz.au [128.250.1.21]. The changes since last week are: > Adds a section on interrelationship between this and CIDR: it's presented as a first step towards CIDR rather than an either/or choice that must be made between the two (I still tend to see this as needing less time to implement and not coming at the expense of CIDR). > Background section quotes stats of growth of routing tables; offers this as a way of keeping table growth down between C# deployment and CIDR. > Section on BGP more specifically describes "BGP 4" as differing only in that C# addreses are recognized. The real BGP-4 becomes BGP-5. > Security concerns (specifically, the lack thereof) are mentioned. At this point, my feeling is that the two efforts are compatible but won't be terribly surprised or disappointed if this doesn't come to pass: time is, after all, of the essence (again, sorry for the amount of time it took to get the changes discussed during Sante Fe out). If there aren't any objections within the next week or so, I'll let Noel know that this can be considered submitted. -- Frank S "I'd call him a sadistic equine necrophiliac, but that would be beating a dead horse" -- Woody Allen ------- End of Forwarded Message From owner-Big-Internet@munnari.oz.au Thu Mar 26 05:40:56 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA28940; Thu, 26 Mar 1992 05:41:28 +1000 (from owner-Big-Internet) Return-Path: Received: from aotearoa.sura.net by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA28935; Thu, 26 Mar 1992 05:40:56 +1000 (from sherk@sura.net) Received: by aotearoa.sura.net with SMTP (5.65b/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id AA11735; Wed, 25 Mar 92 14:40:16 -0500 Message-Id: <9203251940.AA11735@aotearoa.sura.net> To: Scott Brim Cc: ULLMANN@process.com (Robert L Ullmann), big-internet@munnari.oz.au Subject: Re: routing vs ADs In-Reply-To: Your message of "Tue, 24 Mar 92 11:23:16 EST." <9203241623.AA02994@mitchell.cit.cornell.edu> Date: Wed, 25 Mar 92 14:40:16 -0500 From: Erik Sherk > > What's "DNS routing"? Translating directly from a name (a globally > unique identifier with no coupling to topological relationships) to a > route (not just an address) to the named destination?? What I think he is refering to is called "ENCAPS" or IP-IP. It was the proposal not put forth by Ross Callon in the IP addressing issues BOF (I'm sorry, I can't remember his name). In this scheme, within an AD, IP works the same way that we know and love, but when you send a packet outside of your AD, the border router would perform a DNS lookup of the PTR record for that IP address. Then it would lookup a new DNS record type (type RD for routing domain ? :-). The result of this second lookup is an IP address that is associated with the AD of the destination host. The IP packet is then encapsulated in another IP packet and routed between border routers. When it reaches the destination AD, it is unencapsulated and sent on its way to the destination host. This scheme has several neat properties. Host IP addresses remain globally unique. All routes within an AD can be aggregated into one route, thus greatly reducing the global routing table. It separates the host ID from the network ID, thus allowing easy switching of carriers. And finnaly, the same tools can be used both inside an AD and outside an AD for network trouble shooting. Erik From owner-big-internet@munnari.oz.au Thu Mar 26 06:44:28 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA00451; Thu, 26 Mar 1992 06:44:36 +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 AA29723; Thu, 26 Mar 1992 06:17:21 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 25 Mar 92 12:16:52 -0800 Date: Wed, 25 Mar 92 12:16:52 -0800 From: Tony Li Message-Id: <9203252016.AA22806@lager.cisco.com> To: kre@munnari.oz.au Cc: big-internet@munnari.oz.au In-Reply-To: Robert Elz's message of Thu, 26 Mar 92 01:18:15 +1000 <22618.701536695@munnari.oz.au> Subject: Big-Internet list and latest draft rfc From: solensky@animal.clearpoint.com (Frank T. Solensky) > Adds a section on interrelationship between this and CIDR: it's presented as a first step towards CIDR rather than an either/or choice that must be made between the two (I still tend to see this as needing less time to implement and not coming at the expense of CIDR). I'm not conviced that it takes significantly less time to implement. Let me stick to the technical side of things: For CIDR: Hack BGP & IDRP to include a prefix and AS_SET capabilities. For C#: Hack EGP & BGP & IDRP to deal with a new class. I will be the first to admit that it will take me an extra day or two to do the additional stuff for CIDR. Is this significant? I don't think so. Consider that this difference is dwarfed by the beta testing and deployment time in either case, I don't see any difference. Tho I do appreciate that you're happy to change the solution to save me a couple days. ;-) Tony From owner-Big-Internet@munnari.oz.au Thu Mar 26 07:23:46 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA01121; Thu, 26 Mar 1992 07:24:13 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9203252124.1121@munnari.oz.au> Received: from vtvm2.cc.vt.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA01111; Thu, 26 Mar 1992 07:23:46 +1000 (from @VTVM2.CC.VT.EDU:ALGOLD@LNCC2.BITNET) Received: from LNCC2.BITNET by VTVM2.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 3949; Wed, 25 Mar 92 16:23:17 EST Received: by LNCC2 (Mailer R2.05) id 5798; Wed, 25 Mar 92 18:22:12 BS3 Date: Wed, 25 Mar 92 18:18:57 BS3 From: Alexandre Leib Grojsgold Subject: OSPF/BGP availability To: big-internet@munnari.oz.au Reply-To: Algold%LNCC2.bitnet@VTVM2.CC.VT.EDU Can someone give me some pointers to available, FTPable, and reliable (is it ask too much?) implementations of OSPF and/or BGP, that would run on a SUN workstation? Thanks, Alexandre. From owner-Big-Internet@munnari.oz.au Thu Mar 26 10:46:49 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA06894; Thu, 26 Mar 1992 10:47:13 +1000 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA06877; Thu, 26 Mar 1992 10:46:49 +1000 (from bsimpson@vela.acs.oakland.edu) Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA17535; Wed, 25 Mar 92 19:46:34 -0500 Date: Tue, 24 Mar 92 18:43:10 PST From: "William Allen Simpson" Message-Id: <13.bsimpson@vela.acs.oakland.edu> To: postel@isi.edu Cc: big-internet@munnari.oz.au Reply-To: bsimpson@rigel.acs.oakland.edu Subject: automagic address assignment > From: postel@isi.edu > > Alternatively, maybe BARNET could make the program available to every > service provider and the NIC and the IANA so that each could manage > their portion of the address space as they see fit with this wonderfull > tool. > You couldn't pass this around to each of the providers, since the root of .COM or .EDU or whatever has to be maintained in the same place. Also, the whois, network- and domain- contact files. But a remote access program to do this is just what we need to remove the NIC bottleneck. And the BARRnet T3 connectivity is a real plus. > Who can i talk to to fine out more about this program? > I was watching over the shoulder of Vince Fuller at a terminal. Apparently, they allow their clients to manage their DNS entries remotely with this. When I asked him about it, he said it ran on a database program at Stanford, and that there was no reason that we couldn't use it for the entire Internet, but there's some sort of royalty fee structure involved. Unfortunately, this was after the IETF, or I would have raised it sooner. Perhaps there's a reason why he hasn't? Those BARRnet folks just don't seem to blow their own horn as loudly as, for example, CERFnet. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From owner-Big-Internet@munnari.oz.au Thu Mar 26 15:06:36 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA15200; Thu, 26 Mar 1992 15:06:48 +1000 (from owner-Big-Internet) Return-Path: Received: from wraith.internode.com.au by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA15185; Thu, 26 Mar 1992 15:06:36 +1000 (from simon@internode.com.au) Received: by wraith.internode.com.au (5.64+1.3.1+0.50/UA-5.23) id AA07816; Thu, 26 Mar 1992 14:36:15 +0930 From: Simon Hackett Message-Id: <9203260506.AA07816@wraith.internode.com.au> Subject: CIDR? To: big-internet@munnari.oz.au Date: Thu, 26 Mar 92 14:36:13 CST X-Mailer: ELM [version 2.4dev PL17] Sorry if I've missed a train of thought somewhere, but what is "CIDR"? I heard this term being used during the ietf in San Diego (I was listening via Internet Audioconference), but nonone I heard actually *explained* it. I understand the C# proposals. Where does CIDR fit in? Simon {------------------------------------------------} { Simon Hackett, Internode Systems Pty Ltd } { E-mail: simon@internode.com.au } { Phone: +61 8 373 1339 Fax: +61 8 373 4911 } { Mail: PO Box 69, Daw Park, SA 5041 AUSTRALIA } {------------------------------------------------} From owner-Big-Internet@munnari.oz.au Thu Mar 26 18:33:40 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21469; Thu, 26 Mar 1992 18:33:49 +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 AA21456; Thu, 26 Mar 1992 18:33:40 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 25 Mar 92 23:34:53 -0800 Date: Wed, 25 Mar 92 23:34:53 -0800 From: Tony Li Message-Id: <9203260734.AA16387@lager.cisco.com> To: simon@internode.com.au Cc: big-internet@munnari.oz.au In-Reply-To: Simon Hackett's message of Thu, 26 Mar 92 14:36:13 CST <9203260506.AA07816@wraith.internode.com.au> Subject: CIDR? Sorry if I've missed a train of thought somewhere, but what is "CIDR"? I heard this term being used during the ietf in San Diego (I was listening via Internet Audioconference), but nonone I heard actually *explained* it. I understand the C# proposals. Where does CIDR fit in? CIDR stands for "Classless Inter-Domain Routing". It would be used in conjunction with another concept called "Supernetting". In supernetting, a number of network numbers which form a power-of-two block can be tied together and advertised as a single route. This is initially done with Class C network numbers, but in principle can be applied anywhere. The entire block of addresses can be advertised as a single route by also passing some indication of the significant bits (e.g., a mask). So the block of class C's 200.200.0.0 - 200.200.255.0 could be advertised as: 200.200.0.0 255.255.0.0. By assigning large blocks of class C's to service providers and authorizing them to assign these addresses to their clients, the service provider can advertise their entire portion of the network with a single supernet route. This also requires protocol support, which is where CIDR comes in. By passing the indication of the significant bits in the inter-domain protocol, we make that protocol "classless". For more information, please grab the file valinor.stanford.edu:pub/supernet.txt via anonymous ftp. Tony From owner-Big-Internet@munnari.oz.au Fri Mar 27 03:42:45 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA07172; Fri, 27 Mar 1992 03:42:56 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA07168; Fri, 27 Mar 1992 03:42:45 +1000 (from gmalkin@ftp.com) Received: by ftp.com id AA12548; Thu, 26 Mar 92 12:41:17 -0500 Date: Thu, 26 Mar 92 12:41:17 -0500 From: gmalkin@ftp.com (Gary Scott Malkin) Message-Id: <9203261741.AA12548@ftp.com> To: swb@nr-tech.cit.cornell.edu Cc: ULLMANN@process.com, big-internet@munnari.oz.au In-Reply-To: Scott Brim's message of Tue, 24 Mar 92 09:04:26 -0500 <9203241404.AA05528@mitchell.cit.cornell.edu> Subject: ToasterNet Part II All discussions of hierarchy have thus far been based on structuring a single address. This may in fact be the way to go, but we should consider alternatives before we lose sight of the fact that there are alternatives. Consider that there may be advantages to having a network number as a distinct field from the host number, as XNS does, rather than structuring a 64 bit address. One obvious advantage is that traffic between hosts on the same network (which does not necessarily mean the same wire), could specify a "this net" address (which would make multicasting easier). Gary (from the Norse meaning "Thrower of Spears") From owner-Big-Internet@munnari.oz.au Fri Mar 27 03:53:50 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA07392; Fri, 27 Mar 1992 03:54:09 +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 AA07381; Fri, 27 Mar 1992 03:53:50 +1000 (from swb@nr-tech.cit.cornell.edu) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA04956; Thu, 26 Mar 92 12:52:00 EST Message-Id: <9203261752.AA04956@mitchell.cit.cornell.edu> To: gmalkin@ftp.com (Gary Scott Malkin) Cc: big-internet@munnari.oz.au Subject: Re: ToasterNet Part II In-Reply-To: Gary Scott Malkin's message of Thu, 26 Mar 92 12:41:17 -0500. <9203261741.AA12548@ftp.com> Date: Thu, 26 Mar 92 12:51:59 -0500 From: Scott Brim Paul Tsuchiya is finishing up a proposal along these very lines which I'm looking forward to (AND I WISH HE WOULD HURRY UP -- HEAR THAT, PAUL?). >Consider >that there may be advantages to having a network number as >a distinct field from the host number, as XNS does, rather >than structuring a 64 bit address. One obvious advantage >is that traffic between hosts on the same network (which >does not necessarily mean the same wire), could specify a >"this net" address (which would make multicasting easier). From owner-big-internet@munnari.oz.au Fri Mar 27 08:02:40 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12345; Fri, 27 Mar 1992 08:02:45 +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 AA09774; Fri, 27 Mar 1992 05:52:03 +1000 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA28813; Thu, 26 Mar 92 11:51:05 PST Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: routing vs ADs Message-Id: <1992Mar26.195056.28742@spectrum.CMC.COM> Organization: CMC (a Rockwell Company), Santa Barbara, California, USA References: <9203251940.AA11735@aotearoa.sura.net> Date: Thu, 26 Mar 92 19:50:56 GMT Apparently-To: Big-Internet@munnari.OZ.AU >> What's "DNS routing"? Translating directly from a name (a globally >> unique identifier with no coupling to topological relationships) to a >> route (not just an address) to the named destination?? In article <9203251940.AA11735@aotearoa.sura.net> sherk@sura.net (Erik Sherk) writes: >What I think he is refering to is called "ENCAPS" or IP-IP. It was the >proposal not put forth by Ross Callon in the IP addressing issues BOF >(I'm sorry, I can't remember his name). The speaker for the IP-over-IP encapsulation at IETF-23 was Bob Hinden, who recently moved from BBN.COM to SUN.COM. He is also the director of IETF's routing area, which covers BGP and IDPR. The IDPR (Inter-Domain Policy Routing, not to be confused with IDRP, which is the OSI analog to BGP) is a powerful routing protocol proposed to deal with the issues of how to select appropriate routes through a multi-connected Internet in the face of conflicting Acceptable Use Policies (AUPs). IDPR solves this issue by allowing the administrator of each network number to designate a preference list of acceptable carriers. When a packet arrrives at a border router, an acceptable route is calculated based on the source/destination pair, and the packet is encapsulated in a packet addressed to the border router for the destination AD (Administrative Domain). This outer packet can then be source routed through the backbone(s). The route calculation does not have to be performed by the border router, but can be delegated to a route server, which may be a supercomputer if need be. Or a diskful data base engine, which precomputes routes nightly, and saves them on disk. IDPR was very heavily worked on last summer, but I don't know what the current status is. The internet drafts on the information servers have not been revised since July '91, and I don't think there was a working group meeting in San Diego, but the protocol does not appear to have moved to "Proposed Standard" RFC publication. Maybe Bob Hinden or Martha Steenstrup can tell us what the current status is ? -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM From owner-Big-Internet@munnari.oz.au Sat Mar 28 07:50:15 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17033; Sat, 28 Mar 1992 07:50:33 +1000 (from owner-Big-Internet) Return-Path: Received: from pele.psc.edu by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA17030; Sat, 28 Mar 1992 07:50:15 +1000 (from mathis@pele.psc.edu) Received: by pele.psc.edu (5.57/Ultrix2.4-C cf:ab 9/11/90 --MM--) id AA23622; Fri, 27 Mar 92 16:50:01 EST Message-Id: <9203272150.AA23622@pele.psc.edu> To: iwg@rice.edu, big-internet@munnari.oz.au Subject: Arrgh. Wrong thinking at the last IETF. Date: Fri, 27 Mar 92 16:50:00 EST From: mathis@pele.psc.edu Several of us made the assumption that the effort to deploy routing protocol support for CIDR and C# are about the same. Therefore we should pursue the the more general routing technology (BGP-4 support of super/subnetting), and defer actual decision about CIDR vs C# until are closer to deployment. The flaw in this is that the switches themselves require substantially more complex changes than the routing protocols. In particular CIDR requires that ALL switches have patrica tree routing tables. C# can still be implemented in switches using hash tables with fairly small code changes. CIDR will require complete rewites of some switch code. We should push BGP-4 support of super/subnetting along as quickly as we can, but we should expect to deploy some CIDR addresses which are C# conforment. Otherwise some portions of the Internet will insist on using classic A,B, or C addresses, + default. There may be a significant number of sites for which C# is within reach, but CIDR is not. Does anybody know if a butterfly can do patrica? --MM-- From owner-Big-Internet@munnari.oz.au Sat Mar 28 16:32:15 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26631; Sat, 28 Mar 1992 16:32:27 +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 AA26627; Sat, 28 Mar 1992 16:32:15 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA02034; Fri, 27 Mar 92 22:31:52 -0800 Date: Fri, 27 Mar 92 22:31:51 PST From: Vince Fuller To: Simon Hackett Cc: big-internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: CIDR? In-Reply-To: Your message of Thu, 26 Mar 92 14:36:13 CST Message-Id: Sorry if I've missed a train of thought somewhere, but what is "CIDR"? I heard this term being used during the ietf in San Diego (I was listening via Internet Audioconference), but nonone I heard actually *explained* it. I understand the C# proposals. Where does CIDR fit in? CIDR stands for "Classless Inter-Domain Routing". Basically, the idea is to do away with the class-A/B/C structure of network numbers and treat all destinations as (address, mask) pairs (in hindsight it's pretty clear that this is what should have been done in the first place, instead of creating arbitrary and rigid network sizes). For an proposal and analsys of how this might be done in a transitional manner, using a technique of "supernetting" class-C network numbers, see pub/supernet.txt on Valinor.Stanford.EDU (via anonymous FTP). I think this file is also available in the "big-internet" list archive area for those in Australia. --Vince From owner-Big-Internet@munnari.oz.au Mon Mar 30 12:45:39 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA18087; Mon, 30 Mar 1992 12:45:53 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA18080; Mon, 30 Mar 1992 12:45:39 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 29 Mar 92 21:45:07 EST Received: by chiya.bellcore.com (4.1/4.7) id for mathis@pele.psc.edu; Sun, 29 Mar 92 21:45:55 EST Date: Sun, 29 Mar 92 21:45:55 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9203300245.AA02040@chiya.bellcore.com> To: big-internet@munnari.oz.au, iwg@rice.edu, mathis@pele.psc.edu Subject: Re: Arrgh. Wrong thinking at the last IETF. > > The flaw in this is that the switches themselves require substantially more > complex changes than the routing protocols. In particular CIDR requires that > ALL switches have patrica tree routing tables. C# can still be implemented > in switches using hash tables with fairly small code changes. CIDR will > require complete rewites of some switch code. > Well, this doesn't change your point, but I just want to point out that CIDR would still have contiguous masks, so you wouldn't necessarily need patricia per se. You could use the radix algorithm Sklower has for bsd, or the one Rob Colton wrote, which has the advantage of producing balanced trees (both of these work just fine for the contiguous mask case). PT From owner-Big-Internet@munnari.oz.au Tue Mar 31 01:12:05 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12794; Tue, 31 Mar 1992 01:12:19 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12790; Tue, 31 Mar 1992 01:12:05 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-1.pa.dec.com; id AA18963; Mon, 30 Mar 92 07:11:54 -0800 Received: by us1rmc.mso.dec.com; id AA00740; Mon, 30 Mar 92 10:12:10 -0500 Date: Mon, 30 Mar 92 10:12:09 -0500 Message-Id: <9203301512.AA00740@us1rmc.mso.dec.com> From: dee@ranger.enet.dec.com (Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358) To: big-internet@munnari.oz.au Subject: RE: Re: ToasterNet Part II Sorry, I can't see much difference between having a "separate field" and having a structured larger entity with a "subfield". In either case you can define a "this net" value. I suppose a separate field would be a bit more efficient to manipulate but would tend to be less efficient and flexible from the point of view of bit packing and variable length.... -------------- From: US1RMC::"swb@nr-tech.cit.cornell.edu" "Scott Brim" 28-MAR-1992 11:45 To: gmalkin@ftp.com (Gary Scott Malkin) CC: big-internet@munnari.oz.au Subj: Re: ToasterNet Part II Paul Tsuchiya is finishing up a proposal along these very lines which I'm looking forward to (AND I WISH HE WOULD HURRY UP -- HEAR THAT, PAUL?). >Consider >that there may be advantages to having a network number as >a distinct field from the host number, as XNS does, rather >than structuring a 64 bit address. One obvious advantage >is that traffic between hosts on the same network (which >does not necessarily mean the same wire), could specify a >"this net" address (which would make multicasting easier).