From owner-Big-Internet@munnari.oz.au Wed Jan 8 03:35:51 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26052; Wed, 8 Jan 1992 03:36:00 +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 AA26047; Wed, 8 Jan 1992 03:35:51 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA18242; Tue, 7 Jan 92 11:35:28 EST Date: Tue, 7 Jan 92 11:35:28 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9201071635.AA18242@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au Subject: Class E issue Cc: jnc@ALLSPICE.LCS.MIT.EDU At the last ROAD meeting, a number of people suggested very strongly that Class E as it stands is not a workable solution. The issue is that too many hosts out there will barf on Class E addresses. Jeff Honig did the analysis on 4.2, which seemed to indicate it wouldn't work. There are two cases to consider: 1) a host is given a Class E address; will it accept it, be able to get to its neighbour routers, etc, and 2) a host is trying to get to a destination which has a Class E address; can it do so. Can we have some volunteers to canvass existing host software to see which ones fail these two cases? Clearly, if a large number of hosts fail them, Class E as it stands is not too useful. There are a large number of hosts out there now, lots of them binary only, and it will take a while to get them updated. Since Class E cannot be realistically introduced until a good portion of the hosts can understand them, if 90% of the hosts won't, and it will take 4 years to update them, we need a different angle. I don't think it's impossible to bring in class E; we have a recent analog in the DNS, where if you don't implement the DNS there are lots of hosts you can't get to (probably a lot more than would have Class E addresses). We seem to have worked through that OK. I also feel very strongly that the Internet has to keep moving forward, or it will die. Saying that we can't change any hosts, even for the most useful end, is going to put a real curb on the ability to change and grow the system. Still, we have to recognize reality. If Class E as it stands is unworkable, there are probably minor changes we can make which should remove this difficultly. Opinions, everyone? Noel PS: This points out that when we release the new spec, it should include changes to the host routing functionality such that this never happens again. The latest 4.X release has such functionality. More on this in a later message. From owner-Big-Internet@munnari.oz.au Wed Jan 8 22:49:27 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA22702; Wed, 8 Jan 1992 22:49:44 +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 AA22697; Wed, 8 Jan 1992 22:49:27 +1100 (from kre) To: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Class E issue In-Reply-To: Your message of Tue, 07 Jan 92 11:35:28 -0500. <9201071635.AA18242@PTT.LCS.MIT.EDU> Date: Wed, 08 Jan 92 22:49:11 +0100 Message-Id: <16909.694871351@munnari.oz.au> From: Robert Elz I don't think class E will be impossible, but I don't think it will be easy either - I never thought that, I'd suspect at least a year, and maybe two, from when the spec is issued as an RFC till when the first E addresses can be handed out. However, I don't think the DNS case is a useful analogy, there if you had software incapable of using the DNS you just worked around it .. either "telnet 18.26.0.115" or mail to "jnc%ALLSPICE.LCS.MIT.EDU@mit-multics.arpa" (or whatever worked). With class E addresses that kind of user level workaround isn't possible, if the software doesn't support them, then there's simply no communication (mail can be routed around, but that's all). Further, its not just a question of my software not being able to communicate with some site that's been allocated a class E address, another very real problem is that the class E site's software is no more likely to be able to support it, which is a somewhat bigger problem - clearly current versions of SunOS won't handle class E's, and since no new software is likely to appear, from Sun anyway, for Sun 3's or 386i's (or Sun 2's, etc either), then anyone with any of that gear, which includes those using Sun3/50's as xterms, then there's likely to be lots of people who won't be able to recognise, or use, class E addresses for a long time. But even with all that, something has to be done, and quickly, to attempt to avoid exhausting the class B space, without causing the routing table explosion that would occur if we simply allocated parcels of class C numbers. If we give people enough warning, I think class E can work, the vendors will simply have to support it - its not as though it needs to be a major change. I wouldn't insist on eliminating class knowledge from the first "class E support" release though, that's something that should be done, but its a more radical change, that would take longer to go through Q/A, beta tests, etc, than simply adding one more known class. If it looks like there'll be too many people with truly obsolete hosts (ones from vendors who no longer exist to fix things, etc) then it might be an idea to revisit the idea of taking the class E space from the back half of the class C space, which hosts could handle. Routers could even have an option to broadcast class E RIP info as if it were info on 16 class C nets, so RIP snooping hosts would survive - that would need a recommendation on how to do it, so other routers could reconstruct the original net number on seeing the 16 class C parts of the class E number. kre From owner-Big-Internet@munnari.oz.au Wed Jan 8 23:16:23 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA23341; Wed, 8 Jan 1992 23:17:03 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9201081217.23341@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA23331; Wed, 8 Jan 1992 23:16:23 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 8 Jan 1992 12:15:52 +0000 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: Class E issue In-Reply-To: Your message of "Wed, 08 Jan 92 22:49:11 +0100." <16909.694871351@munnari.oz.au> Date: Wed, 08 Jan 92 12:15:51 +0000 From: Jon Crowcroft >If it looks like there'll be too many people with truly obsolete >hosts (ones from vendors who no longer exist to fix things, etc) >then it might be an idea to revisit the idea of taking the >class E space from the back half of the class C space, which >hosts could handle. Routers could even have an option to >broadcast class E RIP info as if it were info on 16 class C >nets, so RIP snooping hosts would survive - that would need >a recommendation on how to do it, so other routers could >reconstruct the original net number on seeing the 16 class C >parts of the class E number. what about TCP checksum dependance on source/destination addres (i believe it was designed to protect against partial reconstructed IP headers...) i think you might consider my half baked idea on dynamic address allocation - keep back 1/2 class C for E to non-E net routing, but multi-home the E machines on a C-net for the duration of any conversation with a non_E-capable site. you'd need a C-net dynamic allocator somewhere (probably part of DNS) and it would mean any nonEcapable host would have to wait for the E-host to finish a C-Net allocation time, plus a C-Net routing update/discovery time, but you wuldnt need anything special wouldn't need any special at broken sites... jon From owner-Big-Internet@munnari.oz.au Thu Jan 9 00:24:46 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25425; Thu, 9 Jan 1992 00:24:59 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9201081324.25425@munnari.oz.au> Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25419; Thu, 9 Jan 1992 00:24:46 +1100 (from kre) Date: Thu, 9 Jan 1992 00:24:46 +1100 From: Robert Elz To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: Class E issue Cc: big-internet@munnari.oz.au I don't understand the TCP checksum reference .. that is, I know how TCP checksums work, but what the address is in them that they check can't be relevant - unless you're doing come kind of address mangling. The dynamic allocation thing sounds like it would require much more work than anyone really wants to do for this - and I'm not sure how it works when a non-E-able host wants to communicate with a host with an E address. Unless the DNS (which we'd have to assume was actually being used by this old host, which is not necessarily going to be the case) knew to remap the E address to a C address (or something) the old host is going to try to send to the E address. Since that's what we're assuming won't work, any kind of fix after that is a bit too late - what the E host would do would be irrelevant. kre From owner-Big-Internet@munnari.oz.au Thu Jan 9 00:54:04 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26010; Thu, 9 Jan 1992 00:54:13 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9201081354.26010@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA26004; Thu, 9 Jan 1992 00:54:04 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 8 Jan 1992 13:53:47 +0000 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: Class E issue In-Reply-To: Your message of "Thu, 09 Jan 92 00:24:46 +1100." <9201081324.25425@munnari.oz.au> Date: Wed, 08 Jan 92 13:53:46 +0000 From: Jon Crowcroft >I don't understand the TCP checksum reference .. that is, I know how TCP >checksums work, but what the address is in them that they check can't >be relevant - unless you're doing come kind of address mangling. my mistake - i re-read yr previous message and see you were'nt suggesting mangling, just allocating E from C space...sorree >The dynamic allocation thing sounds like it would require much more work >than anyone really wants to do for this - and I'm not sure how it works i was thinking in terms of something we use in the UK name registration system (equiv in colour books of DNS) - a name-address query is made in a "context" - i.e. new hosts say 'DNS name - gimme E addr' while old hosts just say 'DNS name - gimme addr' - DNS then just returns C addrs for old hosts. for E to old, E says gimme addr for old host in 'E context, and DNS says fine, but you need to use this new address on a C net to talk to that old bird, and you better advertise this C net to your routers.... if the old bird doesnt use DNS, why then how do they ever hear about E addrs in the first place? cheers jon From owner-Big-Internet@munnari.oz.au Thu Jan 9 00:59:55 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26235; Thu, 9 Jan 1992 01:00:37 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9201081400.26235@munnari.oz.au> Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA26226; Thu, 9 Jan 1992 00:59:55 +1100 (from kre) Date: Thu, 9 Jan 1992 00:59:55 +1100 From: Robert Elz To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: Class E issue Cc: big-internet@munnari.oz.au for E to old, E says gimme addr for old host in 'E context, and DNS says fine, but you need to use this new address on a C net to talk to that old bird, and you better advertise this C net to your routers.... possible, I think we should explore every other possibility first though. if the old bird doesnt use DNS, why then how do they ever hear about E addrs in the first place? "telnet 240.1.1.3" ... or they edit them into /etc/hosts, just the same way as they talk to rest of the world now (I have 2 hosts here now that work like that - they don't talk to many other people, but that's OK. In one case the manufacturer is bankrupt, the othe never relaly had one. They even need a class C net just for those 2, as they don't understand subnets or 1's broadcasts either .. but both will be scap in the junk yard before E's appear). kre From owner-Big-Internet@munnari.oz.au Thu Jan 9 03:28:54 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA28953; Thu, 9 Jan 1992 03:29:10 +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 AA28932; Thu, 9 Jan 1992 03:28:54 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA23533; Wed, 8 Jan 92 11:28:39 EST Date: Wed, 8 Jan 92 11:28:39 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9201081628.AA23533@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au, kre@munnari.oz.au Subject: Re: Class E issue Cc: jnc@ALLSPICE.LCS.MIT.EDU Right, I'd realized that we could go back to using C#. I just wanted to canvass people to make sure that Class E was a dead end before backpedalling. Noel From owner-Big-Internet@munnari.oz.au Sat Jan 11 14:03:48 1992 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA20640; Sat, 11 Jan 1992 14:04:09 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA20620; Sat, 11 Jan 1992 14:03:48 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11999>; Fri, 10 Jan 1992 19:03:40 PST Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <3145>; Fri, 10 Jan 1992 19:02:19 PST To: Robert Elz Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Class E issue In-Reply-To: Your message of Wed, 08 Jan 92 13:49:11 -0800. <16909.694871351@munnari.oz.au> Date: Fri, 10 Jan 1992 19:01:52 PST From: Steve Deering Message-Id: <92Jan10.190219pst.3145@skylark.parc.xerox.com> > If it looks like there'll be too many people with truly obsolete > hosts (ones from vendors who no longer exist to fix things, etc) > then it might be an idea to revisit the idea of taking the > class E space from the back half of the class C space, which > hosts could handle. To me, using the C# (1101) space is clearly superior to using the E (1111) space, because C# addresses will work with existing hosts and routers. I find the two arguments against C# in the internet draft to be specious: - It is argued that allocating blocks of 16 contiguous class C# addresses will exacerbate the routing overhead problem in the backbone nets. However, the backbone routers can just as easily be modified to recognize the aggregatability of 1101 addresses as they can be to recognize 1111 addresses. And the modification is trivial: they simply have to use a mask of FFFFF000 for the C# addresses. Of course, non-backbone routers that are not suffering from excessive numbers of routes need not be changed at all. This is important because, no matter how trivial the change, there are lots of routers out there on the fringe that, lacking the paid staff and management procedures of the backbones and regionals, just won't be updated or replaced for a long time. - It is argued that using the E space would be preferable to the C# space because it would be a greater incentive for vendors/authors to update their IP software to support classless routing. However, there are many boxes out there whose IP software is no longer supported, or whose owners will never get around to updating their software even if it is available. Sure, those boxes will eventually get thown away, but we should avoid making them obsolete unless we really have to. With C#, we don't have to. The first poor suckers to get assigned class E addresses would probably not be content to know, when they are unable to FTP some important file from an old system over which they have no control, that it is for the good of the Internet > Routers could even have an option to > broadcast class E RIP info as if it were info on 16 class C > nets, so RIP snooping hosts would survive - that would need > a recommendation on how to do it, so other routers could > reconstruct the original net number on seeing the 16 class C > parts of the class E number. No need for all that. Just don't bother changing the RIP-speaking routers to know anything special about 1101 addresses. The routers that hosts are listening to for RIP broadcasts are not going to be the ones that have enormous routing tables, or that would benefit significantly from aggregating class C# net numbers. For those routers out on the campuses and such that have actually been updated with classless IP software, they might just as well use the normal class C mask, FFFFFF00, for class C# net numbers. Besides, hosts shouldn't be snooping RIP packets. Steve