From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 01:49:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19507; Thu, 31 Mar 1994 18:50:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA28811; Thu, 31 Mar 1994 18:49:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA28782; Thu, 31 Mar 1994 18:28:04 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13936; Thu, 31 Mar 1994 16:25:30 +1000 (from tli@cisco.com) Received: from [131.108.11.55] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07752 Thu, 31 Mar 1994 16:04:20 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id WAA03113; Wed, 30 Mar 1994 22:01:26 -0800 Date: Wed, 30 Mar 1994 22:01:26 -0800 From: Tony Li Message-Id: <199403310601.WAA03113@lager.cisco.com> To: dcrocker@mordor.stanford.edu Cc: kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU In-Reply-To: Dave Crocker's message of Wed, 30 Mar 1994 13:25:50 -0800 Subject: Minimal Changes & IPng Dave, Frank already said all of this, but it's important enough that I thought you should hear it from the horse's mouth.... Why these market pressures are being ignored in the analysis is a point of question I have yet to find an answer to. I'm not ignoring them. I'm VERY aware of them. However, I also have NO reasonable way of quantifying these effects either in any way that I can justify to myself or to anyone else. In this sense, the market planners have a big advantage over me: they have a history to work with. The Internet "market" is sufficiently new that I don't believe that anyone has ANY idea of how the market will behave. In this global sense, the Internet is its own paradigm shift, and I don't know of any analogous markets in all of history. That said, I'm not a Harvard M.B.A. I'm simply doing the best that I can with the tools that I have. I'm also not a great statistician, a fortune-teller, or a magician.... You need assistance by people who do market planning. Agreed. Are you volunteering? Or are you volunteering to pay for someone? Tony, you might not have noticed, but there has been quite a bit of calm, rational engineering going on. I have noticed this (in fact, I seem to be doing some of it...). And I believe that most people understand that we're under time pressure to do this. So I have to wonder why you're playing Chicken Little here.... Suppose that my projections are off and that the end of the world is 1997. What would you do differently? Do we just slap something out there? Both technically and politically, that would be the ultimate disaster. We get an immature technical decision, and a schism in the IETF. Tony From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 01:56:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04644; Fri, 1 Apr 1994 01:56:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA29377; Fri, 1 Apr 1994 01:54:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA29368; Fri, 1 Apr 1994 01:41:42 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04200; Fri, 1 Apr 1994 01:42:41 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9403311542.4200@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 Mar 1994 16:41:29 +0100 To: jcjones@MIT.EDU Cc: big-internet@munnari.OZ.AU Subject: Re: Solution is on the way... fragementation fields In-Reply-To: Your message of "Wed, 30 Mar 94 18:47:44 EST." <9403302347.AA13348@m16-034-25.MIT.EDU> Date: Thu, 31 Mar 94 16:41:29 +0100 From: Jon Crowcroft i havn't analysed this thouroughly, but this is a good hack solution. assuming nothing breaks if you set the don't frgament bit, but the fragment offset bits are non zero, then you get to have 30 extra bits in the header | Identification |Flags| Fragment Offset | since thew id is really only meaningful in terms of fitting appropriate bits of fragments together.... that gives us 32000 more net numbers than we have now... probably enough for a while... anyone care to see how many systems break if you use this combination of bits of course, by the time you read this, it may be a day later than when i sent it :-) jon From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 02:05:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04708; Fri, 1 Apr 1994 02:05:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA29403; Fri, 1 Apr 1994 02:04:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA29374; Fri, 1 Apr 1994 01:48:13 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04465; Fri, 1 Apr 1994 01:49:21 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9403311549.4465@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 Mar 1994 16:48:43 +0100 To: whyman@mwassocs.demon.co.uk Cc: ericf@atc.boeing.com, Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of "Thu, 31 Mar 94 10:25:25 GMT." <9403311025.aa587@mwassocs.demon.co.uk> Date: Thu, 31 Mar 94 16:48:43 +0100 From: Jon Crowcroft >Uncertainty and Doubt is one way of putting of the day when the last IP >address is allocated, but not exactly an ideal solution. The indecision needs >to end now, then users will have a clear idea of what the future is and how >they get there. This is a very very important perception! >You are also claiming that OSI technologies are immature. This is a sweeping >statement. There are certainly some areas on which I would agree with you, but >not if you are implying CLNP. the maturity of CLNP is not in doubt - however, the requirements process has identified a number of _new_ functions that neither IPv4 nor CLNP as such have - in particular, multicast, multiple network services, security and mobility are not mature in either, although both have draft solutions. Also note that as a host solutiuon, CLNP requires changes to TCP to permit the infrastrucxture as perceived by users to run un changed - that is not a mature stack -in fact it is one of the bases for my compallaint that clnp versus other IPng proposals can be seens as something of a chalk/cheese/ apples and oranges debate... as soon as the tuba folks relinquished the standard CLNP as the basis of the work, they aligned themselves with other IPngs as proposaing a comparible solution. if we keeop re-aligning this proposal with 'mature' clnp, then I believe we have a problem since ware not addressing the needs of the TCP/UDP and other internet protocol community cleanly...(apart from _any_ political questions, which have largely been smoothed now thanks to better peer regard betwen IETF and appropriate ISO folks...) cheers jon From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 02:13:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05142; Fri, 1 Apr 1994 02:13:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA29429; Fri, 1 Apr 1994 02:11:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA29371; Fri, 1 Apr 1994 01:47:56 +1000 Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19275; Thu, 31 Mar 1994 18:45:00 +1000 (from postlog@mwassocs.demon.co.uk) Date: Thu, 31 Mar 1994 09:42:10 GMT Message-Id: <9403310942.aa585@mwassocs.demon.co.uk> From: whyman@mwassocs.demon.co.uk To: big-internet@munnari.OZ.AU (Big Internet Maillist) From: whyman@mwassocs.demon.co.uk (Tony Whyman) Subject: Re: Solution is on the way... X-Mailer: Cinetic Mail Manager V2.1 | |From: jcjones@mit.edu | |Date: Wed, 30 Mar 94 18:47:44 EST | |Content-Length: 1727 | | | | | |********** I HAVE THE SOLUTION TO THE INTERNET PROBLEM ********** | | Are you sure that you did not post this two day's too early ;-) | |I am not going to bore you with the details here, but I will say that | |a paper is forthcoming. The sooner I get my proof-of-concept testing | |done, the sooner the paper will come. | | More seriously if you what this posting not to be put in the "I have just seen Elvis league", then you should justify your claims with a lot more detail, especially as you are making an implicit criticism of just about everyone working in network design. | |In the meantime, I desperately need support. If there is anyone out | |there who is willing to provide equipment for testing please contact | |me. I have been trying to do testing using two RS232 ports on my two | |IBM-PC/XT's, and things just aren't happening as fast as I would like | |them to. I need real machines, a real C compiler, a real assembler, | |and real network adapters. | | | |To all you people out there in Internet land, this is what you have | |coming: | | | |1. 1,000,000,000,000,000,000 (ten-to-the-18) addressable nodes | |2. Small routing tables: The biggest routing table on the Internet | | will never onsume more than 1 megabyte of memory. What is number 3? Has it got anything to do with transition? | |4. Trivial network management: some of you network administrators | | will kick yourselves when you see how easy things could/should | | have been. | |5. Mobility of hosts. | | | | *Security should be handled at the OSI Session and Transport Levels* | | A statement like this makes me think that you have overlooked something. OSI Session currently has no security involvement and the existence of the layer is itself now highly questionable. Upper layer security is closely linked to the application and is hence rightly placed in the application layer. You can place security in the transport layer, but there are a number of very valid reasons for placing it in the network layer - mostly to do with evaluation - although you will also need network layer security if you have to route over networks that offer different levels of protection. | |For those of you who think that I am blowing smoke, let the flames | |rip. For those of you who realize the consequences of a universally | |acceptable solution that can be deployed before the end of this year, If there is anything about your posting that is unbelievable, it is that there can ever be such a thing as a "universally acceptable solution". | |please give me a call or me send e-mail. | | | |(617) 494-1034 | |J.C. Jones | |129 Franklin St. #100 | |Cambrige, MA 02139 | |U.S.A. | | | |P.S. - | | | |I don't know if this is the appropriate place to put a message like | |this. If it is not, I'm sure you'll let me know. | | I am sure that you will receive many suggestions of suitable places. | |I would also like to state for the record that the solution I that | |intend to provide was conceived by myself alone on October 14, 1987. | | | | | | | | | | -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 02:36:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05717; Fri, 1 Apr 1994 02:36:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA29464; Fri, 1 Apr 1994 02:34:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA29446; Fri, 1 Apr 1994 02:17:07 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05313; Fri, 1 Apr 1994 02:18:17 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00285; Thu, 31 Mar 1994 18:18:12 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10285; Thu, 31 Mar 1994 18:18:11 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403311618.AA10285@dxcoms.cern.ch> Subject: Re: Solution is on the way... To: jcjones@MIT.EDU Date: Thu, 31 Mar 1994 18:18:11 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9403302347.AA13348@m16-034-25.MIT.EDU> from "jcjones@MIT.EDU" at Mar 30, 94 06:47:44 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 447 OK... this sounds interesting, but until you publish an Internet Draft you **ARE** blowing smoke. You don't need running code to publish an I-D. So you don't need equipment to publish an I-D. I also solved the Internet problem just before breakfast this morning, BTW :-) Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 | "Press any key to continue"??? I can't even FIND the Any key. | From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 02:56:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06840; Fri, 1 Apr 1994 02:56:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA29502; Fri, 1 Apr 1994 02:54:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA29499; Fri, 1 Apr 1994 02:53:36 +1000 Received: from fennel.acc.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06760; Fri, 1 Apr 1994 02:54:47 +1000 (from art@acc.com) Received: from opal.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA08223; Thu, 31 Mar 94 08:54:05 PST Date: Thu, 31 Mar 94 08:54:05 PST From: art@acc.com (Art Berggreen) Message-Id: <9403311654.AA08223@fennel.acc.com> To: J.Crowcroft@cs.ucl.ac.uk, jcjones@MIT.EDU Subject: Re: Solution is on the way... fragementation fields Cc: big-internet@munnari.OZ.AU > >i havn't analysed this thouroughly, but this is a good hack solution. > >assuming nothing breaks if you set the don't frgament bit, but the >fragment offset bits are non zero, then you get to have 30 extra bits >in the header There was just a discussion somewhere (maybe Usenet) that involved someone seeing fragments with the DF flag set. It appeared that a host was fragmenting a large packet down to interface MTU size then applying Path MTU Discovery. The concensus was that this was legal behavior. In general, I'd shy away from redefining fields in the header in such a manner. The possiblities for implementation specific problems seem to be a minefield. Art From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 09:16:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12329; Fri, 1 Apr 1994 09:16:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA29845; Fri, 1 Apr 1994 09:14:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA29831; Fri, 1 Apr 1994 08:56:55 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11957; Fri, 1 Apr 1994 08:58:08 +1000 (from dcrocker@mordor.stanford.edu) Received: from [192.220.248.125] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA00122; Thu, 31 Mar 1994 14:57:53 -0800 Date: Thu, 31 Mar 1994 14:57:53 -0800 X-Sender: dcrocker@mordor.stanford.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tony Li From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Robert Elz , Big-Internet@munnari.OZ.AU Tony, At 6:20 AM, Tony Li wrote: > Yet, there have been no visible efforts to perform what-if analysis > by these folks. > >I'd love to. What if no one ever asked for an IP address again? >we're done. What if someone walks up tomorrow and asks for 2^32? Ok, >we're also done. The problem is that reality is hopefully somewhere >between the two extremes. I just have no serious clue as to what's >reasonable. Perhaps we should try to iterate with some efforts to re-specify both limits, based on specifics from plausibly derived market estimates. For example, how many pcs with modems are there? What about next year? What's a reasonable guess of the number likely to join the Internet next year? two years? ... How many utility poles are scheduled for network connection? What is the planned, combined connectivity for interactive televisions? What is the likelyihood that my local teller machine will come to use IP? When? ... (Others should feel free to suggest other sources of new users, and why they think the source is plausible.) >Now, we can go on arguing with each other for the rest of the week, >or we can do something productive. Which will it be? Tony, I really am sympathetic with the discomfort about this sort of analysis. But that discomfort does not justify an ostrich response, reverting to tenacious use of inappropriate methodology. (And we can now move from a chicken-and-egg discussion to a chicken (little) and ostrich one.) > If they are going to assert conclusive results from their work, it > needs to stand up against this concern. > >No one is asserting conclusive results. There are caveats all over >the place, Dave. Please grok them... Tony, I thought I'd been paying plenty of attention to plenty of presentations. In fact, the caveats did not seem to be present and I am quite sure that many other listeners/readers have also missed them. E.g., having a presentation end with the exclamation "Don't Panic" sticks in the mind and most certainly isn't accompanied with caveats. Dave From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 09:20:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12405; Fri, 1 Apr 1994 09:20:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA29860; Fri, 1 Apr 1994 09:19:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA29828; Fri, 1 Apr 1994 08:56:49 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11953; Fri, 1 Apr 1994 08:58:02 +1000 (from dcrocker@mordor.stanford.edu) Received: from [192.220.248.125] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA00119; Thu, 31 Mar 1994 14:57:46 -0800 Date: Thu, 31 Mar 1994 14:57:46 -0800 X-Sender: dcrocker@mordor.stanford.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tony Li From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Tony, At 6:01 AM, Tony Li wrote: >(me) Why these market pressures are being ignored in the analysis is a point >of > question I have yet to find an answer to. >(you) >I'm not ignoring them. I'm VERY aware of them. However, I also have >NO reasonable way of quantifying these effects either in any way that >I can justify to myself or to anyone else. In this sense, the market It is certainly true that the kind of what-if analysis that I'm suggesting is based on hypotheses and probabilities, rather than more comforting, concrete traffic data. Especially in our technical world, the latter is familiar and the former is not. My point is that folks experienced in doing projections for new-market growth DO have reasonable ways of quantifying effects. I consider this work for specialists. While I've participated in such exercises a number of times, I'm not competent to lead them. I would hope that the community reading this does have such folk and/or folk who can recruit such folk. > The Internet "market" is sufficiently new that I don't believe >that anyone has ANY idea of how the market will behave. I think that we DO know of immediate, credible pressures. We don't know how they will play out. But I, for one, find them credible enough to believe that they make a strictly history-based projection entirely misleading. If such a projection were part of a BEST-CASE data case, rather than being the ONLY case (with claims that they represent worst case,) it would be fine and even useful. >That said, I'm not a Harvard M.B.A. I'm simply doing the best that I >can with the tools that I have. I'm also not a great statistician, a >fortune-teller, or a magician.... Given the rabbits that you and your company keep pulling out of your hat(s), I'd say you're being overly modest... > You need assistance by people who do market planning. > >Agreed. Are you volunteering? Or are you volunteering to pay for >someone? Glad to help and eager to see real experts participate. "Pay"? Huh? We're all volunteers, right? We need to recruit some volunteers with the right background. An example of the sorts of things we need to include are guesses of plausible sources of new growth, with plausible guesses of their size and probabilities. This produces additional numbers with subjective confidence assertions. > So I have to wonder why you're playing Chicken Little That you are so labeling my raising these concerns is the reason for pushing so hard. As I've said in a number of IETF meetings over the last 2 years, the style of doing projections that has been used is inappropriate and misleading, yet we continue to have assertions that "it's useful". I am being persistent -- and you ain't seen my chicken little routine, yet, but we're working up to it -- because of the steadfast, equal, and opposite persistence at failing to do market projections using appropriate market analysis tools. I take your comments a paragraph or so above as indicating a willingness to do it now. That's great. Let's do it. >here.... Suppose that my projections are off and that the end of the >world is 1997. What would you do differently? I, for one, wouldn't do much differently, but I suspect that folks making projection presentations would not put up slides saying "Don't Panic". >Do we just slap >something out there? Both technically and politically, that would be >the ultimate disaster. We get an immature technical decision, and a >schism in the IETF. Your wording suggests that that's what we are doing. Your earlier text says that you do believe deliberate, quality work is being done. Which do you really believe? For myself, I am satisfied with the quality of the work being done under reasonable time and technical constraints. If you have SPECIFIC criticisms of SPECIFIC technical work, it will help for you to state them. Dave From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 10:16:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13168; Fri, 1 Apr 1994 10:16:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA29933; Fri, 1 Apr 1994 10:14:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA29930; Fri, 1 Apr 1994 10:10:08 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13105; Fri, 1 Apr 1994 10:11:21 +1000 (from solensky@mailserv-D.ftp.com) Received: from mailserv-D.ftp.com by ftp.com ; Thu, 31 Mar 1994 19:11:17 -0500 Received: from solensky.fenway.ietf29.nwnet.net by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19459; Thu, 31 Mar 94 19:10:29 EST Date: Thu, 31 Mar 94 19:10:29 EST Message-Id: <9404010010.AA19459@mailserv-D.ftp.com> To: dcrocker@mordor.stanford.edu Subject: Re: Minimal Changes & IPng From: solensky@ftp.com (Frank T Solensky) Cc: tli@cisco.com, Big-Internet@munnari.OZ.AU Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Mar 31 19:10:26 1994] Originating-Client: fenway.ietf29.nwnet.net Content-Length: 958 > I, for one, wouldn't do much differently, but I suspect that folks making > projection presentations would not put up slides saying "Don't Panic". If it wasn't clear in the meeting or by what I said then, maybe explaining this again on the list for the third time this week will clear up any remaining confusion. I, for one, don't consider the phrase "Don't Panic" to be the equivalent of "Don't Worry". I am not advocating a do-nothing approach or saying that there isn't a problem. I _am_ saying that a full-scale panic, a "let's run somewhere just as long as we're running" to borrow Noel's phrase, is not the right thing to do. That's all. We're also already said that we're willing to take the sort of inputs that you're suggesting. All that has to be done now is to find someone or someones, list members and otherwise, that might have some additional suggestions as to the target environments and timeframes we need to add. -- Frank From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 11:56:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14674; Fri, 1 Apr 1994 11:56:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA00131; Fri, 1 Apr 1994 11:54:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA00113; Fri, 1 Apr 1994 11:35:30 +1000 Received: from alsys1.aecom.yu.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14439; Fri, 1 Apr 1994 11:36:37 +1000 (from sasha@epr1.bioc.aecom.yu.edu) Received: from epr1.bioc.aecom.yu.edu by alsys1.aecom.yu.edu with SMTP id AA13554 (5.67b/IDA-1.5/AECOM-RIT for <@alsys1.aecom.yu.edu:big-internet@munnari.oz.au>); Thu, 31 Mar 1994 20:36:15 -0500 Received: by epr1.bioc.aecom.yu.edu (920330.SGI/911001.SGI) for @alsys1.aecom.yu.edu:big-internet@munnari.oz.au id AA01620; Thu, 31 Mar 94 20:36:31 -0500 Date: Thu, 31 Mar 1994 20:35:54 -0500 (EST) From: Sasha Fedorov To: big-internet@munnari.OZ.AU Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII help quit From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 12:16:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15089; Fri, 1 Apr 1994 12:16:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA00172; Fri, 1 Apr 1994 12:14:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA00169; Fri, 1 Apr 1994 12:12:44 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15005; Fri, 1 Apr 1994 12:13:58 +1000 (from dcrocker@mordor.stanford.edu) Received: from [192.220.248.123] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id SAA02248; Thu, 31 Mar 1994 18:13:51 -0800 Date: Thu, 31 Mar 1994 18:13:51 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: solensky@ftp.com (Frank T Solensky) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Frank, At 12:10 AM, Frank T Solensky wrote: > for the third time this week I share your frustration at having to repeat messages. > I _am_ saying that a >full-scale panic, a "let's run somewhere just as long as we're running" >to borrow Noel's phrase, is not the right thing to do. That's all. Since the IETF discussions and the actions within the IETF have not in any fashion represented this sort of silliness, I guess I don't see how its helpful for you to tell us not to do what we aren't doing and don't contemplate doing. As cited and agreed earlier, the real work in this realm is being done in a deliberate and professional manner. >We're also already said that we're willing to take the sort of inputs >that you're suggesting. All that has to be done now is to find someone >or someones, One of the benefits that this more-commercial Internet ought to be able to offer is access to this sort of resource. So, for perhaps the first time in the IETF's history, I'd like to strongly SOLICIT participation by marketeers! Dave From owner-Big-Internet@munnari.OZ.AU Fri Apr 1 14:36:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20029; Fri, 1 Apr 1994 14:36:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA00304; Fri, 1 Apr 1994 14:34:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA00301; Fri, 1 Apr 1994 14:27:37 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17773; Fri, 1 Apr 1994 13:30:05 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id TAA00834; Thu, 31 Mar 1994 19:29:53 -0800 Date: Thu, 31 Mar 1994 19:29:53 -0800 From: Tony Li Message-Id: <199404010329.TAA00834@lager.cisco.com> To: dcrocker@mordor.stanford.edu Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Dave Crocker's message of Thu, 31 Mar 1994 14:57:46 -0800 Subject: Minimal Changes & IPng I take your comments a paragraph or so above as indicating a willingness to do it now. That's great. Let's do it. Thank you for volunteering. I have you down for an agenda item at our next working group meeting. Tony From owner-Big-Internet@munnari.OZ.AU Sat Apr 2 01:56:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11367; Sat, 2 Apr 1994 01:56:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA00907; Sat, 2 Apr 1994 01:55:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA00882; Sat, 2 Apr 1994 01:38:12 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06128; Fri, 1 Apr 1994 23:18:38 +1000 (from louie@wa3ymh.transsys.com) Received: from wa3ymh.transsys.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwjtd20848; Fri, 1 Apr 94 08:18:32 -0500 Received: from wa3ymh.transsys.com (#6@localhost [127.0.0.1]) by wa3ymh.transsys.com (8.6.8/8.6.4) with ESMTP id IAA15934; Fri, 1 Apr 1994 08:11:51 -0500 Message-Id: <199404011311.IAA15934@wa3ymh.transsys.com> To: big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US From: louie@42.42.202.144.in-addr.arpa Reply-To: louie@202.144.In-Addr.ARPA Cc: louie@1.1.202.144.in-addr.arpa Subject: Re: Solution is on the way... Date: Fri, 01 Apr 1994 08:11:48 -0500 Sender: louie@wa3ymh.transsys.com A recent message to the big-internet mailing list began: >> ********** I HAVE THE SOLUTION TO THE INTERNET PROBLEM ********** I have to disagree! You have missed a very critical component of the INTERNET PROBLEM, which I think you have purposefully ignored because of the terrible difficulty of the problem. >> I am not going to bore you with the details here, but I will say that >> a paper is forthcoming. The sooner I get my proof-of-concept testing >> done, the sooner the paper will come. I have read your brief description, and though you say: >> 1. 1,000,000,000,000,000,000 (ten-to-the-18) addressable nodes >> 2. Small routing tables: The biggest routing table on the Internet >> will never onsume more than 1 megabyte of memory. >> 4. Trivial network management: some of you network administrators >> will kick yourselves when you see how easy things could/should >> have been. >> 5. Mobility of hosts. You very cleverly left out Item #3, the biggest problem that faces the Internet today. Exhaustion of available names in the Domain Name System. Yes, that's right. There's not a lot of discussion about this on the various mailing lists, which is just disgraceful. Yes, its one of those things that's not discussed in polite company, but the time as come to get this out into the open, and propose solutions. Actually, I suspect part of the silence is some fiendish master plan by those planning to corner the market on registered domains. (What next, OVEN.COM? microwave.oven.com, toaster.oven.com, pizza.oven.com..) Because I think that this is vital to the future of the Internet, I have chosen this day to come forward and disclose this fiendishly simple way of solving this problem. It is important that this information get out before something.... happens to me... which might cause it to be lost forever. The ANSWER is: HOST NAMES IN IN-ADDR.ARPA! Shocking in its simplicity, eh? Where you'd normally have something like this in a zone file today: 202.144.IN-ADDR.ARPA. IN SOA wa3ymh.TransSys.COM. postmaster.TransSys.COM. ( 94010801 ; serial (increment on update) 36000 ; refresh 1800 ; retry 604800 ; expire 43200 ); minimum IN NS NS.UU.NET. IN NS UUCP-GW-1.PA.DEC.COM. IN NS UUCP-GW-2.PA.DEC.COM. 1.1 IN PTR wa3ymh.TransSys.COM. 1.42 IN PTR Express.TransSys.COM. 6.42 IN PTR Rover.TransSys.COM. 42.42 IN PTR wa3ymh.TransSys.COM. 43.42 IN PTR PC.TransSys.COM. You simply augment your zone, and have something like this instead: $ORIGIN 202.144.IN-ADDR.ARPA. 202.144.IN-ADDR.ARPA. IN SOA wa3ymh.TransSys.COM. postmaster.TransSys.COM. ( 94010803 ; serial (increment on update) 36000 ; refresh 1800 ; retry 604800 ; expire 43200 ); minimum IN NS NS.UU.NET. IN NS UUCP-GW-1.PA.DEC.COM. IN NS UUCP-GW-2.PA.DEC.COM. IN MX 5 42.42.202.144.IN-ADDR.ARPA. IN MX 10 relay2.UU.NET. 1.1 IN PTR 42.42.202.144.IN-ADDR.ARPA. IN A 144.202.1.1 IN MX 5 1.1.202.144.IN-ADDR.ARPA. IN MX 10 relay2.UU.NET. ; 1.42 IN PTR 42.42.202.144.IN-ADDR.ARPA. IN A 144.202.42.1 IN MX 5 1.42.202.144.IN-ADDR.ARPA. IN MX 10 relay2.UU.NET. 6.42 IN PTR 6.42.202.144.IN-ADDR.ARPA IN A 144.202.42.6 42.42 IN PTR 42.42.202.144.IN-ADDR.ARPA. IN A 144.202.42.42 IN MX 5 42.42.202.144.IN-ADDR.ARPA. IN MX 10 relay2.UU.NET. 43.42 IN PTR 43.42.202.144.IN-ADDR.ARPA. Yes, that's right. There's no reason why you can't have A and MX records associated with names in an IN-ADDR.ARPA zone! Why, its been under our noses (er, fingers) all this time - I would have bit us! The advantages of this fine plan: 0) Simple and easy transition. No "flag days" are required to ease into this easy to implement solution. 1) It's a "GREEN", environmentally friendly solution - we get to recycle and reuse part of the valuable DNS name space which might otherwise go to waste and be discarded or ignored! (No CFCs are required, unlike those used when PC boards are manufactured!) 2) It's educational! It is clear from the problems that some have using anonymous FTP servers that many users of the Internet have not correctly configured their IN-ADDR.ARPA zone. This new approach solves the problem by only requiring ONE zone be allocated to an organization for both their names *AND* their addresses. People will no longer "forget" about their IN-ADDR.ARPA zone. 3) Absolutely *NO* software changes or updates required! Existing TCP/IP implementations that make use of the DNS can immediately use these vast new resources! No expensive software updates or tedious software installation procedures need to be performed to gain this new capability. 4) Network management is unaffected! *ALL* existing DNS management and diagnostic software can immediately be pressed into service to manage this capability. 5) HOST NAME => IP ADDRESS and IP ADDRESS => HOST NAME query operations can now be assured that the they are accessing synchronized data, because for the first time, both the official domain names and the associated PTR records are in the SAME ZONE! 6) Less overhead. Secondary name servers for an organization need only tranfer a single zone, rather than multiple zones to backup an organization! 7) IPng compatible - "Just Works" with longer addresses! 8) Politically Correct. No longer can IN-ADDR.ARPA be treated as a DNS ghetto. It becomes a first class citizen! 9) Good scaling properties. DNS name space for hosts can last at least as long as whatever flavor IP address space is being used. 10) Tastes Great AND Less Filling! >> In the meantime, I desperately need support. If there is anyone out >> there who is willing to provide equipment for testing please contact >> me. I have been trying to do testing using two RS232 ports on my two >> IBM-PC/XT's, and things just aren't happening as fast as I would like >> them to. I need real machines, a real C compiler, a real assembler, >> and real network adapters. I have actually expended considerable resources to get this far, in the form of all 3 of the computers on my network at home. I've done this, so far, without outside support or funding. That's right, no free ride on the American Tax Payer for me! Yet. Open topics for research are applying these same techniques to the X.500 directory service. Here, I could use a little bit of help in the form of equipment donations and funding. I figure a couple 'o Sparcstation 10/50's to run prototype X.500 servers and maybe 2 or 3 SGI Indy's to visulalize the results ought to do it. FDDI to hook all this stuff together; maybe ATM. Oh yeah, I'll need a DS3 connection to the internet to *really* take this baby for a ride. Interested funding agencies can just drop me some mail (and find out that this Technology WORKS TODAY!) Louis Mamakos louie@202.144.IN-ADDR.ARPA From owner-Big-Internet@munnari.OZ.AU Sat Apr 2 11:16:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28304; Sat, 2 Apr 1994 11:16:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA01382; Sat, 2 Apr 1994 11:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA01368; Sat, 2 Apr 1994 11:00:42 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27968; Sat, 2 Apr 1994 11:01:48 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA23556; Fri, 1 Apr 1994 17:01:41 -0800 Date: Fri, 1 Apr 1994 17:01:41 -0800 X-Sender: dcrocker@mordor.stanford.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tony Li From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU At 3:29 AM, Tony Li wrote: >Thank you for volunteering. I have you down for an agenda item at our next >working group meeting. You're entirely welcome. I hope that others also are motivated to attempt to develop a prediction model that pays attention to market segments. On the other hand, Tony, I'm a bit confused. "Next working group meeting"?? As in, Toronto? As in, the same meeting at which IPng will be chosen? Pray tell: what will be the benefit in pursuing the issue at that time or later? Dave From owner-Big-Internet@munnari.OZ.AU Sat Apr 2 14:16:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03546; Sat, 2 Apr 1994 14:16:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA01545; Sat, 2 Apr 1994 14:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA01531; Sat, 2 Apr 1994 13:57:02 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28286; Sat, 2 Apr 1994 11:15:09 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-26.dialip.mich.net (pm002-26.dialip.mich.net [35.1.48.107]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA02325 for ; Fri, 1 Apr 1994 20:15:03 -0500 Date: Fri, 1 Apr 94 23:35:24 GMT From: "William Allen Simpson" Message-Id: <2116.bill.simpson@um.cc.umich.edu> To: Big-Internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Cellular > From: Eric Fleischman > According to your definition (see below), IP is already out of addresses. > I conclude this in view of the actions of the Power Companies (EPRI) and > by the Cellular Data companies (e.g., CDPD spec) which concluded that > the remaining IP address space was inadequate for their needs and > therefore they adopted another protocol other than TCP/IP to "meet > their needs". Eric, you made this assertion a couple of times in the past few days, and it was echoed by John Curran, but it is in error. I can't blame you, as 6 months ago I might have made the same mistake. I can't say for sure about EPRI, but the "Cellular Data companies" did not conclude that IP was in adequate for their needs. In fact, the formal cellular standard EIA/TIA IS-99, which is up for ballot soon, uses TCP/IP/PPP as the basis. The cellular data companies did not write the CDPD spec. It did not go through the EIA/TIA standards process. CDPD was written by ATT cum McCaw, and is a proprietary protocol. It is not widely deployed (one site - Las Vegas), but has had a lot of marketing hype. However, it is an apparently little known fact that CDPD specifies both TP4/CLNP _and_ TCP/IP over its _proprietary_ SNDCP (link layer). The real point of contention right now is not the use of IP; rather, the use of PPP versus CDPD SNDCP and TDMA RLP (for which ATT just disclosed patents last week). The use of PPP is much farther along in the EIA/TIA standards process than the proprietary solutions, but I could probably use some political help in the form of friendly suggestions to knowlegable providers and vendors participating in the EIA/TIA. Both Phil Karn and I helped write IS-99. It references current IP RFCs, but also leaves room for IP Mobility and is carefully worded to allow updating to at least one IPng. And because it uses PPP for the link layer, it will run other protocols than IP, such as IPX, AppleTalk, and even CLNP. Since the allocation of cellular IP numbers is entirely dependent on the number of computers hooked to the phones, the IP address space depletion is bounded by the same computer deployment that already affects IP numbering, not by cellular phone deployment. Projected sales for cellular phones is in the hundreds of thousands per year. The potential load on IP address space is large, but nowhere near the already projected laptop sales. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat Apr 2 16:36:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07338; Sat, 2 Apr 1994 16:36:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA01675; Sat, 2 Apr 1994 16:35:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA01672; Sat, 2 Apr 1994 16:30:20 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07271; Sat, 2 Apr 1994 16:31:33 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id WAA00202; Fri, 1 Apr 1994 22:31:25 -0800 Date: Fri, 1 Apr 1994 22:31:25 -0800 From: Tony Li Message-Id: <199404020631.WAA00202@lager.cisco.com> To: dcrocker@mordor.stanford.edu Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Dave Crocker's message of Fri, 1 Apr 1994 17:01:41 -0800 Subject: Minimal Changes & IPng On the other hand, Tony, I'm a bit confused. "Next working group meeting"?? As in, Toronto? As in, the same meeting at which IPng will be chosen? Pray tell: what will be the benefit in pursuing the issue at that time or later? Yes. Yes. Yes. Gee, Dave, didn't anyone tell you -- we have to do more work after we've made a decision as to which IPng to use. The completed protocol does not spring forth full grown from the forehead of Zeus (or even Steve!). ;-) I'm somewhat surprised, tho Dave, what did you think should come of what we were doing? Were you under the impression that the output of the ALE WG would affect the selection of IPng?????!?!?!?! If so, why? As with an annual physical, I suspect that we will continue to monitor the health of IPv4 well into the deployment of IPng, if only so that we know when we have to have that day when there is an IPng host without a unique IPv4 address. I realize thaat the IPng directorate is supposed to be finished at that point. I suspect, however, that the work will live on in other areas. Tony From owner-Big-Internet@munnari.OZ.AU Sun Apr 3 11:14:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01853; Sun, 3 Apr 1994 06:38:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA02392; Sun, 3 Apr 1994 06:35:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA02378; Sun, 3 Apr 1994 06:24:25 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01508; Sun, 3 Apr 1994 06:25:32 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id MAA14189; Sat, 2 Apr 1994 12:25:03 -0800 Date: Sat, 2 Apr 1994 12:25:03 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tony Li From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU At 6:31 AM, Tony Li wrote: >Gee, Dave, didn't anyone tell you -- we have to do more work after >we've made a decision as to which IPng to use. Well, I certainly do acknowledge being confused as to the real purpose and benefit of this effort. The most common response to my queries on the matter, back when it was being chartered, was along the lines of "it will be interesting." And no, there was no indication that this was an on-going effort. > Were you under the impression that the output of >the ALE WG would affect the selection of IPng?????!?!?!?! If so, why? Maybe it's been the increasing tendency of people to use your output as a basis for saying that we don't need to make a decision soon. Perhaps you didn't hear any of those, this past week, but I sure did. > if only so that >we know when we have to have that day when there is an IPng host >without a unique IPv4 address. Tony, I don't think that your effort will produce that result. I suspect that it will come from a failed registration request. (Someone has claimed we've already hit that point?) As with many efforts to produce fine-grained precision about processes that are only coarsely understood, your effort will keep us dumb but happy. IPng has enough other development and deployment requirements pressing against it so that the feedback from your effort doesn't affect the required project plan. In effect, the only thing we get to see is how well our growth matches a given curve. When we are all done, years from now, you or I will be able to look back and tell the other how right we were. And THAT will probably be the only seriously measureable product of the effort. Dave From owner-Big-Internet@munnari.OZ.AU Sun Apr 3 21:01:05 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26185; Sun, 3 Apr 1994 21:01:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12974 Sun, 3 Apr 1994 20:59:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA03097; Sun, 3 Apr 1994 20:55:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA03083; Sun, 3 Apr 1994 20:45:33 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22125; Sun, 3 Apr 1994 18:42:14 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id AAA03231; Sun, 3 Apr 1994 00:42:02 -0800 Date: Sun, 3 Apr 1994 00:42:02 -0800 From: Tony Li Message-Id: <199404030842.AAA03231@lager.cisco.com> To: dcrocker@mordor.stanford.edu Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Dave Crocker's message of Sat, 2 Apr 1994 12:25:03 -0800 Subject: Minimal Changes & IPng Dave, Tony, I don't think that your effort will produce that result. I suspect that it will come from a failed registration request. (Someone has claimed we've already hit that point?) You're confused. There's a difference between a host with no IP address and a host with an IPng address but no IPv4 (mappable) address. The latter is important operationally as it is the day that there are no more obvious workarounds. As with many efforts to produce fine-grained precision about processes that are only coarsely understood, your effort will keep us dumb but happy. Well, I can see that you're not happy. IPng has enough other development and deployment requirements pressing against it so that the feedback from your effort doesn't affect the required project plan. So you say... I don't believe you. So far the IPng effort has been a colossal spinning of political wheels. I believe that it is very important to remind folks that the clock is ticking. In effect, the only thing we get to see is how well our growth matches a given curve. When we are all done, years from now, you or I will be able to look back and tell the other how right we were. And THAT will probably be the only seriously measureable product of the effort. It's so nice to know that doing operational work is held in such high regard by you. Tony From owner-Big-Internet@munnari.OZ.AU Mon Apr 4 06:14:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28661; Sun, 3 Apr 1994 22:37:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA03195; Sun, 3 Apr 1994 22:35:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA03178; Sun, 3 Apr 1994 22:15:51 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17331; Sun, 3 Apr 1994 15:41:27 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA02377; Sat, 2 Apr 94 21:35:25 -0800 Received: by xirtlu.zk3.dec.com; id AA15098; Sun, 3 Apr 1994 00:35:23 -0500 Message-Id: <9404030535.AA15098@xirtlu.zk3.dec.com> To: Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of "Sat, 02 Apr 94 12:25:03 PST." Date: Sun, 03 Apr 94 00:35:17 -0500 X-Mts: smtp Just to throw my 2 cents in: 1. I think kre should publish his ID with input from Noel's comments. I think this would be of interest and valuable to the IETF community. 2. I do listen carefully to ALE as a Directorate member and consider the data imperative to our review of IPng input. CIDR too. I took the Don't Panic message to mean I have time to think and do some architectural analysis (with implementation thoughts succeeding that architectural analysis as I pointed out at the IETF several times). 3. I do not think we have a great architecture for IPng internetwork defined in any proposal yet for the Internet or the emerging Super Information Highway. We need folks to discuss in more depth Noel's ideas and then relate that data back to technical implementation scenarios for IPng and I believe IPv4 too (a good example was the flow state discussion). It might be IPng proposals don't have to have a great architecture, but their pieces should support a great architecture (yes I do like the ideas of NIMROD that I understand). 4. I don't know what to do about customers who have a near-term need for address space greater than IPv4 will permit if they used all of it as a flat address space or aggregated. My first question is do all these nodes need to be on the Internet? My second question is are all pieces for their solution defined? My third question is a long the lines of Bill Simpson's input, and that is how quickly will the product points enter the market? 5. THIS IS MY OWN PERSONAL OPINION NOT THE DIRECTORATE: If none of the proposals will work based on accurate and well articulated reasons from the Area Directors then I see no failure in stating to the IETF these proposals will not work whether they are tweeked or heavily tweeked. The IPng Area should not select a proposal simply because July is the deadline. It would be nice though based on ALE and CIDR data I am seeing we would have time to put finishing touches on the IPng as required. I believe we do not have to Panic and have believed this since the IPng issues came up in our industry. 6. Transition to IPng: This to me is very critical and must be well thought out and implemented. Or customers in private companies will not accept IPng as a network protocol suite. I don't think the SIPP transition completely is the the best answer and a dual stack approach has many unanswered questions regarding the assumptions about how customers will deploy IPng at their pace. I think the answer is a hybrid of dual stack and IPv4 compatible addresses for tunneling. In addition I believe its best to define translation types and scenarios via an architectural prototype and then discuss where translation will be used. Otherwise we leave it open to the market and let varying technologies be deployed for that purpose and for translation. I am going to take a stab at a generic IPng transition idea. If your interested in being in the loop send me private mail. 7. RFC 1597. I have no opinion as long as its not required and is only an option for a private company. I don't see the DNS problem because those addresses should not be in the DNS or in any Internet routing tables, as I understand the purpose of RFC 1597? 8. TURNIP: Need to think about Tony's packet. But I think it will need more than dual stack for transition. But thats another issue. Regarding the use of OSI routing protocols that would depend on further discussion of Noel's ideas in previous bullet and Dave Clark's question of what do we want in an architecture too. Like do we believe we want Servers on the subnet defining addresses and services. If we do then there could be a need to tweek the OSI protocols and architecture to support TCP/IP 'models' we believe in today and for tomorrow. The issue of Multicast also affects the architecture of tomorrow too. Should routers also be autoconfigured like hosts on the network too? Lots of questions need to be asked before that could be cast in stone. 9. Host performance: It appears from what Tony said at the open IPng Directorate meeting that his routing analysis per any IPng regarding performance was a wash. Others have told me this now too. I am a believer. But what we need to do is make sure customers using hosts today do not see performance degradation because of any IPng. I also do not believe that the Internet Centric applications like ftp, telnet, rlogin, etc. are a good measure of host performance either. We need to test that with industry applications used by private companies. 10. APIs: I want to throw my vote in with Brian Carpenter and Eric Fleischman that this is important. I believe we can come up with an API that will work for any IPng and will permit binary compatibility for IPv4 apps until they port to become IPng capable. But there is a side effect to the API based on its interface to the transport layer depending on the transition architecture of an IPng. An obvious example is an ISV that ports their database to use IPng but still wants to accept and initiate connections with IPv4 clients that know nothing of IPng. The database application ported to IPng should not be concerned with non-IPng addresses like IPv4. The trick is to support IPv4 as a subset to the IPng application without having the IPng application have any knowledge of IPv4. An IPng transition strategy will affect the environment to achieve this function. /jim From owner-Big-Internet@munnari.OZ.AU Mon Apr 4 06:19:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05484; Mon, 4 Apr 1994 02:17:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA03408; Mon, 4 Apr 1994 02:15:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA03394; Mon, 4 Apr 1994 02:04:56 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05179; Mon, 4 Apr 1994 02:06:02 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA02937; Sun, 3 Apr 1994 09:05:30 -0700 Date: Sun, 3 Apr 1994 09:05:30 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Jim, Since one of the suggestions I made at the Friday open directorate was to find a way to make sure that the final pronouncement from the directorate come as no surprise to the community, I think some public discussion of details could be helpful. Since you've been working on implementation, you're in a better than average position of offer some of that detail... At 5:35 AM, bound@zk3.dec.com wrote: > I don't think the SIPP > transition completely is the the best answer and a dual stack > approach has many unanswered questions regarding the assumptions > about how customers will deploy IPng at their pace. It will may be that I've missed them, but are the deficiencies and unaswered questions documented somewhere? I would wish that the directorate would take it as an action item to deliver such queries and preliminary judgements about pieces, real soon, to give the contenders time to respond. I think the > answer is a hybrid of dual stack and IPv4 compatible addresses for > tunneling. An herein lies a heckofalotof confusion for me. IPAE consists of a several transition techniques, two of which are dual stack and IPv4 compatible addresses for tunneling. I gather you don't see it that way and would be interested in some clarification. Dave From owner-Big-Internet@munnari.OZ.AU Mon Apr 4 06:20:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05719; Mon, 4 Apr 1994 02:23:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA03423; Mon, 4 Apr 1994 02:20:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA03391; Mon, 4 Apr 1994 01:56:11 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04952; Mon, 4 Apr 1994 01:57:19 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA02903; Sun, 3 Apr 1994 08:55:14 -0700 Date: Sun, 3 Apr 1994 08:55:14 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tony Li From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU At 8:42 AM, Tony Li wrote: > > IPng has enough other development and deployment requirements pressing > against it so that the feedback from your effort doesn't affect the > required project plan. > >So you say... I don't believe you. Tony, since the tone of the current exchange has dived into a scan of trivializations, please explain your above statement, against the previous one you made expressing surprise that I thought this work would affect the IPng selection. Don't tell me you think it won't affect the selection but WILL affect the deployment? If that were true, then why all the concern for having IPng contain interesting features to attract users? If your predictions were so essential, we wouldn't need the market pull based on features. >So far the IPng effort has been a >colossal spinning of political wheels. I believe that it is very >important to remind folks that the clock is ticking. Well, 50% ain't bad. I think your first statement is frankly an insult to the teams working on the specifications. Anything that far off the mark in the face of fully public, extensive efforts, is willful. That makes it an insult to them. On the other hand, we are in complete agreement about your latter statement. On the other hand, feeding people statements that says they have 14 years (best case) doesn't exactly get the heart rate up. > And THAT will probably be the only seriously measureable product of the > effort. > >It's so nice to know that doing operational work is held in such high >regard by you. Ahh, yes. Over-generalize a statement and it's always interesting to see the distortions that can be made. Tony, my involvement began with a concern for transition. That was strictly and completely the motivation for IPAE. If that doesn't constitute holding operational work in high regard, one of us is on the wrong planet. I was criticizing only the ALE work. A specific piece of operations-related work, in effect trying to apply congestion trend analysis techniques against a new-market growth problem. That's different. Dave From owner-Big-Internet@munnari.OZ.AU Mon Apr 4 09:40:19 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19838; Mon, 4 Apr 1994 09:40:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA21201 Mon, 4 Apr 1994 09:40:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA03811; Mon, 4 Apr 1994 09:35:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA03808; Mon, 4 Apr 1994 09:28:29 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18258; Mon, 4 Apr 1994 08:36:13 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA19445; Sun, 3 Apr 94 18:36:04 EDT Message-Id: <9404032236.AA19445@tipper.oit.unc.edu> To: Big-Internet@munnari.OZ.AU, ses@tipper.oit.unc.edu Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of "Sun, 03 Apr 94 00:42:02 -0800." <199404030842.AAA03231@lager.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Apr 94 18:36:02 -0400 From: Simon E Spero Ad Hominem. On the offence. 5 yards. Repeat the argument From owner-Big-Internet@munnari.OZ.AU Mon Apr 4 13:38:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29621; Mon, 4 Apr 1994 13:38:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA04021; Mon, 4 Apr 1994 13:35:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA04018; Mon, 4 Apr 1994 13:34:28 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28217; Mon, 4 Apr 1994 12:46:17 +1000 (from swb1@cornell.edu) Received: from POSTOFFICE3.MAIL.CORNELL.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23302 Mon, 4 Apr 1994 12:30:32 +1000 (from swb1@cornell.edu) Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.5/8.6.5) with SMTP id WAA20942 for ; Sun, 3 Apr 1994 22:27:47 -0400 Message-Id: <199404040227.WAA20942@postoffice3.mail.cornell.edu> X-Sender: swb1@postoffice3.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 3 Apr 1994 22:27:39 -0500 To: big-internet@munnari.OZ.AU From: Scott W Brim Subject: connecting toasters etc. Folks, Friday morning at IPng meeting a big deal was made of how the Internet is going to have to reach whole new classes of things in the near future. I just want to repeat that while we would like to have a single, pervasive, universal internet protocol suite, it is not necessary to have one for the Internet to work -- and that's our only real goal. As was discussed last year on this list (I think it was this list), you don't need to talk directly to a refrigerator if you can communicate effectively using the house as an intermediary, and decoupling these two steps may allow more rapid adaptation in both sets of protocols. Having a universal suite of protocols can be a goal but it does not need to be a fundamental requirement for IPng, as long as effective universal communication is possible somehow. ...Scott From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 00:37:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19828; Tue, 5 Apr 1994 00:37:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA04573; Tue, 5 Apr 1994 00:35:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA04570; Tue, 5 Apr 1994 00:29:35 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB19040; Tue, 5 Apr 1994 00:11:30 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404041411.19040@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Apr 1994 15:11:07 +0100 To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Sat, 02 Apr 94 00:01:23 -0900." <199404020801.AAA01820@lager.cisco.com> Date: Mon, 04 Apr 94 15:11:05 +0100 From: Jon Crowcroft > TURNIPP - A merger proposal a day too late... >Turnipp is a merger proposal, combining the best parts of SIPP, TUBA, and >CATNIP. 'best' in what sense...? performance, migration, flexibility? sorry, these do not form a metric space. >Routing is done with ES-IS, Integrated ISIS (extended for arbitrary levels) >and IDRP. and what about nimrod? jon From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 01:37:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21548; Tue, 5 Apr 1994 01:37:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA04670; Tue, 5 Apr 1994 01:35:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA04661; Tue, 5 Apr 1994 01:31:16 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20882; Tue, 5 Apr 1994 01:15:17 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404041515.20882@munnari.oz.au> Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Apr 1994 16:14:49 +0100 To: yakov@watson.ibm.com Cc: tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Mon, 04 Apr 94 10:53:44 EDT." Date: Mon, 04 Apr 94 16:14:48 +0100 From: Jon Crowcroft >>>Routing is done with ES-IS, Integrated ISIS (extended for arbitrary >>>levels) and IDRP. >>and what about nimrod ? >Let me answer your question with another question. What is wrong with >Tony's list: ES-IS, ISIS and IDRP plus with some form of source >routing (e.g. SDRP, GRE) to deal with specialized routing requirements ? but i want to use cheap and nasty routoing where possible (in small sites...) too jon From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 01:39:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21738; Tue, 5 Apr 1994 01:39:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA04685; Tue, 5 Apr 1994 01:38:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA04667; Tue, 5 Apr 1994 01:35:51 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21538; Tue, 5 Apr 1994 01:37:05 +1000 (from yakov@watson.ibm.com) Message-Id: <9404041537.21538@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6109; Mon, 04 Apr 94 11:36:57 EDT Date: Mon, 4 Apr 94 11:36:57 EDT To: J.Crowcroft@cs.ucl.ac.uk Cc: tli@cisco.com, big-internet@munnari.OZ.AU Subject: Turnipp - a merger proposal Ref: Your note of Mon, 04 Apr 94 16:14:48 +0100 Jon, >But I want to use cheap and nasty routing where possible (in small >sites...) That is fine. Hierarchical routing (ES-IS, ISIS and IDRP) plus some form of source routing (e.g. SDRP, GRE) to deal with specialized routing requirements seems quite cheap (in terms of the overhead). With respect to being "nasty", you should probably be more specific, but I have very high degree of confidence that the above list could qualify for "nasty" as well :-). Yakov. From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 01:42:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21861; Tue, 5 Apr 1994 01:42:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA04711; Tue, 5 Apr 1994 01:41:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA04664; Tue, 5 Apr 1994 01:31:28 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20906; Tue, 5 Apr 1994 01:16:19 +1000 (from jmh@anubis.network.com) Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA18418; Mon, 4 Apr 94 10:19:43 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA01118; Mon, 4 Apr 94 10:16:07 CDT Date: Mon, 4 Apr 94 10:16:07 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9404041516.AA01118@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In discussing Routing as it might be applied to IPng, a list was suggested, and Jon Crowcroft asked: "what about nimrod?". Yakov asked what was wrong with the base list (ES-IS, ISIS, IDRP) to which Yakov added SDRP and GRE. I think that "what is wrong" is the wrong question. If we are asking about routing for the future, we should be asking "would it be better to use..." rather than "what is wrong with the tool we have?" The tool(s) we have are very nice. But there is a good chance we can build better ones. We should not preclude that in our planning, and should actively inquire as to whether we can build better mousetraps. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 01:57:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22305; Tue, 5 Apr 1994 01:57:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA04741; Tue, 5 Apr 1994 01:55:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA04727; Tue, 5 Apr 1994 01:53:10 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22213; Tue, 5 Apr 1994 01:54:18 +1000 (from lyman@BBN.COM) Message-Id: <9404041554.22213@munnari.oz.au> From: Lyman Chapin Subject: Re: Turnipp - a merger proposal To: jmh@anubis.network.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404041516.AA01118@anubis.network.com> Date: Mon, 4 Apr 94 11:01:34 EDT Mail-System-Version: >Date: Mon, 4 Apr 94 10:16:07 CDT >From: jmh@anubis.network.com (Joel Halpern) >To: big-internet@munnari.oz.au >Subject: Re: Turnipp - a merger proposal > >In discussing Routing as it might be applied to IPng, a list was suggested, >and Jon Crowcroft asked: "what about nimrod?". Yakov asked what was wrong >with the base list (ES-IS, ISIS, IDRP) to which Yakov added SDRP and GRE. >I think that "what is wrong" is the wrong question. If we are asking about >routing for the future, we should be asking "would it be better to use..." >rather than "what is wrong with the tool we have?" The tool(s) we have >are very nice. But there is a good chance we can build better ones. We >should not preclude that in our planning, and should actively inquire as >to whether we can build better mousetraps. > >Thank you, >Joel M. Halpern jmh@network.com >Network Systems Corporation Joel, I agree - as long as we are not in the meantime overrun by a plague of mice... - Lyman From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 03:38:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25886; Tue, 5 Apr 1994 03:38:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA04870; Tue, 5 Apr 1994 03:35:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA04856; Tue, 5 Apr 1994 03:23:56 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AD25408; Tue, 5 Apr 1994 03:24:43 +1000 (from dcrocker@mordor.stanford.edu) Received: from Mordor.Stanford.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08554 Tue, 5 Apr 1994 03:22:36 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA26155; Mon, 4 Apr 1994 10:18:48 -0700 Date: Mon, 4 Apr 1994 10:18:48 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jmh@anubis.network.com (Joel Halpern) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Turnipp - a merger proposal Cc: big-internet@munnari.OZ.AU At 3:16 PM, Joel Halpern wrote: > The tool(s) we have >are very nice. But there is a good chance we can build better ones. Indeed. Both are true. And in moving to IPng, we need to keep both facts in mind. And in moving to IPng, we need to consider finding a path that lets us KEEP USING those tools that are very nice, while allowing for ADDING the better ones. Dave From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 05:09:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20498; Tue, 5 Apr 1994 00:57:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA04614; Tue, 5 Apr 1994 00:55:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA04600; Tue, 5 Apr 1994 00:52:39 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20256; Tue, 5 Apr 1994 00:53:49 +1000 (from yakov@watson.ibm.com) Message-Id: <9404041453.20256@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5003; Mon, 04 Apr 94 10:53:44 EDT Date: Mon, 4 Apr 94 10:53:44 EDT To: J.Crowcroft@cs.ucl.ac.uk, tli@cisco.com Cc: big-internet@munnari.OZ.AU Subject: Turnipp - a merger proposal Ref: Your note of Mon, 04 Apr 94 15:11:05 +0100 Jon, >>Routing is done with ES-IS, Integrated ISIS (extended for arbitrary >>levels) and IDRP. >and what about nimrod ? Let me answer your question with another question. What is wrong with Tony's list: ES-IS, ISIS and IDRP plus with some form of source routing (e.g. SDRP, GRE) to deal with specialized routing requirements ? Yakov Rekhter. From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 08:57:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06951; Tue, 5 Apr 1994 08:57:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA05246; Tue, 5 Apr 1994 08:56:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA05218; Tue, 5 Apr 1994 08:36:00 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB06376; Tue, 5 Apr 1994 08:37:09 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id PAA14444; Mon, 4 Apr 1994 15:36:17 -0700 Date: Mon, 4 Apr 1994 15:36:17 -0700 From: Tony Li Message-Id: <199404042236.PAA14444@lager.cisco.com> To: ses@tipper.oit.unc.edu (Simon E Spero) Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal Can someone tell me privately whether Turnip is a joke or not? I had assumed that it was an April Fool's prank by a Blackadder fan, but it seems to have gone on too long for that. Well, it wasn't intended as a joke. Your technical opinion may vary. ;-) If you weren't at the IPng open directorate meeting, I asked about the possibility of another merger between the current contenders. My personal feeling is that the "selection" of a contender is harmful to the community, and that progress should be made by further mergers. Turnipp is my attempt to suggest a strawman for the proposal authors to work from. If I've done my job correctly, the result still looks like a horse, not a camel. Tony From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 09:03:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07221; Tue, 5 Apr 1994 09:03:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA05261; Tue, 5 Apr 1994 08:59:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA05232; Tue, 5 Apr 1994 08:49:55 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06770; Tue, 5 Apr 1994 08:51:08 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id PAA15249; Mon, 4 Apr 1994 15:50:48 -0700 Date: Mon, 4 Apr 1994 15:50:48 -0700 From: Tony Li Message-Id: <199404042250.PAA15249@lager.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Cc: big-internet@munnari.OZ.AU Subject: Costs, Performance and IPng Jon, i.e. we are being told something quite strong about how fast you can make a given router go on putting packets into the right queue (includes route lookup as well as QoS matching). That thing is that fixed fields (c.f. IPv4 and SIPP) are better than variable ones (c.f. CLNP, TURNIPP, catnip). I'd like to revise the message that you're getting: - For our hardware, the amount of overhead is, to a first order, the number of bytes that I have to read to make the routing decision -- and SIPP is not significantly different from CLNP. - The second order approximation takes into account the placement of the fields within the header. In the case of SIPP, things are pretty much pessimally laid out for us. Consider the case where you actually have to route on the flow. - Variable length is not a problem, even for other architectures. But arbitrary lengths ARE a problem because they force you to treat addresses as strings of bytes. Addresses which are variable but not wholly arbitrary allow you to optimize for the sizes you know you will see most frequently. Thus, SIPP and Turnipp have identical performance when routing on the destination address using the IPng AFI in Turnipp. It's always 8 bytes. Note that most of the above entail changing CLNP to work efficiently....if we (ietf) change CLNP, then where is the a) ownership b) gain in legacy CLNP s/w, and therefore c) why not just change to a fully owned optimised protocol...? I know of nothing that's currently proposing changes to CLNP. Tony From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 10:25:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10129; Sat, 2 Apr 1994 18:16:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA01779; Sat, 2 Apr 1994 18:15:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA01765; Sat, 2 Apr 1994 18:00:21 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09783; Sat, 2 Apr 1994 18:01:29 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id AAA01820; Sat, 2 Apr 1994 00:01:23 -0800 Date: Sat, 2 Apr 1994 00:01:23 -0800 From: Tony Li Message-Id: <199404020801.AAA01820@lager.cisco.com> To: big-internet@munnari.OZ.AU Subject: Turnipp - a merger proposal Folks, After today's open meeting of the IPng directorate, I felt it was only fair if I was an actor for unification amongst the proposals. Attached is a strawman of a merger proposal. Tony TURNIPP - A merger proposal Turnipp is a merger proposal, combining the best parts of SIPP, TUBA, and CATNIP. The Turnipp header consists of two parts, the fixed part and the address part: +-----------------+ | Fixed part | +-----------------+ | Address part | +-----------------+ The fixed portion of the header has format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| |F| Payload Type | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State Control | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All unlabelled fields are reserved, must be sent as zero and ignored on receipt. Version 4-bit Internet Protocol version number = 6. F (Flow bit) Indicates whether the address portion is of one of two formats described below. Payload Type 8-bit selector. Identifies the type of header immediately following the Turnipp header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Total Length 16-bit unsigned integer. Length of the total packet, including the Turnipp header, in octets. State Control 8-bit selector. Identifies the action to be performed if the state associated with the flow in this packet is not in the router. Values and semantics TBD. Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. If the F bit is set to 0, the address portion of the header has the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Length | | +-+-+-+-+-+-+-+-+ Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest Length | | +-+-+-+-+-+-+-+-+ Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Length 8-bit unsigned integer. Length of the source address field. Dest Length 8-bit unsigned integer. Length of the destination address field. Both the source and destination addresses are NSAPs. Implementations are required to support arbitrary length values, but may optimize for the lengths described below. The ISOC will need to acquire two AFI's for it's own use. Call them A and B. Addresses in AFI A will have format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Length) | AFI A | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Source or destination length. Will always be 7 for AFI A addresses. AFI A 8-bit selector. Indicates a globally unique imbedded IPv4 address. Reserved 16 bits. Must be sent as zero, must be ignored on receipt. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Length) | AFI B | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Turnipp Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Source or destination length. Turnipp addresses always have length 7+n*8 octets, i = 0, ... n. AFI B 8-bit selector. Indicates a Turnipp Address. Turnipp Address 7 octets (including AFI). If the F bit is set to 1, the address portion of the header has the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Flow Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Length | | +-+-+-+-+-+-+-+-+ Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest Length | | +-+-+-+-+-+-+-+-+ Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flow Identifier 64 bits. Contents TBD. Discussion: Placement of the F bit in the first byte of the packet allows rapid dispatch to code paths optimized for IPv4, IPng with flows and IPng without flows. Use of the flow bit and the resulting complexity in address portion of the header allows non-flows to not carry 8 octets of useless overhead. Routers only need the first 4 longwords to route the packet in the optimized code path. Fields are aligned appropriately for 64 bit architectures. The overall layout is well-suited for the implementation of hardware assisted routers. Novell is encouraged to acquire another AFI for embedding IPX addresses in Turnipp. As an IPX address is 10 octets, the resulting NSAP is 12 octets which is convenient for 32 bit based machines. The transition plan for Turnipp is dual stack. Routing is done with ES-IS, Integrated ISIS (extended for arbitrary levels) and IDRP. Tony From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 10:27:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25071; Tue, 5 Apr 1994 03:17:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA04840; Tue, 5 Apr 1994 03:15:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA04826; Tue, 5 Apr 1994 02:56:28 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24331; Tue, 5 Apr 1994 02:57:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26717; Mon, 4 Apr 94 12:57:32 -0400 Date: Mon, 4 Apr 94 12:57:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404041657.AA26717@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal Cc: jnc@ginger.lcs.mit.edu >> Routing is done with ES-IS, Integrated ISIS (extended for arbitrary >> levels) and IDRP. > and what about nimrod ? Let me answer your question with another question. What is wrong with Tony's list: ES-IS, ISIS and IDRP plus with some form of source routing (e.g. SDRP, GRE) to deal with specialized routing requirements ? Whoa. I'm not sure if what's going on here is a technical debate about the merits of various alternatives, or not, but I sure don't want to get into a big political hassle here with "dueling routing architectures". As far as I can see, one of two things is true: i) Nimrod is more the right thing than other alternatives, in which case I think that will slowly become clear to all, and no big political fight is needed, or ii) it's not the right thing, in which case using various manoeuverings of the form labelled as "politics" to get it adopted would not be in the Internet's long term interest. I hope the proponents of other alternatives are working from the same basic concept, yes? Anyway, within that concept, I think we could have useful technical debates about the merits of the two approaches, as long as we keep them technical. However, that's a separate debate from the one over TURNIPP as a whole. Having said that, would people like to hear the two approaches discussed? Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 10:29:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26574; Tue, 5 Apr 1994 03:57:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA04915; Tue, 5 Apr 1994 03:55:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA04901; Tue, 5 Apr 1994 03:48:57 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26316; Tue, 5 Apr 1994 03:50:03 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA20397; Mon, 4 Apr 94 13:49:55 EDT Message-Id: <9404041749.AA20397@tipper.oit.unc.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Mon, 04 Apr 94 12:57:32 EDT." <9404041657.AA26717@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Apr 94 13:49:54 -0400 From: Simon E Spero Can someone tell me privately whether Turnip is a joke or not? I had assumed that it was an April Fool's prank by a Blackadder fan, but it seems to have gone on too long for that. From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 10:30:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB00132; Tue, 5 Apr 1994 05:38:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA05023; Tue, 5 Apr 1994 05:35:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA05020; Tue, 5 Apr 1994 05:26:52 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21172; Tue, 5 Apr 1994 01:26:49 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404041526.21172@munnari.oz.au> Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Apr 1994 16:26:33 +0100 To: big-internet@munnari.OZ.AU Subject: Costs, Performance and IPng Date: Mon, 04 Apr 94 16:26:33 +0100 From: Jon Crowcroft 1. At the decision point, I believe the choice for IPng is made based on the _best_ candidate. Not on whether some candidate _can_ achieve the required functions, but on which can do them best. This is why I think the 'performance' requirement is key. Let me assert that under some unifying theory of datagram communication, you can probably show (like yo ucan under the church/turing/markov theorem) that all protocols are funcationally equivalent, so we could never have a bakeoff. However, the fact that an intel 8086 can execute the same program as a cray is neither here nor there. let me also point out that there were at least 2 requirements I heard in the int-serv WG, on flows the model Wroclawski presented at int-serv in seattle for classifcation was that the cost was linar in the number of fields to classify, and also hard to code efficiently in variable length mask/match fields (though easire in the procedural model, but less efficient). i.e. we are being told something quite strong about how fast you can make a given router go on putting packets into the right queue (includes route lookup as well as QoS matching). That thing is that fixed fields (c.f. IPv4 and SIPP) are better than variable ones (c.f. CLNP, TURNIPP, catnip). Why do i think this is key? bcause i believe a selling point of an IPng may well be cost savings, either on Link share savings, ot on multidservice supoort (e.g. routing all our phone calls over a virtual private phone system - (which would save the UK universities 7M per annum)) or multicast or all of the above. Note that most of the above entail changing CLNP to work efficiently....if we (ietf) change CLNP, then where is the a) ownership b) gain in legacy CLNP s/w, and therefore c) why not just change to a fully owned optimised protocol...? 2. now, i asserted in the IPNg requirements bof that communcations costs dominate software+hardware in end systems - lotsa people denied this - "typical americans", i thought - their costs are still largely hidden here in the wilds where market forces cause us to pay for every last detail sooner, we have a comms bill for the UK backbone of 5M pounds per years - for 100, 000 PCs on that net, 1 year would buy an ether net interface per pc. I paid the vast sum of $0 for the s/w on any PC. Hence my assertion. [I havnt included the 3k per department per year to mainain the connectivity). now, if you figure out how much s/w development you could carry out for this amount summed over all backbones, the answer is quite a lot...easily enough to do commercial SIPP host + router....of course, if you pay the inflated current bills for iso-related products, then you wouldn't have a 140Mbps backbone ... you probably wouldn't even have a 140kbps backbone:-) cheers jon From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 10:30:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02255; Tue, 5 Apr 1994 06:37:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA05096; Tue, 5 Apr 1994 06:35:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA05093; Tue, 5 Apr 1994 06:25:52 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01893; Tue, 5 Apr 1994 06:27:05 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id NAA01376; Mon, 4 Apr 1994 13:24:20 -0700 Date: Mon, 4 Apr 1994 13:24:20 -0700 From: Tony Li Message-Id: <199404042024.NAA01376@lager.cisco.com> To: dee@skidrow.lkg.dec.com Cc: big-internet@munnari.OZ.AU In-Reply-To: "Donald E. Eastlake 3rd (Beast)"'s message of Mon, 04 Apr 94 14:17:35 -0400 <9404041817.AA25665@skidrow.lkg.dec.com> Subject: Turnipp - a merger proposal After all, people who want a system that can talk N protocols can do so now. True, but they have N times the adminstrative cost. I suppose you gain something in the host but it seems to me that Internet history shows that generally simplicity triumphs over complexity. And simplifying their administration would encourage them to use IPng. I think that this is a very important carrot in getting people to migrate. Tony From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 12:49:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB12152; Tue, 5 Apr 1994 11:17:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA05393; Tue, 5 Apr 1994 11:16:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA05379; Tue, 5 Apr 1994 10:58:31 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23295; Tue, 5 Apr 1994 02:30:08 +1000 (from yakov@watson.ibm.com) Message-Id: <9404041630.23295@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7195; Mon, 04 Apr 94 12:27:28 EDT Date: Mon, 4 Apr 94 12:27:28 EDT To: jmh@anubis.network.com, big-internet@munnari.OZ.AU Subject: Turnipp - a merger proposal Ref: Your note of Mon, 4 Apr 94 10:16:07 CDT Joel, >Yakov asked what was wrong with the base list... >I think that "what is wrong" is the wrong question. I don't see anything "wrong" with "what is wrong" question. Answering it would help to incrementally improve the existing technology without resorting to wholesale replacement. >If we are asking about routing for the future, we should be asking >"would it be better to use...", rather that "what is wrong with >the tool we have ?" Asking "would it be better to use..." question is fine. But the answer should be supported by solid empirical (operational) evidences. >The tool(s) we have are very nice. Thanks. >But there is a good chance we can build better ones. Provided that there is a market demand for the "better ones"... >we ... should actively inquire as to whether we can build better >mousetraps. while at the same time stay away from creating a "solution looking for a problem".... Yakov. From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 13:59:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18353; Tue, 5 Apr 1994 13:59:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA05660; Tue, 5 Apr 1994 13:56:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA05644; Tue, 5 Apr 1994 13:48:53 +1000 From: bound@zk3.dec.com Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB17938; Tue, 5 Apr 1994 13:50:03 +1000 (from bound@zk3.dec.com) Received: by crl.dec.com; id AA29029; Mon, 4 Apr 94 23:47:33 -0400 Received: by xirtlu.zk3.dec.com; id AA21129; Mon, 4 Apr 1994 23:43:47 -0400 Message-Id: <9404050343.AA21129@xirtlu.zk3.dec.com> To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Cc: bound@zk3.dec.com, Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of "Sun, 03 Apr 94 09:05:30 PDT." Date: Mon, 04 Apr 94 23:43:40 -0400 X-Mts: smtp Dave, >Since one of the suggestions I made at the Friday open directorate was to >find a way to make sure that the final pronouncement from the directorate >come as no surprise to the community, I think some public discussion of >details could be helpful. Since you've been working on implementation, >you're in a better than average position of offer some of that detail... Yes I can and have been. The problem is we are dealing with very strong technical proposals and proponents. None are wrong and I could probably make any of them work on a host. But, I have learned this past year a lot more about routing and looking at that on a host and it has its own discipline that is very delicate to changes even more than the host software I am more familiar with as an engineer. I have also learned that altering the Internet's critical technical pieces needs to go through much iteration so the present network paradigm for the Internet gets better and not worse. The question (using object oriented terms) is what are the constructors to build the object IPng, which then needs to be iterated on this and other mail lists (the LOOP). In addition one of our IPng team members has intense hard core TCP/IP host experience on a network operating system host (in the bowels) and he is scratching his head and I am pulling my hair out at times in front of my workstation. So the best thing to do is try to keep on a path you believe in as an engineer, architect, network manager, or standards expert and keep raising your points with the community. Thats what I have come up with after 1 year in the IETF. I will add that this is not really different from my previous IEEE POSIX and MAP/TOP standards involvement, except more people dress and wear clothes like me so it seems more friendly to me and I have more in common with these folks it appears. >At 5:35 AM, bound@zk3.dec.com wrote: >> I don't think the SIPP >> transition completely is the the best answer and a dual stack >> approach has many unanswered questions regarding the assumptions >> about how customers will deploy IPng at their pace. >It will may be that I've missed them, but are the deficiencies and >unaswered questions documented somewhere? I would wish that the >directorate would take it as an action item to deliver such queries and >preliminary judgements about pieces, real soon, to give the contenders time >to respond. Not sure but I think you read more into my sentence than I stated. I never above used the word deficiencies? SIPP Transition, TUBA Transition, or Rob's belief regarding Transition per CATNIP are not deficient at all. The issue and real debate are the choices they made regarding technology transition. Likewise the choices that will be made if a dual stack is selected and only a dual stack approach, what choices have been made and will they work to transition IPv4 to IPng or make folks want to use IPng. >I think the >> answer is a hybrid of dual stack and IPv4 compatible addresses for >> tunneling. >An herein lies a heckofalotof confusion for me. IPAE consists of a several >transition techniques, two of which are dual stack and IPv4 compatible >addresses for tunneling. I gather you don't see it that way and would be >interested in some clarification. Yes to manys surprise SIPP Transition (I don't want to use the word IPAE until its re-defined by the SIPP WG or I give up) does support a dual stack (another term I don't like for IPng )--> its a great term for OSI, TCP/IP, and IPX stacks on our servers). The IPAE mechanisms (the right way to use the term in my opinion) in SIPP for Transition I admit to me are very much to my liking as an engineer and one who has worked with customers too. But it will require translation in the host in some cases to achieve my model previously portrayed. Its that point in the strategy where the SIPP group is working presently and I have some debate as to its implementation regarding performance and what is called cohesiveness with locality of design. In non computer science terms that means the points where the code must be 'special case' are often and the code path cannot be part of normal flow from datalink to the transport layer. This is the advantage of a pure dual stack. I think it can work but need more time to think and play with the idea of IPv4 compatible addresses being supported by what I like to call an Integrated Network Layer (INL). CATNIP has done a real good job of defining an interface to an INL that comes in via hybrid stacks (IPX, IP, CLNP, SIPP, others if you need). But they come in as multiple stacks. What I like is the idea of demuxing on the version (for IPng) and heading for the right set of modules as required by the version being handled. When possible this permits me to reuse (software reuse) modules I can develop as network objects common to a protocol architecture or suite. It keeps me away from being stack focused, layer focused, or protocol focused except at what we call the network layer. Though I don't believe IPng's objective is to solve the multiprotocol problem I would like to implement it in products I will work on with a multiprotocol software engineering strategy. The two efforts should not be mutually exclusive by an implementation. The excellent feature in the dual stack strategy is that it is very possbile to mimmize translation except at points in the network where complete IPng domains have been created, until IPv4 addresses run out. There are several others but I think we all know them. /jim Dave From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 14:20:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12765; Tue, 5 Apr 1994 11:38:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA05423; Tue, 5 Apr 1994 11:36:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA05420; Tue, 5 Apr 1994 11:25:39 +1000 Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27401; Tue, 5 Apr 1994 04:22:44 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA01791; Mon, 4 Apr 94 11:16:07 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA25665; Mon, 4 Apr 1994 14:17:35 -0400 Message-Id: <9404041817.AA25665@skidrow.lkg.dec.com> To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Sat, 02 Apr 94 00:01:23 PST." <199404020801.AAA01820@lager.cisco.com> Date: Mon, 04 Apr 94 14:17:35 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp My first reaction to this is, if its going to have that many different forms of variable and fixed length addresses and addressing options, what's the point? After all, people who want a system that can talk N protocols can do so now. A router that could handle this mess seems hardley simpler than a router that could handle them all seperately (which it would probably also be able to do as there would be little additional effort). I suppose you gain something in the host but it seems to me that Internet history shows that generally simplicity triumphs over complexity. Maybe if this were adopted, people would write simplified implementation that just threw away packets where the addressing krud didn't match the type they felt comfortable with. Donald From: Tony Li To: big-internet@munnari.oz.au > >Folks, > >After today's open meeting of the IPng directorate, I felt it was only fair >if I was an actor for unification amongst the proposals. Attached is a >strawman of a merger proposal. > >Tony > > TURNIPP - A merger proposal > >Turnipp is a merger proposal, combining the best parts of SIPP, TUBA, and >CATNIP. > >... From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 14:30:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14365; Tue, 5 Apr 1994 12:18:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA05489; Tue, 5 Apr 1994 12:16:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA05472; Tue, 5 Apr 1994 12:08:22 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05892; Tue, 5 Apr 1994 08:26:19 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id PAA13923; Mon, 4 Apr 1994 15:26:07 -0700 Date: Mon, 4 Apr 1994 15:26:07 -0700 From: Tony Li Message-Id: <199404042226.PAA13923@lager.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal As far as I can see, one of two things is true: i) Nimrod is more the right thing than other alternatives, in which case I think that will slowly become clear to all, and no big political fight is needed, or ii) it's not the right thing, in which case using various manoeuverings of the form labelled as "politics" to get it adopted would not be in the Internet's long term interest. Further, there's no point in fighting about it now, as long as the IPng selection can be reasonably routed using Nimrod. This needs to be your focus, Noel. I hope the proponents of other alternatives are working from the same basic concept, yes? Anyway, within that concept, I think we could have useful technical debates about the merits of the two approaches, as long as we keep them technical. However, that's a separate debate from the one over TURNIPP as a whole. Having said that, would people like to hear the two approaches discussed? While I appreciate and would like to participate in the debate at some future time, I'm would like to forgo the discussion for the sake of simply concentrating on getting a network layer that sorta works with today's tools. I'll temporarily stipulate that Nimrod is a good idea and I would not want to exclude it. Does Turnipp/SIPP/TUBA/CATNIP provide you with all of the appropriate hooks for Nimrod style routing? Tony From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 14:43:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14571; Tue, 5 Apr 1994 12:23:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA05504; Tue, 5 Apr 1994 12:22:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA05475; Tue, 5 Apr 1994 12:09:48 +1000 From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05575; Tue, 5 Apr 1994 08:17:21 +1000 (from jcjones@MIT.EDU) Received: from M16-034-12.MIT.EDU by MIT.EDU with SMTP id AA21667; Mon, 4 Apr 94 18:15:20 EDT Received: by m16-034-12.MIT.EDU (AIX 3.2/UCB 5.64/4.7) id AA13452; Mon, 4 Apr 1994 18:15:19 -0400 Message-Id: <9404042215.AA13452@m16-034-12.MIT.EDU> To: Big-Internet@munnari.OZ.AU Subject: IPng Requirements Date: Mon, 04 Apr 94 18:15:19 EDT Hello, again. A few days ago, I wrote a message beginning: ********** I HAVE THE SOLUTION TO THE INTERNET PROBLEM ********** I'd like to say a couple of things about that message. First of all, I was not joking. I wrote that message in earnest. The fact that it was written just before April 1 was just a coincidence. Second, I think that I may have offended a *few* people. I did not mean to offend anyone or imply that anyone involved in networking is stupid. On the the contrary, I happen to think highly of the people whom I've spoken with so far, like John Curran of BBN. I apologize to those who felt trodded upon, and I'll try to be more sensitive in the future. :-) Third, I said that a proposal was on the way. This still holds. Unfortunately, I won't be able to provide running code, but many people have assured me that the proposal itself will be sufficient. In the meantime, I would appreciate it if anyone could direct me to a comprehensive list of IPng proposal requirements, or if none exists, perhaps someone could augment/modify the following list: 1. Virtually unlimited address space (toasters get their fair share) 2. Low routing overhead (in terms of computation power and memory) 3. Simple network management 4. Mobility 5. Simple means of making the transition/compatibility 6. Quality of Service mechanism 7. Security (This will be included at a different level of my protocol stack. If anyone feels strongly that security should be in the network layer, then please let me know soon.) *. Provider Selection (What is this exactly? Why do people want it?) Am I allowed to let my packet header size to get arbitrarily large? Thank you for your support, and thank you, Andrew Myles, in advance, for letting me use your biographical information template. J.C. Jones -------------------------------------------------------------------------- In-Real-Life: John Christopher Jones E-Mail: jcjones@athena.mit.edu Organization: Senior in Electrical Engineering Massachusetts Institute of Technology Telephone: (617) 494-1034 (home) Feel free to call any time you please. I'm usually awake. From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 15:06:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16593; Tue, 5 Apr 1994 13:15:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA05594; Tue, 5 Apr 1994 13:12:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA05532; Tue, 5 Apr 1994 12:37:41 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08860; Tue, 5 Apr 1994 09:44:30 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17664 for big-internet@munnari.oz.au; Mon, 4 Apr 94 19:42:22 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id QAA10126; Mon, 4 Apr 1994 16:39:16 -0700 Message-Id: <199404042339.QAA10126@aland.bbn.com> To: Tony Li Cc: Jon Crowcroft , big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Mon, 04 Apr 94 15:50:48 -0700. <199404042250.PAA15249@lager.cisco.com> From: Craig Partridge Date: Mon, 04 Apr 94 16:39:14 -0700 Sender: craig@aland.bbn.com Hi Tony: - For our hardware, the amount of overhead is, to a first order, the number of bytes that I have to read to make the routing decision -- and SIPP is not significantly different from CLNP. I do my estimates not on bytes, but on power of two bytes (e.g., what is n, such than 2**n bytes always captures all of the header I care about in the usual case -> i.e., no options). This is because many processors have cache line loading schemes that mean the key unit of data is a cache line (which is typically a power of 2 count of bytes wide). For IPv4, n=5 (32 bytes captures the 20 byte IP header). For SIPP, n is again 5 (32 bytes captures the 24 byte SIPP header). For CLNP, n is 6 (64 bytes, to accomodate the up to 51 bytes of header -- tell me if I'm misreading the CLNP spec when I say 51 bytes -- as I read the header layout there's 9 bytes of fixed, plus 1 byte per address, plus up to 20 bytes of address, for 51 bytes). Of course, this isn't the full story. If one adds a TCP or UDP header on to do packet filtering (or to do real-time service classification using headers instead of flow ids), then the numbers get a bit more interesting: n n/TCP header n/UDP header IPv4 5 6 5 SIPP 5 6 5 CLNP 6 7 6 Note that with flow ids, n for SIPP is 5, while n for CLNP (if it doesn't have flow ids) might be as high as 7, which suggests (since we're working in powers of 2), that CLNP could have either the same number of memory access (if the cache line is 128 bytes) or have 4 times as many cache line accesses (if the cache line is 32 bytes). The latter number worries me, since the number of instructions to be done is typically so small that the processor is almost certainly memory bound (and thus the 4 extra accesses are a real performance killer). - The second order approximation takes into account the placement of the fields within the header. In the case of SIPP, things are pretty much pessimally laid out for us. Consider the case where you actually have to route on the flow. Why is it pessimal? From my perspective, if one's playing with a cache architecture, I can see that if the cache line loads in two cycles (e.g., the DEC Alpha) one might prefer the flow id to be in the same cycle as the destination address. Is that the concern? (Otherwise, if it all comes in during one cache load, who cares where the data is laid out?). Note that most of the above entail changing CLNP to work efficiently....if we (ietf) change CLNP, then where is the a) ownership b) gain in legacy CLNP s/w, and therefore c) why not just change to a fully owned optimised protocol...? I know of nothing that's currently proposing changes to CLNP. Well, the question has been raised about whether CLNP needs flow ids (for reasons like those I sketched above). I've hypothesized that one could stuff the flow ID into one of the addresses (there are potentially extra bytes there). But I haven't heard anyone seriously address the question of how CLNP handles packet classification efficiently. Thanks! Craig From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 15:08:13 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17822; Tue, 5 Apr 1994 13:46:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17445 Tue, 5 Apr 1994 13:01:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA05568; Tue, 5 Apr 1994 12:56:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA05535; Tue, 5 Apr 1994 12:39:33 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10087; Tue, 5 Apr 1994 10:20:05 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id RAA20332; Mon, 4 Apr 1994 17:16:38 -0700 Date: Mon, 4 Apr 1994 17:16:38 -0700 From: Tony Li Message-Id: <199404050016.RAA20332@lager.cisco.com> To: craig@aland.bbn.com Cc: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU In-Reply-To: Craig Partridge's message of Mon, 04 Apr 94 16:39:14 -0700 <199404042339.QAA10126@aland.bbn.com> Subject: Costs, Performance and IPng From: Craig Partridge First, I'm not convinced that this entire approach is of great value. The architectures that you're describing are not the current high end hardware. If you want to optimize for low end hardware, we should be discussing the 486. ;-( For CLNP, n is 6 (64 bytes, to accomodate the up to 51 bytes of header -- tell me if I'm misreading the CLNP spec when I say 51 bytes -- as I read the header layout there's 9 bytes of fixed, plus 1 byte per address, plus up to 20 bytes of address, for 51 bytes). You're ignoring the segmentation and global QOS, which you have to read so you can verify the header checksum. Of course, this isn't the full story. If one adds a TCP or UDP header on to do packet filtering (or to do real-time service classification using headers instead of flow ids), then the numbers get a bit more interesting: This seems silly, tho. If you have a flow id, why not use it? SIPP certainly seems to have one. If you'll allow me to add to your chart: n n/TCP header n/UDP header flowid check IPv4 5 6 5 6 SIPP 5 6 5 5 CLNP 6 7 6 7 Turnipp 4 6 5 4 - The second order approximation takes into account the placement of the fields within the header. In the case of SIPP, things are pretty much pessimally laid out for us. Consider the case where you actually have to route on the flow. Why is it pessimal? Well, I can't go into that just yet. Let's suffice it to say that the hardware that I'm using doesn't like it. Note that most of the above entail changing CLNP to work efficiently....if we (ietf) change CLNP, then where is the a) ownership b) gain in legacy CLNP s/w, and therefore c) why not just change to a fully owned optimised protocol...? I know of nothing that's currently proposing changes to CLNP. Well, the question has been raised about whether CLNP needs flow ids (for reasons like those I sketched above). I've hypothesized that one could stuff the flow ID into one of the addresses (there are potentially extra bytes there). But I haven't heard anyone seriously address the question of how CLNP handles packet classification efficiently. Ross proposed a very nice and efficient mechanism for doing flow ids with CLNP. Just consider the source and destination address (with NSELs) to be the flow id. The obvious problem is that it's not enough granularity. Tony From owner-Big-Internet@munnari.OZ.AU Tue Apr 5 18:39:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22404; Tue, 5 Apr 1994 15:58:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA05778; Tue, 5 Apr 1994 15:56:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA05753; Tue, 5 Apr 1994 15:39:56 +1000 From: bound@zk3.dec.com Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19668; Tue, 5 Apr 1994 14:37:31 +1000 (from bound@zk3.dec.com) Received: by crl.dec.com; id AA03370; Tue, 5 Apr 94 00:34:33 -0400 Received: by xirtlu.zk3.dec.com; id AA21347; Tue, 5 Apr 1994 00:29:54 -0400 Message-Id: <9404050429.AA21347@xirtlu.zk3.dec.com> To: Tony Li Cc: craig@aland.bbn.com, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Mon, 04 Apr 94 17:16:38 PDT." <199404050016.RAA20332@lager.cisco.com> Date: Tue, 05 Apr 94 00:29:48 -0400 X-Mts: smtp Just a thought about flows: 1. It will be very possible for high-end servers ( greater than 586 single processor) to have a need to to support greater than 255 flows as multi-process identical source addr/dst addr for transaction processing, database server distributed processing, commercial online data feeds, or engineering finite element analysis parts on an engineering workstations; between cooperating machines. 2. Flows could also be used for distributed virtual memory between workstations as a reservation service among cooperating hosts. The point is that flows on a host can have many functions. My guess is the first users to use them will be Discrete Manufacturing processes for engineering departments and the commercial and retail technical communities. In addition to networkanagers and routing focused technology. /jim From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 03:57:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16882; Wed, 6 Apr 1994 03:57:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA06551; Wed, 6 Apr 1994 03:56:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA06529; Wed, 6 Apr 1994 03:52:02 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10474; Wed, 6 Apr 1994 00:57:00 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA21651; Tue, 5 Apr 94 10:49:40 EDT Message-Id: <9404051449.AA21651@tipper.oit.unc.edu> To: bound@zk3.dec.com Cc: Tony Li , craig@aland.bbn.com, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Tue, 05 Apr 94 00:29:48 EDT." <9404050429.AA21347@xirtlu.zk3.dec.com> Date: Tue, 05 Apr 94 10:49:39 -0400 From: Simon E Spero >>>>> "jim" == bound writes: jim> Just a thought about flows: 1. It will be very possible for jim> high-end servers ( greater than 586 single processor) to have jim> a need to to support greater than 255 flows as multi-process jim> identical source addr/dst addr for transaction processing, The number of cases to which this applies depends very much on the cost of flow set up- if the win point is low enough, then most tcp connections will be going over flows, and 255 will not be nearly enough (imagine a big client site like "Son Of Delphi", connecting to a big server like "Son of Sunsite". The answer, of course, is to make flow set up expensive enough to keep the number of flows in existence limited to ultra-hard real time applications each using >1/255 of the bandwidth of the narrowest point in the path From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 04:02:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10502; Wed, 6 Apr 1994 00:57:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA06248; Wed, 6 Apr 1994 00:56:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA06234; Wed, 6 Apr 1994 00:40:55 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02684; Tue, 5 Apr 1994 20:51:37 +1000 (from Z.Wang@cs.ucl.ac.uk) Message-Id: <9404051051.2684@munnari.oz.au> Received: from reeves.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 5 Apr 1994 11:49:39 +0100 To: Scott W Brim Cc: big-internet@munnari.OZ.AU Subject: Re: connecting toasters etc. In-Reply-To: Your message of "Sun, 03 Apr 94 22:27:39 CDT." <199404040227.WAA20942@postoffice3.mail.cornell.edu> Date: Tue, 05 Apr 94 11:49:37 +0100 From: Zheng Wang >Folks, Friday morning at IPng meeting a big deal was made of how the >Internet is going to have to reach whole new classes of things in the >near future. I just want to repeat that while we would like to have a >single, pervasive, universal internet protocol suite, it is not >necessary to have one for the Internet to work -- and that's our only >real goal. As was discussed last year on this list (I think it was >this list), you don't need to talk directly to a refrigerator if you >can communicate effectively using the house as an intermediary, and >decoupling these two steps may allow more rapid adaptation in both sets >of protocols. Having a universal suite of protocols can be a goal but >it does not need to be a fundamental requirement for IPng, as long as >effective universal communication is possible somehow. You may use the same set of protocols but in different domains: a world-wide public Internet and billions of small company-wide or house-wide private internets. Telephone networks seem to work well in this model. Cheers Zheng From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 04:39:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18421; Wed, 6 Apr 1994 04:39:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA06642; Wed, 6 Apr 1994 04:37:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA06622; Wed, 6 Apr 1994 04:33:29 +1000 Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18133; Wed, 6 Apr 1994 04:34:36 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA01071; Tue, 5 Apr 94 14:11:27 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA06940; Tue, 5 Apr 94 14:22:35 EDT Date: Tue, 5 Apr 94 14:22:35 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404051822.AA06940@pobox.wellfleet> To: bound@zk3.dec.com, tli@cisco.com Subject: Re: Costs, Performance and IPng Cc: big-internet@munnari.OZ.AU Just a thought about flows: 1. It will be very possible for high-end servers ( greater than 586 single processor) to have a need to to support greater than 255 flows as multi-process identical source addr/dst addr for transaction processing, database server distributed processing, commercial online data feeds, or engineering finite element analysis parts on an engineering workstations; between cooperating machines. Jim; I think that we need to distinguish the flows as are understood by the network layer (particularly for reserving resources in routers, and in subnets), versus multiple transport-user-to-transport-user flows. I agree that a very large number of transport-user level flows may be necessary between the same two hosts. However, this does not necessarily mean that thousands of distinguishable flows between the same two hosts have to be understood by routers and subnets. Flows might need to be distinguished at the network layer if either of the two following statements are true: (i) they need significantly different qualities of service; (ii) they need to be kept separate to prevent one from stealing resources from the other. Actually, if the transport layer multiplexes multiple transport-user flows onto one network layer flow, and if the transport layer knows what level of service it has requested and is receiving from the network layer, then the transport level multiplexing should be able to prevent one transport user from stealing too many resources. This implies that different network layer flows are needed between the same two hosts only in order to distinguish measureably different quality of service. So, how many different qualities of service is there likely to be? I have another problem with the idea of thousands of distinguishable flows at the network layer between the same two hosts: The network layer has to keep track of them (if the network layer does not need to keep track of each flow individually, then you don't need to distinguish packets in the network layer headers). If you have several thousand distinguishable flows between two particular hosts, then how many flows total will you need each router to keep track of between all hosts? Are you thinking of each router keeping track of a few million distinguishable flows? How much state will the routers maintain (and how much do you expect your routers to cost)? Thus I think that when your high-end servers are talking to each other, they will need to multiplex multiple transport-user-level flows onto a much smaller number of network layer flows. I don't think that you need thousands of flows between the same two hosts individually identified in network layer headers. Ross From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 05:37:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20298; Wed, 6 Apr 1994 05:37:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA06752; Wed, 6 Apr 1994 05:36:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA06742; Wed, 6 Apr 1994 05:25:53 +1000 Received: from gw1.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19830; Wed, 6 Apr 1994 05:27:01 +1000 (from gfw@qsun.att.com) Received: by emsr0.emsr.att.com (4.1/EMS main.cf 1.33 7/21/93 (SMI-4.1/SVR4)) id AA27109; Tue, 5 Apr 94 15:28:05 EDT Received: from hogpa.ho.att.com by emsr0.emsr.att.com (4.1/EMS main.cf 1.33 7/21/93 (SMI-4.1/SVR4)) id AA27099; Tue, 5 Apr 94 15:28:02 EDT Received: from snipe.ho.att.com by hogpa.ho.att.com (4.1/EMS-1.0.2 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA20897; Tue, 5 Apr 94 15:26:51 EDT Message-Id: Date: Tue, 5 Apr 94 15:25:23 +0100 From: "Greg Wetzel, +1 908 949 6630" Subject: Re: Costs, Performance and IPng Reply-To: G_F_Wetzel@att.com To: "Lyman Chapin" Cc: big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.3 Lyman, The answer to at least part of your question is contained within your (rhetorical) answer: >.... The question is whether it is necessary >to be able to assign each of these distinct channels to *a separate flow* >(identified by separate flow ids), so that the discrimination among the >channels is performed by the flow id. An alternative is for the hosts >to multiplex and demultiplex so that, if necessary, more than one distinct >traffic channel could be sent using the same flow id (that is, "on the same >flow"). Since each flow is established with a particular set of character- >istics (secured during flow setup by some sort of resource reservation >mechanism) If, as you point out, each flow has used a resource reservation mechanism to set up a flow, is it reasonable to assume that other channels could be added to that flow without renegotiating the resource reservation? If not, then you're forced to equate channels and flows (unless you do such things as oversubscribe initially in anticipation, which would be wasteful at least part of the time). Greg Wetzel G_F_Wetzel@att.com +1 908 949 6630 (voice) +1 908 949 4673 (fax) AT&T Bell Laboratories Room 1K-601 P.O. Box 3030 101 Crawfords Corner Road Holmdel, NJ 07733-3030 From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 05:39:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20341; Wed, 6 Apr 1994 05:39:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA06767; Wed, 6 Apr 1994 05:37:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA06745; Wed, 6 Apr 1994 05:26:11 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14639; Wed, 6 Apr 1994 03:05:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08863; Tue, 5 Apr 94 13:05:19 -0400 Date: Tue, 5 Apr 94 13:05:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404051705.AA08863@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: How to create and maintain state in a packet network Cc: jnc@ginger.lcs.mit.edu > Anyway, back to the question is how the state gets into the routers. [...school 1) all state in every packet...] [....subschool 1a) dedicated field in packet as hint to state cache...] [....subschool 1b) combine existing fields as hint...] [...school 2) install state in routers, key in packet to find state...] > I'm not sure how much use there is to any intermediate position. It seems to me that there is an intermediate position worth exploring. Have a hint in the packet ... and have the initial packet contain the state as an option ... Since it is a hint the router could discard it based on whatever criteria ... It seems to me you would want a way for a router to request the hint again... We're suffering from a bit of terminology failure here, but underneath it is the fact that the mental framework I suggested is not yet right. I think I've got it somewhat better this time, though... (As I understood it, the whole concept of a hint is that it is a tag for "user state" which may be cached in the router, but which is repeated in every packet [or perhaps every Nth, for efficiency]. However, let's skip that for now, and try and understand what's really going on.) I think what we ought to start with is thinking about the state, and work back from that to tags. When seen this way around, it becomes a little clearer in my mind. - First, user state is divided into two classes; critical (such as destination addresses), without which the packets cannot be forwarded at all, and non- critical (such as a resource allocation class), without which the packets can still be forwarded, just not quite in the way the user would most prefer. - Second, there are a range of mechanisms for getting this user state to routers; it may be put in every packet, or placed there by a setup (and then you have a whole range of possibilities for how to get it back when you lose it, such as placed in every Nth packet); a whole range of mechanisms. - To the extent that state is stored in the routers, you need some way to find it; the fields in the packets that allow you to do this are the tags. However, depending on whether the state is critical user state or not, and how that state is installed in routers, we have a plethora of names (and usually overlapping definitions :-) for the state itself, how it gets there, and the tags that allow you to find it: soft state, cached state, hints, etc. These definition are often related to a particular mechanism, not to what's really going on at a fundamental level. As an example, let's look at "soft state", which was defined to me as "state that the router is allowed to delete without an explicit deletion request". However, isn't not clear whether this is allowed because i) this is non- critical user state, without which the packet can still be forwarded, or ii) it is critical user state, but there's some mechanism (e.g. there's a copy in every packet) to reload it when needed. Don't get me wrong, it's a very useful mechanism definition, but the fact that it refers to two very different underlying cases can be confusing! I would suggest that things will be clearer if, when looking at a given model for the operation of the internetworking layer, we always ask the following three questions: - how critical is a given piece of user state to forwarding the packet - how does it get to the router - what do you use to find it if it's already in the router I find that if I answer these three questions, I usually have a clear vision of what's going on with any suggested scheme. Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 07:29:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17533; Wed, 6 Apr 1994 04:17:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA06590; Wed, 6 Apr 1994 04:16:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA06569; Wed, 6 Apr 1994 04:01:55 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10511; Wed, 6 Apr 1994 00:57:58 +1000 (from lyman@BBN.COM) Message-Id: <9404051457.10511@munnari.oz.au> From: Lyman Chapin Subject: Re: Costs, Performance and IPng To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU, craig:;, J.Crowcroft@cs.ucl.ac.uk, tli@cisco.com In-Reply-To: <9404050429.AA21347@xirtlu.zk3.dec.com> Date: Tue, 5 Apr 94 10:43:42 EDT Mail-System-Version: >From: bound@zk3.dec.com >To: Tony Li >Cc: craig@aland.bbn.com, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au, > bound@zk3.dec.com >Subject: Re: Costs, Performance and IPng >Date: Tue, 05 Apr 94 00:29:48 -0400 > >Just a thought about flows: > >1. It will be very possible for high-end servers ( greater than 586 >single processor) to have a need to to support greater than 255 flows >as multi-process identical source addr/dst addr for transaction >processing, database server distributed processing, commercial online >data feeds, or engineering finite element analysis parts on an >engineering workstations; between cooperating machines. Jim, This raises again a point that was missed (to Ross's evident frustration!) during the WG meeting. The question is not whether there could be more than 255 distinct simultaneous traffic channels (to avoid using the term "flow") between the same pair of source and destination addresses; clearly there could be (as you point out). The question is whether it is necessary to be able to assign each of these distinct channels to *a separate flow* (identified by separate flow ids), so that the discrimination among the channels is performed by the flow id. An alternative is for the hosts to multiplex and demultiplex so that, if necessary, more than one distinct traffic channel could be sent using the same flow id (that is, "on the same flow"). Since each flow is established with a particular set of character- istics (secured during flow setup by some sort of resource reservation mechanism), the question then becomes whether or not there is a need to specify more than 255 different sets of characteristics for the traffic that is passing between a pair of source and destination addresses at a given time. Note that I don't assume that the answer to the "must each distinct traffic channel be assigned to a distinct flow" is "no" - it might be "yes", in which case the first and last questions above are indeed equivalent. But I strongly suspect that the answer is "no". Of course, I'm also inclined to believe that if you wait long enough, you will eventually have more than 255 of almost *anything*.... - Lyman > >2. Flows could also be used for distributed virtual memory between >workstations as a reservation service among cooperating hosts. > >The point is that flows on a host can have many functions. My guess is >the first users to use them will be Discrete Manufacturing processes for >engineering departments and the commercial and retail technical >communities. In addition to networkanagers and routing focused >technology. > >/jim From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 07:29:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18394; Wed, 6 Apr 1994 04:37:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA06627; Wed, 6 Apr 1994 04:36:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA06619; Wed, 6 Apr 1994 04:28:53 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12575; Wed, 6 Apr 1994 02:05:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08212; Tue, 5 Apr 94 12:04:53 -0400 Date: Tue, 5 Apr 94 12:04:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404051604.AA08212@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: A taxonomy of state and tags in datagram networks Cc: jnc@ginger.lcs.mit.edu A side conversation with Jon Crowcroft has pointed out that the definitions of "keys" and "hints", the non-overlapping subsets into which the set of "tags" (which are fields which are used, in the routers through which the packet passes, to look up various state stored in the routers) is divided is a little fuzzy. My original definition went: A key is a field without which, or without the state in the router to which it refers, one cannot forward the packet; the "address" is such a field in IPv4. A hint is a field which is not necessary for the forwarding of the packet, but which makes the forwarding more efficient if the hint is correct, and the state in the router to which it refers is present. (It's worth pointing out that this definition of "key" doesn't say anything about how that state got installed, or how it gets replaced if it's lost. For example, you might have a copy in every other packet, or it might be setup, or whatever. What's critical is that without the key and the state, you can't forward the packet. Also, if I understand the concept of hint correctly, they just increase the efficiency, they don't change the abstract service provided.) However, this definition doesn't deal well with cases where you can still forward the packet, but just not "correctly". For example, if the tag leads you to some resource allocation state, you might still be able to forward the packet, just not as part of the resource class it ought to be in. Is this a key or a hint? It doesn't seem like either, so there's a third class of stuff there... Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 07:52:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18953; Wed, 6 Apr 1994 05:00:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA06693; Wed, 6 Apr 1994 04:56:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA06679; Wed, 6 Apr 1994 04:51:49 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18854; Wed, 6 Apr 1994 04:53:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10489; Tue, 5 Apr 94 14:52:56 -0400 Date: Tue, 5 Apr 94 14:52:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404051852.AA10489@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal Cc: jnc@ginger.lcs.mit.edu > I think we could have useful technical debates about the merits of the > two approaches [to routing architectures]... However, that's a separate > debate ... Having said that, would people like to hear the two > approaches discussed? While I appreciate and would like to participate in the debate at some future time, I'm would like to forgo the discussion for the sake of simply concentrating on getting a network layer that sorta works with today's tools. Well, we've got that; it's called IPv4. However, when we start making changes, I for one would like to have some idea of where we intend to wind up. I fully understand that the day-to-day stuff seems more pressing, and usually is. However, it's easy to day-to-day yourself into a corner (and I've done it many a time... :-) So, now's not a good time, sure, but we can't blow it off forever. I'll temporarily stipulate that Nimrod is a good idea and I would not want to exclude it. Does Turnipp/SIPP/TUBA/CATNIP provide you with all of the appropriate hooks for Nimrod style routing? This question does not have a yes/no answer, since all the ones you name (and IPv4 besides) are extensible protocols. You also need to disinguish between the host-router part of the path, and the router-router part; a format that works OK for one may not do for another. Finally, Nimrod currently has three planned forwarding modes (flows, datagram, and source-routed packets), and a format that works for one may not work for another. (SDRP has the same thing; source routed packets use the SDRP packet format, whereas datagram mode does not.) Do any of them have packet formats, off the shelf, that both i) provide all the information from the hosts that Nimrod routers would like to see, and ii) provide all the fields that Nimrod needs for all 3 currently planned forwarding modes? No. Can they all be extended to do so? Yes. The devil is in the details: how painful a change is it, how well do modified hosts interoperate with unmodified hosts, etc, etc, etc. I've been requested to send a brief list of Nimrod requirements, and will do so in a separate message. You can use that list to evaluate how difficult it would be, either by extensions, or changing the basic protocol, to make a given IPng candidate useful to Nimrod. Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 10:02:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23903; Wed, 6 Apr 1994 07:17:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA06879; Wed, 6 Apr 1994 07:16:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA06865; Wed, 6 Apr 1994 07:06:02 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16262; Wed, 6 Apr 1994 03:44:43 +1000 (from craig@aland.bbn.com) Received: from [38.145.107.9] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02730 Wed, 6 Apr 1994 03:38:12 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu9.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AB11230 for big-internet@munnari.oz.au; Tue, 5 Apr 94 13:33:30 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA10805; Tue, 5 Apr 1994 10:28:52 -0700 Message-Id: <199404051728.KAA10805@aland.bbn.com> To: Tony Li Cc: craig@aland.bbn.com, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Mon, 04 Apr 94 17:16:38 -0700. <199404050016.RAA20332@lager.cisco.com> From: Craig Partridge Date: Tue, 05 Apr 94 10:28:51 -0700 Sender: craig@aland.bbn.com First, I'm not convinced that this entire approach is of great value. The architectures that you're describing are not the current high end hardware. If you want to optimize for low end hardware, we should be discussing the 486. ;-( Well, I was focussing on the latest fast processors (Alphas, MIPS, Sparcs). These tend to be the type of thing found in networking equipment (good performance/price bounds). If there's another processor base to consider, great, let's add it in. Just give me a list. Of course, this isn't the full story. If one adds a TCP or UDP header o n to do packet filtering (or to do real-time service classification using hea ders instead of flow ids), then the numbers get a bit more interesting: This seems silly, tho. If you have a flow id, why not use it? SIPP certainly seems to have one. If you'll allow me to add to your chart: The point is that some protocols have flow ids (in which case you use them), and some proposals don't. For instance, IPv4 will not have flow ids but rather examine transport headers. Well, I can't go into that just yet. Let's suffice it to say that the hardware that I'm using doesn't like it. Well that's a difficult requirement to deal with, since the hardware other folks (like me) are looking at for experimental platforms like the layout just fine. It is hard to have a rational conversation about performance tradeoffs on equipment that can't be described. Ross proposed a very nice and efficient mechanism for doing flow ids with CLNP. Just consider the source and destination address (with NSELs) to be the flow id. The obvious problem is that it's not enough granularity. How does this work for multicasting, where multiple sources may share a multicast flow? Craig From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 10:24:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25809; Wed, 6 Apr 1994 08:18:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA06953; Wed, 6 Apr 1994 08:16:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA06936; Wed, 6 Apr 1994 08:00:05 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25330; Wed, 6 Apr 1994 08:01:18 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA20227 for big-internet@munnari.oz.au; Tue, 5 Apr 94 18:00:37 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id OAA11070; Tue, 5 Apr 1994 14:58:58 -0700 Message-Id: <199404052158.OAA11070@aland.bbn.com> To: Tony Li Cc: craig@aland.bbn.com, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Tue, 05 Apr 94 13:03:40 -0700. <199404052003.NAA15530@lager.cisco.com> From: Craig Partridge Date: Tue, 05 Apr 94 14:58:53 -0700 Sender: craig@aland.bbn.com Well, your numbers for SIPP don't reflect that you're using the flowid. Ah! Now I understand. The numbers were for two reasons: * firewall filtering (which most routers support now) * flows so yes, for flows, SIPP doesn't need TCP and UDP. But for firewalls, SIPP might. Sorry for the confusion. Craig From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 10:35:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25844; Wed, 6 Apr 1994 08:19:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA06968; Wed, 6 Apr 1994 08:18:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA06939; Wed, 6 Apr 1994 08:00:08 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21295; Wed, 6 Apr 1994 06:04:00 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id NAA15530; Tue, 5 Apr 1994 13:03:40 -0700 Date: Tue, 5 Apr 1994 13:03:40 -0700 From: Tony Li Message-Id: <199404052003.NAA15530@lager.cisco.com> To: craig@aland.bbn.com Cc: craig@aland.bbn.com, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU In-Reply-To: Craig Partridge's message of Tue, 05 Apr 94 10:28:51 -0700 <199404051728.KAA10805@aland.bbn.com> Subject: Costs, Performance and IPng Well, I was focussing on the latest fast processors (Alphas, MIPS, Sparcs). These tend to be the type of thing found in networking equipment (good performance/price bounds). If there's another processor base to consider, great, let's add it in. Just give me a list. Cisco Silicon Switch Processor. The point is that some protocols have flow ids (in which case you use them), and some proposals don't. For instance, IPv4 will not have flow ids but rather examine transport headers. Well, your numbers for SIPP don't reflect that you're using the flowid. Well, I can't go into that just yet. Let's suffice it to say that the hardware that I'm using doesn't like it. Well that's a difficult requirement to deal with, since the hardware other folks (like me) are looking at for experimental platforms like the layout just fine. It is hard to have a rational conversation about performance tradeoffs on equipment that can't be described. Understood. I'll be able to say more later... Tony From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 13:58:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08261; Wed, 6 Apr 1994 13:58:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA07304; Wed, 6 Apr 1994 13:56:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA07288; Wed, 6 Apr 1994 13:47:19 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07783; Wed, 6 Apr 1994 13:48:31 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.rmm3.merit.edu ([35.196.49.11]) by merit.edu (8.6.5/8.6.5) with SMTP id XAA11143 for ; Tue, 5 Apr 1994 23:48:16 -0400 Date: Tue, 5 Apr 94 23:37:11 GMT From: "William Allen Simpson" Message-Id: <2124.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Costs, Performance and IPng > flows. I agree that a very large number of transport-user level > flows may be necessary between the same two hosts. However, this > does not necessarily mean that thousands of distinguishable flows > between the same two hosts have to be understood by routers and > subnets. > Ross, you are making a mistake I also made a year or so ago. You assume that flows are between a pair of hosts. - Many (if not most) flows are likely to be from one host to many hosts. - Others are likely to be many hosts to many. So, the "broadband" internet needs to support far more than 255 flows per source host, if only to support the "500 channels and still nothing worth watching" model. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 14:34:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00154; Wed, 6 Apr 1994 10:19:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA07098; Wed, 6 Apr 1994 10:16:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA07084; Wed, 6 Apr 1994 10:05:16 +1000 Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25034; Wed, 6 Apr 1994 07:53:24 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03671; Tue, 5 Apr 94 17:35:27 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA10846; Tue, 5 Apr 94 17:46:35 EDT Date: Tue, 5 Apr 94 17:46:35 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404052146.AA10846@pobox.wellfleet> To: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: How to create and maintain state in a packet network - First, user state is divided into two classes; critical (such as destination addresses), without which the packets cannot be forwarded at all, and non- critical (such as a resource allocation class), without which the packets can still be forwarded, just not quite in the way the user would most prefer. I have been wondering whether this distinction will turn out to be useful. Let's suppose that the state allows the router to operate at a much higher performance level. In this case if the state is not there then packets might be discarded due to congestion. Similarly, suppose that the state causes the packets to go to the head of the queue, allowing them to receive the low delay that is required. Without the state the packet might arrive at the destination too late, and get discarded there anyway. Similarly, let's suppose that the user is watching a movie, and the requested flow could have a very large delay, but requires a very small delay variance. Thus once the movie starts the associated packets arrive at the destination with the right inter-packet delay, allowing small buffers in the receiver. If loss of state causes the right packets to show up at the correct destination, but with a large delay variation, then the lack of buffering at the destination might cause the packets either to be lost or might cause the resulting application to be unacceptable. Thus, state might be required even if the lack of the state would allow the packets in principle to still be forwarded to the right place. Thus my congecture: There will be some sorts of state that are pretty useless and we don't want to bother with. There will be other types of state that are needed to get the packets to the correct destination at all (ie, critical state). There will be still other kinds of state which is not necessary in order to cause the packets to get to the correct destination, but which are necessary in order for the network as a whole to offer an acceptable level of performance (also critical state). I question whether there will be such a thing as "optional state", which is nice to have but not really needed. Ross From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 19:20:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10049; Wed, 6 Apr 1994 14:38:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA07354; Wed, 6 Apr 1994 14:36:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA07349; Wed, 6 Apr 1994 14:28:30 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01881; Wed, 6 Apr 1994 11:03:17 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id SAA08667; Tue, 5 Apr 1994 18:01:51 -0700 Date: Tue, 5 Apr 1994 18:01:51 -0700 From: Tony Li Message-Id: <199404060101.SAA08667@lager.cisco.com> To: craig@aland.bbn.com (Craig Partridge) Cc: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Ah! Now I understand. The numbers were for two reasons: * firewall filtering (which most routers support now) so yes, for flows, SIPP doesn't need TCP and UDP. But for firewalls, SIPP might. Sorry for the confusion. Thanks for the clarification. However, I guess I'm now more confused. Are you suggesting that performance of port-sensitive firewalls is an important design criteria for IPng? I would argue that because a firewall is not a complete security solution, that firewall performance should very much be a non-goal. Tony From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 19:25:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10954; Wed, 6 Apr 1994 14:58:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA07414; Wed, 6 Apr 1994 14:56:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA07356; Wed, 6 Apr 1994 14:36:25 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02185; Wed, 6 Apr 1994 11:13:42 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA10404 for big-internet@munnari.oz.au; Tue, 5 Apr 94 21:12:32 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id SAA11535; Tue, 5 Apr 1994 18:10:51 -0700 Message-Id: <199404060110.SAA11535@aland.bbn.com> To: Tony Li Cc: craig@aland.bbn.com (Craig Partridge), J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Tue, 05 Apr 94 18:01:51 -0700. <199404060101.SAA08667@lager.cisco.com> From: Craig Partridge Date: Tue, 05 Apr 94 18:10:46 -0700 Sender: craig@aland.bbn.com Thanks for the clarification. However, I guess I'm now more confused. Are you suggesting that performance of port-sensitive firewalls is an important design criteria for IPng? At this point, I don't know. There are folks arguing that we should make firewalls a requirement. I think the current status is that Frank and I have agreed to say that an IPng shouldn't be firewall hostile. Craig From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 19:25:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10099; Wed, 6 Apr 1994 14:40:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA07374; Wed, 6 Apr 1994 14:38:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA07334; Wed, 6 Apr 1994 14:20:36 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09260; Wed, 6 Apr 1994 14:21:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14911; Wed, 6 Apr 94 00:21:41 -0400 Date: Wed, 6 Apr 94 00:21:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404060421.AA14911@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: How to create and maintain state in a packet network Cc: jnc@ginger.lcs.mit.edu Let's suppose that the state allows the router to operate at a much higher performance level. I think this is the theory behind caching copies of user state in routers, and using hints to find it... of course, routers are already doing just this. In this case if the state is not there then packets might be discarded due to congestion. This sort of second order effect is really outside the scope of what's useful to consider. I mean, *any* change in the performance of the network, even if it's still within guarantees, could have some effect. The critical question is "can we design a system that will, modulo specified exceptions like equipment failures, etc, meet service guarantees". There will be still other kinds of state which is not necessary in order to cause the packets to get to the correct destination, but which are necessary in order for the network as a whole to offer an acceptable level of performance (also critical state). As Masataka Ohta pointed out, there's no such thing as an absolute guarantee. The best you can do, as you work harder, is get a higher probability of getting the kind of service you want. I suppose I could view this "optional user state" as a place where we have to think about the costs (in terms of "how hard do we work to make sure it's always there") versus the benefits (in terms of "how much does this help us increase the probability of meeting our perfomance guarantees"). I question whether there will be such a thing as "optional state", which is nice to have but not really needed. You may be right; I don't know enough about resource reservation to be sure. However, in a way I guess I agree with you, since I'm thinking of mechanisms which bundle up absolutely necessary user state (like forwarding entries) along with optional user state (like resource reservations); the latter then gets the high degree of robustness "for free". Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 19:37:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21119; Wed, 6 Apr 1994 19:37:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA07739; Wed, 6 Apr 1994 19:36:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA07710; Wed, 6 Apr 1994 19:21:34 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19511; Wed, 6 Apr 1994 18:52:54 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA25791; Wed, 6 Apr 1994 10:56:56 +0200 Message-Id: <199404060856.AA25791@mitsou.inria.fr> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Tue, 05 Apr 1994 23:37:11 GMT." <2124.bill.simpson@um.cc.umich.edu> Date: Wed, 06 Apr 1994 10:56:55 +0200 From: Christian Huitema Just to add my $.02 to this discussion. There is also a requirement for a sparsely used flow-id space for two reasons: * use as a hash-code: if the flow-id is a random number, then this minimizes the chances that two flow-ids from different sources will collide. It allows soft implementations to use the flow-id value as a hash code for accessing caches and other tables, removing the need to first hash the header. * use as a weak authentication: if the flow-id space is sparsely populated, it becomes hard to guess and can be used for "light weight" checks. One can discuss whether the 28 bits field of SIPP meets these criteria - the birthday paradox starts to hit when we have about 2**14 active flows. But 8 bits clearly do not achieve that result. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 19:42:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21238; Wed, 6 Apr 1994 19:42:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA07795; Wed, 6 Apr 1994 19:41:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA07736; Wed, 6 Apr 1994 19:35:49 +1000 Received: from fennel.acc.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13760; Wed, 6 Apr 1994 16:17:25 +1000 (from fbaker@acc.com) Received: from by fennel.acc.com (4.1/SMI-4.1) id AB14038; Tue, 5 Apr 94 23:16:48 PDT Message-Id: <9404060616.AB14038@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Apr 1994 23:15:54 -0800 To: Tony Li From: fbaker@acc.com (Fred Baker) Subject: Re: Turnipp - a merger proposal Cc: big-internet@munnari.OZ.AU > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (Length) | AFI A | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Length Source or destination length. Will always be 7 for > AFI A addresses. > > AFI A 8-bit selector. Indicates a globally unique > imbedded IPv4 address. > > Reserved 16 bits. Must be sent as zero, must be ignored on > receipt. May I suggest that the originating host or leaf-domain router should set the "reserved" field to zero, but the first router that has any concept of AS should substitute its AS there? This permits remote ASs to forward based on AS, when AS != 0 and != "my AS". (This concept is, I believe, not entirely new :^). >Novell is encouraged to acquire another AFI for embedding IPX addresses in >Turnipp. As an IPX address is 10 octets, the resulting NSAP is 12 octets >which is convenient for 32 bit based machines. No, the socket value is there as well. I think it wants to be > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (Length) | AFI C | AS # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Netware Network | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Netware Host # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Netware Host # | Netware Socket | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >The transition plan for Turnipp is dual stack. Dual stack WHERE? I agree that hosts want to have native functionality eventially, but I continue to believe that a solution that requires this day one is not a cost-effective proposal. I think the router should translate. _______________________________________________________________________ "There's nothing like hay when you're thirsty!" The White King... From owner-Big-Internet@munnari.OZ.AU Wed Apr 6 20:57:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23773; Wed, 6 Apr 1994 20:57:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA07932; Wed, 6 Apr 1994 20:56:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA07918; Wed, 6 Apr 1994 20:50:02 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23639; Wed, 6 Apr 1994 20:51:14 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404061051.23639@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Apr 1994 11:50:38 +0100 To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Mon, 04 Apr 94 15:50:48 PDT." <199404042250.PAA15249@lager.cisco.com> Date: Wed, 06 Apr 94 11:50:30 +0100 From: Jon Crowcroft > > i.e. we are being told something quite strong about how fast you > can make a given router go on putting packets into the right queue >I'd like to revise the message that you're getting: >- For our hardware, the amount of overhead is, to a first order, the >number of bytes that I have to read to make the routing decision -- >and SIPP is not significantly different from CLNP. if the SIPP flow id is a hash of src/dst, qos, which acts as a fast index into forwarding tables (which is what my message was referring to as the outcome of the int-serv WG in seattle), then quite low cost hardware can forward class based queues, including i) route lookup ii) QoS support (e.g. delay bounding, throughput guarantees etc) iii) link sharing (e.g. rules on agnecy/users proportion of link) i think this is an important design aspect of IPngs... >- Variable length is not a problem, even for other architectures. But >arbitrary lengths ARE a problem because they force you to treat >addresses as strings of bytes. variable lenghts _are_ a problem for compsing merged flow id information - that is the point that was made in int-serv. you need to be able to group flow specs in a hierarchy to make this stuff fly....but you cannot predict what the hierarcy will be beforehand, so you can't rely on it being hardcoded in the hierarchy i nthe address (or future QoS fileds) in the packet - it may be some nasty mix of things - at the very least, a mix of different source/dest pairs _and_ QoS (flow id) fields, for link share rules, for example - this means that dealing with varialbe lenght fields i nthis stage of the packet classification is a real pain cozyou have to deal with several _different_ variable lengths... >I know of nothing that's currently proposing changes to CLNP. if it is to be an IPng, it will change, perforce, at least in terms of ownership... to add multicast, flows and mobility, CLNP code must change before it is an IPng. hence my comment about legacy systems. the existence of CLNP code as of now does not buy one iota advantage over the existence of ipv4 code w.r.t IPng. on the question of varable length addresses & prefixes, versus fixed length addresses and variable masks: I am quite happy to believe you can make one go faster than the other with a given hardware base - many lisp machine specialists managed to make their hardware do lists faster than vector memory machines for a given clock speed.....however, what market share do they have now? jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 00:38:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19692; Wed, 6 Apr 1994 18:58:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA07665; Wed, 6 Apr 1994 18:56:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA07637; Wed, 6 Apr 1994 18:38:00 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18922; Wed, 6 Apr 1994 18:39:02 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404060839.18922@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Apr 1994 09:38:09 +0100 To: Lyman Chapin Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU, tli@cisco.com Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Tue, 05 Apr 94 10:43:42 EDT." Date: Wed, 06 Apr 94 09:38:09 +0100 From: Jon Crowcroft >eventually have more than 255 of almost *anything*.... Lyman the flow id is used to optimse distinctive treatment of traffic - not just to distinguish types of flow between pairs of end systems - hence it may be a hash of the QoS, link utilisation share _and_ soruce/destiantion info clearly even 32 bits may possibly be low for this....since hash clashes result in a cache miss, and a flow control block lookup taking the slow path.... 8 bits is hopeless there is also an aspect of security against denial of service attacks from flow ids being sparse also, i would put money on some one already using source NSELs somewhere in some iso stack implementation...but ross knows a lot more than most on that... jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 00:41:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19813; Wed, 6 Apr 1994 19:02:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA07680; Wed, 6 Apr 1994 19:00:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA07651; Wed, 6 Apr 1994 18:43:28 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04615; Wed, 6 Apr 1994 12:23:22 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA19209 for big-internet@munnari.oz.au; Tue, 5 Apr 94 22:23:09 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id TAA11765; Tue, 5 Apr 1994 19:21:36 -0700 Message-Id: <199404060221.TAA11765@aland.bbn.com> To: Ross Callon Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: How to create and maintain state in a packet network In-Reply-To: Your message of Tue, 05 Apr 94 17:46:35 -0400. <9404052146.AA10846@pobox.wellfleet> From: Craig Partridge Date: Tue, 05 Apr 94 19:21:34 -0700 Sender: craig@aland.bbn.com Similarly, let's suppose that the user is watching a movie, and the requested flow could have a very large delay, but requires a very small delay variance. Thus once the movie starts the associated packets arrive at the destination with the right inter-packet delay, allowing small buffers in the receiver. If loss of state causes the right packets to show up at the correct destination, but with a large delay variation, then the lack of buffering at the destination might cause the packets either to be lost or might cause the resulting application to be unacceptable. Ross: Yes, if one makes certain assumptions (like we're going to tightly control variance and the receiving application will take advantage of it) then state becomes vital -- either you've got it or you don't. However, as VAT et al. show, one doesn't have to make so tight a guarantee. A looser guarantee (with some upper bound on delay and broad control on variance) works well. In this situation, if a router drops state, and the router still forwards the packet based on its best guess about what the application need, it is highly likely that the receiving application will be kept happy for the brief interval (an RTT or two) during which state is restored. The major problem to worry about is the router mis-guessing. A good case is imagine a router with two paths to the destination -- one high bandwidth but high delay (e.g., 622 Mb/s satellite link) and one lower bandwidth but low delay (terrestrial T1). If the router guesses wrong on a video stream and sends it over the T1 it may both (a) saturate the T1 and (b) still delivery poor service to the receiver. In this case, lack of flow state is fatal and the router needs to know it. But in the normal case, best-effort recovery (ala IP best effort service) seems likely to work and thus desirable. Craig From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 00:42:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21182; Wed, 6 Apr 1994 19:39:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA07754; Wed, 6 Apr 1994 19:38:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA07715; Wed, 6 Apr 1994 19:23:58 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11474; Wed, 6 Apr 1994 15:16:33 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa03608; 6 Apr 94 1:16 EDT To: Craig Partridge Cc: Tony Li , J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Tue, 05 Apr 1994 18:10:46 -0700. <199404060110.SAA11535@aland.bbn.com> Date: Wed, 06 Apr 1994 01:15:16 -0400 From: John Curran Message-Id: <9404060116.aa03608@nic.near.net> -------- ] From: Craig Partridge ] Subject: Re: Costs, Performance and IPng ] Date: Tue, 05 Apr 94 18:10:46 -0700 ] ... ] Thanks for the clarification. However, I guess I'm now more confused. ] Are you suggesting that performance of port-sensitive firewalls is an ] important design criteria for IPng? ] ] At this point, I don't know. There are folks arguing that we should make ] firewalls a requirement. I think the current status is that Frank and I ] have agreed to say that an IPng shouldn't be firewall hostile. I have heard that we need to accomodate firewalls "as well as" IPv4. This rules out interesting things such as totally-dynamic port numbers for services, etc. Does anyone feel that IPng has to provide particular new features to make it easier to deploy firewalls? I'd like to hear which features would be considered useful for this purpose. /John From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 00:43:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21213; Wed, 6 Apr 1994 19:41:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA07769; Wed, 6 Apr 1994 19:39:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA07733; Wed, 6 Apr 1994 19:35:14 +1000 Received: from fennel.acc.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13790; Wed, 6 Apr 1994 16:18:10 +1000 (from fbaker@acc.com) Received: from by fennel.acc.com (4.1/SMI-4.1) id AB14038; Tue, 5 Apr 94 23:17:34 PDT Message-Id: <9404060617.AB14038@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Apr 1994 23:16:40 -0800 To: Tony Li From: fbaker@acc.com (Fred Baker) Subject: Re: Turnipp - a merger proposal Cc: big-internet@munnari.OZ.AU >If you weren't at the IPng open directorate meeting, I asked about the >possibility of another merger between the current contenders. My >personal feeling is that the "selection" of a contender is harmful to >the community, and that progress should be made by further mergers. >Turnipp is my attempt to suggest a strawman for the proposal authors >to work from. If I've done my job correctly, the result still looks >like a horse, not a camel. I commend you for trying to get them to merge into one. That's the way we will all win, and if we don't all win, I believe that the end user lost bigtime. I wish I was certain where IS-IS fit into this. I guess you're saying that the TURNIPP address would have an area identifier in it. How about: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Length) | AFI B | AS # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area # | Host # in Area | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Source or destination length. Turnipp addresses always have length 7+n*8 octets, i = 0, ... n. AFI B 8-bit selector. Indicates a Turnipp Address. AS # In the source, zero in the leaf domain, set to the ingress AS on receipt. In the destination, learned from DNS or whatever it takes. Area # Like an IS-IS Area # Host # unique in the area. _______________________________________________________________________ "There's nothing like hay when you're thirsty!" The White King... From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 00:50:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22536; Wed, 6 Apr 1994 20:18:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA07854; Wed, 6 Apr 1994 20:16:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA07831; Wed, 6 Apr 1994 20:02:29 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16520; Wed, 6 Apr 1994 17:36:43 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id AAA22938; Wed, 6 Apr 1994 00:36:36 -0700 Date: Wed, 6 Apr 1994 00:36:36 -0700 From: Tony Li Message-Id: <199404060736.AAA22938@lager.cisco.com> To: fbaker@acc.com Cc: big-internet@munnari.OZ.AU In-Reply-To: Fred Baker's message of Tue, 5 Apr 1994 23:15:54 -0800 <9404060616.AB14038@fennel.acc.com> Subject: Turnipp - a merger proposal May I suggest that the originating host or leaf-domain router should set the "reserved" field to zero, but the first router that has any concept of AS should substitute its AS there? This permits remote ASs to forward based on AS, when AS != 0 and != "my AS". (This concept is, I believe, not entirely new :^). Good idea if we can't keep the number of IPv4 routes under the number of AS's. >Novell is encouraged to acquire another AFI for embedding IPX addresses in >Turnipp. As an IPX address is 10 octets, the resulting NSAP is 12 octets >which is convenient for 32 bit based machines. No, the socket value is there as well. I think it wants to be > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (Length) | AFI C | AS # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Netware Network | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Netware Host # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Netware Host # | Netware Socket | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urp. You're correct. Yes, the domain number is the right thing to do with the extra two bytes. Poof. Instant globally unique IPX addresses. Neal, are you out there? ;-) >The transition plan for Turnipp is dual stack. Dual stack WHERE? I agree that hosts want to have native functionality eventially, but I continue to believe that a solution that requires this day one is not a cost-effective proposal. I think the router should translate. We can argue this till we're all blue in the face. Suffice it to say that unless you can make translation simpler than the Phase IV->Phase V translation, I don't believe you have a hope of getting away with it. In any case, I'm willing to simply disagree pro tem if it allows us to close other topics. Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 00:54:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22695; Wed, 6 Apr 1994 20:21:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA07871; Wed, 6 Apr 1994 20:20:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA07834; Wed, 6 Apr 1994 20:04:07 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16118; Wed, 6 Apr 1994 17:24:19 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id AAA22637; Wed, 6 Apr 1994 00:24:07 -0700 Date: Wed, 6 Apr 1994 00:24:07 -0700 From: Tony Li Message-Id: <199404060724.AAA22637@lager.cisco.com> To: fbaker@acc.com Cc: big-internet@munnari.OZ.AU In-Reply-To: Fred Baker's message of Tue, 5 Apr 1994 23:16:40 -0800 <9404060617.AB14038@fennel.acc.com> Subject: Turnipp - a merger proposal I wish I was certain where IS-IS fit into this. I guess you're saying that the TURNIPP address would have an area identifier in it. How about: Actually, yes, it needs an area. However, it's not clear to me that it needs to be fixed format. [Warning: furious hand waving imminent] One of the very nice things about IPv4 routing is that it doesn't force the aggregation levels to be tightly coupled to a fixed addressing format, as with (currently) common NSAP formats. With Turnipp, I would very much like to see us retain this flexibility: the local network manager gets some prefix of some number of (bits, nibbles, byte?) and can have whatever subsequent levels of aggregation they like, at arbitrary (bit, nibble, byte?) boundaries. Thus, we would have the flexibility to do: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Length) | AFI B | AS # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area # | Host # in Area | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Length) | AFI B | AS # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area # | Subarea | Host # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ akin to 8 bit subnets of a class B now, or 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Length) | AFI B | AS # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Superarea | Area # | Subarea | Host # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ for four levels of aggregation within the AS (whoops, ok, let's fix that, it's now domain! ;-) But it's likely that we'll blow through 64k domains quite quickly. And we probably don't want to carry around 64k domain routes anyhow. Perhaps we need to do more aggregation: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Length) | AFI B | Superdomain | Domain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Superarea | Area # | Subarea | Host # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We _could_ also go crazy and subdivide further on nibble or bit boundaries, but that's becoming silly: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Length) | AFI B | Superdomain | Domain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA | Area | Subarea | Region | Subnet | Hub | Room| Host | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The point is simple: We should be purely prefix based, and neither the addressing structure nor the routing protocols should be strongly tied to the particular way we aggregate addresses. We have the technology to allow the network adminstrator the flexibility to assign addresses and aggregate where it is both convenient and optimal for thier particular part of the network. Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 01:37:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03199; Thu, 7 Apr 1994 01:37:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA08242; Thu, 7 Apr 1994 01:36:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA08237; Thu, 7 Apr 1994 01:31:02 +1000 Received: from Tadpole.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02958; Thu, 7 Apr 1994 01:32:05 +1000 (from jim@Tadpole.COM) Received: from chiba.tadpole.com by tadpole.tadpole.com (4.1/SMI-4.1-jim) id AA26910; Wed, 6 Apr 94 10:30:53 CDT Received: by chiba.tadpole.com (5.0/SMI-SVR4) id AA00812; Wed, 6 Apr 1994 10:31:24 +0600 Date: Wed, 6 Apr 1994 10:31:24 +0600 From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9404061531.AA00812@chiba.tadpole.com> To: J.Crowcroft@cs.ucl.ac.uk, fbaker@acc.com Subject: Re: Turnipp - a merger proposal Cc: big-internet@munnari.OZ.AU, tli@cisco.com Content-Length: 80 I certainly hope that what has happened to 'Mobile IP' doesn't happen to IPng. From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 03:07:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01973; Thu, 7 Apr 1994 00:58:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA08176; Thu, 7 Apr 1994 00:56:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA08130; Thu, 7 Apr 1994 00:41:38 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22726; Wed, 6 Apr 1994 20:22:26 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404061022.22726@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Apr 1994 11:21:31 +0100 To: fbaker@acc.com (Fred Baker) Cc: Tony Li , big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Tue, 05 Apr 94 23:15:54 -0900." <9404060616.AB14038@fennel.acc.com> Date: Wed, 06 Apr 94 11:21:28 +0100 From: Jon Crowcroft > "There's nothing like hay when you're thirsty!" > The White King... "just what we need: another protocol design by committee" The IPng purist... jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 03:17:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06939; Thu, 7 Apr 1994 03:17:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA08460; Thu, 7 Apr 1994 03:16:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA08440; Thu, 7 Apr 1994 03:03:44 +1000 Received: from research.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02273; Thu, 7 Apr 1994 01:08:26 +1000 (from kasten@Research.Ftp.Com) Received: by Research.Ftp.Com (920330.SGI/) for big-internet@munnari.oz.au id AA00530; Wed, 6 Apr 94 11:02:32 -0400 Received: by Research.Ftp.Com id AA00530; Wed, 6 Apr 94 11:02:32 -0400 Date: Wed, 6 Apr 1994 11:02:32 -0400 (EDT) From: Frank Kastenholz To: stev@ftp.com, Claudio Topolcic Cc: big-internet@munnari.OZ.AU, Jon Crowcroft Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Steve and Claudio, The IPng Requirements working group met at the Seattle IETF Meeting on 32 March 1994. In its deliberations, the working group decided that having large data areas in ICMP error messages would be of great utility in dealing with transition and coexistance in general. Specifically, that the "Internet Header + 64 bits of Original Data Datagram" which is commonly returned in ICMP error messages is way too small. The working group directed me, as co-chair and scribe, to formally request that the Internet Area take the necessary steps to get more data in these messages. Please consider this note such a formal request. Frank Kastenholz Co-Chair and Scribe IPNG Requirements Working Group From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 03:22:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07044; Thu, 7 Apr 1994 03:22:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA08493; Thu, 7 Apr 1994 03:20:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA08454; Thu, 7 Apr 1994 03:12:12 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06769; Thu, 7 Apr 1994 03:13:23 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa13185; 6 Apr 94 13:13 EDT To: Paul Traina Cc: bgpd@merit.edu, big-internet@munnari.OZ.AU Reply-To: big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? In-Reply-To: Your message of Wed, 06 Apr 1994 08:34:57 -0700. <199404061534.AA20416@cider.cisco.com> Date: Wed, 06 Apr 1994 13:13:09 -0400 From: John Curran Message-Id: <9404061313.aa13185@nic.near.net> -------- ] From: Paul Traina ] Subject: Re: Introducing proxy aggregations? ] Date: Wed, 06 Apr 1994 08:34:57 -0700 ] ] > From: a.bresser@empb.net (Ad Bresser) ] > Subject: Introducing proxy aggregations? ] > To: bgpd@merit.edu ] > Date: Wed, 6 Apr 1994 09:00:10 +0200 (MET DST) ] > ] > Hi, ] > ] > Last week the question was raised to do proxy aggregation for ] > (single homed) regionals not yet using BGP-4. I'm against this and ] > this are my arguments: ] > ] > - When you aggregate your own networks you're managing your own ] > black holes, when doing proxy's you're managing someone else's ] > black holes (manage in this context: check, decide, administer ] > a.s.o.); ] ] I think proxy aggregation should be done now. Your argumement for avoiding ] proxy aggregation doesn't really make sense. If a site or a site-collective ] have been granted a block of addresses, it doesn't matter who does the ] aggregation, just as long as it gets done consistently -- which suggests that ] for a given area, all peers must aggregate in the same fashion... in the ] degenerate (usual) case of a stub area, it means that the one service ] provider does the aggregation and the problem is solved. ] ] Forcing each individual site to upgrade to BGP4 capable hardware and software ] is absolutely insane! Your plan would have us tie the viability of the ] internet to the upgrade plans of people who have no understanding and little ] motivation to upgrade. ] ] I would imagine that given the choice of investing new money in routers or ] switching to a service provider that won't require them to change their ] existing configuration, most end-customers would simply switch providers. ] This would of course be a form of "Internet Darwinism" for any provider who ] wasn't capable of providing proxy-aggregation service. Paul: If we can't get sites to upgrade just one border router and do a minor configuration change "for the good of the Internet" and "because my vendor told me so", how will we ever get them to deploy IPng (which will require host changes before being fully-functional and again provide little tangible benefit). Does "Internet Darwinism" predict NAT boxes for IPng? ;-) /John From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 03:38:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07688; Thu, 7 Apr 1994 03:38:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA08530; Thu, 7 Apr 1994 03:36:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA08520; Thu, 7 Apr 1994 03:28:21 +1000 Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07343; Thu, 7 Apr 1994 03:29:35 +1000 (from pst@cisco.com) Received: from localhost.cisco.com by cider.cisco.com with SMTP id AA22294 (5.67a/IDA-1.5 for ); Wed, 6 Apr 1994 10:29:36 -0700 Message-Id: <199404061729.AA22294@cider.cisco.com> To: big-internet@munnari.OZ.AU Cc: bgpd@merit.edu Subject: Re: Introducing proxy aggregations? In-Reply-To: Your message of "Wed, 06 Apr 1994 13:13:09 EDT." <9404061313.aa13185@nic.near.net> Date: Wed, 06 Apr 1994 10:29:36 -0700 From: Paul Traina > To: Paul Traina > Cc: bgpd@merit.edu, big-internet@munnari.oz.au > Reply-To: big-internet@munnari.oz.au > Subject: Re: Introducing proxy aggregations? > Date: Wed, 06 Apr 1994 13:13:09 -0400 > From: John Curran > > Paul: > > If we can't get sites to upgrade just one border router and do a minor > configuration change "for the good of the Internet" and "because my vendor > told me so", how will we ever get them to deploy IPng (which will require > host changes before being fully-functional and again provide little tangible > benefit). > > Does "Internet Darwinism" predict NAT boxes for IPng? > > ;-) > /John Yes. Paul p.s. no smiley face intended From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 04:38:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09931; Thu, 7 Apr 1994 04:38:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08705; Thu, 7 Apr 1994 04:36:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08702; Thu, 7 Apr 1994 04:33:09 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09843; Thu, 7 Apr 1994 04:34:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20210; Wed, 6 Apr 94 14:34:04 -0400 Date: Wed, 6 Apr 94 14:34:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404061834.AA20210@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Costs, Performance and IPng Cc: jnc@ginger.lcs.mit.edu > There's also a problem with the naming space; if two flows which can be > aggregated have names which cannot be masked so as to create one flow, Why are flows cocerned with name space? Which name space? I'm using "name space" in the RFC-1498 sense (*WHAT* - you haven't read RFC- 1498???? :-) to refer to whatever identifier-space identifies flows, be it 8-bit-flow-id plus source-"address", or whatever. Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 04:39:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09977; Thu, 7 Apr 1994 04:39:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08720; Thu, 7 Apr 1994 04:38:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08681; Thu, 7 Apr 1994 04:22:08 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09436; Thu, 7 Apr 1994 04:23:22 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA26913; Wed, 6 Apr 94 11:11:48 -0700 Received: by xirtlu.zk3.dec.com; id AA16972; Wed, 6 Apr 1994 14:11:32 -0400 Message-Id: <9404061811.AA16972@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Wed, 06 Apr 94 11:28:07 EDT." <9404061528.AA18173@ginger.lcs.mit.edu> Date: Wed, 06 Apr 94 14:11:25 -0400 X-Mts: smtp Noel, >There's also a problem with the naming space; if two flows which can be >aggregated have names which cannot be masked so as to create one flow, you >either have to i) bash the flow name of one while those packets are on the >shared part of the path, and unbash it at the end of that, a potentially >recursive process, or ii) have two small bits of state which name the flows, >and refer to a common block of state for the rest. All you've done is saved >some duplication of data, at the cost of extra complexity. Why are flows cocerned with name space? Which name space? thanks /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 04:58:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10707; Thu, 7 Apr 1994 04:58:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08797; Thu, 7 Apr 1994 04:56:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08725; Thu, 7 Apr 1994 04:38:11 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09970; Thu, 7 Apr 1994 04:39:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20300; Wed, 6 Apr 94 14:39:20 -0400 Date: Wed, 6 Apr 94 14:39:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404061839.AA20300@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? Cc: jnc@ginger.lcs.mit.edu > I would imagine that given the choice of investing new money in routers > or switching to a service provider that won't require them to change > their existing configuration, most end-customers would simply switch > providers. Just out of interest, I assume this provider switch would mean they'd have to renumber, or are you suggested that the new provider would allow them to keep their old addresses? If so, how would we *ever* get aggregation to work? One service provider told me years ago that you'd never get people to renumber when they switched, since providers would use keeping your old number as a competitive advantage. If so, we're really screwed, since the aggregation we do will never really catch up with the inevitable address entropy... Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 04:59:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04676; Thu, 7 Apr 1994 02:18:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA08326; Thu, 7 Apr 1994 02:16:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA08323; Thu, 7 Apr 1994 02:16:10 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27523; Wed, 6 Apr 1994 23:03:38 +1000 (from yakov@watson.ibm.com) Message-Id: <9404061303.27523@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5017; Wed, 06 Apr 94 09:03:25 EDT Date: Wed, 6 Apr 94 09:03:25 EDT To: J.Crowcroft@cs.ucl.ac.uk, tli@cisco.com Cc: big-internet@munnari.OZ.AU Subject: Costs, Performance and IPng Ref: Your note of Wed, 06 Apr 94 11:50:30 +0100 Jon, >to add multicast, flows and mobility, CLNP code must change before >it is an IPng... Since I've been quite involved in IP mobility, I'd like to comment on this assertion. The mobility scheme being developed within the mobile-ip WG could be trivially modified to be used with CLNP. In fact, at the network layer and above the existing CLNP mobility scheme used in CDPD is pretty much the same as the mobile-ip scheme. Neither mobile-ip nor CDPD schemes require any modifications to the network layer protocol (CDPD operates quite happily with CLNP as defined in ISO8473, and the mobile-ip scheme would operate quite happily with IPv4 as defined in RFC791). So, I am really getting confused about what changes CLNP code must undergo in order to support mobility. Would you help to clarify my confusion ? Yakov Rekhter. From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 05:01:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04731; Thu, 7 Apr 1994 02:20:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA08341; Thu, 7 Apr 1994 02:18:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA08305; Thu, 7 Apr 1994 02:10:00 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26625; Wed, 6 Apr 1994 22:38:19 +1000 (from yakov@watson.ibm.com) Message-Id: <9404061238.26625@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4803; Wed, 06 Apr 94 08:38:04 EDT Date: Wed, 6 Apr 94 08:38:04 EDT To: tli@cisco.com, fbaker@acc.com Cc: big-internet@munnari.OZ.AU Subject: Turnipp - a merger proposal Ref: Your note of Wed, 6 Apr 1994 00:24:07 -0700 Folks, It is ok to impose address structure by partitioning an address into individual fixed length components for the purpose of setting up an addressing plan (e.g. an addressing plan for enterprise X could specify the number of bits allocated for individual subnets). At the same time for the purpose of routing (and especially inter-domain routing) it wouldn't be prudent to constrain address structure to a particular sequence of fixed length fields. Rigidity in address structure usually results in either (a) inefficient address space utilization, or (b) inability to perform efficient routing information aggregation, or (a) and (b) combined. IP address structure evolution from pure A/B/C to subnetting, and now to supernetting (with CIDR) clearly shows the need to treat addresses and address information as just variable length prefixes. And, by the way, the technology for doing this is available today. Yakov Rekhter From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 05:10:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06180; Thu, 7 Apr 1994 02:57:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA08407; Thu, 7 Apr 1994 02:56:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA08386; Thu, 7 Apr 1994 02:42:01 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05609; Thu, 7 Apr 1994 02:43:07 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404061643.5609@munnari.oz.au> Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Apr 1994 17:41:56 +0100 To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Wed, 06 Apr 94 08:38:04 EDT." <9404061238.26625@munnari.oz.au> Date: Wed, 06 Apr 94 17:41:56 +0100 From: Jon Crowcroft >IP address structure evolution from pure A/B/C to subnetting, and now >to supernetting (with CIDR) clearly shows the need to treat addresses >and address information as just variable length prefixes. And, by the way, >the technology for doing this is available today. Yakov variable lenght prefixes makes aggregation of contained classes of superclasses of flows _hard_ there is a tradeoff between routing flexibility and flow classification flexibility w.r.t the use of prefixes versus CIDR masks.... and it shows in performance however, if you have a flowid thats big enough to be a hash from src+dst+qos (so you can do route lookup, link share and class based queueing based on it in fast path through router), then the slow path is non-critical, and the use of variable lenght addresses may be perfectly reasoanble.... i.e. if CLNP adds a 64bit flow field, somewhere convenient in the header, and fast forwarding can be based on it except for occasional cache misses, then CLNP is fine....cept it aint clnp anymore:-) jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 05:11:02 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04143; Thu, 7 Apr 1994 02:04:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11394 Thu, 7 Apr 1994 02:00:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA08285; Thu, 7 Apr 1994 01:56:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA08271; Thu, 7 Apr 1994 01:44:56 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03607; Thu, 7 Apr 1994 01:46:03 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404061546.3607@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Apr 1994 16:45:25 +0100 To: big-internet@munnari.OZ.AU Subject: Minutes from Seattle IPNG Requirements open meeting Date: Wed, 06 Apr 94 16:45:21 +0100 From: Jon Crowcroft ==================================================================== IPNG Requirements Working Group Minutes The IPNG Requirements Working Group met on the morning of 31 March 1994. The goal of the working group's meeting was to review the "Technical Criteria for Choosing IP:The Next Generation (IPng)" Internet Draft (available as draft-kastenholz-ipng-criteria-01.txt at any Internet Draft repository). The meeting was broken into two parts, short presentations be several experts in particular technologies, followed by a general discussion. The Technical Presentation part of the discussion lasted for about 1 hour. Several people gave brief, 3 minute, presentations on the requirements that their own particular technology had on IPng. This was very similar to the White Paper process used by the IPng Directorate, though much less formal. A brief open discussion also followed each presentation. The following presentations were given: 1. Mike St. Johns gave a brief presentation on network-layer security. He described the functions that would be needed in order to properly secure the network layer. Among them: privacy and authentication of packets, key distribution, and access and resource control. In the open discussion, the working group expressed its sentiments that security must be present in IPng and that the requirements should be worded as strongly as possible. 2. Greg Minshall gave a talk about mobility. Several points that he brought out were that firewalls are bad for mobility, the control protocol (ICMPng) should have large data fields, separate addresses end endpoint identifiers are highly desireable and that router discovery is necessary. In the ensuing open discussion two points were brought up: - There is a need for larger data areas in ICMPv4 error messages for transition and coexistance. - The working group wants both Mobility and Portability in IPng. 3. Dave Clark gave a talk about network services. His points included that IPng be able to efficiently map packets into services, that there be security for this class mapping scheme, and that highly sophisticated routing be available that can do things like select providers, route according to desired services, and so on. 4. Mark Hadley gave a brief talk about the AVT and MMUSIC work. He indicated that for these areas, low delay and high reliability in the network were particularly to be favored. Also, he said that larger MTUs and smaller headers were desireable. 5. Lixia Zhang talked about RSVP. RSVP's particular concerns were that the routes be stable and that endpoints be notified if routes change, that the routing be able to route based on QOS information, and that a network user must be able to prove that the network is providing the desired service level. 6. Peter Ford gave a brief talk on IPng from the perspective of a network operator. The important points that he brought out were that one must be able to do provider selection, and that the network operators must be able to control the routing within their networks in order to do things like load-shedding and balancing, switching to backup routes, and the like. 7. John Curran gave a talk indicating that IPng must give end users a strong incentive to migrate to IPng and leave IPv4. Simply being able to deal with larger networks (i.e. larger address spaces) would not be sufficient. The group then had a general, open discussion. Additional points were raised and discussed. Among them: - Convergence. Several members of the working group expressed a desire that IPng provide for convergence for all protocol families (e.g. OSI, Netware, XNS, and so on). Some felt that this was just plain silly, some felt that this was useful but not a technical requirement, and others felt that it was a technical requirement. This discussion continued for some time, with no real resolution. - The group expressed a desire to have a larger minimum packet size. - Address assignment must be delegated as far down the administrative hierarchy as possible. - Automatic configuration must not preclude manual configuration. - It was pointed out that the automatic configuration requirements apply only to the internet-layer (analogous to getting the IP address and network mask in today's IP). Higher layer configuration issues (e.g. registring with the DNS) are important, but are explicitly not addressed in the document. - A general discussion of architectural issues was held. This discussion was cut off by lack of time. From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 05:11:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06197; Thu, 7 Apr 1994 02:59:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA08424; Thu, 7 Apr 1994 02:58:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA08393; Thu, 7 Apr 1994 02:50:49 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00991; Thu, 7 Apr 1994 00:32:13 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404061432.991@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Apr 1994 15:20:31 +0100 To: yakov@watson.ibm.com Cc: tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Wed, 06 Apr 94 09:03:25 EDT." Date: Wed, 06 Apr 94 15:20:26 +0100 From: Jon Crowcroft >Since I've been quite involved in IP mobility, I'd like to comment on >this assertion. The mobility scheme being developed within the >mobile-ip WG could be trivially modified to be used with CLNP. In >fact, at the network layer and above the existing CLNP mobility scheme >used in CDPD is pretty much the same as the mobile-ip scheme. Neither >mobile-ip nor CDPD schemes require any modifications to the network >layer protocol (CDPD operates quite happily with CLNP as defined in >ISO8473, and the mobile-ip scheme would operate quite happily with IPv4 >as defined in RFC791). So, I am really getting confused about what >changes CLNP code must undergo in order to support mobility. Would you >help to clarify my confusion ? Yakov some forms of mobility are based on Dynamic Host COnfiguration - you need support for that in IPng. soem are based on helping routers at 'home' or 'abroad'. that means you need to change these to do thsi work - ok, so you don't change the host. but what if my router/helper is a low cost host (typically, i would use a PC server as my redierector at a laptop plugin site...) basically, all the input i'm hearing from cisco, ibm, dec and the like is about how easy it is for people with control of high end systems - sure, but most of the itnernet grew through low end systems, and low-zero cost systems - and specifaicaly through host systems enhancved to be low performance routers... jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 05:18:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11557; Thu, 7 Apr 1994 05:18:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08855; Thu, 7 Apr 1994 05:16:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08830; Thu, 7 Apr 1994 05:08:57 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11114; Thu, 7 Apr 1994 05:10:12 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa28756; 6 Apr 94 15:10 EDT To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Wed, 06 Apr 1994 14:25:50 -0400. <9404061825.AA15215@mailserv-D.ftp.com> Date: Wed, 06 Apr 1994 15:10:04 -0400 From: John Curran Message-Id: <9404061510.aa28756@nic.near.net> -------- ] From: Frank Kastenholz ] Subject: Re: Costs, Performance and IPng ] Date: Wed, 6 Apr 94 14:25:50 EDT ] > Does anyone feel that IPng has to provide particular new features to ] > make it easier to deploy firewalls? I'd like to hear which features ] > would be considered useful for this purpose. ] ] John, Firewalls are a solution to a particular problem -- lack of ] security. Why don't we do our job and focus on the problems that ] need to be solved (or carrots to be offered) and let the protocol ] developers do their jobs and come up with (hopefully) ingenious, ] novel, and new, solutions to the problems. Frank, I agree with you 100%. The only reason that I'm asking is to make sure that there aren't some folks out there who believe that IPng needs to explicitly provide new functionality for firewall development... I haven't heard anyone bring requirements specifically to support firewalls and hence would like to see it dropped from consideration as a potential criterion. My reading of the very rough consensus is that it is important that IPng not _prevent_ firewalls, which should be a fairly easy requirement to meet. /John From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 05:19:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11586; Thu, 7 Apr 1994 05:19:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08872; Thu, 7 Apr 1994 05:18:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08825; Thu, 7 Apr 1994 05:06:38 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06631; Thu, 7 Apr 1994 03:12:21 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa13033; 6 Apr 94 13:12 EDT To: Bob Hinden Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Wed, 06 Apr 1994 09:27:02 -0700. <9404061627.AA08400@jurassic.Eng.Sun.COM> Date: Wed, 06 Apr 1994 13:12:14 -0400 From: John Curran Message-Id: <9404061312.aa13033@nic.near.net> -------- ] From: Bob Hinden ] Subject: Re: Costs, Performance and IPng ] Date: Wed, 6 Apr 1994 09:27:02 -0700 ] ] John, ] ] > Does anyone feel that IPng has to provide particular new features to ] > make it easier to deploy firewalls? I'd like to hear which features ] > would be considered useful for this purpose. ] ] I don't think it has to make doing firewalls easier, but it shouldn't ] make them harder either. I think our goals should be to eliminate the ] need for firewalls in the long term. An IPng should include ] authentication and privacy mechanisms. Agreed. ] My concern is that security (e.g. the lack of) in the Internet is ] becoming the real limit to growth, not routing and addressing. Umm... perhaps. I will note that many people ignore the lessons learned by others until it happens to them, and hence security may not be a very strong factor in limiting growth. ] Given your presentation at the IPng requirements BOF, security in an IPng ] could become a major "carrot" to get people motivated to deploy it. We're going to need something: security is certainly a worthwhile motivator. The real question is whether take the traditional IETF escape clause of making it optional... /John From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 05:20:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11613; Thu, 7 Apr 1994 05:20:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08887; Thu, 7 Apr 1994 05:19:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08817; Thu, 7 Apr 1994 05:04:58 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05035; Thu, 7 Apr 1994 02:28:15 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20622; Wed, 6 Apr 94 09:22:11 -0700 Received: by xirtlu.zk3.dec.com; id AA12939; Wed, 6 Apr 1994 12:22:09 -0400 Message-Id: <9404061622.AA12939@xirtlu.zk3.dec.com> To: Lyman Chapin Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Tue, 05 Apr 94 10:43:42 EDT." <9404051457.10511@munnari.oz.au> Date: Wed, 06 Apr 94 12:22:03 -0400 X-Mts: smtp Lyman, >>Just a thought about flows: >> >>1. It will be very possible for high-end servers ( greater than 586 >>single processor) to have a need to to support greater than 255 flows >>as multi-process identical source addr/dst addr for transaction >>processing, database server distributed processing, commercial online >>data feeds, or engineering finite element analysis parts on an >>engineering workstations; between cooperating machines. >Jim, >This raises again a point that was missed (to Ross's evident frustration!) >during the WG meeting. The question is not whether there could be more >than 255 distinct simultaneous traffic channels (to avoid using the term >"flow") between the same pair of source and destination addresses; clearly >there could be (as you point out). The question is whether it is necessary >to be able to assign each of these distinct channels to *a separate flow* >(identified by separate flow ids), so that the discrimination among the >channels is performed by the flow id. An alternative is for the hosts >to multiplex and demultiplex so that, if necessary, more than one distinct >traffic channel could be sent using the same flow id (that is, "on the same >flow"). Since each flow is established with a particular set of character- >istics (secured during flow setup by some sort of resource reservation >mechanism), the question then becomes whether or not there is a need to >specify more than 255 different sets of characteristics for the traffic >that is passing between a pair of source and destination addresses at >a given time. Yes multiple transaction iterations could use the same flow if they were on the same channel. But if I use a different channel such as the feeds for automatic teller machines or a stock exchange feed across different channels then I would not want to demux on the channeld ID but the flow granularity. I would also as was pointed out by others to set up any lists or cache based on this flow granularity in my network operating system kernel (or subsystem on the host). But I do believe your response points out a good way to limit the flow objects in the subsystems and will reduce chaos clearly when they are used. We need to capture that point in this discussion or the performance hit on random flows being created as a new process on the host will eat up both CPU and memory bandwidth. >Note that I don't assume that the answer to the "must each distinct >traffic channel be assigned to a distinct flow" is "no" - it might be >"yes", in which case the first and last questions above are indeed >equivalent. But I strongly suspect that the answer is "no". Of course, >I'm also inclined to believe that if you wait long enough, you will >eventually have more than 255 of almost *anything*.... Yes I agree we seem to break the limits of an octet easily. When its a protocol ID or payload length it is at least in some control based on the wisdom of the IETF thinkers, but flows being limited to 8 bits is short sighted I believe. thanks /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 05:22:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11654; Thu, 7 Apr 1994 05:22:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08902; Thu, 7 Apr 1994 05:20:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08848; Thu, 7 Apr 1994 05:11:51 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06076; Thu, 7 Apr 1994 02:54:33 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA21803; Wed, 6 Apr 94 09:41:24 -0700 Received: by xirtlu.zk3.dec.com; id AA13414; Wed, 6 Apr 1994 12:41:22 -0400 Message-Id: <9404061641.AA13414@xirtlu.zk3.dec.com> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Tue, 05 Apr 94 14:22:35 EDT." <9404051822.AA06940@pobox.wellfleet> Date: Wed, 06 Apr 94 12:41:16 -0400 X-Mts: smtp Ross, >I think that we need to distinguish the flows as are understood by >the network layer (particularly for reserving resources in routers, >and in subnets), versus multiple transport-user-to-transport-user >flows. I agree that a very large number of transport-user level >flows may be necessary between the same two hosts. However, this >does not necessarily mean that thousands of distinguishable flows >between the same two hosts have to be understood by routers and >subnets. I agree. But if I am using the network layer packet attributes to define my flow granularity, and I do need many flows (for different processes on a server that are mutually exclusive) I do not want to define a new flow field but use the one in the network layer packet. I am pointing to the tight coupling between the network layer flow granularity and the user application. I believe this needs to remain coheisve for the objects a host must maintain regarding the traffic state for connections (e.g. cache, lists, control blocks). But maybe we have come up with another requirement. Transport flows vs network layer flows. >Flows might need to be distinguished at the network layer if either >of the two following statements are true: (i) they need significantly >different qualities of service; (ii) they need to be kept separate to >prevent one from stealing resources from the other. Actually, if the >transport layer multiplexes multiple transport-user flows onto one >network layer flow, and if the transport layer knows what level of >service it has requested and is receiving from the network layer, >then the transport level multiplexing should be able to prevent one >transport user from stealing too many resources. This could work but I am still concerned with granularity. Using the QOS or Traffic Class as a second derivative to the flow granularity on a host would need to be looked at in more depth. But that might work. >This implies that different network layer flows are needed between >the same two hosts only in order to distinguish measureably different >quality of service. So, how many different qualities of service is >there likely to be? Could be. We are leaving my area of expertise now and maybe one of the RSVP experts can chime in here regarding the users need for flows. >I have another problem with the idea of thousands of distinguishable >flows at the network layer between the same two hosts: The network >layer has to keep track of them (if the network layer does not need >to keep track of each flow individually, then you don't need to >distinguish packets in the network layer headers). If you have >several thousand distinguishable flows between two particular hosts, >then how many flows total will you need each router to keep track >of between all hosts? Are you thinking of each router keeping track >of a few million distinguishable flows? How much state will the >routers maintain (and how much do you expect your routers to cost)? Valid business issue but the problem exists a priori in any flow proposal. For example in your idea presented at the TUBA WG I still could come up with thousands of flows too. Its a problem for sure. Thats why I stated above the idea that maybe we need flow IDs for network level packets and something else for transport users of flows. But as I said demux on the granularity of QOS may not be wide enough. >Thus I think that when your high-end servers are talking to each other, >they will need to multiplex multiple transport-user-level flows onto a >much smaller number of network layer flows. I don't think that you need >thousands of flows between the same two hosts individually identified in >network layer headers. I agree in the present IPv4 model of broadcast unicast but not in the case of multicast broadcast/unicast for IPng. In that case the network layer will require differentiation. But your point about separating the two points of flow granularity for business reasons I agree with big time. Good point. thanks /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 06:38:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14406; Thu, 7 Apr 1994 06:38:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA09060; Thu, 7 Apr 1994 06:36:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA09046; Thu, 7 Apr 1994 06:23:21 +1000 From: jcjones@MIT.EDU Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13744; Thu, 7 Apr 1994 06:24:37 +1000 (from jcjones@MIT.EDU) Received: from ATHENA-AS-WELL.MIT.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15244 Thu, 7 Apr 1994 06:07:27 +1000 (from jcjones@MIT.EDU) Received: from CARBONARA.MIT.EDU by MIT.EDU with SMTP id AA01685; Wed, 6 Apr 94 16:04:49 EDT Received: by carbonara.MIT.EDU (5.57/4.7) id AA13083; Wed, 6 Apr 94 16:04:47 -0400 Message-Id: <9404062004.AA13083@carbonara.MIT.EDU> To: Big-Internet@munnari.OZ.AU Subject: Flows Date: Wed, 06 Apr 94 16:04:46 EDT Could someone tell me what flows are? Thanks, J.C. Jones From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:03:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07008; Thu, 7 Apr 1994 03:20:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA08478; Thu, 7 Apr 1994 03:18:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA08457; Thu, 7 Apr 1994 03:14:12 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06812; Thu, 7 Apr 1994 03:15:20 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14520(6)>; Wed, 6 Apr 1994 10:14:41 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 6 Apr 1994 10:14:47 -0700 To: Tony Li Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Costs, Performance and IPng In-Reply-To: tli's message of Mon, 04 Apr 94 15:50:48 -0800. <199404042250.PAA15249@lager.cisco.com> Date: Wed, 6 Apr 1994 10:14:34 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Apr6.101447pdt.12171@skylark.parc.xerox.com> Tony, Regarding your statement, "In the case of SIPP, things are pretty much much pessimally laid out for us.", I have a few questions: - Given that you are talking about a specific architecture/ algorithm/implementation, can you quantify the benefit that would be obtained by changing SIPP to use an "optimal" layout? E.g., would it enable a .1% increase in the packet forwarding rate or a .1% decrease in the amount of state that must be stored? 10%? 1000%? - Assuming that your "Turnipp" proposal represents an optimal layout for your particular architecture, what specific aspects of that layout make it better than the SIPP layout? o is it the fact that the Flow ID is immediately adjacent to the Source Address? o is it the fact that the Flow ID is 64 bits long? o is it something else? o is it some combination of the above? If it is the first item (adjacency of Flow ID and Source Address), it would be possible to rearrange the fields of the SIPP header to satisfy that desire, to the detriment of those for whom it is a performance benefit to have the Hop Limit field in its current position (see old b-i archives). However, I would be loath to change the layout if it provided only a tiny benefit on your particular architecture and a significant penalty on more general-purpose architectures. Steve From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:06:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08403; Thu, 7 Apr 1994 03:58:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA08613; Thu, 7 Apr 1994 03:56:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA08572; Thu, 7 Apr 1994 03:40:50 +1000 Received: from rip.psg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07765; Thu, 7 Apr 1994 03:41:59 +1000 (from randy@psg.com) Received: by rip.psg.com (Smail3.1.28.1 #6) id m0pobbu-00030GC; Wed, 6 Apr 94 10:41 PDT Message-Id: Date: Wed, 6 Apr 94 10:41 PDT From: randy@psg.com (Randy Bush) To: big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? References: <199404061534.AA20416@cider.cisco.com> <9404061313.aa13185@nic.near.net> > If we can't get sites to upgrade just one border router and do a minor > configuration change "for the good of the Internet" and "because my vendor > told me so", how will we ever get them to deploy IPng (which will require > host changes before being fully-functional and again provide little tangible > benefit). Hey! We're just a bottom-feeder, but we're getting BGP4 ROMs and preparing to aggregate. It will just take a coupla weeks. Sheesh, Mon! randy From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:07:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07737; Thu, 7 Apr 1994 03:40:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA08545; Thu, 7 Apr 1994 03:38:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA08523; Thu, 7 Apr 1994 03:28:41 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07353; Thu, 7 Apr 1994 03:29:45 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA24267; Wed, 6 Apr 94 10:23:57 -0700 Received: by xirtlu.zk3.dec.com; id AA14671; Wed, 6 Apr 1994 13:23:52 -0400 Message-Id: <9404061723.AA14671@xirtlu.zk3.dec.com> To: Tony Li Cc: fbaker@acc.com, big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Wed, 06 Apr 94 00:36:36 PDT." <199404060736.AAA22938@lager.cisco.com> Date: Wed, 06 Apr 94 13:23:46 -0400 X-Mts: smtp Tony, >>>The transition plan for Turnipp is dual stack. >>Dual stack WHERE? I agree that hosts want to have native functionality >>eventially, but I continue to believe that a solution that requires this >>day one is not a cost-effective proposal. I think the router should >>translate. >We can argue this till we're all blue in the face. Suffice it to say >that unless you can make translation simpler than the Phase IV->Phase >V translation, I don't believe you have a hope of getting away with >it. In any case, I'm willing to simply disagree pro tem if it allows >us to close other topics. We have more options than we did with Phase IV to Phase V I think as we are only replacing network layer components for interaction between the old and new (if we do this right). Also tunneling will affect the host software and has some complexities to be worked out depending on what we believe per how our customers will want to deploy IPng. I do not believe this is all worked out. There is also the issue of host performance during the transition phase. I think just saying dual stack is not enough more words are needed. And before we throw out translation we should list the reasons and points where one may need translation and then see if it can be technically accomplished. I don't think this is a blue in the face discussion but one that needs to take place, based on customers needs to deploy IPng. We have more option than we did in 1992 with routers performing better and the many improvements in host software for networking. /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:14:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09147; Thu, 7 Apr 1994 04:18:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08656; Thu, 7 Apr 1994 04:16:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08635; Thu, 7 Apr 1994 04:08:34 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04889; Thu, 7 Apr 1994 02:27:32 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA16012; Wed, 6 Apr 94 09:27:11 PDT Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1/SMI-4.1) id AA13447; Wed, 6 Apr 94 09:26:12 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA08400; Wed, 6 Apr 1994 09:27:02 -0700 Date: Wed, 6 Apr 1994 09:27:02 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404061627.AA08400@jurassic.Eng.Sun.COM> To: John Curran Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404060116.aa03608@nic.near.net> Subject: Re: Costs, Performance and IPng John, > Does anyone feel that IPng has to provide particular new features to > make it easier to deploy firewalls? I'd like to hear which features > would be considered useful for this purpose. I don't think it has to make doing firewalls easier, but it shouldn't make them harder either. I think our goals should be to eliminate the need for firewalls in the long term. An IPng should include authentication and privacy mechanisms. My concern is that security (e.g. the lack of) in the Internet is becoming the real limit to growth, not routing and addressing. Given your presentation at the IPng requirements BOF, security in an IPng could become a major "carrot" to get people motivated to deploy it. Bob From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:14:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07793; Thu, 7 Apr 1994 03:42:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA08576; Thu, 7 Apr 1994 03:41:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA08474; Thu, 7 Apr 1994 03:18:24 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02886; Thu, 7 Apr 1994 01:28:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: from GINGER.LCS.MIT.EDU by shark.mel.dit.csiro.au with SMTP id AA19503 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 7 Apr 1994 01:28:19 +1000 Received: by ginger.lcs.mit.edu id AA18173; Wed, 6 Apr 94 11:28:07 -0400 Date: Wed, 6 Apr 94 11:28:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404061528.AA18173@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft you need to be able to group flow specs in a hierarchy to make this stuff fly.... I may cause total melt-down here, but I don't really believe this. I'd like to hear why you think this is true. For what it's worth, my guess is that places where we can do flow aggregation are not going to be widespread, especially if they start doing things like using policy or QOS routing which cause different paths to be taken for given source-destination pairs. It get even harder if they are using resource reservations which have to be enforced. E.g. if two streams sign up for 1 Mbit/sec and 2 Mbit/sec, how can you put them together in a resource class without some state that says how much to give each one? There's also a problem with the naming space; if two flows which can be aggregated have names which cannot be masked so as to create one flow, you either have to i) bash the flow name of one while those packets are on the shared part of the path, and unbash it at the end of that, a potentially recursive process, or ii) have two small bits of state which name the flows, and refer to a common block of state for the rest. All you've done is saved some duplication of data, at the cost of extra complexity. That last point leads into the real argument, which is that the extra complexity may not be worth the savings. I don't see that the state growth issues are going to be unmanageable if we never aggregate flows, and if so, the simplicity of keeping them all separate is the way to go, I think. Assuming flows do not have average bandwidth requirements go down over time (which seems to me a safe bet :-), we've proved that the growth in flows through a switch is bounded by the bandwidth into the switch; i.e. local conditions. In other words, growth elsewhere in the system (i.e. in size, or amount of traffic) won't have much effect on the number of flows through a given switch, providing the average bandwidth does not go down. Since the costs of the switch are directly related to the bandwidth capacity, it's not unreasonable to expect that we'll be able to afford the extra state memory in switches that have more bandwidth, just like phone switches. The numbers aren't that bad: assume you have a switch with 300MBit/sec of incoming bandwidth (e.g. connected to *60* Ethernets, or 6 FDDI rings), and a typical flow wants 10 Kbit/sec (which is low, actually - 100K would be more like it these days). That still only gives you 30K flows through the switch; at 500 bytes per flow of state, that's 15M of memory. You can buy routers with that much off the shelf now... Also, semi-conductor feature size is inversely related to chip size, i.e. you make the chip half the size, it speeds up by a factor of 2. However, when you did that, the memory capacity went up by 4 (the *square*). Economic state/ bandwidth ratios will grow over time, not drop. Given all that, I have to ask: why bother with all the complexity and hassle of aggregating flows anyway? Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:17:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10119; Thu, 7 Apr 1994 04:42:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08751; Thu, 7 Apr 1994 04:40:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08699; Thu, 7 Apr 1994 04:25:38 +1000 Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09522; Thu, 7 Apr 1994 04:26:50 +1000 (from kasten@mailserv-D.ftp.com) Received: from mailserv-D.ftp.com by ftp.com ; Wed, 6 Apr 1994 14:26:42 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA15215; Wed, 6 Apr 94 14:25:50 EDT Date: Wed, 6 Apr 94 14:25:50 EDT Message-Id: <9404061825.AA15215@mailserv-D.ftp.com> To: jcurran@nic.near.net, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 598 > Does anyone feel that IPng has to provide particular new features to > make it easier to deploy firewalls? I'd like to hear which features > would be considered useful for this purpose. John, Firewalls are a solution to a particular problem -- lack of security. Why don't we do our job and focus on the problems that need to be solved (or carrots to be offered) and let the protocol developers do their jobs and come up with (hopefully) ingenious, novel, and new, solutions to the problems. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:17:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10281; Thu, 7 Apr 1994 04:44:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08766; Thu, 7 Apr 1994 04:43:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08676; Thu, 7 Apr 1994 04:20:49 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09406; Thu, 7 Apr 1994 04:22:02 +1000 (from yakov@watson.ibm.com) Message-Id: <9404061822.9406@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1253; Wed, 06 Apr 94 14:21:58 EDT Date: Wed, 6 Apr 94 14:21:58 EDT To: J.Crowcroft@cs.ucl.ac.uk Cc: big-internet@munnari.OZ.AU Subject: Cost, Performance and IPng Jon, >some forms of mobility are based on Dynamic Host COnfiguration - you >need support for that in IPng. soem are based on helping routers at >'home' or 'abroad'. that means you need to change these to do thsi >work - ok, so you don't change the host. but what if my router/helper >is a low cost host (typically, i would use a PC server as my >redierector at a laptop plugin site...) As far as I can see, the above indicates that support for mobility will require new code being added, which is certainly correct. However, I failed to see how the above supports your previous assertion that CLNP code has to change in order to support mobility. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:18:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16077; Thu, 7 Apr 1994 07:18:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09141; Thu, 7 Apr 1994 07:16:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09138; Thu, 7 Apr 1994 07:12:47 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10315; Thu, 7 Apr 1994 04:46:36 +1000 (from yakov@watson.ibm.com) Message-Id: <9404061846.10315@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1793; Wed, 06 Apr 94 14:46:30 EDT Date: Wed, 6 Apr 94 14:46:30 EDT To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU Subject: Turnipp - a merger proposal Ref: Your note of Wed, 06 Apr 94 13:23:46 -0400 Jim, >And before we throw out translation we should list the reasons and >points where one may need translation and then see if it can be >technically accomplished. I'd like to caution people making judgements on purely technical basis (e.g. whether something "can be technically accomplished"). We need also to consider whether it can be deployed and supported in the operational environment of the current Internet (large scale, distributed control, loose coordination, etc...) Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:25:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12179; Thu, 7 Apr 1994 05:38:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08952; Thu, 7 Apr 1994 05:36:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08947; Thu, 7 Apr 1994 05:30:46 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11952; Thu, 7 Apr 1994 05:31:56 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA26170; Wed, 6 Apr 94 15:31:39 EDT Message-Id: <9404061931.AA26170@tipper.oit.unc.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Wed, 06 Apr 94 11:28:07 EDT." <9404061528.AA18173@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Apr 94 15:31:38 -0400 From: Simon E Spero This brings up an interesting question wrt NIMROD; can flows be used as part of a source route-i.e. could you create a source route by concatenating various flows between intermediate routers? Simon // NIMROD - It May Run One Day From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:29:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12293; Thu, 7 Apr 1994 05:42:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08980; Thu, 7 Apr 1994 05:40:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08944; Thu, 7 Apr 1994 05:28:11 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11899; Thu, 7 Apr 1994 05:29:06 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA29505; Wed, 6 Apr 94 12:12:31 -0700 Received: by xirtlu.zk3.dec.com; id AA19559; Wed, 6 Apr 1994 15:12:27 -0400 Message-Id: <9404061912.AA19559@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Wed, 06 Apr 94 14:46:30 EDT." <9404061847.AA27238@decvax.dec.com> Date: Wed, 06 Apr 94 15:12:21 -0400 X-Mts: smtp Yakov, >>And before we throw out translation we should list the reasons and >>points where one may need translation and then see if it can be >>technically accomplished. >I'd like to caution people making judgements on purely technical basis >(e.g. whether something "can be technically accomplished"). We need >also to consider whether it can be deployed and supported in the >operational environment of the current Internet (large scale, >distributed control, loose coordination, etc...) Absolutely. After we know the requirements and using your metrics above we may not need translation and can solve the requirement in another manner. My fear is that we build a set of cabinents in the kitchen for the den (the room next to the kitchen) and when we go to move the cabinets to the den, we cannot get the object through the door way to the den!!! /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:35:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11685; Thu, 7 Apr 1994 05:24:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08917; Thu, 7 Apr 1994 05:22:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08820; Thu, 7 Apr 1994 05:05:10 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04368; Thu, 7 Apr 1994 02:11:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18757; Wed, 6 Apr 94 12:11:41 -0400 Date: Wed, 6 Apr 94 12:11:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404061611.AA18757@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Cc: jnc@ginger.lcs.mit.edu It will be very possible for high-end servers ... to have a need to to support greater than 255 flows multi-process identical source addr/dst addr ... between cooperating machines. I get the sense that some people are suggesting the possibility of identifying flows with the triple source/destination/flow (and wondering if 8 bits might be enough for the latter). I'd like to come at it from a slight different angle from others have. What I see this scheme doing is providing a very large naming space for flows (48+48+8 bits minimum, in anybody's scheme), but preallocating that large naming space out into small chunks, N bits worth per source-destination pair. The likelihood of more than a vanishingly small percentage of these pairs being active at any one time is basically zero. So, that's not the best way to go. Far bettter is to provide a smaller naming space, e.g. source (or destination, for multicast flows) plus larger flow-id, but leave the allocation of it totally up to the user; if they want to devote 50% of it to one source-destination pair, they can. Yes, this turns into more actual bits in the header, but the days of 9.6K lines are fast passing. Overhead is perfectly acceptable provided you get something useful for it, and the cost is reasonable. Think about driving a car; the cars weighs 3K lbs (or 1.5K Kg :-), and the human inside weighs a 20th of that, and it takes *a lot of real energy* to move that car around... Also, is S/D/F the same flow as D/S/F, or not? If it is, you've got a coordination problem where the two ends have to agree, lest they each try and start a flow simultaneously, with the same value for F... Flows might need to be distinguished at the network layer if either of the two following statements are true: (i) they need significantly different qualities of service; (ii) they need to be kept separate to prevent one from stealing resources from the other. What about if their paths diverge at some point? This might happen for a variety of reasons, not just policy; perhaps to get the resources it needed, the second flow had to take a slightly different path at some point? This implies that different network layer flows are needed between the same two hosts only in order to distinguish measureably different quality of service. Nope. The flow will have many attributes other than resources; path, security, accounting (shudder :-), etc. Two flows might differ in any of them... I have another problem with the idea of thousands of distinguishable flows at the network layer between the same two hosts: The network layer has to keep track of them ... If you have several thousand distinguishable flows between two particular hosts, then how many flows total will you need each router to keep track of between all hosts? Are you thinking of each router keeping track of a few million distinguishable flows? How much state will the routers maintain (and how much do you expect your routers to cost)? Your model here is not very well stated. Is the average host going to have several thousand flows, or just the worse case ones? What is going to be the average resource consumption of these several thousand flows? Is the graph of flow length versus % of flows from the host an asymptotic one, or what? When you try and develop models for the growth of flow state, it turns out to be tricky. Andy Molitor suggested a really nice one in which we tried to relate average path length (which would be a function of the diameter of the network, which you can approximate given the number of hosts in the network) and the number of flows in the network total (which you can approximate in similar ways) to the number of routers (similar approximation; the host-router ratio seems to be changing very slowly), and come up with the average number of flows per router. It works; the flow growth should be on average O(G(D)), where G(D) is the growth rate of the diameter. Problem is, it's an *average*; it doesn't say anything about the worst case. A couple of us tried to play around with models for flow length versus % of flows, but without having a topology model (which seemed too thin ice even for us, even though I can handwave extra hard :-) it doesn't help. So, you have to fall back on the bandwidth bound thing. Anyway, maybe there is a problem, but just doing the "millions of flows" bit isn't very productive... Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 07:58:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17681; Thu, 7 Apr 1994 07:58:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09371; Thu, 7 Apr 1994 07:57:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09259; Thu, 7 Apr 1994 07:31:14 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13883; Thu, 7 Apr 1994 06:26:35 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.rmm2.merit.edu ([35.195.225.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA21727 for ; Wed, 6 Apr 1994 16:26:30 -0400 Date: Wed, 6 Apr 94 20:02:13 GMT From: "William Allen Simpson" Message-Id: <2140.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Mobile-IP (was Turnipp) > Date: Wed, 6 Apr 1994 10:31:24 +0600 > From: jim@Tadpole.COM (Jim Thompson) > I certainly hope that what has happened to 'Mobile IP' doesn't > happen to IPng. > Wow. Could you be more specific. Are you saying my editorship is a bad thing? Or that we took too long to arrive where we are? (I agree) Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 08:00:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17750; Thu, 7 Apr 1994 08:00:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09392; Thu, 7 Apr 1994 07:58:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09250; Thu, 7 Apr 1994 07:29:08 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13435; Thu, 7 Apr 1994 06:16:03 +1000 (from yakov@watson.ibm.com) Message-Id: <9404062016.13435@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3301; Wed, 06 Apr 94 16:02:20 EDT Date: Wed, 6 Apr 94 16:02:20 EDT To: jcurran@nic.near.net Cc: big-internet@munnari.OZ.AU Subject: Costs, Performance and IPng Ref: Your note of Wed, 06 Apr 1994 13:12:14 -0400 John, > ] Given your presentation at the IPng requirements BOF, security in > ] an IPng could become a major "carrot" to get people motivated to > ] deploy it. > >We're going to need something; security is certainly a worthwhile >motivator. The real question is whether take the traditional IETF >escape clause of making it optional. Yet another real question is whether the needed security features could be added to IPv4. Could folks on this list who are well-versed in security shed more light on the this (the feasibility of adding the needed security to IPv4) ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 08:08:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16935; Thu, 7 Apr 1994 07:40:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09310; Thu, 7 Apr 1994 07:37:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09259; Thu, 7 Apr 1994 07:31:14 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13883; Thu, 7 Apr 1994 06:26:35 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.rmm2.merit.edu ([35.195.225.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA21727 for ; Wed, 6 Apr 1994 16:26:30 -0400 Date: Wed, 6 Apr 94 20:02:13 GMT From: "William Allen Simpson" Message-Id: <2140.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Mobile-IP (was Turnipp) > Date: Wed, 6 Apr 1994 10:31:24 +0600 > From: jim@Tadpole.COM (Jim Thompson) > I certainly hope that what has happened to 'Mobile IP' doesn't > happen to IPng. > Wow. Could you be more specific. Are you saying my editorship is a bad thing? Or that we took too long to arrive where we are? (I agree) Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 08:18:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18585; Thu, 7 Apr 1994 08:18:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA09467; Thu, 7 Apr 1994 08:17:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA09449; Thu, 7 Apr 1994 08:06:17 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17198; Thu, 7 Apr 1994 07:44:44 +1000 (from kasten@mailserv-D.ftp.com) Received: from mailserv-D.ftp.com by ftp.com ; Wed, 6 Apr 1994 17:44:40 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA18605; Wed, 6 Apr 94 17:43:46 EDT Date: Wed, 6 Apr 94 17:43:46 EDT Message-Id: <9404062143.AA18605@mailserv-D.ftp.com> To: jcurran@nic.near.net Subject: Re: Costs, Performance and IPng From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU Content-Length: 532 > ] My concern is that security (e.g. the lack of) in the Internet is > ] becoming the real limit to growth, not routing and addressing. > > Umm... perhaps. I will note that many people ignore the lessons > learned by others until it happens to them, and hence security may > not be a very strong factor in limiting growth. How many people have explicitly decided to not connect to the Internet? Perhaps because of security? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 08:20:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18615; Thu, 7 Apr 1994 08:20:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA09482; Thu, 7 Apr 1994 08:19:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA09439; Thu, 7 Apr 1994 08:04:37 +1000 Received: from fennel.acc.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16296; Thu, 7 Apr 1994 07:23:03 +1000 (from fbaker@acc.com) Received: from [129.192.69.46] (sb-mac-46.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA10079; Wed, 6 Apr 94 14:22:27 PDT Message-Id: <9404062122.AA10079@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Apr 1994 14:21:30 -0800 To: jcjones@MIT.EDU From: fbaker@acc.com (Fred Baker) Subject: Re: Flows Cc: Big-Internet@munnari.OZ.AU >Could someone tell me what flows are? I beieve that there's an RFC that describes them. This list is using the term in two ways: loosely, a stream of packets or packet trains moving between the same two applications or the same two end stations. tightly, a reservation made with the intermediate systems between here and there that says: please set up a fixed path it needs certain characteristics: ingress point egress point lifetime maximum/nominal data rate Quality of Service (elastic? real time? delay-sensitive?) In the latter case, a flow identifier is assigned that identifies packets on the flow to the routers forwarding them. _______________________________________________________________________ "There's nothing like hay when you're thirsty!" The White King... From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:26:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16123; Thu, 7 Apr 1994 07:20:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09156; Thu, 7 Apr 1994 07:18:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09107; Thu, 7 Apr 1994 07:01:39 +1000 Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07652; Thu, 7 Apr 1994 03:36:22 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12050; Wed, 6 Apr 94 13:17:56 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA22486; Wed, 6 Apr 94 13:29:05 EDT Date: Wed, 6 Apr 94 13:29:05 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404061729.AA22486@pobox.wellfleet> To: craig@aland.bbn.com, tli@cisco.com Subject: Re: Costs, Performance and IPng Cc: big-internet@munnari.OZ.AU Well, I was focussing on the latest fast processors (Alphas, MIPS, Sparcs). These tend to be the type of thing found in networking equipment (good performance/price bounds). If there's another processor base to consider, great, let's add it in. Just give me a list. I symphathize with Tony's inability to quantify their silicon forwarding engine`s performance without giving away proprietary information. There is a trend away from routers which do *all* of the network header processing in a general-purpose processor, towards doing at least *some* of the network layer processing in silicon. This does not need to include all of the processing (a solution that some folks would claim can back you into a corner), but includes more flexible solutions in which part of the network layer processing is done in a general purpose processor, but part of the processing is done in silicon. Obviously the system designers need to look at those particular parts of the data flow which are likely to be a bottleneck, and speed up those parts via application of silicon. This would seem to mean that other processor bases to consider are: (i) 680x0 family processors acting in cooperation with silicon (with tasks split between the two); (ii) RISC processors acting in cooperation with silicon. I would expect that the same trend will eventually effect hosts. Ross From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:26:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16182; Thu, 7 Apr 1994 07:21:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09171; Thu, 7 Apr 1994 07:20:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09104; Thu, 7 Apr 1994 07:01:24 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06967; Thu, 7 Apr 1994 03:18:23 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA23701; Wed, 6 Apr 94 10:13:38 -0700 Received: by xirtlu.zk3.dec.com; id AA14401; Wed, 6 Apr 1994 13:13:33 -0400 Message-Id: <9404061713.AA14401@xirtlu.zk3.dec.com> To: Tony Li Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Sat, 02 Apr 94 00:01:23 PST." <199404020801.AAA01820@lager.cisco.com> Date: Wed, 06 Apr 94 13:13:27 -0400 X-Mts: smtp Hi Tony, I have taken some time to look at TURNIP and it will essentially support what I think is important (adding recent discussions on AS). Mostly it will also let us use IPv4 compatible addresses as long as they exist per the AFI type for transition. One caution I have is that a variable address is nice, but I think we need to define some limit initially for the structures and arrays that will house the IPng address. Even GOSIP did this and we can to. I don't know how but lets suggest an array (that is aligned) for say the next 10 years. The pain to change would be no greater to a host than it was to move to BSD 4.4 socket structure (adding a length field) if we want to in the future extend the address length. We have seen this issue implementing SIPP address sequences, you need to impose some bounds or it gets to ugly to support other IPng requirements. I am not clear dual stack is enough and transition is another discussion. Routing protocols. Well lets look at the limitations of routing protocols now on the system services and architecture. This gets at Dave Clark's suggestion during the requirements BOF at last weeks IETF. Do we like the models of OSI for example imposed on the network environment, could be a sample question? I am going to ask other experts on our IPng implementation team to look at the format too. So the discussion can enter a deeper mode so to speak. This could take us a little time with schedules as you know. thanks /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:26:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16309; Thu, 7 Apr 1994 07:23:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09186; Thu, 7 Apr 1994 07:22:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09132; Thu, 7 Apr 1994 07:11:48 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09107; Thu, 7 Apr 1994 04:16:57 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id LAA23417; Wed, 6 Apr 1994 11:16:27 -0700 Date: Wed, 6 Apr 1994 11:16:27 -0700 From: Tony Li Message-Id: <199404061816.LAA23417@lager.cisco.com> To: craig@aland.bbn.com Cc: rcallon@pobox.wellfleet.com, craig@aland.bbn.com, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: Craig Partridge's message of Wed, 06 Apr 94 10:56:05 -0700 <199404061756.KAA12463@aland.bbn.com> Subject: Costs, Performance and IPng Craig, While I understand this point of view, I'd like to ask folks who believe in silicon to keep in mind that there's another camp (also with adherents) who believe the best way to go fast is to build on commercial processors. (Remember Hennessey and Patterson's argument that special purpose hardware typically has less good performance). Well, the reality is that that the prices we're seeing for commercial processors with enough oomph for high end routers make them a lose/lose proposition. Part of this is that high end routers are a low-volume operation (relative, of course, to the computing industry at large), so the processor manufacturers really put it to you. On the other hand, there are numerous companies here in the valley who are working very hard to help you design custom silicon for Extremely Cheap (e.g., Altera, Xilinx). Our experiences with commercial processors also indicate that they have some other significant architectural drawbacks which I really can't get into in public. Suffice it to say that they need lots of glue around them to keep them at speed because the processor folks concentrate on optimizing stuff in the cache and that I/O is a poor afterthought. [Philosophical rambling about using Von Neuman architectures to do non-Von Neuman tasks omitted.] In some sense, by talking about general purpose processors, I'm trying to guarantee this work applies to IPng as much as Tony and you want to ensure that IPng works with special silicon. (I hope that last sentence made sense...) I don't think that either of us oppose that. We have to consider that too as we all ship lower-cost, lower-performance products. Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:26:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16350; Thu, 7 Apr 1994 07:25:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09201; Thu, 7 Apr 1994 07:23:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09112; Thu, 7 Apr 1994 07:06:03 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08409; Thu, 7 Apr 1994 03:58:46 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00533 for big-internet@munnari.oz.au; Wed, 6 Apr 94 13:57:39 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA12463; Wed, 6 Apr 1994 10:56:06 -0700 Message-Id: <199404061756.KAA12463@aland.bbn.com> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: craig@aland.bbn.com, tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Wed, 06 Apr 94 13:29:05 -0400. <9404061729.AA22486@pobox.wellfleet> From: Craig Partridge Date: Wed, 06 Apr 94 10:56:05 -0700 Sender: craig@aland.bbn.com > There is a trend away from routers which do *all* of the network header > processing in a general-purpose processor, towards doing at least *some* > of the network layer processing in silicon. This does not need to > include all of the processing (a solution that some folks would claim > can back you into a corner), but includes more flexible solutions in > which part of the network layer processing is done in a general purpose > processor, but part of the processing is done in silicon. Obviously the > system designers need to look at those particular parts of the data flow > which are likely to be a bottleneck, and speed up those parts via > application of silicon. Ross: While I understand this point of view, I'd like to ask folks who believe in silicon to keep in mind that there's another camp (also with adherents) who believe the best way to go fast is to build on commercial processors. (Remember Hennessey and Patterson's argument that special purpose hardware typically has less good performance). Furthermore, there's active work afoot to demonstrate that today's general purpose processors can do truly impressive jobs as switching devices (e.g., routers, bridges, etc), if they are programmed carefully and have the right memory management and network interfaces. No special silicon required. I'm hoping we'll see various researchers start to talk about results this summer or late this year. In some sense, by talking about general purpose processors, I'm trying to guarantee this work applies to IPng as much as Tony and you want to ensure that IPng works with special silicon. (I hope that last sentence made sense...) Craig From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:27:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16481; Thu, 7 Apr 1994 07:29:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09245; Thu, 7 Apr 1994 07:28:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09135; Thu, 7 Apr 1994 07:12:38 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09203; Thu, 7 Apr 1994 04:19:56 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA26582; Wed, 6 Apr 94 11:04:47 -0700 Received: by xirtlu.zk3.dec.com; id AA16679; Wed, 6 Apr 1994 14:04:44 -0400 Message-Id: <9404061804.AA16679@xirtlu.zk3.dec.com> To: big-internet@munnari.OZ.AU Cc: Paul Traina , bgpd@merit.edu, bound@zk3.dec.com Subject: Re: Introducing proxy aggregations? In-Reply-To: Your message of "Wed, 06 Apr 94 13:13:09 EDT." <9404061313.aa13185@nic.near.net> Date: Wed, 06 Apr 94 14:04:38 -0400 X-Mts: smtp John, >Paul: > > If we can't get sites to upgrade just one border router and do a minor >configuration change "for the good of the Internet" and "because my vendor >told me so", how will we ever get them to deploy IPng (which will require >host changes before being fully-functional and again provide little tangible >benefit). > > Does "Internet Darwinism" predict NAT boxes for IPng? > >;-) >/John I agree with you regarding the need. But I have worked with many of the fortune 100 companies and for three vendors in my career. I don't think anyone will do anything for the good of network-man-kind. They need a valid business reason presented to them. We are in hard times and most are focusing on how to generate more revenue streams in a very tough economy. I suggest someone put together a white paper from the Internet Society or the IETF or whoever and point out all the valid business reasons why anyone should do what needs to be done. Then it needs to be circulated widely some how and a request for action to be made with very clear plans on how and what needs to be done. Folks are not going to change based on the good of anything (to reiterate) and are not going to change per technical-eeesseee discussions from IETFers. We need a business justification. Henry Ford invented the assembly line so he could make more cars and get more of what he wanted from that revenue stream making him more competitive. He did not do it because everyone was out of work or for man kind. We need to think like captialists. The bottom line question asked will either be whats in it for me or what pain will this avoid for me. Answer those questions and it can happen virtually overnight. The above applys also to the customers using IPng too. /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:28:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16413; Thu, 7 Apr 1994 07:27:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09230; Thu, 7 Apr 1994 07:26:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA09101; Thu, 7 Apr 1994 06:57:46 +1000 Received: from chsun.eunet.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15316; Thu, 7 Apr 1994 06:58:58 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id XAA21477; Wed, 6 Apr 1994 23:01:02 +0200 Message-Id: <199404062101.XAA21477@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <27752-0@magnolia.eunet.ch>; Wed, 6 Apr 1994 22:59:33 +0200 Subject: Re: Introducing proxy aggregations? To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Apr 1994 22:59:29 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9404061839.AA20300@ginger.lcs.mit.edu> from "Noel Chiappa" at Apr 6, 94 02:39:20 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1753 From: Simon Poole Sender: poole@magnolia.eunet.ch Noel writes: > Just out of interest, I assume this provider switch would mean they'd > have to renumber, or are you suggested that the new provider would allow > them to keep their old addresses? If so, how would we *ever* get > aggregation to work? > > One service provider told me years ago that you'd never get people to > renumber when they switched, since providers would use keeping your old > number as a competitive advantage. If so, we're really screwed, since the > aggregation we do will never really catch up with the inevitable address > entropy... Wrong: it's not that people wont renumber; they wont switch in the first place. I quote myself from an article in comp.dcom.sys.cisco: ******************************************************************** > "Domains are encouraged to renumber so that their individual > address allocations do not need to be advertised." > Alas, this disregards one of the fundamental reasons why we have a rapidly growing, competitive market for Internet service provision. The fact that you can change providers with great ease and there is essentially no vendor lock-in. Comparable markets, say for example X.400 service provision, are essentially dead after the initial sale, simply because the cost for the customer to change is nearly always higher than any benefit gained from moving to a better/cheaper service provider. I get a tummy ache everytime somebody mentions provider based adressing for IPng (which is essentially suggested by all current candidates). ******************************************************************** -- EUnet Switzerland Simon Poole Zweierstrasse 35 Tel: +41 1 291 45 80 poole@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=poole;P=EUnet;A=EUnet;C=CH From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:29:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB16708; Thu, 7 Apr 1994 07:33:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09266; Thu, 7 Apr 1994 07:31:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09115; Thu, 7 Apr 1994 07:06:26 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08513; Thu, 7 Apr 1994 04:03:20 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id LAA22540; Wed, 6 Apr 1994 11:02:57 -0700 Date: Wed, 6 Apr 1994 11:02:57 -0700 From: Tony Li Message-Id: <199404061802.LAA22540@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Wed, 6 Apr 1994 10:14:34 PDT <94Apr6.101447pdt.12171@skylark.parc.xerox.com> Subject: Costs, Performance and IPng - Given that you are talking about a specific architecture/ algorithm/implementation, can you quantify the benefit that would be obtained by changing SIPP to use an "optimal" layout? E.g., would it enable a .1% increase in the packet forwarding rate or a .1% decrease in the amount of state that must be stored? 10%? 1000%? It would allow a >25% improvement in certain resources necessary to forward the packet. - Assuming that your "Turnipp" proposal represents an optimal layout for your particular architecture, what specific aspects of that layout make it better than the SIPP layout? o is it the fact that the Flow ID is immediately adjacent to the Source Address? o is it the fact that the Flow ID is 64 bits long? o is it something else? o is it some combination of the above? Something like that. I should point out that I'm trying to do something slightly differently with Turnipp, which is to support global flow ids, not source specific ones. This allows aggregation of flows at appropriate points. The global flow is constructed via concatenation of an integer and the EID of the node generating the flow id. It's very possible that I don't have the flow id big enough yet, as it depends on how big the EID really needs to be. One example would be the 6 byte IEEE 802 address followed by a 2 byte number. If it is the first item (adjacency of Flow ID and Source Address), it would be possible to rearrange the fields of the SIPP header to satisfy that desire, to the detriment of those for whom it is a performance benefit to have the Hop Limit field in its current position (see old b-i archives). Subsequent to my posting, I've moved the Hop Limit back to 1 byte, and it's still located where SIPP has it. Non-issue. [I've also bumped packet lengths up to 3 bytes.] Is this ameanable? Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:34:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16874; Thu, 7 Apr 1994 07:39:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09301; Thu, 7 Apr 1994 07:36:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09118; Thu, 7 Apr 1994 07:07:38 +1000 Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08256; Thu, 7 Apr 1994 03:56:41 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12231; Wed, 6 Apr 94 13:34:52 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA22864; Wed, 6 Apr 94 13:46:01 EDT Date: Wed, 6 Apr 94 13:46:01 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404061746.AA22864@pobox.wellfleet> To: big-internet@munnari.OZ.AU, bsimpson@MorningStar.Com Subject: Re: Costs, Performance and IPng > flows. I agree that a very large number of transport-user level > flows may be necessary between the same two hosts. However, this > does not necessarily mean that thousands of distinguishable flows > between the same two hosts have to be understood by routers and > subnets. > Ross, you are making a mistake I also made a year or so ago. You assume that flows are between a pair of hosts. - Many (if not most) flows are likely to be from one host to many hosts. - Others are likely to be many hosts to many. So, the "broadband" internet needs to support far more than 255 flows per source host, if only to support the "500 channels and still nothing worth watching" model. Bill; Well, you are certainly correct that my message discussed unicast flows, and that multicast flows also need to be thought about. Good point. However, we still could use the destination address as part of the flow ID. In this case, rather than asking "why will we need more than 256 identifiable flows between two hosts", I should have been asking "why will we need more than 255 identifiable flows from any one source address to any one particular destination address (regardless of whether the destination address is unicast or multicast)". This somewhat relates to how multicast addresses are assigned. In your television case, clearly there is a possibility of needing more than 256 television channels. However, would these all be using the same destination address? If so, then will it be necessary to distinguish the flows at the network layer (for example, by giving different service to each one), or will we instead choose to demultiplex using transport ports of some kind? I would think that if 500 different TV stations exist, then there are two likely possibilities: (i) They go to different places (I don't have all 500 arrive at my home). In this case they will need different destination addresses; (ii) They go to the same places, and have similar or identical service requirements. In this case I think they can be part of the same network layer flow, and be demultiplexed at a higher level (probably using transport level port IDs). Of course there is another issue: If we have 500 TV stations arriving at each home, then we are going to need some very good TV program matching service, in order to allow each viewer to find the programs that they want to watch. Perhaps solving application problems like this might be more lucrative in the long run that network layer issues? :-) Ross From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:35:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17798; Thu, 7 Apr 1994 08:02:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA09407; Thu, 7 Apr 1994 08:00:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09206; Thu, 7 Apr 1994 07:24:11 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12170; Thu, 7 Apr 1994 05:37:31 +1000 (from yakov@watson.ibm.com) Message-Id: <9404061937.12170@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2881; Wed, 06 Apr 94 15:37:27 EDT Date: Wed, 6 Apr 94 15:37:27 EDT To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU Subject: Introducing proxy aggregations? Ref: Your note of Wed, 6 Apr 94 14:39:20 -0400 Noel, >I assume this provider switch would mean they'd have to >renumber, or are you suggested that the new provider would >allow them to keep their old addresses ? If so, how would >we *ever* get aggregation to work ? First of all, aggregation may occur at the level above the immediate providers (e.g. two providers, A and B, are both connected to some backbone X; when a site switches from provider A to provider B but doesn't renumber, X still can aggregate the site's routing information with the rest of the routing information coming from A) So, even if sites wouldn't renumber, there are ways to aggregate the routing information. >One service provider told me years ago that you'd never get people >to renumber when they switched... On the one hand I've been hearing assertions that renumbering is almost "close to impossible". On the other hand, I know first hand of few places that did renumbering of few hundred machines, and it didn't consume an unsurmountable amount of efforts. So, I guess renumbering is feasible. That doesn't mean that renumbering is a "piece of cake". There are things we can (and should) do to facilitate renumbering. For example, widely deployed DHCP would be of great help. As a side comment, I'd like to point out that ALL of the existing IPng assume provider-based address assignment. As a corollary, in order to contain the volume of routing information switching providers would require renumbering with any of the IPng we have today on the table. So, I guess renumbering is likely to become a permanent fixture in the Internet, and we need to focus on how to make renumbering as simple as possible. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 09:37:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17870; Thu, 7 Apr 1994 08:03:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA09424; Thu, 7 Apr 1994 08:02:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09118; Thu, 7 Apr 1994 07:07:38 +1000 Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08256; Thu, 7 Apr 1994 03:56:41 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12231; Wed, 6 Apr 94 13:34:52 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA22864; Wed, 6 Apr 94 13:46:01 EDT Date: Wed, 6 Apr 94 13:46:01 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404061746.AA22864@pobox.wellfleet> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: Costs, Performance and IPng > flows. I agree that a very large number of transport-user level > flows may be necessary between the same two hosts. However, this > does not necessarily mean that thousands of distinguishable flows > between the same two hosts have to be understood by routers and > subnets. > Ross, you are making a mistake I also made a year or so ago. You assume that flows are between a pair of hosts. - Many (if not most) flows are likely to be from one host to many hosts. - Others are likely to be many hosts to many. So, the "broadband" internet needs to support far more than 255 flows per source host, if only to support the "500 channels and still nothing worth watching" model. Bill; Well, you are certainly correct that my message discussed unicast flows, and that multicast flows also need to be thought about. Good point. However, we still could use the destination address as part of the flow ID. In this case, rather than asking "why will we need more than 256 identifiable flows between two hosts", I should have been asking "why will we need more than 255 identifiable flows from any one source address to any one particular destination address (regardless of whether the destination address is unicast or multicast)". This somewhat relates to how multicast addresses are assigned. In your television case, clearly there is a possibility of needing more than 256 television channels. However, would these all be using the same destination address? If so, then will it be necessary to distinguish the flows at the network layer (for example, by giving different service to each one), or will we instead choose to demultiplex using transport ports of some kind? I would think that if 500 different TV stations exist, then there are two likely possibilities: (i) They go to different places (I don't have all 500 arrive at my home). In this case they will need different destination addresses; (ii) They go to the same places, and have similar or identical service requirements. In this case I think they can be part of the same network layer flow, and be demultiplexed at a higher level (probably using transport level port IDs). Of course there is another issue: If we have 500 TV stations arriving at each home, then we are going to need some very good TV program matching service, in order to allow each viewer to find the programs that they want to watch. Perhaps solving application problems like this might be more lucrative in the long run that network layer issues? :-) Ross From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 13:10:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21316; Thu, 7 Apr 1994 09:38:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA09599; Thu, 7 Apr 1994 09:37:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA09596; Thu, 7 Apr 1994 09:34:39 +1000 Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16820; Thu, 7 Apr 1994 07:36:36 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA15329; Wed, 6 Apr 94 17:18:33 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA27875; Wed, 6 Apr 94 17:29:42 EDT Date: Wed, 6 Apr 94 17:29:42 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404062129.AA27875@pobox.wellfleet> To: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Costs, Performance and IPng I get the sense that some people are suggesting the possibility of identifying flows with the triple source/destination/flow (and wondering if 8 bits might be enough for the latter). This has been thrown out as a possibility (although I am not sure that anyone is actively pursuing this at this time). What I see this scheme doing is providing a very large naming space for flows (48+48+8 bits minimum, in anybody's scheme), but preallocating that large naming space out into small chunks, N bits worth per source-destination pair. The likelihood of more than a vanishingly small percentage of these pairs being active at any one time is basically zero. So, that's not the best way to go. Far better is to provide a smaller naming space, e.g. source (or destination, for multicast flows) plus larger flow-id, but leave the allocation of it totally up to the user; if they want to devote 50% of it to one source-destination pair, they can. The notion is that source and destination address is already needed in the header (although you could of course imagine other schemes in which the addresses are not carried, such as ATM data packets on an existing connection). There also seems to be am implicit issue in all of this which is that we don't seem to have a widespread agreement regarding what flow IDs (or flows for that matter) are going to be used for. Also, is S/D/F the same flow as D/S/F, or not? If it is, you've got a coordination problem where the two ends have to agree, lest they each try and start a flow simultaneously, with the same value for F... Not. The two directions require different flow IDs. This is certainly the case for "source address + flow ID" and "local flow ID only" solutions, which are two other suggestions that I have seen. Flows might need to be distinguished at the network layer if either of the two following statements are true: (i) they need significantly different qualities of service; (ii) they need to be kept separate to prevent one from stealing resources from the other. What about if their paths diverge at some point? This might happen for a variety of reasons, not just policy; perhaps to get the resources it needed, the second flow had to take a slightly different path at some point? I would include this as different qualities of service (implying that if there is some sort of security specification that impacts the path, then this is included in the terminology "Quality of Service"). This implies that different network layer flows are needed between the same two hosts only in order to distinguish measureably different quality of service. Nope. The flow will have many attributes other than resources; path, security, accounting (shudder :-), etc. Two flows might differ in any of them... I think that we differ on this point only with respect to the definition of the term QOS. I have another problem with the idea of thousands of distinguishable flows at the network layer between the same two hosts: The network layer has to keep track of them ... If you have several thousand distinguishable flows between two particular hosts, then how many flows total will you need each router to keep track of between all hosts? Are you thinking of each router keeping track of a few million distinguishable flows? How much state will the routers maintain (and how much do you expect your routers to cost)? Your model here is not very well stated. Actually, I think that I am asking questions in the belief that we need to get answers to them. Thus perhaps I am suggesting that *our* model is not well stated. Is the average host going to have several thousand flows, or just the worse case ones? What is going to be the average resource consumption of these several thousand flows? Is the graph of flow length versus % of flows from the host an asymptotic one, or what? If only a very small number of source/destination pairs require thousands of flows, then you could just give those few systems multiple addresses (and distinguish the flows via the different addresses). Alternatively, you could use a large flow ID. However, this is still not addressing what I see as the real issue here: What are we actually thinking that flows will be used for? Whatever this is, do we think that we might have one or five between a particular source host and destination address (unicast or multicast), or do we expect to have thousands between one source host and one destination address? If the latter, then why? Ross From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 13:59:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01761; Thu, 7 Apr 1994 13:59:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA09872; Thu, 7 Apr 1994 13:57:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA09858; Thu, 7 Apr 1994 13:46:11 +1000 Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29243; Thu, 7 Apr 1994 12:59:06 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA15524; Wed, 6 Apr 94 19:53:04 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA14455; Wed, 6 Apr 1994 22:54:33 -0400 Message-Id: <9404070254.AA14455@skidrow.lkg.dec.com> To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Wed, 06 Apr 94 16:02:20 EDT." <9404062016.13435@munnari.oz.au> Date: Wed, 06 Apr 94 22:54:33 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I certainly think it is feasible to add security to IPv4. I've even posted an incomplete proposal to the ipsec Working Group mailing list (ipsec@ans.net). Donald From: yakov@watson.ibm.com To: jcurran@nic.near.net Cc: big-internet@munnari.oz.au >Ref: Your note of Wed, 06 Apr 1994 13:12:14 -0400 > > >John, > >> ] Given your presentation at the IPng requirements BOF, security in >> ] an IPng could become a major "carrot" to get people motivated to >> ] deploy it. >> >>We're going to need something; security is certainly a worthwhile >>motivator. The real question is whether take the traditional IETF >>escape clause of making it optional. > >Yet another real question is whether the needed security features >could be added to IPv4. Could folks on this list who are well-versed >in security shed more light on the this (the feasibility of adding >the needed security to IPv4) ? > >Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 14:18:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02588; Thu, 7 Apr 1994 14:18:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA09906; Thu, 7 Apr 1994 14:17:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA09892; Thu, 7 Apr 1994 14:03:22 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01917; Thu, 7 Apr 1994 14:03:52 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 7 Apr 94 12:57:27 +0900 From: Masataka Ohta Message-Id: <9404070357.AA00787@necom830.cc.titech.ac.jp> Subject: Re: Flows To: jcjones@MIT.EDU Date: Thu, 7 Apr 94 12:57:26 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9404062004.AA13083@carbonara.MIT.EDU>; from "jcjones@MIT.EDU" at Apr 6, 94 4:04 pm X-Mailer: ELM [version 2.3 PL11] > Could someone tell me what flows are? A flow is a unit of QoS assurance. So, while several connections may be aggregated into a single flow, aggregation of flows is not so meaningful. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 15:21:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00101; Thu, 7 Apr 1994 13:19:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA09819; Thu, 7 Apr 1994 13:17:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA09805; Thu, 7 Apr 1994 13:03:04 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23142; Thu, 7 Apr 1994 10:22:17 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA27926 for big-internet@munnari.oz.au; Wed, 6 Apr 94 20:21:14 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id RAA13033; Wed, 6 Apr 1994 17:15:50 -0700 Message-Id: <199404070015.RAA13033@aland.bbn.com> To: Ross Callon Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Wed, 06 Apr 94 17:29:42 -0400. <9404062129.AA27875@pobox.wellfleet> From: Craig Partridge Date: Wed, 06 Apr 94 17:15:48 -0700 Sender: craig@aland.bbn.com However, this is still not addressing what I see as the real issue here: What are we actually thinking that flows will be used for? Whatever this is, do we think that we might have one or five between a particular source host and destination address (unicast or multicast), or do we expect to have thousands between one source host and one destination address? If the latter, then why? Ross: I need to write up the INT SERV WG minutes where we talked about flow ids and how they are used. But let me take a stab at this briefly. My expectation is there will certainly be tens and possibly hundreds of flows between any two hosts. Here's one example of such a case. Imagine a movie server delivering a video to a bunch of heterogeneous sites (some with black and white displays, some with color, of varying degrees of resolution). The only solution I've heard of so far for heterogeneous video receivers is to do multi-layered encoding, so that routers in the network can send unwanted parts of the video flow to the bit bucket. (Don't flame about this option before one thinks about whether one prefers forwarding bits a particular receiver won't use rather than routing to the bit bucket -- oh yes, and how one explains to the person at the end of a bandwidth starved link that they can't get black and white video because we'll only forward the ten times larger color stream and won't trim it to black and white for them). So now the question is how many layers of encoding (each with a separate flow ID) will be in use? 4 or 5? That's for one video stream. Now image that what we're actually watching is a set of flows that sends all information from all the cameras at a sporting event to a multicast group (and you pick out which ones you want and b/w or color). Ten cameras, each stream multilayered encoded, and we've got 50 flow ids for one application. Craig From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 15:38:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05648; Thu, 7 Apr 1994 15:38:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA09995; Thu, 7 Apr 1994 15:37:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA09992; Thu, 7 Apr 1994 15:29:45 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02067; Thu, 7 Apr 1994 14:05:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25113; Thu, 7 Apr 94 00:05:16 -0400 Date: Thu, 7 Apr 94 00:05:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404070405.AA25113@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Cc: jnc@ginger.lcs.mit.edu The notion is that source and destination address is already needed in the header... I understood this practical issue ("this turns into more actual bits in the header"), but I was looking at it from the point of view of "does this naming space have useful characteristics"; I think a very large space preallocated into leeeetle tiiiiny chunks, most of which you'll never use, is not such a great idea. The two directions require different flow IDs. This is certainly the case for "source address + flow ID" and "local flow ID only" solutions, which are two other suggestions that I have seen. Not necessarily. For instance, now that Nimrod wants to be able to bash flow-id's in flight, it can't overload the source "address" as part of the logical flow-id, but rather needs a whole separate flow-id field which, by itself, identifies the flow. That being the case, you could have a bidirectional flow (half the state requirements :-) which is identified by the "setup host ID + local flow-id" in both directions. Speaking of bidirectional flows, how useful (if at all) are they anyway? They do have some advantages, e.g. in access control and billing. If only a very small number of source/destination pairs require thousands of flows, then you could just give those few systems multiple addresses (and distinguish the flows via the different addresses). Alternatively, you could use a large flow ID. Ah, I thought you were worried about state growth in the routers, with many flows. The naming is a different issue. Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 18:31:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06485; Thu, 7 Apr 1994 15:58:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA10039; Thu, 7 Apr 1994 15:57:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA10022; Thu, 7 Apr 1994 15:44:41 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04416; Thu, 7 Apr 1994 15:04:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25697; Thu, 7 Apr 94 01:04:41 -0400 Date: Thu, 7 Apr 94 01:04:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404070504.AA25697@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Cc: jnc@ginger.lcs.mit.edu This brings up an interesting question wrt NIMROD; can flows be used as part of a source route-i.e. could you create a source route by concatenating various flows between intermediate routers? This mailing list probably doesn't care about the details (see the recent Nimrod rough draft Nimrod architecture document, and WG mail archives for those), but if you "look underneath the sheets" of both the source-routed forwarding mode, and the datagram forwarding mode, you'll see flows used to implement them. There are a number of reasons; efficiency, robustness, etc. NIMROD - It May Run One Day Maybe even in my lifetime! :-) If only all these fascinating discussions on Big-I, RSVP, etc would stop! Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 18:35:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06544; Thu, 7 Apr 1994 16:01:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA10054; Thu, 7 Apr 1994 16:00:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA10025; Thu, 7 Apr 1994 15:48:41 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04232; Thu, 7 Apr 1994 14:59:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25643; Thu, 7 Apr 94 00:57:31 -0400 Date: Thu, 7 Apr 94 00:57:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404070457.AA25643@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU Subject: Re: Flows Cc: jnc@ginger.lcs.mit.edu Could someone tell me what flows are? Well, you'll get different answers from different people. Here's my take on it. A flow, from the user's point of view, is a sequence of packets which are associated, usually by being from a single application instance. In an internetwork layer which has a more complex service model (e.g. supports more flexible routing, resource allocation, accounting/billing, access control, etc), the flow would have service demands to give to some or all of these subsystems. To give concrete examples, a number of TCP connections might all be part of the same flow, e.g. with FTP where you have the control connection, and a number of data connections. A single application might also have a number of flows; e.g. in a multi-media conference, you'd have one flow for the audio, another for a graphic window, etc, with different resource requirments in terms of bandwidth, delay, etc. From the point of view of the network, and at a level of abstract fundamentals, I think there are two reasons for flows. First, to the extent that you have what I call "service state" in the routers (e.g. a resource allocation), i.e. state which is inherently associated with a number of packets over some time-frame (thereby changing the "stateless" model of routers), you have to be able to associate that state with the packets it goes with. This is a fundamental reason for flows. Second, if the user has requirements in a number of areas (e.g. routing and access control), they can theoretically communicate these to the routers by placing a copy of all the relevant information in each packet (in the internetwork header). If many subsystems of the internetwork are involved, and the requirements are complex, this could be a lot of bits. If something is going to generate lots of packets, it makes engineering sense to give all this information to the routers once, and from then on have a "tag" in the packet which tells the routers where to find that information. This is purely an engineering efficiency reason. Obviously, once you've got flows for the first reason, it makes it even easier to bite the bullet on having them for the second reason. The flow could be identified by a "tag" consisting of a number of fields (such as addresses, ports, etc), as opposed to a specialized "flow-id" field. However, it may be more straightforward, and foolproof, to simply identify the flow a packet belongs to with a "flow id" field in the internetwork header. Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 19:18:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14082; Thu, 7 Apr 1994 19:18:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA10289; Thu, 7 Apr 1994 19:17:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA10280; Thu, 7 Apr 1994 19:12:39 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10954; Thu, 7 Apr 1994 18:00:49 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404070800.10954@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 7 Apr 1994 09:00:18 +0100 To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: Cost, Performance and IPng In-Reply-To: Your message of "Wed, 06 Apr 94 14:21:58 EDT." <9404061822.9406@munnari.oz.au> Date: Thu, 07 Apr 94 09:00:18 +0100 From: Jon Crowcroft >>work - ok, so you don't change the host. but what if my router/helper >>is a low cost host (typically, i would use a PC server as my >>redierector at a laptop plugin site...) > As far as I can see, the above indicates that support for mobility > will require new code being added, which is certainly correct. > However, I failed to see how the above supports your previous > assertion that CLNP code has to change in order to support mobility. look - if i change _any_ kernel code is a system, i am quite happy to change the whole comms code - so are a lot of manufacturers (c.f. SunOS to Solaris went from berkeley to mentat TCP code...) so if i want my (any) laptop to also be a mobile clnp (ipng) router, then great.... actually, i think all hosts should be stub routers and use neighbnour disovery instead of special purpose ES-IS Protocols - that wqay mobility is trivial (or else use multicast groups of 1 for mobility...) but then i always have extreme views:-) jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 20:35:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13047; Thu, 7 Apr 1994 18:49:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA10239; Thu, 7 Apr 1994 18:47:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA10192; Thu, 7 Apr 1994 18:24:25 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11997; Thu, 7 Apr 1994 18:24:46 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404070824.11997@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 7 Apr 1994 09:22:36 +0100 To: Craig Partridge Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Wed, 06 Apr 94 17:15:48 PDT." <199404070015.RAA13033@aland.bbn.com> Date: Thu, 07 Apr 94 09:22:33 +0100 From: Jon Crowcroft > My expectation is there will certainly be tens and possibly hundreds >of flows between any two hosts. nope - 10,000s - imagine a web server with multimedia (or just look at ours:-) clients will access it and randomly trawl through different media, each requireing different flow specs to deliver the info to the client...but all within a single session.... > So now the question is how many layers of encoding (each with a separate >flow ID) will be in use? 4 or 5? That's for one video stream. well, here i agree somewhere in the region of several layers, > Now image that what we're actually watching is a set of flows that sends >all information from all the cameras at a sporting event to a multicast >group (and you pick out which ones you want and b/w or color). Ten cameras, >each stream multilayered encoded, and we've got 50 flow ids for one >application. sounds about ok...why not make it 255...just to be safe:-) jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 21:19:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12574; Thu, 7 Apr 1994 18:39:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA10213; Thu, 7 Apr 1994 18:37:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA10210; Thu, 7 Apr 1994 18:30:23 +1000 Received: from midas.london.micrognosis.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07154; Thu, 7 Apr 1994 16:17:29 +1000 (from imarr@london.micrognosis.com) Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA08719; Thu, 7 Apr 94 07:16:25 BST Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma008713; Thu Apr 7 07:15:53 1994 Received: from moria by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA18765; Thu, 7 Apr 94 07:15:51 BST From: imarr@london.micrognosis.com (Ian Marr) Received: by moria (4.1//ident-1.0) id AA17904; Thu, 7 Apr 94 07:15:50 BST Message-Id: <9404070615.AA17904@moria> Subject: Re: Costs, Performance and IPng To: kasten@ftp.com Date: Thu, 7 Apr 1994 07:15:50 +0100 (BST) Cc: jcurran@nic.near.net, Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: <9404062143.AA18605@mailserv-D.ftp.com> from "Frank Kastenholz" at Apr 6, 94 05:43:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 856 Frank Kastenholz writes: > > How many people have explicitly decided to not connect to the > Internet? Perhaps because of security? I know of at least one financial instition in the City of London who has *not* connected to the Internet because of security. I'm sure there are many more (but unless they have a secure connection they can't respond :-). We, Micrognosis, took about 9 months (or more) to come up with a secure enough method of direct connection. I believe it is big requirement of any new protocol and a (limiting) factor now. Security would be a carrot to migrate. Ian. ------------------------------------------------------------------------------ Ian Marr, Systems Manager, Micrognosis, 63 Queen Victoria St, London, EC4N 4UD imarr@london.micrognosis.com +44-71-815-5254 From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 21:38:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19177; Thu, 7 Apr 1994 21:38:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA10445; Thu, 7 Apr 1994 21:37:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA10440; Thu, 7 Apr 1994 21:26:17 +1000 Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13811; Thu, 7 Apr 1994 19:15:12 +1000 (from whyman@mwassocs.demon.co.uk) Date: Thu, 07 Apr 1994 10:05:46 BST Message-Id: <9404071005.aa749@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Turnipp - a merger proposal X-Mailer: Cinetic Mail Manager V2.1 | |From: bound@zk3.dec.com | |One caution I have is that a variable address is nice, but I think we | |need to define some limit initially for the structures and arrays that | |will house the IPng address. Even GOSIP did this and we can to. I take the opposite view. Imposing a limit other than that imposed by the address length field itself is unnecessary and does no more than impose an artificial limit on both growth and possible uses of a large address space. The only case where pragmatic limit on the address itself is useful is in profiles for routers within a given class of Routing Domain, when you do want to have all routers capable of handling a minimum length address for destinations within the RD (but not external destinations). There is also a case for profiles specifying a minimum address prefix length to be supported for inter-domain routing, but this is a complex issue, with routers in different parts of the topology having requirements for different minimum prefix length support, depending on the addressing plan and its deployment. In the short term it is quite reasonable to make recommendations on the minimum support requirements for routing to addresses within an RD, and for address prefixes in inter-domain routing. However, while implementation of such minima will impose practical limits on addresses within RDs that implement to the minimum requirement, it should not translate into imposing a similar maximum length on the address in someone else's RD. | |Routing protocols. Well lets look at the limitations of routing | |protocols now on the system services and architecture. This gets at | |Dave Clark's suggestion during the requirements BOF at last weeks IETF. | |Do we like the models of OSI for example imposed on the network | |environment, could be a sample question? I doubt whether Tony Li's proposal does impose an OSI model on the Internet other than the NSAP Address and the notions of Routing Domains and RDC's implied by using IDRP. The NSAP Address is the key unifying part of the proposal, and IDRP provides the common routing protocol that can make a scaleable Internet. Although the original proposal also mentioned IS-IS and ES- IS, they should only be regarded as recommendations as IDRP does not prescribe the intra-domain routing protocol and users are free to choose an intra-domain routing protocol appropriate to their circumstances. The true significance of ES-IS and IS-IS is that they exist and by existing make the proposal to use NSAP Addresses a realistic one. If the aim of a unified proposal was to take the best bits, then in the inclusion of NSAP Addressing and IDRP, Tony Li has taken the best bits out of Tuba (although there are some other good bits that shouldn't be lost). -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 22:02:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16128; Thu, 7 Apr 1994 20:18:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA10358; Thu, 7 Apr 1994 20:17:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA10355; Thu, 7 Apr 1994 20:10:17 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11807; Thu, 7 Apr 1994 18:22:07 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404070822.11807@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 7 Apr 1994 09:11:52 +0100 To: jcjones@MIT.EDU Cc: Big-Internet@munnari.OZ.AU Subject: Re: Flows In-Reply-To: Your message of "Wed, 06 Apr 94 16:04:46 EDT." <9404062004.AA13083@carbonara.MIT.EDU> Date: Thu, 07 Apr 94 09:11:49 +0100 From: Jon Crowcroft >Could someone tell me what flows are? J.C. a flow is a sequence of packets from 1 or more sources to one or more (possibly multicast) destinations, which are treated according to the same rules with regard to path selction constraints and queueing behaviour in itnermediate nodes, w.r.t throughput, delay and loss. if the path is nailed down, then its like an ATM Virtual Path(VP) (note, not a VC). if the flow involves only a single source/destination pair and the path is nailed down, then its like a Virtual Circuit (VC). a flow may be deduced from fields in the packet implicitly e.g. source + destiantion IP addresses, transport protocol, ports, or it may be indicated , as in SIPP, by a new field, a flow id. This flow id may be a random number generated at source, but the same for subsequent packets in the same flow, or it may be a well known function of the fields in the packet. If it depends on external information (e.g. the packets are detainted to a multicast group, and the receivers indicate QoS rules via RSVP or SNMP, or it is subject to link sharing rules on some paths, which are programmed into routers via SNMP or other), then the routers along the path may still be able to construct partial forwarding information based on fields in the packet, or they may not. for the path to be fate sharing, end systems must refresh such out-of-band information periodically, if its needed to treat the packet right. flows that are indicated by flow ids may permit very fast forwarding since they may indicate the path. some flow-id designs do not do this, and have to be used in conjunction with source/destiantion addresses to give a 2 stage lookup, route, then queuing treatment. asking about flows when you come from MIT is a bit like asking about unix when you come from berkeley:-) jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 23:18:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22967; Thu, 7 Apr 1994 23:18:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA10552; Thu, 7 Apr 1994 23:17:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA10549; Thu, 7 Apr 1994 23:14:06 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22860; Thu, 7 Apr 1994 23:15:14 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404071315.22860@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 7 Apr 1994 14:13:59 +0100 To: whyman@mwassocs.demon.co.uk Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 07 Apr 94 10:05:46 BST." <9404071005.aa749@mwassocs.demon.co.uk> Date: Thu, 07 Apr 94 14:13:57 +0100 From: Jon Crowcroft >| |From: bound@zk3.dec.com >| |One caution I have is that a variable address is nice, but I think we >| |need to define some limit initially for the structures and arrays that >| |will house the IPng address. Even GOSIP did this and we can to. >I take the opposite view. Imposing a limit other than that imposed by the >address length field itself is unnecessary and does no more than impose an >artificial limit on both growth and possible uses of a large address space. in an aside to tony li, i agreed that if the ipng has a good flow id design (32-64bits) that allows source/dest independent fast lookup (i.e. is a hash of source+dst+qos), then i see no problem with variable length addresses - they are only a problem if you only have them to parse to decide on link share & route lookup and you want to combine the stages of parsing flows with partially different source/destination prefixes to get aggregation of packet classification.... but if ipng has flow ids, then this is only done when the flow-id lookup fails....so would normally be in the nature of a cache miss...a rare event... so tony's proposal has good merits....i think.... jon From owner-Big-Internet@munnari.OZ.AU Thu Apr 7 23:22:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23062; Thu, 7 Apr 1994 23:22:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA10567; Thu, 7 Apr 1994 23:21:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA10546; Thu, 7 Apr 1994 23:12:30 +1000 Received: from bodhi.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22633; Thu, 7 Apr 1994 23:13:43 +1000 (from atkinson@bodhi.itd.nrl.navy.mil) From: Ran Atkinson Message-Id: <9404070908.ZM1445@bodhi.itd.nrl.navy.mil> Date: Thu, 7 Apr 1994 09:08:25 -0400 In-Reply-To: bound@zk3.dec.com "You may want to jump into this one .../jim" (Apr 7, 0:03) References: <9404070403.AA05420@xirtlu.zk3.dec.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 23feb94) To: big-Internet@munnari.OZ.AU Subject: Re: YoIPng Security Issues Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@bodhi.itd.nrl.navy.mil ------ begin quoted note -------------------------------------------- John, > ] Given your presentation at the IPng requirements BOF, security in > ] an IPng could become a major "carrot" to get people motivated to > ] deploy it. > >We're going to need something; security is certainly a worthwhile >motivator. The real question is whether take the traditional IETF >escape clause of making it optional. Yet another real question is whether the needed security features could be added to IPv4. Could folks on this list who are well-versed in security shed more light on the this (the feasibility of adding the needed security to IPv4) ? Yakov. ------- End of Quoted Message ------------------------------------ Folks, The SIPP Encapsulating Security Payload (ESP) is similar to existing security protocols for IP (e.g. US Gov't's SP3D) and is similar to the ISO Network Layer Security Protocol (NLSP) which is intended for use with CLNP. ESP is more streamlined syntactically than either SP3D or NLSP. [NB: The current ESP draft has bugs in the section on its use with DES CBC which will be fixed soon.] If the IPv4 Security WG were to develop a key mgmt protocol, then SIPP would like to reuse that. Had there been an agreed upon IPv4 Security Protocol, the SIPP ESP would have been closely modelled upon that. Alas, no such consensus exists and so there exists no IETF IPv4 Security Protocol that ESP could model. There is an IETF working group on an IPv4 Security Protocol. It has made no visible progress in over a year. There are about 4 packet formats on the table (Zmuda & Lambert's IPSP, swIPe, PIPS, I-NLSP) and there seems to be little working group consensus on which packet format to use. There has been little discussion on the IPv4 Security Protocol WG list. There has been a fair amount of consensus in that working group that some sort of Diffie-Hellman key mgmt mechanism should be used and there is some offline activity on key mgmt. Also, the DNS Security proposal (currently an I-D) includes a mechanism for distributing host public keys. This last mechanism is important becuase of the authentication problem resulting from the "Man in the Middle" attack on pure Diffie-Hellman. SIPP includes an Authentication Header (AH) to provide strong authentication of datagrams (see draft-ietf-sipp-ap-*.txt). The SIPP Authentication Header is not really feasible with IPv4 because of the limited space for options in the IPv4 Header. One of the advantages of SIPP is that optional headers are daisy-chained which not only makes parsing easier but also removes this limitation. The SIPP Authentication Header is being implemented by vendors and is included in the base SIPP specification (i.e. all systems must implement it). Deployment and use of the SIPP Authentication Header would eliminate a large portion of the network attacks currently underway. Note that despite marketing from some crypto vendors, an IPv4 Security Protocol won't solve all problems. Some upper-layer protocols need to include strong authentication within that upper-layer protocol to provide protection against obvious attacks, even if an IPv4 Security Protocol existed. Mobile IP is an example of this and now includes support for keyed MD5 authentication in the mobile node registration protocol (while planning to use the future IPv4 Security Protocol {or SIPP ESP} to provide confidentiality). Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 00:38:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26571; Fri, 8 Apr 1994 00:38:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA10657; Fri, 8 Apr 1994 00:37:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA10654; Fri, 8 Apr 1994 00:36:20 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19962; Thu, 7 Apr 1994 21:57:55 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA00742; Thu, 7 Apr 1994 14:00:53 +0200 Message-Id: <199404071200.AA00742@mitsou.inria.fr> To: whyman@mwassocs.demon.co.uk Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 07 Apr 1994 10:05:46 -0000." <9404071005.aa749@mwassocs.demon.co.uk> Date: Thu, 07 Apr 1994 14:00:52 +0200 From: Christian Huitema => | |From: bound@zk3.dec.com => | |One caution I have is that a variable address is nice, but I think we => | |need to define some limit initially for the structures and arrays that => | |will house the IPng address. Even GOSIP did this and we can to. => => I take the opposite view. Imposing a limit other than that imposed by the => address length field itself is unnecessary and does no more than impose an => artificial limit on both growth and possible uses of a large address space. Variable length addresses are fine, but fixed length have advantages, notably when handling source routes. One of the neat points of the SIPP design is that it allows variable length "by chunks of 64bits" while retaining a fixed format header. The inconveniency of doing source routes with variable length address show in CLNP, where routers have to look inside the option field to determine the currently active destination address - not to mention that poor implementations that would not examine the option field might generate loops. If one wants to remove the need for every intermediate router to examine the option field, then one must be ready to recompose a new header at each source routed relay. Which is probably not a zero cost operation. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 01:38:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29081; Fri, 8 Apr 1994 01:38:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA10778; Fri, 8 Apr 1994 01:37:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA10764; Fri, 8 Apr 1994 01:20:46 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28454; Fri, 8 Apr 1994 01:22:01 +1000 (from kasten@mailserv-D.ftp.com) Received: from mailserv-D.ftp.com by ftp.com ; Thu, 7 Apr 1994 11:21:58 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA24904; Thu, 7 Apr 94 11:21:05 EDT Date: Thu, 7 Apr 94 11:21:05 EDT Message-Id: <9404071521.AA24904@mailserv-D.ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: Costs, Performance and IPng From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 2270 > The two directions require different flow IDs. This is certainly the case > for "source address + flow ID" and "local flow ID only" solutions, which > are two other suggestions that I have seen. > > Not necessarily. For instance, now that Nimrod wants to be able to bash > flow-id's in flight, it can't overload the source "address" as part of the > logical flow-id, but rather needs a whole separate flow-id field which, by > itself, identifies the flow. That being the case, you could have a > bidirectional flow (half the state requirements :-) which is identified by the > "setup host ID + local flow-id" in both directions. > > Speaking of bidirectional flows, how useful (if at all) are they anyway? They > do have some advantages, e.g. in access control and billing. I think very. Obviously, a bi-directional flow could be built as two unidirectional flows with "identical" requirements so from a "keep it as simple a possible" perspective, bidirectional flows are not needed. However, Bi-directional may be a useful optimization. When we start doing 1:1 audio and video stuff (i.e. telephones on the net), you'll want a bi-directional flow, or more interactive operations (e.g. virtual reality things). I also see that these could be symmetric or assymetric. A symmetric flow would be you and I doing an audio session with each other - we both could talk at the same time, we'll both need about the same bandwidth, about the same latency, and so on. An assymetric flow would be more like a current FTP session -- lots of data going in one direction and small acks and commands in the other. Again, this can all be done with two uni-flows. A bi-flow would be an optimization (if I know that I need a flow 'from' you AND you will need a flow 'from' me, I could win by sending one setup message that, in effect, tells the system to set up the bi-directional flow with such-and-such parameters -- now that I think about it a second more, perhaps what is desired is not a bi-directional flow as a 'fundamental entity' but rather a flow-setup protocol that lets us set up one uni-flow (from A to B) or or two uni-flows (A to B and B to A)). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 02:00:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00245; Fri, 8 Apr 1994 02:00:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA10819; Fri, 8 Apr 1994 01:57:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA10803; Fri, 8 Apr 1994 01:40:30 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29178; Fri, 8 Apr 1994 01:41:43 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA11093; Thu, 7 Apr 94 08:43:22 -0700 Date: Thu, 7 Apr 94 08:43:22 -0700 From: Eric Fleischman Message-Id: <9404071543.AA11093@atc.boeing.com> To: big-internet@munnari.OZ.AU Subject: APIs in IPng Transition Dear Big-Internauts, There has been a discussion within the IPng Directorate concerning whether APIs are an essential part of the IPng Transition or not. My view of the rough consensus to date is that consortia and vendor-defined APIs such as TLI, XTI, Revised XTI, CTI, and MPTN are outside of our domain and must be defined and migrated by their owners. However, I have also been arguing that an important part of an IPng Transition would be to provide suggestions concerning how to migrate these APIs to support IPng. More importantly, I have been stating that sockets and its derivatives have become de facto and ubiquitous APIs which are no longer "owned" by any entity -- but rather are "owned" by all. I thus feel that a sockets redefinition to support IPng is an essential part of any IPng Transition -- especially in view of the ubiquity of user-written applications using sockets. As one might imagine, I received a lot of "push-back" on this idea. Some questioned whether APIs should ever be considered at all. Eventually I became so frustrated that I posted the following: >But all this is a side issue. My point is that an IPng Transition is >incomplete until the transition of ubiquitous TCP/IP APIs into the "IPng >world" have been addressed. These APIs are the key for whether user- >written applications can be migrated to IPng or not. Literally multiple >billions of dollars in investments have already been spent on these user >applications. They are dramatically important "ties that bind" real >end users to IPv4 and are one of the more important issues concerning >why IPng is such a "hard sell". > >Now it is my turn to shout: >THERE WILL NEVER EVEN BE A THEORETICAL CHANCE FOR REAL END USERS TO >COMPLETELY MIGRATE FROM IPv4 TO IPng UNLESS THESE APPLICATIONS CAN BE >EASILY PORTED TO AN IPng ENVIRONMENT. IF WE FAIL TO PROVIDE A MECHANISM >TO TRANSITION THESE APPLICATIONS THEN IPv4 CAN NOT EVEN BE THEORETICALLY >REPLACED BY IPng. At Scott Bradner's suggestion, we are now moving the discussion to this forum so that it could receive wider participation. This is therefore your opportunity to join in the fray. (Please note, however, that my sensibilities are already raw at this point in that I have resorted to shouting. ;-) ) Sincerely yours, --ERic Fleischman From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 03:58:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04767; Fri, 8 Apr 1994 03:58:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA11005; Fri, 8 Apr 1994 03:57:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA11002; Fri, 8 Apr 1994 03:55:49 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04704; Fri, 8 Apr 1994 03:56:58 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB11420; Thu, 7 Apr 94 10:52:36 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA14339; Thu, 7 Apr 94 10:51:14 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA05500; Thu, 7 Apr 1994 10:51:59 -0700 Date: Thu, 7 Apr 1994 10:51:59 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404071751.AA05500@jurassic.Eng.Sun.COM> To: Eric Fleischman Cc: Christian.Huitema@sophia.inria.fr, whyman@mwassocs.demon.co.uk, big-internet@munnari.OZ.AU, bound@zk3.dec.com In-Reply-To: <9404071648.AA18869@atc.boeing.com> Subject: Re: Turnipp - a merger proposal Eric, Christian is correct. SIPP supports variable length addresses and the mechanism it uses to implement this is by using one or more 64bit units (using the routing header option). This capability allows the address space to grow to 128-bits, 192-bits (or even larger) while still keeping the address units in manageable 64-bit units. The mechanism allows the scenario you described to be implemented. Suggest you check out the SIPP Whitepaper draft-ietf-sipp-whitepaper-00.txt in the ID directories or the SIPP mosaic pages at: http://town.hall.org/sipp/sipp-main.html Both describe this mechanism. Bob From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 13:52:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02383; Fri, 8 Apr 1994 02:58:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA10895; Fri, 8 Apr 1994 02:57:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA10881; Fri, 8 Apr 1994 02:45:43 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01990; Fri, 8 Apr 1994 02:46:58 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA18869; Thu, 7 Apr 94 09:48:27 -0700 Date: Thu, 7 Apr 94 09:48:27 -0700 From: Eric Fleischman Message-Id: <9404071648.AA18869@atc.boeing.com> To: Christian.Huitema@sophia.inria.fr, whyman@mwassocs.demon.co.uk Subject: Re: Turnipp - a merger proposal Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com Dear Christian: Is your statement below really true? Please correct me if I am wrong, but I thought that the current SIPP routing draft solely permitted a variable length address to be a 64 bit EID with 128 bit locater with the second 64 bits of the locater mandatorily being a autoconfigured address? At least, this is what I understood when speaking with Paul Francis. Now mind you, I am quite capable of misunderstanding even the finest teacher, so please correct me if I am wrong. However, if I have correctly understood, then the SIPP address is by no means "variable" length addresses. >Variable length addresses are fine, but fixed length have advantages, notably >when handling source routes. One of the neat points of the SIPP design is that >it allows variable length "by chunks of 64bits" while retaining a fixed format >header. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 13:58:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03097; Fri, 8 Apr 1994 03:18:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA10940; Fri, 8 Apr 1994 03:17:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA10909; Fri, 8 Apr 1994 03:00:32 +1000 Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02518; Fri, 8 Apr 1994 03:01:21 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22361; Thu, 7 Apr 94 12:43:24 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA09354; Thu, 7 Apr 94 12:54:35 EDT Date: Thu, 7 Apr 94 12:54:35 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404071654.AA09354@pobox.wellfleet> To: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Costs, Performance and IPng Not necessarily. For instance, now that Nimrod wants to be able to bash flow-id's in flight, it can't overload the source "address" as part of the logical flow-id, but rather needs a whole separate flow-id field which, by itself, identifies the flow. That being the case, you could have a bidirectional flow (half the state requirements :-) which is identified by the "setup host ID + local flow-id" in both directions. Well, if the flow IDs are going to be changed in flight, then I agree that you want to identify flows with a single flow ID, and not with {address plus flowID}. In this case I agree that you need more than 8 bits for the flow ID. 24 bits is probably enough here. I will want to take a look at the NIMROD work to understand why you are changing flow IDs in flight. Ross From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 14:20:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08196; Fri, 8 Apr 1994 05:39:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA11128; Fri, 8 Apr 1994 05:37:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA11125; Fri, 8 Apr 1994 05:28:08 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07949; Fri, 8 Apr 1994 05:29:03 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-11.dialip.mich.net (pm002-11.dialip.mich.net [35.1.48.92]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA01008 for ; Thu, 7 Apr 1994 15:28:51 -0400 Date: Thu, 7 Apr 94 19:15:10 GMT From: "William Allen Simpson" Message-Id: <2148.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Introducing proxy aggregations? > From: Simon Poole > I get a tummy ache everytime somebody mentions provider based > adressing for IPng (which is essentially suggested by all current > candidates). > So do I. Don't include SIPP. SIPP doesn't recommend provider-based assignment (except during initial deployment as now). It will dynamically adapt, without user intervention, on the order of minutes. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 14:23:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02574; Fri, 8 Apr 1994 03:03:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA10913; Fri, 8 Apr 1994 03:01:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA10878; Fri, 8 Apr 1994 02:44:53 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01975; Fri, 8 Apr 1994 02:46:05 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 8352; Thu, 07 Apr 94 12:29:41 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 2660; Thu, 7 Apr 1994 12:29:41 -0400 Date: Thu, 07 Apr 94 12:18:22 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Costs, Performance and IPng To: Ross Callon , big-internet@munnari.OZ.AU, bsimpson@MorningStar.Com In-Reply-To: <9404061746.AA22864@pobox.wellfleet> Message-Id: <940407.121822.EDT.VALDIS@vtvm1.cc.vt.edu> On Wed, 6 Apr 94 13:46:01 EDT you said: >However, we still could use the destination address as part of >the flow ID. In this case, rather than asking "why will we need >more than 256 identifiable flows between two hosts", I should have >been asking "why will we need more than 255 identifiable flows from >any one source address to any one particular destination address >(regardless of whether the destination address is unicast or >multicast)". I can *EASILY* see 250 people going from 1 terminal server to 1 host. Or are we implicitely assuming that in the future, there will be less use of terminal servers and more use of SLIP servers, or that there will not exist terminal servers with over 256 ports? Of course, the assumption that there will be more devices that speak IP natively implies a lean towards a toaster-net view of the world, with its attendant problems. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 15:31:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10333; Fri, 8 Apr 1994 06:39:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA11217; Fri, 8 Apr 1994 06:37:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA11214; Fri, 8 Apr 1994 06:26:46 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09848; Fri, 8 Apr 1994 06:27:52 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 7033; Thu, 07 Apr 94 16:26:52 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 2716; Thu, 7 Apr 1994 12:31:31 -0400 Date: Thu, 07 Apr 94 12:30:19 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Costs, Performance and IPng To: Frank Kastenholz , jcurran@nic.near.net Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: <9404062143.AA18605@mailserv-D.ftp.com> Message-Id: <940407.123019.EDT.VALDIS@vtvm1.cc.vt.edu> On Wed, 6 Apr 94 17:43:46 EDT you said: >How many people have explicitly decided to not connect to the >Internet? Perhaps because of security? Given that on comp.protocols.tcpip, there's at least 1 posting a week or so saying "Can anybody tell me the benefits of being on The Net, since our security goons^H^H^H^Hauditors aren't thrilled", I'd say it's a large number. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 15:33:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10514; Fri, 8 Apr 1994 06:43:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA11243; Fri, 8 Apr 1994 06:41:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA11200; Fri, 8 Apr 1994 06:21:00 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09584; Fri, 8 Apr 1994 06:22:16 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA21350; Thu, 7 Apr 1994 13:21:58 -0700 Date: Thu, 7 Apr 1994 13:21:58 -0700 From: Tony Li Message-Id: <199404072021.NAA21350@lager.cisco.com> To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal The inconveniency of doing source routes with variable length address show in CLNP, where routers have to look inside the option field to determine the currently active destination address - not to mention that poor implementations that would not examine the option field might generate loops. If one wants to remove the need for every intermediate router to examine the option field, then one must be ready to recompose a new header at each source routed relay. Which is probably not a zero cost operation. Given that you have flows, one has to wonder just how often you'll be processing a source route. Tony From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 15:58:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00817; Fri, 8 Apr 1994 15:58:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA12035; Fri, 8 Apr 1994 15:57:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA12024; Fri, 8 Apr 1994 15:55:17 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11385; Fri, 8 Apr 1994 07:04:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06600; Thu, 7 Apr 94 16:50:59 -0400 Date: Thu, 7 Apr 94 16:50:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404072050.AA06600@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? Cc: jnc@ginger.lcs.mit.edu > As a corollary, in order to contain the volume of routing information > switching providers would require renumbering with any of the IPng we > have today on the table. No, SIPP does not. It has a provider based initial allocation plan in an informational recommendation ... but specifically avoids the topic. Ignoring the problem won't make it go away. How do you propose to make the routing scale, if not through use of topologically significant addresses (since that's the only namespace SIPP provides)? SIPP will adapt automatically to any heirarchical topology. ... SIPP adapts by having a continuous advertisement of its routing prefixes. This means that hosts can change dynamically, without asking DHCP (or any central server), and without user intervention. In other words, you do renumber, and you've just got automatic mechanisms (as described in draft-ietf-sipp-auto-addr-00.txt, "SIPP: Automatic Host Address Assignment") to make it less painful when they change. Did I miss something here? Noel PS: If the physical topology's really hierarchical, then you don't have alternate paths available. Perhaps you meant that the addressing abstractions which you place over that physical toplogy are hierarchical? From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 16:40:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22856; Fri, 8 Apr 1994 12:39:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA11546; Fri, 8 Apr 1994 12:37:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA11543; Fri, 8 Apr 1994 12:32:34 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27625; Fri, 8 Apr 1994 01:00:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01117; Thu, 7 Apr 94 10:59:26 -0400 Date: Thu, 7 Apr 94 10:59:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404071459.AA01117@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal Cc: jnc@ginger.lcs.mit.edu i agreed that if the ipng has a good flow id design (32-64bits) that allows source/dest independent fast lookup (i.e. is a hash of source+dst+qos) Why does it have to be a hash? Can't it be a "random number" which is set aside to be equivalent (provided you solve the issue of how to distribute that mapping to everyone who needs it)? Or is that your problem - you don't want to have to distribute that mapping? Noel From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 16:55:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06157; Fri, 8 Apr 1994 04:38:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA11056; Fri, 8 Apr 1994 04:37:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA11053; Fri, 8 Apr 1994 04:26:03 +1000 Received: from Princeton.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05786; Fri, 8 Apr 1994 04:27:17 +1000 (from jwagner@Princeton.EDU) Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.108/princeton) id AA00201; Thu, 7 Apr 94 14:22:57 -0400 Received: from clytemnestra.Princeton.EDU by ponyexpress.princeton.edu (5.65c/1.113/newPE) id AA02620; Thu, 7 Apr 1994 14:22:56 -0400 Received: by clytemnestra.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA12165; Thu, 7 Apr 94 14:22:55 EDT Message-Id: <9404071822.AA12165@clytemnestra.Princeton.EDU> To: Craig Partridge Cc: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Wed, 06 Apr 1994 17:15:48 PDT." <199404070015.RAA13033@aland.bbn.com> X-Mailer: exmh version 1.3gamma 3/18/94 Date: Thu, 07 Apr 1994 14:22:53 EDT From: John Wagner > > Now image that what we're actually watching is a set of flows that sends > all information from all the cameras at a sporting event to a multicast > group (and you pick out which ones you want and b/w or color). Ten cameras, > each stream multilayered encoded, and we've got 50 flow ids for one > application. > > Craig > Craig, You got me imagining all right. And the first thing I realized was if I'm in this situation I'm not going to bet serveral million dollars of broadcast on one machine. What happens to those flowids when my application migrates to my backup processor? Is IPng going to require that I run two sets of applications in "parallel"? Or will it provide the service necessary to allow the fate sharing regions to migrate without the flow identifiers changing? If this "flow connected" characteristic is desirable then using the source and destination host identifiers in the hashing operation isn't going to work very well (although it might be a useful as a way to form an initial flowid value). I think this is easy (or atleast not too difficult) to do if the routing architecture is nimrod. Can we avoid designing the capability out before that is available? John Wagner From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 16:57:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08466; Fri, 8 Apr 1994 05:47:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA11154; Fri, 8 Apr 1994 05:46:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA11122; Fri, 8 Apr 1994 05:27:43 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07945; Fri, 8 Apr 1994 05:28:56 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-11.dialip.mich.net (pm002-11.dialip.mich.net [35.1.48.92]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA01000 for ; Thu, 7 Apr 1994 15:28:47 -0400 Date: Thu, 7 Apr 94 19:00:30 GMT From: "William Allen Simpson" Message-Id: <2147.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Introducing proxy aggregations? > From: yakov@watson.ibm.com > On the one hand I've been hearing assertions that renumbering is almost > "close to impossible". On the other hand, I know first hand of few > places that did renumbering of few hundred machines, and it didn't > consume an unsurmountable amount of efforts. > And I personally know one site that refused to renumber out of its part of a class A to several class B's, simply because it was "close to impossible". They have suffered inefficient routing, but obviously are willing to live with it. CIDR may actually make things worse from the routing perspective. I refer to net 35.8 (9, 10, 11, etc), allocated to one of the largest universities in the world. > So, I guess renumbering is feasible. That doesn't mean that renumbering > is a "piece of cake". There are things we can (and should) do to > facilitate renumbering. For example, widely deployed DHCP would be of > great help. > I doubt it. DHCP is only useful when a machine asks for a new number, or to renew a lease. It won't help long-lived connections. > As a side comment, I'd like to point out that ALL of the existing IPng > assume provider-based address assignment. As a corollary, in order to > contain the volume of routing information switching providers would > require renumbering with any of the IPng we have today on the table. > No, SIPP does not. It has a provider based initial allocation plan in an informational recommendation (because that's who is likely to initially hand out addresses), but specifically avoids the topic. In fact, previous plans assumed geographic assignment. SIPP will adapt automatically to any heirarchical topology. > So, I guess renumbering is likely to become a permanent fixture in the > Internet, and we need to focus on how to make renumbering as simple as > possible. > SIPP adapts by having a continuous advertisement of its routing prefixes. This means that hosts can change dynamically, without asking DHCP (or any central server), and without user intervention. Is this true of any other IPng? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 18:30:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24177; Fri, 8 Apr 1994 13:19:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA11604; Fri, 8 Apr 1994 13:17:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA11588; Fri, 8 Apr 1994 13:08:37 +1000 Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29993; Fri, 8 Apr 1994 01:56:45 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21655; Thu, 7 Apr 94 11:38:14 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA08205; Thu, 7 Apr 94 11:49:24 EDT Date: Thu, 7 Apr 94 11:49:24 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404071549.AA08205@pobox.wellfleet> To: craig@aland.bbn.com Subject: Re: Costs, Performance and IPng Cc: big-internet@munnari.OZ.AU Now image that what we're actually watching is a set of flows that sends all information from all the cameras at a sporting event to a multicast group (and you pick out which ones you want and b/w or color). Ten cameras, each stream multilayered encoded, and we've got 50 flow ids for one application. Craig; I will need to think about the implementation, but I *love* the application!!! A similar application (for us audio-nuts): How about multiple sound channels for a symphony or some other sort of concert? Ross From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 18:50:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24241; Fri, 8 Apr 1994 13:22:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA11619; Fri, 8 Apr 1994 13:20:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA11585; Fri, 8 Apr 1994 12:59:23 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27995; Fri, 8 Apr 1994 01:11:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01246; Thu, 7 Apr 94 11:11:00 -0400 Date: Thu, 7 Apr 94 11:11:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404071511.AA01246@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal Cc: jnc@ginger.lcs.mit.edu Imposing a limit other than that imposed by the address length field itself is unnecessary and does no more than impose an artificial limit on both growth and possible uses of a large address space. Exactly. The only slight difference is that it's easier to do an incremental upgrade, since you don't have to play about with different packet formats (like us :-). The only case where pragmatic limit on the address itself is useful is in profiles for routers ... when you do want to have all routers capable of handling a minimum length address for destinations I assume you're talking about the costs of handling and processing variable length addresses? It's easy to write code that handles semi-arbitrary lengths, but it may not be the most efficient code possible... (Of course, if you didn't have to parse the addresses much, it wouldn't be so bad.... :-) other than the NSAP Address ... The NSAP Address is the key unifying part of the proposal ... make the proposal to use NSAP Addresses a realistic one. ... in the inclusion of NSAP Addressing ... has taken the best bits out of Tuba One thing I'm wondering about here: are you talking about the using (i.e. supporting) all the existing NSAP allocations, or are you only talking about the general structure of NSAP's? Noel From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 18:52:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24935; Fri, 8 Apr 1994 13:38:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA11654; Fri, 8 Apr 1994 13:37:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA11637; Fri, 8 Apr 1994 13:23:43 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01050; Fri, 8 Apr 1994 02:22:22 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA28932; Thu, 7 Apr 94 12:22:09 EDT Message-Id: <9404071622.AA28932@tipper.oit.unc.edu> To: big-internet@munnari.OZ.AU Subject: Another firm requirement for IPNG In-Reply-To: Your message of "Thu, 07 Apr 94 11:21:05 EDT." <9404071521.AA24904@mailserv-D.ftp.com> Date: Thu, 07 Apr 94 12:22:08 -0400 From: Simon E Spero Jon Magid has come up with another set of metrics which IPNG must measure up against: 1) The basic architecture for IPNG should be readily described on a single sheet of A4 paper. 2) Sufficient information to implement IPNG for a non-routing host should fit onto 10 sheets of A4 paper (use both sides of the paper if necessary). Margins shall be not less than 2.5cm on the left and right sides, and not less than 1.25cm at the top and bottom. The reference font shall be medium weight 10pt Times Roman. From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 18:53:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25058; Fri, 8 Apr 1994 13:42:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA11680; Fri, 8 Apr 1994 13:40:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA11651; Fri, 8 Apr 1994 13:25:29 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01063; Fri, 8 Apr 1994 02:23:09 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA15701; Thu, 7 Apr 94 09:24:42 -0700 Date: Thu, 7 Apr 94 09:24:42 -0700 From: Eric Fleischman Message-Id: <9404071624.AA15701@atc.boeing.com> To: jnc@ginger.lcs.mit.edu, poole@magnolia.eunet.ch Subject: Re: Introducing proxy aggregations? Cc: big-internet@munnari.OZ.AU I take my hat off to Simon Poole who said (among other wise words): > Wrong: it's not that people wont renumber; they wont switch in the first > place. My personal belief is that should a company be given a choice in Internet exchange carriers and should that company decide to switch carriers it is unreasonable to imagine that that company would be willing to readdress as part of the bargain. Similarly, the "new carrier" is not likely to insist that the company re-address because such insistence will probably convince the company that the new carrier isn't so great after all and so that they will take their business elsewhere -- to a carrier who is more "reasonable". For this reason, I have always thought that "provider based addressing" is unrealistic and A Bad Thing. To me, it is merely another instance that significant percentages of the IETF do not understand even elementary market realities. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 18:57:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25720; Fri, 8 Apr 1994 13:59:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA11716; Fri, 8 Apr 1994 13:57:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA11694; Fri, 8 Apr 1994 13:43:36 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04009; Fri, 8 Apr 1994 03:43:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03543; Thu, 7 Apr 94 13:43:15 -0400 Date: Thu, 7 Apr 94 13:43:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404071743.AA03543@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Cc: jnc@ginger.lcs.mit.edu I will want to take a look at the NIMROD work to understand why you are changing flow IDs in flight. The WG archive is available from BBN.COM, in pub/nimrod-wg/nimrod-wg.archive by anonymous FTP. Look for the message: Date: Fri, 31 Dec 93 13:41:39 -0500 Message-Id: <9312311841.AA26054@ginger.lcs.mit.edu> Subject: New datagram mode which explains it all in some detail, with examples. Noel From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:05:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26492; Fri, 8 Apr 1994 14:19:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA11773; Fri, 8 Apr 1994 14:17:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA11770; Fri, 8 Apr 1994 14:11:16 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06524; Fri, 8 Apr 1994 04:45:51 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA28284 for big-internet@munnari.oz.au; Thu, 7 Apr 94 14:45:17 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id LAA14129; Thu, 7 Apr 1994 11:43:30 -0700 Message-Id: <199404071843.LAA14129@aland.bbn.com> To: John Wagner Cc: Craig Partridge , big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Thu, 07 Apr 94 14:22:53 -0400. <9404071822.AA12165@clytemnestra.Princeton.EDU> From: Craig Partridge Date: Thu, 07 Apr 94 11:43:28 -0700 Sender: craig@aland.bbn.com Hi John: If I've given any impression that I believed that a flow id of source+dest plus flowid was a good solution, I apologize. There are a number of cases (such as the one you mention) where it is clear there may be multiple senders (possibly in series, possibly intermingled) to one flow or set of related flows. There was a discussion about 6 months ago about how this probably implied that using the source address to define the flow ID wasn't necessarily a hot idea. However, the flip side of the problem is that for multicast flows, one needs some distributed negotiation rules to ensure that flow ids don't collide on the mcast address (which is rather grim and difficult to get right in a low-cost way). I don't recall what the resolution was. Craig From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:06:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27246; Fri, 8 Apr 1994 14:39:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA11821; Fri, 8 Apr 1994 14:37:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA11793; Fri, 8 Apr 1994 14:24:04 +1000 Received: from midas.london.micrognosis.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09205; Fri, 8 Apr 1994 06:11:05 +1000 (from nreadwin@london.micrognosis.com) Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA11169; Thu, 7 Apr 94 21:09:44 BST Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma011166; Thu Apr 7 21:09:43 1994 Received: from moria by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA03538; Thu, 7 Apr 94 21:09:41 BST From: nreadwin@london.micrognosis.com (Neil Readwin) Received: by moria (4.1//ident-1.0) id AA19509; Thu, 7 Apr 94 21:09:40 BST Message-Id: <9404072009.AA19509@moria> Subject: Re: Introducing proxy aggregations? To: bsimpson@morningstar.com Date: Thu, 7 Apr 1994 21:09:40 +0100 (BST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <2147.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Apr 7, 94 07:00:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 919 > And I personally know one site that refused to renumber out of its part > of a class A to several class B's, simply because it was "close to > impossible". They have suffered inefficient routing, but obviously are > willing to live with it. CIDR may actually make things worse from the > routing perspective. I refer to net 35.8 (9, 10, 11, etc), allocated to > one of the largest universities in the world. Am I right in thinking that if they have used (say) 35.8-35.80 then they could still hand back 35.1-35.7 and 35.81-35.255? The whole point of this is that a class A network is no longer allocated in a single piece, no?. This would mean that even if people won't renumber (and I can't blame them for that) then significant parts of the address space might be reclaimable. Neil. -- nreadwin@london.micrognosis.com Phone: +1 718 273 8234 Anything is a cause for sorrow that my mind or body has made From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:07:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28220; Fri, 8 Apr 1994 14:59:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA11900; Fri, 8 Apr 1994 14:57:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA11875; Fri, 8 Apr 1994 14:45:21 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27681; Fri, 8 Apr 1994 14:46:26 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA05391; Thu, 7 Apr 94 21:42:24 -0700 Received: by xirtlu.zk3.dec.com; id AA13000; Fri, 8 Apr 1994 00:42:22 -0400 Message-Id: <9404080442.AA13000@xirtlu.zk3.dec.com> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: craig@aland.bbn.com, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Thu, 07 Apr 94 11:49:24 EDT." <9404071549.AA08205@pobox.wellfleet> Date: Fri, 08 Apr 94 00:42:16 -0400 X-Mts: smtp >Craig; > >I will need to think about the implementation, but I *love* the >application!!! > >A similar application (for us audio-nuts): How about multiple sound >channels for a symphony or some other sort of concert? > >Ross I'm with Ross. This would be great also for Pink Floyd's the Wall or the Who's Tommy. In fact after IPng is figured out we could all listen to B. B. King the Thrill is Gone. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:21:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28356; Fri, 8 Apr 1994 15:01:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA11917; Fri, 8 Apr 1994 14:59:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA11852; Fri, 8 Apr 1994 14:42:55 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11404; Fri, 8 Apr 1994 07:04:39 +1000 (from lyman@BBN.COM) Message-Id: <9404072104.11404@munnari.oz.au> From: Lyman Chapin Subject: Re: Turnipp - a merger proposal To: Christian.Huitema@sophia.inria.fr Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com, whyman@mwassocs.demon.co.uk In-Reply-To: <199404071200.AA00742@mitsou.inria.fr> Date: Thu, 7 Apr 94 13:44:55 EDT Mail-System-Version: >To: whyman@mwassocs.demon.co.uk >Cc: bound@zk3.dec.com, big-internet@munnari.oz.au >Subject: Re: Turnipp - a merger proposal >Date: Thu, 07 Apr 1994 14:00:52 +0200 >From: Christian Huitema > >=> | |From: bound@zk3.dec.com >=> | |One caution I have is that a variable address is nice, but I think we >=> | |need to define some limit initially for the structures and arrays that >=> | |will house the IPng address. Even GOSIP did this and we can to. >=> >=> I take the opposite view. Imposing a limit other than that imposed by the >=> address length field itself is unnecessary and does no more than impose an >=> artificial limit on both growth and possible uses of a large address space. > >Variable length addresses are fine, but fixed length have advantages, notably >when handling source routes. One of the neat points of the SIPP design is that >it allows variable length "by chunks of 64bits" while retaining a fixed format >header. > >The inconveniency of doing source routes with variable length address show in >CLNP, where routers have to look inside the option field to determine the >currently active destination address - not to mention that poor >implementations that would not examine the option field might generate loops. Christian, You're not going to like this comment, but an implementation that does not at least recognize the existence of a type-2 option field is not only poor, it's non-conforming; it can discard the packet if it sees an option it does not support, but it cannot ignore the presence of a source route option field and forward the packet without looking into it. That having been said, I agree with you that the process of looking through the variable-length list of variable-length addresses in the source route option field of a CLNP packet to find the current forwarding address is indeed "inconvenient"1 - Lyman >If one wants to remove the need for every intermediate router to examine the >option field, then one must be ready to recompose a new header at each >source routed relay. Which is probably not a zero cost operation. > >Christian Huitema From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:22:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27556; Fri, 8 Apr 1994 14:43:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA11847; Fri, 8 Apr 1994 14:42:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA11807; Fri, 8 Apr 1994 14:26:31 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03134; Fri, 8 Apr 1994 03:20:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03312; Thu, 7 Apr 94 13:20:15 -0400 Date: Thu, 7 Apr 94 13:20:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404071720.AA03312@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, ericf@arc.boeing.com Subject: Re: Introducing proxy aggregations? Cc: jnc@ginger.lcs.mit.edu it is unreasonable to imagine that that company would be willing to readdress as part of the bargain. ... the "new carrier" is not likely to insist that the company re-address ... For this reason, I have always thought that "provider based addressing" is unrealistic and A Bad Thing. To me, it is merely another instance that significant percentages of the IETF do not understand even elementary market realities. Perhaps the researchers could retort that significant percentages of the IETF do not understand even elementary technical realities. (Sorry, couldn't resist; too good a line! :-) Let me try a "real-world" analogy to "provider based addressing" which may make the extent of my inability to grok your statement clear. Suppose I have a small firm which is renting space from building X. We get a better deal on space in building Y, so we move to a different "space provider". However, we insist at the same time that we don't want to change our address, that our deliveries continue to come to our old address. Any landlord would look at you like you're a candidate to be comitted, right? I can understand the desire of people to have "names" for their computers which don't vary as their location in the topology changes. (The fact that I'm Noel in Virginia and Seattle is sort of useful! :-) Let's call these names "gronks". However, in return, please try and understand the needs of routing. (Not the needs of the routing community; the things of which I speak are no more escapable than the laws of thermodynamics! :-) If routing is going to scale (i.e. not have costs on the order of O(N), where N is the number of distincyt destinations in the network) it needs to work with "names" for things which have topological significance; i.e. when you pick something up, and move it to a different place in the topology, it gets a different "name" for the routing to work with. Let's call these names "fnortzes". (I should interject that there are ways to constrain the topology so that if you move from one provider to another within a local area of the topology, to which all the providers are attached, the move can be made "invisible" [the routing will still know about it, obviously] both outside and inside at the cost of a certain amount of overhead, approximately O(N) in the number of things which have moved from their original provider. If you pay that cost, it's not visible from your name that you've changed providers. It may not be practical to enforce this restriction, the costs may also become too large, and in any case, it only works if your reattachment point is inside that local area of the topology. Some variants of this scheme turn into having fnortzes, just under the sheets where the users can't see them.) So, you have two groups, with diametrically opposed needs. You can't keep them both happy at the same time, with one thing! Either a) one loses, or b) you have two separate things. I can guarantee you that routing (like thermodynamics :-) isn't going to lose; it *is* the rules. You only get to chose whether i) you have one name, and it changes when you move to a different provider, or ii) you have two names, so everybody can be happy. I think the latter is the way to go, but that's just my opinion. Noel PS: If it isn't obvious, "gronks" are EID's, and "fnortzes" are locators. From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:22:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29064; Fri, 8 Apr 1994 15:20:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA11962; Fri, 8 Apr 1994 15:17:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA11948; Fri, 8 Apr 1994 15:08:03 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10605; Fri, 8 Apr 1994 06:45:50 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA23084; Thu, 7 Apr 1994 13:44:48 -0700 Date: Thu, 7 Apr 1994 13:44:48 -0700 From: Tony Li Message-Id: <199404072044.NAA23084@lager.cisco.com> To: bsimpson@MorningStar.Com Cc: big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? Newsgroups: cisco.external.big-internet In-Reply-To: <2147.bill.simpson@um.cc.umich.edu> Organization: cisco Systems, Inc., Menlo Park, Ca. In article <2147.bill.simpson@um.cc.umich.edu> you write: And I personally know one site that refused to renumber out of its part of a class A to several class B's, simply because it was "close to impossible". They have suffered inefficient routing, but obviously are willing to live with it. CIDR may actually make things worse from the routing perspective. I refer to net 35.8 (9, 10, 11, etc), allocated to one of the largest universities in the world. Please defend or explain this statement. No throwing loaded bombshells over the wall without rationalization. > As a side comment, I'd like to point out that ALL of the existing IPng > assume provider-based address assignment. As a corollary, in order to > contain the volume of routing information switching providers would > require renumbering with any of the IPng we have today on the table. SIPP will adapt automatically to any heirarchical topology. How does that differ from dynamically performing provider-based addressing? SIPP adapts by having a continuous advertisement of its routing prefixes. This means that hosts can change dynamically, without asking DHCP (or any central server), and without user intervention. Is this true of any other IPng? Yes. Tony From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:26:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28429; Fri, 8 Apr 1994 15:02:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA11932; Fri, 8 Apr 1994 15:01:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA11897; Fri, 8 Apr 1994 14:56:48 +1000 Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28140; Fri, 8 Apr 1994 14:57:57 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by dscs.arc.nasa.gov (8.6.8/1.5T) id VAA08996; Thu, 7 Apr 1994 21:57:39 -0700 Message-Id: <199404080457.VAA08996@dscs.arc.nasa.gov> To: Eric Fleischman Cc: jnc@ginger.lcs.mit.edu, poole@magnolia.eunet.ch, big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? In-Reply-To: Your message of "Thu, 07 Apr 94 09:24:42 PDT." <9404071624.AA15701@atc.boeing.com> Date: Thu, 07 Apr 94 21:57:39 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Well, I think your views are somewhat simplistic. In fact, there is a range of options in just how hard you pursue renumbering. Many smaller networks don't have problems with this at all - we've asked some of our smaller sites to do this and they've complied. Since, if you renumber to aggregate, a small net buys you the same savings as a big site using a class B, you push the smaller sites first. More bang for less effort. It may not be "fair", but it's certainly more practical. I think an analogy may be instructive. If you have ever sat in a F-111 cockpit (it's a fighter-bomber), you'll notice a control that's tied in with the terrain following radar system which the pilots call "dial-a-ride". Basically, the pilot programs the aircraft to fly at a given altitude above the terrain, and this little knob tells the flight computer about how rigidly to conform to this altitude profile as you zip across the terrain. If you set this number high, the aircraft gently enforces the altitude above ground setting. The problem is that after you fly over a hill, you may be flying high enough to be spotted by radar, and get shot at. If you set this number really low, the aircraft will rapidly adjust the altitude in response to changes in terrain. Many pilots find that the shaking is so bad at the lowest settings that it's quite unnerving, and doesn't allow them to effectively perform the bomb run, or read other cockpit displays, though in some cases it can mean the difference in returning home from a mission, or being shot down. It's quite a ride. The point here is that how hard we push renumbering is like the dial a ride control. We can do it gently, and only for sites that are small and can do it without much fuss, but risk running out of routing table space for new sites, or we can renumber very aggressively, and coupled with CIDR, get relatively high efficiency at the cost of a fair amount of pain. But the point is that it's a range. Also, part of this isn't really a network or provider issue. It's a host OS issue. I'll agree with you that renumbering can be a pain today, especially at large bridged sites. However, vendors can make it much easier to renumber hosts, and make such transitions relatively painless. DHCP and other such things will help here. I assume you wouldn't mind renumbering if it wasn't as painful, right? It's not fair to assert that users will not tolerate renumbering. The users will also not tolerate not being able to connect because they can't get addresses that are routable. It's a tradeoff. BTW, one thing I've always found rather amusing about the TUBA debate is that many of the same people who don't like renumbering also like using CLNP as the base internetwork protocol because it's got such large addresses. But in fact, the issue of renumbering is even more of an issue there, because all the addresses are hierarchically assigned and routed. We have to use the same prefix'ing and aggregation there that forces people to renumber with good old IPv4 because we want to keep routing tables down to reasonable sizes. The classic way to attack scaling is with hierarchy. This isn't rocket science. What we have to do is make it easier for people to renumber; not decieve ourselves into thinking we can live without it. It's not a choice as long as we want our routing tables to stay at manageable sizes. Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:34:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27663; Fri, 8 Apr 1994 14:46:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA11867; Fri, 8 Apr 1994 14:44:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA11810; Fri, 8 Apr 1994 14:29:09 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03620; Fri, 8 Apr 1994 03:33:18 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA19465; Thu, 7 Apr 94 10:26:57 -0700 Received: by xirtlu.zk3.dec.com; id AA27311; Thu, 7 Apr 1994 13:26:53 -0400 Message-Id: <9404071726.AA27311@xirtlu.zk3.dec.com> To: whyman@mwassocs.demon.co.uk Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 07 Apr 94 10:05:46 BST." <9404071005.aa749@mwassocs.demon.co.uk> Date: Thu, 07 Apr 94 13:26:46 -0400 X-Mts: smtp | |From: bound@zk3.dec.com | |One caution I have is that a variable address is nice, but I think we | |need to define some limit initially for the structures and arrays that | |will house the IPng address. Even GOSIP did this and we can to. > >From: whyman@massocs.demon.co.uk >I take the opposite view. Imposing a limit other than that imposed by the >address length field itself is unnecessary and does no more than impose an >artificial limit on both growth and possible uses of a large address space. The >only case where pragmatic limit on the address itself is useful is in >profiles for routers within a given class of Routing Domain, when you do want >to have all routers capable of handling a minimum length address for >destinations within the RD (but not external destinations). There is also a >case for profiles specifying a minimum address prefix length to be supported >for inter-domain routing, but this is a complex issue, with routers in >different parts of the topology having requirements for different minimum >prefix length support, depending on the addressing plan and its deployment. Your response has taken a router and discovery only focus. We need to also look at the jist of what I stated from a host network kernel OS perspective. I will use SIPP as a discussion point. As Christian pointed out SIPP provides addresses in 64bit units and can be concatenated to provide multiple 64bit unit parts to provide an address sequence. 64 bits of address space is enough for any domain including the need to support recent needs for things like CDPD that needs more addresses than 32bits can provide anyway you slice it. But 64bits could not be enough for routing. Hence, SIPP now has address sequences. My point is that an address sequence of say addr[6] is 384 bits of address space. This is more than enough space for any toasters or wall sockets I have heard proposed by anyone. On a host we have to maintain queues, control blocks, routing tables (for hosts that will support routing), PMTU state, and many other lists as data structures. I would like to keep them aligned and structured. Plus I will add to what Christian stated that on Alpha a long is 64bits and works out very nicely for addr[XX]. This will be true for other 64bit architectures too. In addition a host has to provide an interface from the network layer to the transport layer and then to an applications layer. Using sockets as an example attempting to select a min and max for the sa_data[XX] to 'house' the IPng address lets me implement the structures discussed above and sockets in a tightly coupled manner. I am hoping that the min value in fact will support any AS or private companies site set of nodes. I do think 64bits will work well at that granularity too. The min could be greater but I am not sure it has to be in my life time. I think we agree on the min right? I don't want to do variable memory access based on the address length field if it changes from connection to connection. We have learned a lot about VM from Mach 2.5 and 3.0, but lets not go to far with stressing the host kernels out, or we will affect performance negatively for IPng capable TCP/IP host nodes. We also need to consider the affect to hosts that have minimal resources and the emerging micro-kernels being developed for hosts. >In the short term it is quite reasonable to make recommendations on the >minimum support requirements for routing to addresses within an RD, and >for address prefixes in inter-domain routing. However, while implementation >of such minima will impose practical limits on addresses within RDs that >implement to the minimum requirement, it should not translate into imposing >a similar maximum length on the address in someone else's RD. I agree but if we can come up with a min for the node identifying address at a site it would make the hosts life much easier and deployment would be easier regarding time to market as we would be changing less of the underlying infrastructure because we need new addresses for TCP/IP. This has a big affect on moving the 1000's of applications for TCP/IP to become IPng capable. Which affects IPng transition. | |Routing protocols. Well lets look at the limitations of routing | |protocols now on the system services and architecture. This gets at | |Dave Clark's suggestion during the requirements BOF at last weeks IETF. | |Do we like the models of OSI for example imposed on the network | |environment, could be a sample question? >I doubt whether Tony Li's proposal does impose an OSI model on the >Internet other than the NSAP Address and the notions of Routing Domains >and RDC's implied by using IDRP. The NSAP Address is the key unifying part >of the proposal, and IDRP provides the common routing protocol that can >make a scaleable Internet. Although the original proposal also mentioned >IS-IS and ES- IS, they should only be regarded as recommendations as IDRP >does not prescribe the intra-domain routing protocol and users are free >to choose an intra-domain routing protocol appropriate to their >circumstances. The true significance of ES-IS and IS-IS is that they exist >and by existing make the proposal to use NSAP Addresses a realistic one. >If the aim of a unified proposal was to take the best bits, then in the >inclusion of NSAP Addressing and IDRP, Tony Li has taken the best bits >out of Tuba (although there are some other good bits that shouldn't >be lost). I did not say Tony was imposing the OSI architecture on IPng. I simply pointed out (I think as your are too) that ES-IS and IS-IS being used should not impose the OSI architecture as complete for IPng. We have learned from OSI and from TCP/IP. The market for TCP/IP includes hosts that can perform as interior routers, diskless nodes getting kernels from servers, servers for name space, and much more. In addition I can purchase a Sun, HP, IBM, Microsoft, Novell, and Digital TCP/IP implementations in a multivendor way and all of the previous sentences functions work together. There is no vendor lock-in when using the TCP/IP architecture from multiple vendors. The market wants this to remain the case as we upgrade TCP/IP to become IPng capable. OSI has yet to demonstrate multiple vendor distributed file systems, similar command interfaces like ftp/telnet, common name space like BIND DNS, and I could go on. So what I was raising is if we adopt OSI protocols we need to determine what pieces of those protocols would not permit the TCP/IP infrastructure today provide by the TCP/IP suite and defacto architecture. Basically what would we do different from all we have learned from both OSI and TCP/IP. Unless somone believes OSI or TCP/IP network layer components are perfect, and I doubt that? As a note it seems both TUBA and SIPP propose using IDRP as the exterior routing protocol. Another point of common ground. CATNIP would be transparent to this issue. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 19:44:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03488; Fri, 8 Apr 1994 16:59:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA12124; Fri, 8 Apr 1994 16:57:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA12117; Fri, 8 Apr 1994 16:55:06 +1000 Received: from INFO-SERVER.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB25739; Fri, 8 Apr 1994 14:00:06 +1000 (from big-internet-request@munnari.oz.au) Received: from localhost (daemon@localhost) by info-server.bbn.com (8.6.5/8.6.5) id XAA07413; Thu, 7 Apr 1994 23:44:41 -0400 Received: from USENET by info-server.bbn.com with netnews for usenet@munnari.oz.au (big-internet@munnari.oz.au); contact usenet@info-server.bbn.com if you have questions. To: big-internet@munnari.OZ.AU Date: 7 Apr 94 16:22:08 GMT Message-Id: <9404071622.AA28932@tipper.oit.unc.edu> Organization: BBN Mail to News Gateway From: news-mail-gateway@bbn.com Sender: big-internet-request@munnari.OZ.AU References: , <9404071521.AA24904@mailserv-D.ftp.com> Subject: Another firm requirement for IPNG Jon Magid has come up with another set of metrics which IPNG must measure up against: 1) The basic architecture for IPNG should be readily described on a single sheet of A4 paper. 2) Sufficient information to implement IPNG for a non-routing host should fit onto 10 sheets of A4 paper (use both sides of the paper if necessary). Margins shall be not less than 2.5cm on the left and right sides, and not less than 1.25cm at the top and bottom. The reference font shall be medium weight 10pt Times Roman. From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 20:05:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03702; Fri, 8 Apr 1994 17:05:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA12139; Fri, 8 Apr 1994 17:03:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA12100; Fri, 8 Apr 1994 16:51:54 +1000 Received: from INFO-SERVER.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25162; Fri, 8 Apr 1994 13:45:05 +1000 (from big-internet-request@munnari.oz.au) Received: from localhost (daemon@localhost) by info-server.bbn.com (8.6.5/8.6.5) id XAA07353; Thu, 7 Apr 1994 23:39:43 -0400 Received: from USENET by info-server.bbn.com with netnews for usenet@munnari.oz.au (big-internet@munnari.oz.au); contact usenet@info-server.bbn.com if you have questions. To: big-internet@munnari.OZ.AU Date: 7 Apr 94 15:49:24 GMT Message-Id: <9404071549.AA08205@pobox.wellfleet> Organization: BBN Mail to News Gateway From: news-mail-gateway@bbn.com Sender: big-internet-request@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Now image that what we're actually watching is a set of flows that sends all information from all the cameras at a sporting event to a multicast group (and you pick out which ones you want and b/w or color). Ten cameras, each stream multilayered encoded, and we've got 50 flow ids for one application. Craig; I will need to think about the implementation, but I *love* the application!!! A similar application (for us audio-nuts): How about multiple sound channels for a symphony or some other sort of concert? Ross From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 20:07:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03769; Fri, 8 Apr 1994 17:07:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA12154; Fri, 8 Apr 1994 17:05:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA12121; Fri, 8 Apr 1994 16:56:59 +1000 Received: from INFO-SERVER.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25743; Fri, 8 Apr 1994 14:00:17 +1000 (from big-internet-request@munnari.oz.au) Received: from localhost (daemon@localhost) by info-server.bbn.com (8.6.5/8.6.5) id XAA07422; Thu, 7 Apr 1994 23:48:10 -0400 Received: from USENET by info-server.bbn.com with netnews for usenet@munnari.oz.au (big-internet@munnari.oz.au); contact usenet@info-server.bbn.com if you have questions. To: big-internet@munnari.OZ.AU Date: 7 Apr 94 16:24:42 GMT Message-Id: <9404071624.AA15701@atc.boeing.com> Organization: BBN Mail to News Gateway From: news-mail-gateway@bbn.com Sender: big-internet-request@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? I take my hat off to Simon Poole who said (among other wise words): > Wrong: it's not that people wont renumber; they wont switch in the first > place. My personal belief is that should a company be given a choice in Internet exchange carriers and should that company decide to switch carriers it is unreasonable to imagine that that company would be willing to readdress as part of the bargain. Similarly, the "new carrier" is not likely to insist that the company re-address because such insistence will probably convince the company that the new carrier isn't so great after all and so that they will take their business elsewhere -- to a carrier who is more "reasonable". For this reason, I have always thought that "provider based addressing" is unrealistic and A Bad Thing. To me, it is merely another instance that significant percentages of the IETF do not understand even elementary market realities. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 20:11:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03824; Fri, 8 Apr 1994 17:09:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA12169; Fri, 8 Apr 1994 17:07:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA12103; Fri, 8 Apr 1994 16:54:28 +1000 Received: from INFO-SERVER.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25164; Fri, 8 Apr 1994 13:45:16 +1000 (from big-internet-request@munnari.oz.au) Received: from localhost (daemon@localhost) by info-server.bbn.com (8.6.5/8.6.5) id XAA07385; Thu, 7 Apr 1994 23:42:09 -0400 Received: from USENET by info-server.bbn.com with netnews for usenet@munnari.oz.au (big-internet@munnari.oz.au); contact usenet@info-server.bbn.com if you have questions. To: big-internet@munnari.OZ.AU Date: 7 Apr 94 15:11:00 GMT Message-Id: <9404071511.AA01246@ginger.lcs.mit.edu> Organization: BBN Mail to News Gateway From: news-mail-gateway@bbn.com Sender: big-internet-request@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal Imposing a limit other than that imposed by the address length field itself is unnecessary and does no more than impose an artificial limit on both growth and possible uses of a large address space. Exactly. The only slight difference is that it's easier to do an incremental upgrade, since you don't have to play about with different packet formats (like us :-). The only case where pragmatic limit on the address itself is useful is in profiles for routers ... when you do want to have all routers capable of handling a minimum length address for destinations I assume you're talking about the costs of handling and processing variable length addresses? It's easy to write code that handles semi-arbitrary lengths, but it may not be the most efficient code possible... (Of course, if you didn't have to parse the addresses much, it wouldn't be so bad.... :-) other than the NSAP Address ... The NSAP Address is the key unifying part of the proposal ... make the proposal to use NSAP Addresses a realistic one. ... in the inclusion of NSAP Addressing ... has taken the best bits out of Tuba One thing I'm wondering about here: are you talking about the using (i.e. supporting) all the existing NSAP allocations, or are you only talking about the general structure of NSAP's? Noel From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 21:39:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14251; Fri, 8 Apr 1994 21:39:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA12615; Fri, 8 Apr 1994 21:37:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA12612; Fri, 8 Apr 1994 21:35:43 +1000 Received: from tuna.wang.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21842; Fri, 8 Apr 1994 12:09:57 +1000 (from fitz@wang.com) Received: from elf.wang.com by tuna.wang.com with SMTP id AA20517 (5.67a/IDA-1.5 for ); Thu, 7 Apr 1994 22:06:45 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA19732 (5.67a/IDA-1.5 for ); Thu, 7 Apr 1994 22:06:37 -0400 Received: by fnord.wang.com (5.65/TF6) id AA12058; Thu, 7 Apr 94 22:06:37 -0400 Date: Thu, 7 Apr 94 22:06:37 -0400 From: Tom Fitzgerald Message-Id: <9404080206.AA12058@fnord.wang.com> To: big-internet@munnari.OZ.AU Subject: Costs, Performance and IPng In response to Tony Li's comment: > I would argue that because a firewall is not a complete security > solution, that firewall performance should very much be a non-goal. With security issues, you want to solve the same problem several times, redundantly, so that if part of your solution is compromised, there's still enough left to stop a breakin (or at least make life harder for the guy breaking in). Elegance is less important than robustness. So, while firewalls aren't a complete solution and other things (authentication, encryption, application-level proxies, etc) are necessary, a firewall is still extremely helpful, and firewall performance will still matter to us customers. > From: jcurran@nic.near.net (John Curran) > Does anyone feel that IPng has to provide particular new features to > make it easier to deploy firewalls? I'd like to hear which features > would be considered useful for this purpose. It would hurt if an IPng design required packets whose source address belonged to an AS to cross a boundary *into* that AS. If this isn't a normal thing, a firewall can treat it as a spoofed source address and discard the packet.. Where a flow ID is redundant with the destination address, tos or whatever, it should be impossible for someone to sneak a packet through a filtered path by spoofing a flow ID. (This is mainly a router implementation issue - flow IDs shouldn't be used to circumvent packet filters.) Security-wise, it would be a shame if IPng relied a lot on source routing, since source routing is such a great way to spoof traffic undetectably. You'll probably find that the best existing IPv4 firewalls are configured with "no ip source-route". For TCPng (whatever it turns out to be), we'd still like a way to detect the first packet of a connection, by examining it - the equivalent of IPv4's SYN with no ACK. None of these is a real killer criterion - we can build firewalls even if we don't get any of these, but it certainly makes things tighter. If IPng makes firewalls weaker, some sites will be even more unhappy about upgrading to it. -- Tom Fitzgerald Wang Labs Lowell MA, USA 1-508-967-5278 fitz@wang.com Pardon me, I'm lost, can you direct me to the information superhighway? From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 21:58:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14802; Fri, 8 Apr 1994 21:58:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA12659; Fri, 8 Apr 1994 21:57:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA12642; Fri, 8 Apr 1994 21:40:51 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29097; Fri, 8 Apr 1994 15:21:27 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Fri, 8 Apr 1994 14:19:36 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id OAA07772; Fri, 8 Apr 1994 14:19:34 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA20206; Fri, 8 Apr 94 14:19:35 JST Date: Fri, 8 Apr 94 14:19:35 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404080519.AA20206@cactus.slab.ntt.jp> To: Christian.Huitema@sophia.inria.fr, lyman@BBN.COM Subject: Re: Turnipp - a merger proposal Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com, whyman@mwassocs.demon.co.uk > > > >The inconveniency of doing source routes with variable length address show in > >CLNP, where routers have to look inside the option field to determine the > >currently active destination address - not to mention that poor > >implementations that would not examine the option field might generate loops. > > Christian, > > You're not going to like this comment, but an implementation that does not > at least recognize the existence of a type-2 option field is not only poor, > it's non-conforming; it can discard the packet if it sees an option it > does not support, but it cannot ignore the presence of a source route > option field and forward the packet without looking into it. > Has CLNP changed since RFC994? RFC994 says that partial source routing is type 3, and therefore the packet can be forwarded without the router looking into the option. PF --- From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:00:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06881; Fri, 8 Apr 1994 18:18:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA12295; Fri, 8 Apr 1994 18:17:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA12292; Fri, 8 Apr 1994 18:12:09 +1000 Received: from brolga.cc.uq.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29310; Fri, 8 Apr 1994 15:27:13 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Fri, 8 Apr 1994 15:27:02 +1000 To: big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? In-Reply-To: Your message of "Thu, 07 Apr 1994 21:57:39 MST." <199404080457.VAA08996@dscs.arc.nasa.gov> X-Mailer: exmh version 1.3delta 3/31/94 Date: Fri, 08 Apr 1994 15:26:58 +1000 Message-Id: <23999.765782818@brolga.cc.uq.oz.au> From: George Michaelson We're a small (1 class B) campus network. delegated responsibilty to owners of the C-splits from most of the B. We've already decided we're going to run out of C-splits and now sub-sub-split to share for small departments, we could ask for CIDR to use as well but haven't. We have almost strict-tree structure cables:networks and we like it that way. We haven't had enough structure to need OSPF or loops, but we expect to see that inside of 2 years. In my opinion the Regional and National model scales accordingly, kre might disagree. We'd re-number if: (1) the wins were visible enough to sell the pain/cost to suits on campus. (if its a zero-dollar s/w shift, we'd still expect some human labour costs right?) (2) we had a way to do it in smaller chunks (subnet-by-subnet?). (3) we had a way to run parallel network spaces even on the same cables. (4) implementations of the new routing code were ROCK SOLID in the routers (cisco and wellfleet for us) and about 4 revisions out of beta-test. Even then we'd insist on running about 2 revs behind current if at all possible. (5) migration on a per-host basis was automated for a sensible list of platforms. perl, shell, we don't mind, as long as we can hand it out to the lobotomized and expect good things to happen. ditto with existing DNS translation. I can understand some bigger people (cern?) saying no way, but for us, and I suspect a VERY large number of B-owning campii, we can and we will do this *IF YOU HOLD OUR HANDS A LITTLE* We're even *resigned* to having no choice. Of course, if you can find a way to make it look less like a gunshot wedding, we may even do it early. If something really useful like (any of) RSVP or RTP or clean interop with virgin conformant CLNP or multicast-in-the-router or mobile-ip is bundled in for-free, we'd jump into it wide-eyed. -George From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:00:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14844; Fri, 8 Apr 1994 22:00:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA12674; Fri, 8 Apr 1994 21:58:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA12645; Fri, 8 Apr 1994 21:41:05 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28642; Fri, 8 Apr 1994 15:11:16 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA06745; Thu, 7 Apr 94 22:05:39 -0700 Received: by xirtlu.zk3.dec.com; id AA13249; Fri, 8 Apr 1994 01:05:33 -0400 Message-Id: <9404080505.AA13249@xirtlu.zk3.dec.com> To: Valdis Kletnieks Cc: kasten@ftp.com, jcurran@nic.near.net, Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Thu, 07 Apr 94 12:30:19 EDT." <940407.123019.EDT.VALDIS@vtvm1.cc.vt.edu> Date: Fri, 08 Apr 94 01:05:27 -0400 X-Mts: smtp On Wed, 6 Apr 94 17:43:46 EDT you said: >How many people have explicitly decided to not connect to the >Internet? Perhaps because of security? >Given that on comp.protocols.tcpip, there's at least 1 posting a week or >so saying "Can anybody tell me the benefits of being on The Net, since our >security goons^H^H^H^Hauditors aren't thrilled", I'd say it's a large number. Well I don't think we have the marketing arm or whatever its called to really figure this out so its a realistic conjecture on this mailing lists part (if I am wrong tell me I could be I am just guessing). But I do know we have a team of folks in the U.S., Europe, and Pacific RIM who specialize in setting up Internet Firewalls for customers and they all work well over the standard hours a week and are very busy training customers on how to do this. So I am seeing an increase for Firewalls at my limited end in engineering. But I can't say this proves anything either regarding Frank's orginal question. Also in the U.S. in my non-networking life (if there is such a life) I am running into folks who are electricians, mechanics, musicians, and other non-computer professionals who know of and use the Internet. So I really see an increase in its use by the private sector, again in my limited world. Its also a hot topic in the business forums on CNN. At least in the U.S. if folks figure out there is a benefit to the Internet they will find a way to use it. Its that captialist emotion I guess. Mosaic is taking off too big time. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:17:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08766; Fri, 8 Apr 1994 18:59:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA12390; Fri, 8 Apr 1994 18:57:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA12376; Fri, 8 Apr 1994 18:54:32 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16873; Fri, 8 Apr 1994 09:41:38 +1000 (from ericf@atc.boeing.com) Received: from [130.42.28.80] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25838 Fri, 8 Apr 1994 09:37:24 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA01727; Thu, 7 Apr 94 16:36:29 -0700 Date: Thu, 7 Apr 94 16:36:29 -0700 From: Eric Fleischman Message-Id: <9404072336.AA01727@atc.boeing.com> To: Bob.Hinden@Eng.Sun.COM, ericf@atc.boeing.com Subject: re: APIs in IPng Transition Cc: big-internet@munnari.OZ.AU Dear Bob, I am greatly comforted to note that you and I are thinking on the same wavelengths concerning IPng APIs. One question I would like to ask you about is sockets (and, to a lesser extent, WinSock). It is my presupposition that the IETF will need to propose an IPng extension to sockets since no consortium or standards group seens to "own" it (unless one wishes to take the controversial position that it is "owned" by IEEE POSIX). Anyway, I view sockets to be a different case than XTI/TLI et al. I am naturally very interested in how you view this matter and what your thoughts concerning sockets are. Would you mind elaborating on this particular case? Sincerely yours, --Eric Fleischman >Historically the IETF has not standardized API, but left it to groups >such as X/Open and POSIX. I don't think this should change. What I had >been hoping would happen is that after the IETF picks an IPng, that a >small set of IETF folks would define the extensions to support IPng for >Sockets and XTI/TLI API's, circulate these extentions (via the ID >process), and then take them to POSIX and X/Open to be standardized. I >think once the IETF has decided on an IPng this should be straight >forward. > >By the way, I have had some discussions with people in X/Open about a >loose working agreement where the IETF defines protocols and X/Open >defines API's. This seems like a reasonable division of >responsibilities. From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:20:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07756; Fri, 8 Apr 1994 18:39:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA12330; Fri, 8 Apr 1994 18:37:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA12313; Fri, 8 Apr 1994 18:24:29 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07178; Fri, 8 Apr 1994 18:25:39 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404080825.7178@munnari.oz.au> Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Apr 1994 09:24:35 +0100 To: big-internet@munnari.OZ.AU Subject: Re: Another firm requirement for IPNG In-Reply-To: Your message of "07 Apr 94 16:22:08 GMT." <9404071622.AA28932@tipper.oit.unc.edu> Date: Fri, 08 Apr 94 09:24:34 +0100 From: Jon Crowcroft Three more requirements: An IPng proposal shall have existed for more than 12 months before the decision time, in at least some for or other, including mergers... When a random sample of IETF attendees are asked to explain the IPng, 60% must be able to get the salient points right. When a random sample of ATM forum attendees are asked to explain a particular IPng, 40% of them must have heard of it... jon :-) From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:20:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15542; Fri, 8 Apr 1994 22:20:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA12724; Fri, 8 Apr 1994 22:19:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA12703; Fri, 8 Apr 1994 22:12:37 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06197; Fri, 8 Apr 1994 18:02:56 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Fri, 8 Apr 1994 17:02:30 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id RAA10346; Fri, 8 Apr 1994 17:02:30 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA26479; Fri, 8 Apr 94 17:02:30 JST Date: Fri, 8 Apr 94 17:02:30 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404080802.AA26479@cactus.slab.ntt.jp> To: big-internet@munnari.OZ.AU Subject: strange flow ID bug..... I was going over SIPP forwarding for the purpose of my thesis, and pondering on how use of the flow ID really works in a kind of soft-state approach (where the full addressing is carried in the packet, but the router only forwards on flow ID). I found an interesting error condition which I describe below. This condition isn't just in SIPP, but perhaps in any protocol that uses a VCI+fullAddressing approach. Thus, maybe it applies to RSVP as well (though I'm not sure because I haven't followed RSVP as closely as I'd like to). (Perhaps the RSVP folks have already thought of this.) In fact, it is premature to say that this condition is in SIPP at all, since SIPP hasn't yet decided how to use the flow ID. I'm assuming a technique where a flow is setup, and packets are being routed according to the flow ID (possibly combined with other info, such as source address). At some point in time, a failure occurs so that a router can no longer forward according to the flow that was set up. Therefore, the router falls back on best-effort forwarding, using the full address information. Consider the case where the original packet was source routed (ala SIPP hierarchical addresses), so that initially the packet targetted router B, and then subsequently targetted destination host D. On the path between router B and host D is router C. After the flow is setup, the original path between C and D fails, so that C re-routes the packet on an alternate path to D. This path, however, goes through B. B receives the packet, looks at the flow ID, and forwards the packet towards C, resulting in a loop. One way I've thought of to fix this is for routers to only honor the flow ID if the hop count is the same as it was when the flow ID is set up. Thus, if a loop occurs, then the packet will be routed correctly. Anyway, it's a thought..... PF From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:21:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09481; Fri, 8 Apr 1994 19:19:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA12427; Fri, 8 Apr 1994 19:17:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA12422; Fri, 8 Apr 1994 19:12:47 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17695; Fri, 8 Apr 1994 10:10:46 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA23049; Thu, 7 Apr 94 17:10:28 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA23221; Thu, 7 Apr 94 17:09:33 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA27803; Thu, 7 Apr 1994 17:10:20 -0700 Date: Thu, 7 Apr 1994 17:10:20 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404080010.AA27803@jurassic.Eng.Sun.COM> To: Eric Fleischman Cc: Bob.Hinden@Eng.Sun.COM, big-internet@munnari.OZ.AU In-Reply-To: <9404072336.AA01727@atc.boeing.com> Subject: re: APIs in IPng Transition Eric, > I am greatly comforted to note that you and I are thinking on the same > wavelengths concerning IPng APIs. One question I would like to ask you > about is sockets (and, to a lesser extent, WinSock). It is my > presupposition that the IETF will need to propose an IPng extension to > sockets since no consortium or standards group seens to "own" it (unless > one wishes to take the controversial position that it is "owned" by IEEE > POSIX). Avoiding the issue of who owns sockets, I think that the extensions to sockets to support IPng would not differ in the versions of sockets that groups are attempting to define. Hopefully the "controversy" which I think you refer will be resolved soon. It is not in anyones interest to have multiple almost identical API's. Bob From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:26:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09730; Fri, 8 Apr 1994 19:24:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA12445; Fri, 8 Apr 1994 19:22:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA12395; Fri, 8 Apr 1994 18:58:32 +1000 Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16878; Fri, 8 Apr 1994 09:41:46 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA05657; Thu, 7 Apr 94 19:37:46 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9404072337.AA05657@wizard.gsfc.nasa.gov> Subject: Re: Introducing proxy aggregations? To: yakov@watson.ibm.com Date: Thu, 7 Apr 1994 19:37:46 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9404061937.12170@munnari.oz.au> from "yakov@watson.ibm.com" at Apr 6, 94 03:37:27 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1433 Yakov, > >One service provider told me years ago that you'd never get people > >to renumber when they switched... > > On the one hand I've been hearing assertions that renumbering is almost > "close to impossible". On the other hand, I know first hand of few > places that did renumbering of few hundred machines, and it didn't > consume an unsurmountable amount of efforts. At a few hundred machines, it may be manageable. At several thousand machines, it's a gargantuan undertaking. > So, I guess renumbering is feasible. That doesn't mean that renumbering > is a "piece of cake". There are things we can (and should) do to > facilitate renumbering. For example, widely deployed DHCP would be of > great help. DHCP is not a panacea. To really make renumbering of hosts a practical possibility requires some mechanism for automated DNS host registration and integrating the DHCP functionality with the DNS. Without this, I don't think renumbering will fly for medium or large scale organizations. > So, I guess renumbering is likely to become a permanent fixture in the > Internet, and we need to focus on how to make renumbering as simple as > possible. I agree with the last part of your statement about focusing on making renumbering as simple as possible. If renumbering is made relatively painless, with all that entails, then it becomes a non-issue, but we're a far way from there right now. > Yakov. -Bill From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:29:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10209; Fri, 8 Apr 1994 19:39:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA12477; Fri, 8 Apr 1994 19:37:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA12435; Fri, 8 Apr 1994 19:20:12 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB02927; Fri, 8 Apr 1994 16:46:00 +1000 (from karl@mcs.com) Received: from [192.160.127.80] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11411 Fri, 8 Apr 1994 16:45:47 +1000 (from karl@mcs.com) Received: by mercury.mcs.com (/\==/\ Smail3.1.28.1 #28.1) id ; Fri, 8 Apr 94 01:40 CDT Message-Id: From: karl@mcs.com (Karl Denninger) Subject: Re: Introducing proxy aggregations? To: tli@cisco.com (Tony Li) Date: Fri, 8 Apr 1994 01:40:23 -0500 (CDT) Cc: bsimpson@MorningStar.Com, big-internet@munnari.OZ.AU In-Reply-To: <199404072044.NAA23084@lager.cisco.com> from "Tony Li" at Apr 7, 94 01:44:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1083 > > > As a side comment, I'd like to point out that ALL of the existing IPng > > assume provider-based address assignment. As a corollary, in order to > > contain the volume of routing information switching providers would > > require renumbering with any of the IPng we have today on the table. > > SIPP will adapt automatically to any heirarchical topology. Tony Li wrote: > How does that differ from dynamically performing provider-based addressing? > You have to fix DNS in order for that to REALLY be dynamic. A fix for addressing which does not address domain resolution (and THIS is a bitch; note that you CANNOT require that someone run their own master nameservers in reality; we have customers who have NO IDEA how to do so). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Full Internet Connectivity (shell, Modem: [+1 312 248-0900] | PPP, SLIP, leased) in Chicago and 'burbs. Voice/FAX: [+1 312 248-8649] | Email "info@mcs.com". MCSNet is a CIX member. Fan Friendly Internet Here | WWW: http://www.mcs.net, gopher: gopher.mcs.net From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 22:32:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10231; Fri, 8 Apr 1994 19:40:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA12492; Fri, 8 Apr 1994 19:39:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA12450; Fri, 8 Apr 1994 19:23:04 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17894; Fri, 8 Apr 1994 10:18:51 +1000 (from atkinson@bodhi.itd.nrl.navy.mil) Received: from bodhi.itd.nrl.navy.mil by shark.mel.dit.csiro.au with SMTP id AA09902 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 8 Apr 1994 10:19:01 +1000 From: Ran Atkinson Message-Id: <9404072013.ZM2192@bodhi.itd.nrl.navy.mil> Date: Thu, 7 Apr 1994 20:13:13 -0400 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 23feb94) To: big-Internet@munnari.OZ.AU Subject: IPng and security Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@bodhi.itd.nrl.navy.mil (I am perhaps on one edge of this discussion, so please add salt to taste...) IMHO, confidentiality isn't critical at the IP-layer and should never be mandatory to implement. In some countries (e.g. France), use of cryptography to provide confidentiality is generally not permitted. In many countries (all of NATO, Australia, Japan, New Zealand, etc), export of cryptographic mechanisms which provide confidentiality are regulated by law (to varying degrees). Thus, we must not require that confidentiality be implemented in every box if we want to have a truly global Internet. By contrast, having solid authentication at the IP-layer is critically important to keeping the Internet up and running (e.g. precludes the ICMP Super Source Quench attack :-). I believe that a solid authentication mechanism should be provided up front in any IPng proposal and should be mandatory in all IPng implementations. It is possible to provide an easily implemented, easily exported, and useful authentication-only mechanism in at least one IPng proposal. I am unaware of any such work on the other two proposals and wish they would undertake such work. Ran atkinson@itd.nrl.navy.mil DISCLAIMER: These opinions are only mine. I have no idea what my employer thinks about this... From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 23:18:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17857; Fri, 8 Apr 1994 23:18:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA12843; Fri, 8 Apr 1994 23:17:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA12835; Fri, 8 Apr 1994 23:12:07 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17661; Fri, 8 Apr 1994 23:13:20 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404081313.17661@munnari.oz.au> Received: from cbt.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Apr 1994 14:12:46 +0100 To: whyman@mwassocs.demon.co.uk Cc: Christian.Huitema@sophia.inria.fr, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Fri, 08 Apr 94 11:01:15 BST." <9404081101.aa871@mwassocs.demon.co.uk> Date: Fri, 08 Apr 94 14:12:42 +0100 From: Jon Crowcroft >In order to get rid of this inefficiency, you could perhaps have flag bits in >the header to identify the presence of various options there are two approaches to optimising fast packet procesisng (i.e. compiled fast paths): 1. predefine the option order/precedence and relavance 2. as you say, have a flag field to indicate the presence both are extensible - you just need a predefined option extension option, or a bit to inidcate the presence of an extension option flag option....same difference - SIPP chooses the former, the RTP (audio video transport) people may chose the latter... so long as the code doesnt have to do more than a nice big jump table, or header prediction is feasible, i'm happy jon From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 23:20:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17881; Fri, 8 Apr 1994 23:20:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA12858; Fri, 8 Apr 1994 23:18:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA12840; Fri, 8 Apr 1994 23:15:32 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17827; Fri, 8 Apr 1994 23:16:48 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404081316.17827@munnari.oz.au> Received: from cbt.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Apr 1994 14:15:52 +0100 To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU Subject: Re: strange flow ID bug..... In-Reply-To: Your message of "Fri, 08 Apr 94 17:02:30 +0200." <9404080802.AA26479@cactus.slab.ntt.jp> Date: Fri, 08 Apr 94 14:15:51 +0100 From: Jon Crowcroft >One way I've thought of to fix this is for routers to only >honor the flow ID if the hop count is the same as it was when >the flow ID is set up. Thus, if a loop occurs, then the >packet will be routed correctly. if a flowif is truly source dependentm, then it should depend on source route info too... if a route changes, then a router weill be hit by a flow it doesnt have soft state for (it'll hash the flow-id to a PCB, find none) and have to recxonstruct the full info from the src, dsty, src route, qos etc.... if a route changes, and a flow is dependednt on out-of-band rsvp info, the PATH/RESV refresh from RSVP will refresh that info i nthe new route, and the timeout delete it in the old... i..e why is there a problem? jon From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 23:21:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18101; Fri, 8 Apr 1994 23:21:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA12873; Fri, 8 Apr 1994 23:19:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA12821; Fri, 8 Apr 1994 23:09:10 +1000 From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20513; Fri, 8 Apr 1994 11:37:23 +1000 (from jcjones@MIT.EDU) Received: from W20-575-109.MIT.EDU by MIT.EDU with SMTP id AA15954; Thu, 7 Apr 94 21:37:13 EDT Received: by w20-575-109.MIT.EDU (5.0/4.7) id AA00882; Thu, 7 Apr 94 21:37:12 EDT Message-Id: <9404080137.AA00882@w20-575-109.MIT.EDU> To: Big-Internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of Thu, 07 Apr 94 12:30:19 -0400. <940407.123019.EDT.VALDIS@vtvm1.cc.vt.edu> Date: Thu, 07 Apr 94 21:37:11 EDT Content-Length: 3585 A couple of days ago, I didn't know what flows were, but thanks to Masataka, Noel, and Jon, I think that I am starting to get a clue. Here are my $0.02 on the subject: My understanding is that the purpose of a flow is to help make sure that an application receives a desired/required quality of service for the duration of its connection to one or many other target processes. The explanations that I have received from Big Internauts so far all seem to focus on the parameters of throughput and latency, while someone has also mentioned security as a parameter. Here I focus on latency and throughput. The approach I took when designing the network layer of my protocol stack was to keep most of the complexity of quality of service specifications in the session and transport layers. When one process connects to another, it specifies its desired quality of service while initializing the connection. So far, the parameters that I have allowed to be specified include security, compression, no-response timeouts, average inter-byte latency, and average inter-byte throughput. Again, I am only focusing on latency and throughput in this message. The result of having a process specify these two parameters at connection time is two signed bytes in my network layer (IP) packets. One byte specifies the maximum *average* inter-byte latency, and the other specifies the minimum average throughput in bytes per second for the requesting process. I'll explain in a minute why I use only two bytes, but first, an example: EXAMPLE: There is a "two-person teleconference application" that continually grabs video and audio data and transmits the data to a remote partner application for recreation. Video images from a camera are sampled at 24 frames per second, and each frame has dimensions of 1280x1024x3. Thus, the resulting throughput requirement for video is about 94 Mb/s. The derivation of the latency requirement is very similar, but a bit more complicated, as it has to do with MTU's and packet fragmentation, but follows basically the same principle. The requirements of the application's audio stream are not as stringent as those of the video and will be ignored here. At connection setup time, this application specifies an average throughput requirement of 27, which is the round-up of the log-base-2 of 94,000,000. The 27 is carried around in every IP packet as an indication of the relative urgency (priority) of the flow associated with this packet in terms of throughput. Every intermediate node between the two teleconference processes sees the 27 and makes an appropriate routing decision based on the values in the average throughput fields of the other packets residing at that node. For example, a co-resident packet associated with an E-mail message of 1800 bytes might have a throughput requirement of -1 (0.5 bytes per second or 1 byte every two seconds) which means, try to get this E-mail message to the next hop within an hour." In such a case, the teleconference packet will obviously take precedence. This is roughly how I'm trying to do things. I have never actually used these fields , so my design philosophy is probably infested with bugs. -JC Jones- P.S. My girlfriend, Inge, wants to know what happens when the flow-ID approach is used and there is a hardware failure at an intermediate node? Would there be a need for a massive refresh of all the intermediate nodes' state tables? Please be gentle while flaming her:-). She studies omputational linguistics and asks only because she's curious. From owner-Big-Internet@munnari.OZ.AU Fri Apr 8 23:51:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07887; Fri, 8 Apr 1994 18:42:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA12358; Fri, 8 Apr 1994 18:40:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA12327; Fri, 8 Apr 1994 18:29:20 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16025; Fri, 8 Apr 1994 09:13:10 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12277; Thu, 7 Apr 94 16:11:50 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA17331; Thu, 7 Apr 94 16:11:01 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA23423; Thu, 7 Apr 1994 16:11:46 -0700 Date: Thu, 7 Apr 1994 16:11:46 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404072311.AA23423@jurassic.Eng.Sun.COM> To: Eric Fleischman Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404071543.AA11093@atc.boeing.com> Subject: re: APIs in IPng Transition Eric, > There has been a discussion within the IPng Directorate concerning whether > APIs are an essential part of the IPng Transition or not. My view of the > rough consensus to date is that consortia and vendor-defined APIs such > as TLI, XTI, Revised XTI, CTI, and MPTN are outside of our domain and must > be defined and migrated by their owners. I agree that API's are an important part of IPng. Note the API work for SIPP. Historically the IETF has not standardized API, but left it to groups such as X/Open and POSIX. I don't think this should change. What I had been hoping would happen is that after the IETF picks an IPng, that a small set of IETF folks would define the extensions to support IPng for Sockets and XTI/TLI API's, circulate these extentions (via the ID process), and then take them to POSIX and X/Open to be standardized. I think once the IETF has decided on an IPng this should be straight forward. By the way, I have had some discussions with people in X/Open about a loose working agreement where the IETF defines protocols and X/Open defines API's. This seems like a reasonable division of responsibilities. Bob From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 01:56:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15507; Fri, 8 Apr 1994 22:18:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA12709; Fri, 8 Apr 1994 22:17:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA12706; Fri, 8 Apr 1994 22:14:31 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15264; Fri, 8 Apr 1994 22:15:28 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA28083; Fri, 8 Apr 94 07:18:52 -0500 Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA14883; Fri, 8 Apr 94 07:15:14 CDT Date: Fri, 8 Apr 94 07:15:14 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9404081215.AA14883@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Here's another take on the security/firewall issue. If IPng makes it totally impossible to do any kind of sane hop-by-hop sanity checking and security, this will force the users to implement real end-to-end security instead of the wretched toys we see today. The down side is that I don't see how to make this work well for datagrammy kinds of things like nameservice lookups. It might be worth considering the idea that datgrammy kinds of lookups, by decree, shall not ever really care if they get the wrong data. For example: If host name lookups are used only to find the remote address, and then real authentication is done before you do anything of substance with the remote, and in particular if rlogin style authentication is explicitly not done, you can afford to not really care if the name server lied to you. If you have critical applications that cannot be vulnerable to denial of service attacks, don't use DNSng. I'd prefer to see an IPng that could be filtered more easily than the present system, but it's not obvious to me that this is a requirement. My employer might well disagree violently, by the way. Andrew From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 01:56:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16179; Fri, 8 Apr 1994 22:39:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA12760; Fri, 8 Apr 1994 22:37:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA12755; Fri, 8 Apr 1994 22:33:37 +1000 Received: from dem.ehnr.state.nc.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15943; Fri, 8 Apr 1994 22:34:48 +1000 (from mikem@dem.ehnr.state.nc.us) Received: from [149.168.123.32] (isb2.ehnr.nc.gov) by dem.ehnr.state.nc.us (4.1/tas-concert/6-19-91) id AA11241; Fri, 8 Apr 94 08:40:20 EDT Message-Id: <9404081240.AA11241@dem.ehnr.state.nc.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Apr 1994 08:34:44 -0400 To: big-internet@munnari.OZ.AU From: mikem@dem.ehnr.state.nc.us (Michael Maxson) Subject: unsubscribe unsubscribe big-internet mikem@dem.ehnr.nc.gov From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 01:59:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24724; Sat, 9 Apr 1994 01:59:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA13148; Sat, 9 Apr 1994 01:57:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA13145; Sat, 9 Apr 1994 01:56:26 +1000 Received: from chsun.eunet.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24694; Sat, 9 Apr 1994 01:57:38 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id RAA04636; Fri, 8 Apr 1994 17:59:08 +0200 Message-Id: <199404081559.RAA04636@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <11348-0@magnolia.eunet.ch>; Fri, 8 Apr 1994 17:57:38 +0200 Subject: Re: Costs, renumbering and IPng To: pld@math.luc.edu (Peter Dordal) Date: Fri, 8 Apr 1994 17:57:22 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU, pld@math.luc.edu In-Reply-To: <9404081433.AA08784@dedekind.math.luc.edu> from "Peter Dordal" at Apr 8, 94 09:33:13 am X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1899 From: Simon Poole Sender: poole@magnolia.eunet.ch > > At this point, it is entirely up to the customer to decide if renumbering is > worth the discount. If an organization pays $1000/mo and gets $200 off for renumbering, > maybe it isn't. If they had the foresight to adopt a scheme where IPng > addresses are easily reassigned administratively, maybe it is. > If the costs are $800/mo with renumbering and $100,000/mo without > [since the carrier has to lease a Cray to do the routing], > most customers will renumber. At any rate, the carrier covers their costs. > Sorry, but I think you missed the essence of my assertion. The net result of any substantial cost in changing providers will be that customers will not change. A reasonable assumption is that cost of renumbering << 1 years cost advantage of changing provider will have to hold for any market to continue to exist. Assummimg that a 64k connection will not cost more than $12k per year, that you will not be able to save more than 50% of that, and would not want to spend more than 10% of that on a renumbering effort. You get an upper bound on the cost of renumbering of $600. If you only have a couple of machines this is obviously doable, if any real work has to be invested just as obviously not. In any case I think the parallel thread on security has some interesting implications in this thread. -If- we could assume that most commercial sites would -not- have direct IPng connectivity and that Internet-ng access would typically be through a company firewall (one or more) then the situation would seem to be a bit less dramatic. The requirements then would be a large amount of provider independent address space for internal purposes and a small number of addresses for the external connectivity that could very well fit in to some provider based topology. However I'm not convinced that this is really the way things will develop. Simon From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:17:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16972; Fri, 8 Apr 1994 22:59:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA12805; Fri, 8 Apr 1994 22:57:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA12791; Fri, 8 Apr 1994 22:49:27 +1000 Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11326; Fri, 8 Apr 1994 20:04:18 +1000 (from whyman@mwassocs.demon.co.uk) Date: Fri, 08 Apr 1994 11:01:15 BST Message-Id: <9404081101.aa871@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: Christian.Huitema@sophia.inria.fr Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal X-Mailer: Cinetic Mail Manager V2.1 | |From: Christian Huitema | | | |=> | |From: bound@zk3.dec.com | |=> | |One caution I have is that a variable address is nice, but I think we | |=> | |need to define some limit initially for the structures and arrays that | |=> | |will house the IPng address. Even GOSIP did this and we can to. | |=> | |=> I take the opposite view. Imposing a limit other than that imposed by the | |=> address length field itself is unnecessary and does no more than impose an | |=> artificial limit on both growth and possible uses of a large address space. | | | |Variable length addresses are fine, but fixed length have advantages, notably | |when handling source routes. One of the neat points of the SIPP design is that | |it allows variable length "by chunks of 64bits" while retaining a fixed format | |header. | | | |The inconveniency of doing source routes with variable length address show in | |CLNP, where routers have to look inside the option field to determine the | |currently active destination address - not to mention that poor | |implementations that would not examine the option field might generate loops. | |If one wants to remove the need for every intermediate router to examine the | |option field, then one must be ready to recompose a new header at each | |source routed relay. Which is probably not a zero cost operation. | | | |Christian Huitema | | | | The point you are making is more of an argument against CLNP's way of handling source routing (and more generally, CLNP's handling of protocol options) rather than variable length addresses. If you were designing a protocol from a clean sheet (which to some extent is what Tony Li proposed) then the fixed part of the header can always include an "offset to active destination address" field to avoid parsing the rest of the header - a simple extension of CLNP's source routing mechanism. (In fact if you make the offset relative to the proper destination address, then an offset of zero would imply no source routing). In the case of CLNP, however, analysis of the options field is always required - as Lyman has pointed out - in order to check for type 2 options, such as source routing and route recording, and is also required if the router supports any other options, such as QoS Maintenance. There is thus no benefit in changing the CLNP fixed header to include the kind of offset field discussed above, unless you can also remove the need to parse options period. Your perceived inefficient handling of source routing in CLNP is a consequence of variable options, not variable length addresses. In order to get rid of this inefficiency, you could perhaps have flag bits in the header to identify the presence of various options, or different format headers for different situations, but these approaches may limit the potential for adding new options as the need arises and for special purpose use. In the end, there is a trade-off between what is the most efficient encoding for a given implementation, and what is the most flexible future proof approach. What could be an interesting avenue to explore is to view Tony Li's proposal as being a "compressed CLNP" i.e. choosing the options you need and optimising the protocol header for those options only, with the full CLNP still available for use when required. The important thing to do is to have a common addressing plan and identical semantics for common functions. Such an approach could be very attractive if it can be made to meet the concerns of those that prefer fixed field encodings, while allowing for compatibility with existing CLNP. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:36:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21509; Sat, 9 Apr 1994 00:39:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA12979; Sat, 9 Apr 1994 00:37:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA12963; Sat, 9 Apr 1994 00:25:37 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21024; Sat, 9 Apr 1994 00:26:51 +1000 (from lyman@BBN.COM) Message-Id: <9404081426.21024@munnari.oz.au> From: Lyman Chapin Subject: Re: Turnipp - a merger proposal To: francis@cactus.slab.ntt.jp Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com, Christian.Huitema@sophia.inria.fr, lyman@BBN.COM, whyman@mwassocs.demon.co.uk In-Reply-To: <9404080519.AA20206@cactus.slab.ntt.jp> Date: Fri, 8 Apr 94 09:32:29 EDT Mail-System-Version: >Date: Fri, 8 Apr 94 14:19:35 JST >From: francis@cactus.slab.ntt.jp (Paul Francis) >To: Christian.Huitema@sophia.inria.fr, lyman@BBN.COM >Subject: Re: Turnipp - a merger proposal >Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com, whyman@mwassocs.demon.co.uk > >> > >> >The inconveniency of doing source routes with variable length address show in >> >CLNP, where routers have to look inside the option field to determine the >> >currently active destination address - not to mention that poor >> >implementations that would not examine the option field might generate loops. >> >> Christian, >> >> You're not going to like this comment, but an implementation that does not >> at least recognize the existence of a type-2 option field is not only poor, >> it's non-conforming; it can discard the packet if it sees an option it >> does not support, but it cannot ignore the presence of a source route >> option field and forward the packet without looking into it. >> > >Has CLNP changed since RFC994? RFC994 says that partial source routing >is type 3, and therefore the packet can be forwarded without the router >looking into the option. > >PF Paul, You're right - partial source routing is type 3, complete source routing is type 2. But that's why partial source routing doesn't work for CLNP (routing loops), and why we have an amendment in progress in SC6 to change PSR to be a type 2 option (and at the same time, allowing the entries in the PSR option to be NETs - effectively, area prefixes - so that PSR can be used to support provider selection). I don't know of anyone who uses the current (broken) PSR in CLNP, precisely because of the possibility of generating loops. [In my response to Christian, I was assuming complete source routing.] - Lyman From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:36:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21738; Sat, 9 Apr 1994 00:44:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA13035; Sat, 9 Apr 1994 00:42:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA12966; Sat, 9 Apr 1994 00:28:17 +1000 Received: from dedekind.math.luc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21085; Sat, 9 Apr 1994 00:29:31 +1000 (from pld@math.luc.edu) Received: by dedekind.math.luc.edu (4.1/SMI-4.1) id AA08784; Fri, 8 Apr 94 09:33:13 CDT Date: Fri, 8 Apr 94 09:33:13 CDT From: pld@math.luc.edu (Peter Dordal) Message-Id: <9404081433.AA08784@dedekind.math.luc.edu> To: big-internet@munnari.OZ.AU, pld@math.luc.edu Subject: Re: Costs, renumbering and IPng > My personal belief is that should a company be given a choice in Internet > exchange carriers and should that company decide to switch carriers it is > unreasonable to imagine that that company would be willing to readdress > as part of the bargain. > Similarly, the "new carrier" is not likely to insist that the company > re-address because such insistence will probably convince the company that > the new carrier isn't so great after all and so that they will take their > business elsewhere -- to a carrier who is more "reasonable". > For this reason, I have always thought that "provider based addressing" > is unrealistic and A Bad Thing. To me, it is merely another instance that > significant percentages of the IETF do not understand even elementary > market realities. I think this problem is quite amenable to market-based solutions: New carriers will simply provide discounts to customers willing to renumber. After all, renumbering saves the carrier real dollars, both in direct equipment costs and charges from the backbone [if, indeed, the backbone starts charging (in part) by the route, which I think it should]. At this point, it is entirely up to the customer to decide if renumbering is worth the discount. If an organization pays $1000/mo and gets $200 off for renumbering, maybe it isn't. If they had the foresight to adopt a scheme where IPng addresses are easily reassigned administratively, maybe it is. If the costs are $800/mo with renumbering and $100,000/mo without [since the carrier has to lease a Cray to do the routing], most customers will renumber. At any rate, the carrier covers their costs. I don't think this will make changing carriers such a burden -- if anything, it will be simpler because the customer will have a choice. If carriers find they don't really save much, the discounts will be small. In that case, though, customers won't have to feel guilty not renumbering "for the good of the net". It never fails to amaze me how small a discount has to be to motivate some people. peter dordal loyola univ chicago math dept If you want real CIDR, you have to be prepared to squeeze. [sorry] From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:37:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23143; Sat, 9 Apr 1994 01:20:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA13089; Sat, 9 Apr 1994 01:17:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA13075; Sat, 9 Apr 1994 01:02:28 +1000 Received: from bodhi.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22481; Sat, 9 Apr 1994 01:03:36 +1000 (from atkinson@bodhi.itd.nrl.navy.mil) From: Ran Atkinson Message-Id: <9404081059.ZM2408@bodhi.itd.nrl.navy.mil> Date: Fri, 8 Apr 1994 10:59:24 -0400 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 23feb94) To: big-Internet@munnari.OZ.AU Subject: IPng APIs Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@bodhi.itd.nrl.navy.mil Folks, I think that Eric's assertion that we should try to reach consensus on Sockets and XTI/TLI extensions for IPng is not controversial. One of the reasons that the Internet protocols have been successful is application portability made possible by a standard and widespread API for Sockets interfacing to TCP/UDP/IP. The SIPP WG has had an API spec out as an I-D for a while now. I know that NRL has been paying particular attention to that API specification in our SIPP for BSD implementation. I am peripherally involved (that is: not doing the work, but rather actively watching it) in the POSIX work on Sockets and TLI/XTI standardisation. That POSIX work is trying to just write down the existing de facto standards without major change. I think that it would be reasonable for interested folks to take a written IPng Sockets or TLI/XTI extension (perhaps in the form of an Informational RFC) to the POSIX folks once IPng is selected. I also think that the POSIX folks would be agreeable to adding that in during their normal review cycles. At present, the protocol specific parts of the POSIX spec are in separate sections of the document. Support for IPng would mean adding some smallish new sections on "application of Sockets to IPng" and should be straight forward. I ran the earlier SIP spec past the POSIX folks a year ago (just as a test of how protocol independent their main chapters were written, NOT to add support for SIP to POSIX prematurely). The POSIX document appeared to be well structured for use in a multi-protocol world. The other IPng proposals might want to get a copy of the POSIX draft or the BSD API specs and write up a short I-D on how they would extend Sockets/TLI to support their IPng proposal. Certainly that would be useful. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:37:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25515; Sat, 9 Apr 1994 02:20:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA13181; Sat, 9 Apr 1994 02:17:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA13164; Sat, 9 Apr 1994 02:07:24 +1000 Received: from efficient.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20023; Sat, 9 Apr 1994 00:06:41 +1000 (from tbuckley@efficient.com) Received: from parrot.efficient.com by efficient.com (5.0/SMI-SVR4) id AA24157; Fri, 8 Apr 94 09:05:18 CDT Received: by parrot.efficient.com (5.0/SMI-SVR4) id AA10333; Fri, 8 Apr 1994 09:06:38 +0600 Date: Fri, 8 Apr 1994 09:06:38 +0600 From: tbuckley@efficient.com (Terry Buckley) Message-Id: <9404081406.AA10333@parrot.efficient.com> To: big-internet@munnari.OZ.AU Subject: unsubscribe Content-Type: text Content-Length: 196 unsubscribe big-internet Terry Buckley tbuckley@efficient.com Efficient Networks, Inc. Bringing ATM Technology to the Desktop (214) 991-3884. From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:37:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25539; Sat, 9 Apr 1994 02:21:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA13204; Sat, 9 Apr 1994 02:19:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA13178; Sat, 9 Apr 1994 02:10:38 +1000 Received: from norge.unet.umn.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18556; Fri, 8 Apr 1994 23:34:01 +1000 (from fin@unet.umn.edu) Received: by norge.unet.umn.edu (5.65c) id AA17014; Fri, 8 Apr 1994 08:33:47 -0500 Date: Fri, 8 Apr 1994 08:33:47 -0500 From: "Craig A. Finseth" Message-Id: <199404081333.AA17014@norge.unet.umn.edu> To: bill@wizard.gsfc.nasa.gov Cc: yakov@watson.ibm.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: Bill Fink's message of Thu, 7 Apr 1994 19:37:46 -0400 (EDT) <9404072337.AA05657@wizard.gsfc.nasa.gov> Subject: Introducing proxy aggregations? ... > On the one hand I've been hearing assertions that renumbering is almost > "close to impossible". On the other hand, I know first hand of few > places that did renumbering of few hundred machines, and it didn't > consume an unsurmountable amount of efforts. At a few hundred machines, it may be manageable. At several thousand machines, it's a gargantuan undertaking. ... We have direct, relevant experience here. As part of our routine network growth, we occasionally renumber all hosts in a building. This renumbering provides an opportunity to actually verify that we have found all hosts and that we have found someone who will be responsible for each host. Our experience is this: the bulk of all hosts in a building can be migrated farily quickly. It doesn't matter too much whether the host is manually configured or uses BOOTP (we offer central BOOTP service that is tied in with the DNS). HOWEVER! There are usually a significant number (say 5-15) of hosts in each building that we have enormous difficulty in getting converted. Typically, these are machines that are running fine and doing a useful job. But the person who configured them is no longer around. The person who they trained in is no longer around. The vendor may well be out of business or at the least is not supporting the host anymore. There is literally no one who knows how the hosts work. But they do. It takes a lot of arm-twisting to get someone to step forward and take responsibility for the host. The worst such conversion took 15 months. Oh, yes. We have 200 buildings. By the time we finished an address conversion, the new carrier would probably be out of business... Address conversion is not a serious possibility for large sites. We will reqiure that any new carrier carry our old addresses. And we're large enough that they will be happy to. This is because: Cost(our conversion) >>>>>>> Cost(carrier to handle old address) I expect the benefits of carrier-based addressign to last for only a year or so. Craig A. Finseth Craig.A.Finseth-1@umn.edu University Networking Services fin@unet.umn.edu University of Minnesota +1 612 624 3375 desk 130 Lind Hall +1 612 625 0006 problems 207 Church St SE +1 612 626 1002 fax Minneapolis MN 55455-0134, USA member, LPF "A ship is safe in a harbor, but that's not what a ship is for" -- unknown From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:39:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26274; Sat, 9 Apr 1994 02:39:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA13235; Sat, 9 Apr 1994 02:37:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA13186; Sat, 9 Apr 1994 02:18:13 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20219; Sat, 9 Apr 1994 00:11:37 +1000 (from Z.Wang@cs.ucl.ac.uk) Message-Id: <9404081411.20219@munnari.oz.au> Received: from reeves.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Apr 1994 15:11:03 +0100 To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU Subject: Re: strange flow ID bug..... In-Reply-To: Your message of "Fri, 08 Apr 94 17:02:30 +0200." <9404080802.AA26479@cactus.slab.ntt.jp> Date: Fri, 08 Apr 94 15:11:01 +0100 From: Zheng Wang >Consider the case where the original packet was source routed >(ala SIPP hierarchical addresses), so that initially the >packet targetted router B, and then subsequently targetted >destination host D. On the path between router B and host D is router >C. After the flow is setup, the original path between C and >D fails, so that C re-routes the packet on an alternate path >to D. This path, however, goes through B. B receives the packet, >looks at the flow ID, and forwards the packet towards C, resulting >in a loop. Paul, I think the scenario you've described above is real and is not confined to SIPP. In some sense, the problem is very similar to that in alternate routing where there are more than one paths. Loops may be formed if you allow routers to shift packets between the alternative paths more than once. Since the dest-based path (used in emergence) differs from the flow-based path, they may be viewed as two alternate paths. In your scenario, the routers shift the packets twice (once at C and once at B) thus may form a loop. The solution I used in our alternate routing is to have a bit in the packet header. When a router uses an alternate path, it sets the bit so the packet will be forwarded along the alternate path. I think the technique can be applied to solve the problem you've described. When C re-routes the packet, it sets a bit in the header so B knows that it must forward the packet based on dest rather than flow. Hopefully the routes has been updated by then thus the dest-based forwarding can send the packet to a correct path. Flow-based route will be updated in the next PATH/RESV flush, and the flow-based route and dest-based route become consistent again. Cheers Zheng From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:41:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26326; Sat, 9 Apr 1994 02:41:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA13253; Sat, 9 Apr 1994 02:39:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA13197; Sat, 9 Apr 1994 02:18:51 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19989; Sat, 9 Apr 1994 00:05:21 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404081405.19989@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Apr 1994 15:03:52 +0100 To: jcjones@MIT.EDU Cc: Big-Internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng In-Reply-To: Your message of "Thu, 07 Apr 94 21:37:11 EDT." <9404080137.AA00882@w20-575-109.MIT.EDU> Date: Fri, 08 Apr 94 15:03:50 +0100 From: Jon Crowcroft >The result of having a process specify these two parameters at >connection time is two signed bytes in my network layer (IP) packets. >One byte specifies the maximum *average* inter-byte latency, and the >other specifies the minimum average throughput in bytes per second for >the requesting process. I'll explain in a minute why I use only two >bytes, but first, an example: unforutnately, the question of flow is rather more complex than this - i suggest people read the very excellent introduction to integrated services wrriten by scott shenker, dave clark and lixia zhang - c.f sigcomm 92, or the integrated services ietf wg - check out the mail archive on isi.edu... basically, some applications can pre-state their requirements & some can't except in the broadest terms - the former are either capturesd as firm parameters, or as ranges of tradable parameters - e.g. constandt biterate and delay, or delay, average and peak bandwidth, or jitter & average and burst lenght and so on and so on...while things like the latter (e.g. FTP) have effectively near to infiniate range of bandwidth requirements...(and can be met by what we call 'best effort' ad what the ATM people called available bitrate service, and what i call avaialble bitrot...) >P.S. My girlfriend, Inge, wants to know what happens when the flow-ID > approach is used and there is a hardware failure at an > intermediate node? Would there be a need for a massive > refresh of all the intermediate nodes' state tables? in the ip integrated services model, a flowid contains information that may partially, or fully, be reconstruvcted from other fields in the packet - so if a route changes, then a packet hits a router that doesn;t have an entry for that flow, and it re-calculates it - if out-of-band information is needed, it will either preced, or shortly follow the packet, either from the sink or source, i.e. there is no once-only setup in the flow model - the stteady state admits of dynamic routing, as either the packet is self-describing, or else the application/service includes periodic refresh of any out-of-band state jon to plagiarise a phrase, everything goes with the flow... From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 02:59:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27085; Sat, 9 Apr 1994 02:59:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA13300; Sat, 9 Apr 1994 02:57:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA13240; Sat, 9 Apr 1994 02:37:53 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26266; Sat, 9 Apr 1994 02:39:00 +1000 (from yakov@watson.ibm.com) Message-Id: <9404081639.26266@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2573; Fri, 08 Apr 94 12:38:56 EDT Date: Fri, 8 Apr 94 12:38:56 EDT To: poole@magnolia.eunet.ch Cc: big-internet@munnari.OZ.AU, pld@math.luc.edu Subject: Costs, renumbering and IPng Ref: Your note of Fri, 8 Apr 1994 17:57:22 +0200 (MET DST) Simon, >The requirements then would be a large amount of provider independent >address space for internal purposes and a small number of addresses for >the external connectivity that could very well fit in to some provider >based topology. Just like to mention that RFC1597 already specifies a block of addresses for internal purposes. The block is reserved by the IANA. Yakov. From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 03:01:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27112; Sat, 9 Apr 1994 03:01:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA13315; Sat, 9 Apr 1994 02:59:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA13282; Sat, 9 Apr 1994 02:43:22 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22200; Sat, 9 Apr 1994 00:56:10 +1000 (from lyman@BBN.COM) Message-Id: <9404081456.22200@munnari.oz.au> From: Lyman Chapin Subject: Re: strange flow ID bug..... To: J.Crowcroft@cs.ucl.ac.uk Cc: big-internet@munnari.OZ.AU, francis@cactus.slab.ntt.jp In-Reply-To: <9404081316.17827@munnari.oz.au> Date: Fri, 8 Apr 94 09:55:02 EDT Mail-System-Version: >To: francis@cactus.slab.ntt.jp (Paul Francis) >Cc: big-internet@munnari.oz.au >Subject: Re: strange flow ID bug..... >Date: Fri, 08 Apr 94 14:15:51 +0100 >From: Jon Crowcroft > > > > >One way I've thought of to fix this is for routers to only > >honor the flow ID if the hop count is the same as it was when > >the flow ID is set up. Thus, if a loop occurs, then the > >packet will be routed correctly. > >if a flowif is truly source dependentm, then it should depend on source route info >too... > >if a route changes, then a router weill be hit by a flow it doesnt have soft state for >(it'll hash the flow-id to a PCB, find none) and have to recxonstruct the full info >from the src, dsty, src route, qos etc.... Jon, My understanding of Paul's scenario is that the route change involves a router (C in Paul's example) that does not look at the flow ID (it just forwards packets towards the destination D). The route changes between C and D, but B's shortest-path route to D is still through C, even though C's path to D now goes through B. Surely this loop will be detected by both C and B after new routing updates have been exchanged? If an alternate path from C to D goes through B, then B presumably has a path to D that does not involve C, and will switch to that path when the new state of the C-to-D link has propagated to B. Doesn't look like a problem to me, unless I've missed something in Paul's note. - Lyman > >if a route changes, and a flow is dependednt on out-of-band rsvp info, >the PATH/RESV refresh from RSVP will refresh that info i nthe new route, and the >timeout delete it in the old... > >i..e why is there a problem? > > jon > From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 03:38:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28197; Sat, 9 Apr 1994 03:38:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA13368; Sat, 9 Apr 1994 03:37:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA13347; Sat, 9 Apr 1994 03:21:12 +1000 Received: from bodhi.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22752; Sat, 9 Apr 1994 01:08:54 +1000 (from atkinson@bodhi.itd.nrl.navy.mil) From: Ran Atkinson Message-Id: <9404081105.ZM2415@bodhi.itd.nrl.navy.mil> Date: Fri, 8 Apr 1994 11:05:53 -0400 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 23feb94) To: big-Internet@munnari.OZ.AU Subject: IPng & Provider-oriented addressing Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@bodhi.itd.nrl.navy.mil Like Eric at Boeing, I am not entirely comfortable with the prospect of having to renumber my machines when I change providers. Moreover, NRL currently has several external network connections (e.g. SURAnet, DSI, MILnet, NASA Science Internet) and it is operationally awkward to require each of our machines to have multiple addresses, one per provider. I do understand the need to better aggregate addresses to permit the Internet to continue to grow rapidly, but I hope that the R&D community is continuing to examine alternatives to provider-oriented addressing. I believe that IPng support for DHCP is necessary but it is not sufficient to make provider-oriented addressing completely practical. This is an area that needs more attention within the IETF regardless of IPng (perhaps the Operations Area could examine this and make suggestions ?? :-). I liked the basic concept of geographic-based addressing, but the service providers didn't want to commit to cross-connecting their networks at multiple cities. I continue to think that campus-sized networks that are at fixed locations ought to have their own addresses. Also, very large privately operated networks (e.g. the US Navy or Boeing or Chrysler or IBM) ought to be able to get their own "provider" address blocks. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 03:40:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28331; Sat, 9 Apr 1994 03:40:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA13383; Sat, 9 Apr 1994 03:39:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA13363; Sat, 9 Apr 1994 03:34:09 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24187; Sat, 9 Apr 1994 01:46:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11994; Fri, 8 Apr 94 11:46:09 -0400 Date: Fri, 8 Apr 94 11:46:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404081546.AA11994@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: strange flow ID bug..... Cc: jnc@ginger.lcs.mit.edu pondering on how use of the flow ID really works ... I found an interesting error condition ... perhaps in any protocol that uses a VCI+fullAddressing approach ... a flow is setup, and packets are being routed according to the flow ID (possibly combined with other info, such as source address) ... a failure occurs so that a router can no longer forward according to the flow ... the router falls back on best-effort forwarding, using the full address information ... resulting in a loop. The problem with any routing architecture which allows the choice of the next hop to be made in a fashion which is relatively uncoordinated with other entities making that decision is that it can result in routing loops. (That's the single biggest reason why Nimrod uses source-routing type techniques; all the fancy policy-routing capabilities that gives you is really a secondary reason at this point. Actually, "unitary" is a better word than "source", because it's not classic source routing, but the decisions about the path are made only in a few, fixed, places. Flows in Nimrod are just an engineering efficiency thing; the basic model would work with source routed packets, but that's not practical.) The kind of problem you point out is *inevitable* in any system which is doing a mixture of "best effort", and "soft state" which has *any* influence on the choice of next hop. If one router along the way tosses its soft state without telling people (which is the definition of "soft state", right?), it can screw up the packet forwarding. Hop-by-hop routing simply cannot be made robust enough in a system which is trying to provide a more complex service model. That service model is inevitably going to want to effect the paths data takes, and the interaction with hop-by-hop routing gets way complicated. Robustness, power, flexibility, simplicity: they all point you toward source routing. Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 04:19:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29835; Sat, 9 Apr 1994 04:19:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA13458; Sat, 9 Apr 1994 04:17:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA13422; Sat, 9 Apr 1994 04:04:38 +1000 Received: from ibm.cl.msu.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29287; Sat, 9 Apr 1994 04:05:50 +1000 (from NELSON@msu.edu) Message-Id: <9404081805.29287@munnari.oz.au> Received: from MSU.BITNET by msu.edu (IBM VM SMTP V2R2) with BSMTP id 2108; Fri, 08 Apr 94 14:05:47 EDT Received: by MSU (Mailer R2.08 PTF008) id 1674; Fri, 08 Apr 94 14:05:47 EDT Date: Fri, 08 Apr 94 14:05 EDT To: big-internet@munnari.OZ.AU From: "Doug.Nelson" Subject: Re: Introducing proxy aggregations? In-Reply-To: The letter of Thu, 7 Apr 94 19:00:30 GMT Bill Simpson writes: > > From: yakov@watson.ibm.com > > On the one hand I've been hearing assertions that renumbering is almost > > "close to impossible". On the other hand, I know first hand of few > > places that did renumbering of few hundred machines, and it didn't > > consume an unsurmountable amount of efforts. > > > And I personally know one site that refused to renumber out of its part > of a class A to several class B's, simply because it was "close to > impossible". They have suffered inefficient routing, but obviously are > willing to live with it. CIDR may actually make things worse from the > routing perspective. I refer to net 35.8 (9, 10, 11, etc), allocated to > one of the largest universities in the world. Let me set the record straight. I'm from Michigan State University, the one that Bill refers to above, and made the recommendation not to renumber our hosts. We never concluded that it was "close to impossible" to renumber. What we concluded at the time was that renumbering several thousand systems (now close to 10,000) would consume a lot of effort that we would rather not expend if there was no compelling reason. Our opinion at the time was that there was no compelling reason, for performance or otherwise. We do not suffer from inefficient routing. At the worst, some of our traffic may go over an extra T1 hop, or take the "politically incorrect" path (we belong to two regional networks, and have T1 connectivity to NSFNet from both regionals). We also can lose external connectivity if our primary link goes down, because of the sharing of a class A network between us and the MichNet network, but the frequency of such outages is very low (less than that of a backhoe going through MCI's NSFNet circuits lately...). I also don't understand the comment about CIDR making things worse. It has forced router vendors to implement the variable subnetting that is needed to effectively utilize pieces of a class A network by multiple organizations. That will only help our particular situation. I expect to hold out from renumbering until IPng is deployed here. But I also expect that we will phase in IPng, and some sort of dynamic address assignment strategy, over a period of time. Renumbering addresses seems like a minor irritant compared with deploying all new Internet software. Doug Nelson nelson@msu.edu Network Manager Ph: (517) 353-2980 Computer Laboratory Michigan State University From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 04:38:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00675; Sat, 9 Apr 1994 04:38:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA13488; Sat, 9 Apr 1994 04:37:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA13463; Sat, 9 Apr 1994 04:18:13 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29845; Sat, 9 Apr 1994 04:19:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14110; Fri, 8 Apr 94 14:19:13 -0400 Date: Fri, 8 Apr 94 14:19:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404081819.AA14110@ginger.lcs.mit.edu> To: atkinson@itd.nrl.navy.mil Subject: Re: IPng & Provider-oriented addressing Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Moreover, NRL currently has several external network connections ... and it is operationally awkward to require each of our machines to have multiple addresses, one per provider. You've just put your finger on one of the most difficult problems of all. It's just darned hard to do anything about this in a destination-vector model without either i) multiple addresses, or ii) advertising that multiply connected entity at a fairly high level, which sort of defeats the concept of aggregation. The problem with ii) is that the scope over which that destination has to be visible to the routing as a separate entity (to make paths to it precomputable through a variety of providers) includes lots of places that are never going to want to talk to that destination; i.e. useless overhead. There are a number of suggestions as to how to deal with this (such as Dave Clark's "route suffix" concepts). My personal guess (the Nimrod WG hasn't looked at this problem yet in detail) is similar to Dave's, in that I think you need to get, along with the address of the destination, some info about what its connectivity is. All share the common characteristic that they try and delay the route computation so that only those sites which are trying to talk to the destination find out about its multiple connections. I liked the basic concept of geographic-based addressing, but the service providers didn't want to commit to cross-connecting their networks at multiple cities. Right. The current telephone system is not a good model, as you don't get to change RBOC's without changing your phone number; your incoming traffic is always sent through the RBOC. Geographic-based addressing isn't a free solution to this problem, either: there are ways to constrain the topology so that if you move from one provider to another within a local area of the topology, to which all the providers are attached, the move can be made "invisible" (the routing will still know about it, obviously) both outside and inside at the cost of a certain amount of overhead, approximately O(N) in the number of things which have moved from their original provider. Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 04:58:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01359; Sat, 9 Apr 1994 04:58:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA13531; Sat, 9 Apr 1994 04:57:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA13515; Sat, 9 Apr 1994 04:40:26 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25064; Sat, 9 Apr 1994 02:05:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12312; Fri, 8 Apr 94 12:05:34 -0400 Date: Fri, 8 Apr 94 12:05:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404081605.AA12312@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Costs, Performance and IPng Cc: jnc@ginger.lcs.mit.edu There are a number of cases ... where it is clear there may be multiple senders ... to one flow or set of related flows. There was a discussion about 6 months ago about how this probably implied that using the source address to define the flow ID wasn't necessarily a hot idea. You can still use a source EID as part of generating a globally unique flow-id, you just can't use the "source EID" field of the packet as part of the logical flow-id field. for multicast flows, one needs some distributed negotiation rules to ensure that flow ids don't collide on the mcast address (which is rather grim and difficult to get right in a low-cost way). If you're doing "tree per source", can't you just let the source pick the flow-id, using the rule above, whether the source has only one flow going to that multicast group, or many? If you've only got a single distribution tree (a la CBT or whatever), then can tree root pick the flow-id, and you get it when you rendezvous with the tree? What am I missing? Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 05:19:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02060; Sat, 9 Apr 1994 05:19:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA13566; Sat, 9 Apr 1994 05:17:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA13561; Sat, 9 Apr 1994 05:12:07 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28970; Sat, 9 Apr 1994 03:57:35 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15896 for big-Internet@munnari.oz.au; Fri, 8 Apr 94 13:56:57 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA15446; Fri, 8 Apr 1994 10:55:23 -0700 Message-Id: <199404081755.KAA15446@aland.bbn.com> To: atkinson@itd.nrl.navy.mil Cc: big-Internet@munnari.OZ.AU Subject: Re: IPng & Provider-oriented addressing In-Reply-To: Your message of Fri, 08 Apr 94 11:05:53 -0400. <9404081105.ZM2415@bodhi.itd.nrl.navy.mil> From: Craig Partridge Date: Fri, 08 Apr 94 10:55:21 -0700 Sender: craig@aland.bbn.com Hi folks: I've heard different analogies to defend or condemn provider based addressing. Here are a couple: * Moving office buildings for a better rent. One doesn't get to keep one's old street address (thus change must happen). True, but here in the US many companies actually rent post office Boxes (even if they give you street addresses, the zip code sends to a postal pickup), so moves sometimes don't change where the mail goes. * Phone numbers. A business often doesn't have to change phone numbers when one moves, unless it crosses key network topological boundaries. And there's now a move to give people permanent phone numbers that never change because people want them. Furthermore, changing long-lines or local providers does *not* change one's phone number. As these examples may suggest, my suspicion is any scheme that *forces* people to change is bad news. Schemes that make renumbering easy if desired are clearly also a win. Craig From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 05:20:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02083; Sat, 9 Apr 1994 05:20:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA13581; Sat, 9 Apr 1994 05:19:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA13547; Sat, 9 Apr 1994 05:01:29 +1000 Received: from chsun.eunet.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27550; Sat, 9 Apr 1994 03:17:40 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id TAA14123; Fri, 8 Apr 1994 19:20:54 +0200 Message-Id: <199404081720.TAA14123@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <12178-0@magnolia.eunet.ch>; Fri, 8 Apr 1994 19:19:18 +0200 Subject: Re: Costs, renumbering and IPng To: yakov@watson.ibm.com Date: Fri, 8 Apr 1994 19:19:10 +0200 (MET DST) Cc: poole@magnolia.eunet.ch, big-internet@munnari.OZ.AU, pld@math.luc.edu In-Reply-To: <199404081642.SAA09728@chsun.eunet.ch> from "yakov@watson.ibm.com" at Apr 8, 94 12:38:56 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1235 From: Simon Poole Sender: poole@magnolia.eunet.ch > Ref: Your note of Fri, 8 Apr 1994 17:57:22 +0200 (MET DST) .. > >The requirements then would be a large amount of provider independent > >address space for internal purposes and a small number of addresses for > >the external connectivity that could very well fit in to some provider > >based topology. > > Just like to mention that RFC1597 already specifies a block of > addresses for internal purposes. The block is reserved by the IANA. I have naturally read RFC1597 (we run the IP registry of last resort here in Switzerland and are confronted with these problems on a daily basis). And I disagree substantially with some of the points raised there. In particular it disregards that fact that companies merge, purchase other companies etc.. By suggesting specific reserved addresses, it will actually cause more conflicts and costs in these cases than if the parties concerned had chosen random addresses. Naturally it -is- convinient to have this specific reserved address space available and there are quite a few cases where this can be used. In any case I think this is a moot issue with respect to IPv4, I was really thinking in terms of IPng (where hopefully address space itsself will not be scarce). Simon From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 06:19:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04125; Sat, 9 Apr 1994 06:19:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA13655; Sat, 9 Apr 1994 06:17:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA13652; Sat, 9 Apr 1994 06:15:07 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02716; Sat, 9 Apr 1994 05:41:36 +1000 (from yakov@watson.ibm.com) Message-Id: <9404081941.2716@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5783; Fri, 08 Apr 94 15:41:25 EDT Date: Fri, 8 Apr 94 15:41:25 EDT To: craig@aland.bbn.com Cc: big-Internet@munnari.OZ.AU Subject: IPng & Provider-oriented addressing Ref: Your note of Fri, 08 Apr 94 10:55:21 -0700 Craig, >As these examples may suggest, my suspicion is any scheme that *forces* >people to change is bad news. I agree with this. However, we need to understand that people should be cognizant of *names* and not *addresses*. So *names* should not change. At the same time, people shouldn't be exposed to IP (or IPng) addresses, so changing IP (or IPng) addresses should be transparent to a human being. >Schemes that make renumbering easy if desired are clearly also a win. Yes, since it minimizes the amount of human intervention (makes address changes transparent), while enables scalable routing. Yakov. From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 06:39:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04815; Sat, 9 Apr 1994 06:39:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA13700; Sat, 9 Apr 1994 06:37:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA13663; Sat, 9 Apr 1994 06:18:24 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02409; Sat, 9 Apr 1994 05:33:13 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA24474; Fri, 8 Apr 94 12:34:47 -0700 Date: Fri, 8 Apr 94 12:34:47 -0700 From: Eric Fleischman Message-Id: <9404081934.AA24474@atc.boeing.com> To: ericf@atc.boeing.com, medin@nsipo.nasa.gov Subject: Re: Introducing proxy aggregations? Cc: big-internet@munnari.OZ.AU, ericf@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, poole@magnolia.eunet.ch Dear Milo, Your points about renumbering have some merit but do not reflect the hard reality that renumbering costs money. A request to renumber is a request to spend money: architect the new address structure, schedule when renumbering will take place, do the actual re-addressing, fix the inadvertant bugs resulting from renumbering due to human error, etc. We have found that large sites with large renumberings need unbelievable amount of attention and care (i.e., $$$$) to "get it right". And one must "get it right" because a mistake may translate into really big bucks solving the resulting problems. The bottom line is that if humans are involved then human error is possible. And humans do err. I realize that it is not possible to speak in other than simplistic terms in this discussion due to the sheer complexity of the issues. However, I believe that you are overly optimistic about current technologies such as DHCP serving as a sufficient "renumbering aide" to eliminate the expense of renumbering. (I speak as a site which has widely deployed DHCP.) Our present TCP/IP solutions today are inadequate (e.g., no autoregistration) with inadequate integration to eliminate the strong human part of the equation. Therefore, DHCP is a help but not itself a sufficient solution. However, even if we should arrive at adequate autoaddressing, autoconfiguration, and auto-everything the painful reality is that there are many reasons why such technologies can't be deployed/used in many environments. These are some of the reasons why "real users" will push-back at any "outside" request to renumber. I suspect that as we (as a community) continue to think about these issues we will find that any approach which presupposes the need to renumber is an approach which "lacks business sense" for the reasons explained in my previous message. Having said this I wish to hastily state that I am well aware of the fact that entities which exist to support the Internet or have unlimited (or at least "adequate") funds will not be swayed by anything which I have said on this matter. In such cases I guess we'll just have to recognize that alternative viewpoints exist. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 06:59:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05513; Sat, 9 Apr 1994 06:59:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA13743; Sat, 9 Apr 1994 06:57:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA13727; Sat, 9 Apr 1994 06:49:04 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01709; Sat, 9 Apr 1994 05:08:30 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Fri, 8 Apr 1994 15:08:22 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 8 Apr 1994 15:08:22 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA12656; Fri, 8 Apr 94 15:07:28 EDT Date: Fri, 8 Apr 94 15:07:28 EDT Message-Id: <9404081907.AA12656@mailserv-D.ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: IPng & Provider-oriented addressing From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU Content-Length: 2945 > Moreover, NRL currently has several external network connections ... > and it is operationally awkward to require each of our machines to have > multiple addresses, one per provider. > > You've just put your finger on one of the most difficult problems of all. > It's just darned hard to do anything about this in a destination-vector model > without either i) multiple addresses, or ii) advertising that multiply > connected entity at a fairly high level, which sort of defeats the concept of > aggregation. The problem with ii) is that the scope over which that > destination has to be visible to the routing as a separate entity (to make > paths to it precomputable through a variety of providers) includes lots of > places that are never going to want to talk to that destination; i.e. useless > overhead. Here's a random, pseudo-crazy idea. Why does a host need to know its full locator/address? Obviously, the sender needs, somehow, to get the packet 'addressed' to the destination; fairly obviously the DNS needs to know that host X is at locator Y, and very obviously, routing needs to know how to get to locator Y, but does a host that is at locator Y need to know that it is at locator Y? Packets that are misdelivered to a host could be filtered out based on the destination Endpoint ID. Things like TCP connections and FTP port commands could be based on Endpoint ID also. One question: If a host wants to send a packet, how does it know whether to send the packet to a router or directly to the destination host? That is, presumably the sender host has done a DNS lookup or the like on the destination and gets a locator for the destination. The sender does not know its own (i.e. the sender's) locator so the sender can't determine whether the sender and destination are on the same network or not. Well, I suppose that the sender could 1. Always send to a router and the router, knowing the topological information, could decide whether the packet is 'local' or not, forward the packet as needed, and if the sender and destination are on the same net, the router could also send a redirect to the sender. This, of course, means that you need a router on every network. Even networks that are off by themselves and not connected anyplace else. Ick. 2. We could do, in effect, Proxy Arp. The sender, when it starts sending to a new destination EID or locator would send an ARP which has both the Dest EID and Locator. If a host on the local network recognizes the request it responds. If a router on the local net recognizes the destination and would be the first hop router for a packet going to the destination locator, the router responds. So, if a host does not need to know its own locator, then there is no need to 'renumber' hosts if locators change. Problem solved? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 09:59:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11583; Sat, 9 Apr 1994 09:59:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA13928; Sat, 9 Apr 1994 09:57:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA13912; Sat, 9 Apr 1994 09:42:20 +1000 Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06651; Sat, 9 Apr 1994 07:29:51 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (8.6.8/1.5T) id OAA08772; Fri, 8 Apr 1994 14:28:54 -0700 Message-Id: <199404082128.OAA08772@cincsac.arc.nasa.gov> To: Eric Fleischman Cc: big-internet@munnari.OZ.AU, ericf@cincsac.arc.nasa.gov, jnc@ginger.lcs.mit.edu, poole@magnolia.eunet.ch Subject: Re: Introducing proxy aggregations? In-Reply-To: Your message of "Fri, 08 Apr 94 12:34:47 PDT." <9404081934.AA24474@atc.boeing.com> Date: Fri, 08 Apr 94 14:28:54 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Eric, I can certainly appreciate what you are saying. Several years ago, a big part of the Ames network split into a new class B net, and the rest changed subnet masks, so a lot of systems had to be renumbered. It was a pain, and someone who wasn't careful did something wrong and caused a broadcast storm... It was a mess. My message had 3 primary points: 1) Renumbering is not an all or nothing issue. We can renumber smaller sites which don't have gobs of hosts a lot more easily than larger sites. We shouldn't consider all customer networks equal in size and complexity. 2) The hardship in renumbering is primarily a problem with the hosts and their OS's. Things can be done to make this easier. DHCP or the DNS or ANY PROTOCOL by itself isn't going to solve the problem as long as vendors build things in place that have local dotted quad addresses stuck in files etc, and do stupid things that cause problems in transitions (like not understanding that you should never forward (or send back an ICMP message) when a packet is recieved by a MAC level multicast, not matter what the destination IP address is). We can do a lot to make OS's deal with renumbering better, and make it easier to change addresses as required. We ought to do this. 3) There isn't much that can be done about this. You attack problems of scale using hierarchy, and that means using some sort of prefixing, and that means have to renumber. You can also use indirection, so that IP "address" becomes more of a name than a routable entity, and that looks up something that's hierarchically allocated and changes when your provider changes. This would sort of make the IP address act more like a MAC address. I remember a few years ago listening to Zbigniev Brezinski (!) being interviewed on an ABC news program about the likely outcomes of the then current unrest in the USSR, and he responded with 3 possibilities: 1) The USSR falls apart, and the various states attempt to become independent, and the Russians respond using force and there is massive bloodshed. 2) The USSR falls apart, and the various states sucessfully become independent, and internal ethnic strife leads to internal civil wars resulting in massive bloodshed. 3) The USSR doesn't fall apart, the hardliners take over again, and ruthlessly purge all the reformers, resulting in massive bloodshed. The interviewer then commented by saying, that couldn't be right, since all the scenarios led to massive bloodshed. Brezinski responded by saying that was correct, no matter what happened, that would be massive bloodshed - sometimes there is no good answer. There will be pain. That is not the question. Renumbering will almost certainly be necessary, but we can soften it's impact. It's not just an issue of being able to build routers that support 50,000 nets (John Moy from Proteon believes a CNX 600 today can support that number of nets), but whether or not you can do it in a way that is managable, and a service provider can support it effectively. We begin to hit limits in the tools we use as well. Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 10:19:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12398; Sat, 9 Apr 1994 10:19:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA13960; Sat, 9 Apr 1994 10:17:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA13957; Sat, 9 Apr 1994 10:17:09 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10113; Sat, 9 Apr 1994 09:10:19 +1000 (from poole@magnolia.eunet.ch) Received: from chsun.eunet.ch by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00893 Sat, 9 Apr 1994 09:06:37 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (8.6.4/1.34) id BAA19452; Sat, 9 Apr 1994 01:07:18 +0200 Message-Id: <199404082307.BAA19452@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <13775-0@magnolia.eunet.ch>; Sat, 9 Apr 1994 01:05:50 +0200 Subject: Re: IPng & Provider-oriented addressing To: kasten@ftp.com Date: Sat, 9 Apr 1994 01:05:46 +0200 (MET DST) Cc: jnc@ginger.lcs.mit.edu, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU In-Reply-To: <9404081907.AA12656@mailserv-D.ftp.com> from "Frank Kastenholz" at Apr 8, 94 03:07:28 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1018 From: Simon Poole Sender: poole@magnolia.eunet.ch > > Why does a host need to know its full locator/address? Obviously, the > sender needs, somehow, to get the packet 'addressed' to the > destination; fairly obviously the DNS needs to know that host X is at > locator Y, and very obviously, routing needs to know how to get to > locator Y, but does a host that is at locator Y need to know that it > is at locator Y? > I've had something like this going araound in my head too. What seems to be a bit problematic is that the border router to your service provider will have to insert the correct prefix or whatever in to the IPng header. I've got no idea if this is desirable from a performance point of view, it would however seem to support a multiple provider scenario nicely. I do have a feeling the problems are in the details: DNS, ftp* and so on. Simon * why don't we deploying a modified ftp protocol that uses (DNS) names instead of addresses in the port command now? This would seem to be a good thing regardless of whatever turns up for IPng. From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 10:05:21 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11887; Sat, 9 Apr 1994 10:05:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01365 Sat, 9 Apr 1994 09:41:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA13885; Sat, 9 Apr 1994 09:37:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA13882; Sat, 9 Apr 1994 09:34:07 +1000 Received: from midas.london.micrognosis.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06653; Sat, 9 Apr 1994 07:30:00 +1000 (from nreadwin@london.micrognosis.com) Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA14754; Fri, 8 Apr 94 22:28:31 BST Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma014751; Fri Apr 8 22:28:21 1994 Received: from moria by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA11663; Fri, 8 Apr 94 22:28:19 BST From: nreadwin@london.micrognosis.com (Neil Readwin) Received: by moria (4.1//ident-1.0) id AA22031; Fri, 8 Apr 94 22:28:18 BST Message-Id: <9404082128.AA22031@moria> Subject: Re: IPng & Provider-oriented addressing To: craig@aland.bbn.com (Craig Partridge) Date: Fri, 8 Apr 1994 22:28:18 +0100 (BST) Cc: big-Internet@munnari.OZ.AU In-Reply-To: <199404081755.KAA15446@aland.bbn.com> from "Craig Partridge" at Apr 8, 94 10:55:21 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 893 Craig, > I've heard different analogies to defend or condemn provider based > addressing. Here are a couple: > > * Moving office buildings [...] > > * Phone numbers. [...] I don't think either analogy is very close since in both cases the hard part is making sure that everyone who knew your old address/number finds out about your new address/number. With IP the DNS would take care of that. If we (Micrognosis in London) had to renumber our network the hardest part would be updating each machine to have its new address. That's like saying the hardest part of moving offices is making sure all your employees know they are meant to arrive at a different location on Monday morning. Last time we moved offices that was not a major problem. Neil. -- nreadwin@london.micrognosis.com Phone: +1 718 273 8234 Anything is a cause for sorrow that my mind or body has made From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 13:42:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25058; Fri, 8 Apr 1994 13:42:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA11680; Fri, 8 Apr 1994 13:40:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA11651; Fri, 8 Apr 1994 13:25:29 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01063; Fri, 8 Apr 1994 02:23:09 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA15701; Thu, 7 Apr 94 09:24:42 -0700 Date: Thu, 7 Apr 94 09:24:42 -0700 From: Eric Fleischman Message-Id: <9404071624.AA15701@atc.boeing.com> To: jnc@ginger.lcs.mit.edu, poole@magnolia.eunet.ch Subject: Re: Introducing proxy aggregations? Cc: big-internet@munnari.OZ.AU I take my hat off to Simon Poole who said (among other wise words): > Wrong: it's not that people wont renumber; they wont switch in the first > place. My personal belief is that should a company be given a choice in Internet exchange carriers and should that company decide to switch carriers it is unreasonable to imagine that that company would be willing to readdress as part of the bargain. Similarly, the "new carrier" is not likely to insist that the company re-address because such insistence will probably convince the company that the new carrier isn't so great after all and so that they will take their business elsewhere -- to a carrier who is more "reasonable". For this reason, I have always thought that "provider based addressing" is unrealistic and A Bad Thing. To me, it is merely another instance that significant percentages of the IETF do not understand even elementary market realities. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 15:09:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17515; Sat, 9 Apr 1994 12:39:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA14094; Sat, 9 Apr 1994 12:37:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA14091; Sat, 9 Apr 1994 12:25:26 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16050; Sat, 9 Apr 1994 12:00:55 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-27.dialip.mich.net (pm002-27.dialip.mich.net [35.1.48.108]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA16533 for ; Fri, 8 Apr 1994 22:00:48 -0400 Date: Sat, 9 Apr 94 01:40:20 GMT From: "William Allen Simpson" Message-Id: <2164.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: heirarchical addressing > From: Tony Li > SIPP will adapt automatically to any heirarchical topology. > > How does that differ from dynamically performing provider-based addressing? > Who says it is provider-based? Geographically-based addresses are far more efficient and predictable, especially in the face of concurrent use of more than one provider. I thought that we beat this to death a year or so ago on this list. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 15:14:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18626; Sat, 9 Apr 1994 13:19:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA14150; Sat, 9 Apr 1994 13:17:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA14135; Sat, 9 Apr 1994 13:08:13 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16048; Sat, 9 Apr 1994 12:00:52 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-27.dialip.mich.net (pm002-27.dialip.mich.net [35.1.48.108]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA16530 for ; Fri, 8 Apr 1994 22:00:46 -0400 Date: Sat, 9 Apr 94 01:32:32 GMT From: "William Allen Simpson" Message-Id: <2163.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: renumbering > From: Tony Li > In article <2147.bill.simpson@um.cc.umich.edu> you write: > And I personally know one site that refused to renumber out of its part > of a class A to several class B's, simply because it was "close to > impossible". They have suffered inefficient routing, but obviously are > willing to live with it. CIDR may actually make things worse from the > routing perspective. I refer to net 35.8 (9, 10, 11, etc), allocated to > one of the largest universities in the world. > > Please defend or explain this statement. No throwing loaded bombshells > over the wall without rationalization. > Which part needs defense? I personally know .... I refer to net 35.8 .... If you just need more details, try Dave Katz, who worked at both 35.8 and 35.1, and now is at Cisco. The problems were elucidated in a later message from a sister university of about the same size. The conclusion is that auto-renumbering without user intervention is crucial, and any IPng candidate that doesn't have a mechanism can be immediately rejected. > SIPP adapts by having a continuous advertisement of its routing > prefixes. This means that hosts can change dynamically, without > asking DHCP (or any central server), and without user intervention. > > Is this true of any other IPng? > > Yes. > Please defend or explain this statement. No throwing loaded bombshells over the wall without rationalization. (As in, where is the internet-draft?) Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 18:21:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28111; Sat, 9 Apr 1994 18:04:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14677; Sat, 9 Apr 1994 18:02:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA14672; Sat, 9 Apr 1994 17:59:57 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27984; Sat, 9 Apr 1994 18:00:11 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU Subject: Administrivia From: Big-Internet-Request@munnari.OZ.AU Reply-To: Big-Internet-Request@munnari.OZ.AU Date: Sat, 09 Apr 1994 18:00:14 +1000 Message-Id: <12333.765878414@munnari.OZ.AU> Sender: kre@munnari.OZ.AU Hi, First apologies for the few messages that looped in the recent past, I believe the errant news gateway has now been "fixed" and this problem has been cured for now. I have had the list turned off for the past several hours, so those of you who sent messages to the list, but haven't seen them appear should see them come through soon as the list is back on again now. Second, I believe I have now made all the list changes that have been requested in the past few weeks - apologies for some lengthy delays in there, just a short absense can cause absurd amounts of mail to build up and want to be processed, especially when that absense coincides with (is caused by) an IETF meeting, which generates lots of subscription requests, and also with a large burst of Big-Internet traffic, which generates both large numbers of unsubscribe requests, and even larger numbers of bounce messages. If you asked to be deleted before the weekend, and you receive this message, please accept my apologies, and send your request again. If you asked for an address change, and this is still being sent to your old address, please do the same. If you asked to be added, and aren't seeing this, then I'm not sure what to do! Finally, for general reference, and with apologies to those who have just joined, here is the (current) B-I standard welcome message, which contains the B-I rules of operation, etc. If you're reading this message via a news system, or administer such a system, please take particular note of the final paragraph. kre Welcome to the Big-Internet list. This list is intended to discuss issues related to the growth of the Internet, including particularly the problems with IP addressing and routing that this growth entails. Messages for the list (which is a simple reflector, not moderated or edited) should be sent to Big-Internet@munnari.OZ.AU Requests to be added to, or deleted from, the list, and other administrivia, should be sent to (and ONLY to) Big-Internet-Request@munnari.OZ.AU Please be patient, this list is operated by a human, who occasionally sleeps, attends conferences, and does other stuff like that. Requests can take a while to be acted upon sometimes (a while may be more than a week). All requests are acknowledged when processed, if you don't receive an ack after a reasonable delay, feel free to resend your request. Please save this message, messages sent to the list with content like "How do I get off this list" or "Unsubscribe me" are not welcome. Further, if you send something like that, and you catch me in a bad mood, you may end up with twice as many copies of every message as you were getting before... If you look closely, you may see the address owner-Big-Internet@munnari.OZ.AU in various places. That address is useful only for mailers to send bounce messages at. There is no guarantee that messages sent to that address will end up anywhere but a black hole. Archives of previous discussions on the list (which everyone is encouraged to survey, before contribution) can be found on munnari.OZ.AU [128.250.1.21] in the directory big-internet/list-archive Archives of traffic from previous months will be found in files named YYYY-MM-Mon (as in 1991-07-Jul), traffic from the current month will be located in the file "current". This list was created in July 1991. Months are defined to begin at 00:00 on the first of each month, local time, Melbourne, Australia. Missing archive files indicate months in which there was no traffic. Some older archives are compressed. Reading the archives, or at least some of them, is highly recommended. Other files, contributed documents, etc, may be found in the big-internet directory, or sub-directories of it, as notified from time to time. Files to be placed in that directory may be packaged in some convenient form and mailed to Big-Internet-Request@munnari.OZ.AU or may be dropped, by anonymous FTP, in the "tmp" directory on munnari.OZ.AU, along with a short message to the above address so I know to move them to the appropriate place. Please note - this list can be VERY busy at times, while being dormant at others, if you can't handle large volumes of (usually) fairly technical e-mail, you may not want to remain on here. Some sites choose to relay Big-Internet into a local usenet style newsgroup for ease of reading by many local recipients. That's fine. However it is an absolute rule of Big-Internet that NO news system ever take news "postings" and send them to the Big-Internet list. If you are reading this message via a news system, please note that the only way to send messages to the list is via mail, sending news "followups" will see your message only relayed to a very small subset of all normal recipients. NB: making a news system treat B-I as a "moderated" group, so postings are all automatically mailed is NOT a suitable way of implementing this policy, news postings must not ever be sent to the list, any way at all. Robert Elz kre@munnari.oz.au From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 18:34:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29324; Sat, 9 Apr 1994 18:34:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14752; Sat, 9 Apr 1994 18:33:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14715; Sat, 9 Apr 1994 18:11:02 +1000 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19869; Sat, 9 Apr 1994 13:54:01 +1000 (from Robert_Ullmann.LOTUS@CRD.lotus.com) Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA03430; Fri, 8 Apr 94 23:55:47 EDT Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA03762; Fri, 8 Apr 94 23:59:51 EDT Date: Fri, 8 Apr 94 23:59:51 EDT Message-Id: <9404090359.AA03762@Mail.Lotus.com> Received: by DniMail (v1.0); Fri Apr 8 23:59:48 1994 EDT To: UNIXML::"Big-Internet@munnari.OZ.AU"@lotus.com Subject: Re: IPng & Provider-oriented addressing It isn't a question of changing providers, it is a question of using multiple providers simultaneously. Even a small site (like me at home) already has 2 or 3 providers of network services; large multinationals typically have hundreds of providers. From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 18:37:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29356; Sat, 9 Apr 1994 18:37:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14767; Sat, 9 Apr 1994 18:35:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14712; Sat, 9 Apr 1994 18:10:46 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22539; Sat, 9 Apr 1994 15:16:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19726; Sat, 9 Apr 94 01:16:28 -0400 Date: Sat, 9 Apr 94 01:16:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404090516.AA19726@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: IPng & Provider-oriented addressing Cc: jnc@ginger.lcs.mit.edu But using the EID for the transport connection may not be enough, unless the EID is Worldnet globally unique. That's the theory, that they are globally unique. I am assuming locators will not duplicate themselves in the Worldnet? Yes, since otherwise the routing, given such a duplicated locator, wouldn't know which one to send packets to. Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 18:39:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29475; Sat, 9 Apr 1994 18:39:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14782; Sat, 9 Apr 1994 18:37:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14724; Sat, 9 Apr 1994 18:11:44 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20398; Sat, 9 Apr 1994 14:14:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19369; Sat, 9 Apr 94 00:14:04 -0400 Date: Sat, 9 Apr 94 00:14:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404090414.AA19369@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Cc: jnc@ginger.lcs.mit.edu I thought that we beat this to death a year or so ago on this list. So did I, actually. I thought that the fact that the overhead cost in the routing inside the geographical region is something worse than O(N) (where N is the number of things which have moved from their original provider) made it perfectly obvious to everyone that geographical addressing was not a panacea. (For those who didn't follow this, consider company C which moves from provider P to provider Q inside geographical area A. That company's address can now no longer be tracked as a part of P's address by the rest of the routers in area A. They now have to track it as a separate destination within A, one which probably cannot be aggregated in any way inside A. Since all routing schemes I know of have overhead worse than O(X), where X is the number of discrete destinations being tracked, the routing overhead inside A of things which have moved from their original provider will be worse than O(N). This assumes, of course, that you do manage to constrain the topology so that all the providers are interconnected appropriately; if not, the overhead spreads over an even *larger* area.) If 100K people and businesses have changed their provider inside a city (not an unreasonable number over a period of years), and kept the same "address" as the *only* label by which the routing tracks them, the routing just can't hack that. Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 19:10:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00560; Sat, 9 Apr 1994 19:10:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA14920; Sat, 9 Apr 1994 19:09:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14733; Sat, 9 Apr 1994 18:12:18 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20676; Sat, 9 Apr 1994 14:21:25 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA05019; Fri, 8 Apr 94 21:19:53 -0700 Received: by xirtlu.zk3.dec.com; id AA10099; Sat, 9 Apr 1994 00:19:52 -0400 Message-Id: <9404090419.AA10099@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU Subject: Re: IPng & Provider-oriented addressing In-Reply-To: Your message of "Fri, 08 Apr 94 15:07:28 EDT." <9404081907.AA12656@mailserv-D.ftp.com> Date: Sat, 09 Apr 94 00:19:46 -0400 X-Mts: smtp Good idea/point Frank. >Here's a random, pseudo-crazy idea. I think its a great idear and indirectly one John Curran and I hit on in a private conversation per tcp connection blocks a while ago, trying to solve a different problem than renumbering. )--> NIMROD makes it more clear to me now and Franks mail. >Why does a host need to know its full locator/address? Obviously, the >sender needs, somehow, to get the packet 'addressed' to the >destination; fairly obviously the DNS needs to know that host X is at >locator Y, and very obviously, routing needs to know how to get to >locator Y, but does a host that is at locator Y need to know that it >is at locator Y? I think so. Because it can use the locator to determine its subnet direct host to host modes. It could also be useful during transition to IPng. But the locator is only an object to the host in these special cases? Not all hosts would need the special case. So make it a transient object. >Packets that are misdelivered to a host could be filtered out based >on the destination Endpoint ID. Things like TCP connections and FTP >port commands could be based on Endpoint ID also. See below but the connections will need the locators too when outside of the aggregate address space for that subnet or AS. But this will still work. >One question: If a host wants to send a packet, how does it know whether >to send the packet to a router or directly to the destination host? >That is, presumably the sender host has done a DNS lookup or the like >on the destination and gets a locator for the destination. The sender >does not know its own (i.e. the sender's) locator so the sender can't >determine whether the sender and destination are on the same network >or not. Well, I suppose that the sender could Literal addresses entered present a minor annoyance. But using the EID for the transport connection may not be enough, unless the EID is Worldnet globally unique. The locator would make unfortuneate serendepity of similar EIDs again unique. This is needed for the transport connection blocks. I am assuming locators will not duplicate themselves in the Worldnet? >1. Always send to a router and the router, knowing the topological > information, could decide whether the packet is 'local' or not, > forward the packet as needed, and if the sender and destination > are on the same net, the router could also send a redirect to the > sender. This, of course, means that you need a router on every > network. Even networks that are off by themselves and not > connected anyplace else. Ick. Ick here too. >2. We could do, in effect, Proxy Arp. The sender, when it starts > sending to a new destination EID or locator would send an ARP > which has both the Dest EID and Locator. If a host on the local > network recognizes the request it responds. If a router on the > local net recognizes the destination and would be the first hop > router for a packet going to the destination locator, the router > responds. Or use a new IPng ICMP ES-IS discovery message? >So, if a host does not need to know its own locator, then there is no >need to 'renumber' hosts if locators change. Problem solved? Even if the host does know its locator for the purposes I feel exceptions may exist. The locator should be treated as an object in the host to AND, OR, XOR, et al. to get the mask for its locator to do the compare in the situations I propose above. But if the object changes who cares the host won't. Unless you have cache based on the locator and that would just get flushed when a new locator shows up as a new object on the host. Still Franks idea solves the problem in my mind too? Whats missing? /jim From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 21:20:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29554; Sat, 9 Apr 1994 18:41:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14797; Sat, 9 Apr 1994 18:39:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14706; Sat, 9 Apr 1994 18:10:20 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23637; Sat, 9 Apr 1994 15:49:39 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 8 Apr 1994 22:49:34 -0700 Date: Fri, 8 Apr 1994 22:49:34 -0700 Message-Id: <199404090549.AA13900@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: big-internet@munnari.OZ.AU Subject: unified Reply-To: estrin@usc.edu Earlier in the week there was discussion of Unified (IDRP+SDRP) and Nimrod that seemed to imply that Unified was compromise technology based on current artifact, whereas Nimrod design was attempting to do it "the right way". I guess I think of Nimrod as more of a "process" than an artifact or set of mechanisms. In this sense it has contributed alot to the IPng debate for example wrt EID/address/locator distinctions and discussions. Similarly, I expect to be able to use some of the to be developed Nimrod concepts as part of future SDRP route construction. (I am tempted to draw an analogy here to the role that AI plays wrt computer science, but that is pushing it...:}) Unified is an architecture with a current instantiation (IDRP+SDRP). We have argued (in writing...and in IETFpresentations) in a rather detailed manner why the system is designed as it is. We have demonsrated how the goals of scalability and heterogeneity can be realized with: a) a path vector hop by hop scheme that computes generic (widely used) routes and has excellent scaling properties based on its ability to employ FLEXIBLE aggregation. and b) a link state source routing scheme that acquires routing information (or route fragments) on demand from IDRP RIBs, constructs routes, and achieves on-demand routing along special-purpose routes . (optioinally using a lite-weight setup mechanism) So, with that summary (which Yakov and Tony Li et. al. will undoubtedly criticize...oops I mean refine...) My question is, what is it that causes people to think that in Unified we are designing a compromising architecture. I am eager to hear construcitve criticsms from whatever your perspective. THanks, D. From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 21:20:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29635; Sat, 9 Apr 1994 18:43:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14823; Sat, 9 Apr 1994 18:42:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14749; Sat, 9 Apr 1994 18:29:24 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29287; Sat, 9 Apr 1994 18:30:35 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA27657; Sat, 9 Apr 1994 01:30:02 -0700 Date: Sat, 9 Apr 1994 01:30:02 -0700 From: Tony Li Message-Id: <199404090830.BAA27657@lager.cisco.com> To: bill.simpson@um.cc.umich.edu ("William Allen Simpson") Cc: big-internet@munnari.OZ.AU Subject: renumbering > How does that differ from dynamically performing provider-based addressing? Who says it is provider-based? Geographically-based addresses are far more efficient and predictable, especially in the face of concurrent use of more than one provider. Excuse me, but why do you need geographically based addressing when you have automagic renumbering? You clearly need hierarchical addressing. If that doesn't result in provider-based addressing, then we're only disagreeing about the role that providers play in this world, and that's not even worthy of these bytes. I thought that we beat this to death a year or so ago on this list. No, that was YOU that we beat to death. ;-) Which part needs defense? > CIDR may actually make things worse from the routing perspective. That does. The problems were elucidated in a later message from a sister university of about the same size. I saw NOTHING that suggested that CIDR made things worse. I have seen one from Doug Nelson: "I also don't understand the comment about CIDR making things worse." > SIPP adapts by having a continuous advertisement of its routing > prefixes. This means that hosts can change dynamically, without > asking DHCP (or any central server), and without user intervention. > > Is this true of any other IPng? > > Yes. Please defend or explain this statement. No throwing loaded bombshells over the wall without rationalization. (As in, where is the internet-draft?) I believe that ES-IS already does this. Sorry, my copy of the spec isn't handy right now. And I refuse to use my PostScript previewer across my modem line. ;-( [Side note: we seem to have IS-IS as an RFC, but NOT ES-IS. ;-(] Tony From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 21:20:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29676; Sat, 9 Apr 1994 18:45:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14838; Sat, 9 Apr 1994 18:44:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14730; Sat, 9 Apr 1994 18:12:09 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21359; Sat, 9 Apr 1994 14:41:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19541; Sat, 9 Apr 94 00:41:29 -0400 Date: Sat, 9 Apr 94 00:41:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404090441.AA19541@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: IPng & Provider-oriented addressing Cc: jnc@ginger.lcs.mit.edu here in the US many companies actually rent post office Boxes (even if they give you street addresses, the zip code sends to a postal pickup), so moves sometimes don't change where the mail goes. This analogy is being pushed a bit too far, I think. First, my example was in terms of street addresses and cargo deliveries (i.e. semi-trailers). Second, you still have to schlep down and pick up the mail; it's thus more like a "base station" where you have to somehow go pick up the packets. A business often doesn't have to change phone numbers when one moves, unless it crosses key network topological boundaries. Similar problems. First, you're still connected to the same RBOC, so you actually haven't switched providers. Second, there is a mapping somewhere, be it the wiring in an old exchange, a number->port table on an ESS, or one of the more exotic features which allow you to keep the same number on a different exchange (a mapping which costs money to keep the table entry up). The only similar place in internetworking to do such a mapping in systems without an explicit EID/locator split is in (argh) ARP. And there's now a move to give people permanent phone numbers that never change because people want them. Yah, and if you look inside them, these systems all map your "permanent" number into something that does change as your location in the phone net changes... Furthermore, changing long-lines or local providers does *not* change one's phone number. Changing long-line providers only works for outgoing traffic, not incoming. How can you change local providers when the RBOC's have monopolies on intra- LATA traffic? As these examples may suggest, my suspicion is any scheme that *forces* people to change is bad news. I think it's great if people have a permanent ID of some sort. I also think the routing should deal in more ephemeral labels that are more related to the real topology. Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 21:21:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29755; Sat, 9 Apr 1994 18:48:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14853; Sat, 9 Apr 1994 18:46:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14727; Sat, 9 Apr 1994 18:11:57 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20083; Sat, 9 Apr 1994 14:03:03 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm012-21.dialip.mich.net (pm012-21.dialip.mich.net [35.1.48.222]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id AAA22770; Sat, 9 Apr 1994 00:02:55 -0400 Date: Sat, 9 Apr 94 03:38:39 GMT From: "William Allen Simpson" Message-Id: <2167.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Cc: "Doug.Nelson" , Eric Fleischman Reply-To: bsimpson@morningstar.com Subject: cost of renumbering > From: "Doug.Nelson" > We never concluded that it was "close to impossible" to renumber. What > we concluded at the time was that renumbering several thousand systems > (now close to 10,000) would consume a lot of effort that we would rather > not expend if there was no compelling reason. Our opinion at the time > was that there was no compelling reason, for performance or otherwise. > I think that's what is meant by "close to impossible". After all, it is usually _possible_ in some way to renumber, even if that means editting binaries in place. But it's the cost of doing it all within some reasonable time frame without loss of service that makes it impossible. (As an aside, you mean it _was_ possible? That's not what you told the user sub-committee -- "insufficient resources", "too few staff", as I recall.) > From: Eric Fleischman > Your points about renumbering have some merit but do not reflect the hard > reality that renumbering costs money. A request to renumber is a request > to spend money: architect the new address structure, schedule when > renumbering will take place, do the actual re-addressing, fix the > inadvertant bugs resulting from renumbering due to human error, etc. > We have found that large sites with large renumberings need unbelievable > amount of attention and care (i.e., $$$$) to "get it right". And one > must "get it right" because a mistake may translate into really big bucks > solving the resulting problems. The bottom line is that if humans are > involved then human error is possible. And humans do err. > ... > Having said this I wish to hastily state that I am well aware of the > fact that entities which exist to support the Internet or have unlimited > (or at least "adequate") funds will not be swayed by anything which I have > said on this matter. In such cases I guess we'll just have to recognize > that alternative viewpoints exist. > So, is it agreed that the cost to renumber hosts (nothing said about routers here), with as little human intervention as possible, is a primary IPng consideration? Is it so primary we are ready to make an IPng decision? How do we weight this criterion? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 21:22:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29943; Sat, 9 Apr 1994 18:52:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14872; Sat, 9 Apr 1994 18:50:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14718; Sat, 9 Apr 1994 18:11:15 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18946; Sat, 9 Apr 1994 13:27:33 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-24.dialip.mich.net (pm002-24.dialip.mich.net [35.1.48.105]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id XAA20467; Fri, 8 Apr 1994 23:27:28 -0400 Date: Sat, 9 Apr 94 02:59:59 GMT From: "William Allen Simpson" Message-Id: <2166.bill.simpson@um.cc.umich.edu> To: "Doug.Nelson" Cc: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: renumbering > From: "Doug.Nelson" > Let me set the record straight. I'm from Michigan State University, the > one that Bill refers to above, and made the recommendation not to renumber > our hosts. > Thanks, Doug. > We do not suffer from inefficient routing. At the worst, some of our > traffic may go over an extra T1 hop, or take the "politically incorrect" > path (we belong to two regional networks, and have T1 connectivity to > NSFNet from both regionals). Yes, that's what I meant. Although at the Columbus IETF, it was 6 extra T3 and T1 hops, as in one direction the traffic went via Cleveland or some such, but the other came straight up CICnet. Also, traffic from other universities in Michigan goes to you via Ann Arbor, rather than directly. That's usually more than 1 hop, too. > We also can lose external connectivity if > our primary link goes down, because of the sharing of a class A network > between us and the MichNet network, but the frequency of such outages is > very low (less than that of a backhoe going through MCI's NSFNet circuits > lately...). > But, if you had a separate number space, you wouldn't have lost connectivity. That may or may nor be a big win, but it certainly was a massive failure in the past few months. > I also don't understand the comment about CIDR making things worse. > It has forced router vendors to implement the variable subnetting that > is needed to effectively utilize pieces of a class A network by multiple > organizations. That will only help our particular situation. > It could help for _internal_ routing, as it will allow classless routing between universities within Michigan, solving one of the problems listed above. But, it MAY be a loss for _external_ routing, since you will either have to accept all of Ann Arbor's traffic, or route everything through Ann Arbor, due to aggregation. Or have special routes in the tables. Maybe you already do that, and it's not any worse than already occurs. > I expect to hold out from renumbering until IPng is deployed here. But > I also expect that we will phase in IPng, and some sort of dynamic address > assignment strategy, over a period of time. Renumbering addresses seems > like a minor irritant compared with deploying all new Internet software. > Too true. That's why we need a clear migration plan. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 21:22:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00164; Sat, 9 Apr 1994 18:56:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14887; Sat, 9 Apr 1994 18:54:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14709; Sat, 9 Apr 1994 18:10:31 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22664; Sat, 9 Apr 1994 15:20:56 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA08590; Fri, 8 Apr 94 22:18:59 -0700 Received: by xirtlu.zk3.dec.com; id AA10522; Sat, 9 Apr 1994 01:18:58 -0400 Message-Id: <9404090518.AA10522@xirtlu.zk3.dec.com> To: big-internet@munnari.OZ.AU Subject: IPng should support binary IPv4 mode API out-of-the-box Date: Sat, 09 Apr 94 01:18:52 -0400 X-Mts: smtp Hang with me OK (I had a dream): 1. IPng is selected and the thrill is gone now its time to do. 2. Host vendors incorporate IPng into their network OS subsystems and an API is provided to access IPng. Mean while (I was there thinking) Mr. customer has these real critical ISV applications that run over IPv4. In fact Mr. Customer and the many applications are very numerous. Mr. customer's ISV has not ported their application to IPng and has not even thought about doing this yet (its early the IETF just told the world). Guess what (imagine the Rocky Horror picture show) a few months later Mr. Customer gets some new hosts from his favorite TCP/IP host vendor's A and B. Vendor A and B have put IPng on these hosts. Now. The big question Mr. Customer asks? Gee vendor A and B will my ISV application binary I have just run on your host now? My ISV has not ported the application to be IPng capable, and I don't really want to recompile either. The answer should be NO PROBLEM Mr. Customer our API alterations to support applications being IPng capable provide backwards compatibility for IPv4 binaries, as part of the IETF IPng transition plan. We realize and the IETF that applications will take time to port. Mr. Customer who will SPEND THE MOST MONEY ON FUTURE IPNG STUFF, smiles and writes host vendor A and B a check for their shiny new hosts supporting IPng. Even though Mr. Customer has not started using IPng, he can begin to think about it and talk to Mr. ISV (Mr. Customer now has the IPng carrot in his hand and waving )---> a side benefit to get IPng deployed). Each IPng proposal should take the time to write up or build an API ID that describes what their proposal will do in this situation. And I don't think the answer 'this is an implementation issue' is a valid answer or correct in my mind. How an IPng proposal will go about solving this problem will tell us a lot about that proposal and their transition strategy. It may even tell us something about their use of addresses on the host, I think it will. Part two is this. It will cost ISVs money to port to IPng. If that is real hard they will want to charge the customer which means IPng being deployed will slow down a bit. If its real easy ISVs will port quicker if there is very little cost and again deployment will be quicker and the carrot is taken. So in addition how hard and what integration is involved in using IPng for the ISV or applications developer at the API. Part three is this. The ISV knows for awhile their server app can leverage IPng as competitive ploy, but the server still wants to accept IPv4 clients (another bite of the carrot is taken) as connections to the database or engineering CAD/CAM server. How hard will this be with each of the IPng proposals. Is there a performance hit more with one or the other? Will an IPng's transition strategy not permit this to happen? etc. etc. We need to undertand these issues and see them on paper. If not we could get messed up at the end of the day because no one wants to port their applications to IPng per the pain. This also can extend the transition period even to the point where we run out of IPv4 addresses in the worst case. What happens: we have failed and as Frank K. said we go get jobs as Cobol programmers, everyone will hate us (our companies, providers, and governments/industry who need the Internet to work with real applications besides FTP and TELNET). /jim From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 21:24:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00710; Sat, 9 Apr 1994 19:14:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA14948; Sat, 9 Apr 1994 19:12:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14721; Sat, 9 Apr 1994 18:11:28 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18570; Sat, 9 Apr 1994 13:16:33 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA00949; Fri, 8 Apr 94 20:10:51 -0700 Received: by xirtlu.zk3.dec.com; id AA09546; Fri, 8 Apr 1994 23:10:50 -0400 Message-Id: <9404090310.AA09546@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil Cc: big-Internet@munnari.OZ.AU Subject: Re: IPng APIs In-Reply-To: Your message of "Fri, 08 Apr 94 10:59:24 EDT." <9404081059.ZM2408@bodhi.itd.nrl.navy.mil> Date: Fri, 08 Apr 94 23:10:43 -0400 X-Mts: smtp I have actually worked on these at Digital and so has Keith Sklower from BSDi (and should chime in if he is on this list too). As you know the process walks through the specs and even checks for test assertions for the API. This gets really complex and a good thing to do. But such an effort in the IETF would require a complete working group. Now if we just state the changes needed to Sockets for the selected IPng then that could be used by implementors to get started and then passed on as Info RFC to POSIX and X/Open. I am willing to work with Bob Hinden from within Digital to move and track this in POSIX and X/Open per our Stds Technical Managers and participants. I think this will suffice and cover the ISV's (but see my next message for another issue on APIs per IPng I will bring up to this list), who I am most concerned about because if they don't port to IPng the private sector will not move to IPng as fast, and maybe even so slow IPng hits a big interrupt, and I am not sure where the IETF program status word will find IPng after this kind of interrupt. > I think that Eric's assertion that we should try to reach consensus >on Sockets and XTI/TLI extensions for IPng is not controversial. One >of the reasons that the Internet protocols have been successful is >application portability made possible by a standard and widespread API >for Sockets interfacing to TCP/UDP/IP. The SIPP WG has had an API >spec out as an I-D for a while now. I know that NRL has been paying >particular attention to that API specification in our SIPP for BSD >implementation. Agreed I am implementing it right now as I am able with all the IPng work and this mail too, as part of the prototype work. > I am peripherally involved (that is: not doing the work, but rather >actively watching it) in the POSIX work on Sockets and TLI/XTI >standardisation. That POSIX work is trying to just write down the >existing de facto standards without major change. They have added the use of 4.4 structure. It helps with the multiprotocol support. >I think that it >would be reasonable for interested folks to take a written IPng >Sockets or TLI/XTI extension (perhaps in the form of an Informational >RFC) to the POSIX folks once IPng is selected. I also think that the >POSIX folks would be agreeable to adding that in during their normal >review cycles. Tricky but possible. POSIX work is IEEE 1003.12. Usually when a POSIX standard gets ISO approval and the FIPs status in U.S. its 3 years before you can change the standard, unless you need to correct part of the spec based on an error as an exception. I think IPng would create a big enough exception. Same with X/Open only a different process via the XNET meetings. >At present, the protocol specific parts of the POSIX >spec are in separate sections of the document. Support for IPng would >mean adding some smallish new sections on "application of Sockets to >IPng" and should be straight forward. I ran the earlier SIP spec past >the POSIX folks a year ago (just as a test of how protocol independent >their main chapters were written, NOT to add support for SIP to POSIX >prematurely). The POSIX document appeared to be well structured for >use in a multi-protocol world. > The other IPng proposals might want to get a copy of the POSIX draft >or the BSD API specs and write up a short I-D on how they would extend >Sockets/TLI to support their IPng proposal. Certainly that would be >useful. The changes for SIPP to the API would be minimal so I think what your saying would work just fine for Sockets. XTI/TLI is another issue and best to let X/Open do that work based on the changes to sockets. There are subtle design differences between XTI/TLI as an interface and Sockets. For example Sockets supports a scatter/gather read and write and XTI does not but may in the future. Its better to let the X/Open folks take the sockets paradigm from IPng IETF ID or Info RFC and adapt to XTI. I think this would work better. But this is premature. But I agree with Eric in that there needs to be something stated in the requirements or somewhere that any IPng provide a technical API ID to become an info RFC into those standards bodies. They own APIs and Sockets too now is my reading of the situation, but as good standards folks we should give them what we have learned. /jim From owner-Big-Internet@munnari.OZ.AU Sat Apr 9 23:06:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04758; Sat, 9 Apr 1994 21:30:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA15071; Sat, 9 Apr 1994 21:29:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA15057; Sat, 9 Apr 1994 21:19:53 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01111; Sat, 9 Apr 1994 19:28:17 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA28514; Sat, 9 Apr 1994 02:27:56 -0700 Date: Sat, 9 Apr 1994 02:27:56 -0700 From: Tony Li Message-Id: <199404090927.CAA28514@lager.cisco.com> To: bill.simpson@um.cc.umich.edu ("William Allen Simpson") Cc: big-internet@munnari.OZ.AU Subject: renumbering Bill, > I also don't understand the comment about CIDR making things worse. But, it MAY be a loss for _external_ routing, since you will either have to accept all of Ann Arbor's traffic, or route everything through Ann Arbor, due to aggregation. Or have special routes in the tables. Maybe you already do that, and it's not any worse than already occurs. I don't know the physical topology, but I take it that you're pointing out that aggregation causes loss of information and that you'll get sub-optimal routing due to aggregation. Ok, this is Routing Theorem #3, no surprise. As you point out, you should get more specific routes in this case. In which case, things are no worse. So the point that I take away from this is that CIDR can be misapplied and that you have to be careful about aggregation if you're multihomed. This is not news. I consider this an adequate defense. ;-) Thank you. Tony From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 01:35:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11609; Sun, 10 Apr 1994 01:35:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA15293; Sun, 10 Apr 1994 01:34:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA15263; Sun, 10 Apr 1994 01:01:35 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08992; Sun, 10 Apr 1994 00:10:39 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA08947; Sat, 9 Apr 94 07:07:09 -0700 Received: by xirtlu.zk3.dec.com; id AA16582; Sat, 9 Apr 1994 10:07:08 -0400 Message-Id: <9404091407.AA16582@xirtlu.zk3.dec.com> To: big-internet@munnari.OZ.AU Cc: bound@zk3.dec.com Subject: IPng Merger Ideas that are Generated Date: Sat, 09 Apr 94 10:07:02 -0400 X-Mts: smtp After thinking about this and even playing with the headers of each proposal my self that there is a big differenece between suggesting an IPng merger header (for political or technical reasons) based on the present IPng proposals and writing, developing, and building a clear IPng technical proposal and all it parts. If a merger idea is suggested I think it would be good if it is extrapolated by the thinker as it would apply to any proposal on the table. This would help us keep momentum to deliver an IPng solution and basic time-to-market to build a product #101. In this case its not a product but a specification for the next generation IP for the world. I think if a merger idea does not afford integration with one of the proposals or integration with several proposal parts then its suspect in my mind. I will defer to the present Tech Criterion by Jon, Craig, and Frank as to what are the parts a proposal may have or may not have addressed at this point in time. We don't want to take one step forward and three steps backward we will melt down. /jim From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 03:52:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11792; Sun, 10 Apr 1994 01:42:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA15319; Sun, 10 Apr 1994 01:40:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA15279; Sun, 10 Apr 1994 01:24:25 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11202; Sun, 10 Apr 1994 01:25:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25238; Sat, 9 Apr 94 11:25:36 -0400 Date: Sat, 9 Apr 94 11:25:36 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404091525.AA25238@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, estrin@usc.edu Subject: Re: unified Cc: jnc@ginger.lcs.mit.edu I guess I think of Nimrod as more of a "process" than an artifact or set of mechanisms. I'm not quite qure what gave you this impression, but it's not correct. Both the WG charter (which was discussed at some length on the WG mailing list, which I believe you are on), and the contract for funding for the group at BBN, call for actual protocols to be developed, along with a viable plan for interoperable, incremental deployment in the Internet. I don't know of anyone associated with the Nimrod work, either in the WG or at BBN, who isn't operating toward these goals. Perhaps you are getting mislead by the fact that the Nimrod architecture makes so many of the algorithms which we usually associate with a routing architecture (e.g. route selection) local choices; i.e. you can deploy new ones incrementally without system-wide arrangements. These algorithms are thus not part of the spec; however, that's not a bug, that's a *major* feature. We intend to provide reasonably good "sample" algorithms for all of these, as an "appendix" to the spec, both as proof-of-concept, examples, and for initial use. One other thing which might have misled you is the heavy emphasis on trying to develop a deeper understanding of the underlying fundamentals of routing, from which to work. This may make it appear that the only thing which happens is abstract academic discussions, but it's simply a necesary precursor to doing something more lasting than any of the previous N routing protocols we've seen. No doubt you will recall that some thinking about the fundamentals of critical state, fatesharing, etc led to TCP, which has been wildly sucessful, without the constant necessity for "new, incrementally improved protocols" which has been constant feature of life on the Internet through GGP, Hello, RIP-1, EGP, OSPF, BGP-[2-4], etc, etc, etc. Anyway, any impression you have the Nimrod effort is not intended to produce a complete, working set of implemented, tested protocols which will be suitable for adoption by the Internet (which is obviously a decision that the IETF as a whole will have to make down the road, once they see the results) is not one shared by the people who are actually involved. We have argued ... in a rather detailed manner why the system is designed as it is. We have demonsrated how the goals of scalability and heterogeneity can be realized ... My question is, what is it that causes people to think that in Unified we are designing a compromising architecture. This is something of a guess on my part, people will have to speak for themselves, but perhaps the very nature of Unified, with the two separate mechanisms, lends itself, after a surface inspection, to this conclusion. I know you have technical arguments as to why this is the way to go, arguments which have some validity, and ones I've thought about a lot (and which have influenced the forwarding modes of Nimrod). However, I obviously have come up with slightly different answers, but the arcane technical details of why I'll leave, unless this mailing list wants to go into it. Noel From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 08:07:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23935; Sun, 10 Apr 1994 08:07:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA15669; Sun, 10 Apr 1994 08:06:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA15616; Sun, 10 Apr 1994 07:49:37 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23400; Sun, 10 Apr 1994 07:50:44 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-21.dialip.mich.net (pm002-21.dialip.mich.net [35.1.48.102]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA16114 for ; Sat, 9 Apr 1994 17:50:29 -0400 Date: Sat, 9 Apr 94 21:02:37 GMT From: "William Allen Simpson" Message-Id: <2175.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: heirarchical addressing > I thought that the fact that the overhead cost in the routing inside the > geographical region is something worse than O(N) (where N is the number of > things which have moved from their original provider) made it perfectly > obvious to everyone that geographical addressing was not a panacea. > But _outside_ the geographical region, the aggregation is better, assuming any interconnectivity at all in the geographic region. And, you (and many others) assume single provider. Provider aggregation doesn't work with multi-provider sites. I believe that this assumption is a severe fallacy even in the current Internet, let alone the future Internet. Many if not most of the university sites are multi-homed now. As a case in point, consider the local freenet, m-net.ann-arbor.mi.us. They have a small class C of three machines (I just donated one). They have over a 1000 weekly users -- and 2 provider connections. It would be terrible if their address was based on their first provider (Merit), because most of their traffic comes via their second provider (MSEN). Worse, my traffic there goes via Washington, DC, to go a 10 minute walk across town. This is insane! The right thing to do is have geographic assignment and widespread interconnection. If you try to force people to have one provider forever, you'll have a revolt on your hands. A geographic heirarchy makes much more sense, and is more understandable to the end users. And a geographic heirarchy penalizes the providers who refuse to interconnect, not the ones who do. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 08:13:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23739; Sun, 10 Apr 1994 08:01:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA15634; Sun, 10 Apr 1994 07:59:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA15615; Sun, 10 Apr 1994 07:49:37 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23408; Sun, 10 Apr 1994 07:50:49 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-21.dialip.mich.net (pm002-21.dialip.mich.net [35.1.48.102]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA16145 for ; Sat, 9 Apr 1994 17:50:32 -0400 Date: Sat, 9 Apr 94 21:33:39 GMT From: "William Allen Simpson" Message-Id: <2176.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: renumbering > From: Tony Li > > SIPP adapts by having a continuous advertisement of its routing > > prefixes. This means that hosts can change dynamically, without > > asking DHCP (or any central server), and without user intervention. > > > > Is this true of any other IPng? > > > > Yes. > > Please defend or explain this statement. No throwing loaded bombshells > over the wall without rationalization. > > (As in, where is the internet-draft?) > > I believe that ES-IS already does this. Sorry, my copy of the spec > isn't handy right now. And I refuse to use my PostScript previewer > across my modem line. ;-( [Side note: we seem to have IS-IS as an > RFC, but NOT ES-IS. ;-(] > ES-IS is RFC 995. IS-IS is RFC 1142. I can't see anything in ES-IS for dynamic self-configuration of routing prefixes, with automatic updating. Of course, reading ES-IS will make you go blind. And IS-IS is even worse. There's no question that OSPF is a better written protocol. If another IPng requires either ES-IS or IS-IS, I'd say that automatically disqualifies them. I want to know how RIP and OSPF work with any new IP. Where are the drafts? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 12:40:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02447; Sun, 10 Apr 1994 12:40:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA15919; Sun, 10 Apr 1994 12:39:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA15916; Sun, 10 Apr 1994 12:33:19 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00522; Sun, 10 Apr 1994 11:53:10 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA05581; Sat, 9 Apr 1994 18:53:02 -0700 Date: Sat, 9 Apr 1994 18:53:02 -0700 From: Tony Li Message-Id: <199404100153.SAA05581@lager.cisco.com> To: bill.simpson@um.cc.umich.edu ("William Allen Simpson") Cc: big-internet@munnari.OZ.AU Subject: Re: renumbering > > SIPP adapts by having a continuous advertisement of its routing > > prefixes. This means that hosts can change dynamically, without > > asking DHCP (or any central server), and without user intervention. > > Is this true of any other IPng? I can't see anything in ES-IS for dynamic self-configuration of routing prefixes, with automatic updating. Of course, reading ES-IS will make you go blind. And your palms will grow hair. ;-) ES-IS does advertise the NET of the IS in each ISH. See section 8.7.1. That's how the ES figures out its NSAP in the first place. And IS-IS is even worse. There's no question that OSPF is a better written protocol. Yes, the spec is easier to read. That doesn't make it better or worse technically. [And before you start, I _refuse_ to get into that argument.] That DOES make OSPF more accessible, which is a good thing. If another IPng requires either ES-IS or IS-IS, I'd say that automatically disqualifies them. Really? I think that just disqualified all of them. Well, that's another fine mess you've got us into now, Stanley. ;-) Tony From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 17:20:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12414; Sun, 10 Apr 1994 17:20:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA16158; Sun, 10 Apr 1994 17:19:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA16144; Sun, 10 Apr 1994 17:05:44 +1000 Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11863; Sun, 10 Apr 1994 17:06:57 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by large.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA23022; Sun, 10 Apr 1994 00:06:51 -0700 Date: Sun, 10 Apr 1994 00:06:51 -0700 From: Dave Katz Message-Id: <199404100706.AAA23022@large.cisco.com> To: bill.simpson@um.cc.umich.edu, big-internet@munnari.OZ.AU In-Reply-To: Tony Li's message of Sat, 9 Apr 1994 18:53:02 -0700 <199404100153.SAA05581@lager.cisco.com> Subject: renumbering As Tony points out, in ES-IS the IS does advertise its NET with ISHs, providing one method for hosts to do autoconfiguration. IS-IS also provides clean support for address renumbering by supporting multiple area addresses per area. This means that individual hosts can adopt new addresses over as long a period as the network administrator cares to tolerate. ES-IS also provides a query/response protocol for address assignment; this is an amendment to the base protocol which is now full standard; presumably Lyman will work his magic to get this out as an I-D forthwith. There are also two I-Ds out recently in this area; one extends the query/response model to allow the host to suggest a system ID, and the other specifies how hosts should implement autoconfiguration given all of the possibilities in a way that does not require the query/response model, but allows it if the administrator so desires (and I have customers that absolutely *do not* want machines on their net to be able to give themselves globally-visible network addresses without intervention). From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 19:06:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15903; Sun, 10 Apr 1994 19:06:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA16259; Sun, 10 Apr 1994 19:04:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA16256; Sun, 10 Apr 1994 19:01:08 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14815; Sun, 10 Apr 1994 18:36:19 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Sun, 10 Apr 1994 01:36:08 -0700 Date: Sun, 10 Apr 1994 01:36:08 -0700 Message-Id: <199404100836.AA26196@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Sat, 9 Apr 94 11:25:36 -0400 <9404091525.AA25238@ginger.lcs.mit.edu> Subject: unified Reply-To: estrin@usc.edu Apologies to Noel and other Nimrod folks re. my process comment. It was a sloppy comment. I did not mean to imply that Nimrod woudl never be artifact, just that to date it seems to have been more process...which is NOT BAD, you have been addressing important questions. But it is at a different stage. ANyway, again, I stand corrected in my remark. As to Unified being two pieces, well the two are really not that separate...SDRP is just an alternate mechanism for installing routes in the routing tables and it even will get its routes via IDRP and IDRP RIBs. From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 20:02:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16096; Sun, 10 Apr 1994 19:11:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA16274; Sun, 10 Apr 1994 19:09:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA16253; Sun, 10 Apr 1994 18:58:09 +1000 Received: from ceres.fokus.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13651; Sun, 10 Apr 1994 17:59:08 +1000 (from schulzrinne@fokus.gmd.de) Message-Id: <9404100759.13651@munnari.oz.au> Received: from fokus.gmd.de by ceres.fokus.gmd.de id <14740-0@ceres.fokus.gmd.de>; Sun, 10 Apr 1994 09:58:16 +0200 To: Big-Internet@munnari.OZ.AU Subject: Re: IPng & Provider-oriented addressing Date: Sun, 10 Apr 1994 09:58:16 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de Couple of more analogies for the pot: 1) Germany just went from four-digit to five-digit zip codes last year. (Had to do with growth-by-merger, if that's not obvious.) The new zip codes had only a tangential relationship with the old (first two digits in the West, usually none in the East.) That meant, every piece of company stationery, address label, etc. had to be changed, plus probably a host of software that assumed that zip codes would always be four digits long, not even mentioning all the company databases, from personnel to junk mail lists. Obviously, old zip-codes still worked, but with the ominous warning by the postal service of additional delays as penalty. Besides additional business for printing companies and overtime for programmers, Germany seems to have recovered. 2) Ethernet interfaces are changed routinely, without requiring that the replacement has the same IEEE identifier as the old. This indicates that given good software support (ARP), the task is manageable. (It's not quite the same, since Ethernet interfaces typically are changed one at a time rather than wholesale.) --- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin From owner-Big-Internet@munnari.OZ.AU Sun Apr 10 22:36:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21898; Sun, 10 Apr 1994 22:36:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA16466; Sun, 10 Apr 1994 22:34:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA16463; Sun, 10 Apr 1994 22:27:17 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21716; Sun, 10 Apr 1994 22:28:32 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23621; Sun, 10 Apr 1994 14:28:25 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20309; Sun, 10 Apr 1994 14:28:24 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404101228.AA20309@dxcoms.cern.ch> Subject: APIs in OSI transition To: ericf@atc.boeing.com (Eric Fleischman) Date: Sun, 10 Apr 1994 14:28:23 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404071543.AA11093@atc.boeing.com> from "Eric Fleischman" at Apr 7, 94 08:43:22 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 493 I would just like to point out that one of the most common explanations for the failure of OSI in the multi-vendor market is the lack of multi-vendor APIs. We would be very foolish to "release" IPng without the API issue being resolved. If it is resolved outside the IETF, fine, so long as it is reolved. Other explanations for the failure of OSI should be posted elsewhere, please :-) Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 04:06:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00747; Mon, 11 Apr 1994 03:50:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA16728; Mon, 11 Apr 1994 03:49:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA16703; Mon, 11 Apr 1994 03:19:11 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29676; Mon, 11 Apr 1994 03:16:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29810; Sun, 10 Apr 94 13:16:27 -0400 Date: Sun, 10 Apr 94 13:16:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404101716.AA29810@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Cc: jnc@ginger.lcs.mit.edu > I thought that the fact that the overhead cost in the routing inside the > geographical region is something worse than O(N) (where N is the number > of things which have moved from their original provider) made it > perfectly obvious to everyone that geographical addressing was not a > panacea. But _outside_ the geographical region, the aggregation is better, assuming any interconnectivity at all in the geographic region. Perhaps; I'd have to go away and think for a while about cases like multinationals, and other similar entities which want to run geographically distributed private topologies. However, even if true, it still doesn't get around the point that geographical addressing seems to impose unworkable costs inside a region. Is there some bug in my analysis I've missed, or am I right in saying that the routing overhead inside the area is at least O(N) in the number of things which have switched providers? If that's correct, are you saying that those costs are reasonable? Unless I'm missing something, those costs do happen, and they aren't reasonable. If so, geographic address won't work inside areas, and if it won't work inside areas, it doesn't matter how well it works outside them. And, you (and many others) assume single provider. ... I believe that this assumption is a severe fallacy even in the current Internet, let alone the future Internet. Many if not most of the university sites are multi-homed now. ... If you try to force people to have one provider forever, you'll have a revolt on your hands. I am not assuming single providers. Nobody's talking about doing this. Please don't create non-existent, undefendable "opposing" positions to ceremoniously knock down. Provider aggregation doesn't work with multi-provider sites. How to make multiple providers work in a topology based addressing system, for both outgoing (easy) and incoming (hard) is a very difficult issue (as I mentioned in the resonse to Ran Atkinson's message about it). This has been a recognized issue for years now: section 6.3 of the old Nimrod I-D from years ago says: The problem with that is that a [local] area, such as a campus, which in actual physical terms has connections to several long-haul networks, each of which is probably a separate [high-level] area, has an insufferable choice to make. Depending on which [high-level] area they associate themselves with, any traffic using the simple ... routing will get to that [local] area by means of the long-haul network with which the [high-level] area is associated in its global address. The problem *everyone* keeps bumping their heads on is that for the routing to scale, it has to use names which are based in the real topology. "Provider based addressing" isn't being considered because we like providers, but because it's a reflection of reality. Mail, UPS, Fedex, etc all manage to use the same addresses because they are based on the topology of the real world, which is rather two-dimensional and static, and in which a single set of "transmission" assets (streets) is shared by everyone. Unfortunately, the network topology has *none* of these attributes. There are a number of ideas on how to deal with this; see 6.3 for some of them. It would be terrible if their address was based on their first provider (Merit), because most of their traffic comes via their second provider (MSEN). ... The right thing to do is have geographic assignment and widespread interconnection. ... A geographic heirarchy makes much more sense, and is more understandable to the end users. How does geographic addressing distribute incoming traffic across multiple long-haul providers? I might point out that equal access through multiple providers with direct access to the end user is not something that the current phone system provides; if I have direct tie-lines to MCI and Sprint for outgoing phone calls, and you call in, you use your own long-distance carrier as far as the LATA, and then the RBOC. You may not use any of my long-haul carriers *at all*! Presumably exactly the same thing is going to happen in a system which uses geographic addressing. You'll get to the geographic area through the long-haul carrier to which you are connected, or which *you* pick (if you are multiply connected); only once at the city do you perhaps switch carriers for the final hop. And a geographic heirarchy penalizes the providers who refuse to interconnect, not the ones who do. It seems to me that it's just the opposite. As shown above, geographic address gives to the users more power to pick a carrier. If the only address I have for you is UTT.Bill_Simpson, and I send packets to that, then my carrier more or less has to give my traffic for you to UTT pretty quickly, otherwise they'll just be going in circles. It's in UTT's advantage (unless prevented by regulation) to give you an address which only makes sense to them. Noel From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 06:10:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04752; Mon, 11 Apr 1994 06:10:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA16856; Mon, 11 Apr 1994 06:09:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA16853; Mon, 11 Apr 1994 06:05:04 +1000 Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04024; Mon, 11 Apr 1994 05:47:05 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA03774 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sun, 10 Apr 1994 15:46:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 10 Apr 1994 15:46:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 10 Apr 1994 15:46:41 -0400 Message-Id: <199404101943.AA107979@foo.ans.net> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing In-Reply-To: Your message of "Sat, 09 Apr 1994 21:02:37 GMT." <2175.bill.simpson@um.cc.umich.edu> Date: Sun, 10 Apr 1994 15:43:42 -0400 From: Dennis Ferguson >> I thought that the fact that the overhead cost in the routing inside the >> geographical region is something worse than O(N) (where N is the number of >> things which have moved from their original provider) made it perfectly >> obvious to everyone that geographical addressing was not a panacea. >> > But _outside_ the geographical region, the aggregation is better, > assuming any interconnectivity at all in the geographic region. This is simply incorrect. It ignores even the basics of the current Internet's routing policy. The primary constraining policy which the current Internet's routing must be designed to implement is that the route taken from a source to a destination must only transit providers who have been paid (or have otherwise agreed, or been tasked) to carry traffic on behalf of either the source or the destination. This is sort of fundamental economics. Providers pay for their infrastructure with the income from their customers. If providers transit traffic which is not sourced by or destined to their customers then they are having infrastructure consumed without a corresponding source of income (or "having infrastructure consumed in a way which does not advance their mission-specific goals", if they're another kind of provider). No one could stay in business long under those conditions, so this policy is fundamental. Given this, a provider which has some of the subscribers in a particular geographic area as his customers, but not all, must avoid advertising routes to other providers (especially including those who have no customers in the geographic area, i.e. most of them) for those subscribers who are not his customers. To accomplish this the provider is prevented from ever aggregating the geographic address, since otherwise he would be forced to carry traffic from sources to destinations which weren't his customers. This is independent of interconnectivity (or lack thereof) within the geographic area. Geographic addresses cannot in general be aggregated without violating this policy (except in the special case where a single provider serves the entire region, since then the geographic address becomes a "provider address"). > And, you (and many others) assume single provider. Provider > aggregation doesn't work with multi-provider sites. Having multiple providers generally kicks in a second policy (it is better if the routes from m.p.site->X and X->m.p.site are symmetric for as many X's as possible) which requires the routes for such sites to be left unaggregated through a large part of the Internet topology no matter how the addresses were assigned. You may be right that the addition of multiprovider sites costs less when doing geographic addressing, but only because with provider addressing you actually can do aggregation, while with geographic addressing you almost never could, so you'll already have paid the price for geographic addressing whether sites are multi-homed or not. Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 13:23:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17249; Mon, 11 Apr 1994 12:36:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA17174; Mon, 11 Apr 1994 12:34:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA17171; Mon, 11 Apr 1994 12:25:19 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13111; Mon, 11 Apr 1994 10:48:53 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 11 Apr 1994 09:48:22 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA11768; Mon, 11 Apr 1994 09:48:23 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA09730; Mon, 11 Apr 94 09:48:24 JST Date: Mon, 11 Apr 94 09:48:24 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404110048.AA09730@cactus.slab.ntt.jp> To: J.Crowcroft@cs.ucl.ac.uk, lyman@BBN.COM Subject: Re: strange flow ID bug..... Cc: big-internet@munnari.OZ.AU, francis@BBN.COM From Lyman: > My understanding of Paul's scenario is that the route change involves a router > (C in Paul's example) that does not look at the flow ID (it just forwards > packets towards the destination D). The route changes between C and D, > but B's shortest-path route to D is still through C, even though C's > path to D now goes through B. Surely this loop will be detected by both > C and B after new routing updates have been exchanged? If an alternate > path from C to D goes through B, then B presumably has a path to D that > does not involve C, and will switch to that path when the new state of > the C-to-D link has propagated to B. Doesn't look like a problem to me, > unless I've missed something in Paul's note. > > - Lyman Lyman, You are absolutely correct.....my example was wrong (though several people overlooked this minor problem and understood what I was getting at anyway :-) How about this: Packet from host X to host Y, source routed to router B on the way. Assume a flow has been setup to this effect, and that the path goes like this: X --> A --> B --> C --> Y. Keep in mind that as far as router A was concerned, the destination was B, and as far as router C was concerned, the destination was host Y. Now, the path between C and Y breaks, so C finds that its flow ID is no longer good and looks into the packet to find the addressing info and reroutes the packet. This reroute, unfortunately, takes the packet back through A. Router A, however, is still routing on the flow ID, and forwarding the packet to B, which forwards it to C, which loops it back to A. As several people have pointed out, the solution is to somehow tag the packet to indicate that it is no longer being routed on the flow ID..... PF From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 16:41:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25802; Mon, 11 Apr 1994 16:41:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA17417; Mon, 11 Apr 1994 16:39:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA17413; Mon, 11 Apr 1994 16:38:11 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25743; Mon, 11 Apr 1994 16:39:22 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-03.dialip.mich.net (pm002-03.dialip.mich.net [35.1.48.84]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id CAA10617 for ; Mon, 11 Apr 1994 02:39:16 -0400 Date: Mon, 11 Apr 94 03:54:35 GMT From: "William Allen Simpson" Message-Id: <2182.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: heirarchical addressing > From: Dennis Ferguson > This is simply incorrect. It ignores even the basics of the current > Internet's routing policy. > Dennis, I don't know what to say, except that I don't know anyone else who thinks that traffic should be segregated by customer, and no transit be allowed between providers. Your economics and mine don't match. The current Internet routing policy expects a single backbone. This is going away soon. In my expectation, there will be multiple backbones, and every backbone will carry all traffic presented to it. Policy is best expressed by the user at the source, not by some provider. Go read NIMROD. :-< Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 16:44:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25909; Mon, 11 Apr 1994 16:44:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA17443; Mon, 11 Apr 1994 16:43:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA17412; Mon, 11 Apr 1994 16:38:11 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25736; Mon, 11 Apr 1994 16:39:18 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-03.dialip.mich.net (pm002-03.dialip.mich.net [35.1.48.84]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id CAA10614 for ; Mon, 11 Apr 1994 02:39:14 -0400 Date: Mon, 11 Apr 94 03:46:52 GMT From: "William Allen Simpson" Message-Id: <2181.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: strange flow ID bug..... > X --> A --> B --> C --> Y. > > Keep in mind that as far as router A was concerned, the destination was B, > and as far as router C was concerned, the destination was host Y. Now, the > path between C and Y breaks, so C finds that its flow ID is no longer good > and looks into the packet to find the addressing info and reroutes the packet. > This reroute, unfortunately, takes the packet back through A. Router A, > however, is still routing on the flow ID, and forwarding the packet to B, > which forwards it to C, which loops it back to A. > The flaw in this is that router C should be closest to Y. If A is closer to Y topologically, then the packet should never have gone through C in the first place. What path setup mechanism are we considering that would pass through a topologically close router to a topologically far router? I don't see that in RSVP or NIMROD, but am not familiar with SDRP (except for cursory reading). Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 17:15:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27009; Mon, 11 Apr 1994 17:15:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA17490; Mon, 11 Apr 1994 17:14:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA17465; Mon, 11 Apr 1994 16:51:26 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26213; Mon, 11 Apr 1994 16:52:37 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 11 Apr 1994 15:52:32 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id PAA17340; Mon, 11 Apr 1994 15:52:32 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA13948; Mon, 11 Apr 94 15:52:32 JST Date: Mon, 11 Apr 94 15:52:32 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404110652.AA13948@cactus.slab.ntt.jp> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: strange flow ID bug..... > > > X --> A --> B --> C --> Y. > > > > Keep in mind that as far as router A was concerned, the destination was B, > > and as far as router C was concerned, the destination was host Y. Now, the > > path between C and Y breaks, so C finds that its flow ID is no longer good > > and looks into the packet to find the addressing info and reroutes the packet. > > This reroute, unfortunately, takes the packet back through A. Router A, > > however, is still routing on the flow ID, and forwarding the packet to B, > > which forwards it to C, which loops it back to A. > > > The flaw in this is that router C should be closest to Y. If A is closer > to Y topologically, then the packet should never have gone through C in > the first place. What path setup mechanism are we considering that > would pass through a topologically close router to a topologically far > router? I don't see that in RSVP or NIMROD, but am not familiar with > SDRP (except for cursory reading). > For this example, A only became closer to Y after something between C and Y broke. It might have been a perfectly good path before something broke. That having been said, I guess there is nothing in RSVP or NIMROD that prevents a source route that first goes through something far and then something close to ultimately get to something far. In both of those schemes, the source presents the network with a source route. If the source route is stupid, so be it. It is not in the network's purview to ignore a stupid source route based on its knowledge of topology. PF From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 18:14:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28197; Mon, 11 Apr 1994 17:51:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA17531; Mon, 11 Apr 1994 17:49:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA17506; Mon, 11 Apr 1994 17:23:07 +1000 Received: from vangogh.CS.Berkeley.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27315; Mon, 11 Apr 1994 17:24:22 +1000 (from sklower@vangogh.CS.Berkeley.EDU) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.8.1/8.6.6) id AAA12658; Mon, 11 Apr 1994 00:19:28 -0700 Date: Mon, 11 Apr 1994 00:19:28 -0700 From: Keith Sklower Message-Id: <199404110719.AAA12658@vangogh.CS.Berkeley.EDU> To: bound@zk3.dec.com Subject: Correcting Mistaken Affiliations, (was IPng APIs) Cc: atkinson@zk3.dec.com, big-internet@munnari.OZ.AU This has very little IPng content. I am not on the big-internet mailing list, but somebody forwarded some remarks of Jim Bound (bound@zk3.dec.com) to which I feel very much obliged to make some corrections. I do not work for, nor do I have any financial interest in BSDI. I am employed by the University of California, and do everything I can so that my work stays publically available. However, I have served on the Posix.12 committee, and can say in all honesty that the goal of the committee is document existing practice so as to enhance program portability. It was made painfully clear to us, after conducting a survey, that the community does not want much innovation from **that** direction. It is widely felt that both sockets and XTI provide access to protocol-dependent features in a relatively protocol independent framework. That the proposed API's by Hinden & al for SIPP, and the breadboard prototype that I did for TCP/CLNP fit easily in sockets is a tribute to the good work of other people a while ago. However, it I think it would be very premature to cast these as a formal standard before there was substatial implementation experience. From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 19:36:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01867; Mon, 11 Apr 1994 19:36:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA17666; Mon, 11 Apr 1994 19:34:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA17662; Mon, 11 Apr 1994 19:25:18 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01640; Mon, 11 Apr 1994 19:26:35 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA02577; Mon, 11 Apr 1994 02:26:05 -0700 Date: Mon, 11 Apr 1994 02:26:05 -0700 From: Tony Li Message-Id: <199404110926.CAA02577@lager.cisco.com> To: bill.simpson@um.cc.umich.edu ("William Allen Simpson") Cc: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Dennis, I don't know what to say, except that I don't know anyone else who thinks that traffic should be segregated by customer, and no transit be allowed between providers. Your economics and mine don't match. The current Internet routing policy expects a single backbone. This is going away soon. In my expectation, there will be multiple backbones, and every backbone will carry all traffic presented to it. Policy is best expressed by the user at the source, not by some provider. Go read NIMROD. :-< Bill, I suggest you go read the NSFnet re-solicitation. Your economics simply don't match reality. Please pay attention to the acronym vBNS. If that doesn't help, I'll buy you and Milo lunch and he can explain it to you. ;-) Tony From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 21:32:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29382; Mon, 11 Apr 1994 18:25:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA17572; Mon, 11 Apr 1994 18:24:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA17569; Mon, 11 Apr 1994 18:19:19 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25789; Mon, 11 Apr 1994 16:40:43 +1000 (from bill.simpson@um.cc.umich.edu) Received: from merit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15207 Mon, 11 Apr 1994 16:40:39 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-03.dialip.mich.net (pm002-03.dialip.mich.net [35.1.48.84]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id CAA10620 for ; Mon, 11 Apr 1994 02:39:18 -0400 Date: Mon, 11 Apr 94 04:00:44 GMT From: "William Allen Simpson" Message-Id: <2183.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: heirarchical addressing > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Perhaps; I'd have to go away and think for a while about cases like > multinationals, and other similar entities which want to run geographically > distributed private topologies. However, even if true, it still doesn't get > around the point that geographical addressing seems to impose unworkable costs > inside a region. > Sorry, but I think that your regions must be bigger than my regions. I just don't think a few thousand local routes is very many. I remember Deering arguing that even a million local routes isn't too many. And, as I said before, if the region becomes too dense, have multiple interconnections within the region. Just like overlapping area codes. The phone company can already do it. We are much better at routing than the phone company (a little hubris ;-). > Is there some bug in my analysis I've missed, or am I right in saying that the > routing overhead inside the area is at least O(N) in the number of things > which have switched providers? If that's correct, are you saying that those > costs are reasonable? Unless I'm missing something, those costs do happen, and > they aren't reasonable. If so, geographic address won't work inside areas, and > if it won't work inside areas, it doesn't matter how well it works outside > them. > I agree on the O(N) inside the region. I think it's workable, at least for the regions that I'm contemplating. > The problem *everyone* keeps bumping their heads on is that for the routing to > scale, it has to use names which are based in the real topology. "Provider > based addressing" isn't being considered because we like providers, but > because it's a reflection of reality. > Right. But, we are stuck with a single backbone for now. Does that mean that they own the address space forever? No. Better that even now, we plan for multiple backbones and a widely interconnected mesh. > Presumably exactly the same thing is going to happen in a system which uses > geographic addressing. You'll get to the geographic area through the long-haul > carrier to which you are connected, or which *you* pick (if you are multiply > connected); only once at the city do you perhaps switch carriers for the > final hop. > That's right! It should be the same for the Internet. My traffic to you would be carried on my provider as far as your local area. My flow setup would require this. (Is it likely that some other provider would let me use its routers instead?) For datagram based hop-by-hop, the path is necessarily asymetric (no flow setup). On my provider to you; on your provider back to me. > And a geographic heirarchy penalizes the providers who refuse to > interconnect, not the ones who do. > > It seems to me that it's just the opposite. As shown above, geographic address > gives to the users more power to pick a carrier. If the only address I have > for you is UTT.Bill_Simpson, and I send packets to that, then my carrier more > or less has to give my traffic for you to UTT pretty quickly, otherwise > they'll just be going in circles. It's in UTT's advantage (unless prevented > by regulation) to give you an address which only makes sense to them. > If UTT uses addresses that only make sense to them, their routing table will overflow really quickly! And nobody will switch to them (unless UTT is really cheap), because UTT won't support the old addresses. It costs $$$ to switch addresses, even using DHCP. As you say, the other carriers will give the traffic to UTT really quickly, which means UTT will carry more of the burden, because they will have to carry the traffic both ways, through their lack of interconnection. If they join the pool of geographically assigned addresses, their global tables will be limited to one entry for each region they serve, and people will be happy to switch to them, since they can keep their old addresses. The traffic between regions will take optimal routes, instead of (over-)loading UTT's links. It's a competitive advantage. ---- Are you are predicting that the current assignment of provider-based addresses will give current providers an advantage against new ones? If so, then we must STOP giving out provider-based addresses. I will gladly draw up a U.S. plan for regional address assignment, and ask everyone to require their provider use it to get their business. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 21:49:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04378; Mon, 11 Apr 1994 20:46:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA17758; Mon, 11 Apr 1994 20:44:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA17744; Mon, 11 Apr 1994 20:31:40 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03748; Mon, 11 Apr 1994 20:32:54 +1000 (from Z.Wang@cs.ucl.ac.uk) Message-Id: <9404111032.3748@munnari.oz.au> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 11 Apr 1994 11:32:14 +0100 To: Lyman Chapin Cc: big-internet@munnari.OZ.AU Subject: Re: strange flow ID bug..... In-Reply-To: Your message of "Fri, 08 Apr 94 09:55:02 EDT." <9404081456.22200@munnari.oz.au> Date: Mon, 11 Apr 94 11:32:14 +0100 From: Zheng Wang >My understanding of Paul's scenario is that the route change involves a router >(C in Paul's example) that does not look at the flow ID (it just forwards >packets towards the destination D). The route changes between C and D, >but B's shortest-path route to D is still through C, even though C's >path to D now goes through B. Surely this loop will be detected by both >C and B after new routing updates have been exchanged? If an alternate >path from C to D goes through B, then B presumably has a path to D that >does not involve C, and will switch to that path when the new state of >the C-to-D link has propagated to B. Doesn't look like a problem to me, >unless I've missed something in Paul's note. You are right, but in general, distance-vector routing does not have info to detect loops with more than two nodes. Cheers Zheng From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 00:43:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06132; Mon, 11 Apr 1994 21:56:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA17822; Mon, 11 Apr 1994 21:54:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA17819; Mon, 11 Apr 1994 21:49:36 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04983; Mon, 11 Apr 1994 21:16:11 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 11 Apr 94 19:54:58 +0859 From: Masataka Ohta Message-Id: <9404111055.AA22302@necom830.cc.titech.ac.jp> Subject: Re: heirarchical addressing To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Apr 94 19:54:56 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9404090414.AA19369@ginger.lcs.mit.edu>; from "Noel Chiappa" at Apr 9, 94 12:14 am X-Mailer: ELM [version 2.3 PL11] > I thought that we beat this to death a year or so ago on this list. > > So did I, actually. > > I thought that the fact that the overhead cost in the routing inside the > geographical region is something worse than O(N) (where N is the number of > things which have moved from their original provider) made it perfectly > obvious to everyone that geographical addressing was not a panacea. I agree. > If 100K people and businesses have changed their provider inside a city (not > an unreasonable number over a period of years), and kept the same "address" as > the *only* label by which the routing tracks them, the routing just can't hack > that. I think the issue should be addressed by DNS and DHCP. That is, a host should know its provider address from DHCP through broadcast (or, in case of mobility, by contacting its HR). DNS RR for IPng should have some indirection mechanism to specify the provider address. For example, A_ng PROVIDER_A As PROVIDER_A RR will be added to the additional section most of the time, we don't actually need extra DNS query. With proper indirection, a new provider address of a host can be specified only by changing a single RR (including several instances of the glue records for name servers). Thus, we don't need any complex routing. Doesn't it work? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 03:55:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12964; Tue, 12 Apr 1994 01:26:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA18002; Tue, 12 Apr 1994 01:24:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA17988; Tue, 12 Apr 1994 01:01:49 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08470; Mon, 11 Apr 1994 23:18:31 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA27125; Mon, 11 Apr 94 06:14:08 -0700 Received: by xirtlu.zk3.dec.com; id AA15099; Mon, 11 Apr 1994 09:14:05 -0400 Message-Id: <9404111314.AA15099@xirtlu.zk3.dec.com> To: Keith Sklower Cc: bound@zk3.dec.com, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU Subject: Re: Correcting Mistaken Affiliations, (was IPng APIs) In-Reply-To: Your message of "Mon, 11 Apr 94 00:19:28 PDT." <199404110719.AAA12658@vangogh.CS.Berkeley.EDU> Date: Mon, 11 Apr 94 09:13:23 -0400 X-Mts: smtp >This has very little IPng content. I am not on the big-internet >mailing list, but somebody forwarded some remarks of Jim Bound >(bound@zk3.dec.com) to which I feel very much obliged to make some >corrections. It was referenced regarding whether the IETF should make a requirment that each proposal provide an API spec for their proposal. I can send you the back mail on this off line if you like. Thats what generated my mail and it was very IPng related with content. >I do not work for, nor do I have any financial interest in BSDI. >I am employed by the University of California, and do everything >I can so that my work stays publically available. My error )--> sorry. >However, I have served on the Posix.12 committee, and can say >in all honesty that the goal of the committee is document >existing practice so as to enhance program portability. It was made >painfully clear to us, after conducting a survey, that the >community does not want much innovation from **that** direction. Well I would not say totally just document the existing practice. There was deliberation on readv and writev as they did not match the POSIX read/write semantics. They don't just sit there and take it as is, they determine if they work. For example in X/Open there was just a discussion of what the option IP_DONROUTE really means and why its important and how it is used today. This should tell us something about the services we provide at the network layer to the transport via IPng and how that is specified in an RFC. Clarity is critical. Also when folks on this list talk about a defacto sockets API some also may include gethostbyname, ascii conversion of addresses, and the other library calls often associated with sockets. POSIX nor X/Open at this time address these interfaces. It might be good for the IETF to suggest to the POSIX and X/Open groups to pick up these interfaces too? Or this may be a whole new set of APIs needed for specification. >It is widely felt that both sockets and XTI provide access to >protocol-dependent features in a relatively protocol independent >framework. That the proposed API's by Hinden & al for SIPP, and >the breadboard prototype that I did for TCP/CLNP fit easily in >sockets is a tribute to the good work of other people a while ago. It is Gilligan & al for SIPP. And so far we only have a spec for SIPP and that you will see an update for soon. Also none of the APIs anywhere are really multi-protocol but this list is not the place for us to get into this age old network interface debate. >However, it I think it would be very premature to cast these as a >formal standard before there was substatial implementation experience. Agreed. But specs help get implementation experience started. They also provide a discussion reference for the proposals strategy to support IPng at the interface and backwards compatibility. /jim From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 03:59:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15414; Tue, 12 Apr 1994 02:36:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA18149; Tue, 12 Apr 1994 02:34:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18126; Tue, 12 Apr 1994 02:23:31 +1000 Received: from admii.arl.army.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14949; Tue, 12 Apr 1994 02:24:45 +1000 (from reschly@ARL.ARMY.MIL) Date: Mon, 11 Apr 94 12:15:03 EDT From: "Robert J. Reschly Jr." To: Jon Crowcroft Cc: big-internet@munnari.OZ.AU Subject: Re: Another firm requirement for IPNG Message-Id: <9404111215.aa15915@ADMII.ARL.ARMY.MIL> Jon :-) writes: > When a random sample of IETF attendees are asked to explain the IPng, 60% > must be able to get the salient points right. I can see it now....an ISOC advertisment in which states: "...and 3 out of 5 network experts agree...." [VO: We return now to our regularly scheduled discussion...] Later, Bob From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 04:00:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15474; Tue, 12 Apr 1994 02:39:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA18164; Tue, 12 Apr 1994 02:37:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18080; Tue, 12 Apr 1994 02:05:53 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11767; Tue, 12 Apr 1994 00:42:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06004; Mon, 11 Apr 94 10:42:12 -0400 Date: Mon, 11 Apr 94 10:42:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404111442.AA06004@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Cc: jnc@ginger.lcs.mit.edu Policy is best expressed by the user at the source, not by some provider. Go read NIMROD. Funny you should mention this, I was just thinking about this this morning! I think there are applications for "destination" policies, e.g. 800 numbers, where the destination is paying the charges, and wishes to say something about what the path to it looks like. How exactly to handle things like this (the worst case being where each end want sot have some influence on the path, so it cannot be set wholly by one entity) is something of an open issue... Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 04:00:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15529; Tue, 12 Apr 1994 02:40:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA18179; Tue, 12 Apr 1994 02:38:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18097; Tue, 12 Apr 1994 02:09:04 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11874; Tue, 12 Apr 1994 00:46:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06026; Mon, 11 Apr 94 10:46:07 -0400 Date: Mon, 11 Apr 94 10:46:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404111446.AA06026@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: strange flow ID bug..... Cc: jnc@ginger.lcs.mit.edu What path setup mechanism are we considering that would pass through a topologically close router to a topologically far router? Maybe that was the only path that met some wierd set of policy constraints the user had? Maybe the bandwidth the user needed was only available along that path? Who knows... I don't see that in ... NIMROD Nimrod doesn't have the path-generation mechanisms as part of the spec; they are local choices. Thus, it's not really correct to say that "Nimrod will/will not generate such paths"; it's the path-generation which would do it, and that's not really part of Nimrod. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 04:01:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15541; Tue, 12 Apr 1994 02:41:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA18199; Tue, 12 Apr 1994 02:40:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18143; Tue, 12 Apr 1994 02:29:27 +1000 Received: from ibmmail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13990; Tue, 12 Apr 1994 01:56:52 +1000 (from camg64lb@ibmmail.IBMMAIL.COM) Message-Id: <9404111556.13990@munnari.oz.au> Received: from IBMMAIL.COM by ibmmail.COM (IBM VM SMTP V2R3) with BSMTP id 8537; Mon, 11 Apr 94 11:55:48 EDT Date: Mon, 11 Apr 94 11:54:20 EDT From: camg64lb@ibmmail.COM To: francis@catus.slab.ntt.jp Cc: Big-Internet@munnari.OZ.AU Subject: Strange flow ID bug ----------------------- Mail item text follows --------------- To: INTERNET--IBMMAIL From: Mark Kaczmarczyk Subject: Strange flow ID bug "...the source presents the network with a source route. If the source route is stupid, so be it. It is not within the network's purview to ignore a stupid source route based on its knowledge of topology..." I agree completely....especially since the network has no idea whether the route IS stupid, other than topologically. Perhaps cost, security or other factors were involved at the source to choose the route in the first place. Thanks, Mark Global Securities Systems, 74 Victoria, 5th Floor RTHOST(MKACZMAR) (416) 981-8194 From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 04:03:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15575; Tue, 12 Apr 1994 02:43:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA18220; Tue, 12 Apr 1994 02:41:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18100; Tue, 12 Apr 1994 02:09:21 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11683; Tue, 12 Apr 1994 00:39:36 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Mon, 11 Apr 1994 10:39:22 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 11 Apr 1994 10:39:22 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA29197; Mon, 11 Apr 94 10:38:18 EDT Date: Mon, 11 Apr 94 10:38:18 EDT Message-Id: <9404111438.AA29197@mailserv-D.ftp.com> To: bound@zk3.dec.com Subject: Re: IPng should support binary IPv4 mode API out-of-the-box From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 941 > Each IPng proposal should take the time to write up or build an API ID > that describes what their proposal will do in this situation. And I > don't think the answer 'this is an implementation issue' is a valid > answer or correct in my mind. Presumably this will be for the more common APIs? Does this include ftp software's INT-61 API and PCTCPAPI for our PC/TCP product? I'd imagine that, in terms of "number of stacks shipped" we are probably one of the top providers of TCP/IP stacks to the world. There are A LOT of PCs in the world :-) While the IPng directorate are certainly within their rights to require the IPng proposals to provide any documents, including, e.g., a sockets API specification, people should not think for one minute that this solves the problem of migration and/or porting software from IPv4 to IPng.... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 04:05:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15619; Tue, 12 Apr 1994 02:44:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA18235; Tue, 12 Apr 1994 02:43:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18140; Tue, 12 Apr 1994 02:29:09 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12945; Tue, 12 Apr 1994 01:23:26 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA05493; Mon, 11 Apr 94 08:16:17 -0700 Received: by xirtlu.zk3.dec.com; id AA24445; Mon, 11 Apr 1994 11:16:14 -0400 Message-Id: <9404111516.AA24445@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: IPng should support binary IPv4 mode API out-of-the-box In-Reply-To: Your message of "Mon, 11 Apr 94 10:38:18 EDT." <9404111438.AA29197@mailserv-D.ftp.com> Date: Mon, 11 Apr 94 11:16:08 -0400 X-Mts: smtp > > Each IPng proposal should take the time to write up or build an API ID > > that describes what their proposal will do in this situation. And I > > don't think the answer 'this is an implementation issue' is a valid > > answer or correct in my mind. >Presumably this will be for the more common APIs? Does this include >ftp software's INT-61 API and PCTCPAPI for our PC/TCP product? I'd >imagine that, in terms of "number of stacks shipped" we are probably >one of the top providers of TCP/IP stacks to the world. There are A >LOT of PCs in the world :-) You know I don't want to get into what we do or don't do but we too are shipping a lot of stacks too and Pathwork PCs are moving well with IP and servers too. The bottom line is the binary compatibility issue for IP apps on all machines I reiterated until they become IPng capable. If thats not possible in all cases thats fine as long as we tell folks and explain a work around. Also different proposals have different affects on the implementations which I am waiting to lay on all once we get there. Believe me there is a difference. >While the IPng directorate are certainly within their rights to >require the IPng proposals to provide any documents, including, e.g., >a sockets API specification, people should not think for one minute >that this solves the problem of migration and/or porting software >from IPv4 to IPng.... It does not solve the problem no. It does two things. It lets us investigate feasibility and technical viability prior to unleashing the beast on the market with one of these proposals, and forces detailed technical analysis. It also may permit us to get some specifications written down for a very complex technical area for IPng. /jim From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 04:06:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15669; Tue, 12 Apr 1994 02:49:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA18250; Tue, 12 Apr 1994 02:45:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18146; Tue, 12 Apr 1994 02:29:49 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14123; Tue, 12 Apr 1994 02:00:59 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA11651; Mon, 11 Apr 94 09:02:39 -0700 Date: Mon, 11 Apr 94 09:02:39 -0700 From: Eric Fleischman Message-Id: <9404111602.AA11651@atc.boeing.com> To: ericf@atc.boeing.com, medin@nsipo.nasa.gov Subject: Re: Introducing proxy aggregations? Cc: big-internet@munnari.OZ.AU, ericf@cincsac.arc.nasa.gov, jnc@ginger.lcs.mit.edu, poole@magnolia.eunet.ch Dear Milo, Thanks for your response. Your arguments are excellent. However, from my knot-hole, the essential point of disagreement between us seems to be that you equate provider-based addressing as the only (or preferable) way of doing "hierarchy" (which is neccessary for aggregation) while I haven't addressed aggregation at all. Rather, I merely stated that provider-based addressing has a burdon on the end user which in some/ many cases is untenable and thus I believe that provider-based addressing is ultimately untenable. Now to meet you on a common topic: my viewpoint is that the ultimate hierachy should be flexible: not prescribed by an a priori schema but able to "conform" to whatever schema proves to be desirable. However, failing that, my own "best cut" would be for geographical hierarchy. Our networks are not likely to change location and we (as a company) have a geographical orientation already. We talk of the bezillion Boeing Puget Sound locations and our locations in Wichita, Philadelphia, Huntsville, et.al. nationally and internationally. This is how we think and we have a VERY large international corporate network of our own. However, I am not suggesting that the whole world adopt geographical addressing because that is how we see it. I am stating, however, that this is a logical "cut" to view huge networks and thus should not be rejected out-of-hand -- and this viewpoint is much more benign (tenable) for the end user than provider-based addressing. Of course, geographical hierachies has been argued against for a variety of reasons including current network providers and their needs. However, should users be given an option to select between network providers then we would have a very different world than today -- with vastly different requirements for the service prover than today. In such a world only geography would be a constant. Thus this is the only "still point" to have hierarchy around. Thus, the bottom line in my thinking is whether one imagines that the current "network provider" reality will remain constant or whether one imagines that "local competition" will arise thus vastly changing future realities from today's reality. Please forgive me if I am not being coherent: I am talking (over the phone) and typing at the same time (on different topics). Things are really hectic around here... In any case, thank you for your very insightful comments on this important topic. Sincerely yours, --ERic Fleischman From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 04:56:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20350; Tue, 12 Apr 1994 04:56:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA18417; Tue, 12 Apr 1994 04:54:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA18414; Tue, 12 Apr 1994 04:48:35 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20128; Tue, 12 Apr 1994 04:49:51 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 0428; Mon, 11 Apr 94 14:48:30 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 0311; Mon, 11 Apr 1994 14:48:30 -0400 Date: Mon, 11 Apr 94 14:44:06 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: IPng & Provider-oriented addressing To: Neil Readwin , Craig Partridge Cc: big-Internet@munnari.OZ.AU In-Reply-To: <9404082128.AA22031@moria> Message-Id: <940411.144406.EDT.VALDIS@vtvm1.cc.vt.edu> On Fri, 8 Apr 1994 22:28:18 +0100 (BST) you said: >That's like saying the hardest part of moving offices is making sure >all your employees know they are meant to arrive at a different >location on Monday morning. Last time we moved offices that was not a >major problem. Neil. Well.. the last time I moved my office, the hard part was making sure that the 35 tractor trailer loads of hardware arrived in the right order - we moved a data center that had a 3090, a 3084, about 200 3350/3370/3380 disk drive enclosures, and a bunch of small stuff (Vaxen, 4300's, etc). That was 4 years ago, and there are *STILL* people on this campus that think that we're still in Burrus Hall (the old machine room has been an architecture studio all this time) and don't know that we're out past the airport in the Corporate Research Center. It isn't your *EMPLOYEES* finding their way to work - it's all the people that the employees deal with that you have to worry about.... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 05:17:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17853; Tue, 12 Apr 1994 03:46:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA18326; Tue, 12 Apr 1994 03:44:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA18299; Tue, 12 Apr 1994 03:14:42 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16694; Tue, 12 Apr 1994 03:15:51 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-23.dialip.mich.net (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA27061 for ; Mon, 11 Apr 1994 13:15:46 -0400 Date: Mon, 11 Apr 94 15:33:50 GMT From: "William Allen Simpson" Message-Id: <2192.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: strange flow ID bug..... > From: francis@cactus.slab.ntt.jp (Paul Francis) > That having been said, I guess there is nothing in RSVP or NIMROD that > prevents a source route that first goes through something far and then > something close to ultimately get to something far. In both of those > schemes, the source presents the network with a source route. If the > source route is stupid, so be it. It is not in the network's purview to > ignore a stupid source route based on its knowledge of topology. > Then, I don't think we much care if a "stupid" source route gets dropped because its TTL expires when a link fails. It is an onus on source routing that the source do a good job of picking its routes. Let's not optimize for "stupid" situations. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 06:31:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19076; Tue, 12 Apr 1994 04:21:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA18374; Tue, 12 Apr 1994 04:19:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA18353; Tue, 12 Apr 1994 04:03:18 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13977; Tue, 12 Apr 1994 01:55:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06723; Mon, 11 Apr 94 11:55:37 -0400 Date: Mon, 11 Apr 94 11:55:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404111555.AA06723@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Cc: jnc@ginger.lcs.mit.edu > it still doesn't get around the point that geographical addressing seems > to impose unworkable costs inside a region. Sorry, but I think that your regions must be bigger than my regions. I just don't think a few thousand local routes is very many. I remember Deering arguing that even a million local routes isn't too many. I guess I was assuming that a region would be like, a city or so. If so, you're going to get a lot more than "a few thousand" local routes. With, say, 5 million subscibers (individuals and business), it would be reasonable to assume that after, say, 10 years, 25% would no longer be with their original provider; i.e. 1.25 million subscribers which cannot be aggregated. That's a *lot* of routes to carry around. Steve may think that it's no big deal to route to a million separate, distinct destinations, but see if *any* routing specialist will agree with that.... Try running OSPF, IS-IS, IDRP, a hypothetical new DV protocol based on Jose Garcia-Luna's algorithms, or anything else, to a million destinations... And, as I said before, if the region becomes too dense, have multiple interconnections within the region. Just like overlapping area codes. I was unable to figure out what you meant here. Multiple physical connections inside a piece of the topology which is addressed "flat" (as geographic addressing requires) isn't going to change the scale of the routing problem. If you assign two different "area codes", either i) they are aliases, which isn't going to help, or ii) you've split the area into two, so when you move from one half to the other you have to change. The phone company can already do it. We are much better at routing than the phone company (a little hubris ;-). That may or may not be true (I'm not up on their latest work in the long-haul networks), but it doesn't mean we can make water run uphill. > Is there some bug .. I've missed, or am I right in saying that the > routing overhead inside the area is at least O(N) in the number of things > which have switched providers? ... are you [then] saying that those > costs are reasonable? I agree on the O(N) inside the region. I think it's workable, at least for the regions that I'm contemplating. Umm. Exactly how many subscribers do you forsee inside one of these flat-addressed geographic regions, and what's your prediction for the % that will switch providers each year? >> And a geographic heirarchy penalizes the providers who refuse to >> interconnect, not the ones who do. > It seems to me that it's just the opposite. As shown above, geographic > address gives to the users more power to pick a carrier. If the only > address I have for you is UTT.Bill_Simpson ... then my carrier more or > less has to give my traffic for you to UTT pretty quickly ... It's in > UTT's advantage (unless prevented by regulation) to give you an address > which only makes sense to them. If UTT uses addresses that only make sense to them, their routing table will overflow really quickly! Absolutely not. They could assign addresses via a strict relationship to your topological location within *their* network. (I'm temporarily passing over how they deal with topology changes...) These addresses would be absolutely fine for them, just useless to people outside. And nobody will switch to them (unless UTT is really cheap), because UTT won't support the old addresses. It's not an issue of making is easy to convert *to* them, it's an issue of making it harder to *leave* them, although that's secondary to the main point, maximizing revenues. As you say, the other carriers will give the traffic to UTT really quickly, which means UTT will carry more of the burden If the charging model we adopt hands out revenues based on the actual amount of carrying done, this will benfit UTT, as they will have more revenue. they will have to carry the traffic both ways, through their lack of interconnection. Nope. If the site you're taling to is on GTT, which has the same crafty kind of people running it, they will have the same scheme, and UTT will have to give the traffic back to *them* as soon as possible. people will be happy to switch to them, since they can keep their old addresses. Oh, they'd want to support this, to make it easy to snarf customers, but for people who are just signing up, they'd want to hand out UTT addresses. The traffic between regions will take optimal routes, instead of (over-)loading UTT's links. It depends on the charging model whether this is good or bad. If the charge is closely related to the amount of traffic, more traffic -> more revenues, and that's what most companies want. They can use the revenues to provide the capacity, and assuming they are competent business-people, they will make more money from the larger revenues. Are you are predicting that the current assignment of provider-based addresses will give current providers an advantage against new ones? Not in the current routing model, which is basically flat addressing internet-wide; i.e. you can take your IP address with you whereever you go. Also, the current charging model is not heavily based on traffic, so there's no advantage to carrying it for more of its path; in fact, its in a carrier's economic interest to hand it off to some other carrier ASAP. I mean, if I'm carrier X, and you're carrier Y, and we're both connected to customer C, and at some point a long, long way away from C, where we are interconnected, I'm given a packet to C, if I can keep the $$$ and give *you* the packet (and the work of carrying it all the way to C), I'm set! To that the extent that the charging model does not reflect reality, there will be an opportunity for sharp operators to skim the cream, just the way old-style arbitrage worked. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 06:45:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22448; Tue, 12 Apr 1994 06:08:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA18499; Tue, 12 Apr 1994 06:04:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA18480; Tue, 12 Apr 1994 05:42:17 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18467; Tue, 12 Apr 1994 04:05:30 +1000 (from Geoff.Arnold@East.Sun.COM) Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00978; Mon, 11 Apr 94 11:05:01 PDT Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA29586; Mon, 11 Apr 94 14:04:59 EDT Received: from tyger.East.Sun.COM by suneast.East.Sun.COM (4.1/SMI-4.1) id AA10067; Mon, 11 Apr 94 14:05:34 EDT Received: by tyger.East.Sun.COM (5.0/SMI-SVR4) id AA11329; Mon, 11 Apr 1994 14:04:42 +0500 Date: Mon, 11 Apr 1994 14:04:42 +0500 From: Geoff.Arnold@East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) Message-Id: <9404111804.AA11329@tyger.East.Sun.COM> To: big-internet@munnari.OZ.AU Subject: Re: IPng should support binary IPv4 mode API out-of-the-box X-Sun-Charset: US-ASCII Content-Length: 1592 >> From owner-Big-Internet@munnari.OZ.AU Mon Apr 11 13:04:57 1994 >> From: bound@zk3.dec.com >> To: kasten@ftp.com >> Cc: bound@zk3.dec.com, big-internet@munnari.oz.au >> Subject: Re: IPng should support binary IPv4 mode API out-of-the-box >> Date: Mon, 11 Apr 94 11:16:08 -0400 >> X-Mts: smtp >> >> >> > > Each IPng proposal should take the time to write up or build an API ID >> > > that describes what their proposal will do in this situation. And I >> > > don't think the answer 'this is an implementation issue' is a valid >> > > answer or correct in my mind. >> >> >Presumably this will be for the more common APIs? Does this include >> >ftp software's INT-61 API and PCTCPAPI for our PC/TCP product? I'd >> >imagine that, in terms of "number of stacks shipped" we are probably >> >one of the top providers of TCP/IP stacks to the world. There are A >> >LOT of PCs in the world :-) >> >> You know I don't want to get into what we do or don't do but we too are >> shipping a lot of stacks too and Pathwork PCs are moving well >> with IP and servers too. The bottom line is the binary compatibility >> issue for IP apps on all machines I reiterated until they become IPng >> capable. As yet another vendor of "lots of stacks", I would like to suggest that for PCs the only really important API to get right is Windows Sockets. The timing is right for this; discussions are underway for Windows Sockets 2.0, and we should see initial development and interoperability testing of the APIs by the end of the summer. (My guess, not a Sun commitment, blah, blah, blah). Geoff From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 10:00:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23418; Tue, 12 Apr 1994 06:41:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA18563; Tue, 12 Apr 1994 06:39:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA18558; Tue, 12 Apr 1994 06:28:40 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21388; Tue, 12 Apr 1994 05:29:33 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14454(6)>; Mon, 11 Apr 1994 12:29:05 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 11 Apr 1994 12:29:11 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: heirarchical addressing In-Reply-To: jnc's message of Mon, 11 Apr 94 08:55:37 -0800. <9404111555.AA06723@ginger.lcs.mit.edu> Date: Mon, 11 Apr 1994 12:29:09 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Apr11.122911pdt.12171@skylark.parc.xerox.com> > Steve may think that it's no big deal to route to a million separate, > distinct destinations, but see if *any* routing specialist will agree with > that.... Try running OSPF, IS-IS, IDRP, a hypothetical new DV protocol > based on Jose Garcia-Luna's algorithms, or anything else, to a million > destinations... Even a routing ignoramus like me would never propose such a thing. What I had proposed is that providers keep a database of all of their own customers within a metro area, containing a mapping from each customer prefix to the address(es) of the provider's own boundary router(s) where the customer is attached to the provider. The database could contain millions or tens of millions of entries, and is likely to exist anyway, for maintenance, billing, or other reasons. Routing to intra-metro destinations by the provider's routers would be a two-step process: (1) look up a destination address in the database to learn the boundary router and (2) look up the boundary router in the routing table to determine the next hop. The result of the first step would be cached, so it would not have to be repeated on every packet to the same customer prefix. If an intra-metro destination address were not found in the provider's database, implying that the destination was not one of the provider's own customers, the packet would be routed towards the nearest MIX (Metropolitan Internet Exchange, where all of the provider's serving the same metro area interconnect) for hand-off to the appropriate provider. Thus, I was not proposing that anyone run a conventional routing protocol over a flat space of millions of address prefixes, but rather just over the addresses of a provider's own routers. An important assumption was that response to changes of customer-prefix-to-boundary-router bindings need not be as dynamic as the response to topology changes that conventional routing protocols are designed to handle. I stopped pushing my geographical addressing proposal because too many people failed to distinguish it from SIP and, since they favored provider-based addressing, they used that as an excuse to reject SIP. We are working hard to make auto-readdressing work in SIPP, so that provider-based addressing will be tolerable. However, the jury is still out on how tolerable we can actually make it. If it turns out to be not so painless as we hope, I am comforted to know that the geographical alternative is available as a fall-back. Steve From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 10:49:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26923; Tue, 12 Apr 1994 08:26:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA18663; Tue, 12 Apr 1994 08:24:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA18660; Tue, 12 Apr 1994 08:20:19 +1000 Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26684; Tue, 12 Apr 1994 08:21:28 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA19127 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 11 Apr 1994 18:21:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 11 Apr 1994 18:21:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 11 Apr 1994 18:21:12 -0400 Message-Id: <199404112218.AA111894@foo.ans.net> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing In-Reply-To: Your message of "Mon, 11 Apr 1994 03:54:35 GMT." <2182.bill.simpson@um.cc.umich.edu> Date: Mon, 11 Apr 1994 18:18:12 -0400 From: Dennis Ferguson > Dennis, I don't know what to say, except that I don't know anyone else > who thinks that traffic should be segregated by customer, and no transit > be allowed between providers. Your economics and mine don't match. Bill, I didn't say "should be" (i.e. a matter of opinion), I said "is" (i.e. a matter of fact). You are welcome to offer examples which do not exhibit this policy, I doubt you'll find many. The world is hardly ever what one would like it to be. The problem with the current routing technology and aggregation is that addresses for sites with dissimilar policy cannot be aggregated together anywhere which needs to distiguish those policies. The fact that most people (network operators, certainly, since this debate never occurs on mailing lists with a high proportion of network operators) think you can aggregate provider-based addresses to good effect, but can't aggregate geographically-assigned addresses at all, should give you a hint about what the most common determinant of routing policy is. > The current Internet routing policy expects a single backbone. This is > going away soon. The current Internet routing policy in no way expects a single backbone, since the current Internet is not constructed from a single backbone. I can assure you that even ANS' routers don't think the Internet is constructed from a single backbone. Future changes (I assume you mean changes to what the U.S. government funds, since changes to routing technology never occur "soon") may very well change who carries your traffic, but won't likely change the basic paradigm. > In my expectation, there will be multiple backbones, and every backbone > will carry all traffic presented to it. Policy is best expressed by the > user at the source, not by some provider. Go read NIMROD. :-< I wonder if you will actually like the Internet you expect. The current policy is what allows the Internet to operate commercially without traffic-based settlements, I would personally regret losing this property (though it may happen in any case). Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 13:11:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01507; Tue, 12 Apr 1994 10:47:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA18797; Tue, 12 Apr 1994 10:44:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA18783; Tue, 12 Apr 1994 10:30:21 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27809; Tue, 12 Apr 1994 08:45:48 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-06.dialip.mich.net (pm002-06.dialip.mich.net [35.1.48.87]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA27501 for ; Mon, 11 Apr 1994 18:45:42 -0400 Date: Mon, 11 Apr 94 22:30:45 GMT From: "William Allen Simpson" Message-Id: <2197.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: heirarchical addressing > Sorry, but I think that your regions must be bigger than my regions. I > just don't think a few thousand local routes is very many. I remember > Deering arguing that even a million local routes isn't too many. > > I guess I was assuming that a region would be like, a city or so. If so, > you're going to get a lot more than "a few thousand" local routes. With, say, > 5 million subscibers (individuals and business), it would be reasonable to > assume that after, say, 10 years, 25% would no longer be with their original > provider; i.e. 1.25 million subscribers which cannot be aggregated. That's a > *lot* of routes to carry around. > Aha, I guessed right! I can see it now -- the City of Michigan, the City of Minnesota and North and South Dakota, .... > Umm. Exactly how many subscribers do you forsee inside one of these > flat-addressed geographic regions, More like a telephone exchange, or even two or three. Using the wires we have now. It's kind of what we're stuck with, until we bypass the phone companies entirely. > and what's your prediction for the % that > will switch providers each year? > About 20% a year. But then, my three phones have three different default long-distance providers. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 14:16:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09532; Tue, 12 Apr 1994 14:16:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA18977; Tue, 12 Apr 1994 14:14:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA18974; Tue, 12 Apr 1994 14:11:09 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06804; Tue, 12 Apr 1994 13:17:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12727; Mon, 11 Apr 94 23:17:49 -0400 Date: Mon, 11 Apr 94 23:17:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404120317.AA12727@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Cc: jnc@ginger.lcs.mit.edu >> Sorry, but I think that your regions must be bigger than my regions. > I guess I was assuming that a region would be like, a city or so. I can see it now -- the City of Michigan, the City of Minnesota and North and South Dakota, .... I was thinking of larger metropoli, like Boston, New York, Washington, Chicago, Dallas, Houston, LA, SF, etc. Basically, an area code (although NY and LA have two now...). We have over a hundred area codes in the US alone. > Umm. Exactly how many subscribers do you forsee inside one of these > flat-addressed geographic regions, More like a telephone exchange, or even two or three. By "exchange", do you mean central office, or do you really mean exchange (as in the 3-digit prefix to the 4-digit line number)? Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 14:53:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11008; Tue, 12 Apr 1994 14:53:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA19038; Tue, 12 Apr 1994 14:51:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA19007; Tue, 12 Apr 1994 14:29:04 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10076; Tue, 12 Apr 1994 14:30:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13090; Tue, 12 Apr 94 00:29:48 -0400 Date: Tue, 12 Apr 94 00:29:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404120429.AA13090@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Cc: jnc@ginger.lcs.mit.edu > Steve may think that it's no big deal to route to a million separate, > distinct destinations, but see if *any* routing specialist will agree > with that.... Even a routing ignoramus like me would never propose such a thing. Sorry, my apologies, I was relying on a retelling of your position. I should have gone to the source. What I had proposed is that providers keep a database of all of their own customers within a metro area, containing a mapping from each customer prefix to the address(es) of the provider's own boundary router(s) where the customer is attached to the provider. ... Routing to intra-metro destinations by the provider's routers would be a two-step process: (1) look up a destination address in the database to learn the boundary router and (2) look up the boundary router in the routing table to determine the next hop. ... If an intra-metro destination address were not found in the provider's database, implying that the destination was not one of the provider's own customers, the packet would be routed towards the nearest MIX (Metropolitan Internet Exchange, where all of the provider's serving the same metro area interconnect) for hand-off to the appropriate provider. OK, let me see if I'm seeing the same picture as you. Each customer has an "address" prefix which doesn't tell you where the customer is; it's a topology independant name for the customer. (It's not an EID, since although it shares the topology independant attribute within the metro, it is a prefix that has as subsidiaries names for all the customer's machines. Let's call it a CID, then...) You have to map from the CID to something which *is* topology dependant, i.e. a locator for the exit router to the customer. This mapping is done via means of a large table, which contains entries (giving the locator of the exit router) for all the CID's attached to this provider. For entries which aren't in the table, they are attached to some other provider, and are sent off to some exchange point to other providers. This GIX would contain a table which maps from CID to provider, for every CID in the metro. I think this is it, right? I have a number of questions that I'm wondering about. Is this mapping from CID to router locator performed at each router, or only at the border routers where traffic enters the provider mesh, and the resulting locator stored in the packet? (I'm assuming a hop-by-hop forwarding model here...) How large do you expect this database to be, per entry, and what would be the maximum size you'd expect to see overall? Do you think that the model of a single GIX is going to be robust enough, or have enough bandwidth? If you have multiple GIXes, will all providers be attached to all of them? If so, do you assume that all the GIXes are about equivalent, and just route to the nearest one? How big do you think the GIX database will be, per entry, and what would be the maximum size you'd expect to see overall? Also, and this is somewhat less relevant, given that you have such a mapping, why not make it a more visible and explicit part of the forwarding architecture (instead of hidden inside the provider's network), to allow mobility over larger scopes than just a metro? Thus, I was not proposing that anyone run a conventional routing protocol over a flat space of millions of address prefixes, but rather just over the addresses of a provider's own routers. The technique of mapping from topologically independant names to topologically dependant ones is useful, yes. An important assumption was that response to changes of customer-prefix-to-boundary-router bindings need not be as dynamic as the response to topology changes that conventional routing protocols are designed to handle. Good point. What do you do about customers who have multiple connections (for robustness, in case of equipment/line failure) from their customer equipment to the provider mesh? This needs something more dynamic, no? What about people who have multiple connections to provide the required bandwidth; how do you interact with the routing to distribute resource reservations (assuming we decide we need them, I'm aware you're dubious of that) to the two different customer entry points? Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 16:01:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13440; Tue, 12 Apr 1994 16:01:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA19137; Tue, 12 Apr 1994 15:59:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA19121; Tue, 12 Apr 1994 15:53:22 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10521; Tue, 12 Apr 1994 14:41:57 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA22371 Tue, 12 Apr 1994 14:41:53 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id WAA09502; Mon, 11 Apr 1994 22:39:12 -0600 From: "Peter S. Ford" Message-Id: <199404120439.WAA09502@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: Dennis Ferguson Cc: bsimpson@morningstar.com, big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing In-Reply-To: Your message of Sun, 10 Apr 94 15:43:42 -0400. <199404101943.AA107979@foo.ans.net> Date: Mon, 11 Apr 94 22:39:11 MST Dennis's discussion hints at a critical element that facilitates geographical addressing/routing today in the phone system: REGULATION. In the US it is the regulation of the local loop on RBOCs, in other parts of the world it is an implicit regulation of the local loop via PTT activity. With the monopoly US RBOCs are granted goes particular responsibilties. It is a lot easier to route when you can point to a particular party and say: FIX IT. May I suggest if you want to pursue this discussion in greater detail you might want to spread spectrum into com-priv. You might also want to work on generic provider selection APIs for DNS as well as IPv4 and IPNG. cheers, peter ( +1 0 288 505 665 0058) From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 16:07:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10944; Tue, 12 Apr 1994 14:51:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA19021; Tue, 12 Apr 1994 14:49:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA18993; Tue, 12 Apr 1994 14:21:07 +1000 Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09806; Tue, 12 Apr 1994 14:22:22 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id WAA09299; Mon, 11 Apr 1994 22:18:29 -0600 From: "Peter S. Ford" Message-Id: <199404120418.WAA09299@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU Subject: Re: IPng should support binary IPv4 mode API out-of-the-box In-Reply-To: Your message of Sat, 09 Apr 94 01:18:52 -0400. <9404090518.AA10522@xirtlu.zk3.dec.com> Date: Mon, 11 Apr 94 22:18:25 MST Jim, I would think the API issues for supporting old ISV applications could be the same, independent of the instantiation of IPng. As you might guess, I don't agree with you that the transition plans are very distinguishable at the API. I suspect all proposals have some real cruft, especially if they allow for any host mapping of IPv4 to IPng. I also believe that any host implementing IPng will also implement IPv4, minimally with dual stack (same API as before), plus other transition strategies (encaps, transcapulation, tunnels, etc.) Perhaps this should be dealt with in an API wg, instead of draining more from the individual working groups. If not a working group, perhaps an issue to be dealt with by the TACIT group? If we pull together on many of these things (FTP, APIs, transition plans, security, etc.) into IPng neutral plans/designs/projects, then we can help the Internet software implementors build better systems while the final haggling about packet formats and M&A activities comes to closure. Yours for a name based, opaquely typed, Internet, peter From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 16:33:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12234; Tue, 12 Apr 1994 15:26:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA19079; Tue, 12 Apr 1994 15:24:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA19076; Tue, 12 Apr 1994 15:22:22 +1000 Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08496; Tue, 12 Apr 1994 13:53:11 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id VAA09046; Mon, 11 Apr 1994 21:52:56 -0600 From: "Peter S. Ford" Message-Id: <199404120352.VAA09046@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: Simon Poole Cc: big-internet@munnari.OZ.AU Subject: Re: IPng & Provider-oriented addressing In-Reply-To: Your message of Sat, 09 Apr 94 01:05:46 +0200. <199404082307.BAA19452@chsun.eunet.ch> Date: Mon, 11 Apr 94 21:52:55 MST >>> * why don't we deploying a modified ftp protocol that uses (DNS) names >>> instead of addresses in the port command now? This would seem to be >>> a good thing regardless of whatever turns up for IPng. Simon, This is an excellent idea. There is a spec for a new FTP (Foobar) by Dave Piscitello which the tuba folks have implemented to get FTP to work over CLNP. One can easily define a new type for the PORT and PASV commands that would use names instead of network layer addresses within Foobar. One should also consider the issues Steve Bellovin has brought up with the use of FTP through firewalls in any new FTP software release. There are several other things we have similarly learned which need to be folded into new software releases for IP/TCP products. Topics like kerberos, rpc, etc. come to mind. Perhaps we need an IPv4++ working group established in the IPng directorate? Getting what we now know could be done better with IPv4 into common practice with IPv4 will certainly pay off as we develop new Internet software (IPng). cheers, peter From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 17:11:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16317; Tue, 12 Apr 1994 17:11:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA19223; Tue, 12 Apr 1994 17:09:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA19205; Tue, 12 Apr 1994 16:51:05 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15586; Tue, 12 Apr 1994 16:52:19 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22661; Tue, 12 Apr 1994 08:52:13 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA14690; Tue, 12 Apr 1994 08:52:12 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404120652.AA14690@dxcoms.cern.ch> Subject: Re: heirarchical addressing To: big-internet@munnari.OZ.AU Date: Tue, 12 Apr 1994 08:52:12 +0200 (MET DST) In-Reply-To: <9404111442.AA06004@ginger.lcs.mit.edu> from "Noel Chiappa" at Apr 11, 94 10:42:12 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1132 Definitely right. I want to say "packets from a physics department host at MIT must enter CERN via Provider #1, and packets from other hosts at MIT must enter CERN via Provider #2." This is not fictitious. This is exactly and precisely the policy requirement of my management today. The reason is that different funding agencies pay for our connection to the two providers. Money talks. Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 >--------- Text sent by Noel Chiappa follows: > > Policy is best expressed by the user at the source, not by some provider. > Go read NIMROD. > > Funny you should mention this, I was just thinking about this this morning! I > think there are applications for "destination" policies, e.g. 800 numbers, > where the destination is paying the charges, and wishes to say something about > what the path to it looks like. How exactly to handle things like this (the > worst case being where each end want sot have some influence on the path, so > it cannot be set wholly by one entity) is something of an open issue... > > Noel > From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 18:27:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15036; Tue, 12 Apr 1994 16:37:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA19178; Tue, 12 Apr 1994 16:34:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA19164; Tue, 12 Apr 1994 16:11:05 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12560; Tue, 12 Apr 1994 15:36:37 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA29854; Mon, 11 Apr 94 22:32:10 -0700 Received: by xirtlu.zk3.dec.com; id AA12331; Tue, 12 Apr 1994 01:32:09 -0400 Message-Id: <9404120532.AA12331@xirtlu.zk3.dec.com> To: "Peter S. Ford" Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: IPng should support binary IPv4 mode API out-of-the-box In-Reply-To: Your message of "Mon, 11 Apr 94 22:18:25 MST." <199404120418.WAA09299@goshawk.lanl.gov> Date: Tue, 12 Apr 94 01:32:02 -0400 X-Mts: smtp Peter,, >I would think the API issues for supporting old ISV applications >could be the same, independent of the instantiation of IPng. I agree. >As you might guess, I don't agree with you that the transition plans >are very distinguishable at the API. I suspect all proposals have some >real cruft, especially if they allow for any host mapping of >IPv4 to IPng. I also believe that any host implementing IPng will >also implement IPv4, minimally with dual stack (same API as before), plus >other transition strategies (encaps, transcapulation, tunnels, etc.) >Perhaps this should be dealt with in an API wg, instead of draining >more from the individual working groups. If not a working >group, perhaps an issue to be dealt with by the TACIT group? It could all be the same and not be distinguishable. I just think some may be harder than others to do. TACIT is a real good idea. >If we pull together on many of these things (FTP, APIs, transition >plans, security, etc.) into IPng neutral plans/designs/projects, then >we can help the Internet software implementors build better systems >while the final haggling about packet formats and M&A activities comes >to closure. This would be ideal. >Yours for a name based, opaquely typed, Internet, Good motto. Gee I just agreed with 99% of what you said. take care, /jim From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 18:56:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20073; Tue, 12 Apr 1994 18:56:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA19326; Tue, 12 Apr 1994 18:54:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA19323; Tue, 12 Apr 1994 18:47:44 +1000 Received: from [192.5.216.174] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19956; Tue, 12 Apr 1994 18:48:54 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 12 Apr 1994 17:44:40 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id RAA14626; Tue, 12 Apr 1994 17:44:40 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA23019; Tue, 12 Apr 94 17:44:40 JST Date: Tue, 12 Apr 94 17:44:40 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404120844.AA23019@cactus.slab.ntt.jp> To: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing > > Definitely right. I want to say "packets from a physics department > host at MIT must enter CERN via Provider #1, and packets from other > hosts at MIT must enter CERN via Provider #2." This is not fictitious. > This is exactly and precisely the policy requirement of my management > today. The reason is that different funding agencies pay for our > connection to the two providers. Money talks. > SIPP does this using a combination of provider-rooted addressing and the source-route mechanism thingy. The CERN host can even con the MIT host into sending the right header to make this happen just by feeding it the reverse of that in the packets it sends to the MIT host. Even if the MIT host is a "dumb" host, it will turn the source route around and send the packet to CERN via the right provider. The bit we haven't worked out is how to get the CERN host to know the cluster address for its providers automatically..... PF From owner-Big-Internet@munnari.OZ.AU Tue Apr 12 21:16:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24447; Tue, 12 Apr 1994 21:16:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA19567; Tue, 12 Apr 1994 21:14:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA19564; Tue, 12 Apr 1994 21:10:46 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24125; Tue, 12 Apr 1994 21:03:39 +1000 (from Z.Wang@cs.ucl.ac.uk) Message-Id: <9404121103.24125@munnari.oz.au> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Apr 1994 11:52:15 +0100 To: big-internet@munnari.OZ.AU In-Reply-To: Your message of "Mon, 11 Apr 94 13:15:16 PDT." <199404112015.NAA24962@lager.cisco.com> Date: Tue, 12 Apr 94 11:52:15 +0100 From: Zheng Wang > You are right, but in general, distance-vector routing does not > have info to detect loops with more than two nodes. I received a few private messages pointing out that distance-vector routing are look-free with J.J. Garcia's algorithm. I think I didn't explain clearly in my previous message. While it is true that new distance-vector algorithms are loop-free, this does not change the fact that a node with distance-vector info (i.e. dest, next-hop, distance) can not work out by itself if there is a loop in the path thus the need for tagging the packets ... Cheers Zheng From owner-Big-Internet@munnari.OZ.AU Wed Apr 13 00:54:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27248; Tue, 12 Apr 1994 23:01:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA19667; Tue, 12 Apr 1994 22:59:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA19642; Tue, 12 Apr 1994 22:32:15 +1000 Received: from enh.nist.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26484; Tue, 12 Apr 1994 22:33:29 +1000 (from glenn@osi.ncsl.nist.gov) Received: from osi.ncsl.nist.gov by ENH.NIST.GOV (PMDF V4.2-13 #4653) id <01HB2XPFCTV4003NI7@ENH.NIST.GOV>; Tue, 12 Apr 1994 08:32:20 EDT Received: from sloth.ncsl.nist.gov.noname by osi.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA01433; Tue, 12 Apr 94 08:34:12 EDT Date: Tue, 12 Apr 1994 08:34:12 -0400 (EDT) From: glenn@osi.ncsl.nist.gov (Robert Glenn) Subject: Re: IPng and security To: big-Internet@munnari.OZ.AU Cc: ipsec@ans.net, tuba@lanl.gov, glenn@osi.ncsl.nist.gov Message-Id: <9404121234.AA01433@osi.ncsl.nist.gov> Content-Transfer-Encoding: 7BIT There has been some recent discussion suggesting that the TUBA WG has taken a passive view on IPng security concerns. For example, at the SAAG meeting it was initially assumed that TUBA was going to use ISO NLSP to provide security services. As pointed out in "TUBA as IPng: A White Paper", we've been actively participating in the IPSEC WG to contribute to the development of an IPv4 security protocol that would/could also be used to provide the same security services for CLNP, figuring that a common security protocol could only benefit the transition from IPv4 to IPng. Due to the approaching July "decision point" and the lack of closure in the IPSEC WG, I've drafted a security protocol for TUBA based on the requirements and work that has already been accomplished by IPSEC. The initial premise used to devise this protocol was to keep it as simple as possible and only address those security concerns that, 1) could be effectively addressed by a network layer security protocol, and 2) provided protection for the areas that require security the most. By following this approach, a secure encapsulation protocol for CLNP and IPv4 to provide confidentiality and integrity has been drafted. As soon as the draft is finished it will be posted as an I-D. From owner-Big-Internet@munnari.OZ.AU Wed Apr 13 02:33:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05166; Wed, 13 Apr 1994 02:33:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19939; Wed, 13 Apr 1994 02:32:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19897; Wed, 13 Apr 1994 02:09:48 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04374; Wed, 13 Apr 1994 02:11:05 +1000 (from Z.Wang@cs.ucl.ac.uk) Message-Id: <9404121611.4374@munnari.oz.au> Received: from reeves.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Apr 1994 17:10:32 +0100 To: Jose Garcia-Luna Cc: big-internet@munnari.OZ.AU In-Reply-To: Your message of "Tue, 12 Apr 94 08:33:41 PDT." <9404121533.AA10944@pj> Date: Tue, 12 Apr 94 17:10:33 +0100 From: Zheng Wang >There are a number of distance-vector algorithms (IEEE/ACM Trans on >Networking, Vol 1, No. 1, pp. 130-141, 1993) that provide loop-free >routes at very instant for each known destination using only "dest, >next-hop, distance" information to operate. First, let me repeat that I compeletly agree with you that the distance routing algorithms proposed by you provide loop-free route any any instant. >Each router cannot work out the problem by itslef, you are right. >Routers collaborate with one another using the algorithms. > >I don't see the need to tag packets...I must be missing something. >Would you care to elaborate? I was replying to Lyman's message about Paul's first scenario on the flow-id buy. In Paul's first scenario, B, C and D are only one-hop away so B should be able to detect that the change in C-D will form a loop between Flow-based forwarding and destination-based forwarding. But in a more general case where B is more than one hop away, B will not be able to do that with the distance-vector info. I think the key point is that each router cannot work out the problem itself but routers must collaborate. Tagging is one way of doing that (i.e. detecting loop between flowId-based forwarding and dest-based forwarding). I am sure there are other ways too. Cheers Zheng From owner-Big-Internet@munnari.OZ.AU Wed Apr 13 02:46:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03849; Wed, 13 Apr 1994 01:56:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA19845; Wed, 13 Apr 1994 01:54:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19801; Wed, 13 Apr 1994 01:33:17 +1000 Received: from pj.cse.ucsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03019; Wed, 13 Apr 1994 01:34:34 +1000 (from jj@cse.ucsc.edu) Received: by pj id AA10944 (5.65/IDA-1.4.4); Tue, 12 Apr 1994 08:33:42 -0700 Message-Id: <9404121533.AA10944@pj> To: Zheng Wang Cc: big-internet@munnari.OZ.AU In-Reply-To: Your message of "Tue, 12 Apr 1994 11:52:15 BST." <9404121103.24125@munnari.oz.au> Date: Tue, 12 Apr 1994 08:33:41 -0700 From: Jose Garcia-Luna Zheng: I don't understand your statements: " distance-vector routing does not have info to detect loops with more than two nodes." and "While it is true that new distance-vector algorithms are loop-free, this does not change the fact that a node with distance-vector info (i.e. dest, next-hop, distance) can not work out by itself if there is a loop in the path thus the need for tagging the packets ..." If I read your statements correctly, you are wrong. There are a number of distance-vector algorithms (IEEE/ACM Trans on Networking, Vol 1, No. 1, pp. 130-141, 1993) that provide loop-free routes at very instant for each known destination using only "dest, next-hop, distance" information to operate. The algorithms are such that, for each destination, the next-hop entries in the routing tables of all routers always define an acyclic graph (which is a tree when the network is connected and in steady state). Each router cannot work out the problem by itslef, you are right. Routers collaborate with one another using the algorithms. I don't see the need to tag packets...I must be missing something. Would you care to elaborate? Thanks, JJ From owner-Big-Internet@munnari.OZ.AU Wed Apr 13 03:15:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05112; Wed, 13 Apr 1994 02:31:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19924; Wed, 13 Apr 1994 02:29:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19894; Wed, 13 Apr 1994 02:06:36 +1000 Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00999; Wed, 13 Apr 1994 00:33:33 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HB2ZTOM4MO009DL0@FNAL.FNAL.GOV>; Tue, 12 Apr 1994 09:33:02 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA13483; Tue, 12 Apr 94 09:32:20 CDT Date: Tue, 12 Apr 1994 09:32:20 -0500 From: Matt Crawford Subject: Re: heirarchical addressing In-Reply-To: Your message of Tue, 12 Apr 94 08:52:12 +0100. <9404120652.AA14690@dxcoms.cern.ch> To: big-internet@munnari.OZ.AU Cc: Brian.Carpenter@cern.ch Message-Id: <9404121432.AA13483@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Definitely right. I want to say "packets from a physics department host at MIT must enter CERN via Provider #1, and packets from other hosts at MIT must enter CERN via Provider #2." This is not fictitious. At Fermilab, we have the same story with respect to Yale. One way for the physics department, another way for anyone else. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Wed Apr 13 03:31:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06503; Wed, 13 Apr 1994 03:06:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA19987; Wed, 13 Apr 1994 03:04:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19971; Wed, 13 Apr 1994 02:52:56 +1000 Received: from swix.nvg.unit.no by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06086; Wed, 13 Apr 1994 02:54:12 +1000 (from agulbra@nvg.unit.no) Received: from 129.241.163.240 by swix.nvg.unit.no with smtp (Smail3.1.28.1 #18) id for ; Tue, 12 Apr 94 18:53 +0200 Received: by trondviggo.nvg.unit.no (smallmail 0.9.9); Tue, 12 Apr 1994 18:53:58 +0200 Date: Tue, 12 Apr 1994 18:53:58 +0200 Message-Id: <29559.8467.766169638@trondviggo.nvg.unit.no> From: Arnt Gulbrandsen To: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing In-Reply-To: <9404120844.AA23019@cactus.slab.ntt.jp> Organization: Nettverksgruppa - UNIT In article <9404120844.AA23019@cactus.slab.ntt.jp> you write: >> >> Definitely right. I want to say "packets from a physics department >> host at MIT must enter CERN via Provider #1, and packets from other >> hosts at MIT must enter CERN via Provider #2." This is not fictitious. >> This is exactly and precisely the policy requirement of my management >> today. The reason is that different funding agencies pay for our >> connection to the two providers. Money talks. > >SIPP does this using a combination of provider-rooted addressing and >the source-route mechanism thingy. The CERN host can even con the MIT >host into sending the right header to make this happen just by feeding >it the reverse of that in the packets it sends to the MIT host. Well, what if MIT had three providers and required that packets from CERN enter it via a certain provider depending on what department at CERN is sending the packet? Can you outline how the correct path would be found? --Arnt From owner-Big-Internet@munnari.OZ.AU Wed Apr 13 03:32:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06539; Wed, 13 Apr 1994 03:08:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA20002; Wed, 13 Apr 1994 03:06:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19966; Wed, 13 Apr 1994 02:41:05 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02609; Wed, 13 Apr 1994 01:19:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16053; Tue, 12 Apr 94 11:19:15 -0400 Date: Tue, 12 Apr 94 11:19:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404121519.AA16053@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Cc: jnc@ginger.lcs.mit.edu > I want to say "packets from a physics department host at MIT must enter > CERN via Provider #1, and packets from other hosts at MIT must enter CERN > via Provider #2." SIPP does this using a combination of provider-rooted addressing and the source-route mechanism thingy. I didn't quite see the relevance of the provider-addressing; shouldn't the trick below still work if you use geographic addressing (at the CERN end)? The CERN host can even con the MIT host into sending the right header to make this happen just by feeding it the reverse of that in the packets it sends to the MIT host. Even if the MIT host is a "dumb" host, it will turn the source route around and send the packet to CERN via the right provider. Does this still work if the connection was initiated from the MIT end? I.e., will it switch to using the source route in the packets it receives, if it started the connection without one? (Needless to say, if so, there's a giant security hole there unless there's authentication which prevents people from hijacking open connections with this technique...) The bit we haven't worked out is how to get the CERN host to know the cluster address for its providers automatically..... It's worse than that. It has to know which hosts at MIT should use provider #1, and which should use provider #2. Summed over all the sites which talk to CERN, this is a pretty big database. This is really a perfect application for source-based policy routing. Trying to make hop-by-hop routing do this kind of thing is like trying to teach an elephant to skip rope. You want a mechanism on which the knobs aren't totally orthogonal to what you're trying to accomplish (as so many of our existing policy knobs are). What you really want is to be able to directly tag CERN's two provider links as "for type A traffic" and "for type B traffic"; if the applications trying to reach CERN know whether they are type A, or type B, it's pretty trivial from there, and you are working with absolute minimum of configured policy information Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 13 11:49:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19630; Wed, 13 Apr 1994 10:06:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA20351; Wed, 13 Apr 1994 10:04:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA20348; Wed, 13 Apr 1994 09:58:24 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19488; Wed, 13 Apr 1994 09:59:34 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Wed, 13 Apr 1994 08:59:02 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA07206; Wed, 13 Apr 1994 08:59:02 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA26547; Wed, 13 Apr 94 08:59:01 JST Date: Wed, 13 Apr 94 08:59:01 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404122359.AA26547@cactus.slab.ntt.jp> To: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: heirarchical addressing > > > I want to say "packets from a physics department host at MIT must enter > > CERN via Provider #1, and packets from other hosts at MIT must enter CERN > > via Provider #2." > > SIPP does this using a combination of provider-rooted addressing and > the source-route mechanism thingy. > > I didn't quite see the relevance of the provider-addressing; shouldn't the > trick below still work if you use geographic addressing (at the CERN end)? The relevance is simply that you have to have something in the packet that tells the routers to route it through the desired provider. If you have geographic addresses, then you add something to the packet to indicate the provider. If you have provider-rooted addresses, then you have to choose the right address. I don't see to two choices very different in terms of what the hosts and private networks have to configure to make it work. However, geographic addresses put more burden on providers (required connectivity and routing tables), so I feel we may as well use the provider-rooted addresses and leverage them for provider-selection at the same time. Also, if you are going to to provider-selection, then the routers in the infrastructure must keep provider routes in any event. Why burden them (and hosts) with both geographic and provider information? Why not just use provider information? Well, the answer of course is that some subscriber networks don't need provider selection and so geographic addresses are easy for them to deal with. So I guess there is a place for both.... > > The CERN host can even con the MIT host into sending the right header to > make this happen just by feeding it the reverse of that in the packets it > sends to the MIT host. Even if the MIT host is a "dumb" host, it will turn > the source route around and send the packet to CERN via the right provider. > > Does this still work if the connection was initiated from the MIT end? I.e., > will it switch to using the source route in the packets it receives, if it > started the connection without one? (Needless to say, if so, there's a giant > security hole there unless there's authentication which prevents people from > hijacking open connections with this technique...) Well, I was speaking in a connectionless sense. But you are absolutely right about the security problem, though that problem is workable I think.... > > The bit we haven't worked out is how to get the CERN host to know the > cluster address for its providers automatically..... > > It's worse than that. It has to know which hosts at MIT should use provider #1, > and which should use provider #2. Summed over all the sites which talk to CERN, > this is a pretty big database. This is orthogonal to what I said above. I'm just talking about SIPP packet mechanism to get the right thing to happen. How the hosts on either end know how to set the mechanism is a difficult problem no matter what the mechanism is. Source routing doesn't make it any easier. In any event, if CERN really wants to distinguish between all the sites that talk to it, then it must pay the price of a large database... > > This is really a perfect application for source-based policy routing. Trying It is also a perfect application for connection-less provider-selection ala SIPP. > to make hop-by-hop routing do this kind of thing is like trying to teach an > elephant to skip rope. You want a mechanism on which the knobs aren't totally The way SIPP does it, it is basically source-based policy routing, on top of an otherwise hop-by-hop routing infrastructure. That's the whole point of leveraging SIPP's source route mechanism--because source routing is powerful for some thing, as you have so often (and seemingly tirelessly :-) pointed out. > orthogonal to what you're trying to accomplish (as so many of our existing > policy knobs are). What you really want is to be able to directly tag CERN's > two provider links as "for type A traffic" and "for type B traffic"; if the > applications trying to reach CERN know whether they are type A, or type B, > it's pretty trivial from there, and you are working with absolute minimum > of configured policy information > I agree that this would be good *if* you can really come up with such universally agreed upon classifications (which I'm real doubtful about). Even if you do, though, you *could* use this approach with the SIPP header mechanism. The Pip road architecture spec discussed one way to do it (leveraged DNS.....) I'm sorry but I don't want to take the time to type it out now..... PF From owner-Big-Internet@munnari.OZ.AU Wed Apr 13 12:28:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23454; Wed, 13 Apr 1994 11:51:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA20452; Wed, 13 Apr 1994 11:49:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA20448; Wed, 13 Apr 1994 11:45:30 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19828; Wed, 13 Apr 1994 10:10:36 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Wed, 13 Apr 1994 09:09:45 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA07375; Wed, 13 Apr 1994 09:09:45 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA26634; Wed, 13 Apr 94 09:09:45 JST Date: Wed, 13 Apr 94 09:09:45 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404130009.AA26634@cactus.slab.ntt.jp> To: agulbra@nvg.unit.no, big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing > >> > >> Definitely right. I want to say "packets from a physics department > >> host at MIT must enter CERN via Provider #1, and packets from other > >> hosts at MIT must enter CERN via Provider #2." This is not fictitious. > >> This is exactly and precisely the policy requirement of my management > >> today. The reason is that different funding agencies pay for our > >> connection to the two providers. Money talks. > > > >SIPP does this using a combination of provider-rooted addressing and > >the source-route mechanism thingy. The CERN host can even con the MIT > >host into sending the right header to make this happen just by feeding > >it the reverse of that in the packets it sends to the MIT host. > > Well, what if MIT had three providers and required that packets from > CERN enter it via a certain provider depending on what department at > CERN is sending the packet? Can you outline how the correct path > would be found? > In this case, it would require 1) that the varous departments at CERN could be distinguished by address prefix (possible to arrange, but not a given), and 2) that the MIT host know the mapping between CERN prefixes and providers. Assuming that the MIT host initiates the connection, it gets back a number of prefixes for the CERN host (based on the CERN host's multiple providers), looks in its database and decides which of its own providers it wants to use, chooses among its own provider-rooted addresses to match that provider. When the CERN host returns packets to the MIT host, then they will naturally go through the chosen provider. If the CERN host initiates the exchange, it may initially choose an address for the MIT host that causes the packet to go through a different provider than the one the MIT host wants. Thus, the MIT host must insert a cluster address for the provider it wants in the source route back to the CERN host on return packets, which in turn get reflected by the CERN host and thus enter MIT at the right provider. Of course, it is not all quite so simple as this, as some details on configuration of routing information for MIT in MIT's providers depend on whether MIT is using extended addresses or simple addresses (SIPP terminology.....it's in the SIPP road spec), and it would all be cleaner if the two hosts could agree in advance about which providers they want to use, but such protocol does not (yet?) exist. I know this is all very confusing. The main point I want to make is that SIPP provides a header format and address assignment scheme that supports provider selection, using connectionless packets, and with traditional hop-by-hop routing in the infrastructure. How the host's know to format the packet is another matter, which hasn't and doesn't have to be completely worked out now. PF From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 00:23:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18107; Wed, 13 Apr 1994 22:22:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA20958; Wed, 13 Apr 1994 22:19:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA20955; Wed, 13 Apr 1994 22:16:05 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17899; Wed, 13 Apr 1994 22:17:21 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA08147; Wed, 13 Apr 94 07:17:53 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad14405; 13 Apr 94 12:09 GMT Date: Wed, 13 Apr 94 07:11 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Turnipp - a merger proposal Message-Id: <40940413121104/0003858921NA3EM@mcimail.com> >>Routing is done with ES-IS, Integrated ISIS (extended for arbitrary >>levels) and IDRP. >and what about nimrod ? >Let me answer your question with another question. What is wrong with >Tony's list: ES-IS, ISIS and IDRP plus with some form of source >routing (e.g. SDRP, GRE) to deal with specialized routing requirements ? Please educate me. Why is OSPF not in this list? Bob From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 05:21:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03936; Thu, 14 Apr 1994 05:21:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA21357; Thu, 14 Apr 1994 05:19:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA21354; Thu, 14 Apr 1994 05:11:04 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02278; Thu, 14 Apr 1994 04:30:42 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA15762; Wed, 13 Apr 1994 11:28:18 -0700 Date: Wed, 13 Apr 1994 11:28:18 -0700 From: Tony Li Message-Id: <199404131828.LAA15762@lager.cisco.com> To: 0003858921@mcimail.com ("Robert G. Moskowitz") Cc: Subject: Re: Turnipp - a merger proposal [ALERT, ALERT, HERESY ALERT. This message contains opinions which are contrary to the established norm of IETF thought and IP bigotry. Don't bother flaming.] >>Routing is done with ES-IS, Integrated ISIS (extended for arbitrary >>levels) and IDRP. >and what about nimrod ? >Let me answer your question with another question. What is wrong with >Tony's list: ES-IS, ISIS and IDRP plus with some form of source >routing (e.g. SDRP, GRE) to deal with specialized routing requirements ? Please educate me. Why is OSPF not in this list? OSPF is redundant. It's very clear that the future of the Internet is multiprotocol (and I inlcude IPX, AT (in isolated clouds) and CLNP). We need to provide an integrated routing protocol to support this. Given that the two protocols are almost functionally equivalent, and that ISIS requires far fewer fixes necessary moving forward, I think that there's little point in fixing OSPF too. Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 08:18:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10421; Thu, 14 Apr 1994 08:18:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA21552; Thu, 14 Apr 1994 08:17:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA21523; Thu, 14 Apr 1994 08:05:45 +1000 Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10035; Thu, 14 Apr 1994 08:07:01 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA23998); Wed, 13 Apr 94 17:06:51 CDT Received: by sabine.is.rice.edu (AA14657); Wed, 13 Apr 94 17:05:08 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9404132205.AA14657@sabine.is.rice.edu> Subject: Re: Turnipp - a merger proposal To: tli@cisco.com (Tony Li) Date: Wed, 13 Apr 94 17:05:07 CDT Cc: 0003858921@mcimail.com, big-internet@munnari.OZ.AU In-Reply-To: <199404131828.LAA15762@lager.cisco.com>; from "Tony Li" at Apr 13, 94 11:28 am X-Mailer: ELM [version 2.3 PL11] Soo much for reading mail in reverse. Nice opinion. Is this intended to generate constructive debate or are you cold? (see note sent to BSimpson a few minutes back) -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 08:19:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09153; Thu, 14 Apr 1994 07:41:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA21480; Thu, 14 Apr 1994 07:39:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA21455; Thu, 14 Apr 1994 07:06:39 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07284; Thu, 14 Apr 1994 06:45:48 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm012-04.dialip.mich.net (pm012-04.dialip.mich.net [35.1.48.205]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA12719 for ; Wed, 13 Apr 1994 16:45:38 -0400 Date: Wed, 13 Apr 94 20:29:46 GMT From: "William Allen Simpson" Message-Id: <2212.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Future IGPs It's very clear that the future of the Internet is migrating toward a single Internet Protocol, both politically (the expressed desires of the NIST, ISoc, and other bodies), and practically (the merger of NetWare over IP, the Apple TI2 API). CLNP has never done better than SIN, and is therefore on its way to extinction. We need a good IGP that handles all of the needs of IP, including multicast, and it is pretty clear that OSPF is the best solution. Also, OSPF doesn't require link-layer specific addresses, and is more general and managable -- and easier to read and implement. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 09:24:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10357; Thu, 14 Apr 1994 08:16:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA21537; Thu, 14 Apr 1994 08:14:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA21518; Thu, 14 Apr 1994 07:55:24 +1000 Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09678; Thu, 14 Apr 1994 07:56:41 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA23176); Wed, 13 Apr 94 16:56:28 CDT Received: by sabine.is.rice.edu (AA14550); Wed, 13 Apr 94 16:54:45 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9404132154.AA14550@sabine.is.rice.edu> Subject: Re: Future IGPs To: bsimpson@morningstar.com Date: Wed, 13 Apr 94 16:54:45 CDT Cc: big-internet@munnari.OZ.AU In-Reply-To: <2212.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Apr 13, 94 8:29 pm X-Mailer: ELM [version 2.3 PL11] Thank you for your opinion. Is this remark intended to engender discussion and debate or are you cold? -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 09:42:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11434; Thu, 14 Apr 1994 08:51:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA21597; Thu, 14 Apr 1994 08:49:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA21568; Thu, 14 Apr 1994 08:24:45 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10681; Thu, 14 Apr 1994 08:25:44 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA19357; Wed, 13 Apr 94 15:19:18 -0700 Received: by xirtlu.zk3.dec.com; id AA24846; Wed, 13 Apr 1994 18:19:16 -0400 Message-Id: <9404132219.AA24846@xirtlu.zk3.dec.com> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Wed, 13 Apr 94 20:29:46 GMT." <2212.bill.simpson@um.cc.umich.edu> Date: Wed, 13 Apr 94 18:19:10 -0400 X-Mts: smtp I tend to agree with Bill Simpson that the Internet will migrate to one protoocol. In fact I don't know of anyone who has asked me for a firewall for anything but IPv4? So I think saying that the Internet is multiprotocol is premature, right now its IPv4. If IPng is done right it will IPng transitioning from IPv4. But at many of our customers they have at least 5 protocols running in house. But the three they often route with are OSI, TCP/IP, and SNA across their backbone networks. Others are tunneled in TCP/IP often for end to end functionality. Also the only protocol that seems to have the lead right now for Multicast is OSPF. Hence I think discounting it is premature. Some say Beta was better than VHS. But VHS won. Same could be with the routing protocols. /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 10:37:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15676; Thu, 14 Apr 1994 10:37:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA21736; Thu, 14 Apr 1994 10:34:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA21702; Thu, 14 Apr 1994 10:10:32 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB14502; Thu, 14 Apr 1994 10:10:49 +1000 (from yakov@watson.ibm.com) Message-Id: <9404140010.14502@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6163; Wed, 13 Apr 94 20:10:24 EDT Date: Wed, 13 Apr 94 19:54:46 EDT To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU Subject: Future IGPs Ref: Your note of Wed, 13 Apr 94 18:19:10 -0400 Jim, >I tend to agree with Bill Simpson that the Internet will migrate >to one protocol... Let me just mentioned that some of the issues related to this topic are discussed in RFC1560. Below is a fragment from this RFC that would probably help the discussion: "The issue of multiprotocol Internet is multidimensional and should be analyzed with respect to two simultaneous principles: - It is desirable to have a single protocol stack. The community should try to avoid unconstrained proliferation of various protocol stacks. - In reality there will always be more than one protocol stack. Presence of multiple network layers is just one of the corollaries of this observation, as even within a single protocol stack, forces of evolution of that stack will lead to periods of multiple protocols. We need to develop mechanisms that maximize the services that can be provided across all the protocol stacks (multiprotocol Internet)." Yakov Rekhter From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 12:19:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14270; Thu, 14 Apr 1994 10:04:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA21677; Thu, 14 Apr 1994 09:59:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA21663; Thu, 14 Apr 1994 09:49:16 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12079; Thu, 14 Apr 1994 09:06:45 +1000 (from jmh@anubis.network.com) Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA13823; Wed, 13 Apr 94 18:10:07 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA07765; Wed, 13 Apr 94 18:06:22 CDT Date: Wed, 13 Apr 94 18:06:22 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9404132306.AA07765@anubis.network.com> To: bound@zk3.dec.com Subject: Re: Future IGPs Cc: big-internet@munnari.OZ.AU Jim comments that no customers have asked him for Firewalls for anything but IPv4. And further says that he thinks that the observation that we are moving to a single-protocol internet is accurate. 1) We have, repeatedly, been asked for firewalls for other protocols than IPv4. 2) If anything, the frequency with which customers want to "internetwork" non-IP protocols is increasing, not decreasing. I have trouble imagining any time in the future when it will not be the case that many customers have many network layer protocols. And I expect them to want to communicate with remote parties (eg over the internet) using these protocols. [There are those who declare: well, we will tunnel it all inside IP/IPng. That is clearly an insufficient answer. There are many topological/reachability/addressing issues besides just the packet format ones.] I would not go so far as to say that this conditions our selection of routing protocols inherently. But it should always be taken into account. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 12:22:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14749; Thu, 14 Apr 1994 10:16:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA21709; Thu, 14 Apr 1994 10:13:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA21649; Thu, 14 Apr 1994 09:34:03 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11119; Thu, 14 Apr 1994 08:39:09 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA06030; Wed, 13 Apr 1994 15:38:53 -0700 Message-Id: <199404132238.PAA06030@Mordor.Stanford.EDU> To: bmanning@is.rice.edu (William Manning) Cc: tli@cisco.com (Tony Li), 0003858921@mcimail.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 13 Apr 94 17:05:07 -0500. <9404132205.AA14657@sabine.is.rice.edu> Date: Wed, 13 Apr 94 15:38:53 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: Nice opinion. Is this intended to generate constructive debate I used to be quite sure that the future of the Internet included multiple internet-layer protocols. Time has reduced the certitude. But I'm not sure there is any way to pursue this issue. There are several factors: 1. What is the "right" outcome? 2. What is the outcome that is happening? 3. What degree of effect can we have on this? #1 is, of course, a matter of religion and, like most religious debates, means that everyone is completely correct. Not much chance of progress down THAT line. #2 tries to look at anything constituting empirical data, doing something one might call a 'trend' analysis and predict where the world is going. For the internet layer, my own subjective sense is that there really IS a trend and it is to fewer, not more, protocols, with a reasonable chance of converging on one, if we don't screw things up. Not much chance of progress on THIS line of debate either, since I don't have hard data and suspect no one else does either. But at least there is a way to pursue it, for those with the fortitude. #3 reflects my own opinion that this level of strategic debate has a lousy history of accomplishing anything productive in the IETF forum. d/ From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 12:25:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16048; Thu, 14 Apr 1994 10:47:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA21764; Thu, 14 Apr 1994 10:45:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA21685; Thu, 14 Apr 1994 10:06:09 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14311; Thu, 14 Apr 1994 10:06:19 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA11972; Wed, 13 Apr 1994 16:54:19 -0700 Date: Wed, 13 Apr 1994 16:54:19 -0700 From: Tony Li Message-Id: <199404132354.QAA11972@lager.cisco.com> To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU Subject: Re: Future IGPs Jim, So I think saying that the Internet is multiprotocol is premature, right now its IPv4. I beg to differ. In fact you make the point for me: But at many of our customers they have at least 5 protocols running in house. But the three they often route with are OSI, TCP/IP, and SNA across their backbone networks. Others are tunneled in TCP/IP often for end to end functionality. Our customers are similar to yours and express a very high preference for the simplicity in management of their IGP. They would very much like to have an integrated IGP. Also the only protocol that seems to have the lead right now for Multicast is OSPF. Hence I think discounting it is premature. As the current trend in multicasting is away from MOSPF and mrouted to PIM, I would not consider this to be a major difficulty. Some say Beta was better than VHS. But VHS won. Same could be with the routing protocols. Good example. VHS won because the end units were cheaper. The difference in quality was invisible to Joe Budweiser. Which IGP is Joe Budweiser more likely to use, given that Joe is using those 5 protocols already? Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 13:32:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22736; Thu, 14 Apr 1994 13:32:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA21991; Thu, 14 Apr 1994 13:31:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA21957; Thu, 14 Apr 1994 13:10:18 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18075; Thu, 14 Apr 1994 11:46:40 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA18382; Wed, 13 Apr 1994 18:41:48 -0700 Date: Wed, 13 Apr 1994 18:41:48 -0700 From: Tony Li Message-Id: <199404140141.SAA18382@lager.cisco.com> To: Bob.Hinden@Eng.Sun.COM Cc: big-internet@munnari.OZ.AU In-Reply-To: Bob Hinden's message of Wed, 13 Apr 1994 18:26:31 -0700 <9404140126.AA16556@jurassic.Eng.Sun.COM> Subject: Turnipp - a merger proposal Bob, There is lots of redundancy in the world. Some people think this can be a feature. I think that the redundancy of IGP's in the Internet has been a good thing. It provides choices for users. For example RIP provides a very low entry routing protocol. It doesn't scale too well for large environments but for small to moderate sized networks it has proven itself to be just fine. Also, some router vendors have even been know to have their own proprietary routing protocols. I don't see anything wrong with this. I think the choice of routing protocols we have provided has helped the internet to grow. I think it would be mistake to say that only one IGP should run with IPng. That's neither what I intended nor what I said. Currently IPv4 has one "MUST IMPLEMENT" IGP. That is currently OSPF. I think you might know more about this than I do. From IPv4 router requirements: A router which implements any routing protocol (other than static routes) MUST IMPLEMENT OSPF (see Section [7.2.2]) and MUST IMPLEMENT RIP (see Section [7.2.4]). A router MAY implement additional IGPs. Others are certainly permitted. Good grief, do you think I've forgotten where I work? ;-) For Turnipp, the "MUST IMPLEMENT" IGP is ISIS. That's all there is to it. I also think that it is easier to extend our current infrastructure to support new functionality (like extending RIP or OSPF to support IPng addresses, and how BGP was extended to support CIDR) than to deploy something altogether new. I think that for sites currently running OSPF/RIP/etc it will be much easier to deploy a new version of these protocols which support IPng than it will be to change routing protocols. Likewise it would be easier for sites currently running ISIS to use this for IPng than to switch to OSPF. A fine point. However, for some values of IPng (Turnipp in particular), RIP and OSPF are clearly NOT extensible in a backwards-compatible way. And given that you're already changing the basic building block of the world, the link level routing protocol, and the interdomain routing protocol, I have a very hard time buying that there's a strong need to minimize the amount of work for the IGP. Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 13:34:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22771; Thu, 14 Apr 1994 13:34:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA22008; Thu, 14 Apr 1994 13:32:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA21960; Thu, 14 Apr 1994 13:20:04 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18851; Thu, 14 Apr 1994 12:06:19 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA28642; Wed, 13 Apr 94 18:55:37 -0700 Received: by xirtlu.zk3.dec.com; id AA02925; Wed, 13 Apr 1994 21:55:33 -0400 Message-Id: <9404140155.AA02925@xirtlu.zk3.dec.com> To: jmh@anubis.network.com (Joel Halpern) Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Wed, 13 Apr 94 18:06:22 CDT." <9404132306.AA07765@anubis.network.com> Date: Wed, 13 Apr 94 21:55:27 -0400 X-Mts: smtp Joel, A bit of clarification. >Jim comments that no customers have asked him for Firewalls for anything >but IPv4. For access to the Internet. They mostly want the services of ftp (to get files), telnet (more restricted but to access remote hosts as a user), and then mail. I am not aware of any other network layer protocol that does this for ftp, telnet, or smtp. Now if folks start using a protocol in a big way across the Internet backbones (which I am not aware they do but would be interested in hearing about where the use warrants > $10 million in business for a vendor) to use such services then I and others will begin to hear requests for firewalls other than for IPv4 on the Internet. My issue is that people throw the word multiprotocol around in an invalid context. I am talking about using the Internet today for research, standards development, and the new services being offered on the Internet. What IETF member could communicate with this list or get the files etc without IPv4? Or better how would any other protocol help them do their job in this community on the Internet? Do the hosts offering this service support ftp et al for a network layer other than IPv4. Yes, almost all fortune 100 companies I know of do have > 5 protocols and may route them as IGPs within their corporate domain. This is a different set of requirements than building a protocol for the Internet and I get a bit annoyed when people confuse the two. It would be wonderful if the goals were the same but they are not today. Plus the wealth of 'network' applications that run over the TCP/IP suite use IPv4. I don't see this wealth of applications for the multivendor heterogeneous environment in any other suite. >And further says that he thinks that the observation that we >are moving to a single-protocol internet is accurate. Yep I think so. Or are we now to port all the applications to each stack. Noble idea but very costly. I have not seen this cost justified as in the $12 billion TCP/IP market. When I do as an individual I will jump up and take notice so far I do not. >1) We have, repeatedly, been asked for firewalls for other protocols than > IPv4. To access the services from the Internet like Mosaic for example. Most all the services assume IPv4? So what protocol are you speaking of? >2) If anything, the frequency with which customers want to "internetwork" > non-IP protocols is increasing, not decreasing. I have trouble > imagining any time in the future when it will not be the case that > many customers have many network layer protocols. And I expect them > to want to communicate with remote parties (eg over the internet) > using these protocols. > [There are those who declare: well, we will tunnel it all inside > IP/IPng. That is clearly an insufficient answer. There are many > topological/reachability/addressing issues besides just the > packet format ones.] This is what I was getting at regarding the confusion of this dimension. Of course customers want to internetwork many protocols. Now if they want to communicate over the Internet with them too then that needs attention. I also agree that tunneling should not be the only answer to the future. But for awhile it will have to be. But what we don't want to do IMHO is reduce the network layer to the leaset common denominator becuase of the work 'multiprotocol' used in an invalid context. >I would not go so far as to say that this conditions our selection of >routing protocols inherently. But it should always be taken into account. True. But often I hear the phrase mutliprotocol used as hand waving instead of good technical analysis of a problem. This I find to be bad for the Internets health and effects negatively our efforts in some cases in the IETF to make TCP/IP the suite better and greater for the Information Super Highway. What other protocol suite even has a remote chance of doing. None. TCP/IP is an infrastructure and huge market that has proven it will spend money. And the body that defines those standards and in this case actual implements them have proven themselves too. Oh and the stuff works in a 'multivendor' OPEN environment and has proof of concept too. /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 14:02:58 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21318; Thu, 14 Apr 1994 12:59:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06244 Thu, 14 Apr 1994 12:58:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21886; Thu, 14 Apr 1994 12:54:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21866; Thu, 14 Apr 1994 12:38:25 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17632; Thu, 14 Apr 1994 11:32:01 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14473(1)>; Wed, 13 Apr 1994 18:31:10 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 13 Apr 1994 18:31:18 -0700 To: Tony Li Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Future IGPs In-Reply-To: tli's message of Wed, 13 Apr 94 16:54:19 -0800. <199404132354.QAA11972@lager.cisco.com> Date: Wed, 13 Apr 1994 18:31:16 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Apr13.183118pdt.12171@skylark.parc.xerox.com> > As the current trend in multicasting is away from MOSPF and mrouted to > PIM, ... That's a heck of a leap, Tony. Wishing it were so does not make it so. Steve From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 14:03:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21348; Thu, 14 Apr 1994 13:00:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21930; Thu, 14 Apr 1994 12:58:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21883; Thu, 14 Apr 1994 12:54:10 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18151; Thu, 14 Apr 1994 11:47:34 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA18579; Wed, 13 Apr 1994 18:45:34 -0700 Date: Wed, 13 Apr 1994 18:45:34 -0700 From: Tony Li Message-Id: <199404140145.SAA18579@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Wed, 13 Apr 1994 18:31:16 PDT <94Apr13.183118pdt.12171@skylark.parc.xerox.com> Subject: Future IGPs > As the current trend in multicasting is away from MOSPF and mrouted to > PIM, ... That's a heck of a leap, Tony. Wishing it were so does not make it so. And from one of the supposed author's of the PIM protocol spec no less... Are you saying that you wish it were otherwise? How much MOSPF and mrouted is there deployed in the world? What is the first derivative on these deployments? How do these compare to PIM deployment even now while PIM isn't even out of field test? I stand by my statement. Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 14:03:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21321; Thu, 14 Apr 1994 12:59:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21915; Thu, 14 Apr 1994 12:57:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21869; Thu, 14 Apr 1994 12:38:46 +1000 Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17658; Thu, 14 Apr 1994 11:33:04 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id TAA03127; Wed, 13 Apr 1994 19:28:08 -0600 From: "Peter S. Ford" Message-Id: <199404140128.TAA03127@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: Tony Li Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of Wed, 13 Apr 94 16:54:19 -0700. <199404132354.QAA11972@lager.cisco.com> Date: Wed, 13 Apr 94 19:28:08 MST >>> Which IGP is Joe Budweiser more likely to use, given that Joe >>> is using those 5 protocols already? IGRP? Or is this a trick question? It seems to me that if OSPF is to be used for IPng then it would be worth the effort of making it "generic". I know many sites that would be more enthusiastic about OSPF if it solved the remaining 80% (other 4 protocols) of their problems. This is not to say that IS-IS could not stand a change or two. peter From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 14:05:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22715; Thu, 14 Apr 1994 13:31:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA21976; Thu, 14 Apr 1994 13:29:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21902; Thu, 14 Apr 1994 12:55:26 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17514; Thu, 14 Apr 1994 11:26:56 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA07646; Wed, 13 Apr 94 18:26:39 PDT Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1/SMI-4.1) id AA23270; Wed, 13 Apr 94 18:25:47 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA16556; Wed, 13 Apr 1994 18:26:31 -0700 Date: Wed, 13 Apr 1994 18:26:31 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404140126.AA16556@jurassic.Eng.Sun.COM> To: Tony Li Cc: big-internet@munnari.OZ.AU In-Reply-To: <199404131828.LAA15762@lager.cisco.com> Subject: Re: Turnipp - a merger proposal Tony, > OSPF is redundant. It's very clear that the future of the Internet is > multiprotocol (and I inlcude IPX, AT (in isolated clouds) and CLNP). > We need to provide an integrated routing protocol to support this. > Given that the two protocols are almost functionally equivalent, and > that ISIS requires far fewer fixes necessary moving forward, I think > that there's little point in fixing OSPF too. There is lots of redundancy in the world. Some people think this can be a feature. I think that the redundancy of IGP's in the Internet has been a good thing. It provides choices for users. For example RIP provides a very low entry routing protocol. It doesn't scale too well for large environments but for small to moderate sized networks it has proven itself to be just fine. Also, some router vendors have even been know to have their own proprietary routing protocols. I don't see anything wrong with this. I think the choice of routing protocols we have provided has helped the internet to grow. I think it would be mistake to say that only one IGP should run with IPng. I also think that it is easier to extend our current infrastructure to support new functionality (like extending RIP or OSPF to support IPng addresses, and how BGP was extended to support CIDR) than to deploy something altogether new. I think that for sites currently running OSPF/RIP/etc it will be much easier to deploy a new version of these protocols which support IPng than it will be to change routing protocols. Likewise it would be easier for sites currently running ISIS to use this for IPng than to switch to OSPF. Bob From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 16:13:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25732; Thu, 14 Apr 1994 14:41:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA22089; Thu, 14 Apr 1994 14:40:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA22080; Thu, 14 Apr 1994 14:28:57 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25300; Thu, 14 Apr 1994 14:30:16 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09931 Thu, 14 Apr 1994 14:30:07 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id WAA04337; Wed, 13 Apr 1994 22:23:27 -0600 From: "Peter S. Ford" Message-Id: <199404140423.WAA04337@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: bound@zk3.dec.com Cc: jmh@anubis.network.com (Joel Halpern), big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of Wed, 13 Apr 94 21:55:27 -0400. <9404140155.AA02925@xirtlu.zk3.dec.com> Date: Wed, 13 Apr 94 22:23:23 MST Jim, Most of us share your enthusiasm for IP. But there are very large install bases of software other than IP and they should not be ignored in the IPng process. We should try to make IPng the desirable underlying protocol for them to implement their services on top of. I do not believe customers blindly procure protocols, I think they buy services to meet their needs. If they can run on top of IP, that would be just as nice as them running on top of SNA, IPX, etc. One way to facilitate their "transition" to IPng is to develop routing systems/frameworks that facilitate coexistence in the near term. Similarly, name spaces might accommodate coexistence and point to subsequent paths towards coalescence. Co-opt vrs conquer? There are advantages. peter From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 16:14:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25900; Thu, 14 Apr 1994 14:43:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA22115; Thu, 14 Apr 1994 14:42:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA22086; Thu, 14 Apr 1994 14:38:39 +1000 Received: from brazos.is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25686; Thu, 14 Apr 1994 14:39:45 +1000 (from bmanning@is.rice.edu) Received: by brazos.is.rice.edu (AA15437); Wed, 13 Apr 94 23:39:37 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9404140439.AA15437@brazos.is.rice.edu> Subject: Re: Turnipp - a merger proposal To: tli@cisco.com (Tony Li) Date: Wed, 13 Apr 1994 23:39:36 -0500 (CDT) Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: <199404140141.SAA18382@lager.cisco.com> from "Tony Li" at Apr 13, 94 06:41:48 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 914 > That's neither what I intended nor what I said. Currently IPv4 has > one "MUST IMPLEMENT" IGP. That is currently OSPF. I think you might > know more about this than I do. From IPv4 router requirements: > > A router which implements any routing protocol (other > than static routes) MUST IMPLEMENT OSPF (see Section > [7.2.2]) and MUST IMPLEMENT RIP (see Section [7.2.4]). > A router MAY implement additional IGPs. > > Others are certainly permitted. Good grief, do you think I've > forgotten where I work? ;-) > > For Turnipp, the "MUST IMPLEMENT" IGP is ISIS. That's all there is to > it. > MUST IMPLEMENT - based on the fact the OSPF is a full standard. ISIS (& by extention IISIS) has never progressed that far. Tough to say that ISIS is MUST IMPLEMENT while not yet blessed as a full standard. Perhaps its time to progress ISIS within IESG?? -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 16:14:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25938; Thu, 14 Apr 1994 14:44:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA22130; Thu, 14 Apr 1994 14:43:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA22066; Thu, 14 Apr 1994 14:20:45 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25095; Thu, 14 Apr 1994 14:21:49 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA04007; Wed, 13 Apr 94 21:19:38 -0700 Received: by xirtlu.zk3.dec.com; id AA18928; Thu, 14 Apr 1994 00:19:36 -0400 Message-Id: <9404140419.AA18928@xirtlu.zk3.dec.com> To: Tony Li Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Wed, 13 Apr 94 18:41:48 PDT." <199404140141.SAA18382@lager.cisco.com> Date: Thu, 14 Apr 94 00:19:30 -0400 X-Mts: smtp Tony, >For Turnipp, the "MUST IMPLEMENT" IGP is ISIS. That's all there is to >it. Hmmm. So are you saying there is now a fourth IPng proposal? If so then we need some specs. Or is this just an idea to assist with a merger? Basically whats the objective here with TURNIP if anything more than an idea to generate an idea to make one of the existing IPng proposals work. If its a merger idea then adding it to each proposals text should be the objective. We have momentum and I think good work on IPng now with some points of contention, but they have done the work to build a complete proposal (some more complete than others). Also is that IS-IS as is today or IS-IS after the IETF makes it more supportive of the TCP/IP environment and address the needs of TCP/IP existing practice too. Do you believe the IETF should have complete change control over IS-IS? Has some one spec'd out PIM for IS-IS? Multicast is a requirement for IPng in anyones set of to-do for IPng. /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 16:16:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25972; Thu, 14 Apr 1994 14:45:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA22145; Thu, 14 Apr 1994 14:44:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA22083; Thu, 14 Apr 1994 14:34:21 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25587; Thu, 14 Apr 1994 14:35:39 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA00436; Wed, 13 Apr 1994 21:31:19 -0700 Date: Wed, 13 Apr 1994 21:31:19 -0700 From: Tony Li Message-Id: <199404140431.VAA00436@lager.cisco.com> To: bound@zk3.dec.com Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: bound@zk3.dec.com's message of Thu, 14 Apr 94 00:19:30 -0400 <9404140419.AA18928@xirtlu.zk3.dec.com> Subject: Turnipp - a merger proposal >For Turnipp, the "MUST IMPLEMENT" IGP is ISIS. That's all there is to >it. Hmmm. So are you saying there is now a fourth IPng proposal? If so then we need some specs. Or is this just an idea to assist with a merger? It's a proposal for a merger. ;-) Basically whats the objective here with TURNIP if anything more than an idea to generate an idea to make one of the existing IPng proposals work. If its a merger idea then adding it to each proposals text should be the objective. We have momentum and I think good work on IPng now with some points of contention, but they have done the work to build a complete proposal (some more complete than others). My goal is to achieve a merger between the proposals. My objective is to get the the proponents of the proposals thinking, talking and working towards a merger. Also is that IS-IS as is today or IS-IS after the IETF makes it more supportive of the TCP/IP environment and address the needs of TCP/IP existing practice too. Yes, as they are one and the same. Do you believe the IETF should have complete change control over IS-IS? "should" is irrelevant. The IETF _will_ have complete and effective change control over it. I know people don't believe this, but from what I can tell, the ISO folks are simply imploding. Here's a piece that we could pick up. If the liason would go through, I bet we'd get their blessing. Has some one spec'd out PIM for IS-IS? Multicast is a requirement for IPng in anyones set of to-do for IPng. No one needs to spec out PIM for ISIS. Or for any other IGP. PIM is Protocol Independent Multicasting. It works with OSPF, RIP and IGRP too. PIM for IPng pretty falls out the day that we decide what IPng looks like (or at least what IPng addresses look like). Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 16:26:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29756; Thu, 14 Apr 1994 16:26:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA22271; Thu, 14 Apr 1994 16:25:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA22249; Thu, 14 Apr 1994 16:09:09 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25985; Thu, 14 Apr 1994 14:46:40 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA04909; Wed, 13 Apr 94 21:42:25 -0700 Received: by xirtlu.zk3.dec.com; id AB20996; Thu, 14 Apr 1994 00:42:23 -0400 Message-Id: <9404140442.AB20996@xirtlu.zk3.dec.com> To: Tony Li Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Wed, 13 Apr 94 21:07:56 PDT." <199404140407.VAA29162@lager.cisco.com> Date: Thu, 14 Apr 94 00:42:17 -0400 X-Mts: smtp Tony, >I would suggest that the Internet exists because it solves user >(customer) problems. If IPng does not solve real user problems, then >there is NO point in doing it. If fixing user problems means ripping >out the current Internet by the roots, well, let's do it. This is why >the Internet exists the way it does today and why we're not on some >giant X.25 cloud passing 80 byte card images around. This is very true and important for all of us to capture. But if we are going to do an extraction instead of a root canal (sorry just had a tooth pulled today) to save it then lets do it. But we are going to need a very intense transition plan for such an effort. The customers who don't care about the Internet will not be able to jump as quick as this could be designed and deployed. Dual Stack will not be enough. There will have to be compatibility stages to be very generic in my meaning right now. Good point about IS-IS being extensible it is very much so. In fact from a host perspective (which is not my only perspective) I want to be able to go to servers for my services and addresses if I choose so. I want any IGP to not prevent a host from being able to act as a router for IGP. I want hosts to work on a network without any router present. ....more later.... thanks /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 16:27:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29779; Thu, 14 Apr 1994 16:27:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA22297; Thu, 14 Apr 1994 16:26:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA22263; Thu, 14 Apr 1994 16:12:15 +1000 Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26332; Thu, 14 Apr 1994 14:54:20 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by large.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA15987; Wed, 13 Apr 1994 21:53:56 -0700 Date: Wed, 13 Apr 1994 21:53:56 -0700 From: Dave Katz Message-Id: <199404140453.VAA15987@large.cisco.com> To: bmanning@is.rice.edu Cc: tli@cisco.com, Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: William Manning's message of Wed, 13 Apr 1994 23:39:36 -0500 (CDT) <9404140439.AA15437@brazos.is.rice.edu> Subject: Turnipp - a merger proposal ISIS is in the process of progressing--Chris Gunner has prepared the appropriate documents. From: bmanning@is.rice.edu (William Manning) Date: Wed, 13 Apr 1994 23:39:36 -0500 (CDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 914 > That's neither what I intended nor what I said. Currently IPv4 has > one "MUST IMPLEMENT" IGP. That is currently OSPF. I think you might > know more about this than I do. From IPv4 router requirements: > > A router which implements any routing protocol (other > than static routes) MUST IMPLEMENT OSPF (see Section > [7.2.2]) and MUST IMPLEMENT RIP (see Section [7.2.4]). > A router MAY implement additional IGPs. > > Others are certainly permitted. Good grief, do you think I've > forgotten where I work? ;-) > > For Turnipp, the "MUST IMPLEMENT" IGP is ISIS. That's all there is to > it. > MUST IMPLEMENT - based on the fact the OSPF is a full standard. ISIS (& by extention IISIS) has never progressed that far. Tough to say that ISIS is MUST IMPLEMENT while not yet blessed as a full standard. Perhaps its time to progress ISIS within IESG?? -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 16:28:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29819; Thu, 14 Apr 1994 16:28:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA22312; Thu, 14 Apr 1994 16:27:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA22266; Thu, 14 Apr 1994 16:13:18 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24644; Thu, 14 Apr 1994 14:11:57 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA29162; Wed, 13 Apr 1994 21:07:56 -0700 Date: Wed, 13 Apr 1994 21:07:56 -0700 From: Tony Li Message-Id: <199404140407.VAA29162@lager.cisco.com> To: bound@zk3.dec.com Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU In-Reply-To: bound@zk3.dec.com's message of Wed, 13 Apr 94 23:12:01 -0400 <9404140312.AA11058@xirtlu.zk3.dec.com> Subject: Future IGPs Jim, My point is one of focus. What I focus on in the IETF is TCP/IP and its suite. When I go work on products I solve customers problems with networking. What your stating is a valid customer problem. But the Internet is a focus and the question is should we combine the two focuses in the IETF? I would suggest that the Internet exists because it solves user (customer) problems. If IPng does not solve real user problems, then there is NO point in doing it. If fixing user problems means ripping out the current Internet by the roots, well, let's do it. This is why the Internet exists the way it does today and why we're not on some giant X.25 cloud passing 80 byte card images around. Making TCP/IP better technically with IPng or adding value to the existing suite does solve some customer problems, but is it the focus of the Internet? Should we combine them? They are not now in my mind in CHARTER in this standards body. If we want to change the CHARTER then I and many will play any game that we want to play. Well, you might as well make it part of the charter. Again, IPng without more of a carrot is not worth the effort. Good point. One thing I have been thinking about ON MY OWN NOT AFFILIATED WITH ANY GROUP IN THE IETF OR WHERE I WORK. Is why shouldn't any IPng for example selected not want to work with IS-IS or OSPF or RIPv2. Want to? All would want to. However, not all may be technically tractable or reasonable to do. Certainly implementing RIP with 20-byte NSAPs is about as appealing as carrying around an elephant with a little red wagon. Each have different strengths and good points as routing protocols and indirectly as function selectors to solve different problems. I believe IDRP has figured out how to do this right? But a real integrated routing protocol that would handle Joe Budweiser's 5 protocols would be great. But if we take the time to do that can we do it independently of IPng? You don't have to take the time to go build in all five protocols. You only have to figure out how to use IPng with the existing routing protocol. The changes to ISIS are _exactly_ _analogous_ and _as_ _non-challenging_ as the changes to IDRP. Even if we have until 2008 before running out of IPv4 addresses I still think we need to move on IPng. Mom, Apple pie and Honda. ;-) No arguments here. So can IPng be selected and then later adapt an integrated routing protocol? Why later? It is quicker to steal from your neighbor and define the integrated hooks than it is to even start to fix OSPF. It's real clear that folks not directly involved in routing protocols haven't looked to see what's necessary. Well, the basics are simple: integrated routing protocols such as IDRP, ISIS, and EIGRP carry around routing information encoded in such a way that it is extensible and can be shared by multiple protocols. Thus, for IDRP, we can carry around a GOSIP format NSAP and a SIPP address with impunity. The packet itself carries sufficient context to determine the address family. The computation of the optimal route is an algorithm that is address family independent. So, for example, adding IPng support to IDRP consists of defining one new attribute and saying "well, addresses of type 57 will be IPng addresses". That's IT. Done. Fixing OSPF involves ripping it up, fixing all of the four byte assumptions and changing packets all over the place. Oh, and by the way, when you're done, deployed routers won't recognize IPng packet formats so you have to roll the version number or something and then you have divided OSPF systems. Ok, I'm sure some clever person can kludge up something, but hey, why bother? The technology already exists. Let's stand on each other's shoulders instead of trampling each other's toes. If an integrated network layer effort on routers and hosts for applications would move forward the 1st paragraph above then we could absorb the evolution reality suggested in the second paragraph. True. And that would be fine. But as with IPng deployment, there's always transition. Just as IPng transition would never work with a flag day, there's no hope of instantly converting all other hosts to the One True Way. Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 16:30:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29845; Thu, 14 Apr 1994 16:30:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA22327; Thu, 14 Apr 1994 16:28:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA22246; Thu, 14 Apr 1994 16:07:38 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22207; Thu, 14 Apr 1994 13:19:00 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA01445; Wed, 13 Apr 94 20:12:09 -0700 Received: by xirtlu.zk3.dec.com; id AA11058; Wed, 13 Apr 1994 23:12:07 -0400 Message-Id: <9404140312.AA11058@xirtlu.zk3.dec.com> To: Tony Li Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Wed, 13 Apr 94 16:54:19 PDT." <199404132354.QAA11972@lager.cisco.com> Date: Wed, 13 Apr 94 23:12:01 -0400 X-Mts: smtp Tony, Well I don't think this will go anywhere but I hope so. I am not saying there is not a need by the market for multiprotocol routers and that hosts should not support this at the server end minimally. >>So I think saying that the Internet is >>multiprotocol is premature, right now its IPv4. >I beg to differ. In fact you make the point for me: >>But at many of our customers they have at least 5 protocols running in >>house. But the three they often route with are OSI, TCP/IP, and SNA across >>their backbone networks. Others are tunneled in TCP/IP often for end to >>end functionality. >Our customers are similar to yours and express a very high preference >for the simplicity in management of their IGP. They would very much >like to have an integrated IGP. Yes I agree with you. But if we want to solve this problem and keep the TCP/IP Internet going then we need a new compass reading of the problem we are trying to solve for IPng and the routing groups. I believe greatly in an integrated network layer and for hosts too. In fact one the excellent features of CATNIP is that Rob has figured out how to do this for the transport on hosts. Do we want to make OSPF better (and I agree with Peter that we should make OSPF better where it is perceived to need enhancements) or take OSPF and IS-IS and make a new routing protocol. My point is one of focus. What I focus on in the IETF is TCP/IP and its suite. When I go work on products I solve customers problems with networking. What your stating is a valid customer problem. But the Internet is a focus and the question is should we combine the two focuses in the IETF? Making TCP/IP better technically with IPng or adding value to the existing suite does solve some customer problems, but is it the focus of the Internet? Should we combine them? They are not now in my mind in CHARTER in this standards body. If we want to change the CHARTER then I and many will play any game that we want to play. If you had a chance to read my host IPng paper I kept using the word integrated network layer for the host. This is how I see it because it really is greater than two stacks in reality in the customer market (you could say hyrbrid stacks I guess). >> Also the only protocol that seems to have the lead right now for >> Multicast is OSPF. Hence I think discounting it is premature. >As the current trend in multicasting is away from MOSPF and mrouted to >PIM, I would not consider this to be a major difficulty. Good point. PIM is a good idea philosophically. I have figured out how to support multiple stacks at the transport with a common set of interfaces as an example. What I ran into are shims. Not that they are bad but they are dangerous to performance on a host if not implemented correctly (of course thats true with all things). >>Some say Beta was better than VHS. But VHS won. Same could be with the >>routing protocols. >Good example. VHS won because the end units were cheaper. The >difference in quality was invisible to Joe Budweiser. Which IGP is >Joe Budweiser more likely to use, given that Joe is using those 5 >protocols already? Good point. One thing I have been thinking about ON MY OWN NOT AFFILIATED WITH ANY GROUP IN THE IETF OR WHERE I WORK. Is why shouldn't any IPng for example selected not want to work with IS-IS or OSPF or RIPv2. Each have different strengths and good points as routing protocols and indirectly as function selectors to solve different problems. I believe IDRP has figured out how to do this right? But a real integrated routing protocol that would handle Joe Budweiser's 5 protocols would be great. But if we take the time to do that can we do it independently of IPng? Even if we have until 2008 before running out of IPv4 addresses I still think we need to move on IPng. So can IPng be selected and then later adapt an integrated routing protocol? As I said in the beginning I am here to make the Internet work and also to avoid breaking things for existing TCP/IP customers (which is a very lucrative customer to have). But if we want to reshuffle the focus I assume we need the IETF hiearchy to re-set some of the bits for direction or would this be a shift right and then left illogical? I also think Yakov's msg encapsulating the text in RFC 1560 is quite important to remember too: ================================================================= "The issue of multiprotocol Internet is multidimensional and should be analyzed with respect to two simultaneous principles: - It is desirable to have a single protocol stack. The community should try to avoid unconstrained proliferation of various protocol stacks. - In reality there will always be more than one protocol stack. Presence of multiple network layers is just one of the corollaries of this observation, as even within a single protocol stack, forces of evolution of that stack will lead to periods of multiple protocols. We need to develop mechanisms that maximize the services that can be provided across all the protocol stacks (multiprotocol Internet)." ================================================================ If an integrated network layer effort on routers and hosts for applications would move forward the 1st paragraph above then we could absorb the evolution reality suggested in the second paragraph. I think we agree on where it needs to go. I guess I am a stickler on what is the charter of what I am focusing on and was my point to Joel. I don't want to work on stuff in the blind I like it all on the table. The bottom line is what I am saying is that I do not perceive the IETFs goal is to solve the multiprotocol problems discussed here. I think that would be a wonderful goal and welcomed by the market, but I believe that would require a shift operation in the project plan so to speak. Anyone who believes TCP/IP is the only suite in the market is clueless. Good prompting of my brain, /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 17:16:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28448; Thu, 14 Apr 1994 15:51:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA22219; Thu, 14 Apr 1994 15:50:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA22201; Thu, 14 Apr 1994 15:33:30 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21294; Thu, 14 Apr 1994 12:58:44 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: from necom830.cc.titech.ac.jp by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06065 Thu, 14 Apr 1994 12:52:18 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 14 Apr 94 11:41:22 +0900 From: Masataka Ohta Message-Id: <9404140241.AA06981@necom830.cc.titech.ac.jp> Subject: Re: Turnipp - a merger proposal To: tli@cisco.com (Tony Li) Date: Thu, 14 Apr 94 11:41:20 JST Cc: 0003858921@mcimail.com, big-internet@munnari.OZ.AU In-Reply-To: <199404131828.LAA15762@lager.cisco.com>; from "Tony Li" at Apr 13, 94 11:28 am X-Mailer: ELM [version 2.3 PL11] > OSPF is redundant. It's very clear that the future of the Internet is > multiprotocol (and I inlcude IPX, AT (in isolated clouds) and CLNP). It seems to me that Turnipp is just another catnip and is redundant. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 17:36:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02768; Thu, 14 Apr 1994 17:36:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA22419; Thu, 14 Apr 1994 17:35:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA22416; Thu, 14 Apr 1994 17:31:30 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02623; Thu, 14 Apr 1994 17:32:45 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA27859; Thu, 14 Apr 1994 09:36:56 +0200 Message-Id: <199404140736.AA27859@mitsou.inria.fr> To: Tony Li Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Wed, 13 Apr 1994 16:54:19 PDT." <199404132354.QAA11972@lager.cisco.com> Date: Thu, 14 Apr 1994 09:36:55 +0200 From: Christian Huitema => Our customers are similar to yours and express a very high preference => for the simplicity in management of their IGP. They would very much => like to have an integrated IGP. Tony, I remember asking a question on the interest of multi-protocol routing to M. George Powers, from Novell, during a session on "multi-protocol backbones" at last Interop in SF. Is answer was that he was essentially not interested in "multi-protocol routing" for one very good reason: different protocols have different routing requirements thus integrated routing is mostly a compromise which is only useful "when the customer's requirements meet the compromise's assumption". In short, he much prefered SIN. This was not challenged by the other speakers. There were two other very clear outputs of the whole session, which also featured Joel Bion of cisco and Keith Nelson of the US bank. Firstly, multiple protocols imply multiple managements, which is painful. Big users are busy cutting out the losers to concentrate on a small set of winners - typically IP and IPX, plus SNA "for legacy". The demand for AT and DECNET was mentioned, as well as the unanimous need to eliminate NETBIOS. And the four letters C-L-N-P where not pronounced even once during the whole session - in fact, were not printed either in the special edition of computer week that was distributed during the show. This tells a lot about the status of the market... The second very clear agreement was that the problem of multiprotocol backbone was not so much routing (SIN works OK) than resource management, e.g. the interaction of a fixed windows transport (IPX), a friendly and polite congestion avoider (TCP) and a very sensitive set of applications (SNA transactional applications expects almost constant delays). Now *that* is interesting. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 18:46:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05694; Thu, 14 Apr 1994 18:46:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA22500; Thu, 14 Apr 1994 18:45:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA22486; Thu, 14 Apr 1994 18:28:37 +1000 Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28892; Thu, 14 Apr 1994 16:02:51 +1000 (from dino@cisco.com) Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA09020; Wed, 13 Apr 1994 22:57:07 -0700 Date: Wed, 13 Apr 1994 22:57:07 -0700 From: Dino Farinacci Message-Id: <199404140557.WAA09020@feta.cisco.com> To: bound@zk3.dec.com Cc: tli@cisco.com, Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: bound@zk3.dec.com's message of Thu, 14 Apr 94 00:19:30 -0400 <9404140419.AA18928@xirtlu.zk3.dec.com> Subject: Turnipp - a merger proposal >> Also is that IS-IS as is today or IS-IS after the IETF makes it more >> supportive of the TCP/IP environment and address the needs of TCP/IP >> existing practice too. There is nothing more that needs to be added to integrated IS-IS to make if supportive for TCP/IPv4. It's just another routing protocol. Why is everyone making such a big deal? >> Has some one spec'd out PIM for IS-IS? Multicast is a requirement for >> IPng in anyones set of to-do for IPng. PIM runs over any unicast routing protocol even static routing if that is what you choose to run. Dino From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 18:48:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05836; Thu, 14 Apr 1994 18:48:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA22515; Thu, 14 Apr 1994 18:47:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA22472; Thu, 14 Apr 1994 18:22:43 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28069; Thu, 14 Apr 1994 15:43:07 +1000 (from ses@tipper.oit.unc.edu) Received: from hillary.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA03306; Thu, 14 Apr 94 01:42:24 EDT Date: Fri, 15 Apr 94 01:40:06 -0500 From: Simon Spero To: big-internet@munnari.OZ.AU Subject: Size of IPNG candidate address fields? Message-Id: In-Reply-To: Your message <199404140423.WAA04337@goshawk.lanl.gov> of Wed, 13 Apr 94 22:23:23 MST Content-Type: TEXT/plain; charset=US-ASCII Can anyone tell me the size constrains for addresses in the various candidate IPNGs? For example, IPV4 has addresses with a minimum and maximum size of 32 bits, and SIPP has a minimum size of 64bits. When I say address, I'm referring to the value that would be returned when resolving a name in a directory service (which just happens to be what I want to do). I'm defining the structure for referrals in SID (the Simple Internet Directory), and because it uses some of the really nifty stuff in the Packed Encoding Rules, I can get some big wins if I known any upper and lower bounds for address sizes. Simon // SID - the flexibility of whois++, the power of X.500, half the overhead of DNS p.s. Yes, the client side is codenamed Nancy. From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 18:49:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05864; Thu, 14 Apr 1994 18:49:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA22530; Thu, 14 Apr 1994 18:48:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA22469; Thu, 14 Apr 1994 18:19:00 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27319; Thu, 14 Apr 1994 15:25:51 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA06449; Wed, 13 Apr 94 22:22:31 -0700 Received: by xirtlu.zk3.dec.com; id AA25161; Thu, 14 Apr 1994 01:22:15 -0400 Message-Id: <9404140522.AA25161@xirtlu.zk3.dec.com> To: tli@cisco.com Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Wed, 13 Apr 94 21:31:19 PDT." <199404140431.VAA00436@lager.cisco.com> Date: Thu, 14 Apr 94 01:22:09 -0400 X-Mts: smtp For sure if IPng IGP (and the exterior routing protocol) can support IPX, DECnet, CLNP, SNA, and others I have not listed we are talking about a really big carrot for the market to move to IPng. This would also be a carrot to move the world to IPng eventually too going back to paragraph 1 from Yakov's RFC 1560 excerpt. Also ACK on B Manning's suggestion fast track ISIS with IESG. This way its an option no matter what happens. Also without specifically trying to, this would also solve Jack Houldsworths IPng convergence need for CLNP as the ISO liaison and FIRPs need I think too. And continue to keep momentum for TCP/IP. As captain Kirk used to say this could be a win-win scenario or was that Mr. Rogers. All - This was a really good discussion )---> thanks for your time.... /jim From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 20:25:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07055; Thu, 14 Apr 1994 19:21:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA22580; Thu, 14 Apr 1994 19:20:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA22546; Thu, 14 Apr 1994 18:50:49 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00852; Thu, 14 Apr 1994 16:50:53 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA06234; Wed, 13 Apr 1994 23:50:29 -0700 Date: Wed, 13 Apr 1994 23:50:29 -0700 From: Tony Li Message-Id: <199404140650.XAA06234@lager.cisco.com> To: medin@nsipo.nasa.gov Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU In-Reply-To: "Milo S. Medin" (NASA ARC NSI Office)'s message of Wed, 13 Apr 94 23:42:57 -0700 <199404140642.XAA08210@dscs.arc.nasa.gov> Subject: Future IGPs Or perhaps people are basing these statements on the incredible success of integrated IS-IS in the marketplace? :-) As a matter of fact, yes. There are several regionals that are using integrated ISIS as their IGP. The marketplace likes integrated routing, especially since the market turned on multiple LS protocols in the same box and saw no point in doing that.... Integrated routing is not human friendly. Integrated routing is a HELL of a lot more friendly than SIN routing. Besides, what makes you think all these proprietary system vendors are going to give up their own proprietary simple routing protocols? Nobody said that they have to. But those simple routing protocols don't have the same features that a more mature routing protocol has. Cisco is working on PIM now (but is also implementing MOSPF), False, we are NOT currently implementing MOSPF. but I didn't think that had even gone into beta yet... Correct. It's in "Early Field Test". Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 20:30:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07089; Thu, 14 Apr 1994 19:23:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA22595; Thu, 14 Apr 1994 19:21:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA22577; Thu, 14 Apr 1994 19:12:35 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04451; Thu, 14 Apr 1994 18:18:01 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA10023; Thu, 14 Apr 1994 01:17:38 -0700 Date: Thu, 14 Apr 1994 01:17:38 -0700 From: Tony Li Message-Id: <199404140817.BAA10023@lager.cisco.com> To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs Christian, I remember asking a question on the interest of multi-protocol routing to M. George Powers, from Novell, during a session on "multi-protocol backbones" at last Interop in SF. Is answer was that he was essentially not interested in "multi-protocol routing" for one very good reason: different protocols have different routing requirements thus integrated routing is mostly a compromise which is only useful "when the customer's requirements meet the compromise's assumption". In short, he much prefered SIN. This was not challenged by the other speakers. I'm sure he preferred SIN. He'd prefer a closed solution too. It's not clear that there are a whole lot of compromises. Recall that NLSP _is_ based on ISIS. There were two other very clear outputs of the whole session, which also featured Joel Bion of cisco and Keith Nelson of the US bank. Firstly, multiple protocols imply multiple managements, which is painful. Big users are busy cutting out the losers to concentrate on a small set of winners - typically IP and IPX, plus SNA "for legacy". The demand for AT and DECNET was mentioned, as well as the unanimous need to eliminate NETBIOS. And the four letters C-L-N-P where not pronounced even once during the whole session - in fact, were not printed either in the special edition of computer week that was distributed during the show. This tells a lot about the status of the market... ARGGGGGGGGGGHHHHHHHH!!!!! This is NOT just about CLNP. This IS about IPX and AT and DECnet and even SNA if I ever figure out enough about that.... (not that I'm trying). The second very clear agreement was that the problem of multiprotocol backbone was not so much routing (SIN works OK) than resource management, e.g. the interaction of a fixed windows transport (IPX), a friendly and polite congestion avoider (TCP) and a very sensitive set of applications (SNA transactional applications expects almost constant delays). Now *that* is interesting. You are correct -- the other protocol stacks are more broken. That's fine. But you can't fix those other protocol stack by judicious choice of routing protocols. We _can_ fix the SIN problem. We should just do it. Tony From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 20:32:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07132; Thu, 14 Apr 1994 19:24:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA22610; Thu, 14 Apr 1994 19:23:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA22563; Thu, 14 Apr 1994 19:01:19 +1000 Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00688; Thu, 14 Apr 1994 16:47:00 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by dscs.arc.nasa.gov (8.6.8/1.5T) id XAA08210; Wed, 13 Apr 1994 23:42:58 -0700 Message-Id: <199404140642.XAA08210@dscs.arc.nasa.gov> To: Tony Li Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Wed, 13 Apr 94 16:54:19 PDT." <199404132354.QAA11972@lager.cisco.com> Date: Wed, 13 Apr 94 23:42:57 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Sigh, not this argument yet again! Our customers are similar to yours and express a very high preference for the simplicity in management of their IGP. They would very much like to have an integrated IGP. We've been to this movie before. Why people continue to persist this "integrated routing" philosophy that has been rejected in the marketplace, I still don't understand. Even DEC has moved away from integrated routing support so that you can not run Phase V and Phase IV in the same box. Integrated routing is not human friendly. Routing is complicated enough to manage without having to figure out what you want your Novell doing while not screwing up the way you want IP to work. It violates the way people think about managing their networks. That is, if you talk to an organization that manages a large multiprotocol system, you'll find experts in X protocol, and experts in Y protocol, etc... These people typically make manage things more or less independently of each other, but integrated routing forces a brain "integration" that doesn't generally work too well. If every routing product was nicely uniform, and forwarded all the protocols of interest, and filtered them all in the same way, and configured them all using the same options, then I might be convinced. But as long as we have people building products that support different protocols differently (look at most of the Appletalk or Novell specific products out there - which probably outnumber the number of IP routers in the field), then integrated routing is not going to be the norm. Besides, what makes you think all these proprietary system vendors are going to give up their own proprietary simple routing protocols? The user's want it because that's what the vendor likes them to run, and makes it easy to run. And the vendors want to be able to change things themselves, without going through the IETF and reducing their advantages in the marketplace by allowing other vendors to compete immediately with them. Or perhaps people are basing these statements on the incredible success of integrated IS-IS in the marketplace? :-) Also the only protocol that seems to have the lead right now for Multicast is OSPF. Hence I think discounting it is premature. As the current trend in multicasting is away from MOSPF and mrouted to PIM, I would not consider this to be a major difficulty. Well, I'm not sure what you mean by "the trend in multicasting" that you state above. Proteon is shipping MOSPF and DVMRP today. Wellfleet (to my best understanding) is also working on adding MOSPF. Cisco is working on PIM now (but is also implementing MOSPF), but I didn't think that had even gone into beta yet... There are more MOSPF and DVMRP speaking hosts out there BY FAR. Now, maybe this trend will change in the future, and maybe it won't. But I don't think you can say the trend is away from MOSPF and DVMRP to PIM, when no company is shipping it yet, and the MBONE is completely run without it (esp. since earlier this week :-(). I understand that Cisco has the bulk of the router market these days, but you should at least wait until your new software is shipped to your users before declaring a trend exists to replace all the other protocols that other vendors support. :-)^2 Some say Beta was better than VHS. But VHS won. Same could be wit h the routing protocols. Good example. VHS won because the end units were cheaper. The difference in quality was invisible to Joe Budweiser. Which IGP is Joe Budweiser more likely to use, given that Joe is using those 5 protocols already? Joe will run X, Frank will run Y, and Ben will run Z. And Fred will make sure the overall system works. It's may not be cheaper in hardware costs, but it's much cheaper in mushware (that's brain programming), which is what the users always optimize for. It's too hard to partition the overall routing problem when you try and mash everything into one big amalgam. Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 20:33:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07151; Thu, 14 Apr 1994 19:26:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA22625; Thu, 14 Apr 1994 19:24:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA22560; Thu, 14 Apr 1994 18:58:31 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29353; Thu, 14 Apr 1994 16:18:32 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17271; Thu, 14 Apr 1994 08:18:06 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19057; Thu, 14 Apr 1994 08:18:05 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404140618.AA19057@dxcoms.cern.ch> Subject: AEIOU BOF minutes To: big-internet@munnari.OZ.AU (bigi) Date: Thu, 14 Apr 1994 08:18:04 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5246 AEIOU BOF, Seattle IETF, 28 March, 1994. 1.30pm. Chair: Brian Carpenter (CERN) Brian.Carpenter@cern.ch Scribe: Peter S. Ford (LANL) peter@goshawk.lanl.gov About 45 participants. Agenda: Brian's Talk on AEIOU Discussion What next for AEIOU? Brian Carpenter presented his ideas on Address Extension by IP Option Usage (AEIOU). The motivation for AEIOU is consideration of the case where no IPng is ready for deployment before IP address runout. AEIOU is not positioned as an IPng, but it is a new version of IP which is to provide interim connectivity for IP until IPng is fully deployed. As such, AEIOU is a limited form of insurance against IPv4 address depletion. Brian presented an overview of AEIOU (see draft-carpenter-aeiou-00.txt). What is needed is flexible address extension beyond IP's 32 bits. One goal for AEIOU is to avoid changing addressing and routing in the Wide Area. Brian assumes that several "conservation measures" would be in effect. We would not extend the global IPv4 address space or modify global routing. We would leverage the current deployment of CIDR and new sites would only get the address space they "need" for the next 1-2 years. There would also be a recycling and recovery process on the current allocation of IP addresses. Private networks would be encouraged to use RFC 1597. There was a fair amount of spirited debate on RFC 1597 revolving around whether or not it was mandatory, that it was not always applicable if a site would eventually connect to the Internet, etc. Many feel that private addresses are a mistake, while others point out that it is irresponsible to use global address space for numbering hosts that never talk outside their site. Further debate on 1597 was left to the ALE group. AEIOU adds two new IP options: Source Addr Extension and Dest. Addr. ext.(SAE, DAE). Each site has its current IANA address space that is globally known, and it picks one of these addresses as a site address. The AEs are managed within a site. It is pointed out that it is dangerous to assume that new options will survive passage across the Internet, Rob Ullman has done some investigation on what routers and hosts do to options. AE is the low order part of the "new" AEIOU address. Steve Deering noted that this is a dual to IPAE, and the mobile group has studied this extensively and they are duals of each other. In the new world there are 3 classes of systems: Old, 32 bit IP only New, AE capable, don't use AE AE, AE used, now have 64 bit addresses. Brian presents a matrix where only OLD and AE cannot talk to each other. It was pointed out that one should carve out part of the global IPv4 space for AEs to be allocated. This way within a site an OLD host can talk to an AE host since the AE part of the address will be unique within the site and can be used as the IPv4 address to talk to an old IPv4 host within the site. Mike ODell noted that this could be net 10, and it would never be routed in the global Internet. Deployment of AEIOU requires that all routers within a site be upgraded. Paul Traina noted that option checking may slow down routers and the fastest routers tend to be attached to LANs within a site, exactly those routers that will need to look at AE options. It is also noted that servers that AE hosts depend on will need to be upgraded before AE clients are deployed. During discussion several issues emerged: System on other end has to change to AE to reach you if you are AE. Checksum only protect 32 bits of address, so potential of misdelivery is greater. Eric Fleischman noted that AE addresses the toaster net problem, ex. power company. This ignited a discussion of application relays as the solution to the toaster net problem. A ton of software needs to be changed for AEIOU: SNMP, DNS, ARP, etc. The API for sockets would need to be extended. Steve Deering noted that you need more than 32 bits to enumerate "sites"/network terminations, Brian pointed out that AEIOU was an interim, not final solution. Summary discussion focused on whether or not AEIOU was too much effort for the return, in light of IPng efforts. Many felt that this would hamper IPng efforts and Eric Fleischman asked if we did AEIOU wouldn't it cause several people to think that they did not have to worry about deploying IPng. John Curran noted that a lot of this work has to happen anyways and suggested that AEIOU could be a Hip Pocket solution requiring a minimum change set. It was noted that the real IPv4 issue at this time is what goes into "Internet in the BOX". Given the parallel problems of AEIOU viz. IPng, Steve Deering recommended that AEIOU should withdraw in favor of IPng efforts. Adding a new protocol (AEIOU) also implies a new thing to transition from to IPng which could unnecessarily complicate matters. After this discussion, Brian is not inclined to propose it as an "active proposal". No mandate for a working group is perceived but it is worth keeping the discussion alive for anybody interested (mail Brian.Carpenter@cern.ch if this is you). Deering noted that AEIOU should go into the same status as as EIP, honored, revered, unimplemented. From owner-Big-Internet@munnari.OZ.AU Thu Apr 14 21:27:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09675; Thu, 14 Apr 1994 20:31:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA22719; Thu, 14 Apr 1994 20:30:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA22686; Thu, 14 Apr 1994 20:17:15 +1000 Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07016; Thu, 14 Apr 1994 19:20:10 +1000 (from dino@cisco.com) Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA14094; Thu, 14 Apr 1994 02:15:40 -0700 Date: Thu, 14 Apr 1994 02:15:40 -0700 From: Dino Farinacci Message-Id: <199404140915.CAA14094@feta.cisco.com> To: bound@zk3.dec.com Cc: tli@cisco.com, bound@zk3.dec.com, big-internet@munnari.OZ.AU, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com In-Reply-To: bound@zk3.dec.com's message of Thu, 14 Apr 94 01:22:09 -0400 <9404140522.AA25161@xirtlu.zk3.dec.com> Subject: Turnipp - a merger proposal >> For sure if IPng IGP (and the exterior routing protocol) can support >> IPX, DECnet, CLNP, SNA, and others I have not listed we are talking >> about a really big carrot for the market to move to IPng. This would >> also be a carrot to move the world to IPng eventually too going back to >> paragraph 1 from Yakov's RFC 1560 excerpt. I disagree. The carrots are for the end-users and not network administrators. It will be hard for people (especially end-users) to get excited for an integrated IGP and go to IPng for specifically this reason. Dino From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 00:21:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15355; Thu, 14 Apr 1994 23:26:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA22880; Thu, 14 Apr 1994 23:25:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA22852; Thu, 14 Apr 1994 23:03:42 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11363; Thu, 14 Apr 1994 21:25:39 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA02704; Thu, 14 Apr 94 06:26:09 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ah18240; 14 Apr 94 11:17 GMT Date: Thu, 14 Apr 94 06:23 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Turnipp - a merger proposal Message-Id: <12940414112321/0003858921NA5EM@mcimail.com> >All - This was a really good discussion )---> thanks for your time.... I second this. It would mean a VERY big change for Chrysler, looking at the size of our OSPF environment. But now as we move to a group of Autonomous domains within Chrysler with our own BGP backbone, a future shift a couple years out would be do-able... Bob From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 00:23:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15644; Thu, 14 Apr 1994 23:37:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA22895; Thu, 14 Apr 1994 23:30:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA22855; Thu, 14 Apr 1994 23:06:17 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12544; Thu, 14 Apr 1994 22:01:22 +1000 (from yakov@watson.ibm.com) Message-Id: <9404141201.12544@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1107; Thu, 14 Apr 94 08:01:20 EDT Date: Thu, 14 Apr 94 08:00:12 EDT To: tli@cisco.com Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Future IGPs Ref: Your note of Wed, 13 Apr 1994 21:07:56 -0700 Tony, >Thus, for IDRP, we can carry around a GOSIP format NSAP and a SIPP >address with impunity.. That is correct. Folks who doubt this, should consider reading IDRP for IP Internet Draft (draft-hares-idrp-05.txt) and IDRP for SIP Internet Draft (draft-ietf-ipidrp-sip-01.txt). >So, for example, adding IPng support to IDRP consists of defining >one new attribute and saying "well, addresses of type 57 will be >IPng addresses". That's IT. Done. Actually for IDRP you DON'T need to define ANY NEW attributes. You just need to specify the protocol type of the the Network Layer Reachability Information you carry (e.g. IPv4 has protocol type X, SIPP has protocol type Y, etc...). So, it is even simpler than you described. Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 01:46:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20806; Fri, 15 Apr 1994 01:46:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA23090; Fri, 15 Apr 1994 01:45:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA23087; Fri, 15 Apr 1994 01:40:55 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20590; Fri, 15 Apr 1994 01:42:09 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 14 Apr 1994 08:40:51 -0700 Date: Thu, 14 Apr 1994 08:40:51 -0700 Message-Id: <199404141540.AA09791@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: craig@aland.bbn.com Cc: big-internet@munnari.OZ.AU In-Reply-To: Craig Partridge's message of Thu, 14 Apr 94 07:54:49 -0700 <199404141454.HAA03961@aland.bbn.com> Subject: while we're tuning up routing protocols Reply-To: estrin@usc.edu From: Craig Partridge Hi folks: If we're on the topic of tuning up routing protocols for the future... Could we make it a requirement of future routing protocols that we be able to add arbitrary information to each individual route or link state and that routing agents that don't understand the additional information pass it through untouched? It is a real pain to have to completely rewrite a routing protocol's packet formats to experiment with passing around new routing information for multimedia/policy/etc. Craig If you are doing this in a link state, hop by hop, protocol, you had better be careful that it does not lead to inconsistant decisions! From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 02:33:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19639; Fri, 15 Apr 1994 01:11:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA23004; Fri, 15 Apr 1994 01:10:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA22987; Fri, 15 Apr 1994 01:03:45 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18197; Fri, 15 Apr 1994 00:28:04 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA07052; Thu, 14 Apr 94 07:24:42 -0700 Received: by xirtlu.zk3.dec.com; id AA02875; Thu, 14 Apr 1994 10:24:41 -0400 Message-Id: <9404141424.AA02875@xirtlu.zk3.dec.com> To: Masataka Ohta Cc: tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 14 Apr 94 11:41:20 +0200." <9404140241.AA06981@necom830.cc.titech.ac.jp> Date: Thu, 14 Apr 94 10:24:35 -0400 X-Mts: smtp >> OSPF is redundant. It's very clear that the future of the Internet is >> multiprotocol (and I inlcude IPX, AT (in isolated clouds) and CLNP). >It seems to me that Turnipp is just another catnip and is redundant. > Masataka Ohta So do you believe CATNIP can solve what TURNIP is suggesting as a 'merger'? Could you say more. thanks /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 02:33:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19733; Fri, 15 Apr 1994 01:13:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA23019; Fri, 15 Apr 1994 01:12:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA22984; Fri, 15 Apr 1994 00:58:16 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19133; Fri, 15 Apr 1994 00:59:18 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00231 for big-internet@munnari.oz.au; Thu, 14 Apr 94 10:57:21 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id HAA03961; Thu, 14 Apr 1994 07:54:53 -0700 Message-Id: <199404141454.HAA03961@aland.bbn.com> To: big-internet@munnari.OZ.AU Subject: while we're tuning up routing protocols From: Craig Partridge Date: Thu, 14 Apr 94 07:54:49 -0700 Sender: craig@aland.bbn.com Hi folks: If we're on the topic of tuning up routing protocols for the future... Could we make it a requirement of future routing protocols that we be able to add arbitrary information to each individual route or link state and that routing agents that don't understand the additional information pass it through untouched? It is a real pain to have to completely rewrite a routing protocol's packet formats to experiment with passing around new routing information for multimedia/policy/etc. Craig From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 02:56:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23834; Fri, 15 Apr 1994 02:56:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA23238; Fri, 15 Apr 1994 02:55:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA23210; Fri, 15 Apr 1994 02:30:15 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20229; Fri, 15 Apr 1994 01:31:04 +1000 (from yakov@watson.ibm.com) Message-Id: <9404141531.20229@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4335; Thu, 14 Apr 94 11:30:52 EDT Date: Thu, 14 Apr 94 11:30:07 EDT To: craig@bbn.com, big-internet@munnari.OZ.AU Subject: while we're tuning up routing protocols Ref: Your note of Thu, 14 Apr 94 07:54:49 -0700 Craig, >Could we make it a requirement of future routing protocols that we >be able to add arbitrary information to each invidivual route or link >state and that routing agents that don't understand the additional >information pass it through untouched ? Just to let you know that this requirement is already supported in BGP/IDRP via the mechanism of "optional path attributes". Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 02:57:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23892; Fri, 15 Apr 1994 02:57:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA23253; Fri, 15 Apr 1994 02:56:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA23224; Fri, 15 Apr 1994 02:51:14 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20187; Fri, 15 Apr 1994 01:28:44 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA10931; Thu, 14 Apr 94 08:22:03 -0700 Received: by xirtlu.zk3.dec.com; id AA04641; Thu, 14 Apr 1994 11:21:57 -0400 Message-Id: <9404141521.AA04641@xirtlu.zk3.dec.com> To: Dino Farinacci Cc: big-internet@munnari.OZ.AU Subject: Routers vs Hosts needs for Networking Date: Thu, 14 Apr 94 11:21:51 -0400 X-Mts: smtp Dino, I don't believe ISIS will work as is for an IPng 'merger'. It and ES-IS make assumptions regarding the model of distributed computing regarding servers on the network, host IGP routing, autoconfiguration, and system discovery that I think need to be looked at in technical detail. For example the idea of Areas supporting a subnet (in IP terms) spanning multiple links is not necessary and may not even be good. I think from a router perspective its great but we have millions of hosts in the market that are not dictated to by routers. For example the network layer greeting strategy (advertisment and solicitation) needs review if it were to be the IPng integrated routing protocol. I hear what all are saying about PIM. But I would like to hear from Steve Deering, Van Jacobson, and others on this magic happening and with IS-IS. I also think we need to hear from Dave Clark on the issue he wanted to bring up at the IETF Reqs BOF regarding the architecture models for IPng (and I mean next generation). NIMROD should also be used as a test too. And finally I think Paul Francis has done a real good job with SIPP routing spec and I am curious what can be learned from that strategy that could be added to a new IPng integrated routing protocol. So I guess I don't believe IS-IS is ready to be this until I do and hear more analysis. And as Milo stated its not like we have IS-IS all over the market and its been around for awile and even with government mandates its still not pervasive. I don't believe its all political. I also believe it forces strategies on hosts that do not support the IP model of cooperative anarchy. But I do believe IS-IS and OSPF are a place to start. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 03:18:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19760; Fri, 15 Apr 1994 01:15:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA23034; Fri, 15 Apr 1994 01:13:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA22990; Fri, 15 Apr 1994 01:04:50 +1000 Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17892; Fri, 15 Apr 1994 00:21:59 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id IAA06603; Thu, 14 Apr 1994 08:21:52 -0600 From: "Peter S. Ford" Message-Id: <199404141421.IAA06603@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: "Milo S. Medin" (NASA ARC NSI Office) Cc: Tony Li , big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of Wed, 13 Apr 94 23:42:57 -0700. <199404140642.XAA08210@dscs.arc.nasa.gov> Date: Thu, 14 Apr 94 08:21:51 MST >>> We've been to this movie before. Yes Milo, you have once again taken the idea of using the same routing protocol for different network layer protocols and seg-wayed it (logical steps missing) into the Integrated vrs. SIN debate. Familiar storyline. Take N++. Add to that your proof by emphatic assertion that IPv4 routing is soooooooo different from any other network layer routing and bingo we get the answer: for each protocol we need a different routing protocol with the corollary SIN is the ONLY way to route. The problem with this theorem is that we have empirical evidence in contradiction. And this is the crux of the frustration, if people use integrated routing who are we to tell them any different? OSPF is probably the right solution for you and many others. No debate here. The contention is that many people who operate networks would love to have the Faberge eggheads (us), who are supposedly looking out for their interests, help them to simplify their jobs. SIN with the same protocol would be a good start. Integrated routing is an orthogonal issue. By the way, will NSI run OSPF extended for SIP as SIN or as integrated routing? Or perhaps there should there be two different OSPFs? Linguists need not reply. cheers, peter From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 03:19:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19795; Fri, 15 Apr 1994 01:16:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA23049; Fri, 15 Apr 1994 01:14:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA22981; Fri, 15 Apr 1994 00:57:12 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19065; Fri, 15 Apr 1994 00:58:30 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA09016; Thu, 14 Apr 94 07:54:47 -0700 Received: by xirtlu.zk3.dec.com; id AA03731; Thu, 14 Apr 1994 10:54:44 -0400 Message-Id: <9404141454.AA03731@xirtlu.zk3.dec.com> To: Dino Farinacci Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 14 Apr 94 02:15:40 PDT." <199404140915.CAA14094@feta.cisco.com> Date: Thu, 14 Apr 94 10:54:38 -0400 X-Mts: smtp >> For sure if IPng IGP (and the exterior routing protocol) can support >> IPX, DECnet, CLNP, SNA, and others I have not listed we are talking >> about a really big carrot for the market to move to IPng. This would >> also be a carrot to move the world to IPng eventually too going back to >> paragraph 1 from Yakov's RFC 1560 excerpt. > I disagree. The carrots are for the end-users and not network > administrators. It will be hard for people (especially end-users) to get > excited for an integrated IGP and go to IPng for specifically this reason. I disagree with you on this and here is why. Customers are not just users who find a need and then just satisfy it anymore. They think hard and long before having a bidders meeting. Customers have architects and computer scientists on site (if you never have been beat up by one you are missing a great learning experience). They do look at what their networks should be 5-10 years from now to solve their business problem. There are two carrots the customer will look for in an IPng. First what does it do for me today at a reasonable cost. This could be autoconfiguration, multicast, autoregistration, ease of porting their existing applications etc. The second carrot is what is the principles and architecture behind IPng. If IPng can afford them a future transition of their protocols to an integrated IGP then this will gain their interest. Yes it is a carrot. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 03:31:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25600; Fri, 15 Apr 1994 03:31:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA23306; Fri, 15 Apr 1994 03:30:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA23283; Fri, 15 Apr 1994 03:18:04 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21651; Fri, 15 Apr 1994 02:11:36 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA13952; Thu, 14 Apr 94 09:05:24 -0700 Received: by xirtlu.zk3.dec.com; id AA05723; Thu, 14 Apr 1994 12:05:23 -0400 Message-Id: <9404141605.AA05723@xirtlu.zk3.dec.com> To: estrin@usc.edu Cc: craig@aland.bbn.com, big-internet@munnari.OZ.AU Subject: Re: while we're tuning up routing protocols In-Reply-To: Your message of "Thu, 14 Apr 94 08:40:51 PDT." <199404141540.AA09791@zephyr.isi.edu> Date: Thu, 14 Apr 94 12:05:17 -0400 X-Mts: smtp >If you are doing this in a link state, hop by hop, protocol, you had >better be careful that it does not lead to inconsistant decisions! Such as? thanks /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 03:40:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25971; Fri, 15 Apr 1994 03:40:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA23321; Fri, 15 Apr 1994 03:38:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA23289; Fri, 15 Apr 1994 03:22:48 +1000 Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22209; Fri, 15 Apr 1994 02:23:08 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by large.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id JAA07460; Thu, 14 Apr 1994 09:20:33 -0700 Date: Thu, 14 Apr 1994 09:20:33 -0700 From: Dave Katz Message-Id: <199404141620.JAA07460@large.cisco.com> To: craig@aland.bbn.com Cc: big-internet@munnari.OZ.AU In-Reply-To: Craig Partridge's message of Thu, 14 Apr 94 07:54:49 -0700 <199404141454.HAA03961@aland.bbn.com> Subject: while we're tuning up routing protocols This is already the case with IS-IS. From: Craig Partridge Date: Thu, 14 Apr 94 07:54:49 -0700 Sender: craig@aland.bbn.com Hi folks: If we're on the topic of tuning up routing protocols for the future... Could we make it a requirement of future routing protocols that we be able to add arbitrary information to each individual route or link state and that routing agents that don't understand the additional information pass it through untouched? It is a real pain to have to completely rewrite a routing protocol's packet formats to experiment with passing around new routing information for multimedia/policy/etc. Craig From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 03:43:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26098; Fri, 15 Apr 1994 03:43:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA23347; Fri, 15 Apr 1994 03:42:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA23303; Fri, 15 Apr 1994 03:26:48 +1000 Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25489; Fri, 15 Apr 1994 03:28:06 +1000 (from dino@cisco.com) Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA04351; Thu, 14 Apr 1994 10:25:04 -0700 Date: Thu, 14 Apr 1994 10:25:04 -0700 From: Dino Farinacci Message-Id: <199404141725.KAA04351@feta.cisco.com> To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU In-Reply-To: bound@zk3.dec.com's message of Thu, 14 Apr 94 10:54:38 -0400 <9404141454.AA03731@xirtlu.zk3.dec.com> Subject: Turnipp - a merger proposal >> There are two carrots the customer will look for in an IPng. First what >> does it do for me today at a reasonable cost. This could be >> autoconfiguration, multicast, autoregistration, ease of porting their >> existing applications etc. The second carrot is what is the principles >> and architecture behind IPng. If IPng can afford them a future >> transition of their protocols to an integrated IGP then this will gain >> their interest. Again, if we use this logic, IPv4 has all the carrots you state except for one big carrot - longer addresses. You should know as well as I, that IPng will be reaching (we hope) more people that are less knowledgable about networking. If you tell them that they get an integrated IGP, you think they will 1) understand what it is, 2) know if it is important, or 3) not worry about it because it's their vendor's problem. Dino P.S. Don't get me wrong, I think integrated routing is a good thing. From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 03:46:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26238; Fri, 15 Apr 1994 03:46:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA23362; Fri, 15 Apr 1994 03:44:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA23269; Fri, 15 Apr 1994 03:07:55 +1000 Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18201; Fri, 15 Apr 1994 00:28:36 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA30329 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 14 Apr 1994 10:28:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 14 Apr 1994 10:28:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 14 Apr 1994 10:28:30 -0400 Message-Id: <199404141425.AA97714@foo.ans.net> To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 14 Apr 1994 01:41:48 GMT." <199404140141.SAA18382@lager.cisco.com> Date: Thu, 14 Apr 1994 10:25:29 -0400 From: Dennis Ferguson Tony, In fact I sort of agree with you about the need for multiprotocol support, and am very much of the opinion that if you have to do this then an integrated routing protocol is a useful thing to have. I think we should be clear that IS-IS is also not without a serious limitation in need of repair, however. > For Turnipp, the "MUST IMPLEMENT" IGP is ISIS. That's all there is to > it. [...] > A fine point. However, for some values of IPng (Turnipp in > particular), RIP and OSPF are clearly NOT extensible in a > backwards-compatible way. But, even ignoring the too-small metrics and the lack of forwarding address support, the fact is that the current IS-IS is pretty much unuseable by anyone who needs to carry the current full Internet IPv4 routing in their IGP, even ignoring trying to route the four other network protocols you mentioned. IS-IS imposes some relatively severe size limitations on the amount of routing information a single router may originate, and while the places which are affected by this are currently few I think it would be short sighted to assume that the size of the routing problem on the public IPv4 Internet today is somehow a different scale than the size of the routing problem on tomorrow's multiprotocol private internets. IS-IS needs to be fixed too, and sooner would be better. Hence we have OSPF, which is free of architected-in size limitations but which is single-protocol, and IS-IS, which is multiprotocol but which has a fetish for unreasonably small integer fields. Either, or both, of these protocols can be fixed to have their limitations removed, but unless I'm missing something I don't see how the repaired IS-IS is going to be any more backwards-compatible, and friendly to existing implementations, than a repaired OSPF. I therefore think that, as currently specified, neither IGP is without difficulties when extrapolated forward into future multiprotocol environments, both IGPs are repairable to remove these difficulties, but neither is repairable in a fashion which has much hope of providing backward compatibility. I don't have strong opinions for or against either of them (I prefer how OSPF handled many of the details of the protocol, but in a practical sense I much prefer basic functionality to details) but I don't quite understand the exclusive focus on IS-IS. Both IGPs are imperfect, your justification above ignores the fact that IS-IS needs work too. Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 03:52:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22160; Fri, 15 Apr 1994 02:21:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA23161; Fri, 15 Apr 1994 02:20:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA23106; Fri, 15 Apr 1994 01:51:32 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20923; Fri, 15 Apr 1994 01:52:41 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA12585; Thu, 14 Apr 94 08:45:44 -0700 Received: by xirtlu.zk3.dec.com; id AA05315; Thu, 14 Apr 1994 11:45:40 -0400 Message-Id: <9404141545.AA05315@xirtlu.zk3.dec.com> To: "Peter S. Ford" Cc: big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Thu, 14 Apr 94 08:21:51 MST." <199404141421.IAA06603@goshawk.lanl.gov> Date: Thu, 14 Apr 94 11:45:33 -0400 X-Mts: smtp >OSPF is probably the right solution for you and many others. No debate here. >The contention is that many people who operate networks would love >to have the Faberge eggheads (us), who are supposedly looking out for >their interests, help them to simplify their jobs. SIN with the same >protocol would be a good start. Integrated routing is an orthogonal issue. I think this is a key point Peter has suggested. I view this discussion as orhogonal to SIN too. thanks /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 04:27:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26385; Fri, 15 Apr 1994 03:47:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA23377; Fri, 15 Apr 1994 03:45:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA23286; Fri, 15 Apr 1994 03:22:28 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18912; Fri, 15 Apr 1994 00:54:10 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA08547; Thu, 14 Apr 94 07:47:10 -0700 Received: by xirtlu.zk3.dec.com; id AA03530; Thu, 14 Apr 1994 10:47:08 -0400 Message-Id: <9404141447.AA03530@xirtlu.zk3.dec.com> To: "Milo S. Medin" (NASA ARC NSI Office) Cc: tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Wed, 13 Apr 94 23:42:57 PDT." <199404140642.XAA08210@dscs.arc.nasa.gov> Date: Thu, 14 Apr 94 10:47:02 -0400 X-Mts: smtp Milo, >Sigh, not this argument yet again! I think it is different because we now are doing IPng. I agree that an IGP is more complex but what I am trying to see is can we build an integtrated IPng routing protocol that can or may support other protocols? This does not seem bad to me? Unless it slows down IPng to get completed in the IETF or miss the July deadline by an order of magnitude. I believe it can be done post IPng and adapt to the proposal selected. This would not prevent a proposal using their suggestion for routing. What I am thinking is work for an addendum and new routing protocol if ISIS will not work. Or is this old too? )---> thanks.. >Our customers are similar to yours and express a very high preference >for the simplicity in management of their IGP. They would very much >like to have an integrated IGP. >We've been to this movie before. Why people continue to persist this >"integrated routing" philosophy that has been rejected in the marketplace, >I still don't understand. Even DEC has moved away from integrated routing >support so that you can not run Phase V and Phase IV in the same box. Well we do now offer this and you know why. >Integrated routing is not human friendly. Routing is complicated enough >to manage without having to figure out what you want your Novell doing while >not screwing up the way you want IP to work. It violates the way people >think about managing their networks. That is, if you talk to an organization >that manages a large multiprotocol system, you'll find experts in X >protocol, and experts in Y protocol, etc... These people typically make >manage things more or less independently of each other, but integrated >routing forces a brain "integration" that doesn't generally work too well. This was a big part of my diatribe last night on this list. The core goal is to make IP work. Again what I am saying is lets build a template for tomorrow not sacrifice todays IP environment for an IGP. >If every routing product was nicely uniform, and forwarded all the protocols >of interest, and filtered them all in the same way, and configured them >all using the same options, then I might be convinced. But as long as we >have people building products that support different protocols differently >(look at most of the Appletalk or Novell specific products out there - which >probably outnumber the number of IP routers in the field), then integrated >routing is not going to be the norm. I believe if we give folks an option to merge to a great IPng to reduce the protocols we need to support as vendors they will move. But there is a transition issue here to a new integrated IGP. This would make it less brain intensive to adapt to at end user sights. >Besides, what makes you think all these proprietary system vendors >are going to give up their own proprietary simple routing protocols? >The user's want it because that's what the vendor likes them to run, and >makes it easy to run. And the vendors want to be able to change things >themselves, without going through the IETF and reducing their advantages >in the marketplace by allowing other vendors to compete immediately with them. Well this is what your seeing now in the market place. All vendors have a primary IP strategy for their end users because of the multivendor purchase requirements. IP is the only one that can provide this in a robust manner. >Or perhaps people are basing these statements on the incredible success >of integrated IS-IS in the marketplace? :-) I hope not and I am not for sure. I am trying to figure out if users at GM, Chrysler, Ford, Boeing, Shell, TRW, CERN, HEP, NTT, Ministry of Singapore, etc would like it if the IETF did provide an IPng strategy that in the future could route their other protocols across their backbones while they might transitiion to IPng. ISIS may be a protocol to look at to solve this problem. I will repsond to others why it might not be in a follow up mail message to another response. >> Also the only protocol that seems to have the lead right now for >> Multicast is OSPF. Hence I think discounting it is premature. >> As the current trend in multicasting is away from MOSPF and mrouted to >> PIM, I would not consider this to be a major difficulty. >Well, I'm not sure what you mean by "the trend in multicasting" that you >state above. Proteon is shipping MOSPF and DVMRP today. Wellfleet (to my >best understanding) is also working on adding MOSPF. Cisco is working >on PIM now (but is also implementing MOSPF), but I didn't think that had >even gone into beta yet... There are more MOSPF and DVMRP speaking hosts >out there BY FAR. Now, maybe this trend will change in the future, and >maybe it won't. But I don't think you can say the trend is away from MOSPF >and DVMRP to PIM, when no company is shipping it yet, and the MBONE is >completely run without it (esp. since earlier this week :-(). Yes it is critical we understand the here and now. Agreed. This was the beginning of my mail when I got into this discussion. >>Some say Beta was better than VHS. But VHS won. Same could be with >> the routing protocols. >> Good example. VHS won because the end units were cheaper. The >> difference in quality was invisible to Joe Budweiser. Which IGP is >> Joe Budweiser more likely to use, given that Joe is using those 5 >> protocols already? >Joe will run X, Frank will run Y, and Ben will run Z. And Fred will make sure >the overall system works. It's may not be cheaper in hardware costs, but >it's much cheaper in mushware (that's brain programming), which is what >the users always optimize for. It's too hard to partition the overall >routing problem when you try and mash everything into one big amalgam. This is a complexity I assume we could solve. thanks /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 05:32:18 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28911; Fri, 15 Apr 1994 04:47:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02884 Fri, 15 Apr 1994 04:44:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA23473; Fri, 15 Apr 1994 04:40:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA23439; Fri, 15 Apr 1994 04:24:52 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26634; Fri, 15 Apr 1994 03:55:32 +1000 (from yakov@watson.ibm.com) Message-Id: <9404141755.26634@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7101; Thu, 14 Apr 94 13:55:31 EDT Date: Thu, 14 Apr 94 13:54:33 EDT To: bound@zk3.dec.com, estrin@usc.edu Cc: big-internet@munnari.OZ.AU Subject: while we're tuning up routing protocols Ref: Your note of Thu, 14 Apr 94 12:05:17 -0400 Jim, >>If you are doing this in a link state, hop by hop, protocol, you >>have better be careful that it does not lead to inconsistent decisions > >Such as ? One of the fundamental assumptions of link-state with hop-by-hop forwarding is that the topology that is used for Dijksra algorithm is consistent among the nodes (routers) involved in computation. It is relatively simple to construct an example of how a situation where different nodes (routers) that don't have exactly the same topology information would compute their forwarding tables (used for hop-by-hop forwarding) such that using these tables for forwarding would result in a persistent forwarding loop (packets would loop forever). Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 05:51:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01777; Fri, 15 Apr 1994 05:51:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA23618; Fri, 15 Apr 1994 05:50:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA23615; Fri, 15 Apr 1994 05:46:22 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01565; Fri, 15 Apr 1994 05:47:35 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA28115; Thu, 14 Apr 94 12:41:09 -0700 Received: by xirtlu.zk3.dec.com; id AA11009; Thu, 14 Apr 1994 15:41:06 -0400 Message-Id: <9404141941.AA11009@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: while we're tuning up routing protocols In-Reply-To: Your message of "Thu, 14 Apr 94 13:54:33 EDT." <9404141755.26634@munnari.oz.au> Date: Thu, 14 Apr 94 15:41:00 -0400 X-Mts: smtp Yakov, >>If you are doing this in a link state, hop by hop, protocol, you >>have better be careful that it does not lead to inconsistent decisions > >Such as ? >One of the fundamental assumptions of link-state with hop-by-hop >forwarding is that the topology that is used for Dijksra algorithm is >consistent among the nodes (routers) involved in computation. It is >relatively simple to construct an example of how a situation where >different nodes (routers) that don't have exactly the same topology >information would compute their forwarding tables (used for hop-by-hop >forwarding) such that using these tables for forwarding would result in >a persistent forwarding loop (packets would loop forever). Thanks. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 06:21:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27036; Fri, 15 Apr 1994 04:06:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA23407; Fri, 15 Apr 1994 04:05:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA23404; Fri, 15 Apr 1994 03:58:06 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22922; Fri, 15 Apr 1994 02:42:50 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA03929; Thu, 14 Apr 94 12:40:59 EDT Message-Id: <9404141640.AA03929@tipper.oit.unc.edu> To: estrin@usc.edu Cc: craig@aland.bbn.com, big-internet@munnari.OZ.AU Subject: Re: while we're tuning up routing protocols In-Reply-To: Your message of "Thu, 14 Apr 94 08:40:51 PDT." <199404141540.AA09791@zephyr.isi.edu> Date: Thu, 14 Apr 94 12:40:59 -0400 From: Simon E Spero >>>>> "Deborah" == Deborah Estrin writes: >>>>> "Craig" == Craig Partridge Craig> Could we make it a requirement of future routing Craig> protocols that we be able to add arbitrary information to Craig> each individual route or link state and that routing Craig> agents that don't understand the additional information Craig> pass it through untouched? It is a real pain to have to Deborah> If you are doing this in a link state, hop by hop, Deborah> protocol, you had better be careful that it does not lead Deborah> to inconsistant decisions! Hey- maybe what we need is IPNG Routing MOPP (meta object protocol protocol), with the ability to define classes for packets, route combination, slots &c. We could even have special packets to define new classes, specify new methods on those functions, etc. Compile it down to the level of your switching hardware, and there needn't be any performance loss. With a dynamically reconfigurable network substrate, we could have a different IPNG backbone for every day of the week - CLNP on Mondays, IPV7 on Tuesdays, SIPP on Wednesdays; we could even make thursdays IPV4 nostalgia night. With CLOS on every router, everyone's a winner. Hah! Let's see NIMROD do that! Simon From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 06:43:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00298; Fri, 15 Apr 1994 05:16:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA23562; Fri, 15 Apr 1994 05:15:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA23548; Fri, 15 Apr 1994 05:06:08 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29862; Fri, 15 Apr 1994 05:07:20 +1000 (from tli@cisco.com) Received: from lager.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02989 Fri, 15 Apr 1994 04:51:23 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA13957; Thu, 14 Apr 1994 11:48:40 -0700 Date: Thu, 14 Apr 1994 11:48:40 -0700 From: Tony Li Message-Id: <199404141848.LAA13957@lager.cisco.com> To: medin@nsipo.nasa.gov Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU In-Reply-To: "Milo S. Medin" (NASA ARC NSI Office)'s message of Thu, 14 Apr 94 10:55:17 -0700 <199404141755.KAA13674@cincsac.arc.nasa.gov> Subject: Future IGPs Integrated routing is a HELL of a lot more friendly than SIN routing. Saying that doesn't make it so. You're right. However, Dino did the coding and that made it so. ;-) This gets into organizational issue of how people do their work and manage their networks. Proposals which may be technically elegant tend not to fly if they are at odds with how the customers do their job. No argument. Now you've pointed out that NASA has a SIN architecture. What you fail to account for is that in the commercial world, folks don't do that. There's one networking group, they have responsibility for the routers. They have _integrated_ responsibility. The regionals work the same way. My langauge was ambigious. I believe that you WILL be implementing MOSPF, Saying that doesn't make it so. or so your boss has promised to me. This should be good... Tony From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 06:47:48 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03793; Fri, 15 Apr 1994 06:47:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04457 Fri, 15 Apr 1994 06:29:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA23680; Fri, 15 Apr 1994 06:25:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA23649; Fri, 15 Apr 1994 06:08:41 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00240; Fri, 15 Apr 1994 05:15:23 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-13.dialip.mich.net (pm002-13.dialip.mich.net [35.1.48.94]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA12902 for ; Thu, 14 Apr 1994 15:15:14 -0400 Date: Thu, 14 Apr 94 17:34:40 GMT From: "William Allen Simpson" Message-Id: <2213.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Cisco Future IGPs > From: Tony Li > False, we are NOT currently implementing MOSPF. > Can I assume that this is a truthful rendering of what Cisco is actually doing? Since Cisco marketing promised at least 1 client of mine that multicast would be delivered in the second quarter of this year, on the promise of which they ordered 2 7000s, I suspect you are going to have some very angry customers if you aren't working on it right now. Coupled to your earlier assertion that Cisco won't be doing RIP2, what exactly is Cisco doing to support CIDR at local sites? That will talk to the dozens of other vendor's routers, many of which talk RIP2, but not OSPF? And what RFC is the Proposed Standard for PIM which Cisco is implementing? I can't find it. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 06:47:53 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03801; Fri, 15 Apr 1994 06:47:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04470 Fri, 15 Apr 1994 06:30:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA23695; Fri, 15 Apr 1994 06:26:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA23626; Fri, 15 Apr 1994 05:51:19 +1000 Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01803; Fri, 15 Apr 1994 05:52:36 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id NAA11230; Thu, 14 Apr 1994 13:52:33 -0600 From: "Peter S. Ford" Message-Id: <199404141952.NAA11230@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: "Milo S. Medin" (NASA ARC NSI Office) Cc: big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of Thu, 14 Apr 94 11:34:47 -0700. <199404141834.LAA13707@cincsac.arc.nasa.gov> Date: Thu, 14 Apr 94 13:52:32 MST >>> I'm a lower layers type of guy myself, and I tend to view problem >>> solving as requiring lower layer issues to be resolved. But when you >>> look at it, you see that's a minor issue, and that we need to solve it >>> higher up in the food chain. If it's fixed there, then it'll also fix >>> the problems we have with multiprotocol issues down here. Milo, Since the lower layer issues are done with, then I assume we can kill off the B-I list ... I do agree with you that a single internal gateway routing protocol does not solve *the* multiprotocol Internet problem. My position is that it is not a bad thing. Yours is that this can not be done. I would argue that empirical evidence supports my side and will concede that your assertions are more emphatic then mine. No Contest. I do like the vision you present for merging protocol suites. What many would say is this is equivalent to how you get from IPv4 to IPng, but you are raising the stakes to : {IPv4, IPX, AT (I know you own a DUO), DEC, CLNP} --> IPng. I believe this is a good idea. What I would like to see ("Somewhere over the Rainbow" is playing in the background) is that those parties see IPng of such tremendous value that they figure out how to transition their apps and services to IPng. (Music volume is increasing) Transition strategies that work for IPv4 -> IPng may even be applicable with ProtXXX -> IPng. What many of us have argued is that we should take this kind of evolution into account when coming up with the addressing structure for IPng. The net result for us is the use of NSAPs, as documented in Catnip, Turnipp etc. This may facilitate transition/coexistence strategies that use packet translation. Milo, it is always a pleasure when we find common ground. take a nap, peter From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 06:48:07 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03822; Fri, 15 Apr 1994 06:48:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04523 Fri, 15 Apr 1994 06:34:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA23710; Fri, 15 Apr 1994 06:27:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA23663; Fri, 15 Apr 1994 06:20:20 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27362; Fri, 15 Apr 1994 04:16:39 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA25757; Thu, 14 Apr 94 11:18:17 -0700 Date: Thu, 14 Apr 94 11:18:17 -0700 From: Eric Fleischman Message-Id: <9404141818.AA25757@atc.boeing.com> To: bound@zk3.dec.com, dino@cisco.com Subject: Re: Turnipp - a merger proposal Cc: big-internet@munnari.OZ.AU, ericf@munnari.OZ.AU The purpose of this message is to fully support Jim Bound's analysis and his resulting conclusions: >There are two carrots the customer will look for in an IPng. First what >does it do for me today at a reasonable cost. This could be >autoconfiguration, multicast, autoregistration, ease of porting their >existing applications etc. The second carrot is what is the principles >and architecture behind IPng. If IPng can afford them a future >transition of their protocols to an integrated IGP then this will gain >their interest. I do wish to say that Jim's first list is a bit of "apples and oranges". Networking types like me are motivated by autoregistration, ease of porting applications, etc. These things motivate me to want to back a technology. Of course, even more fundamental issues such as the ability of the technolgy to scale and its technical long-term viability (or what I perceive that viability to be) including its ability to interwork with the installed base are even bigger sellers in my book. Thus, Jim's point number two (integration) is an immensely important point which is probably more important to me than any of the items in the first list. However, the things which "sell" a technology are not what we networking- types want but rather what our real end users want. My customers want multimedia, real-time applications, etc. My customers want powerful, integrated applications. These are the things which will cause us to want to buy an IPng -- assuming, of course, that these applications demand functionalities which can only (best ?) be met by IPng and not IPv4. The challenge we end users have as a corporation is to try to satisfy our real end users in an intelligent fashion. Our real end users' needs, after all, directly affect our corporate bottom line and must not be ignored. However, to ignore the implication of the "new technology" on the installed base is suicidal -- and WILL translate into notable cost increases which very well may not pass the cost/benefit analysis (i.e., business case). Thus, senior management seeks to "balance" these two forces: the "sane networking" concerns which motivate me with the "functionality needs" of my users. Both are very important and without satisfying both you do not really have a viable (long term) technology -- unless, of course, the application is a "killer application" which we perceive we must have to continue to exist as a business. In that case our real end users must always win. Thus, I concur with Jim's observations but I wish to emphasize that a corporation is not a single entity with a single viewpoint. The bottom line from the IETF point-of-view is that you can not ignore either my needs or my end users' needs and hope to have a "deployable technology" which could replace IPv4. Sincerly yours, --Eric Fleischman BCS Network Architect From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 06:48:17 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03831; Fri, 15 Apr 1994 06:48:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04497 Fri, 15 Apr 1994 06:32:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA23725; Fri, 15 Apr 1994 06:28:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA23666; Fri, 15 Apr 1994 06:22:54 +1000 Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27698; Fri, 15 Apr 1994 04:21:53 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (8.6.8/1.5T) id LAA13692; Thu, 14 Apr 1994 11:17:59 -0700 Message-Id: <199404141817.LAA13692@cincsac.arc.nasa.gov> To: bound@zk3.dec.com Cc: tli@cisco.com, big-internet@munnari.OZ.AU, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 14 Apr 94 01:22:09 EDT." <9404140522.AA25161@xirtlu.zk3.dec.com> Date: Thu, 14 Apr 94 11:17:59 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) For sure if IPng IGP (and the exterior routing protocol) can support IPX, DECnet, CLNP, SNA, and others I have not listed we are talking about a really big carrot for the market to move to IPng. This would also be a carrot to move the world to IPng eventually too going back t o paragraph 1 from Yakov's RFC 1560 excerpt. Perhaps I'm cynical, but I just don't see this happening practically. People will use products and buy services that solve problems. The people I deal with in the field don't believe that routing of multiple protocols is a problem. They believe mananging these networks, running different transport and packet layers, with different filtering parameters, and the different software in the hosts is the problem. Router vendors have sold multiprotocol router solutions to customers for some time now, quite successfully. Almost all of these implementations have been done using SIN routing. Groups who manage these networks support different protocol suites differently. It's important to have a DECNET or Appletalk guy who knows the routing, management, transport and software configuration issues in order to solve problems in those networks. If you have integrated routing, you still need this guy, but now he has to coordinate routing changes with the IP guy and other folks. Solving problems effectively means end to end debugging. Integrated routing makes this harder when you have different people responsible for different protocols. You only wind up increasing the amount of coordination required to build and manage networks. This is NOT a technical problem - this is a sociology problem. Networking is 90% sociology and 10% technology. We need to be working on optimizing network systems for where the real effort is being spent. Also without specifically trying to, this would also solve Jack Houldsworths IPng convergence need for CLNP as the ISO liaison and FIRPs need I think too. And continue to keep momentum for TCP/IP. As captain Kirk used to say this could be a win-win scenario or was that Mr. Rogers. This might be nice, but it won't solve the users' problems. The main issue as I stated in my FIRP talk is the applications. Why do we have Novell and Appletalk as such dominant protocols today? Their elegance at their lower layers? Their advanced networking routing architectures? Their network management? No! Because people build applications that ran on top on them which were simple, and outclassed most of the open protocol's applications in both ease of use and cost of deployment. I am sorry to say that the future for proprietary protocols looks extremely promising, because folks are still looking at the lower layers as the entire world, not realizing that people will drag along any lower layer that is associated with the application suite they want. They don't care about integrated routing or scaling, etc... They want their M: drive mounted without having to type 4 lines of commands! IPng is not going to determine whether or not we can converge to one protocol - it's going to be if the proprietary applications get outclassed by open interoperable ones. We have a long way to go before this looks even possible, much less probable. Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 06:52:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00438; Fri, 15 Apr 1994 05:17:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA23577; Fri, 15 Apr 1994 05:16:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA23545; Fri, 15 Apr 1994 04:56:51 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29431; Fri, 15 Apr 1994 04:58:07 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA14826; Thu, 14 Apr 1994 11:57:16 -0700 Date: Thu, 14 Apr 1994 11:57:16 -0700 From: Tony Li Message-Id: <199404141857.LAA14826@lager.cisco.com> To: dennis@ans.net Cc: big-internet@munnari.OZ.AU In-Reply-To: Dennis Ferguson's message of Thu, 14 Apr 1994 10:25:29 -0400 <199404141425.AA97714@foo.ans.net> Subject: Turnipp - a merger proposal I think we should be clear that IS-IS is also not without a serious limitation in need of repair, however. Most certainly agreed. However, this is orthogonal to the IPng decision. I believe that Chris Gunner is already working on this. Hence we have OSPF, which is free of architected-in size limitations but which is single-protocol, and IS-IS, which is multiprotocol but which has a fetish for unreasonably small integer fields. Either, or both, of these protocols can be fixed to have their limitations removed, but unless I'm missing something I don't see how the repaired IS-IS is going to be any more backwards-compatible, and friendly to existing implementations, than a repaired OSPF. I expect that we'll have a repaired ISIS deployed long before IPng actually gets deployed. Thus we deal with the compatibility problems earlier on. I don't have strong opinions for or against either of them (I prefer how OSPF handled many of the details of the protocol, but in a practical sense I much prefer basic functionality to details) but I don't quite understand the exclusive focus on IS-IS. Both IGPs are imperfect, your justification above ignores the fact that IS-IS needs work too. Well, ya sorta gotta pick one. I view integrated routing as a very big carrot, so I prefer the one that's closer to Utopia as a base. Tony From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 06:55:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28960; Fri, 15 Apr 1994 04:48:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA23518; Fri, 15 Apr 1994 04:45:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA23456; Fri, 15 Apr 1994 04:26:18 +1000 Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26790; Fri, 15 Apr 1994 04:00:01 +1000 (from dino@cisco.com) Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA06688; Thu, 14 Apr 1994 10:56:05 -0700 Date: Thu, 14 Apr 1994 10:56:05 -0700 From: Dino Farinacci Message-Id: <199404141756.KAA06688@feta.cisco.com> To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU In-Reply-To: bound@zk3.dec.com's message of Thu, 14 Apr 94 11:21:51 -0400 <9404141521.AA04641@xirtlu.zk3.dec.com> Subject: Routers vs Hosts needs for Networking >> I don't believe ISIS will work as is for an IPng 'merger'. It and ES-IS >> make assumptions regarding the model of distributed computing regarding >> servers on the network, host IGP routing, autoconfiguration, and system >> discovery that I think need to be looked at in technical detail. For This is absolutely not true when you run IS-IS with IP. IS-IS does not do host IGP routing for IP hosts. >> discovery that I think need to be looked at in technical detail. For >> example the idea of Areas supporting a subnet (in IP terms) spanning >> multiple links is not necessary and may not even be good. I think from Of course it is not a good idea to have an area per subnet. But configuring an area per collection of subnets (ideally comprises a network), then the network number only is summarized out of the area into the level-2 backbone. >> market that are not dictated to by routers. For example the network >> layer greeting strategy (advertisment and solicitation) needs review if >> it were to be the IPng integrated routing protocol. Sorry, reset please. Go look at how IS-IS is used for IPv4. There is no reason why the same approach cannot be used for SIPP. In fact, you create a new TLV for LSPs (as Tony and Yakov have mentioned for IDRP) and nothing else in the protocol has to change. >> I hear what all are saying about PIM. But I would like to hear from >> Steve Deering, Van Jacobson, and others on this magic happening and with >> IS-IS. I also think we need to hear from Dave Clark on the issue he PIM and IS-IS have no intimate knowledge about each other and don't care about each other. In a nutshell, PIM does an RPF check to determine if it should forward a multicast packet. The RPF check is a unicast routing table lookup. If the next-hop to the source is learned via RIP, OSPF, IS-IS, so what. If the next-hop interface is equal to the incoming interface the multicast packet was received on, forward the packet. >> And finally I think Paul Francis has done a real good job with SIPP >> routing spec and I am curious what can be learned from that strategy >> that could be added to a new IPng integrated routing protocol. So I >> guess I don't believe IS-IS is ready to be this until I do and hear more >> analysis. And as Milo stated its not like we have IS-IS all over the You have a right to your opinion. >> analysis. And as Milo stated its not like we have IS-IS all over the >> market and its been around for awile and even with government mandates >> its still not pervasive. I don't believe its all political. I also >> believe it forces strategies on hosts that do not support the IP model >> of cooperative anarchy. You can discount cisco's customer base if you want, but we have customers running IS-IS. In CLNP only shops, used in ships-in-the-night mode with OSPF in CLNP and IP shops, in integrated mode with IP, OSI, and DECNET Phase IV, and even some Internet sites use it, it is used, and therfore requires support. IS-IS is very real to us. We should not discount OSPF because IGRP is more pervasive, should we? Dino From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 07:10:56 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29894; Fri, 15 Apr 1994 05:07:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02932 Fri, 15 Apr 1994 04:46:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA23488; Fri, 15 Apr 1994 04:42:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA23459; Fri, 15 Apr 1994 04:36:05 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28448; Fri, 15 Apr 1994 04:37:23 +1000 (from medin@nsipo.nasa.gov) Received: from cincsac.arc.nasa.gov by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02801 Fri, 15 Apr 1994 04:37:20 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (8.6.8/1.5T) id LAA13707; Thu, 14 Apr 1994 11:34:47 -0700 Message-Id: <199404141834.LAA13707@cincsac.arc.nasa.gov> To: "Peter S. Ford" Cc: Tony Li , big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Thu, 14 Apr 94 08:21:51 MST." <199404141421.IAA06603@goshawk.lanl.gov> Date: Thu, 14 Apr 94 11:34:47 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Peter, while it's true that you could view integrated routing and using the same routing protocol for multiple protocols as orthogonal, I just don't see any margin in doing so. If you aren't going to do integrated routing, then why try and mash every protocol's routing under the one umbrella? Either this will result in such a compromise that it's uniformly mediocre in which case noone will want to run it, or that it's so complex that noone will be able to implement it right. The different protocol suites all have different people (more or less) that work on them. You now have to get all these people to work together, and tie the protocol evolution of all these disparate protocols together on one path. This just doesn't seem practical to me. Again, the crux of the issue seems to be what problem you are trying to solve. I don't believe multiple routing protocols is the real problem we who run multiprotocol networks suffer from. It's being able to deal with the protocol specific transports, software interactions, etc... That's what is taking up so many people's time. If we could get proprietary applications running on top of TCP transport, then you've solved a LOT of these problems, and you don't need multiple routing protocols at all, you just use whatever you run for IP. The real problem is the multiple protocols themselves. The real need that drives this in the first place is in the applications, and that's where this problem needs to be resolved. I'm a lower layers type of guy myself, and I tend to view problem solving as requiring lower layer issues to be resolved. But when you look at it, you see that's a minor issue, and that we need to solve it higher up in the food chain. If it's fixed there, then it'll also fix the problems we have with multiprotocol issues down here. Well, enough of Big-Internet responding today - I have real work to do! You know, that 90% of networking that's sociology! :-) It's higher in the Government anyway. :-) Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 07:23:55 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29900; Fri, 15 Apr 1994 05:07:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02949 Fri, 15 Apr 1994 04:48:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA23503; Fri, 15 Apr 1994 04:44:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA23453; Fri, 15 Apr 1994 04:26:12 +1000 Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26761; Fri, 15 Apr 1994 03:59:16 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (8.6.8/1.5T) id KAA13674; Thu, 14 Apr 1994 10:55:18 -0700 Message-Id: <199404141755.KAA13674@cincsac.arc.nasa.gov> To: Tony Li Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Wed, 13 Apr 94 23:50:29 PDT." <199404140650.XAA06234@lager.cisco.com> Date: Thu, 14 Apr 94 10:55:17 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Or perhaps people are basing these statements on the incredible suc cess of integrated IS-IS in the marketplace? :-) As a matter of fact, yes. There are several regionals that are using integrated ISIS as their IGP. The marketplace likes integrated routing, especially since the market turned on multiple LS protocols in the same box and saw no point in doing that.... Interesting. I thought most of the regionals still ran IGRP. In any case, I'd bet that in your customer base you still have a lot more people running IGRP than anything else, and you look at the marketplace overall, I bet you will find a lot more OSPF in use that integrated IS-IS. I don't believe it's been tremedously successful, but the DEC folks would probably have the most info on this since they've been pushing it for the longest time. Integrated routing is not human friendly. Integrated routing is a HELL of a lot more friendly than SIN routing. Saying that doesn't make it so. Most of the network people I deal with who run multiprotocol networks tend to partition their engineering staff into protocol types (NSI has engineers who really know DECNet IV well, and work on costing of links and area routing, and don't do nearly as much on the IP side, and we have a totally different group of folks who know Appletalk). At other NASA centers, you'll find people with titles like "Novell manager", and "XNS manager", and "SNA manager"... This gets into organizational issue of how people do their work and manage their networks. Proposals which may be technically elegant tend not to fly if they are at odds with how the customers do their job. Besides, what makes you think all these proprietary system vendors are going to give up their own proprietary simple routing protocols ? Nobody said that they have to. But those simple routing protocols don't have the same features that a more mature routing protocol has. True, but people still buy them and force the WAN guys to carry them. This has to do with the crack dealers' approach to networking. You get someone started off cheaply. and then once they are hooked, you stick it to them. These simple protocols tend to be cheap to implement, and so people start off with them, and then they grow and expand and then cause a problem because they don't scale. But that doesn't mean that you can sell a solution that does scale to these users on day one. They view it as uncessarily complex. Cisco is working on PIM now (but is also implementing MOSPF), False, we are NOT currently implementing MOSPF. My langauge was ambigious. I believe that you WILL be implementing MOSPF, or so your boss has promised to me. It'll be out after your PIM stuff is out, but you will be doing MOSPF in any case. That's important for us, since we have a multivendor network, but alas, this is getting off the track... thanks, Milo From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 08:11:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07177; Fri, 15 Apr 1994 08:11:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA23859; Fri, 15 Apr 1994 08:10:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA23845; Fri, 15 Apr 1994 08:08:39 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04826; Fri, 15 Apr 1994 07:15:06 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA04466; Thu, 14 Apr 94 17:14:47 EDT Message-Id: <9404142114.AA04466@tipper.oit.unc.edu> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Subject: Re: Cisco Future IGPs In-Reply-To: Your message of "Thu, 14 Apr 94 17:34:40 GMT." <2213.bill.simpson@um.cc.umich.edu> Date: Thu, 14 Apr 94 17:14:46 -0400 From: Simon E Spero . Illegal defence warning - Is this strictly relevant to big-internet? From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 08:44:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05599; Fri, 15 Apr 1994 07:36:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA23792; Fri, 15 Apr 1994 07:35:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA23778; Fri, 15 Apr 1994 07:18:58 +1000 Received: from aotearoa.sura.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05019; Fri, 15 Apr 1994 07:20:14 +1000 (from sherk@sura.net) Received: from localhost by barsoom.sura.net with SMTP (5.67b/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id AA11756; Thu, 14 Apr 1994 17:20:06 -0400 Message-Id: <199404142120.AA11756@barsoom.sura.net> To: "Milo S. Medin" (NASA ARC NSI Office) Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 14 Apr 1994 11:17:59 PDT." <199404141817.LAA13692@cincsac.arc.nasa.gov> Date: Thu, 14 Apr 1994 17:20:05 -0400 From: Erik Sherk > Router vendors have sold multiprotocol router solutions to customers > for some time now, quite successfully. Almost all of these implementations > have been done using SIN routing. Groups who manage these networks support > different protocol suites differently. It's important to have a DECNET > or Appletalk guy who knows the routing, management, transport and software > configuration issues in order to solve problems in those networks. If you > have integrated routing, you still need this guy, but now he has to > coordinate routing changes with the IP guy and other folks. Solving problems > effectively means end to end debugging. Integrated routing makes this harder > when you have different people responsible for different protocols. You > only wind up increasing the amount of coordination required to build and > manage networks. Milo, It has been my experience that there are a lot more small shops out there where they only have one person who does the "network stuff". Situations where there is a IP guy, an AT guy and a SNA guy seem pretty few and far between. In addition, in theory SIN separates the different protocols. In practice, these protocols are running in the same router and they are competing for the same CPU, memory and other resources. If the different network protocols are using the same routing protocol, then at least you have a chance at observing any untoward interaction. This isn't the case for SIN. I have never seen a router that is instrumented for observing routing protocol interactions. Erik From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 08:44:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05751; Fri, 15 Apr 1994 07:38:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA23807; Fri, 15 Apr 1994 07:37:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA23764; Fri, 15 Apr 1994 07:00:41 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00886; Fri, 15 Apr 1994 05:30:08 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA27046; Thu, 14 Apr 94 12:21:49 -0700 Received: by xirtlu.zk3.dec.com; id AA10276; Thu, 14 Apr 1994 15:21:47 -0400 Message-Id: <9404141921.AA10276@xirtlu.zk3.dec.com> To: Dino Farinacci Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 14 Apr 94 10:25:04 PDT." <199404141725.KAA04351@feta.cisco.com> Date: Thu, 14 Apr 94 15:21:41 -0400 X-Mts: smtp >> There are two carrots the customer will look for in an IPng. First what >> does it do for me today at a reasonable cost. This could be >> autoconfiguration, multicast, autoregistration, ease of porting their >> existing applications etc. The second carrot is what is the principles >> and architecture behind IPng. If IPng can afford them a future >> transition of their protocols to an integrated IGP then this will gain >> their interest. >Again, if we use this logic, IPv4 has all the carrots you state except >for one big carrot - longer addresses. IPv4 I think will have a hard time with flows. I believe this because I believe in Flow IDs and do not believe they should be an option but in the actual header. We are doing this because at some point IPv4 addresses will run out. While we are doing this we can make the first list of carrots better and the header and other parts of the protocol more efficient and robust (at least) I hope we can. >You should know as well as I, that IPng will be reaching (we hope) more >people that are less knowledgable about networking. If you tell them >that they get an integrated IGP, you think they will 1) understand what >it is, 2) know if it is important, or 3) not worry about it because >it's their vendor's problem. I agree about reaching more people. But I cannot forget all the large customers who may buy 2000 Workstations and 5,000 PCs in the next 2 years. These customers have very qualified networking personnel who do look at what an I-IGP would provide for them in their network architecture and they are starting to come to the IETF too, and in some cases have been around the IETF for awhile. But I do see your point. I know a person who has a resturant and uses the Internet he does not care about IGPs or TCP/IP for that matter. But he only spends max about $2K per 2 years with vendors. Not that he is not important but he is not the only customer. Also and IGP gives the vendor a lot of nice ways to solve customers network problems too. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 10:01:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08224; Fri, 15 Apr 1994 08:47:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA23903; Fri, 15 Apr 1994 08:45:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA23875; Fri, 15 Apr 1994 08:16:47 +1000 Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03580; Fri, 15 Apr 1994 06:43:36 +1000 (from dino@cisco.com) Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA15501; Thu, 14 Apr 1994 13:39:25 -0700 Date: Thu, 14 Apr 1994 13:39:25 -0700 From: Dino Farinacci Message-Id: <199404142039.NAA15501@feta.cisco.com> To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU In-Reply-To: bound@zk3.dec.com's message of Thu, 14 Apr 94 16:10:41 -0400 <9404142010.AA11657@xirtlu.zk3.dec.com> Subject: Routers vs Hosts needs for Networking >> Sounds good I don't see why people are bothering then with anything >> else but PIM. But they are? Why? DVMRP is out there now on MBONE. The MBONE is growing so you can't ignore DVMRP. MOSPF has been available as a protocol spec for some time. It works well for multicast in OSPF networks. It has shortest path multicast routing, never introduces duplicates and converges very fast at a moderate/high cost of CPU utilization in routers. CBT and PIM are trying to address the scalability issue of multicast routing in very large internets. >> No we cannot. But there are more customers in the market opportunity >> running IP than CLNP. And IS-IS does nothing for them. There are different >> customers with different needs and I am not disputing that. What I >> question is if IS-IS was so compatible with the IP environment why >> does OSPF exist at all for IP. Look Jim, both protocols have there weaknesses as Dennis points out. IS-IS can carry around IP addresses just like OSPF and both have the same convergence properties. People use IS-IS for IP-only shops if they envision using it for other protocols they might add to the backbone. OSPF was created because ANSI designed IS-IS for CLNP. Dual IS-IS came later. Talk to your cohorts at DEC and ask them why it wasn't originally designed with IP in mind. >> Maybe? But then I believe OPEN is best if it avoids vendor lock-in >> personally. Why don't you offer IGRP to the IETF as Sun has done >> with RPC? We tried and it got shot down. >> But my main point was can we use IS-IS and OSPF to build an >> integrated routing protocol and we got off track into IS-IS. And many people responded that IS-IS is more extensible in its current form then OSPF is in its current form. >> But after reading Milo's mail I must say I am more skeptical >> about bothering now. Which takes us back to the original >> goal IPng is to solve the internetworking problem of TCP/IP >> and the problems facing IPv4 address space and routing table >> explosion and provide some key new emerging new technology as a >> carrot. Don't forget Milo was one of the OSPF designers. >> Oh Well....I am done on this one. I'm off this thread. I think Dennis hit the nail right on the head. Dino From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 10:02:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08304; Fri, 15 Apr 1994 08:49:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA23918; Fri, 15 Apr 1994 08:47:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA23878; Fri, 15 Apr 1994 08:16:57 +1000 From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02698; Fri, 15 Apr 1994 06:20:49 +1000 (from bound@zk3.dec.com) Received: from inet-gw-1.pa.dec.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04353 Fri, 15 Apr 1994 06:20:19 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA29793; Thu, 14 Apr 94 13:10:48 -0700 Received: by xirtlu.zk3.dec.com; id AA11657; Thu, 14 Apr 1994 16:10:47 -0400 Message-Id: <9404142010.AA11657@xirtlu.zk3.dec.com> To: Dino Farinacci Cc: big-internet@munnari.OZ.AU Subject: Re: Routers vs Hosts needs for Networking In-Reply-To: Your message of "Thu, 14 Apr 94 10:56:05 PDT." <199404141756.KAA06688@feta.cisco.com> Date: Thu, 14 Apr 94 16:10:41 -0400 X-Mts: smtp >> I don't believe ISIS will work as is for an IPng 'merger'. It and ES-IS >> make assumptions regarding the model of distributed computing regarding >> servers on the network, host IGP routing, autoconfiguration, and system >> discovery that I think need to be looked at in technical detail. For >This is absolutely not true when you run IS-IS with IP. IS-IS does not >do host IGP routing for IP hosts. I dont know of a single host vendor that connects two customer LANs with IS-IS as they do with with IP routing. The model is not used. And I was talking about IS-IS with IPng. >> market that are not dictated to by routers. For example the network >> layer greeting strategy (advertisment and solicitation) needs review if >> it were to be the IPng integrated routing protocol. >Sorry, reset please. Go look at how IS-IS is used for IPv4. There is no >reason why the same approach cannot be used for SIPP. In fact, you >create a new TLV for LSPs (as Tony and Yakov have mentioned for IDRP) >and nothing else in the protocol has to change. Good point but it will not work as is with the SIPP model. A model I believe is a good one in IPng scheme of things. Again my personal opinion. The ESH packets are not the same for starters. >> I hear what all are saying about PIM. But I would like to hear from >> Steve Deering, Van Jacobson, and others on this magic happening and with >> IS-IS. I also think we need to hear from Dave Clark on the issue he >PIM and IS-IS have no intimate knowledge about each other and don't care >about each other. In a nutshell, PIM does an RPF check to determine if it >should forward a multicast packet. The RPF check is a unicast routing table >lookup. If the next-hop to the source is learned via RIP, OSPF, IS-IS, so >what. If the next-hop interface is equal to the incoming interface the >multicast packet was received on, forward the packet. Sounds good I don't see why people are bothering then with anything else but PIM. But they are? Why? >> analysis. And as Milo stated its not like we have IS-IS all over the >> market and its been around for awile and even with government mandates >> its still not pervasive. I don't believe its all political. I also >> believe it forces strategies on hosts that do not support the IP model >> of cooperative anarchy. >You can discount cisco's customer base if you want, but we have customers >running IS-IS. In CLNP only shops, used in ships-in-the-night mode with >OSPF in CLNP and IP shops, in integrated mode with IP, OSI, and DECNET >Phase IV, and even some Internet sites use it, it is used, and therfore >requires support. IS-IS is very real to us. No we cannot. But there are more customers in the market opportunity running IP than CLNP. And IS-IS does nothing for them. There are different customers with different needs and I am not disputing that. What I question is if IS-IS was so compatible with the IP environment why does OSPF exist at all for IP. >We should not discount OSPF because IGRP is more pervasive, should we? Maybe? But then I believe OPEN is best if it avoids vendor lock-in personally. Why don't you offer IGRP to the IETF as Sun has done with RPC? But my main point was can we use IS-IS and OSPF to build an integrated routing protocol and we got off track into IS-IS. But after reading Milo's mail I must say I am more skeptical about bothering now. Which takes us back to the original goal IPng is to solve the internetworking problem of TCP/IP and the problems facing IPv4 address space and routing table explosion and provide some key new emerging new technology as a carrot. But Eric pointed out exactly why I think its still an issue. Oh Well....I am done on this one. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 13:08:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14596; Fri, 15 Apr 1994 11:43:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA24074; Fri, 15 Apr 1994 11:40:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA24049; Fri, 15 Apr 1994 11:21:03 +1000 Received: from diablo.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13828; Fri, 15 Apr 1994 11:22:20 +1000 (from pfortin@cisco.com) Message-Id: <9404150122.13828@munnari.oz.au> Received: from dallas-dynamic-135.cisco.com by diablo.cisco.com with SMTP (1.37.109.8/16.2) id AA00354; Thu, 14 Apr 1994 18:21:09 -0700 Date: Thu, 14 Apr 1994 18:21:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Dino Farinacci , bound@zk3.dec.com From: pfortin@cisco.com (Pierre Fortin) Subject: Re: Routers vs Hosts needs for Networking Cc: big-internet@munnari.OZ.AU At 1:39 PM 4/14/94 -0700, Dino Farinacci wrote: >>> Maybe? But then I believe OPEN is best if it avoids vendor lock-in >>> personally. Why don't you offer IGRP to the IETF as Sun has done >>> with RPC? > > We tried and it got shot down. Should we try again? It sure would have made my life easier when I was a customer... (before you ask: I would not have wasted lots of cycles defending its use over OSPF based pretty much only on the latter's "but it's the standard" argument.) Back to lurk. Pierre From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 14:01:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20701; Fri, 15 Apr 1994 14:01:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA24195; Fri, 15 Apr 1994 14:00:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA24170; Fri, 15 Apr 1994 13:38:38 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19737; Fri, 15 Apr 1994 13:39:46 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 15 Apr 94 12:34:07 +0900 From: Masataka Ohta Message-Id: <9404150334.AA13441@necom830.cc.titech.ac.jp> Subject: Re: Turnipp - a merger proposal To: bound@zk3.dec.com Date: Fri, 15 Apr 94 12:34:05 JST Cc: tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <9404141424.AA02875@xirtlu.zk3.dec.com>; from "bound@zk3.dec.com" at Apr 14, 94 10:24 am X-Mailer: ELM [version 2.3 PL11] > >It seems to me that Turnipp is just another catnip and is redundant. > So do you believe CATNIP can solve what TURNIP is suggesting as a > 'merger'? No. My point is that Turnipp is not a merger but a proposal whose goal is equivalent to that of CATNIP, that is, support everything but not so cleanly. Masataka Ohta PS Does everybody think IS-IS fruits to motivate people deploy IPng? From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 15:11:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23693; Fri, 15 Apr 1994 15:11:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA24270; Fri, 15 Apr 1994 15:10:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA24245; Fri, 15 Apr 1994 14:51:48 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23010; Fri, 15 Apr 1994 14:51:58 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA29793; Thu, 14 Apr 94 21:46:18 -0700 Received: by xirtlu.zk3.dec.com; id AA18003; Fri, 15 Apr 1994 00:46:16 -0400 Message-Id: <9404150446.AA18003@xirtlu.zk3.dec.com> To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Fri, 15 Apr 94 12:34:05 +0200." <9404150334.AA13441@necom830.cc.titech.ac.jp> Date: Fri, 15 Apr 94 00:46:10 -0400 X-Mts: smtp >>>It seems to me that Turnipp is just another catnip and is redundant. >> So do you believe CATNIP can solve what TURNIP is suggesting as a >> 'merger'? >No. My point is that Turnipp is not a merger but a proposal whose >goal is equivalent to that of CATNIP, that is, support everything >but not so cleanly. > Masataka Ohta Thank You. >PS >Does everybody think IS-IS fruits to motivate people deploy IPng? Not me. /jim From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 17:31:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29639; Fri, 15 Apr 1994 17:31:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA24411; Fri, 15 Apr 1994 17:30:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA24397; Fri, 15 Apr 1994 17:23:58 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27187; Fri, 15 Apr 1994 16:31:01 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA21815; Thu, 14 Apr 1994 23:30:56 -0700 Date: Thu, 14 Apr 1994 23:30:56 -0700 From: Tony Li Message-Id: <199404150630.XAA21815@lager.cisco.com> To: pfortin@cisco.com (Pierre Fortin) Cc: Dino Farinacci , bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Routers vs Hosts needs for Networking At 1:39 PM 4/14/94 -0700, Dino Farinacci wrote: >>> Maybe? But then I believe OPEN is best if it avoids vendor lock-in >>> personally. Why don't you offer IGRP to the IETF as Sun has done >>> with RPC? > > We tried and it got shot down. Should we try again? It sure would have made my life easier when I was a customer... (before you ask: I would not have wasted lots of cycles defending its use over OSPF based pretty much only on the latter's "but it's the standard" argument.) Actually, we did try again. I offered EIGRP as the DV routing protocol for SIPP in Amsterdam. People were polite. They want their RIP. As Kirk says: "Don't fall in love with your technology. It doesn't last a lifetime." Tony From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 18:09:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01402; Fri, 15 Apr 1994 18:07:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA24452; Fri, 15 Apr 1994 18:05:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA24427; Fri, 15 Apr 1994 17:37:03 +1000 Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29977; Fri, 15 Apr 1994 17:38:07 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by dscs.arc.nasa.gov (8.6.8/1.5T) id AAA18907; Fri, 15 Apr 1994 00:38:01 -0700 Message-Id: <199404150738.AAA18907@dscs.arc.nasa.gov> To: "Peter S. Ford" Cc: big-internet@munnari.OZ.AU Subject: Re: Future IGPs In-Reply-To: Your message of "Thu, 14 Apr 94 13:52:32 MST." <199404141952.NAA11230@goshawk.lanl.gov> Date: Fri, 15 Apr 94 00:38:00 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) ... Milo, Since the lower layer issues are done with, then I assume we can kill off the B-I list ... I do agree with you that a single internal gateway routing protocol do es not solve *the* multiprotocol Internet problem. My position is that it is not a bad thing. Yours is that this can not be done. I would argu e that empirical evidence supports my side and will concede that your assertions are more emphatic then mine. No Contest. I didn't say it couldn't be done, merely that it would be hard to do well. :-) That is, either it's such a compromise as to do nothing very well, or it's so complicated that it will be nearly impossible to implement well. I'm not sure that my assertions are more emphatic than yours, but I'm always more comfortable operating at the extremes in any case. ;-) Imagine what a routing protocol would look like that could route native SNA, Appletalk, and IP all in one package. It's pretty scary. I do like the vision you present for merging protocol suites. What ma ny would say is this is equivalent to how you get from IPv4 to IPng, but you are raising the stakes to : {IPv4, IPX, AT (I know you own a DUO), DEC, CLNP} --> IPng. I believe this is a good idea. What I would like to see ("Somewhere over the Rainbow" is playing in the background) is that those parties see IPng of such tremendous value that they figure out how to transition their apps and services to IPng. (Music volume is increasing) Transition strategies that work for IPv4 -> IPng may even be applicable with ProtXXX -> IPng. I won't argue much with this, but again, your example mentions the lower layers, where my emphasis is on the higher layers alone. For example, if AFP ran over a TCP transport, you wouldn't have to figure out how to get an AT packet to be routed by IP (or IPng if you will); you are always dealing with a native IP message. This is sort of what happens with Netware/IP, where netware protocols are running over UDP/IP (I think this still misses the mark, since it still ends up with the Novell transport layer being involved, and I'd prefer to see that gutted as well, but it's a step in the right direction...). If IPng had better capabilities for resource location, etc..., this might be easier than it would be for IPv4, but there is nothing that prevents folks from solving this problem now. I would prefer to attack the proprietary protocols in this way today, and not have to wait for IPng. The bulk of the work to be done is at the Apps level, and I think that Erik is committed to leading the charge here. We should avoid trying to pile all the problems we need to address into the IPng area - there is plenty of work to go around. What many of us have argued is that we should take this kind of evolut ion into account when coming up with the addressing structure for IPng. T he net result for us is the use of NSAPs, as documented in Catnip, Turnip p etc. This may facilitate transition/coexistence strategies that use p acket translation. Well, that's quite a leap for me to understand. You are saying that the network address semantics for NSAP's make application porting over IPng transport easier. I don't see that correlation, at least not for something like NSAP addresses. Nimrod and some of the more 'radical' proposals probably offer better options in this area. NSAP's are too similiar to CIDR'ized IPv4 addresses to be of much marginal gain in the application fight. Milo, it is always a pleasure when we find common ground. It's probably our common heritage working at weapons' labs no doubt. :-) Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 20:16:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04023; Fri, 15 Apr 1994 19:16:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA24527; Fri, 15 Apr 1994 19:15:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA24502; Fri, 15 Apr 1994 18:48:56 +1000 Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01471; Fri, 15 Apr 1994 18:09:35 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by dscs.arc.nasa.gov (8.6.8/1.5T) id BAA19021; Fri, 15 Apr 1994 01:04:56 -0700 Message-Id: <199404150804.BAA19021@dscs.arc.nasa.gov> To: Dino Farinacci Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Routers vs Hosts needs for Networking In-Reply-To: Your message of "Thu, 14 Apr 94 13:39:25 PDT." <199404142039.NAA15501@feta.cisco.com> Date: Fri, 15 Apr 94 01:04:55 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Dino, ... >> No we cannot. But there are more customers in the market opport unity >> running IP than CLNP. And IS-IS does nothing for them. There ar e different >> customers with different needs and I am not disputing that. Wha t I >> question is if IS-IS was so compatible with the IP environment w hy >> does OSPF exist at all for IP. Look Jim, both protocols have there weaknesses as Dennis points ou t. IS-IS can carry around IP addresses just like OSPF and both have t he same convergence properties. People use IS-IS for IP-only shops if they envision using it for other protocols they might add to the backbo ne. OSPF was created because ANSI designed IS-IS for CLNP. Dual IS-IS came later. Talk to your cohorts at DEC and ask them why it wasn't orig inally designed with IP in mind. Incorrect. We in the OSPF group didn't design OSPF because IS-IS didn't do IP. If that was the only problem, there would have been a number of ways to solve that problem without building a new protocol from scratch, which is exactly what happened with OSPF. Specific design decisions were made differently - how DR transitions work, routing in areas, how partitions are dealt with, security mods, summarization of routes at area boundaries, external routing information importation, optimization of next hops at AS boundaries, etc... There are a pile of differences, and the protocol was designed to optimize things that real world IP network operators had to deal with. It had heavy involvement through it's design (and it's evolution today, with multicast, and NSSA support) by network managers, attempting to solve the problems they were experiencing. Because both are link state protocols, there is a tendency to believe that political reasons were responsible for OSPF not being more like IS-IS. This just isn't accurate from a historical viewpoint. There is also the issue of control of the spec and being able to add things (like multicasting), that some people believe is much harder if you use a base OSI protocol (not controlled by the IETF). But that wasn't the issue for me. Personally, I think if you look at who worked for who and what they were working from when the protocols were designed, I'd say both were derivatives from the original BBN LS routing work done for the ARPANet. I remember an IETF meeting in Anapolis where Mike St. Johns had graciously provided the OSPF group with BBN technical reports about the LS protocols used for routing in the ARPANet/Milnet in fact. I think if you try and remember back that far, you'll recall a set of meetings where requirements were discussed and documentated, then an architecture ironed out, then a design, and then implementation and later refinement (in OSPF V2). >> Maybe? But then I believe OPEN is best if it avoids vendor lock -in >> personally. Why don't you offer IGRP to the IETF as Sun has don e >> with RPC? We tried and it got shot down. Well, I recall an IETF back at Stanford (I arrived late, just getting off a United flight flight from Honolulu, and arrived to find no less than 50 people running around with Milo Medin as the name on their IETF badge :-)), there was a rather "active" debate, about whether or not the IETF would have total royalty free access to the specification, and whether or not control would be turned over to the IETF. As I remember, cisco wasn't quite willing to go all the way in this direction, and then there was an interesting interchange between Mike Petry and Len Bosack, and various things were said, etc... My memory is quite good on such things, even though it was probably 5 years ago... :-) And you of course were doing a bang up job for 3com at the time... >> But my main point was can we use IS-IS and OSPF to build an >> integrated routing protocol and we got off track into IS-IS. And many people responded that IS-IS is more extensible in its cur rent form then OSPF is in its current form. Sure, because of certain decisions that were made to use fixed field formats in OSPF, vs the variable length and format of messages in IS-IS. That was a requirement that was defined in the requirements phase of the protocol development. >> But after reading Milo's mail I must say I am more skeptical >> about bothering now. Which takes us back to the original >> goal IPng is to solve the internetworking problem of TCP/IP >> and the problems facing IPv4 address space and routing table >> explosion and provide some key new emerging new technology as a >> carrot. Don't forget Milo was one of the OSPF designers. Why, thank you for the compliment! :-) My only real contribution was the tag field on external LSP's, which people initially didn't want to put in, since they knew a very capable new EGP was right around then corner that would solve our external routing problems. It was called EGP3 I think. But people decided to hedge their bets (and I wore everyone out in the meetings :-)), and left it in... Also, I recall you playing a very positive role in several of the OSPF meetings as well. A lot of people were involved, and I think the protocol is a lot better off because of that team effort. Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 20:17:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05007; Fri, 15 Apr 1994 19:51:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA24568; Fri, 15 Apr 1994 19:50:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA24554; Fri, 15 Apr 1994 19:26:10 +1000 Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02451; Fri, 15 Apr 1994 18:31:59 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by dscs.arc.nasa.gov (8.6.8/1.5T) id BAA19209; Fri, 15 Apr 1994 01:31:50 -0700 Message-Id: <199404150831.BAA19209@dscs.arc.nasa.gov> To: Erik Sherk Cc: big-internet@munnari.OZ.AU Subject: Re: Turnipp - a merger proposal In-Reply-To: Your message of "Thu, 14 Apr 94 17:20:05 EDT." <199404142120.AA11756@barsoom.sura.net> Date: Fri, 15 Apr 94 01:31:49 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) EriK, Milo, It has been my experience that there are a lot more small shops out there where they only have one person who does the "network stuff" . Situations where there is a IP guy, an AT guy and a SNA guy seem prett y few and far between. Well, that's true, but many of these smaller shops have a very simple network architecture that isn't going to stress router hardware or software anyway. The biggest win I see being advocated is that it's easier to manage a large network environment with an integrated routing protocol, rather than N seperate routing protocols. But the complexity that is required to make such a protocol work robustly and scale well in a large environment often makes it very unwieldly to run in the simple shops you mention. Smaller, simple DV protocols like RIP, and RTMP work very well in this environment. You can get really cheap small routers that run these well, or even have hosts do the job, and do it with much less hassle in the small shop than the monster integrated LS routing protocol would entail. The small shops don't have the problem that the do-all integrated protocol is going to be good at solving. Also, I have yet to see a facility where you have the SNA expert and the AT expert be the same person. It's a mushware issue. Usually, the SNA wiz is the VM system programmer, and the AT guy is the Quickmail administrator as well. In addition, in theory SIN separates the different protocols. In practice, these protocols are running in the same router and they are competing for the same CPU, memory and other resources. If the different network protocols are using the same routing protocol, then at least you have a chance at observing any untoward interaction. This isn't the case for SIN. I have never seen a router that is instrumented for observing routing protocol interactions. I've heard this argument made multiple times before. As I recall, the IS-IS spec calls for certain realtime parameters to be met that many systems used as routers today can't positively meet. In addition, routers today do a number of things. They'll be handling ATM signalling, SNA encapsulation or protocol translation, time synchornization, and not the least of which is network management. Since all these activities are going on at the same time, doesn't the line of reasoning you are espousing mean all of them should be wrapped up into the routing protocol too? I mean they all compete for the same CPU, memory, I/O bandwidth, etc.... These problems don't go away with integrated routing - you still have to solve them. And on top of this all, these pesky users actually expect you to spend time forwarding their packets! Imagine that! :-) And don't forget that we're just talking about the IGP here - there will still be an EGP to run. In many of the problem cases I've seen with poor protocol interactions and resource interference, it hasn't been appletalk fighting with an IP IGP as much as it is BGP or EGP updates hitting the router and it doing LS updates and route table merges, and filter processing all at once. We still have to run an EGP (unless we do something like NIMROD where there are no IGP's or EGP's), and that's going to be competing for cycles, memory, etc... On most of our routers, the external peering processes are the CPU dominant ones, not OSPF (being an IGP). I'm not saying there wouldn't be some benefit, but I doubt it'll be as much as you might think, and there will be trade offs made with complexity than argue for some compartmentalization of processes and code. I just think the negatives outweigh the positives in the real world out there that is running large networks. Alas, it's time for bed. :-) Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 23:04:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09448; Fri, 15 Apr 1994 22:11:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA24706; Fri, 15 Apr 1994 22:10:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA24686; Fri, 15 Apr 1994 22:08:27 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08492; Fri, 15 Apr 1994 21:42:14 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA29426; Fri, 15 Apr 94 06:42:45 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa02221; 15 Apr 94 11:34 GMT Date: Fri, 15 Apr 94 06:39 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Costs, Performance and IPng Message-Id: <31940415113913/0003858921NA3EM@mcimail.com> > ] My concern is that security (e.g. the lack of) in the Internet is > ] becoming the real limit to growth, not routing and addressing. > > Umm... perhaps. I will note that many people ignore the lessons > learned by others until it happens to them, and hence security may > not be a very strong factor in limiting growth. >How many people have explicitly decided to not connect to the >Internet? Perhaps because of security? Corps whose management listens to the Gardner Group. Or rather they firewall their connectivity and they limit who can do what. Bob From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 23:04:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09516; Fri, 15 Apr 1994 22:14:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA24721; Fri, 15 Apr 1994 22:13:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA24689; Fri, 15 Apr 1994 22:08:43 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08463; Fri, 15 Apr 1994 21:41:36 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA29409; Fri, 15 Apr 94 06:42:08 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa02175; 15 Apr 94 11:33 GMT Date: Fri, 15 Apr 94 06:38 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Introducing proxy aggregations? Message-Id: <15940415113851/0003858921NA3EM@mcimail.com> >> I would imagine that given the choice of investing new money in routers >> or switching to a service provider that won't require them to change >> their existing configuration, most end-customers would simply switch >> providers. >Just out of interest, I assume this provider switch would mean they'd >have to renumber, or are you suggested that the new provider would allow >them to keep their old addresses? If so, how would we *ever* get >aggregation to work? This sounds like X.400 addresses. Once you commit to a VAN, you are committed forever, who wants to change everyone's Business card. This argues for 1597 today so that only the firewall addresses need to change and a SIPP like structure for IPng so that only the prefix needs to change. Or does this issue go away with IPng? Bob (still a week behind...) From owner-Big-Internet@munnari.OZ.AU Fri Apr 15 23:05:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09578; Fri, 15 Apr 1994 22:16:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA24736; Fri, 15 Apr 1994 22:14:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA24692; Fri, 15 Apr 1994 22:08:47 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08461; Fri, 15 Apr 1994 21:41:35 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA29412; Fri, 15 Apr 94 06:42:10 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab02175; 15 Apr 94 11:33 GMT Date: Fri, 15 Apr 94 06:39 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Costs, Performance and IPng Message-Id: <30940415113903/0003858921NA3EM@mcimail.com> > I haven't heard anyone bring requirements specifically to support >firewalls and hence would like to see it dropped from consideration as >a potential criterion. My reading of the very rough consensus is that it >is important that IPng not _prevent_ firewalls, which should be a fairly >easy requirement to meet. You people seem to be missing something important about firewalls and security. I keep hearing that 'if the protocol is secure, we can eliminate firewalls'. I don't buy it. There is a discussion going on right now on the firewall list about security holes in XMOSAIC. If an app like that can open me up to bombs, I'd want to control and limit who can run it from where. Again, MY auditors will require secure systems, secure apps, along with secure network protocols before they would agree to no firewalls. ERGO: IPng must not only not _prevent_ firewalls, it should make them easier. Bob Moskowitz Chrysler Corp IS Tech Services From owner-Big-Internet@munnari.OZ.AU Sat Apr 16 00:23:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12019; Fri, 15 Apr 1994 23:21:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA24808; Fri, 15 Apr 1994 23:20:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA24794; Fri, 15 Apr 1994 23:04:14 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10851; Fri, 15 Apr 1994 22:48:41 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03200; Fri, 15 Apr 1994 14:48:31 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA06804; Fri, 15 Apr 1994 14:48:30 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404151248.AA06804@dxcoms.cern.ch> Subject: Re: Costs, Performance and IPng To: big-internet@munnari.OZ.AU (bigi) Date: Fri, 15 Apr 1994 14:48:30 +0200 (MET DST) In-Reply-To: <30940415113903/0003858921NA3EM@mcimail.com> from "Robert G. Moskowitz" at Apr 15, 94 06:39:00 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 331 > > IPng must not only not _prevent_ firewalls, it should make them easier. > Dave Clark gave us the technical requirement in Seattle: IPng must support LLIDs (low-level IDs, which are slightly more generic than flow IDs). Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.OZ.AU Sat Apr 16 00:32:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14970; Sat, 16 Apr 1994 00:32:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA24891; Sat, 16 Apr 1994 00:30:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA24877; Sat, 16 Apr 1994 00:24:21 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14729; Sat, 16 Apr 1994 00:25:39 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09136; Fri, 15 Apr 94 10:25:34 EDT Date: Fri, 15 Apr 94 10:25:34 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404151425.AA09136@itd.nrl.navy.mil> To: big-Internet@munnari.OZ.AU Subject: IPng and firewalling Brian, Your note was not clear to me on (1) why the combination of port, protocol, source, destination, and flowID is not sufficient and (2) what a lower-level ID would look like if it is fundamentally different from the set of things in (1). I for one would appreciate clarification on what you think the specific requirement actually is. The I-D from the IAB leads me to believe that the set of information that I list above in (1) is sufficient. Best Regards, Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Sat Apr 16 02:10:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15101; Sat, 16 Apr 1994 00:37:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA24906; Sat, 16 Apr 1994 00:36:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA24874; Sat, 16 Apr 1994 00:21:38 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12465; Fri, 15 Apr 1994 23:34:32 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA00354; Fri, 15 Apr 94 06:29:08 -0700 Received: by xirtlu.zk3.dec.com; id AA26525; Fri, 15 Apr 1994 09:29:06 -0400 Message-Id: <9404151329.AA26525@xirtlu.zk3.dec.com> To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Routers vs Hosts needs for Networking In-Reply-To: Your message of "Thu, 14 Apr 94 23:30:56 PDT." <199404150630.XAA21815@lager.cisco.com> Date: Fri, 15 Apr 94 09:29:00 -0400 X-Mts: smtp Tony, >Actually, we did try again. I offered EIGRP as the DV routing >protocol for SIPP in Amsterdam. People were polite. They want their >RIP. Hmmm. I remember this. You proposed durig RIP discuss. I thought it was worth looking at technically. Then I was told it had to be reviewed by the IESG. If they thought it could work then we would have a technical discussion on the SIPP mailing list. Being brand new to the IETF process I just assumed that the IESG shot it down per legalities or something of that nature. I would have liked to have reviewed it technically. Anytime a pervasive defacto std can be stanardized with some tweeking is good for the world. Can you elaborate on what happen or folks just did not get back to you. thanks /jim From owner-Big-Internet@munnari.OZ.AU Sat Apr 16 02:12:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15296; Sat, 16 Apr 1994 00:40:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA24921; Sat, 16 Apr 1994 00:38:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA24871; Sat, 16 Apr 1994 00:19:35 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11849; Fri, 15 Apr 1994 23:18:02 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA11256; Fri, 15 Apr 94 06:19:46 -0700 Date: Fri, 15 Apr 94 06:19:46 -0700 From: Eric Fleischman Message-Id: <9404151319.AA11256@atc.boeing.com> To: bound@zk3.dec.com, mohta@necom830.cc.titech.ac.jp Subject: Re: Turnipp - a merger proposal Cc: big-internet@munnari.OZ.AU, tli@cisco.com Dear Big-internauts, An apology and a point of clarification: My mail message of yesterday was part of this thread. I did not intend to imply what Masataka is concluding below. That is, I do not claim that either OSPF or IS-IS are going to motivate people to deploy IPng. Rather, what motivates my users is powerful applications doing useful things. What motivates me is solid technology with integration into my installed base. My point yesterday was to address integration in general -- not SIN vs I-IS-IS. Integration is A Good Thing and is to be encouraged -- but not every technology designed to provide integration is of the same quality/utility (and some have been down-right disappointing). Ships-in-the-night or I-IS-IS, in my mind, are not motivators to deploy IPng (as they are currently defined) because this is not a situation where "one size fits all" (i.e., I can envision scenarios whereby each is preferable over the other). Rather, motivations for IPng need universal appeal. Sincerely yours, --Eric Fleischman >From: Masataka Ohta >Does everybody think IS-IS fruits to motivate people deploy IPng? From owner-Big-Internet@munnari.OZ.AU Sat Apr 16 03:07:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19071; Sat, 16 Apr 1994 02:16:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA25077; Sat, 16 Apr 1994 02:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA25063; Sat, 16 Apr 1994 02:09:05 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15452; Sat, 16 Apr 1994 00:44:26 +1000 (from jmh@anubis.network.com) Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA01391; Fri, 15 Apr 94 09:48:00 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA26421; Fri, 15 Apr 94 09:44:16 CDT Date: Fri, 15 Apr 94 09:44:16 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9404151444.AA26421@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? In commenting on "re-numbering" someone says it is like X.400, after all, who wants to change everyone's business cards. I will note that most businesses re-issue business cards much faster than they are used. We have re-issued them 3 times in the last 2 years. I will also note that re-numbering, while it has many problems, should have no effect on your reachability by external entities. Anyone establishing a new connection will use DNS to translate your name (which has not changed) to your new address. This leaves two issues with renumbering: 1) Getting the local hosts to change their notion of their own identity. IPv4 has many problems with this. All the IPng proposals have mechanisms intended to simplify this problem (often to the point of transparency). 2) Existing connections. If one assumes that the old addresses will continue to work for a while, one will not need to "correct" an existing TCP session (or UDP packet stream). After all, the aggregation will occur as long as people who change providers lose their old addresses after a relatively short while (3 months anyone)? Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation PS Note that while I refer to changing providers, whis works whether you are changing your number because you are changing providers, or because someone split your area code. All of the proposals, while they seem to assume provider based addressing, will work fine with geographic addressing if we find we want that. From owner-Big-Internet@munnari.OZ.AU Sat Apr 16 04:07:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21438; Sat, 16 Apr 1994 03:26:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA25155; Sat, 16 Apr 1994 03:25:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA25141; Sat, 16 Apr 1994 03:18:05 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21187; Sat, 16 Apr 1994 03:19:23 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 0634; Fri, 15 Apr 94 13:02:05 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 4602; Fri, 15 Apr 1994 13:02:05 -0400 Date: Fri, 15 Apr 94 12:57:34 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: while we're tuning up routing protocols To: Simon E Spero , estrin@usc.edu Cc: craig@aland.bbn.com, big-internet@munnari.OZ.AU In-Reply-To: <9404141640.AA03929@tipper.oit.unc.edu> Message-Id: <940415.125734.EDT.VALDIS@vtvm1.cc.vt.edu> On Thu, 14 Apr 94 12:40:59 -0400 you said: >With a dynamically reconfigurable network substrate, we could have a different >IPNG backbone for every day of the week - CLNP on Mondays, IPV7 on Tuesdays, >SIPP on Wednesdays; we could even make thursdays IPV4 nostalgia night. >With CLOS on every router, everyone's a winner. Simon: A very interesting concept. Of course, you'd then have to specify *when* the backbone would change each day. At midnight GMT? Inconvenient for those whos regular business hours are still in effect then. Midnight local time? Very sub-optimal for those T3 links that span 4 time zones. And of course, there's *no* way to deal with Newfoundland ;) Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Sat Apr 16 04:09:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21512; Sat, 16 Apr 1994 03:29:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA25170; Sat, 16 Apr 1994 03:28:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA25116; Sat, 16 Apr 1994 02:53:49 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20448; Sat, 16 Apr 1994 02:55:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04549; Fri, 15 Apr 94 12:54:55 -0400 Date: Fri, 15 Apr 94 12:54:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404151654.AA04549@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Routers vs Hosts needs for Networking Cc: jnc@ginger.lcs.mit.edu We in the OSPF group didn't design OSPF because IS-IS didn't do IP. ... there is a tendency to believe that political reasons were responsible for OSPF ... This just isn't accurate from a historical viewpoint. Well, this is all history, and it's too late to change it, and not really worth time going over, but let's get our facts straight. I imagine that there probably as many different reasons for doing OSPF as there were people working on it. I can tell you that the original concept of doing OSPF had nothing at all to do with IS-IS, ISO, DV, or anything at all like that. It all got started because Cisco was making a great sales play out of IGRP, making various claims about its superiority. Proteon needed something to go up against IGRP with, and that's how OSPF got started. Proteon was originally planning on doing it as a proprietary thing, to allow it to be done quickly, but on appeal (I think from Phill) it was decided to do it within the IETF context. Obviously, as time went on, the exact reasons for doing OSPF changed. The first big fights over OSPF (at the Washington IETF, as I recall) were between the DV fans and LS fans, not OSI/TCP, so that was a big factor in pushing it. To some degree there was bureacratic intertia; once having started a separate design, there was a tendency to continue. Later on, when the OSI/TCP wars got really going, there was a dust-up over which to use which got partially tangled up in the fight over which approach to multi-protocol internetworking (SIN or something else) was best. Of course these was a "not-OSI-and-done-by-the-IETF" component to the OSPF stuff, but exactly how strong is probably impossible to sort out in retrospect. It's also useful to remember that both protocols were in a state of flux that far back; when the OSPF effort started, IS-IS was just a proposal, not even a DIS, if memory serves. The two have changed, and influenced each other: OSPF copied the IS-IS lollipop sequence number space just as IS-IS decided to change it, etc. I think both have turned out better for that competition. Don't forget that the model many people had for networking as a whole back then was a TCP->OSI transition, and in that kind of environment, the tradeoffs all look different. Etc, etc, etc. It's really not very useful to look back and try and figure it all out, really; it was very complicated. Specific design decisions were made differently Yup. At the time of the IS-IS/OSPF debate (at the Florida IETF) I went through and produced a lengthy list of them. Some things that used to be different have changed; OSPF used to always inject level 2 info into a level 1 area (i.e. it did not support stub areas) to allow a non-continguous backbone. There are still important differences, for instance in the mechanism which imports external information is quite different. I'll have to defer to people using it in practise to say whether these differences are significant enough to be useful. Noel From owner-Big-Internet@munnari.OZ.AU Mon Apr 18 04:03:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17267; Mon, 18 Apr 1994 03:52:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA27455; Mon, 18 Apr 1994 03:50:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA27430; Mon, 18 Apr 1994 03:22:05 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15779; Mon, 18 Apr 1994 02:55:22 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28237; Sun, 17 Apr 94 09:55:18 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA25177; Sun, 17 Apr 94 09:54:27 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA20488; Sun, 17 Apr 1994 09:55:14 -0700 Date: Sun, 17 Apr 1994 09:55:14 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404171655.AA20488@jurassic.Eng.Sun.COM> To: Tony Li Cc: pfortin@cisco.com (Pierre Fortin), Dino Farinacci , bound@zk3.dec.com, big-internet@munnari.OZ.AU In-Reply-To: <199404150630.XAA21815@lager.cisco.com> Subject: Re: Routers vs Hosts needs for Networking Tony, > Actually, we did try again. I offered EIGRP as the DV routing > protocol for SIPP in Amsterdam. People were polite. They want their > RIP. This does not match my memory. I think there was serious interest. The minutes of the meeting state: "Tony Li then offered to provide SIP-IGRP, giving change control to the IETF of the SIP specific extensions! After considerable discussion, the w.g. agreed that this should be pursued, given the usual caveats about licensing agreements and change control." I recollect that we talked about it on the phone after the meeting and think we also had lunch. You were to take the proposal to your management. I think it is still in your court. I still think that turning IGRP into an IETF standard would be good. Issues about change control, license terms, etc. would have to be dealt with. Please give me a call (415 / 336-2082) next week if you want pursue this. I would be happy to help. Bob From owner-Big-Internet@munnari.OZ.AU Mon Apr 18 19:02:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19768; Mon, 18 Apr 1994 19:02:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA28190; Mon, 18 Apr 1994 19:00:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA28165; Mon, 18 Apr 1994 18:27:04 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16556; Mon, 18 Apr 1994 17:46:08 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24424; Mon, 18 Apr 1994 09:44:37 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03962; Mon, 18 Apr 1994 09:44:37 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404180744.AA03962@dxcoms.cern.ch> Subject: Re: IPng and firewalling To: big-internet@munnari.OZ.AU (bigi) Date: Mon, 18 Apr 1994 09:44:36 +0200 (MET DST) In-Reply-To: <9404151425.AA09136@itd.nrl.navy.mil> from "Ran Atkinson" at Apr 15, 94 10:25:34 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1087 Ran, This is not my area of expertise. My feeling (expressed in my IPng white paper) was originally exactly the same as yours. Dave Clark seemed to be asking for more semantics than just "Flow ID" and a new (forthcoming) white paper on IPng accounting also seems to ask for more. However, that mainly affects how the Flow ID is allocated, so in terms of packet headers I think you are correct. Presumably the Flow ID needs to be several bytes, however. Brian >--------- Text sent by Ran Atkinson follows: > > > Brian, > > Your note was not clear to me on > > (1) why the combination of port, protocol, source, destination, and flowID > is not sufficient > > and > > (2) what a lower-level ID would look like if it is fundamentally different > from the set of things in (1). > > I for one would appreciate clarification on what you think the > specific requirement actually is. The I-D from the IAB leads me to > believe that the set of information that I list above in (1) is > sufficient. > > Best Regards, > > Ran > atkinson@itd.nrl.navy.mil > From owner-Big-Internet@munnari.OZ.AU Tue Apr 19 02:37:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06939; Tue, 19 Apr 1994 02:37:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA28609; Tue, 19 Apr 1994 02:35:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA28584; Tue, 19 Apr 1994 02:09:42 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03709; Tue, 19 Apr 1994 01:16:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27417; Mon, 18 Apr 94 11:16:05 -0400 Date: Mon, 18 Apr 94 11:16:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404181516.AA27417@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? Cc: jnc@ginger.lcs.mit.edu I will also note that re-numbering, while it has many problems, should have no effect on your reachability by external entities. Anyone establishing a new connection will use DNS to translate your name (which has not changed) to your new address. This leaves two issues with renumbering: 1) Getting the local hosts to change their notion of their own identity. ... 2) Existing connections. I wish it were so! The problem is that for a number of reasons (among them the lack of authentication in DNS, ease of quick'n'dirty implementation, etc), many access control databases, route filtering databases, rlogin, NFS, etc, etc, etc elsewhere in the network store data in the form of hard-coded IP address/mask pairs. Basically, any place outside where info relating to that site is stored, but not in symbolic form, is a problem. These represent an equally daunting challenge to changing addresses. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 19 04:14:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09429; Tue, 19 Apr 1994 03:47:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA28689; Tue, 19 Apr 1994 03:45:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA28672; Tue, 19 Apr 1994 03:35:09 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06168; Tue, 19 Apr 1994 02:21:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28064; Mon, 18 Apr 94 12:21:19 -0400 Date: Mon, 18 Apr 94 12:21:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404181621.AA28064@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Routers vs Hosts needs for Networking Cc: jnc@ginger.lcs.mit.edu I don't see why people are bothering then with anything else but PIM. But they are? Why? Most currently multicast schemes bundle together several logically separable tasks, including i) keeping track of members of the multicast group, ii) deciding what kind of data distribution paths to maintain (a separate one for each source of data, or one shared one), iii) constructing how ever many spanning trees (not necessarily the optimal spanning tree) you decide you want in ii) to those groups members from i), etc. With such a wealth of things to pick mechanisms for, it's not surprising that one design group comes up with a different set of design decisions from another group. This is particularly true if the designs are targeted toward different applications in terms of the size, dynamicity, number of groups, etc supported. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 19 04:26:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09556; Tue, 19 Apr 1994 03:51:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA28704; Tue, 19 Apr 1994 03:49:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA28675; Tue, 19 Apr 1994 03:38:48 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04922; Tue, 19 Apr 1994 01:47:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27794; Mon, 18 Apr 94 11:47:33 -0400 Date: Mon, 18 Apr 94 11:47:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404181547.AA27794@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: IPng and firewalling Cc: jnc@ginger.lcs.mit.edu > IPng must support LLIDs (low-level IDs, which are slightly more generic > than flow IDs). Your note was not clear to me on: (1) why the combination of port, protocol, source, destination, and flowID is not sufficient and (2) what a lower-level ID would look like if it is fundamentally different from the set of things in (1). Ran, in my own mind I first go backward to try and figure out what a "flow" is (or whatever it is that Dave's LLID's name). Then I can go forward and look at mechanisms to identify the packets that belong to that flow, and see which ones are fundamentally workable/unworkable, and from that then look at the engineering costs/benefit on each one. I'm not sure we all understand (let alone agree) on what a flow is. In my mind, to the internetworking layer, a flow is a sequence of packets that, share all the attributes that the internetworking layer cares about. This includes, but is not limited to: source/destination, path, resource allocation, accounting/authorization, authentication/security, etc, etc. Flows may also be multicast constructs; i.e. multiple sources and destinations. There isn't necessarily a one-one mapping from flows to *anything* else, be it a TCP connection, or an application instance, or whatever. A single flow might contain several TCP connections (e.g. with FTP), or a single application might have several flows (e.g. multi-media conferencing). With all that in hand, my personal perception is that most of the fields you name are not necessarily tremedously useful in distinguishing flows. For example, a single value of the "source, destination" may not cover all the packets which belong to a multi-cast flow. (Technical aside: this depending on the semantics of the "destination"; this is true if it just names a particular multicast group, and not the particular data path, i.e. if there are several data distribution trees.) You may need multiple such pairings. Similarly, with "port, protocol", a single value may not locate all the TCP connections which are part of an FTP flow. Again, multiple values may be needed. Sure, you can build these semantics in, but the mechanisms are necessarily going to be more complex, and require looking at more header bits. Given that you can always find situations where you *still* need a separate flow-ID field to do the job correctly, I just bite the bullet, and go for the simple, direct approach, and say "a flow is named by a flow-id in the packet header". I prefer the simplicity of globally-unique flow-id's; they take more bits in the header, but then you don't have to worry about all the mechanism needed to remap locally-unique flow-id's, etc, etc. I think from the perspective of designing something with a long lifetime, and which is to be deployed widely, simplicity and directness is the only way to go. For me, that translates into flows being named solely by globally unique flow-id's, rather than some complex lashup of existing fields. I for one would appreciate clarification on what you think the specific requirement actually is. The I-D from the IAB leads me to believe that the set of information that I list above in (1) is sufficient. The Nimrod WG (since Nimrod uses flows heavily) is working on an IPng requirements document which gives, among other thigns, more details of what it would like to see in this area. A draft has been circulated to the WG mailing list. I'm not sure if Int-Serv is going to produce something; there's some stuff in their IETF meeting minutes. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 19 13:56:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01343; Tue, 19 Apr 1994 13:46:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA29188; Tue, 19 Apr 1994 13:40:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA29174; Tue, 19 Apr 1994 13:35:52 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23303; Tue, 19 Apr 1994 10:16:41 +1000 (from Greg_Minshall@Novell.COM) Received: from ns.Novell.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17727 Tue, 19 Apr 1994 10:11:07 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA20202; Mon, 18 Apr 94 18:12:29 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB17851; Mon, 18 Apr 94 17:06:31 PDT Date: Mon, 18 Apr 94 17:06:31 PDT Message-Id: <9404190006.AB17851@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: francis@cactus.slab.ntt.jp (Paul Francis) From: Greg Minshall Subject: Re: heirarchical addressing Cc: big-internet@munnari.OZ.AU Paul, >SIPP does this using a combination of provider-rooted addressing and >the source-route mechanism thingy. The CERN host can even con the MIT >host into sending the right header to make this happen just by feeding >it the reverse of that in the packets it sends to the MIT host. Even >if the MIT host is a "dumb" host, it will turn the source route around >and send the packet to CERN via the right provider. The bit we haven't >worked out is how to get the CERN host to know the cluster address for >its providers automatically..... I actually think the part we (for some "we") haven't got worked out is how to allow the MIT host to *securely* turn around the source route in the received packet... Greg From owner-Big-Internet@munnari.OZ.AU Tue Apr 19 15:23:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02698; Tue, 19 Apr 1994 14:17:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA29229; Tue, 19 Apr 1994 14:15:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA29215; Tue, 19 Apr 1994 14:09:09 +1000 Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25618; Tue, 19 Apr 1994 11:14:06 +1000 (from francis@cactus.slab.ntt.jp) Received: from mail.ntt.jp by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwmfp08902; Mon, 18 Apr 94 20:24:14 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 19 Apr 1994 09:17:29 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA00446; Tue, 19 Apr 1994 09:17:28 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA05209; Tue, 19 Apr 94 09:17:28 JST Date: Tue, 19 Apr 94 09:17:28 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404190017.AA05209@cactus.slab.ntt.jp> To: Greg_Minshall@Novell.COM, francis@Novell.COM Subject: Re: heirarchical addressing Cc: big-internet@munnari.OZ.AU > > >SIPP does this using a combination of provider-rooted addressing and > >the source-route mechanism thingy. The CERN host can even con the MIT > >host into sending the right header to make this happen just by feeding > >it the reverse of that in the packets it sends to the MIT host. Even > >if the MIT host is a "dumb" host, it will turn the source route around > >and send the packet to CERN via the right provider. The bit we haven't > >worked out is how to get the CERN host to know the cluster address for > >its providers automatically..... > > I actually think the part we (for some "we") haven't got worked out is how > to allow the MIT host to *securely* turn around the source route in the > received packet... > I have been attracted, for various reasons, to the notion of having SIPP hosts automatically assign a psuedo-random Flow ID to packets with a given source ID/dest ID/ route sequence info. Perhaps another use for such a function would be to provide some level of security for reversing source routes. That is, when reversing a source route, the reverser would have to feed back the previous flow ID. So, to spoof it, the spoofer would have to have been snooping the packets somehow. This makes it a lot harder..... I guess there are some sequencing details to be worked out, but..... PF From owner-Big-Internet@munnari.OZ.AU Tue Apr 19 17:48:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06717; Tue, 19 Apr 1994 16:02:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA29343; Tue, 19 Apr 1994 16:01:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA29329; Tue, 19 Apr 1994 15:45:31 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05978; Tue, 19 Apr 1994 15:46:48 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 4771; Tue, 19 Apr 94 01:40:40 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 6497; Tue, 19 Apr 1994 01:40:40 -0400 Date: Tue, 19 Apr 94 01:31:11 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: heirarchical addressing To: Paul Francis Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404190017.AA05209@cactus.slab.ntt.jp> Message-Id: <940419.013111.EDT.VALDIS@vtvm1.cc.vt.edu> On Tue, 19 Apr 94 09:17:28 JST you said: >> I actually think the part we (for some "we") haven't got worked out is how >> to allow the MIT host to *securely* turn around the source route in the >> received packet... >I have been attracted, for various reasons, to the notion of having SIPP hosts >automatically assign a psuedo-random Flow ID to packets with a given source > ID/dest ID/ >route sequence info. > >Perhaps another use for such a function would be to provide some level of >security for reversing source routes. That is, when reversing a source route, >the reverser would have to feed back the previous flow ID. So, to spoof it, >the >spoofer would have to have been snooping the packets somehow. This makes it a >lot harder..... The problem is that it's not as easy as it looks to write a non-spoofable pseudo-random number generator. People thought that 'sequence number' attacks weren't a problem until Steve Bellovin showed how easy it was... ;) The real challenge is coming up with a way to do it even when the spoofer *is* able to snoop packets. Although the majority of "hacker" attacks on the Internet come from some.random.edu, the ones I'd *worry* about are inside jobs - this is where most embezzlement happens *now*. And let's face it, a motivated disgruntled employee can almost ALWAYS get access to a PC with an Ethernet card on an 'interesting' cable segment. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Tue Apr 19 18:22:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12174; Tue, 19 Apr 1994 18:22:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA29473; Tue, 19 Apr 1994 18:21:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA29470; Tue, 19 Apr 1994 18:18:57 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09707; Tue, 19 Apr 1994 17:17:19 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 19 Apr 1994 16:16:55 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id QAA07888; Tue, 19 Apr 1994 16:16:55 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA09426; Tue, 19 Apr 94 16:16:54 JST Date: Tue, 19 Apr 94 16:16:54 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404190716.AA09426@cactus.slab.ntt.jp> To: VALDIS@VTVM1.CC.VT.EDU, francis@VTVM1.CC.VT.EDU Subject: Re: heirarchical addressing Cc: big-internet@munnari.OZ.AU > > > >Perhaps another use for such a function would be to provide some level of > >security for reversing source routes. That is, when reversing a source route, > >the reverser would have to feed back the previous flow ID. So, to spoof it, > >the > >spoofer would have to have been snooping the packets somehow. This makes it a > >lot harder..... > > The problem is that it's not as easy as it looks to write a > non-spoofable pseudo-random number generator. People thought that > 'sequence number' attacks weren't a problem until Steve Bellovin showed > how easy it was... ;) In what I'm describing there is no need for it to be non-spoofable. The randomness is just to help the caching that routers and hosts will do. > > The real challenge is coming up with a way to do it even when the > spoofer *is* able to snoop packets. Although the majority of "hacker" I agree, that is a good challenge. But, if we can do something simple (indeed, somthing simple that is usefull for multiple things) that changes the attack from trivial to kinda hard, then why not? PF From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 03:07:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00533; Wed, 20 Apr 1994 03:07:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA29965; Wed, 20 Apr 1994 03:06:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA29949; Wed, 20 Apr 1994 02:40:36 +1000 Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27421; Wed, 20 Apr 1994 01:54:55 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA15981 (5.65c/IDA-1.4.4nsd for ); Tue, 19 Apr 1994 08:54:27 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA12403 (5.65c/IDA-1.4.4-910725); Tue, 19 Apr 1994 08:54:26 -0700 Message-Id: <199404191554.AA12403@remmel.NSD.3Com.COM> To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: big-internet@munnari.OZ.AU Subject: Re: Routers vs Hosts needs for Networking In-Reply-To: Your message of "Sun, 17 Apr 94 09:55:14 PDT." <9404171655.AA20488@jurassic.Eng.Sun.COM> Date: Tue, 19 Apr 94 08:54:25 -0700 From: tracym@NSD.3Com.COM > "Tony Li then offered to provide SIP-IGRP, giving change control to > the IETF of the SIP specific extensions! After considerable > discussion, the w.g. agreed that this should be pursued, given the > usual caveats about licensing agreements and change control." > I still think that turning IGRP into an IETF standard would be good. > Issues about change control, license terms, etc. would have to be dealt > with. Please give me a call (415 / 336-2082) next week if you want > pursue this. I would be happy to help. I'd have an extremely hard time supporting SIPP-only IGRP as a standard. At the absolute minimum, it should be IPv4/SIPP. My opinion may not have much weight at present, but if/when SIPP should be chosen... Currently this is just a personal opinion. Regards, Tracy. From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 03:41:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29048; Wed, 20 Apr 1994 02:36:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA29924; Wed, 20 Apr 1994 02:31:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA29910; Wed, 20 Apr 1994 02:18:40 +1000 From: smb@research.att.com Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25331; Wed, 20 Apr 1994 00:49:45 +1000 (from smb@research.att.com) Message-Id: <9404191449.25331@munnari.oz.au> Received: by gryphon; Tue Apr 19 10:47:06 EDT 1994 To: Valdis Kletnieks Cc: Paul Francis , big-internet@munnari.OZ.AU Subject: Re: heirarchical addressing Date: Tue, 19 Apr 94 10:47:04 EDT > On Tue, 19 Apr 94 09:17:28 JST you said: > >> I actually think the part we (for some "we") haven't got worked out is how > >> to allow the MIT host to *securely* turn around the source route in the > >> received packet... > >I have been attracted, for various reasons, to the notion of having SIPP hosts > >automatically assign a psuedo-random Flow ID to packets with a given source > > ID/dest ID/ > >route sequence info. > > > >Perhaps another use for such a function would be to provide some level of > >security for reversing source routes. That is, when reversing a source route, > >the reverser would have to feed back the previous flow ID. So, to spoof it, > >the > >spoofer would have to have been snooping the packets somehow. This makes it a > >lot harder..... > > The problem is that it's not as easy as it looks to write a > non-spoofable pseudo-random number generator. People thought that > 'sequence number' attacks weren't a problem until Steve Bellovin showed > how easy it was... ;) It was Bob Morris, Jr., who discovered -- and wrote up -- the technique; I merely popularized it. I did add some discussion about the need for cryptographically strong random numbers as a defense. > > The real challenge is coming up with a way to do it even when the > spoofer *is* able to snoop packets. Although the majority of "hacker" > attacks on the Internet come from some.random.edu, the ones I'd *worry* > about are inside jobs - this is where most embezzlement happens *now*. > And let's face it, a motivated disgruntled employee can almost ALWAYS > get access to a PC with an Ethernet card on an 'interesting' cable > segment. I confess that I don't understand the entire concept being discussed here. First, flow ids don't add any security to source-routed messages. By definition, they're random, which means that the destination host has no way to verify their correctness. Since they're not very long, at least in SIPP (24 bits, as I recall), the probability of a collision is fairly high. That means that routers can't use flow ids as anything more than a hash table index, with checking against the address fields mandatory. All that knowledge of a flow id buys you is some ability to insert a packet in the middle of an existing conversation. If you don't have the TCP sequence numbers right, your attempt will likely fail anyway. Getting the sequence numbers right for both sides of a conversation is much harder than Morris' sequence number attack, which only required the ability to predict one end's numbers. Source routing can't be saved by flow ids, at least not if address-based or name-based authentication is to be used. --Steve Bellovin From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 04:48:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01857; Wed, 20 Apr 1994 03:42:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA00119; Wed, 20 Apr 1994 03:41:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA00103; Wed, 20 Apr 1994 03:38:27 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29173; Wed, 20 Apr 1994 02:41:09 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 5059; Tue, 19 Apr 94 12:34:24 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 7236; Tue, 19 Apr 1994 12:34:25 -0400 Date: Tue, 19 Apr 94 12:13:34 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: heirarchical addressing To: Paul Francis Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404190716.AA09426@cactus.slab.ntt.jp> Message-Id: <940419.121334.EDT.VALDIS@vtvm1.cc.vt.edu> On Tue, 19 Apr 94 16:16:54 JST you said: >I agree, that is a good challenge. But, if we can do something simple >(indeed, somthing simple that is usefull for multiple things) that >changes the attack from trivial to kinda hard, then why not? The major danger is that people will equate "kinda hard" with "secure", when they're not. I have nothing against using a good pseudo-random number as an ID to hash on, do flow IDs for routing, and so on.. And as Steve Bellovin pointed out in another note, predicting all the numbers for both ends of a conversation is a lot "harder". Unfortunately, unless we choose a cryptographically strong method of generating numbers, we may find ourselves open to new attacks - for instance, if you are using a ID(n) = f(ID(n-1)) it may be possible to apply large amounts of computing power on a sniffer to compute the function and its next value. Those who think I'm full of cow manure should consider that when the Unix password encryption scheme was designed, it was considered fairly strong - and now that macho-flop workstations are common, the 'CRACK' utility is the scourge of a lot of system administrators. Now consider the amount of time between those two data points, and consider the design goal for serviceable lifetime for IPng. One person suggested using iterated MD5 to generate values - is anybody willing to bet the security of their machines on this remaining computationally hard for 20 more years? Maybe what we need is to use an (algorithm,data) pair, so we can insert new algorithms in the future as the current ones become too weak... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 04:52:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04633; Wed, 20 Apr 1994 04:52:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA00190; Wed, 20 Apr 1994 04:51:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA00176; Wed, 20 Apr 1994 04:29:11 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01741; Wed, 20 Apr 1994 03:38:35 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03368; Tue, 19 Apr 94 10:38:11 PDT Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1/SMI-4.1) id AA02753; Tue, 19 Apr 94 10:37:09 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA07383; Tue, 19 Apr 1994 10:37:56 -0700 Date: Tue, 19 Apr 1994 10:37:56 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404191737.AA07383@jurassic.Eng.Sun.COM> To: tracym@NSD.3Com.COM Cc: Bob.Hinden@Eng.Sun.COM (Bob Hinden), big-internet@munnari.OZ.AU In-Reply-To: <199404191554.AA12403@remmel.NSD.3Com.COM> Subject: Re: Routers vs Hosts needs for Networking Tracy, > I'd have an extremely hard time supporting SIPP-only IGRP as a > standard. At the absolute minimum, it should be IPv4/SIPP. My > opinion may not have much weight at present, but if/when SIPP should > be chosen... I personally agree with you that IGRP for SIPP-only is not very interesting. My note was to correct the notion that the SIPP w.g. had not shown any interest in SIPP support in IGRP. Bob From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 05:27:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05608; Wed, 20 Apr 1994 05:27:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA00242; Wed, 20 Apr 1994 05:26:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA00217; Wed, 20 Apr 1994 05:05:06 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03676; Wed, 20 Apr 1994 04:27:54 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18298; Tue, 19 Apr 94 14:27:49 EDT Date: Tue, 19 Apr 94 14:27:49 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404191827.AA18298@itd.nrl.navy.mil> To: big-Internet@munnari.OZ.AU Subject: Flow IDs and security Valdis, The pseudo-random nature of Flow IDs is useful in the normal hashing senses, IMHO. Their pseudo-random nature does not, IMHO, provide protection against spoofing. The use of strong authentication mechanisms (e.g. SIPP Authentication Header draft-ietf-sipp-ap-*.txt) will provide protection against spoofing attacks. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 11:17:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17800; Wed, 20 Apr 1994 11:17:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA00525; Wed, 20 Apr 1994 11:16:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA00511; Wed, 20 Apr 1994 11:07:49 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13755; Wed, 20 Apr 1994 09:24:17 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Wed, 20 Apr 1994 08:23:49 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA02665; Wed, 20 Apr 1994 08:23:48 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA14989; Wed, 20 Apr 94 08:23:48 JST Date: Wed, 20 Apr 94 08:23:48 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404192323.AA14989@cactus.slab.ntt.jp> To: VALDIS@VTVM1.CC.VT.EDU, smb@research.att.com Subject: Re: heirarchical addressing Cc: big-internet@munnari.OZ.AU, francis@research.att.com From Steve..... > > I confess that I don't understand the entire concept being discussed here. > > First, flow ids don't add any security to source-routed messages. > By definition, they're random, which means that the destination host > has no way to verify their correctness. Since they're not very long, >I agree, that is a good challenge. But, if we can do something simple >(indeed, somthing simple that is usefull for multiple things) that >changes the attack from trivial to kinda hard, then why not? From Valdis.... > The major danger is that people will equate "kinda hard" with "secure", > when they're not. > > I have nothing against using a good pseudo-random number as an ID to > hash on, do flow IDs for routing, and so on.. And as Steve Bellovin This discussion has completely left the original context. The original context was......My host is talking to some other host using some SIPP route sequence. I'm perfectly happy with the existing state of affairs (meaning, that I'm confident that I'm talking to who I think I'm talking to, say according roughly to today's standard of confidence--I know, not real high). Suddenly, my host gets a packet apparently from the same host I've been talking to (because the source EID is the same), but with a new route sequence. This might have happened because the other host moved and now has a new address, or because it wants to send the packets through another provider (for instance, because we were talking about research but now we're talking about cute men which is against AUP). According to the SIPP spec, my host should blithely accept this new route sequence as the proper way to talk to the other host. But, how do I know that some third party didn't send me a bogus packet with the new route sequence, and the new route sequence actually causes the packets to go through her host so she can snoop them. It is a very easy attack. So, the original basic idea (sans details) is to always have hosts put some psuedo-random (not a hard one to compute, but satisfactory for router hashing) number in the packets, and to change the number when the route sequence changes. The purpose is just to make packet processing more efficient, nothing else. The modification to this is to tag new flow ID packets with the old flow ID so that a host can trust (for some level of trust) that the new packets were really from the same host. This changes the attack scenario from trivial-by-anybody-anywhere to hard-unless-you-already-saw-the-packet-stream. That's all I'm talking about. A simple fix to a simple hole introduced by SIPP's more general treatment of the source route mechanism. PF From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 13:02:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22241; Wed, 20 Apr 1994 13:02:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA00626; Wed, 20 Apr 1994 13:01:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA00612; Wed, 20 Apr 1994 12:53:50 +1000 Received: from avalon.mpce.mq.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20049; Wed, 20 Apr 1994 12:09:48 +1000 (from andrewm@avalon.mpce.mq.edu.au) Message-Id: <9404200209.20049@munnari.oz.au> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA14586; Wed, 20 Apr 94 12:08:54 est From: Andrew Myles Subject: Re: heirarchical addressing To: francis@cactus.slab.ntt.jp (Paul Francis) (Paul Francis) Date: Wed, 20 Apr 94 12:08:52 EST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404192323.AA14989@cactus.slab.ntt.jp>; from "Paul Francis" at Apr 20, 94 8:23 am Mailer: Elm [revision: 64.9] G'day Paul, > So, the original basic idea is to always have hosts put some > psuedo-random number in the packets, and to change the number > when the route sequence changes. ... > The modification to this is to tag new flow ID packets with the > old flow ID so that a host can trust (for some level of trust) > that the new packets were really from the same host. This > changes the attack scenario from trivial-by-anybody-anywhere to > hard-unless-you-already-saw-the-packet-stream. > > That's all I'm talking about. A simple fix to a simple hole introduced by > SIPP's more general treatment of the source route mechanism. Myself and others suggested a similar mechanism for use by Mobile IP. The security "experts" claimed that such a mechanism is totally unsatisfactory and would NEVER be passed by the IETF. I still think they are wrong but conceded. However, the mechanism will be included in a route optimisation extension to basic Mobile IP. If it unacceptable in Mobile IP, why is it acceptable in SIPP? Do you also believe the "experts" are wrong? Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, MPCE Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8059071 (W), +61 2 8059128 (Fax), +61 2 8786060 (H). From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 15:33:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26580; Wed, 20 Apr 1994 14:47:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA00726; Wed, 20 Apr 1994 14:46:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA00723; Wed, 20 Apr 1994 14:41:10 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26421; Wed, 20 Apr 1994 14:42:18 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Wed, 20 Apr 1994 13:41:14 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id NAA08064; Wed, 20 Apr 1994 13:41:13 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA17654; Wed, 20 Apr 94 13:41:12 JST Date: Wed, 20 Apr 94 13:41:12 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404200441.AA17654@cactus.slab.ntt.jp> To: andrewm@avalon.mpce.mq.edu.au, francis@avalon.mpce.mq.edu.au Subject: Re: heirarchical addressing Cc: big-internet@munnari.OZ.AU > > > > That's all I'm talking about. A simple fix to a simple hole introduced by > > SIPP's more general treatment of the source route mechanism. > > Myself and others suggested a similar mechanism for use by Mobile IP. > The security "experts" claimed that such a mechanism is totally > unsatisfactory and would NEVER be passed by the IETF. I still think > they are wrong but conceded. However, the mechanism will be included > in a route optimisation extension to basic Mobile IP. > > If it unacceptable in Mobile IP, why is it acceptable in SIPP? Do you > also believe the "experts" are wrong? > I guess it depends on what problem you are trying to solve. If you are trying to solve the general authentication problem, then the simple thing we proposed is clearly inadequate. If you are trying only to plug the snooping hole introduced by SIPP source route handling, and equally by the mobile IP route optimisation (they are exactly the same semantics, just different mechanism), then I think our proposal is fine, and I think the experts would agree, if they could lower their sights for this one moment. PF From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 16:18:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29380; Wed, 20 Apr 1994 15:57:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA00803; Wed, 20 Apr 1994 15:56:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA00765; Wed, 20 Apr 1994 15:23:25 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24615; Wed, 20 Apr 1994 13:56:41 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Apr 94 12:51:19 +0900 From: Masataka Ohta Message-Id: <9404200351.AA06337@necom830.cc.titech.ac.jp> Subject: Re: heirarchical addressing To: francis%cactus.slab.NTT.JP@CS.TITECH.AC.JP (Paul Francis) Date: Wed, 20 Apr 94 12:51:18 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404192323.AA14989@cactus.slab.ntt.jp>; from "Paul Francis" at Apr 20, 94 8:23 am X-Mailer: ELM [version 2.3 PL11] > According to the SIPP spec, my host should blithely accept this new route > sequence as the proper way to talk to the other host. But, how do I know > that some third party didn't send me a bogus packet with the new route > sequence, and the new route sequence actually causes the packets to go > through her host so she can snoop them. It is a very easy attack. > So, the original basic idea (sans details) is to always have hosts put some > psuedo-random (not a hard one to compute, but satisfactory for router hashing) > number in the packets, and to change the number when the route sequence > changes. The mechanism merely provides a very weak protection for existing connection. But it is no protection for new connection or connectionless communication. For example, anyone can spoof ".rhosts" mechanism to get login. In general, weak authentication based on host's address won't work with bogus source routing blindly reversed. For a little more stronger (but still weak) security, ASEQ reversing policy must be changed. That is, ID part of the source address sequence should be checked against DNS (or NIS or /etc/hosts) reverse domain to know a weakly authenticated hostname. The hostname should then be used for DNS forward lookup to know weakly authenticated source address sequences. Now, only the part of the source address sequence which matches one of the DNS reggistered address sequences should be reversed and rest of the source address sequence should be dropped (unless the receiver has other reason to use them). This way, SIPP with source routing can be just as secure as IPv4 without source routing. The mechanism may be moderately secure within a small LAN in which all the users are trusted. For real security, we need real authentication information (not a mere IP address) at the time of the connection establishment. But, if such security is desired and such information is available, we should and can use really authenticated communication through IPsec. So, I don't think flow ID is useful for security. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Apr 20 18:14:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03624; Wed, 20 Apr 1994 17:42:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA00903; Wed, 20 Apr 1994 17:41:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA00878; Wed, 20 Apr 1994 17:12:03 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00575; Wed, 20 Apr 1994 16:28:11 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 20 Apr 94 15:23:06 +0900 From: Masataka Ohta Message-Id: <9404200623.AA07077@necom830.cc.titech.ac.jp> Subject: Weak security and the big internet To: big-internet@munnari.OZ.AU Date: Wed, 20 Apr 94 15:23:05 JST In-Reply-To: <9404200441.AA17654@cactus.slab.ntt.jp>; from "Paul Francis" at Apr 20, 94 1:41 pm X-Mailer: ELM [version 2.3 PL11] > > If it unacceptable in Mobile IP, why is it acceptable in SIPP? Do you > > also believe the "experts" are wrong? > > > > I guess it depends on what problem you are trying to solve. If you > are trying to solve the general authentication problem, then the simple > thing we proposed is clearly inadequate. If you are trying only to plug > the snooping hole introduced by SIPP source route handling, and equally > by the mobile IP route optimisation (they are exactly the same semantics, > just different mechanism), then I think our proposal is fine, I think weak security, which is providev by IPv4, NOT by SIPP flow ID, might be enough within some LAN but can't be enough in the Big Internet in the near future or even today. As mobility in general involves the whole Internet, it should be secure enough. But, are there any problem in doing so? As MH and HR are supposed to share secret, commnication between them could be designed secure enough quite easily. As for the communication between SH and home network (HR and, maybe, MH), conventional security (that is, in many cases, weak security) can be assumed to be enough, because its security has nothing to do with mobility. In designing mobile security, we can assume that communication between SH and immobile MH at home is secure enough, can't we? Lastly, communication between MH and SH (through VR) can be made secure enough by exchanging secret information (randomly generated transaction key, for example) between MH and SH through HR. Thus, mobility (including triangle elimination) can be secure enough. What's wrong with it? Are there any patent or export control issues? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 00:43:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16627; Wed, 20 Apr 1994 23:33:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA01228; Wed, 20 Apr 1994 23:31:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA01225; Wed, 20 Apr 1994 23:27:32 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16478; Wed, 20 Apr 1994 23:28:53 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14966; Wed, 20 Apr 94 09:28:46 EDT Date: Wed, 20 Apr 94 09:28:46 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404201328.AA14966@itd.nrl.navy.mil> To: big-Internet@munnari.OZ.AU Subject: SIPP Routing Header & security Cc: sipp@sunroof2.eng.sun.com Paul, I am not an expert, but I do believe that your desire to have widespread use of route sequences without the SIPP Authentication Header is unfortunate. Others have suggested in the past and during the IPng review process that source routing without authentication is an undue security risk. There is significant evidence that passive attacks are widespread in the current Internet. The mechanism you suggest is trivial to spoof using the same passive attacks that we know are in use today. That mechanism provides no additional assurance or security to anything or anyone. SIPP in fact has a strong authentication mechanism that is easily implemented. That mechanism is being widely implemented and will probably be widely deployed (in no small part this is because it is easily exported from most countries and is easily imported and is easily used in most countries so commercial vendors can include it with every copy of their OS). I believe that the SIPP spec should require that an Authentication Header be present in all packets that contain a Routing Header and I have said so at SIPP meetings in Seattle (e.g. Sunday evening). The NRL SIPP implementation is likely to ignore Routing Headers if the packet omits the Authentication Header because it represents an unacceptable security risk in the current Internet environment. Why do you object to using the mechanisms which already are defined and are already being implemented and really address the concern at hand ? I'm very confused. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 01:08:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19892; Thu, 21 Apr 1994 00:43:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA01305; Thu, 21 Apr 1994 00:41:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA01291; Thu, 21 Apr 1994 00:37:36 +1000 From: ercm20@festival.ed.ac.uk Received: from sun2.nsfnet-relay.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19656; Thu, 21 Apr 1994 00:38:56 +1000 (from ercm20@festival.ed.ac.uk) Via: uk.ac.edinburgh.festival; Wed, 20 Apr 1994 14:19:29 +0100 Date: Wed, 20 Apr 94 14:19:22 BST To: Big-Internet@munnari.OZ.AU Message-Id: <9404201419.aa00217@uk.ac.ed.festival> To: Big-Internet@munnari.OZ.AU Subject: Re: IPng & Provider-oriented addressing Reply-To: Sam.Wilson@ed.ac.uk Newsgroups: info.big-internet Organization: Edinburgh University X-Newsreader: TIN [version 1.1 PL8] In article <9404081907.AA12656@mailserv-D.ftp.com> Frank Kastenholz wrote: : 1. Always send to a router and the router, knowing the topological : information, could decide whether the packet is 'local' or not, : forward the packet as needed, and if the sender and destination : are on the same net, the router could also send a redirect to the : sender. This, of course, means that you need a router on every : network. Even networks that are off by themselves and not : connected anyplace else. Ick. I have a hazy memory that DECNet phase IV has some feature a little like this involving a router setting the 'same ethernet' bit in packets forwarded back onto the same LAN. Someone on this list must know more about it than the rest of us want to know. ES-IS is also designed to tackle this kind of problem, isn't it? Sam Wilson Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 02:27:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23557; Thu, 21 Apr 1994 02:27:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA01421; Thu, 21 Apr 1994 02:26:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA01407; Thu, 21 Apr 1994 02:15:43 +1000 Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21933; Thu, 21 Apr 1994 01:43:45 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id IAA28821; Wed, 20 Apr 1994 08:43:04 -0700 Date: Wed, 20 Apr 1994 08:43:04 -0700 From: Dave Katz Message-Id: <199404201543.IAA28821@feta.cisco.com> To: ercm20@festival.ed.ac.uk Cc: Big-Internet@munnari.OZ.AU In-Reply-To: ercm20@festival.ed.ac.uk's message of Wed, 20 Apr 94 14:19:22 BST <9404201419.aa00217@uk.ac.ed.festival> CLNP/ESIS reverts to ARP-like behavior in this case, by having the ES multicast the data packet onto the local LAN; the destination ES sends back a unicast ES Hello and then everybody does the right thing. From: ercm20@festival.ed.ac.uk Date: Wed, 20 Apr 94 14:19:22 BST To: Big-Internet@munnari.OZ.AU Subject: Re: IPng & Provider-oriented addressing Reply-To: Sam.Wilson@ed.ac.uk Newsgroups: info.big-internet Organization: Edinburgh University X-Newsreader: TIN [version 1.1 PL8] In article <9404081907.AA12656@mailserv-D.ftp.com> Frank Kastenholz wrote: : 1. Always send to a router and the router, knowing the topological : information, could decide whether the packet is 'local' or not, : forward the packet as needed, and if the sender and destination : are on the same net, the router could also send a redirect to the : sender. This, of course, means that you need a router on every : network. Even networks that are off by themselves and not : connected anyplace else. Ick. I have a hazy memory that DECNet phase IV has some feature a little like this involving a router setting the 'same ethernet' bit in packets forwarded back onto the same LAN. Someone on this list must know more about it than the rest of us want to know. ES-IS is also designed to tackle this kind of problem, isn't it? Sam Wilson Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 02:49:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21083; Thu, 21 Apr 1994 01:17:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA01346; Thu, 21 Apr 1994 01:16:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA01332; Thu, 21 Apr 1994 01:08:56 +1000 Received: from haig.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13559; Wed, 20 Apr 1994 22:08:21 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404201208.13559@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 20 Apr 1994 13:07:22 +0100 To: big-internet@munnari.OZ.AU Subject: A modest proposal Date: Wed, 20 Apr 94 13:07:14 +0100 From: Jon Crowcroft I PING: Ideal Protocol for the Internet Next Generation Jon Crowcroft Department of Computer Science, University College London Gower Street, London WC1E 6BT, United Kingdom ABSTRACT 1. INTRODUCTION This is a strawman proposal for an IPng. It is so simple, that it is quite likely it doesn't work. However, it addresses some of the criteria in the requirements document, and thus can be used as a benchmark for other proposals. A core belief of the author is that the Internet progresses through piecewise re-engineering, rather than punctuated evolu- tion. Hence, we have seen: 1) IPv4 2) Subnetworking though masks 3The IGP/EGP split. 4The CIDR Deployment 5MTU Discovery and so forth. Basically, these schemes have all worked since they have had minimal impact on end systems, and small impact on routers. We hope that this proposal is in that spirit. 2. THE I PING HEADER Before designing an IPng packet, let us re-visit the IPv4 packet format, and understand the problem. April 20, 1994 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IPv4 Header The main problem is simply that the two address fields, 32 bit source and destination, are: 1) Too small 2) Already Allocated The requirements document asks for better scaling of routing and more topological flexibility. In fact, any prefix or mask and match scheme can provide this, so long as: a) We have a new address space b) We have a bit more address space The migration problems include both host and routers. There are two basic approaches to a migration plan: i) Dual Stack ii)Header re-writing. There are also two places we need concern ourselves with migration: I Legacy hosts talking to IPng hosts. II)IPng hosts using legacy routers. This proposal addresses both of these problems. April 20, 1994 The I PING proposal is to re-use fields in the IPv4 header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Field |x|y|Flg| Source Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: I PING Header The key change to the IP header is the use of the ID and Fragment offset to provide two 14 bit fields (called the "F" fields) which extend the Source and Destination fields. Note that the Flg field coincides with the IPv4 Flags field's first 2 bits. IPv4, the flags field is defined as: Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. I PING defines a use for Bit 0. If this is not permissible, we define a use for the DF bit. I PING also defines 2 more control bits, that are used for interactions with the FAT (see below). In either case, non-zero use of DF in an I PING network indi- cates an I PING packet with a valid Source and Destination field. A zero DF field indicates an IPv4 packet. I PING rules out fragmentation, and mandates the use of MTU discovery. April 20, 1994 An IPv4 host that wishes to transit an I PING network to must either carry out MTU discovery, or the IPv4-I PING border router (called a FAT, Fragmentation and Address Translator), carries out reassembly on behalf of the IPv4 source. Any IPv4 host that cannot find an MTU that works across an I PING transit net will not gain connectivity as those that can. 3. I PING HOSTS AND ROUTER REQUIREMENTS The address space available is now increased by 14 bits. Since the current internet supports 2.5M connected hosts, and of order 10**4 networks, and this increases this by 10**4, it meets the requirements for scaling of number of end and intermediate systems, quite easily Should further extension be required, this can be dealt with at our leisure, by means unforeseen by this author. Obviously, an end system that wishes to distinguish its pack- ets as being I PING, needs to be able to support a 46 bit address space. Since this is similar to the Ethernet/IEEE 802 MAC address space, this should not prove taxing. The Socket and stream API can accommodate a field this size with ease. A Router that supports I PING must now support subnet masks (and/or CIDR masks) of 6 bytes. One area for exploration is whether a flat allocation of the extra 14 bits to Providers, or a geographic allocation might not work (or both). "F" values of 0 mean IPv4. |Note the implication. IPng is implicit - i.e. I PING is only known by configuration of an interface on a host or router as being I PING rather than IPv4. One could imagine very clean software here, just using the "F" additional space in routing and ifnet structures. 4. The Fragmentation and Address Translation Functions The FAT has several functions, but is basically similar to Van Jacobson's NAT. 1) It can act as a border for a single site which has I PING address space allocated, but can append the sites F to sources and use IPv4 interworking techniques (below) to fill in the destinations F fields. 2) A FAT supports 3 functions in enhancement of packet forward- ing to enable IPv4 hosts to interwork with I PING hosts: i) Two tier proposed the use of a reserved address space for scaling of IPv4. We propose the reservation of part of IPv4 (and I PING "F") address space, which is to be dynamically April 20, 1994 allocated. The Ipv4 dynamic space is called dIPv4. ii) Dynamic allocation is used for mobility in I PING (for later study). Dynamic allocation of IPv4 address space is used on demand to provide I PING hosts with addresses that appear to be at FATs from the IPv4 side. (In fact, the address space is pre-divided amongst the FATs). When an I PING or IPv4 host start to try and send datagrams to each other, the I PING host is assigned to a FAT, and an IPv4 dynamic address at that NAT assigned to provide mapping. Cache/Map invalidation is for further study (if RSVP is used below to establish this mapping state, it can be used to removew it too - so could an expanding ring multicast based protocol). Certainly, ICMP redirects could help with re-assignment of FAT. iii) The FAT interacts with the DNS (where these addresses are known), to inform it of the mapping between the DNS Name of the I PING host, and its binding with the dynamically allo- cated IPv4 address for interworkign with legacy hosts. This requires two types of interaction. Either a FAT starts to receive I PING packets destined for an IPv4 host, does the allocation, and informs the DNS so it knows and the receiv- ing host sees the right entry, or else the IPv4 tries to connect to an I PING host (by name: it cannot do by address, by definition), and the DNS lookup causes the same effect. 3) There remains the question of whether the packets from the IPv4 host to the FAT, and from the FAT to the I PING host are translated or encapsulated. Either can be done. If the I PING host supports de-encapsulation, then the FAT can simply take the packet with an IPv4 dynamic address, lookup the mapping, and encapsulate it in an I PING packet to the actual I PING host, which then de-encapsulates and hands up to I PINg, which then hands the packet to TCP or UDP as is. Alterna- tively, the FAT can re-write the IPv4 dynamically allocated address with the I PING address (and "F" field). The problem with the latter approach is the TCP or UDP checksums must needs be updated too. Future work will identify which of these approaches is best, and when. As mentioned above, I PING mandates MTU discovery. Since there is no fragmentation, the DF bit is not needed for MTU discovery. Any router receiving an I PING packet too large sim- ply reports the size problem as if it were an IPv4 router receiving an IP packet with a DF bit set. An I PING FAT receiving an IPv4 packet that is fragmented, reassembles it. If it is too large, it reports this (too bad!). If the DF bit is set, it carries out MTU discovery. Note there is no problem using the DF bit in forwarding an IPv4 packet. April 20, 1994 Once we get to an I PING router area, the IPv4 route space is just a subset....(a single CIDR?) 5. FAT DNS INTERACTION The interaction between the FAT and the DNS needs clarifica- tion. We anticipate a simple protocol being used for the case of an I PING source trying to reach an IPv4 site. Basically, the routing will find a good path to an appropri- ate FAT. The FAT will then assign an I PING:dIPv4 address entry. It then reports to the DNS server in the I PING domain, this entry. This requires a WRITE facility to the DNS. However, it may be reasonable for I PING DNS servers to have this for other reasons (c.f. Mobility support/assistance). Without this, the option is for the I PING source to ask the FAT for an address, and encapsulate as far as the FAT. The x/y bits in the IP Header may be of use in a protocol here (for further study). Of course, if the DNS servers in the IPv4 areas need to con- tact the DNS servers in the I PING areas, there is a bootstrap problem. We anticipate encapsulation, with pre-allocated addresses here. The use of multicast and/or RSVP has been considered, but needs further study, for the establishment of the FAT state in a soft safe way. 6. DISCUSSION of ADDITIONAL CRITERIA Since the source is now a larger field, Multicast works fine, and even has a larger address space. 7. FUTURE WORK Treatment of ICMPs (a la IPAE?) Flows...Could we re-use the "F" fields as flows? Could we use the checksum field as a flow? REFERENCES [1] Postel, J.B. "INTERNET PROTOCOL", RFC-791, 1981. [2] "Technical Criteria for Choosing IP:The Next Generation (IPng)", Frank Kastenholz, Craig Partridge, 23 March 1994. [3] Van Jacobson, "Network Address Translation", on big-internet [4] Z Wang, J Crowcroft, "Two Tier". RFC-1335, 1992 [5] Tuba April 20, 1994 [6] SIPP [7] CATNIPP April 20, 1994 From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 12:19:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09488; Thu, 21 Apr 1994 09:35:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA01543; Thu, 21 Apr 1994 09:33:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA01537; Thu, 21 Apr 1994 09:28:38 +1000 Received: from sun2.nsfnet-relay.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00673; Thu, 21 Apr 1994 05:25:24 +1000 (from ercm20@festival.ed.ac.uk) Via: uk.ac.edinburgh.festival; Wed, 20 Apr 1994 19:06:58 +0100 Date: 20 Apr 94 19:06:47 BST From: Sam Wilson To: Dave Katz Cc: Big-Internet@munnari.OZ.AU Reply-To: Sam.Wilson@edinburgh.ac.uk In-Reply-To: Your message <199404201543.IAA28821@feta.cisco.com> Message-Id: <9404201906.aa02986@uk.ac.ed.festival> Dave Katz wrote: > CLNP/ESIS reverts to ARP-like behavior in this case [no router], by having the ES > multicast the data packet onto the local LAN; the destination ES sends > back a unicast ES Hello and then everybody does the right thing. In DECnet/OSI (aka Phase V) the documents claim that ES-IS is used to give the non-local part of the NSAP (IDP+area) to the ES. Presumably in the no-router case the ESs just use NSAPs with fudged non-local parts in the same sort of way that AppleTalk configures itself in the absence of a router. Yes? Sam Wilson Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 12:25:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09744; Thu, 21 Apr 1994 09:40:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA01558; Thu, 21 Apr 1994 09:39:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA01523; Thu, 21 Apr 1994 09:24:48 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05552; Thu, 21 Apr 1994 07:38:22 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA19623; Wed, 20 Apr 94 15:43:26 MDT Received: from [130.57.64.149] by WC.Novell.COM (4.1/SMI-4.1) id AA24678; Wed, 20 Apr 94 14:37:21 PDT Date: Wed, 20 Apr 94 14:37:20 PDT Message-Id: <9404202137.AA24678@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: big-internet@munnari.OZ.AU From: Greg Minshall Subject: alignment Well, i'm within a week of catching up on e-mail... Let me mention one issue *i* have with supporting NSAPs a la CLNP, TUBA, CATNIP (?), TURNIPP (?). It would be nice if when a packet has been received the *transport* header (i.e., the thing after the internet header) is on some "nice" alignment for the receiving host. Current thinking is that this should be 0 mod 64 (bits). But, CLNP, TUBA, and maybe CATNIP and TURNIPP could leave you at x mod 64, for any x in [0..63]. To *me*, this is a *BAD* thing. SIPP, if it were to see the need to support NSAPs, would presumably do it such that 20-byte NSAPs took 24 bytes each. Thus, alignment would happen (== "could be made to happen"). Or, am i missing something? Greg From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 12:26:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09783; Thu, 21 Apr 1994 09:41:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA01584; Thu, 21 Apr 1994 09:40:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA01540; Thu, 21 Apr 1994 09:29:33 +1000 Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02237; Thu, 21 Apr 1994 06:08:35 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA12851; Wed, 20 Apr 1994 13:08:00 -0700 Date: Wed, 20 Apr 1994 13:08:00 -0700 From: Dave Katz Message-Id: <199404202008.NAA12851@feta.cisco.com> To: Sam.Wilson@edinburgh.ac.uk Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Sam Wilson's message of 20 Apr 94 19:06:47 BST <9404201906.aa02986@uk.ac.ed.festival> I've got an I-D out on this very subject that expands on this mechanism (draft-ietf-tuba-addr-assign-00.txt). But yes, they use AFI 49 (local scope) addresses if there is no other information available. Date: 20 Apr 94 19:06:47 BST From: Sam Wilson Reply-To: Sam.Wilson@edinburgh.ac.uk Dave Katz wrote: > CLNP/ESIS reverts to ARP-like behavior in this case [no router], by having the ES > multicast the data packet onto the local LAN; the destination ES sends > back a unicast ES Hello and then everybody does the right thing. In DECnet/OSI (aka Phase V) the documents claim that ES-IS is used to give the non-local part of the NSAP (IDP+area) to the ES. Presumably in the no-router case the ESs just use NSAPs with fudged non-local parts in the same sort of way that AppleTalk configures itself in the absence of a router. Yes? Sam Wilson Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 13:37:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16398; Thu, 21 Apr 1994 12:30:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA01737; Thu, 21 Apr 1994 12:28:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA01723; Thu, 21 Apr 1994 12:22:02 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10968; Thu, 21 Apr 1994 10:12:02 +1000 (from yakov@watson.ibm.com) Message-Id: <9404210012.10968@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8815; Wed, 20 Apr 94 20:12:00 EDT Date: Wed, 20 Apr 94 20:10:03 EDT To: Greg_Minshall@Novell.COM, big-internet@munnari.OZ.AU Subject: alignment Ref: Your note of Wed, 20 Apr 94 14:37:20 PDT Greg, >it would be nice if when a packet has been received the *transport* >header is on some nice alignment for the receiving host... For the purpose of alignment do you count from the beginning of the IP header or from the beginning of the MAC header ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 14:23:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17873; Thu, 21 Apr 1994 13:04:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA01782; Thu, 21 Apr 1994 13:03:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA01779; Thu, 21 Apr 1994 12:55:50 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11430; Thu, 21 Apr 1994 10:23:36 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Thu, 21 Apr 1994 09:23:09 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA04142; Thu, 21 Apr 1994 09:23:09 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA24257; Thu, 21 Apr 94 09:23:09 JST Date: Thu, 21 Apr 94 09:23:09 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404210023.AA24257@cactus.slab.ntt.jp> To: atkinson@itd.nrl.navy.mil, big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security Cc: sipp@sunroof2.eng.sun.com > > I am not an expert, but I do believe that your desire to have > widespread use of route sequences without the SIPP Authentication > Header is unfortunate. Others have suggested in the past and during I'm sorry if I said or implied that the Flow-ID hash number scheme was meant to replace SIPP Authentication Header. I never thought that. Perhaps the correct reply to Greg Minshall's original comment should have been "no problem, the authentication header will handle that". What happened was that I got pulled into an argument that was completely different from the original point I was trying to make. Here's how I think the sequence went: Minshall: That source routing trick you want to do has a security problem. Me: I've been thinking that X (pseudo-randomly set Flow IDs) are a good idea in general, and your point reminds me of another good reason for them---that is, they can trivially solve Z (make snooping much harder) (my point being here that Z is yet another good reason for doing X, not that the sole purpose of X is to solve Z) Somebody: You moron (me.....), your security proposal doesn't solve Y (the general authentication problem). Me: I never meant to solve Y, I only meant to solve Z. (my mistake....now I'm defending a solution to Z, which wasn't my original point) Ran: Why are you proposing something to solve Y when we already have a solution to Y....... So, at this point I should probably just drop the whole topic, but..... > the IPng review process that source routing without authentication is > an undue security risk. There is significant evidence that passive > attacks are widespread in the current Internet. The mechanism you > suggest is trivial to spoof using the same passive attacks that we > know are in use today. That mechanism provides no additional > assurance or security to anything or anyone. At the risk of still appearing to define the idea, could you replay back to me in your own words what you think I proposed and what problem you think I'm trying to solve? I still think that what I proposed (were I still proposing it) makes it harder for Joe Budwieser (or Taro Asahi) to snoop packets. > > SIPP in fact has a strong authentication mechanism that is easily > implemented. That mechanism is being widely implemented and will > probably be widely deployed (in no small part this is because it is This is a genuine question (not a statement in disguise). What is required for the key distribution part of the Authentication Header (I hope this isn't a totally stupid question....I've not kept up with SIPP Authentication......)? Ie., is it as easily managed and operated as it is easily implemented? > easily exported from most countries and is easily imported and is > easily used in most countries so commercial vendors can include it > with every copy of their OS). I believe that the SIPP spec should > require that an Authentication Header be present in all packets that > contain a Routing Header and I have said so at SIPP meetings in > Seattle (e.g. Sunday evening). The NRL SIPP implementation is likely I agree. We should do everything we can to insure that the mechanism is ubiquitous (I know, including stamping out loose cannons who, even unwittingly, propose weak alternatives..... :-) > > Why do you object to using the mechanisms which already are defined > and are already being implemented and really address the concern at > hand ? I'm very confused. > I hope you're now not confused..... PF From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 14:24:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19184; Thu, 21 Apr 1994 13:40:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA01826; Thu, 21 Apr 1994 13:38:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA01812; Thu, 21 Apr 1994 13:19:03 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13656; Thu, 21 Apr 1994 11:19:22 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Thu, 21 Apr 1994 10:19:02 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA05078; Thu, 21 Apr 1994 10:19:01 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA24808; Thu, 21 Apr 94 10:19:01 JST Date: Thu, 21 Apr 94 10:19:01 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404210119.AA24808@cactus.slab.ntt.jp> To: atkinson@itd.nrl.navy.mil, francis@itd.nrl.navy.mil Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com > > % I still think that what I proposed (were I still proposing it) makes > % it harder for Joe Budwieser (or Taro Asahi) to snoop packets. > > I don't think so. The current passive attackers are sniffing packets, > parsing IP, TCP, and the contents of the TCP to grab the passwords and > login ids from ftp/telnet/rlogin traffic. Parsing all that seems Right. That isn't the attack I'm talking about. The hole introduced by SIPP source routing (or optimal route in mobility) is that *anybody anywhere* can pretty easily intercept and therefore snoop your packets. I'm not addressing passive attackers that are sniffing packets.....if they are already in the path to sniff your packets, then obviously they can read them too.... That clearly requires encryption. I'm addressing the case where, say, you're going to talk with Steve Deering. I (in Japan) have no way of sniffing packets between you and Steve. Still, I want to listen to your conversation. I know you're address and I know Steve's address. I periodically send a packet to your host that looks like it came from Steve's host, but has a reverse source route that causes the packet to go to my host. When you start talking to Steve, your host receives such a packet, accepts the reverse source route, and starts sending the packets to me. I listen to the packet, reformat the header to feed Steve's host a source route that makes his headers come back to me, and now I'm in the loop. If, on the other hand, you'll only believe my bogus packet if it contained the right flow ID, then it is much harder for me to successfully feed you a bogus source route, yes? Basically all I was trying to do is bring SIPP up to the level of security of IP (I know, not much....) with a simple hack... > > % What is required for the key distribution part of the Authentication > % Header (I hope this isn't a totally stupid question....I've not kept > % up with SIPP Authentication......)? Ie., is it as easily managed > % and operated as it is easily implemented? > > The SIPP security specs only require manual key distribution for now. > Lack of a scalable key mgmt protocol is the critical barrier to > widespread deployment and use, not only of the SIPP Authentication > Header and SIPP Encapsulating Security Payload, but also of any future This is a concern. Even if SIPP Authentication header is easy to implement, people won't use it if it is hard to configure. How can we overcome that???? PF From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 14:24:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19384; Thu, 21 Apr 1994 13:42:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA01852; Thu, 21 Apr 1994 13:40:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA01809; Thu, 21 Apr 1994 13:16:27 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13128; Thu, 21 Apr 1994 11:05:20 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11907; Wed, 20 Apr 94 21:05:16 EDT Date: Wed, 20 Apr 94 21:05:16 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404210105.AA11907@itd.nrl.navy.mil> To: francis@cactus.slab.ntt.jp Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com % What happened was that I got pulled into an argument that was % completely different from the original point I was trying to make. Paul, I think you are right. The conversation took a confusing turn. I happen to agree with you that FlowIDs should be pseudo-random. % I still think that what I proposed (were I still proposing it) makes % it harder for Joe Budwieser (or Taro Asahi) to snoop packets. I don't think so. The current passive attackers are sniffing packets, parsing IP, TCP, and the contents of the TCP to grab the passwords and login ids from ftp/telnet/rlogin traffic. Parsing all that seems harder than just parsing a FlowID from a known location at the beginning of a packet. Since the FlowID can't serve its purpose of assisting in resource reservation (and helping in routing optimisation) if it is encrypted, we can safely assume it will be plain text. So grabbing the FlowID seems straight-forward. This means that the FlowID really isn't adding any security to the overall system. % What is required for the key distribution part of the Authentication % Header (I hope this isn't a totally stupid question....I've not kept % up with SIPP Authentication......)? Ie., is it as easily managed % and operated as it is easily implemented? The SIPP security specs only require manual key distribution for now. Lack of a scalable key mgmt protocol is the critical barrier to widespread deployment and use, not only of the SIPP Authentication Header and SIPP Encapsulating Security Payload, but also of any future IPv4 Security Protocol, Mobile IP authentication, OSPF authentication, and perhaps also BGP-4 authentication. I am not sure if it really is a problem for BGP because BGP already requires so much manual intervention (though that seems like a backwards argument to me). The dependence of several critical security mechanisms on to-be-developed scalable key mgmt is one reason that I urged that the key management work either be made the high priority task of the IPv4 Security Protocol WG or be spun off into a separate Internet Key Mgmt Protocol WG. My views did not prevail and the IPv4 SP packet format is the higher priority and key mgmt remains in that WG. Several folks who understand key management (I'm not one) are looking into exactly what the Internet should use. Many of these folks are doing their examination because of the IPv4 Security Protocol WG. SIPP should be able to reuse whatever comes out of those efforts because the key management protocol will live on a TCP or UDP port in all likelihood. Most folks seem to think that some kind of Diffie-Hellman algorithm will be used to setup the session keys. Public Key Partners claim rights to the Diffie-Hellman patent in the USA. This economic and legal factor will make widespread deployment of an Internet Key Mgmt Protocol (IKMP) much harder. I think that implementation of the key mgmt protocol won't be hard as a strictly technical exercise. Given time and an IKMP spec, I'll probably implement it myself in BSD as an experiment. Regards, Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 18:40:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24892; Thu, 21 Apr 1994 16:03:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA02003; Thu, 21 Apr 1994 15:58:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA01986; Thu, 21 Apr 1994 15:46:51 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22157; Thu, 21 Apr 1994 14:48:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24676; Thu, 21 Apr 94 00:47:41 -0400 Date: Thu, 21 Apr 94 00:47:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404210447.AA24676@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security Cc: jnc@ginger.lcs.mit.edu The hole introduced by SIPP source routing (or optimal route in mobility) is that *anybody anywhere* can pretty easily intercept and therefore snoop your packets. .... I periodically send a packet to your host that looks like it came from Steve's host, but has a reverse source route that causes the packet to go to my host. .... I listen to the packet, reformat the header to feed Steve's host a source route that makes his headers come back to me, and now I'm in the loop. It's worth pointing out that the basic problem here is not the use of a source route, but the fact that the two hosts uncritically accept, and then use, information which has come in from the network, without making sure that that information is reliable and safe to use. It happens to be a source route, which they uncritically accept and turn around, but the problem is not with source routing per se, or even *use* of unauthenticated source routes. Any time you use *any* information without being sure i) who sent it, and ii) that it has not been tampered with, you've got a potential security hole. Sooner or later some smart person will figure out how to drive a truck through it, and software being what it is, 2 weeks after our evil Einstein figures it out, Joe Mac-Hack down the street will have a copy. Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 18:41:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25493; Thu, 21 Apr 1994 16:17:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA02029; Thu, 21 Apr 1994 16:15:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA01989; Thu, 21 Apr 1994 15:49:48 +1000 Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22173; Thu, 21 Apr 1994 14:48:42 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA11492; Wed, 20 Apr 94 21:24:53 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA11259; Thu, 21 Apr 1994 00:24:51 -0400 Date: Wed, 20 Apr 1994 23:45:47 -0400 Message-Id: <94042023454772@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: yakov@watson.ibm.com, Greg_Minshall@novell.com, big-internet@munnari.OZ.AU Subject: Re: alignment X-Vms-To: SMTP%"yakov@watson.ibm.com" X-Vms-Cc: SMTP%"Greg_Minshall@novell.com", SMTP%"big-internet@munnari.oz.au",CONTA Greg, I would like to subscribe to the opinion that 'naturally' aligned fields in the protocol headers are extremelly desirable - in fact I could easily go with is a must. Furthermore, fixed size fields is also desirable, if not a must - variable size fields not only that contribute to unaligning, but also make protocol engines processing slower. Yakov makes a good point. Most implementations pass/process link (MAC) headers contiguous to upper layer headers. Link drivers usually allocate receive buffers that are aligned, but the size of the link headers may put upper layers headers at a non-natural alignment. Optimizing the offset in the receive buffers may be a solution, but because it has to be done for all received packets, in a multiprotocol environment, it may have opposite effects for protocols that use padding and those that don't. Which is to say, that where possible, link headers padding could/should be manipulated to help upper layer headers alignment. Alex ----------------- From: SMTP%"yakov@watson.ibm.com" 20-APR-1994 23:18:16.42 To: Greg_Minshall@novell.com, big-internet@munnari.oz.au CC: Subj: alignment Ref: Your note of Wed, 20 Apr 94 14:37:20 PDT Greg, >it would be nice if when a packet has been received the *transport* >header is on some nice alignment for the receiving host... For the purpose of alignment do you count from the beginning of the IP header or from the beginning of the MAC header ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 18:46:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29160; Thu, 21 Apr 1994 17:45:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA02124; Thu, 21 Apr 1994 17:43:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA02097; Thu, 21 Apr 1994 17:21:06 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26488; Thu, 21 Apr 1994 16:39:29 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 21 Apr 94 15:33:15 +0900 From: Masataka Ohta Message-Id: <9404210633.AA13208@necom830.cc.titech.ac.jp> Subject: Re: alignment To: conta@ucx.lkg.dec.com (Alex Conta Networks Engineering - TCP/IP) Date: Thu, 21 Apr 94 15:33:14 JST Cc: yakov@watson.ibm.com, Greg_Minshall@novell.com, big-internet@munnari.OZ.AU In-Reply-To: <94042023454772@ucx.lkg.dec.com>; from "Alex Conta, Networks Engineering - TCP/IP" at Apr 20, 94 11:45 pm X-Mailer: ELM [version 2.3 PL11] > Optimizing the offset in the receive buffers may be a solution, > but because it has to be done for all received packets, in a multiprotocol > environment, it may have opposite effects for protocols that use padding and > those that don't. In a multiprotocol environment? Isn't Greg assuming SIPP only? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Apr 21 23:22:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09098; Thu, 21 Apr 1994 22:27:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA02350; Thu, 21 Apr 1994 22:23:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA02325; Thu, 21 Apr 1994 21:48:44 +1000 Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07247; Thu, 21 Apr 1994 21:17:19 +1000 (from sob@hsdndev.harvard.edu) Date: Thu, 21 Apr 94 07:17:08 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404211117.AA15862@hsdndev.harvard.edu> To: atkinson@itd.nrl.navy.mil, francis@cactus.slab.ntt.jp Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Re: key management something may come out of the DNS security work that will help in the key management area. Since DNS would be an early target for any IPng implementation, key management of at least one type could be assumed during an IPng deployment phase. Scott From owner-Big-Internet@munnari.OZ.AU Fri Apr 22 02:33:45 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18312; Fri, 22 Apr 1994 02:33:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04662 Fri, 22 Apr 1994 02:32:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA02624; Fri, 22 Apr 1994 02:28:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA02599; Fri, 22 Apr 1994 01:56:35 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16909; Fri, 22 Apr 1994 01:57:55 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA26903; Thu, 21 Apr 94 08:57:39 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA29000; Thu, 21 Apr 94 08:56:16 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA11177; Thu, 21 Apr 1994 08:57:02 -0700 Date: Thu, 21 Apr 1994 08:57:02 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404211557.AA11177@jurassic.Eng.Sun.COM> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9404210447.AA24676@ginger.lcs.mit.edu> Subject: Re: SIPP Routing Header & security Noel, >It's worth pointing out that the basic problem here is not the use of a source >route, but the fact that the two hosts uncritically accept, and then use, >information which has come in from the network, without making sure that that >information is reliable and safe to use. It happens to be a source route, >which they uncritically accept and turn around, but the problem is not with >source routing per se, or even *use* of unauthenticated source routes. Good point. The same problem occurs with ICMP redirect. It is not a serious problem on a LAN, but a large public network (e.g. X.25, SMDS, ATM) is a very different story. There is no substitute for real authentication. Bob From owner-Big-Internet@munnari.OZ.AU Fri Apr 22 04:50:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24304; Fri, 22 Apr 1994 04:50:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA02752; Fri, 22 Apr 1994 04:48:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA02727; Fri, 22 Apr 1994 04:18:09 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22872; Fri, 22 Apr 1994 04:19:28 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA24672; Thu, 21 Apr 94 12:24:35 MDT Received: from [130.57.64.148] by WC.Novell.COM (4.1/SMI-4.1) id AA27002; Thu, 21 Apr 94 11:18:23 PDT Date: Thu, 21 Apr 94 11:18:22 PDT Message-Id: <9404211818.AA27002@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: yakov@watson.ibm.com, big-internet@munnari.OZ.AU From: Greg Minshall Subject: Re: alignment Yakov, >For the purpose of alignment do you count from the beginning of >the IP header or from the beginning of the MAC header ? Depending on the MAC, i can "align" my receive buffers (though this is hard on ethernet with the various encapsulation formats - maybe someday chips/boards will be able to help with that). So, i *assume* i can align the start of the internet header. From that, i would like the transport header aligned. Greg From owner-Big-Internet@munnari.OZ.AU Fri Apr 22 06:04:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27484; Fri, 22 Apr 1994 06:04:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA02865; Fri, 22 Apr 1994 05:58:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA02840; Fri, 22 Apr 1994 05:32:55 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23692; Fri, 22 Apr 1994 04:37:40 +1000 (from yakov@watson.ibm.com) Message-Id: <9404211837.23692@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0735; Thu, 21 Apr 94 14:37:26 EDT Date: Thu, 21 Apr 94 14:37:05 EDT To: Greg_Minshall@Novell.COM, big-internet@munnari.OZ.AU Subject: alignment Ref: Your note of Thu, 21 Apr 94 11:18:22 PDT Greg, >Depending on the MAC, I can "align" my receive buffers (though this >is hard on ethernet...) >So, I *assume* I can align the start of the internet header. I wonder how you'll get the alignment with 802.5 and source-routing bridges ? (hint: MAC + LLC header is variable length). Yakov. P.S. I think that from a host perspective what you *really* want to do is to make sure that the transport payload is properly align. For that matter, it would be convinient to have a field somewhere closer to the beginnig of a packet that would provide the offset to the transport payload. From owner-Big-Internet@munnari.OZ.AU Fri Apr 22 07:59:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25961; Fri, 22 Apr 1994 05:25:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA02796; Fri, 22 Apr 1994 05:23:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA02793; Fri, 22 Apr 1994 05:12:37 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22882; Fri, 22 Apr 1994 04:19:53 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA24689; Thu, 21 Apr 94 12:24:57 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB27002; Thu, 21 Apr 94 11:18:49 PDT Date: Thu, 21 Apr 94 11:18:49 PDT Message-Id: <9404211818.AB27002@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Masataka Ohta From: Greg Minshall Subject: Re: alignment Cc: big-internet@munnari.OZ.AU Masataka, >In a multiprotocol environment? Isn't Greg assuming SIPP only? "IPng only". Or, more correctly, i'd like to make sure that IPng makes things easier in this regard. Greg From owner-Big-Internet@munnari.OZ.AU Fri Apr 22 08:00:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26032; Fri, 22 Apr 1994 05:27:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA02824; Fri, 22 Apr 1994 05:25:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA02779; Fri, 22 Apr 1994 05:01:42 +1000 Received: from haig.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25006; Fri, 22 Apr 1994 05:02:54 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9404211902.25006@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 21 Apr 1994 15:08:44 +0100 To: big-internet@munnari.OZ.AU Subject: Re: A modest proposal In-Reply-To: Your message of "Wed, 20 Apr 94 13:07:14 BST." <9404201208.13559@munnari.oz.au> Date: Thu, 21 Apr 94 15:08:00 +0100 From: Jon Crowcroft this, by the way, was not a joke - if i had meant it as such, a big smiley would have appeared comments welcome (there seems to be a deafening silence) > I PING: Ideal Protocol for the Internet Next > Generation From owner-Big-Internet@munnari.OZ.AU Fri Apr 22 16:35:08 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20885; Fri, 22 Apr 1994 16:35:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28595 Fri, 22 Apr 1994 16:34:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA03391; Fri, 22 Apr 1994 16:28:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA03366; Fri, 22 Apr 1994 16:06:27 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19743; Fri, 22 Apr 1994 16:07:39 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 22 Apr 94 15:00:48 +0859 From: Masataka Ohta Message-Id: <9404220601.AA18718@necom830.cc.titech.ac.jp> Subject: Re: alignment To: yakov@watson.ibm.com Date: Fri, 22 Apr 94 15:00:45 JST Cc: Greg_Minshall@Novell.COM, big-internet@munnari.OZ.AU In-Reply-To: <9404211837.23692@munnari.oz.au>; from "yakov@watson.ibm.com" at Apr 21, 94 2:37 pm X-Mailer: ELM [version 2.3 PL11] > >Depending on the MAC, I can "align" my receive buffers (though this > >is hard on ethernet...) > >So, I *assume* I can align the start of the internet header. > > I wonder how you'll get the alignment with 802.5 and source-routing > bridges ? > (hint: MAC + LLC header is variable length). A simple workaround would be to add variable length padding bytes. It might be better not to use such MAC at all. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Apr 22 22:20:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03957; Fri, 22 Apr 1994 22:20:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA03679; Fri, 22 Apr 1994 22:18:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA03662; Fri, 22 Apr 1994 22:09:38 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02273; Fri, 22 Apr 1994 21:30:16 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00792; Fri, 22 Apr 1994 13:30:12 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA14334; Fri, 22 Apr 1994 13:30:11 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404221130.AA14334@dxcoms.cern.ch> Subject: Re: alignment To: big-internet@munnari.OZ.AU (bigi) Date: Fri, 22 Apr 1994 13:30:10 +0200 (MET DST) In-Reply-To: <9404202137.AA24678@WC.Novell.COM> from "Greg Minshall" at Apr 20, 94 02:37:20 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 550 Greg et al, I think we have to accept that using NSAPAs and insisting on 2**N alignment are incompatible requirements. NSAPAs are variable length. GOSIP NSAPAs are a national subset of NSAPAs that happen to be fixed length. There is a clearly stated requirement from part of our community to support CLNP islands and NSAPA-addressable islands via the Internet. But this is not the same thing as a requirement that IPng use NSAPA addressing. Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.OZ.AU Fri Apr 22 22:23:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04105; Fri, 22 Apr 1994 22:23:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA03694; Fri, 22 Apr 1994 22:22:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA03676; Fri, 22 Apr 1994 22:13:41 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03263; Fri, 22 Apr 1994 21:58:56 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA22764; Fri, 22 Apr 1994 14:02:50 +0200 Message-Id: <199404221202.AA22764@mitsou.inria.fr> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: francis@cactus.slab.ntt.jp, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of "Wed, 20 Apr 1994 21:05:16 EDT." <9404210105.AA11907@itd.nrl.navy.mil> Date: Fri, 22 Apr 1994 14:02:50 +0200 From: Christian Huitema Ran, When Dave Clark mentioned the use of LLIDs for "security" he did not mean "end to end security" where solutyion like SIPP's AP are entirely appropriate. He specifically addressed the "denial of service" attack, i.e. an intruder filling the network with packets so that your TCP connections (or RTP) starve. The "correct" answer is through some kind of public key, but that is far too CPU demanding for routers. In fact, even computing MD5 on all packet contents is probably too expensive - routers are not designed to pass the packet contents through their CPUs. Beside computing SIPP's AP in intermediate routers require that you expose the key to all these routers, which mean that any of them can now spoof you. In the absence of these two solutions, sticking a "random" number in the packet makes it harder for outsiders (not in the transmission path). The flow-id may play this role. The only problem I see is that the 24 bits flow-id field is a bit small. Indeed, the exchange of the flow-id between the routers and you must be authentified, e.g. protected in an AP payload. We will need to codify this exchange. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 03:10:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10332; Sat, 23 Apr 1994 01:15:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA03855; Sat, 23 Apr 1994 01:13:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA03830; Sat, 23 Apr 1994 00:49:01 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09502; Sat, 23 Apr 1994 00:50:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10204; Fri, 22 Apr 94 10:50:17 -0400 Date: Fri, 22 Apr 94 10:50:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404221450.AA10204@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security Cc: jnc@ginger.lcs.mit.edu Indeed, the exchange of the flow-id between the routers and you must be authentified, e.g. protected in an AP payload. We will need to codify this exchange. Yah, any exchanges between hosts and routers in which the hosts install state in the routers (be it via explicit setup, or user state in each data packet) is going to have to be authenticated, and if necessary, made private. I've been worrying about this in the context of multi-cast flow setup; it's easier in unicast. Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 04:09:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15123; Sat, 23 Apr 1994 03:35:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA04033; Sat, 23 Apr 1994 03:33:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA04019; Sat, 23 Apr 1994 03:19:42 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12932; Sat, 23 Apr 1994 02:35:00 +1000 (from estrin@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 22 Apr 1994 09:33:36 -0700 Date: Fri, 22 Apr 1994 09:33:36 -0700 Message-Id: <199404221633.AA08515@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: ddc@lcs.mit.edu, big-internet@munnari.OZ.AU Subject: [jnc@ginger.lcs.mit.edu: Re: SIPP Routing Header & security] Reply-To: estrin@usc.edu Read the part of the IAB security workshop report that talks about using hop by hop trust mechanisms to support this function. Then think about RSVP reservation messages being propagated hop by hop upstream and we can build a mechanism int he context of multicast. Date: Fri, 22 Apr 94 10:50:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) To: big-internet@munnari.oz.au Subject: Re: SIPP Routing Header & security Cc: jnc@ginger.lcs.mit.edu Indeed, the exchange of the flow-id between the routers and you must be authentified, e.g. protected in an AP payload. We will need to codify this exchange. Yah, any exchanges between hosts and routers in which the hosts install state in the routers (be it via explicit setup, or user state in each data packet) is going to have to be authenticated, and if necessary, made private. I've been worrying about this in the context of multi-cast flow setup; it's easier in unicast. Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 04:19:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15232; Sat, 23 Apr 1994 03:38:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA04048; Sat, 23 Apr 1994 03:37:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA04016; Sat, 23 Apr 1994 03:19:31 +1000 Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14443; Sat, 23 Apr 1994 03:20:46 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA08231 (5.65c/IDA-1.4.4nsd for ); Fri, 22 Apr 1994 10:20:34 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA21408 (5.65c/IDA-1.4.4-910725); Fri, 22 Apr 1994 10:20:28 -0700 Message-Id: <199404221720.AA21408@remmel.NSD.3Com.COM> To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU Subject: Re: alignment In-Reply-To: Your message of "Fri, 22 Apr 94 13:30:10 +0200." <9404221130.AA14334@dxcoms.cern.ch> Date: Fri, 22 Apr 94 10:20:28 -0700 From: tracym@NSD.3Com.COM > I think we have to accept that using NSAPAs and insisting > on 2**N alignment are incompatible requirements. NSAPAs are > variable length. GOSIP NSAPAs are a national subset of NSAPAs > that happen to be fixed length. > > There is a clearly stated requirement from part of our > community to support CLNP islands and NSAPA-addressable > islands via the Internet. But this is not the same thing > as a requirement that IPng use NSAPA addressing. Brian, I still don't see the problem with the basic CATNIP approach of padding the address fields. The length octet of an arbitrary NSAP should be left as is, with (uncounted) trailing zeros inserted to pad to the next appropriate boundary. Translating from and to CLNP would be no problem (at least for the addresss). [If CLNP was mine, I'd define, and then mandate the use of, zero-valued padding octets between any header fields starting with the first address field. Padding would be used to align the start of all address fields and option fields to 4-octet boundaries. And get rid of Fletcher, too! )but it's not;-( ] Regards, Tracy From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 08:50:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25161; Sat, 23 Apr 1994 08:50:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA04334; Sat, 23 Apr 1994 08:48:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA04320; Sat, 23 Apr 1994 08:27:40 +1000 Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24761; Sat, 23 Apr 1994 08:29:00 +1000 (from sob@hsdndev.harvard.edu) Date: Fri, 22 Apr 94 18:28:30 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404222228.AA12457@hsdndev.harvard.edu> To: Greg_Minshall@Novell.COM, atkinson@itd.nrl.navy.mil, francis@cactus.slab.ntt.jp Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM > Yes, though if i understand Ran's stuff, and enough crypto, you *still* > need to set up a private key. But, the DNS stuff seems to guarantee that > *public* keys can be passed around. > > Of course, this is going to take a long time to code up, etc. (plus > standardization). And, there has to be someway figured out, documented, > standardized, coded, etc., to have two end nodes, knowing each other's > public keys, to come up with some shared private key (for efficiency). All true, but it don't hurt to have only one base to build on. Scott From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 08:54:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25251; Sat, 23 Apr 1994 08:54:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA04349; Sat, 23 Apr 1994 08:53:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA04303; Sat, 23 Apr 1994 08:14:56 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24350; Sat, 23 Apr 1994 08:16:12 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA20407; Fri, 22 Apr 94 16:21:11 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA00859; Fri, 22 Apr 94 15:14:59 PDT Date: Fri, 22 Apr 94 15:14:58 PDT Message-Id: <9404222214.AA00859@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: sob@hsdndev.harvard.edu (Scott Bradner), atkinson@itd.nrl.navy.mil, francis@cactus.slab.ntt.jp From: Greg Minshall Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM Scott, >something may come out of the DNS security work that will help in the >key management area. Since DNS would be an early target for any IPng >implementation, key management of at least one type could be assumed >during an IPng deployment phase. Yes, though if i understand Ran's stuff, and enough crypto, you *still* need to set up a private key. But, the DNS stuff seems to guarantee that *public* keys can be passed around. Of course, this is going to take a long time to code up, etc. (plus standardization). And, there has to be someway figured out, documented, standardized, coded, etc., to have two end nodes, knowing each other's public keys, to come up with some shared private key (for efficiency). Greg From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 08:57:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25376; Sat, 23 Apr 1994 08:57:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA04375; Sat, 23 Apr 1994 08:56:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA04306; Sat, 23 Apr 1994 08:24:00 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23999; Sat, 23 Apr 1994 07:59:33 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18958; Fri, 22 Apr 94 16:04:47 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB00789; Fri, 22 Apr 94 14:58:36 PDT Date: Fri, 22 Apr 94 14:58:36 PDT Message-Id: <9404222158.AB00789@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU (bigi) From: Greg Minshall Subject: Re: alignment Brian, >I think we have to accept that using NSAPAs and insisting >on 2**N alignment are incompatible requirements. NSAPAs are >variable length. GOSIP NSAPAs are a national subset of NSAPAs >that happen to be fixed length. I don't think there is an incompatibility. If you say that 1-8 byte NSAPs take exactly 8 bytes, 9-16 byte NSAPs take exactly 16 bytes, etc., then you are using NSAPs *and* getting alignment. (**) >There is a clearly stated requirement from part of our >community to support CLNP islands and NSAPA-addressable >islands via the Internet. But this is not the same thing >as a requirement that IPng use NSAPA addressing. Agreed. Greg (**) Which is to say, you are using the value assigned by some NSAP assignment authority, possibly already assigned to some end node, and using that for both routing and end node identification purposes. From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 09:25:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26360; Sat, 23 Apr 1994 09:25:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA04405; Sat, 23 Apr 1994 09:23:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA04391; Sat, 23 Apr 1994 09:03:38 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25632; Sat, 23 Apr 1994 09:04:58 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA22772; Fri, 22 Apr 94 17:08:57 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA00988; Fri, 22 Apr 94 16:02:45 PDT Date: Fri, 22 Apr 94 16:02:44 PDT Message-Id: <9404222302.AA00988@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: francis@cactus.slab.ntt.jp (Paul Francis) From: Greg Minshall Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Paul, >I'm addressing the case where, say, you're going to talk with Steve >Deering. >I (in Japan) have no way of sniffing packets between you and Steve. >Still, I want to listen to your conversation. I know you're address >and I know Steve's address. I periodically send a packet to your >host that looks like it came from Steve's host, but has a reverse source >route that causes the packet to go to my host. When you start talking >to Steve, your host receives such a packet, accepts the reverse source >route, and starts sending the packets to me. I listen to the packet, >reformat the header to feed Steve's host a source route that makes his >headers come back to me, and now I'm in the loop. I think the point of, or the lesson to be learned from, the "current sniffing attacks" is that *you*, in Japan, *do* have a way of sniffing packets between you and Steve (by breaking in to some random system which is between you and Steve - there are lots of such, and then "sniffing"). Greg From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 10:00:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27575; Sat, 23 Apr 1994 10:00:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA04469; Sat, 23 Apr 1994 09:58:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA04410; Sat, 23 Apr 1994 09:23:56 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26362; Sat, 23 Apr 1994 09:25:16 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA23863; Fri, 22 Apr 94 17:30:25 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB01027; Fri, 22 Apr 94 16:24:14 PDT Date: Fri, 22 Apr 94 16:24:14 PDT Message-Id: <9404222324.AB01027@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jon Crowcroft From: Greg Minshall Subject: Re: A modest proposal Cc: big-internet@munnari.OZ.AU Jon, Seems to me to be too few bits to be interesting (but, maybe i've been contaminated by all the 64/160 bit address which have been floating around...). Greg From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 10:03:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27655; Sat, 23 Apr 1994 10:03:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA04484; Sat, 23 Apr 1994 10:02:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA04449; Sat, 23 Apr 1994 09:42:35 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27031; Sat, 23 Apr 1994 09:43:51 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA24344; Fri, 22 Apr 94 17:47:49 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA01108; Fri, 22 Apr 94 16:41:37 PDT Date: Fri, 22 Apr 94 16:41:36 PDT Message-Id: <9404222341.AA01108@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atkinson@itd.nrl.navy.mil (Ran Atkinson), big-Internet@munnari.OZ.AU From: Greg Minshall Subject: Re: SIPP Routing Header & security Cc: sipp@sunroof2.Eng.Sun.COM Ran, > SIPP in fact has a strong authentication mechanism that is easily >implemented. That mechanism is being widely implemented and will >probably be widely deployed (in no small part this is because it is >easily exported from most countries and is easily imported and is >easily used in most countries so commercial vendors can include it >with every copy of their OS). I believe that the SIPP spec should >require that an Authentication Header be present in all packets that >contain a Routing Header and I have said so at SIPP meetings in >Seattle (e.g. Sunday evening). The NRL SIPP implementation is likely >to ignore Routing Headers if the packet omits the Authentication >Header because it represents an unacceptable security risk in the >current Internet environment. I think someone else already said approximately this, but i think it is important that you understand that the existence of a packet format does nothing to actually make "a strong authentication mechanism ... easily implemented". The whole key management issue is so thorny (as far as *i* can tell) as to make your statement discountable. I would *like* there to be a strong authentication mechanism in SIPP or in any of the IPng proposals. There is today NO SUCH THING. (**) (Which means, by the way, that the turning around of SIPP "source routes" is totally unacceptable security-wise as of this point, in my always-so-humble opinion.) Greg (**) And, by the way, this situation clearly isn't SIPP's fault (or any other IPng's fault). And, fixing it isn't something i believe any of the IPng proposals needs to do (though, if you managed to do so :) that would be nice!). Any solution to this issue would almost certainly admit to a trivial mapping onto any of the other proposals. From owner-Big-Internet@munnari.OZ.AU Sat Apr 23 10:06:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27727; Sat, 23 Apr 1994 10:06:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA04499; Sat, 23 Apr 1994 10:05:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA04435; Sat, 23 Apr 1994 09:34:16 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26796; Sat, 23 Apr 1994 09:35:34 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA24150; Fri, 22 Apr 94 17:40:47 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA01061; Fri, 22 Apr 94 16:34:34 PDT Date: Fri, 22 Apr 94 16:34:33 PDT Message-Id: <9404222334.AA01061@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: big-internet@munnari.OZ.AU From: Greg Minshall Subject: WARTs and IPng Hi, all. After IPv4 was released, various things changed in its environment which caused new features and hacks to be developed and glommed onto it. Some of these things have integrated in reasonably nicely; others stick out horribly. Additionally, because of the way things work, certain things we might like to do are reasonably hard. I would like to make sure that, to the extent possible, these issues are addressed in IPng. In order to do that, i have been attempting to collect a list of these WARTs. (Note that not all are "bad"; i think, however, that all are accruals to IPv4 resulting from changes in the environment since the initial deployment of IPv4.) Here is the current (totally unprioritized) list. If you have more, please send them to me and i will add them. Greg ---- Warts on IP and the Internet: ; New ICMP messages You'd like to send a new ICMP message to a host, but you don't know if the host "groks" the new ICMP message (and, the message is "data driven", eg, if the host doesn't change its send behaviour, you will continue generating these new message types). Also (firewalls, security, etc.), need (? - nice to have?) some way of saying "if you don't understand this, then SHUT UP!". ; Firewalls The existence thereof. Because of non-research use of (connection to) Internet. Recognize firewalls as a first class object in the architecture (whatever that means). The desire of a firewall to know "when" "who" tried to ask "whom" to do "what". Should this packet (e-mail message? gasp!) ever leave this "site", "company", "organization"... ; "Mask and Match" Hard to do ad hoc networking ; Priority queuing, fair queuing, etc. Because (?) of more traffic classes, shared usage by a larger number of organiations/users; administrative policies. Some ??? way of describing priority and/or "slice of the pie" in a packet (so the router doesn't have to grunge around in the packet). ; packet classifying Required for priority/fair queueing. A packet class field, with local or global significance. ; drop sets (w/in packet stream) For graceful degradation with newer (time-based) streams A field which describes a "drop set", precedence within that set, etc. ; link (and other resource) sharing Like priority/fair queueing. Fair queueing solution? ; routers need to look at all options (and shouldn't have to) Performance conflicting with desires for extensibility End-to-end options separate from hop-by-hop options. ; TMUX Performance for small packets to the same destination host Make it part of the base spec (if it were worth it) ; Fragmentation Doesn't carry total datagram length in fragments. Doing it in routers probably keeps sending host blissfully unaware of performance it is incurring. Previous hop versus source Sometimes you'd like to know the "previous hop" of a packet (previous router). RFC1577; "Classical IP and ARP over ATM" IP over different data links. Would it be enough to include the ATM node address as the IPng node address? RFC1560; "The Multiprotocol Internet" The Internet as a set of wires which connect the world so we want to use those wires to support "all" of our applications. RFC1548; "PPP" Light-weight connection to a network (and to the Internet). RFC1546; "Host Anycasting Service" New idea - type-based addressing. RFC1545; "FOOBAR" Multiprotocol. RFC1542; "BOOTP" More hosts ==> management (configuration) harder. So, make it easier. RFC1541; "DHCP" == BOOTP. RFC1519; "CIDR" Impose an N-level hierarchical addressing structure to simplify the routing problem. RFC1518; "Address allocation with CIDR" == CIDR. RFC1510; "Kerberos" Larger user population, non-research use of Internet, coupled with desire to protect resources. Need to identify/authenticate principals RFC1492; "An Access Control Protocol, Sometimes Called TACACS" ??? == Kerberos. RFC1483; "Multiprotocol Encapsulation over AAL5" IP over various link layers. IP over cell-oriented media. (Eventually, issues about cell drop probabilities ==> packet drop probabilities.) RFC1478; "IDPR" (policy routing) Muliple policies in the routing infrastructures + source sensitivity to routing. RFC1433; "Directed ARP" IP over various media ???. RFC1393; "Traceroute IP option" In general, traceroute is a hack to manage the network. (Probably a good wart...) RFC1329; "ARP for dual MAC FDDI networks" ??? RFC1326; "Mutual encapsulation considered dangerous" Increased use of the Internet in order to achieve connectivity for various protocols. Reality that there are patches (large or small) where any given protocol will not have connectivity (but needs connectivity). RFC1322; "Unified approach to inter-domain routing" ??? RFC1306; "Experiences supporting by-request circuit switched T3 networks" ??? RFC1281; "Guidelines for the secure operation of the Internet" Lots of people, very open, Internet as environment for "mission critical" applications, concern to protect assets/resources. RFC1267; "BGP-3" Split between IGP and EGP; reflects the need to have clean (well-defined, thus protected) borders between administrative domains. RFC1256; "Router Discovery" Hosts aren't directly connected to routers (IMPs). The fact that with increased number of nodes, hand configuring the local router doesn't work (especially if routers go down). RFC1247; "OSPF v 2" RIP doesn't scale. RFC1234; "Tunneling IPX through IP" Multiple protocols over the Internet; connectivity. RFC1209; "Transmission of IP datagrams over SMDS" IP over various data links. RFC1193; "Client requirements for real-time communications" New (time-based) applications. RFC1191; "Path MTU discovery" Heterogeneous links + desire for increased performance. RFC1190; "ST-II" Guaranteed performance for time-based applications. RFC1144; "VJ compression" IP over low speed links, quickly. RFC1141; "Incremental updating of the IP checksum" Better performance (for routing). RFC1112; "IP Multicasting" 1-N communications. RFC1088; "IP over NetBIOS" Connectivity in a multi-protocol Internet. RFC1075; "DVMRP" == IP Multicasting RFC1058; "RIP" Need for routing at the network (rather than link == IMP) layer. Actually, wasn't this a key implication of catenet model? RFC1035; "DNS" Larger number of name<>address bindings makes manual, centralized table incorrect. RFC1029; "Fault tolerant approach to ARP for multi-LAN system of ethernets" ??? RFC1027; "Using ARP to implement transparent subnet gateways" Well, make IP subnetting easier to use. RFC950; "IP subnetting" Deal with scaling in number of wires. RFC947; "Multi-network broadcasting in the Internet" There is more than one network in the Internet. RFC922; "Broadcasting IP datagrams in the presence of subnets" Subnets exist. RFC903; "RARP" Eliminate manual configuration, due to increased number of hosts. RFC893; "Trailer encapsulation" Desire to have as efficient as possible a method of running IP over a given data link. RFC826; "ARP" There is no algorithmic mapping of IP address into data link address. From owner-Big-Internet@munnari.OZ.AU Sun Apr 24 09:55:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14720; Sun, 24 Apr 1994 09:55:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA05626; Sun, 24 Apr 1994 09:53:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA05612; Sun, 24 Apr 1994 09:33:46 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11512; Sun, 24 Apr 1994 08:14:57 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA01071; Sat, 23 Apr 94 18:14:51 EDT Date: Sat, 23 Apr 94 18:14:51 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404232214.AA01071@itd.nrl.navy.mil> To: Greg_Minshall@Novell.COM, atkinson@itd.nrl.navy.mil, big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security Cc: sipp@sunroof2.Eng.Sun.COM % I think someone else already said approximately this, but i think it is % important that you understand that the existence of a packet format does % nothing to actually make "a strong authentication mechanism ... easily % implemented". The whole key management issue is so thorny (as far as *i* % can tell) as to make your statement discountable. Greg, You are mixing apples and oranges. They authentication mechanism is deliberately decoupled from key management, at least in SIPP. SIPP's authentication mechanism really is easily implemented. Now key management is related, but the viability and implementation complexity of authentication is NOT dependent upon any particular key management mechanism. There are prototype implementations of SIPP's authentication mechanism which act as existence proofs of the decoupling. SIPP is capable of using asymmetric algorithms and the DNS Security proposal's public keys if folks desire to do that. However, asymmetric algorithms are often more computationally expensive than symmetric algorithms, so SIPP has proposed mandating a couple of widely used symmetric algorithms (i.e. MD5 and DES CBC) as a minimum for interoperability. In the short term, SIPP implementations are likely to use manual key management. In the longer term, SIPP implementations will probably use the public keys from the DNS Security WG efforts to bootstrap into an Internet Key Mgmt Protocol. The latter is being worked on by several folks offline from the IPng efforts and the current Security AD has stated that the key mgmt protocol work belongs within the IPsec WG for now. % I would *like* there to be a strong authentication mechanism in SIPP or in % any of the IPng proposals. There is today NO SUCH THING. (**) Not True, as the above explains. What no IPng proposal includes is a key management protocol. That omission is not surprising since the key management protocol is at the application layer and is in no way dependent on the network-layer protocol and should work just fine over IPv4, CLNP, or SIPP. % (Which means, by the way, that the turning around of SIPP "source routes" % is totally unacceptable security-wise as of this point, in my % always-so-humble opinion.) Not true. It means that one should not invert source routes that aren't authenticated. One could most certainly setup authentication keys with frequent correspondent hosts and use source routing within the set of authenticatable hosts. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Sun Apr 24 15:07:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22810; Sun, 24 Apr 1994 14:35:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA05867; Sun, 24 Apr 1994 14:33:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA05838; Sun, 24 Apr 1994 14:08:24 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22069; Sun, 24 Apr 1994 14:09:46 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa22583; 24 Apr 94 0:09 EDT To: Ran Atkinson Cc: Greg_Minshall@novell.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of Sat, 23 Apr 1994 18:14:51 -0400. <9404232214.AA01071@itd.nrl.navy.mil> Date: Sun, 24 Apr 1994 00:09:35 -0400 From: John Curran Message-Id: <9404240009.aa22583@nic.near.net> -------- ] From: Ran Atkinson ] Subject: Re: SIPP Routing Header & security ] Date: Sat, 23 Apr 94 18:14:51 EDT ] ] ... ] [quoting Greg_Minshall] ] % I would *like* there to be a strong authentication mechanism in SIPP or in ] % any of the IPng proposals. There is today NO SUCH THING. (**) ] ] Not True, as the above explains. What no IPng proposal includes is a ] key management protocol. That omission is not surprising since the ] key management protocol is at the application layer and is in no way ] dependent on the network-layer protocol and should work just fine over ] IPv4, CLNP, or SIPP. Okay, I agree that key management is not part of the network service, and Greg is probably using the term "authentication mechanism" in a much broader scope than generally expected, but the fact remains that there is not a deployable IPng security _architecture_ right now, due to the lack of a key distribution mechanism. It is certainly true that having specifications for the network-layer (SIPP) component of the security architecture is a very good thing, and other IPng efforts had best rise to the challenge or risk being left behind. Even still, without an agreed upon ubiquitous key-distribution mechanism, actual usage of the security option will be quite rare. Are we actually going to deploy an IPng without having this settled? Is there some belief that we can get it deployed and adopted after the fact? (Our efforts with subnetting, TTL, and multicast deployment into the installed base have had mixed results at best). Perhaps it would be worth holding IPng deployment (regardless of which proposal is selected) so that we can include a standard key-management mechanism and hence usable security in the base capabilities. /John From owner-Big-Internet@munnari.OZ.AU Sun Apr 24 19:50:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02504; Sun, 24 Apr 1994 19:50:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA06130; Sun, 24 Apr 1994 19:48:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA06127; Sun, 24 Apr 1994 19:42:52 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02292; Sun, 24 Apr 1994 19:44:13 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03522; Sun, 24 Apr 1994 11:44:09 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10695; Sun, 24 Apr 1994 11:44:08 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404240944.AA10695@dxcoms.cern.ch> Subject: Re: alignment To: big-internet@munnari.OZ.AU (bigi) Date: Sun, 24 Apr 1994 11:44:08 +0200 (MET DST) In-Reply-To: <9404222208.AA00826@WC.Novell.COM> from "Greg Minshall" at Apr 22, 94 03:08:11 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 382 This thread seems to have split (some on big-i, some on the IPng Directorate's list, and some private). Nothing on tuba strangely :-) This one is going to big-i. Just to say that yes, you could make a rule that padding is used to align the field following an NSAPA on a 4-byte boundary. Let's stop talking about it for now, until we know whether we will be using NSAPAs. Brian From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 02:15:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14395; Mon, 25 Apr 1994 02:15:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA06471; Mon, 25 Apr 1994 02:13:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA06435; Mon, 25 Apr 1994 01:39:42 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13242; Mon, 25 Apr 1994 01:41:04 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12956; Sun, 24 Apr 94 11:41:02 EDT Date: Sun, 24 Apr 94 11:41:02 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404241541.AA12956@itd.nrl.navy.mil> To: jcurran@nic.near.net Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU % It really doesn't matter what state the work is in, the issue of % whether of not IPng should have such a mechanism is a question about % basic IPng requirements. IPng is not just a network-layer issue, to % actually work it is going to require shipping new transport code, new % routing software, new DNS software, etc. It's about time we lived up % to the fact that IPng is going to affect many layers, and IPng represents % one the few opportunities we will ever get to deploy enhanced functionality % to the "Internet" suite of protocols. % % /John John, I'm sorry. It seems that I've missed the main point that you (and perhaps Greg ?) have been trying to make. If you mean that IPng will have impacts outside the network layer, I agree. If you mean that security is multi-layer, I agree with that as well. If the IPng Directorate feels there are requirements outside the network layer, ALL of those requirements need to be put openly on the table now AND the various IPng WGs need to be permitted to work on those requirements themselves now. I think there has been general understanding that some DNS extensions to support address records was within the scope of IPng WGs. I don't think many other items outside the internet-layer have been understood to be within the purview of IPng WGs so far. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 03:08:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10911; Mon, 25 Apr 1994 00:30:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA06371; Mon, 25 Apr 1994 00:28:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA06357; Mon, 25 Apr 1994 00:21:26 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08890; Sun, 24 Apr 1994 23:45:37 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11847; Sun, 24 Apr 94 09:45:34 EDT Date: Sun, 24 Apr 94 09:45:34 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404241345.AA11847@itd.nrl.navy.mil> To: jcurran@nic.near.net Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU % Okay, I agree that key management is not part of the network service, % and Greg is probably using the term "authentication mechanism" in a much % broader scope than generally expected, but the fact remains that there is % not a deployable IPng security _architecture_ right now, due to the lack % of a key distribution mechanism. John, At the risk of quibbling excessively, I think that there is at least one IPng Security Architecture (in fact I have had an Internet-Draft describing the SIPP Security Architecture for a while now, a new version will appear next week with minor changes). The SIPP Security Architecture is limited to the network-layer, but it does discuss key management and the relationship between key management and the other services (i.e. authentication, integrity, and confidentiality). What the community lacks is a general-purpose multi-layer "Internet Security Architecture" -- I am told that the IRTF's Privacy & Security Research Group (PSRG) is developing one. I'd suggest you ask them about where that effort stands. % It is certainly true that having specifications for the network-layer (SIPP) % component of the security architecture is a very good thing, and other IPng % efforts had best rise to the challenge or risk being left behind. It is important to understand that an ISO Network Layer Security Protocol (NLSP) specification does exist. I've read that ISO spec and I do not understand it, but it does exist. The TUBA folks could use that if they wished to. A recent note to big-Internet indicates that someone at NSA^h^h^hNIST is looking into TUBA security and that they plan to reuse the (currently non-existent) IPv4 Security Protocol (if/when one exists). % Even still, without an agreed upon ubiquitous key-distribution mechanism, % actual usage of the security option will be quite rare. Are we actually % going to deploy an IPng without having this settled? Is there some belief % that we can get it deployed and adopted after the fact? (Our efforts with % subnetting, TTL, and multicast deployment into the installed base have had % mixed results at best). Perhaps it would be worth holding IPng deployment % (regardless of which proposal is selected) so that we can include a standard % key-management mechanism and hence usable security in the base capabilities. I fully agree that we need key management yesterday. I doubt that anyone in the SAAG would disagree with that assertion. I would argue (and have in the past argued) that key management is so important to so many things (e.g. IPv4, IPng, OSPF authentication, BGP authentication, Mobile IP) that we should have a separate Internet Key Mgmt WG within the Security Area. There are some folks who strongly disagree with the notion of adding security directly to protocols above IP and want to put all their eggs in the IPv4 Security Protocol basket. I am not one of those folks. I want a generic multi-purpose key management protocol. The concept of splitting out key mgmt from the IPv4 Security Protocol WG was discussed in Seattle and the Security AD decided against splitting out key mgmt into its own WG. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 04:06:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16230; Mon, 25 Apr 1994 03:25:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA06540; Mon, 25 Apr 1994 03:23:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA06523; Mon, 25 Apr 1994 03:03:05 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10968; Mon, 25 Apr 1994 00:35:42 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa09116; 24 Apr 94 10:35 EDT To: Ran Atkinson Cc: big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of Sun, 24 Apr 1994 09:45:34 -0400. <9404241345.AA11847@itd.nrl.navy.mil> Date: Sun, 24 Apr 1994 10:35:35 -0400 From: John Curran Message-Id: <9404241035.aa09116@nic.near.net> -------- ] From: Ran Atkinson ] Subject: Re: SIPP Routing Header & security ] Date: Sun, 24 Apr 94 09:45:34 EDT ] ] % Okay, I agree that key management is not part of the network service, ] % and Greg is probably using the term "authentication mechanism" in a much ] % broader scope than generally expected, but the fact remains that there is ] % not a deployable IPng security _architecture_ right now, due to the lack ] % of a key distribution mechanism. ] ] John, ] ] At the risk of quibbling excessively, I think that there is at least ] one IPng Security Architecture (in fact I have had an Internet-Draft ] describing the SIPP Security Architecture for a while now, a new ] version will appear next week with minor changes). The SIPP Security ] Architecture is limited to the network-layer, but it does discuss key ] management and the relationship between key management and the other ] services (i.e. authentication, integrity, and confidentiality). Ran, I'm aware of the SIPP Security draft, NLSP, and even the recent work in DNS security. As has been noted before, none of it is deployable now, and specifications for a network-layer security architecture will not amount to much without a key distribution mechanism. I believe that this was the point that Greg was trying to make. ] What the community lacks is a general-purpose multi-layer "Internet ] Security Architecture" -- I am told that the IRTF's Privacy & Security ] Research Group (PSRG) is developing one. I'd suggest you ask them ] about where that effort stands. It really doesn't matter what state the work is in, the issue of whether of not IPng should have such a mechanism is a question about basic IPng requirements. IPng is not just a network-layer issue, to actually work it is going to require shipping new transport code, new routing software, new DNS software, etc. It's about time we lived up to the fact that IPng is going to affect many layers, and IPng represents one the few opportunities we will ever get to deploy enhanced functionality to the "Internet" suite of protocols. /John From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 04:06:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16261; Mon, 25 Apr 1994 03:27:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA06566; Mon, 25 Apr 1994 03:25:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA06526; Mon, 25 Apr 1994 03:09:14 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15366; Mon, 25 Apr 1994 02:51:26 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA10317; Sun, 24 Apr 94 09:45:02 -0700 Received: by xirtlu.zk3.dec.com; id AA04362; Sun, 24 Apr 1994 12:44:57 -0400 Message-Id: <9404241644.AA04362@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: jcurran@nic.near.net, big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of "Sun, 24 Apr 94 09:45:34 EDT." <9404241345.AA11847@itd.nrl.navy.mil> Date: Sun, 24 Apr 94 12:44:51 -0400 X-Mts: smtp Ran your being so nice. I won't be. The spec has been out there and evolving for at least 6 months. It provides a template and some ideas specifically around this discussion. No other proposal has provided any text I can even look at or discuss as an 'implementor'. Theories are great but unless they are written down its hard to code them, unless you want to write the spec yourself. IPng should not be held up for lack of an agreed upon key management protocol as far as its 'selection'. Whether we want to 'deploy' without a key management solution is another issue. Question: Won't different international domains use different key management protocols? Or can this work internationally? )--> thanks. If folks don't read all the IPng specs and I figure that out when I see anti or pro statements in this discussion I am just going to hit delete on my keyboard. I was appalled at the SIPP IPAE meeting as an example (Seattle, IETF) how many folks had comments and obviously had not read the specs. Like I said 'd' key. There is just too much work to waste time on speculating unless its an architecture discussion and that is a good thing. But in this case SIPP has defined a place holder for security with specifications. Is it bad or good or close? If you do not agree with how the place holder is defined for SIPP then state what you don't like about the approach. At this point we need to try not to mix up what actually is proposed, what is actually not proposed, and what else is needed in a proposal. These can be discussed intelligently and technically (which I personnally would like to see more of as opposed to all this marketing and political discussion )--> if the IPng reqs don't cover the market then thats a valid discussion). I hate when folks are political during a technical discussion and technical during a political discussion because it makes debating almost invalid. And then when not reading the specs its impossible )--> 'd-key'. I am just listening and learning from the discussion but I would like to see a point of reference here in the debate. Please separate them. What I do know is that vendors want to ship products internationally and not break export restrictions, so providing a template that will let the customer use their confidentiality mechanisms within the environment is something that is important and a good idea. /jim From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 06:24:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18399; Mon, 25 Apr 1994 04:35:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA06639; Mon, 25 Apr 1994 04:33:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA06609; Mon, 25 Apr 1994 04:05:23 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16547; Mon, 25 Apr 1994 03:32:58 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13891; Sun, 24 Apr 94 13:32:36 EDT Date: Sun, 24 Apr 94 13:32:36 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404241732.AA13891@itd.nrl.navy.mil> To: bound@zk3.dec.com Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU Jim Bound, % IPng should not be held up for lack of an agreed upon key management % protocol as far as its 'selection'. Whether we want to 'deploy' without a % key management solution is another issue. I agree. % Question: Won't different international domains use different key % management protocols? Or can this work internationally? )--> thanks. I sure hope that we'll all have at least one common key mgmt protocol to be used throughout the entire Internet. If we don't have at least one common key mgmt protocol, then we can forget interoperability and forget continued rapid growth in the Internet because inSecurity will prevent it (IMHO). There is a surprising amount of agreement within the security community that such a protocol would be a relative of Diffie-Hellman that has some reasonable authentication added (possibly based on DNS Security's public keys) to protect against a widely known attack on D-H. % But in this case SIPP has defined a place holder for security with % specifications. Is it bad or good or close? I'm going to quibble and say that the SIPP Security work is more than a "place holder". It has real specifications that real implementers can use and a real network-layer security architecture document that can be reviewed and criticised. There is a "place holder" in the key mgmt area, but that is mainly because key mgmt isn't (or IMHO should not be) unique to IPng but should instead be useful at multiple layers in the Internet protocol suite. I think that the SIPP security work is reasonable. It can probably be improved and I'm open to specific suggestions on how to improve it. Dave Solo of BBN had some good specific comments earlier on the SIPP list. I revised the SIPP security drafts to account for his comments. I have received no negative comments on the current drafts. Some prototype implementations are in progress based on the current drafts, which I find encouraging. % What I do know is that vendors want to ship products internationally and % not break export restrictions, so providing a template that will let the % customer use their confidentiality mechanisms within the environment is % something that is important and a good idea. I do not really understand the export laws of any country. However, my understanding from discussions with vendors, IAB members, and others is that it is very straight-forward to export mechanisms which provide authentication-without-confidentiality. It is apparently much more difficult to export confidentiality mechanisms from many countries (not just the US). It is reportedly illegal to use confidentiality mechanisms in some European countries unless one has some kind of official permission from the government. Authentication without confidentiality has significant value in protecting the Internet from a large subclass of attacks. My conclusion from all this was that SIPP should have two separately specified security mechanisms. The two mechanisms may be combined. The about to be released revisions to the SIPP Security I-Ds should make the combined use more clear. Network-layer security mechanisms can not solve all security problems. I believe that different security properties need to be provided at different layers and in different protocols. There are some who appear to think that network-layer security is sufficient, but I disagree. The first mechanism, SIPP Authentication Header, provides strong authentication without confidentiality and should be widely exportable and useable. I hope and believe that vendors can ship this with every copy of their operating system. Use of this mechanism should be sufficient to protect against source-routing attacks and a number of other attacks. The second mechanism, SIPP Encapsulating Security Payload, provides confidentiality and integrity (possibly authentication as well, depending on algorithm and mode in use). This mechanism can provide confidentiality either of transport-layer (e.g. UDP or TCP) data or of entire encapsulated SIPP datagrams including both a protected SIPP header and protected transport-layer data. Because it provides confidentiality, SIPP ESP appears to be less widely exportable and so vendors are much less likely to build it into every copy of their operating system and are much more likely to make it an optional add-in (such as some vendors currently do with their DES software). Further discussion of the SIPP security mechanisms specified should occur on the SIPP WG mailing list rather than on big-Internet. That list may be joined by sending a request to: sipp-request@sunroof2.eng.sun.com Ran atkinson@itd.nrl.navy.mil employed by, but not speaking officially for the Naval Research Laboratory From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 11:09:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29172; Mon, 25 Apr 1994 10:25:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA06922; Mon, 25 Apr 1994 10:24:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA06908; Mon, 25 Apr 1994 10:07:33 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27398; Mon, 25 Apr 1994 09:29:27 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa09908; 24 Apr 94 19:29 EDT To: bound@zk3.dec.com Cc: Ran Atkinson , big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of Sun, 24 Apr 1994 12:44:51 -0400. <9404241644.AA04362@xirtlu.zk3.dec.com> Date: Sun, 24 Apr 1994 19:29:15 -0400 From: John Curran Message-Id: <9404241929.aa09908@nic.near.net> -------- ] From: bound@zk3.dec.com ] Subject: Re: SIPP Routing Header & security ] Date: Sun, 24 Apr 94 12:44:51 -0400 ] ] ... ] IPng should not be held up for lack of an agreed upon key management ] protocol as far as its 'selection'. Whether we want to 'deploy' without a ] key management solution is another issue. Jim, 100 percent agreement. I don't think that the selection process should be held up due to lack of complete security solution. For any IPng proposal, there will places where only the architecture can be specified while we wait for work in progress. This is perfectly reasonable, Deployment _is_ a different issue; some folks feel quite strongly that a feature left out of the initial IPng deployment will never be widely deployed. ] What I do know is that vendors want to ship products internationally and ] not break export restrictions, so providing a template that will let the ] customer use their confidentiality mechanisms within the environment is ] something that is important and a good idea. Sure, supporting customer specified security mechanisms is a great idea, but we also deperately need "default" confidentiality and authentication mechanisms if we expect these features to be commonly used. /John From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 14:30:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07367; Mon, 25 Apr 1994 14:30:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA07182; Mon, 25 Apr 1994 14:29:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA07157; Mon, 25 Apr 1994 14:07:46 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04499; Mon, 25 Apr 1994 13:06:00 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA29850; Sun, 24 Apr 94 19:57:51 -0700 Received: by xirtlu.zk3.dec.com; id AA07710; Sun, 24 Apr 1994 22:57:45 -0400 Message-Id: <9404250257.AA07710@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of "Sun, 24 Apr 94 13:32:36 EDT." <9404241732.AA13891@itd.nrl.navy.mil> Date: Sun, 24 Apr 94 22:57:40 -0400 X-Mts: smtp Ran, ACK on your correction to my phrase place holder. What you stated is what I mean't. Its part of the SIPP architecture. I agree it should go to the SIPP list but it is nice folks can see that this work has been done here too. /jim From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 15:05:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03861; Mon, 25 Apr 1994 12:45:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA07059; Mon, 25 Apr 1994 12:44:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA07031; Mon, 25 Apr 1994 12:21:03 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01075; Mon, 25 Apr 1994 11:24:49 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 25 Apr 1994 10:24:36 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA18286; Mon, 25 Apr 1994 10:24:36 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA29135; Mon, 25 Apr 94 10:24:35 JST Date: Mon, 25 Apr 94 10:24:35 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404250124.AA29135@cactus.slab.ntt.jp> To: Greg_Minshall@Novell.COM Subject: just source route hole (was Re: SIPP Routing Header & security) Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com > > I think the point of, or the lesson to be learned from, the "current > sniffing attacks" is that *you*, in Japan, *do* have a way of sniffing > packets between you and Steve (by breaking in to some random system which > is between you and Steve - there are lots of such, and then "sniffing"). > > Greg > I don't disagree. (Well, actually, *I* don't know how to sniff from random places, but I do know how to exploit the source route hole, so it is a big difference.) But, if this is your concern, then I don't understand your original posting about the security hole that SIPP source routing introduces. Someone breaking into random systems to sniff seems to have nothing to do with the source routing hole per se. Can we just talk about the source routing hole? PF From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 15:10:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04148; Mon, 25 Apr 1994 12:56:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA07074; Mon, 25 Apr 1994 12:50:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA07045; Mon, 25 Apr 1994 12:27:26 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03275; Mon, 25 Apr 1994 12:28:47 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA17250; Sun, 24 Apr 94 20:33:52 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB03323; Sun, 24 Apr 94 19:27:29 PDT Date: Sun, 24 Apr 94 19:27:29 PDT Message-Id: <9404250227.AB03323@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atkinson@itd.nrl.navy.mil (Ran Atkinson), big-Internet@munnari.OZ.AU From: Greg Minshall Subject: Re: SIPP Routing Header & security Cc: sipp@sunroof2.eng.sun.com Ran, Yes, i probably say "authentication mechanism" when something like "security infrastructure" was more appropriate. The point is still the same: There isn't any such security infrastructure in SIPP or in any of the other IPng proposals. (And, such an infrastructure is probably outside the scope of a specific proposal.) >% (Which means, by the way, that the turning around of SIPP "source routes" >% is totally unacceptable security-wise as of this point, in my >% always-so-humble opinion.) >Not true. It means that one should not invert source routes that >aren't authenticated. One could most certainly setup authentication >keys with frequent correspondent hosts and use source routing within >the set of authenticatable hosts. Not having looked at any of the PD SIPP code, it would still be my guess that most of the versions probably turn around source routes nilly-willy. It is certainly the case that SIPP, as far as *i* can tell, assumes that you *can* turn around one of these source routes. I.e., i suspect that if you *can't* turn around such a source route, some conversations will never get established; i.e., you need to be able to turn around in order to get full connectivity. But, given that, as you say above, you *shouldn't* turn such a source route around unless it is authenticated, and given that there is no security infrastructure in place today which would allow for any wide spread authentication (whatever), my contention is that you cannot expect to be able to turn around a source route. And, if turning around source routes is key to the correct operation of SIPP (i step off a gangplank here, possibly) then you cannot assume the correct operation of SIPP. (I'm painfully aware that i am beating hard on this issue. I am reminded, though, of the saying "the difference between theory and practice is that in theory there is no difference, and in practice there is.") Greg ps - Possibly one of my SIPP worries, slightly PAST all of this, is how to look at a SIPP packet and figure out which sequence of 64-bit things makes up an "address" (source, say, or destination), and which other 64-bit things are, really, provider names, source routes, whatever. From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 15:40:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09958; Mon, 25 Apr 1994 15:40:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA07251; Mon, 25 Apr 1994 15:39:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA07221; Mon, 25 Apr 1994 15:05:57 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04576; Mon, 25 Apr 1994 13:11:13 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA00232; Sun, 24 Apr 94 20:08:23 -0700 Received: by xirtlu.zk3.dec.com; id AA07904; Sun, 24 Apr 1994 23:08:18 -0400 Message-Id: <9404250308.AA07904@xirtlu.zk3.dec.com> To: John Curran Cc: big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of "Sun, 24 Apr 94 19:29:15 EDT." <9404241929.aa09908@nic.near.net> Date: Sun, 24 Apr 94 23:08:12 -0400 X-Mts: smtp John, > Deployment _is_ a different issue; some folks feel quite strongly >that a feature left out of the initial IPng deployment will never be >widely deployed. I agree completely. ]] What I do know is that vendors want to ship products internationally and ]] not break export restrictions, so providing a template that will let the ]] customer use their confidentiality mechanisms within the environment is ]] something that is important and a good idea. >Sure, supporting customer specified security mechanisms is a great idea, >but we also deperately need "default" confidentiality and authentication >mechanisms if we expect these features to be commonly used. Agreed. But these may only apply to national/private interests on a case by case basis. France may want different confidentiality than the U.S. GM may want different confidentiality than Boeing. On and On. My advice is to keep it open and variant. Of course it would be nice to create the Star Trek model of the Federation and then we could have a WIN / WIN scenario for the Internet. But who would Dr. Spock be in this Federation? /jim From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 16:15:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11712; Mon, 25 Apr 1994 16:15:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA07318; Mon, 25 Apr 1994 16:14:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA07304; Mon, 25 Apr 1994 16:09:02 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09676; Mon, 25 Apr 1994 15:33:01 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA15665; Sun, 24 Apr 94 22:32:45 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA19153; Sun, 24 Apr 94 22:31:59 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA20742; Sun, 24 Apr 1994 22:32:43 -0700 Date: Sun, 24 Apr 1994 22:32:43 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404250532.AA20742@jurassic.Eng.Sun.COM> To: John Curran Cc: Ran Atkinson , Greg_Minshall@novell.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM In-Reply-To: <9404240009.aa22583@nic.near.net> Subject: Re: SIPP Routing Header & security John, > mixed results at best). Perhaps it would be worth holding IPng deployment > (regardless of which proposal is selected) so that we can include a standard > key-management mechanism and hence usable security in the base capabilities. I don't think we should delay deploying IPng based on this. I do think that we should send a strong message to the security folks that the Internet needs a key-management mechanism soon. We shouldn't delay the IPng work, we should accelerate the security work. Bob From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 16:18:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10255; Mon, 25 Apr 1994 15:44:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA07277; Mon, 25 Apr 1994 15:42:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA07224; Mon, 25 Apr 1994 15:08:04 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05509; Mon, 25 Apr 1994 13:33:07 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa24281; 24 Apr 94 23:32 EDT To: bound@zk3.dec.com Cc: big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of Sun, 24 Apr 1994 23:08:12 -0400. <9404250308.AA07904@xirtlu.zk3.dec.com> Date: Sun, 24 Apr 1994 23:31:59 -0400 From: John Curran Message-Id: <9404242332.aa24281@nic.near.net> -------- ] From: bound@zk3.dec.com ] Subject: Re: SIPP Routing Header & security ] Date: Sun, 24 Apr 94 23:08:12 -0400 ] ] ]] What I do know is that vendors want to ship products internationally and ] ]] not break export restrictions, so providing a template that will let the ] ]] customer use their confidentiality mechanisms within the environment is ] ]] something that is important and a good idea. ] ] >Sure, supporting customer specified security mechanisms is a great idea, ] >but we also deperately need "default" confidentiality and authentication ] >mechanisms if we expect these features to be commonly used. ] ] Agreed. But these may only apply to national/private interests on a case ] by case basis. France may want different confidentiality than the U.S. ] GM may want different confidentiality than Boeing. On and On. My ] advice is to keep it open and variant. Hmm. Perhaps it has to be done on a "case by case" basis. I understand the reasoning which leads to this conclusion, but am less than thrilled with the consequences: o Lack of a "default" mechanism means that the defacto connection mode will be with neither confidentiality or authentication. o Packet sniffing and source impersonation will remain potent attacks modes on Internet-ng. Should make for a booming business in firewalls, if nothing else... /John From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 18:29:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15559; Mon, 25 Apr 1994 18:00:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA07440; Mon, 25 Apr 1994 17:59:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA07426; Mon, 25 Apr 1994 17:41:10 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14823; Mon, 25 Apr 1994 17:42:31 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04869; Mon, 25 Apr 1994 09:42:27 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07429; Mon, 25 Apr 1994 09:42:26 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404250742.AA07429@dxcoms.cern.ch> Subject: Re: WARTs and IPng To: big-internet@munnari.OZ.AU (bigi) Date: Mon, 25 Apr 1994 09:42:26 +0200 (MET DST) In-Reply-To: <9404222334.AA01061@WC.Novell.COM> from "Greg Minshall" at Apr 22, 94 04:34:33 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 662 Greg, A nice list. Hands up anyone who thinks that choosing IPng is simple. ... > RFC1577; "Classical IP and ARP over ATM" > IP over different data links. > > Would it be enough to include the ATM node address as the IPng node > address? > No, no, no! ATM addresses are not Level 3 addresses. Don't mix levels. Look you say it yourself later: > RFC826; "ARP" > There is no algorithmic mapping of IP address into data link address. > Of course not. Why should there be? This problem is fixed by either an ARP server as in RFC 1577 or by an ES-IS like model. You don't need multicasts and you don't need algorithmic mapping. Brian From owner-Big-Internet@munnari.OZ.AU Mon Apr 25 18:30:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14218; Mon, 25 Apr 1994 17:25:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA07388; Mon, 25 Apr 1994 17:24:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA07374; Mon, 25 Apr 1994 17:09:30 +1000 Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11866; Mon, 25 Apr 1994 16:19:03 +1000 (from vixie@gw.home.vix.com) Received: by gw.home.vix.com id AA04495; Sun, 24 Apr 94 23:18:58 -0700 Message-Id: <9404250618.AA04495@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of "Sun, 24 Apr 1994 22:32:43 PDT." <9404250532.AA20742@jurassic.Eng.Sun.COM> Date: Sun, 24 Apr 1994 23:18:58 -0700 From: Paul A Vixie I've been watching this discussion for a couple of days now, and I've been alarmed to see references to the RSA proposal on dns-security as if it were a given. That work is very much still ``in progress'' and should not form a part of the strata on which you folks base any IP++ ideas. Today, Bob Hinden made an oblique reference to something I've been thinking about in connection with DNS security, when he said: >I don't think we should delay deploying IPng based on this. I do think >that we should send a strong message to the security folks that the >Internet needs a key-management mechanism soon. We shouldn't delay the >IPng work, we should accelerate the security work. I likewise feel that a standard mechanism for key distribution has to come about before we start trying to implement lots of different protocols which depend on it. After all, when a protocol designer wants to _depend_on_ some cryptographic tool which itself depends on key distribution, and then at some point realizes, "oh, yeah, and we need key distribution if this is going to work," then the key distribution mechanism is likely to be (a) less robust than the protocol which happens to require it, (b) incompatible with other key distribution mechanisms, (c) not scalable or generalized enough so that other protocols can also use it, or (d) all three. I didn't come to this thought through quite the same means Bob Hinden did, though. My problem is that the DNS protocol is not extensible in the dimension dns-security is currently requiring it to bend and stretch, and I came up with an "it sure would be nice if..." when I realized that It Sure Would Be Nice If any given host "just knew" or had the means to determine whether it could (or had already) exchange(d) keys with any other given host. Of course, the protocol itself would probably have to look a lot like DNS, since it would have as its key some unique host identifier (not just a name or an address, given multi-homed hosts, but probably some kind of hash of all its names and addresses, with CNAME-ish links to that hash from each individual name or address) and as its data a list of tuples of the form: (algorithm, public key) With enough rending and tearing and gnashing, this could probably be made a new RR in the existing DNS. But I don't think that's a terribly good idea. Ideally it would be or become the basis for the next rev of the DNS, which is an idea whose time has long since come except that I don't think we have collectively enough cycles to take on this general a problem right now. But I have seen the chaos that can erupt when the same feature is needed by lots of different protocols or subsystems but never becomes a ``first class'' subsystem or protocol of its own. Consider the feature called "queuing" and examine for yourself the many suboptimal implementations of it in the various UNIX subsystems (sendmail, uucp, lpd, at, and so on.) I dread the day when there are two sets of encryption datum offered by each host: one for IP++, one for Secure DNS. And two protocols for this. And two probably-variant implementations, each with their own foibles. Say it isn't so, someone, please! This sounds to me like a task for another new working group. (Sorry!) From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 00:23:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23529; Mon, 25 Apr 1994 22:05:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA07651; Mon, 25 Apr 1994 22:04:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA07620; Mon, 25 Apr 1994 21:36:05 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21960; Mon, 25 Apr 1994 21:06:05 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29855; Mon, 25 Apr 94 07:05:57 EDT Date: Mon, 25 Apr 94 07:05:57 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404251105.AA29855@itd.nrl.navy.mil> To: Bob.Hinden@Eng.Sun.COM Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU % I do think that we should send a strong message to the security folks % that the Internet needs a key-management mechanism soon. Most of the community is painfully aware of this. The various problems are being worked on by various folks. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 00:24:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23594; Mon, 25 Apr 1994 22:09:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA07666; Mon, 25 Apr 1994 22:07:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA07623; Mon, 25 Apr 1994 21:39:19 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22881; Mon, 25 Apr 1994 21:40:38 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA04726; Mon, 25 Apr 94 07:36:33 EDT Message-Id: <9404251136.AA04726@tipper.oit.unc.edu> To: bound@zk3.dec.com Cc: John Curran , big-Internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security In-Reply-To: Your message of "Sun, 24 Apr 94 23:08:12 EDT." <9404250308.AA07904@xirtlu.zk3.dec.com> Date: Mon, 25 Apr 94 07:36:32 -0400 From: Simon E Spero >>>>> "bound" == bound writes: bound> Of course it would be nice to create the Star Trek model of bound> the Federation and then we could have a WIN / WIN scenario bound> for the Internet. But who would Dr. Spock be in this bound> Federation? I don't think you realise quite how appropriate this is; Dr. Spock is a world famous expert on raising very small children. Now, play nicely children. Simon From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 00:25:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29008; Tue, 26 Apr 1994 00:25:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA07810; Tue, 26 Apr 1994 00:24:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA07807; Tue, 26 Apr 1994 00:22:45 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24055; Mon, 25 Apr 1994 22:25:27 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA20626; Mon, 25 Apr 94 08:25:21 -0400 Message-Id: <9404251225.AA20626@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: Security won't be used without all-singing-all-dancing key distribution Date: Mon, 25 Apr 1994 08:25:19 -0400 From: "Mike O'Dell" I strongly object to this assertion. Yes key management is a pain, and having it automated is probably a win, but it is certainly NOT a prerequisite for significant use of security payload facilities. Manual key distribution works quite well for some well-chosen value of "works" in a constrained problem space, and being able to run protected TCP sessions (encrypted, authenticated, etc) for certain critical functions *should* get used very, very quickly after IPng is deployed. In fact, having a strong security payload facility, even with manual key distribution, is one of the "market acceptance" features which will help pull IPng into the marketplace. -Mike O'Dell From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 00:35:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23625; Mon, 25 Apr 1994 22:11:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA07681; Mon, 25 Apr 1994 22:09:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA07637; Mon, 25 Apr 1994 21:41:07 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21925; Mon, 25 Apr 1994 21:05:04 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29710; Mon, 25 Apr 94 07:02:55 EDT Date: Mon, 25 Apr 94 07:02:55 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404251102.AA29710@itd.nrl.navy.mil> To: Greg_Minshall@Novell.COM Subject: Re: SIPP Routing Header & security Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM Greg, % Yes, i probably say "authentication mechanism" when something like % "security infrastructure" was more appropriate. Substitute "key management infrastructure" for "security infrastructure" and we can agree. % The point is still the same: There isn't any such security infrastructure % in SIPP or in any of the other IPng proposals. (And, such an % infrastructure is probably outside the scope of a specific proposal.) Again, with the above substitution made here, I agree that no proposal has a key mgmt infrastructure and no proposal should have one. There should be a generic key mgmt infrastructure and one is being developed independent of IPng. % >Not true. It means that one should not invert source routes that % >aren't authenticated. One could most certainly setup authentication % >keys with frequent correspondent hosts and use source routing within % >the set of authenticatable hosts. % % Not having looked at any of the PD SIPP code, it would still be my guess % that most of the versions probably turn around source routes nilly-willy. NRL's implementation will not invert source routes that are not fully and correctly authenticated. Our implementation is not finished yet, but you may rest assured that restriction will be in our final code. There is active discussion of such a restriction being made part of the spec. I find it very curious that only SIPP's security is being discussed here. None of the other proposals has bothered to say word one about any form of security and yet their current lack of security isn't even being discussed. Source routing is not the only kind of security problem around and the other proposals don't address in detail ANY of the many security issues generic to a internet-layer protocol. Most of the attacks on the current Internet will work fine without regard to how you format bits in packets and so the other proposals are WIDE OPEN unless/until they come up with a specific proposal for how to provide meaningful security. % It is certainly the case that SIPP, as far as *i* can tell, assumes that % you *can* turn around one of these source routes. I.e., i suspect that if % you *can't* turn around such a source route, some conversations will never % get established; i.e., you need to be able to turn around in order to get % full connectivity. I believe that you are making incorrect assumptions, but I will leave it to Steve and Paul to talk to the routing issues. % But, given that, as you say above, you *shouldn't* turn such a source route % around unless it is authenticated, and given that there is no security % infrastructure in place today which would allow for any wide spread % authentication (whatever), my contention is that you cannot expect to be % able to turn around a source route. And, if turning around source routes % is key to the correct operation of SIPP (i step off a gangplank here, % possibly) then you cannot assume the correct operation of SIPP. You are now in the water being eaten by sharks, because you leaped off the gangplank at a high velocity. I think you are seriously mistaken. % ps - Possibly one of my SIPP worries, slightly PAST all of this, is how to % look at a SIPP packet and figure out which sequence of 64-bit things makes % up an "address" (source, say, or destination), and which other 64-bit % things are, really, provider names, source routes, whatever. The implementers had a lengthy discussion about this in Seattle and Steve gave a very clear explanation. Implementation of the address sequences isn't a problem. Again, I'll leave explanations of the routing stuff to Paul and Steve. I believe that the next rev of the SIPP ROAD will make this all a bit more clear. What bothers me is that you seem to be hammering on SIPP because it has all its details down in print in detail enough to be implementable and you do not seem to be equally hard in reviewing or commenting on the other proposals. There is NO security in the other proposals at this time and there most assuredly are very serious vulnerabilities in the other proposals until/unless one has strong authentication. I believe that they are obliged to put down in detail in print as an Internet Draft exactly what mechanisms they propose and what security architecture they propose. Then we can discuss the merits of the various proposals in a cogent and even-handed way. Since this discussion is specific to SIPP, it should be moved out of big-Internet and onto sipp's mailing list. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 03:54:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00510; Tue, 26 Apr 1994 01:00:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA07862; Tue, 26 Apr 1994 00:59:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA07815; Tue, 26 Apr 1994 00:24:41 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29021; Tue, 26 Apr 1994 00:26:01 +1000 (from tld5032@commanche.ca.boeing.com) Received: by atc.boeing.com (5.57) id AA10782; Mon, 25 Apr 94 07:10:48 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA05999; Mon, 25 Apr 94 07:10:28 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA25621; Mon, 25 Apr 1994 07:08:41 -0700 Message-Id: <9404251408.AA25621@commanche.ca.boeing.com> To: dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM Cc: paul@vix.com, dee@skidrow.lkg.dec.com, mohta@necom830.cc.titech.ac.jp Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: (Your message of Sun, 24 Apr 94 23:38:09 MST.) <9404250638.AA05035@gw.home.vix.com> Date: Mon, 25 Apr 94 07:08:40 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" I've also been quietly watching these discussions but with the momentum building to adapt RSA so globally I do have to respond. I happen to agree with Paul Vixie that designing a generic key distribution protocol is far superior to building in proprietary ones. I ask that you consider the following thoughts: 1) It was always my impression that standards were implemented to avoid incorporating proprietary technologies so that each implementor could take advantage of his/her best mix of public, proprietary, and licensed solutions. Building in fixed requirements of this type certainly defeats that. 2) To me it is still totally unclear that any corporation could use RSA technology within a their established business or production processes without licensing it. I think several armies of lawyers could be enlisted here without definitive answers. 3) As anyone who has had even a minimal experience with cryptography knows, what often times what seems to be the most totally invulnerable algorithm possible often falls to a trivial solution. Just consider for a moment the impact to the Internet, should a trivial solution for de-crypting RSA algorithms be found in a few years with the entire structure of world-wide communication security resting solely on it. I personally cannot imagine designing security mechanisms for global use that will rely on any single technology; the risks are simply to great. If nothing else, consider the incentives you offer to the dark side of humanity for succeeding in breaking that single technology; un-imagined wealth and power for the taking. Take care | Terry L. Davis,P.E.| Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | -------------- Monday April 25,1994 07:01 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! == From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 03:55:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01856; Tue, 26 Apr 1994 01:35:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA07912; Tue, 26 Apr 1994 01:34:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA07880; Tue, 26 Apr 1994 01:04:43 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29491; Tue, 26 Apr 1994 00:39:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25318; Mon, 25 Apr 94 10:39:00 -0400 Date: Mon, 25 Apr 94 10:39:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404251439.AA25318@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Security won't be used without all-singing-all-dancing key distribution Cc: jnc@ginger.lcs.mit.edu being able to run protected TCP sessions (encrypted, authenticated, etc) for certain critical functions *should* get used very, very quickly after IPng is deployed. In fact, having a strong security payload facility, even with manual key distribution, is one of the "market acceptance" features which will help pull IPng into the marketplace. Reality check. This facility is needed *NOW*. People are *not* going to wait the *5 years* it is going to take to get IPng *widely deployed*. Since this facility is therefore going to be added to IPv4/TCP, it won't be a feature which can be used to push market acceptance of IPng. This argument may be repeated 'ad nauseam' with the feature of your choice: resource reservation, autoconfiguration, etc, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 04:04:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09567; Tue, 26 Apr 1994 04:04:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08124; Tue, 26 Apr 1994 04:02:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA08108; Tue, 26 Apr 1994 03:53:39 +1000 Received: from relay.tis.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08853; Tue, 26 Apr 1994 03:54:55 +1000 (from crocker@tis.com) Received: by relay.tis.com; id AA27402; Mon, 25 Apr 94 13:54:34 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma027392; Mon Apr 25 13:53:52 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA17273; Mon, 25 Apr 94 13:52:32 EDT Message-Id: <9404251752.AA17273@tis.com> To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Subject: RSA technology [Was: SIPP Routing ... & DNS Security] In-Reply-To: Your message of "Mon, 25 Apr 94 13:14:53 EDT." <9404251714.AA13136@skidrow.lkg.dec.com> Date: Mon, 25 Apr 94 13:52:24 -0400 From: Stephen D Crocker Donald, You wrote: > >2) To me it is still totally unclear that any corporation could use RSA > > technology within a their established business or production processes > > without licensing it. I think several armies of lawyers could be > > enlisted here without definitive answers. > > Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in > Redwood City, California. (Or have your lawyer call their lawyer.) > They will confirm that any company can use RSA internally, use PEM to > communicate with other companies, etc., all in a profit making > setting. The only thing RSA is still asking for royalties for is > people who want to sell software incorporating RSA or sell a service > where RSA is an essential part. I see three distinctions which are not evident in your advice. Here's my understanding, with the usual caveats about legal advice. a) There is RSA technology. If you write your own software and implement the RSA algorithms for key exchange or signature, I believe you're using RSA technology. This is patented technology, and I believe you have to deal with Public Key Partners for permission to make, use, etc. this technology. (Consult your own lawyer for details on fair use or other doctrine; I won't attempt to speak to that sort of thing.) b) RSA Data Security Inc. makes available a general purpose package, RSAREF, which implements the RSA technology. It comes with a specific license governing how it's to be used. Some forms of non-commercial use are permitted. c) There are specific application programs, including RIPEM/SIG from RSADSI and TIS/PEM from TIS, which have broad permission for use in non-sales contexts. These incorporate RSAREF, but may be usable without charge in some contexts not covered by the generic RSAREF license. Steve From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 04:21:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04845; Tue, 26 Apr 1994 02:45:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA08009; Tue, 26 Apr 1994 02:44:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA07984; Tue, 26 Apr 1994 02:16:20 +1000 Received: from TSX-11.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03686; Tue, 26 Apr 1994 02:17:42 +1000 (from tytso@ATHENA.MIT.EDU) Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA11885; Mon, 25 Apr 94 12:16:34 EDT Date: Mon, 25 Apr 94 12:16:34 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9404251616.AA11885@tsx-11.MIT.EDU> To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Cc: dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com, mohta@necom830.cc.titech.ac.jp In-Reply-To: Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA's message of Mon, 25 Apr 94 07:08:40 -0800, <9404251408.AA25621@commanche.ca.boeing.com> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 25 Apr 94 07:08:40 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" I've also been quietly watching these discussions but with the momentum building to adapt RSA so globally I do have to respond. I happen to agree with Paul Vixie that designing a generic key distribution protocol is far superior to building in proprietary ones. Generic protocols also mean "non-interoperable". I would have thought we would have learned to avoid the mistakes of OSI by now. Like it or not, whether or not we have an algorithm identifier field or not, in order for this thing to work, the IETF is going to have to put a stake in the ground and say that everyone is going to use this *one* cryptographic algorithm. It's the same problem as the one that's facing the IPNG decision process. Sometimes, you just have to pick one, and picking anything protocol is better than not picking a protocol at all. 1) It was always my impression that standards were implemented to avoid incorporating proprietary technologies so that each implementor could take advantage of his/her best mix of public, proprietary, and licensed solutions. Building in fixed requirements of this type certainly defeats that. It is certainly desierable to avoid incorporating proprietary technologies whenever possible. However, it is one thing to avoid trying to use propietary protocols; it is another thing to say we can not use a particular concept at all because it has been patented. After all, Ethernet is patented, and yet the fact that it has been patented has not stopped it from being widely deployed all over world, has it not? For all of the people who have been bitching and moaning --- if you don't like the current proposal, then come up with something new! Unfortunately, public key cryptography is a key technology, without which, many things in cryptography and security architecture become much harder. Don't get me wrong --- I think software patents and algorithm patents are particularily evil, and Congress should wake up and ban the Patent Office from issuing any more of them. But I also think we need to wake up and face reality. The Internet needs public key cryptography --- badly; and if making peace with RSADSI is what's required until the patent runs out in a few more years, then we should do what is necessary to do so. - Ted From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 06:08:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06646; Tue, 26 Apr 1994 03:21:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA08051; Tue, 26 Apr 1994 03:19:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA08023; Tue, 26 Apr 1994 02:46:40 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04914; Tue, 26 Apr 1994 02:47:51 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA02302; Mon, 25 Apr 94 10:52:49 MDT Received: from [130.57.64.146] by WC.Novell.COM (4.1/SMI-4.1) id AA05580; Mon, 25 Apr 94 09:46:25 PDT Date: Mon, 25 Apr 94 09:46:23 PDT Message-Id: <9404251646.AA05580@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: francis@cactus.slab.ntt.jp (Paul Francis) From: Greg Minshall Subject: Re: just source route hole (was Re: SIPP Routing Header & security) Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Paul, >I don't disagree. (Well, actually, *I* don't know how to sniff from >random places, but I do know how to exploit the source route hole, so >it is a big difference.) But, if this is your concern, then I don't understand >your original posting about the security hole that SIPP source routing >introduces. Someone breaking into random systems to sniff seems to have >nothing to do with the source routing hole per se. >Can we just talk about the source routing hole? Sorry. I'm not doing a good job. In the past, we used to believe that there was "strong security", "weak security", and "no security". Weak security said "secure to attacks from far away, but vulnerable to hosts and routes on the path between A and B". The point of the sniffing attack is that there are no hosts "far away" - all the bad guys are on your LAN or on the LAN between you and B. (Though i am *clearly* not the expert on this; security stuff.) Greg From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 06:10:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10837; Tue, 26 Apr 1994 04:32:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08194; Tue, 26 Apr 1994 04:30:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08157; Tue, 26 Apr 1994 04:13:27 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09973; Tue, 26 Apr 1994 04:14:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27017; Mon, 25 Apr 94 14:14:31 -0400 Date: Mon, 25 Apr 94 14:14:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404251814.AA27017@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security Cc: jnc@ginger.lcs.mit.edu, sipp@sunroof2.eng.sun.com What bothers me is that you seem to be hammering on SIPP ... There is NO security in the other proposals at this time Don't assume that just because people are beating up on SIPP, they favor one of the other alternatives. Maybe people are beating up on SIPP since it has more stuff down on paper to beat up. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 06:10:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10770; Tue, 26 Apr 1994 04:30:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08179; Tue, 26 Apr 1994 04:29:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08165; Tue, 26 Apr 1994 04:21:16 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10337; Tue, 26 Apr 1994 04:22:36 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14254; Mon, 25 Apr 94 11:22:30 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA27812; Mon, 25 Apr 94 11:21:17 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA20821; Mon, 25 Apr 1994 11:22:07 -0700 Date: Mon, 25 Apr 1994 11:22:07 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9404251822.AA20821@jurassic.Eng.Sun.COM> To: big-Internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM Subject: New SIPP Mosaic Pages Check out the new SIPP mosaic pages on http://town.hall.org/ in the "New and Trendy Protocols" section. The new version includes detailed information on current SIPP implementation efforts and a general cleanup of the other information. It is a good way to get a general overview of the SIPP work. Bob From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 06:12:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10877; Tue, 26 Apr 1994 04:33:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08209; Tue, 26 Apr 1994 04:32:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08151; Tue, 26 Apr 1994 04:10:55 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05465; Tue, 26 Apr 1994 02:59:13 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 8534; Mon, 25 Apr 94 12:31:57 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 7880; Mon, 25 Apr 1994 12:31:57 -0400 Date: Mon, 25 Apr 94 12:24:51 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Security won't be used without all-singing-all-dancing key distribution To: "Mike O'Dell" , big-internet@munnari.OZ.AU In-Reply-To: <9404251225.AA20626@rodan.UU.NET> Message-Id: <940425.122451.EDT.VALDIS@vtvm1.cc.vt.edu> On Mon, 25 Apr 1994 08:25:19 -0400 you said: >security payload facilities. Manual key distribution works quite well >for some well-chosen value of "works" in a constrained problem space, Unfortunately, for a large portion of the internet, the "well-chosen" value of "works" is incredibly restrictive. >very, very quickly after IPng is deployed. In fact, having a strong >security payload facility, even with manual key distribution, is one >of the "market acceptance" features which will help pull IPng into the >marketplace. Gaak. We have 2,500+ systems online here, and more coming every week (right now, there are 500 Mac Quadras sitting in our machine room waiting to be installed in various offices - all with 10BaseT connections). A "strong security payload" simply Will Not Work if we have to trust these people to do anything manual - remember - this is the SAME category of people we want to have auto-configuring IP addresses because they can't type in their IP address, subnet mask, and default router correctly. And you want them to deal with 1024-bit RSA keys or similar? /Valdis (who thinks Mike O'Dell needs to spend a few weeks doing Mac support before he posts again saying manual key distribution will work ;) From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 06:12:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10957; Tue, 26 Apr 1994 04:35:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA08224; Tue, 26 Apr 1994 04:34:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA08154; Tue, 26 Apr 1994 04:11:53 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05469; Tue, 26 Apr 1994 02:59:18 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 8588; Mon, 25 Apr 94 12:41:45 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 8443; Mon, 25 Apr 1994 12:41:44 -0400 Date: Mon, 25 Apr 94 12:33:10 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: WARTs and IPng To: Greg Minshall , big-internet@munnari.OZ.AU In-Reply-To: <9404222334.AA01061@WC.Novell.COM> Message-Id: <940425.123310.EDT.VALDIS@vtvm1.cc.vt.edu> (A few comments about a few points Greg made...) On Fri, 22 Apr 94 16:34:33 PDT you said: >; Firewalls > The existence thereof. Because of non-research use of (connection >to) Internet. Does a proper security architecture need a firewall? > Recognize firewalls as a first class object in the architecture >(whatever that means). For some applications, I can see the *LACK* of firewalls as a "first class" object as being a Good Thing. In particular, if it's listed as a firewall, then every net-cowboy wannabe knows where to attack. On the other hand, if the reply back is merely an ICMP message that says "A properly authenticated server said to take a flying leap" (possibly by being digitally signed with just company.com rather than router23.gate34.eastcoast.company.com), that gives the bad guys less leverage. Yes, security through obscurity is by itself a bad thing, but used in conjunction with other things.... >Previous hop versus source > > Sometimes you'd like to know the "previous hop" of a packet >(previous router). Odd.. Isn't this possible now? For all technologies I'm familiar with, either it's a point-to-point (in which case you know what interface you received it on and therefor the source router) or it's broadcast like an Ethernet, in which case you can peek at the MAC address. Or do you mean "if we're router N, we know router N-1, but we WISH we knew router N-2 as well"? Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 06:13:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13675; Tue, 26 Apr 1994 05:40:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08299; Tue, 26 Apr 1994 05:39:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08276; Tue, 26 Apr 1994 05:20:20 +1000 Received: from dnlts0.research.ptt.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13006; Tue, 26 Apr 1994 05:21:38 +1000 (from A.A.L.Reijnierse@research.ptt.nl) Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-14 #2928) id <01HBLU9553LSCLAQLL@research.ptt.nl>; Mon, 25 Apr 1994 21:21:36 +0200 Date: Mon, 25 Apr 1994 21:21:36 +0200 From: Alex Reijnierse Subject: Re: New SIPP Mosaic Pages To: Bob.Hinden@Eng.Sun.COM Cc: big-Internet@munnari.OZ.AU, tuba@lanl.gov Message-Id: <01HBLU955MW2CLAQLL@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: big-Internet@munnari.oz.au X-Vms-To: IN%"Bob.Hinden@Eng.Sun.COM" X-Vms-Cc: IN%"big-Internet@munnari.oz.au", IN%"tuba@lanl.gov" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT > > Check out the new SIPP mosaic pages on > > http://town.hall.org/ > While you are at it....... Also check out the TUBA Home Page http://explorer.nsap.research.ptt.nl/index.html or the more fancy one: http://explorer.nsap.research.ptt.nl/tuba.html this server is also accesible through gopher, anonymous FTP or anon FTAM. - Alex From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 11:03:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18068; Tue, 26 Apr 1994 07:25:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA08418; Tue, 26 Apr 1994 07:24:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA08415; Tue, 26 Apr 1994 07:16:42 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15006; Tue, 26 Apr 1994 06:11:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28316; Mon, 25 Apr 94 16:11:12 -0400 Date: Mon, 25 Apr 94 16:11:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404252011.AA28316@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Subject: Re: just source route hole (was Re: SIPP Routing Header & security) Cc: jnc@ginger.lcs.mit.edu The point of the sniffing attack is that there are no hosts "far away" - all the bad guys are on your LAN or on the LAN between you and B. There's an interesting sidelight where, which is that this, along with already deployed hardware (i.e. capital investment) is going to drive the desire for privatization technology as much as anything else. If I have 3 hosts (A-C)) on a LAN, and hosts A and C are hyper-secure, but exchange critical corporate data (financial or otherwise) over the LAN, and B is a poorly maintained work-station, into which some cracker breaks, that data is no longer secure. There's no improvement the security on A or B which will help; the only defense on the part of A and B is to deploy privatizaion technology. The recently promulgated fix of changing the OS to get rid of the monitoring device is going to slow crackers down by 2 minutes; they'll just rebuild the system. Anything you can do in software, you can undo. The *right* fix was to have a switch on the interface card which disabled sniffing, but it's too late now for that. Once you're into *any* machine, you can wiretap the net. So, put 2 and 2 together.... Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 14:30:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13869; Tue, 26 Apr 1994 05:44:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA08327; Tue, 26 Apr 1994 05:42:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA08290; Tue, 26 Apr 1994 05:25:41 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13121; Tue, 26 Apr 1994 05:26:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27740; Mon, 25 Apr 94 15:26:53 -0400 Date: Mon, 25 Apr 94 15:26:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404251926.AA27740@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security Cc: jnc@ginger.lcs.mit.edu, sipp@sunroof2.eng.sun.com it would still be my guess that most of the versions probably turn around source routes nilly-willy. It is certainly the case that SIPP, as far as *i* can tell, assumes that you *can* turn around one of these source routes. I.e., i suspect that if you *can't* turn around such a source route, some conversations will never get established; i.e., you need to be able to turn around in order to get full connectivity. But, given that, as you say above, you *shouldn't* turn such a source route around unless it is authenticated One technical point to make here: you can divide source routes into two conceptual classes: "initialization/update", which is one you need to give to the entity on the other end so they can get back to you, and "service", which is what you put into packets to get them places. The particular mechanism being discussed doesn't differentiate between the two, and I'm not sure that's the best way to go. For one thing, if either side decides (for whatever reason) to change the path, the other will follow; this may not be desired behaviour. However, that's sort of a side issue. What *is* directly relevant here is that use of the former *does* have to be authenticated, otherwise it's a security hole. I had a side conversation with Ran which left me unable to discover any use for the latter (assuming the endpoints themselves are authenticated). Either the routers in the middle are trusworthy, or they aren't, but authenticating a "service source route" won't help; all it tells you is that the entity on the other end *tried* to use the right path. Even complex mechanisms in which each router "signs" the source route to show the packet went through it do not stop diversion if the routers are subverted, and if they aren't subverted, authenticating the source route doesn't help. Is there some attack here I'm missing? Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 14:34:27 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27773; Tue, 26 Apr 1994 12:35:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27573 Tue, 26 Apr 1994 10:24:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA08575; Tue, 26 Apr 1994 10:19:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA08561; Tue, 26 Apr 1994 09:58:00 +1000 Received: from TSX-11.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17458; Tue, 26 Apr 1994 07:06:17 +1000 (from tytso@ATHENA.MIT.EDU) Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA15683; Mon, 25 Apr 94 17:04:50 EDT Date: Mon, 25 Apr 94 17:04:50 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9404252104.AA15683@tsx-11.MIT.EDU> To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, dns-security@tis.com, sipp@sunroof2.eng.sun.com, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Mon, 25 Apr 94 16:00:11 -0400, <9404252000.AA28202@ginger.lcs.mit.edu> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 25 Apr 94 16:00:11 -0400 From: Noel Chiappa Not quite. You and I may decide to use some private encryption algorithm, and nobody but us has to know. (I know, key distribution is a trickier case, since you may have to deal with many other sites, but...) The internetwork packet format, on the other hand, is *the* glue that holds it all together. Not just you and I, but all sites in between, have to use the same thing for us to communicate. What I am talking about is specifically key distribution, and signatures for the DNS. (The original complaints originally arose out of discussions from the DNS Security working group.) And, specifically within this context, I will claim that we do need to pick one protocol, because like the internetwork packet format, an internet-wide key distribution and certification system is *the* glue to hold any cryptographic security system all together. - Ted From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 14:47:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29178; Tue, 26 Apr 1994 13:16:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA08738; Tue, 26 Apr 1994 13:14:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA08724; Tue, 26 Apr 1994 12:56:25 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22503; Tue, 26 Apr 1994 09:32:16 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 26 Apr 1994 08:31:04 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA12468; Tue, 26 Apr 1994 08:31:04 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA10427; Tue, 26 Apr 94 08:31:03 JST Date: Tue, 26 Apr 94 08:31:03 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404252331.AA10427@cactus.slab.ntt.jp> To: Greg_Minshall@Novell.COM, atkinson@itd.nrl.navy.mil Subject: focused discussion (was Re: SIPP Routing Header & security) Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM > > % It is certainly the case that SIPP, as far as *i* can tell, assumes that > % you *can* turn around one of these source routes. I.e., i suspect that if > % you *can't* turn around such a source route, some conversations will never > % get established; i.e., you need to be able to turn around in order to get > % full connectivity. > > I believe that you are making incorrect assumptions, but I will leave it > to Steve and Paul to talk to the routing issues. > Greg is exactly right. For instance, if my host is using an extended address, then (the upper part of) that address is encoded as a source route. Thus, if a system refuses to reverse that source route, then it can't talk to me. This whole discussion has gotten a bit imprecise, so let's reel it in a bit..... First of all, consider what is a "source route" in SIPP (I put it in quotes because the term is not used by SIPP. It doesn't appear at all in the sipp spec, and it appears once in the road spec, but this is a bug and will be fixed in the next version). The sipp road spec talks about something called a "route sequence". A route sequence is the series of addresses, starting with the source identifying address, and ending with the dest identifying address, and possibly having some addresses in between (these would be encoded using the SIPP Route Header). So, a packet with no route header has a very small route sequence--two addresses. None-the-less, when a host receives such a packet, it "turns around" (the spec calls it reversing) the route sequence--ie, it exchanges the source and dest identifying addresses and returns the packet. If a host won't "turn around" a "source route" for another host that hasn't been authenticated, then it also shouldn't reverse the source and dest address for another host that hasn't been authenticated. So, my question to Ran is, exactly when will your host be willing to exchange packets with another host. For instance, will your implementation talk to a host that hasn't been authenticated as long as the packet does not contain a Route Header? Will your host strip out the Route Header of another host that hasn't been authenticated, but still talk to it? Will your host just not talk to anything that hasn't been authenticated? It has just occured to me that the original message of Greg's that started this whole thread never actually said what the security hole was that source routing introduced. I assumed that he was referring to the trivial sniffing scenario, which I proposed a way to solve that doesn't require key exchange. I think it would be good if both Greg and Ran write down, in as few words as possible, what the threat is *introduced* by turning around the source route. Then let's talk just about *that* threat..... PF From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 15:35:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04900; Tue, 26 Apr 1994 15:35:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA08863; Tue, 26 Apr 1994 15:34:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA08849; Tue, 26 Apr 1994 15:24:19 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23277; Tue, 26 Apr 1994 10:00:32 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 26 Apr 1994 09:00:14 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA12681; Tue, 26 Apr 1994 09:00:14 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA10864; Tue, 26 Apr 94 09:00:13 JST Date: Tue, 26 Apr 94 09:00:13 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404260000.AA10864@cactus.slab.ntt.jp> To: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, sipp@sunroof2.eng.sun.com Subject: Re: just source route hole (was Re: SIPP Routing Header & security) > > If I have 3 hosts (A-C)) on a LAN, and hosts A and C are hyper-secure, but > exchange critical corporate data (financial or otherwise) over the LAN, and B > is a poorly maintained work-station, into which some cracker breaks, that > data is no longer secure. There's no improvement the security on A or B which > will help; the only defense on the part of A and B is to deploy privatizaion > technology. > Sigh..... I *tried* to bring the topic back to the source route hole. Really I tried... I even made the subject line of the message say "just source route hole". Can I assume that actually people don't want to talk about the source route hole, and want to talk about the big security problem? :-( PF From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 19:06:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13757; Tue, 26 Apr 1994 19:06:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA09108; Tue, 26 Apr 1994 19:04:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA09105; Tue, 26 Apr 1994 18:55:25 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13446; Tue, 26 Apr 1994 18:56:39 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 17:50:57 +0859 From: Masataka Ohta Message-Id: <9404260851.AA05994@necom830.cc.titech.ac.jp> Subject: Re: WARTs and IPng To: Brian.Carpenter@cern.ch Date: Tue, 26 Apr 94 17:50:56 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9404250742.AA07429@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Apr 25, 94 9:42 am X-Mailer: ELM [version 2.3 PL11] > > RFC826; "ARP" > > There is no algorithmic mapping of IP address into data link address. > > > Of course not. Why should there be? This problem is fixed by > either an ARP server as in RFC 1577 or by an ES-IS like model. > You don't need multicasts and you don't need algorithmic mapping. And you will have the single point of failure, the ARP server. Use broadcasted ARP. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 19:11:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11007; Tue, 26 Apr 1994 17:55:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA09028; Tue, 26 Apr 1994 17:54:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA09023; Tue, 26 Apr 1994 17:42:03 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06007; Tue, 26 Apr 1994 16:07:30 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17534; Tue, 26 Apr 1994 08:07:10 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA12179; Tue, 26 Apr 1994 08:07:09 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404260607.AA12179@dxcoms.cern.ch> Subject: Re: Security won't be used without all-singing-all-dancing key To: VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) Date: Tue, 26 Apr 1994 08:07:09 +0200 (MET DST) Cc: mo@uunet.uu.net, big-internet@munnari.OZ.AU In-Reply-To: <940425.122451.EDT.VALDIS@vtvm1.cc.vt.edu> from "Valdis Kletnieks" at Apr 25, 94 12:24:51 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 452 >--------- Text sent by Valdis Kletnieks follows: ... > A "strong security payload" simply Will Not Work if we have to trust these > people to do anything manual - remember - this is the SAME category of > people we want to have auto-configuring IP addresses because they can't > type in their IP address, subnet mask, and default router correctly. Yeah, and ain't it fun when they type in the default router address as their own IP address? Brian From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 19:23:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06133; Tue, 26 Apr 1994 16:11:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA08907; Tue, 26 Apr 1994 16:09:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA08904; Tue, 26 Apr 1994 16:00:23 +1000 Received: from brazos.is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27001; Tue, 26 Apr 1994 12:16:41 +1000 (from bmanning@is.rice.edu) Received: by brazos.is.rice.edu (AA01958); Mon, 25 Apr 94 21:15:32 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9404260215.AA01958@brazos.is.rice.edu> Subject: Re: just source route hole (was Re: SIPP Routing Header & security) To: francis@cactus.slab.ntt.jp (Paul Francis) Date: Mon, 25 Apr 1994 21:15:31 -0500 (CDT) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, sipp@sunroof2.eng.sun.com In-Reply-To: <9404260000.AA10864@cactus.slab.ntt.jp> from "Paul Francis" at Apr 26, 94 09:00:13 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 103 Would it be too much to ask to drop Big-I off this discussion... or Sipp? -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 19:42:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15020; Tue, 26 Apr 1994 19:42:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA09202; Tue, 26 Apr 1994 19:40:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA09113; Tue, 26 Apr 1994 19:04:28 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13729; Tue, 26 Apr 1994 19:05:24 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 17:57:24 +0900 From: Masataka Ohta Message-Id: <9404260857.AA06015@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft To: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Date: Tue, 26 Apr 94 17:57:23 JST Cc: "Terry, L., Davis, P.E., Boeing, Computer, Services, Bellevue, WA"@necom830.cc.titech.ac.jp, tld5032@commanche.ca.boeing.com, dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com In-Reply-To: <9404251616.AA11885@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Apr 25, 94 12:16 pm X-Mailer: ELM [version 2.3 PL11] > Don't get me wrong --- I think software patents and algorithm patents > are particularily evil, and Congress should wake up and ban the Patent > Office from issuing any more of them. From a purely political point of view, the better approach is to try to bankrupt RSA DSI by not paying to them. > But I also think we need to wake > up and face reality. The Internet needs public key cryptography --- > badly; and if making peace with RSADSI is what's required until the > patent runs out in a few more years, then we should do what is necessary > to do so. What's wrong with ElGamal? > Unfortunately, public key cryptography is a key technology, without > which, many things in cryptography and security architecture become > much harder. Public key makes management issue of secret data much easier. Other things won't be affected by it. Modularized secure DNS which enables both RSA, shared secret and KDC is easy to construct. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 20:18:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16339; Tue, 26 Apr 1994 20:18:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA09290; Tue, 26 Apr 1994 20:16:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA09255; Tue, 26 Apr 1994 20:03:50 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27589; Tue, 26 Apr 1994 12:29:57 +1000 (from francis@cactus.slab.ntt.jp) Received: from mail.ntt.jp by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29329 Tue, 26 Apr 1994 11:11:45 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 26 Apr 1994 10:09:03 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA13186; Tue, 26 Apr 1994 10:09:02 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA11900; Tue, 26 Apr 94 10:09:02 JST Date: Tue, 26 Apr 94 10:09:02 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404260109.AA11900@cactus.slab.ntt.jp> To: atkinson@itd.nrl.navy.mil, francis@itd.nrl.navy.mil Subject: Re: focused discussion Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com > > % Perhaps one work around is for your host to accept the first packet > % sent to you by another host, but not accept any *changes* in the > % Route Header. If your willing to talk to an un-authenticated host > % host without a route header, you should be just as willing to talk > % to one with a route header as long as the route header doesn't change > % once you've exchanged the first packet, yes? > > No. The problem is that if my route is A-->B-->C and is not > authenticated, then it is trivial for B to impersonate A without > subverting routing or other parts of the infrastructure. > Yes, you're right....I should've see it..... > > This is the crux of a discussion I've had with several other > implementers now. Several of us would find it simpler if our kernel > could distinguish between a source route and an address whose size is > larger than 64 bits. It is precisely this part of the ROAD spec that > several of us get confused by and hope to see clarified in the next > revision. I think I'm about to get educated and that would be A Good > Thing. > > % The problem here seems to be that sometimes the Route Header is used > % to encode a hierarchical address, and sometimes to encode an explicit > % intermediate hop. The former case you don't need to authenticate, and > % the latter case you do. I'm not sure what to do about this. > > Yes. I also do not know what to do and so am taking what I perceive > as the safe way out of my dilemma. I see. If you know the extended address(es) of the other host (which you have to know to send packets to it in the first place), then you can inspect the Route Header to make sure that it has *only* the extended address and nothing else. Does this help? PF From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 20:19:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16380; Tue, 26 Apr 1994 20:19:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA09305; Tue, 26 Apr 1994 20:18:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA09258; Tue, 26 Apr 1994 20:06:01 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27780; Tue, 26 Apr 1994 12:35:54 +1000 (from francis@cactus.slab.ntt.jp) Received: from mail.ntt.jp by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27871 Tue, 26 Apr 1994 10:31:41 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 26 Apr 1994 09:28:55 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA12860; Tue, 26 Apr 1994 09:28:54 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA11296; Tue, 26 Apr 94 09:28:54 JST Date: Tue, 26 Apr 94 09:28:54 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404260028.AA11296@cactus.slab.ntt.jp> To: atkinson@itd.nrl.navy.mil, francis@itd.nrl.navy.mil Subject: Re: focused discussion Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com > > Paul, > > A source route is a source route. Anytime one specifies ANY > intermediate hop explicitly, one has a source route. If one strictly > uses the source address (a 64 bit chunk) and the destination address > (another 64 bit chunk) and one only uses ordinary routing > algorithms/protocols (e.g. OSPF, BGP), then one does not have a source > route. Ok. So, with an extended address, one is not specifying an "intermediate hop explicitly" in the Route Header, one is specifying a portion of a hierarchical address, at the same level of specificity as when one utters a single hierarchical address. > > % So, my question to Ran is, exactly when will your host be willing to > % exchange packets with another host. For instance, will your > % implementation talk to a host that hasn't been authenticated as long > % as the packet does not contain a Route Header? Will your host strip > % out the Route Header of another host that hasn't been authenticated, > % but still talk to it? Will your host just not talk to anything that > % hasn't been authenticated? > > Will ignore all Routing Headers that are not authenticated > successfully. Will try to talk to the alleged originator of the > packet without inverting the alleged source route and will rely on > normal routing (e.g. OSPF, BGP) to get the outgoing packet back to the > alleged originator of the packet. > Ok, then your host cannot talk to another host that is 1) using an extended address, and 2) isn't using the authentication. The problem here seems to be that sometimes the Route Header is used to encode a hierarchical address, and sometimes to encode an explicit intermediate hop. The former case you don't need to authenticate, and the latter case you do. I'm not sure what to do about this. Perhaps one work around is for your host to accept the first packet sent to you by another host, but not accept any *changes* in the Route Header. If your willing to talk to an un-authenticated host host without a route header, you should be just as willing to talk to one with a route header as long as the route header doesn't change once you've exchanged the first packet, yes? PF From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 20:33:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06191; Tue, 26 Apr 1994 16:13:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA08933; Tue, 26 Apr 1994 16:11:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA08890; Tue, 26 Apr 1994 15:43:48 +1000 Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05201; Tue, 26 Apr 1994 15:44:55 +1000 (from news@vix.com) Received: by gw.home.vix.com id AA11744; Mon, 25 Apr 94 22:44:50 -0700 Date: Mon, 25 Apr 94 22:44:50 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: big-Internet@munnari.OZ.AU From: paul@vix.com (Paul A Vixie) Subject: Re: Security won't be used without all-singing-all-dancing key Organization: Vixie Enterprises Message-Id: References: <940425.122451.EDT.VALDIS@vtvm1.cc.vt.edu> Nntp-Posting-Host: office.home.vix.com In-Reply-To: VALDIS@VTVM1.CC.VT.EDU's message of 25 Apr 1994 12:38:58 -0700 > A "strong security payload" simply Will Not Work if we have to trust these > people to do anything manual - remember - this is the SAME category of > people we want to have auto-configuring IP addresses because they can't > type in their IP address, subnet mask, and default router correctly. Excuse me, I'm new here. I feel quite sure that somewhere back in time, it was suggested that a general "capability protocol" be created so that a host could answer questions like "do you have a public key?", "what is it?", and "what algorythms can i use it with?". I'm sure that given the simplicity of a design incorporating this protocol and a local cache so that a system could remember other systems' capabilities in between attempts to depend or use those capabilities, such a system has been discussed here and rejected as hopeless or unsuitable. Can someone please point me to the year and month of the archive that contains this discussion, so I can read it and avoid rehashing the same old thing? I just *know* there's got to be some reason why folks here are talking about per-packet "payloads" even though the above approach seems so doable, and generalizable, and extensible, and so on. Again, please forgive my ignorance on this point. I promise to summarize back to the list any nonconfidential replies I get; go ahead and answer me privately since I'm sure everybody else knows this but me. -- Paul Vixie Redwood City, CA decwrl!vixie!paul From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 20:58:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13938; Tue, 26 Apr 1994 19:09:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA09126; Tue, 26 Apr 1994 19:07:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA09078; Tue, 26 Apr 1994 18:30:27 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06701; Tue, 26 Apr 1994 03:22:50 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA21580; Mon, 25 Apr 94 13:22:11 -0400 Date: Mon, 25 Apr 94 13:22:11 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9404251722.AA21580@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: re: MO needs to spend time doing Mac administration..... Thanks, I've been there, done that, and don't like how the movie ends. (grin) Look, I never, ever claimed that you can solve Vladis' problem with manual key distribution. Yes indeed, the space solvable with manual distribution *is* constrained, but probably more interesting than you might first think. There ARE some pressing problems which CAN be solved that way, and waiting to solve them until there is some all-singing all-dancing key distribution scheme is a very, very Bad Idea. While I'm not blessed with as large a fraction of Apple's annual output as Vladis seems to be, I *am* an operator of a large national backbone and hence am not completely clueless about complex network problems. Further, since UUNET builds a box which does IP traffic encryption, we do have occassion to speak with customers who have strong opinions about key management. Most of them also belong to the school that says there is no excuse for "waiting for Godot" to make things better and *want* manual distribution, thank you very much. So, I repeat my statement that while manual distribution is NOT a feasible solution for all or even some problems, it IS a perfectly workable solution for others, and some of those are important enough (to me) to put up with the grief of manual key management. I'd use security payloads post haste, given the chance. Just because IPngSEC without universal key management won't solve your most direct problem doesn't mean it can't solve a problem you may (badly) want solved once it bites you hard enough. -Mike O'Dell Resident Crank, and... VP of R&D UUNET Technologies From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 20:58:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14985; Tue, 26 Apr 1994 19:40:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA09174; Tue, 26 Apr 1994 19:39:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA09155; Tue, 26 Apr 1994 19:15:07 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB14099; Tue, 26 Apr 1994 19:16:25 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 26 Apr 94 18:08:13 +0900 From: Masataka Ohta Message-Id: <9404260908.AA06073@necom830.cc.titech.ac.jp> Subject: Re: Security won't be used without all-singing-all-dancing key To: VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) Date: Tue, 26 Apr 94 18:08:12 JST Cc: mo@uunet.uu.net, big-internet@munnari.OZ.AU In-Reply-To: <940425.122451.EDT.VALDIS@vtvm1.cc.vt.edu>; from "Valdis Kletnieks" at Apr 25, 94 12:24 pm X-Mailer: ELM [version 2.3 PL11] > A "strong security payload" simply Will Not Work if we have to trust these > people to do anything manual - remember - this is the SAME category of > people we want to have auto-configuring IP addresses because they can't > type in their IP address, subnet mask, and default router correctly. > And you want them to deal with 1024-bit RSA keys or similar? No, it is not necessary. For the real security, we must deal with 128 bit MD5 of the key. Rest of the information could be auto-configured. We may add extra bits to automatically correct some missing/extra/mistyped digits. Vendor's may preconigure their products with MD5 information on a secure DNS server at their costomer service center. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 20:59:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15090; Tue, 26 Apr 1994 19:43:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA09217; Tue, 26 Apr 1994 19:41:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA09171; Tue, 26 Apr 1994 19:32:57 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14561; Tue, 26 Apr 1994 06:00:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28202; Mon, 25 Apr 94 16:00:11 -0400 Date: Mon, 25 Apr 94 16:00:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404252000.AA28202@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu Generic protocols also mean "non-interoperable". ... Like it or not, whether or not we have an algorithm identifier field or not, in order for this thing to work, the IETF is going to have to put a stake in the ground and say that everyone is going to use this *one* cryptographic algorithm. I have no problem with picking one, as long as the hooks are there to use something else, as you desire. For a number of reasons (not wanting to intrude on patents, algorithmic expense, discovery of holes in algorithms) you might want to use something else. So, let's make sure to keep "algorithm identifier field"! It's the same problem as the one that's facing the IPNG decision process. Not quite. You and I may decide to use some private encryption algorithm, and nobody but us has to know. (I know, key distribution is a trickier case, since you may have to deal with many other sites, but...) The internetwork packet format, on the other hand, is *the* glue that holds it all together. Not just you and I, but all sites in between, have to use the same thing for us to communicate. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 21:14:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16292; Tue, 26 Apr 1994 20:15:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA09275; Tue, 26 Apr 1994 20:14:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA09252; Tue, 26 Apr 1994 20:02:00 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28051; Tue, 26 Apr 1994 12:41:22 +1000 (from francis@cactus.slab.ntt.jp) Received: from mail.ntt.jp by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26161 Tue, 26 Apr 1994 09:50:23 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 26 Apr 1994 08:47:43 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA12574; Tue, 26 Apr 1994 08:47:43 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA10586; Tue, 26 Apr 94 08:47:42 JST Date: Tue, 26 Apr 94 08:47:42 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404252347.AA10586@cactus.slab.ntt.jp> To: Greg_Minshall@Novell.COM, francis@Novell.COM Subject: Re: just source route hole (was Re: SIPP Routing Header & security) Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com > > >Can we just talk about the source routing hole? > > Sorry. I'm not doing a good job. > > In the past, we used to believe that there was "strong security", "weak > security", and "no security". Weak security said "secure to attacks from > far away, but vulnerable to hosts and routes on the path between A and B". > > The point of the sniffing attack is that there are no hosts "far away" - > all the bad guys are on your LAN or on the LAN between you and B. Ok. If all the bad guys are already in the path, then the Routing Header of SIPP does not weaken the security of SIPP in the least. PF From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 21:25:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18461; Tue, 26 Apr 1994 21:25:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA09406; Tue, 26 Apr 1994 21:24:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA09403; Tue, 26 Apr 1994 21:20:58 +1000 Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07136; Tue, 26 Apr 1994 03:30:02 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA12388; Mon, 25 Apr 94 10:13:08 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA13136; Mon, 25 Apr 1994 13:14:53 -0400 Message-Id: <9404251714.AA13136@skidrow.lkg.dec.com> To: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Cc: dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Mon, 25 Apr 94 07:08:40 -0800." <9404251408.AA25621@commanche.ca.boeing.com> Date: Mon, 25 Apr 94 13:14:53 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Terry, From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" To: dns-security@tis.com, big-Internet@munnari.oz.au, sipp@sunroof2.eng.sun.com Cc: paul@vix.com, dee, mohta@necom830.cc.titech.ac.jp In-Reply-To: (Your message of Sun, 24 Apr 94 23:38:09 MST.) <9404250638.AA05035@gw.home.vix.com> > >... > >2) To me it is still totally unclear that any corporation could use RSA > technology within a their established business or production processes > without licensing it. I think several armies of lawyers could be > enlisted here without definitive answers. Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in Redwood City, California. (Or have your lawyer call their lawyer.) They will confirm that any company can use RSA internally, use PEM to communicate with other companies, etc., all in a profit making setting. The only thing RSA is still asking for royalties for is people who want to sell software incorporating RSA or sell a service where RSA is an essential part. >3) As anyone who has had even a minimal experience with cryptography > knows, what often times what seems to be the most totally invulnerable > algorithm possible often falls to a trivial solution. Just consider > for a moment the impact to the Internet, should a trivial solution for > de-crypting RSA algorithms be found in a few years with the entire > structure of world-wide communication security resting solely on it. Whatever algoritm is chosen, the people who want to interoperate will all have to speak it. Everyone knows you will need a method to roll over to a new algorithm when / if that is necessary. >I personally cannot imagine designing security mechanisms for global >use that will rely on any single technology; the risks are simply to >great. If nothing else, consider the incentives you offer to the dark >side of humanity for succeeding in breaking that single technology; >un-imagined wealth and power for the taking. So you want multiple algorithms so that those who want to interoperate will have to speak all of them so that if *any* *one* *of* *them* is broken, things will fall apart? Sounds like a great way to weaken network security to me. (Of course there should also be a way for consenting adults to use whatever algorithm they want, not that you could stop them anyway.) >Take care > > | Terry L. Davis,P.E.| Boeing Computer Services, Bellevue, WA | > | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | > | INTERNET EMAIL: tld5032@atc.boeing.com. | > -------------- Monday April 25,1994 07:01 AM PDT ------------- > > == As always, the above cannot be construed as representing BOEING, == > == the thoughts, comments, and ideas contained herein are mine alone! == Donald From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 21:54:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16454; Tue, 26 Apr 1994 20:21:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA09322; Tue, 26 Apr 1994 20:20:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA09261; Tue, 26 Apr 1994 20:07:05 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28033; Tue, 26 Apr 1994 12:40:42 +1000 (from atkinson@itd.nrl.navy.mil) Received: from itd.nrl.navy.mil by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28484 Tue, 26 Apr 1994 10:45:18 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02012; Mon, 25 Apr 94 20:42:45 EDT Date: Mon, 25 Apr 94 20:42:45 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404260042.AA02012@itd.nrl.navy.mil> To: francis@cactus.slab.ntt.jp Subject: Re: focused discussion Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com % Ok. So, with an extended address, one is not specifying an "intermediate % hop explicitly" in the Route Header, one is specifying a portion of a % hierarchical address, at the same level of specificity as when one utters % a single hierarchical address. Paul, This is the crux of a discussion I've had with several other implementers now. Several of us would find it simpler if our kernel could distinguish between a source route and an address whose size is larger than 64 bits. It is precisely this part of the ROAD spec that several of us get confused by and hope to see clarified in the next revision. I think I'm about to get educated and that would be A Good Thing. % > Will ignore all Routing Headers that are not authenticated % > successfully. Will try to talk to the alleged originator of the % > packet without inverting the alleged source route and will rely on % > normal routing (e.g. OSPF, BGP) to get the outgoing packet back to the % > alleged originator of the packet. % Ok, then your host cannot talk to another host that is 1) using an % extended address, and 2) isn't using the authentication. Yes. % The problem here seems to be that sometimes the Route Header is used % to encode a hierarchical address, and sometimes to encode an explicit % intermediate hop. The former case you don't need to authenticate, and % the latter case you do. I'm not sure what to do about this. Yes. I also do not know what to do and so am taking what I perceive as the safe way out of my dilemma. % Perhaps one work around is for your host to accept the first packet % sent to you by another host, but not accept any *changes* in the % Route Header. If your willing to talk to an un-authenticated host % host without a route header, you should be just as willing to talk % to one with a route header as long as the route header doesn't change % once you've exchanged the first packet, yes? No. The problem is that if my route is A-->B-->C and is not authenticated, then it is trivial for B to impersonate A without subverting routing or other parts of the infrastructure. Use of pseudo-random FlowIDs doesn't really protect this situation because pseudo-random numbers aren't truly random and because it is easy for me to devise cases where there might be more than one flow (and hence more than one active FlowID) between two systems, possibly even using different routes if we have source routing. Regards, Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 22:00:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19775; Tue, 26 Apr 1994 22:00:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA09463; Tue, 26 Apr 1994 21:59:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA09449; Tue, 26 Apr 1994 21:46:42 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19074; Tue, 26 Apr 1994 21:48:04 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14496; Tue, 26 Apr 94 07:47:59 EDT Date: Tue, 26 Apr 94 07:47:59 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404261147.AA14496@itd.nrl.navy.mil> To: big-Internet@munnari.OZ.AU Subject: example uses for manual key dist By way of explaining why some of us think manual key distribution really does have value for some interesting problems, here are some examples where it might be useful: - securing conversations among the routers of some network - securing conversations between border routers of different networks - securing traffic between a single firm's two campuses where those campuses are connected via a commercial service provider and there is an encrypting firewall router thingy at each campus gateway. - securing traffic between frequent correspondents or within a single small workgroup - securing traffic between a mobile host/router and its home - authenticating mobile host/router registrations with its home None of these solve Valdis' problems, but they are all interesting cases that CAN be addressed using manual key distribution. It is especially important to pick strong keys when one has manual key distribution because key lifetimes tend in practice to be longer than might be usual with a scalable key mgmt protocol. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 22:02:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19787; Tue, 26 Apr 1994 22:02:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA09478; Tue, 26 Apr 1994 22:00:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA09435; Tue, 26 Apr 1994 21:32:54 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18660; Tue, 26 Apr 1994 21:34:15 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14160; Tue, 26 Apr 94 07:34:06 EDT Date: Tue, 26 Apr 94 07:34:06 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404261134.AA14160@itd.nrl.navy.mil> To: francis@cactus.slab.ntt.jp Subject: Re: focused discussion Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM % > This is the crux of a discussion I've had with several other % > implementers now. Several of us would find it simpler if our kernel % > could distinguish between a source route and an address whose size is % > larger than 64 bits. It is precisely this part of the ROAD spec that % > several of us get confused by and hope to see clarified in the next % > revision. I think I'm about to get educated and that would be A Good % > Thing. % > % > % The problem here seems to be that sometimes the Route Header is used % > % to encode a hierarchical address, and sometimes to encode an explicit % > % intermediate hop. The former case you don't need to authenticate, and % > % the latter case you do. I'm not sure what to do about this. % > % > Yes. I also do not know what to do and so am taking what I perceive % > as the safe way out of my dilemma. % % I see. If you know the extended address(es) of the other host (which you % have to know to send packets to it in the first place), then you can % inspect the Route Header to make sure that it has *only* the extended % address and nothing else. % % Does this help? Possibly. If the kernel can dependably determine what bits are "extended address" and which are "source route" then the kernel can inspect the Route Header and process it normally if not a "source route". If the kernel can't _dependably_ distinguish the two, then it doesn't help because some clever person will make a source route look like an extended address and we have the same problem as before. I need a bit more education because this is precisely the part of ROAD that I find a bit confusing. Please permit me to ask some stupid questions: - Why does the kernel have to know that something is an "extended address" specifically rather than "either an extended address or a src route" ? - How does the kernel distinguish a "source route" from an "extended address" in the most general case ? - How does the routing engine process the bits, always 64 at a time ? - How should my routing table be structured to support extended addresses ? Thanks, Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 23:10:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22231; Tue, 26 Apr 1994 23:10:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA09572; Tue, 26 Apr 1994 23:09:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA09543; Tue, 26 Apr 1994 22:37:53 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28045; Tue, 26 Apr 1994 12:41:13 +1000 (from atkinson@itd.nrl.navy.mil) Received: from [128.60.2.2] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26929 Tue, 26 Apr 1994 10:11:21 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA01475; Mon, 25 Apr 94 20:08:43 EDT Date: Mon, 25 Apr 94 20:08:43 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9404260008.AA01475@itd.nrl.navy.mil> To: francis@cactus.slab.ntt.jp Subject: Re: focused discussion Cc: big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM % First of all, consider what is a "source route" in SIPP (I put it in % quotes because the term is not used by SIPP. It doesn't appear at all % in the sipp spec, and it appears once in the road spec, but this is a % bug and will be fixed in the next version). The sipp road spec talks % about something called a "route sequence". A route sequence is the % series of addresses, starting with the source identifying address, and % ending with the dest identifying address, and possibly having some % addresses in between (these would be encoded using the SIPP Route % Header). Paul, A source route is a source route. Anytime one specifies ANY intermediate hop explicitly, one has a source route. If one strictly uses the source address (a 64 bit chunk) and the destination address (another 64 bit chunk) and one only uses ordinary routing algorithms/protocols (e.g. OSPF, BGP), then one does not have a source route. % So, a packet with no route header has a very small route sequence--two % addresses. None-the-less, when a host receives such a packet, it % "turns around" (the spec calls it reversing) the route sequence--ie, % it exchanges the source and dest identifying addresses and returns the % packet. If a host won't "turn around" a "source route" for another % host that hasn't been authenticated, then it also shouldn't reverse % the source and dest address for another host that hasn't been % authenticated. I refuse to buy the semantic game above. If there is no Routing Header, the receiver is not reversing a route sequence because there is no "sequence" to reverse. The receiver is just sending a packet back to the originator and not specifying any particular route back to the originator. Instead, such packets rely on normal routing (e.g. OSPF, BGP). % So, my question to Ran is, exactly when will your host be willing to % exchange packets with another host. For instance, will your % implementation talk to a host that hasn't been authenticated as long % as the packet does not contain a Route Header? Will your host strip % out the Route Header of another host that hasn't been authenticated, % but still talk to it? Will your host just not talk to anything that % hasn't been authenticated? Will ignore all Routing Headers that are not authenticated successfully. Will try to talk to the alleged originator of the packet without inverting the alleged source route and will rely on normal routing (e.g. OSPF, BGP) to get the outgoing packet back to the alleged originator of the packet. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 23:28:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20911; Tue, 26 Apr 1994 22:35:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA09527; Tue, 26 Apr 1994 22:34:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA09511; Tue, 26 Apr 1994 22:13:24 +1000 Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20171; Tue, 26 Apr 1994 22:14:46 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HBMF219C40002KI6@FNAL.FNAL.GOV>; Tue, 26 Apr 1994 07:13:55 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA21884; Tue, 26 Apr 94 07:13:11 CDT Date: Tue, 26 Apr 1994 07:13:10 -0500 From: Matt Crawford Subject: Re: focused discussion (was Re: SIPP Routing Header & security) In-Reply-To: Your message of Tue, 26 Apr 94 08:31:03 +0800. <9404252331.AA10427@cactus.slab.ntt.jp> To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: Greg_Minshall@Novell.COM, atkinson@itd.nrl.navy.mil, big-Internet@munnari.OZ.AU, sipp@sunroof2.Eng.Sun.COM Message-Id: <9404261213.AA21884@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > If a host won't "turn around" a "source route" for another host that > hasn't been authenticated, then it also shouldn't reverse the source and > dest address for another host that hasn't been authenticated. Point! From owner-Big-Internet@munnari.OZ.AU Tue Apr 26 23:46:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23708; Tue, 26 Apr 1994 23:46:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA09628; Tue, 26 Apr 1994 23:44:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA09614; Tue, 26 Apr 1994 23:28:54 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21401; Tue, 26 Apr 1994 22:47:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02870; Tue, 26 Apr 94 08:47:42 -0400 Date: Tue, 26 Apr 94 08:47:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404261247.AA02870@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: dns-security@tis.com, jnc@ginger.lcs.mit.edu, sipp@sunroof2.eng.sun.com >> Generic protocols also mean "non-interoperable". ... Like it or not, >> ... in order for this thing to work, the IETF is going to have to put a >> stake in the ground and say that everyone is going to use this *one* >> cryptographic algorithm. > I have no problem with picking one, as long as the hooks are there to use > something else ... let's make sure to keep "algorithm identifier field"! > ... You and I may decide to use some private encryption algorithm, and > nobody but us has to know. What I am talking about is specifically key distribution, and signatures for the DNS. ... And, specifically within this context, I will claim that we do need to pick one protocol, because like the internetwork packet format, an internet-wide key distribution and certification system is *the* glue to hold any cryptographic security system all together. Whoa. We just went from "one algorithm" (in your first clip) to "one protocol". I don't believe they are the same; the "algorithm identifier field" (along with key length, etc) would allow use of several signing algorithms within one protocol. Did I miss something? I agree that we need one protocol to do key distribution, and that is a pretty fundamental piece of glue (let's not argue about exactly *how* fundamental). However, I stick with my original claim that we should allow various algorithms. Sure, we should have one (or more, for export/patent/whatever reasons) base algorithm, so that all entries are signed in at least one way which everyone can verify. I don't see any reason not to allow pairwise use of other algorithms, though. If (as seems unlikely, but I admit it's possible) someone discovers a hole in the base algorithm, this would allow a (less painful) incremental, and interoperable, switch to a new algorithm. Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 01:24:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25718; Wed, 27 Apr 1994 00:21:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA09675; Wed, 27 Apr 1994 00:19:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA09672; Wed, 27 Apr 1994 00:16:01 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25548; Wed, 27 Apr 1994 00:17:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03362; Tue, 26 Apr 94 10:17:19 -0400 Date: Tue, 26 Apr 94 10:17:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404261417.AA03362@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: focused discussion (was Re: SIPP Routing Header & security) Cc: jnc@ginger.lcs.mit.edu, sipp@sunroof2.eng.sun.com From: francis@cactus.slab.ntt.jp (Paul Francis) Date: Tue, 26 Apr 94 08:31:03 JST So, a packet with no route header has a very small route sequence--two addresses. These addresses also identify the source and destination of the packet, and say nothing about the path in between (that's *entirely* controlled by the routing tables in the routers), so this case *is* different in important ways. If a host won't "turn around" a "source route" for another host that hasn't been authenticated, then it also shouldn't reverse the source and dest address for another host that hasn't been authenticated. It all depends on what kind of attack you're worried about. If you're willing to assume the routers haven't been subverted, you might be willing to turn around a source/dest pair which hasn't been authenticated, on the grounds that the host is one you are prepared to send traffic to, without authentication that the packets come from that host. You can be sure that traffic sent to that host will get to it; pretty much the worst possible problem here is denial of service (through bogus incoming packets). However, if, in addition to accepting unathenticated sources, you're willing to accept and turn around source routes as well, anybody can masquerade as anyone else. the original message ... never actually said what the security hole was that source routing introduced. ... write down ... what the threat is *introduced* by turning around the source route. There are various threats (in addition to the ones above), such as wiretapping, traffic analysis, etc, depending on what the scenario is: is the source authenticated; is the packet modified; etc, etc. From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Date: Mon, 25 Apr 94 20:08:43 EDT > So, my question to Ran is, exactly when will your host be willing to > exchange packets with another host. ... Will your host just not talk to > anything that hasn't been authenticated? Will ignore all Routing Headers that are not authenticated successfully. Is this only in cases where the source is not authenticated? After a previous private discussion with Ran, I still claim that if the source is authenticated, and the packet isn't modified (to prevent stealing an authentication, and slapping it on the front of a totally different packet) the authentication of the Routing Header adds almost nothing. If the routers are subverted, all bets are off anyway, and if they are not, you're OK without the authentication. So, as far as I can see, given those two conditions, you don't need to authenticate the source route; you can even turn it around safely. What am I missing? From: francis@cactus.slab.ntt.jp (Paul Francis) Date: Tue, 26 Apr 94 09:28:54 JST So, with an extended address, ... one is specifying a portion of a hierarchical address, at the same level of specificity as when one utters a single hierarchical address. The host may be uniquely identified by the low-order 64-bits, and that may be correct, but if the rest of the address is not protected, there is a potential for the same kind of attack as with source routes. If you think of the low order part as an EID, and the rest as the locator, it's just like changing the EID->locator binding; you could get some other machine at a different locator to "impersonate" the host (modulo authentication issues). The problem here seems to be that sometimes the Route Header is used to encode a hierarchical address, and sometimes to encode an explicit intermediate hop. ... I'm not sure what to do about this. Use two different mechanisms for the two different functions. This is just one of the many problems you will *inevitably* run into when you try and get one thing to serve two masters. From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Date: Tue, 26 Apr 94 07:34:06 EDT If the kernel can't _dependably_ distinguish the two, then it doesn't help because some clever person will make a source route look like an extended address and we have the same problem as before. Given the way the semantics of that field is defined, I'm wondering if there is any easy fix to this problem. That address sequence is supposed to consist of a list of SIP addresses, i.e. things you stick in the packet "destination address" field, and route on. Whether it's a source route, or an extended address, is far more in the mind of the beholder, than in any mechanistic difference. Sticking in a bit to say "this is part of an extended address" isn't going to help; as long as the *mechanism* for *using* that field is the same, it's subject to the same kinds of attacks. Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 02:40:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01207; Wed, 27 Apr 1994 02:40:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA09871; Wed, 27 Apr 1994 02:39:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA09868; Wed, 27 Apr 1994 02:34:11 +1000 From: smb@research.att.com Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01062; Wed, 27 Apr 1994 02:35:33 +1000 (from smb@research.att.com) Message-Id: <9404261635.1062@munnari.oz.au> Received: by gryphon; Tue Apr 26 12:33:13 EDT 1994 To: ekr@eit.COM (Eric Rescorla) Cc: Big-Internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp Subject: Re: Public Key Patents (Was SIPP header & security & DNS security draft) Date: Tue, 26 Apr 94 12:33:10 EDT On the other hand, I don't know that status of ElGamal with regard to being separately patented. If it isn't, it will become freely available in 1997 when the general public key patents expire whereas RSA's patents expire in 2000. ElGamal is not patented. From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 03:48:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29897; Wed, 27 Apr 1994 02:07:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA09829; Wed, 27 Apr 1994 02:04:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA09752; Wed, 27 Apr 1994 01:36:04 +1000 Received: from [192.100.58.2] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28641; Wed, 27 Apr 1994 01:37:24 +1000 (from ekr@eit.COM) Received: from kmac.eitech.com (kmac.eit.COM) by eit.COM (4.1/SMI-4.1) id AA05381; Tue, 26 Apr 94 08:36:59 PDT Date: Tue, 26 Apr 94 08:36:59 PDT From: ekr@eit.COM (Eric Rescorla) Message-Id: <9404261536.AA05381@eit.COM> To: Big-Internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp Subject: Public Key Patents (Was SIPP header & security & DNS security draft) > is Masataka Ohta I'm not sure who >> is. >> But I also think we need to wake >> up and face reality. The Internet needs public key cryptography --- >> badly; and if making peace with RSADSI is what's required until the >> patent runs out in a few more years, then we should do what is necessary >> to do so. >What's wrong with ElGamal? PKP claims that ElGamal is covered under the original patents granted to Diffie, Merkle, and Hellman (US Pat 4,200,770) and Merkle and Hellman (4,218,582). In fact, the RSA FAQ states that "In an recent case, for example, PKP brought suit against the TRW corporation which was using Public Key Cryptography (the ElGamal system) without a license; TRW claimed it did not need a license. In June 1992 a settlement was reached in which TRW agreed to license the patents." (RSA FAQ v 2.0) Whatever your opinion on algorithmic patents, it appears that PKP intends to act against those who use ElGamal without licenses as well as RSA. On the other hand, I don't know that status of ElGamal with regard to being separately patented. If it isn't, it will become freely available in 1997 when the general public key patents expire whereas RSA's patents expire in 2000. -Ekr From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 06:52:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06760; Wed, 27 Apr 1994 04:25:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA09995; Wed, 27 Apr 1994 04:24:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA09965; Wed, 27 Apr 1994 03:52:49 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00440; Wed, 27 Apr 1994 02:17:28 +1000 (from yakov@watson.ibm.com) Message-Id: <9404261617.440@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1107; Tue, 26 Apr 94 12:17:20 EDT Date: Tue, 26 Apr 94 12:16:04 EDT To: big-internet@munnari.OZ.AU Subject: a question about the IPng criteria In the IPng Criteria document Section 5.10 said: "Every datagram must carry the identifier of both its source and its destination (or some other method must be available to determine these identifiers, given a datagram)." What is the time limit of the binding between an identifier and the entity it identifies ? For example is it a requirement to be able to identify the source of a packet one day (week, month, year) from the time the packet has been traversed through the Internet ? Yakov. From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 08:30:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15714; Wed, 27 Apr 1994 08:30:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA10249; Wed, 27 Apr 1994 08:29:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA10235; Wed, 27 Apr 1994 08:21:06 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04642; Wed, 27 Apr 1994 03:40:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: from [18.26.0.82] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25041 Wed, 27 Apr 1994 03:29:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05986; Tue, 26 Apr 94 13:27:03 -0400 Date: Tue, 26 Apr 94 13:27:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404261727.AA05986@ginger.lcs.mit.edu> To: int-serv@isi.edu, nimrod-wg@bbn.com, rsvp@isi.edu, sdrp@catarina.usc.edu Subject: Do we need a 'flows' mailing list? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu During a discussion with Craig, he suggested that I poll people to see if those of us who believe in flows should have a single mailing list for discussing generic flow stuff on. The current situation, with 4 (or more) groups working on flows means that either i) generic topics cause people to get multiple copies or ii) some people miss useful stuff. For instance, some of the Nimrod people at BBN missed the discussion of mulitcast flows which happened on the RSVP list. Replies pro and con to me *only*, please (no 'reply-all' :-), and I'll send out a summary. (Volunteers to host same also accepted...) Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 08:39:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12020; Wed, 27 Apr 1994 06:46:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA10129; Wed, 27 Apr 1994 06:44:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA10115; Wed, 27 Apr 1994 06:25:23 +1000 Received: from TSX-11.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11284; Wed, 27 Apr 1994 06:26:45 +1000 (from tytso@ATHENA.MIT.EDU) Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA00886; Tue, 26 Apr 94 16:25:38 EDT Date: Tue, 26 Apr 94 16:25:38 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9404262025.AA00886@tsx-11.MIT.EDU> To: Masataka Ohta Cc: "Terry, L., Davis, P.E., Boeing, Computer, Services, Bellevue, WA"@necom830.cc.titech.ac.jp, tld5032@commanche.ca.boeing.com, dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com, paul@vix.com, dee@skidrow.lkg.dec.com In-Reply-To: Masataka Ohta's message of Tue, 26 Apr 94 17:57:23 JST, <9404260857.AA06015@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Tue, 26 Apr 94 17:57:23 JST What's wrong with ElGamal? 1) It doesn't provide support for data hiding. RSA does. While this is not required for DNS per se, having support for encryption would allow us to leverage the DNS key hierarchy for many other things, including IP security. With RSA, the keys that are used for secure DNS can also be used to establish secure data exchange keys for encryption purposes. El Gamal does not provide this capability. 2) El Gamal is also subject to U.S. patents: From the "Answers to FREQUENTLY ASKED QUESTIONS About Today's Cryptography", published by RSA Data Security: In a recent case, for example, PKP brought suit against the TRW Corporation which was using public-key cryptography (the ElGamal system) without a license; TRW claimed it did not need to license. In June 1992 a settlement was reached in which TRW agreed to license to the patents. Either way, vendors will have to fork some amount of money over to RSA DSI. Public key makes management issue of secret data much easier. Other things won't be affected by it. Modularized secure DNS which enables both RSA, shared secret and KDC is easy to construct. It may be easy to construct; a shared secret system (like Kerberos) simply can't be maintained or administered at large scales, however. KDC's are primarily good for a single site, or a few sites. They don't work over the entire Internet, and that's the problem that we're trying to solve. - Ted From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 08:40:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13184; Wed, 27 Apr 1994 07:20:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA10170; Wed, 27 Apr 1994 07:19:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA10145; Wed, 27 Apr 1994 06:49:11 +1000 Received: from gw.home.vix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12111; Wed, 27 Apr 1994 06:50:10 +1000 (from vixie@gw.home.vix.com) Received: by gw.home.vix.com id AA06227; Tue, 26 Apr 94 13:49:54 -0700 Message-Id: <9404262049.AA06227@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Reply-To: paul@vix.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Tue, 26 Apr 1994 16:25:38 EDT." <9404262025.AA00886@tsx-11.MIT.EDU> Date: Tue, 26 Apr 1994 13:49:53 -0700 From: Paul A Vixie I have several requests. First, if you reply to a message on the list, edit the reply headers to remove all the individuals who are themselves probably on the list. Wide-area dupli- cate suppression doesn't work, and I don't like getting N+1 copies of each msg which is a distant descendent of some thread I've participated in. Second, please think very carefully about sending any message to more than one list. There is a huge overlap in the memberships, and charters, of SIPP, BigInternet, and dns-security. Sending to one and only one of these lists is probably enough for most topics. I'm making an exception for this message since it's meta-topical rather than topical. Third, well, #3 is topical so I'll make it into a separate message. From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 14:15:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21792; Wed, 27 Apr 1994 11:25:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA10402; Wed, 27 Apr 1994 11:24:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA10399; Wed, 27 Apr 1994 11:22:01 +1000 Received: from ADRASTEA.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12771; Wed, 27 Apr 1994 07:08:25 +1000 (from wollman@adrastea.lcs.mit.edu) Received: by adrastea.lcs.mit.edu; id AA23432; Tue, 26 Apr 1994 17:07:59 -0400 Date: Tue, 26 Apr 1994 17:07:59 -0400 From: Garrett Wollman Message-Id: <9404262107.AA23432@adrastea.lcs.mit.edu> To: dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Reply-To: wollman@lcs.mit.edu Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: <9404262025.AA00886@tsx-11.MIT.EDU> References: <9404260857.AA06015@necom830.cc.titech.ac.jp> <9404262025.AA00886@tsx-11.MIT.EDU> < Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17610 Wed, 27 Apr 1994 16:48:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA10665; Wed, 27 Apr 1994 16:39:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA10651; Wed, 27 Apr 1994 16:18:04 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04013; Wed, 27 Apr 1994 16:19:20 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20052; Wed, 27 Apr 1994 08:18:32 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07785; Wed, 27 Apr 1994 08:18:31 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404270618.AA07785@dxcoms.cern.ch> Subject: Re: a question about the IPng criteria To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 27 Apr 1994 08:18:31 +0200 (MET DST) In-Reply-To: <9404261617.440@munnari.oz.au> from "yakov@watson.ibm.com" at Apr 26, 94 12:16:04 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 787 Yakov, > > In the IPng Criteria document Section 5.10 said: > > "Every datagram must carry the identifier of both its source > and its destination (or some other method must be available > to determine these identifiers, given a datagram)." > > What is the time limit of the binding between an identifier > and the entity it identifies ? For example is it a requirement > to be able to identify the source of a packet one day (week, month, year) > from the time the packet has been traversed through the Internet ? > Are you asking whether it is an EID or a locator which is referred to here? Since accounting is one of the things behind this requirement my answer is EID. Because of mobility, it seems unlikely that a locator is sufficient for accounting purposes. Brian From owner-Big-Internet@munnari.OZ.AU Wed Apr 27 20:02:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05467; Wed, 27 Apr 1994 16:55:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA10691; Wed, 27 Apr 1994 16:53:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA10637; Wed, 27 Apr 1994 16:07:38 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26869; Wed, 27 Apr 1994 13:34:15 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 27 Apr 94 12:28:36 +0900 From: Masataka Ohta Message-Id: <9404270328.AA09765@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft To: dns-security@tis.com, big-internet@munnari.OZ.AU Date: Wed, 27 Apr 94 12:28:35 JST In-Reply-To: <9404262025.AA00886@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Apr 26, 94 4:25 pm X-Mailer: ELM [version 2.3 PL11] > What's wrong with ElGamal? > > 1) It doesn't provide support for data hiding. It does, though the algorithms for confidentiality and for authentication are different. > With RSA, the keys that are used for secure DNS can also be used to > establish secure data exchange keys for encryption purposes. Wrong. For encryption purposes, you need keys for hosts or users. Secure DNS is now being deeveloped so that a zone, not a host in general, will have a key. > El Gamal does not provide this capability. It does. Two ElGamal algorithms for confidentiality and for authentication share the same public key. > 2) El Gamal is also subject to U.S. patents: I know. But it will expire 1997, much earlier than 2000. > Public key makes management issue of secret data much easier. Other > things won't be affected by it. Modularized secure DNS which enables > both RSA, shared secret and KDC is easy to construct. > > It may be easy to construct; a shared secret system (like Kerberos) > simply can't be maintained or administered at large scales, however. > KDC's are primarily good for a single site, or a few sites. They don't > work over the entire Internet, and that's the problem that we're trying > to solve. I merely pointed out that we can construct modularized secure DNS without technical difficulty. I'm not particulary in favour of the idea to use KDC or something like that till 1997 and ElGamal later. But, when any public key mechanism is proven to be broken, as some of the people are afraid of, KDC with conventional security model or something like that could be a refuge till a new algorithm prevails. If any public key mechanism is proven to be broken, we are valunerable till alternative secure algorithm is developpeed and installed within a name server, which will take a considerable amount of time, much longer than rewriting secure DNS RFC with a new algorithm. So, unless alternate secure algorithm is installed in name servers IN ADVANCE, algorithm independence is not meaningful. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Apr 28 04:56:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04309; Thu, 28 Apr 1994 04:56:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA11352; Thu, 28 Apr 1994 04:54:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA11336; Thu, 28 Apr 1994 04:36:54 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03636; Thu, 28 Apr 1994 04:38:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13825; Wed, 27 Apr 94 14:38:13 -0400 Date: Wed, 27 Apr 94 14:38:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404271838.AA13825@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu I see nothing wrong with a "default" algorithm if we can change it. I cannot see that capability in the draft as it appears to be tightly written around RSA. ... Should at some future date the single chosen technology be broken, all you are left with is "false security" which is worse than "no security". For what it's worth, the paper today reports that group of researchers have factored a 129-digit number (of the kind used by RSA). 25 years down the line, when we all have 1M-CPU connection machines in our PDA's, we might want something better.... Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 28 05:01:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04431; Thu, 28 Apr 1994 05:01:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA11378; Thu, 28 Apr 1994 05:00:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA11333; Thu, 28 Apr 1994 04:30:05 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25068; Thu, 28 Apr 1994 01:35:51 +1000 (from tld5032@commanche.ca.boeing.com) Received: by atc.boeing.com (5.57) id AA12434; Wed, 27 Apr 94 08:35:59 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA08369; Wed, 27 Apr 94 08:35:44 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA22093; Wed, 27 Apr 1994 08:34:01 -0700 Message-Id: <9404271534.AA22093@commanche.ca.boeing.com> To: dee@skidrow.lkg.dec.com Cc: dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: (Your message of Mon, 25 Apr 94 13:14:53 D.) <9404251714.AA13136@skidrow.lkg.dec.com> Date: Wed, 27 Apr 94 08:34:01 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Donald > Nonsense. Pick up the telephone. Call RSA Data Systems Inc. in > Redwood City, California. (Or have your lawyer call their lawyer.) > They will confirm that any company can use RSA internally, use PEM to > communicate with other companies, etc., all in a profit making > setting. The only thing RSA is still asking for royalties for is > people who want to sell software incorporating RSA or sell a service > where RSA is an essential part. > Given the option to discuss issues with lawyers (most of whom I can almost never understand) or to design in a way that I may be able to leave them out, I always opt to try to leave them out. Whether I'm selling aircraft, video services, or personal information devices, in the near future all will rely on incorporation of DNS into their core systems. You're saying that they won't want any royalties from my airplane, my home entertain system, or my home computer, all of which would utilize their technology via DNS? That's not quite how I understood their statements. > Whatever algoritm is chosen, the people who want to interoperate will > all have to speak it. Everyone knows you will need a method to roll > over to a new algorithm when / if that is necessary. > As I responded to "Ted Ts'o", I have no problem with a "default algorithm", but I see no way to incorporate any alternative algorithm into DNS or to "roll over to a new algorithm" as the draft is currently written. > So you want multiple algorithms so that those who want to interoperate > will have to speak all of them so that if *any* *one* *of* *them* > is broken, things will fall apart? Sounds like a great way to weaken > network security to me. > Point well taken! But in some cases, groups even countries may be required to NOT use the chosen technology but something else more "politically" acceptable. Governments (and large corporations, especially if they're into money) tend to be paranoid about crytography. I'm fairly sure that not all the world governments would allow comm systems utilizing this crytographic technology to be deployed within their borders. Remember our own country requires anyone selling good crytography to be hold a federal "armaments manufacturers" license and places their exports under even tighter restrictions than just selling missles or bombs. > (Of course there should also be a way for consenting adults to use > whatever algorithm they want, not that you could stop them anyway.) > That's what I am looking. I think it would also solve the "roll over" problem. > Donald > Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | --------------- Wednesday April 27,1994 08:31 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! == From owner-Big-Internet@munnari.OZ.AU Thu Apr 28 06:53:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01585; Thu, 28 Apr 1994 03:49:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA11274; Thu, 28 Apr 1994 03:44:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA11260; Thu, 28 Apr 1994 03:36:02 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22810; Thu, 28 Apr 1994 00:31:36 +1000 (from tld5032@commanche.ca.boeing.com) Received: by atc.boeing.com (5.57) id AA05808; Wed, 27 Apr 94 07:33:18 -0700 Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (16.6/16.2) id AA07161; Wed, 27 Apr 94 07:33:03 -0700 Received: by commanche.ca.boeing.com (AIX 3.2/UCB 5.64/4.03.TLDavis.AIX_3.2.5) id AA25120; Wed, 27 Apr 1994 07:31:19 -0700 Message-Id: <9404271431.AA25120@commanche.ca.boeing.com> To: tytso@athena.mit.edu Cc: dns-security@tis.com, big-Internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Date: Wed, 27 Apr 94 07:31:18 -0800 From: "Terry L. Davis P.E., Boeing Computer Services, Bellevue, WA" Ted > .........Like it or > not, whether or not we have an algorithm identifier field or not, in > order for this thing to work, the IETF is going to have to put a stake > in the ground and say that everyone is going to use this *one* > cryptographic algorithm. > I see nothing wrong with a "default" algorithm if we can change it. I cannot see that capability in the draft as it appears to be tightly written around RSA. I think the capability to switch away from a default algorithm is critical. At the same time, this capability would probably also allow those of us who wish to (or are required to) use our own alternates (between consenting adults of course!) to do so. > It's the same problem as the one that's facing the IPNG decision > process. Sometimes, you just have to pick one, and picking anything > protocol is better than not picking a protocol at all. > In any engineering problem, risk assessments must be made; that is are the consequences of failure as weighed against the cost of alternative designs or delays balanced. In this case, I personally think not and certainly do not agree that "anything is better than nothing". Should at some future date the single chosen technology be broken, all you are left with is "false security" which is worse than "no security". > For all of the people who have been bitching and moaning --- if you > don't like the current proposal, then come up with something new! > Unfortunately, public key cryptography is a key technology, without > which, many things in cryptography and security architecture become > much harder. > A lot of us are thinking about alternatives and I don't think any of us want to see the work that Donald and Charles started not be carried to completion. I not so concerned about ease as I am long term durability. > Don't get me wrong --- I think software patents and algorithm patents > are particularily evil, and Congress should wake up and ban the Patent > Office from issuing any more of them. > Evil ??? Needs work, Definitely!!! > - Ted > Take care | Terry L. Davis | Boeing Computer Services, Bellevue, WA | | 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. | | INTERNET EMAIL: tld5032@atc.boeing.com. | --------------- Wednesday April 27,1994 07:29 AM PDT ------------- == As always, the above cannot be construed as representing BOEING, == == the thoughts, comments, and ideas contained herein are mine alone! == From owner-Big-Internet@munnari.OZ.AU Thu Apr 28 06:57:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07981; Thu, 28 Apr 1994 06:43:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA11492; Thu, 28 Apr 1994 06:39:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA11457; Thu, 28 Apr 1994 06:23:01 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07343; Thu, 28 Apr 1994 06:24:21 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA19960; Wed, 27 Apr 94 16:24:00 EDT Message-Id: <9404272024.AA19960@tipper.oit.unc.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 14:38:13 EDT." <9404271838.AA13825@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Apr 94 16:23:59 -0400 From: Simon E Spero Even with the new techniques, factorisation still gets exponentially harder as you add more digits. 129 digits is only 429 bits, so 512 bit keys are still pretty safe. By the way, it's interesting to note that the folks who did the factorisation donated the $100 prize money to the FSF. Maybe we can apply that to the problem of address space wasterels. If we set up a tax for every IP address allocated to an organisation that isn't pingable from (say) venera.isi.edu, and give all the proceeds to the FSF, we'd get a bunch of addresses back, a reduction in the number of firewalls, and a whole bunch of new free software which is one of the main wins of the net anyway. From owner-Big-Internet@munnari.OZ.AU Thu Apr 28 13:41:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26690; Thu, 28 Apr 1994 13:41:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA11890; Thu, 28 Apr 1994 13:39:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA11887; Thu, 28 Apr 1994 13:38:18 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26577; Thu, 28 Apr 1994 13:39:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16412; Wed, 27 Apr 94 23:39:19 -0400 Date: Wed, 27 Apr 94 23:39:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404280339.AA16412@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: recent AN_S PSI route flapping Cc: jnc@ginger.lcs.mit.edu Sounds to me like policy routing is already out of its depth, and we should abandon it in favor of something dynamic. Did you mean this exactly, or did you mean something more like your previous comment ("hand configuring these policy tables will be intractable")? "Policy routing" refers to a really broad range of things, some of which are fairly automated. Noel From owner-Big-Internet@munnari.OZ.AU Thu Apr 28 15:16:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19456; Thu, 28 Apr 1994 11:22:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA11748; Thu, 28 Apr 1994 11:19:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA11734; Thu, 28 Apr 1994 10:57:01 +1000 Received: from relay.tis.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09645; Thu, 28 Apr 1994 07:29:31 +1000 (from crocker@tis.com) Received: by relay.tis.com; id AA22062; Wed, 27 Apr 94 17:30:09 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma022040; Wed Apr 27 17:29:46 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA01753; Wed, 27 Apr 94 17:28:25 EDT Message-Id: <9404272128.AA01753@tis.com> To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Wed, 27 Apr 94 14:38:13 EDT." <9404271838.AA13825@ginger.lcs.mit.edu> Date: Wed, 27 Apr 94 17:28:19 -0400 From: Stephen D Crocker > From: Noel Chiappa > To: big-internet@munnari.oz.au, dns-security@tis.com > cc: jnc@ginger.lcs.mit.edu > Date: Wed, 27 Apr 94 14:38:13 -0400 > Subject: Re: SIPP Routing Header & security & Re: DNS security draft > ... > For what it's worth, the paper today reports that group of > researchers have factored a 129-digit number (of the kind used by > RSA). 25 years down the line, when we all have 1M-CPU connection > machines in our PDA's, we might want something better.... > > Noel > This has been known for a few weeks. There's nothing worrisome, if that's the implicit question. 129 digits is 430 bits. Don't use RSA keys that short. 512 is the least anyone would use. 640, 768 and 1024 are more conservative key sizes that are in increasingly common use. These are all *much* harder to crack (factor) than 430 bits. Except for special exercises like the one reported, or organizations with exceptional resources like NSA, even cracking 430 bits is not within ordinary reach. On the other side of the coin, 512 is exportable, so that's considered unacceptable if you really want security. (Exportable for encryption. Any length is exportable for signature.) Steve From owner-Big-Internet@munnari.OZ.AU Thu Apr 28 17:46:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24872; Thu, 28 Apr 1994 13:08:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA11849; Thu, 28 Apr 1994 13:04:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA11823; Thu, 28 Apr 1994 12:30:40 +1000 Received: from [128.60.2.2] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07782; Thu, 28 Apr 1994 06:38:19 +1000 (from mankin@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09850; Wed, 27 Apr 94 14:39:41 EDT Date: Wed, 27 Apr 94 14:39:41 EDT From: mankin@itd.nrl.navy.mil (Allison Mankin) Message-Id: <9404271839.AA09850@itd.nrl.navy.mil> To: big-internet@munnari.OZ.AU, iab@isi.edu, iesg@cnri.reston.va.us, ietf@cnri.reston.va.us Subject: IPng Area Update This is a quick update on the status of the IETF IPng effort. Since the creation of the IPng area late last year we have been focused on two primary tasks; developing a reasonable estimate of the projected lifetime for the IPv4 address space and producing a draft requirements document. The IPv4 Address Expectations Working Group (ALE), chaired by Frank Solensky and Tony Li reported during a session held at the IETF meeting in Seattle that their current estimate was that the IPv4 address supply would be exhausted in the year 2008 ( plus or minus 3 years), assuming no changes in the basic rate of growth in the demand for addresses. Clearly, if there were a request for a very large block (many millions) of addresses, it would affect this estimate. The Transition and Coexistence Including Testing (TACIT) working group, chaired by Atul Bansal and Geoff Huston had its first meeting in Seattle. This group will focus on the long term transition and coexistence issues and will define recommendations for testing IPng specifications and implementations. Of course, the working groups for each of the IPng candidates have been busy and did meet in Seattle to further refine the details of their proposals. The IPng Requirements BOF, chaired by Frank Kastenholz and Jon Crowcroft, has produced a draft of an IPng requirements document. The current draft is a refinement of an initial document by Frank Kastenholz and Craig Partridge. It reflects input from a number of the white papers that the IPng area solicited with RFC1550 and comments from the IPng directorate. The requirements draft is ready for public comment. It has been published as an internet-draft (draft-kastenholz-ipng-criteria-01.txt). We need as many comments as possible by May 10. All interested persons (that should be just about all reading this message) should take a look at this document and, if you have comments or suggestions, send them to the big-internet list. (Send a note to big-internet-request@munnari.oz.au to subscribe.) You should also take a look at the RFC1550 white papers, they have been published as internet drafts. Look for any internet draft with "ipng" in its filename. All of these documents are available at you favorite internet-drafts site and from hsdndev.harvard.edu in pub/ipng/wp for anonymous ftp. Hsdndev also allows gopher access. The IPng directorate mailing list archives and directorate teleconference minutes are also available from hsdndev. We urge you to take a look at these documents and records. Let us know on the big-internet list or in private mail what you think. This is an effort that will effect us all and anyone who can help make the result better or the transition easier is encouraged to participate. Appended to this update is the area status report from the Seattle IETF meeting. Scott & Allison IETF 29 IP: Next Generation Area Report Seattle, Washington Scott Bradner Allison Mankin Meetings of 4 IP: Next Generation working group, 3 BOFs, and an open IPng directorate meeting were held during the 29th IETF meeting in Seattle, Washington. Address Extension by IP Option Utilisation BOF (AEIOU) Reported by Peter Ford Chair Brian Carpenter Brian Carpenter presented the aeiou proposal (draft-carpenter-aeiou-00.txt) and there was a lively discussion. Most people felt that aeiou would work and could, with effort, be developed into a viable stop-gap solution. There was one significant technical issue, the impact of option analysis on local router performance. The main debate was whether the savings in work and time to implement and deploy aeiou compared to a full IPng solution were significant and worthwhile. There was a range of views on this. The conclusion was not to propose an aeiou working group at this time, but to document the proposal (possibly as an Informational RFC) to keep it in reserve for future eventualities. Interested people should contact brian@dxcoms.cern.ch. Address Lifetime Expectations WG (ALE) Reported by Tony Li Chairs: Tony Li , Frank Solensky The ALE WG met to discuss its projections and future mechanisms for improving the lifetime of the address space. Our current projections were presented and subsequent discussion ensued. As a result, ALE will also begin to track routing table sizes. We have volunteers to collect data for us. We discussed address efficiency and have a volunteer to produce a document on improving address space efficiency. RFC 1597 was presented, and was thought to be very helpful. We discussed the timetable for IPng, but were unable to come to any reasonable conclusions due to uncertainty about the deployment of CIDR and the explosion of the routing tables. Common Architecture for Next-Generation IP WG (CATNIP) Reported by Robert Ullmann Chair (pro tem) Robert Ullmann WG meeting was chaired pro-tem by Robert Ullmann, as Vladimir Sukonnik was unable to attend. Robert did a small soapbox on the proper scope of the IPng proposals. This was followed by discussion of a number of minor technical issues identified recently on the CATNIP list. Several IPX related issues were left uncertain. The issue of TUBA TCP and UDP checksums to be discussed with the TUBA WG. DNS issues to be resolved in a near future revision of the Collela/Manning draft which will be used by both TUBA and CATNIP. Fragment translation was discussed, with the differring semantics between CLNP, IPv4, and SIPP making it less useful than would be expected. IPNG Requirements WG (NGREQS) Reported by Frank Kastenholz Chairs Jon Crowcroft , Frank Kastenholz The working group had a number of presentations from members of the community who are experts in particular technical areas. These included Mike StJohns on Security, Greg Minshall on Mobility, Dave Clark on Network Services, Lixia Zhang on RSVP, Mark Handly on AVT, Peter Ford on Backbones, and John Curran on Market Needs. The intent was to give the group background information on these particular areas and their specific needs -- similar to the White Papers solicited by the Directorate. The working group then proceeded into a lively and spirited debate on the various criteria. The community suggested many significant improvements which are still being digested by the chairs and authors. One important improvement that seemed to have great support from the community was that the requirements should be strengthened amd made firmer -- fewer "should allows" and the like and more "musts". SIPP WG Reported by Bob Hinden Chair Bob Hinden March 1994 IETF The SIPP working group held a implementors meeting on Sunday afternoon and two working group sessions on Wednesday and Thursday. Bob Hinden presented a summary of recent working group activities. This included that the SIPP charter had been approved, the SIPP Whitepaper had been completed on time, a summary of the SIPP specifications which had been completed since the last IETF meeting, and the SIPP specifications which were submitted to the IPng area directors for publication as experimental RFC's. Also presented was the announcement that Mosaic pages had been created for the SIPP working group. These can be found at http://town.hall.org Jim Bound presented a summary of the implementors meeting. A number of SIPP implementors had attended and several refinements had been made to some of the SIPP options based on implementation experience. These changes will be documented in an update to the SIPP specification. Steve Deering presented an overview of the changes from last fall's SIP spec to the current SIPP specification. This included details on the layout of the Flow ID. Ramesh Govindan and Sue Thompson presented the current approach for dealing with auto configuration and discovery. This resolved the issues that were outstanding with the current drafts. New specifications will be published. Bob Gilligan presented an overview of IPAE. This resulted in a discussion of some of the details of IPAE and uncovered a bug. There was general agreement that IPAE needs to be simplified. This will be worked on and the specification will be updated. The Transition and Coexistence including Testing (TACIT) BOF Reported by Geoff Huston Chairs: Geoff Huston Atul Bansal The BOF discussed the issues relating to transition and coexistence in general terms as they relate to the constituency of the Internet, and also discussed the specific issues relating to potential IPng transition environments. The view was expressed that the characteristics and potential timeframe of transition, coexistence and testing processes will be greatly influenced through the interplay of market forces within the Internet, and that any IPng transition plan should recognise these motivations and provide ample levels opportunity identification to encourage the broad Internet constituency to subscribe to the transition process (and therefore undertake to meet the associated deployment costs of such transition). The group decided to recommend to the IPNG Area Directoriate to form a Working Group to explore the generic issues of the IPng transition process and gather experience from previous technology transition that have occured both within the Internet and within related networking technologies. A draft charter was reviewed, with the view that this Working Group work would contribute to the IETF IPng process by identifying these issues and reviewing IPng transition plans at the appropriate phase of the IPng process. TCP and UDP with Big Addresses (TUBA) WG Reported by Peter Ford Chairs Peter Ford Mark Knopper Dave Marlow presented an update on the status of CLNP multicast. His Internet Draft is intended to be multicast routing protocol independent, and was presented from the ES viewpoint. Discussion ensued as to whether the complexity of the network-to-data-link address mapping protocol was worthwhile. The "extra hop" problem is widely viewed as being a show-stopper and Dave presented an approach to address this problem and will be updating the ID to reflect this. Lyman Chapin updated the group on the electronic availability of the pertinent ISO standards. Lyman is now comfortable posting these documents as I-Ds and the network layer protocols (CLNP, IS-IS, ES-IS and IDRP) will all be published by the end of the Seattle IETF. Dino Farinacci gave a short presentation on the status of Protocol Independent Multicasting (PIM) in the IDMR working group. He noted there would be little difficulty in using PIM for multicast routing of CLNP. Ross Callon presented his work on flows in CLNP. In this scheme the source NSEL is used to demultiplex flows between a single host pair. The size of this field (eight bits) was a source of controversy and there was concern that using the Source NSEL might cause to non-TUBA CLNP entitities. Dave Piscitello gave an overview of the current TUBA transition document. Bob Brenner from GTE gave an overview of Cellular Packet Data Network (CDPD). CDPD is using CLNP as an underlying protocol, but it can support mobile hosts that are either CLNP or IP speakers. From owner-Big-Internet@munnari.OZ.AU Fri Apr 29 08:23:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08619; Fri, 29 Apr 1994 06:01:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA12726; Fri, 29 Apr 1994 05:59:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA12723; Fri, 29 Apr 1994 05:57:51 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08555; Fri, 29 Apr 1994 05:59:11 +1000 (from mankin@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA24111; Thu, 28 Apr 94 15:59:03 EDT Date: Thu, 28 Apr 94 15:59:03 EDT From: mankin@itd.nrl.navy.mil (Allison Mankin) Message-Id: <9404281959.AA24111@itd.nrl.navy.mil> To: big-internet@munnari.OZ.AU, iab@isi.edu, iesg@cnri.reston.va.us, ietf@cnri.reston.va.us Subject: IPng Addendum Whoops, the IPng Area Directors forgot to mention one important item, which is that we are still on track to present our recommendation on IPng at the Toronto IETF at the end of July. Also, note that our presentation from the Houston IETF Monday plenary is available by ftp and gopher from hsdndev.harvard.edu in pub/ipng/ietf.3.94. Allison and Scott From owner-Big-Internet@munnari.OZ.AU Fri Apr 29 11:30:33 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17626; Fri, 29 Apr 1994 10:20:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12858 Fri, 29 Apr 1994 09:03:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA12921; Fri, 29 Apr 1994 08:59:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA12881; Fri, 29 Apr 1994 08:35:28 +1000 Received: from TSX-11.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28712; Fri, 29 Apr 1994 02:06:41 +1000 (from tytso@ATHENA.MIT.EDU) Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA10972; Thu, 28 Apr 94 12:06:08 EDT Date: Thu, 28 Apr 94 12:06:08 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9404281606.AA10972@tsx-11.MIT.EDU> To: Masataka Ohta Cc: dns-security@tis.com, big-internet@munnari.OZ.AU In-Reply-To: Masataka Ohta's message of Wed, 27 Apr 94 12:28:35 JST, <9404270328.AA09765@necom830.cc.titech.ac.jp> Subject: Re: SIPP Routing Header & security & Re: DNS security draft Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Masataka Ohta Date: Wed, 27 Apr 94 12:28:35 JST > What's wrong with ElGamal? > > 1) It doesn't provide support for data hiding. It does, though the algorithms for confidentiality and for authentication are different. You're right. I was confused; most of my knowledge of El Gamal comes from the DSS. > With RSA, the keys that are used for secure DNS can also be used to > establish secure data exchange keys for encryption purposes. Wrong. For encryption purposes, you need keys for hosts or users. Secure DNS is now being deeveloped so that a zone, not a host in general, will have a key. We can use the same RR for distributing the key for a zone to distribute the key for a host in general; that DNS information can be signed by zone key, which gives you the public key certification which you need. - Ted From owner-Big-Internet@munnari.OZ.AU Fri Apr 29 11:34:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17618; Fri, 29 Apr 1994 10:20:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA00114; Fri, 29 Apr 1994 09:57:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA12975; Fri, 29 Apr 1994 09:40:11 +1000 Received: from netmail.microsoft.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05224; Fri, 29 Apr 1994 04:31:19 +1000 (from paulle@microsoft.com) Received: by netmail.microsoft.com (5.65/25-eef) id AA14150; Thu, 28 Apr 94 11:31:07 -0700 Message-Id: <9404281831.AA14150@netmail.microsoft.com> Received: by netmail using fxenixd 1.0 Thu, 28 Apr 94 11:31:06 PDT X-Msmail-Message-Id: B714071C X-Msmail-Conversation-Id: B714071C From: Paul Leach To: dee@skidrow.lkg.dec.com, sipp-request@sunroof2.Eng.Sun.COM Date: Thu, 28 Apr 94 09:24:24 TZ Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: big-Internet@munnari.OZ.AU, dns-security@tis.com, sipp@sunroof2.Eng.Sun.COM ---------- | From: "Terry L. Davis P.E., Boeing Computer Services, | Bellevue, WA" | To: | Cc: ; ; | | Subject: Re: SIPP Routing Header & security & Re: DNS security draft | Date: Wednesday, April 27, 1994 8:34AM | | > Whatever algoritm is chosen, the people who want to interoperate will | > all have to speak it. Everyone knows you will need a method to roll | > over to a new algorithm when / if that is necessary. | > | As I responded to "Ted Ts'o", I have no problem with a "default | algorithm", but I see no way to incorporate any alternative algorithm | into DNS or to "roll over to a new algorithm" as the draft is currently | written. | | > So you want multiple algorithms so that those who want to interoperate | > will have to speak all of them so that if *any* *one* *of* *them* | > is broken, things will fall apart? Sounds like a great way to weaken | > network security to me. This is true, but overlooks some context. If there are several algorithms, but if for any party with whom I might want to communicate there is exactly one that I must use, then breaking one algorithm only exposes the parties that use that algorithm. So, for example, the paranoid company referred to below might use one (allegedly stronger than the default) algorithm internally, but another with outside parties. The same principle applies to using differnet algorithms for different purposes. Thus, all EFT/EDIF mail could use one algorithm, and mail discussing acquisition of another company a second. Etc. | > | Point well taken! But in some cases, groups even countries may be | required to NOT use the chosen technology but something else more | "politically" acceptable. Governments (and large corporations, | especially if they're into money) tend to be paranoid about crytography. | I'm fairly sure that not all the world governments would allow comm | systems utilizing this crytographic technology to be deployed within | their borders. Remember our own country requires anyone selling good | crytography to be hold a federal "armaments manufacturers" license | and places their exports under even tighter restrictions than just | selling missles or bombs. Paul From owner-Big-Internet@munnari.OZ.AU Fri Apr 29 11:35:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18974; Fri, 29 Apr 1994 10:55:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA00233; Fri, 29 Apr 1994 10:32:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA00191; Fri, 29 Apr 1994 10:10:31 +1000 Received: from Csli.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10389; Fri, 29 Apr 1994 06:44:00 +1000 (from ole@CSLI.Stanford.EDU) Received: by CSLI.Stanford.EDU (4.1/25-CSLI-eef) id AA04993; Thu, 28 Apr 94 13:43:29 PDT Date: Thu, 28 Apr 94 13:43:27 PDT From: "Ole J. Jacobsen" To: Allison Mankin Cc: big-internet@munnari.OZ.AU, iab@isi.edu, iesg@cnri.reston.va.us, ietf@cnri.reston.va.us Phone: +1 415 578-6900 (ZD Expos) Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular) Direct: +1 415 578-6988 (Office) +1 415 998-4427 (Pager) Fax: +1 415 525-0194 (ZD Expos) +1 415 826-2008 (Home) Address: 303 Vintage Park Drive, Foster City, CA 94404-1138 Subject: Re: IPng Addendum In-Reply-To: Your message of Thu, 28 Apr 94 15:59:03 EDT Message-Id: Let me also mention that the May 1994 issue of ConneXions is a special 56 page edition devoted entirely to IPng. It contains description of all three IPng candidates, analysis of the problem, description of the selection process, etc. You may request a sample copy of this issue by sending me a simple message with your POSTAL address. Thanks, Ole Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report, Interop Company, a division of ZD Expos, 303 Vintage Park Drive, Foster City, CA 94404-1138, USA. Phone: +1 (415) 578-6988 Fax: +1 (415) 525-0194. From owner-Big-Internet@munnari.OZ.AU Fri Apr 29 15:01:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20331; Fri, 29 Apr 1994 11:31:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA00276; Fri, 29 Apr 1994 11:07:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA00260; Fri, 29 Apr 1994 10:41:03 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26370; Thu, 28 Apr 1994 13:36:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16374; Wed, 27 Apr 94 23:36:30 -0400 Date: Wed, 27 Apr 94 23:36:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404280336.AA16374@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dns-security@tis.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft Cc: jnc@ginger.lcs.mit.edu > ...a group of researchers have factored a 129-digit number (of the kind > used by RSA). 25 years down the line, when we all have 1M-CPU connection > machines in our PDA's, we might want something better... There's nothing worrisome, if that's the implicit question. 129 digits is 430 bits. Don't use RSA keys that short. 512 is the least anyone would use. 640, 768 and 1024 are more conservative key sizes that are in increasingly common use. These are all *much* harder to crack (factor) than 430 bits. I am somewhat familiar with longer key-lengths and what that does to computationally intensive attacks. What I found illuminating (and failed to post, sorry) was that when the problem was first posed, when RSA was discovered in the late 70's, it was thought that it wouldn't be solved until "well into the next century". I think there might be a lesson there. I'm not saying I expect someone to find a magic fast factoring algorithm any time soon, or that anyone's likely to find a hole in RSA anytime soon. However, to do designs based on the assumption that RSA (even the longer key lengths you mention) will be good for all time is a bit unwise of us, (or perhaps even arrogant, as writers on technology disasters from the Titanic onward point out), don't you think? On the other side of the coin, 512 is exportable, so that's considered unacceptable if you really want security. (Exportable for encryption. Any length is exportable for signature.) Facinating. Let me make sure I get this straight. RSA for privacy with key lengths of less than 512 is OK'd for export, but not DES? Noel From owner-Big-Internet@munnari.OZ.AU Fri Apr 29 23:50:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13979; Fri, 29 Apr 1994 21:59:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA00778; Fri, 29 Apr 1994 21:37:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA00764; Fri, 29 Apr 1994 21:18:02 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11518; Fri, 29 Apr 1994 20:43:35 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA24915; Fri, 29 Apr 94 05:43:33 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa10702; 29 Apr 94 10:34 GMT Date: Fri, 29 Apr 94 05:39 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Eric Fleischman To: brian To: ipv4 ale To: big internet To: firewalls Subject: Re: NATs Message-Id: <40940429103904/0003858921NA3EM@mcimail.com> This was one the ALE list, but really belongs elsewhere... Appologies in advance to those that get multiple copies. Brian said: >>Semantics check: when I write NAT I mean IP-level address translation. >>Application level gateways are different and of course they work >>(they can even do application protocol translation if you want). >>They are however a pain to operate - we used to run a file transfer >>gateway, and we still have to run mail and terminal emulation gateways. Eric said: >Check. We have the same viewpoint once again and the only sticking point >was in wording/communication of that viewpoint. In my own mind I had >written off NATs as being impractical to implement but that the idea was >great. Thus, I had mentally substituted for that term (NAT) an entity >which is somewhat practical to implement (application layer gateways) and >which does the same thing. I prefer the term "NAT" because it represents >what is LOGICALLY happening. When Noel first told me about NATs, I got excited. Something that might be easier than application gateways, read firewalls. But I studied the NATs issues. And I listened in on the FIREWALLS list for a couple of months and came to an important realization: Network level security is worthless as long as there is application insecurity. And thus there will always be application gateways to institute corporate security policies. Yes I am fighting VERY hard to allow all employees to have public EMail, but not necessarily with THEIR SENDMAIL. All mail will end at a few defined points and from there it will be POPmail (or IMAP when that is done). We will get WWW going, but I will have to watch XMOSIAC very closely, too many system() calls according to the security experts. There will be a corporate anon FTP server, but no individual ones. Look at the resent wuFTP trapdoor. NATs are just an open door. My risks are too high for an open door policy. Note, by the way, that I, unlike someothers here, are not too concerned about exporting corporate secrets. There are too many other non-detectable ways to do that! So all of you IETFers, continue the network level security work. That has an important place. But DO NOT DELUDE YOURSELVES! It will not make the internet secure anymore than C2 has made UNIX secure. The application writers need to be indoctrinated also. Perhaps after there is a major security incident at some big university or company that is all C2 UNIX and IPng authenticated due to an application level attach, then we will raise our eyes and tackle the last great frontier, the network applications. Bob From owner-Big-Internet@munnari.OZ.AU Fri Apr 29 23:50:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16453; Fri, 29 Apr 1994 23:10:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA00855; Fri, 29 Apr 1994 22:47:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA00852; Fri, 29 Apr 1994 22:42:01 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14316; Fri, 29 Apr 1994 22:10:12 +1000 (from yakov@watson.ibm.com) Message-Id: <9404291210.14316@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3281; Fri, 29 Apr 94 08:10:11 EDT Date: Fri, 29 Apr 94 08:09:52 EDT To: brian@dxcoms.cern.ch, big-internet@munnari.OZ.AU Subject: a question about the IPng criteria Ref: Your note of Wed, 27 Apr 1994 08:18:31 +0200 (MET DST) Brian, >Are you asking whether it is an EID or a locator which is referred to >here ? EID is a way of binding an identifier to the entity it identifies. However, an open issue is the lower bound on the duration of the binding. Section 5.10 in the criteria document leaves this open. Does the binding must be in effect for 2 hours, 2 days, 2 years, etc... ??? I'd like to see this section to be tightened as to specify the lower bound. Yakov. From owner-Big-Internet@munnari.OZ.AU Sat Apr 30 01:35:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23064; Sat, 30 Apr 1994 01:29:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA01032; Sat, 30 Apr 1994 01:07:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA00977; Sat, 30 Apr 1994 00:37:13 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17890; Fri, 29 Apr 1994 23:45:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02567; Fri, 29 Apr 94 09:44:58 -0400 Date: Fri, 29 Apr 94 09:44:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404291344.AA02567@ginger.lcs.mit.edu> To: 0003858921@mcimail.com, big-internet@munnari.OZ.AU, ericf@atc.boeing.com Subject: Re: NATs Cc: jnc@ginger.lcs.mit.edu This was one the ALE list, but really belongs elsewhere... Appologies in advance to those that get multiple copies. I'll stick with Big-I. When Noel first told me about NATs, I got excited. Something that might be easier than application gateways, read firewalls. Err, I never, ever, thought of NAT boxes as security devices, simply as a way of getting 25 pounds of detritus (i.e. the global internet) into a 5 pound bag (32 bits). Network level security is worthless as long as there is application insecurity. And thus there will always be application gateways to institute corporate security policies. Dave Clark gave a great talk at Interop some years back in which he pointed out that the future of the Internet, if we didn't get real security (and I don't have a specific technical mechanism in mind here; I'm talking about a user-type definition), was a series of smaller areas connected by application level gateways. So all of you IETFers, continue the network level security work. That has an important place. But DO NOT DELUDE YOURSELVES! It will not make the internet secure... It has been obvious for a while that restricting access was not a panacea; the Morris worm showed how even the tightest internetwork level security boundary could be breached, if the applications it did allow through (e.g. SMTP) weren't secure. The major bug with application gateways is that it makes the deployment of new applications harder. Security is a real problem. I personally thing we are many years of really hard thinking away from really understanding how to provide reliable, comprehensive but flexible security in the network. Noel From owner-Big-Internet@munnari.OZ.AU Sat Apr 30 07:08:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01213; Sat, 30 Apr 1994 04:24:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA01216; Sat, 30 Apr 1994 04:02:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA01202; Sat, 30 Apr 1994 03:43:10 +1000 Received: from uu.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25313; Sat, 30 Apr 1994 02:33:14 +1000 (from pjnesser@rocket.com) Received: by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA10229 for ; Fri, 29 Apr 94 12:13:00 -0400 Received: from asgaard.rocket.com (asgaard.ARPA) by earth.rocket.com (4.1/3.2.083191-Olin Aerospace Company - Redmond Wa) id AA23664; Fri, 29 Apr 94 07:40:18 PDT Organization: Olin Aerospace Company Telephone: (206)885-5000 Fax: (206)882-5804 Received: by asgaard.rocket.com (4.1/SMI-4.1) id AA15079; Fri, 29 Apr 94 07:40:17 PDT Date: Fri, 29 Apr 94 07:40:17 PDT Message-Id: <9404291440.AA15079@asgaard.rocket.com> To: 0003858921@mcimail.com Cc: ericf@atc.boeing.com, brian@dxcoms.cern.ch, ipv4-ale@ftp.com, big-internet@munnari.OZ.AU, firewalls@greatcircle.com In-Reply-To: <40940429103904/0003858921NA3EM@mcimail.com> Subject: Re: NATs From: "Philip J. Nesser" Sender: pjnesser@rocket.com Us-Snail: 15825 Leary Way NE #306, Redmond WA, 98052 >Date: Fri, 29 Apr 94 05:39 EST >From: "Robert G. Moskowitz" <0003858921@mcimail.com> >When Noel first told me about NATs, I got excited. Something that might be >easier than application gateways, read firewalls. >But I studied the NATs issues. And I listened in on the FIREWALLS list for >a couple of months and came to an important realization: >Network level security is worthless as long as there is application >insecurity. I don't think anyone will argue with you on that issue. >So all of you IETFers, continue the network level security work. That has >an important place. But DO NOT DELUDE YOURSELVES! It will not make the >internet secure anymore than C2 has made UNIX secure. The application >writers need to be indoctrinated also. Perhaps after there is a major >security incident at some big university or company that is all C2 UNIX and >IPng authenticated due to an application level attach, then we will raise >our eyes and tackle the last great frontier, the network applications. I don't think anyone is deluding themselves. Security is an issue at all levels. Just because some application writer doesn't take the time to do it right doesn't invalidate the validity of the work on making another layer as secure as possible. People, especially in the IETF, are taking security concerns much more seriously than ever before. Putting a deadbolt lock on your front door doesn't keep burglers out if you have open windows, but that doesn't mean its a bad idea to have one put in. >Bob ---> Phil From owner-Big-Internet@munnari.OZ.AU Sat Apr 30 16:21:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23364; Sat, 30 Apr 1994 14:55:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA01736; Sat, 30 Apr 1994 14:32:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA01722; Sat, 30 Apr 1994 14:23:55 +1000 Received: from hearn.nic.surfnet.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15411; Sat, 30 Apr 1994 10:50:51 +1000 (from @HEARN.nic.SURFnet.nl:JENNINGS@IRLEARN.UCD.IE) Message-Id: <9404300050.15411@munnari.oz.au> Received: from IRLEARN.UCD.IE by HEARN.nic.SURFnet.nl (IBM VM SMTP V2R2) with BSMTP id 7825; Sat, 30 Apr 94 02:42:06 CET Received: from IRLEARN.UCD.IE (NJE origin JENNINGS@IRLEARN) by IRLEARN.UCD.IE (LMail V1.2a/1.8a) with BSMTP id 1094; Fri, 29 Apr 1994 22:22:46 +0100 Date: Fri, 29 Apr 94 22:13:58 WET From: Dennis Jennings Subject: Engineers Conference in Paris To: end2end-interest-request@isi.edu, rem-conf-request@es.net, ietf@ietf.cnri.reston.va.us, big-internet@munnari.OZ.AU Cc: Christian Huitema , Emmanuelle Gille , Susan Karlson , Mike Millikin Dear Sirs, At Christian Huitema's suggestion, I write to you to request permission to circulate on your e-mail lists the following Call for Papers for the Engineers conference to be held at NetWorld+Interop 94 in files. With many thanks in anticipation, Dennis (Jennings) Chairman, NetWorld+Interop European Programme Committee ----------------------------------------------------------------------- ===================== First Call for Papers ------------------- Engineers Conference at NetWorld+Interop 94 Paris --------------------------------------------------------------------- Interop Company is soliciting technical papers for an Engineers Conference to be held as part of the upcoming NetWorld+Interop 94 Paris event, October 24 - 28, 1994, in Paris. The Engineers Conference, which will be held on Thursday/Friday October 27 - 28, is a two-day focused event offering approaches and solutions to practical systems and software design for networking. All participants in the conference will be able to attend the NetWorld+Interop 94, Paris exhibition, which will run from October 26 - 28. FORMAT The conference will feature the presentation of original papers which will have been selected by a review committee. All accepted papers will be published in Conference Proceedings. Accepted papers must be presented by original authors during the 2-day conference. Conference sessions typically will be 90 minutes long and will present three papers of 20 to 30 minutes duration. The Engineer's Conference will concentrate on engineering design problems in three areas: High Speed Networking, Internetworking, and Multimedia. This conference seeks to bring together research scholars, engineers, and vendors to address pragmatic engineering issues in the field of networking and distributed systems interoperability. It is an excellent forum for Engineers and Researchers to publish papers and to be brought up to date on solutions to today's engineering related problems. Papers are solicited in the following areas: * High Speed Networking: ATM, Fast Ethernet, SDH, FDDI-II, HIPPI, SMDS, Frame Relay, Broadband ISDN, etc. * Internetworking: Addressing Schemes, Routing Protocols, Support of Mobility, Design of Bridges, Routers, and Multiprotocol Brouters, Application Gateways etc. * Multimedia Networking: Multimedia technologies, Multimedia inteoperability, Packet Video and voice, Multimedia Mail and Conferencing, Tele-Presence, Virtual Reality, etc. SUBMISSION GUIDELINES Interested authors are invited to submit an abstract (up to 600 words) clearly describing the problem and the solution offered. All abstracts will be reviewed and authors will be notified for acceptance or rejection of the abstract. Authors of accepted abstracts must submit the paper before the last date. These papers are reviewed by a technical committee for technical merit of the paper before final acceptance. Please note the important dates for abstract and paper submission. All abstracts must contain the authors name, address, telephone number, Fax number and e-mail address (if available). Please send your abstract to: Interop Europe 14 Place Marie-Jeanne Bassot, 92593 Levallois Peret Cedex, Paris, France Attention: Engineer's Conference or e-mail it (in ASCII or PostScript) to: Paris_Engineer@interop.com ** E-mail is preferred. ** =================== = Important Dates = =================== Abstracts due: 3 Jun, 1994 Notification to authors: 24 Jun, 1994 Draft paper due: 22 Jul, 1994 Feedback to authors: 5 Aug, 1994 Camera ready copy due: 9 Sep, 1994 Final camera reader papers must not exceed 10 A4 pages.