From owner-Big-Internet@munnari.oz.au Tue Aug 6 09:25:54 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA18290; Tue, 6 Aug 1991 09:26: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 AA18284; Tue, 6 Aug 1991 09:25:54 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA00495; Mon, 5 Aug 91 19:24:20 EDT Date: Mon, 5 Aug 91 19:24:20 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9108052324.AA00495@animal.clearpoint.com> To: Big-Internet@munnari.oz.au Subject: "The Addressing Hack" Folks -- Here's the draft for using Class E IP address numbers as discussed in Atlanta.. -- Frank ------------------------------------------------------------------------ Network Working Group F. Solensky INTERNET-DRAFT F. Kastenholz Clearpoint Research Corp. August, 1991 Definition of Class E IP Addresses Status of this Memo This Internet Draft document will be submitted to the RFC editor for a standards document. Comments and suggestions are welcome and may be sent to the authors. 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 an temporary work-around to the imminent exhaustion of Class B network numbers until new architectures are developed [1]. It is a product of a "birds-of-a-feather" discussion held on July 21, 1991 at the twenty- first IETF conference held in Atlanta, GA. It should be noted that this document does NOT address the limitations inherent in the current routing architectures and technology. 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. 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. While there are still a very large number of Class C addresses available, few organizations expect that their connectivity needs will be satisfied within the limitations of 254 IP addresses. The level of demand for Class B addresses can be illustrated by a short analysis of the data available. In the period between August 1990 and June 1991, the number of assigned Class B network numbers grew from 2533 to 5654 [2,3]. This averages out to an annual growth rate of over 123%. If this trend were to continue, the pool of available Class B network numbers would be depleted by October 1992. Solensky, Kastenholz [Page 1] INTERNET DRAFT AUGUST, 1991 While the authors acknowledge that a logistic or "s-shaped" curve would be a more realistic model, a projection based on this assmption 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: the annual growth rate in the allocation of Class B network numbers between 1983 and mid-1990 was only 78% [4], indicating that the growth rate is continuing to increase. Class E Network Numbers The entire Class E address space will be used for the assignment of new IP network numbers. Within the 28 bits available in Class E addresses, the first sixteen will define the network number and the remaining twelve will be the local address, as illustrated below. 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 1 1| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class E address This approach has the advantage of allowing a more practical network size than the Class C address space (4094 addresses as compared to 254) while reducing the probability that large amounts of numbers would remain unused within the network. The network number 255.255.240.0 is reserved so that it does not conflict with the address reserved for IP broadcasts (255.255.255.255). Revisions to IP Address Classes A and C. The space for both Class A and C network numbers will be reduced. The low half of these address ranges - network number fields starting with "0" - will continue to be used in their present form, as illustrated. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Revised Class A address Solensky, Kastenholz [Page 2] INTERNET DRAFT AUGUST, 1991 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 0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Revised Class C address The upper half of these classes will be redesignated as classes F and G. These are illustrated below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class F address 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| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class G address This reduces the number of networks in each class to 126 and 1048574 respectively. It should be noted, however, the demand for numbers in these network classes has not been nearly as great as that for Class B. The reason for this is that by reserving the upper half of these address ranges, there will be sufficient numbering space available to develop alternative network number classifications should the need arise in the near future. This may include the restoration of their prior interpretations. For the sake of completeness, Class B and D addresses are also illustrated. The use of Class D or multicast addresses is specified in [5]. 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 0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class B address Solensky, Kastenholz [Page 3] INTERNET DRAFT AUGUST, 1991 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 1 0| multicast address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class D address Conclusions It must be emphasized that this is intended only to be a work-around to the problem. It is by no means a "solution". While it defines a network classification that is four times the size of the original Class B space, this will only survive only two 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 [4,6] 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 the one described in [5]. References: [1] "A New IP Routing and Addressing Architecture", J. Noel Chiappa. [2] "Internet Numbers", S. Kirkpatrick, M. Stahl, M. Recker, RFC 1166, SRI International, July 1990. [3] Internet Monthly Report, A. Westine [ed], June, 1991. [4] "Continued Internet Growth", Frank Solensky, Proceedings of the Eighteenth Internet Engineering Task Force, July 30-August 3, 1990. pages 59-61. [5] "Host Extentions for IP Multicasting", S. Deering, RFC 1112, SRI International, August 1989. [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 4] INTERNET DRAFT AUGUST, 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 5] From owner-Big-Internet@munnari.oz.au Tue Aug 6 10:48:20 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20839; Tue, 6 Aug 1991 10:48:31 +1000 (from owner-Big-Internet) Return-Path: Received: from EMERALD.ACC.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20836; Tue, 6 Aug 1991 10:48:20 +1000 (from fbaker@acc.com) Received: by emerald.acc.com (4.1/SMI-4.1) id AA14668; Mon, 5 Aug 91 17:45:38 PDT Date: Mon, 5 Aug 91 17:45:38 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9108060045.AA14668@emerald.acc.com> To: solensky@animal.clearpoint.com Subject: Re: "The Addressing Hack" Cc: Big-Internet@munnari.oz.au Good job. May I suggest that Class D be similarly treated? It seems to me that the use of class D as we know it today (new multicast-based applications being different from "as we know it :^)") is not likely to exceed 4095 addresses within either your or my lifetime. Reserving half the class D space won't kill us. Running out of addresses might. Fred From owner-Big-Internet@munnari.oz.au Tue Aug 6 22:55:08 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA08628; Tue, 6 Aug 1991 22:55:16 +1000 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA08610; Tue, 6 Aug 1991 22:55:08 +1000 (from gmalkin@ftp.com) Received: by ftp.com id AA06723; Tue, 6 Aug 91 08:54:56 -0400 Date: Tue, 6 Aug 91 08:54:56 -0400 From: gmalkin@ftp.com (Gary Scott Malkin) Message-Id: <9108061254.AA06723@ftp.com> To: solensky@animal.clearpoint.com Cc: Big-Internet@munnari.oz.au In-Reply-To: Frank T. Solensky's message of Mon, 5 Aug 91 19:24:20 EDT <9108052324.AA00495@animal.clearpoint.com> Subject: "The Addressing Hack" I didn't realize that we had designated the reserved space as classes F and G. Gary (from the Norse meaning "Thrower of Spears") From owner-Big-Internet@munnari.oz.au Wed Aug 7 02:27:27 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12472; Wed, 7 Aug 1991 02:27:46 +1000 (from owner-Big-Internet) Return-Path: Received: from EMERALD.ACC.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12461; Wed, 7 Aug 1991 02:27:27 +1000 (from fbaker@acc.com) Received: by emerald.acc.com (4.1/SMI-4.1) id AA15097; Tue, 6 Aug 91 09:24:47 PDT Date: Tue, 6 Aug 91 09:24:47 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9108061624.AA15097@emerald.acc.com> To: Abhijit.Khale@Eng.Sun.COM Subject: Re: Multicast applications Cc: Big-Internet@munnari.oz.au >> >>May I suggest that Class D be similarly treated? It seems to me that >> >>the use of class D as we know it today (new multicast-based >> >>applications being different from "as we know it :^)") is not likely to >> >>exceed 4095 addresses within either your or my lifetime. Reserving >> >>half the class D space won't kill us. Running out of addresses might. >> >> I'm not denying that more efficient encoding could prevent >> the use of so many addresses : nonetheless, I think 4096 addresses is WAY >> too restrictive. Imprecision. It does us all in. Classes A and C were cut in half. When I said "similarly treated", I meant cut in half. 4K was mentioned because it was the size of a single address space - I probably should have left that out. Sorry about that. Fred From owner-Big-Internet@munnari.oz.au Wed Aug 7 03:04:48 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA13551; Wed, 7 Aug 1991 03:05:03 +1000 (from owner-Big-Internet) Return-Path: Received: from europa.clearpoint.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA13543; Wed, 7 Aug 1991 03:04:48 +1000 (from kasten@europa.clearpoint.com) Received: by europa.clearpoint.com (4.1/1.34) id AA00947; Tue, 6 Aug 91 13:01:53 EDT Date: Tue, 6 Aug 91 13:01:53 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9108061701.AA00947@europa.clearpoint.com> To: Big-Internet@munnari.oz.au Subject: Re: The Addressing Hack Cc: solensky@animal.clearpoint.com > From owner-Big-Internet@munnari.oz.au Mon Aug 5 21:01:14 1991 > From: fbaker@acc.com (Fred Baker) > To: solensky@animal.clearpoint.com > Subject: Re: "The Addressing Hack" > Cc: Big-Internet@munnari.oz.au > > > Good job. > > May I suggest that Class D be similarly treated? It seems to me that > the use of class D as we know it today (new multicast-based > applications being different from "as we know it :^)") is not likely to > exceed 4095 addresses within either your or my lifetime. Reserving > half the class D space won't kill us. Running out of addresses might. > > Fred > Fred, This topic did not come up during the BOF, nor did we think of it while editing the draft. However, I do have a couple of thoughts on the subject. 1. If we take the new class F address (the back half of class A) and chop out 12 local address bits, then there are 18 bits of network number left, which gives us 262,142 more "e-type" network numbers. Doing the same to the new class G (back half of class C) gives another 65,534 numbers. Along with the 65,534 new class E networks, we get a total of 393,210 numbers. I would guess that the net will be suffering severe routing collapse long before we allocate this amount of numbers. I'll try to get Frank Solensky to run this upper bound through his regressions to see when they get exhausted. 2. While your guess that at most 4k class D addresses will be used does not seem far fetched to me, we ought to remember that the original Arpanauts said the same sort of thing about the max. number of networks that would be used, and we ended up with the 32 bit fixed size address with its class structure. I would suggest that we leave class D alone for now. If it does not get used much (i.e. the 4k number is about right) then we don't really need to reserve space, it will be there when we need it. If class Ds become very popular, reserving space out of the class could serve to limit the supply of class D addresses to less than the demand, putting us in the same situation we are in now for class Bs, only we would have to find more class Ds someplace..... Frank Kastenholz Clearpoint Research From owner-Big-Internet@munnari.oz.au Wed Aug 7 03:43:32 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA14125; Wed, 7 Aug 1991 03:43:38 +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 AA14120; Wed, 7 Aug 1991 03:43:32 +1000 (from VALDIS@vtvm1.cc.vt.edu) Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 5185; Tue, 06 Aug 91 13:42:42 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 2449; Tue, 06 Aug 91 13:42:42 EDT Date: Tue, 06 Aug 91 13:39:01 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: "The Addressing Hack" To: "Frank T. Solensky" , Big-Internet@munnari.oz.au Message-Id: <910806.133901.EDT.VALDIS@vtvm1.cc.vt.edu> In-Reply-To: <9108052324.AA00495@animal.clearpoint.com> On Mon, 5 Aug 91 19:24:20 EDT you said: >Revisions to IP Address Classes A and C. > > The space for both Class A and C network numbers will be reduced. > The low half of these address ranges - network number fields starting > with "0" - will continue to be used in their present form, as > illustrated. > > ... (figures deleted) > > The upper half of these classes will be redesignated as classes F and > G. These are illustrated below. > > ... (figures deleted) > > This reduces the number of networks in each class to 126 and 1048574 > respectively. It should be noted, however, the demand for numbers in > these network classes has not been nearly as great as that for Class > B. Ahem. Did I blink? Do I need to re-read my RFC's? Or were there 126 class A networks *before*, and the proposed new number is now 63? I don't have a calculator handy to check over the class C's.... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Wed Aug 7 06:23:57 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16788; Wed, 7 Aug 1991 06:24:13 +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 AA16784; Wed, 7 Aug 1991 06:23:57 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA01330; Tue, 6 Aug 91 16:22:17 EDT Date: Tue, 6 Aug 91 16:22:17 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9108062022.AA01330@animal.clearpoint.com> To: Big-Internet@munnari.oz.au, fbaker@acc.com, kasten@europa.clearpoint.com Subject: Re: The Addressing Hack From: kasten@europa.clearpoint.com (Frank Kastenholz) > From: fbaker@acc.com (Fred Baker) > > > May I suggest that Class D be similarly treated? > > > > Fred > >1. If we take the new class F address (the back half of > class A) and chop out 12 local address bits, then there > are 18 bits of network number left, which gives us 262,142 > more "e-type" network numbers. Doing the same to the new > class G (back half of class C) gives another 65,534 numbers. > Along with the 65,534 new class E networks, we get a total of > 393,210 numbers. I'm a bit hesitant about taking both of these groups, since I don't want to presume a completely different future good idea (like multicasting) is unlikely to occur. There's also the "transition period" problem: some routers may try to combine distant Class F nets into a single Class A net number and lead to all sorts of problems. BGP still doesn't recognize subnet masks, right? On the other hand, if we call Class F 14 bits of net and 16 bits of local number, it creates local nets the same size as ever-popular Class B nets. These could be used for larger orgs that might find 4k to be too small. It also makes the loopback addresses (127.x.x.x) fall more neatly into a reserved set of already formatted addresses. What do others think about this? I'm leaning towards leaving things as discussed in Atlanta and, if it looks like another hack is needed, seeing what patterns have developed before we have to announce something like this again. > I would guess that the net will be suffering severe routing > collapse long before we allocate this amount of numbers. I'll > try to get Frank Solensky to run this upper bound through his > regressions to see when they get exhausted. Continuing to average 78 and 123%/yr (doubling, conveniently enough) would mean another six years after Class E runs out. -- Frank Solensky / Clearpoint Research From owner-Big-Internet@munnari.oz.au Wed Aug 7 07:36:49 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17538; Wed, 7 Aug 1991 07:37:28 +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 AA17531; Wed, 7 Aug 1991 07:36:49 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA01389; Tue, 6 Aug 91 17:34:56 EDT Date: Tue, 6 Aug 91 17:34:56 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9108062134.AA01389@animal.clearpoint.com> To: gmalkin@ftp.com Subject: Re: "The Addressing Hack" Cc: Big-Internet@munnari.oz.au Gary -- >I didn't realize that we had designated the reserved space as classes F >and G. Writer's perogitive: we figured that if we said that the network _numbers_ were reserved, it might take longer to disassociate the old formats if we had to change them later on. The names "A-sharp" and "C-sharp" might be more appropriate to those musically inclined.. -- Frank From owner-Big-Internet@munnari.oz.au Wed Aug 7 08:25:32 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA18395; Wed, 7 Aug 1991 08:25:40 +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 AA18388; Wed, 7 Aug 1991 08:25:32 +1000 (from mo@gizmo.bellcore.com) Received: from gizmo.bellcore.com by bellcore.bellcore.com (5.61/1.34) id AA07454; Tue, 6 Aug 91 16:35:16 -0400 Message-Id: <9108062035.AA07454@bellcore.bellcore.com> To: solensky@animal.clearpoint.com (Frank T. Solensky) Cc: Big-Internet@munnari.oz.au, fbaker@acc.com, kasten@europa.clearpoint.com, mo@gizmo.bellcore.com Subject: Re: The Addressing Hack In-Reply-To: Your message of "Tue, 06 Aug 91 16:22:17 EDT." <9108062022.AA01330@animal.clearpoint.com> Date: Tue, 06 Aug 91 16:35:14 -0400 From: mo@gizmo.bellcore.com I suggested in Atlanta considering a 15/13 or 14/14 split. The question in my mind is what percent of site who would currently need a class B would be served by either of thost two approaches so they wouldn't need a Class B. I realize they could request two F addresses, but if we don't think we can route 65000 network destinations, then what's the reason to not consider a different split? -Mike From owner-Big-Internet@munnari.oz.au Sat Aug 10 05:02:20 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22519; Sat, 10 Aug 1991 05:02:26 +1000 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA22512; Sat, 10 Aug 1991 05:02:20 +1000 (from gmalkin@ftp.com) Received: by ftp.com id AA10940; Fri, 9 Aug 91 15:02:07 -0400 Date: Fri, 9 Aug 91 15:02:07 -0400 From: gmalkin@ftp.com (Gary Scott Malkin) Message-Id: <9108091902.AA10940@ftp.com> To: solensky@animal.clearpoint.com Cc: Big-Internet@munnari.oz.au In-Reply-To: Frank T. Solensky's message of Tue, 6 Aug 91 17:34:56 EDT <9108062134.AA01389@animal.clearpoint.com> Subject: "The Addressing Hack" I wonder if we could get A-sharp and C-sharp through. I *really* like those names. Gary (from the Norse meaning "Thrower of Spears") From owner-Big-Internet@munnari.oz.au Sat Aug 10 13:14:02 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA08652; Sat, 10 Aug 1991 13:14:16 +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 AA08647; Sat, 10 Aug 1991 13:14:02 +1000 (from kre) To: big-internet@munnari.oz.au Subject: Apologies for the disruption Date: Sat, 10 Aug 91 13:13:52 +0000 Message-Id: <2439.681794032@munnari> From: Robert Elz Australia was off the internet for about 3 days (the PTT people who should ahve fixed the problem were on strike, or other words that have the same effect but sound better to them). We have a backup (dial up) path over which mail was received, but because of the way that works, I need to do a little config for addresses on munnari.oz.au which are to be effective using that path, and I had forgotten to set up big-internet correctly. That is fixed now, Australia is back on the Internet now too, so if any messages you sent bounced, please send them again. kre From owner-Big-Internet@munnari.oz.au Sat Aug 10 13:18:27 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA08754; Sat, 10 Aug 1991 13:18:47 +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 AA08749; Sat, 10 Aug 1991 13:18:27 +1000 (from kre) To: big-internet@munnari.oz.au Subject: Class E addresses and .IN-ADDR.ARPA Date: Sat, 10 Aug 91 13:18:21 +0000 Message-Id: <2444.681794301@munnari> From: Robert Elz Has anyone thought about how we're going to cope with .IN-ADDR.ARPA delegations with class E addresses? kre From owner-big-internet@munnari.oz.au Mon Aug 12 23:37:43 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA10044; Mon, 12 Aug 1991 23:37:58 +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 AA04169; Mon, 12 Aug 1991 20:53:26 +1000 (from lwj@cs.kun.nl) Received: from manta.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA04695 (5.65b/IDA-1.4.3/DIT-1.2 for Big-Internet@munnari.oz.au); Mon, 12 Aug 91 18:28:33 +1000 Received: from wn1.sci.kun.nl by manta.mel.dit.CSIRO.AU (4.1/SMI-4.0.1) id AA17233; Mon, 12 Aug 91 18:28:19 EST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA02774; Mon, 12 Aug 91 10:20:12 +0200 Received: from iris by cs.kun.nl (4.1/SMI-3.2) id AA01245; Mon, 12 Aug 91 10:20:06 +0200 Message-Id: <9108120820.AA01245@cs.kun.nl> To: Big-Internet@munnari.oz.au Subject: Re: The Addressing Hack In-Reply-To: Your message of "Tue, 06 Aug 91 16:22:17 EDT." <9108062022.AA01330@animal.clearpoint.com> Date: Mon, 12 Aug 91 10:20:00 +0200 From: lwj@cs.kun.nl > On the other hand, if we call Class F 14 bits of net and 16 bits of local > number, it creates local nets the same size as ever-popular Class B nets. > These could be used for larger orgs that might find 4k to be too small. > It also makes the loopback addresses (127.x.x.x) fall more neatly into > a reserved set of already formatted addresses. As it stands now, the loopback network is not mentioned at all in the draft. It should probably be added, if only to clarify things. Also, it isn't really clear to me what exactly is the purpose of these modifications. Only really new implementations can make use of the new class E adresses, since they need to recognize the new class. I vagely remember something about routers dropping packets containing unknown adresses? Re-dividing class A, on the other hand, can already be handled by any implementation that can handle subnets, i.e., most modern ones. Why was the decision taken to assign the 1111 space instead of using up the upper half of the 0 space? It even provides more bits... Another thought is how all of this interacts with the in-addr.arpa delegation. Has anyone considered the fact that delegation of authority for the new class E adresses is very awkward, because the network number does not end on a byte boundary? To me this seems a very good reason to subdivide on byte boundaries, at least until we find a satisfactory way to delegate reverse mappings on arbitrary bit boundaries. The current way of delegating for the first class E network, 240.0.0.0, would require 16 NS records in the in-addr.arpa zone: 0.0.240.in-addr.arpa. NS some.server. 1.0.240.in-addr.arpa. NS some.server. ... 15.0.240.in-addr.arpa. NS some.server. and this for every class E network! Finally, I think it is worthwhile to invent a way to find out the "highest level" network mask of an IP address (e.g., 255.0.0.0, 255.255.0.0, 255.255.255.0 for the old class A, B, C adresses) from the DNS. If we can do this, then the division of address bits does not need to be wired down into implementations anymore, so that we can use any scheme we like. Since usage of class E adresses requires updating implementations anyway, why not do it this way? RFC 1101 already specifies a way to add second or third level subnet masks to the DNS, using in-addr.arpa zone. There are several easy ways to add the first-level networks masks, but this is probably not the right place to discuss them. Most of these do not require DNS software modifications, nor introduction of new zones or addition of data to all zones. -- Luc Rooijakkers Internet: lwj@cs.kun.nl Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj University of Nijmegen, the Netherlands tel. +3180652271 From owner-big-internet@munnari.oz.au Mon Aug 12 23:42:26 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA10152; Mon, 12 Aug 1991 23:42:34 +1000 (from owner-big-internet) Return-Path: Received: from wn1.sci.kun.nl by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA05310; Mon, 12 Aug 1991 21:10:12 +1000 (from lwj@cs.kun.nl) Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA04304; Mon, 12 Aug 91 13:10:33 +0200 Received: from iris by cs.kun.nl (4.1/SMI-3.2) id AA03049; Mon, 12 Aug 91 13:10:31 +0200 Message-Id: <9108121110.AA03049@cs.kun.nl> From: lwj@cs.kun.nl (Luc Rooijakkers) To: big-internet@munnari.oz.au Cc: lwj@cs.kun.nl (Luc Rooijakkers) Subject: Re: The Addressing Hack In-Reply-To: Your message of "Tue, 06 Aug 91 16:22:17 EDT." <9108062022.AA01330@animal.clearpoint.com> Date: Mon, 12 Aug 91 13:10:29 +0200 Sender: lwj@cs.kun.nl > On the other hand, if we call Class F 14 bits of net and 16 bits of local > number, it creates local nets the same size as ever-popular Class B nets. > These could be used for larger orgs that might find 4k to be too small. > It also makes the loopback addresses (127.x.x.x) fall more neatly into > a reserved set of already formatted addresses. As it stands now, the loopback network is not mentioned at all in the draft. It should probably be added, if only to clarify things. Also, it isn't really clear to me what exactly is the purpose of these modifications. Only really new implementations can make use of the new class E adresses, since they need to recognize the new class. I vagely remember something about routers dropping packets containing unknown adresses? Re-dividing class A, on the other hand, can already be handled by any implementation that can handle subnets, i.e., most modern ones. Why was the decision taken to assign the 1111 space instead of using up the upper half of the 0 space? It even provides more bits... Another thought is how all of this interacts with the in-addr.arpa delegation. Has anyone considered the fact that delegation of authority for the new class E adresses is very awkward, because the network number does not end on a byte boundary? To me this seems a very good reason to subdivide on byte boundaries, at least until we find a satisfactory way to delegate reverse mappings on arbitrary bit boundaries. The current way of delegating for the first class E network, 240.0.0.0, would require 16 NS records in the in-addr.arpa zone: 0.0.240.in-addr.arpa. NS some.server. 1.0.240.in-addr.arpa. NS some.server. ... 15.0.240.in-addr.arpa. NS some.server. and this for every class E network! Finally, I think it is worthwhile to invent a way to find out the "highest level" network mask of an IP address (e.g., 255.0.0.0, 255.255.0.0, 255.255.255.0 for the old class A, B, C adresses) from the DNS. If we can do this, then the division of address bits does not need to be wired down into implementations anymore, so that we can use any scheme we like. Since usage of class E adresses requires updating implementations anyway, why not do it this way? RFC 1101 already specifies a way to add second or third level subnet masks to the DNS, using in-addr.arpa zone. There are several easy ways to add the first-level networks masks, but this is probably not the right place to discuss them. Most of these do not require DNS software modifications, nor introduction of new zones or addition of data to all zones. -- Luc Rooijakkers Internet: lwj@cs.kun.nl Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj University of Nijmegen, the Netherlands tel. +3180652271 From owner-Big-Internet@munnari.oz.au Tue Aug 20 01:18:35 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA04898; Tue, 20 Aug 1991 01:18:48 +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 AA04895; Tue, 20 Aug 1991 01:18:35 +1000 (from swb@MITCHELL.CIT.CORNELL.EDU) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA16456; Mon, 19 Aug 91 11:18:22 EDT Message-Id: <9108191518.AA16456@mitchell.cit.cornell.edu> To: solensky@animal.clearpoint.com (Frank T. Solensky) Cc: Big-Internet@munnari.oz.au Subject: Re: The Addressing Hack In-Reply-To: Your message of "Tue, 06 Aug 91 16:22:17 EDT." <9108062022.AA01330@animal.clearpoint.com> Date: Mon, 19 Aug 91 11:18:21 -0400 From: Scott Brim First, you're right that BGP still doesn't recognize subnet masks, but we're working on it. There are more or less two camps right now, one saying "it's simple, let's just do it" and the other saying "look at all the trouble other groups are having just defining the aspects of the problem clearly -- let's wait". It's in the works at least. About dividing up class D addresses: the problem is that we're going to have to do something about multicast scope -- rules for how far packets and/or membership information are meant to propagate. Of all the proposed weird ideas for supporting this the only decent one is to divide up the address space and have meaningful subclasses of class D. Unless and until we get a nice stable way of supporting scope without dividing up the address space (and we're still trying!), and we prove it works in operation, it really would be a good idea to leave class D alone. Of course if the Internet is about to die and the multicast crowd is still hemming and hawing I think grabbing half or all of class D will be justified, but, as you say, let's wait a while. Thanks ... Scott