From bound@zk3.dec.com Fri Mar 4 22:09:27 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA01126 for ; Fri, 4 Mar 1994 22:15:33 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA22844; Fri, 4 Mar 94 19:10:10 -0800 Received: by xirtlu.zk3.dec.com; id AA12688; Fri, 4 Mar 1994 22:09:33 -0500 Message-Id: <9403050309.AA12688@xirtlu.zk3.dec.com> To: ariel@world.std.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Question on CATNIP Focus prior to Technical Review Date: Fri, 04 Mar 94 22:09:27 -0500 X-Mts: smtp Rob, I am going to take a slot out of my work load to do a CATNIP technical review. Before I start I need to ask a focus question. Its my belief the objective of the IPng area is to select a new IPv4 network layer protocol and associated components that come with a technical strategy to replace IPv4. I do not believe its in the IPng charter to be concerned that an IPng solves the multiprotocol convergence problem. Not that I do not think this is a good thing to do in the industry or at some future point in the IETF. So when I do a technical review of CATNIP do I do it just for IPv4 extended address? For example I am not going to ask you technical questions regarding making TP4 work over IPv4, IPX, or IPv4-extended. It seems I should review for IPng purposes the IPv4-extended address parts and other parts not really associated with a specific protocol (e.g. FCI, NSAP strategy, IPv4 prefix)? I would be glad to give you input offline as an engineer on TP4 over protocols other than OSI and issues I have seen in this space in another forum or over a beverage, and other parts of the paper of course. Just want to use the little time we have to focus on IPng critical points for now. thanks /jim From mankin Fri Mar 4 23:53:53 1994 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA01366; Fri, 4 Mar 1994 23:53:54 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA02988; Fri, 4 Mar 94 23:53:53 EST Date: Fri, 4 Mar 94 23:53:53 EST Message-Id: <9403050453.AA02988@radegond.cmf.nrl.navy.mil> To: ipng Subject: Mail archive Cc: craig@aland.bbn.com, jon@cs.ucl.ac.uk, kasten@ftp.com The mail archive at long last is going into place on hsdndev.harvard.edu, pub/ipng/archive. Raw white papers and your mail reviewing them have been taken out of the archive, and we'll put in a README explaining that and notify folks that this archive is available. There's some great essays among your messages here. Allison From sob@hsdndev.harvard.edu Sat Mar 5 00:09:11 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA01427 for ; Sat, 5 Mar 1994 00:09:38 -0500 Date: Sat, 5 Mar 94 00:09:11 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403050509.AA16575@hsdndev.harvard.edu> To: ipng@picard.cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil Subject: Re: Mail archive Cc: craig@aland.bbn.com, jon@cs.ucl.ac.uk, kasten@ftp.com r actually in pub/ipng/mailing.list Scott :-) From ddc@caraway.lcs.mit.edu Tue Mar 8 22:37:19 1994 Return-Path: ddc@caraway.lcs.mit.edu Received: from caraway.lcs.mit.edu (CARAWAY.LCS.MIT.EDU [18.26.0.170]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA24462 for ; Tue, 8 Mar 1994 22:37:50 -0500 Received: by caraway.lcs.mit.edu id AA24072; Tue, 8 Mar 94 22:37:20 -0500 Message-Id: <9403090337.AA24072@caraway.lcs.mit.edu> To: Frank Kastenholz , Craig Partridge Cc: ipng@cmf.nrl.navy.mil Subject: Comments on criteria document From: David Clark Date: Tue, 08 Mar 94 22:37:19 -0500 Sender: ddc@caraway.lcs.mit.edu X-Mts: smtp Frank and Craig, I have been reading your criteria document, which I like a lot. I think the format is good, and allows you to make points naturally. May I throw four suggestions and a comment into the hopper? Scale: One issue that has come up in discussions with telco types is that we will see, in at least parts of the Internet, large regions built out of very sophisticated subnet technology, like ATM. If ATM won totally it might not be an issue, since maybe we do no need an IP layer, or at least one with smarts. But the worst combination is the one we will get. A smart IP layer, smart enough to deal with all the dumb subnets we have today (LANs, links, etc) which must also run on a smart subnet. The requirement is that the IP functions must be able to work harmoniously with lower layer realizations of the same functions. In particular, IP routing must work with a very large subnet with its one routing. The same for resource management, network management in general, and so on. This is an extention of several of your ideas, 5.1, 5.2 and 5.5. Note particularly that since ATM is a connection-oriented layer which may generate usage-based bills, the ability to provide the correct control information to drive connection management is a key requirement. Performance: there is no criteria for forwarding performance. This is a real lack. I have an aggresive target, which I have mentioned to both of you. Criterion A state of the art router should be able to process packets at the same rate as a state of the art ATM switch running at the same line rate. Discussion Today routers are evaluated by their ability to process a stream of 64 byte packets. 64 and 48 are not that different. If an ATM VC can deliver packets to a router faster than the router can process them, people will not use that approach. The Internet layer of the future must be able to "keep up with" any subnet layer it runs over. So if we are going to have 155 mb/s links, then we better process 64 byte packets at that rate, or else get Bradner to change his testing criteria. I note some details: 64 bytes is actually two cells, so half the rate might do; and switches are multi-port and routers will more and more be two port, so the comparision is not so demanding. But lets not argue about a factor of two. Lets get the basic objective out there. To live long and prosper, one must keep up. page 21; 5.13. The wording is perhaps problematical. The phrase "guaranteed flows" means, to some folks" a lot more that the general idea of binding packets to traffic classes which have some specific QoS. It means specifically committeed bandwidth. This is only one of the QoS we will probably end up supporting. So I would rather say: Criterion: The protocol must support explicit and implicit QoS functionality. If you don't like those words (and I do not find them really wonderful) pick some others, but imply general QoS, and not just guaranteeed service. In the discussion section, you might give another example of QoS which is not multi-media, which is enforced fairness of best-effort flows. The underlying criterion, I think, is that the protocol must permit packets inside a router to be associated with a service class. That is the real requirement, but may be a little low-level for the reader. But actually, as I look at what I am writing, I think this is the point you should hit. All sort of classes, with all sorts of behavior we have not thought of yet, can be invented in the future. But uless there is a standard way of mapping packets to classes, none of this will work. Coming back to effeciency, I would note in the document that my requirement for effeciency has a real impact on this criterion, as well as 5.12 Extensibility. The only reason that options did not make it as a extension mechanism is the cost of processing them. We will need something like options, and they better be easy to process. Finally, a small point. I think the working group is being silly if they do not put a requirement for accounting in the document. We will get our clock cleaned if we do not mention it. But if you want to leave it out, you must add it to the non-goal section. Finally, a general comment. This document is not very aggressive. I look at it and ask what the criteria exclude, and it is not crisp. I like "in your face" criteria, criteria that make people wince. They have to be right, but the crisper and more concrete they are, the more punch they have. In that light, a forwarding performance criterion is mandatory. Lots of things work if you don't ask how long they take. Here is a test question to ask yourselves. The cable TV people have the general idea that they could not possibly use an IP layer as part of digital video delivery to the home. They don't really know why, they just assume that it is foreign, suspect, and must add cost to the system. So can we write down criteria that have the final consequence that IP gets used for the next generation of cable TV delivery? If not, why not. While I am on this performance kick, let me note that high processing rates are not the only issue. For low speed links, header compression is key. So a CRITERION is that the header should be organized to permit smart compression. Again, I note that in some circles it is a given that IP will not be useful over mobile links. Ask: what criterion would dispell this myth. Criterion 5.14 does not call out any specific functional issues that are implied by mobility. I think those specifics are needed. The document as I read it is just a little motherhood. One must avoid mechanistic criteria (such as that you must have a flow spec). That is an answer to a criteria, not a criteria. But it is important to hit real issues. I am not sure what you might want to do with this sort of flame. I am really torn, since the aggressive schedule that Scott and Allision have requires that the version of the requirements document we send for review go out BEFORE the IETF. If you think that points like this need public debate, then I think the document will not be ready for review until after the IETF. It would be great fun to come to a working group and start a debate on performance. But that does not address the key issue of getting a document that is good enough to send out to review. We only get to send it out once. Dave From sob@hsdndev.harvard.edu Tue Mar 8 23:14:12 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA24589 for ; Tue, 8 Mar 1994 23:14:24 -0500 Date: Tue, 8 Mar 94 23:14:12 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403090414.AA00315@hsdndev.harvard.edu> To: ddc@lcs.mit.edu, kasten@ftp.com Subject: Re: Comments on criteria document Cc: ipng@cmf.nrl.navy.mil ps - > or else get Bradner to change his testing fyi - an ATM tester (right now T3 only but "soon" OC3) should be installed in the Harvard lab on Monday. Scott From kasten@mailserv-D.ftp.com Wed Mar 9 09:12:21 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA26673 for ; Wed, 9 Mar 1994 09:13:28 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 9 Mar 1994 09:12:53 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA13319; Wed, 9 Mar 94 09:12:21 EST Date: Wed, 9 Mar 94 09:12:21 EST Message-Id: <9403091412.AA13319@mailserv-D.ftp.com> To: ddc@lcs.mit.edu Subject: Re: Comments on criteria document From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com, ipng@cmf.nrl.navy.mil Content-Length: 8647 > Frank and Craig, > > I have been reading your criteria document, which I like a lot. I > think the format is good, and allows you to make points naturally. May Thank you very much. > I throw four suggestions and a comment into the hopper? Please do... > The requirement is that the IP functions must be able to > work harmoniously with lower layer realizations of the same functions. Absolutely. > In particular, IP routing must work with a very large subnet with its > one routing. The same for resource management, network management in > general, and so on. This is an extention of several of your ideas, > 5.1, 5.2 and 5.5. To me, "5.1 Scale", and "5.2 Topological Flexibility" are routing and addressing issues and I always have considered them as such. I think that this point falls most naturally under "5.5 Media" as you bring up things like connection-oriented lower-layers, resource management, network management, etc... I'll add this to 5.5 > Performance: there is no criteria for forwarding performance. This is > a real lack. I always thought so but I could not come up with a satisfactory criterion. Saying that IPng must operate at 'x bits/bytes/packets per second' did not seem like the right thing. > Criterion > A state of the art router should be able to process packets at the > same rate as a state of the art ATM switch running at the same line > rate. I'd suggest that it be a little more general -- I'd require that a state of the art ***Commercial Grade**** router be able to process packets at the same rate as the common 'high-speed' network media at the time. For today, that would be FDDI @100Mb, in a couple of years, that may well be ATM @ 155Mb. Coupling specifically to ATM might not be a good thing. ATM might flop, as far as we are concerned. Also, I've been talking with Frank Solensky recently and his optimistic projections on address space exhaustion seem to imply that CIDR is buying us a lot of time -- perhaps to the end of the millenium. If this is right (big IF there) then we might be able to put off deploying IPng for a long time and there might then be a network technology that makes ATM look like cars on the Southeast Expressway during rush hour... I mention commercial grade since I would like these speeds to be available to me in the commercial world. One could call some research project that is being done in a hidden corner of MIT LCS a "state of the art router" but I can't go to Proteon or Wellfleet or Cisco and buy it... If I put in 155Mb ATM then I'd like to be able to go to the local router store and buy a router that will keep up. It would also be nice if we could also require that IPng be routable at the highest media bandwidths that are available, even if it requires that special router that some overly-bright researcher is building in a dark corner of MIT or BBN... > The underlying criterion, I think, is that the protocol must permit > packets inside a router to be associated with a service class. That is "The protocol must allow the network (routers, intelligent media, etc) to associate packets with particular service classes." Then mention flows, QOS, implicit/explicit setup, etc etc, in the disucssion. Good? > Finally, a small point. I think the working group is being silly if > they do not put a requirement for accounting in the document. We will > get our clock cleaned if we do not mention it. But if you want to > leave it out, you must add it to the non-goal section. There was such a requirement a long time ago. My opinion is that accounting is not a function of the IP layer, itself. I am open to arguments as to why accounting is a function of the IPNG protocol, and not built on top of it... > Finally, a general comment. This document is not very aggressive. I Some history here. We started this after the work on the various contenders began. It then got subsumed into the political IPng process. This made it difficult to get anything into the document that any of the contenders felt would unfairly exclude their protocol.... Now as we try to bring things back away from this state, there are still remnants of history.... Grrrrr. > Here is a test question to ask yourselves. The cable TV people have > the general idea that they could not possibly use an IP layer as part > of digital video delivery to the home. They don't really know why, > they just assume that it is foreign, suspect, and must add cost to the > system. So can we write down criteria that have the final consequence > that IP gets used for the next generation of cable TV delivery? If > not, why not. My thoughts were that this is the next big revision of the list. We'd take the white papers and try to divine out of them what they really want and then roll those requirements into the document. For example, you mention cable TV. I read their white paper and once I started thinking about their numbers, I started to get a bit ill.... For instance, it looks like they want OC-3 to the home (possibly an OC-3 channel to EACH home) which would make your performance requirement too small. They estimate that there are ~10e8 homes in the US (and ~10e10 homes in the world) and they think that 10e12 nodes, which is our requirement, is ok. But I think that the home will become a network, and not a node, so now we need 10e10 networks in the world, not counting backbones, and service providers and cars and planes and boats and trains and offices and.... Is this starting to get "in your face" enough? :-) > Again, I note that in some circles it is a > given that IP will not be useful over mobile links. Ask: what > criterion would dispell this myth. Criterion 5.14 does not call out > any specific functional issues that are implied by mobility. I think > those specifics are needed. The time frame for 5.14 should give you a clue :-) -- I am not very up on the needs, etc, of mobility, and, I gather, neither is Craig. We have the statement, maybe someone who does know what mobility really needs will come along... > The document as I read it is just a little motherhood. One must avoid > mechanistic criteria (such as that you must have a flow spec). That is > an answer to a criteria, not a criteria. But it is important to hit > real issues. Yup. We were torn between several different ways to do the document. We did not want to dictate solutions -- rather we wished to identify the issues that needed to be solved. We also wanted to keep the requirements relatively loose in order to allow bright people to have new and interesting ideas -- if we got too specific then we might start ruling out some of those bright ideas. On the other hand, if the requirements were too vague then they become nothing but motherhood. Given that, please feel free to point out anyplace that looks too vague. For example, requiring that routers specifically meet ATM speeds, to me, was too specific in that it did not allow for changes in underlying network technology, or changes in the political landscape. (a bit out of order.....) > Coming back to effeciency, I would note in the document that my > requirement for effeciency has a real impact on this criterion, as > well as 5.12 Extensibility. The only reason that options did not make > it as a extension mechanism is the cost of processing them. We will > need something like options, and they better be easy to process. This is why we didn't want to demand options -- it was a solution, it bounded the space of possible solutions, etc etc. One way to meet this sort of thing would be a version number in the protocol header (as the header needs new stuff, give it new versions....) or perhaps someone might want to define payload packets and control packets, where the control packets go on ahead of the data, get processed at slower rates, and 'prepare' the routers for the data packets that are coming. > I am not sure what you might want to do with this sort of flame. I am Right now, the document is not public. I can turn it around and get your comments (and those from several other IPNg directorati) into the draft and have it available by the end of today (modulo the time it takes for Craig to get a copy and review it). Then, it would be available for the IPng people again. I'd like to put it up in as an ID by the middle of next week -- the IETF meeting is a bit over 2 weeks away... How does this all sound? Sorry for the length of this. I guess I've been talking with Noel too much -- I'm starting to write Noelgrams.... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From lkeiper@IETF.CNRI.Reston.VA.US Wed Mar 9 11:19:31 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA00721 for ; Wed, 9 Mar 1994 11:19:31 -0500 Date: Wed, 9 Mar 1994 11:19:31 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa06874; 9 Mar 94 11:18 EST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 2 (High) To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference, March 14, 1994 Cc: lkeiper@CNRI.Reston.VA.US Message-ID: <9403091118.aa06874@IETF.CNRI.Reston.VA.US> ANNOUNCEMENT**** The names marked with an asterisk are those who have confirmed participation for the IPng teleconference scheduled for March 14, 1994 at 11:30 - 1:30 EST. Please send your confirmation of participation and any corrections or changes to lkeiper@cnri.reston.va.us. ASAP! Many thanks! J. Allard 206-936-9031 Steve Bellovin 908-582-5886 Jim Bound 603-881-0400 Scott Bradner 617-495-3864 Ross Callon 508-436-3936 Brian Carpenter +41 22 767 4967 Dave Clark 617-253-6003 *Steve Coya 703-620-8990* Jon Crowcroft +44 71 380 7296 John Curran 617-873-4398 Steve Deering 415-812-4839 Dino Farinacci 415-688-4696 Eric Fleischman 206-957-5334 Paul Francis +81 3 3928 0408 Daniel Karrenberg +31 20 592 5065 Frank Kastenholz 508-685-4000 Mark Knopper 313-741-5445 Allison Mankin 202-404-7030 Greg Minshall 510-975-4507 Paul Mockapetris 310-822-1511 Craig Partridge 415-326-4541 Rob Ullmann 617-693-1315 Lixia Zhang 415-812-4415 If you need to be added to the teleconference call in progress, please call 1-800-232-1234 or for the international participants, 516-424-3151. The call can be referenced by the confirmation number -ER96987 in the orginators name, Steve Coya. Thanks Lois From craig@aland.bbn.com Wed Mar 9 08:37:13 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01129 for ; Wed, 9 Mar 1994 11:40:11 -0500 Received: from port17.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA02302 for ipng@cmf.nrl.navy.mil; Wed, 9 Mar 94 11:38:39 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA10021; Wed, 9 Mar 1994 08:37:14 -0800 Message-Id: <199403091637.IAA10021@aland.bbn.com> To: David Clark Cc: Frank Kastenholz , Craig Partridge , ipng@cmf.nrl.navy.mil Subject: Re: Comments on criteria document In-Reply-To: Your message of Tue, 08 Mar 94 22:37:19 -0500. <9403090337.AA24072@caraway.lcs.mit.edu> From: Craig Partridge Date: Wed, 09 Mar 94 08:37:13 -0800 Sender: craig@aland.bbn.com Dave: I think Frank's Noelgram pretty completely summarizes the tradeoffs we made in writing the document, so I'll try to be brief. It is very important to keep in mind that Frank and I are trying to nudge a lot of IETF folks a little bit into the future. I know I've talked with many people about IPng needing to be forward looking, but one of the stunning events at the BOF last year was the firm opinion of the majority of folks in the BOF that they'd be willing to throw out an IPng and replace it with another one in only a few years. Personally, I think they're confused, but that's what they said. Also, it seems to me that a lot of the concerns, about mobility, about ability to map onto different new media (like ATM), are about heterogeneity -- the ability of IPng to run over everything. And yes, we need a performance goal, but like Frank, I'd love to find one that doesn't make ATM the stalking horse. (Jon Turner was telling me a few months ago about struggles to get his ATM hardware running at 622 Mb/s. He'll make it work, but the point is that if we tie ourselves to ATM performance, I worry we'll be inviting folks to tie ourselves to ATM's limitations too). Craig From mankin Wed Mar 9 11:55:38 1994 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01551 for ; Wed, 9 Mar 1994 11:55:40 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA16915; Wed, 9 Mar 94 11:55:38 EST Date: Wed, 9 Mar 94 11:55:38 EST Message-Id: <9403091655.AA16915@radegond.cmf.nrl.navy.mil> To: ipng Subject: IPNG Requirements Discussion I've added Jon Crowcroft, Frank Kastenholtz and Craig Partridge to the IPng mailing list to facilitate our work on the requirements document. Here's the current mailing list: ariel@world.std.com bound@zk3.dec.com brian@dxcern.cern.ch callon@wellfleet.com craig@aland.bbn.com daniel@ripe.net ddc@lcs.mit.edu deering@parc.xerox.com dino@cisco.com ericf@atc.boeing.com francis@cactus.ntt.jp jallard@microsoft.com jcurran@nic.near.net jon@cs.ucl.ac.uk kasten@ftp.com lixia@parc.xerox.com mankin@cmf.nrl.navy.mil mak@merit.edu minshall@novell.com pvm@isi.edu scoya@cnri.reston.va.us smb@research.att.com sob@harvard.edu Allison From bound@zk3.dec.com Wed Mar 9 12:14:34 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA01847 for ; Wed, 9 Mar 1994 12:16:43 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA15139; Wed, 9 Mar 94 09:14:01 -0800 Received: by xirtlu.zk3.dec.com; id AA04050; Wed, 9 Mar 1994 12:14:39 -0500 Message-Id: <9403091714.AA04050@xirtlu.zk3.dec.com> To: ipng@picard.cmf.nrl.navy.mil Subject: Re: IPNG Requirements Discussion In-Reply-To: Your message of "Wed, 09 Mar 94 11:55:38 EST." <9403091655.AA16915@radegond.cmf.nrl.navy.mil> Date: Wed, 09 Mar 94 12:14:34 -0500 X-Mts: smtp I want to fully support Craig's statement of making the requirements forward thinking. /jim From bound@zk3.dec.com Wed Mar 9 17:47:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA05481 for ; Wed, 9 Mar 1994 17:54:56 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA01734; Wed, 9 Mar 94 14:47:17 -0800 Received: by xirtlu.zk3.dec.com; id AA12086; Wed, 9 Mar 1994 17:47:54 -0500 Message-Id: <9403092247.AA12086@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: SIPP WP Transition Excerpt Date: Wed, 09 Mar 94 17:47:47 -0500 X-Mts: smtp As I did with the Cablelabs WP I thought taking the excerpt from the SIPP WP on Transition was useful too. Clearly how this gets implemented is what needs to be technically reviewed. But from this excerpt we have an idea about the underlying assumptions and strategy. /jim - Direct interoperability between IPv4 and SIPP Hosts. - Allow user population to adopt SIPP in a highly diffused fashion. - Incremental Transition with few or no critical dependencies. - Permit network users to upgrade their hosts and network operators to deploy SIPP in routers, with very little coordination between the two. - Ensure that SIPP hosts can interoperate with IPv4 hosts anywhere in the Internet up until the time when IPv4 addresses run out. - Five key Elements of the Transition: o A 64bit address plan that encompasses the existing 32bit IPv4 addressing plan. o A mechanism for encapsulating SIPP traffic within IPv4 packets so the IPv4 infrastructure can be leveraged early in the transition. o Algorithm in SIPP hosts that allow them to directly interoperate with IPv4 hosts on the same subnet and elsewhere in the Internet. o A mechanism for translating IPv4 addresses to SIPP addresses to allow SIPP-only hosts to communicate with IPv4-only hosts communicating over a SIPP backbone. o An optional mechanism for mapping IPv4 addresses to SIPP addresses to allow improved scaling of IPv4 routing. From bound@zk3.dec.com Thu Mar 10 12:50:00 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA09810 for ; Thu, 10 Mar 1994 12:52:20 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA14516; Thu, 10 Mar 94 09:49:30 -0800 Received: by xirtlu.zk3.dec.com; id AA29876; Thu, 10 Mar 1994 12:50:06 -0500 Message-Id: <9403101750.AA29876@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IETF IPNG meetings Date: Thu, 10 Mar 94 12:50:00 -0500 X-Mts: smtp Scott and Allison and Steve C., Good job on scheduling we can go to all the IPNG meetings without overlap. thanks /jim From sob@hsdndev.harvard.edu Thu Mar 10 14:37:12 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA10458 for ; Thu, 10 Mar 1994 14:37:37 -0500 Date: Thu, 10 Mar 94 14:37:12 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403101937.AA10997@hsdndev.harvard.edu> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: IETF IPNG meetings Cc: mwalnut@CNRI.Reston.VA.US, scoya@CNRI.Reston.VA.US > Good job on scheduling we can go to all the IPNG meetings without overlap actually, a lot of the work was done by Megan the wonder woman From mwalnut@CNRI.Reston.VA.US Thu Mar 10 14:51:35 1994 Return-Path: mwalnut@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA10648 for ; Thu, 10 Mar 1994 15:03:56 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11563; 10 Mar 94 14:51 EST To: Scott Bradner cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil, mwalnut@CNRI.Reston.VA.US, scoya@CNRI.Reston.VA.US Subject: Re: IETF IPNG meetings In-reply-to: Your message of "Thu, 10 Mar 94 14:37:12 EST." <9403101937.AA10997@hsdndev.harvard.edu> Date: Thu, 10 Mar 94 14:51:35 -0500 From: Megan Davies Walnut Message-ID: <9403101451.aa11563@IETF.CNRI.Reston.VA.US> Gosh that's nice. Thank you. and you're welcome. Megan >> > Good job on scheduling we can go to all the IPNG meetings without >> overlap >> >> actually, a lot of the work was done by Megan the wonder woman >> From scoya@CNRI.Reston.VA.US Thu Mar 10 15:40:03 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA11041 for ; Thu, 10 Mar 1994 15:41:11 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12522; 10 Mar 94 15:40 EST To: ipng@cmf.nrl.navy.mil Subject: Draft agenda for March 14 Teleconference Date: Thu, 10 Mar 94 15:40:03 -0500 From: Steve Coya Message-ID: <9403101540.aa12522@IETF.CNRI.Reston.VA.US> DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT IPNG Directorate Teleconfence Agenda for March 14, 1994 1. Administrivia o Roll Call o Agenda bashing o Approval of minutes January 17 (?) January 25 (mbone) February 14 2. Working group actions o Requirements WG charter 3. Requirements Discussion 4. Roundtable From faradaychong@hgrncc.enet.dec.com Thu Mar 10 19:21:33 1994 Return-Path: faradaychong@hgrncc.enet.dec.com Received: from enet-gw.pa.dec.com (enet-gw.pa.dec.com [16.1.240.15]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA13281 for ; Thu, 10 Mar 1994 22:22:53 -0500 From: faradaychong@hgrncc.enet.dec.com Received: by enet-gw.pa.dec.com (5.65/13Jan94) id AA24953; Thu, 10 Mar 94 19:20:48 -0800 Message-Id: <9403110320.AA24953@enet-gw.pa.dec.com> Received: from hgrncc.enet; by decwrl.enet; Thu, 10 Mar 94 19:21:33 PST Date: Thu, 10 Mar 94 19:21:33 PST To: ipng-request@cmf.nrl.navy.mil Cc: faradaychong@hgrncc.enet.dec.com Apparently-To: ipng-request@cmf.nrl.navy.mil Subject: subscribe subscribe From bound@zk3.dec.com Sun Mar 13 15:48:44 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA08586 for ; Sun, 13 Mar 1994 15:52:43 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA21959; Sun, 13 Mar 94 12:48:12 -0800 Received: by xirtlu.zk3.dec.com; id AA06081; Sun, 13 Mar 1994 15:48:50 -0500 Message-Id: <9403132048.AA06081@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: CATNIP Focus Resend Date: Sun, 13 Mar 94 15:48:44 -0500 X-Mts: smtp Rob, Still have not heard from you and we both are having hard time connecting off line. Still need focus. Also Greg Minshall's input to you on CATNIP on the Directorate and CATNIP mailing list are some of the same questions I have seen from colleagues developing IPng solutions too. Did you respond to Greg offline? If so could you send to the Directorate too as many of the questions and comments are similiar to what I am hearing internally and maybe others are too. The other question is has anyone implemented CATNIP to begin testing of its parts operationally? I know doing TUBA and SIPP is a handful. In that sense another comment is maybe some of your ideas belong in the IETF Transport WG as opposed to IPng? p.s. I have been ice fishing three nights a week so not at home often right now after work. Trout and Pickerel. thanks /jim ------- Forwarded Message Return-Path: bound Message-Id: <9403050309.AA12688@xirtlu.zk3.dec.com> To: ariel@world.std.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Question on CATNIP Focus prior to Technical Review Date: Fri, 04 Mar 94 22:09:27 -0500 From: bound X-Mts: smtp Rob, I am going to take a slot out of my work load to do a CATNIP technical review. Before I start I need to ask a focus question. Its my belief the objective of the IPng area is to select a new IPv4 network layer protocol and associated components that come with a technical strategy to replace IPv4. I do not believe its in the IPng charter to be concerned that an IPng solves the multiprotocol convergence problem. Not that I do not think this is a good thing to do in the industry or at some future point in the IETF. So when I do a technical review of CATNIP do I do it just for IPv4 extended address? For example I am not going to ask you technical questions regarding making TP4 work over IPv4, IPX, or IPv4-extended. It seems I should review for IPng purposes the IPv4-extended address parts and other parts not really associated with a specific protocol (e.g. FCI, NSAP strategy, IPv4 prefix)? I would be glad to give you input offline as an engineer on TP4 over protocols other than OSI and issues I have seen in this space in another forum or over a beverage, and other parts of the paper of course. Just want to use the little time we have to focus on IPng critical points for now. thanks /jim ------- End of Forwarded Message From lkeiper@IETF.CNRI.Reston.VA.US Mon Mar 14 10:06:02 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA11521 for ; Mon, 14 Mar 1994 10:06:02 -0500 Date: Mon, 14 Mar 1994 10:06:02 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa03785; 14 Mar 94 10:00 EST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference Cc: lkeiper@CNRI.Reston.VA.US Message-ID: <9403141000.aa03785@IETF.CNRI.Reston.VA.US> FINAL******** The names marked with an asterisk are those who have confirmed participation for the IPng teleconference sheduled for Monday, March 14, 1994 11:30 - 1:30pm EST. Please contact me with any changes @lkeiper.cnri.reston.va.us. If you plan to participate and have not yet sent your RSVP, please do so ASAP. Many Thanks. *Scott Bradner 617-495-3864* ?Steve Bellovin 908-582-5886? *Jim Bound 603-465-3130* *Ross Callon 508-436-3936* *Brian Carpenter +41 227 674 967* ?Dave Clark 617-253-6003? *Steve Coya 703-620-8990* ?Jon Crowcroft +44 713 807 296? *John Curran 617-873-4398* -Steve Deering REGRETS *Dino Farinacci 408-226-6870* *Eric Fleischman 206-957-5334* ?Paul Frances +81 339 280 408? ?Dan Karrenberg +31 205 925 065? ?Frank Kastenholtz 508-685-4000? ?Mark Knopper 313-741-5445? ?Alison Mankin 202-404-7030? ?Greg Minshall 510-975-4507? *Paul Mockapetris 703-620-8990* ?Frank Kastenholtz 508-685-4000? ?Craig Partridge 415-326-4541? *Rob Ullmann 617-693-1315* Lixia Zhang 415-812-4415 If you need to be added to the call in progress, Please call 1-800-232-1234 or for international particpants, 516-424-3151. The call can be referenced by the confirmation number ER96987 in the orginators name, Steve Coya. Many thanks, Lois From bound@zk3.dec.com Mon Mar 14 22:08:17 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA16271 for ; Mon, 14 Mar 1994 22:10:54 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA09965; Mon, 14 Mar 94 19:07:45 -0800 Received: by xirtlu.zk3.dec.com; id AA08444; Mon, 14 Mar 1994 22:08:23 -0500 Message-Id: <9403150308.AA08444@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IPng Reqs Docs -- Can't find them ... Date: Mon, 14 Mar 94 22:08:17 -0500 X-Mts: smtp Got to research.ftp.com. cd /pub ... then no ip7 dir but found ip7reqs dir. cd to ip7reqs .. no files Did they move ?? && ^[.*?]. Was looking for the March 10th version fyi.. thanks /jim From bound@zk3.dec.com Tue Mar 15 00:36:13 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA16712 for ; Tue, 15 Mar 1994 00:42:41 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA17982; Mon, 14 Mar 94 21:35:42 -0800 Received: by xirtlu.zk3.dec.com; id AA10591; Tue, 15 Mar 1994 00:36:19 -0500 Message-Id: <9403150536.AA10591@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IPng Requirements : More input on Requirements Date: Tue, 15 Mar 94 00:36:13 -0500 X-Mts: smtp Thanks to a Directorate member I now have the March 10th version. The doc looks even better. Good Job ... I like the log files ? Did you use rcs? ???? Change the name of the doc to "Technical Requirements for Choosing ...etc." Let the title make it very clear these are technical requirements being addressed. Also could say "Technology ..." to permit marketing statements as needed in the requirements. What about actual implementations. Running Code. Should this not also be a requirement. How much and levels of required integration with the transition plan should be demonstrated. I would like to see the same performance requirements concerns for hosts that were projected for routers stated. Many Host vendors can saturate an FDDI 100MB board with TCP and UDP today. An IPng proposals network layer components should not reduce this type of performance gain. Depending on what approach or extra baggage a specific protocol brings to the party, it could adversely affect the overall network performance of a Host. This will be very obvious in some instances depending on how the transition plan is stated. One nice thing about the TCP/IP suite is that we all use the same commands for the same function. If I am on a PC, UNIX, VMS, or MVS I say FTP, TELNET, RCP, etc. During IPng transition I have fears of Proposal X providing two commands for TELNET, etc. Not Good. Worse yet two code paths in the kernel because of the transition plan. In the Transition section. Add "Application binary compatibility for existing IPv4 applications". IPv4 apps should not have to be altered or recompiled on a host because IPng is installed on a host. Lets not forget about the ISVs they are very important and a customer for any host vendor. Configuration strategy and interfaces for transition should be well defined in any transition plan (they are not now in any IPng). We need this especially for IPv4/IPng tunnels which will exist in any IPng proposal, as one example. Now my favorite subject Explicit Non-Goals >5.17. Explicit Non-Goals How about "Functionality not Required" This is more direct cause thats what it is. What these categories may be are the gating factors of selection given all proposals are equal in the above requirements. Or added value from an IPng proposal. Maybe the section needs more clarity. In some cases its a double negative semantically from a Gestalt view of this section. This is a good idea but its a non-goal. I like to use double negatives in code and in explaining things or to reach a logic value of True. But they can also burn you. If the audience or the branch to register interprets them to be False. >This section contains some explicit non-goals of IP:ng. A >non-goal does not mean that a protocol MUST NOT do something. >It means that the authors do not believe that it matters >whether the non-goal is in the protocol or not. If a protocol >includes one of the non-goals; well, that's cool. If it >doesn't; that's cool too. A non-goal might be necessary in >order to meet some other criterion, however this is irrelevant >to including the non-goal merely for its own sake. Well I don't think thats cool. If removing the checksum or saying no more fragmentation at routers (except for IPv4 compatibility) increases performance (which it does) then if a proposal is not going to do that I don't think that is cool at all. In fact to use an old sixties term its uncool. >Fragmentation > The technology exists for path MTU discovery. > Presumably, IP:ng will continue to provide this > technology. Therefore, we believe that IP:ng > Fragmentation and Reassembly, as provided in IPv4, is not > necessary. OK this is what I mean by the double negative in the Gestalt perspective. Its OK to change the way IPv4 frag/reass has done it but its a non-goal. Well if everyone does it I think its important how they propose doing it. I know NFS and Transaction Processing Asynch software over UDP will care a lot. >IPv4/IP:ng Communication > It is not necessary that IPv4-only and IP:ng-only hosts > be able to communicate directly with each other. Well it is necessary for some systems and consensus seems to be split on this one. See Mbone minutes that should come out this week as they have been ratified by the Directorate. Also talk to any Embedded systems vendor. One stack is real nice for performance. I know there is talk of a chip which I wont mention can support two stacks well. Thats not the point and most embedded systems are not implemented on chip they are implemented with honest-to-good old fashion network subsystem software and two stacks cost more than one on these minimal host implementations. Not only that but getting back to host performance. Each proposals ability to perform well within a real-time operating system is directly related to its ability to process data structures and recursive code routines efficiently on a host. How the network datagram is structured and its ability to be stored and fetched efficiently not only for packetization but for memory storage at the interface_network structure as data enters the network subsystem will also affect performance. Yes this is a fine grained host detail discussion of one IPng over the other but we need to do that if this is going to exist for 20 years. The comments in the previous section on the way IP options are handled today is just the easy part of determining protocol performance for a host. Or is it possible when considering that problem were the authors only thinking of routers and not hosts? This is important and I would like to digress for a minute. A Jr engineer working hosts once said to me. Jim check out how fast I can copy across the network with the new chip. I asked them to tell me what order of magnitude of a gain in performance they had seen. They said about 20%. I said you did not see network performance increase you saw CPU performance increase. The MIPs had increased by 70% but the network software had not. The point is that IPng will affect host network software performance in ways that are inherent from the structure of a particular network datagram and other components proposed. >IP Checksum > There has been discussion indicating that the IP Checksum > does not provide enough error protection to warrant its > performance impact. The argument states that there is > almost always a stronger datalink level CRC, and that > end-to-end protection is provided by the TCP checksum. > Therefore we believe that an IP:ng checksum is not > required per-se. Ok here is the double-negative again. Basically checksum is bad. So if someone removes the checksum which is good, its not good cause its a non-goal. So if its good why is it not a good goal (now there is a double negative). >Firewalls > Some have requested that IP:ng include support for > firewalls. The authors believe that firewalls are one > particular solution to the problem of security and, as > such, do not consider that support for firewalls is a > valid requirement for IP:ng. Well I know Digital, Sun, and Cisco have implemented some pretty good firewalls and they help sell into accounts accessing the Internet. If a proposal does something to prevent or disrupt the use of the software to support Firewalls so it is not as easy or more costly via performance to implement I care a lot. We should be able to ding someone on this as its taking $$$$ away from vendors who build firewalls. I am saying if something technically prohibits a vendor from building a firewall at a reasonable cost then thats not good. >Network Management > Network Management properly is a task to be carried out > by additional protocols and standards, such as SNMP and > its MIBs. We believe that network management, per se, is > not an attribute of the IP:ng protocol. Furthermore, > network management is viewed as a support, or service, > function. Network management should be developed to fit > IP:ng and not the other way round. This gets to the fulcrum of my issue with this section. IPng is not like adding DHCP or RFC 1122/1123 (which I was and am involved with to put in products) to the TCP/IP suite. IPng changes a fundamental building block within the TCP/IP protocol suite. This change will affect all dependencies on that building block and in the case of host network kernel code the data structures and access points to those data structures will be affected. The strategy for the requirements should not change the network layer and let everyone figure it out that depends on the existing paradigm. In addition different proposals will affect the dependencies in different ways. These differences can affect the performance of an application such as Network Management. I agree that IPng should be developed and then the services will have to fit that model. But if one proposals makes it easier to maintain the performance and functionality of the existing applications and services then that is a plus for that proposal. Yes this will require us to go to a very deep level of detail just like determining the best algorithms for scalability or routing performance. But the difference is that this is the hosts complex set of variables we are stating as an Explicit-NON goal. Not good and we must focus as much on the host concerns as we do the router concerns regarding affect by IPng. >Accounting > We believe that accounting, like network management, must > be designed to fit the IP:ng protocol, and not the other > way round. Therefore, accounting, in and of itself, is > not a requirement of IP:ng. However, there are some > facets of the protocol that have been specified to make > accounting easier, such as non-repudiation of origin > under security, and the unique naming requirement for I have never figured out how this gets done but nothing in a proposal should prevent accounting. I don't know who has the expertise to determine this but we should find someone and ask them. Consensus on the Directorate is that we need accounting of some kind. As the Internet gains more commercial use this will be a forward requirement. We don't want to be stuck emulating what should have been put in a network layer datagram on the hosts or routers when we have to do accounting. /jim From bound@zk3.dec.com Tue Mar 15 08:26:45 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA00511 for ; Tue, 15 Mar 1994 09:05:13 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA15014; Tue, 15 Mar 94 05:26:17 -0800 Received: by xirtlu.zk3.dec.com; id AA22332; Tue, 15 Mar 1994 08:26:52 -0500 Message-Id: <9403151326.AA22332@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IPng Requirements : Autoconfiguratin Forward Thinking Date: Tue, 15 Mar 94 08:26:45 -0500 X-Mts: smtp It appears that Autoconfiguration is a function that must be provided with any IPng solution. It could also be one of the carrots to move TCP/IP users to IPng. Right now all IPng proposals say nothing of Autoregistration once a node has been autoconfigured (auto-assigned an address) with an IPng network layer address. It is assumed but not stated that these addresses will have to update the BIND DNS manually or possibly by uploading a static configuration file in the best case. In the future it would be very beneficial to have the node autoregister their autoconfigured address with BIND DNS. The technical problem facing implementations is the dynamic binding across the network of the autoconfigured network address to the BIND DNS server (which should not be accessed via a relay agent). Another technical problem is the install vs update of a nodes autoconfigured address as a client of the autoconfiguration address server database (BIND DNS). I will not go into these in depth but essentially their are database constraints regarding updating tuples vs installing new tuples and where that operation overlaps logically. An IPng's autoconfiguration technical proposed implementation should not prevent autoregistration from a node to the BIND DNS server in the future. In addition an IPng's proposed autoconfiguration proposal should state the affect it will have and how it will convey updates and installs to the BIND DNS server for a specific domain. /jim From smb@research.att.com Tue Mar 15 09:19:09 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA00628 for ; Tue, 15 Mar 1994 09:21:43 -0500 From: smb@research.att.com Message-Id: <199403151421.JAA00628@picard.cmf.nrl.navy.mil> Received: by gryphon; Tue Mar 15 09:19:10 EST 1994 To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking Date: Tue, 15 Mar 94 09:19:09 EST Yet another technical problem is the need to authenticate any DNS updates. And that implies the need for some sort of cryptographic secret on the new machine. How that can be reconciled with autoconfiguration is an interesting puzzle. From J.Crowcroft@cs.ucl.ac.uk Tue Mar 15 09:34:44 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA00705 for ; Tue, 15 Mar 1994 09:36:11 -0500 Message-Id: <199403151436.JAA00705@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Mar 1994 09:34:50 +0000 To: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : More input on Requirements Date: Tue, 15 Mar 94 09:34:44 +0000 From: Jon Crowcroft 1. on flows/resource: I am still concerend over flow id's, and datagrams. the technology for soft state flows is not entirely proven yet(pace rsvp, CSZ etc), and in fact the only large scale demonstrators of working resource reseravtion (apart from POTS:-) are ST-II on the DSI net and ATM pilots, which are both connection oriented (and both have problems with multicast and other serious design flaws...but they do demo one thing). If we say we want resource control, but we ewant datagrams, we are making quite a strong requirement statement that while i agree with, that is based ont eh direction of what i regards as plausible research, but in the face of other work. I am also interested in how you do TOS routing with flow ids but without TOS bits? (sure you can do QoS routing, but TOS is coarser garined, manageable (e.g. [M]OSPF) and exists. So, is TOS routing a requirement? is QOS routing (i.e. load balancing) a requirement? if datagram, and resource guarantees, then what about the reseravtion protocol requirement? 2. on politics: I find the argument that ISO costs to much completely flawed - the hidden cost of IP is huge and there was a single agency that happened to have the largest budget for R&D in the history of the world, ever. The one thing that will make or break IPng selection is whether some similar agency (post peace dividend, that seems to me to mean a large business such as automotive, or power or TV entertainment or news distribution) backs the selection. To this end, the technical community behind any decision has a marginal, but still effective, voice... 3. on failure: if (as happened last time) a selection is made, and the community ignores it, what is the procedure....? jon From kasten@mailserv-D.ftp.com Tue Mar 15 09:50:46 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA00797 for ; Tue, 15 Mar 1994 09:51:29 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 15 Mar 1994 09:51:26 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA29636; Tue, 15 Mar 94 09:50:46 EST Date: Tue, 15 Mar 94 09:50:46 EST Message-Id: <9403151450.AA29636@mailserv-D.ftp.com> To: bound@zk3.dec.com Subject: Re: IPng Reqs Docs -- Can't find them ... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 611 > Got to research.ftp.com. cd /pub ... then no ip7 dir but found ip7reqs > dir. cd to ip7reqs .. no files Did they move ?? && ^[.*?]. Was > looking for the March 10th version fyi.. pub/ip7reqs/criteria.txt i've taken read permission off of the directory because there have been a fair number of random people anonymously ftp'ing to the machine and just wandering about the directories to 'see what is there'. i do not feel that the document is ready for widespread, general, distribution at this point. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From craig@BBN.COM Tue Mar 15 10:12:15 1994 Return-Path: craig@BBN.COM Received: from FRED.BBN.COM (FRED.BBN.COM [128.89.1.132]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA01073 for ; Tue, 15 Mar 1994 10:22:19 -0500 Message-Id: <199403151522.KAA01073@picard.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil To: bound@zk3.dec.com Subject: re: IPng Requirements: More input on Requirements Date: Tue, 15 Mar 94 10:12:15 -0500 From: Craig Partridge Jim and fellows: I'm typing at an odd terminal while travelling so I will keep this short and focus on a couple of comments of Jim's about which I feel strongly. IP checksum -- it is a "non-goal" for the following reason. Given today's IPv4, in retrospect, it wasn't needed. So in a successor to IPv4, if we are just duplicating IPv4 technology, leave the checksum out. But if we are adding new functionality (say, IDs for flows that need to be verified), a checksum-like function may need to exist. Kudos for leaving out a checksum if you don't need it, and kudos for putting it in if you do need it. That doesn't sound like a requirement -- it sounds like careful protocol engineering. Accounting -- a damnable tricky problem. One doesn't need any IP support for accounting if all you want to do is bill best effort traffic or do bandwidth management by policy of a link's bandwidth. In fact, I'm philosophically opposed to putting accounting in for these purposes -- I view per-packet accounting as extraordinarily destructive to the Internet protocols. Now we may need to do some form of accounting (or at least, verification) for flows, since they are asking for a higher quality of service and the only way I know to keep everyone from asking for the higher quality is to bill folks who ask for higher quality for the privilege. However, what may happen is that one requests, say, 2 hours of a certain bandwidth and delay path (to watch a movie) and the network then simply verifies your flow ID as it goes past (the IAB workshop looked at this problem a bit -- a good bit of reading -- to appear shortly). So while our accounting non-goal may not be quite straight it is close -- the point is, we don't need it for IPv4 functions -- we probably do need it for flows, but the flow accounting mechanism may not require explicit support in IPng. So... where does this put us in terms of framing a requirement? Craig From kasten@Research.Ftp.Com Tue Mar 15 10:30:33 1994 Return-Path: kasten@Research.Ftp.Com Received: from Research.Ftp.Com (research.ftp.com [128.127.145.125]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA01185 for ; Tue, 15 Mar 1994 10:34:33 -0500 Received: by Research.Ftp.Com (920330.SGI/) for ipng@cmf.nrl.navy.mil id AA11259; Tue, 15 Mar 94 10:30:33 -0500 Received: by Research.Ftp.Com id AA11259; Tue, 15 Mar 94 10:30:33 -0500 Date: Tue, 15 Mar 1994 10:30:33 -0500 (EST) From: Frank Kastenholz Subject: White papers boiled down To: ipng mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Per the phone conference yesterday, here is my quick view of what the white papers really seem to be requiring. I was rather ruthless in slashing the papers down to try to figure out what they truly want (I've got ~300 K of whitepaper text, which I've reduced to a 10K mail message...) and I hope none of the authors are too offended... Frank Re Clark, Ammar, and Calvert, "Multiprotocol Interoperability in IPng": For the most part, they want IPng to be operable in a multiprotocol environment. No problem, we require it. The last two paragraphs of section 3 imply, to me, that they want to run non-internet transport (etc) protocols over IPng, e.g. run TP* over IPng. This would require that either 1) IPng support the service definitions of all (major?) network layer protocols or 2) that 'harmonization elements' be definable to provide said services (and that IPng support some TBD 'core' set of services that allows these harmonization elements to be defined). Is this important? I do not think so. To me, this smacks of "kitchen sink" protocol design. At the beginning of section 4 they seem to indicate that a multiprotocol environment be seamlessly created and hidden from the end user. That is, I can just say "login to machine foo" and the network figures out which protocols are needed, etc etc. This is not a function of IP and I think that it should be ignored. I think that their "Addressing" and "Header Option Handling" requirements (section 5.1) are adequately covered by our document. They have a requirement called "Multiplexing" which says that IPng must support >1 higher-layer protocol. This IS a requirement but I sort of consider it "motherhood". I suppose that it could be added.... Everything else in their note seems to be either covered or not within the realm of IP (not to say that they are not interesting or important problems, but they are not _our_ problems...) Re INFN/CNAF White paper, Ghiselli, Salomoni, and Vistoli I read this document as requiring bigger/better addressing (we cover this) and that the transition be easy, as transparent as possible, and other good things like this. I do not see any real, new, requirements here. Re Vecchi, "IPng Requirements: A Cable Television Industry Viewpoint" A very very interesting document. In the second to last paragraph of section 2 ("The cable networks are..." implies OC-3 to the home (possibly 1 OC-3 to EACH home). Imagine the speed of the packet switch behind that...... I think that this might well have an affect on our performance goals, though I don't (yet) know what they are. I think that their estimates of network size are very important and low by a couple of orders of magnitude. See section 3.1. They see each home as a single end-node of their network. However, from an IP perspective, I would consider each home to be an "end-network" of which the cable receiving box is just one end-node. They estimate that their are about 10e10 households in the world (and their logic seems ok). This implies that our goal of 10e9 networks is too small. To the 10e10 households, I'd add all the infrastructure networks (backbones, regionals, etc etc etc), networks in offices, factories, stores, cars, planes, boats, trains, and there might be 10e11 or 10e12 networks.... Add a couple of orders of magnitude for 'safety' and we get 10e13 or 10e14 end-networks. Grrrr. These two require much thinking and cogitating. In section 3.4 of security, the first paragraph says that "the possibility of illicitly monitoring TRAFFIC PATTERNS... could be disturbing" (my emphasis). Obviously, privacy of the data is important and (I think) our security requirement covers this. What I think that they want is security for traffic pattern analysis. I am not sure if this is 'feasible' in IPng. I think that it should be a datalink layer function. Traffic pattern analysis protection requires that all addressing information in the packet be protected. In other words, the datalink-layer and IP-layer addresses be encrypted. Very very very expensive. But now that I think about it a moment, one could provide this protection by setting up flows or network and datalink layer connections and then just include a connection id (with no algorithmic mapping to source/destination addresses) in each packet. I think that this can be added to security... Section 3.12 wants a timestamp in each pcket. This seems to be a solution, not a problem. The rest, I think, is adequately covered. Re Green, Irey, Marlow, and O'Donoghue, "HPN Working Group Input to the IPng Requirements Solicitation" Section 3.1, bullet 3, Multi-homed. Yup. We forgot this... Multihoming always complicates things tremendously :-) Section 4.1, Addressing, requires mobile networks (each ship is 1 or more network) and mobile internetworks (e.g. an aircraft carrier containing its own network, and the networks of each plane on its flight deck...). Also, some of these nets could be large, they say 100,000 nodes. I'd add an order of magnitude or two here and give, as a high end, 1E7 end-nodes (i.e. a class-a address per ship in the navy -- if we allocated those now we'd be out of class a's). Section 4.1 also seems to require a highly-directable and highly-selective multicast ability. It looks like they want to limit multicasts to a single net/subnet. And they want to allow at least 16 bits of multicast group-id for a subnet. As a requirement, it seems that we want to ask for 'directed multicasts' (i.e. all hosts of multicast group 'x' on net/subnet 'y'), as well as wider-area multicasts. Section 4.2 requires a high-powered network-layer services architecture. Things like precedence... Our requirement can be broadened to require that real-time, mission-critical applications be supported. Section 4.5 and 5.1 imply high-speed for detecting network failures and rerouting. 4.5 says that 1 second is the max route-reconfiguration. This is a good requirement. Section 5.3 gives a lot of detailed requirements for security. These are probably worth adding. Re Heagerty, "Input to IPng Engineering Considerations" Well thought-out transition plan and ease of operation. Re Symington, Wood, and Pullen "Modelling and Simulation Requirements for IPng" Most of this, I think, is covered by our "Network Service". They do mention some things such as 100 millisecond latency (which is a function of both the IP layer and the datalink), 98% reliability (ditto). Section 3, bullet b requires that multicasts be scalable and wide-area. They want multicast groups consisting of 10's of thousands of nodes, and a node should be able to partake of hundreds of multicast groups. lots of scaling here.... Re Variot, "A White Paper on IPng: Various Low-Level topics" He wants flexibility/extensibility (covered) and scalability (covered). The rest is just some general stuff about protocol header design (solutions, not problems) and some things that are properly a higher-layer issue (see his section 4). re EPRI's response. They want CLNP. This is not something that we can require. Re Fleischman, "A User's View of IPng:" Long-term coexistance and interoperability are required. There must be some reason to go to IPng other than to keep the internet running (i.e. neat, new services and functions). Re Carpenter, "IPng White Paper on Transition and Other Considerations" Requires operation over ATM. I do not wish to require operation over particular datalink technologies (we'd have to list all of them, and then what about the ones we do not list?). I think that we've now got this covered. "Interworking at every stage and every layer" -- v4 and ng will have to coexist for a long time and their will have to be methods for v4-only and ng-only (i.e. neither host is dual-stacked) hosts to interoperate. There are also requirements for dual-stacking (I'm a: not sure that this is a problem that needs to be solved or a solution to the transition and coexistance problem and b: not sure whether this is an ip-level problem or a tcp-level problem). I do not think that the "transaction type" is a problem, but a solution to the problem of classifying packets for security and accounting needs (why not classify on transport protocol id and port ids?). Re tavs@vnet.ibm.com An element of the network service description must include cost parameters (question, what are the units?) Everything else seems to be covered. Re Hinden, "SIPP White Paper" I consciously made a decision to read only section 2 of this paper as I am not interested in how wonderful SIPP is..... No offense to any sippers, I'm interested in what the problems are, not what SIPP has done to solve them In section 2 he indicates that a big network and long-term coexistance are important. Re Bellovin "On many addresses per host" Part of this seems to be fixing broken or poorly written application layers with additional capabilities in IP (or making things easier for lazy application developers). The basic requirement is that there be a very very very very big number space out of which addresses and endpoint ids and stuff like that can be allocated. Re Bound "IPng Host Implementation Analysis" Section 4 seems to be the only section that presents any requirements of the protocol. I think that we've either covered them or that they are solutions to problems, and not the problems themselves. From brian@dxcoms.cern.ch Tue Mar 15 17:04:55 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01372 for ; Tue, 15 Mar 1994 11:05:30 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03374; Tue, 15 Mar 1994 17:05:03 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10315; Tue, 15 Mar 1994 17:04:55 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403151604.AA10315@dxcoms.cern.ch> Subject: Re: White papers boiled down To: kasten@Research.Ftp.Com (Frank Kastenholz) Date: Tue, 15 Mar 1994 17:04:55 +0100 (MET) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: from "Frank Kastenholz" at Mar 15, 94 10:30:33 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: 1527 Frank, I really admire what you have done here. Did you get any sleep last night? > > Re Carpenter, "IPng White Paper on Transition and Other Considerations" > Requires operation over ATM. I do not wish to require operation > over particular datalink technologies (we'd have to list all of > them, and then what about the ones we do not list?). I think that > we've now got this covered. Yes. > > "Interworking at every stage and every layer" -- v4 and ng will > have to coexist for a long time and their will have to be ** methods for v4-only and ng-only (IF neither host is dual-stacked) ** > hosts to interoperate. Yes. > There are also requirements for dual-stacking > (I'm a: not sure that this is a problem that needs to be solved or > a solution to the transition and coexistance problem and b: not sure > whether this is an ip-level problem or a tcp-level problem). This is more Carpenter shooting his mouth off about solutions than a requirement. I regard this part of my paper more as input to the Transition WG than to Requirements. > > I do not think that the "transaction type" is a problem, but a solution > to the problem of classifying packets for security and accounting > needs (why not classify on transport protocol id and port ids?). > True. The requirement is that IPng should ALLOW accounting, security and policy routing [you missed that one], or stated negatively, it should do nothing to make them more difficult than today. Brian From ericf@atc.boeing.com Tue Mar 15 08:46:22 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01639 for ; Tue, 15 Mar 1994 11:45:14 -0500 Received: by atc.boeing.com (5.57) id AA03879; Tue, 15 Mar 94 08:46:22 -0800 Date: Tue, 15 Mar 94 08:46:22 -0800 From: Eric Fleischman Message-Id: <9403151646.AA03879@atc.boeing.com> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking Dear Group, I second Jim's recommendation that autoconfiguration and autoregistration forms a requirement for IPng. You will note that requirement among the five requirements present in Boeing's IPng white paper. We call this capability "plug and play" networking. --Eric From ericf@atc.boeing.com Tue Mar 15 08:41:51 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01604 for ; Tue, 15 Mar 1994 11:40:40 -0500 Received: by atc.boeing.com (5.57) id AA03507; Tue, 15 Mar 94 08:41:51 -0800 Date: Tue, 15 Mar 94 08:41:51 -0800 From: Eric Fleischman Message-Id: <9403151641.AA03507@atc.boeing.com> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : More input on Requirements Jim wrote concerning recommended changes to the Requirements document: > In the Transition section. Add "Application binary compatibility for > existing IPv4 applications". IPv4 apps should not have to be altered or > recompiled on a host because IPng is installed on a host. > Lets not forget about the ISVs they are very important and a customer > for any host vendor. Is this really true? I can see this being a requirement for those TCP/IP implementations where the lower layers are imbedded within the host's operating system. However, by no means are all TCP/IP stacks constructed in such a way (e.g., many FTP Software's products). For this reason it may not be fair to make this a requirement in all situations. > Configuration strategy and interfaces for transition should be well defined > in any transition plan (they are not now in any IPng). We need this > especially for IPv4/IPng tunnels which will exist in any IPng proposal, > as one example. I second this point. Also, I had always seen IPng written as "IPng". The authors' "IP:ng" strikes me as non-standard. I would find it more aesthetically pleasing if the standard spelling were used. > Well I know Digital, Sun, and Cisco have implemented some pretty good > firewalls and they help sell into accounts accessing the Internet. > If a proposal does something to prevent or disrupt the use of the > software to support Firewalls so it is not as easy or more costly via > performance to implement I care a lot. We should be able to ding > someone on this as its taking $$$$ away from vendors who build > firewalls. I am saying if something technically prohibits a vendor from > building a firewall at a reasonable cost then thats not good. I fully agree with Jim's sentiment but I don't think that our requirements document can satisfactorily address costs except in those cases in which direct negative cost impacts can be demonstrated. This is because costs are implementation and environment specific in so many cases. This means that costs can be quite subjective. However, when costs can be demonstrated to occur across the board, the function which drives the costs up is what we should target in our requirements. --Eric From kasten@mailserv-D.ftp.com Tue Mar 15 11:50:32 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01665 for ; Tue, 15 Mar 1994 11:51:14 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 15 Mar 1994 11:51:07 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01696; Tue, 15 Mar 94 11:50:32 EST Date: Tue, 15 Mar 94 11:50:32 EST Message-Id: <9403151650.AA01696@mailserv-D.ftp.com> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: IPng Requirements : More input on Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 2004 > > 1. on flows/resource: > I am still concerend over flow id's, and datagrams. > the technology for soft state flows is not entirely proven yet(pace Perhaps we will provide the impetus to force those technologies to become proven... > If we say we want resource control, but we ewant datagrams, we are > making quite a strong requirement statement that while i agree with, > that is based ont eh direction of what i regards as plausible > research, but in the face of other work. IPv4-like datagram service is necessary. It might not be sufficient. If you need connection-like service to do resource stuff, well, then so be it. If you can do resrouce control, etc, using datagrams, that's nice too. And if you come up with something in between, so much the better. > I am also interested in how you do TOS routing with flow ids but > without TOS bits? (sure you can do QoS routing, but TOS is coarser > garined, manageable (e.g. [M]OSPF) and exists. > > So, > is TOS routing a requirement? > is QOS routing (i.e. load balancing) a requirement? > if datagram, and resource guarantees, then what about the reseravtion > protocol requirement? Are these things problems to be solved, or are they possible methods for solving the problem of network services and resource reservations and so on? I think that they are all possible solutions, not problems. > 2. on politics: > I find the argument that ISO costs to much completely flawed - the I do not think that we are making this argument. We are making the argument that A) the ISO process is flawed so tying IPng to this process is 'bad' and B) CLNP is not sufficient to meet our needs (even if we simply take it as is from the ISO and rename it IPng). > 3. on failure: > if (as happened last time) a selection is made, and the community > ignores it, what is the procedure....? Find jobs writing accounting programs in Cobol? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From kasten@mailserv-D.ftp.com Tue Mar 15 11:50:24 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01662 for ; Tue, 15 Mar 1994 11:51:11 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 15 Mar 1994 11:51:05 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01693; Tue, 15 Mar 94 11:50:24 EST Date: Tue, 15 Mar 94 11:50:24 EST Message-Id: <9403151650.AA01693@mailserv-D.ftp.com> To: bound@zk3.dec.com Subject: Re: IPng Requirements : More input on Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 9166 > The doc looks even better. Good Job ... thanks > I like the log files ? Did you use rcs? ???? No. I type them in manually. "Computerized automation" is not the solution to all problems. > Change the name of the doc to "Technical Requirements for Choosing > ...etc." Let the title make it very clear these are technical > requirements being addressed. Also could say "Technology ..." to permit > marketing statements as needed in the requirements. I do not particularly care about the title. I do not think that "marketing statements" have a place in this document. Marketing statements are dependent on the marketeer doing the stating and the company for which said marketeer works -- I am sure that FTP has vastly different marketing statements about TCP/IP and IPng than does DEC. > What about actual implementations. Running Code. Should this not also > be a requirement. How much and levels of required integration with the > transition plan should be demonstrated. I think that the directorate's role is to figure out how to determine whether its requirements are met or not. > I would like to see the same performance requirements concerns for hosts > that were projected for routers stated. Yeah, but the wording is going to be "interesting". We got away with it for routers by using phrases like "state of the art" and "common, commercially available". What's this mean with respect to hosts? When someone makes computerized wall electrical outlets, they could become the most commonly available and most state of the art (due to miniaturization, etc) computing 'hosts' in the world. And they might run 2 Mhz 6502 processors... I'd like to think that the requirements in media speed (ELF to 500Gbits) and router switching speed will end up with side effects that give the desired host performance. Otherwise we'll get into an interminable debate about what host counts for doing the performance tests... > In the Transition section. Add "Application binary compatibility for > existing IPv4 applications". IPv4 apps should not have to be altered or > recompiled on a host because IPng is installed on a host. > Lets not forget about the ISVs they are very important and a customer > for any host vendor. Which applications? Traceroute? There are apps in the world that use unsigned longs to contain the IP address. This is impossible, though I understand its desireability. > Configuration strategy and interfaces for transition should be well defined > in any transition plan (they are not now in any IPng). To me, this says that you want a "protocol user's/adminstrator's manual"? > >5.17. Explicit Non-Goals > > How about "Functionality not Required" This is more direct cause thats > what it is. I do not understand the difference. > >This section contains some explicit non-goals of IP:ng. A > >non-goal does not mean that a protocol MUST NOT do something. > >It means that the authors do not believe that it matters > >whether the non-goal is in the protocol or not. If a protocol > >includes one of the non-goals; well, that's cool. If it > >doesn't; that's cool too. A non-goal might be necessary in > >order to meet some other criterion, however this is irrelevant > >to including the non-goal merely for its own sake. > > Well I don't think thats cool. If removing the checksum or saying no > more fragmentation at routers (except for IPv4 compatibility) increases > performance (which it does) then if a proposal is not going to do that I > don't think that is cool at all. In fact to use an old sixties term its > uncool. I think that I do not care how the proposals meet the stated requirements. If your proposal meets the performance and robustness goals by not doing checksums, and my proposal has the same performance and robustness and uses checksums, then, to me, there is no difference. In fact, I would argue that my proposal would be inferior to yours (see section 4.1, "Architectural Simplicity") > >Fragmentation > > The technology exists for path MTU discovery. > > Presumably, IP:ng will continue to provide this > > technology. Therefore, we believe that IP:ng > > Fragmentation and Reassembly, as provided in IPv4, is not > > necessary. > > OK this is what I mean by the double negative in the Gestalt > perspective. Its OK to change the way IPv4 frag/reass has done it but > its a non-goal. Well if everyone does it I think its important how they > propose doing it. I know NFS and Transaction Processing Asynch > software over UDP will care a lot. It seems to me that what NFS, et al, require, is that they can send moby-grams over the net, not that fragmentation is done. I think that we have stated the need to send moby-grams. Fragmentation is one possible solution to that need. If NFS, et al, have additional service or behavior needs then let's state those needs. It might turn out that fragmentation is the only possible solution. It might be that there is some underpaid, overworked grad student inventing some new technique which will be infinitely better than fragmentation or MTU discovery. Let's not rule out such a technique. > >IPv4/IP:ng Communication > > It is not necessary that IPv4-only and IP:ng-only hosts > > be able to communicate directly with each other. > > Well it is necessary for some systems and consensus seems to be split on > this one. See Mbone minutes that should come out this week as they have > been ratified by the Directorate. Also talk to any Embedded systems > vendor. One stack is real nice for performance. I know there is talk > of a chip which I wont mention can support two stacks well. Thats not > the point and most embedded systems are not implemented on chip they are > implemented with honest-to-good old fashion network subsystem software > and two stacks cost more than one on these minimal host > implementations. You do not seem to understand the point. Suppose that there is a network which is not connected to the rest of the world, with exactly two hosts on it. One host supports IPv4 ONLY. The other host supports IPng ONLY. Neither host is dual-stacked. There is no requirement that these two hosts, in the situation described, be able to establish any form of communication. To allow these two to communicate we admit that another, external, agency may be introduced, such as a translating gateway. To put it another way, today, a host that supports ONLY CLNP can not establish communications with a host that supports ONLY IP unless there is some third agency on the network that will translate CLNP to IP. > Not only that but getting back to host performance. What you keep wanting to require, as I read your note, is that hosts must do X and Y and Z to meet performance or security goals. I'd rather just state the goals and then let the bright engineers figure out how to meet them. > >Firewalls > > Some have requested that IP:ng include support for > > firewalls. The authors believe that firewalls are one > > particular solution to the problem of security and, as > > such, do not consider that support for firewalls is a > > valid requirement for IP:ng. > > Well I know Digital, Sun, and Cisco have implemented some pretty good > firewalls and they help sell into accounts accessing the Internet. > If a proposal does something to prevent or disrupt the use of the > software to support Firewalls so it is not as easy or more costly via > performance to implement I care a lot. The proposals, to meet the requirements, must provide security. Today you use firewalls because that is how you get a certain desired level of security. What the requirements should say is what the desired level of security is, not that we want firewalls. > I agree that IPng should be developed and then the services will have to > fit that model. But if one proposals makes it easier to maintain the > performance and functionality of the existing applications and services > then that is a plus for that proposal. But how would you state this as a requirement? How do you quantify it? It's sort of like the cost question yesterday. "It must be easy to maintain the performance and functions of existing applications" -- well, define "easy"... Finally, as to the whole 'non-goals' issue. Remember the first sentence of section 1.0: "This note codifies and orgianizes the authors' personal opinions...." When and if the IPng Directorate chose to adopt our document as the basis for continuing their own evolutiotion of a document, the directorate are certainly free to change it however they wish; presumably they will appoint an editor of their requirements document and said editor will have to make changes as the directorate wish. Unless and until the directorate 'adopt' the document, Section 1.0 holds. Some might consider this an offensive and arrogant point of view, in fact, I'll be the first to admit that it is arrogant, but it also represents a 'fact of life'. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ericf@atc.boeing.com Tue Mar 15 08:52:39 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01668 for ; Tue, 15 Mar 1994 11:51:17 -0500 Received: by atc.boeing.com (5.57) id AA04618; Tue, 15 Mar 94 08:52:39 -0800 Date: Tue, 15 Mar 94 08:52:39 -0800 From: Eric Fleischman Message-Id: <9403151652.AA04618@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, kasten@Research.Ftp.Com Subject: Re: White papers boiled down Dear Frank, Our IPng requirements were contained in the last section of our white paper. I guessed you must have missed them due to battle fatigue. In any case, we believe that we have five specific IPng requirements which we would like to be fully reflected in the requirements document: 1) The IPng approach must permit users to slowly transition to IPng in a piecemeal fashion. Even if IPng becomes widely deployed, it is unrealistic to expect that users will ever transition all of the extensive IPv4 installed base to IPng. Consequently, the approach must indefinitely support corporate-internal communication between IPng hosts and IPv4 hosts regardless of the requirements of the world-wide Internet. 2) The IPng approach must not hinder technological advances from being implemented. 3) The IPng approach is expected to eventually foster greater synergy (integration/adoption) between Internet Standards and International Standards (i.e., OSI). [Note: This may be accomplished in a variety of ways including having the Internet Standards adopted as International Standards or else having the International Standards adopted as Internet Standards.] 4) The IPng approach should have "self-defining network" (i.e., "plug & play") capabilities. That is, large installations require device portability in which one may readily move devices within one's corporate network and have them autoconfigure, autoaddress, autoregister, etc. without explicit human administrative overhead at the new location -- assuming that the security criteria of the new location have been met. 5) The approach must have network security characteristics which are better than existing IPv4 protocols. Thank you for your attention to this matter. Sincerely yours, --Eric Fleischman From brian@dxcoms.cern.ch Tue Mar 15 18:11:55 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA01867 for ; Tue, 15 Mar 1994 12:12:33 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27276; Tue, 15 Mar 1994 18:12:04 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13238; Tue, 15 Mar 1994 18:11:56 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403151711.AA13238@dxcoms.cern.ch> Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking To: ericf@atc.boeing.com (Eric Fleischman) Date: Tue, 15 Mar 1994 18:11:55 +0100 (MET) Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil In-Reply-To: <9403151646.AA03879@atc.boeing.com> from "Eric Fleischman" at Mar 15, 94 08:46: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: 422 Yes, but it must be optional (some sites detest plug-and-play). Brian >--------- Text sent by Eric Fleischman follows: > > Dear Group, > > I second Jim's recommendation that autoconfiguration and autoregistration > forms a requirement for IPng. You will note that requirement among the > five requirements present in Boeing's IPng white paper. We call this > capability "plug and play" networking. > > --Eric > From bound@zk3.dec.com Tue Mar 15 12:28:45 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA02311 for ; Tue, 15 Mar 1994 12:33:57 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA02764; Tue, 15 Mar 94 09:28:13 -0800 Received: by xirtlu.zk3.dec.com; id AA28496; Tue, 15 Mar 1994 12:28:51 -0500 Message-Id: <9403151728.AA28496@xirtlu.zk3.dec.com> To: smb@research.att.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking In-Reply-To: Your message of "Tue, 15 Mar 94 09:19:09 EST." <9403151421.AA24134@decvax.dec.com> Date: Tue, 15 Mar 94 12:28:45 -0500 X-Mts: smtp Two of our folks Donald Eastlake and Charlie Kaufman just submitted a DNS security spec. Have you check that out? Any comment? Donald and Charile are well aware of IPng and I have asked them to keep a watchful eye on this space for IPng. General beliefs are that IPSEC is not moving to good is what I hear? /jim From smb@research.att.com Tue Mar 15 13:19:38 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id NAA02654 for ; Tue, 15 Mar 1994 13:21:12 -0500 From: smb@research.att.com Message-Id: <199403151821.NAA02654@picard.cmf.nrl.navy.mil> Received: by gryphon; Tue Mar 15 13:19:39 EST 1994 To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking Date: Tue, 15 Mar 94 13:19:38 EST Two of our folks Donald Eastlake and Charlie Kaufman just submitted a DNS security spec. Have you check that out? Any comment? Donald and Charile are well aware of IPng and I have asked them to keep a watchful eye on this space for IPng. The general DNS security question is an interesting one. But my point is more fundamental: you can't do authentication without some sort of secret -- the exact flavor doesn't matter much -- and I don't think you should update a DNS without authentication. Providing a new host with a secret, while still preserving the simplicity of plug-and-play, is difficult (to put it mildly). I can think of all sorts of solutions for environments with one sort of restriction or another -- but a general solution may be impossible. Can we come close? General beliefs are that IPSEC is not moving to good is what I hear? There's a suggestion that a good key management/distribution protocol will really get things moving in that arena, since there are lots of protocols that assume the existence of one. In fact, that's what I'm going to be working on myself as soon as the manuscript is out the door (which should be any day now). From bound@zk3.dec.com Tue Mar 15 13:19:23 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id NAA02684 for ; Tue, 15 Mar 1994 13:24:46 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA06548; Tue, 15 Mar 94 10:18:52 -0800 Received: by xirtlu.zk3.dec.com; id AA29824; Tue, 15 Mar 1994 13:19:29 -0500 Message-Id: <9403151819.AA29824@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : More input on Requirements In-Reply-To: Your message of "Tue, 15 Mar 94 11:50:24 EST." <9403151650.AA01693@mailserv-D.ftp.com> Date: Tue, 15 Mar 94 13:19:23 -0500 X-Mts: smtp Frank, Well I am like you and sleeping a few hours a night. I think there is an underlying problem I have with not having a certain set of requirements in general that won't be able to be required. They do seem either like a solution to the problem or a side effect from IPng that will have to be addressed. But I think they are much more covering our butts as much as possible for when implement IPng. Let me try two examples. Example 1 Application Binary Compatibility for IPv4 existing Apps: Today I run an application X over IPv4 using a sockets API. Then IPng is chosen. All IPng's during the transition period will support both IPng and IPv4 on their end systems. It will take some time to port applications to use IPng once host vendors deliver products supporting the IPng network layer and other integrated pieces for IPng. Any existing IPv4 application that wants to make use of IPng will have to make source code changes. That application then becomes IPng capabable. But until application X is ported to be IPng capable, application X will need to execute over the IPv4 protocol family. What I am saying is that applications that are not ported to take advantage of IPng once they are re-installed on a host supporting both IPng and IPv4 that application should not have to have source modifications and in fact be binary compatible on the IPng/IPv4 system. I am not saying that the applications can just run over IPng without modification. We don't want to have to port all those IPv4 apps in one fail swoop and they will get done gradually as ISVs and vendors feel it will be profitable. Example 2 Discussion of Host Performance. A good example of host performance loss is if an IPng's data structures are not aligned on XXbit boundary. Depending on that boundary it can affect register stores and even mapping of page tables. For example one way to increase host performance is to support a move rather than a copy from the applications user space to kernel space on VMS or UNIX. Alignment of the data in the kernel or user space affects the memory and network subsystem of the host environment. But I understand it would take a lot of work to get this in the requirements and really is protocol engineering analysis of an IPng. If its not a requirement how is this addressed at the end of day by the Directorate and the IETF if an IPng is just plain not good by design for a host. What gives us the opportunity to say this in the IETF? This is the heart of my concern with generating requirements. I admit I am implementing TUBA and SIPP and I am seeing these kinds of trade-offs at a very low level of detail. They are important and I feel they will not be discussable because they are not on the requirements list. ???? p.s. Your responses are real good and this dialogue is useful. I don't mind arrogance some of the best architects I know are very arrogant. p.s.s. I agree with Eric F. lets use IPng not IP:ng. Forget my comment about the title. Its fine. /jim From bound@zk3.dec.com Tue Mar 15 13:31:26 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id NAA02763 for ; Tue, 15 Mar 1994 13:38:56 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA07462; Tue, 15 Mar 94 10:30:54 -0800 Received: by xirtlu.zk3.dec.com; id AA00422; Tue, 15 Mar 1994 13:31:32 -0500 Message-Id: <9403151831.AA00422@xirtlu.zk3.dec.com> To: smb@research.att.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking In-Reply-To: Your message of "Tue, 15 Mar 94 13:19:38 EST." <9403151820.AA12938@decvax.dec.com> Date: Tue, 15 Mar 94 13:31:26 -0500 X-Mts: smtp steve, great i would love to only have to know and understand one key managment protocol. we need to figure out security before something real bad happens on the Internet or in a private company. hope a new IPSEC AD helps. i dont follow this space so I just listen to those how know. p.s. i do use kereberos to get ticket each day so i can get to my source code pool. /jim From bound@zk3.dec.com Tue Mar 15 13:38:16 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id NAA02791 for ; Tue, 15 Mar 1994 13:43:55 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA07893; Tue, 15 Mar 94 10:37:44 -0800 Received: by xirtlu.zk3.dec.com; id AA00517; Tue, 15 Mar 1994 13:38:22 -0500 Message-Id: <9403151838.AA00517@xirtlu.zk3.dec.com> To: Jon Crowcroft Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : More input on Requirements In-Reply-To: Your message of "Tue, 15 Mar 94 09:34:44 GMT." <199403151436.JAA00705@picard.cmf.nrl.navy.mil> Date: Tue, 15 Mar 94 13:38:16 -0500 X-Mts: smtp John, >1. on flows/resource: >I am still concerend over flow id's, and datagrams. >the technology for soft state flows is not entirely proven yet(pace >rsvp, CSZ etc), and in fact the only large scale demonstrators of >working resource reseravtion (apart from POTS:-) are ST-II on the DSI >net and ATM pilots, which are both connection oriented (and both have >problems with multicast and other serious design flaws...but they do >demo one thing). >If we say we want resource control, but we ewant datagrams, we are >making quite a strong requirement statement that while i agree with, >that is based ont eh direction of what i regards as plausible >research, but in the face of other work. I have customers who have told us they want this now. Its a definite carrot for IPng so they will use it. Time to market from Research to Delivery is getting better each year IMHO. >I am also interested in how you do TOS routing with flow ids but >without TOS bits? (sure you can do QoS routing, but TOS is coarser >garined, manageable (e.g. [M]OSPF) and exists. TOS could be part of a flow ID field. >So, >is TOS routing a requirement? >is QOS routing (i.e. load balancing) a requirement? >if datagram, and resource guarantees, then what about the reseravtion >protocol requirement? I think QOS and TOS need to become integrated. RSVP will use the network layer flow which can be QOS/TOS integrated and a flow key or ID or whatever. >2. on politics: >I find the argument that ISO costs to much completely flawed - the >hidden cost of IP is huge and there was a single agency that happened >to have the largest budget for R&D in the history of the world, ever. >The one thing that will make or break IPng selection is whether some >similar agency (post peace dividend, that seems to me to mean a large >business such as automotive, or power or TV entertainment or news distribution) >backs the selection. To this end, the technical community behind any >decision has a marginal, but still effective, voice... ACK on Franks previous response. We need to use the IETF process it works better. Lots more IP nodes than OSI nodes in the world as Open System protocols. >3. on failure: >if (as happened last time) a selection is made, and the community >ignores it, what is the procedure....? Use IPX. /jim From kasten@mailserv-D.ftp.com Tue Mar 15 13:46:35 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id NAA02826 for ; Tue, 15 Mar 1994 13:47:30 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 15 Mar 1994 13:47:17 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA03206; Tue, 15 Mar 94 13:46:35 EST Date: Tue, 15 Mar 94 13:46:35 EST Message-Id: <9403151846.AA03206@mailserv-D.ftp.com> To: smb@research.att.com Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Content-Length: 1703 > Two of our folks Donald Eastlake and Charlie Kaufman just submitted a > DNS security spec. Have you check that out? Any comment? Donald and > Charile are well aware of IPng and I have asked them to keep a > watchful eye on this space for IPng. > >The general DNS security question is an interesting one. But my point >is more fundamental: you can't do authentication without some sort >of secret -- the exact flavor doesn't matter much -- and I don't think >you should update a DNS without authentication. Providing a new host >with a secret, while still preserving the simplicity of plug-and-play, >is difficult (to put it mildly). I can think of all sorts of solutions >for environments with one sort of restriction or another -- but a >general solution may be impossible. Can we come close? Stop presuming a solution (a host which obtains an IP address then registers itself with the local DNS server) and start looking at problems (how to get DNS to know about a (possibly new) host's (possibly new) IP address). How does a host get to know its IP address? There are three ways that I can think of: 1) manually configured. if you are doing manual configuration then you can manually configure the secret into the host, or manually configure your DNS. problem solved. 2) obtained from an address service (DHCP, bootp, etc). how about having the address service ALSO inform the DNS? 3) magic. well, if you've solved the general problem of creating magic then you can create some more magic and maybe the DNS can use magic to learn of the host :-) -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ericf@atc.boeing.com Tue Mar 15 11:03:11 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id OAA02933 for ; Tue, 15 Mar 1994 14:01:52 -0500 Received: by atc.boeing.com (5.57) id AA19790; Tue, 15 Mar 94 11:03:11 -0800 Date: Tue, 15 Mar 94 11:03:11 -0800 From: Eric Fleischman Message-Id: <9403151903.AA19790@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, kasten@research.ftp.com Subject: Critique on March 10 criteria doc Dear Frank and Craig, I want to thank you for the spendid job you did on the March 10, 1994 version of the IPng Criteria document. The document has really "come a long way" and is well suited to be a "going in position" at the next IETF. Thank you for your excellent (and difficult) work. I have just finished a "close read" of this document and thus have a few minor comments to make. 1) The separation of "General Principles" (Section 4) from "Criteria" (Section 5) is a very good idea. I particularly liked the second paragraphy of Section 4.4. Please note that the final paragraph of Section 4.3 was probably written some time ago based on the verb tenses used. That paragraph should probably be updated. 2) I am grateful for the Robust Service criterion of section 5.4. It doubtlessly will exasperate many to learn that Boeing end users expect the same reliability from IPng that we currently get from SNA -- essentially 100% reliability or nearly 7x24 service. My users are therefore very upset by what they perceive to be the currently unacceptable service capabilities of TCP/IP, particularly in regards to what we consider to be unstable protocol implimentations such as DNS. Therefore, we expect superior service reliability for IPng than what IPv4 can provide today. Thus, the text IPng "must be at least as robust as IPv4" is greatly appreciated. The paragraph of that section beginning "The detrimental effects of failures, errors, and..." sidestep the critical point: IPng must become substantially easier to administer than IPv4 and thus these errors must become correspondingly less frequent if IPng is to fly. 3) A paragraph in Section 5.5 states: "Finally it may be necessary that multiple IP:ng protocols coexist on the network during the testing and evaluation periods." What? I do not understand why multiple IPng protocols should co-exist. Rather, this appears to be "old text" dating from the late 1992 period in which we still thought that the various IPngs may have to "fight to the finish". The new philosophy (I THOUGHT) was to select and deploy only one of the IPng alternatives. Please correct me if I am wrong. In any case, I suggest that this paragraph be deleted (as per the Antoine de Sant-Exupery quote). 4) The wording of the first paragraph of the discussion section of 5.7 should be sharpened. The logic of the first two sentences of that paragraph is weak. 5) I agree with Jim, Section 5.8 (Config, Admin, and Op) should mention autoregistration. Autoconfiguration by itself is inadequate for "plug and play" -- which is what we are after here. Let's not forget, however, that plug and play needs to be implemented as an option because it is not appropriate for ALL deployments (e.g., security needs should dictate actual deployment). The reference to "ownership" of addresses in the 3rd sentence bothers me. The administrator of a domain must be able to control the addressing of that domain without outside interference. For example, End Users must OWN their own addresses -- for security reasons if no other. The concept of Local Addresses needs to be part of IPng -- and IPv4. Pointedly, End Users simply will not tolerate control of internal addresses by outsiders. This is a basic security and control issue. 6) The statement of Section 5.9 in regard to security is unacceptably weak: IPng MUST HAVE better security than IPv4. It MUST at a minimum provide a way to protect transmitted passwords (via encryption or via some other means such as kerberos) and key data. The Jan 1994 CERT bulletins will ensure that business can not continue to proceed as usual in this domain if the Internet is to be used for commerce. Put another way, End Users are finally beginning to "wake up" on this issue: if Internet security isn't soon fixed, then who would risk anything but trivial data over the Internet (i.e., non-Internet solutions will be viewed as manditory to meet "real business" needs) ? I can speak (privately) quite pointedly on this matter since it is something which I must deal with increasingly often these days. All is not well in the commercial Internet world. 7) The renaming of section 5.14 from Flows to Network Service is greatly appreciated. I personally would like to see the concept of "priority" introduced into this section despite the problems the community has had in implementing that concept. I say this because I want "real time" services to "become real" very soon-- and "type of service" and quality of service" imply (to me) that messages can be prioritized. Is there a reason why that word was not included here? 8) In the Explicit non-goals section I agree with Jim's comments that Firewalls must not be precluded by IPng. Perhaps such a statement should be added to the Security section and the Firewalls deleted from this section? I think that accounting needs to be designed into the protocol "up front" if it is to function well. Thus, I disagree with including Accounting in this section. Simultaneously, I do not think that the IETF community has a common vision concerning how to do accounting and that we are therefore not able to address that topic at this time. This "disconnect" bothers me but I would rather form a new section labelled "Holes" to put this into than sweep it under the rug in this fashion. Thank you for your attention to these comments. Sincerely yours, --Eric Fleischman From bound@zk3.dec.com Tue Mar 15 13:55:29 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id OAA02930 for ; Tue, 15 Mar 1994 14:00:54 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA09200; Tue, 15 Mar 94 10:54:56 -0800 Received: by xirtlu.zk3.dec.com; id AA00938; Tue, 15 Mar 1994 13:55:35 -0500 Message-Id: <9403151855.AA00938@xirtlu.zk3.dec.com> To: Craig Partridge Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements: More input on Requirements In-Reply-To: Your message of "Tue, 15 Mar 94 10:12:15 EST." <199403151522.KAA01073@picard.cmf.nrl.navy.mil> Date: Tue, 15 Mar 94 13:55:29 -0500 X-Mts: smtp Craig, >IP checksum -- it is a "non-goal" for the following reason. Given today's >IPv4, in retrospect, it wasn't needed. So in a successor to IPv4, if we >are just duplicating IPv4 technology, leave the checksum out. But if we >are adding new functionality (say, IDs for flows that need to be verified), >a checksum-like function may need to exist. Kudos for leaving out a checksum >if you don't need it, and kudos for putting it in if you do need it. >That doesn't sound like a requirement -- it sounds like careful protocol >engineering. Agreed. My point is that how do we ding a proposal when after looking at their solution it will not work after careful protocol engineering analysis, or more difficult to prove, it won't work as good as another proposals solution. Just saying they can solve that requirement does not mean a proposal did it in the most efficient manner. Question: Why not include the flow ID in the pseudo checksums on hosts? Unless your saying routers need to checksum flows? Why is that? )--> thanks. >Accounting -- a damnable tricky problem. One doesn't need any IP support >for accounting if all you want to do is bill best effort traffic or do >bandwidth management by policy of a link's bandwidth. In fact, I'm >philosophically opposed to putting accounting in for these purposes -- >I view per-packet accounting as extraordinarily destructive to the Internet >protocols. Now we may need to do some form of accounting (or at least, >verification) for flows, since they are asking for a higher quality of service >and the only way I know to keep everyone from asking for the higher quality >is to bill folks who ask for higher quality for the privilege. However, what >may happen is that one requests, say, 2 hours of a certain bandwidth and >delay path (to watch a movie) and the network then simply verifies your flow >ID as it goes past (the IAB workshop looked at this problem a bit -- a good >bit of reading -- to appear shortly). So while our accounting non-goal >may not be quite straight it is close -- the point is, we don't need it for >IPv4 functions -- we probably do need it for flows, but the flow accounting >mechanism may not require explicit support in IPng. So... where does this >put us in terms of framing a requirement? ACK. I look forward to reading the IAB results. Will they come on the Big Internet list? I am beginning after all this mail today to take a new view of the requirements. Let me explain as you, John, and Frank just came on the mailing list. One common comment in jest but with some seriousness within the Directorate was that maybe the requirements could select the next IPng. After this mail today I do not think this is at all true unless an IPng cannot meet most of the requirements then it should be dropped. We will need to get into some very serious technical analysis of how each proposal goes about implementing those requirements. I for one look forward to this part so lets get the requirements done at Seattle if at all possible. This will be the most technical part of the process IMHO. Many of what I am saying are requiremnts are trying to address the negative side effects that could happen from implementing an IPng. When we do the technical analysis of how those requirements are met I will have a list, which I have already started keeping from my IPng engineering work. /jim From brian@dxcoms.cern.ch Tue Mar 15 21:10:52 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA03359 for ; Tue, 15 Mar 1994 15:11:30 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06538; Tue, 15 Mar 1994 21:11:01 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA17618; Tue, 15 Mar 1994 21:10:53 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403152010.AA17618@dxcoms.cern.ch> Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking To: kasten@ftp.com Date: Tue, 15 Mar 1994 21:10:52 +0100 (MET) Cc: smb@research.att.com, bound@zk3.dec.com, ipng@cmf.nrl.navy.mil In-Reply-To: <9403151846.AA03206@mailserv-D.ftp.com> from "Frank Kastenholz" at Mar 15, 94 01:46:35 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: 928 >--------- Text sent by Frank Kastenholz follows: ... > How does a host get to know its IP address? There are three ways that > I can think of: > 1) manually configured. if you are doing manual configuration then > you can manually configure the secret into the host, or manually > configure your DNS. problem solved. > 2) obtained from an address service (DHCP, bootp, etc). how about having > the address service ALSO inform the DNS? > 3) magic. well, if you've solved the general problem of creating magic then > you can create some more magic and maybe the DNS can use magic to learn > of the host :-) > 4) concatenate a local prefix and the host's IEEE 802 hardware address. Use method 1), 2) or 3) to obtain the local prefix. But this is still not self-authenticating, since the "hardware" address is often soft-settable these days. 5) choose a random address, ARP it, use it if nobody replies. Brian From craig@BBN.COM Tue Mar 15 16:03:57 1994 Return-Path: craig@BBN.COM Received: from FRED.BBN.COM (FRED.BBN.COM [128.89.1.132]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA04226 for ; Tue, 15 Mar 1994 16:10:02 -0500 Message-Id: <199403152110.QAA04226@picard.cmf.nrl.navy.mil> To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking In-reply-to: Your message of Tue, 15 Mar 94 21:10:52 +0100. <9403152010.AA17618@dxcoms.cern.ch> Date: Tue, 15 Mar 94 16:03:57 -0500 From: Craig Partridge Brian: Choosing an random address and defending it via ARP has all sorts of wonderful failure effects. Like, suppose the file server crashes, and during the delay while it checks its disks, a workstation comes up, choose the fileserver's address, finds no one to contest it, and starts going? [There are fixes -- like divide the address space into permanent and configurable addresses -- but then we aren't quite doing plug and play again...] Craig From brian@dxcoms.cern.ch Tue Mar 15 22:21:38 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA04364 for ; Tue, 15 Mar 1994 16:22:18 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18151; Tue, 15 Mar 1994 22:21:48 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19373; Tue, 15 Mar 1994 22:21:39 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403152121.AA19373@dxcoms.cern.ch> Subject: Brian's comments on March 10 draft To: ipng@cmf.nrl.navy.mil Date: Tue, 15 Mar 1994 22:21:38 +0100 (MET) 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: 5409 Frank, Craig, et al, Unfortunately I will have to miss Monday's telechat (at least you will know that it's always Jon speaking). Here are my comments on the March 10 draft of the requirements draft (150 lines to come). Obviously the first comment is a big thank you to the authors. General: 1) I'd like to see "criterion/a" changed to "requirement/s" throughout, to remove the impression that this is an exam paper. 2) I'd also like a ruling from our Directors whether it is "IPng" or "IP:ng". Missing: 1) Policy-based routing is mentioned only as an aside under service classes. I waste a lot of time in political and funding discussions because we don't have policy-based routing today, and I would like to see this requirement promoted to a heading. (I think it is like security and accounting: an unpopular subject at the IETF, but an absolute business requirement in the era of the information superbuzzword.) 2) The API issue is not mentioned and neither is the word "socket". Agreed, this is not an issue for the protocol design as such. However, any IPng proposal that does not explain how the socket API is made backwards compatible is incomplete. Maybe this fits in the 'non-goals' chapter (whose name I propose to change, see below). Page by page: [Page 10] > 4. General Principles Somewhere in this chapter, perhaps as an extension of 'Architectural Simplicity', how about adding "If it ain't broke, don't fix it." [Page 11] > 4.5. Co-operative Anarchy ... > We believe that this decentralized and decoupled nature of the > Internet must be preserved. Only a minimum amount of > centralization or forced cooperation will be tolerated by the > community as a whole. I would add that this last sentence applies especially to the transition to IPng, which can only succeed if the deployment model ASSUMES cooperative anarchy (especially, uncoordinated release dates from different vendors). [Page 22] > VJ-like header compression should be shown immediately, Most people know who VJ is, but not everybody. [Page 23] > The protocol must permit easy and largely distributed > configuration and operation. Automatic configuration of > hosts and routers is required. Please say "Optional automatic configuration..." > - Ease of address allocation. Please add "delegated to service providers and user sites as much as possible" [Page 25] > IPv4 and related RFCs. There must be no licensing fees > for implementing or selling IP:ng software. This could be confusing. I propose "There must be no licensing fees to use these documents for implementing or selling IPng software." [Page 26] > 5.12. Addressing I remember complaining in 1992 that multicast was hidden away in a section called "addressing". It still is, and I'm still complaining. (Ahah! But then I wasn't in the IPng Directorate, and now I am :-) Two comments in this area: why not say that IPng broadcast is not required and not wanted? And can we add that multicasts should never travel more than once on the same wire? [In fairness I should mention that this second point is a problem for TUBA, given the current CLNP multicast draft. But it is so obvious.] [Page 29] > 5.15. Support for Mobility It is a bit hand-waving to say > We use a vague definition of "mobility" here. You can be more precise. In fact I can be more precise: 5.15. Support for Portability and Roaming We note that there are two forms of mobility. In portability hosts are disconnected from the network, carried elsewhere, and reconnected temporarily. In roaming, hosts move freely with a wireless link to the network, and should stay on line continuously. Both portability and roaming should work over any geographical scale, from different rooms in the same building to trips round the world. IPng should support both portability and roaming. Time Frame With the current growth in the number of laptop computers, the need for portability is here and now. The need for roaming will grow rapidly over the next five years, especially with the spread of digital cellular telephony (GSM). [Page 30] > 5.17. Explicit Non-Goals I propose a rename and rewrite: 5.17 Side Issues This section contains some side issues related to IPng. Listing something as a side issue does not mean that a protocol MUST NOT do it. It means that the authors do not believe that it matters whether the issue is handled explicitly by the protocol or not. If a protocol includes one of the side issues; well, that's cool. If it doesn't; that's cool too. A side issue might arise in order to meet some other criterion, however this is irrelevant to including it for its own sake. [Page 31] > Accounting > We believe that accounting, like network management, must > be designed to fit the IP:ng protocol, and not the other > way round. Therefore, accounting, in and of itself, is > not a requirement of IP:ng. However, there are some > facets of the protocol that have been specified to make > accounting easier, such as non-repudiation of origin > under security, and the unique naming requirement for ^ insert "service classes," here Service classes are definitely helpful for accounting, since presumably flows should be charged more than telnet sessions. That's all, folks. Brian From bound@zk3.dec.com Tue Mar 15 15:46:34 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA04424 for ; Tue, 15 Mar 1994 16:24:51 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA17209; Tue, 15 Mar 94 12:46:02 -0800 Received: by xirtlu.zk3.dec.com; id AA03211; Tue, 15 Mar 1994 15:46:40 -0500 Message-Id: <9403152046.AA03211@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch, kasten@ftp.com, smb@research.att.com, bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking In-Reply-To: Your message of "Tue, 15 Mar 94 15:42:52 EST." <9403152042.AA03117@xirtlu.zk3.dec.com> Date: Tue, 15 Mar 94 15:46:34 -0500 X-Mts: smtp WHOOPS...CORRECTION >The hard part is making sure nothing in the proposal prevents future >dynamic autoconfiguration. ^^^^^^^^^^^^^^^^^ autoregistration. /jim From brian@dxcoms.cern.ch Tue Mar 15 22:30:49 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA04507 for ; Tue, 15 Mar 1994 16:31:24 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18575; Tue, 15 Mar 1994 22:30:57 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19626; Tue, 15 Mar 1994 22:30:49 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403152130.AA19626@dxcoms.cern.ch> Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking To: craig@BBN.COM (Craig Partridge) Date: Tue, 15 Mar 1994 22:30:49 +0100 (MET) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil In-Reply-To: <9403152110.AA17588@dxmint.cern.ch> from "Craig Partridge" at Mar 15, 94 04:03:57 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: 996 Craig, You may note that I want auto-config to be optional. This is because we have plenty of experience with the random choice method not converging on a large net. There are race conditions that you cannot fix. (I don't want to insult any particular company, but if you think of pears and oranges you won't be far off). Anyway, Jim's code for method 3) will solve this problem, and many others too :-) I'm going to bed, have a nice afternoon. Brian >--------- Text sent by Craig Partridge follows: > > > Brian: > > Choosing an random address and defending it via ARP has all sorts of > wonderful failure effects. Like, suppose the file server crashes, and > during the delay while it checks its disks, a workstation comes up, choose > the fileserver's address, finds no one to contest it, and starts going? > [There are fixes -- like divide the address space into permanent and > configurable addresses -- but then we aren't quite doing plug and play > again...] > > Craig > From craig@BBN.COM Tue Mar 15 16:20:33 1994 Return-Path: craig@BBN.COM Received: from FRED.BBN.COM (FRED.BBN.COM [128.89.1.132]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA04515 for ; Tue, 15 Mar 1994 16:31:32 -0500 Message-Id: <199403152131.QAA04515@picard.cmf.nrl.navy.mil> To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil Subject: Re