From owner-big-internet@munnari.oz.au Tue Dec 1 00:26:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24950; Tue, 1 Dec 1992 00:26:37 +1100 (from owner-big-internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23406; Mon, 30 Nov 1992 23:55:04 +1100 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA18134); Mon, 30 Nov 92 06:54:27 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9211301254.AA18134@is.rice.edu> Subject: Re: one person's view about recent IETF and IPv7 To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Mon, 30 Nov 92 6:54:27 CST Cc: big-internet@munnari.oz.au In-Reply-To: <9211300032.AA08572@Mordor.Stanford.EDU>; from "Dave Crocker" at Nov 29, 92 4:32 pm X-Mailer: ELM [version 2.3 PL11] Dave Crocker > communication. Perhaps you missed those discussions? (As in, "what > kind of a question are you asking? After 6 months of IPAE > work and discussion, I simply do not understand what you could possibly > be asking.) > There are some of us who weere not in on the telco confernece calls that made up much of the IPAE work (at least this was reported at the IETF) Were these calls transcribed and archived for others to look at? If not, it might be worth the effort to document how IPAE choices were arrived at. There is nothing quite like pointing at the archives to get the ground work in. Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Tue Dec 1 01:53:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28312; Tue, 1 Dec 1992 01:53:58 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28307; Tue, 1 Dec 1992 01:53:51 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA17729; Mon, 30 Nov 92 06:53:28 -0800 Message-Id: <9211301453.AA17729@Mordor.Stanford.EDU> To: Brian Carpenter CERN-CN Cc: yakov@watson.ibm.com, big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 09:22:15 +0700. <9211300822.AA20378@dxcern.cern.ch> Date: Mon, 30 Nov 92 06:53:27 -0800 From: Dave Crocker X-Mts: smtp Brian, At the second TUBA meeting in Washington it was agreed that a document detailing how TUBA satisfies the criteria will be written, once the criteria are written. Thanks for the clarification on this. However, I suggest that the decision is not in the best interests of the community, since it withholds useful information from that community. (I also had the understanding that the contendors were _expected_ to respond to the IESG Criteria list, in time for the recent IETF.) A policy of waiting, rather than deliverying whatever is reasonably possible, to facilitate community review, seems most odd to me. I'm sure that the decision isn't intended to be obstructionistic, but suspect that it looks that way. Dave From owner-Big-Internet@munnari.oz.au Tue Dec 1 02:06:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28696; Tue, 1 Dec 1992 02:06:20 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211301506.28696@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28691; Tue, 1 Dec 1992 02:06:11 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5965; Mon, 30 Nov 92 10:06:04 EST Date: Mon, 30 Nov 92 10:05:26 EST From: yakov@watson.ibm.com To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: one person's view about recent IETF and IPv7 Ref: Your note of Sun, 29 Nov 92 16:15:54 -0800 >You may recall that the community is felt to be under some time pressure >to fix the network address and table space limitations problems. Dave, The network address and table space limitations are *two* separate problems. While there is time pressure to solve both of these problems, the amount of pressure is different for each of these problems. The community was, in fact, under a heavy pressure to fix the table space limitation problem, and today we may proudly say that the community was able to react to this pressure in the best possible way -- in a record short time the community came up with the proposal to solve the table space limitation problem -- CIDR, and we are right now in the process of implementing and deploying this proposal. >Hence, I suggest that your offer to serialize the process, awaiting >consensus on the criteria does not, in fact, serve the community well. I am *not* suggesting that TUBA or IPAE/SIP or PIP should stop working on their proposals until the community would reach consensus on the criteria. Your interpretation of my mail is a gross misrepresentation of my position. The *only* thing I suggested is that spending time trying to write a document that describe how each proposal satisfies the criteria, where the criteria is a moving target, may not the most productive way to spend our efforts. Yakov From owner-Big-Internet@munnari.oz.au Tue Dec 1 02:12:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28846; Tue, 1 Dec 1992 02:12:24 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28840; Tue, 1 Dec 1992 02:12:12 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA17815; Mon, 30 Nov 92 07:12:05 -0800 Message-Id: <9211301512.AA17815@Mordor.Stanford.EDU> To: bmanning@is.rice.edu (William Manning) Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 06:54:27 -0600. <9211301254.AA18134@is.rice.edu> Date: Mon, 30 Nov 92 07:12:05 -0800 From: Dave Crocker X-Mts: smtp Bill, concerning the record for IPAE meetings: I owe Megan 'minutes of interim meetings' for inclusion in the IETF proceedings. But such things never do justice to the actual discussions. To date, the IPAE spec and the published response to the Criteria list(s) are the best records we have for the utility of the features (tho not for the juggling of alternatives.) At base, the logic behind the working group's choices is simple: People need transition options. We provide them. A somewhat more verbose explanation is that large-scale transition processes -- particularly when they inolve many independent administrations -- must have alternatives available which reduce the critical interoperability dependencies, so that two willing hosts or a small collection of willing routers, can use the new technology, independent of its use by others. IPAE let's a family of routers convert and immediately obtain table compression (assuming they currently use global tables). It also allows hosts to convert, without waiting for their routers, tho there doesn't seem to be any major "benefit" they derive from the new protocol, until we run out of IP network addresses. (This assertion applies to _all_ of the contendors, at this stage.) For host interoperability, I will comment that the assertion of universal CLNP availability is one I would like to see far better documented, before we ask the entire community to rely on it. While it is available in most/all of the so-called Internet backbone, it is far less obvious that it is available in most/all of the leaf (end-user) networks. IPAE doesn't require all leaf (interior) routers to be running SIP prior to the use of SIP by hosts. Dave From owner-Big-Internet@munnari.oz.au Tue Dec 1 02:30:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29665; Tue, 1 Dec 1992 02:30:57 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29662; Tue, 1 Dec 1992 02:30:51 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA18167; Mon, 30 Nov 92 07:30:47 -0800 Message-Id: <9211301530.AA18167@Mordor.Stanford.EDU> To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 10:05:26 -0500. <9211301506.AA17791@Mordor.Stanford.EDU> Date: Mon, 30 Nov 92 07:30:46 -0800 From: Dave Crocker X-Mts: smtp Yakov, solve the table space limitation problem -- CIDR, and we are right now in the process of implementing and deploying this proposal. What is the schedule for CIDR deployment? What will be the schedule for its benefits? As I understand CIDR, it is a long way from deployment and requires quite a bit of global coordination to work. While it clearly is the best alternative available, to date, I suggest that the problems it addresses (oops, pun) are so serious that we would be very, very well-advised to encourage additional (complementary) solutions, when they appear. IPAE happens to offer one. I am *not* suggesting that TUBA or IPAE/SIP or PIP should stop working on their proposals until the community would reach consensus on the criteria. Your interpretation of my mail is a gross misrepresentatio Fine. But I didn't suggest that you had. Re-read my note. My concern is that you are doing the community a disservice by withholding a discussion paper that would provide a useful basis for community discussion, particularly since it would provide a common framework for all three contendors. of my position. The *only* thing I suggested is that spending time trying to write a document that describe how each proposal satisfies the criteria, where the criteria is a moving target, may not the most productive way to spend our efforts. Yakov, Life is a moving target. The IESG published a criteria list for the contendors to respond to, in time for the recent IETF meeting. The purpose of that list and its responses was/is to give the community more information to chew on. It sounds to me as if you are trying to redefine things on the fly. If two of the contendors were able to respond, I can't imagine why TUBA couldn't. Again, I assert that the absence of the effort and the absence of the criteria response, is simply not helpful to the community. Dave From owner-Big-Internet@munnari.oz.au Tue Dec 1 03:04:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00785; Tue, 1 Dec 1992 03:04:48 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00778; Tue, 1 Dec 1992 03:04:35 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08485; Mon, 30 Nov 92 11:04:27 -0500 Date: Mon, 30 Nov 92 11:04:27 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211301604.AA08485@ginger.lcs.mit.edu> To: brian@dxcern.cern.ch, dcrocker@mordor.stanford.edu Subject: Re: one person's view about recent IETF and IPv7 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I'm sure that the decision isn't intended to be obstructionistic, but suspect that it looks that way. I think that's a bit extreme; I certainly don't see that. I just see a limited set of resources, and a "decision process" that, much as the IESG has put time and energy into it, is not really the critical point. This is not to say that the IESG's time and energy was wasted; the criteria documents provide a useful mental framework for looking at protocols, and the debate over what criteria are important have made it clear that different communities have very different priorities, which helps tamp down miscommunication. However, let's be realistic; it's prefectly rational to sit down and say "producing this document is not the most critical use of limited resources". I will note, in this context, that what we are really trying to solve here is a routing problem, and *neither* routing camp filled out this document either. (So slap my wrist! :-) Noel From owner-Big-Internet@munnari.oz.au Tue Dec 1 03:07:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00899; Tue, 1 Dec 1992 03:07:49 +1100 (from owner-Big-Internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00875; Tue, 1 Dec 1992 03:07:36 +1100 (from brian@dxcern.cern.ch) Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02051; Mon, 30 Nov 1992 17:07:19 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA02421; Mon, 30 Nov 92 17:07:11 +0100 Message-Id: <9211301607.AA02421@dxcern.cern.ch> Subject: Re: one person's view about recent IETF and IPv7 To: Dave Crocker Date: Mon, 30 Nov 92 17:07:11 MET From: Brian Carpenter CERN-CN Cc: yakov@watson.ibm.com, big-internet@munnari.oz.au, bmanning@is.rice.edu In-Reply-To: <9211301453.AA17729@Mordor.Stanford.EDU>; from "Dave Crocker" at Nov 30, 92 6:53 am X-Mailer: ELM [version 2.3 PL11 CERN 11] Glug?? AARgh? Did I say something wrong? There are no secrets here, but I assumed that the big-internet list should not be wasted on preliminary versions of such documents. We did have a non-consensus version of a response to the IESG list before Washington but it was only sent to the tuba list (and contained bugs). I haven't yet seen a writeup of the new post-Washington list; we need it to update the tuba response. It shall be done, and posted as soon as reasonably debugged. Brian >--------- Text sent by Dave Crocker follows: > > Brian, > > At the second TUBA meeting in Washington it was > agreed that a document detailing how TUBA satisfies > the criteria will be written, once the criteria are written. > > Thanks for the clarification on this. > > However, I suggest that the decision is not in the best interests of > the community, since it withholds useful information from that > community. (I also had the understanding that the contendors were > _expected_ to respond to the IESG Criteria list, in time for the > recent IETF.) A policy of waiting, rather than deliverying whatever > is reasonably possible, to facilitate community review, seems > most odd to me. I'm sure that the decision isn't intended to be > obstructionistic, but suspect that it looks that way. > > Dave > From owner-Big-Internet@munnari.oz.au Tue Dec 1 04:53:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03556; Tue, 1 Dec 1992 04:53:52 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03542; Tue, 1 Dec 1992 04:53:38 +1100 (from kasten@ftp.com) Received: by ftp.com id AA02896; Mon, 30 Nov 92 12:53:38 -0500 Date: Mon, 30 Nov 92 12:53:38 -0500 Message-Id: <9211301753.AA02896@ftp.com> To: peter@goshawk.lanl.gov Subject: Re: one person's view about recent IETF and IPv7 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com, big-internet@munnari.oz.au There is no need to change the network management framework. SNMP is defined as running over UDP. There is no definition of what UDP runs over :-) SNMP-over-UDP works if UDP runs over: - IPv4 - SIP/IPAE - TUBA - raw datalink > In terms of how SNMP should work over CLNP, I will defer to Marshall or > any other SNMP guru as to how RFC1283 ( Rose, M. SNMP over OSI. > 1991 December ) should be updated in light of TUBA (or for SNMP v2 > for that matter). I can imagine there will need to be some MIB work > done for TCP/UDP over CLNP. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Dec 1 04:53:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03550; Tue, 1 Dec 1992 04:53:50 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03539; Tue, 1 Dec 1992 04:53:33 +1100 (from kasten@ftp.com) Received: by ftp.com id AA02887; Mon, 30 Nov 92 12:53:33 -0500 Date: Mon, 30 Nov 92 12:53:33 -0500 Message-Id: <9211301753.AA02887@ftp.com> To: peter@goshawk.lanl.gov Subject: Re: FYI: one person's view about recent IETF and IPv7 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: dcrocker@Mordor.Stanford.EDU, dave@sabre.bellcore.com, big-internet@munnari.oz.au > Perhaps we should put 'impact on end users' on the criteria list. Peter, While this is an important issue, couldn't we assume that it would be met by ensuring that DNS is upgraded properly to handle the new address/identification models and formats for the proposed protocols? Also, since "end users" typically use applications (e.g. telnet in your note) hat this reduces to is saying that the app's must present an interface to the user that does not require the user to know what the protocol is; telnet mordor.stanford.edu will work. I.e., one would not type something like telnet --protocol=tuba mordor.stanford.edu This then becomes a matter for the application writers, not the IP writers. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Dec 1 04:53:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03561; Tue, 1 Dec 1992 04:53:56 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03546; Tue, 1 Dec 1992 04:53:44 +1100 (from kasten@ftp.com) Received: by ftp.com id AA02884; Mon, 30 Nov 92 12:53:31 -0500 Date: Mon, 30 Nov 92 12:53:31 -0500 Message-Id: <9211301753.AA02884@ftp.com> To: tsuchiya@thumper.bellcore.com Subject: Re: one person's view about recent IETF and IPv7 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au, craig@aland.bbn.com > C: > C: We heard three presentations on IPv7 proposals: PIP, SIP and TUBA. > C: Paul started the PIP talk with an announcement that the PIP spec wouldn't > C: be ready for another year, at which point a large number of folks walked > > No, I didn't say the Pip spec wouldn't be ready for another year, I > said that it would be a year before anybody could really confidently > choose Pip as the next generation IP. The Pip specs are already half > done, and I expect pretty solid specs in 3 months. What I hope for > in one year are prototypes and enough experience that we can make a > real decision concerning Pip. Paul This is what you said. Craig's note recounted what most people heard. I agree with the rest of your post too -- Frank Kastenholz rvices need be upgraded, and only when they need them. -- frank kastenholz From owner-big-internet@munnari.oz.au Tue Dec 1 07:16:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06291; Tue, 1 Dec 1992 07:16:29 +1100 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01264; Tue, 1 Dec 1992 03:25:39 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA19012; Mon, 30 Nov 92 08:25:18 -0800 Message-Id: <9211301625.AA19012@Mordor.Stanford.EDU> To: Brian Carpenter CERN-CN Cc: yakov@watson.ibm.com, big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 17:07:11 +0700. <9211301607.AA02421@dxcern.cern.ch> Date: Mon, 30 Nov 92 08:25:18 -0800 From: Dave Crocker X-Mts: smtp Brian, Glug?? AARgh? Did I say something wrong? There are no secrets No, you said something right. I know that my tone is coming off stronger than is wise, but I think we all have an obligation to provide the community with the best available basis (bases?) for making comparisons and I was frankly somewhat irked to note the absence of the TUBA contribution. (Hinden has freely offered his draft as base, the same as it served for PIP, as long as he gets to be co-author...) response. It shall be done, and posted as soon as reasonably debugged. Many thanks. Dave From owner-big-internet@munnari.oz.au Tue Dec 1 07:59:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07273; Tue, 1 Dec 1992 08:00:06 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211302100.7273@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05440; Tue, 1 Dec 1992 06:33:59 +1100 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <00902-0@datanet.tele.fi>; Mon, 30 Nov 1992 21:33:16 +0200 To: dcrocker@Mordor.Stanford.EDU Cc: jcurran@nic.near.net, tuba@lanl.gov, mrose@dbc.mtview.ca.us, peter@goshawk.LANL.GOV, big-internet@munnari.oz.au In-Reply-To: <9211301917.AA21706@Mordor.Stanford.EDU> "dcrocker@Mordor.Stanford.EDU" Subject: one person's view about recent IETF and IPv7 Date: Mon, 30 Nov 1992 21:33:16 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi a host being listed in the DNS has nothing to do with the host being reachable from anywhere. being "reachable from the Internet" doesn't mean anything either, since what is Internet today? -- juha From owner-big-internet@munnari.oz.au Tue Dec 1 11:19:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11929; Tue, 1 Dec 1992 11:19:47 +1100 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02031; Tue, 1 Dec 1992 03:58:18 +1100 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA21945; Mon, 30 Nov 92 11:58:02 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA19104; Mon, 30 Nov 92 08:56:34 PST Message-Id: <9211301656.AA19104@aland.bbn.com> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: having the market decide From: Craig Partridge Date: Mon, 30 Nov 92 08:56:33 -0800 Sender: craig@aland.bbn.com > I believe you are making my point. People were trying to decide > instead of letting natural selection take place. Shouldn't the process > be to push ideas/documents/implementations out for critical review and > acceptance and then see if we observe survival and progeny? Peter: I'd like to expand on this comment. It seems to me that there are two separate steps to the selection process that need to be dealt with. First, assessing the technical solidity of a proposal. The market (however defined, and apologies to Jon C's stomach) is not in a position to figure out if a proposal will scale to billions of end systems, work nicely for multimedia, etc. The market generally expects someone else (their vendor, standards groups, whatever) to technically vet proposals. Second, assessing the desirability of a proposal. For example, there are lots of folks who will argue strongly that mobility, flow support, self configuration, interoperability with other protocols, or some other useful feature should be part of IPv7. That's a utility argument that I think consumers make pretty well. So it seems to me that IETF has a real obligation to technically vet proposals and be clear about their relative technical strengths and weaknesses. Getting the proposals elevated to Proposed Standard is at least part of this process; doing experimental deployments is another. At some point it is then necessary to sit back and see what consumers want to buy. We didn't handle this process as cleanly as we might have for SNMP/CMOT. Having had the experience, I'd like to see us do it better this time around. Craig From owner-big-internet@munnari.oz.au Tue Dec 1 11:44:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12578; Tue, 1 Dec 1992 11:44:21 +1100 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03287; Tue, 1 Dec 1992 04:44:36 +1100 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28336; Mon, 30 Nov 92 12:44:24 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA19355; Mon, 30 Nov 92 09:42:55 PST Message-Id: <9211301742.AA19355@aland.bbn.com> To: Paul Tsuchiya Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 From: Craig Partridge Date: Mon, 30 Nov 92 09:42:55 -0800 Sender: craig@aland.bbn.com >C: >C: We heard three presentations on IPv7 proposals: PIP, SIP and TUBA. >C: Paul started the PIP talk with an announcement that the PIP spec wouldn't >C: be ready for another year, at which point a large number of folks walked > > No, I didn't say the Pip spec wouldn't be ready for another year, I > said that it would be a year before anybody could really confidently > choose Pip as the next generation IP. The Pip specs are already half > done, and I expect pretty solid specs in 3 months. What I hope for > in one year are prototypes and enough experience that we can make a > real decision concerning Pip. Paul: Thanks for the clarification -- I think this probably describes the status of all the projects. However (speaking now as a reporter who simply tried to describe what he heard) it is true that I found a lot of folks in the halls who mis-interpreted your opening statement as I did. Craig From owner-big-internet@munnari.oz.au Tue Dec 1 12:10:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13287; Tue, 1 Dec 1992 12:10:06 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212010110.13287@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03778; Tue, 1 Dec 1992 05:10:50 +1100 (from jcurran@nic.near.net) To: tuba@lanl.gov Cc: Dave Crocker , mrose@dbc.mtview.ca.us, peter@goshawk.lanl.gov, big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Sat, 28 Nov 92 15:09:29 -0800. <9211282309.AA27625@Mordor.Stanford.EDU> Date: Mon, 30 Nov 92 13:10:18 -0500 From: John Curran -------- Some quick replies for clarity... I recommend that the subsequent discussion go to tuba mailing list. /John --- ] From: Dave Crocker ] Subject: Re: one person's view about recent IETF and IPv7 ] Date: Sat, 28 Nov 92 15:09:29 -0800 ] ] Peter, ] ] While all entities in the Internet are still IP reachable, the issue of ] whether you get to it via CLNP or IP does not seem to be such a big ] deal. ] ] Seems like a big deal to me. How is the sender to make the selection ] between IPv4 and TUBA? The Tuba doc says 'look in the DNS'. This, ] unfortunately, only works if _all_ the intermediate routers support ] _both_ IPv4 and TUBA. They don't now and it seems unwise to have this ] critical dependency. In general, IP hosts are listed in the public DNS database when they are reachable from the Internet. Likewise, there is an emerging CLNP Internet and I would not expect to find a DNS record for TUBA host unless it was connected to the CLNP infrastructure. --- ] From: Marshall Rose ] Subject: Re: one person's view about recent IETF and IPv7 ] Date: Sun, 29 Nov 1992 02:32:28 -0800 ] ] I thought TUBA was about running TCP and UDP over ~CLNP. While a box ] might have IPv4 in addition to TUBA, it is difficult to imagine someone ] saying "manage the TUBA box using SNMP/UDP/IPv4". I would expect them ] to say "manage the TUBA box using SNMP/TUBA". TUBA hosts speak TUBA/CLNP and IPv4. TUBA-compatible routers have to support both IP and CLNP, but do not necessarily have to support TUBA during initial deployment. Management via IPv4 will continue to work until IPv4 routing fails or IPv4 network number depletion strikes. By that time, routers _will_ need to support TUBA specification for management purposes. I believe Peter was trying to get across the point that software in many of the routers does not have to be updated before TUBA host software can be deployed. Given TUBA's dual-stack migration strategy, not having to wait for coordinated infrastructure changes helps deployment significantly. From owner-big-internet@munnari.oz.au Tue Dec 1 12:55:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15159; Tue, 1 Dec 1992 12:55:53 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212010155.15159@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07153; Tue, 1 Dec 1992 07:53:46 +1100 (from jcurran@nic.near.net) To: Dave Crocker Cc: tuba@lanl.gov, big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Mon, 30 Nov 92 11:17:23 -0800. <9211301917.AA21706@Mordor.Stanford.EDU> Date: Mon, 30 Nov 92 15:53:27 -0500 From: John Curran -------- ] From: Dave Crocker ] Subject: Re: one person's view about recent IETF and IPv7 ] Date: Mon, 30 Nov 92 11:17:23 -0800 ] ] John, ] ] Some quick replies for clarity... I recommend that the subsequent ] discussion go to tuba mailing list. ] ] I'm keeping this on the big-internet list because I believe that you've ] phrased the DNS issue in a way which goes beyond any particular proposal ] and I think it would be helpful to treat it generically. ] ] In general, IP hosts are listed in the public DNS database when they are ] reachable from the Internet. Likewise, there is an emerging CLNP Internet ] ] The generic issue is one of introducing _any_ second protocol stack and ] what it means to be listed in the Internet's DNS. For IP, there was ] only one source of connectivity, so IP support by intermediate routers ] has always been implicit. For a new stack, I believe this is not ] true. Okay, I see from Juha's message below that there are different views in this area. There is always the possibility that DNS records will contain addresses which the majority of the Internet community cannot reach. This situation exists presently for IP (particularly with the advent of corporate firewalls) and CLNP is no better or worse off in this area. For a lot of us, the term "CLNP Internet" is meaningful, and whether you're connected to the Internet via CLNP is readily determined. The network osi operations (noop) WG generally includes a status update at each IETF; there should be a reference to the connectivity map in the minutes. /John --- From: Juha Heinanen Subject: one person's view about recent IETF and IPv7 Date: Mon, 30 Nov 1992 21:33:16 +0200 a host being listed in the DNS has nothing to do with the host being reachable from anywhere. being "reachable from the Internet" doesn't mean anything either, since what is Internet today? -- juha From owner-big-internet@munnari.oz.au Tue Dec 1 13:31:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16498; Tue, 1 Dec 1992 13:31:49 +1100 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07504; Tue, 1 Dec 1992 08:16:23 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA23679; Mon, 30 Nov 92 13:16:00 -0800 Message-Id: <9211302116.AA23679@Mordor.Stanford.EDU> To: kasten@ftp.com Cc: peter@goshawk.lanl.gov, dave@sabre.bellcore.com, big-internet@munnari.oz.au Subject: Re: FYI: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 12:53:33 -0500. <9211301753.AA02887@ftp.com> Date: Mon, 30 Nov 92 13:16:00 -0800 From: Dave Crocker X-Mts: smtp Well now, this _is_ turning into an interesting day... > Perhaps we should put 'impact on end users' on the criteria list. Peter, While this is an important issue, couldn't we assume that it would be met by ensuring that DNS is upgraded properly to handle the new I am entirely in agreement with Peter. Frank, I believe that end-user impact is far more complicated than simply involving the DNS. Issues of service disruption and degree of visbility to the transition have a direct impact on users. address/identification models and formats for the proposed protocols? an interface to the user that does not require the user to know what the protocol is; telnet mordor.stanford.edu will work. I.e., one would not type something like telnet --protocol=tuba mordor.stanford.edu Yup. This then becomes a matter for the application writers, not the IP writers. Only as long as the IP-layer writer provide a sufficiently robust environment to make it operationally reasonable to "hide" the protocol choice from the end-user. Dave From owner-big-internet@munnari.oz.au Tue Dec 1 13:55:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17353; Tue, 1 Dec 1992 13:55:57 +1100 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07598; Tue, 1 Dec 1992 08:21:10 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA23732; Mon, 30 Nov 92 13:20:58 -0800 Message-Id: <9211302120.AA23732@Mordor.Stanford.EDU> To: John Curran Cc: tuba@lanl.gov, big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 15:53:27 -0500. <9211302053.AA23198@Mordor.Stanford.EDU> Date: Mon, 30 Nov 92 13:20:58 -0800 From: Dave Crocker X-Mts: smtp John, this area. There is always the possibility that DNS records will contain addresses which the majority of the Internet community cannot reach. This situation exists presently for IP (particularly with the advent of corporate firewalls) and CLNP is no better or worse off in this area. >From a theorectical standpoint, you are correct. However, I believe the statistics of current operations, versus those certain for any second stack, make a big difference. My own experience with the list-but-unavailable phenomenon is particularly prevalent with MX (mail recipient) records, but that the unavailable addresses are only part of a list. hence, other addresses which _are_ accessible are also listed. It doesn't seem as if that will be true for the second stack. connected to the Internet via CLNP is readily determined. The network osi operations (noop) WG generally includes a status update at each IETF; there should be a reference to the connectivity map in the minutes. Does this mean that an end-user should consult your connectivity map, prior to attempting to access a CLNP host? Dave From owner-big-internet@munnari.oz.au Tue Dec 1 14:44:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19031; Tue, 1 Dec 1992 14:44:42 +1100 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05126; Tue, 1 Dec 1992 06:17:51 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA21706; Mon, 30 Nov 92 11:17:24 -0800 Message-Id: <9211301917.AA21706@Mordor.Stanford.EDU> To: John Curran Cc: tuba@lanl.gov, mrose@dbc.mtview.ca.us, peter@goshawk.lanl.gov, big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 13:10:18 -0500. <9211301810.AA20756@Mordor.Stanford.EDU> Date: Mon, 30 Nov 92 11:17:23 -0800 From: Dave Crocker X-Mts: smtp John, Some quick replies for clarity... I recommend that the subsequent discussion go to tuba mailing list. I'm keeping this on the big-internet list because I believe that you've phrased the DNS issue in a way which goes beyond any particular proposal and I think it would be helpful to treat it generically. In general, IP hosts are listed in the public DNS database when they are reachable from the Internet. Likewise, there is an emerging CLNP Internet The generic issue is one of introducing _any_ second protocol stack and what it means to be listed in the Internet's DNS. For IP, there was only one source of connectivity, so IP support by intermediate routers has always been implicit. For a new stack, I believe this is not true. Worse, we don't really have a way for hosts to get a good indication of connectivity, other than to send a packet coded in the new protocol. Sending it successfully is definitive. Having it rejected (or fall into a black hole) is _not_ definitive. This sounds, to me, like a serious impediment to global transition. While IPAE has a response to it, through tunneling and internet-layer translation, I am interested in the generic question of handling the transition by a pure second-stack approach, without tunneling, since there seems to be a strong constituency for that appproach. TUBA hosts speak TUBA/CLNP and IPv4. TUBA-compatible routers have to support both IP and CLNP, but do not necessarily have to support TUBA i.e., end-to-end for TUBA would not necessarily be available? during initial deployment. Management via IPv4 will continue to work until IPv4 routing fails or IPv4 network number depletion strikes. i.e., end-to-end TUBA-based SNMP support would not necessarily be available? By that time, routers _will_ need to support TUBA specification for management purposes. My concern is that this implicitly defines the Network Exhaustion date as the formal cut-over date, albeit with a long lead-time to it. That is, connectivity via the new protocol would be entirely hit-or-miss until we drop off the cliff; then there would be a period of disruption while unconverted links get the new protocol added; and only _then_ do we get true, Internet-wide support for the new stack. To repeat, I intend this note as a generic dual-stack probe, rather than being specific to TUBA. Is it true that the community (including end-user organizations) are comfortable with this model of conversion??? Dave From owner-big-internet@munnari.oz.au Tue Dec 1 15:23:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20340; Tue, 1 Dec 1992 15:24:07 +1100 (from owner-big-internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06391; Tue, 1 Dec 1992 07:20:38 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA05294; Mon, 30 Nov 92 15:18:32 -0500 Date: Mon, 30 Nov 92 15:18:32 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9211302018.AA05294@er.doe.gov> To: big-internet@munnari.oz.au From owner-Big-Internet@munnari.oz.au Sun Nov 29 14:39:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21786; Mon, 30 Nov 1992 03:37:47 +1100 (from owner-Big-Internet) Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21759; Mon, 30 Nov 1992 03:36:38 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06084; Sun, 29 Nov 92 11:36:09 -0500 Date: Sun, 29 Nov 92 11:36:09 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211291636.AA06084@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, peter@goshawk.lanl.gov Subject: Re: one person's view about recent IETF and IPv7 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Status: R In the end with H/C/S, natural selection seems to have won out and rendered much of the earlier decision processing moot. ... Anyways, the point of my note is that many seem to be making the same mistake the IAB was accused of, in that there is a decision to be made so let's make it as soon as possible ... We certainly can drive the process by working hard on the various proposals, ... but I argue we shouldn't get too caught up with making *the* decision. >With H/C/S the situation was VERY DIFFERENT, the absence of standard >network management protocols did not make global connectivity impossible which >multiple incompatible network protocols could. The more I think about these, the more I agree. This debate is midly interesting, but when it's said and done, what has it really accomplished? How many minds will have been changed? Perhaps we should all stop arguing, since that clearly is not going to produce closure, as (painfully :-) demonstrated oevr the last couple of months, and go off and design, implement and deploy stuff? >Implementing and deploying "stuff" is fine; however, it may be weakly coupled >to the problem facing the operational nets. Note that it takes an RBOC approx. 2 years even to introduce a new area code (1year to warn people, 1 year when >both work) which is a much simpler issue than introducing a new protocol. >Also note that perhaps the most critical feature of a protocol is the # >of folks it connects you to. Now I think it is clear to all on this list that >NONE of the proposed protocols will be ready for wide scale deployment within >the critical next 24 months. > >What is desperately needed for the next 24 months, although perhaps not from this >group is a strategy for a set of tools to hide protocol and address structure >changes from users of the net. in the case of an internetwork layer protocol I believe we will see the necessary consensus emerge. I agree. The desirability of unbiquitous communication does tend to drive people toward a common communication substructure. Isn't there some statistic to the effect that some number of obscure human languages die off each year? Same principle... Noel >Having lived through Decnet vs IP protocol wars and watched the wealth of PC, MAC,... protocols which have sprung up, I suspect that the speed of >this consensus emergence is VERY SLOW...In fact the second law of thermodynamics, Mr. Murphy, and the attractiveness of local optimizations all work against this! This is not to say that lowest common denominator e-mail, file transfer, and virtual terminal can't be made to work. D Hitchcock From owner-big-internet@munnari.oz.au Tue Dec 1 15:49:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21146; Tue, 1 Dec 1992 15:49:53 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212010449.21146@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09715; Tue, 1 Dec 1992 09:51:39 +1100 (from jcurran@nic.near.net) To: big-internet@munnari.oz.au Cc: tuba@lanl.gov, Dave Crocker Subject: DNS issues (Re: one person's view about recent IETF and IPv7) In-Reply-To: Your message of Mon, 30 Nov 92 13:20:58 -0800. <9211302120.AA23732@Mordor.Stanford.EDU> Date: Mon, 30 Nov 92 17:51:23 -0500 From: John Curran -------- ] From: Dave Crocker ] Subject: Re: one person's view about recent IETF and IPv7 ] Date: Mon, 30 Nov 92 13:20:58 -0800 ] ] My own experience with the list-but-unavailable phenomenon is particularly ] prevalent with MX (mail recipient) records, but that the unavailable ] addresses are only part of a list. hence, other addresses which _are_ ] accessible are also listed. It doesn't seem as if that will be true ] for the second stack. I called Dave for some assistance in parsing this, and am in synch now. He noted that a host which adds a CLNP record for a unreachable address would becomes unavailable (from other dual-stack systems) and that such an event could easily occur during transition. This is a nice deployment pitfall to be avoided. Another colorful implication of using DNS records for stack selection is the potential loss of connectivity due to mismatching TTL's and DNS caching. If a DNS server has cached the address record for one stack (but the other stack address record has expired), the DNS server will return a partial response for searches of type any. It is necessary to perform a specific query for the type in question, or constrain the TTL's to avoid this. We generally agreed that it would be good if operational ramifications (like the above) were fleshed out as the proposals mature. /John From owner-big-internet@munnari.oz.au Tue Dec 1 17:22:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24035; Tue, 1 Dec 1992 17:22:11 +1100 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12213; Tue, 1 Dec 1992 11:30:15 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA26797; Mon, 30 Nov 92 16:30:02 -0800 Message-Id: <9212010030.AA26797@Mordor.Stanford.EDU> To: John Curran Cc: big-internet@munnari.oz.au, tuba@lanl.gov Subject: Re: DNS issues (Re: one person's view about recent IETF and IPv7) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 17:51:23 -0500. <9211302251.AA25537@Mordor.Stanford.EDU> Date: Mon, 30 Nov 92 16:30:01 -0800 From: Dave Crocker X-Mts: smtp ack. thanks for the summary. d/ From owner-big-internet@munnari.oz.au Tue Dec 1 22:13:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03586; Tue, 1 Dec 1992 22:13:43 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212011113.3586@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17843; Tue, 1 Dec 1992 14:10:47 +1100 (from jcurran@nic.near.net) To: Craig Partridge Cc: peter@goshawk.lanl.gov, big-internet@munnari.oz.au Subject: Re: having the market decide In-Reply-To: Your message of Mon, 30 Nov 92 08:56:33 -0800. <9211301656.AA19104@aland.bbn.com> Date: Mon, 30 Nov 92 22:10:16 -0500 From: John Curran -------- ] From: Craig Partridge ] Subject: having the market decide ] Date: Mon, 30 Nov 92 08:56:33 -0800 ] ] ... ] So it seems to me that IETF has a real obligation to technically vet ] proposals and be clear about their relative technical strengths and ] weaknesses. Agreed. The IETF has an obligation to assess the technical merits of the proposals and make clear statements regarding how proposals satisfy IETF criteria. In particular, this means determining if any of proposals are technically flawed and unable to perform the task at hand. Market forces may not be a major issue in this case, since any valid shortcomings should result the proposal either being corrected or withdrawn by the appropriate WG. At this time, I don't think that IETF has a role beyond reviewing the proposals and encouraging working group progress. It is possible that a single proposal might be selected sometime (once the ramifications of each are better understood) but this this will require great vision and courage if it is to be done in advance of clear market pressure. /John From owner-big-internet@munnari.oz.au Wed Dec 2 03:30:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13565; Wed, 2 Dec 1992 03:30:44 +1100 (from owner-big-internet) Return-Path: Received: from boa-f.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08626; Wed, 2 Dec 1992 00:54:26 +1100 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA11832; Tue, 1 Dec 1992 08:54:12 -0500 Message-Id: <9212011354.AA11832@boa.gsfc.nasa.gov> Subject: Re: having the market decide To: craig@aland.bbn.com (Craig Partridge) Date: Tue, 1 Dec 92 8:54:11 EST From: Dick desJardins Cc: big-internet@munnari.oz.au In-Reply-To: <9211301656.AA19104@aland.bbn.com>; from "Craig Partridge" at Nov 30, 92 8:56 am X-Mailer: ELM [version 2.3 PL11] Craig, You have hit the nail squarely on the head with the following message. I will steal it (and I hope other people will steal it also, especially the *despised Press*) to explain how selections should be made, and the role of IETF/other standards groups vis-a-vis the *beloved Marketplace*. Keep on thinking! Dick dJ ----Forwarded message> > > > I believe you are making my point. People were trying to decide > > instead of letting natural selection take place. Shouldn't the process > > be to push ideas/documents/implementations out for critical review and > > acceptance and then see if we observe survival and progeny? > > Peter: > > I'd like to expand on this comment. It seems to me that there > are two separate steps to the selection process that need to be dealt with. > > First, assessing the technical solidity of a proposal. The market > (however defined, and apologies to Jon C's stomach) is not in a position > to figure out if a proposal will scale to billions of end systems, work > nicely for multimedia, etc. The market generally expects someone else > (their vendor, standards groups, whatever) to technically vet proposals. > > Second, assessing the desirability of a proposal. For example, there > are lots of folks who will argue strongly that mobility, flow support, self > configuration, interoperability with other protocols, or some other useful > feature should be part of IPv7. That's a utility argument that I think > consumers make pretty well. > > So it seems to me that IETF has a real obligation to technically vet > proposals and be clear about their relative technical strengths and > weaknesses. Getting the proposals elevated to Proposed Standard is at > least part of this process; doing experimental deployments is another. > > At some point it is then necessary to sit back and see what consumers > want to buy. > > We didn't handle this process as cleanly as we might have for SNMP/CMOT. > Having had the experience, I'd like to see us do it better this time around. > > Craig > From owner-big-internet@munnari.oz.au Wed Dec 2 04:20:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14645; Wed, 2 Dec 1992 04:20:28 +1100 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13432; Wed, 2 Dec 1992 03:26:20 +1100 (from @yonge.csri.toronto.edu:chk@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14438>; Tue, 1 Dec 1992 11:26:07 -0500 Received: from dino.alias.com by barney.alias.com with SMTP id AA13474 (5.65a/IDA-1.4.2 for tuba@lanl.gov); Tue, 1 Dec 92 10:53:44 -0500 Received: by dino.alias.com id AA28159 (5.65a/IDA-1.4.2 for big-internet@munnari.oz.au); Tue, 1 Dec 92 10:53:44 -0500 From: chk@alias.com (C. Harald Koch) Message-Id: <9212011553.AA28159@dino.alias.com> Subject: Re: one person's view about recent IETF and IPv7 To: tuba@lanl.gov, big-internet@munnari.oz.au Date: Tue, 1 Dec 1992 10:53:43 -0500 In-Reply-To: <9211302100.7273@munnari.oz.au> from "Juha Heinanen" at Nov 30, 92 02:33:16 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1750 > a host being listed in the DNS has nothing to do with the host being > reachable from anywhere. being "reachable from the Internet" doesn't > mean anything either, since what is Internet today? I wanted to add a bit more to this statement, since some people on the lists are still being somewhat cavalier about the "DNS == Connected" issue. Some people have brought up firewalls as one reason why a host would be in the DNS but not 'reachable' from all hosts. There are (apparently) a set of networks that are reachable from the CIX, but not reachable from the NSFNet, due to "acceptable use restrictions". These networks are still listed in the DNS, you just can't get there unless your packets can get there without crossing the NSF backbone. There's an entire experimental network out there, 44.0.0.0, devoted to the amateur radio internet. The laws governing access to this network are esoteric, vary from country to country, and there's some debate about the interpretation, but the current consensus is that while only an Amateur can initiate communications, any legal communication initiated by an Amateur is OK. So, for example, I can initiate an FTP session from net 44 to the Internet, but you can't FTP to my net 44 machine from the Internet. So this network is "quasi-reachable", very similar to the firewall case above (but for different reasons). All ampr.org hosts are listed in the DNS. Food for thought? -- Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON action, there is an equal | chk@alias.com (work-related mail) and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address) program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet) From owner-Big-Internet@munnari.oz.au Wed Dec 2 04:48:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15333; Wed, 2 Dec 1992 04:48:22 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15330; Wed, 2 Dec 1992 04:48:09 +1100 (from kasten@ftp.com) Received: by ftp.com id AA01676; Tue, 1 Dec 92 12:48:01 -0500 Date: Tue, 1 Dec 92 12:48:01 -0500 Message-Id: <9212011748.AA01676@ftp.com> To: big-internet@munnari.oz.au Subject: Washington IETF BOF notes/minutes From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com Hi At the BOF the other week, we produced the following: 1. A new and refined list of criteria based on Craig's and my Internet Draft (a new one is in the works). This list is also in a MUST/SHOULD format and not an ordered list. This was the slide that Craig was working from. This is an exact transcript of what is on the slide -- except that the MUSTs and SHOULDs have been grouped together. Here it is: MUSTS: - Long Live (20 years +/-) - Scalability - Robustness - Ease/possibility of transition (cost) - Media/Link Speed/L2 Protocol Independance - Unreliable Datagram Service - Ease/possibility of config/admin/operation/management (at least as good as IPv4) - Security as good as IPv4 -- includes integrity, authentication(?) information hiding and firewalls(?) - Globally unique ids. - Topological Flexibility (as good as IPv4) - Risk/Maturity of field - Documents online and "owned" by the IETF ala RFCs following requirements in rfc1310. SHOULDs: - Multicast Support - Flow Support/Capacity Reservation - Mobile Host Support (vs. "Portable") - Architectural Simplicity Extensibility has a big ? next to it on the slide we were working on. I believe that, if the protocol is to last 20 years then it has to be extensible so this should be a MUST. Performance and Cost Distribution were marked as "defer" 2. Some notes provided by Richard DesJardins: Config/Ease of Admin/Operations = - Easy to identify endpoint independent of address - Easy to allocate address - Easy to change network topology - Easy to change network provider - Easy to configure host address - Easy to operate network/routers 3. Points that I plucked out of the general discussion: - Security should include methods of dealing with hostile attacks. - Accounting (as we defined it) should be dropped. - Autoconfig is required. -- Frank Kastenholz From owner-big-internet@munnari.oz.au Wed Dec 2 08:55:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21172; Wed, 2 Dec 1992 08:55:11 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212012155.21172@munnari.oz.au> Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16155; Wed, 2 Dec 1992 05:27:41 +1100 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA07558; Tue, 1 Dec 92 13:25:45 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Randall Atkinson) Date: Tue, 1 Dec 1992 13:25:45 EST In-Reply-To: kasten@ftp.com (Frank Kastenholz) "Re: Draft Charter IPSEC WG" (Dec 1, 12:48pm) X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: kasten@ftp.com Subject: Re: Network Layer Security Properties Cc: ipsec@ans.net, big-Internet@munnari.oz.au Frank, In my own view, IP/ICMP/etc primarily need to have two properties that are not currently available: authentication (preclude Super Source Quench [1], preclude routing attacks, etc) and data integrity (prevents folks from twiddling other folks bits without the receiver knowing about it). In my view, these two properties need to be available in an ordinary IP/SIP/CLNP/etc option and must not require the use of an encapsulating protocol -- if we want to really provide basic security to the majority of the Internet sites. Every site needs these two properties TODAY to preclude simple obvious attacks on the network and hosts connected to the network. Confidentiality via encryption is not as critical at the network layer, though probably good to have [2]. For confidentiality, use of an encapsulating protocol such as SP3 or the ISO Network Layer Security Protocol (NLSP) sounds reasonable. Because relatively fewer sites are really worried about network layer confidentiality, use of an encapsulating protocol by the interested sites is fine. This is not arguing against an SP3/NLSP basis for the IP Security work. Rather it is suggesting that, while an encapsulating SP3/NLSP-like protocol be developed for use, thought also be given to incorporating compatible authentication/integrity mechanisms in new options to the regular network protocol (IP/SIP/CLNP/whatever). I suspect that not much can really be done with IPv4 because of the current header/options size restriction. Regards, Ran atkinson@itd.nrl.navy.mil [1] ICMP message to the victim host that declares the default gateway address to be 127.0.0.1; similar attacks are also possible. [2] I'm trying to avoid starting a layer war here. Some sites don't believe they ever need confidentiality outside the application layer, and there is little consensus in the community on the question of handling confidentiality at the Transport Layer or the Network Layer. -- From owner-big-internet@munnari.oz.au Wed Dec 2 10:42:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25518; Wed, 2 Dec 1992 10:42:58 +1100 (from owner-big-internet) Return-Path: Received: from qualcom.qualcomm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24008; Wed, 2 Dec 1992 09:58:42 +1100 (from karn@qualcomm.com) Received: from servo.qualcomm.com by qualcomm.com; id AA02135 sendmail 5.65/QC-main-2.1 via SMTP Tue, 1 Dec 92 14:55:52 -0800 for big-Internet@munnari.oz.au Received: by servo; id AA26782 sendmail 5.67/QC-subsidiary-2.1 Tue, 1 Dec 92 14:55:49 -0800 for kasten@ftp.com Date: Tue, 1 Dec 92 14:55:49 -0800 From: karn@qualcomm.com (Phil Karn) Message-Id: <9212012255.AA26782@servo> To: atkinson@tengwar.itd.nrl.navy.mil, kasten@ftp.com Subject: Re: Network Layer Security Properties Cc: big-Internet@munnari.oz.au, ipsec@ans.net Ran Atkinson: >In my view, these two properties need to be available in an ordinary >IP/SIP/CLNP/etc option and must not require the use of an encapsulating >protocol -- if we want to really provide basic security to the majority >of the Internet sites. I don't see how this follows. As the core protocol of the Internet, IP's simplicity (so far) is largely responsible for the success of the entire Internet. There's a very real danger of the "second system effect" in the IPv7 project, especially as the frustrated OSIers get involved. (Personally I agree with Noel Chiappa that switching the whole Internet to a new routing and addressing architecture at the same time would be sheer madness. I'd much prefer to find clever, compatible ways to get more out of the 32 bit addresses in IPv4 headers.) So I think it's important to review what I personally consider to be the most important principles of the current IP (IPv4) design that ought to be retained in any new IP -- if in fact there *is* to be a new IP: 1. The protocol is connectionless. (This ought to go without saying, but I guess it doesn't.) 2. The internet protocol contains ONLY those fields that must be there for the routers to do their job. This is true for every field in the IPv4 header with the exception of the Protocol field, which is interpreted by the destination host. 3. There is a "basic" IP header format with fields of fixed size that is sufficiently useful to account for the vast majority of Internet packets. High performance routers can then be heavily optimized around this format, perhaps by building custom hardware. The relatively few packets with options can be processed by software with little impact on average performance. Principle 3 pretty much follows from 1 and 2. Since network layer security information is interpreted only by the destination host, by principle 2 it just doesn't belong in the IP header. Putting it there anyway could well violate 3, especially since many sites might well opt to run without network layer security even if it is widely available. By the way, some years ago I originally proposed adding authentication to IP as an IP header option. Jeff Schiller talked me out of it, and he was correct. As for the layer 3/4 controversy, I think it shows that there's a need for both. Layer 3 security is arguably much more flexible and complete. It covers and protects any arbitrary transport protocol. E.g., authentication between TCP and IP protects TCP against maliciously generated spurious RSTs and connection hijacking. If the authenticator includes a timestamp, it could protect against long-delayed replay attacks (defense against short-term replay would still be the responsibility of the transport protocol, but this is something it has to defend against anyway since the Internet can duplicate packets occasionally on its own.) And if encryption is used, an eavesdropper is denied the maximal amount of information. All he sees is traffic between two hosts; he can't tell what application or even what transport protocol is in use. The only problem I can see with layer 3 security has to do with efficiency. For example, it breaks Van Jacobson TCP/IP header compression. Some slow serial line users might not be willing to give this up to gain all of the benefits of network layer security. If they're mainly interested in confidentiality, then they could simply run a stream cipher on top of TCP. This could be part of the application (as it is in Kerberos) or it could become a TCP option. This would make security an optional level 4 service. Phil From owner-big-internet@munnari.oz.au Thu Dec 3 06:24:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06195; Thu, 3 Dec 1992 06:24:50 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212021924.6195@munnari.oz.au> Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25724; Thu, 3 Dec 1992 01:01:28 +1100 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA08241; Wed, 2 Dec 92 09:01:03 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Randall Atkinson) Date: Wed, 2 Dec 1992 09:01:03 EST In-Reply-To: teb@saturn.sys.acc.com (Tom Benkart) "Where does security belong?" (Dec 2, 7:59am) X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: teb@saturn.sys.acc.com (Tom Benkart) Subject: Re: Where does security belong? Cc: big-Internet@munnari.oz.au, ipsec@ans.net On Dec 2, 7:59am, Tom Benkart wrote: } I'd like to second Phil's comments about the "appropriate" place } for security in the protocol stack. Restricting information at } the IP layer to only that which is needed by end AND intermediate } (router) systems is my strong preference. I don't think there is any single place in the protocol stack that has an exclusive on security. My understanding is that the current work in ipsec is on security for IPv4 (with perhaps an eye towards SIP/PIP/CLNP/etc). Working on IP level security need not preclude subsequent or parallel work at other layers. There has already been discussion of handling key management in parallel and possibly doing it at a different layer in the stack (I *do* hope that work proceeds in parallel rather than being deferred). } Not very much security-related information falls into this category. Not sure what this means. See below. } Most of the discussion so far has centered around authentication, } integrity and confidentiality. By my criteria from the first } paragraph, none of these *have* to be handled at the IP level. I disagree, by your own criteria, there are many that HAVE to be handled at the IP level. For example, without some kind of authentication in ICMP, there are a very large number of attacks on both end systems and intermediate systems (Super Source Quench is only one example). Policy-based routing (which would be of significant value to the Navy and probably also most commercial network service providers) cannot be reliably implemented unless there is some mechanism which provides assurance that the information used to make the routing decision is in fact authentic and not forged. Policy-based routing would probably depend on the source of the traffic as well as the destination and might also depend on QOS information. There are numerous other examples that directly relate. } Conspicuously absent from the discussion is any mention of access } control, which would have to be done at the IP level since routers } might need to restrict routes based on that information. It is } also interesting that access control is about the only thing the } current RIPSO/CIPSO provides. Is the lack of mention of access } control because no one really wants/needs it, or because it is } assumed as a given? RIPSO/CIPSO do NOT provide access control. That is a myth or perhaps "aggressive marketing" -- depending on one's perspective about marketing. The RIPSO/CIPSO options provide unauthenticated label information on the sensitivity of the data in the IP datagram. The CIPSO folks have strongly resisted efforts to add more descriptive language to their draft clarifying how to handle packets that are out of range and so forth -- so the CIPSO draft doesn't even provide any requirements on access control in the end system, let alone distinguishing the intermediate router case. What the receiving host with the arriving packet is not fully specified -- most trusted systems will map the received sensitivity label into an internal-to-the-OS sensitivity label and make MAC decisions based on the OS label. Moreover, it is almost trivial to modify the RIPSO/CIPSO label on the fly (i.e. while the packet is in transit). Without some authentication mechanism for the CIPSO/RIPSO information, one can not make any kind of dependable access control decision based on the information in that label. Optional support for some kind of authentication (whether bundled with confidentiality or also available separately) is clearly needed. Integrity and confidentiality properties are also desired by many, at least optionally (regardless of whether one has an IP option or optionally encapsulates IP into another security protocol). Ran atkinson@itd.nrl.navy.mil -- From owner-big-internet@munnari.oz.au Thu Dec 3 07:01:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07326; Thu, 3 Dec 1992 07:02:13 +1100 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00817; Thu, 3 Dec 1992 03:39:12 +1100 (from hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA27222; Wed, 2 Dec 92 08:39:02 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA08074; Wed, 2 Dec 92 08:39:04 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA07764; Wed, 2 Dec 92 08:36:39 PST Date: Wed, 2 Dec 92 08:36:39 PST From: hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9212021636.AA07764@bigriver.Eng.Sun.COM> To: Brian Carpenter CERN-CN Cc: Dave Crocker , big-internet@munnari.oz.au In-Reply-To: <9211301625.AA19012@Mordor.Stanford.EDU> Subject: Re: one person's view about recent IETF and IPv7 Content-Length: 125 Brian, I would be happy to send you the nroff source for the IPAE/SIP criteria document. Let me know if you want it. Bob From owner-Big-Internet@munnari.oz.au Thu Dec 3 11:38:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17979; Thu, 3 Dec 1992 11:39:14 +1100 (from owner-Big-Internet) Return-Path: Received: from hostshost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17950; Thu, 3 Dec 1992 11:38:56 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA16989; Wed, 2 Dec 92 17:38:47 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA09258; Wed, 2 Dec 92 17:38:46 MST Message-Id: <9212030038.AA09258@goshawk.lanl.gov> To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Mon, 30 Nov 92 06:53:27 -0800. <9211301453.AA17729@Mordor.Stanford.EDU> Date: Wed, 02 Dec 92 17:38:45 MST From: peter@goshawk.lanl.gov Dave, >>> However, I suggest that the decision is not in the best interests of >>> the community, since it withholds useful information from that >>> community. (I also had the understanding that the contendors were >>> _expected_ to respond to the IESG Criteria list, in time for the >>> recent IETF.) The tuba mailing list is available for anonymous ftp from merit.edu:pub/tuba-archive. In that archive is a mail message from Brian Carpenter which responds to both the IESG document and the P&K document. There are several subsequent messages refining those responses. Brian and I are tasked by the TUBA group to clean up a response I wrote using Brian's mail message as a starting point. I encourage those members of the community who want to learn about TUBA get the archive and subscribe to the tuba mailing list (send mail to tuba-request@lanl.gov). My plenary talk was structured to respond to the IESG criteria so as to provide a TUBA response within the timeline posed in the IESG document. I thought it prudent to wait for the P&K process to converge (at the DC bof) prior to a written response. Also, there was a very important topic which needed to be discussed at the DC working group meeting. That has happened and we now have our work assignments and look forward to getting the results of the P&K BOF to respond to. Several members of the TUBA effort actively participated in the P&K requirements effort, and you, and readers of the B-I list, will remember that I am one of the early supporters for the formation of what is now the P&K effort. >>> A policy of waiting, rather than deliverying whatever >>> is reasonably possible, to facilitate community review, seems >>> most odd to me. I'm sure that the decision isn't intended to be >>> obstructionistic, but suspect that it looks that way. I have significant faith in the IETF membership and assume they will show at least the same level of maturity in this matter as you do. cheers, peter From owner-Big-Internet@munnari.oz.au Thu Dec 3 16:29:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00265; Thu, 3 Dec 1992 16:29:30 +1100 (from owner-Big-Internet) Return-Path: Received: from hostshost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00258; Thu, 3 Dec 1992 16:29:14 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA01994; Wed, 2 Dec 92 22:28:58 -0700 Received: by goshawk.lanl.gov (4.1/5.17) id AA10931; Wed, 2 Dec 92 22:28:56 MST Date: Wed, 2 Dec 92 22:28:56 MST From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9212030528.AA10931@goshawk.lanl.gov> To: kasten@ftp.com Subject: Re: Washington IETF BOF notes/minutes Cc: big-internet@munnari.oz.au Frank, >>> - Documents online and "owned" by the IETF ala RFCs following requirements >>> in rfc1310. For the record, the hand vote on this topic did not cover the issue of ownership. We did discuss this, but did not vote on it. A vote on "free, online access like the current RFCs" was held and there seemed to be unanimity. The meeting was then brought to a close since we had run past 6 pm. cheers, peter From owner-Big-Internet@munnari.oz.au Fri Dec 4 03:46:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22304; Fri, 4 Dec 1992 03:46:32 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9212031646.22304@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22301; Fri, 4 Dec 1992 03:46:25 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5957; Thu, 03 Dec 92 08:02:40 EST Date: Thu, 3 Dec 92 08:02:39 EST From: yakov@watson.ibm.com To: big-internet@munnari.oz.au Cc: kasten@ftp.com, craig@aland.bbn.com Subject: Criteria BOF >At the BOF the other week, we produced the following: >MUST: >... > - Documents online and "owned" by the IETF ala RFCs following requirements > in rfc1310 While the first part ("online") was voted on, the group did not even have time to discuss the second part ("owned" by the IETF). Certainly, no decision was reached on the second part ("owned by the IETF). Please correct the notes/minutes. >SHOULDs: >-Multicast Support >-Flow Support/Capacity Reservation >-Mobile Host Support >-Architectural Simplicity I don't think the group decided that the above items are "SHOULD" rather than "MAY". I certainly recall that the group had a consensus that the lack of support of the "SHOULD" features in a particular IPv7 should not be viewed as a showstopper for adopting that particular IPv7. So, I would suggest to replace "SHOULD" with "MAY" and add additional clarification on the importance of the "MAY" factors (e.g. "lack of the "MAY" features shall not impact the adoption of a particular proposal"). Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Fri Dec 4 05:09:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24786; Fri, 4 Dec 1992 05:09:26 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9212031809.24786@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24781; Fri, 4 Dec 1992 05:09:16 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8963; Thu, 03 Dec 92 13:09:15 EST Date: Thu, 3 Dec 92 13:09:15 EST From: yakov@watson.ibm.com To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au Subject: Criteria BOF Ref: Your note of Thu, 03 Dec 92 09:46:18 -0800 >I believe that Yakov's comments about on-line document is partially >correct. Craig, "Partially correct" means that certain aspect of my comments about "on-line" document were incorrect. I would appreciate if you'll tell me what was incorrect in my comments about "on-line". >However, there is enough sentiment behind several of them that I think >Frank's characterization of them as SHOULDs is a perfectly reasonable >starting point. (I'm also not interested in playing games of >splitting hairs amonst SHOULDs and MAYs)... I don't recall reaching *any* consensus on "sentiments" :-). I don't think that Frank's characterization of them as SHOULDs is a perfectly reasonable starting point. However, I pretty much agree with your comments about "playing games of splitting hairs...". So, I would suggest to replace both SHOULD and MAY by the text you put in your message (with minor editorial change at the end): "A MUST mean that we would hold up deployment of an IPv7 rather than deploy a protocol that lacked just one of the MUST features. All other features, by definition, optional characteristics of an IPv7 protocol. Absence of any of these features should not preclude the deployment." Yakov Rekhter From owner-big-internet@munnari.oz.au Fri Dec 4 06:01:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26367; Fri, 4 Dec 1992 06:01:31 +1100 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24183; Fri, 4 Dec 1992 04:48:18 +1100 (from craig@aland.bbn.com) Received: from port17.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA14500; Thu, 3 Dec 92 12:47:52 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA18659; Thu, 3 Dec 92 09:46:19 PST Message-Id: <9212031746.AA18659@aland.bbn.com> To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au Subject: Re: Criteria BOF In-Reply-To: Your message of Thu, 03 Dec 92 08:02:39 -0500. <9212031646.22304@munnari.oz.au> From: Craig Partridge Date: Thu, 03 Dec 92 09:46:18 -0800 Sender: craig@aland.bbn.com I dunno -- it must have been something in the Washington air, but it seems to me that almost every WG list I'm on is having debates about what was actually decided at the respective WG meetings in DC. :-( I believe that Yakov's comment about on-line document is partially correct. The group voted that the documents must be available in a form similar to RFCs. In practice that means, on-line, but also freely redistributable and the ability of authors to produce modified versions (much as folks revise RFCs). As for the SHOULDs -- the group decided to decide what as really necessary (MUST exist) -- using the principle that a MUST meant we would hold up deployment of an IPv7 rather than deploy a protocol that lacked just one of the MUST features. All other features are, by definition, optional characteristics of an IPv7 protocol. Good if you've got them but we won't hold up the parade. However, there's enough sentiment behind several of them that I think Frank's characterization of them as SHOULDs is a perfectly reasonable starting point. (I'm also not interested in playing games of splitting hairs amongst SHOULDs and MAYs, at least, not at this stage of developing the criteria draft). Craig From owner-big-internet@munnari.oz.au Fri Dec 4 06:23:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27038; Fri, 4 Dec 1992 06:23:47 +1100 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25176; Fri, 4 Dec 1992 05:24:44 +1100 (from craig@aland.bbn.com) Received: from port17.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA18886; Thu, 3 Dec 92 13:24:25 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA19046; Thu, 3 Dec 92 10:22:53 PST Message-Id: <9212031822.AA19046@aland.bbn.com> To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au Subject: partially correct Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 03 Dec 92 10:22:52 -0800 Sender: craig@aland.bbn.com Yakov: You said that the second part ("owned" by the IETF) had not been discussed. It was discussed, but we rapidly found that defining the notion of "owned by IETF" was too tricky, so we instead said available in the way RFCs are. Also, your note emphasized that the key decision was on the question of being "on-line" while I believe the key decision was on similarity to the availability of RFCs (which is more than just on-line). So I felt your synopsis of the discussion was not quite correct even if your statement about what was actually decided was correct. Thus "partially correct." I'm comfortable with your text in lieu of MUST/SHOULD or MUST/MAY distinctions. Thanks! Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-big-internet@munnari.oz.au Fri Dec 4 07:52:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29449; Fri, 4 Dec 1992 07:52:59 +1100 (from owner-big-internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26499; Fri, 4 Dec 1992 06:05:43 +1100 (from rnorth@max.cecer.army.mil) Received: from max.cecer.army.mil by ux1.cso.uiuc.edu with SMTP id AA02253 (5.67a8/IDA-1.5 for ); Thu, 3 Dec 1992 13:04:00 -0600 Received: by max.cecer.army.mil id AA21967 (5.67a/IDA-1.5 for info-big-internet@ux1.cso.uiuc.edu); Thu, 3 Dec 1992 13:05:33 -0600 Date: Thu, 3 Dec 1992 13:05:33 -0600 From: Russ Northrup Message-Id: <199212031905.AA21967@max.cecer.army.mil> To: info-big-internet@ux1.cso.uiuc.edu Newsgroups: info.big-internet Path: rnorth From: rnorth@news.cecer.army.mil (Russ Northrup) Subject: Help newbie to IB get up to speed Message-ID: Keywords: help Reply-To: rnorth@max.cecer.army.mil Organization: US Army Corps of Engineers Construction Engineering Research Labs Date: Thu, 3 Dec 1992 19:05:30 GMT Lines: 29 Well, OK, I'm not totally a know-nothing... I manage what I'm told is a median size network. About 800-1000 hosts on 9 subnets (soon to be 14), supporting several different protocols. We have expanded 10 fold in the last couple years, and I don't anticipate my load decreasing very quickly. I'm also in charge of strategic planning (5-7 years) at this site, so I am really interested in directions the net will be taking in order to consider them as I expand, plan, budget, etc... I've been reading the articles here for a while and I'd like to be able to get more out of this group. However, I find that I'm handicapped by not knowing all the abbreviations used, nor many of the reletive merits of the protocols discussed. Is there a FAQ, or proceedings from previous meetings, or texts or _something_ that I could use to come up to speed? I understand that there are periodic meetings to discuss these topics as well, are these invitation only, open committee, or what? Thanks, Russ Northrup System Admin. r-northrup@cecer.army.mil From owner-big-internet@munnari.oz.au Fri Dec 4 08:48:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01054; Fri, 4 Dec 1992 08:48:48 +1100 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28279; Fri, 4 Dec 1992 07:10:20 +1100 (from kasten@ftp.com) Received: by ftp.com id AA14684; Thu, 3 Dec 92 15:09:16 -0500 Date: Thu, 3 Dec 92 15:09:16 -0500 Message-Id: <9212032009.AA14684@ftp.com> To: yakov@watson.ibm.com Subject: Re: Criteria BOF From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au, kasten@ftp.com, craig@aland.bbn.com > > - Documents online and "owned" by the IETF ala RFCs following requirements > > in rfc1310 > > While the first part ("online") was voted on, the group did not > even have time to discuss the second part ("owned" by the IETF). > Certainly, no decision was reached on the second part ("owned by the IETF). > Please correct the notes/minutes. I view the 1310 issue as a fallout of the need to have things online as RFCS. If IPv7 is to be an Internet Standard then its supporting documentation must follow the rules of 1310. > >SHOULDs: > >-Multicast Support > >-Flow Support/Capacity Reservation > >-Mobile Host Support > >-Architectural Simplicity > > I don't think the group decided that the above items are "SHOULD" > rather than "MAY". I certainly recall that the group had a consensus > that the lack of support of the "SHOULD" features in a particular IPv7 > should not be viewed as a showstopper for adopting that particular > IPv7. > > So, I would suggest to replace "SHOULD" with "MAY" and add additional > clarification on the importance of the "MAY" factors (e.g. "lack of > the "MAY" features shall not impact the adoption of a particular proposal"). WRONG! The wording used in the BOF was something like "Even if the Internet has suffered Routing Congestion Collapse and Address Exhaustion (i.e. it Has DIED -- NO PACKETS ARE MOVING ANYWHERE) then we still must hold up IPv7 if it does not have all of the MUSTs." otherwise the new protocol ought to have these things. A criteria/requirements document is supposed to list those things which really really really really ought to be in the protocol. It should not ennumerate those things which are pretty optional. "MAY" implies "pretty optional", not "really really really really ought to". The things that would fall under the "MAY" category can be considered "product differentiators" -- they make your protocol really different from my protocol. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Fri Dec 4 10:39:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05764; Fri, 4 Dec 1992 10:39:25 +1100 (from owner-Big-Internet) Return-Path: Received: from x400gate.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05755; Fri, 4 Dec 1992 10:39:08 +1100 (from macgill@bnr.ca) X400-Received: by mta bcars520 in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 3 Dec 1992 17:55:24 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 3 Dec 1992 17:54:38 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 3 Dec 1992 12:53:00 -0500 Date: Thu, 3 Dec 1992 17:53:00 +0000 X400-Originator: /DD.ID=1658997/G=Ross/I=RM/S=MacGillivray/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.848:03.11.92.22.54.38] X400-Content-Type: P2-1984 (2) Content-Identifier: Latest TUBA S... From: "Ross (R.M.) MacGillivray" Message-Id: <"15893 Thu Dec 3 17:55:08 1992"@bnr.ca> To: big-internet@munnari.oz.au Subject: Latest TUBA Specs I would very much like to get a copy of the latest TUBA specs. Could someone give the coordinates of a server on the internet that contains the latest versions. Also, how do I subscribe to the TUBA list? Ross MacGillivray Bell Northern Research email: macgill@bnr.ca From owner-Big-Internet@munnari.oz.au Fri Dec 4 11:35:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07894; Fri, 4 Dec 1992 11:35:44 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9212040035.7894@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07868; Fri, 4 Dec 1992 11:35:05 +1100 (from ULLMANN@PROCESS.COM) Date: Thu, 3 Dec 1992 19:34 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: about transitions to a new IP Hi, I think we should remind ourselves of something very basic to the context of this discussion: If we didn't have an impending address space problem, we wouldn't be talking about a new protocol. I.e. the problem is "simple", and needs a proportionate response. Re-architecting a working Internet because we ran out of bits in a field or two is _not_ a proportionate response. ------- Yes, there is a potential routing explosion problem too; but if we had enough bits in the address, we would not be seriously suggesting changes to the packet format. ------- Transition: Picture in your mind's eye 50 million boxes, both hosts and routers, spread all over the world, with tangles of bright yellow wire in between. Color all the boxes Red. Now pick n percent of those boxes, mostly at random, with some bunching. But no actual rules as to which you pick are allowed. Choose n between 1 and 99. Color the boxes you choose Green. Now: you aren't allowed to move the Red boxes, or open them up to change anything. You can't even write over the labels on them. The Green boxes are open, you can do anything you like. But it must work the first time. There will be no second chance. You aren't allowed to break the Red boxes. They have to continue to work. If some of them break, every nearby box turns Blue (at least in the 1988 version :-), and you lose the game. ------- If a proposal for a new IP needs a "transition plan", it isn't going to fly. Best Regards, Robert Ullmann From owner-Big-Internet@munnari.oz.au Fri Dec 4 13:27:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12453; Fri, 4 Dec 1992 13:28:26 +1100 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12430; Fri, 4 Dec 1992 13:27:59 +1100 (from smart@mel.dit.csiro.au) Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA05736 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 4 Dec 1992 13:26:48 +1100 Received: by squid.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA09525; Fri, 4 Dec 92 13:25:40 EST Message-Id: <9212040225.AA09525@squid.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Cc: smart@mel.dit.csiro.au Subject: encouraging thoughts Date: Fri, 04 Dec 92 13:25:39 +1100 From: Bob Smart If it were easy to change network numbers then CIDR would last a long time. The loss due to allocating hosts to nets, subnets and subsubnets is not that great if you don't have to leave a lot of empty space around to allow for expansion. The problem of expansion causing renumbering could be significantly reduced if we allowed host-routing within a network. Somebody suggested this under the heading "subnetting considered harmful", and it seemed like a good idea to me. It wouldn't be compulsory, but it would give network managers an option that would allow them to use their address space more densely and make it easier for them to reorganize what hosts are on what wires. The problem of expansion causing a complete network number change can be reduced if the NIC allocates numbers sparsely (or backwards as described in the the RFC on subnet numbering). If the NIC did this people would be more prepared to accept an allocation that is only just big enough at the moment, knowing that they can expand their existing number later (and not have to change existing numbers). The same technique allows subnets to be allocated which are only just big enough. But if the enclosing network is only just big enough this ceases to work very well. That is one reason why a protocol for distributing host-routes between routers within a network would complement CIDR and extend the life of IPv4. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - It also occurs to me that the advantages of splitting addresses from Endpoint Identifiers can be gained in SIP with careful use of SIP's very loose source routing system. Effectively SIP's unique addresses can be considered EIDs which also encode one particular address of the end-point. The problem of how to encode in directory services the extra information about useful source routes (and of how to use it sensibly) remains an important one. It is not one that has to be completely worked out at day one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Now that the TUBA folks have decided that TUBA = adding TCP & UDP to standard CLNP, it becomes almost irrelevant. That work can proceed and be seen as a good thing whether it is to be IPv7 or not. The question of whether it will be good or bad for OSI is very reminiscent of the question of whether MIME would be good or bad for X.400. If in 2 years time SIP or PIP is not going to provide a significantly more functional network layer than CLNP then we have something to fall back on. The spread of the necessary CLNP infrastructure in the Internet is something worthwhile which is going to happen anyway. TUBA will presumably speed it up. Bob Smart From owner-big-internet@munnari.oz.au Fri Dec 4 16:34:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19726; Fri, 4 Dec 1992 16:35:13 +1100 (from owner-big-internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06912; Fri, 4 Dec 1992 11:07:32 +1100 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA25289 (5.65c/IDA-1.4.4nsd for ); Thu, 3 Dec 1992 16:07:24 -0800 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA18080 (5.65c/IDA-1.4.4-910725); Thu, 3 Dec 1992 16:07:23 -0800 Message-Id: <199212040007.AA18080@remmel.NSD.3Com.COM> To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Re: Criteria BOF In-Reply-To: Your message of "Thu, 03 Dec 92 15:09:16 EST." <9212032009.AA14684@ftp.com> Date: Thu, 03 Dec 92 16:07:22 -0800 From: tracym@NSD.3Com.COM > > >SHOULDs: > > >-Multicast Support > > >-Flow Support/Capacity Reservation > > >-Mobile Host Support > > >-Architectural Simplicity > > > > A criteria/requirements document is supposed to list those things > which really really really really ought to be in the protocol. It > should not ennumerate those things which are pretty optional. "MAY" > implies "pretty optional", not "really really really really ought to". > WRONG! A criteria/requirements document is supposed to describe all of those things which must be CONSIDERED when evaluating proposed solutions. It includes lists of MUSTs, REALLY-REALLY-OUGHT-TOs, OUGHT-TOs, MAYs, etc., but is MUCH more than those lists. Let's get off the SHOULD/MAY stuff, and flesh out some of the items. We don't yet know that mobile host solutions will require ANY support from the internet protocol itself. Multicast support may be no more than a multicast address space. Arguing SHOULD/MAY seems somewhat pointless if virtually no work turns out to be needed in any of the proposed solutions. Tracy From owner-Big-Internet@munnari.oz.au Fri Dec 4 22:49:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03140; Fri, 4 Dec 1992 22:54:13 +1100 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB02953; Fri, 4 Dec 1992 22:49:09 +1100 (from kre) To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au, kasten@ftp.com, craig@aland.bbn.com Subject: Re: Criteria BOF In-Reply-To: Your message of Thu, 03 Dec 92 08:02:39 -0500. Date: Fri, 04 Dec 92 22:48:40 +1100 Message-Id: <28995.723469720@munnari.oz.au> From: Robert Elz Date: Thu, 3 Dec 92 08:02:39 EST From: yakov@watson.ibm.com So, I would suggest to replace "SHOULD" with "MAY" and add additional clarification on the importance of the "MAY" factors (e.g. "lack of the "MAY" features shall not impact the adoption of a particular proposal"). Date: Thu, 3 Dec 92 13:09:15 EST From: yakov@watson.ibm.com "A MUST mean that we would hold up deployment of an IPv7 rather than deploy a protocol that lacked just one of the MUST features. All other features, by definition, optional characteristics of an IPv7 protocol. Absence of any of these features should not preclude the deployment." Those two came from two different messages on the same topic. The first I'd strongly object to, it amounts to saying that the only criteria that count at all are the MUSTs. The second I object to only mildly, that because it ignores the differences bewteen the optional features - while none should kill the chances of a protocol without them, clearly some optional features are more important than others, and the ones that are particularly important - ie: their presence or absense will weigh heavily in the final decision should be clearly marked. Personally, I doubt that MAY is the right word to use anywhere here - in HR type documents its useful, as it explicitly indicates that some particular feature is not illegal, which simply omitting reference to it may be taken as implying by some people (especially where there had already been an argument to that effect). MAY basically means "you can do this if you want to, but we don't care". None of the criteria listed are in that category I don't think - they're all "the protocol will be better if it includes this" and so are SHOULD. While I agree with Tracy's comment that the criteria should contain all kinds of things that should be considered, there's no point at all listing things over which the final outcome is of no consequence, that's what MAY means to me. However, I don't think you should read that SHOULD in the HR sense, of "you really ought to do this, and if you don't you'd better have a pretty good explanation why not or you're no good". Just read it more like the English "should". After saying all of this, and while not meaning to imply that the list of criteris isn't useful - it certainly is - but in the final count, I doubt there will be any of the protocols that don't, one way or another, satisfy all the MUSTs, or claim that they do with some reasonable sounding argument. What the decision is going to come down to, is which protocol people believe best suits the future needs of the internet, as its going to be around for a long time. For that its the "optional" features that are going to count. kre From owner-Big-Internet@munnari.oz.au Fri Dec 4 23:23:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03886; Fri, 4 Dec 1992 23:24:59 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9212041224.3886@munnari.oz.au> Received: from vnet.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03866; Fri, 4 Dec 1992 23:23:48 +1100 (from rboivie@vnet.ibm.com) Received: from RHQVM21 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5610; Fri, 04 Dec 92 07:20:48 EST Date: Fri, 4 Dec 92 07:20:39 EST From: rboivie@vnet.ibm.com To: big-internet@munnari.oz.au Subject: CIDR and Network Growth > From: Bob Smart > If it were easy to change network numbers then CIDR would last a > long time. < other stuff deleted > If it's true that an IPv4 based Internet would last a long time with CIDR and a re-allocation of network numbers then it sounds like we should do that and defer any plans for moving to IPv7 until we really know what ought to be in it. It would seem to be much easier to change network numbers then to change protocol stacks **and** network numbers. I don't think it makes much sense to say it's too hard to change network numbers so let's change everything. If we don't think we can do the first then how can we possibly think we can do the second? Also, isn't it true that problems associated with changing network numbers can be minimized with some neat tricks like running two IP networks over the same ethernet during a transition period? Rick Boivie From owner-big-internet@munnari.oz.au Sat Dec 5 05:28:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14665; Sat, 5 Dec 1992 05:30:47 +1100 (from owner-big-internet) Return-Path: Received: from motgate.mot.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27612; Fri, 4 Dec 1992 06:42:37 +1100 (from Paul_Lambert@poncho.phx.sectel.mot.com) Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA21590; Thu, 3 Dec 1992 13:42:29 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA26980; Thu, 3 Dec 1992 13:42:26 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA04999; Thu, 3 Dec 92 12:39:38 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29378; Thu, 3 Dec 1992 12:48:29 MST Message-Id: <00112.2806231709.29378@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Cc: big-Internet@munnari.oz.au (the big-Internet), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 3 Dec 1992 12:44:40 MST Subject: 24 Security Examples Reply to: 24 Security Examples Ran, I agree with your comments about considering the SDNS work. >It seemed to me like we ought to _at least_ seriously consider using the SDNS work, including >the SDNS Key Mgmt mechanisms, as a good base to work from. Other considerations aside, >a lot of work has been done on that and as near as I can tell, all of the US DoD will be moving >in an SDNS-like direction (which means that leveraging that work should help the availability >of commercial implementations that would eventually [preferably soon] be really interoperable. > >I haven't studied the SP3 and NLSP documents side by side recently, but am doing so now. >If someone had an existing summary of differences that they could post to this list, it would >be generally useful, I think. > >Ran >atkinson@itd.nrl.navy.mil However, both NLSP and IEEE 802.10 have already been strongly influenced by SDNS! The Secure Data Network System (SDNS) specifications were released to NIST in 1989 and have not been significantly updated since. The SDNS specification for network layer security (SP3 - Security Protocol layer 3) is the basis for the connection-less mode of the ISO Network Layer Security Protocol (NLSP). The SDNS SP4 (Security Protocol layer 4) is nearly identical to the ISO Transport Layer Security Protocol (TLSP). The IEEE 802.10C work was originally using the SDNS Key Management Protocol as a basis for their key management. SP3 and NLSP both define a new protocol that can be placed in the network layer to provide cryptographic encapsulation of other protocols. The connectionless mode of NLSP was originally nearly identical to the SP3 specification. The major changes in NLSP from SP3 are: - The NLSP clear header was modified to make the first octet be a Protocol ID (PID) that is compliant with the ISO TR 9577 guidelines. Both SP3 and SP4 were defined to share the NSEL of ISO TP. This NSEL limited placement of SP3 to the top (SNICP) of the network layer. The Initial PID (IPID) assigned to NLSP allows it to placed at the bottom, middle or top of the network layer. - The SP3-I and SP3-D header encapsulation modes were replaced by identical functionality that uses the Subsequent PID (SPID) in the data to determine if IP or CLNP has been encapsulated. Note that the cryptographic encapsulation of a complete IP datagram is one approach for subnet-to-subnet protection. TLSP and SP4 both added security directly into the ISO Transport protocol. TLSP differs from SP4 only in the removal of a final sequence number (SP3 has this feature). To illustrate how all of these protocols could encapsulate information I have developed a few examples. First, here are a few examples of ways that NLSP might operate at the network layer. a) | link | IP | NLSP-CL | TP or TCP(?) or.. | b) | link | CLNP | NLSP-CL | TP or IDRP or TCP or ... | c) | link | IP | NLSP-CL(S-NSAP,D-NSAP)| TCP or UDP or ... | d) | link | IP | NLSP-CL | IP | TCP or UDP or ... | e) | link | CLNP | NLSP-CL | CLNP | TP or IDRP or ... | f) | link | NLSP-CL | any 802.2 SNAP | g) | X.25 | NLSP-CO | any client protocol of X.25 | NLSP has two distinct modes of operation connection-oriented (CO) and connection-less (CL). Much of the ISO specification (DIS 11577) is unreadable because of the CO mechanism. Ipsec, luckily, only needs the connection-less mode of operation. The examples of SP3 encapsulation below are similar to NLSP with two important differences. First, the model for SP3 places it only at the top (SNICP) of the network layer. Second, the IP/SP3/IP modes of encapsulation explicitly define a complete IPv4 header as part of SP3 (the SP3-D mode). h) | link | IP | SP3-N | TP or ? ... | i) | link | CLNP | SP3-N | TP or ? ... | j) | link | IP | SP3-A(S-NSAP,D-NSAP) | TP or TCP or UDP or ... | k) | link | CLNP | SP3-A(S-NSAP,D-NSAP) | TP or TCP or UDP or ... ? | l) | link | IP | SP3-D( IP ) | TP or TCP or UDP or ... | m) | link | CLNP | SP3-I(CLNP ) | TP or TCP or UDP or ... | As an additional point of confusion one mode of SP3 (SP3-N) is identical to one mode of SP4 (SP4-E). This commonalty is an artifact of compromise made to ease the religious wars of layer 3/4 security placement. n) | link | CLNP | TP(SP4-E) | ISO Session etc.. | Some transport layer zealots still feel that SP4-E is viable for ipsec. I still strongly advocate NLSP as a starting point for ipsec, but at this early stage it might be useful to examine the encapsulation characteristics of ipsec. To provide host-to-host security the following example of ipsec protocol encapsulation seems reasonable. o) | link | IPv4 | IPSEC | any client protocol of IP | p) | link | IPv7 | IPSEC | any client protocol of IP | Alternatives for IPSEC encapsulation for host-to-subnet and subnet-to- subnet security include example o & p above along with: s) | link | IPv4 | IPSEC | IPv4 | any client protocol of IP | t) | link | IPv4 | IPSEC | IPv7 | any client protocol of IP | u) | link | IPv7 | IPSEC | IPv4 | any client protocol of IP | v) | link | IPv7 | IPSEC | IPv7 | any client protocol of IP | w) | link | IP | IPSEC(S-addr,D-addr) | any client protocol of IP | Given that proposals exist for installing NLSP directly over IEEE 802.2 the following example is of interest. This application is beyond the charterUs scope of protecting clients of IP. x) | link | IPSEC | any 802.2 SNAP | Recursive cryptographic encapsulation is yet another example to consider. y) | link | IP |IPSEC|IPSEC|... | any client of IP including IPSEC | Finally, we should recognize the suggestions to embed cryptographic security directly into IPv7. z) | link | IPv7(IPSEC) | any client protocol of IP | The only advantage of embedding ipsec into IPv7 would be in saving a few bytes of header information. There are more permutations of the examples above, but IUve run out of letters. Paul From owner-big-internet@munnari.oz.au Sat Dec 5 10:19:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23115; Sat, 5 Dec 1992 10:19:57 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212042319.23115@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13761; Sat, 5 Dec 1992 04:45:42 +1100 (from jcurran@nic.near.net) To: big-internet@munnari.oz.au Cc: yakov@watson.ibm.com Subject: Re: Criteria BOF Date: Fri, 04 Dec 92 12:45:07 -0500 From: John Curran -------- We now know the criteria that "MUST" be satisfied by IPv4+n. This is progress, since there was some debate before about the obvious need for some functionality. Yakov is correct when he noted the criteria bof did not reach consensus that all remaining criteria are "SHOULD IMPLEMENT". This is probably because we did not make it to prioritizing the remaining items. A document that reflects the BOF output cannot conclusively state that all of the remaining criteria were considered desirable by the community. That question simply wasn't asked, so there's no way to tell. So I ask now to Yakov (and anyone else): "Is there any of the remaining criteria which you do not consider desirable and which, in fact, will pose a serious problem if present?" If no one responds, then we can use the term SHOULD and note that the document reflects the discussion from the bof meeting and the WG mailing list. /John From owner-big-internet@munnari.oz.au Sat Dec 5 13:52:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29713; Sat, 5 Dec 1992 13:52:41 +1100 (from owner-big-internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14908; Sat, 5 Dec 1992 05:42:03 +1100 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA15869; Fri, 4 Dec 92 13:03:20 -0500 Date: Fri, 4 Dec 92 13:03:20 -0500 Message-Id: <9212041803.AA15869@worldlink.worldlink.com> From: David M. Piscitello To: big-internet@munnari.oz.au Cc: tuba@lanl.gov Subject: FYI: Re: one person's view about recent IETF and IPv7 My two cents: IMHO - you would map SNMP onto UDP (onto CLNP) packets - no MIB work is necessary for UDP (already in MIB-II) - no MIB work is necessary for CLNP (done deal) - some MIB work remains for routing protocols (underway in NOOP) Personally, if you are discussing SNMP, there is no reason to define what UDP runs over. Am I incorrect in assuming that the corresponding set of MIB activities is required for SIP, PIP, IPAE, (others)? ------ Forwarded Message There is no need to change the network management framework. SNMP is defined as running over UDP. There is no definition of what UDP runs over :-) SNMP-over-UDP works if UDP runs over: - IPv4 - SIP/IPAE - TUBA - raw datalink > In terms of how SNMP should work over CLNP, I will defer to Marshall or > any other SNMP guru as to how RFC1283 ( Rose, M. SNMP over OSI. > 1991 December ) should be updated in light of TUBA (or for SNMP v2 > for that matter). I can imagine there will need to be some MIB work > done for TCP/UDP over CLNP. -- Frank Kastenholz ------ End of Forwarded Message From owner-big-internet@munnari.oz.au Sat Dec 5 14:41:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB01148; Sat, 5 Dec 1992 14:41:41 +1100 (from owner-big-internet) Return-Path: Received: from relay.hp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15936; Sat, 5 Dec 1992 06:26:36 +1100 (from eva@hpindda.cup.hp.com) Received: from hpindda.cup.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA15303; Fri, 4 Dec 92 11:26:02 -0800 Received: by hpindda.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA26586; Fri, 4 Dec 92 11:27:07 pst From: Eva Kuiper Message-Id: <9212041927.AA26586@hpindda.cup.hp.com> Subject: Re: FYI: Re: one person's view about recent IETF and IPv7 To: dave@mail.bellcore.com Date: Fri, 4 Dec 92 11:27:05 PST Cc: big-internet@munnari.oz.au, tuba@lanl.gov, eva@hpindda.cup.hp.com In-Reply-To: <9212041803.AA15869@worldlink.worldlink.com>; from "David M. Piscitello" at Dec 4, 92 1:03 pm Mailer: Elm [revision: 64.9] David, I agree and I also would like to add that I don't see the need for any changes in RFC 1283 in light of TUBA. RFC 1283 addresses the issue of SNMP over CLTP (the OSI equivalent of UDP) and it is merely an alternative way of supporting SNMP for systems that do not support TCP (strange as it may sound, there are some of those around!). Eva > > > My two cents: IMHO > > - you would map SNMP onto UDP (onto CLNP) packets > - no MIB work is necessary for UDP (already in MIB-II) > - no MIB work is necessary for CLNP (done deal) > - some MIB work remains for routing protocols (underway in NOOP) > > Personally, if you are discussing SNMP, there is no reason > to define what UDP runs over. > > Am I incorrect in assuming that the corresponding set of MIB activities > is required for SIP, PIP, IPAE, (others)? > > ------ Forwarded Message > > There is no need to change the network management framework. SNMP is defined > as running over UDP. There is no definition of what UDP runs over :-) > > SNMP-over-UDP works if UDP runs over: > - IPv4 > - SIP/IPAE > - TUBA > - raw datalink > > > > In terms of how SNMP should work over CLNP, I will defer to Marshall or > > any other SNMP guru as to how RFC1283 ( Rose, M. SNMP over OSI. > > 1991 December ) should be updated in light of TUBA (or for SNMP v2 > > for that matter). I can imagine there will need to be some MIB work > > done for TCP/UDP over CLNP. > > > -- > Frank Kastenholz > > ------ End of Forwarded Message > > From owner-big-internet@munnari.oz.au Sat Dec 5 23:37:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16609; Sat, 5 Dec 1992 23:37:08 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212051237.16609@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03342; Sat, 5 Dec 1992 15:38:56 +1100 (from ULLMANN@PROCESS.COM) Date: Fri, 4 Dec 1992 23:38 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: Re: criteria BOF Hi, When you (John Curran) ask: "Is there any of the remaining criteria which you do not consider desirable and which, in fact, will pose a serious problem if present?" And then say lack of response is an indication that they should be SHOULDs, you skip over a crucial question, to which you assume, with nothing resembling proof, that the answer is affirmative: Does the support for the feature belong in the IP layer? Even more: Is the feature needed? Does it even work? ---- To apply these questions to a couple of the hypothetical SHOULDs, starting with Flows and "Multimedia": IMNSHO, "multimedia" is nothing special. It is, rather, another point on the isochronicity/delay/bandwidth graph, which happens to be outside the performance of some parts of the present Internet. The history of networking protocols is strewn with the remains of development efforts that started from the premise that (e.g.) TCP was too complex and/or too inefficient for some application, leading to the development of some idiosyncratic "lightweight" protocol to accomplish the performance desired. This comes from a (perfectly understandable) failure to distinguish between the capabilities of a protocol and the limitations and outright failures of implementations. (An example: X.25 is often perceived as slow because of typical PSDN services, and typical implementations. But there are implementations that easily run at 10Mbps; there is nothing slow about the protocol itself.) The effort that starts by trying to discard part of what (I'll use TCP as an example) TCP does to save something, usually ends up re-inventing all that TCP did in other ways, almost always seriously inferior, and sometimes pushed into layers where it doesn't belong. Remember the argument over whether TCP/IP was appropriate for LANs, having been designed for slow WANs, and obviously much too inefficient for the enormous bandwidth available? It wasn't as silly as it looks now; thrust has since increased to the point where a host can saturate the ethernet with one TCP/IP connection. (And is very nearly doing the same to FDDI.) Things that we take as requiring special methods to get "real time" response, end up 5 or 10 years later being done with ordinary s/w on the general purpose computer. In 1972, we had to have special logic connecting the puck/tablet to the scope to do a crosshair cursor on the screen, which was drawn with low-energy vectors so it wouldn't stay in the phosphorence being held by a voltage on the screen (so that the cursor wouldn't leave a trail.) And the digital read-out of the position was done with nixie tubes, it could not be done fast enough by sending updates to the 110 bps Infoton glass-TTY. Now you grab and drag the _entire_image_of_the_object_ and it is all done by the commodity CPU chip doing everything in pure Von Neumann bottleneck bit-blitting. But: the thrust is such that it is real time to our human perception. And that specially designed TCP replacement is history, having been blown away by TCP itself. It is, of course, certainly useful to deploy the special purpose solution when the general one is out of reach, rather than waiting. (Even if automatic digital telephony had been conceived of in, say, 1920, would we have been served by waiting, and not deploying manual analog? :-) But when the general solution is within current technology, it is virtually certain to become a commodity in a few years. VIA-FTP was an attempt to do a lightweight FTP/TCP. NETBLT tried to do a higher performance TCP for bulk transfers. And some other ones I won't go into. But I see it again, possibly in ISO "skinny stack", in Frame Relay (which tried to discard the "inefficient" parts of X.25, and the users have to add the missing functions back in), and finally in the present A/V work, which discards TCP, and then tries to force fit the missing functions back into vat and IP, both in inferior versions. ----- Sorry about the length of that. Point is, we should be PROVING that the function is needed at all, AND belongs in the IP layer, before we even PERMIT it to be a criteria for IP. To me, flows/etc is probably a SHOULD NOT. (Note that _that_ is only an opinion, NOT a proof.) ----- Mobile hosts: First, we distinguish them from portable hosts, agreed? A truly mobile host has to communicate by RF with stations near its location. (I haven't heard of any other methods. :-) Note that a satellite is a nearby "station.") To be a global system, this has to be operated by the telephone companies, and will be the same system used to provide global digital (micro-)cellular telephones. In a few years, laptops will have integral cell phones. (Note that this technology exists now.) A mobile host is a digital cellular ISDN subnetwork access point. It stays at the same E.163/E.164 address, regardless of its physical location. Ergo: to the IP layer, it is in a fixed location. I believe this demonstrates that mobile host support does not belong in the IP layer. Which, of course, does not in any way diminish the utility of IP tunneling hacks and other wonderful, but temporary, ways of showing ourselves what the net can do; which we can then do right later. ----- Never forget what the IP layer does: it exists to provide the absolute minimum to move data in blocks from host A to host B, for arbitrary A and B, with a universal protocol. Full Stop. IPv4 does what is needed; it is proof by existance that the layer is understood. None of the "futures" criteria is well enough understood to be sure of what they need from each layer, but I maintain (opinion again :-) that they need _nothing_ from the IP layer. I thank anyone who is still with me after all this length; please get the new draft-ullmann-ipv7-01.txt and send me your comments. With my Best Regards, Robert Process Software Corporation +1 508 879 6994 x226 (800) 722 7770 x226 From owner-Big-Internet@munnari.oz.au Sun Dec 6 05:34:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26664; Sun, 6 Dec 1992 05:34:51 +1100 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26656; Sun, 6 Dec 1992 05:34:24 +1100 (from kre) To: ULLMANN@PROCESS.COM (Robert L Ullmann) Cc: big-internet@munnari.oz.au Subject: Re: criteria BOF In-Reply-To: Your message of Fri, 04 Dec 92 23:38:00 -0500. Date: Sun, 06 Dec 92 05:34:01 +1100 Message-Id: <29314.723580441@munnari.oz.au> From: Robert Elz Date: Fri, 4 Dec 1992 23:38 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) Does the support for the feature belong in the IP layer? Is the feature needed? Does it even work? These are certainly reasonable questions, but I think you've gone a little off the track in this bit ... To apply these questions to a couple of the hypothetical SHOULDs, starting with Flows and "Multimedia": Multimedia I agree is nothing special, and I'm not sure why its mentioned, other than as an example of where flows might be used. The flow stuff isn't to suggest that some new protocol is being invented to supplant tcp, or whatever, just that it would be nice if the network layer has some way of guaranteeing the bandwidth that some applications need (and multimedia is an example) - not average bandwidth, but continuous bandwidth. Is it needed at the IP layer - clearly, that's where the packet forwarding is all done, and consequently where the queueing delays (mostly) all occur. Is it needed, that's more debatable, but I suspect yes - however much thrust (bandwidth) you supply there's no way that you can supply enough that you can guarantee that an application that needs some slice will get what it needs, all the time, without some way to tell the routers along the path of the need. Does it work - well, that's the point - the contending protocols should demonstrate that its at least possible. Mobile hosts: First, we distinguish them from portable hosts, agreed? No - I don't agree with that at all. There needs to be something to deal with hosts whose address changes. That's what I mean by "mobile hosts" - whether the host is bolted to a floor somewhere, or is inside my wristwatch doesn't matter at all. A truly mobile host has to communicate by RF with stations near its location. Something like this while a host is actually moving around, but its not going to be moving all the time, or its not necessarily going to be moving all the time. The simple, obvious, example is your typical laptop type machine. That you want to have plugged into your local fddi or something while at work, then unplug, and continue working as you ride home on the bus, or train, or plane, or whatever, and then plug back into the net via 2Mb ISDN (or something) when you get home - the box will probably have one address at work, one of your E.nnn addresses while its on the plane, and another address when I finally get home, given that it will be connected to some totally different provider. My news reading session (and others) should stay alive the whole time. Never forget what the IP layer does: it exists to provide the absolute minimum to move data in blocks from host A to host B, for arbitrary A and B, with a universal protocol. Full Stop. IPv4 does what is needed; But IP does lots more than the absolute minimum. SIP is coming closer to your minimum, but even it does much more than you (here at least) seem to imply is needed. kre From owner-Big-Internet@munnari.oz.au Tue Dec 8 00:14:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14663; Tue, 8 Dec 1992 00:14:07 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9212071314.14663@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14660; Tue, 8 Dec 1992 00:14:00 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7961; Mon, 07 Dec 92 08:14:12 EST Date: Mon, 7 Dec 92 08:14:11 EST From: yakov@watson.ibm.com To: ULLMANN@PROCESS.COM, big-internet@munnari.oz.au Subject: criteria BOF Ref: Your note of Fri, 4 Dec 1992 23:38 -0500 >...you skip over a cricial question, to which you assume, with >nothing resembling proof, that the answer is affirmative: > > Does the support for the feature belong in the IP layer ? > >...Point is, we should be PROVING that the function is needed > at all, AND belongs in the IP layer, before we even PERMIT it to be a criteria for IP. Robert, With respect to mobility, VMTP may be used as an "existence proof" that support for mobility NEED NOT belong to the network layer (through it may). In VMTP location transparence is tied to the transport layer. With respect to flows, discussing flows in the context of just the network layer is likely to be insufficient. Support for flows would impact both layers above the network layer, and layers below the network layer. To illustrate possible scope of related issues, here are few questions: (a) What are the mechanisms to pass flow requirements from an application down to the network layer ? (b) Should we assume that TCP (or UDP) will be used as a transport for applications requiring flows ? (c) What are the implications of providing support for flows at the network layer on the underlying subnetwork (Layer 2) technology ? >Even more: > > Is the feature needed ? Does it even work ? > I think your last question ("Does it even work ?") should be stated more strongly: Does it even work, GIVEN ALL THE MANDATORY REQUIREMENTS ? Yakov. P.S. There is another basic question that needs to be asked. If, in fact, we are aiming our design to last for 20 years, should we assumed that the "layered cake" architecture is a proper framework for the next 20 years of computer communications ? From owner-Big-Internet@munnari.oz.au Tue Dec 8 00:30:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15006; Tue, 8 Dec 1992 00:30:48 +1100 (from owner-Big-Internet) Return-Path: Received: from CSEIC.SAIC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15000; Tue, 8 Dec 1992 00:30:38 +1100 (from carlberg@cseic.saic.com) Received: from caspian.cseic.saic.com by cseic.saic.com (4.1/1.34) id AA02863; Mon, 7 Dec 92 08:27:20 EST Date: Mon, 7 Dec 92 08:27:20 EST From: carlberg@cseic.saic.com (Kenneth Carlberg) Message-Id: <9212071327.AA02863@cseic.saic.com> To: kre@munnari.oz.au Subject: Re: criteria BOF Cc: big-internet@munnari.oz.au > Mobile hosts: > First, we distinguish them from portable hosts, agreed? > > No - I don't agree with that at all. There needs to be > something to deal with hosts whose address changes. That's > what I mean by "mobile hosts" - whether the host is bolted to > a floor somewhere, or is inside my wristwatch doesn't matter > at all... > > ...My news reading session (and others) should stay alive the > whole time. Your last sentence is what distinguishes the mobile from the portable; ie. maintaining connections as the host moves vs. simply (note: a relative term ;-) obtaining the current location of the host. These are two different functions. The (atomic) solution to one function, in my opinion, does not specifically solve the needs of the other function - hence the distinction. -ken From owner-Big-Internet@munnari.oz.au Tue Dec 8 02:57:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18814; Tue, 8 Dec 1992 02:57:28 +1100 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18807; Tue, 8 Dec 1992 02:57:18 +1100 (from huston@ps73.ako.dec.com) Received: by inet-gw-1.pa.dec.com; id AA25620; Mon, 7 Dec 92 07:57:12 -0800 Received: by ps73.ako.dec.com (5.57/Ultrix V4.2-sdh-921109); id AA16022; Mon, 7 Dec 92 10:56:57 -0500 Message-Id: <9212071556.AA16022@ps73.ako.dec.com> To: Robert Elz Cc: ULLMANN@PROCESS.COM (Robert L Ullmann), big-internet@munnari.oz.au Subject: Re: criteria BOF In-Reply-To: Your message of "Sun, 06 Dec 92 05:34:01 +1100." <29314.723580441@munnari.oz.au> Date: Mon, 07 Dec 92 10:56:56 -0500 From: huston@ps73.ako.dec.com X-Mts: smtp >The flow stuff isn't to suggest that some >new protocol is being invented to supplant tcp, or whatever, That wasn't the suggestion. TCP was offered as an example of times when folks said a given technology/protocol couldn't hack it, then reinvented it in some other form. The argument is that it has not been proven that 1) flows are a necessary piece of IPv7, and if they are, 2) they belong at the IP layer. >just that it would be nice if the network layer has some >way of guaranteeing the bandwidth that some applications >need (and multimedia is an example) - not average bandwidth, >but continuous bandwidth. This also has not been *proven* to be a problem. As Robert U. pointed out, technology moves quickly. If the public carriers can sell you a circuit (like they do for your home phone) and guarantee you'll have such-and-such bandwidth, why do you need special IP support? Your cable TV wiring supplies a fair amount of bandwidth, and they weren't even trying - and that started years ago. The data networks will (my opinion...) move toward the phone model. Applications that need special considerations can still order things like dedicated T3. Let the carriers worry about guaranteeing bandwidth - IP probably won't need to. > Mobile hosts: > First, we distinguish them from portable hosts, agreed? > >No - I don't agree with that at all. There needs to be >something to deal with hosts whose address changes. That's Yes, there needs to be a way to deal with address changes. However, I agree with Robert Ullmann and Kenneth Carlbrg that there is a fundamental difference between that and a host that just moves around. So let's maintain the mobile/portable distinction. >the box will probably have one address >at work, one of your E.nnn addresses while its on the plane, >and another address when I finally get home, given that it >will be connected to some totally different provider. There's no reason the IP address needs to change with all those transitions. Your last statement is also not a given, from your node's point of view. It's a given today, but not for the (not so distant) future. And even if it does remain a necessary point in the future, Yakov (@watsom.ibm.com) has showed that it doesn't need to be handled at the IP layer. > IPv4 does what is needed; > >But IP does lots more than the absolute minimum. I respectfully disagree. IP does just what Robert U. stated - it gets data from A to B using a universal protocol. Dealing with the multitude of stuff beneath it (frag/reassem, routing, etc.) is part of getting it there. Steve Huston huston@ps73.ako.dec.com On contract to, but not speaking for, Digital Equipment Corporation From owner-Big-Internet@munnari.oz.au Tue Dec 8 12:38:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08669; Tue, 8 Dec 1992 12:38:38 +1100 (from owner-Big-Internet) Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08666; Tue, 8 Dec 1992 12:38:31 +1100 (from kre) Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01503; Tue, 8 Dec 1992 09:36:12 +1100 (from solensky@andr.UB.com) Return-Path: Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA05448; Mon, 7 Dec 92 14:36:02 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA25415; Mon, 7 Dec 92 17:36:04 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA20695; Mon, 7 Dec 92 17:31:57 EST Date: Mon, 7 Dec 92 17:31:57 EST From: Frank T Solensky Message-Id: <9212072231.AA20695@fenway.andr.UB.com> To: kre@munnari.oz.au Subject: New growth charts Resent-To: Big-Internet@munnari.OZ.AU Resent-Date: Tue, 08 Dec 92 12:38:13 +1100 Resent-Message-Id: <141.723778693@munnari.oz.au> Resent-From: Robert Elz The monthly NFSnet growth charts have just been made available at munnari.oz.au:big-internet/nsf-netnumbers-9212.ps via anonymous FTP. For the benefit of those that may be new to the list: this PostScript file usually contains two graphs. The first is a plot of the number of networks represented in the NSFNet policy routing database from mid-1988 through the current time. It also has an estimate of the number of networks that will appear over the next couple of years and is based on the suggestion by Van Jacobson that a logistic curve would be good model for projecting future growth and was also used in an independent effort by Vijay Gurbaxani in a similar analysis of the growth of BITNET in a CACM article [Dec. 90]. The second graph charts how the estimate of the maximum number of networks has changed from month to month. For example, using the data available in January 1991, this model predicted that the curve would flatten out at 2718 networks (a point we've long since passed). We would become more confident on the reliability of the estimate on the future part of the first curve if the second were relatively flat over recent months. It's pretty clear from looking at the second that this currently isn't the case. The data last month predicted that there would be 7425 by December 1, there were actually 7854 networks (7425 was actually available by the end of the first week). There were 3751 networks this time last year, thus the growth rate is still a little better than doubling each year ('better' being a relative term). The prediction on the maximum number of networks grew from 22,551 last month to 30,059 (an increase of 33.1%) and predicts 7958 for the end of the year (a level already surpassed by Friday). This month also includes similar graphs of the estimated number of host systems connected to the Internet. The data is based on the "zone" reports by Mark Lottor at SRI (see RFC-1296). While two points do not a trend make, it is worth noting that there was only a relatively small revision in the estimated maximum number of hosts and that it was a downward revision. The estimate for number of Zone hosts for the end of January is 1,288,500. From owner-Big-Internet@munnari.oz.au Wed Dec 9 01:00:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07255; Wed, 9 Dec 1992 01:00:55 +1100 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07250; Wed, 9 Dec 1992 01:00:48 +1100 (from kasten@ftp.com) Received: by ftp.com id AA08582; Tue, 8 Dec 92 09:00:54 -0500 Date: Tue, 8 Dec 92 09:00:54 -0500 Message-Id: <9212081400.AA08582@ftp.com> To: big-internet@munnari.oz.au Subject: IPV7 Criteria Mailing List From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Hi, In response to the overwhelming interest in this topic, a new mailing list for IPv7 criteria discussions has been set up. This mailing list is criteria@ftp.com -- as usual, send administrivia to criteria-request@ftp.com. The "charter" of this list is to discuss the criteria that will be used to evaluate the various proposals for IPv7. The basis for these discussions should be the Internet Draft written by Criag Partridge and myself, as discussed at our BOF at the Washington DC IETF. - These discussions should provide Craig and I with more feedback and information so that we can fill out the details in our document. We also hope that an open discussion will take place on each of the items in our document. - These discussions should provide feedback to the proposal developers as to where the general community wishes to see IPv7 go. The developers would then be able to take this feedback and make their proposals better. - These discussions should provide input to the deliberations of the leadership as they study and evaluate the proposals. This information should help the IAB and IESG frame their own discussions and evaluations so that they can examine the proposals in an orderly manner. - These discussions should provide feedback to the community at large so that we all can understand where various segments of the community wish IPv7 to go. It is especially important that the community understand the IAB's and IESG's desires and goals. I should note that THERE IS NO IPV7 CRITERIA WORKING GROUP. The discussions on this list are "unofficial" in the sense that there is no IETF Chartered working group providing the forum for the discussions. If, at some point in the future, there is enough interest in forming a w.g., then we will go to the IESG, etc, and do the right thing. I have posted this note to many places where people might be hanging out that could be interested in this topic. I am sure that many of you will get multiple copies (I should get 6 :-). I am sorry about that. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Wed Dec 9 07:13:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19211; Wed, 9 Dec 1992 07:14:20 +1100 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB19170; Wed, 9 Dec 1992 07:13:37 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA24612; Tue, 8 Dec 92 14:45:29 -0500 Date: Tue, 8 Dec 92 14:45:29 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9212081945.AA24612@er.doe.gov> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: one person's view about recent IETF and IPv7 From jnc@ginger.lcs.mit.edu Wed Dec 2 11:14:59 1992 Received: by ginger.lcs.mit.edu id AA13740; Wed, 2 Dec 92 11:15:42 -0500 Date: Wed, 2 Dec 92 11:15:42 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9212021615.AA13740@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov Subject: one person's view about recent IETF and IPv7 Cc: jnc@ginger.lcs.mit.edu Also note that perhaps the most critical feature of a protocol is the # of folks it connects you to. That's true, although everyone is going to realize the importance of trying to leverage off the existing user community by providing good interoperabilty tools; it may be the quality of the interoperabilty tools which decide which one wins. What is desperately needed for the next 24 months, although perhaps not from this group is a strategy for a set of tools to hide protocol and address structure changes from users of the net. Yes, we need this, but given vendor release cycles, etc, could we even get these designed, implemented and out in 24 months? I'll remind everyone that something along this line is going to be needed to maximize CIDR utility. Having lived through Decnet vs IP protocol wars and watched the wealth of PC, MAC,... protocols which have sprung up, I suspect that the speed of this consensus emergence is VERY SLOW...In fact the second law of thermodynamics, Mr. Murphy, and the attractiveness of local optimizations all work against this! All too true, sadly. You've also forgot to mention another, inertia: once a group of people have a working communication system, or a big manufacturer has a lot of machines deployed with the X protocol in them, there's a lot of resistance to short-term change, no matter how obvious the long-term future is. Noel If we can't deploy tools rapidly then the transition strategy based on CIDR will fail (and we certainly cant deploy a new protocol!) Also, perhaps if we manage these tools (which every local site net manager wants anyway) we can buy oursevles the time to rationally decide on son of IP. Dan From owner-Big-Internet@munnari.oz.au Fri Dec 11 06:09:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02617; Fri, 11 Dec 1992 06:10:13 +1100 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02607; Fri, 11 Dec 1992 06:09:54 +1100 (from craig@aland.bbn.com) Received: from port14.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA19877; Thu, 10 Dec 92 14:09:39 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA21971; Thu, 10 Dec 92 11:08:03 PST Message-Id: <9212101908.AA21971@aland.bbn.com> To: huston@ps73.ako.dec.com Cc: big-internet@munnari.oz.au Subject: need for flow support in internetwork layer From: Craig Partridge Date: Thu, 10 Dec 92 11:08:02 -0800 Sender: craig@aland.bbn.com > That wasn't the suggestion. TCP was offered as an example of times when > folks said a given technology/protocol couldn't hack it, then reinvented it > in some other form. The argument is that it has not been proven that 1) > flows are a necessary piece of IPv7, and if they are, 2) they belong at > the IP layer. Steve: I think we can reasonably debate point (1) but I don't see how anyone can reasonably argue that if flow support of some variety is supported that it will not impose some requirements on the internetwork layer. In brief, the major concern for flows is moderately predictable delay, and some firm guarantees about minimum bandwidth provided. OK, now consider a router, receiving traffic from hundreds of sources, some of which we might assume are misbehaving or misguessing the available bandwidth and sending lots of datagrams. How is the router to make sure that the datagrams of the flows don't get screwed by the misbehaving sources if it cannot distinguish guaranteed datagrams from non-guaranteed datagrams? Making the problem harder, suppose some of those misbehaving sources are misbehaving flows -- how are we to protect well-behaved flows from misbehaving ones if we cannot distinguish among flows? I think that a way to identify flows is a minimum requirement IFF we buy into having flows. Craig PS: There's a scheme proposed that has routers read transport headers to generate unique flow IDs. That might allow us to leave flow IDs out of the IPv7 header and still have flows. But the IPv7 *SPECIFICATION* will still have to address queueing issues raised by the existence of flow ids, however they are created and managed. From owner-big-internet@munnari.oz.au Fri Dec 11 12:33:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15137; Fri, 11 Dec 1992 12:34:01 +1100 (from owner-big-internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08181; Fri, 11 Dec 1992 09:28:21 +1100 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA11240; Thu, 10 Dec 92 14:27:48 PST Date: Thu, 10 Dec 92 14:27:48 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9212102227.AA11240@saffron.acc.com> To: craig@aland.bbn.com Subject: Re: need for flow support in internetwork layer Cc: big-internet@munnari.oz.au, huston@ps73.ako.dec.com >> I think that a way to identify flows is a minimum requirement IFF we >> buy into having flows. >> PS: There's a scheme proposed that has routers read transport >> headers to generate unique flow IDs. That might allow us to leave >> flow IDs out of the IPv7 header and still have flows. But the IPv7 >> *SPECIFICATION* will still have to address queueing issues raised by >> the existence of flow ids, however they are created and managed. I wonder if you are referring to my comments of a few weeks ago here. If so, I think we have to agree that transport layer information can be relied on if and only if sufficient such information is present in every message to associate it with the pre-negotiated flow - ie, no network layer fragmentation (read: MTU discovery is supported in the routers and used by the hosts). That has some implications for CLNP if IPv7 is a flavor of CLNP. Like you here, I'd like to separate the debate into four sections: 1) do we need flows? The answer here is certainly yes IF we are talking about negotiating bandwidth and delay requirements through the internet. Seems like the debate needs to focus on this requirement. 2) given that we do, at what layer do they belong? I would argue that they are implemented largely in the data link layer (traffic rate controls and queuing strategies) based on information provided to the data link by the network layer. There's going to be some co-operation between layers here, and it's not obvious to me that arguing about who's in control is a wise use of time. 3) given that we do, how do we negotiate them? I'd like to believe that this is related to the problem Sue Estrin has bitten off in the SDRP development - the "so what route should we choose and how do we choose it?" part. I tend to think that this is best solved by an application that parameterizes the network and/or data link layers with a correspondence between identifiable traffic and forwarding characteristics. My mental analogy is routing, wherein an application (RIP, OSPF, BGP, ...) parameterizes the network layer with a correspondence between destinations and next hops. 4) given that we do, how do we identify traffic as relating to them? There are two obvious approaches: a flow identifier and a combination of information that would be matched by a fast path matcher. The former is elegant; however, if it is used, I immediately wonder why I still need the network layer addresses. If I know the flow (traffic with flow identifer will be forwarded with characteristics ) why not just make it a virtual circuit (traffic with flow identifer will be forwarded *to*next*hop** with characteristics )? However, it doesn't work with *any* existing protocols. Therefore, I am still going to have to implement the more classical forwarding algorithms. Having said that, why not just make the matcher be smart enough to identify the flows based on cached route decisions, with the negotiation being one of the sources of cached route decisions? Fred From owner-big-internet@munnari.oz.au Fri Dec 11 13:27:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16801; Fri, 11 Dec 1992 13:28:45 +1100 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14376; Fri, 11 Dec 1992 12:11:50 +1100 (from craig@aland.bbn.com) Received: from port14.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA23067; Thu, 10 Dec 92 20:11:16 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA24159; Thu, 10 Dec 92 17:09:42 PST Message-Id: <9212110109.AA24159@aland.bbn.com> To: big-internet@munnari.oz.au Subject: is the sub-network or internetwork responsible for flows? Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 10 Dec 92 17:09:42 -0800 Sender: craig@aland.bbn.com Hi: I've gotten a couple of queries about why it is that the subnet cannot handle all the flow problems and leave IPv7 alone and I'd like to respond to those questions before I run off to teach a course on this subject in Belgium next week. First, let's assume we believe in internetworking -- disparate types of networks attached by routers to create a large virtual network. There exist subnetwork technologies capable of supporting service guarantees. Right now, all of them allocate some amount of bandwidth on a regular basis to conversations between particular hosts. There's also typically the ability to send some unreserved traffic as well. Let's assume for a moment that *ALL* subnets support this new type of service. OK, now a router gets two datagrams destined to host XXX on an attached subnet. First datagram is a datagram containing an NFS file block (big), the second datagram is part of a screen bitmap for a video conference. There exists some reserved bandwidth between router and host XXX for the video conference. Now, if all IP datagrams are the same, how does the router figure out that it better not send the NFS datagram using its reserved bandwidth? If it sends the NFS datagram over the reserved channel, the datagram may be big enough that there's no reserved bandwidth left for the video conference datagram -- and if the network is busy, there may not be enough unreserved bandwidth to send the video datagram in unreserved mode. At this point, I think it becomes clear that if we have reserved and unreserved traffic, at minimum IPv7 better be able to distinguish between reserved and unreserved traffic and queue them separately. That's a first step towards flow identification. In fact, I believe having looked at some of these networks that you'll probably want more than a bit, but the details of how the networks will do flow support is still sketchy enough that I'm not prepared to defend that assertion. But taking the scenario a bit farther, let's assume that there are some subnets that don't support bandwidth allocation themselves. Good examples are PPP and FDDI. PPP's a good example because it is clear that if the sender interleaves its datagrams carefully on a PPP line it should be able to provide performance guarantees. FDDI's a good example because people already do very successful video conferencing over FDDI (without guarantees). Now the router needs to schedule how it puts its datagrams onto the PPP link or the FDDI ring (where it gets a limited access to the token each revolution) to support flows. Clearly this is a desirable service. (If we support flows in some of our subnet technologies, the ability to support flows over other subnets with help from the internetwork layer would clearly be a win). But the only way it works is if IPv7 takes on the responsibility to do some queue management and bandwidth management based on the service requirements of individual flows. (For example, if if the router's got a 8-bit voice sample and a 8-Kbit video sample to be forwarded over the PPP link, the router needs to be able to figure out if the voice sample has to go first [to avoid being delayed over long by the video sample] -- and keep in mind the decision may not be this clear cut in all case). At this point we've said we need flow support in the internetwork layer, both to identify various types of traffic, and to allow us to implement flow management over subnets which can't provide service guarantees without help. One last thing -- there's another point of view. Some people have argued that we should get rid of the internetwork layer, and use a single protocol (usually ATM) as our universal protocol. This is really an argument that internetworking isn't necessary because we're all going to buy the same type of network. Historically users haven't done this -- they've bought the network appropriate for their needs, be it Ethernet, FDDI, SLIP, PPP, token ring, HIPPI, etc. There exist multiple gigabit network technologies -- I find it hard to believe the market is just going to buy one. And if you believe this view, you probably shouldn't be worried about IPv7 anyway. Right? :-). Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-Big-Internet@munnari.oz.au Fri Dec 11 19:50:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00359; Fri, 11 Dec 1992 19:50:42 +1100 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00352; Fri, 11 Dec 1992 19:50:31 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA25476; Fri, 11 Dec 1992 09:52:12 +0100 Message-Id: <199212110852.AA25476@mitsou.inria.fr> To: Craig Partridge Cc: huston@ps73.ako.dec.com, big-internet@munnari.oz.au Subject: Re: need for flow support in internetwork layer In-Reply-To: Your message of "Thu, 10 Dec 92 11:08:02 PST." <9212101908.AA21971@aland.bbn.com> Date: Fri, 11 Dec 92 09:52:11 -0500 From: Christian Huitema >Craig > >PS: There's a scheme proposed that has routers read transport headers to >generate unique flow IDs. There may be such a scheme, but it does not hold water. If flows are to be used, that will probably be for relatively high speed connections, i.e. frequent packets: we have an efficiency problem here. Moreover, that will probably be in conjunction with special routing techniques, e.g. source routing the packets through those links or those subnets where ressource have been reserved. Looking in the transport might require peeling off network options, and is not likely to be computationally efficient. The other reason for not looking "inside the transport" is that .. it may not be feasible. Granted, that can be done with TCP or UDP, due to the "port pair" scheme. But that will fail miserably for any transport protocol that uses a "reference negotiation" scheme, e.g. TP4 or XTP: the particular references that will be used cannot be predicted before the connection set up. Now, are we 100% sure that future transport protocols will keep using the 16 bits ports scheme? That is a known limitation for "RPC" like applications, were one can "burn out" connection ids by using fast connections. Also, are we 100% sure that the transport data will never be encrypted? All in all, I think that the case for identifying flows at the network level is pretty strong! Christian Huitema From owner-Big-Internet@munnari.oz.au Sat Dec 12 01:26:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11191; Sat, 12 Dec 1992 01:26:59 +1100 (from owner-Big-Internet) Return-Path: Received: from SPARTA.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11134; Sat, 12 Dec 1992 01:26:25 +1100 (from woody@sparta.com) Received: from [192.48.111.116] by sparta.com (5.65/1.34) id AA25583; Fri, 11 Dec 92 09:27:30 -0500 Date: Fri, 11 Dec 92 09:27:30 -0500 From: woody@sparta.com (Robert "Woody" Woodburn) Message-Id: <9212111427.AA25583@sparta.com> Received: by 630mp.noname (4.1/SMI-4.1) id AA00914; Fri, 11 Dec 92 09:23:17 EST To: fbaker@acc.com Cc: craig@aland.bbn.com, big-internet@munnari.oz.au, huston@ps73.ako.dec.com In-Reply-To: Fred Baker's message of Thu, 10 Dec 92 14:27:48 PST <9212102227.AA11240@saffron.acc.com> Subject: need for flow support in internetwork layer This may be an aside, but I thought I'd comment anyway... I wonder if you are referring to my comments of a few weeks ago here. If so, I think we have to agree that transport layer information can be relied on if and only if sufficient such information is present in every message to associate it with the pre-negotiated flow - ie, no network layer fragmentation (read: MTU discovery is supported in the routers and used by the hosts). That has some implications for CLNP if IPv7 is a flavor of CLNP. IDPR has had the same problem in its flows. The existing gated implementation ignores the problem, by only looking at addresses, not port numbers, although the hooks are there to also use ports. Fragmentation makes it impossible to identify a particular session (which seems to be a reasonable granularity for a flow), and because we were using encapsulation, fragmentation became more of a problem. (no, we didn't implement path discovery for a variety of reasons...) I believe I discuss some of these issues in RFC1241, which might be useful if you haven't read it. 3) given that we do, how do we negotiate them? Do they have to be negotiated? I made the flow ID 32 bits in 1241, but that was to handle problems with ICMP. Dave Mills didn't like this, but I was thinking of hop-by-hop negotiation at the time. Now I think that the benefits of a short identifier are outweighed by the complexity of the ID negotiation. And besides, if ICMP is going to be changed to return more of the header, the need for short flow IDs goes away. IDPR uses a 64bit flow ID, which is assigned by a policy gateway. the first part of the ID is the unique gateway identifier, and the other 32 bits are a locally assigned number. Would assignment of globally unique identifiers to flows be out of the question? When Dave and I bounced this back and forth, he convinced me that dynamic generation of a truly globally unique ID was a very hard problem. Generation of a 64bit "ticket-to-ride" could be done through "ticket servers" who own a portion of the space, but there could be a lot of overhead there. Going one step further to something more like IDPR, if a fixed length part is globally assigned, then what happens when things get bigger than we ever thought they would in another decade? 4) given that we do, how do we identify traffic as relating to them? There are two obvious approaches: a flow identifier and a combination of information that would be matched by a fast path matcher. IDPR uses a combination. It matches on header information to assign the packet to a flow and encapsulate it. Subsequent gateways only look at the flow ID. wood y From owner-Big-Internet@munnari.oz.au Sat Dec 12 04:28:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16738; Sat, 12 Dec 1992 04:29:32 +1100 (from owner-Big-Internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16716; Sat, 12 Dec 1992 04:28:30 +1100 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA00336; Fri, 11 Dec 92 09:28:11 PST Date: Fri, 11 Dec 92 09:28:11 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9212111728.AA00336@saffron.acc.com> To: woody@sparta.com Subject: Re: need for flow support in internetwork layer Cc: big-internet@munnari.oz.au >> 3) given that we do, how do we negotiate them? >> >> Do they have to be negotiated? Well, I'll be the first to admit to being a tad dense; *I* think that a flow can only provide a service guarantee if someone or a set of someones pre-configures a route that provides the guarantee, and conciously doesn't superimpose other routes that would obviate the guarantee. That implies, to my pea brain, either a distributed algorithm that sets up the route, or a central route server. In either case, the flow (traffic service characteristics) must be negotiated with the guy who sets up the route (traffic forwarding characteristics) if the route is to provide the guarantees that the flow demands. Am I on the wrong planet? Fred From owner-Big-Internet@munnari.oz.au Sat Dec 12 06:03:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18818; Sat, 12 Dec 1992 06:03:35 +1100 (from owner-Big-Internet) Return-Path: Received: from SPARTA.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18807; Sat, 12 Dec 1992 06:03:18 +1100 (from woody@sparta.com) Received: from [192.48.111.116] by sparta.com (5.65/1.34) id AA27668; Fri, 11 Dec 92 14:07:01 -0500 Date: Fri, 11 Dec 92 14:07:01 -0500 From: woody@sparta.com (Robert "Woody" Woodburn) Message-Id: <9212111907.AA27668@sparta.com> Received: by 630mp.noname (4.1/SMI-4.1) id AA01286; Fri, 11 Dec 92 14:02:48 EST To: fbaker@acc.com Cc: big-internet@munnari.oz.au, msteenst@bbn.com In-Reply-To: Fred Baker's message of Fri, 11 Dec 92 09:28:11 PST <9212111728.AA00336@saffron.acc.com> Subject: need for flow support in internetwork layer >> 3) given that we do, how do we negotiate them? >> >> Do they have to be negotiated? Well, I'll be the first to admit to being a tad dense; *I* think that a flow can only provide a service guarantee if someone or a set of someones pre-configures a route that provides the guarantee, and conciously doesn't superimpose other routes that would obviate the guarantee. That implies, to my pea brain, either a distributed algorithm that sets up the route, or a central route server. In either case, the flow (traffic service characteristics) must be negotiated with the guy who sets up the route (traffic forwarding characteristics) if the route is to provide the guarantees that the flow demands. Am I on the wrong planet? No, I'm coming from an IDPR universe in a galaxy far, far away, so I presumed something like the IDPR path setup protocol upon things. And I was missing the point that negotiation was for the flow resources that are tagged by some ID, not just the ID itself. I didn't do any work on the resource guarantee part of IDPR for lack of time/funding and I think only now is BBN adding something that gives some sort of resource reservation/guarantee. But now that you mention it, I don't think the details were ever worked out for how IDPR could advertised bandwidth availability, certainly doing it through the policy advertisements would be absurd, because of the bandwidth. So you're right, there would have to be another mechanism that would work in parallel with an IDPR path setup to establish the resource guarantees. Martha, are you there and do you have any comments? wood y From owner-Big-Internet@munnari.oz.au Sat Dec 12 08:24:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22159; Sat, 12 Dec 1992 08:25:14 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22139; Sat, 12 Dec 1992 08:24:40 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21609; Fri, 11 Dec 92 16:24:12 -0500 Date: Fri, 11 Dec 92 16:24:12 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9212112124.AA21609@ginger.lcs.mit.edu> To: fbaker@acc.com, woody@sparta.com Subject: Re: need for flow support in internetwork layer Cc: big-internet@munnari.oz.au, craig@aland.bbn.com But now that you mention it, I don't think the details were ever worked out for how IDPR could advertised bandwidth availability, certainly doing it through the policy advertisements would be absurd, because of the bandwidth. So you're right, there would have to be another mechanism that would work in parallel with an IDPR path setup to establish the resource guarantees. Bandwidth requirements to update *current* bandwidth availability in a flooded fashion were one the reasons the Open Routing WG (in RFC-1126, A.6.4 and A.6.5) decided that this kind of thing should be handled in a somewhat separate mechanism. (Note that historically, congestion avoidance and routing were all rolled up into a ball, e.g. in the new ARPANet routing algorithm.) I say "somewhat" because there are connections between the two, obviously; I just don't think classical routing/forwarding systems can undertake all of the resource allocation demands. It's not that hard to visualize how this would work in the context of an IDPR like system, though: information about links in the topology map includes information on the capacity of the link (e.g. in bit/second), whether the switches into it enforce resource allocation, etc. (This is sort of like your Rand-McNally showing you which roads are high capacity multi-lane jobs by the way they are drawn, etc.) When you go to set up a flow, you check to make sure you can get the resources you need, and try the setup; if one of more links on the path you picked is congested (or just plain full), you get get an error, mark up your map appropriately, and try again. The question is whether this kind of 'distribute resource usage info on demand' is actually more efficient of overall resources than a system which floods information on current resource usages. My bet is it is, but I could be wrong. I'm not sure it would be part of a separate 'parallal .. path setup' mechanism; I'd rather see a single 'flow setup' mechanism which interacts with *both* routing *and* resource allocation. This means, I guess, that whatever path setup mechanism we devise ought to have a syntax which allows extendable semantics, since we probably aren't ready to cast our resource allocation semantics in concrete yet, I reckon. Also, I guess, this indicates that heavy reliance on conventional source routing (as opposed to path setup), as is described in the current SDRP document (which only contains a packet format for source routing), may not be the way to go for the future, where a lot of the traffic (anyone care to blue sky crystal ball what share of the traffic?) will require resource allocation.. Noel From owner-Big-Internet@munnari.oz.au Sat Dec 12 12:02:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29671; Sat, 12 Dec 1992 12:02:30 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29652; Sat, 12 Dec 1992 12:02:03 +1100 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11752>; Fri, 11 Dec 1992 17:01:14 PST Received: by redwing.parc.xerox.com id <57162>; Fri, 11 Dec 1992 17:01:01 -0800 Date: Fri, 11 Dec 1992 17:01:00 PST Sender: Lixia Zhang From: Lixia Zhang Reply-To: lixia@parc.xerox.com To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: fbaker@acc.com, woody@sparta.com, big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: need for flow support in internetwork layer In-Reply-To: Your message of Fri, 11 Dec 1992 13:24:12 -0800 Message-Id: > Bandwidth requirements to update *current* bandwidth availability in a > flooded fashion were one the reasons the Open Routing WG (in RFC-1126, A.6.4 > and A.6.5) decided that this kind of thing should be handled in a somewhat > separate mechanism. (Note that historically, congestion avoidance and routing > were all rolled up into a ball, e.g. in the new ARPANet routing algorithm.) > I say "somewhat" because there are connections between the two, > obviously; I just don't think classical routing/forwarding systems can > undertake all of the resource allocation demands. I'd like to clarify things a bit further: the resource setup takes more than just one step. Yes it is desirable to have a routing protocol that can give a most promising route for each of the setup request, but because of the dynamic changes in network load, I dont think it is possible for a routing protocol to guarantee you a resource setup (the resource available 0.5 sec ago could have gone before you get there). So you always need a separate setup protocol that actually carries the request to each of the routers/switches along the way to make the switches confirm the needed resources and setup proper state. - So, as Noel pointed out, routing itself does NOT do all of the resource allocation work. - A poor routing protocol may lead to some unnecessary failed setup requests (that could have succeeded along a better path), but this is not to say that we cannot have resource setup before we get the best routing protocol. Lixia From owner-big-internet@munnari.oz.au Sat Dec 12 20:40:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17995; Sat, 12 Dec 1992 20:41:25 +1100 (from owner-big-internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25918; Sat, 12 Dec 1992 10:16:28 +1100 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA09945; Fri, 11 Dec 92 15:13:38 -0800 Date: Fri, 11 Dec 92 15:13:38 -0800 From: Eric Fleischman Message-Id: <9212112313.AA09945@atc.boeing.com> To: big-internet@munnari.oz.au, kasten@ftp.com Subject: IPv7 Selection Criteria Proposed IPv7 Selection Criteria I recently hosted a meeting within The Boeing Company in which several of my co-workers discussed with me how we ourselves would order the IPv7 selection criteria which have been identified by the SELECT BOF. We also sought to identify whether we agreed with these criteria and whether we though any criteria should be added or eliminated from the list. What follows is a presentation of the conclusions of our meeting. I would be very surprised if our results would be universally representative of the Internet community. However, I nevertheless submit this as input into our community's discussion of these matters. In any case, the following is how these criteria appear from our "knot hole": ABSOLUTELY THE TWO MOST CRITICAL AND IMPORTANT CRITERIA: * Scalability (supporting at least 10 ** 12 hosts and 10 ** 9 routers). Note, we prefer the explicit reference to "routers" rather than to "networks" (as the Craig Partridge working draft does in section 4.1) because we desire that this criteria not explicitly favor the approach of correlating addressing with the identification of physical networks. That is, several approaches to addressing are possible and we desire this criteria to be as "politically neutral" as possible concerning the implementation of how routing aggregation will occur for a given approach. * Ease/possibility of transition (cost & desirable attribributes to encourage transition). This criteria reflects the importance of protecting existing TCP/IP "investments" through (1) well-established migration paths from IPv4 to IPv7 and (2) "backwards compatibility" of IPv7 supporting IPv4 installations. We suspect that *true* "backwards compatibility" will prove to be elusive but at a barest minimum no functionality must be lost (between IPv4 & IPv7) and we must be assured that IPv4 and IPv7 will be able to run over the same "wire" at the same time and not interfere with each other due to broadcast/multicast co-existance problems or other factors. HIGHER PRIORITY MUSTS (listed in order of decreasing priority): * Media/Link Speed Independence and Data Link Protocol Independence * "Self-Defining Networks" or "Plug & Play functionality". That is, the concept of device portability in which one may readily move devices within one's network and have them autoconfigure, autoregister, autoaddress, etc. without explicit human administrative overhead at the new location - - assuming that the security criteria of the new location have been met. Please note that this represents greater functionality than the existing criteria of "Ease/possibility of configuration/administration/operating/management" which this criteria replaces. It is difficult for us to exaggerate how important this factor is to our ongoing support and maintenance of our own extensive TCP/IP infrastructure. This incredibly important requirement is a primary reason why our corporation has been so active in the IETF's Dynamic Host Configuration Protocol (DHCP) working group. * Globally unique IDs * Topology Flexibility (as least as good as IPv4) [Note: we believe that this criteria also includes Ross Callon's suggested criteria of "no topology constraints (i.e., ugly topology support)".] LOWER PRIORITY MUSTS (not listed in priority order): * Robustness (including surviving hostile attacks) * Unreliable datagram service * Security (as least as good as IPv4) including integrity, authentication (information hiding & firewalls?) * Extensibility. An example of what we mean by this criteria is the existance of the Type of Service (TOS) field in IPv4: Although we don't necessarily know how to implement TOS, we desire to eventually implement TOS and so we have built into the protocol the ability to eventually "extend" it to support this desired functionality once we have figured out how to implement it. Note that we are by no means desire to imply that "extensibility" should be equated with "unused place-holding fields" in the protocol. We are more concerned with building in the ability to extend the protocol rather than how this ability is actually manifested in any given protocol. SHOULDS (not listed in priority order): * Multicast support * Flow Support/Capacity Reservation * Mobile Host support (vs. "Portable") * Architectural Simplicity * Documents online and "owned" by the IETF a la RFCs as per RFC 1310. While this is important, we can not conceive of permitting the Internet to collapse due to not deploying an immediately deployable protocol which meets all MUST components except this one -- which is the SELECT BOF's meaning of a "MUST" identification. Thus, we believe that this criteria must be a "SHOULD" at best. More accurately, we suspect that both this criteria and the "maturity" one were identified for "political reasons" by different "political factions" (thus we moved both from "musts" to "shoulds"). Our own judgement of the relevancy of this ownership criteria to our own network is that we would rate it no higher than a "MAY", but we understand its importance to the IETF community and so we concur with a "SHOULD" recommendation. Note: A related but thus far unaddressed issue is that of "timeline". Our question is whether this requirement is intended to reflect IETF ownership of the documents upon the protocol's initial deployment or some eventual IETF ownership at some time after deployment. We believe that the former is intended and desire that the timeline requirements be explicitly stated. * Conformance Certification (This concept was formerly listed as "Risk/Maturity of field" and originally placed in the MUST category for reasons which we believe were largely political.) We believe that "Maturity" is not quantifiable per se and so we desire to postulate something that is quantifiable. Also, we are troubled by several instances of non-interoperable TCP/IP implementations and our inability to determine who "should change their implementation" due to a lack of adequate detail in the authoritative RFC standards. However, we do not mean to necessarily imply by "certification" the elaborate process used by NVLAP or GOSIP or the various other certification bodies of governments. Rather, the idea is that some mechanism should exist to demonstrate product maturity and interoperability such as is established by the Sun Microsystem's-hosted Connectathon. ELIMINATE FROM THE EXISTING CRITERIA LIST: * Last a long time (20 years). We feel that this item is not subject to quantification. Thus, although it is a very desirable goal, we do not see how one can a priori determine whether a protocol will last 20 years or not. We feel that "selection criteria" must be quantifiable to be useful. I hope that this input will prove to be useful to our Select considerations. Individuals desiring further clarification of our "thought processes" are encouraged to direct Email messages to me at ericf@atc.boeing.com. Sincerely yours, -- Eric Fleischman This note is not to be interpreted to be an official statement of The Boeing Company nor to represent an official Boeing position. Rather, it is solely representative of the personal opinions of five networking professionals. From owner-Big-Internet@munnari.oz.au Sun Dec 13 01:35:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28189; Sun, 13 Dec 1992 01:35:24 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9212121435.28189@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28184; Sun, 13 Dec 1992 01:35:18 +1100 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: Re: need for flow support in internetwork layer To: craig:; Cc: big-internet@munnari.oz.au, huston@ps73.ako.dec.com In-Reply-To: <9212101908.AA21971@aland.bbn.com> Date: Fri, 11 Dec 92 07:55:03 EDT Mail-System-Version: >PS: There's a scheme proposed that has routers read transport headers to >generate unique flow IDs. That might allow us to leave flow IDs out of >the IPv7 header and still have flows. But the IPv7 *SPECIFICATION* will >still have to address queueing issues raised by the existence of flow >ids, however they are created and managed. Craig, Any scheme that has routers looking into transport headers will break when the transport data stream is encrypted as part of an end-to-end security mechanism. (I'm not as concerned about current instances of this, such as for packet filtering, because they have reasonable fallbacks; but if the ability to identify flows depends on being able to read the transport header, we'll give up the ability to have end-to-end encrypted flows). - Lyman From owner-Big-Internet@munnari.oz.au Sun Dec 13 01:39:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28474; Sun, 13 Dec 1992 01:39:56 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28465; Sun, 13 Dec 1992 01:39:50 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27429; Sat, 12 Dec 92 09:39:43 -0500 Date: Sat, 12 Dec 92 09:39:43 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9212121439.AA27429@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: SDRP clarification Cc: jnc@ginger.lcs.mit.edu Also, I guess, this indicates that heavy reliance on conventional source routing (as opposed to path setup), as is described in the current SDRP document (which only contains a packet format for source routing), may not be the way to go for the future, where a lot of the traffic (anyone care to blue sky crystal ball what share of the traffic?) will require resource allocation.. It has been pointed out to me that I should clarify the refernce to SDRP. The overall SDRP scheme is planned to include a path-setup mode, but the details are not yet available. My impression, though, and SDRP'ers correct me, was that SDRP did intend to rely more heavily on source-routed packets (as opposed to being basically a flow setup scheme like IDPR and Nimrod), and it was in that context that I was speculating that perhaps source-routing should not be the basic forwarding mechanism. The generic technical point was really the point of that paragraph, and it applies to Nimrod just as much as it does to SDRP, although I made the observation in the context of SDRP. Noel From owner-Big-Internet@munnari.oz.au Sun Dec 13 01:58:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29147; Sun, 13 Dec 1992 01:58:38 +1100 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29138; Sun, 13 Dec 1992 01:58:24 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27466; Sat, 12 Dec 92 09:58:13 -0500 Date: Sat, 12 Dec 92 09:58:13 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9212121458.AA27466@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ericf@atc.boeing.com, kasten@ftp.com Subject: Re: IPv7 Selection Criteria Cc: jnc@ginger.lcs.mit.edu Eric: An interesting viewpoint! A couple of things I want to ask about: * Scalabilty Why is this so high for you guys? Presumably you mostly just care if the network can be big enough for your company? If you intend to be globally connected, and this is important, shouldn't Robustness/Security be higher? * Ease/possibility of transition Everyone should contemplate the fact that this was one of their 'top 2'. If a scheme doesn't have *real* complete interoperability to unmodifed hosts, my prediction is it'll be much less desireable (i.e. "undesireable"). * Robustness (including surviving hostile attacks) Why was this one a lower priority must? If you are connected to the global Internet, aren't you worried about repeats of the Morris incident, only by more malicious types? Sure, you can fix the Morris holes, but there are probably others.... Unless you have a limited number of application gatways, with *carefully* checked code (in which case you don't care about 'scalabilty'), the possibilty of invasion is there. I would think that an unsecureable network was almost a useless network to a large corporation which was critically dependant on the network for its day-to-day operation... * Last a long time (20 years). I agree that it's hard to quantify the lifetime of an architecture. However, don't you think that this is a critical goal. I.e. wouldn't you agree we've failed if the thing we pick is obsolete in 5 years? Would you like it better if it simply said "Last as long as possible"? Are you simply deleting it *because* it's so hard to measure/predict how long a design will last (although I still maintain a good designer knows a lasting design when they see it :-)? Aren't there other points which are almost as hard to quantify (Topology Flexibilty/Robustness/Architectural Simplicity) which are still in? Noel From owner-Big-Internet@munnari.oz.au Sun Dec 13 05:45:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04903; Sun, 13 Dec 1992 05:46:06 +1100 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04898; Sun, 13 Dec 1992 05:45:56 +1100 (from estrin@caldera.usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.7) id AA05054; Sat, 12 Dec 92 10:45:35 PST Received: by caldera.usc.edu (4.1/SMI-4.1+ucs-3.0) id AA10917; Sat, 12 Dec 92 10:45:33 PST Date: Sat, 12 Dec 92 10:45:33 PST Message-Id: <9212121845.AA10917@caldera.usc.edu> From: estrin@caldera.usc.edu (Deborah Estrin) Sender: estrin@caldera.usc.edu To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Sat, 12 Dec 92 09:39:43 -0500 <9212121439.AA27429@ginger.lcs.mit.edu> Subject: Re: SDRP clarification Reply-To: estrin@caldera.usc.edu Thanks for the clarification NOel. Actually we just planned to start with no-setup and have that mode be a first-class citizen since that is the dominant traffic right now. I fully intend that a setup version of SDRP will be ANOTHER first class citizen and be used for traffic for which it is the more efficient approach. I think it was a good idea to start with the no-setup mode....just as an implementation/deployment/staging strategy... D. From owner-Big-Internet@munnari.oz.au Sun Dec 13 05:53:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05143; Sun, 13 Dec 1992 05:54:08 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05119; Sun, 13 Dec 1992 05:53:36 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11791>; Sat, 12 Dec 1992 10:53:07 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sat, 12 Dec 1992 10:53:02 -0800 To: "Lyman Chapin" Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: need for flow support in internetwork layer In-Reply-To: Your message of "Fri, 11 Dec 92 03:55:03 PST." <9212121435.28189@munnari.oz.au> Date: Sat, 12 Dec 1992 10:52:55 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Dec12.105302pst.10779@skylark.parc.xerox.com> > Any scheme that has routers looking into transport headers will break when > the transport data stream is encrypted as part of an end-to-end security > mechanism. (I'm not as concerned about current instances of this, such as > for packet filtering, because they have reasonable fallbacks; but if the > ability to identify flows depends on being able to read the transport header, > we'll give up the ability to have end-to-end encrypted flows). Lyman, If each flow is separately encrypted (e.g., transport-layer encryption a la SP4, rather than internet-layer a la SP3), there will still be some cleartext information in a header above the internet header that identifies a particular flow, whether it be port numbers, a key ID, or something else. For example, I could well imagine a secure version of TCP that encrypted everything except the port numbers; the port numbers would be used to demultiplex to the right connection state, where the decryption key would be found. So I don't think the desire to do end-to-end encryption necessarily implies that routers will not be able to look beyond the internet header to identify flows, if that is what you were suggesting. (That is not to say there aren't other, more compelling resons for putting a flow ID in the internet header.) Steve From owner-Big-Internet@munnari.oz.au Sun Dec 13 08:38:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09183; Sun, 13 Dec 1992 08:39:07 +1100 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09175; Sun, 13 Dec 1992 08:38:54 +1100 (from rlglende@netcom.com) Received: from netcom.netcom.com by ux1.cso.uiuc.edu with SMTP id AA07793 (5.67a8/IDA-1.5 for ); Sat, 12 Dec 1992 15:36:58 -0600 Received: by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA20713; Sat, 12 Dec 92 13:38:11 -0800 Newsgroups: info.big-internet Path: rlglende From: rlglende@netcom.com (Robert Lewis Glendenning) Subject: Re: need for flow support in internetwork layer Message-Id: <1992Dec12.213805.20655@netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) References: <9212111728.AA00336@saffron.acc.com> <9212111907.AA27668@sparta.com> Date: Sat, 12 Dec 1992 21:38:05 GMT Apparently-To: info-big-internet@ux1.cso.uiuc.edu IP now works on a "first-come, first-served" basis. Flow control in IP is intended to prevent swamping the intervening pipes and relays. Flow control as it has been discussed in this thread seems to involve "guarantees", an entirely different color of horse. Flow control with guarantees involves contention for scarce resources. Pre-negotiated routes presume one system or application has priority over others. How are these to be assigned? Lew -- Lew Glendenning rlglende@netcom.com "Perspective is worth 80 IQ points." Nils Bohr (or somebody like that). From owner-big-internet@munnari.oz.au Mon Dec 14 19:39:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17491; Mon, 14 Dec 1992 19:39:47 +1100 (from owner-big-internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17169; Mon, 14 Dec 1992 19:27:56 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA04998; Mon, 14 Dec 1992 09:27:04 +0100 Message-Id: <199212140827.AA04998@mitsou.inria.fr> To: woody@sparta.com (Robert "Woody" Woodburn) Cc: fbaker@acc.com, craig@aland.bbn.com, big-internet@munnari.oz.au, huston@ps73.ako.dec.com Subject: Re: need for flow support in internetwork layer In-Reply-To: Your message of "Fri, 11 Dec 92 09:27:30 EST." <9212111427.AA25583@sparta.com> Date: Mon, 14 Dec 92 09:26:59 -0500 From: Christian Huitema > .............Fragmentation makes it impossible to > identify a particular session (which seems to be a reasonable granularity for > a flow) This is a fairly common assumption, and it is also a very false assumption. For one thing, it supposes that you can identify a "session". What if you session is actually implemented as a set of uncorrelated RPC queries, e.g. a station on a leaf local net querying one NFS server through an Internet? It is quite reasonable that the manager of such stations would be quite happy to "reserve some bandwidth" in order to maintain an average quality of service. Then, even if such a thing as a session can be identified, e.g. in the case of a video conference, it is dangerous to assume an equivalence between "transport sessions", identified by port numbers, and resource reservation. A video conference uses several flows, not just one. The users will switch on an off various devices during the conference. They may decide to use one particular reservation for each device, or each flow. They may also decide to use one single resource reservation -- so they can master the global cost -- and then use end to end mechanisms to share this reservation. One last point. Having a model of resource reservations performed on a "session" basis carries the risk of slipping into resource reservation at sessions set up time. As Lixia mentioned in a later message, this may be much to late in the "non trivial" cases. If we have to reserve 1/4 of the bandwidth on an heavily loaded transtlantic link to broadcast the next IETF, I would feel much more confortable if we could stage the reservation some time in advance. Like, three months... Christian Huitema From owner-Big-Internet@munnari.oz.au Tue Dec 15 00:30:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26764; Tue, 15 Dec 1992 00:30:23 +1100 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26761; Tue, 15 Dec 1992 00:30:17 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA13454; Mon, 14 Dec 92 05:30:11 -0800 Message-Id: <9212141330.AA13454@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, ericf@atc.boeing.com, kasten@ftp.com Subject: Re: IPv7 Selection Criteria Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sat, 12 Dec 92 09:58:13 -0500. <9212121458.AA27466@ginger.lcs.mit.edu> Date: Mon, 14 Dec 92 05:30:11 -0800 From: Dave Crocker X-Mts: smtp Noel, * Last a long time (20 years). I agree that it's hard to quantify the lifetime of an architecture. However, don't you think that this is a critical goal. I.e. wouldn't you ag Would you care to offer some examples of concrete tests that can be used to determine whether a spec satisfies this requirement? Dave From owner-Big-Internet@munnari.oz.au Tue Dec 15 04:15:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04011; Tue, 15 Dec 1992 04:16:15 +1100 (from owner-Big-Internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03984; Tue, 15 Dec 1992 04:15:35 +1100 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA09109; Mon, 14 Dec 92 09:12:50 -0800 Date: Mon, 14 Dec 92 09:12:50 -0800 From: Eric Fleischman Message-Id: <9212141712.AA09109@atc.boeing.com> To: big-internet@munnari.oz.au, ericf@atc.boeing.com, jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: Re: IPv7 Selection Criteria Cc: ericf@munnari.oz.au The purpose of this note is to respond to Noel Chiappa" questions concerning our recntly posted potential ranking for IPv7 selection criteria: >> Eric: >> An interesting viewpoint! A couple of things I want to ask about: >> * Scalabilty >>Why is this so high for you guys? Presumably you mostly just care if the >>network can be big enough for your company? If you intend to be globally >>connected, and this is important, shouldn't Robustness/Security be higher? Scalability and router aggregation is at the top of our criteria list because these are the primary problems IPv7 are trying to resolve. Other problem resolutions, we feel, are secondary to this (we concur with Ullmann's Email messages in this regards). We care about this matter because the world is "getting smaller" and every Internet user must be concerned with the continued viability of the Internet community as a whole if the Internet is to continue to meet our various parochial needs. >> * Ease/possibility of transition >>Everyone should contemplate the fact that this was one of their 'top 2'. If a >>scheme doesn't have *real* complete interoperability to unmodifed hosts, my >>prediction is it'll be much less desireable (i.e. "undesireable"). We concur. An ultimate solution from our point of view will not ask currently deployed hosts to be touched in order to function in the "new world". Since router deployments tend to be two order of magnitudes smaller in size (at least they are in our network) we vastly prefer the solution to primarily impact routers, as opposed to both hosts and routers. We have previously posted a corporate position dealing with our preferences if there is no alternative to modifying hosts. However, the key message we wish to send is that migrational issues are "key" from our viewpoint. From our knothole, "ease of migration/transition" is among the top two requirements in importance. >> * Robustness (including surviving hostile attacks) >> Why was this one a lower priority must? If you are connected to the >>global Internet, aren't you worried about repeats of the Morris incident, only >>by more malicious types? Sure, you can fix the Morris holes, but there are >>probably others.... Unless you have a limited number of application gatways, >>with *carefully* checked code (in which case you don't care about >>'scalabilty'), the possibilty of invasion is there. Robustness is an extremely critical factor. We tremendously value robustness, hence its continued inclusion in the "MUST HAVE" list. It's just that we value other factors more. Now mind you, what we sent was just OUR opinion. Other viewpoints are of tremendous value and those viewpoints may well put robustness significantly higher in the list than we did. >> I would think that an unsecureable network was almost a useless >>network to a large corporation which was critically dependant on the network >>for its day-to-day operation... We concur. An unsecurable network could be used for personal uses but is not fit for business uses. >> * Last a long time (20 years). >> I agree that it's hard to quantify the lifetime of an architecture. >>However, don't you think that this is a critical goal. I.e. wouldn't you agree >>we've failed if the thing we pick is obsolete in 5 years? >> Would you like it better if it simply said "Last as long as possible"? >>Are you simply deleting it *because* it's so hard to measure/predict how long >>a design will last (although I still maintain a good designer knows a lasting >>design when they see it :-)? Aren't there other points which are almost as >>hard to quantify (Topology Flexibilty/Robustness/Architectural Simplicity) >>which are still in? >> Noel Lasting 20 years is an extremely important goal for IPv7. However, it seems to us that it is a "warm and fuzzy". Many of its hard criteria are embodied by the other metrics we have included. Thus, we ask, why include something which we can't quantify? While "flexibility" and other aspects are also not "hard", we nevertheless feel that we can identify a non-flexible approach from a flexible one. Similarly we think we can roughly judge a short term kludge from a really well engineered long-term solution. But to say that a protocol will last 20 years in this changing world? We don't think that WE (the writers of the original opinion) can judge that. Perhaps you or others can, but we can't. In any case, if the committee can think of ways in which this criteria could be measured (aside from waiting 20 years) we would be happy to re-include it among the MUSTS in our recommendation. --Eric From owner-Big-Internet@munnari.oz.au Tue Dec 15 08:52:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11264; Tue, 15 Dec 1992 08:53:06 +1100 (from owner-Big-Internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11252; Tue, 15 Dec 1992 08:52:23 +1100 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA27728; Mon, 14 Dec 92 16:14:14 -0500 Date: Mon, 14 Dec 92 16:14:14 -0500 Message-Id: <9212142114.AA27728@worldlink.worldlink.com> From: David M. Piscitello To: big-internet@munnari.oz.au Subject: is the sub-network or internetwork responsible for flows? Let's assume for a moment that *ALL* subnets support this new type of service. Let's not. Primarily because all this will do is create yet another "subnet is umvelt" vs. "Internet is umvelt" discussion. This is yet a different twist on "connections vs. datagrams". I for one am tired to death of this. One last thing -- there's another point of view. Some people have argued that we should get rid of the internetwork layer, and use a single protocol (usually ATM) as our universal protocol. This is really an argument that internetworking isn't necessary because we're all going to buy the same type of network. actually, they are probably arguing that ATM is the internetworking fabric. all well and good for those who believe that ATM is the only solution. ATM may be a wonderful solution, but it probably won't be the only solution. Nothing has ever proven to meet the criteria for "glorious ultimate solution". you probably shouldn't be worried about IPv7 anyway. forgive me, but I'm still worried:-) From owner-big-internet@munnari.oz.au Tue Dec 15 08:35:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10690; Tue, 15 Dec 1992 08:35:59 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10145; Tue, 15 Dec 1992 08:14:27 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Mon, 14 Dec 92 16:14:07 EST Received: by chiya.bellcore.com (4.1/4.7) id for kasten@ftp.com; Mon, 14 Dec 92 16:14:05 EST Date: Mon, 14 Dec 92 16:14:05 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9212142114.AA04151@chiya.bellcore.com> To: big-internet@munnari.oz.au, ericf@atc.boeing.com, jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: Re: IPv7 Selection Criteria Cc: ericf@munnari.oz.au > > We concur. An ultimate solution from our point of view will not ask > currently deployed hosts to be touched in order to function in the > "new world". Since router deployments tend to be two order > of magnitudes smaller in size (at least they are in our network) > we vastly prefer the solution to primarily impact routers, > as opposed to both hosts and routers. We have previously posted a > corporate position dealing with our preferences if there is no alternative > to modifying hosts. However, the key message we wish to send is that > migrational issues are "key" from our viewpoint. From our knothole, > "ease of migration/transition" is among the top two requirements in > importance. It seems to me that all of the proposals have in common that, in order for a host to be able to communicate globally, it must be modified. This is because *all* proposals involve bigger addresses, and therefore at that point in time when 32 bits no longer constitutes a unique identifier, the host *must* understand the larger address and therefore must be modified. The only alternative is to do a NAT type scheme where the 32 bit address is used locally to index a cache that dynamically maps 32 bit numbers into larger addresses......But, my impression is that this sort of scheme has been broadly denounced as ugly.... (Of course, the other alternative is to simply not have many machines that speak globally........) PX From owner-big-internet@munnari.oz.au Tue Dec 15 13:22:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20611; Tue, 15 Dec 1992 13:24:52 +1100 (from owner-big-internet) Return-Path: Message-Id: <9212150224.20611@munnari.oz.au> Received: from HYPATIA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17197; Tue, 15 Dec 1992 11:43:31 +1100 (from msteenst@BBN.COM) To: big-internet@munnari.oz.au Subject: IDPR and resource reservation Date: Mon, 14 Dec 92 19:42:29 -0500 From: Martha Steenstrup Hi, Woody recently mentioned that we were planning on adding a facility to IDPR that permits resource reservation for flows. In order not to interrupt the flow of the current big-internet discussion, I have placed some information about how this will work with IDPR in a little file available via anonymous ftp from nic.near.net. The file is in the "incoming" directory and it's called "resres". m From owner-Big-Internet@munnari.oz.au Wed Dec 16 01:42:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15807; Wed, 16 Dec 1992 01:42:43 +1100 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15791; Wed, 16 Dec 1992 01:42:17 +1100 (from huston@ps73.ako.dec.com) Received: by inet-gw-1.pa.dec.com; id AA14517; Tue, 15 Dec 92 06:40:53 -0800 Received: by ps73.ako.dec.com (5.57/Ultrix V4.2-sdh-921109); id AA10572; Tue, 15 Dec 92 09:40:45 -0500 Message-Id: <9212151440.AA10572@ps73.ako.dec.com> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au, ericf@atc.boeing.com Subject: Re: IPv7 Selection Criteria In-Reply-To: Your message of "Mon, 14 Dec 92 16:14:05 EST." <9212142114.AA04151@chiya.bellcore.com> Date: Tue, 15 Dec 92 09:40:44 -0500 From: huston@ps73.ako.dec.com X-Mts: smtp >It seems to me that all of the proposals have in common that, >in order for a host to be able to communicate globally, it must >be modified. Robert Ulllmann's proposal (draft-ullmann-ipv7-01.txt in the internet-drafts repositories) requires IPv4 and IPv7 hosts to interoperate. Hosts can be changed at IPv7 as desired. Until such point as the v4 address space overflows, then universal interoperability starts to be a problem. Steve Huston on contract to, but not speaking for, Digital Equipment Corporation huston@ps73.ako.dec.com +1 508 264 7117 From owner-Big-Internet@munnari.oz.au Wed Dec 16 02:40:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17728; Wed, 16 Dec 1992 02:42:21 +1100 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17668; Wed, 16 Dec 1992 02:40:53 +1100 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA07847; Tue, 15 Dec 92 07:40:41 -0800 Received: by us1rmc.bb.dec.com; id AA06467; Tue, 15 Dec 92 10:38:13 -0500 Message-Id: <9212151538.AA06467@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 15 Dec 92 10:38:15 EST Date: Tue, 15 Dec 92 10:38:15 EST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 15-Dec-1992 1040" To: deering@parc.xerox.com Cc: dee@ranger.enet.dec.com, big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: RE: Re: need for flow support in internetwork layer Steve, It's not necessary to go to transport level encryption to have flows determined by transport headers. You could have network level encryption with an "encryption start offset" field allowing a variable length prefix of the message to be in the clear so that TCP port numbers, etc., could be revealed; however, there will be people who will reasonably want both guaranteed flows and secrecy for just what protocol/ports, etc., they are using. It might be possible to get this effect occasionally if there is some encapsulation you could do so the outer layer implied the right flow and the real stuff was in an encrypted encapsulated message but if you are going to all this trouble, why not just have a flow/QoS/whatever there at the top level?? In any case, TCP/UDP port numbers and the like are just plain wrong for determing flows or class of service. If my mail system is doing a DNS lookup in the background for some queued mail, it should probably ask for reliability. If I'm trying to diagnose a network problem and doing name service lookups interactively, I want low response times. A server-server NNTP conversation wants low cost and high bandwidth. A user-server NNTP conversation is probably not as worried about cost and may want the best response time it can get. How can you tell if a file transfer is of a small amount of data for a time critical process or part of some sort of background transfer of lots of files by a site which is trying to mirror another? How can you tell what is desried for a remote procedure call? As far as I can tell, in the vast majority of cases trying to user existing header fields like protocol and port number to determine class of service when they were never designed for this is fundamentally brain damaged. Donald -------------- From: US1RMC::"deering@parc.xerox.com" "Steve Deering" 14-DEC-1992 17:44 To: "Lyman Chapin" CC: big-internet@munnari.oz.au, deering@parc.xerox.com Subj: Re: need for flow support in internetwork layer > Any scheme that has routers looking into transport headers will break when > the transport data stream is encrypted as part of an end-to-end security > mechanism. (I'm not as concerned about current instances of this, such as > for packet filtering, because they have reasonable fallbacks; but if the > ability to identify flows depends on being able to read the transport header, > we'll give up the ability to have end-to-end encrypted flows). Lyman, If each flow is separately encrypted (e.g., transport-layer encryption a la SP4, rather than internet-layer a la SP3), there will still be some cleartext information in a header above the internet header that identifies a particular flow, whether it be port numbers, a key ID, or something else. For example, I could well imagine a secure version of TCP that encrypted everything except the port numbers; the port numbers would be used to demultiplex to the right connection state, where the decryption key would be found. So I don't think the desire to do end-to-end encryption necessarily implies that routers will not be able to look beyond the internet header to identify flows, if that is what you were suggesting. (That is not to say there aren't other, more compelling resons for putting a flow ID in the internet header.) Steve From owner-Big-Internet@munnari.oz.au Thu Dec 17 04:10:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01625; Thu, 17 Dec 1992 04:11:12 +1100 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01620; Thu, 17 Dec 1992 04:10:30 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA12891; Wed, 16 Dec 92 12:07:37 -0500 Date: Wed, 16 Dec 92 12:07:37 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9212161707.AA12891@er.doe.gov> To: big-internet@munnari.oz.au Proposal for Implementing DNS as EID architecture in IPv4 One of the major problems confronting the internet is the impending exhaustion of the IPv4 address space and the accompanying explosion of the routing tables. There are numerous proposals to help this problem in both the short and long terms. Most of these rely on some renumbering to be effective. In addition, deployment of any of these schemes needs to proceed incrementally. The administrative difficulty with renumbering IPv4 hosts could be a major barrier to any of these schemes as well as to introducing future protocols. One of the few points of "consensus" on the big-internet list seems to have been the desireability of separating end system ID's from routing direction. This note is an attempt to stimultate discussion on whether some of the advantages of EID's could be gained through modifications to the DNS and some of the major applications in use on the internet. If this were possible, it might be possible to develop tools which would facilitate and make more acceptable to users the renumbering which may need to be done to help the internet survive the next 36 months. In addition, this structure could perhaps facilitate the transition to a new protocol... or the coexistence of multiple protocols. Of course the DNS name is not an ideal choice for an EID, especially if you need to include it in every packet. So one of the constraints is that this DNS based EID cannot go into packets. There are several sets of issues to be discussed: How does a host find its own routing information if it only knows its EID. How does a host find routing information to reach DNS servers if it only knows names. How does a host find other hosts if it only knows names and what applications have addresses and names stored independantly. The first two issues are coupled. One strategy would be to have each host have a cache of DNS names and addresses which is updated and an entry for the EID and routing info for "the mother of all name servers" which is hard coded into the config file. This would give several entries into the DNS structure so that if current cache routing info doesn't work the mother server is queried... and its routing info or address is always fixed. Of course, when a machine is booted it knows its name, the name and address of the mother server, and the name of its local server. So it would have to query the server tree to find its address. Perhaps it could build the inverse source route as it went to its server so that the reply could get back to it. Also, the local DNS server needs to have a way of updating addresses of machines in its immediate name space. Once all this works, there are major applications like mail, telnet,...NFS,... which need to be checked so that they always get addresses from the DNS rather than hard coded config files and the like. And net-name to net address resolver demons need to be written so that users who have addresses hard coded in their software can conveniently move to DNS references. Perhaps, we also need to consider securing the DNS references so that you know that a real DNS is giving you the data rather than an imposter. Why would this help. First, local net managers could renumber nets without touching all the machines. Second, it would hide the routing address from the user so he/she wouldn't resist renumbering so strongly. Third, one could consider adding multiple protocol addresses to the DNS and letting the software do protocol negotiation between hosts to facilitate transition. One could even bind DNS names to "real EID's" this way. Dan Hitchcock From owner-big-internet@munnari.oz.au Fri Dec 18 09:19:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26040; Fri, 18 Dec 1992 09:19:52 +1100 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14611; Fri, 18 Dec 1992 03:51:02 +1100 (from ljm@ftp.com) Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP id AA02993; Thu, 17 Dec 92 11:50:26 -0500 Date: Thu, 17 Dec 92 11:50:26 -0500 Message-Id: <9212171650.AA02993@ftp.com> To: craig@aland.bbn.com Subject: Re: having the market decide From: ljm@ftp.com (leo j mclaughlin iii) Reply-To: ljm@ftp.com Cc: big-internet@munnari.oz.au, ljm-status@ftp.com Sender: ljm@ftp.com Repository: babyoil.ftp.com Originating-Client: leather-lace.ftp.com > We didn't handle this process as cleanly as we might have for SNMP/CMOT. > Having had the experience, I'd like to see us do it better this time around. Having witnessed a good bit of this, I'm not sure if we could do much better than we did with SNMP/CMOT. As I look at the work of the IETF over the past four years, the omnipresence of SNMP in everything from ethernet cards to UPSs over all sorts of different media and transports stands out as a singular success. And as I remember the attitudes of the designers and early implementors of SNMP, I am quite confident that were it not for the existance of CMOT as a proposed alternative SNMP would never have been developed nor deployed as quickly as it has been. I hope we 'fail' as miserably with IPv7 as we have with network management. enjoy, leo j mclaughlin iii ljm@ftp.com From owner-Big-Internet@munnari.oz.au Sat Dec 19 03:17:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05531; Sat, 19 Dec 1992 03:17:21 +1100 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05524; Sat, 19 Dec 1992 03:17:05 +1100 (from dee@skidrow.pa.dec.com) Received: by inet-gw-1.pa.dec.com; id AA07981; Fri, 18 Dec 92 08:16:44 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA08670; Fri, 18 Dec 92 11:17:47 -0500 Message-Id: <9212181617.AA08670@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: sip@caldera.usc.edu Cc: big-internet@munnari.oz.au Subject: ES-IS/autoconfiguration Date: Fri, 18 Dec 92 11:17:46 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp People interested in ES-IS and autoconfiguration may find it interesting and informative to read the related section's of Radia Perlman's excellent and very readable book: Interconnections. Chapter 8, Network Layer Neighbor Greeting, is the most relevnat section (and it's only 11 pages long). Many other parts, 6.3.2 (Autoconfiguration) 5.1.1 (Network Service Types) etc., may be of interest. Donald *+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+- Donald E. Eastlake, III 1-508-486-2358(w) dee@skidrow.ljo.dec.com PO Box N, MIT Branch PO dee@ranger.enet.dec.com Cambridge, MA 02139 USA 1-617-244-2679(h)