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: IPng Requirements: More input on Requirements Date: Tue, 15 Mar 94 16:20:33 -0500 From: Craig Partridge > Why not include the flow ID in the pseudo checksums on hosts? Unless > your saying routers need to checksum flows? Why is that? )--> thanks. Routers need to verify flow ids, to ensure that folks do not grab flow IDs. Since many authentication protocols are "checksums" in that if you succeed in the authentication, the data is almost certainly correct, one might have a "checksum" field in the IPng header. Craig From bound@zk3.dec.com Tue Mar 15 15:42:52 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 QAA04427 for ; Tue, 15 Mar 1994 16:24:54 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/13Jan94) id AA16976; Tue, 15 Mar 94 12:42:22 -0800 Received: by xirtlu.zk3.dec.com; id AA03117; Tue, 15 Mar 1994 15:42:58 -0500 Message-Id: <9403152042.AA03117@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: 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 21:10:52 +0100." <9403152010.AA17618@dxcoms.cern.ch> Date: Tue, 15 Mar 94 15:42:52 -0500 X-Mts: smtp Folks this is great we just laid out the possible ways to do autoconfig with Brians last two points. Its the integration and how to of each way below that needs to specified by any IPng. And then it can be discussed by the IPng how they update the DNS. Also I realize doing dynamic autoregistration day one (unless day one is two years from now) will be difficult but static autoregistration should be possible so the application or network manager can get a name or address after its autoconfigured. The hard part is making sure nothing in the proposal prevents future dynamic autoconfiguration. p.s. Brian I tried # 5 with a prototype today and my system crashed but its fun. I am now going to try Franks #3. Got to have some humor. We have had some good ones today Cobol, Magic, and if no one replies just use whatever you like. John Curran must be going OH NO... /jim ------------------------------------------------------- >--------- 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. From craig@BBN.COM Tue Mar 15 16:28:28 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 QAA04630 for ; Tue, 15 Mar 1994 16:41:35 -0500 Message-Id: <199403152141.QAA04630@picard.cmf.nrl.navy.mil> To: Brian Carpenter CERN-CN Subject: re: Brian's comments on March 10 draft cc: ipng@cmf.nrl.navy.mil Date: Tue, 15 Mar 94 16:28:28 -0500 From: Craig Partridge > 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.) Brian: I don't object to policy based routing (unlike per-packet account which I do object to). However, I think it can be solved multiple ways -- such as by using flow IDs. (If one allows multiple entities to use one Flow ID, which says -- I'm part of a NASA flow over this link, or whatever). Craig From francis@cactus.slab.ntt.jp Wed Mar 16 08:34:38 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp ([192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with ESMTP id SAA05689 for ; Tue, 15 Mar 1994 18:40:51 -0500 Received: by mail.ntt.jp (8.6.5/COREMAIL.1); Wed, 16 Mar 1994 08:32:44 +0900 Received: by slab.ntt.jp (8.5/core-slab.s5+) id IAA12096; Wed, 16 Mar 1994 08:32:16 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA18238; Wed, 16 Mar 94 08:34:38 JST Date: Wed, 16 Mar 94 08:34:38 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9403152334.AA18238@cactus.slab.ntt.jp> To: brian@dxcoms.cern.ch, craig@BBN.COM Subject: re: Brian's comments on March 10 draft Cc: ipng@cmf.nrl.navy.mil > > I don't object to policy based routing (unlike per-packet account which > I do object to). However, I think it can be solved multiple ways -- such > as by using flow IDs. (If one allows multiple entities to use one Flow ID, > which says -- I'm part of a NASA flow over this link, or whatever). > > Craig But, you have to consider how the flow got setup in the first place. For that, you need a (setup?) protocol that has the right routing/addressing semantics.... PF From lixia@parc.xerox.com Tue Mar 15 15:43:51 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id SAA05707 for ; Tue, 15 Mar 1994 18:44:50 -0500 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14427(7)>; Tue, 15 Mar 1994 15:43:54 PST Received: by redwing.parc.xerox.com id <57155>; Tue, 15 Mar 1994 15:43:59 -0800 Date: Tue, 15 Mar 1994 15:43:51 PST Sender: Lixia Zhang From: Lixia Zhang 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 1994 01:34:44 -0800 Message-ID: > 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. Jon, I'm not sure what your main concern is. As I read the current draft (Mar 10), it doesnt say anything about "the technology for soft state flows"; the criterion merely asks IPng for some facility with packet classification, which I believe is a well justified, proven necessity for QoS support (and a few other important functionalities). To the authors: Similar to accounting, personally I do NOT think the machinary for QoS support (all this reservation, admission control, scheduling scheme, etc) should be part of IPng protocol, although IPng must provide ^^^^^^^^ assistence (e.g. this LLID, as named by the recent IAB retreat) in implementing those machinaries. Based on this view, the last two paragraphs of this section sound a bit odd to me (perhaps this is what concerned Jon?). How about changing the words to something like "this criterion will facilitate functionalities such as policy-based routing, resource reservation, Quality-of-Service support, and so on ..." Lixia From francis@cactus.slab.ntt.jp Wed Mar 16 08:25:51 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp ([192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with ESMTP id TAA05852 for ; Tue, 15 Mar 1994 19:24:01 -0500 Received: by mail.ntt.jp (8.6.5/COREMAIL.1); Wed, 16 Mar 1994 08:22:43 +0900 Received: by slab.ntt.jp (8.5/core-slab.s5+) id IAA12000; Wed, 16 Mar 1994 08:22:54 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA18130; Wed, 16 Mar 94 08:25:51 JST Date: Wed, 16 Mar 94 08:25:51 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9403152325.AA18130@cactus.slab.ntt.jp> To: bound@zk3.dec.com, ericf@atc.boeing.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. > As a humorous aside, I heard a story here that when plug-and-play capabilities was announced some years back by a Japanese computer company, some newspaper mis-understood the phrase and published that the computer had "plug-and-pray" capability. What is funny is that that phrase is generally more appropriate.... PF From J.Crowcroft@cs.ucl.ac.uk Wed Mar 16 08:44:17 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.7/8.6.4) with SMTP id DAA07385 for ; Wed, 16 Mar 1994 03:45:39 -0500 Message-Id: <199403160845.DAA07385@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 16 Mar 1994 08:44:17 +0000 To: bound@zk3.dec.com cc: Brian.Carpenter@cern.ch, kasten@ftp.com, smb@research.att.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: Wed, 16 Mar 94 08:44:17 +0000 From: Jon Crowcroft >> How does a host get to know its IP address? There are three ways that >> I can think of: >5) choose a random address, ARP it, use it if nobody replies. 6) new service called hypercast. with multicast, steve deering gave us a way to send packets all with the same destination address. Now, new Hypercast allows all hosts to send FROM the same address. NO address scaling problems, no routing problems. All packets go from everywhere to everywhere - routers simply forward all packets out all interfaces, and hosts simply run all applications jon (:-), maybe From craig@BBN.COM Wed Mar 16 11:26:20 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 LAA10408 for ; Wed, 16 Mar 1994 11:41:01 -0500 Message-Id: <199403161641.LAA10408@picard.cmf.nrl.navy.mil> To: Paul Francis cc: brian@dxcoms.cern.ch, craig@BBN.COM, ipng@cmf.nrl.navy.mil Subject: Re: Brian's comments on March 10 draft In-reply-to: Your message of Wed, 16 Mar 94 08:34:38 +0200. <9403152334.AA18238@cactus.slab.ntt.jp> Date: Wed, 16 Mar 94 11:26:20 -0500 From: Craig Partridge Paul: Yes policy based routing of flows means the routing protocols need some information. But since the discussion was about what goes into the IPng datagram header, what I'm saying is that I'm not sure what requirements policy puts on the IPng header. Craig From rcallon@pobox.wellfleet.com Wed Mar 16 14:21:52 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id OAA12642 for ; Wed, 16 Mar 1994 14:28:40 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA26501; Wed, 16 Mar 94 14:11:08 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA05681; Wed, 16 Mar 94 14:21:52 EST Date: Wed, 16 Mar 94 14:21:52 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9403161921.AA05681@pobox.wellfleet> To: Brian.Carpenter@cern.ch, ericf@atc.boeing.com Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil 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 > I agree on both points. I think that the biggest growth market in the future for Datacomms (perhaps the only growth market) will be amongst folks who are not particularly technically literate. We really have to make things a lot easier for them to use. On the other hand, I don't see any reason to preclude the ability to override the default autoconfiguration for those users who are capable of figuring out how to do this. Ross From lkeiper@IETF.CNRI.Reston.VA.US Wed Mar 16 15:42:13 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.7/8.6.4) with SMTP id PAA13478 for ; Wed, 16 Mar 1994 15:42:13 -0500 Date: Wed, 16 Mar 1994 15:42:13 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa12760; 16 Mar 94 15:07 EST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference, March 14, 1994 Cc: lkeiper@cnri.reston.va.us Message-ID: <9403161507.aa12760@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 21, 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 -ER54769 in the orginators name, >Steve Coya. > >Thanks > > >Lois > > From lkeiper@IETF.CNRI.Reston.VA.US Wed Mar 16 15:48:46 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.7/8.6.4) with SMTP id PAA13597 for ; Wed, 16 Mar 1994 15:48:46 -0500 Date: Wed, 16 Mar 1994 15:48:46 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa13461; 16 Mar 94 15:35 EST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference, March 14, 1994 Cc: lkeiper@cnri.reston.va.us Message-ID: <9403161535.aa13461@IETF.CNRI.Reston.VA.US> >> >> >>ANNOUNCEMENT****(my apologies for receiving this twice) >> >>The names marked with an asterisk are those who have confirmed participation >>for the IPng teleconference scheduled for March 21, 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 -ER54769 in the orginators name, >>Steve Coya. >> >>Thanks >> >> >>Lois >> >> > > From rcallon@pobox.wellfleet.com Wed Mar 16 16:20:56 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA14044 for ; Wed, 16 Mar 1994 16:27:56 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28088; Wed, 16 Mar 94 16:10:12 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA08106; Wed, 16 Mar 94 16:20:56 EST Date: Wed, 16 Mar 94 16:20:56 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9403162120.AA08106@pobox.wellfleet> To: Brian.Carpenter@cern.ch, bound@zk3.dec.com Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking Cc: ipng@cmf.nrl.navy.mil, kasten@ftp.com, smb@research.att.com Folks this is great we just laid out the possible ways to do autoconfig with Brians last two points. Well, actually this is *some of* the ways to do address autoconfiguration. Its the integration and how to of each way below that needs to specified by any IPng. And then it can be discussed by the IPng how they update the DNS. Also I realize doing dynamic autoregistration day one (unless day one is two years from now) will be difficult but static autoregistration should be possible so the application or network manager can get a name or address after its autoconfigured. I think that DNS folks should figure out how, if the host can somehow find out its address, then how will the DNS autoregister it. The IPng should figure out the first part (how does the host get its address). The hard part is making sure nothing in the proposal prevents future dynamic autoconfiguration. I actually think that address autoconfiguration is important enough that it should be in IPng from day 1. p.s. Brian I tried # 5 with a prototype today and my system crashed but its fun. I am now going to try Franks #3. Got to have some humor. We have had some good ones today Cobol, Magic, and if no one replies just use whatever you like. John Curran must be going OH NO... /jim ------------------------------------------------------- >--------- 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. As perhaps another way for use on broadcase subnets only, the prefix (mentioned in 4) could be just heard off the wire (possibly taken from packets that are already sent on the wire for other reasons, such as router discovery packets). The host's local ID does not have to have anything to do with any particular subnet address. If we were willing to have the IANA administer a global ID space, then we could use our own IPng-specific ID space. This might save a lot of confusion. Ross From rcallon@pobox.wellfleet.com Wed Mar 16 16:22:43 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA14062 for ; Wed, 16 Mar 1994 16:29:47 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28108; Wed, 16 Mar 94 16:12:00 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA08131; Wed, 16 Mar 94 16:22:43 EST Date: Wed, 16 Mar 94 16:22:43 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9403162122.AA08131@pobox.wellfleet> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil, kasten@ftp.com, smb@research.att.com Subject: Re: IPng Requirements : Autoconfiguration Forward Thinking WHOOPS...CORRECTION >The hard part is making sure nothing in the proposal prevents future >dynamic autoconfiguration. ^^^^^^^^^^^^^^^^^ autoregistration. woops myself. I should have read ahead before sending my response. Yes I agree, IPng should do autoconfiguration, and ensure that nothing prevents future definition of autoregistration. It sounds like we may agree on this one :-). Ross From rcallon@pobox.wellfleet.com Wed Mar 16 16:39:19 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA14208 for ; Wed, 16 Mar 1994 16:46:10 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28408; Wed, 16 Mar 94 16:28:36 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA08505; Wed, 16 Mar 94 16:39:19 EST Date: Wed, 16 Mar 94 16:39:19 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9403162139.AA08505@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil, lkeiper@IETF.CNRI.Reston.VA.US Subject: Re: IPng Teleconference, March 14, 1994 I will not be able to attend this teleconference. I will be at the ATM forum next week. Ross From rcallon@pobox.wellfleet.com Wed Mar 16 16:46:18 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA14275 for ; Wed, 16 Mar 1994 16:53:01 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28518; Wed, 16 Mar 94 16:35:34 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA08660; Wed, 16 Mar 94 16:46:18 EST Date: Wed, 16 Mar 94 16:46:18 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9403162146.AA08660@pobox.wellfleet> To: craig@BBN.COM, ipng@cmf.nrl.navy.mil Subject: re: IPng Requirements: More input on Requirements 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. Just an off comment (in case anyone cares): When CLNP was defined, it did not have a checksum (for much the same reasons that SIPP doesn't have one). However, the US DOD insisted that CLNP *MUST* have a checksum, for important security reasons that they couldn't tell us. Thus the CLNP checksum was made optional -- so that the US DoD folks would be happy, and the folks who don't think that it is needed don't have to use it. Ross From J.Crowcroft@cs.ucl.ac.uk Thu Mar 17 09:16:53 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.7/8.6.4) with SMTP id IAA00981 for ; Thu, 17 Mar 1994 08:07:52 -0500 Message-Id: <199403171307.IAA00981@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 17 Mar 1994 09:16:57 +0000 To: Lois Keiper cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Teleconference, March 21, 1994 In-reply-to: Your message of "Wed, 16 Mar 94 15:42:13 EST." <9403161507.aa12760@IETF.CNRI.Reston.VA.US> Date: Thu, 17 Mar 94 09:16:53 +0000 From: Jon Crowcroft I may well not be able to be in this one except for a bit - we have a deprtmental assessment at exactly this time....if i can get away, i will. so long as the minutes are forthcoming, and i know what I have to do in seattle, i'll feel settled. jon From sob@hsdndev.harvard.edu Thu Mar 17 23:40:08 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.7/8.6.4) with SMTP id XAA08458 for ; Thu, 17 Mar 1994 23:40:13 -0500 Date: Thu, 17 Mar 94 23:40:08 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403180440.AA29765@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: ALE effector take a look at this document >From ietf-announce-request@IETF.CNRI.Reston.VA.US Thu Mar 17 23:34:09 1994 Received: by harvisr.harvard.edu; Thu, 17 Mar 94 23:32:06 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11875; 17 Mar 94 16:08 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11800; 17 Mar 94 16:06 EST Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22233; 17 Mar 94 16:06 EST Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 17 Mar 1994 13:06:58 -0800 Message-Id: <199403172106.AA20030@zephyr.isi.edu> To: IETF-Announce:;@IETF.CNRI.Reston.VA.US Subject: RFC1597 on Address Allocation for Private Internets Cc: jkrey@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 17 Mar 94 13:06:58 PST Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" Status: R --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1597: Title: Address Allocation for Private Internets Author: Y. Rekhter, B. Moskowitz, D. Karrenberg & G. de Groot Mailbox: yakov@watson.ibm.com, 3858921@mcimail.com, Daniel.Karrenberg@ripe.net, GeertJan.deGroot@ripe.net Pages: 8 Characters: 17,430 Update/Obsoletes: none This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. The authors hope, that using these methods, significant savings can be made on allocating IP address space. For the purposes of this memo, an enterprise is an entity autonomously operating a network using TCP/IP and in particular determining the addressing plan and address assignments within that network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <940317130307.RFC@ISI.EDU> SEND /rfc/rfc1597.txt --OtherAccess Content-Type: Message/External-body; name="rfc1597.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <940317130307.RFC@ISI.EDU> --OtherAccess-- --NextPart-- From rcallon@pobox.wellfleet.com Fri Mar 18 15:52:55 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA14816 for ; Fri, 18 Mar 1994 15:59:41 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA17272; Fri, 18 Mar 94 15:42:08 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA08492; Fri, 18 Mar 94 15:52:55 EST Date: Fri, 18 Mar 94 15:52:55 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9403182052.AA08492@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil Subject: IPng dinner Are we planning on getting together for an IPng direcotrate dinner at the IETF? If so, then which evening? Perhaps the same evening as the social might be the most likely time to find everyone available. Ross From lkeiper@IETF.CNRI.Reston.VA.US Fri Mar 18 16:49:07 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.7/8.6.4) with SMTP id QAA15203 for ; Fri, 18 Mar 1994 16:49:07 -0500 Date: Fri, 18 Mar 1994 16:49:07 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa11615; 18 Mar 94 15:55 EST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference, UPDATE*** Cc: lkeiper@cnri.reston.va.us Message-ID: <9403181555.aa11615@IETF.CNRI.Reston.VA.US> > >>> >>> >>>UPDATE************** >>> >>>The names marked with an asterisk are those who have confirmed participation >>>for the IPng teleconference scheduled for March 21, 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-465-3130* >>> *Scott Bradner 617-495-3864* >>> -Ross Callon REGRETS >>> -Brian Carpenter REGRETS >>> Dave Clark 617-253-6003 >>> *Steve Coya 703-620-8990* >>> -Jon Crowcroft REGRETS >>> John Curran 617-873-4398 >>> Steve Deering 415-812-4839 >>> -Dino Farinacci REGRETS >>> *Eric Fleischman 206-957-5334* >>> -Paul Francis REGRETS >>> 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 -ER54769 in the orginators name, >>>Steve Coya. >>> >>>Thanks >>> >>> >>>Lois >>> >>> >> >> > Lois J. Keiper IETF Secretariat From bound@zk3.dec.com Fri Mar 18 22:48:24 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA00961 for ; Sat, 19 Mar 1994 12:44:20 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA29430; Fri, 18 Mar 94 19:49:31 -0800 Received: by xirtlu.zk3.dec.com; id AA22366; Fri, 18 Mar 1994 22:48:30 -0500 Message-Id: <9403190348.AA22366@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Security and Firewalls with SIPP fyi .. Date: Fri, 18 Mar 94 22:48:24 -0500 X-Mts: smtp ------- Forwarded Message Return-Path: sipp-request@sunroof2.eng.sun.com Received: by wasted.zk3.dec.com; id AA29727; Fri, 18 Mar 1994 07:41:27 -0500 Received: from Sun.COM by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA25220; Fri, 18 Mar 1994 07:41:23 -0500 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09639; Fri, 18 Mar 94 04:34:43 PST Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06182; Fri, 18 Mar 94 04:33:43 PST Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02535; Fri, 18 Mar 94 04:38:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02529; Fri, 18 Mar 94 04:38:31 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03460; Fri, 18 Mar 94 04:33:23 PST Received: from itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA09610; Fri, 18 Mar 94 04:34:15 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27255; Fri, 18 Mar 94 07:34:09 EST Date: Fri, 18 Mar 94 07:34:09 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9403181234.AA27255@itd.nrl.navy.mil> To: sipp@sunroof2.eng.sun.com Subject: SIPP Security, filtering, etc. Sender: sipp-request@sunroof.eng.sun.com There have been recent discussions on the "firewalls" mailing list about security issues arising from the various IPng proposals and also about the well-known security issues arising from source routing. Although I'm not normally on the firewalls list, some of those comments were forwarded in my direction and I sent back the note below to the "firewalls" list to clarify why these aren't serious problems with SIPP. The bottom line is that it is VERY important that the SIPP Authentication Header be very widely deployed from day 1. Since that appears to be exportable, this should be a reasonable objective. Ran atkinson@itd.nrl.navy.mil - ----- Begin Included Message ----- >From atkinson Thu Mar 17 13:05:42 1994 Date: Thu, 17 Mar 94 13:02:27 EST Message-Id: <9403171802.AA27678@itd.nrl.navy.mil> To: firewalls@greatcircle.com Subject: SIPP Security, filtering, etc. Content-Length: 2908 X-Lines: 55 Firewall folks, I'm not a subscriber to the "firewalls" mailing list (yet), but a colleague forwarded a copy of Digest v3 #81 to me because it mentioned SIPP. I'd like to add a little data relating to security in SIPP (an IPng proposal). Steve Bellovin is absolutely right that "source routing" and "loose source routing" are potential security problems. However, SIPP includes strong authentication (e.g. keyed MD5) in the SIPP Authentication Header that eliminates those potential source routing security problems. So the presence of source routing in SIPP is not a security problem (assuming that the communicating parties use the SIPP Authentication Header as intended). The authentication mechanism can also be used to protect against other kinds of attacks (e.g. ICMP-based) and should significantly improve the security of the Internet if widely deployed. Note that the SIPP Authentication Header is included in the base SIPP specification; the SIPP working group has included security as an integral part of the design process rather than as a later add-on. NRL is building a SIPP implementation that will include all the security mechanisms. We intend to make our source code freely distributable. Commercial firms have also expressed interest in SIPP security, so I believe that SIPP will deployed with strong authentication if it is selected as the IPng. It appears that the SIPP Authentication Header is exportable because it provides authentication without confidentiality. Confidentiality is provided by SIPP Encapsulating Security Payload and so is also available to interested users, though its exportability is less clear. [DISCLAIMER: This is a personal opinion; I don't ever speak officially and I'm not affiliated with the part of the US Gov't that handles export stuff. :-] There are 3 Internet Drafts on SIPP Security that interested parties might want to read (all available from ftp.internic.net:/internet-drafts and other sites) and other SIPP specs, including the base spec, are also available as Internet Drafts: draft-ietf-sip-sa-*.txt SIPP Security Architecture draft-ietf-sip-ap-*.txt SIPP Authentication Header draft-ietf-sip-esp-*.txt SIPP Encapsulating Security Payload draft-ietf-sipp-spec-*.txt SIPP Specification I believe that filtering will continue to work for SIPP in a manner very similar to the way that routers currently can filter IPv4. Our implementation experience inside a BSD-ish kernel makes us think that filtering is not particularly different for SIPP. Regardless of which proposal gets chosen as IPng, the boxes doing the filtering will need to understand the IPng syntax in order to perform the filtering (This last should be obvious :-). Ran atkinson@itd.nrl.navy.mil employed by, but not speaking officially for Center for Secure Information Technology Information Technology Division Naval Research Laboratory - ----- End Included Message ----- ------- End of Forwarded Message From bound@zk3.dec.com Fri Mar 18 23:19:49 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA00966 for ; Sat, 19 Mar 1994 12:45:25 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA01469; Fri, 18 Mar 94 20:20:56 -0800 Received: by xirtlu.zk3.dec.com; id AA22788; Fri, 18 Mar 1994 23:19:55 -0500 Message-Id: <9403190419.AA22788@xirtlu.zk3.dec.com> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng dinner In-Reply-To: Your message of "Fri, 18 Mar 94 15:52:55 EST." <9403182052.AA08492@pobox.wellfleet> Date: Fri, 18 Mar 94 23:19:49 -0500 X-Mts: smtp Well Tues is about the only night left open for me and I don't do IETF socials. But I would be willing to meet with any folks not going as Ross suggested. take care, /jim From bound@zk3.dec.com Fri Mar 18 22:07:28 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA00979 for ; Sat, 19 Mar 1994 12:47:33 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA26921; Fri, 18 Mar 94 19:07:46 -0800 Received: by xirtlu.zk3.dec.com; id AA21993; Fri, 18 Mar 1994 22:07:34 -0500 Message-Id: <9403190307.AA21993@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IPng Reqs: Checksum Date: Fri, 18 Mar 94 22:07:28 -0500 X-Mts: smtp I ran the checksum issue by two of our security experts Charlier Kaufman and Donald Eastlake. This is the discussion I am able to forward. What I get out of it is that the checksum is for integrity not security. Also got received from oustide of Digital folks working on security too. Oh well different folks have different technical beliefs. Alas reality. take care, /jim ------- Forwarded Message Return-Path: PATHWK::dee@ranger.ENET.dec.com Received: by xirtlu.zk3.dec.com; id AA13812; Wed, 16 Mar 1994 20:17:48 -0500 Date: Wed, 16 Mar 1994 20:17:46 -0500 Message-Id: <9403170117.AA13812@xirtlu.zk3.dec.com> From: PATHWK::dee@ranger.ENET.dec.com (Donald Eastlake) To: XIRTLU::bound@ranger.ENET.dec.com (Jim Bound NOS) Cc: dee@ranger.ENET.dec.com, kaufman@zk3.dec.com Subject: Re: Could I get your input on the attached thx /jim A naked checksum of some sort will protect you against assorted hardware and software glitches but is, of course, no protection at all against malicious behavior. The two camps are presumably one that thinks glitches are of no importance as the net needs to be robust in terms of retransmitting/filtering to handle dropped/duplicated packets anyway. The other is worried about waste of resources or looping or congestion or something that could occur is packets were being frequently corrupted, etc. (People who are really worried about determining that some packet (or an action it commands) is authorized need to use cryptographic techniques anyway which will probably be a lot more expensive than a quick checksum.) My personal feeling is that the cost of computation is falling faster than anything else and a properly implemented checksum, which will catch even many software problems in routers, is worth it. If you want to go further, you could make it optional but it must be relatively hard for a glitch to turn off the checksum. I realize many people are strongly of different views from mine. Donald To: bound@XIRTLU.ENET.dec.com (Jim Bound NOS) Cc: dee@PATHWK.ENET.dec.com (Donald Eastlake), kaufman@zk3.dec.com Subject: Re: Could I get your input on the attached thx /jim Sure, feel free to forward my remarks to the IPng Directorate. What I meant was that it would be better, for example, to set things up so that an unlikely error would have to occur (very roughly as unlikely as a false checksum match) to disable the checksum if you made it optional. Thus having a single bit to enable/disable checksums is not so good. Even having a zero value mean it is disable (a la UDP) isn't great because if a 16 or 32 bit area is going to be smashed by a software error, zero is probably the most likely bad value. You want something like a weird pre-selected value of the checksum field meaning it is disabled or a special value of a byte which is choosen to be at a reasonable hamming distance from other meaningful values. If you look at the military IP security spec, you will see that they label the small number of special level values (SECRET, CONFIDENTIAL, etc., etc.) with strange values of a one byte field choosen so that they are unlikely to be corrupted into each other and none are particularly likely bit values in general (ie., none is zero or FF or ascii for space ...). Donald Return-Path: kaufman@zk3.dec.com Received: by abyss.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91); id AA08116; Thu, 17 Mar 1994 15:57:34 -0500 Message-Id: <9403172057.AA08116@abyss.zk3.dec.com> To: bound@zk3.dec.com Cc: dee@ranger.ENET.dec.com, kaufman@zk3.dec.com Subject: Re: Could I get your input on the attached thx /jim Date: Thu, 17 Mar 94 15:57:32 -0500 From: kaufman@zk3.dec.com X-Mts: smtp Any claim that a non-cryptographic checksum is useful for security purposes in IP is clearly nonsense. If the checksum slot permitted a cryptographic checksum, it might have value but I would be skeptical and would want to see the whole protocol before conceding that it was worth considering. There are other good arguments for an IP checksum - mostly protection from sloppy routers (and it's not like that situation is likely to get any better). But don't confuse that with "I could tell you but then I'd have to kill you" arguments. --Charlie Return-Path: dee@pathwk.ENET.dec.com Received: by abyss.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91); id AA11351; Thu, 17 Mar 1994 16:47:29 -0500 Date: Thu, 17 Mar 1994 16:47:25 -0500 Message-Id: <9403172147.AA11351@abyss.zk3.dec.com> From: dee@pathwk.ENET.dec.com (Donald Eastlake) To: kaufman@ABYSS.ENET.dec.com (Charles Kaufman dss) Cc: bound@abyss.ENET.dec.com, dee@ranger.ENET.dec.com Subject: Re: Could I get your input on the attached thx /jim I agree completely. A non-cryptographic checksum is for "integrity" not "security". Donald From bound@zk3.dec.com Sat Mar 19 14:22:02 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id OAA01252 for ; Sat, 19 Mar 1994 14:25:43 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA22346; Sat, 19 Mar 94 11:22:10 -0800 Received: by xirtlu.zk3.dec.com; id AA01511; Sat, 19 Mar 1994 14:22:08 -0500 Message-Id: <9403191922.AA01511@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: TUBA Transition Plan input fyi ... Date: Sat, 19 Mar 94 14:22:02 -0500 X-Mts: smtp ------- Forwarded Message Return-Path: bound Message-Id: <9403191907.AA01381@xirtlu.zk3.dec.com> To: dave@corecom.com Cc: bound@zk3.dec.com, tuba@Lanl.Gov Subject: Input: TUBA Transition Plan Date: Sat, 19 Mar 94 14:07:24 -0500 From: bound X-Mts: smtp Dave, Here is some input on the transition plan. Most are clarification questions so we can understand the implementation effect for transition. But I have also called out some questions when I could not understand the assumptions being made either technically or about the end users needs. Congrats on a very well written and technical spec to get us started with the TUBA transition discussion. Documents referenced that do not exist need to be completed so they can be verified against statements in the transition plan OK. So I am in holding pattern on those specs as far as them having an effect on the transition plan. Assumptions about CLNP are valid as an existing technology. But no IPng replacement has been tested to support the wide range of applications that exist in the Internet or the network management of this very complex transition task for the Internet. CLNP is certainly not deployed to the extent IPv4 is today as was stated. I ding the paper on this because I feel it over estimated the operational experience, trained personnel, and application experience in a multivendor host CLNP network, when compared to what has been accomplished and exists with TCP/IP. Also trained personnel should not just be limited in definition to network providers or site network managers, but any TCP/IP user that sets up a TCP/IP node on a network. Like me and you. In section 3. Tuba Overview there is a statement that TUBA satisfies the IPng objective of unlimited addressing. Unlimited addressing is not the objective of any requirements I have seen. Although all proposals could theoretically support such a strategy, I think we need to careful when we say unlimited addressing in any IPng specifications. Its like the cliche never say never. In section 4. Transition to TUBA/CLNP there is a statement that CLNP is provided to all sites. Is the proposal declaring a "flag day"? The reason I ask this now is that I do not believe it can be assumed early on in the transition that CLNP will be routable from every user site of the Internet or within every customer site that uses TCP/IP today as a network protocol to operate their day to day functions. There also seems to be an inherent requirement for a TUBA host to use CLNP; that CLNP must be supported by the next hop router as an assumption. CLNP interoperability early on in the transition should be possible over an IPv4 tunnel. I get into this more later on. Any IPng proposal that references statically configured tables for any function during transition, as in the proposals dual stack section, should give examples and provide text as to the essence of those tables. CLNP should not be required to access a DNS server that supports TUBA record types. Early on in the transition hosts will need TUBA DNS records and should be able to get them using IPv4 as the network layer protocol to access the DNS servers. This lets us deploy TUBA hosts that can use the DNS servers on the network that are only IPv4 capable from a network layer perspective but can contain TUBA DNS records. In the table for CLNP connectivity: ORIGIN RECIPIENT DNS_REPLY USE TUBA host TUBA host IPv4 addr IPv4 (2) TUBA host TUBA host IPv4 addr, CLNP (3) NSAP addr, I think we need more of an explanation on the effects to the network when CLNP (3) is used via tunneling. Also why not just send CLNP packets directly if the next hop router or host gateway supports CLNP interior routing and leave tunneling to points on the Internet where transit or interior routing domains do not support CLNP forwarding? This also gets at my previous comment regarding the papers assumption that CLNP would exists for hosts at all routers. It was stated that most routers are multiprotocol, hence, CLNP is supported in most cases. Thus there seems to be a contradiction in the table. If multiprotocol routers exist just send CLNP packets from the host at CLNP(3). But I suspect that all routers will not support CLNP during transition early on so IPv4 tunneling will be required. The proposal references both GRE and EON as a tunneling technique. I need some clarity here. Which, when, and how are they used. An IPng transition plan even though referencing other encapsulation proposals should still enter much technical detail as to how an IPng proposal will use those encapsulation techniques or parts they will not use. There should be an entire section with diagrams and technical discussion for TUBA encapsulation and provide the differentials for EON and GRE. This will permit us to understand any state changes and points of failure in the encapsulation strategy so we can cover that with our TUBA implementation prototypes to test this operationally. The statement that the Internet has several infrastructural components which must have dual stack functionality needs some clarification: 1) Network Service Providers. These are not computer systems? 2) DNS. See previous comment on DNS. You should be able to access DNS even if the DNS node only supports IPv4 but the DNS records can reflect the new TUBA record types. 3) IANA and Assignment function. Again this is not a node. 4. Hosts Hosts that become IPng capable. We cannot specify a flag day that all hosts support IPng to get started. The section on updating DNS Infrastructure needs to be checked against the transition strategy. I think some of us should go off line and talk this one out I think it can be much simpler than proposed. In section 4.1.4 Dual Stack and hosts. Well you know how I feel about the phrase dual stack for IPng so I won't go into it again. The types of preference listed has me worried to some degree as follows: (1) IPv4 only. This is OK. (2) Prefer IPv4. What is mean't by some other resolver or name server? Are you talking aobut DCE or ONC? I know of none others that are implemented to support a multivendor host environment name space? Lets stick to DNS for IPng. If we evolve past DNS for "TCP/IP" then fine but lets do one thing at time. Why would this case prefer an IPv4 path. Reasons are needed under this bullet. (3) Prefer CLNP. One problem that I don't think is necessary is that for this mode to take place it appears to me that the proposal is requiring that a CLNP next hop router exist to begin using CLNP preference level. This should not be the case. If users want to put a TUBA IPng host on an IPv4 subnet that is only IPv4 and only supports next hop IPv4 host gateway or router then they still should be able to communicate with other CLNP hosts off their IPv4 subnet via encapsulation early on during transition. (4) CLNP only. Yes but this is when host vendors could begin to ship CLNP only systems without IPv4 stacks. Not that they should but they could. The IETF cannot require vendors to ship both IPng and IPv4 on their end systems forever. That is a business decision each vendor will have to make. I think there needs to be a section in here regarding talking to non-intelligent host nodes like printers that use IPv4 today as part of the transition how to's. I also think it will be required to support IPng-only hosts talking to IPv4-only hosts before the IPv4 address space runs out. That is not assumed or addressed in this proposal. This transition proposal is requiring that a host support two network layers even if a host has no need of IPv4 anymore other than to send mail etc. But thats OK as a belief system and a strategy and its good it was clearly stated. There needs to be algorithms specified on the host to set the state of the type of packet to send in this transition proposal. In section 7.1 What packet to send stating something will set the granularity should have some examples and a technical discussion. In section 7.2 TCP and UDP connection identification for TUBA hosts it states that when communicating with another dual stack host TCP uses the full source and destination NSAP addresses. Is this not a contradiction to the previous statements on preference when the host uses IPv4 for connectivity. Unless the proposal is trying to address source and destination addresses for CLNP packets encapsulated in IPv4 and use of the DNS records? This is why I made a previous comment on the need for a technical section on TUBA tunneling/encapsulation in addition to references to GRE and EON. The ICMP message returned for IPng in TUBA should support greater than 8 octets. This will be important during tunneling and its to small in IPv4 today. We need to make sure we get as much of the offending packets as we need for error processing in IPng due to the bigger addresses and potential expanded field lengths. Under section 7.5 Transport API changes: 3) Un-Modified applications should provide as much TUBA/CLNP services as possible. I can't parse this what and how is this possible if the application does not know anything about TUBA? This needs more clarity. TUBA should have a formal API spec too and then it should be referenced by this transition plan. It should validate some of the application compatibility assumptions stated in the proposal. Network management tools. What we don't need from any IPng proposals transition strategy are dual implementations of tcpdump and other debugging tools. This should be handled transparent to the user based on address type. How that is done is most likely another document on IPng transition tools we might need from each proposal. Also any vague configuration file statements should be clearly articulated where they might exists and where the data will come from on the host based on the IPng implementation. This is too critical to leave less specified as we transition the Internet and live customers to IPng. This does not just apply to TUBA but any transition proposal. We do not want two network management interfaces. It can be done and I am willing to work offline if anyone is interested. New tools that only apply to IPng are cool. Would like to see specs addressing DHCP and BOOTP and how that relates to the TUBA Autoconfiguration transition plan. The reference to Mobility is not CLNP but CNLP. Also the present document states this is not part of the Mobility WG and is provided for Historical purposes. I am not sure TUBA really needs a Mobile spec per se. But how IS-IS, ES-IS, and IDRP solve problems like the half-link problem, attachment off the subnet of its address (or Area), and QOS requirements would be useful in some TUBA document. I don't think TUBA needs an Autoregistration spec but rather a technical verification that nothing in the Autoconfiguration proposal for TUBA would prevent dynamic Autoregistration with BIND DNS. I think we need to figure out Autoconfiguration with an architectural eye towards autoregistration and when we select an IPng let our DNS gurus figure out how to automate the funtion of Autoregistration. We need to see the proposal on flows for TUBA as there is no field now in CLNP to hold flow IDs. If a field is created we need to consider this in our prototype implementations. If the flow stratey is to create a flow ID without a new field we need to review if that will work. Do we believe there is consensus in TUBA WG that we don't need a security optional header for authentication? Do we want to leave all this to IPSEC WG. If they need extensions to CLNP its best we ask them now. I think the key management protocol should be transparent to TUBA. thanks for the hard work, /jim ------- End of Forwarded Message From bound@zk3.dec.com Sat Mar 19 16:44:28 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA01636 for ; Sat, 19 Mar 1994 16:45:53 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA00674; Sat, 19 Mar 94 13:44:39 -0800 Received: by xirtlu.zk3.dec.com; id AA02775; Sat, 19 Mar 1994 16:44:34 -0500 Message-Id: <9403192144.AA02775@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: ALE effector In-Reply-To: Your message of "Thu, 17 Mar 94 23:40:08 EST." <9403180440.AA29765@hsdndev.harvard.edu> Date: Sat, 19 Mar 94 16:44:28 -0500 X-Mts: smtp Scott, Heres my input. Regarding the recent RFC 1597 on private network address assignments. I don't care one way or the other about assignments of this nature. Don't tell me I have to use it and thats cool. Regarding it saving us IPv4 address space. I don't think it will amount to a great savings but every little bit helps. I don't see it as a big ALE effector. If anything in Digital and in many of my customer environments I am seeing the opposite of this input. I am hearing we want access to the Internet for our business to access the services available. An error in the paper (Daniel) is that Firewalls are application gateways. This should say one way to implement Firewalls is to build them as applications gateways. We have done it differently for example using packet screening and IPv4 tunnels. No application gateways. That should have been fixed before it became and RFC too. Routers also support Firewalls and they don't run applications per se like SMTP to VMSmail or FTP to FTAM, etc. What I don't want to see is this as a strategy to fix the IPv4 address space problem. That 'executable' is in CIDRs corner and if they can't do it they should tell us a.s.a.p. Finally I am not sure a lot of additional discussion on this topic will do us any good. We spent a lot of time on this previously. For example both the TUBA and SIPP transition plans are on the net and we need to get into those in depth a.s.a.p. and the requirements work. /jim From mankin@cmf.nrl.navy.mil Sun Mar 20 09:49:34 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with ESMTP id JAA04023 for ; Sun, 20 Mar 1994 09:49:36 -0500 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.7/8.6.6) id JAA16589 for ipng; Sun, 20 Mar 1994 09:49:34 -0500 Date: Sun, 20 Mar 1994 09:49:34 -0500 From: Allison J Mankin Message-Id: <199403201449.JAA16589@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: Monday agenda Hi, folks, this will be an informal agenda. As stated last week, our job is to complete our review of the Mar 10 requirements paper. We'll go through it carefully. We'd also like to have a list of the white paper points that should be added, if any of you have identified any that aren't really covered. After this review, and revisions, it has to go to the IETF and to the External Review Panel. There will only be a day or two after Monday to complete the revision (I hope that's possible) if we want there to be some lead time for reading before IETF. Your bearleader for Monday, Allison From brian@dxcoms.cern.ch Sun Mar 20 16:04:25 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 KAA04083 for ; Sun, 20 Mar 1994 10:04:59 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16896; Sun, 20 Mar 1994 16:03:50 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16441; Sun, 20 Mar 1994 16:04:26 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403201504.AA16441@dxcoms.cern.ch> Subject: Re: IPng dinner To: rcallon@pobox.wellfleet.com (Ross Callon) Date: Sun, 20 Mar 1994 16:04:25 +0100 (MET) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <9403182052.AA08492@pobox.wellfleet> from "Ross Callon" at Mar 18, 94 03:52:55 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: 180 I plan to be at the Aquarium on the social evening. Surely we are having a private meeting of the Directorate during the week, as well as the open meeting? When, where? Brian From mankin@cmf.nrl.navy.mil Sun Mar 20 10:17:58 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with ESMTP id KAA04143 for ; Sun, 20 Mar 1994 10:17:59 -0500 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.7/8.6.6) id KAA16635 for ipng@cmf.nrl.navy.mil; Sun, 20 Mar 1994 10:17:58 -0500 Date: Sun, 20 Mar 1994 10:17:58 -0500 From: Allison J Mankin Message-Id: <199403201517.KAA16635@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: re: IPng dinner I suggest that we schedule our IPng private meeting as a dinner plus meeting following the open IESG plenary on Thursday night. We can review the week and prepare for Friday rather well that time. (I hope there isn't an IESG dinner, Scott do you know?) Even so, I think this might be the only night we can count on. The IESG plenary ends about 7 PM. Allison From bound@zk3.dec.com Sun Mar 20 10:42:21 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id KAA04206; Sun, 20 Mar 1994 10:45:40 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA27537; Sun, 20 Mar 94 07:42:28 -0800 Received: by xirtlu.zk3.dec.com; id AA15987; Sun, 20 Mar 1994 10:42:27 -0500 Message-Id: <9403201542.AA15987@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng dinner In-Reply-To: Your message of "Sun, 20 Mar 94 10:17:58 EST." <199403201517.KAA16635@radegond.cmf.nrl.navy.mil> Date: Sun, 20 Mar 94 10:42:21 -0500 X-Mts: smtp May I please ask this be decided at tomorrows directorate con call as a courteousy to us. Last time we selected an evening a head of time and that worked out real good. The reason I ask is that I usually will meet with Digital folks in the city I am going to be in and in most cases with a customer too. In this case IPng has priority and I can work around that but notice is required. I can reschedule what I have planned but it would be great if a decision can be made tomorrow. What about Monday eve 5:30 - 7:30 this will get us back in time for ALE? p.s. the plenary ends at 7:30 p.m. I think. thanks /jim From jallard@microsoft.com Sun Mar 20 19:26:59 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id WAA05958 for ; Sun, 20 Mar 1994 22:30:56 -0500 From: jallard@microsoft.com Received: by netmail2.microsoft.com (5.65/25-eef) id AA22367; Sun, 20 Mar 94 19:32:02 -0800 Message-Id: <9403210332.AA22367@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sun, 20 Mar 94 19:32:01 PST To: ipng@cmf.nrl.navy.mil Subject: Re: IPng Requirements : Autoconfiguratin Forward Thinking Date: Sun, 20 Mar 94 19:26:59 >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. microsoft has taken an initial stab at the autoconfiguration problem for the next release of windows nt. a brief history of how we got to where we are: our initial product, lan manager (client-server file/print sharing technology) used 1001/1002 broadcasts to register and locate resources by name. history: lan manager (note LAN, notWAN) benefits: purely dynamic disadvantages: scalability one benefit with this scheme is that dhcp doesn't break it. the fact that SERVER1 changes an ip address across reboots, or even on the fly makes no difference to the client that broadcasts looking for it since SERVER1 will always respond with its own correct ip address. the obvious difficulty is locating resources across the router. netbios ipx gets by this by forwarding the registration/query/release broadcasts to all neighbors and bumping the hopcount. we obviously were uncomfortable with telling our customers to fwd bcasts worldwide on udp port 137, so we implemented a local hosts file for remote systems to override the bcast mechanism. hosts files are great for people that understand ip and manage systems, but lousy for the beancounter that just wants to save a spreadsheet across a router (what's a router?). so, we needed a name service. dns had lots of cool stuff we didn't need (e.g. heirarchical names, mx support, recursion, etc..), but lacked the one thing we did need - dynamic updates. what we did was take the 1001/1002 name registration/resolution frame format and ship them off to a nameserver (these are dns-derived packets) which supports a challenge/defense mechanism and does some simple replication with peers. we're calling this nameserver WINS - windows internet name server, and plan to ship it with windwos nt 3.5. what i'd like to see is wins and dns converge. specifically, enhance dns to accept simple datagram updates up name/address pairs and to expand the scope of wins to efficiently manage heirarchy, etc... unfortunately, the dns group thus far maintains that security of these mappings is very important and have resisted this proposal thus far. the demand that we're seeing with dhcp (also shipping in windows nt 3.5 and the next release of windows) will ultimately drive this to happening. i'd be happy to collaborate with anyone interested in pursuing this discussion further. specifically, in developing a concrete proposal for the protocol to update the dns. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From brian@dxcoms.cern.ch Mon Mar 21 08:11:58 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 CAA06483; Mon, 21 Mar 1994 02:12:32 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14484; Mon, 21 Mar 1994 08:11:22 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05779; Mon, 21 Mar 1994 08:11:58 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403210711.AA05779@dxcoms.cern.ch> Subject: Re: IPng dinner To: mankin@cmf.nrl.navy.mil (Allison J Mankin) Date: Mon, 21 Mar 1994 08:11:58 +0100 (MET) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <199403201517.KAA16635@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Mar 20, 94 10:17:58 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: 145 Thursday night is a good idea. Whatever you decide in the call, please post a message promptly for those of us who will miss the call. Brian From craig@BBN.COM Mon Mar 21 08:09:02 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 IAA07358 for ; Mon, 21 Mar 1994 08:12:39 -0500 Message-Id: <199403211312.IAA07358@picard.cmf.nrl.navy.mil> To: Lois Keiper cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Teleconference, UPDATE*** In-reply-to: Your message of Fri, 18 Mar 94 16:49:07 -0500. <9403181555.aa11615@IETF.CNRI.Reston.VA.US> Date: Mon, 21 Mar 94 08:09:02 -0500 From: Craig Partridge I'm on the road today (checking my e-mail before being off net all day) so I'll have to miss the teleconf. (Sigh..) Craig From craig@BBN.COM Mon Mar 21 08:21: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.7/8.6.4) with SMTP id IAA07445 for ; Mon, 21 Mar 1994 08:34:16 -0500 Message-Id: <199403211334.IAA07445@picard.cmf.nrl.navy.mil> To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Reqs: Checksum In-reply-to: Your message of Fri, 18 Mar 94 22:07:28 -0500. <9403190307.AA21993@xirtlu.zk3.dec.com> Date: Mon, 21 Mar 94 08:21:15 -0500 From: Craig Partridge Jim: One small point. One of the notes you forwarded repeated the line about the checksum protecting against data corruption, etc. That's typically viewed as what the *TCP* checksum does. The IP checksum just checksums the IP header (not the data), and is sufficiently useless to routers that most of them don't check it and just do the incremental update. Craig From lkeiper@IETF.CNRI.Reston.VA.US Mon Mar 21 10:12:49 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.7/8.6.4) with SMTP id KAA08688 for ; Mon, 21 Mar 1994 10:12:49 -0500 Date: Mon, 21 Mar 1994 10:12:49 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa02564; 21 Mar 94 10:10 EST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference, FINAL**** Cc: lkeiper@cnri.reston.va.us Message-ID: <9403211010.aa02564@IETF.CNRI.Reston.VA.US> FINAL************** >>> >>>The names marked with an asterisk are those who have confirmed participation >>>for the IPng teleconference scheduled for March 21, 1994 at 11:30 - 1:30 >>>EST. >>> >>>Please send your confirmation of participation and any corrections or changes >>>to lkeiper@cnri.reston.va.us. Many thanks! >>> >>> >>> *J. Allard 206-936-9031* >>> *Steve Bellovin 908-582-5886* >>> *Jim Bound 603-465-3130* >>> *Scott Bradner 617-495-3864* >>> -Ross Callon REGRETS >>> -Brian Carpenter REGRETS >>> ?Dave Clark 617-253-6003? >>> *Steve Coya 703-620-8990* >>> -Jon Crowcroft REGRETS >>> ?John Curran 617-873-4398? >>> ?Steve Deering 415-812-4839? >>> -Dino Farinacci REGRETS >>> *Eric Fleischman 206-957-5334* >>> -Paul Francis REGRETS >>> ?Daniel Karrenberg +31 20 592 5065? >>> *Frank Kastenholz 508-685-4000* >>> ?Mark Knopper 313-741-5445? >>> ?Allison Mankin 202-404-7030? >>> *Greg Minshall will call in* (may be late) >>> *Paul Mockapetris 310-822-1511* (may be late) >>> -Craig Partridge REGRETS >>> *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 -ER54769 in the orginators name, >>>Steve Coya. >>> >>>Thanks >>> >>> >>>Lois >>> >>> >> >> > Lois J. Keiper IETF Secretariat From kasten@mailserv-D.ftp.com Mon Mar 21 10:24:01 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 KAA08787 for ; Mon, 21 Mar 1994 10:24:49 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 21 Mar 1994 10:24:41 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01516; Mon, 21 Mar 94 10:24:01 EST Date: Mon, 21 Mar 94 10:24:01 EST Message-Id: <9403211524.AA01516@mailserv-D.ftp.com> To: craig@BBN.COM Subject: Re: IPng Reqs: Checksum From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Content-Length: 586 > One small point. One of the notes you forwarded repeated the line about > the checksum protecting against data corruption, etc. That's typically > viewed as what the *TCP* checksum does. The IP checksum just checksums the > IP header (not the data), and is sufficiently useless to routers that most > of them don't check it and just do the incremental update. This is especially true when one considers that most all common media have a CRC that is stronger than the IP checksum. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From mankin@radegond.cmf.nrl.navy.mil Mon Mar 21 12:30:18 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with ESMTP id MAA09583 for ; Mon, 21 Mar 1994 12:30:22 -0500 Received: from localhost.cmf.nrl.navy.mil (localhost.cmf.nrl.navy.mil [127.0.0.1]) by radegond.cmf.nrl.navy.mil (8.6.7/8.6.6) with SMTP id MAA00450 for ; Mon, 21 Mar 1994 12:30:19 -0500 Message-Id: <199403211730.MAA00450@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost.cmf.nrl.navy.mil didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil Subject: words about CLNP Date: Mon, 21 Mar 1994 12:30:18 -0500 From: Allison J Mankin We hope that the final recommendation produced by the IPng process would be evaluated by any organizations that would be considering revising CLNP or selecting a successor to CLNP, to see if the results would be applicable. We and the IETF share with the FIRP common goals of the continued growth of internetworking for global communications and industrial productivity. We would be quite pleased if the evaluations of other organizations result in the furtherance of these shared goals.