From scoya@CNRI.Reston.VA.US Mon Mar 21 14:05:53 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id SAA12015 for ; Mon, 21 Mar 1994 18:32:12 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09014; 21 Mar 94 14:05 EST To: ipng@cmf.nrl.navy.mil Subject: List of documents Date: Mon, 21 Mar 94 14:05:53 -0500 From: Steve Coya Message-ID: <9403211405.aa09014@IETF.CNRI.Reston.VA.US> Status: O As requested during today's IPNG telechat, I am hereby requesting the complete set of documents. DO NOT send the actual documents, just the list of documents! :-) for each of the IPNG proposals. I will consolidate into a single list. Please send me the document title and filename (if it's not an I-D, send me location information). Thanks. Steve From deering@parc.xerox.com Mon Mar 21 16:08:45 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id TAA12231 for ; Mon, 21 Mar 1994 19:09:32 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14450(2)>; Mon, 21 Mar 1994 16:08:39 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 21 Mar 1994 16:08:46 -0800 To: ipng@cmf.nrl.navy.mil Cc: hinden@eng.sun.com, francis@cactus.ntt.jp, deering@parc.xerox.com Subject: SIPP documents ready for clarity review Date: Mon, 21 Mar 1994 16:08:45 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Mar21.160846pst.12171@skylark.parc.xerox.com> Status: O Dear IPng Directorate, The SIPP WG would like to submit the following documents for clarity review by the Directorate: S. Deering, "Simple Internet Protocol Plus (SIPP) Specification", Internet Draft, draft-ietf-sipp-spec-00.txt, February, 1994. S. Deering, et al, "Simple Internet Protocol Plus (SIPP): Routing and Addressing", Internet Draft, draft-ietf-sip- routing-addr-01.txt, February, 1994. P. Francis, "Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment", Internet Draft, , January 1994. R. Gilligan, et al, "IPAE: The SIPP Interoperability and Transition Mechanism", Internet Draft, draft-ietf-sipp-ipae-transition-01.txt, March 1994. These are the "base" SIPP documents. There are a bunch of auxilliary documents, covering DNS changes, ICMP changes, autoconfiguration, and routing protocol changes, most of which are also ready for review, and some of which we expect to have ready by the end of the Seattle IETF week. If the base set isn't enough to keep the reviewers busy for the next couple weeks, let me know, and I will forward the titles of all of the auxilliary docs that are ready now. Steve From sob@hsdndev.harvard.edu Mon Mar 21 20:51:41 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id UAA12729 for ; Mon, 21 Mar 1994 20:52:04 -0500 Date: Mon, 21 Mar 94 20:51:41 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403220151.AA22034@hsdndev.harvard.edu> To: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: SIPP documents ready for clarity review Cc: francis@cactus.ntt.jp, hinden@eng.sun.com Status: O Steve, thanks (I guess) :-) Scott From brian@dxcoms.cern.ch Tue Mar 22 17:07:42 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id LAA16621 for ; Tue, 22 Mar 1994 11:08:17 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11037; Tue, 22 Mar 1994 17:07:43 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11780; Tue, 22 Mar 1994 17:07:42 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403221607.AA11780@dxcoms.cern.ch> Subject: Where, when To: ipng@cmf.nrl.navy.mil Date: Tue, 22 Mar 1994 17:07:42 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 244 Status: O Could somebody post an answer today to 2 questions, for those of us who missed the IPng conf call? 1. Where, when is the first Directorate meeting/meal in Seattle? 2. Where, when is the final draft of the requirements text? Thanx Brian From mankin@cmf.nrl.navy.mil Tue Mar 22 15:09:44 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with ESMTP id PAA18840 for ; Tue, 22 Mar 1994 15:09:46 -0500 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.7/8.6.6) id PAA03999 for ipng; Tue, 22 Mar 1994 15:09:44 -0500 Date: Tue, 22 Mar 1994 15:09:44 -0500 From: Allison J Mankin Message-Id: <199403222009.PAA03999@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: re: Where, when Status: O > 1. Where, when is the first Directorate meeting/meal in Seattle? Thursday night, following the IESG Open Plenary, we have dinner and then meeting. Let's just gather together in the Plenary room at the end of the IESG meeting. > 2. Where, when is the final draft of the requirements text? All comments must be to Frank, Jon and Craig for the final pre-IETF by the end of today (Tuesday) and Frank will undertake to make all the changes by the end of Wednesday so that the I-D can be published. From scoya@CNRI.Reston.VA.US Wed Mar 23 09:50:59 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA25208 for ; Wed, 23 Mar 1994 12:59:21 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07792; 23 Mar 94 9:51 EST To: ipng@cmf.nrl.navy.mil Subject: Draft minutes from March 21 IPNG Telechat Date: Wed, 23 Mar 94 09:50:59 -0500 From: Steve Coya Message-ID: <9403230951.aa07792@IETF.CNRI.Reston.VA.US> Status: O DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference March 21, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Jim Bound / DEC Dave Clark / MIT Eric Fleischman / Boeing Frank Kastenholz / FTP Greg Minshall / Novell Paul Mockapetris / ISI Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- Steve Bellovin / AT&T Ross Callon / Wellfleet Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Paul Francis / NTT Daniel Karrenberg / RIPE Mark Knopper / Ameritech Craig Partridge / BBN 1. Scott and Allison will attempt to organize a dinner for the IPNG Directorate members on Thursday, following the IESG Plenary, during the Seattle IETF meeting. 2. The list of IPNG presentations that are to take place Monday morning in Seattle were reviewed. The breakdown is as follows: a. Allison and Scott - IPNG status b. Dave Clark - status of the External Review Panel c. Frank Solensky - Report from the ALE WG d. Jon Crowcroft and/or Frank Kastenholz - Report on the IPNG Requirements document 3. Coya to prepare an IPNG track for Seattle and send to Scott and Allison. Coya to send message to the IPNG list soliciting the formal set of documents from each of the groups. 4. The text of the disclaimer written by Allison and Scott, which is to be included in IPNG documents, was read to the directorate. No requests for changes were made. 5. Allison conducted a full review of the Criteria section of the requirements document. Request changes include: a. In the section on scale, the phrase "up to" should be replaced with "at least" A notation that "another 3 orders of magnitude might be needed" will be added. b. All references to the big-internet list should include the list address. c. In the discussion on scale, change "whole purpose" to "initial motivating purpose" d. Replace "very very very" with "extremely extremely extremely" :-) Ok, maybe only need one extremely... just wanted to see who's reading these minutes. e. The character string to use is IPng, not IP:NG (5 points to those who recall why the colon was there in the first place, 5 bonus points to whomever knows the entire history (with dates)! f. The requirement that multiple IPNG protocols co-exist needs to be reworded as there will only be one (1) IPNG protocol. Will be reworded to require that multiple versions of IPNG need to co-exist on the network. g. On the section on Media, expand "VJ-like" to "Van Jacobson-like" h. It was requested that the requirements include "the ability to send an IP datagram as large as allowed by the inter-network layer (assuming, of course, that the recipient is able to accept a datagram that large). The topic of fragmentation was raised, but discussion was deferred. i. In the section on Configuration, Admin, and OPS, it should be added that "nothing in the proposal should inhibit a future requirement for auto registration." j. It was suggested that the IAB report from the Security W/S might provide text for the security section of the requirements document. Coya to send to the IPNG list, Kastenholz to review. k. In the section on unique naming, use the phrase "multicast addresses" l. In the section on extensibility, reiterate the need to run multiple versions on IPNG over the same wire. m. In the section on non-goals, it was suggested that the section on IPv4 and IPng Communication be removed as it was not needed in the requirements document. n. Might be able to incorporate some ideas, concepts and text from the IAB report or the recently published RFC on Firewall in the section on Firewalls in the requirements document. o. There is a need to clarify what is meant by "accounting" in the section on non-goals. Kastenholz will reword. p. In the section on robust service, it was stated that host performance should not decrease (below the level of IPv4), and that the protocol should not, due to its complexity or other features, increase the liklihood of poor implementation on host platforms, especially with respect to performance. From kasten@Research.Ftp.Com Wed Mar 23 10:19:58 1994 Return-Path: kasten@Research.Ftp.Com Received: from Research.Ftp.Com (research.ftp.com [128.127.145.125]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id KAA24048 for ; Wed, 23 Mar 1994 10:24:02 -0500 Received: by Research.Ftp.Com (920330.SGI/) for ipng@cmf.nrl.navy.mil id AA24091; Wed, 23 Mar 94 10:19:59 -0500 Received: by Research.Ftp.Com id AA24091; Wed, 23 Mar 94 10:19:59 -0500 Date: Wed, 23 Mar 1994 10:19:58 -0500 (EST) From: Frank Kastenholz Subject: To Autoregister or not to Autoregister... To: ipng mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O The more I've thought about the autoregistration issue, the more I've come to the conclusion that it does not belong in the technical criteria for IPng. Calm down Brian and Eric -- let me explain! 0. I consider Autoregistration to be how a node is made known to any other systems on the network -- for example, (using IPv4 terms and technology) when BOOTP gives a node its IP address it might also tell DNS, getting yourself registered with Kerberos (if you've got the dubious pleasure of running Kerberos), telling NFS servers that there is a new node and who it is and giving the node the needed NFS privilges, getting email servers/relays set up to forward email properly, and so on. 1. Autoregistration IS critically important to a plug-and-play network. There is no doubt about that. 2. As I indicate in point 0, it seems that autoregistration covers a lot more than just IP level things. Setting up email relays (e.g.) has absolutely nothing to do with IP. In other words, this is a very very broad problem. 3. Most of the autoregistration protocol work would be done at higher layers than IP. For example, when registering a node with DNS, there would presumably be some DNS-level protocol operation which basically says Register Node and gives all the RR information needed (e.g. name, ip address, etc) AND includes the authentication information. This would be a dns-level protocol operation, running over tcp or udp.... 4. To me, it seems that the autoregistration technologies are orthogonal to the IP layer. For instance, the SIPPers could develop autoregistration scheme "X" and the TUBAteers scheme "Y". I would have to imagine that, modulo the formats of addresses and the like, each could use the other's scheme. 5. I am not comfortable with IPng specifying changes to other, non-IP- level protocols. Adding new RRs to DNS is one thing -- it was designed to handle this and was expected by the original architects. (In fact, from what I've been told by BIND experts, the changes to the BIND code to add a new RR are close to, if not exactly, 0). However, requiring new protocol operations as a result of this IP work, is really beyond my comfort level. So, my conclusion is that we should not specifically require autoregistration as a techncial feature of IPng. The document will contain text that says that autoregistration is a critical part of a plug-and-play internet and that we encourage IPng teams to consider this area, in conjunction with other protocol working groups (e.g. DNS autoregistration really ought to be a part of the DNS working group's efforts). Finally, I've strengthened the requirement for auto configuration: The paragraph in the config section that used to say: It should be possible for a node to dynamically obtain all of its operational, IP-level parameters... Now says We require that a node be able to dynamically obtain all of its operational, IP-level parameters at boot time via a dynamic configuration mechanism. In other words, instead of a "you might want to do this" it is a "you must do this". The list of "things to consider" with respect to auto-config has not changed. I have added the following paragraphs after the list: The requirements of this section apply only to IPng and its supporting protocols (such as for routing, address resolution, and network-layer control). Specifically, as far as IPng is concerned, we are concerned only with how routers and hosts get their configuration information. We note that in general, automatic configuration of hosts is a large and complex problem and getting the configuration information into hosts and routers is only one, small, piece of the problem. A large amount of additional, non-Internet-layer work is needed in order to be able to do "plug-and-play" networking. Other aspects of "plug-and-play" networking include things like: Autoregistration of new nodes with DNS, configuring security service systems (e.g. Kerberos), setting up email relays and mail servers, locating network resources, adding entries to NFS export files, and so on. To a large degree, these capabilities do not have any dependence on the IPng protocol (other than, perhaps, the format of addresses). We require that any IPng proposal not impede or prevent, in any way, the development of "plug-and-play" network configuration technologies. I'll be finishing the document within the hour and will put it up for anonymous FTP in research.ftp.com in pub/ip7ng/criteria.txt Frank From kasten@Research.Ftp.Com Wed Mar 23 11:29:53 1994 Return-Path: kasten@Research.Ftp.Com Received: from Research.Ftp.Com (research.ftp.com [128.127.145.125]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id LAA24555 for ; Wed, 23 Mar 1994 11:33:52 -0500 Received: by Research.Ftp.Com (920330.SGI/) for ipng@cmf.nrl.navy.mil id AA24482; Wed, 23 Mar 94 11:29:54 -0500 Received: by Research.Ftp.Com id AA24482; Wed, 23 Mar 94 11:29:54 -0500 Date: Wed, 23 Mar 1994 11:29:53 -0500 (EST) From: Frank Kastenholz Subject: final version of the document To: ipng mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O the lastest and last pre-seattle version of the document is available at research.ftp.com in pub/ip7reqs/criteria.txt i am sending it to the internet-draft people next.... ---- Frank Kastenholz FTP Software 2 High Street North Andover Mass USA 01845 508-685-4000 From ericf@atc.boeing.com Wed Mar 23 09:29:45 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA25029 for ; Wed, 23 Mar 1994 12:28:29 -0500 Received: by atc.boeing.com (5.57) id AA10479; Wed, 23 Mar 94 09:29:45 -0800 Date: Wed, 23 Mar 94 09:29:45 -0800 From: Eric Fleischman Message-Id: <9403231729.AA10479@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, kasten@Research.Ftp.Com Subject: Re: To Autoregister or not to Autoregister... Cc: ericf Status: O Dear Frank, Be calm? What's that? Having said that, I find your logic concerning why autoregistration should not be a part of our technical requirements to be commendable. My thoughts have also gone on similar routes. However, as one who has been repeatedly frustrated by "pidgeon-holers" (i.e., the beaurocrats (spelling?) who say "since this isn't totally in my department, we can't do anything -- we get a lot of that around here), I thought that it must be at least mentioned as something to consider and to not preclude so that it wouldn't become lost and swept under the carpet yet again. Thus, I concur with the wording and sentiment of Brian's response to you -- and of your original message. However, to be contentious, I could also say that IPng affects many layers in addition to the network layer. Need I mention DNS? How about FTP, etc.? Thus, one may counter your arguments (though I personally wouldn't dare do so) by saying that since you must add in DNS hooks for IPng, why not go the whole 9 yards. But without a DNS WG existing... Thus, let's compromise with Brian's words. However, about the "calmness" part -- you are asking too much! Sincerely yours, --Eric Fleischman From smb@research.att.com Wed Mar 23 15:06:29 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA26259 for ; Wed, 23 Mar 1994 15:23:58 -0500 From: smb@research.att.com Message-Id: <199403232023.PAA26259@picard.cmf.nrl.navy.mil> Received: by bigbird.zoo.att.com; Wed Mar 23 15:06:30 EST 1994 To: ipng@cmf.nrl.navy.mil Subject: requirements document Date: Wed, 23 Mar 94 15:06:29 EST Status: O I just finished reading through the document. I'm not happy with this passage, as some of you could probably guess: Firewalls Some have requested that IPng include support for firewalls. The authors believe that firewalls are one particular solution to the problem of security and, as such, do not consider that support for firewalls is a valid requirement for IPng. I do not suggest that the criteria document mandate support for firewalls. The statement I'd like added is that many commercial customers view firewalls -- of whatever sort -- as the *only* current solution to certain security issues, and that therefore IPng should not make it harder to create a firewall than in IPv4. ``Above all, do no harm''. From Robert_Ullmann.LOTUS@CRD.lotus.com Wed Mar 23 16:28:29 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA26755 for ; Wed, 23 Mar 1994 16:23:06 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA19895; Wed, 23 Mar 94 16:24:37 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA19316; Wed, 23 Mar 94 16:28:29 EST Date: Wed, 23 Mar 94 16:28:29 EST Message-Id: <9403232128.AA19316@Mail.Lotus.com> Received: by DniMail (v1.0); Wed Mar 23 16:28:27 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: fragmentation in IPng Status: O Hi, On fragmentation: yes, it's harmful, yes, you want to avoid it. No, I don't think we can live without it. Note that in TCP, the transport layer can be taught to do MTU discovery, and applications won't know. But UDP is different: if IPng doesn't provide fragmentation, the MTU-discovery changes have to be made in the *application*. Existing IPv4 UDP applications expect to be able to send and receive application layer PDUs of up to about 64K. Also consider this: in the first part of a transition, IPng hosts need to be able to "tunnel" through the IPv4 infrastructure; this is all well and good. But later, we need to reverse this, with unmodified IPv4 hosts communicating over an infrastructure that is IPng, with IPv4 decomissioned. Those IPv4 hosts are still going to be sending 1480 byte TPDUs. Either we have to force IPv4 fragmentation on all of them (i.e. offer a "tunnel" MTU of less than 1500), or increase the subnetwork MTU (possible on some types, difficult on Ethernet), or use IPng fragmentation. Or arrange to fit it in: CATNIP 16 byte header (using FCIs), plus 1480 bytes of TPDU, and 4 bytes left over. This ability to do one-for-one operation without modifying the subnetwork MTU is (IMNSHO :-) really important. Rob ["tunnel" being in quotes to mean some kind of logical equivalent of a tunnel; not necessarily the strict definition. And for "1500" and "1480" read "subnetwork MTU" and "subnetwork MTU minus 20" if you like, but we've done a real good job of getting 1500 almost everywhere...] From sob@hsdndev.harvard.edu Wed Mar 23 16:54:48 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA27058 for ; Wed, 23 Mar 1994 16:54:56 -0500 Date: Wed, 23 Mar 94 16:54:48 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403232154.AA12753@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil, smb@research.att.com Subject: Re: requirements document Status: O I support Steve's view. Scott >From ipng-request@cmf.nrl.navy.mil Wed Mar 23 15:38:27 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA01571; Wed, 23 Mar 1994 15:40:17 -0500 Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA26259 for ; Wed, 23 Mar 1994 15:23:58 -0500 From: smb@research.att.com Message-Id: <199403232023.PAA26259@picard.cmf.nrl.navy.mil> Received: by bigbird.zoo.att.com; Wed Mar 23 15:06:30 EST 1994 To: ipng@cmf.nrl.navy.mil Subject: requirements document Date: Wed, 23 Mar 94 15:06:29 EST Status: R I just finished reading through the document. I'm not happy with this passage, as some of you could probably guess: Firewalls Some have requested that IPng include support for firewalls. The authors believe that firewalls are one particular solution to the problem of security and, as such, do not consider that support for firewalls is a valid requirement for IPng. I do not suggest that the criteria document mandate support for firewalls. The statement I'd like added is that many commercial customers view firewalls -- of whatever sort -- as the *only* current solution to certain security issues, and that therefore IPng should not make it harder to create a firewall than in IPv4. ``Above all, do no harm''. From smb@research.att.com Wed Mar 23 21:37:53 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id VAA28783 for ; Wed, 23 Mar 1994 21:39:58 -0500 From: smb@research.att.com Message-Id: <199403240239.VAA28783@picard.cmf.nrl.navy.mil> Date: Wed, 23 Mar 94 21:37:53 EST To: ipng@cmf.nrl.navy.mil Subject: better late than never.... Status: O Network Working Group S. Bellovin IPng White Paper AT&T Bell Laboratories Experimental 23 March 1994 Security Concerns for IPng Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550 Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Overview and Rationale A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. Below, I outline a number of areas of concern. In some cases, there are features that would have a negative impact on security if nothing else is done. It may be desirable to adopt the features anyway, but in that case, the corrective action is mandatory. Firewalls For better or worse, firewalls are very much a feature of today's Internet. They are not, primarily, a response to network protocol security problems per se. Rather, they are a means to compensate for Bellovin [Page 1] White Paper Security Concerns for IPng 21 December 1993 failings in software engineering and system administration. As such, firewalls are not likely to go away any time soon; IPng will do nothing to make host programs any less buggy. Anything that makes firewalls harder to deploy will make IPng less acceptable in the market. Firewalls impose a number of requirements. First, there must be a hierarchical address space. Many address-based filters use the structure of IPv4 addresses for access control decisions. Fortunately, this is a requirement for scalable routing as well. Routers, though, only need access to the destination address of the packet. Network-level firewalls often need to check both the source and destination address. A structure that makes it harder to find the source address is a distinct negative. There is also a need for access to the transport-level (i.e., the TCP or UDP) header. This may be for the port number field, or for access to various flag bits, notably the ACK bit in the TCP header. This latter field is used to distinguish between incoming and outgoing calls. In a different vein, at least one of the possible transition plans uses network-level packet translators [1]. Organizations that use firewalls will need to deploy their own translators to aid in converting their own internal networks. They cannot rely on centrally-located translators intended to serve the entire Internet community. It is thus vital that translators be simple, portable to many common platforms, and cheap -- we do not want to impose too high a financial barrier for converts to IPng. By the same token, it is desirable that such translation boxes not be usable for network-layer connection-laundering. It is difficult enough to trace back attacks today; we should not make it harder. (Some brands of terminal servers can be used for laundering. Most sites with such boxes have learned to configure them so that such activities are impossible.) Comprehensive logging is a possible alternative. IPAE [1] does not have problems with its translation strategy, as address are (insofar as possible) preserved; it is necessary to avoid any alternative strategies, such as circuit-level translators, that might. Encryption and Authentication A number of people are starting to experiment with IP-level encryption and cryptographic authentication. This trend will (and Bellovin [Page 2] White Paper Security Concerns for IPng 21 December 1993 should) continue. IPng should not make this harder, either intrinsically or by imposing a substantial perforance barrier. Encryption can be done with various different granularities: host to host, host to gateway, and gateway to gateway. All of these have their uses; IPng must not rule out any of them. Encapsulation and tunneling strategies are somewhat problematic, as the packet may no longer carry the original source address when it reaches an encrypting gateway. (This may be seen more as a constraint on network topologies. So be it, but we should warn people of the limitation.) Dual-stack approaches, such as in TUBA's transition plan [2], imply multiple addresses for each host. (IPAE has this feature, too.) The encryption and access control infrastructure needs to know about all addresses for a given host, belonging to whichever stack. It should not be possible to bypass authentication or encryption by asking for a different address for the same host. Source Routing and Address-based Authentication The dominant form of host authentication in today's Internet is address-based. That is, hosts often decide to trust other hosts based on their IP addresses. (Actually, it's worse than that; much authentication is name-based, which opens up new avenues of attack. But if an attacker can spoof an IP address, there's no need to attack the name service.) To the extent that it does work, address-based authentication relies on the implied accuracy of the return route. That is, though it is easy to inject packets with a false source address, replies will generally follow the usual routing patterns, and be sent to the real host with that address. This frustrates most, though not all, attempts at impersonation. Problems can arise if source-routing is used. A source route, which must be reversed for reply packets, overrides the usual routing mechanism, and hence destroys the security of address-based authentication. For this reason, many organizations disable source- routing, at least at their border routers. One candidate IPng -- SIPP -- includes source-routing as an important component. To the extent this is used, it is a breaks address-based authentication. This may not be bad; in fact, it is probably good. But it is vital that a more secure cryptographic authentication protocol be defined and deployed before any substantial cutover to source routing, if SIPP is adopted. Accounting Bellovin [Page 3] White Paper Security Concerns for IPng 21 December 1993 An significant part of the world wishes to do usage-sensitive accounting. This may be for billing, or it may simply be to accomodate quality-of-service requests. Either way, definitive knowledge of the relevant address fields is needed. To accomodate this, IPng should have a non-intrusive packet authentication mechanism. By ``non-intrusive'', I mean that it should (a) present little or no load to intermediate hops that do not need to do authentication; (b) be deletable (if desired) by the border gateways, and (c) be ignorable by end-systems or billing systems to which it is not relevant. [1] Robert E. Gilligan, Erik Nordmark, Erik Nordmark, ``IPAE: The SIPP Interoperability and Transition Mechanism'', working draft, March 16, 1994. [2] David M. Piscitello, ``Transition Plan for TUBA/CLNP'', working draft, March 4, 1994. Bellovin [Page 4] From ddc@caraway.lcs.mit.edu Wed Mar 23 22:13:50 1994 Return-Path: ddc@caraway.lcs.mit.edu Received: from caraway.lcs.mit.edu (CARAWAY.LCS.MIT.EDU [18.26.0.170]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id WAA28974 for ; Wed, 23 Mar 1994 22:13:56 -0500 Received: by caraway.lcs.mit.edu id AA12241; Wed, 23 Mar 94 22:13:50 -0500 Message-Id: <9403240313.AA12241@caraway.lcs.mit.edu> To: ipng@cmf.nrl.navy.mil Subject: Draft of ext review kickoff letter From: David Clark Date: Wed, 23 Mar 94 22:13:50 -0500 Sender: ddc@caraway.lcs.mit.edu X-Mts: smtp Status: O Folks, Here is the note I intend to send to the set of known external reviewers tomorrow. Any quick comments on style or function?? Dave ----------- Dear IPng reviewers, The time has come to put you to work. The purpose of this note is to fill you in on the status of our IPng selection process, to tell you what is coming up, and to tell you what we would like you to do. As a first step in our evaluation process, we have solicited from the community white papers on the requirements which a new IP will have to meet. We have a number of papers in hand, which represent an interesting range of positions. Frank Kastenholz and Craig Partridge have produced a single summary document which represents our assessment of the integrated requirements for the new IP. Our first request for you will be to review this summary document and offer any comments you have. We will welcome comments on requirements we and the white papers have missed, or problems you identify relating our summary to the white papers. The individual white papers are now being released as draft Requests for Comments (RFCs). We will send you a set of these papers, and if you are willing we would love to have you look them over as part of the review process. The summary document is now being completed, and will be sent to you shortly, along with specific information on how to get the white papers. We are hoping that we can get some comments back from you within three weeks, so that we can start the next step of evaluating the IPng proposals against this document. Our next request to you will be to perform the same sort of review on a second and final document, which will represent the conclusions of the group concerning the actual selection. Again, there will be backup documentation on the proposals, which we will make available to you. We expect this second stage to occur in June. Our final objective is a presentation at an IETF meeting at the end of July, which is an immovable date against which we must plan. There are a variety of ways you can provide your comments to us. Written (e-mail) comments are most welcome. We will arrange some times for a teleconference, at which you can present your comments, and discuss your thoughts with some of the other reviewers and the directorate. Finally, we will be happy to talk to you one on one. At the time of the second review, we are thinking of arranging an informal workshop to discuss our conclusions. If we decide to proceed with this plan, we will make specific arrangements soon, so that you can put the dates in your calendar; we hope that some of you will be able to come. If you have any questions or comments, please send a message to me or to either of the area directors, Allison Mankin or Scott Bradner. From kasten@mailserv-D.ftp.com Thu Mar 24 09:25:29 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id JAA02052 for ; Thu, 24 Mar 1994 09:26:20 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 24 Mar 1994 09:26:17 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA09315; Thu, 24 Mar 94 09:25:29 EST Date: Thu, 24 Mar 94 09:25:29 EST Message-Id: <9403241425.AA09315@mailserv-D.ftp.com> To: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: fragmentation in IPng From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 646 Status: O > What we *really* need for the IP suite is a standard request-response/RPC > transport protocol that handles frag/reasm, PMTU discovery, RTT computation, > etc. Too bad nothing ever came of all the work on this topic in the > end2end RG several years ago. Steve, this is right on. Let's look at the problem -- getting large datagrams through the net in a connectionless manner -- instead of the solution ("we must have fragmentation"). It sounds like a lightweight transport protocol, about halfway between UDP and TCP in function is desired. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From crb@faline.bellcore.com Thu Mar 24 10:55:58 1994 Return-Path: crb@faline.bellcore.com Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id KAA02908 for ; Thu, 24 Mar 1994 10:57:17 -0500 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA06135; Thu, 24 Mar 1994 11:00:21 -0500 Received: from localhost (localhost [127.0.0.1]) by faline.bellcore.com (8.6.7/8.6.4) with SMTP id KAA13452 for ; Thu, 24 Mar 1994 10:56:05 -0500 Message-Id: <199403241556.KAA13452@faline.bellcore.com> X-Authentication-Warning: faline.bellcore.com: Host localhost didn't use HELO protocol To: ipng-wp@harvard.edu Subject: rfc 1550 white paper submission Date: Thu, 24 Mar 94 10:55:58 -0500 From: Chris Brazdziunas Status: O I would like to submit this white paper as an engineering consideration for IPng as solicited by rfc1550. FYI, this output was generated by nroff. chris brazdziunas --------------------------------------------------------------------- Network Working Group C. Brazdziunas INTERNET-DRAFT Bellcore Category: Informational March 1994 IPng Support for ATM Services Executive Summary This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. IPng should provide support for existing and emerging link technologies that it will be transported over. Link technologies like Ethernet simply multiplex traffic from upper layer protocols onto a single channel. "Sophisticated" link technologies like ATM are emerging in the marketplace allowing several virtual channels to be established over a single wire (or fiber) potentially based on an applications' network performance objectives. Support for both "sophisticated" (ATM) and existing link technologies needs to be considered in an IPng candidate. End-to-end applications will communicate through a network where IPng packets travel across subnetworks such as Ethernet and Hippi and also more "sophisticated" link levels such as ATM. Though initial support for IPng over ATM subnetworks will not facilitate a virtual circuit per application, the hooks to provide such a mapping should be in place while also maintaining support for the transport of IPng packets across conventional subnetworks. Application support for QOS-based link level service requires that the following types of ATM information be mappable (or derivable) from the higher level protocol(s) such as IPng: source and destination(s) addresses, connection quality of service parameters, connection state, and ATM virtual circuit identifier. Some of these mappings may be derivable from information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier should be efficiently derivable from IPng packet information. An IPng candidate should provide evidence that the mapping from an applications' IPng packets to ATM virtual circuit(s) can be accomplished in a heterogeneous Internet architecture keeping in consideration the gigabit/sec rates that IPng/ATM subnetworks will eventually be operating at. Brazdziunas [Page 1] INTERNET-DRAFT IPng Support for ATM Services March 1994 1. Introduction This paper describes parameters that are needed to map IPng (or any protocol operating above the link level) to ATM services. ATM is a "sophisticated" link level technology which provides the potential capability for applications at the TCP/UDP level to map to a single ATM virtual circuit for transport across an ATM network(s) customized to the network performance and traffic requirements for that application. This is a step above many of today's existing link technologies which can only support a single level of network performance that must be shared by all applications operating on a single endpoint. The future Internet will be comprised of both conventional and "sophisticated" link technologies. The "sophisticated" features of link layers like ATM need to be incorporated into an internet where data travels not only across an ATM network but also several other existing LAN and WAN technologies. Future networks are likely to be a combination of subnetworks providing best-effort link level service such as Ethernet and also sophisticated subnetworks that can support quality of service-based connections like ATM. One can envision data originating from an Ethernet, passing through an ATM network, FDDI network, another ATM network, and finally arriving at its destination residing on a HIPPI network. IPng packets will travel through such a list of interconnected network technologies as ATM is incorporated as one of the components of the future Internet. To support per application customizable link level connections, four types of ATM information should be derivable from the higher level protocol(s) like IPng. This ATM information includes: source and destination ATM addresses, connection quality of service parameters, connection state, and an ATM virtual circuit identifier which maps to a single IPng application (i.e. single TCP/UDP application). Some of these mapping could potentially be derivable through information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier needs to be efficiently mappable from IPng packet information. Organization of this white paper is as follows. First the characteristics of ATM are described focusing on functions that are not provided in today's LAN technologies. This section provides background information necessary for the following section describing the parameters needed to map IPng services to ATM services. Brazdziunas [Page 2] INTERNET-DRAFT IPng Support for ATM Services March 1994 2. Terminology In this white paper, the term "application" refers to a process or set of collective processes operating at the TCP/UDP level or above in the protocol stack. For example, each instance of "telnet" or "ftp" session running on an end station is a distinct application. 3. Characteristics of ATM Service ATM has several characteristics which differentiates it from current link level technologies. First of all, ATM has the capability of providing many virtual channels to transmit information over a single wire (or fiber). This is very similar to X.25, where many logical channels can be established over a single physical media. But unlike X.25, ATM allows for each of these channels or circuits to have a customizable set of performance and quality of service characteristics. Link level technologies like Ethernet provide a single channel with a single performance and quality of service characteristic. In a sense, a single ATM link level media appears like an array of of link level technologies each with customizable characteristics. ATM virtual circuits can be established dynamically utilizing its signaling protocol. ATM signaling is a source initiated negotiation process for connection establishment. This protocol informs elements in the network of the characteristics for the desired connection. ATM signaling does not provide any guidelines for how network elements decide whether it can accept a call or where a signaling request should be forwarded if the end destination (from the link level perspective) has not been reached. In short, ATM signaling does not support any routing functionality of network admission control. ATM signaling establishes a "hard state" in the network for a call. "Hard state" implies that the state of a connection in intermediate switching equipment can be set and once established it will be maintained until a message is received by one of the ends of the call requesting a change in state for the connection [2]. As a result, an ATM end system (this could be a workstation with an ATM adapter or a router with an ATM interface) receives guaranteed service from the ATM network. The ATM network is responsible for maintaining the connection state. The price the ATM termination points pay for this guarantee is the responsibility of changing the state of the connection, specifically informing the ATM network to establish, alter, or tear-down the connection. Brazdziunas [Page 3] INTERNET-DRAFT IPng Support for ATM Services March 1994 Each ATM end point in a network has an ATM address associated with it to support dynamic connection establishment via signaling. These addresses are hierarchical in structure and globally unique [3]. As a result, these addresses are routable. This allows ATM networks to eventually support a large number of ATM endpoints once a routing architecture and protocols to support it become available. The ATM User-Network Interface (UNI) signaling protocol based on ITU-TS Q.93B allows many different service parameters to be specified for describing connection characteristics. [3] These parameters can be grouped into several categories: ATM adaptation layer (AAL) information, network QOS objectives, connection traffic descriptor, and transit network selector. The AAL information specifies negotiable parameters such as AAL type and maximum packet sizes. The network QOS objectives describe the service that the ATM user expects from the network. Q.93B allows for one of five service classes to be selected by the ATM user. The service classes are defined as general traffic types such as circuit emulation (class A), variable bit rate audio and video (class B), connection-oriented data transfer (class C), connectionless data transfer (class D), best effort service (class X), and unspecified [3]. Each of these categories are further specified through network provider objectives for various ATM performance parameters. These parameters may include cell transfer delay, cell delay variation, and cell loss ratio. The connection traffic descriptor specifies characteristics of the data generated by the user of the connection. This information allows the ATM network to commit the resources necessary to support the traffic flow with the quality of service the user expects. Characteristics defined in the ATM Forum UNI specification include peak cell rate, sustainable cell rate, and maximum and minimum burst sizes [3]. Lastly, the transit network selection parameter allows an ATM user to select a preferred network provider to service the connection [3]. 4. Parameters Required to Map IPng to ATM There are several parameters required to map ATM services from a higher level service like IPng. These ATM parameters can be categorized in the following manner: addressing parameters, connection QOS-related parameters, connection management information, and ATM virtual circuit identifier. The first three categories provide support for ATM signaling. The last parameter, a connection identifier that maps IPng packets to ATM virtual circuits, provides support for an ATM virtual circuit per application when the end-to- end connection travels across an ATM subnetwork(s) (this does not assume that ATM is the only type of subnetwork that this connection Brazdziunas [Page 4] INTERNET-DRAFT IPng Support for ATM Services March 1994 travels across). Below, mapping issues for each of these parameters will be described. 4.1. Addressing ATM supports routable addresses to each ATM endpoint to facilitate the dynamic establishment of connections. These addresses need to be derived from a higher level address such as an IPng address and IPng routing information. This type of mapping is not novel. It is a mapping that is currently done for support of current IP over link technologies such as Ethernet. An IP over ATM address resolution protocol (ARP) has been described in the Internet Standard, "Classical IP over ATM" [5]. In addition, support for IP routing over large ATM networks is being worked in the IETF's "Routing over Large Clouds" working group. 4.2. Quality of Service As described in section 3, an ATM virtual circuit is established based upon a user's traffic characteristics and network performance objectives. These characteristics which include delay and throughput requirements can only be defined by the application level (at the transport level or above) as opposed to the internetworking (IPng) level. For instance, a file transfer application transferring a 100 MB file has very different link level performance requirements than a network time application. The former requires a high throughput and low error rate connection whereas the latter could perhaps be adequately serviced utilizing a best-effort service. Current IP does not provide much support for a quality of service specification and provides no support for the specification of link level performance needs by an application directly. This is due to the fact that only a single type of link level performance is available with link technologies like Ethernet. As a result, all applications over IP today receive the same level of link service. IPng packets need not explicitly contain information parameters describing an application's traffic characteristics and network performance objectives (e.g. delay = low, throughput = 10 Mb/s). This information could potentially be mapped from resource reservation protocols that operate at the IP (and potentially IPng) level [4]. Brazdziunas [Page 5] INTERNET-DRAFT IPng Support for ATM Services March 1994 4.3. Connection Management The establishment and release of ATM connections should ultimately be controlled by the applications utilizing the circuits. As described in section 3, ATM signaling establishes a "hard state" in the network which is controlled by the ATM termination points [2]. Currently, IP provides no explicit mechanism for link level connection management. Future support for link level connection management could be accomplished through resource reservation protocols and need not necessarily be supported directly via information contained in the IPng protocol. 4.4. Connection Identifier A mapping function needs to exist between IPng packets and ATM so that application flows map one-to-one to ATM virtual circuits. Currently, application traffic flows are identified at the transport level by UDP/TCP source and destination ports and IP protocol identifiers. This level of identification should also be available at the IPng level so that information in the IPng packets identify an application's flow and map to an ATM virtual circuit supporting that flow when the IPng packets travels across an ATM subnetwork(s). Using the current IP protocol, identifying an application's traffic flow requires the combination of the following five parameters: source and destination IP addresses, source and destination UDP/TCP ports, and IP protocol identifier. This application connection identifier for IP is complex and could potentially be costly to implement in IP end stations and routers. The IPng connection identifier should be large enough so that all application level traffic from an IPng end point can be mapped into the IPng packet. Currently, ATM provides 24 bits for virtual circuit identification (VPI and VCI). This provides sufficient capacity for 2^24 (16,777,216) connections [6]. The actual number of bits that are used for the ATM virtual circuit however is established through negotiation between the ATM endpoint and ATM network. This number is useful as an upper bound for the number of mappings that are needed to be supported by IPng. An IPng candidate should be able to identify how IPng packets from an application can map to an ATM virtual circuit. In addition, this mapping should be large enough to support a mapping for every IPng application on an end system to an ATM virtual circuit. Careful consideration should be given to complexity of this mapping for IPng Brazdziunas [Page 6] INTERNET-DRAFT IPng Support for ATM Services March 1994 to ATM since it needs to eventually support gigabit/sec rates. Security Considerations Security issues are not addressed in this memo. References [1] Bradner, S., Mankin, A., "IP: Next Generation (IPng) White Paper Solicitation", RFC 1550, December, 1993. [2] Clark, D. D., "The Design Philosophy of the DARPA Internet Protocols", Proc. ATM SIGCOMM '88, August, 1988. [3] "ATM User-Network Interface Specification, Version 3.0", ATM Forum, September 10, 1993 [4] Zhang, L., Estrin, D., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Internet Draft, October, 1993. [5] Laubach, M., "Classical IP and ARP over ATM", Internet Draft, December 20, 1993. [6] "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols Generic Requirements", Bellcore Technical Advisory TA-NWT-001113, Issue 1, June 1993. Author Information Christina Brazdziunas Bellcore 445 South Street Morristown, NJ 07960 (201) 829-4173 crb@faline.bellcore.com Brazdziunas [Page 7] From sob@hsdndev.harvard.edu Thu Mar 24 11:12:37 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id LAA03106 for ; Thu, 24 Mar 1994 11:13:15 -0500 Date: Thu, 24 Mar 94 11:12:37 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403241612.AA22342@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: another white paper Status: O >From crb@faline.bellcore.com Thu Mar 24 10:57:01 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA06135; Thu, 24 Mar 1994 11:00:21 -0500 Received: from localhost (localhost [127.0.0.1]) by faline.bellcore.com (8.6.7/8.6.4) with SMTP id KAA13452 for ; Thu, 24 Mar 1994 10:56:05 -0500 Message-Id: <199403241556.KAA13452@faline.bellcore.com> X-Authentication-Warning: faline.bellcore.com: Host localhost didn't use HELO protocol To: ipng-wp@harvard.edu Subject: rfc 1550 white paper submission Date: Thu, 24 Mar 94 10:55:58 -0500 From: Chris Brazdziunas Status: R I would like to submit this white paper as an engineering consideration for IPng as solicited by rfc1550. FYI, this output was generated by nroff. chris brazdziunas --------------------------------------------------------------------- Network Working Group C. Brazdziunas INTERNET-DRAFT Bellcore Category: Informational March 1994 IPng Support for ATM Services Executive Summary This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. IPng should provide support for existing and emerging link technologies that it will be transported over. Link technologies like Ethernet simply multiplex traffic from upper layer protocols onto a single channel. "Sophisticated" link technologies like ATM are emerging in the marketplace allowing several virtual channels to be established over a single wire (or fiber) potentially based on an applications' network performance objectives. Support for both "sophisticated" (ATM) and existing link technologies needs to be considered in an IPng candidate. End-to-end applications will communicate through a network where IPng packets travel across subnetworks such as Ethernet and Hippi and also more "sophisticated" link levels such as ATM. Though initial support for IPng over ATM subnetworks will not facilitate a virtual circuit per application, the hooks to provide such a mapping should be in place while also maintaining support for the transport of IPng packets across conventional subnetworks. Application support for QOS-based link level service requires that the following types of ATM information be mappable (or derivable) from the higher level protocol(s) such as IPng: source and destination(s) addresses, connection quality of service parameters, connection state, and ATM virtual circuit identifier. Some of these mappings may be derivable from information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier should be efficiently derivable from IPng packet information. An IPng candidate should provide evidence that the mapping from an applications' IPng packets to ATM virtual circuit(s) can be accomplished in a heterogeneous Internet architecture keeping in consideration the gigabit/sec rates that IPng/ATM subnetworks will eventually be operating at. Brazdziunas [Page 1] INTERNET-DRAFT IPng Support for ATM Services March 1994 1. Introduction This paper describes parameters that are needed to map IPng (or any protocol operating above the link level) to ATM services. ATM is a "sophisticated" link level technology which provides the potential capability for applications at the TCP/UDP level to map to a single ATM virtual circuit for transport across an ATM network(s) customized to the network performance and traffic requirements for that application. This is a step above many of today's existing link technologies which can only support a single level of network performance that must be shared by all applications operating on a single endpoint. The future Internet will be comprised of both conventional and "sophisticated" link technologies. The "sophisticated" features of link layers like ATM need to be incorporated into an internet where data travels not only across an ATM network but also several other existing LAN and WAN technologies. Future networks are likely to be a combination of subnetworks providing best-effort link level service such as Ethernet and also sophisticated subnetworks that can support quality of service-based connections like ATM. One can envision data originating from an Ethernet, passing through an ATM network, FDDI network, another ATM network, and finally arriving at its destination residing on a HIPPI network. IPng packets will travel through such a list of interconnected network technologies as ATM is incorporated as one of the components of the future Internet. To support per application customizable link level connections, four types of ATM information should be derivable from the higher level protocol(s) like IPng. This ATM information includes: source and destination ATM addresses, connection quality of service parameters, connection state, and an ATM virtual circuit identifier which maps to a single IPng application (i.e. single TCP/UDP application). Some of these mapping could potentially be derivable through information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier needs to be efficiently mappable from IPng packet information. Organization of this white paper is as follows. First the characteristics of ATM are described focusing on functions that are not provided in today's LAN technologies. This section provides background information necessary for the following section describing the parameters needed to map IPng services to ATM services. Brazdziunas [Page 2] INTERNET-DRAFT IPng Support for ATM Services March 1994 2. Terminology In this white paper, the term "application" refers to a process or set of collective processes operating at the TCP/UDP level or above in the protocol stack. For example, each instance of "telnet" or "ftp" session running on an end station is a distinct application. 3. Characteristics of ATM Service ATM has several characteristics which differentiates it from current link level technologies. First of all, ATM has the capability of providing many virtual channels to transmit information over a single wire (or fiber). This is very similar to X.25, where many logical channels can be established over a single physical media. But unlike X.25, ATM allows for each of these channels or circuits to have a customizable set of performance and quality of service characteristics. Link level technologies like Ethernet provide a single channel with a single performance and quality of service characteristic. In a sense, a single ATM link level media appears like an array of of link level technologies each with customizable characteristics. ATM virtual circuits can be established dynamically utilizing its signaling protocol. ATM signaling is a source initiated negotiation process for connection establishment. This protocol informs elements in the network of the characteristics for the desired connection. ATM signaling does not provide any guidelines for how network elements decide whether it can accept a call or where a signaling request should be forwarded if the end destination (from the link level perspective) has not been reached. In short, ATM signaling does not support any routing functionality of network admission control. ATM signaling establishes a "hard state" in the network for a call. "Hard state" implies that the state of a connection in intermediate switching equipment can be set and once established it will be maintained until a message is received by one of the ends of the call requesting a change in state for the connection [2]. As a result, an ATM end system (this could be a workstation with an ATM adapter or a router with an ATM interface) receives guaranteed service from the ATM network. The ATM network is responsible for maintaining the connection state. The price the ATM termination points pay for this guarantee is the responsibility of changing the state of the connection, specifically informing the ATM network to establish, alter, or tear-down the connection. Brazdziunas [Page 3] INTERNET-DRAFT IPng Support for ATM Services March 1994 Each ATM end point in a network has an ATM address associated with it to support dynamic connection establishment via signaling. These addresses are hierarchical in structure and globally unique [3]. As a result, these addresses are routable. This allows ATM networks to eventually support a large number of ATM endpoints once a routing architecture and protocols to support it become available. The ATM User-Network Interface (UNI) signaling protocol based on ITU-TS Q.93B allows many different service parameters to be specified for describing connection characteristics. [3] These parameters can be grouped into several categories: ATM adaptation layer (AAL) information, network QOS objectives, connection traffic descriptor, and transit network selector. The AAL information specifies negotiable parameters such as AAL type and maximum packet sizes. The network QOS objectives describe the service that the ATM user expects from the network. Q.93B allows for one of five service classes to be selected by the ATM user. The service classes are defined as general traffic types such as circuit emulation (class A), variable bit rate audio and video (class B), connection-oriented data transfer (class C), connectionless data transfer (class D), best effort service (class X), and unspecified [3]. Each of these categories are further specified through network provider objectives for various ATM performance parameters. These parameters may include cell transfer delay, cell delay variation, and cell loss ratio. The connection traffic descriptor specifies characteristics of the data generated by the user of the connection. This information allows the ATM network to commit the resources necessary to support the traffic flow with the quality of service the user expects. Characteristics defined in the ATM Forum UNI specification include peak cell rate, sustainable cell rate, and maximum and minimum burst sizes [3]. Lastly, the transit network selection parameter allows an ATM user to select a preferred network provider to service the connection [3]. 4. Parameters Required to Map IPng to ATM There are several parameters required to map ATM services from a higher level service like IPng. These ATM parameters can be categorized in the following manner: addressing parameters, connection QOS-related parameters, connection management information, and ATM virtual circuit identifier. The first three categories provide support for ATM signaling. The last parameter, a connection identifier that maps IPng packets to ATM virtual circuits, provides support for an ATM virtual circuit per application when the end-to- end connection travels across an ATM subnetwork(s) (this does not assume that ATM is the only type of subnetwork that this connection Brazdziunas [Page 4] INTERNET-DRAFT IPng Support for ATM Services March 1994 travels across). Below, mapping issues for each of these parameters will be described. 4.1. Addressing ATM supports routable addresses to each ATM endpoint to facilitate the dynamic establishment of connections. These addresses need to be derived from a higher level address such as an IPng address and IPng routing information. This type of mapping is not novel. It is a mapping that is currently done for support of current IP over link technologies such as Ethernet. An IP over ATM address resolution protocol (ARP) has been described in the Internet Standard, "Classical IP over ATM" [5]. In addition, support for IP routing over large ATM networks is being worked in the IETF's "Routing over Large Clouds" working group. 4.2. Quality of Service As described in section 3, an ATM virtual circuit is established based upon a user's traffic characteristics and network performance objectives. These characteristics which include delay and throughput requirements can only be defined by the application level (at the transport level or above) as opposed to the internetworking (IPng) level. For instance, a file transfer application transferring a 100 MB file has very different link level performance requirements than a network time application. The former requires a high throughput and low error rate connection whereas the latter could perhaps be adequately serviced utilizing a best-effort service. Current IP does not provide much support for a quality of service specification and provides no support for the specification of link level performance needs by an application directly. This is due to the fact that only a single type of link level performance is available with link technologies like Ethernet. As a result, all applications over IP today receive the same level of link service. IPng packets need not explicitly contain information parameters describing an application's traffic characteristics and network performance objectives (e.g. delay = low, throughput = 10 Mb/s). This information could potentially be mapped from resource reservation protocols that operate at the IP (and potentially IPng) level [4]. Brazdziunas [Page 5] INTERNET-DRAFT IPng Support for ATM Services March 1994 4.3. Connection Management The establishment and release of ATM connections should ultimately be controlled by the applications utilizing the circuits. As described in section 3, ATM signaling establishes a "hard state" in the network which is controlled by the ATM termination points [2]. Currently, IP provides no explicit mechanism for link level connection management. Future support for link level connection management could be accomplished through resource reservation protocols and need not necessarily be supported directly via information contained in the IPng protocol. 4.4. Connection Identifier A mapping function needs to exist between IPng packets and ATM so that application flows map one-to-one to ATM virtual circuits. Currently, application traffic flows are identified at the transport level by UDP/TCP source and destination ports and IP protocol identifiers. This level of identification should also be available at the IPng level so that information in the IPng packets identify an application's flow and map to an ATM virtual circuit supporting that flow when the IPng packets travels across an ATM subnetwork(s). Using the current IP protocol, identifying an application's traffic flow requires the combination of the following five parameters: source and destination IP addresses, source and destination UDP/TCP ports, and IP protocol identifier. This application connection identifier for IP is complex and could potentially be costly to implement in IP end stations and routers. The IPng connection identifier should be large enough so that all application level traffic from an IPng end point can be mapped into the IPng packet. Currently, ATM provides 24 bits for virtual circuit identification (VPI and VCI). This provides sufficient capacity for 2^24 (16,777,216) connections [6]. The actual number of bits that are used for the ATM virtual circuit however is established through negotiation between the ATM endpoint and ATM network. This number is useful as an upper bound for the number of mappings that are needed to be supported by IPng. An IPng candidate should be able to identify how IPng packets from an application can map to an ATM virtual circuit. In addition, this mapping should be large enough to support a mapping for every IPng application on an end system to an ATM virtual circuit. Careful consideration should be given to complexity of this mapping for IPng Brazdziunas [Page 6] INTERNET-DRAFT IPng Support for ATM Services March 1994 to ATM since it needs to eventually support gigabit/sec rates. Security Considerations Security issues are not addressed in this memo. References [1] Bradner, S., Mankin, A., "IP: Next Generation (IPng) White Paper Solicitation", RFC 1550, December, 1993. [2] Clark, D. D., "The Design Philosophy of the DARPA Internet Protocols", Proc. ATM SIGCOMM '88, August, 1988. [3] "ATM User-Network Interface Specification, Version 3.0", ATM Forum, September 10, 1993 [4] Zhang, L., Estrin, D., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Internet Draft, October, 1993. [5] Laubach, M., "Classical IP and ARP over ATM", Internet Draft, December 20, 1993. [6] "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols Generic Requirements", Bellcore Technical Advisory TA-NWT-001113, Issue 1, June 1993. Author Information Christina Brazdziunas Bellcore 445 South Street Morristown, NJ 07960 (201) 829-4173 crb@faline.bellcore.com Brazdziunas [Page 7] From Robert_Ullmann.LOTUS@CRD.lotus.com Thu Mar 24 14:39:17 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id OAA05181 for ; Thu, 24 Mar 1994 14:33:58 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA14275; Thu, 24 Mar 94 14:35:25 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA28216; Thu, 24 Mar 94 14:39:17 EST Date: Thu, 24 Mar 94 14:39:17 EST Message-Id: <9403241939.AA28216@Mail.Lotus.com> Received: by DniMail (v1.0); Thu Mar 24 14:39:14 1994 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: fragmentation in IPng Status: O Hi, > [smb] > I think, then, that we're converging on a consensus. I strongly disagree. > 1) IPng routers will not do fragmentation. > 2) IPng hosts may do fragmentation for now. In the present architecture, it is exactly the opposite; fragmentation is something only routers need worry about, except when the datagram is fragmented against the local subnetwork MTU. Hosts do reassembly. I wouldn't change this lightly. In particular, changing it by moving the complexity into the hosts deprives hosts of a valubale service now provided by the network. Pushing up into the transport and applications is inconceivable; it means they must each re-implement the function. Think about what happens when routes change. Think about what happens when datagrams overloading a route are splashed onto a less-desireable route with a smaller MTU. (Yes, the TCP or a similar transport MAY be able to still do something intelligent; but a connectionless protocol will not.) > 3) Path MTU discovery is the preferred option, where applicable For UDP, this changes the present expectation that a large TPDU (say an NFS write) will almost always work the first time, to an expectation that it will ALWAYS FAIL the first time. Not pleasant at all. When the RPC timer runs out and retransmits, all the pieces go out again anyway. Sure, you can invent something to improve that; and re-invent it for every new application. -------------- Right now, in both the IPv4 and OSI *architecture*, the following holds: The transport can present TDPUs with lengths up to the architectural limit (e.g. ~64Kbytes) to the network layer interface with an expectation that they will be delivered most of the time. --------------- If you want to change that, we need an area called the IP and TCP and UDP and Application Services Next Generation Area. --------------- I've been asked several times where the "application" or "API" specifications are in the CATNIP specification, as if they are somehow missing. Of course they are missing. The API presented to an IPv4 or CLNP or IPX-based application is *exactly* what it is today. You don't change the applications. The network service access point interface presented to the transport is *exactly* what it is today. You don't change the transport. Likewise, the use of the subnetwork services is *exactly* as it is now; the only problem being that we already have (for example) both ARP and ES-IS; the IETF will eventually want to pick one and (mildly) deprecate the other. Anything else is not in the charter. Then, as, when, and if individual protocols, implementations, and instances of implementations want to become knowledgeable of the new standard addressing and capabilities, they do so. Not all at once. (In between, there are some cute hacks, like offering applications addresses in the 224.x.x.x-255.x.x.x range if the actual address is outside the version 4 space, and things like that. Keep the details confined inside your implementation please.) Best Regards, Robert From bound@zk3.dec.com Thu Mar 24 16:15:02 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA06077 for ; Thu, 24 Mar 1994 16:22:02 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA07172; Thu, 24 Mar 94 13:15:10 -0800 Received: by xirtlu.zk3.dec.com; id AA12419; Thu, 24 Mar 1994 16:15:08 -0500 Message-Id: <9403242115.AA12419@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Payload Length and Fragmentation Date: Thu, 24 Mar 94 16:15:02 -0500 X-Mts: smtp Status: O FYI.. Us working on IPng at Digital just pulled across all the Big-i archive mail on the subject titled in this mail. That took some work too. Anyway we are looking at it and there were some good arguments pro and con. If its useful after I read it all I will send it. Also just scanning it I must say folks get really nasty in this forum. If someone talked to me right in front of my face in person like some of the folks talk to each other on the mail I found I think I would take it as an assault and react accordingly. I might even spit on them, and see where it goes from there, and get real nasty back (just kidding). /jim From Robert_Ullmann.LOTUS@CRD.lotus.com Thu Mar 24 17:50:20 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id RAA06662 for ; Thu, 24 Mar 1994 17:44:56 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA18797; Thu, 24 Mar 94 17:46:27 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA09264; Thu, 24 Mar 94 17:50:20 EST Date: Thu, 24 Mar 94 17:50:20 EST Message-Id: <9403242250.AA09264@Mail.Lotus.com> Received: by DniMail (v1.0); Thu Mar 24 17:50:18 1994 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: 224.x.x.x Status: O It was, of course, a typo; I meant 240.x.x.x and up. Then again, you might choose not to do Deering-style multicasting ... Rob From Greg_Minshall@Novell.COM Thu Mar 24 22:19:56 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id BAA08990 for ; Fri, 25 Mar 1994 01:28:51 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA05492; Thu, 24 Mar 94 23:33:17 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB27175; Thu, 24 Mar 94 22:19:56 PST Date: Thu, 24 Mar 94 22:19:56 PST Message-Id: <9403250619.AB27175@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng mailing list From: Greg Minshall Subject: If *i* were to write a white paper... Status: O If i were to actually write a white paper, it would suggest 3 things as required for operation (today) in an IPng. 1. No configuration needed for a host. So, use IEEE address as the "node id". (But, to allow sites to be more administration-intensive, define an ICMP which says "can't route autoconfigured address"; and a way, a la DHCP, to acquire an "administered" address.) (**) 2. Ease configuration of "subnets" (wires, whatever). One of the hardest things in configuring IPv4 networks is *subnet masks*. They are a total disaster from an ease of use point of view. So, no subnet masks. At most, choose one single number from some set of numbers and assign it to a subnet. Nothing more complex than that. 3. Some sort of dynamic name (and service) registration/query protocol, which does NOT rely on servers (you can't assume servers in an ad hoc case, for example). We use something called SAP (Apple uses something called NBP, which is similar) which has bad problems with scaling. The scaling problems can probably be dealt with; it works very well for local and ad hoc networking. (In IPv4, hosts, not services, are named; i would suggest there is a problem here, though SMB would suggest that we just think of "host names" as, really, being "service names"; long sentence, but i'm uncomfortable with this view.) (Which is to say, yes, autoregistration is important!) Greg (**) There *will*, of course, be manual configuration for *users*, conveying rights to file services, etc. ps - still looking for warts (the above reflect a few). From Greg_Minshall@Novell.COM Thu Mar 24 22:21:24 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id BAA09002 for ; Fri, 25 Mar 1994 01:30:21 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA05527; Thu, 24 Mar 94 23:34:48 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB27175; Thu, 24 Mar 94 22:21:24 PST Date: Thu, 24 Mar 94 22:21:24 PST Message-Id: <9403250621.AB27175@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: smb@research.att.com, ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Re: better late than never.... Status: O Steve, > There is also a need for access to the transport-level (i.e., the TCP > or UDP) header. This may be for the port number field, or for access > to various flag bits, notably the ACK bit in the TCP header. This > latter field is used to distinguish between incoming and outgoing > calls. You probably meant the SYN bit? > A number of people are starting to experiment with IP-level > encryption and cryptographic authentication. This trend will (and > should) continue. IPng should not make this harder, either > intrinsically or by imposing a substantial perforance barrier. How *could* IPng make this harder? > Dual-stack approaches, such as in TUBA's transition plan [2], imply > multiple addresses for each host. (IPAE has this feature, too.) The > encryption and access control infrastructure needs to know about all > addresses for a given host, belonging to whichever stack. It should > not be possible to bypass authentication or encryption by asking for > a different address for the same host. Somebody, if i remember correctly, wrote a wp about the need for multiple addreses for a single host. Who was that? Greg From craig@aland.bbn.com Fri Mar 25 09:05:24 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA02708 for ; Fri, 25 Mar 1994 12:07:25 -0500 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA23692 for ipng@cmf.nrl.navy.mil; Fri, 25 Mar 94 12:06:57 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA03370; Fri, 25 Mar 1994 09:05:27 -0800 Message-Id: <199403251705.JAA03370@aland.bbn.com> To: ipng@cmf.nrl.navy.mil Subject: avoiding second system syndrome Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 25 Mar 94 09:05:24 -0800 Sender: craig@aland.bbn.com Status: O Hi folks: As we go to IETF, I'd like to send out a brief cautionary note. Remember Fred Brooks' warning to avoid second system syndrome. (The instinct to put everything into the second version of a system that you couldn't put into the first, with the result that the second system is delivered late or not at all). Another stricter standard is one I heard from a software engineering friend who had somehow inherited the wisdom that, in general, a successful project does at most one thing that no one has done before. There are lots of things we'd like in IPng... Lets make sure that we don't overburden ourselves with many requirements that each force us to solve problems that no one has successfully solved before. Right now, by my count, we have at least three activities that no one has quite done: * expanding the address space to huge proportions (and note, I was reminded last week that folks are working on networking individual people -- for military reasons -- yes, your gun might have a separate IP address from your heads-up display). * support for real-time flows * autoconfiguration that works for arbitrary networks (not just 802) and topologies There are precedents for each task (except autoconfig) but the point is the technical risks are mounting, and we should think long and hard before we any more hard problems to this list. Craig From Greg_Minshall@Novell.COM Mon Mar 28 14:34:46 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id RAA00899 for ; Mon, 28 Mar 1994 17:43:51 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA28417; Mon, 28 Mar 94 15:48:20 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB04242; Mon, 28 Mar 94 14:34:46 PST Date: Mon, 28 Mar 94 14:34:46 PST Message-Id: <9403282234.AB04242@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: kasten@ftp.com From: Greg Minshall Subject: Re: If *i* were to write a white paper... Cc: ipng mailing list Status: O Frank, Thanks for the response. > > 1. No configuration needed for a host. So, use IEEE address as the "node > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I think that this succinctly states the requirements vis hosts. I really >don't want to change the draft now -- will you be at the BOF to suggest >it? Yes. >Though the word "no" worries me a bit -- I am afraid that there might >be some needed config -- as your other post pointed out, a host can't >be expected to divine its node-name... And there was a lot of >discussion on big-i as to whether relying on IEEE 802 numbers was valid >(some machines might not have them etc etc etc). I'd probably word >an explanation to say that > "No config" is the ideal. We realize that there will probably need > to be some manual config and proposals will be evaluated based on the > amount and complexity of manual config that they require (the less > of both, the better)" I guess "needed" is the key. I *don't* need to set up a DNS name in order to use a host (as a client, say). Also, my third point (dynamic naming a la SAP) implies that once someone types *in* my name, it should be exported to the net with not additional configuration/manual entries. > > 2. Ease configuration of "subnets" (wires, whatever). One of the hardest > > things in configuring IPv4 networks is *subnet masks*. They are a total > > disaster from an ease of use point of view. So, no subnet masks. At most, > > choose one single number from some set of numbers and assign it to a > > subnet. Nothing more complex than that. > >I've always thought along the lines of having the routers periodically >advertise onto all connected nets >a) the 'network prefix' of the network which gives any receiving host > all it needs to know in order to determine the 'network number' > component of its address, (i.e. solving the auto-config issue > for getting network numbers/subnet-masks, etc, in to the hosts) and >b) what the router can connect to, which gives us router discovery... > >This has the added property that to change the network number of a >subnet, I simply have to tell the routers and they tell the hosts. I >do not even have to know that a host exists in order to change its >network number (AND, if there is a hierarchical relationship among >routers, the I can change the 'network number' in the 'network-level >router' and it can tell all the 'subnet-level routers' and they can >tell the hosts)... This is thinking done while driving to work in the >mornings - I'm sure that there is a hole or two in it :-) You aren't getting my point (i think). My point is *MAKE ROUTER CONFIGURATION SIGNIFICANTLY EASIER*. With (traditional) IPX and AppleTalk, configuring a router is fairly trivial: reach in a bag of 32 or 16 bit numbers and choose a network number and assign that number to the router. With non-subnetted IP, configuring a router is slightly harder: ask some *authority* for a number (or numbers), then assign one of those assigned numbers to the router. But, SUBNETTING has made configuring IP routers a nightmare for your mere mortal. Get this, get this, get this! Configuring routers is every bit as important as configuring hosts in terms of the needed simplicity. You (we) need to make this incredibly easy to do. Greg From J.Crowcroft@cs.ucl.ac.uk Tue Mar 29 16:42:13 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id KAA04780 for ; Tue, 29 Mar 1994 10:42:34 -0500 Message-Id: <199403291542.KAA04780@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 29 Mar 1994 16:42:15 +0100 To: ipng mailing list Subject: Comments on White Papers so far... Inereply-to: Your message of "Mon, 28 Mar 94 14:34:46 PST." <9403282234.AB04242@WC.Novell.COM> Date: Tue, 29 Mar 94 16:42:13 +0100 From: Jon Crowcroft Status: O 1. Technical Criteria Draft: couple of typos c.f. page 19, under Time Scale - sentance does not parse ("is immidiately" page 27, the novel portmanteua "bothe" appears in place of the conventional both the page 29 - the word specifically is misspelled, and the phrase "trwat a tunneled" doesnt parse. on page 23, the multicast groups "up to 10**6", doesnt fit with the Time Warner vision Vision - if you want to run cable tv, and cover Live Aid, you need 10**9 recipients i na group - you probably also want 10**6 groups. I think that the _range_ of speeds is important as well as the higher speeds - it means that you need flexible protocols and very stable control algorithms (c.f. congestion ctl).o I think there should be a specific requirement for "testability" - it is possible to design protocols that apparently meet requirements but which are hard to implement in testable ways... 2. Tuba as IPng white paper i thought this was unclear, but couldn't specify i ndetail why. 3. On adding a flow spec to clnp - needs complete revision after the Int-Servoutput is available...afor isntance use of the soruce TSEL to give 256 independnet flows is just to simple, insecure, and too few...o 4. cable television induistry viewpoint this is excellent - the best contrib so far 5. HPN contribution this was also very good - the requirement for clock synch hooks was interesting - as was the extreme example of mobility ... one thing we might beware of is whether we want to combine this type of extreme mobility with the time warner vision of very large sclae multimedia? 6,. Multiprotocol Interop....from georgeia texh this was useful just in enumerating the understood interworking techniques availbe... 7. SIPP - i'm biiased so i'll say nothing 8. TUBA Transision this is based on the same idea as the OSI transisiotn in the UK - the use of context in nameservers to indicate what protocol stack a hosts' lookup was in (source and destination version/protocol versiosns) i prefer the previous ISO idea of end to end negotiation - like MTU discovery - a source shoul just start sending hughest ersion IP it supports, and an ICMP version unrecable, try this, error report will move it wn a version, or else it will timeout, and try a lower version til, when it succeeds, it caches the versio nfor use wit hther other host (and keeps the cache entry alive while conversastions persist, or unti la timeout similar to ARP...) 9. CERN paper on Engineering Considerations useful simple list of concerns 10. CATNIP the only really "unifying" approach - as an ex-phsysicist, i feel unifying approaches are holy grails, and not attainable (even to the Parsifal that is the IETF:-) - i don't believe you can do the header translations suggested, efficiently, or in a general bug free way (though I do believe you can do them...)o 11. Mark Pullens DSI input this is also very useful, in terms of big stressful systems - i was very impressed he didnt say ST-II once:-) 12. Electric Power Research this is frankly baloney - 13. implementation analysis this is useful except i dispute the assertion about confornmant APIs making recompiliation necessary for networked applications - forinstance, in programming languages like C (and C++) peoplke +_always_ workaround, nd get the return structure pointer from a gethostbyname() call, and just bcopy 4 bytes out of it....so you are just going to +have _ to recompile and probably mildyly fix a fairly large number of applicatiuons, or design the API (e.g. SIPP could quite easily use the low 4 bytes of a SIPP addr and add the rest as default...)o 14. Carpenters "on dynamica header translation considered harnful" depends - if the header translation is an innate iece of IOng, then it will be present at _all_ border gateways betewren IPng and IPv4 clouds so the config problem is non-problem. its clear to me that this also suggests that dynamic host config (plug and play) and mobility provide ways for intewrworking between IPng and IPv4 - we reserve some Ipv4 address space for 10 years past the IPng startup date - all IPng hosts must support IPv4 if they are to taslk to legacy hosts, but thwy must also support dynamic config of addresses, whether IPng or IUOv4 - so then to talk to an old site, you merely on demand get a IPv4 trasnsient address. assuming the number of IPv4 siters is _decreasing_ once IPng starts to be fielded, this is a scalable viable solution, and must also be a paret of the technology at least 2 of the requirements on IPng demand,. 15. the Boeing Usaers View. This is excellent - - it complkements the Time Warner view of technology, with the naive (in the good sense) requirement for simple application connectivity....- keepos our feet on the ground cheers jon p.s. sorry about the typos, but the 21 hps from seattly to london make it hard to drive a creen editor... From Greg_Minshall@Novell.COM Tue Mar 29 12:11:31 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA04306 for ; Tue, 29 Mar 1994 15:20:38 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA10818; Tue, 29 Mar 94 13:25:07 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06393; Tue, 29 Mar 94 12:11:31 PST Date: Tue, 29 Mar 94 12:11:31 PST Message-Id: <9403292011.AB06393@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jon Crowcroft From: Greg Minshall Subject: Re: Comments on White Papers so far... Cc: ipng mailing list Status: O Jon, >i prefer the previous ISO idea of end to end negotiation - like MTU >discovery - a source shoul just start sending hughest ersion IP it >supports, and an ICMP version unrecable, try this, error report >will move it wn a version, or else it will timeout, and try a lower >version til, when it succeeds, it caches the versio nfor use wit hther >other host (and keeps the cache entry alive while conversastions >persist, or unti la timeout similar to ARP...) Do IP implementations (i.e., does BSD) send back ICMP "version unreachable" messages? (Or, does the rawip handler get them? :) Greg From J.Crowcroft@cs.ucl.ac.uk Wed Mar 30 21:20:40 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA03305 for ; Wed, 30 Mar 1994 15:21:54 -0500 Message-Id: <199403302021.PAA03305@picard.cmf.nrl.navy.mil> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 30 Mar 1994 21:20:45 +0100 To: Greg Minshall cc: ipng mailing list Subject: Re: Comments on White Papers so far... In-reply-to: Your message of "Tue, 29 Mar 94 12:11:31 PST." <9403292011.AB06393@WC.Novell.COM> Date: Wed, 30 Mar 94 21:20:40 +0100 From: Jon Crowcroft Status: O >>will move it wn a version, or else it will timeout, and try a lower >>version til, when it succeeds, it caches the versio nfor use wit hther >>other host (and keeps the cache entry alive while conversastions >>persist, or unti la timeout similar to ARP...) >Do IP implementations (i.e., does BSD) send back ICMP "version unreachable" >messages? (Or, does the rawip handler get them? :) Greg it isn't the host that wil lreport this - if the host doesnt provide IPvn, then the last hop router in IPvn router world will report that the host on IPvn is unreachiable, at which point the source moves to IPvn-1. jon From jcurran@nic.near.net Thu Mar 31 06:32:31 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id GAA22326 for ; Thu, 31 Mar 1994 06:32:54 -0500 Received: from nic.near.net by nic.near.net id aa08578; 31 Mar 94 6:32 EST To: ipng@cmf.nrl.navy.mil cc: Big-Internet@munnari.oz.au Subject: Market viability for IPng Date: Thu, 31 Mar 1994 06:32:31 -0500 From: John Curran Message-ID: <9403310632.aa08578@nic.near.net> Status: O This is already submitted as an ID earlier this week, but I figured some folks wouldn't want to wait... /John p.s. Please excuse the rather rough format. --- Network Working Group J. Curran Internet draft BBN 25 March 1994 Market Viability as a IPng Criteria Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Introduction In an open marketplace, adoption of new technology is driven by consumer demand. New technologies that wish to succeed in the marketplace must provide new capabilities or reduced costs to gain consumer confidence. Internetworking technologies can be particularly difficult to deploy and must provide a correspondingly high return on investment. In order to determine market viability of new internetworking technology, it's necessary to compare the required deployment effort against the potential benefits as seen by the customer. "Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. Curran [Page 1] Internet draft IPng White Paper on Market Viability 25 March 1994 "Pushing" Internetworking Technology It has been asserted by some that the adoption of a single IPng protocol by the computing industry would generate general acceptance in the networking industry. There is ample evidence to support this view; for example, some of the today's more prevalent networking protocols gained initial market acceptance through bundling with computer operating systems (e.g. IP via UNIX, DECNET via VMS, etc.) It should be noted, however, that this approach to technology deployment is by no means assured, and some of today's most popular internetworking software (Novell, etc.) have thrived despite alternatives bundled by computing manufacturers. Given that IPng will have to compete against an well established and mature internetworking protocol (IP version 4), promotion of an IPng solution by computer system manufacturers should be recognized as highly desirable but not sufficient on its own to ensure IPng acceptance in the marketplace. Can IPng compete against IPv4? Given the large installed base of IPv4 systems, computer system manufacturers will need to continue to provide IPv4 capabilities for the foreseeable future. With both IPng and IPv4 support in their new systems, users will be facing a difficult choice between using IPv4 and IPng for internetworking. Existing IPv4 users will migrate to IPng for one of three possible reasons: New functionality not found in IPv4 IPng needs to provide functionality equivalent to that currently provided by IPv4. It remains to be seen whether additional functionality (such as resource reservation, mobility, autoconfiguration, autoregistration, or security) will be included in the base specification of any IPng candidate. In order to provide motivation to migrate to IPng, it will be necessary for IPng proposals to offer capabilities beyond those already provided IPv4. Reduced costs by using IPng It is quite unlikely that migration to IPng will result in cost savings in any organization. Migration to IPng will certainly result in an increased need for training and engineering, and hence increased costs. To gain connectivity to otherwise unreachable IPng hosts For existing sites with valid IPv4 network assignments, connectivity is not affected until address depletion occurs. Systems with globally-unique IPv4 addresses will have complete connectivity to any systems since backwards- compatible communication is required of new IPng hosts. Curran [Page 2] Internet draft IPng White Paper on Market Viability 25 March 1994 >From the perspective of an existing IPv4 site, IPng provides little tangible benefit until IPv4 address depletion occurs and organizations reachable only via IPng appear. Given the absence of benefits from migration, it is uncertain whether a significant base of IPng sites will be occur prior to IPv4 address depletion. Sites which are not yet running IP have little motivation to deploy IPng for the immediate future. As long as IPv4 network assignments are available, new sites have an choice to use IPv4 which provides the sufficient internetworking capabilities (measured in functionality, cost, and connectivity) for many organizations today. Given the parity in IPng and IPv4 capabilities, IPv4 (as a more mature internetworking protocol) is the more probable choice for organizations just now selecting an internetworking protocol. Once IPv4 address assignments are no longer available, sites wishing to participate in the global Internet will have a very difficult decision in selection of an internetworking protocol. The current suite of IPng proposals cannot provide complete internetworking between IPng-only sites and IPv4-only sites since (by definition) there will be insufficient space to map all IPng addresses into the IPv4 address space. As none of the proposals currently call for dynamic network address translation (NAT), it is inevitable that IPng-only sites will have access to a partial set of IPv4 sites at any given moment. Internetworking services which do not allow complete access to the global Internet (IPv4 and IPng in the post-IPv4-address-depletion world) are clearly not as valuable as services which offer complete Internet access. Sites which are unable to obtain IPv4 network assignments will be seeking Internet services which can provide complete Internet service. Additionally, some sites will have "privately numbered" IPv4 networks and will desire similar Internet services which provide transparent access to the entire Internet. The development of network address translation devices and subsequent services is highly likely under these market conditions. Summary No internetworking vendor (whether host, router, or service vendor) can afford to deploy and support products and services which are not desired in the marketplace. Given the potential proliferation of network address translation devices, it is not clear that IPng will secure sufficient following to attain market viability. In the past, we have seen internetworking protocols fail in the marketplace despite vendor deployment and IPng cannot succeed if it is not deployed by organizations. As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices. In order to meet the requirement for "viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred. Curran [Page 3] Internet draft IPng White Paper on Market Viability 25 March 1994 Author's Address John Curran BBN Technology Services, Inc. 10 Moulton Street Cambridge MA 02138 jcurran@near.net From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 06:32:31 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id HAA22448 for ; Thu, 31 Mar 1994 07:28:07 -0500 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA29066; Thu, 31 Mar 1994 21:40:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA29029; Thu, 31 Mar 1994 21:31:47 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24511; Thu, 31 Mar 1994 21:32:57 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa08578; 31 Mar 94 6:32 EST To: ipng@cmf.nrl.navy.mil Cc: Big-Internet@munnari.OZ.AU Subject: Market viability for IPng Date: Thu, 31 Mar 1994 06:32:31 -0500 From: John Curran Message-Id: <9403310632.aa08578@nic.near.net> Status: O This is already submitted as an ID earlier this week, but I figured some folks wouldn't want to wait... /John p.s. Please excuse the rather rough format. --- Network Working Group J. Curran Internet draft BBN 25 March 1994 Market Viability as a IPng Criteria Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Introduction In an open marketplace, adoption of new technology is driven by consumer demand. New technologies that wish to succeed in the marketplace must provide new capabilities or reduced costs to gain consumer confidence. Internetworking technologies can be particularly difficult to deploy and must provide a correspondingly high return on investment. In order to determine market viability of new internetworking technology, it's necessary to compare the required deployment effort against the potential benefits as seen by the customer. "Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. Curran [Page 1] Internet draft IPng White Paper on Market Viability 25 March 1994 "Pushing" Internetworking Technology It has been asserted by some that the adoption of a single IPng protocol by the computing industry would generate general acceptance in the networking industry. There is ample evidence to support this view; for example, some of the today's more prevalent networking protocols gained initial market acceptance through bundling with computer operating systems (e.g. IP via UNIX, DECNET via VMS, etc.) It should be noted, however, that this approach to technology deployment is by no means assured, and some of today's most popular internetworking software (Novell, etc.) have thrived despite alternatives bundled by computing manufacturers. Given that IPng will have to compete against an well established and mature internetworking protocol (IP version 4), promotion of an IPng solution by computer system manufacturers should be recognized as highly desirable but not sufficient on its own to ensure IPng acceptance in the marketplace. Can IPng compete against IPv4? Given the large installed base of IPv4 systems, computer system manufacturers will need to continue to provide IPv4 capabilities for the foreseeable future. With both IPng and IPv4 support in their new systems, users will be facing a difficult choice between using IPv4 and IPng for internetworking. Existing IPv4 users will migrate to IPng for one of three possible reasons: New functionality not found in IPv4 IPng needs to provide functionality equivalent to that currently provided by IPv4. It remains to be seen whether additional functionality (such as resource reservation, mobility, autoconfiguration, autoregistration, or security) will be included in the base specification of any IPng candidate. In order to provide motivation to migrate to IPng, it will be necessary for IPng proposals to offer capabilities beyond those already provided IPv4. Reduced costs by using IPng It is quite unlikely that migration to IPng will result in cost savings in any organization. Migration to IPng will certainly result in an increased need for training and engineering, and hence increased costs. To gain connectivity to otherwise unreachable IPng hosts For existing sites with valid IPv4 network assignments, connectivity is not affected until address depletion occurs. Systems with globally-unique IPv4 addresses will have complete connectivity to any systems since backwards- compatible communication is required of new IPng hosts. Curran [Page 2] Internet draft IPng White Paper on Market Viability 25 March 1994 >From the perspective of an existing IPv4 site, IPng provides little tangible benefit until IPv4 address depletion occurs and organizations reachable only via IPng appear. Given the absence of benefits from migration, it is uncertain whether a significant base of IPng sites will be occur prior to IPv4 address depletion. Sites which are not yet running IP have little motivation to deploy IPng for the immediate future. As long as IPv4 network assignments are available, new sites have an choice to use IPv4 which provides the sufficient internetworking capabilities (measured in functionality, cost, and connectivity) for many organizations today. Given the parity in IPng and IPv4 capabilities, IPv4 (as a more mature internetworking protocol) is the more probable choice for organizations just now selecting an internetworking protocol. Once IPv4 address assignments are no longer available, sites wishing to participate in the global Internet will have a very difficult decision in selection of an internetworking protocol. The current suite of IPng proposals cannot provide complete internetworking between IPng-only sites and IPv4-only sites since (by definition) there will be insufficient space to map all IPng addresses into the IPv4 address space. As none of the proposals currently call for dynamic network address translation (NAT), it is inevitable that IPng-only sites will have access to a partial set of IPv4 sites at any given moment. Internetworking services which do not allow complete access to the global Internet (IPv4 and IPng in the post-IPv4-address-depletion world) are clearly not as valuable as services which offer complete Internet access. Sites which are unable to obtain IPv4 network assignments will be seeking Internet services which can provide complete Internet service. Additionally, some sites will have "privately numbered" IPv4 networks and will desire similar Internet services which provide transparent access to the entire Internet. The development of network address translation devices and subsequent services is highly likely under these market conditions. Summary No internetworking vendor (whether host, router, or service vendor) can afford to deploy and support products and services which are not desired in the marketplace. Given the potential proliferation of network address translation devices, it is not clear that IPng will secure sufficient following to attain market viability. In the past, we have seen internetworking protocols fail in the marketplace despite vendor deployment and IPng cannot succeed if it is not deployed by organizations. As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices. In order to meet the requirement for "viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred. Curran [Page 3] Internet draft IPng White Paper on Market Viability 25 March 1994 Author's Address John Curran BBN Technology Services, Inc. 10 Moulton Street Cambridge MA 02138 jcurran@near.net From J.Crowcroft@cs.ucl.ac.uk Thu Mar 31 21:43:02 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA26521 for ; Thu, 31 Mar 1994 15:43:23 -0500 Message-Id: <199403312043.PAA26521@picard.cmf.nrl.navy.mil> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 Mar 1994 21:43:06 +0100 To: ipng@cmf.nrl.navy.mil Subject: Summary of European RTDNET Backbone requirements Date: Thu, 31 Mar 94 21:43:02 +0100 From: Jon Crowcroft Status: O the attached messages may be of itnerest for their requirements... ------- Forwarded Messages Return-Path: Received: from sapling.surfnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 31 Mar 1994 18:41:45 +0100 X400-Received: by mta sapling.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:41:25 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:27:19 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:27:02 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:26:57 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:26:43 +0200 Date: Thu, 31 Mar 1994 19:26:43 +0200 X400-Originator: rtdnet-forum-request@nl.rare X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;<9403311726.AA09158@dante.org.uk] X400-Content-Type: P2-1984 (2) Content-Identifier: Summary of Ba... From: " (Dai Davies)" Sender: rtdnet-forum-request@nl.rare Message-ID: <9403311726.AA09158@dante.org.uk> To: rtdnet-forum@nl.rare Cc: dai@uk.org.dante, sho@be.cec.dg13, mgri@be.cec.dg13 Subject: Summary of Backbone network results 1 X-Sender: dai@sun Content-Length: 15557 The backbone network panel members have extended the contributions made at the working meetings. I have edited and combined these to form the basis of discussions at the next Meeting. They are being sent to the RTDNet forum for wider information and comment This set of Contributions deal with issues surrounding the Implementation of the backbone both from an Implementation and pilot experimentation perspective. There has been a debate about whether we are talking about a single or multiple backbones. The requirements here do not take a position on implementation per-se. They do recognise the need to interwork with what exists today and allow the potential for High performnance operational serrvice to co-exist with one another. No position on the commercial implications of this work. Please note that the following information is being made public to stimulate discussion, in the preparation of the work programme for Telematics for Research, under the EC Fourth Framework Programme. It is assembled by the Rapporteur. The European Commission makes no commitment to incorporate any part of the information into future calls for proposals; neither is the European Commission responsible for any use to which the information is put. 1 Planning implications of interconnecting with existing networks User Requirements There is a range of user requirements for the high performance backbone inclding piloting new applications, dealing with the aggregate demand from existing, applications, pilotting the new backbone itself and routine use of the new high performanec applications by the broad range of the European reserach community. In this context inter-connection with existing networks has to be an important work item of any developments. It has both commercial and technical implications Even in a pilot project phase users will not accept degradation concerning their actual levels of service quality and full connectivity. Planning will have to cope with the interconnection of existing networks problems and needs tio address this question on a global scale. Objectives To define plans for the the integration of current networking facilities with the new high performnace backbone taking inot account geographic scope, the distinction between "pilot" and "service" networks and the need to maintain and enhance quality of service. Approach - -QOS needs to be guaranteed from END user to END user. Both the Backbone and the connected networks are concerned. Transparency to the user should be guaranteed. - -Rules, rule-sets are needed regarding common use policies. Are research 'for profit' organisations allowed in the programme ? - -Standards are needed regarding global issues such as network management, quality of service, experiments with potential standards, market proven..... - -To ensure full connectivity the Backbone and traffic interchange should be sufficiently open. Monopolistic situations have to be avoided. - -Fair schemes for cost allocation to the different networks using the Backbone infrastructure need to be defined. 2 Development of criteria for success in backbone piloting activities Interactions with other areas - ----------------------------- This area interlinks with: charging - one criterion of success is (may be) that services should still be viable when charged at eventual commercial rates migration to operational service - another criterion of success is (may be) that services should successfully make this transition quality of service - ability to meet defined Q-O-S goals, and hence a requirement to be able to measure delivered quality of service, are central to the success of operational services user support - subjective evaluation of services by the user community is an important component of overall evaluations in all backbone areas project management - the gathering of data, monitoring and reporting of progress which are required for project evaluation are management roles Rationale - --------------- Telematics for RTD is a technically demanding area and directions will change during the programme. The project guidelines foresee this as 'iterations' in the project plans, and input to that process is required. Further, the Telematics for RTD imperatives require that technical validation of projects be carried out by some process. Objectives - ---------------- The criteria for success adopted for any individual pilot infrastructure activity must be such as to provide feedback to sponsors, participants and others on the effectiveness of that part of the 4th framework programme. The criteria listed for an activity should be sufficiently concrete to provide objectives for project participants. Technical Approach - ------------------------ 1) 'Success' must be defined in explicit and concrete terms for each proposed infrastructure project. It will be necessary to establish a working group to set a standard practice for pilot projects to be carried out under this programme. Suitable inputs for gauging success will be: a) Subjective criteria - based on the reactions of users/participants/sponsors. 'Users' is not a preordained group in this context, implying merely the group or community which is supposed to benefit from the implementation of the particular pilot. This may consist of (groups of) end users, research computing centres, research network operators or backbone network operators. The approach should be to weigh the reactions of users more heavily than others in assessing the subjective success of pilot projects. It may not be necessary to gauge the reaction of sponsors (EC?) at all, depending on established practice. A convenient methodology is to ask for scores on a 5-point scale from the evaluation groups, and to weight the scores (e.g.) 80-20 in favour of the user ratings. Pilot projects should always be required to define their target community (-ies). In some cases, where a pilot project is considered advisable for technical reasons but has no obvious or appropriate user community (e.g. level of demand is insufficient to adequately exercise some new technology), it may be necessary to *construct* an application group or project to provide on-going verification for the pilot. It may be further advisable that a proposed sample of the target group should be involved in the pilot planning, even to the extent of requiring endorsement from such a group as a precondition of acceptance. b) Objective criteria - based on measurement or evidence Objective project characteristics may be performance-related (requiring measurement procedures for the parameters - such as rates, availabilities etc. - which are targeted); or may be sub-goal- related (requiring verification of deliverable services, milestones, procedures or attributes). One important category of objective criteria consists of the planned implementation time-scale, against which subsequent progress may be judged. One consequence of the early lack of sophistication which the network infrastructure is likely to exhibit is that it may be difficult to gather some kinds of statistics on network performance and behaviour. Objectives should therefore, where possible, be of such a natur