From owner-Big-Internet@munnari.oz.au Mon Nov 11 15:25:30 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22129; Mon, 11 Nov 1991 15:26:53 +1100 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.64+1.3.1+0.50) id AA22117; Mon, 11 Nov 1991 15:25:30 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: from PTT.LCS.MIT.EDU (via ALLSPICE.LCS.MIT.EDU) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27372; Sun, 10 Nov 91 23:23:40 -0500 Received: by PTT.LCS.MIT.EDU id AA08448; Sun, 10 Nov 91 23:19:36 EST Date: Sun, 10 Nov 91 23:19:36 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9111110419.AA08448@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au Subject: IP Address Hacks Cc: jnc@ALLSPICE.LCS.MIT.EDU I'm looking back over the draft RFC and message traffic on the mailing list, preparatory to taking the draft RFC (which we will have to somewhat revise to include more rationale for various design choices, which people will want to see) to the IAB. I see a couple of open questions and suggestions I'd like to comment on, and get people's reaction. First, although initially appealing, on reflection I don't think the suggestion to reserve the back half of D space is very profitable. It would result in sectors which had a five bit prefix (11100 for m'cast, and 11101 for 'D sharp' (I *LOVE* that name :-)), whereas currently four bits covers them all. This isn't exactly earth-shattering, I know.... However, it does lead to useful point; we'd be saving 1/32nd of the address space, which is not a great deal. Sure, we can make sure we don't allocate out of the back half, just in case, but I doubt it will be critical. Second, everyone seems OK with the choice to a) create a new format, and b) use all the reserved space (1111 prefix) for the new format (as opposed to recycling the back half of class C). The reasons for the latter were given in the BoF writeup in the Atlanta Proceedings. (I can email a copy to the mailing list if wanted.) Is this a correct assumption? Third, I have looked into the IN-ADDR question and Philip Almquist (who is, among other things, the Bind maintainer for DEC these days) indicates to me that things will work, although vanilla BIND implementations will need slightly verbose manual databases. Note, however, that since IN-ADDR asssume 8 bit boundaries, this would be a problem with anything except a 16 bit rest, which seems deprecated at the moment (see below). Finally, with regard to whether we should have 16 bits of network number with 12 of rest, or 15/13 or 14/14, I think this is really the sole remaining open question. Note that I don't think it's the end of the world if we are a little off, since I think there is general agreement that this address structure is not long for the world anyway. In other words, it doesn't matter if we don't get the 'best' answer. I agree that the question really is "how many of the current B users would be satisfied with an E?" Obviously, if 75% are happy with a 12 bit rest E, then that is perfect, since there will be 4 times as many E's as B's with a 12 bit rest (2^16 E's as opposed to 2^14 B's). If, on the other hand, only 25% are, we should go to a 13 or 14 bit rest. Note, however, that a 14 bit rest would only give us as many new network numbers as we now have B's. Given the consumption rate of B's, simply doubling the number of mid-size nets available probably is not going to hack it, so maybe the choice, practically, is 13 or 12. I'll insert below the reasons for a 12 bit rest from the Atlanta Proceedings. In addition to the reasons given therein, 12 bits also has the nice property that it's on a Hex boundary! Lacking a poll (any volunteers, hint hint), we have to guess. What do people think? 12, 13 or 14 bits of rest? Noel -------- On the other hand, use of a smaller rest field would allow more network numbers to be packed into the portion of the address space allocated; since the available free (or reclaimable) spaces were mostly quite small, this weighed heavily in favor of the smaller fields. A new class, with a 12 bit rest field (to called class 'E' addresses) was finally decided on, since it maximizes the number of network numbers that can be created. While a 12 bit rest field only allows for 4K hosts, this is still significantly more than a class C, and should be more than enough for most companies. Also, it is exactly equidistant between the class B and class C sizes. However, this decision (for 12 instead of 13 or more) needs to be reviewed carefully to make sure that a 12 bit rest field will actually be useful to a significant number of network number applicants. From owner-Big-Internet@munnari.oz.au Mon Nov 11 19:36:41 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA29930; Mon, 11 Nov 1991 19:36:59 +1100 (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 AA29921; Mon, 11 Nov 1991 19:36:41 +1100 (from lwj@cs.kun.nl) Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA08410; Mon, 11 Nov 91 09:35:36 +0100 Received: from iris by cs.kun.nl (4.1/SMI-3.2) id AA05565; Mon, 11 Nov 91 09:35:30 +0100 Message-Id: <9111110835.AA05565@cs.kun.nl> To: jnc@allspice.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: IP Address Hacks In-Reply-To: Your message of "Sun, 10 Nov 91 23:19:36 EST." <9111110419.AA08448@PTT.LCS.MIT.EDU> Date: Mon, 11 Nov 91 09:35:26 +0100 From: lwj@cs.kun.nl > Second, everyone seems OK with the choice to a) create a new > format, and b) use all the reserved space (1111 prefix) for the new format > (as opposed to recycling the back half of class C). The reasons for the > latter were given in the BoF writeup in the Atlanta Proceedings. (I can > email a copy to the mailing list if wanted.) > Is this a correct assumption? Please mail it to the list, as it seems to be the basic foundation for all of this discussion. I'm not sure if 'everyone' is OK; I at least am not really convinced that using the 1111 space (class D) is better then using the 01 space (class A). Way back in august I wrote > 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... I did not see any response to this. Could someone enlighten me? > Third, I have looked into the IN-ADDR question and Philip Almquist > (who is, among other things, the Bind maintainer for DEC these days) > indicates to me that things will work, although vanilla BIND > implementations will need slightly verbose manual databases. Note, however, > that since IN-ADDR asssume 8 bit boundaries, this would be a problem with > anything except a 16 bit rest, which seems deprecated at the moment (see > below). It gets messy, yes. Depending on the division, one needs either 2, 4, 8, 16, 32, 64 or 128 records of type NS to delegate the subdomain. Note that a new feature for BIND alone does not cut it, unless it interoperates smoothly with other server implementations. This would mean dynamic expansion of a new "wildcard" record during zone transfer, and possibly re-compression at the receiving end. -- 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 Nov 12 03:27:38 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA09895; Tue, 12 Nov 1991 03:27:44 +1100 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.64+1.3.1+0.50) id AA09892; Tue, 12 Nov 1991 03:27:38 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: from PTT.LCS.MIT.EDU (via ALLSPICE.LCS.MIT.EDU) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10942; Mon, 11 Nov 91 11:07:55 -0500 Received: by PTT.LCS.MIT.EDU id AA10088; Mon, 11 Nov 91 11:02:49 EST Date: Mon, 11 Nov 91 11:02:49 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9111111602.AA10088@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au, lwj@cs.kun.nl Subject: Re: IP Address Hacks Here's the BoF report from Atlanta. I will send a separate reply about the technical points. Noel -------- IP Address Hacks BoF This BoF discussed potential interim solutions to the near-term problem of the shortage of class B IP network numbers. Of the three classes of IP network numbers, A, B and C, the class B numbers are being used up at the highest rate. There are 16K (2^14) of these, and over four thousand are already allocated (although not all are being advertised in the Internet). These are the most useful numbers, since most sites are not large enough to need a class A (24 bit rest), where most are too large to make good use of a class C (8 bit rest), particularly if subnetting is being used. Depending on which exact model is used to predict future usage of these numbers, at the current rate of usage these will run out in several years. A straight exponential fits the curve so far quite well; it has been argued that this is not a useful model, but rather an S-curve model should be used. The problem is that no inflection point has yet appeared, so it is difficult to fit an S curve to the growth. In any case, there is general agreement that the problem is severe. The two key questions were what kind of extra network numbers to create, and what portion of the existing IP address space to devote to them. After a commendably quick discussion, consensus answers did appear to both of these. There were several potential answers to the first question. One option is to simply create more class B (i.e. 16 bit 'rest' field) numbers. The other was to create a new class of network numbers with a different size rest field, intermediate between class B and C. It was pointed out that most sites which are getting class B numbers do not need a whole class B space, but could easily use something a little smaller; this would reduce the usage of the class B space, thereby extending the lifetime of that space. Suggestions were made for a number of different sizes, including 14, 13 and 12 bits. One thing going against more class B numbers was that to create a reasonable number of them would use a large chunk of the 32 bit IP address space. The current block of 16K used one quarter of the address space; all addresses with a '10' prefix. If another quarter were (somehow) devoted to class B, that would still only double the number. On the other hand, use of a smaller rest field would allow more network numbers to be packed into the portion of the address space allocated; since the available free (or reclaimable) spaces were mostly quite small, this weighed heavily in favor of the smaller fields. A new class, with a 12 bit rest field (to called class 'E' addresses) was finally decided on, since it maximizes the number of network numbers that can be created. While a 12 bit rest field only allows for 4K hosts, this is still significantly more than a class C, and should be more than enough for most companies. Also, it is exactly equidistant between the class B and class C sizes. However, this decision (for 12 instead of 13 or more) needs to be reviewed carefully to make sure that a 12 bit rest field will actually be useful to a significant number of network number applicants. This does point 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. There are two broad classes of solution to the question of where to allocate any new network numbers. The first is to use some or all of the currently reserved space; i.e. prefix 1111. The second is to recycle some of the currently "unlikely to be used" space; for instance the back half of the class A space (prefix 01), or the back half of class C (prefix 1101). Considering the first, the question was whether or not to use the entire space, or to continue the practice of allocating a space whose prefix started with all 1's and ended with a 0; i.e. allocate 11110 and reserve 11111. It was decided not to keep a part reserved if this space were used, but to use the entire space. The problem is that this practise is resulting in diminishing returns as far as the size of the portion of address space available to hold network numbers and the rest field; in other words, the overhead of the field dedicated to format identification was getting quite large (5 of 32 bits). Use of the entire block would allow creation of 2^16 of these new network numbers. (4 bits of prefix + 16 of network number + 12 of rest = 32) This number, sixteen times larger than the number of class B's, could reasonably be expected to last quite a long time. Were this done, since it would use the last reserved space, a new reserved space should be created, consisting of the back half of the existing class A and/or C space. Alternatively, if the back half of class C space (1101 prefix) were used to hold these new numbers, 2^16 of them could also be created here. It was pointed out that use of class C numbers would allow routers which did not understand class E addresses to treat them as a group (2^4, or 16) of class C numbers. No definite answer was arrived at in the BoF for the question of where to place the new numbers, although there was general consensus that using all the reserved space or the back half of class C space were the two viable options. It was agreed that in either case the back half of the class A space should be reserved; it was felt that rather than move directly from one use to another, it would be best if a portion of the address space cycled through 'reserved', to allow use of the old meaning to disappear from the net before the new use was taken up. Discussion in the hallways after the BoF concluded that the optimal choice was in fact to use the reserved space. It was felt that the ability to have older routers handle class E numbers as a group of class C numbers was not actually good, given the problems in the network with large numbers of network numbers. Also, it was felt that the argument above about cycling through reserve should apply to the back half of class C space as well. Finally, and most important, it was pointed out that unless the new numbers were allocated from the reserved space, there would be less impetus on people's part to change their software. The ability to model a class E net as a group of C's would, from this viewpoint, be a problem, not an advantage. This is a weighty point, given the necessity of the change in the network; presumably people making the change to recognize E's would also put in the change to reserve the back half of A and C space, which might well be critical in the future. From owner-Big-Internet@munnari.oz.au Tue Nov 12 07:21:46 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA14071; Tue, 12 Nov 1991 07:22:13 +1100 (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 AA14052; Tue, 12 Nov 1991 07:21:46 +1100 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA02815; Mon, 11 Nov 91 15:17:58 EST Date: Mon, 11 Nov 91 15:17:58 EST From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9111112017.AA02815@animal.clearpoint.com> To: big-internet@munnari.oz.au, jnc@allspice.lcs.mit.edu Subject: Re: IP Address Hacks > First, although initially appealing, on reflection I don't think >the suggestion to reserve the back half of D space is very profitable. > It would result in sectors which had a five bit prefix (11100 for >m'cast, and 11101 for 'D sharp' (I *LOVE* that name :-)), whereas currently >four bits covers them all. This isn't exactly earth-shattering, I know.... A nit: splitting class D wasn't considered. The class A and C spaces were to be split, with the high end (A-sharp & C-sharp) "reserved". Class E became a sixteen-bit net/twelve-bit rest division. The draft we sent to Noel varied from the one sent to the list last August only in some editorial points, typos, diagrams for all address classes (not just the revised ones) and describing the mnemonic device for the "sharp" class names. > Lacking a poll (any volunteers, hint hint), we have to guess. >What do people think? 12, 13 or 14 bits of rest? > As I remember it, Paul Tsuchiya's survey about a year and a half ago indicated that there was less than 3% utilization of the host numbers within class B nets -- a twelve-bit rest would represent more than twice that. Which brings up another point -- did we resolve the question on whether Class E addresses would not be assigned until we ran out of Class B, or would they start right away so that the remaining Class B numbers could be assigned only to organizations that would find Class E to be too small? -- Frank Solensky From owner-Big-Internet@munnari.oz.au Tue Nov 12 15:22:32 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26370; Tue, 12 Nov 1991 15:22:42 +1100 (from owner-Big-Internet) Return-Path: Received: from ALLSPICE.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26366; Tue, 12 Nov 1991 15:22:32 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA12010; Mon, 11 Nov 91 23:22:23 EST Date: Mon, 11 Nov 91 23:22:23 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9111120422.AA12010@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au, solensky@animal.clearpoint.com Subject: Re: IP Address Hacks Cc: jnc@ALLSPICE.LCS.MIT.EDU My references to the Class D stuff were a response to traffic on the mailing list, not to anything said in the BoF or draft RFC. As far as when to start allocating, I would think we should start as soon as most of the major router vendors support class E. I absolutely don't want to wait until Class B is used; what would we do with people who didn't fit into a Class E? Noel From owner-Big-Internet@munnari.oz.au Tue Nov 12 16:36:14 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA28218; Tue, 12 Nov 1991 16:36:17 +1100 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.64+1.3.1+0.50) id AA28215; Tue, 12 Nov 1991 16:36:14 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: from PTT.LCS.MIT.EDU (via ALLSPICE.LCS.MIT.EDU) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27903; Tue, 12 Nov 91 00:30:21 -0500 Received: by PTT.LCS.MIT.EDU id AA12176; Tue, 12 Nov 91 00:25:19 EST Date: Tue, 12 Nov 91 00:25:19 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9111120525.AA12176@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au, lwj@cs.kun.nl Subject: Re: IP Address Hacks Cc: jnc@ALLSPICE.LCS.MIT.EDU I am resolutely against using the A# (A-sharp, for those who are non-musicians) space for class E addresses. The reason is simple; if we in fact run out of Class B addresses, for whatever reason, the A# space is the only *practical* place left to create more. The 1111 space will still provide 2^16 (i.e. 65K) class E numbers; we don't *need* a bigger space. Due to the size of the Class B 'rest' field, even a chunk of the address space with a two bit prefix (of which there is precisely *one* available, the A# space) gives us only 2^14 (i.e. 16K) network numbers. Now, I know 16K sounds like a lot, since we seem to be having troubles with 3K now! However, not all will be connected, and new routers with more memory, more processing speed, etc (not to mention faster network links) will allow the system to handle quantities of network numbers far larger than what we can today. We could easily use those numbers! Given that we don't know how long it will take to design and deploy the replacement address/routing, I feel that it is vital that we keep this escape hatch free. The BIND feature I was speaking of was to allow the manual databases to be compressed. I was not proposing that we try and change the protocol. Bandwidth and memory are cheap, and getting cheaper. Tired humans are not getting any faster, however. I want to optimize the human interface; I don't care if the packets are verbose. In your original message you wrote: 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! I am merely proposing a new type of manual database entry, say: 0.0.240.in-addr.arpa. ENS some.server. which would automatically expand into the list of records above. Just trying to make it easy on the humans! Noel From owner-Big-Internet@munnari.oz.au Tue Nov 12 19:11:42 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA02474; Tue, 12 Nov 1991 19:14:05 +1100 (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 AA02434; Tue, 12 Nov 1991 19:11:42 +1100 (from lwj@cs.kun.nl) Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA13725; Tue, 12 Nov 91 09:09:37 +0100 Received: from iris by cs.kun.nl (4.1/SMI-3.2) id AA13696; Tue, 12 Nov 91 09:09:33 +0100 Message-Id: <9111120809.AA13696@cs.kun.nl> To: jnc@allspice.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: IP Address Hacks In-Reply-To: Your message of "Tue, 12 Nov 91 00:25:19 EST." <9111120525.AA12176@PTT.LCS.MIT.EDU> Date: Tue, 12 Nov 91 09:09:30 +0100 From: lwj@cs.kun.nl Noel writes: > I am resolutely against using the A# (A-sharp, for those who are > non-musicians) space for class E addresses. The reason is simple; if we in > fact run out of Class B addresses, for whatever reason, the A# space is the > only *practical* place left to create more. The 1111 space will still > provide 2^16 (i.e. 65K) class E numbers; we don't *need* a bigger space. > Due to the size of the Class B 'rest' field, even a chunk of the > address space with a two bit prefix (of which there is precisely *one* > available, the A# space) gives us only 2^14 (i.e. 16K) network numbers. > Now, I know 16K sounds like a lot, since we seem to be having troubles with > 3K now! However, not all will be connected, and new routers with more > memory, more processing speed, etc (not to mention faster network links) > will allow the system to handle quantities of network numbers far larger > than what we can today. We could easily use those numbers! > Given that we don't know how long it will take to design and deploy > the replacement address/routing, I feel that it is vital that we keep this > escape hatch free. Ok, that covers my concerns. My major reason for them was the reaction of host software to the new class E numbers; routers will likely have to change anyway. It seems that this had been thought of already. Anyone care to post test results for various implementations, in particular BSD :-) ? > 0.0.240.in-addr.arpa. ENS some.server. > > which would automatically expand into the list of records above. > Just trying to make it easy on the humans! That was exactly what I meant, though the ENS should probably be more general (e.g. WNS with a replication mask instead of specifically tied to the class E numbers, or a general WILD keyword). From the BoF report: > This does point 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. Perhaps it is time to add a facility to the DNS to find out top-level network masks (or network masks in generals)? Something like IN-MASK.ARPA. ? Using wildcard delegations this would be quite easy, e.g. *.IN-MASK.ARPA. A 255.0.0.0 *.128.IN-MASK.ARPA. A 255.255.0.0 . . . This would take only 256 RRs in the root nameservers! Note that the mechanisms from RFC 1101 (DNS Encoding of Network Names and Other Types) are not sufficient, since these would require the data in the delegated zone, whereas it belongs in the root servers. Other ways of getting this information to the hosts who need it are also feasable, e.g., a new ICMP request/reply message. -- 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 Wed Nov 13 03:47:26 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA12137; Wed, 13 Nov 1991 03:48:29 +1100 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA12132; Wed, 13 Nov 1991 03:47:26 +1100 (from gmalkin@ftp.com) Received: by ftp.com id AA28852; Tue, 12 Nov 91 11:48:26 -0500 Date: Tue, 12 Nov 91 11:48:26 -0500 From: gmalkin@ftp.com (Gary Scott Malkin) Message-Id: <9111121648.AA28852@ftp.com> To: solensky@animal.clearpoint.com Cc: big-internet@munnari.oz.au, jnc@allspice.lcs.mit.edu In-Reply-To: Frank T. Solensky's message of Mon, 11 Nov 91 15:17:58 EST <9111112017.AA02815@animal.clearpoint.com> Subject: IP Address Hacks > Which brings up another point -- did we resolve the question on whether > Class E addresses would not be assigned until we ran out of Class B, or > would they start right away so that the remaining Class B numbers could be > assigned only to organizations that would find Class E to be too small? As I recall, we decided that we would start assigning class E ASAP so that we could keep the class B addresses for those who *really* do need them. Gary (from the Norse meaning "Thrower of Spears") From owner-Big-Internet@munnari.oz.au Wed Nov 13 09:54:33 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20652; Wed, 13 Nov 1991 09:54:36 +1100 (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 AA20648; Wed, 13 Nov 1991 09:54:33 +1100 (from kre) To: big-internet@munnari.oz.au Subject: Class E addresses (etc) Date: Wed, 13 Nov 91 09:54:29 +0100 Message-Id: <1488.689986469@munnari.oz.au> From: Robert Elz The DNS issue that needs to be solved isn't how to delegate the 16 zones to the owner of a class E net (which only needs to be done in the IN-ADDR.ARPA zone anyway - the owners of that zone can run special software if necessary), but just how the delagee copes with making 16 SOA's, sets of NS's, etc, all appear, and how we teach people how they will have to divide up their PTR's into the 16 different zones they inherit. So something like ENS isn't what's needed, you need something to go in named.boot to tell named that its about to see a zone that it needs to split 16 ways based on the values of the labels, along with replication of the misc data (SOA, NS's etc) - possible but very messy. Or you need a tool to take a composite file and split it apart - easy for those who use tools already to maintain DNS files, but a burden on those of us who perfer to manually edit the DNS files as primary data sources. You also need something to tell named to secondary 16 zones from another server, but that one ie much easier. I know named (BIND) isn't the only server, but for this purpose it may as well be. If people who run some other (existing) server (new ones should be written to cope once the problem is known) were to request class B's rather than E's just for this reason, it wouldn't be a major problem, there are so few of them. Those few could also do the work by hand if necessary (again, there are very few). I think I'd go for a 12 bit rest - I agree the choice is between 12 & 13. Picking a "rest" part that's too small just means that some people may need two of them to cope (just as currently some sites use multiple class C's) - most won't. Picking one that's too big ends up wasting address space, which is the very problem we need to solve. Allocating multiple numbers to sites will increase routing table sizes, but I'd expect less of that with E's than we currently get with C's (and certainly less than if we get close to running out of B's and have to opt for allocating groups of 16 or so C's to sites) so while this is a problem, I don't think E's will make it worse. So, err on the "smaller is better" side, pick 12 bit rests (and its a nice hex boundary, which is a bonus). I agree A# certainly isn't the place to put these things, if there was to be an alternative to 1111 (E) it would have to be C# I think - E's will make C's even less popular than they are now, C's simply don't have enough bits for almost anyone, only groups of them are useable - so the chances of ever needing C# for class C nets is pretty remote. C# does have the advantage that hosts could deal with them (better than A# actually, a host could actually be allocated a number on a C# net and have it work properly, which I'm not sure it would on A#). But I'd still go for 1111 (E) I think - we do have a couple of years to get this thing in place, its a trivial implementation change, so even the dullest vendors should be able to cope with this upgrade - as long as its specified in the very near future. Unfortunately, as almost all host implementations understand the internals of IP addresses (whether they should or not), simply updating the routers won't allow E's to start being allocated, hosts do need to be updated as well. Its also true that a large fraction of "routers" in the real world are just hosts with embedded routing code, so in practice the two are much the same thing (Sun have probably shipped as many "routers" as any of the major router vendors, possibly many times more). Here (that is, in my university), as well as Cisco and Protoen (and maybe some Wellfleet as well) we have Sun, SGI, and Encore "routers", and had a Vax "router" a while ago, and will have a Decstation "router" soon. There are also some PC's (running pcroute) kicking around somewhere (and misc other crud you really don't want to know about). This is the real world, and its real ugly... kre From owner-Big-Internet@munnari.oz.au Wed Nov 13 21:28:36 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA09175; Wed, 13 Nov 1991 21:29:09 +1100 (from owner-Big-Internet) Return-Path: Received: from [131.174.80.1] by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA09152; Wed, 13 Nov 1991 21:28:36 +1100 (from lwj@cs.kun.nl) Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA10339; Wed, 13 Nov 91 11:28:23 +0100 Received: from iris by cs.kun.nl (4.1/SMI-3.2) id AA24448; Wed, 13 Nov 91 11:28:20 +0100 Message-Id: <9111131028.AA24448@cs.kun.nl> To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: Class E addresses (etc) In-Reply-To: Your message of "Wed, 13 Nov 91 09:54:29 +0100." <1488.689986469@munnari.oz.au> Date: Wed, 13 Nov 91 11:28:19 +0100 From: lwj@cs.kun.nl > The DNS issue that needs to be solved isn't how to delegate > the 16 zones to the owner of a class E net (which only needs > to be done in the IN-ADDR.ARPA zone anyway - the owners of > that zone can run special software if necessary), but just > how the delagee copes with making 16 SOA's, sets of NS's, > etc, all appear, and how we teach people how they will have > to divide up their PTR's into the 16 different zones they > inherit. Taking the puritan view, you are right. What currently happens in practice is that all these PTR records are stored in a *single* master file, with one SOA. The name server is made authoritative for this zone, although this is incorrect in principle. This is all managable for subnets of a single network (and is the way currently used on our campus), but becomes utterly unmanagable when the sub-byte delegations cross administrative boundaries. The real problem is that authoritative zones can now overlap. E.g. say organisation A has class E network X.Y.Z.0 (mask 255.255.240.0) and organisation B has class E network X.Y.Z'.0 (same mask). If the above aproach is used, both organisations will tell their nameservers that they are authoritative for Y.X.in-addr.arpa. Now, if either nameserver receives a request for an inverse mapping from the other organisation, it will respond with an *authoritative* name error. Furthermore, both organisations will have (different) SOA records for Y.X.in-addr.arpa. > So something like ENS isn't what's needed, you need something > to go in named.boot to tell named that its about to see a > zone that it needs to split 16 ways based on the values of the > labels, along with replication of the misc data (SOA, NS's etc) > - possible but very messy. Or you need a tool to take a > composite file and split it apart - easy for those who use tools > already to maintain DNS files, but a burden on those of us who > perfer to manually edit the DNS files as primary data sources. > You also need something to tell named to secondary 16 zones > from another server, but that one ie much easier. I agree that it is very messy, and it will be difficult to get people to use this way, because the other approach sort of "works" also. This will increase the amount of garbage in the DNS, which is already a problem sometimes. Someone needs to write an "nslint"; doc is a step in the right direction but not sufficient; it also cannot take master files. > I know named (BIND) isn't the only server, but for this purpose > it may as well be. If people who run some other (existing) > server (new ones should be written to cope once the problem > is known) were to request class B's rather than E's just for > this reason, it wouldn't be a major problem, there are so > few of them. Those few could also do the work by hand if > necessary (again, there are very few). Would not most organisations request a class B "just in case"? -- 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 Thu Nov 14 06:03:40 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20776; Thu, 14 Nov 1991 06:04:03 +1100 (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 AA19591; Thu, 14 Nov 1991 05:19:09 +1100 (from kre) To: lwj@cs.kun.nl Cc: big-internet@munnari.oz.au Subject: Re: Class E addresses (etc) In-Reply-To: Your message of Wed, 13 Nov 91 11:28:19 +0100. <9111131028.AA24448@cs.kun.nl> Date: Thu, 14 Nov 91 05:19:00 +0100 Message-Id: <1743.690056340@munnari.oz.au> From: Robert Elz Date: Wed, 13 Nov 91 11:28:19 +0100 From: lwj@cs.kun.nl Message-ID: <9111131028.AA24448@cs.kun.nl> The real problem is that authoritative zones can now overlap. E.g. say organisation A has class E network X.Y.Z.0 (mask 255.255.240.0) and organisation B has class E network X.Y.Z'.0 (same mask). If the above aproach is used, both organisations will tell their nameservers that they are authoritative for Y.X.in-addr.arpa. This is totally unworkable, and I hadn't heard anyone even suggest anything like this before. Clearly no-one will be delegated, or authoritative for, or should claim either of those, for Y.X.in-addr.arpa (for the class E 'X's), just as no-one does for 128.in-addr.arpa. Without DNS changes, which possibly should happen to the in-addr.arpa stuff - but that's an issue for other places, the only way to make class E in-addr.arpa zones work is to delegate the 16 (or however many) separate zones, and for the servers to claim to be authoritative for exactly those zones and no supersets of them. How the setup is done to aid humans make that happen is the only open question here - nothing is mandatory, it can be made to work as things stand now - but something should be done. Managing internal subnets not split on subnet boundaries is a similar problem, and should be solved with the same basic estensions (multiple delegations in one line, and multiple zones out of one file). Would not most organisations request a class B "just in case"? No, I don't think so. Most people understand the problems, and will request only what they're really likely to need. I mean, we could all be requesting class A's "just in case" but we don't. Enhancements in the handling of subnets, both by allowing variable sized subnets in one network, and fixing DNS implementations to make the in-addr.arpa handling of that practical, will both help in reassuring people that they don't need to over-estimate the size of their nets, just to be safe. Improvements in routing protocols will also assist by allowing subnets of 2 nets to be intermixed freely if this turns out to be necessary. kre From owner-Big-Internet@munnari.oz.au Fri Nov 15 00:57:27 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20209; Fri, 15 Nov 1991 00:57:38 +1100 (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 AA20198; Fri, 15 Nov 1991 00:57:27 +1100 (from kasten@europa.clearpoint.com) Received: by europa.clearpoint.com (4.1/1.34) id AA00588; Thu, 14 Nov 91 08:51:42 EST Date: Thu, 14 Nov 91 08:51:42 EST From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9111141351.AA00588@europa.clearpoint.com> To: big-internet@munnari.oz.au, jnc@allspice.lcs.mit.edu, solensky@animal.clearpoint.com Subject: Re: IP Address Hacks > From owner-Big-Internet@munnari.oz.au Mon Nov 11 15:39:44 1991 > From: solensky@animal.clearpoint.com (Frank T. Solensky) > To: big-internet@munnari.oz.au, jnc@allspice.lcs.mit.edu > Subject: Re: IP Address Hacks > > > Which brings up another point -- did we resolve the question on whether > Class E addresses would not be assigned until we ran out of Class B, or > would they start right away so that the remaining Class B numbers could be > assigned only to organizations that would find Class E to be too small? > > -- Frank Solensky > Catching up a bit late on some mail.... I recall that we wanted to start allocating the new address class right away to those that can use it. We would be "preserving" class B for the medium-large nets which need it. Those who can live with E should not "waste" class B space. Frank Kastenholz (the other frank at clearpoint) From owner-Big-Internet@munnari.oz.au Fri Nov 15 09:57:12 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA03697; Fri, 15 Nov 1991 10:07:20 +1100 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.64+1.3.1+0.50) id AA03407; Fri, 15 Nov 1991 09:57:12 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: from PTT.LCS.MIT.EDU (via ALLSPICE.LCS.MIT.EDU) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18234; Thu, 14 Nov 91 17:46:54 -0500 Received: by PTT.LCS.MIT.EDU id AA01351; Thu, 14 Nov 91 17:40:22 EST Date: Thu, 14 Nov 91 17:40:22 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9111142240.AA01351@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au Subject: New draft of Address Hack RFC available Cc: jnc@ALLSPICE.LCS.MIT.EDU A new draft of the RFC is now available. It's accessible via anonymous FTP on on ALLSPICE.LCS.MIT.EDU, pathname pub/addrhack.txt and it's in formatted ASCII. There are no changes of technical content since the last version, (i.e. still 12 bit rests in E with A# and C# to reserved), just a bunch more text to explain why each of these choices is the right thing. If people who care could cast a quick glance over this and send comments to the list I'd be grateful. Noel From owner-big-internet@munnari.oz.au Fri Nov 15 15:43:53 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA14226; Fri, 15 Nov 1991 15:43:54 +1100 (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 AA11422; Fri, 15 Nov 1991 14:20:26 +1100 (from kre) To: big-internet@munnari.oz.au Subject: Re: New draft of Address Hack RFC available In-Reply-To: Your message of Thu, 14 Nov 91 17:40:22 -0500. <9111142240.AA01351@PTT.LCS.MIT.EDU> Date: Fri, 15 Nov 91 14:20:18 +0100 Message-Id: <2526.690175218@munnari.oz.au> From: Robert Elz Date: Thu, 14 Nov 91 17:40:22 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-ID: <9111142240.AA01351@PTT.LCS.MIT.EDU> A new draft of the RFC is now available. It's accessible via anonymous FTP on on ALLSPICE.LCS.MIT.EDU, pathname pub/addrhack.txt and it's in formatted ASCII. With some help from Noel, this is now also available via anon ftp from munnari.oz.au [128.250.1.21] in big-internet/addrhack.txt so any of you having as much trouble ftp'ing to MIT as I've been having recently can fetch it from munnari. kre From owner-Big-Internet@munnari.oz.au Thu Nov 21 02:54:52 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA03474; Thu, 21 Nov 1991 02:55:04 +1100 (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 AA03467; Thu, 21 Nov 1991 02:54:52 +1100 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA00277; Wed, 20 Nov 91 10:50:23 EST Date: Wed, 20 Nov 91 10:50:23 EST From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9111201550.AA00277@animal.clearpoint.com> To: Big-Internet@munnari.oz.au Subject: Class E addresses and EGP Cc: solensky@animal.clearpoint.com Noel Chiappa pointed out an interesting issue with Class E addresses: EGP. The message format in RFC 827 stores network numbers and 'rest' parts in the minimal number of bytes to Do The Right Thing. At first, it seemed that all we'd have to do would be to rephrase the descriptions of the Network Reachability and Network Reachability Poll (NR, NR Poll) messages: in the NR message, the Network address field would be three bytes, zero-filled for Class E addresses and the Gateway IP address field would be two bytes, zero-filled to ease the parsing. Similarly, the definition the IP Source Network field (three bytes) in the NR Poll message would be extended to include Class E addresses: zero-fill with a single nybble on the right. On further reflection, though, this would work only if both ends recognized the Class E address format. If the receipient can't recognize it, it's most likely going to respond with an error message and drop a good part of the message. Anyone have any ideas about alternatives? -- Frank Solensky From owner-Big-Internet@munnari.oz.au Thu Nov 21 08:50:08 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA10764; Thu, 21 Nov 1991 08:50:15 +1100 (from owner-Big-Internet) Return-Path: Received: from ALLSPICE.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA10761; Thu, 21 Nov 1991 08:50:08 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA14363; Wed, 20 Nov 91 16:49:57 EST Date: Wed, 20 Nov 91 16:49:57 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9111202149.AA14363@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au, solensky@animal.clearpoint.com Subject: Re: Class E addresses and EGP Cc: jnc@ALLSPICE.LCS.MIT.EDU Well, if the router on the other end doesn't recognize class E, then you aare screwed no matter what you do. I don't think there's anything really good you *can* do at that point... Noel From owner-Big-Internet@munnari.oz.au Thu Nov 21 11:57:06 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17562; Thu, 21 Nov 1991 11:57:35 +1100 (from owner-Big-Internet) Return-Path: Received: from MrBill.CAnet.CA by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA17545; Thu, 21 Nov 1991 11:57:06 +1100 (from dennis@MrBill.CAnet.CA) Received: by MrBill.CAnet.CA id <105471>; Wed, 20 Nov 1991 19:53:38 -0000 From: Dennis Ferguson To: solensky@animal.clearpoint.com Subject: Re: Class E addresses and EGP Cc: Big-Internet@munnari.oz.au Message-Id: <91Nov20.195338gmt.105471@MrBill.CAnet.CA> Date: Wed, 20 Nov 1991 19:53:26 -0000 > On further reflection, though, this would work only if both ends recognized > the Class E address format. If the receipient can't recognize it, it's most > likely going to respond with an error message and drop a good part of the > message. > > Anyone have any ideas about alternatives? Any current EGP implementation worth its salt should probably throw up its hands in disgust when a neighbour sends it a class E address, and immediately drop the session. An EGP which doesn't do this is also one which could be coaxed to fill the router's forwarding table with garbage under slightly different circumstances. This means that class E addresses will almost certainly be a poison pill if sent to EGPs which don't understand it. This implies that if you are "fixing" EGP to understand class E addresses you'd also better include a way for an EGP to determine which of its neighbours understand class E addresses and which don't so we don't have to rely on configuration alone to avoid EGP failures. Pragmatically speaking, however, I don't think "fixing" routing protocols and IP forwarders to understand class E is a practical option here. Even if you could get every affected vendor to support class E in a hurry (something I doubt) you'll just end up doing the same thing all over again for class A', and class C', and whatever else you might decide to do. I don't think anyone wants to get into the rathole of having to continually modify software to support the "class de jour". What I think instead is that you've got to push for the development and wide deployment of "classless" routing protocols, which carry masks along with addresses, on the Internet so you can fiddle with address assignments to your hearts' content without having to "fix" something every time you do so. OSPF and IS-IS will already carry masks along with the addresses, and the IP forwarders in routers which fully support either of these protocols will support variable length masks as well. What is missing right now is a replacement low-end routing protocol, a la RIP, and an exterior routing protocol which carries net masks. I understand there is a RIP II BOF being held (or was held) at the current IETF to address the variable length network mask issue, so this may be in hand. The bigger problem is what to do about an exterior routing protocol, and for this I think the only practical solution is a modification to BGP to allow it to carry net masks. The problem with just adding network masks to the BGP protocol is that it is more complicated than one would first think (general support for network masks implies that BGP can no longer view the IP address space as flat, so you have to think about either defining a whole new set of semantics for hierarchical reachability announcements, or at least define a set of restrictions on such announcements to simplify the protocol without disallowing potentially useful capabilities). Adding network masks to BGP will require some hard work on the part of whoever does this, so I think it is important to find a sucke^H^H^H^H^Hvolunteer or two to start on this now. I don't think it is possible to "fix" EGP. It needs to be replaced. It is just that a replacement which is going to advance the network-number-reassignment cause doesn't exist yet. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Thu Nov 21 14:44:28 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22219; Thu, 21 Nov 1991 14:44:41 +1100 (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 AA22215; Thu, 21 Nov 1991 14:44:28 +1100 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA01172; Wed, 20 Nov 91 22:39:47 EST Date: Wed, 20 Nov 91 22:39:47 EST From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9111210339.AA01172@animal.clearpoint.com> To: dennis@mrbill.canet.ca Subject: Re: Class E addresses and EGP Cc: Big-Internet@munnari.oz.au >Any current EGP implementation worth its salt should probably throw >up its hands in disgust when a neighbour sends it a class E address, and >immediately drop the session. An EGP which doesn't do this is also one >which could be coaxed to fill the router's forwarding table with >garbage under slightly different circumstances. This means that class >E addresses will almost certainly be a poison pill if sent to EGPs >which don't understand it. This implies that if you are "fixing" EGP >to understand class E addresses you'd also better include a way for >an EGP to determine which of its neighbours understand class E addresses >and which don't so we don't have to rely on configuration alone to >avoid EGP failures. > OK -- I'll check router requirements and be sure that the section on EGP actually requires that unrecognized formats be dropped. Most of the problem could be detected in a neighbor at startup in the poll messages if the response indicated a bad IP address, I think, but wouldn't be detected right away if a more current router that happened to have a class A/B/C address wanted to mention a class E neighbor later on. >Pragmatically speaking, however, I don't think "fixing" routing protocols >and IP forwarders to understand class E is a practical option here... Agreed -- definitely.. The main reason that I'm going into this is to be able to indicate in the draft what some of the gotchas are before we go off and start injecting these addresses into the nets. The more side effects we can anticipate, the better. But we have to remember that the whole goal of this exercise is more to buy time so that the whole new architecture doesn't need to be developed and deployed by the end of next year. -- Frank Solensky PS: >I understand there is a RIP II BOF being held (or was held) at the >current IETF to address the variable length network mask issue, so >this may be in hand. Gary: care to say a few words? :-) -- Frank From owner-Big-Internet@munnari.oz.au Fri Nov 22 02:43:05 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA10818; Fri, 22 Nov 1991 02:43:14 +1100 (from owner-Big-Internet) Return-Path: Received: from ALLSPICE.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA10814; Fri, 22 Nov 1991 02:43:05 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA17393; Thu, 21 Nov 91 10:42:40 EST Date: Thu, 21 Nov 91 10:42:40 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9111211542.AA17393@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au, solensky@animal.clearpoint.com Subject: Re: Class E addresses and EGP Cc: jnc@ALLSPICE.LCS.MIT.EDU The RIP-II stuff has a mailing list, rip-ietf or some such. RIP-II will support variable width subnet masks. I'll respond in detail to the previous message (about what we should *really* be doing) in a bit; gotta go BoF at the moment. Noel From owner-Big-Internet@munnari.oz.au Fri Nov 22 05:53:46 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA15189; Fri, 22 Nov 1991 05:53:54 +1100 (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 AA15186; Fri, 22 Nov 1991 05:53:46 +1100 (from gmalkin@ftp.com) Received: by ftp.com id AA00546; Thu, 21 Nov 91 13:55:50 -0500 Date: Thu, 21 Nov 91 13:55:50 -0500 From: gmalkin@ftp.com (Gary Scott Malkin) Message-Id: <9111211855.AA00546@ftp.com> To: jnc@ALLSPICE.LCS.MIT.EDU Cc: big-internet@munnari.oz.au, solensky@animal.clearpoint.com, jnc@ALLSPICE.LCS.MIT.EDU In-Reply-To: Noel Chiappa's message of Thu, 21 Nov 91 10:42:40 EST <9111211542.AA17393@PTT.LCS.MIT.EDU> Subject: Class E addresses and EGP The RIP-II mailing list is ietf-rip@ftp.com (with the appropriate -request also). Gary (from the Norse meaning "Thrower of Spears") From owner-Big-Internet@munnari.oz.au Fri Nov 22 09:42:57 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20088; Fri, 22 Nov 1991 09:43:17 +1100 (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 AA20071; Fri, 22 Nov 1991 09:42:57 +1100 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA02242; Thu, 21 Nov 91 17:37:38 EST Date: Thu, 21 Nov 91 17:37:38 EST From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9111212237.AA02242@animal.clearpoint.com> To: Big-Internet@munnari.oz.au Subject: Class E and EGP Folks -- How feasible does this seem: in EGP, add a new code type to the neighbor aquisition message (say, code=5) as a Request/Class E knowlegable message? A receipient that can't deal with Class Es wouldn't know about this code and presumably return a Refuse response (code 2). Those that do return a Confirm (code 1). In response to receiving a 0, we know that the sender can't do Class E addresses, code 5 indicates it can. -- Frank From owner-Big-Internet@munnari.oz.au Sat Nov 23 01:58:31 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16195; Sat, 23 Nov 1991 01:58:40 +1100 (from owner-Big-Internet) Return-Path: Received: from nis.ans.net by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16191; Sat, 23 Nov 1991 01:58:31 +1100 (from pgross@ans.net) Received: by nis.ans.net id AA23686 (5.65c/IDA-1.4.4 for Big-Internet@munnari.oz.au); Fri, 22 Nov 1991 09:57:47 -0500 Message-Id: <199111221457.AA23686@nis.ans.net> To: Dennis Ferguson Cc: Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E addresses and EGP In-Reply-To: (Your message of Wed, 20 Nov 91 19:53:26 GMT.) <91Nov20.195338gmt.105471@MrBill.CAnet.CA> Date: Fri, 22 Nov 91 09:57:46 -0500 From: Phill Gross What I think instead is that you've got to push for the development and wide deployment of "classless" routing protocols, which carry masks along with addresses, .... The bigger problem is what to do about an exterior routing protocol, and for this I think the only practical solution is a modification to BGP to allow it to carry net masks. .... Adding network masks to BGP will require some hard work, so I think it is important to find a sucke^H^H^H^H^Hvolunteer or two to start on this now. Dennis, I'd like to support your suggestion to add subnet masks to BGP. This was discussed at the BGP WG this week in Santa Fe and several interesting things happened. I had a rough outline for a paper to specify subnets in BGP. I was also trying to sell the notion of an overall IP addressing and routing "Plan" for the Internet. The sketchy outlines I presented for each ("Plan" and BGP subnet masks) are below. (It should look a bit familiar to you, since it contains some points that you sent me earlier. I also solicitated comments from some other folks before taking it to the BGP WG). The BGP WG liked some of the points and seemed to not like others, but their real interest quickly turned toward solving the address depletion and routing scaling problems for the long-term. As a result, we will be forming a WG to examine approaches to the ROuting and ADressing (ROAD) problem. (Naturally, folks involved in this WG will be called "ROAD Worriers", but that's another story). I believe this is a very positive result, and you will hear more about that angle in the notes of the BGP WG. However, I would still like to solicit comments on the outline for the BGP subnets masks paper. Is there anything we can do to get started on the BGP subnet mask thing in parallel with the ROAD work? I am cc'ing the BGP mailing list, since I assume that any follow-up discussion on BGP subnet masks should happen on that list. Phill "Outline For A Plan For Near-Term IP Routing And Addressing In The Internet" (18 Nov 1991, PG) 1. Develop IP Routing and Addressing Plan The "Plan" should address both protocol and operational issues. The "Plan" could be composed of several related papers. For example, a paper on the "IP address hack" issue is being written. Another possible paper on "How to use IP subnets masks in BGP" is outlined below. A. IP Addressing Architecture - How are IP addressing and routing related in the Internet model? Does Internet addressing serve the Internet routing model well? - How to hack current format to extend IP address space for the "near-term". - How to assign IP addresses in a coherent way that will rationalize and conserve address space (eg, eliminate A/B/C addressing format using "supernet mask" concept) B. Routing Protocol Architecture - Overview of IGP/EGP model - New Requirements (eg, policy, large tables, new net technology, etc) - How EGPs and IGPs use addresses for routing - How to pass information between IGPs and EGPs - How to pass information between different EGPs - (What else?) - Some issues include: - How to route in a multi-protocol environment? - use default routes? - pass subnet masks between IGP/EGP? - discontiguous subnets? - "logical IP addressing" - multiple logical nets on a wire - advocate use of policy stuff (in BGP &/or IDPR) - security - TOS routing and priority queueing - (what are some other issues?) C. Operational Routing Architecture - Summary of current Routing protocols (Dual IS-IS, OSPF, BGP, IDPR, RIP) - Routing between NSFnet and Regionals - Deploying BGP - How BGP and IDPR interact - Routing between commercial and research networks - Multi-protocol routing - (What else needs to be considered?) 2. Advocate that elements of the Addressing and Routing Plan be reflected into all current routing protocols SOME ISSUES: - Is this needed? How related to long-term efforts? - How to handle in Multi-protocol environment? "How To Use Subnet Masks in BGP" (22 Nov 1991, PG) (Sections 1-3 could be structured as a "Requirements" paper and section 4 below could become separate individual papers.) 1. Motivation for passing subnet masks between AS boundries - To eliminate A/B/C addressing format (BGP WG) - "Supernet Masks" to condense tables (BGP WG) - Partition healing between multiply connected backbones - Toward "Virtual Private net" capabilities - To aid routing to mobile hosts (Dennis Ferguson) - To aid addressing hacks to extend the current IP address space (DF) - Elimination of "extra hop" at NSFNet/regional "DMZ's" (Matt Mathis) - other reasons? 2. Some Issues to consider if subnet masks are used in inter-domain routing: - Need to define "Supernet Mask" concept carefully; need to worry about migration and impact on other aspects of routing architecture - Have to think about either defining a whole new set of semantics for hierarchical reachability announcements, or at least define a set of restrictions on such announcements to simplify the protocol without disallowing potentially useful capabilities (Ferguson) - How to control the amount of routing information in the Internet; without some constraints, passing subnet masks could act in opposition to the original reason for creating subnets -- namely, to condense routing information. (Moy/Gross) - How to avoid allowing people to assign their addresses in such a way that older protocols like EGP (probably not such a big deal) or RIP (probably a bigger deal) might not be able to route them. (Moy) - Other generic issues to worry about? 3. General interaction between BGP and IGPs to pass subnet masks - Passing and using subnet masks between the IGP to BGP - Passing and using subnet masks between BGP to the IGP - Perhaps include sections on interactions for specific IGPs (eg, OSPF, IS-IS) as appendices (or, separate documents) 4. Sections (or individual papers?) on how to solve the problems in 1. above. - How to use "supernet masks" in BGP to condense routing tables.... - How to heal partitions between multiply connected backbones using subnet masks in BGP. - How to eliminate the extra hop using ..... - How to provide a "virtual private net"-like capability using ... - How to do other stuff with subnet masks in BGP..... Questions - Is outline complete? What else needs to be covered in the paper? - Are there more good reasons for wanting masks in BGP? - Are there volunteers to write sections (or papers) of Chap 4 ? From owner-Big-Internet@munnari.oz.au Sun Nov 24 17:45:40 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA27084; Sun, 24 Nov 1991 17:45:52 +1100 (from owner-Big-Internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA27081; Sun, 24 Nov 1991 17:45:40 +1100 (from medin@nsipo.nasa.gov) Received: Sat, 23 Nov 91 22:44:29 PST from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9111240644.AA08464@dscs.arc.nasa.gov> To: Phill Gross Cc: Dennis Ferguson , Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E addresses and EGP In-Reply-To: Your message of "Fri, 22 Nov 91 09:57:46 EST." <199111221457.AA23686@nis.ans.net> Date: Sat, 23 Nov 91 22:44:19 -0800 From: "Milo S. Medin" (NASA ARC NSI Project Office) Phill, I think this is a very good idea. We know the protocol needs to be modified to carry masks. We can implement this now, and issue a followon document on how to process it. This will accelerate implementation. Thanks, Milo From owner-Big-Internet@munnari.oz.au Tue Nov 26 07:41:02 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA15833; Tue, 26 Nov 1991 07:41:10 +1100 (from owner-Big-Internet) Return-Path: Received: from watson.ibm.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA15830; Tue, 26 Nov 1991 07:41:02 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0964; Mon, 25 Nov 91 15:40:51 EST Date: Mon, 25 Nov 91 15:37:41 EST From: yakov@watson.ibm.com To: medin@nsipo.nasa.gov, pgross@ans.net, dennis@mrbill.canet.ca, Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Class E and EGP >Phill, I think this is a very good idea. We know the protocol needs >to be modified to carry masks. We can implement this now, and issue >a followon document on how to process it. This will accelerate >implementation. > > Thanks, > Milo Let me repeat what had been said before by Hans-Werner: "I have no problems with net masks in general, but would like to see an architecture document to design it before requiring every protocol to support it. In the BGP case we are talking about inter-AS routing, likely between clusters of network numbers, which is where my comments regarding the net number distribution were coming from. If certain things could be rationalized by using network number masks as a vehicle, great ! But, really, someone needs to sit down and think about the "how" prior to possibly making mistakes in the protocol evolution. So, it makes me a little uncomfortable to see protocols instrumented with fields which's implications are not well understood. I can think of other fields that would be nice to have, but where the utility and architecture should be inverstigated first for working at a global scale." To summarize, I would really like to see the proponents of putting masks (or subnet masks) in BGP to answer concerns raised by Hans-Werner. I would also suggest that ANY proposal on masks in BGP should be required to addresses the concerns raised by Hans-Werner. Yakov. From owner-Big-Internet@munnari.oz.au Tue Nov 26 16:28:14 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA01289; Tue, 26 Nov 1991 16:28:30 +1100 (from owner-Big-Internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA01276; Tue, 26 Nov 1991 16:28:14 +1100 (from medin@nsipo.nasa.gov) Received: Mon, 25 Nov 91 21:25:19 PST from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9111260525.AA10209@dscs.arc.nasa.gov> To: yakov@watson.ibm.com Cc: pgross@ans.net, dennis@mrbill.canet.ca, Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: Your message of "Mon, 25 Nov 91 15:37:41 EST." <9111252040.AA10790@nsipo.arc.nasa.gov> Date: Mon, 25 Nov 91 21:25:10 -0800 From: "Milo S. Medin" (NASA ARC NSI Project Office) I would like to ask the group to consider whether or not any disagrees with my opinion that will need netmask support in the future. It will also be necessary to use BGP as a RIP replacement when a WAN provider attaches to a campus subnet. One could use proxy-arp I guess, like MERIT does, but there are also problems with this approach. Let's talk about subnet masks the book, not the movie. I would seriously like to know if and why people think adding masks would be a mistake in protocol evolution... Thanks, Milo From owner-Big-Internet@munnari.oz.au Tue Nov 26 17:41:55 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA03537; Tue, 26 Nov 1991 17:42:00 +1100 (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 AA03534; Tue, 26 Nov 1991 17:41:55 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Mon, 25 Nov 91 22:41:40 -0800 Date: Mon, 25 Nov 91 22:41:40 -0800 From: Tony Li Message-Id: <9111260641.AA21622@lager.cisco.com> To: medin@nsipo.nasa.gov Cc: yakov@watson.ibm.com, pgross@ans.net, dennis@mrbill.canet.ca, Big-Internet@munnari.oz.au, iwg@rice.edu In-Reply-To: "Milo S. Medin" (NASA ARC NSI Project Office)'s message of Mon, 25 Nov 91 21:25:10 -0800 <9111260525.AA10209@dscs.arc.nasa.gov> Subject: Class E and EGP I would like to ask the group to consider whether or not any disagrees with my opinion that will need netmask support in the future. I assume you mean in BGP. ;-) What do you mean by "need"? Is it a cute hook that you could add? Yes. Would it solve some problems? Yes. Will the Internet collapse if we don't do this? Maybe. Maybe not. What do you intend to do with masks? What problem do they solve and what do they mean? If you were defining a programming language, I would ask you for the syntax and semantics of the construct that you were proposing. I would ask you if it increases the "power" of the language. For BGP, the syntax of masks is straightforward. What are the semantics? How does it make BGP more powerful? I believe that I understand the semantics of the case of subnet masks. I see how they can solve some minor problems when dividing a network number amongst AS's. I am not yet convinced that the win is worth the effort. I do not begin to understand all of the implications of super masks. While this might be a very big win, it looks difficult to utilize. If there were a coherent explanation of the semantics and their usage, the arguments for masks would be much more convincing. Until then, bells and whistles belong on my VCR... Tony From owner-Big-Internet@munnari.oz.au Tue Nov 26 19:17:57 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA05876; Tue, 26 Nov 1991 19:18:36 +1100 (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 AA05871; Tue, 26 Nov 1991 19:17:57 +1100 (from kre) To: yakov@watson.ibm.com Cc: medin@nsipo.nasa.gov, pgross@ans.net, dennis@mrbill.canet.ca, Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: Your message of Mon, 25 Nov 91 15:37:41 -0500. Date: Tue, 26 Nov 91 19:17:51 +0100 Message-Id: <5784.691143471@munnari.oz.au> From: Robert Elz Date: Mon, 25 Nov 91 15:37:41 EST From: yakov@watson.ibm.com Let me repeat what had been said before by Hans-Werner: "I have no problems with net masks in general, but would like to see an architecture document to design it before requiring every protocol to support it. In the BGP case we are talking about inter-AS routing, likely between clusters of network numbers, This is what I see as the key point - Hans-Werner (and many others I believe) have a world view which sees "network classes" (A B C etc) as an inherent fact of life, without those, and without netmasks, there's no way for BGP (or any other protocol) to tell just what is the network number in a packet its sent. Currently the A/B/C stuff is ingrained, all over the place. This has to change - at the very least, there has to be a new address class to help keep addresses available. As I understand it currently, this is going to mean that all BGP implementations will have to be upgraded to cope with the new class, and then perhaps angain in the future perhaps if the address structure has to change again. Adding masks allows the network numbers to be totally decoupled from the "classes" - in the immediate future the netmasks passed around will probably simply reflect the current net classes, that is, adding the netmask doesn't necessarily mean any increase in flexibility or functionality, but it is essential. In the future perhaps BGP may allow partitioned net numbers to be linked, by allowing subnet-masks to be passed around, or even adjacent numbers to be coalesced by passing a superset mask. But all this can wait. Just add provision for passing the mask, and pass it in all cases, removing all A/B/C network class knowledge from the implementations. Then you'll get class E support for free... kre From owner-Big-Internet@munnari.oz.au Tue Nov 26 23:09:30 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA10325; Tue, 26 Nov 1991 23:09:37 +1100 (from owner-Big-Internet) Return-Path: Received: from gizmo.bellcore.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA10313; Tue, 26 Nov 1991 23:09:30 +1100 (from mo@gizmo.bellcore.com) Received: by gizmo.bellcore.com (5.61/1.34) id AA07605; Tue, 26 Nov 91 07:08:43 -0500 Date: Tue, 26 Nov 91 07:08:43 -0500 From: mo@gizmo.bellcore.com (Michael O'Dell) Message-Id: <9111261208.AA07605@gizmo.bellcore.com> To: big-internet@munnari.oz.au Subject: adding netmasks to routing goop.... another way of looking at this (and why it is attractive) is that it is a way to get everyone accustom to the notion that addresses are really 64-bits long. The current use is to perform some operation of the two halve to produce a smaller cookie for use in packet headers, but getting the world 64-bit-convinced starts opening the crack needed to leverage things into the next world.... -Mike From owner-Big-Internet@munnari.oz.au Wed Nov 27 03:12:40 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16116; Wed, 27 Nov 1991 03:12:47 +1100 (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 AA16113; Wed, 27 Nov 1991 03:12:40 +1100 (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 AA25697; Tue, 26 Nov 91 11:11:08 EST Message-Id: <9111261611.AA25697@mitchell.cit.cornell.edu> To: "Milo S. Medin" (NASA ARC NSI Project Office) Cc: Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: Your message of "Mon, 25 Nov 91 21:25:10 PST." <9111260525.AA10209@dscs.arc.nasa.gov> Date: Tue, 26 Nov 91 11:11:07 -0500 From: Scott Brim Hey, Milo.... >I would seriously >like to know if and why people think adding masks would be a mistake >in protocol evolution... That's like asking if we need GUIs -- the answer is that netmasks would obviously a nice thing. You've backed off from your original statement, which was basically that we should just implement it now and figure out the finer points of how to use it later. I share others' concern about that. Could you please write down exactly how you think netmasks should be used (not just what the BGP attribute should look like in the packet), and also how they should not be used? Don't necessarily make it a thorough analysis, but at least give it some technical substance. You're in just as good a position to do this as anyone else. Scott From owner-Big-Internet@munnari.oz.au Wed Nov 27 03:25:02 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16332; Wed, 27 Nov 1991 03:25:10 +1100 (from owner-Big-Internet) Return-Path: Received: from nis.ans.net by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16329; Wed, 27 Nov 1991 03:25:02 +1100 (from pgross@ans.net) Received: by nis.ans.net id AA19913 (5.65c/IDA-1.4.4 for Big-Internet@munnari.oz.au); Tue, 26 Nov 1991 11:22:57 -0500 Message-Id: <199111261622.AA19913@nis.ans.net> To: "Milo S. Medin" (NASA ARC NSI Project Office) Cc: Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: (Your message of Mon, 25 Nov 91 21:25:10 PST.) <9111260525.AA10209@dscs.arc.nasa.gov> Date: Tue, 26 Nov 91 11:22:56 -0500 From: Phill Gross I would seriously like to know if and why people think adding masks would be a mistake in protocol evolution... Milo, One problem that might be worrying folks is that allowing subnet masks in BGP advertisments could potentially explode the size of the routing tables (ie, without some restrictions, you could begin to see many subnets in BGP updates. This would work against the reason for inventing subnet masks in the first place -- to reduce routing table size). I believe this is why Yakov and others want to see a careful "How to use..." document before changing the BGP spec. If this is the case, then let's focus on the "How to..." document. Ok, so how would you use subnets in BGP? And, what are the restrictions that need to be placed on the usage of subnet masks? Phill From owner-Big-Internet@munnari.oz.au Wed Nov 27 03:26:34 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16391; Wed, 27 Nov 1991 03:26:43 +1100 (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 AA16385; Wed, 27 Nov 1991 03:26:34 +1100 (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 AA26154; Tue, 26 Nov 91 11:26:22 EST Message-Id: <9111261626.AA26154@mitchell.cit.cornell.edu> To: Robert Elz Cc: Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: Your message of "Tue, 26 Nov 91 19:17:51 +0100." <5784.691143471@munnari.oz.au> Date: Tue, 26 Nov 91 11:26:22 -0500 From: Scott Brim Robert: >This is what I see as the key point - Hans-Werner (and many >others I believe) have a world view which sees "network classes" >(A B C etc) as an inherent fact of life, without those, and Neither Hans-Werner nor Yakov said anything about the old class structure. It would be perfectly easy to have a mask attribute in BGP and to make it loop-free (internal routing databases and forwarding databases would be more difficult). I (and others) have questions about how to use them, for example about aggregation/coalescence behavior. If we do it wrong, BGP (and IDRP??) will no longer be provably loop-free. Just putting the mask attribute in the spec would be all right, except if we don't understand how to use it (1) people will use it inconsistently and we may get hurt, and (2) we may have to change it if, as we work out how to use it we discover that what we specified isn't enough. So that's why I asked Milo to do the first strawman for IWG to blow over. Let's at least spend a little time talking about how we are going to use it. In the masking BOF two IETFs ago, I thought it became clear that there are all sorts of wormcans when you start actually trying to deploy netmasks. You were in the front row -- don't you agree? Do you know if there were any notes from that BOF published? Scott From owner-Big-Internet@munnari.oz.au Wed Nov 27 05:17:21 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA18585; Wed, 27 Nov 1991 05:17:45 +1100 (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 AA18576; Wed, 27 Nov 1991 05:17:21 +1100 (from kre) To: Scott Brim Cc: Big-Internet@munnari.oz.au, iwg@rice.edu, hwb@sdsc.edu Subject: Re: Class E and EGP In-Reply-To: Your message of Tue, 26 Nov 91 11:26:22 -0500. <9111261626.AA26154@mitchell.cit.cornell.edu> Date: Wed, 27 Nov 91 05:17:10 +0100 Message-Id: <5950.691179430@munnari.oz.au> From: Robert Elz First I want to apologise to Hans-Werner for mis-representing his views, which I apparently did - problem of extrapolating from a quote without the necesary context I expect. However, I still can't help but wonder how anyone can argue in any way that there's anywhere at all that netmasks don't belong to be carried along with network numbers - the mask is (will be) the only reliable way to determine which of the 32 bits actually is the network number - while addresses remain 32 bits at all. As I see it they're simply essential, everywhere. Date: Tue, 26 Nov 91 11:26:22 -0500 From: Scott Brim Message-ID: <9111261626.AA26154@mitchell.cit.cornell.edu> I (and others) have questions about how to use them, for example about aggregation/coalescence behavior. I would have no objections (now) to simply requiring that the netmask be the "natural" mask for the network number, forbidding any subnet or supernet masks. To take the risk of possibly mis-representing again, I suspect that's approximately also what Milo meant in his "We can implement this now" comment. That is, the purpose of the netmask would be simply to allow implementations to avoid retaining built in rules about how to find the network number. Work on what other uses the mask field could have can be done later - perhaps no other safe use will ever be found, perhaps careful use of subnet masks will be found to be safe but not superset masks, or whatever. But existance of the masks is needed now. I would expect that in any case the filter lists of legal numbers to receive in bgp announcements from various peers will (would have to be) extended to be net-number / mask pairs, so errors in masks coming from some site would be detected, just as bogus net numbers are. In the masking BOF two IETFs ago, I thought it became clear that there are all sorts of wormcans when you start actually trying to deploy netmasks. You were in the front row -- don't you agree? No, not in this sense. Working out just what are reasonable combinations of netmasks to use is not trivial - but once you have those I don't see them as being especially difficult for routing, or uses in routing protocols. Coalescing them isn't trivial in general - if it weren't for the need to do this, and all routing tables simply carried all subnet-mask pairs in use on the internet, routing would be trivial (yes, I know its totally impractical, and undesireable, and I refer only to the simple routing decision, no intention to ignore TOS, or mrging routing protocols, or policy routing, or any of the other complications). However I don't see any special magic in coalescing net numbers into "natural" masks, (that is, class A B and C masks) which I don't think should exist at all, except as a convenience for the NIC in allocating numbers. If I had a class B that was only half used (and wasn't going to be more than half used) I'd like to be able to donate the other half to some other similar sized organisation. If that were possible by simply passing around the net numbers, and mask of 255.255.128.0 and then everyone simply treating them as two independant numbers we could avoid allocation of one more class B for the other site. Nothing else alters at all (regardless of where on the Internet the two sites are connected) - but we need masks in all the protocols for this to work. There are many other possibilities. Do you know if there were any notes from that BOF published? There haven't been yet - I'm working on them - sorry for the delay, very soon now, though I'm going to be away for much of the rest of the year (summer vacation time around here), so it might not be till around Christmas that the first draft is ready for perusal (which is later than I thought even a week or two ago). kre From owner-Big-Internet@munnari.oz.au Wed Nov 27 05:42:38 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19201; Wed, 27 Nov 1991 05:42:51 +1100 (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 AA19197; Wed, 27 Nov 1991 05:42:38 +1100 (from kre) To: Phill Gross Cc: Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: Your message of Tue, 26 Nov 91 11:22:56 -0500. <199111261622.AA19913@nis.ans.net> Date: Wed, 27 Nov 91 05:42:28 +0100 Message-Id: <5963.691180948@munnari.oz.au> From: Robert Elz Date: Tue, 26 Nov 91 11:22:56 -0500 From: Phill Gross Message-ID: <199111261622.AA19913@nis.ans.net> One problem that might be worrying folks is that allowing subnet masks in BGP advertisments I see this as the major point of confusion - its not "subnet" masks that need to be added, its "network" masks. Obviously a network mask could become what you now think of as a subnet mask, but it need not. The problem is largely that people seem to have become ingrained into thinking of the mask as being useful only to specify subnets, which I contend they're not. As Mike O'Dell said - we should regard the network number & mask as an integral 64 bit entity, neither part terribly useful without the other. This would seem to be an essential pre- requisite to making any kind of forward step in the IP address architecture. If it proves unreasonable to transport subnets across BGP (as is currently forbidden) that's OK - a little less functional than it could be, but compromises are necessary. But don't use that to forbid nets 126.1.0.0 and 126.2.0.0 (with netmask 255.255.0.0 in each case) just because you're used to net 126.x.y.z being a class A net with a mask of 255.0.0.0. When its actually assigned, it might not be that at all. kre From owner-Big-Internet@munnari.oz.au Wed Nov 27 06:12:24 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19717; Wed, 27 Nov 1991 06:12:46 +1100 (from owner-Big-Internet) Return-Path: Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA19712; Wed, 27 Nov 1991 06:12:24 +1100 (from medin@nsipo.nasa.gov) Received: Tue, 26 Nov 91 11:10:44 PST from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Message-Id: <9111261910.AA01348@cincsac.arc.nasa.gov> To: Robert Elz Cc: yakov@watson.ibm.com, pgross@ans.net, dennis@mrbill.canet.ca, Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: Your message of "Tue, 26 Nov 91 19:17:51 +0100." <5784.691143471@munnari.oz.au> Date: Tue, 26 Nov 91 11:10:43 -0800 From: "Milo S. Medin" (NASA ARC NSI Project Office) I strongly agree with Robert. If there are any changes to be made to support this "bogus" Class E address, theeen let's make sure BGP implements them in as general way as possible. I say bogus, because as I understand it, people are going to end up spending 90% of the work need to implement general mask support on class E support, and we will likely force these people to rev implementations again. This does not mean we should use all kinds of weird masks from day 1, we may use only "Class E" addresses. But the implementations should all support masks in a general way. I had an interesting chat with Radia Perlman on this subject. I likened the class issue to problems in learning morse code. If you learn morse as translating sounds to dots and dashs, and then dots and dashes to letters, you hit a plateau at about 10 words per minute. If you learn morse by translating sounds direct to characters (like dididi -> S, instead of dididi -> . . . -> S), then you do not hit this plateau. People end up getting confused about nets and subnets and variable mask support etc, because they are raised to believe there are class A nets, class B nets, class C nets, 8 bit subnets, etc... They never think generally. We need to make sure people think (and implement generally). RIP doesn't do this. It makes assumptions about subnet masks. So does BGP. All I'm asking for is to turn these assumptions into entries in fields. Thanks, Milo From owner-Big-Internet@munnari.oz.au Wed Nov 27 06:12:38 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA19720; Wed, 27 Nov 1991 06:12:49 +1100 (from owner-Big-Internet) Return-Path: Received: from flash.bellcore.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA19714; Wed, 27 Nov 1991 06:12:38 +1100 (from mo@gizmo.bellcore.com) Received: from gizmo.bellcore.com by flash.bellcore.com (5.65/1.34) id AA10459; Tue, 26 Nov 91 14:12:29 -0500 Message-Id: <9111261912.AA10459@flash.bellcore.com> To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: Network masks... In-Reply-To: Your message of "Wed, 27 Nov 91 05:42:28 +0100." <5963.691180948@munnari.oz.au> Date: Tue, 26 Nov 91 14:11:12 -0500 From: mo@gizmo.bellcore.com We have had networks masks ever since we instituted more than one address class - the only problem is that we cleverly encoded the 32-bits of the network mask in the upper 1, 2, or 3 bits of the 32-bit IP address. When that encoding was found lacking, we coined the phrase "subnet mask" (an honestly inspired hack at the time - in the best tradition of the phrase), handled the additional bits as a separate object (subject to the usual loss, damage, and misconfiguration) and hoped it would be doing something else for a living when that decision caught up with us. well guess what - it's caught up with us, or at least some of us. Phil Karn's network code comes the closest to getting it right so far - his code has no notion of "address class" anywhere in it. It only has addresses and masks, and they must be specified together when you configuring things. the mask is used for all testing, so he can float the "net/subnet" and "rest" boundary back and forth with 1 bit granularity. so, I realize we can't break everything at once. the internet world has been very, very good at treading the line between progress and stasis, but in the words of a great song: Somethin's gotta give Somethin's gotta give Somethin's gotta give -Mike From owner-Big-Internet@munnari.oz.au Wed Nov 27 07:02:56 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20656; Wed, 27 Nov 1991 07:03:02 +1100 (from owner-Big-Internet) Return-Path: Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20653; Wed, 27 Nov 1991 07:02:56 +1100 (from medin@nsipo.nasa.gov) Received: Tue, 26 Nov 91 12:02:18 PST from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Message-Id: <9111262002.AA01432@cincsac.arc.nasa.gov> To: Phill Gross Cc: Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: Your message of "Tue, 26 Nov 91 11:22:56 EST." <199111261622.AA19913@nis.ans.net> Date: Tue, 26 Nov 91 12:02:17 -0800 From: "Milo S. Medin" (NASA ARC NSI Project Office) You could, but this is what you want in some cases. People seem to be confused about what environments BGP would be used in. I think I have the view of a WAN provider who needs to pick up subnet routes from an OSPF speaking campus. I would like BGP to do this. Maybe people should just say that BGP is not appropriate to use in this case. These routes would be collapsed at the WAN border router, and a summary net route could be sent into the IGP, and then onward to other BGP speakers on other sides of the transit AS. But that last part isn't interesting to me now. I could use BGP strictly as an interface between AS's, and not have that BGP conversation play at all with the big transit BGP system. In fact, I have less need for the big transit BGP system now, than I do for the campus interconnects. If we are talking about BGP to movie, then a lot more work has to be done on BGP subnetting specs. But in the BGP the trashy paperback scenario, I expect much less of it, and there using subnets is pretty easy. It's just like running RIP on your router... If people aren't interesting in supporting isolated BGP conversations, where BGP isn't used as part of a multi transit AS system, then please say so... Thanks, Milo From owner-Big-Internet@munnari.oz.au Wed Nov 27 07:13:19 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20773; Wed, 27 Nov 1991 07:13:30 +1100 (from owner-Big-Internet) Return-Path: Received: from ALLSPICE.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20769; Wed, 27 Nov 1991 07:13:19 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA07672; Tue, 26 Nov 91 15:12:59 EST Date: Tue, 26 Nov 91 15:12:59 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9111262012.AA07672@PTT.LCS.MIT.EDU> To: iwg@rice.edu.big-internet@munnari.oz.au, medin@nsipo.nasa.gov Subject: Re: Class E and EGP Cc: jnc@ALLSPICE.LCS.MIT.EDU I don't have time to type in a detailed response now, but everyone needs to understand that simply adding masks to BGP is not neccessarily going to solve our problems. A lot depends on how they are used. In fact, if used the wrong way, it could makes things worse, and something I've learned is that people usually use any protocol in every way they can, including the bad ways. (Rule #1.) The challenge is to reduce the number of objects which must be known about at a global level in the routing. So. Adding subnet masks to BGP, to allow a network to be split between AS's, will make the problem worse if the two parts have to be globally visible. People have already started to split IP networks into disjoint pieces (see Rule #1). Use of the mask as a supernet mask, to agglomerate several network numbers together, does have some potential. Realize though, that this requires separate administrations to cooperate on allocating address space. Why can't/don't they do this now, with a single net number? Alternatively, to make real use of this, we are going to have to go through massive renumbering to rationalize the allocation of IP network numbers to various areas of the network topology. Now, none of this is to say that it is not possible/desireable. However, it is not going to be easy to make sure that the gains of such a change outweigh the costs. Noel From owner-Big-Internet@munnari.oz.au Wed Nov 27 07:44:07 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21455; Wed, 27 Nov 1991 07:44:23 +1100 (from owner-Big-Internet) Return-Path: Received: from MrBill.CAnet.CA by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA21449; Wed, 27 Nov 1991 07:44:07 +1100 (from dennis@MrBill.CAnet.CA) Received: by MrBill.CAnet.CA id <105495>; Tue, 26 Nov 1991 15:41:03 -0000 From: Dennis Ferguson To: kre@munnari.oz.au Subject: Re: Class E and EGP Cc: Big-Internet@munnari.oz.au, iwg@rice.edu, pgross@ans.net Message-Id: <91Nov26.154103gmt.105495@MrBill.CAnet.CA> Date: Tue, 26 Nov 1991 15:40:57 -0000 Robert, > I see this as the major point of confusion - its not "subnet" > masks that need to be added, its "network" masks. [...] > If it proves unreasonable to transport subnets across BGP > (as is currently forbidden) that's OK - a little less functional > than it could be, but compromises are necessary. But don't > use that to forbid nets 126.1.0.0 and 126.2.0.0 (with netmask > 255.255.0.0 in each case) just because you're used to net > 126.x.y.z being a class A net with a mask of 255.0.0.0. When > its actually assigned, it might not be that at all. No, I don't think this is quite the point. One of the things network classes do is provide a set of rules constraining topology and addressing. You can summarize routing information automatically because you know these rules, and hence you know when it is topologically valid and safe to summarize. By deleting classes you've removed the rules. The question then becomes, how do you know when to summarize? If the BGP-speaking router also is running OSPF, and has a routing table full of things like 126.1.2.0 and 126.2.4.0 mask 255.255.255.0, how does it know what you really mean BGP to export is 126.1.0.0 and 126.2.0.0 mask 255.255.0.0, and not all the gory detail? And if the answer is "configuration", what is the default behaviour? Do we really want to make changes in such a way that one needs an advanced degree in configuration science to set up a router? Note, too, that new address allocations are not the only reason there is demand for classlessness in BGP, and summarization of internal routing during IGP->EGP route leaking is not the only place where summarization is demanded in support of this. If you want masks in BGP to get the next hop right at a backbone-client gateway what you really want is summarization during EGP->IGP routing leaking. If your aim is support of "virtual private networks" what you really want is summarization of during IGP->EGP leaking of external routes. If your aim is to route an entire regional using network 36 you want re-summarization at several places. If you add to this the fact that classes do allow BGP to treat its address space as flat, while classlessness necessitates some thought about heirarchical routes (i.e. 126.0.0.0 mask 255.0.0.0 and 126.1.0.0 mask 255.255.0.0 in the same routing database) then the problems multiply. And, of course, additional AS numbers cost BGP at least as much as additional network numbers, so if you turn BGP into a protocol to provide filtering at every OSPF-OSPF point of contact you've got to think about managing the proliferation of AS's as well. Now I agree that reallocation of the address space to make it last longer is an important issue and needs to be addressed quickly. I would suggest, however, that we must be careful about changes to routing protocols whose operation has impact for the entire Internet, since it won't matter a damn how we allocate addresses if the routing technology we have isn't up to carrying the load demanded of it. Because of this I don't think it is reasonable to add function to BGP which could potentially increase the size of the routing table in a default-free router from 3000 to 50,000 without simultaneously doing what needs to be done to make sure the latter doesn't happen. We need new rules to replace the ones you want to discard by removing classes, and the protocol support to implement and enforce them, and I know of no way to even start working on this without a complete understanding of the problems we want solved by this. If the fix for an in-grown toenail could potentially cause heart failure, I might prefer to live with the in-grown toenail. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Wed Nov 27 08:10:04 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA21971; Wed, 27 Nov 1991 08:10:22 +1100 (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 AA21968; Wed, 27 Nov 1991 08:10:04 +1100 (from kre) To: Dennis Ferguson Cc: Big-Internet@munnari.oz.au, iwg@rice.edu, pgross@ans.net Subject: Re: Class E and EGP In-Reply-To: Your message of Tue, 26 Nov 91 15:40:57 -0000. <91Nov26.154103gmt.105495@MrBill.CAnet.CA> Date: Wed, 27 Nov 91 08:09:56 +0100 Message-Id: <6085.691189796@munnari.oz.au> From: Robert Elz Date: Tue, 26 Nov 1991 15:40:57 -0000 From: Dennis Ferguson Message-ID: <91Nov26.154103gmt.105495@MrBill.CAnet.CA> I think I've said (and mis-said) just about enough on this topic for one brief period, however... The question then becomes, how do you know when to summarize? And if the answer is "configuration", what is the default behaviour? The answer is configuration, and there is no default behaviour. Do we really want to make changes in such a way that one needs an advanced degree in configuration science to set up a router? I think this is a little over stated... Assuming we're not doing anything like spreading subnets or coalescing nets (yet), then all that's needed is one number/mask pair per allocated net number (of whatever class, or fraction of a class or whatever it ends up being). This is approximately equivalent to configuring the IP address of each interface that has one, which must also be done - it requires no intelligence (even less that configuring IP addresses, and interface subnet masks, as no-one explicitly tell you the answer to that question), and can't really be hard. All you're doing is explicitly telling the router the information it can now deduce from the class of the addresses it sees. Average sites won't have a problem at all. Certainly the huge sites, regionals, and backbone nets will have a slightly harder job, but they're generally expected to have (and need) some expertise in the area. If the fix for an in-grown toenail could potentially cause heart failure, I might prefer to live with the in-grown toenail. I think you have the wrong analogy - what we have is not an in-grown toenail, but a cancer, and while curing the cancer might cause heart failure, for which we do have time to prepare and hopefully recover if it occurs, but failure to cure the cancer will lead to certain death. I think we need to take the risk - after all due preparation to handle the expected after effects of the cure. kre From owner-Big-Internet@munnari.oz.au Wed Nov 27 09:55:24 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25654; Wed, 27 Nov 1991 09:55:35 +1100 (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 AA25637; Wed, 27 Nov 1991 09:55:24 +1100 (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 AA09852; Tue, 26 Nov 91 17:55:15 EST Message-Id: <9111262255.AA09852@mitchell.cit.cornell.edu> To: Big-Internet@munnari.oz.au Subject: Class E and the real world: Unix and gated Reply-To: Jeffrey C Honig Organization: Information Technologies/Network Resources; Cornell University, Ithaca, NY X-Mailer: MH [version 6.7] MH-E [version 3.7+] MH-E [version 3.7+] Date: Tue, 26 Nov 91 17:55:14 -0500 From: Jeffrey C Honig I took a look at the BSD 4.3 source in respect to class E addresses. What I found is many sections of code like the following: if (IN_CLASSA(net)) mask = IN_CLASSA_HOST; else if (IN_CLASSB(net)) mask = IN_CLASSB_HOST; else mask = IN_CLASSC_HOST; Which would cause a class C netmask to be used on class E networks. The implications of this are: SUBNETSARELOCAL is broken. This compilation option (runtime on SunOS 4.1.1) enables interface MTU sized packets to be sent to other subnets of the same network. This would only work on subnets within the same class C mask. In some cases ICMP HOST redirects will be sent instead of NET redirects. Probably not a big problem. Detection of net.subnet.0 broadcasts would not work properly. Detection of whole network broadcasts net.ones (net.zeros) would not work properly. Network redirects for class E networks would be treated as if they had class C masks so they would only redirect to some subnets of the network. There may be problems with locating an outgoing interface for packets to a class E network. And more... I also found that packets will not be forwarded to experimental networks (classes D and E). So systems based on BSD 4.3 can not be used as routers. I'd assume that the same applies to BSD 4.3 Tahoe and other Unix systems with networking derived from BSD 4.3 (SunOS, AIX, Ultrix, ...). Much of the same still applies to BSD 4.3 Reno. The changes would not be extensive, but I it would take quite a while for the vendors to percolate them out and the sysadmins to actually install them, probably a year or two. On the subject of gated, the changes to gated in general are rather trivial. The changes to EGP are not much more difficult. They will be available (but not compiled in by default) with the next release of the alpha test version. As to EGP error recovery. The gated EGP is "liberal in what it accepts", if it gets a bogus network in an update, it assumes it is three bytes long. Versions of gated not supporting class E network will just ignore them. I'd hope other implementations would be as forgiving. Jeff From owner-Big-Internet@munnari.oz.au Wed Nov 27 09:56:44 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25715; Wed, 27 Nov 1991 09:57:17 +1100 (from owner-Big-Internet) Return-Path: Received: from MrBill.CAnet.CA by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA25688; Wed, 27 Nov 1991 09:56:44 +1100 (from dennis@MrBill.CAnet.CA) Received: by MrBill.CAnet.CA id <105495>; Tue, 26 Nov 1991 17:53:38 -0000 From: Dennis Ferguson To: kre@munnari.oz.au Subject: Re: Class E and EGP Cc: Big-Internet@munnari.oz.au, iwg@rice.edu Message-Id: <91Nov26.175338gmt.105495@MrBill.CAnet.CA> Date: Tue, 26 Nov 1991 17:53:37 -0000 Robert, > I think this is a little over stated... Assuming we're not doing > anything like spreading subnets or coalescing nets (yet), then > all that's needed is one number/mask pair per allocated net > number (of whatever class, or fraction of a class or whatever > it ends up being). This is approximately equivalent to > configuring the IP address of each interface that has one, which > must also be done - it requires no intelligence (even less that > configuring IP addresses, and interface subnet masks, as no-one > explicitly tell you the answer to that question), and can't > really be hard. All you're doing is explicitly telling the > router the information it can now deduce from the class of the > addresses it sees. If what you are implying here is that the only thing you want BGP-with-subnet-masks to do is carry addresses-and-masks as they were allocated by the NIC, and nothing else, this is fine by me as long as everyone else understands that this may not help them do what they wanted masks-in-BGP for. This of course includes Milo's get-the-next-hop-right-on-the-customer's-LAN-and-replace-RIP problem, as well as the split-a-network-across-a-backbone problem, as well as the subdivide-a-network-among-a-regional's-customers problem. And it does nothing to decrease the rate at which a default-free router's forwarding table grows, a problem which is at least as important as address space depletion. Everyone's problem is just a small problem and only requires a small change. It is just that taken together they constitute a fairly major change in the way we process routing information. And while my comments on configuration certainly were an overstatement with respect to your problem alone, I don't think they were an overstatement at all with respect to variable length net mask routing implemented in full generality. Now, if everyone will agree that supporting new class addresses, and only new class addresses, is the correct first step to get us to where we want to end up with from all of this, then we have a basis to work from. My only problem with this is that it isn't clear to me how anyone could know this is the correct first step since we don't seem to have much of an idea of where we want to end up at all. I really think we should make our best effort at determining the end before taking the first step, just to make sure we aren't walking in the wrong direction. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Wed Nov 27 10:21:26 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26745; Wed, 27 Nov 1991 10:21:35 +1100 (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 AA26742; Wed, 27 Nov 1991 10:21:26 +1100 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA08065; Tue, 26 Nov 91 18:16:08 EST Date: Tue, 26 Nov 91 18:16:08 EST From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9111262316.AA08065@animal.clearpoint.com> To: Big-Internet@munnari.oz.au, jch@nr-tech.cit.cornell.edu Subject: Re: Class E and the real world: Unix and gated >The changes would not be extensive, but I it would take quite a while >for the vendors to percolate them out ... probably a year or two. The idea had crossed my mind while talking to Chuck Davin on the way back from IETF: we could probably prod the vendors by passing out net numbers out of the Class E address space at the next InterOp. Nice job: thanks for the list. -- Frank (from the East European meaning "other") Solensky From owner-Big-Internet@munnari.oz.au Thu Nov 28 01:24:16 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22276; Thu, 28 Nov 1991 01:24:23 +1100 (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 AA22273; Thu, 28 Nov 1991 01:24:16 +1100 (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; Wed, 27 Nov 91 09:20:57 EST Received: by chiya.bellcore.com (5.57/4.7) id AA03090; Wed, 27 Nov 91 09:20:50 -0500 Date: Wed, 27 Nov 91 09:20:50 -0500 From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9111271420.AA03090@chiya.bellcore.com> To: medin@nsipo.nasa.gov, yakov@watson.ibm.com Subject: Re: Class E and EGP Cc: Big-Internet@munnari.oz.au, dennis@mrbill.canet.ca, iwg@rice.edu, pgross@ans.net > > Let's talk about subnet masks the book, not the movie. I would seriously > like to know if and why people think adding masks would be a mistake > in protocol evolution... > As you probably by now know, this was discussed at some length at the BGP meeting Tuesday night in Santa Fe. My interpretation of the general concensus (if one existed at all) is that in the abstract, masks could be useful, but the impact of supernetting especially on hosts and intra-domain routing is greater than zero. Given that we don't know the total cost of using super-netting, it is hard to decide that it is worth doing. Hopefully the group that is meeting between now and San Diego (the so-called Road Warriors, where road stands for routing and addressing) will come up with an opinion on the matter, and we can proceed from there. PT From owner-Big-Internet@munnari.oz.au Thu Nov 28 03:10:12 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25093; Thu, 28 Nov 1991 03:10:20 +1100 (from owner-Big-Internet) Return-Path: Received: from nis.ans.net by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA25087; Thu, 28 Nov 1991 03:10:12 +1100 (from pgross@ans.net) Received: by nis.ans.net id AA33549 (5.65c/IDA-1.4.4 for Big-Internet@munnari.oz.au); Wed, 27 Nov 1991 11:07:03 -0500 Message-Id: <199111271607.AA33549@nis.ans.net> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: medin@nsipo.nasa.gov, yakov@watson.ibm.com, Big-Internet@munnari.oz.au, iwg@rice.edu Subject: Re: Class E and EGP In-Reply-To: (Your message of Wed, 27 Nov 91 09:20:50 EST.) <9111271420.AA03090@chiya.bellcore.com> Date: Wed, 27 Nov 91 11:07:02 -0500 From: Phill Gross Given that we don't know the total cost of using super-netting, it is hard to decide that it is worth doing. Hopefully the group that is meeting between now and San Diego (the so-called Road Warriors, where road stands for routing and addressing) will come up with an opinion on the matter, and we can proceed from there. Paul, I thought it was Road Worriers, not Road Warriers. :-) I agree the Road folks will be talking about this, but I also think it is very helpful to hear the views expressed on these 2 lists. In particular, there are other motivations for passing masks in BGP than just super-netting. If the folks on these lists could 1) start to specify how to pass masks in BGP, and 2) specify how to *use* the masks for some of the more interesting functions, and 3) how to constrain the usage so the routing tables don't explode, then I think if would be very helpful input to the Road folks. Phill From owner-Big-Internet@munnari.oz.au Thu Nov 28 03:38:48 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26009; Thu, 28 Nov 1991 03:38:54 +1100 (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 AA26006; Thu, 28 Nov 1991 03:38:48 +1100 (from stev@ftp.com) Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA26689; Wed, 27 Nov 91 11:40:54 -0500 Date: Wed, 27 Nov 91 11:40:54 -0500 Message-Id: <9111271640.AA26689@ftp.com> To: solensky@animal.clearpoint.com Subject: Re: Class E and the real world: Unix and gated From: stev@ftp.com (stev knowles) Cc: Big-Internet@munnari.oz.au, jch@nr-tech.cit.cornell.edu Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com this has the feature of screwing customers if the vendors wont (or cant) meet your arbitrary deadline. one solution, after looking at jeff's posting about the 4.N stuff, is to give people class E addresses, and have the systems create them as a set of class C bastards. this way, old systems that follow the berkeley thread will work correctly (and have alot of routes floating around, but at least they work) and newer systems will just work correctly. has anyone thought about how to explain these new numbers to the users? the current A-B-C scheme, which cuts on byte boundries, was much easier. explaining to folks which addresses are "theirs" is going to be more difficult. talk of bits will probably confuse more than it will help alot of the users. rom owner-Big-Internet@munnari.oz.au Thu Nov 28 05:11:30 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA28189; Thu, 28 Nov 1991 05:11:36 +1100 (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 AA28186; Thu, 28 Nov 1991 05:11:30 +1100 (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; Wed, 27 Nov 91 13:10:46 EST Received: by chiya.bellcore.com (4.1/4.7) id for yakov@watson.ibm.com; Wed, 27 Nov 91 13:10:53 EST Date: Wed, 27 Nov 91 13:10:53 EST From: tsuchiya@thuFrom owner-Big-Internet@munnari.oz.au Thu Nov 28 05:37:31 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA28998; Thu, 28 Nov 1991 05:37:43 +1100 (from owner-Big-Internet) Received: from gateway.mitre.org by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA28985; Thu, 28 Nov 1991 05:37:31 +1100 (from barns@gateway.mitre.org) Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA07112; Wed, 27 Nov 91 13:35:13 -0500 Message-Id: <9111271835.AA07112@gateway.mitre.org> To: Big-Internet@munnari.oz.au Cc: barns@gateway.mitre.org Subject: Re: Class E and the real world: Unix and gated In-Reply-To: stev knowles's message of "Wed, 27 Nov 91 11:40:54 EST." <9111271640.AA26689@ftp.com> Date: Wed, 27 Nov 91 13:34:59 -0500 From: barns@gateway.mitre.org >has anyone thought about how to explain these new numbers to the users? the >current A-B-C scheme, which cuts on byte boundries, was much easier. >explaining to folks which addresses are "theirs" is going to be more >difficult. talk of bits will probably confuse more than it will help alot of >the users. Mm. A similar situation exists for OSI NSAPs. I have been finding that the people I have to explain these things to seem to want to think in terms of "blocks of addresses" so perhaps that is the way to approach it - 224.99.16.0 through 224.99.31.255 (did I get that right? Whatever) with the "first address" reserved and the "last address" the broadcast address. Is this good? Bill Barns / barns@gateway.mitre.org