From brian@dxcoms.cern.ch Tue Feb 15 11:39:33 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id GAA02387 for ; Tue, 15 Feb 1994 06:34:49 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06338; Tue, 15 Feb 1994 12:34:17 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05029; Tue, 15 Feb 1994 11:39:33 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402151039.AA05029@dxcoms.cern.ch> Subject: The way ahead? To: ipng@cmf.nrl.navy.mil Date: Tue, 15 Feb 1994 11:39:33 +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: 1020 I was thinking of three possible ways ahead for IPng. (This message is intended to be a bit provocative.) 1. The requirements RFC is produced. We reach consensus that proposal X is the best match; proposals Y and Z are dropped; proposal X is enhanced to satisfy all requirements (and maybe to drop unnecessary frills). 2. The requirements RFC is produced. We reach consensus that no proposal is good enough to be accepted, and we launch a call for new or radically enhanced proposals. 3. The requirements RFC is produced. We lock Steve, Bob, Paul, Robert, Mark and Peter in a room with a portable but no Internet connection, and don't let them out till they have written the STUBNIPP proposal. STUBNIPP is the combination of SIPP, TUBA and CATNIP. It looks like a camel. Camels are ugly, bad tempered, but very good at crossing deserts. IMHO the first option is clearly ideal but I wonder whether we shouldn't think a little bit about the third one. The second one would not make the industry wildly happy. Brian From bound@zk3.dec.com Tue Feb 15 07:54:30 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.4/8.6.4) with SMTP id IAA02978 for ; Tue, 15 Feb 1994 08:36:10 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA29099; Tue, 15 Feb 94 04:55:37 -0800 Received: by xirtlu.zk3.dec.com; id AA29998; Tue, 15 Feb 1994 07:54:36 -0500 Message-Id: <9402151254.AA29998@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: white papers In-Reply-To: Your message of "Mon, 14 Feb 94 21:50:31 EST." <9402150250.AA13923@hsdndev.harvard.edu> Date: Tue, 15 Feb 94 07:54:30 -0500 X-Mts: smtp Directorate, I will review the following: 08 EPRI EPRI Electric Power Research Institute Response to RFC 1550 04 Green, Dan, et al Navy HPN WG HPN Working Group Input to the IPng Requirements Solicitation 03 Vecchi, Mario P. Time Warner Cable IPng Requirements: a cable television industry viewpoint /jim From bound@zk3.dec.com Tue Feb 15 08:04:19 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.4/8.6.4) with SMTP id IAA02998 for ; Tue, 15 Feb 1994 08:39:23 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA29498; Tue, 15 Feb 94 05:04:32 -0800 Received: by xirtlu.zk3.dec.com; id AA00359; Tue, 15 Feb 1994 08:04:25 -0500 Message-Id: <9402151304.AA00359@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: The way ahead? In-Reply-To: Your message of "Tue, 15 Feb 94 11:39:33 +0100." <9402151039.AA05029@dxcoms.cern.ch> Date: Tue, 15 Feb 94 08:04:19 -0500 X-Mts: smtp Brian, I think your third solution might be necessary too. But, if we are to reach the first I think we need to figure out what John Curran and I asked about on the telechat. Which is how are conflicts resolved. Especially technical ones. I think we need to spend time on this in the next telechat if it can be more than philosophizing about infinity. Also I am not interested in saving political face of any proposal when one of them will work. The others just loose. If I thought as a Directorate member that the best proposal was not being put forth to save face on the other ones to appease the needs of not picking one proposal I would have to object ethically. /jim From ddc@caraway.lcs.mit.edu Tue Feb 15 14:56:14 1994 Return-Path: ddc@caraway.lcs.mit.edu Received: from caraway.lcs.mit.edu (CARAWAY.LCS.MIT.EDU [18.26.0.170]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA07163 for ; Tue, 15 Feb 1994 14:56:27 -0500 Received: by caraway.lcs.mit.edu id AA02961; Tue, 15 Feb 94 14:56:14 -0500 Message-Id: <9402151956.AA02961@caraway.lcs.mit.edu> To: Scott Bradner Cc: ipng@cmf.nrl.navy.mil Subject: Re: draft response to the FIRP In-Reply-To: Your message of Tue, 15 Feb 94 11:21:57 -0500. <9402151621.AA06446@hsdndev.harvard.edu> From: David Clark Date: Tue, 15 Feb 94 14:56:14 -0500 Sender: ddc@caraway.lcs.mit.edu X-Mts: smtp My only thought about the letter, which I very much like, is that in the last paragraph you might want to explicitly mention that we would like to invite NIST to join in the process of review of our deliberation. I am not sure about this, and I really offer it as a suggestion for discussion. (?) This letter is to Nakassis, but we could also send it to the director, as Vint did with his (he sent a cover letter to Prabhakar with the real letter as an atttachment.) Dave From brian@dxcoms.cern.ch Tue Feb 15 22:05:15 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA08121 for ; Tue, 15 Feb 1994 16:05:50 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16756; Tue, 15 Feb 1994 22:05:17 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA23666; Tue, 15 Feb 1994 22:05:15 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402152105.AA23666@dxcoms.cern.ch> Subject: Re: draft response to the FIRP To: ipng@cmf.nrl.navy.mil Date: Tue, 15 Feb 1994 22:05:15 +0100 (MET) In-Reply-To: <9402151621.AA06446@hsdndev.harvard.edu> from "Scott Bradner" at Feb 15, 94 11:21:57 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 604 ... > involved in the use and development of data networks. The directorate > includes personnel from router manufacturers, personal computer software > firms, industrial research organizations, telecommunications companies, > computer manufacturers, U.S. government and education, and international > governments. > I won't comment on the letter since it is a US internal affair, but neither I nor Daniel work for an international government. (If I did, I would fix OSI, Bosnia, and a few other problems PDQ :-) Say "international organizations" and that covers both CERN and RIPE I guess. Brian From bound@zk3.dec.com Tue Feb 15 16:59:30 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.4/8.6.4) with SMTP id SAA09983 for ; Tue, 15 Feb 1994 18:53:32 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA25840; Tue, 15 Feb 94 13:59:40 -0800 Received: by xirtlu.zk3.dec.com; id AA19717; Tue, 15 Feb 1994 16:59:37 -0500 Message-Id: <9402152159.AA19717@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: draft response to the FIRP In-Reply-To: Your message of "Tue, 15 Feb 94 11:21:57 EST." <9402151621.AA06446@hsdndev.harvard.edu> Date: Tue, 15 Feb 94 16:59:30 -0500 X-Mts: smtp Scott, I think you and Allison did well with the memo. I am not sure what we do with IPng should effect OSI one way or the other. The Air Traffic Control systems being built right now with OSI are not dependent on IPng or the Internet and I am not sure they should be. A question I am not sure how to ask when I read it was: did the memo make it perfectly clear we are working on an IPv4 replacement? I think so. Regarding Dave's mention of NIST being in the loop. I think as an external source just like the PTTs, or Pacific RIM consortia is aays welcome as White Paper input, but I don't think we want to have a U.S. government bodyas anymore than external input to keep the process open internationally, as seen by the international public. /jim From bound@zk3.dec.com Tue Feb 15 17:29:48 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.4/8.6.4) with SMTP id SAA09737 for ; Tue, 15 Feb 1994 18:01:05 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA27198; Tue, 15 Feb 94 14:29:57 -0800 Received: by xirtlu.zk3.dec.com; id AA20884; Tue, 15 Feb 1994 17:29:54 -0500 Message-Id: <9402152229.AA20884@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: ISOC Response to FIRP if you did not get that mail ... Date: Tue, 15 Feb 94 17:29:48 -0500 X-Mts: smtp ------- Forwarded Message Return-Path: isoc-sender@isoc.org Received: by wasted.zk3.dec.com; id AA21872; Tue, 15 Feb 1994 17:22:53 -0500 Received: from ietf.cnri.reston.va.us by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA01650; Tue, 15 Feb 1994 17:22:49 -0500 Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07397; 15 Feb 94 11:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06846; 15 Feb 94 11:15 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10837; 15 Feb 94 11:13 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06805; 15 Feb 94 11:13 EST To: firp-comments@osi.ncsl.nist.gov Cc: fnc@fnc.gov, fncac@fnc.gov, iab@isi.edu, ietf@CNRI.Reston.VA.US, internauts:;@decvax.dec.com;;;;;; ;, XIWT:;@decvax.dec.com;;;;;; ; Subject: Internet Society comments on the Federal Internet Requirements Panel Report Date: Tue, 15 Feb 94 11:13:19 -0500 Sender: isoc-sender@isoc.org From: "Vinton G. Cerf" Message-Id: <9402151113.aa06805@IETF.CNRI.Reston.VA.US> 18 Feb 94 Dr. Arati Prabhakar Director, National Institutes of Standards and Technology Administration Building, 11th Floor Gaithersburg, MD 20899 Dear Dr. Prabhakar: As you are no doubt aware, the development of Internet Standards takes place under the auspices of the Internet Society and is carried out by the Internet Engineering Task Force under the management of the Internet Engineering Steering Group with oversight by the Internet Architecture Board. A secretariat for the Internet Engineering Task Force is operated by the Corporation for National Research Initiatives (CNRI) with support from the Internet Society and from the Advanced Research Projects Agency, the Department of Energy, the National Aeronautics and Space Administration and the National Science Foundation. The work of the U.S. Federal Internetworking Requirements Panel is of vital interest to the Internet Society members. On behalf of the chairmen of the Internet Architecture Board and Internet Engineering Steering Group, I am pleased to forward to you their comments on the Panel's report. Sincerely, Vinton G. Cerf President Internet Society VCERF@ISOC.ORG CC: Distribution List - ----------------------------------------------------------- Chief, Systems and Network Architecture Division National Institutes of Standards and Technology Gaithersburg, MD ATTN: Draft of FIRP Report Dear Sir/Madam: The Internet Architecture Board and Internet Engineering Steering Group compliment the U.S. Federal Internetworking Requirements Panel on its draft report. As the panel points out, the Internet and the associated Internet Protocol Suite have become an important part of national and global information infrastructures. Assuring that the United States Government can continue to play a productive role in evolving this infrastructure for both its own use and for national and global purposes requires the kind of systematic and pragmatic view advocated in this report. The report raises several important issues. Independent of this letter, we expect that individual members of the Internet Community at large will have comments they will make directly to you. We would like to take this opportunity, though, to comment on several of the higher-level issues raised. 1. Security The report correctly points out that there are a number of unresolved security concerns that impede the full use of networking to achieve the goals of the U.S. Government. These issues transcend the specific protocol suite in use. We are fully aware of these issues and will continue to address this important area through various community processes including , but not limited to, ISOC and IAB- sponsored workshops, IESG area directorate activities, and IETF working groups. For example, ISOC sponsored a general workshop this year on network and distributed system security in early February, and the IAB sponsored a special workshop in this same month to investigate issues related to the evolution of the Internet and its technology. One specific set of concerns addressed in the latter workshop is the relationship between potential approaches to security requirements and proposed approached to routing, addressing and mobility. The results of this Workshop will be made available in oral form at the next meeting of the IETF in Seattle, WA, in late March, and will be available in a written report shortly thereafter. We would be pleased to meet in addition with members of the FIRP and other U.S. Government officials to discuss the results of the IAB workshop as well as other ongoing work in the IETF and what specific actions might be taken to further address these security concerns. 2. Internet Standards Process When the Internet Activities Board (the precursor to the Internet Engineering Task force and Internet Architecture Board) was first formed, it was for the purpose of assisting in coordinating the ARPA research activities in internetworking. It was therefore appropriate in those early years that the process be rather informal. As the Internet has grown, and become a more operational infrastructure, the IAB/IETF has also evolved to respond to changing requirements, in part by developing a process for dealing with protocol agreements (standards) required by the growing industry and user communities. The report correctly points out that the IETF standards process (more properly, the Internet Standards process) has its roots in an informal consensus process. This has been a strength through its emphasis on working code prior to standardization and its ability to adapt rapidly to changing community requirements. However, these aspects of the Internet Standards process have also resulted in the perception that the process lacks formal mechanisms for achieving fair and open hearing and consensus balance among all interested parties. We are cognizant of the concerns raised in the report for well-documented and demonstrably fair procedures. The IETF and its associated bodies and processes have undergone many changes over the last decade in response to changing needs. We have recently devoted considerable effort to formal documentation of the Internet Standards process and of the procedures to be followed by the IETF working groups. This process includes rigorous requirements for review and recourse. We believe that we have been successful at achieving a process that both assures balance among interested parties and also preserves the fundamental nature of an open consensus-making approach to standards development. We are actively engaged in fully reviewing and documenting these procedures, including attention to concerns for fairness, openness, accountability and protection against restraint of trade. A major topic of the report is the relation between the Internet Protocol Suite and the Open Systems Interconnection (OSI) protocols. The report correctly points out that the issue is not so much a choice between them as the selection of the best and most appropriate combination of protocols for each application. The Internet currently makes use of protocols from both suites (e.g. use of X.500 certificate syntax for public key management in support of privacy-enhanced mail) and we expect this practice to continue. In addition, we are exploring mechanisms to achieve improved and enhanced communications and coordination with the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU) to maximize information flow between our organizations. In summary, we again applaud the directions recommended in the draft FIRP report that will allow the United States Government to fully and cost-effectively take advantage of the widespread use of the Internet Protocol Suite and to participate in the evolution of internetworking. We look forward to working with agencies of the U.S. and other Governments to move forward in these directions. Sincerely yours, Dr. Christian Huitema Chairman, Internet Architecture Board Mr. Phillip Gross Chairman, Internet Engineering Steering Group ------- End of Forwarded Message From jcurran@nic.near.net Tue Feb 15 21:45:25 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.4/8.6.4) with SMTP id VAA10832 for ; Tue, 15 Feb 1994 21:45:30 -0500 Message-Id: <199402160245.VAA10832@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa07584; 15 Feb 94 21:45 EST To: Scott Bradner cc: ipng@cmf.nrl.navy.mil Subject: Re: white papers In-reply-to: Your message of Mon, 14 Feb 1994 21:50:31 -0500. <9402150250.AA13923@hsdndev.harvard.edu> Date: Tue, 15 Feb 1994 21:45:25 -0500 From: John Curran -------- ] From: Scott Bradner ] Subject: white papers ] Date: Mon, 14 Feb 94 21:50:31 -0500 ] I'll send mine in, and then perform a clarity review on: ] 01 Clark, Russ, et Georgia Tech ] Multiprotocol Interoperability In IPng ] 12 Hinden, Robert Sipp ] Simple Internet Protocol Plus White Pape ] 03 Vecchi, Mario P. Time Warner Cable ] IPng Requirements: a cable television industry viewpoint /John From rcallon@wellfleet.com Thu Feb 17 11:17:38 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA08196 for ; Thu, 17 Feb 1994 11:12:55 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20558; Thu, 17 Feb 94 10:56:43 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA19832; Thu, 17 Feb 94 11:06:46 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA23492; Thu, 17 Feb 94 11:17:38 EST Date: Thu, 17 Feb 94 11:17:38 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9402171617.AA23492@cabernet.wellfleet> To: ipng@cmf.nrl.navy.mil, jkrey@isi.edu, postel@isi.edu Subject: Local IP addresses Cc: rcallon@wellfleet.com We are getting increased customer requests for local IP addresses ("at least a couple of class B's"). Some user sites are thinking of just picking a couple of addresses at random and start using them unless some local IP addresses are "officially" assigned. Obviously future chaos could occur (or at least some problems) if folks grab some unassigned address as random and start using it as a local address, only to have the same address officially assigned to a different site later in time. Naturally this is motivated by the IP address space issue, and the perceived growing scarcity of IP addresses. Jon, Joyce: Are you familiar with this issue, or should we send a better description to you? Would it make sense to assign a few addresses and let customers who are agitating for this to go ahead, but not widely publicise it until we have an agreed document to publish along with the local address assignments? Yakov has a nearly complete paper on the subject (which I think may be partially based on my rough notes from a while back). Ross From postel@ISI.EDU Thu Feb 17 08:51:00 1994 Return-Path: postel@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA08457 for ; Thu, 17 Feb 1994 11:51:29 -0500 Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 17 Feb 1994 08:51:00 -0800 Date: Thu, 17 Feb 1994 08:51:00 -0800 From: postel@ISI.EDU (Jon Postel) Message-Id: <199402171651.AA21434@zephyr.isi.edu> To: rcallon@wellfleet.com Subject: Re: Local IP addresses Cc: ipng@cmf.nrl.navy.mil, iana@ISI.EDU, Daniel.Karrenberg@ripe.net Ross: Yes we are very familiar with this issue. the Memo (started by Yakov and Bob Moskowitz) is progressing and is now in Daniel Karrenberg's hands (or maybe in his powerbook). Given the move to "classless" addressing with CIDR it may be more appropriate to allocate a large block of "class C" space to be used for non-connected networks (rather than a class B or two). I'd rather not pick the addresses till the memo is ready. There are number of warnings about the downside risks of doing this that should be associated with it. --jon. Date: Thu, 17 Feb 94 11:17:38 EST From: rcallon@wellfleet.com (Ross Callon) To: ipng@cmf.nrl.navy.mil, jkrey@ISI.EDU, postel@ISI.EDU Subject: Local IP addresses Cc: rcallon@wellfleet.com We are getting increased customer requests for local IP addresses ("at least a couple of class B's"). Some user sites are thinking of just picking a couple of addresses at random and start using them unless some local IP addresses are "officially" assigned. Obviously future chaos could occur (or at least some problems) if folks grab some unassigned address as random and start using it as a local address, only to have the same address officially assigned to a different site later in time. Naturally this is motivated by the IP address space issue, and the perceived growing scarcity of IP addresses. Jon, Joyce: Are you familiar with this issue, or should we send a better description to you? Would it make sense to assign a few addresses and let customers who are agitating for this to go ahead, but not widely publicise it until we have an agreed document to publish along with the local address assignments? Yakov has a nearly complete paper on the subject (which I think may be partially based on my rough notes from a while back). Ross From bound@zk3.dec.com Thu Feb 17 12:02:55 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA08633 for ; Thu, 17 Feb 1994 12:09:25 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA29123; Thu, 17 Feb 94 09:03:06 -0800 Received: by xirtlu.zk3.dec.com; id AA08697; Thu, 17 Feb 1994 12:03:01 -0500 Message-Id: <9402171703.AA08697@xirtlu.zk3.dec.com> To: postel@ISI.EDU (Jon Postel) Cc: rcallon@wellfleet.com, ipng@cmf.nrl.navy.mil, iana@ISI.EDU, Daniel.Karrenberg@ripe.net, bound@zk3.dec.com Subject: Re: Local IP addresses In-Reply-To: Your message of "Thu, 17 Feb 94 08:51:00 PST." <199402171651.AA21434@zephyr.isi.edu> Date: Thu, 17 Feb 94 12:02:55 -0500 X-Mts: smtp Jon, >I'd rather not pick the addresses till the memo is ready. There are >number of warnings about the downside risks of doing this that should >be associated with it. Could you maybe also run this by Steve Bellovin too at AT&T who has expressed some security concerns in this area during our IPng Directorate discussions. thanks /jim From rcallon@wellfleet.com Thu Feb 17 14:21:44 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA11262 for ; Thu, 17 Feb 1994 14:18:39 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22504; Thu, 17 Feb 94 14:00:49 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA23751; Thu, 17 Feb 94 14:10:53 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA23619; Thu, 17 Feb 94 14:21:44 EST Date: Thu, 17 Feb 94 14:21:44 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9402171921.AA23619@cabernet.wellfleet> To: postel@ISI.EDU Subject: Re: Local IP addresses Cc: Daniel.Karrenberg@ripe.net, iana@ISI.EDU, ipng@cmf.nrl.navy.mil Yes we are very familiar with this issue. the Memo (started by Yakov and Bob Moskowitz) is progressing and is now in Daniel Karrenberg's hands (or maybe in his powerbook). Great. Yakov sent me an updated copy this morning. Generally it looks very good (I had a few nit comments which I sent to Yakov). Given the move to "classless" addressing with CIDR it may be more appropriate to allocate a large block of "class C" space to be used for non-connected networks (rather than a class B or two). The one case where a few B's would be useful would be a corporation with several large sites, which was running BGP-3 (or EGP) between sites and didn't want to upgrade to BGP-4, and preferred to aggregate inter-site information. On the other hand, there are probably at least as many companies which have large numbers of small sites, also want to run BGP-3, and thus need a larger number of C's (If folks are running BGP-4, it doesn't seem to make any difference whether there is a small number of B's or a larger number of C's). This seems to imply that a large block of C's (as you suggest) is more flexible than a smaller block of B's, but that both would be slightly more flexible still. I guess there is a tradeoff here versus how much of the address space we want to use for this purpose. I'd rather not pick the addresses till the memo is ready. There are number of warnings about the downside risks of doing this that should be associated with it. This is a good point. Hopefully it should not take too long to get the draft finished. Ross From ericf@atc.boeing.com Thu Feb 17 13:11:04 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA12286 for ; Thu, 17 Feb 1994 16:10:05 -0500 Received: by atc.boeing.com (5.57) id AA11956; Thu, 17 Feb 94 13:11:04 -0800 Date: Thu, 17 Feb 94 13:11:04 -0800 From: Eric Fleischman Message-Id: <9402172111.AA11956@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, jkrey@isi.edu, postel@isi.edu, rcallon@wellfleet.com Subject: Re: Local IP addresses Cc: eek, ericf, xrjo Concerning Local Addresses: The purpose of this note is to emphasize (and expand upon) Ross Callon's public Email message to Jon and Joyce (which is copied in its entirety below): The Boeing Company is very interested in obtaining Class B network numbers to be used as "Local Addresses". I have spoken to Jon privately about this at the Houston IETF and this topic prominently figures within a section of my IPng white-paper which is entitled "A User's View of IPng". This white paper is a formal position statement of The Boeing Company. The reference within the white paper specifically asks for 12 Class B addresses to be designated at "Local Addresses". [Note: Local addresses are network numbers which are not unique within the Internet but are unique within a specific domain (e.g., a corporation). These addresses, therefore, are not to be seen outside of that domain (i.e., over the Internet).] In addition, we note an independent request from Bob Moscowitz (Chrysler) and Yakov Rekhter (IBM) for a combination of Class A, B, and C addresses to be so designated as "Local Addresses". Boeing would also be interested in that possibility as well. In any case, my white paper addresses WHY end users such as Boeing are interested in "Local Addresses". This need is largely independent from the IP address depletion problem except for the possibility that the adoption of "Local Addresses" may somewhat delay "IP address depletion" for the Internet as a whole. In any case, I strongly suggest that the need for "Local Addresses" represents a genuine end-user requirement and that Ross' question >assign a few addresses and let customers who are agitating >for this to go ahead, but not widely publicise it until we >have an agreed document to publish along with the local >address assignments? needs to be answered by a well publicized, official response designating a significant range of network numbers (e.g., 12 Class B's) to officially become "Local Addresses". Thank you for your attention on this matter. Sincerely yours, --Eric Fleischman BCS Network Architect >From: rcallon@wellfleet.com (Ross Callon) >We are getting increased customer requests for local IP >addresses ("at least a couple of class B's"). Some user >sites are thinking of just picking a couple of addresses at >random and start using them unless some local IP addresses >are "officially" assigned. Obviously future chaos could occur >(or at least some problems) if folks grab some unassigned >address as random and start using it as a local address, only >to have the same address officially assigned to a different >site later in time. Naturally this is motivated by the IP >address space issue, and the perceived growing scarcity of >IP addresses. > >Jon, Joyce: Are you familiar with this issue, or should we >send a better description to you? Would it make sense to >assign a few addresses and let customers who are agitating >for this to go ahead, but not widely publicise it until we >have an agreed document to publish along with the local >address assignments? > >Yakov has a nearly complete paper on the subject (which I >think may be partially based on my rough notes from a while >back). > >Ross From mankin Thu Feb 17 16:14:40 1994 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA12295; Thu, 17 Feb 1994 16:14:44 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA00381; Thu, 17 Feb 94 16:14:40 EST Date: Thu, 17 Feb 94 16:14:40 EST Message-Id: <9402172114.AA00381@radegond.cmf.nrl.navy.mil> To: firp-comments@osi.ncsl.nist.gov Subject: Comment on FIRP Draft from IP Next Generation Area Cc: iab@isi.edu, iesg@cnri.reston.va.us, ipng@cmf.nrl.navy.mil 17 February 1994 Dr. Arati Prabhakar Director, National Institutes of Standards and Technology Administration Building, 11th Floor Gaithersburg, MD 20899 Dear Dr. Prabhakar: The Internet Engineering Task Force is in the process of selecting a replacement for the Internet Protocol Suite, an IP Next Generation (IPng), engineered to accomodate the rapid network growth and high-paced introduction of new applications and services that the Internet is seeing. The Internet has been "enduring" great success as a technology and a medium. Among the goals we hope to meet with IPng are: 1. management of sustained growth (the Internet now connects 20% more users per month) 2. access for billions of connected users (the Internet conservatively now has between 2 and 3 million users in over 25,000 organizations). 3. support for widespread multimedia and mobile communications 4. support for commercial requirements, such as authentication. As co-directors of this IP Next Generation undertaking, we appreciate the opportunity to comment on the Federal Internetworking Requirements Panel draft report and to describe some of the process that is being used to select the replacement for IP. In addition, the IPng Area invites the participation of NIST in our review of requirements and development of recommendations. In order to record the panel's concerns as a part of the formal record of the IPng effort, we request your consent to publish the draft FIRP report as one of the RFC 1550 IPng white papers. Sincerely, Scott Bradner, Harvard University Allison Mankin, Naval Research Laboratory Co-Directors, IP Next Generation Area Internet Engineering Task Force ------------------------------------------------------------------ Anastase Nakassis Acting Chief, Systems and Network Architecture Division Diane Fountaine Chair, Federal Internetworking Requirements Panel Office of the Secretary of Defense Attn: Draft Report of FIRP Dear Dr. Nakassis and Ms. Fountaine: As the co-directors of the Internet Engineering Task Force (IETF) area that has been charged with the task of producing a recommendation for a replacement for the current version of the Internet Protocol Suite, we would like to compliment the U.S. Federal Internetworking Requirements Panel on the draft of its report to NIST. We feel that if the conclusions in the draft report are followed they will result in the flexibility to ensure that the U.S. Government will obtain the most technologically advanced solutions to its data networking requirements. We would like to specifically address the comment in 4.2 where the hope is expressed that "the replacement for IP should converge with the replacement for the OSI connectionless network protocol (CLNP)." In September, 1993 we were appointed by the chair of the IETF to head a special area with a mission to select the replacement for the current version of the Internet Protocol Suite. We believe that the process which we have crafted to pursue this goal mirrors the process that would be undertaken by any group tasked with selecting a replacement for CLNP. Our first step was to recruit a directorate to assist in the review and selection process from across the spectrum of individuals and organizations involved in the use and development of data networks. The directorate includes personnel from router manufacturers, personal computer software firms, industrial research organizations, telecommunications companies, computer manufacturers, U.S. government and education, and international governments. In addition, we are assembling an expert panel from an even wider range of organizations to assist in the review of the IPng requirements document and the final report. Since a full understanding of the near and long-term requirements for a data networking protocol is the key prerequisite for the selection process, we are using an aggressive requirements development process. We have established an open IETF working group to produce a document outlining the set of requirements and associated time frames that should be tion can be undertaken. We have been soliciting input for this working group from the networking community and, in particular, issued a solicitation for white papers (RFC 1550) detailing particular concerns or suggestions for requirements. We have received white papers from a wide variety of sources, including major industrial and computer manufacturers, utility consortia, the cable TV industry, data networking researchers, and military and government agencies. In summary, the process for selecting the replacement for IP is taking into account the same range of requirements that a process for selecting a replacement for CLNP would have to take into account. The requirements review is being undertaken by a group whose membership and interests are as diverse as would be used in evaluating the requirements for any replacement for CLNP. Thus the results of the process should be as valid for CLNP as they will be for IP. We hope that the final recommendation produced by the IPng process would be evaluated by any organizations that would be considering revising CLNP or selecting a successor to CLNP, to see if the results would be applicable. We and the IETF share with the FIRP common goals of the continued growth of internetworking for global communications and industrial productivity. We would be quite pleased if the evaluations of other organizations result in the furtherance of these shared goals. Sincerely Yours, Scott Bradner, Harvard University Allison Mankin, Naval Research Laboratory Co-Directors, IP Next Generation Area Internet Engineering Task Force From iesg-request@ietf.cnri.reston.va.us Thu Feb 17 16:14:40 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA12635 for ; Thu, 17 Feb 1994 17:01:52 -0500 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16464; 17 Feb 94 16:21 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16460; 17 Feb 94 16:21 EST Received: from picard.cmf.nrl.navy.mil by CNRI.Reston.VA.US id aa18475; 17 Feb 94 16:21 EST Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA12295; Thu, 17 Feb 1994 16:14:44 -0500 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA00381; Thu, 17 Feb 94 16:14:40 EST Date: Thu, 17 Feb 94 16:14:40 EST Message-Id: <9402172114.AA00381@radegond.cmf.nrl.navy.mil> To: firp-comments@osi.ncsl.nist.gov Subject: Comment on FIRP Draft from IP Next Generation Area Cc: iab@isi.edu, iesg@CNRI.Reston.VA.US, ipng@cmf.nrl.navy.mil 17 February 1994 Dr. Arati Prabhakar Director, National Institutes of Standards and Technology Administration Building, 11th Floor Gaithersburg, MD 20899 Dear Dr. Prabhakar: The Internet Engineering Task Force is in the process of selecting a replacement for the Internet Protocol Suite, an IP Next Generation (IPng), engineered to accomodate the rapid network growth and high-paced introduction of new applications and services that the Internet is seeing. The Internet has been "enduring" great success as a technology and a medium. Among the goals we hope to meet with IPng are: 1. management of sustained growth (the Internet now connects 20% more users per month) 2. access for billions of connected users (the Internet conservatively now has between 2 and 3 million users in over 25,000 organizations). 3. support for widespread multimedia and mobile communications 4. support for commercial requirements, such as authentication. As co-directors of this IP Next Generation undertaking, we appreciate the opportunity to comment on the Federal Internetworking Requirements Panel draft report and to describe some of the process that is being used to select the replacement for IP. In addition, the IPng Area invites the participation of NIST in our review of requirements and development of recommendations. In order to record the panel's concerns as a part of the formal record of the IPng effort, we request your consent to publish the draft FIRP report as one of the RFC 1550 IPng white papers. Sincerely, Scott Bradner, Harvard University Allison Mankin, Naval Research Laboratory Co-Directors, IP Next Generation Area Internet Engineering Task Force ------------------------------------------------------------------ Anastase Nakassis Acting Chief, Systems and Network Architecture Division Diane Fountaine Chair, Federal Internetworking Requirements Panel Office of the Secretary of Defense Attn: Draft Report of FIRP Dear Dr. Nakassis and Ms. Fountaine: As the co-directors of the Internet Engineering Task Force (IETF) area that has been charged with the task of producing a recommendation for a replacement for the current version of the Internet Protocol Suite, we would like to compliment the U.S. Federal Internetworking Requirements Panel on the draft of its report to NIST. We feel that if the conclusions in the draft report are followed they will result in the flexibility to ensure that the U.S. Government will obtain the most technologically advanced solutions to its data networking requirements. We would like to specifically address the comment in 4.2 where the hope is expressed that "the replacement for IP should converge with the replacement for the OSI connectionless network protocol (CLNP)." In September, 1993 we were appointed by the chair of the IETF to head a special area with a mission to select the replacement for the current version of the Internet Protocol Suite. We believe that the process which we have crafted to pursue this goal mirrors the process that would be undertaken by any group tasked with selecting a replacement for CLNP. Our first step was to recruit a directorate to assist in the review and selection process from across the spectrum of individuals and organizations involved in the use and development of data networks. The directorate includes personnel from router manufacturers, personal computer software firms, industrial research organizations, telecommunications companies, computer manufacturers, U.S. government and education, and international governments. In addition, we are assembling an expert panel from an even wider range of organizations to assist in the review of the IPng requirements document and the final report. Since a full understanding of the near and long-term requirements for a data networking protocol is the key prerequisite for the selection process, we are using an aggressive requirements development process. We have established an open IETF working group to produce a document outlining the set of requirements and associated time frames that should be tion can be undertaken. We have been soliciting input for this working group from the networking community and, in particular, issued a solicitation for white papers (RFC 1550) detailing particular concerns or suggestions for requirements. We have received white papers from a wide variety of sources, including major industrial and computer manufacturers, utility consortia, the cable TV industry, data networking researchers, and military and government agencies. In summary, the process for selecting the replacement for IP is taking into account the same range of requirements that a process for selecting a replacement for CLNP would have to take into account. The requirements review is being undertaken by a group whose membership and interests are as diverse as would be used in evaluating the requirements for any replacement for CLNP. Thus the results of the process should be as valid for CLNP as they will be for IP. We hope that the final recommendation produced by the IPng process would be evaluated by any organizations that would be considering revising CLNP or selecting a successor to CLNP, to see if the results would be applicable. We and the IETF share with the FIRP common goals of the continued growth of internetworking for global communications and industrial productivity. We would be quite pleased if the evaluations of other organizations result in the furtherance of these shared goals. Sincerely Yours, Scott Bradner, Harvard University Allison Mankin, Naval Research Laboratory Co-Directors, IP Next Generation Area Internet Engineering Task Force From ericf@atc.boeing.com Thu Feb 17 14:44:35 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA12873 for ; Thu, 17 Feb 1994 17:49:01 -0500 Received: by atc.boeing.com (5.57) id AA20811; Thu, 17 Feb 94 14:44:35 -0800 Date: Thu, 17 Feb 94 14:44:35 -0800 From: Eric Fleischman Message-Id: <9402172244.AA20811@atc.boeing.com> To: postel@ISI.EDU, rcallon@wellfleet.com Subject: Re: Local IP addresses Cc: Daniel.Karrenberg@ripe.net, eek, ericf, iana@ISI.EDU, ipng@cmf.nrl.navy.mil, xrjo About Local Addresses (again) I am quite alarmed by the following dialog between Jon Postel (indented) and Ross Callon (not indented). What alarms me is that it represents yet another example of my personal "pet-peeve" about vendors in general and the IETF in particular. I am, of course, speaking about "scale" and my continual frustration over what I perceive (a significant percentage of) the IETF community apparently thinks a "large population" of devices to be. More to the point: this dialog imagines that we are talking about the need for a corporation to use Local Addresses to address a few hundred devices -- or maybe a few thousand in the extreme case. WRONG!!!!! Rather, DEAD WRONG!!!!! [Please note: I am not trying to be offensive by the use of these capitolized words. Rather, I don't know how to properly convey the concept of an emphatic (but polite) denial of the veracity of a statement within English. What I wanted to say was the German "doch".] By contrast, we are talking about the need for a corporation to use Local Addresses to address a SMALL subset of its IP devices -- say in the order of 50,000 (or more) devices. Please don't misunderstand me: "a few Class Bs" is definitely not what we are talking about since not all of these devices will necessarily be in the same city or state (by a long shot) -- but a given location may simultaneously literally require tens of thousands of devices to be so addressed. "A Large Block of Class Cs" (mentioned in the dialog below) is a *VERY BAD IDEA* (unless it is also coupled with a large block of Class Bs) because Boeing's internal corporate network is already so large that we anticipate the need for something like an intra-domain (i.e., within our corporation alone) CIDR to aggregate what we expect our corporate IP network to soon become. Without such an intra-domain CIDR, this "large block of Class Cs" idea will make our aggregation problems increasingly untenable. That is, we have already deployed something like 26 Class Bs and 250 Class Cs internally. Each of these network populations are more than an order of magnitude denser than what Phil Gross stated was the perceived Internet population average -- certainly significantly denser than his ultimate "address usage density target". The bottom line is that our internal TCP/IP network is expected to grow in the short term at a surprising rate beyond its current size. Virtually all of this growth will be for devices which we want to remain hidden from the Internet. I, personally, resist the idea of going to any outside entity to "justify" our need to obtain network numbers for devices which we want to be hidden from the Internet anyway. (Frankly, it is none of their business.) Thus, we are seriously considering "making up" network numbers should we fail to expeditiously receive a viable range of "Local Addresses" for our internal, private use. In any case, we all know of companies who have already done just that. Sincerely yours, --Eric Fleischman P.S. I realize that the above description is rather terse and does not adequately convey the reason why local addresses are needed. Please see my IPng white paper "A User's View of IPng" for a more adequate treatment of this subject. In any case, I am very alarmed that my many public statements concerning end users' pressing requirement for Local Addresses have apparently gone unheard. =========================================== > Yes we are very familiar with this issue. the Memo (started by > Yakov and Bob Moskowitz) is progressing and is now in Daniel > Karrenberg's hands (or maybe in his powerbook). > >Great. Yakov sent me an updated copy this morning. Generally >it looks very good (I had a few nit comments which I sent to >Yakov). > > Given the move to "classless" addressing with CIDR it may be more > appropriate to allocate a large block of "class C" space to be used > for non-connected networks (rather than a class B or two). > >The one case where a few B's would be useful would be a >corporation with several large sites, which was running >BGP-3 (or EGP) between sites and didn't want to upgrade to >BGP-4, and preferred to aggregate inter-site information. >On the other hand, there are probably at least as many >companies which have large numbers of small sites, also >want to run BGP-3, and thus need a larger number of C's >(If folks are running BGP-4, it doesn't seem to make any >difference whether there is a small number of B's or a >larger number of C's). > >This seems to imply that a large block of C's (as you >suggest) is more flexible than a smaller block of B's, >but that both would be slightly more flexible still. I >guess there is a tradeoff here versus how much of the >address space we want to use for this purpose. > > I'd rather not pick the addresses till the memo is ready. There are > number of warnings about the downside risks of doing this that should > be associated with it. > >This is a good point. Hopefully it should not take too >long to get the draft finished. > >Ross From rcallon@wellfleet.com Thu Feb 17 18:41:24 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA13075 for ; Thu, 17 Feb 1994 18:40:40 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25368; Thu, 17 Feb 94 18:20:28 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA29837; Thu, 17 Feb 94 18:30:32 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA23787; Thu, 17 Feb 94 18:41:24 EST Date: Thu, 17 Feb 94 18:41:24 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9402172341.AA23787@cabernet.wellfleet> To: eek@atc.boeing.com, ericf@atc.boeing.com, xrjo@atc.boeing.com Subject: Re: Local IP addresses and scaling Cc: Daniel.Karrenberg@ripe.net, iana@ISI.EDU, ipng@cmf.nrl.navy.mil, postel@ISI.EDU I am quite alarmed by the following dialog between Jon Postel (indented) and Ross Callon (not indented). What alarms me is that it represents yet another example of my personal "pet-peeve" about vendors in general and the IETF in particular. I am, of course, speaking about "scale" and my continual frustration over what I perceive (a significant percentage of) the IETF community apparently thinks a "large population" of devices to be. Eric; My apologies. Most of the time I keep scale in mind, and most of the time I have the same concern that you have -- I get frustrated by folks who talk about "big networks" with 50 routers and 2000 hosts, while I am concerned about "little networks" with 1,000 routers and 100,000 hosts (and also with big networks which are a whole lot bigger than this). This morning I must have been tired or something. Clearly you are right, and we have to think about the scale of networks that are going to need local IP addresses. "A Large Block of Class Cs" (mentioned in the dialog below) is a *VERY BAD IDEA* (unless it is also coupled with a large block of Class Bs) because Boeing's internal corporate network is already so large that we anticipate the need for something like an intra-domain (i.e., within our corporation alone) CIDR to aggregate what we expect our corporate IP network to soon become. Without such an intra-domain CIDR, this "large block of Class Cs" idea will make our aggregation problems increasingly untenable. That is, we have already deployed something like 26 Class Bs and 250 Class Cs internally. Each of these network populations are more than an order of magnitude denser than what Phil Gross stated was the perceived Internet population average -- certainly significantly denser than his ultimate "address usage density target". You can do CIDR with OSPF or with I.IS-IS. I think that you might however want more than two levels of hierarchy, which seems to imply using BGP (there are lots of other private corporate networks which are large enough to consider using BGP or IDRP internally between different parts of the same company). I doubt that you have the largest network in the world that will require local network numbers. Also, I expect that for very large corporate networks we (the "keepers of the Internet") will be very glad if they use local IP addresses for 99.99% of their devices (given that a corporation with a million devices could otherwise take quite a bite out of the IP address space). This all implies that we definitely should be reserving enough private address space for Boeing, and probably more. This makes me wonder how large a chunk will be needed. Are we talking about something like one class A, 128 or 256 Class B addresses, plus a few tens of thousand class Cs? If local IP addresses are likely to be used by the vast majority of the systems using IP, then should we consider assigning something like 1% of the total IP address space for this purpose? I don't think that this is quite what folks have been thinking up to now, but perhaps we need to re-think the scale issues. Ross From ericf@atc.boeing.com Thu Feb 17 16:56:31 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA13339 for ; Thu, 17 Feb 1994 19:55:37 -0500 Received: by atc.boeing.com (5.57) id AA01462; Thu, 17 Feb 94 16:56:31 -0800 Date: Thu, 17 Feb 94 16:56:31 -0800 From: Eric Fleischman Message-Id: <9402180056.AA01462@atc.boeing.com> To: Daniel.Karrenberg@ripe.net, iana@ISI.EDU, ipng@cmf.nrl.navy.mil, postel@ISI.EDU Subject: 3rd Message on Local Addresses Cc: ericf Dear Daniel and Jon, It occurs to me that I owe you a terse explanation as to why Boeing (and other companies) are deploying so many IP devices needing Local Addresses. There are at least 3 reasons: 1) Some of these devices are "dumb" devices which are now "intelligent". For example, many of our doors and some of our elevators are IP addressable because their security badge reader which "drives" them uses the our corporate IP network to verify the ability of that badge-holder to enter that door. Boeing has a great many doors and elevators. All of these new IP devices must not be addressed from outside Boeing. We also are talking about IP-addressable thermostats and other "oddities". 2) Most of the need is for computers which formerly used another network infrastructure (e.g., SNA, CATIA/GAM, etc.) and which are beginning to use an IP network as their transport (with their old "upper layers" still intact; i.e., do not use TCP/IP applications). Within Boeing, these devices are much more numerous our current "pure" TCP/IP network devices -- though many devices currently have two or more "stacks" today. These non-TCP/IP-devices-about-to-use-TCP/IP-transports often carry highly sensitive "mission critical" data. [I, personally, am immensely concerned at the current state of TCP/IP security. This situation is very critical and demands a very complicated total security response on our part. Having "local addresses" is a small part of our total security response. Of course, the most pressing reason for Local Addresses is to remove all outside influence and visibility for issues which are totally private and local within our corporation. ] 3) Some of these devices represent new computer purchases for sensitive applications or usages. Please note that we are currently trying to migrate as many of our devices as possible to use our IP infrastructure (i.e., to reduce our current 12+ distinct internal physical networks and 22 protocol families down to as integrated and common an infrastructure as possible -- one preferentially based on TCP/IP). I hope that this information aids your understanding as to why we need so many Local Addresses. As you should hopefully be able to immediately see, the 50,000 number (for devices needing Local Addresses) which I used in my previous note is probably less than our probable need should our present efforts be met with success. Of course, I don't want to overstate our need either and thus lose credibility with you. Sincerely yours, --Eric Fleischman From brian@dxcoms.cern.ch Fri Feb 18 08:23:57 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA14870 for ; Fri, 18 Feb 1994 02:24:36 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13549; Fri, 18 Feb 1994 08:23:59 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA12674; Fri, 18 Feb 1994 08:23:58 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402180723.AA12674@dxcoms.cern.ch> Subject: Re: Local IP addresses and scaling To: rcallon@wellfleet.com (Ross Callon) Date: Fri, 18 Feb 1994 08:23:57 +0100 (MET) Cc: eek@atc.boeing.com, ericf@atc.boeing.com, xrjo@atc.boeing.com, Daniel.Karrenberg@ripe.net, iana@ISI.EDU, ipng@cmf.nrl.navy.mil, postel@ISI.EDU In-Reply-To: <9402172341.AA23787@cabernet.wellfleet> from "Ross Callon" at Feb 17, 94 06:41:24 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 524 I have to support Eric (CERN will be buying 777s soon if this continues, as long as Boeing buys some protons :-) When I sent my note on PINNs to the Directorate a few weeks ago I suggested that one Class A, a few class Bs and 64 Class Cs should be reserved for private use. I think this is so obviously right that I am surprised anyone could imagine limiting it to a few Class C's. Eric has given the arguments so I won't repeat them. Could somebody post today's draft from Yakov et al on the ipng list? Thanks. Brian From scoya@CNRI.Reston.VA.US Tue Feb 22 11:02:21 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA14308 for ; Tue, 22 Feb 1994 11:44:47 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05605; 22 Feb 94 11:02 EST To: Mark Knopper cc: ipng@cmf.nrl.navy.mil Subject: Re: 2/14 telechat minutes In-reply-to: Your message of "Mon, 21 Feb 94 23:26:22 EST." <199402220426.XAA29108@merit.edu> Date: Tue, 22 Feb 94 11:02:21 -0500 From: Steve Coya Message-ID: <9402221102.aa05605@IETF.CNRI.Reston.VA.US> >> The minutes of the 1/31/94 telechat were approved. Great.... but there was no telechat on the 31st of January :-) Maybe the approval was for the minutes of January 17??? From scoya@CNRI.Reston.VA.US Tue Feb 22 18:25:09 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA19522 for ; Tue, 22 Feb 1994 20:16:43 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15788; 22 Feb 94 18:25 EST To: ipng@cmf.nrl.navy.mil Subject: Draft minutes of February 14 Teleconference Date: Tue, 22 Feb 94 18:25:09 -0500 From: Steve Coya Message-ID: <9402221825.aa15788@IETF.CNRI.Reston.VA.US> Greetings, First, I want to thank Mark for stepping in at the last minute. Second, corrections and nits should be sent to me. I have incorporated changes and suggestions received so far. Be sure to check everything (like which set of minutes were approved, who was there and who was not, etc.). Steve ======================================================================== DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference Valentines Day, 1993 Reported by: Mark Knopper This report contains IPNG Directorate meeting notes, positions and action items. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL Steve Bellovin / AT&T Ross Callon / Wellfleet Brian Carpenter / CERN Dave Clark / MIT John Curran / NEARnet Steve Deering /Xerox PARC Eric Fleischman / Boeing Paul Francis / Bellcore Mark Knopper / Ameritech Greg Minshall / Novell Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- J Allard / Microsoft Jim Bound / DEC Dino Farinacci / Cisco Daniel Karrenberg / RIPE Paul Mockapetris / ISI 1. The minutes of the January 17 teleconference were approved. 2. Dave Clark reviewed the purpose of the External Review Panel which is to lead the process to produce an IPng requirements document and an overall assessment document and ultimately produce a recommendation for a protocol selection. 3. The following process and schedule was adopted: Before March IETF: a. Frank Kastenholtz and Craig Partridge to produce a draft requirements document, without benefit of input from IPng Directorate White Papers. This is needed 3 weeks from now (March 7). b. The Directorate will produce an update of this document based on the White Papers. This update will be sent to external reviewers, and a 3 week comment period will be allowed. During March IETF: c. The requirements draft will be presented to the plenary at the start of the week. d. The protocol working groups (TUBA, CATNIP, SIPP) will discuss these requirements as part of their agendas. There will also be a transition working group (TACIT) meeting. e. A requirements BOF will be held toward the end of the week. After March IETF: f. The IPng Directorate will immediately produce a new draft based on feedback from external reviewers and the IETF. A 3 week comment period will be allowed. g. A final Requirements RFC will be produced by the Directorate (& wg chairs) revising the document after IETF meeting. h. Each proposal group will produce a paper saying how they will meet requirements. A 3 week turn around will follow, then the Directorate & ADs review these answers. i. The IPng area directors will write the first draft of the final output document for IPng (assessment and protocol selection). The draft will be sent to the Directorate, and external reviewers, with a 3 week period for comments. The document will be revised based on comments received. During the July IETF: j. The final requirements paper will be presented to the IETF plenary. k. The assessment document will be presented for discussion at the plenary and a BOF. It was noted by some that this is a very aggressive schedule, but the group felt it should be pursued. 4. Dave Clark will lead the process of lining up the external reviewers. He will send a draft of a kickoff message to the directorate for review, which will then be sent to the potential reviewers. Reviewers will be asked to participate via written comments, on conference calls, or possibly in a special workshop in July. Reviewer comments will not be made public without permission of their authors. 5. A list of white papers received and expected was sent out by Allison. It was suggested that the list include the topic for each white paper, and Allison agreed to update the list. The group also agreed that white papers should be assigned document numbers for easy reference. The white papers are not publicly available via FTP until the clarity review process is complete. Each white paper will need to be reviewed by at least 3 people. Reviews are mainly for clarity, ie. are the words clear and thoughts complete, with specific suggestions on how to fix any problems. Allison will collate comments received and send them out to the group in an organized fashion. Comments from directorate members can be sent to authors directly (with copy to directorate list). Future white papers will be sent to the group with descriptive e-mail subject. Suggested white papers were: an ATM perspective (eg. Juha Heinanen); and a telephone company perspective (eg. Mark Knopper). 6. Frank Kastenholtz is a co-chair of the Requirements WG; a European co-chair is being solicited by Brian Carpenter. 7. Atul Bansal (DEC) and Geoff Huston (AARN) will be co-chairs of the TACIT WG. TACIT will be a long term working group. Atul will be drafting the WG charter. 8. TP/IX is being renamed to CATNIP.The charter is ready to go. Rob has added minor wording changes. The SIPP working group also needs a new charter, since it has been renamed. 9. Next IPng Directorate meetings: February 28: telechat March 14: telechat March 21: possible telechat March 28-April 1: IETF From bound@zk3.dec.com Tue Feb 22 18:41:13 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA19060 for ; Tue, 22 Feb 1994 18:48:47 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA23988; Tue, 22 Feb 94 15:41:21 -0800 Received: by xirtlu.zk3.dec.com; id AA17659; Tue, 22 Feb 1994 18:41:18 -0500 Message-Id: <9402222341.AA17659@xirtlu.zk3.dec.com> To: rullmann@crd.lotus.com, scrivner@world.std.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Clarity Review - CATNIP ... Date: Tue, 22 Feb 94 18:41:13 -0500 X-Mts: smtp Robert and Michael, I read your CATNIP White Paper and found iquite clear. Of course this may be biased as I have been keeping up with CATNIP, and its approach to IPng. Thanks for taking the time to write this paper I know it was done after your real jobs. p.s. Rob - Could we get an anti-gravity demonstration at the next IETF? I liked your BIOs. Sincerely, /jim From bound@zk3.dec.com Wed Feb 23 10:37:43 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA23961 for ; Wed, 23 Feb 1994 10:45:44 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA02116; Wed, 23 Feb 94 07:37:54 -0800 Received: by xirtlu.zk3.dec.com; id AA01873; Wed, 23 Feb 1994 10:37:48 -0500 Message-Id: <9402231537.AA01873@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: X/Open and POSIX working on Sockets fyi .. Date: Wed, 23 Feb 94 10:37:43 -0500 X-Mts: smtp Just wanted to send this to you so you know folks do work on sockets. Note the clarification of the meaning of IP_DONTROUTE by an application in the discussion. /jim ------- Forwarded Message Return-Path: us2rmc::petja@xopen.co.uk Received: by xirtlu.zk3.dec.com; id AA20877; Wed, 23 Feb 1994 01:06:00 -0500 Date: Wed, 23 Feb 1994 01:06:00 -0500 Message-Id: <9402230606.AA20877@xirtlu.zk3.dec.com> From: us2rmc::petja@xopen.co.uk (Petr Janecek) To: XoXTI@xopen.co.uk Subject: (XoXTI 384) Meaning of IP_DONTROUTE Dear XTI Expert, There was a POSIX ballot comment (EVA-63) on the XTI part of P1003.12 which related to the meaning of IP_DONTROUTE. The comment was as follows. > > What does "bypass the standard routing facilities" mean? This is > not clear. > > Action: > > Rewrite so that it is clear. > It has been suggested that the meaning is that "the destination address shall refer to a destination on a directly attached network interface, and that interface shall be used to deliver all packets." This is the meaning that will be given in the next draft. Does anyone have any views as to whether it is correct? Alternatively, there is a nice description of SO_DONTROUTE in the Spec-1170 man-page for setsockopt(). This says that the option "Indicates whether outgoing messages should bypass the standard routing facilities. Instead, they are directed to the appropriate network interface, according to the network portion of the destination address." Is this description better and, if so, can POSIX use it? Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding Data Logic Tel: +44 81 715 9696 C I Tower Fax: +44 81 715 1771 St. Georges Square New Malden X/Open E-mail: c.harding@xopen.co.uk Surrey KT3 4HH Other E-mail: charding@datlog.co.uk UK ------------------------------------------------------------------------- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us2rmc.bb.dec.com; id AA08396; Wed, 23 Feb 94 01:02:56 -0500 % Received: from xopen.xopen.co.uk by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA06883; Tue, 22 Feb 94 22:00:10 -080 % Received: by xopen.xopen.co.uk (1.36.108.3/15.6) id AA23575; Wed, 23 Feb 94 05:50:05 GM % Message-Id: <9402230550.AA23575@xopen.co.uk> % Received: by xopuk.xopen.co.uk (1.36.108.3/16.2) id AA12468; Wed, 23 Feb 94 05:45:17 GM % Date: Wed, 23 Feb 94 05:45:17 GMT % From: Petr Janecek % To: XoXTI@xopen.co.uk % Subject: (XoXTI 384) Meaning of IP_DONTROUTE % Sender: XoXTI-request@xopen.co.uk % Comments: (XoXTI 384) ------- End of Forwarded Message From lkeiper@IETF.CNRI.Reston.VA.US Wed Feb 23 14:00:22 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA25843 for ; Wed, 23 Feb 1994 14:00:22 -0500 Date: Wed, 23 Feb 1994 14:00:22 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa09338; 23 Feb 94 13:56 EST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference February, 28, 1994 Message-ID: <9402231356.aa09338@IETF.CNRI.Reston.VA.US> ANNOUNCEMENT**** The names marked with an asterisk are those who have confirmed participation for the IPng teleconference scheduled for Monday February 28, 1994, 11;30 am EST - 1:30pm EST. Please send your confirmation of participation or regrets to Lois Keiper @ lkeiper@cnri.reston.va.us. Thank you for your cooperation. J. Allard 206-936-9031 Steve Bellovin 908-582-5886 Jim Bound 603-465-3130 Scott Bradner 617-495-3864 Ross Callon 508-436-3936 Brian Carpenter +41 22 767 4967 Dave Clark 617-253-6003 Steve Coya 703-620-8990 John Curran 617-873-4398 Steve Deering 415-812-4839 Dino Farinacci 408-226-6870 Eric Fleischman 206-957-5334 Paul Francis +81 3 3928 0408 Dan Karrenberg +31 20 592 5065 Mark Knopper 313-763-6061 Greg Minshall 510-975-4507 Paul Mockapetris 703-696-2262 Rob Ullmann 617-693-1315 Lixia Zhang 415-812-4415 If you need to be added to the teleconference in progress, please call 1-800-232-1234 or 516-424-3151 for the international participants. The call can be referenced by the confirmation number ER13193 in the orginators name, Steve Coya. Thanks, Lois From mankin Thu Feb 24 15:18:52 1994 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA06190 for ; Thu, 24 Feb 1994 15:18:59 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA15186; Thu, 24 Feb 94 15:18:52 EST Date: Thu, 24 Feb 94 15:18:52 EST Message-Id: <9402242018.AA15186@radegond.cmf.nrl.navy.mil> To: ipng Subject: IPng Reqs news Thanks Directorate, for all the reviewing you've been doing. The procedure of sending the comments to the authors seems to be working really well. Scott and I will concoct a message to the white paper authors so the reviews can come to closure before IETF and in time for the big push to incorporate white paper views into the requirements draft. Jon Crowcroft has agreed to serve as the second IPng Requirements WG chair. We are going to ask Jon, Frank K. and Craig to join us for the next few telechats, so we can work as a group on the revision of the document. Frank and Craig did their new draft. It is available from research.ftp.com in pub/ip7reqs/criteria.txt (or .rf in which case also grab idmacs to format the nroff). From bound@zk3.dec.com Fri Feb 25 00:54:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA09453 for ; Fri, 25 Feb 1994 00:56:28 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA28202; Thu, 24 Feb 94 21:54:54 -0800 Received: by xirtlu.zk3.dec.com; id AA14292; Fri, 25 Feb 1994 00:54:53 -0500 Message-Id: <9402250554.AA14292@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: bound@zk3.dec.com Subject: LATE: Mbone IPng only & IPv4 only minutes Date: Fri, 25 Feb 94 00:54:47 -0500 X-Mts: smtp But better late than never. Please send any points missed before they get sent out by Scott and Allison. thanks /jim Return-Path: bound Message-Id: <9401271605.AA10991@xirtlu.zk3.dec.com> To: mankin@cmf.nrl.navy.mil Cc: sob@hsdndev.harvard.edu, jcurran@nic.near.net, bound@zk3.dec.com Subject: DRAFT MINUTES OF MBONE IPNG MEETING Date: Thu, 27 Jan 94 11:05:27 -0500 From: bound X-Mts: smtp Allison, Please fill in any gaps or make corrections you see. I asked in the text for you to fill in participants for me. CC'd Scott and John for input too. /jim ----------------------------------------------------- These are the minutes of the IPng Area Directorate MBONE meeting on January 25, 1994 12:30 - 14:00 EST. This meeting was open to others in the IETF body besides the IPng Directorate and was an open meeting. The discussion topic was IPv4 only and IPng only stacks interoperating across a network path. It was specifically stated that no mention of any IPng proposal should be discussed and would be stopped if it began. Hence, there is no mention of any IPng proposal in these minutes. *********************************** If we need this can one of you fill this in from your SD if it was saved on the Whiteboard files???? Participants: *********************************** The discussion started by describing the problem space for the topic. If it is a requirement that an IPng proposal provide a technical solution to support interoperation between IPng only and IPv4 only systems, then this will effect the required strategy for a transition plan from each proposal. To support this interoperation would require at a minimum packet translation and address translation. The meeting then discussed the reasons that may exist for this interoperation and why systems may have a requirement at times to support an IPng only protocol implementation as follows: 1. Resource poor systems that cannot support two stacks (e.g. Real-Time Kernels, Light Switches, PC implementations). 2. Minimize the cost of systems to support two protocol implementations. 3. Reserve bandwidth on Hosts for performance gains per the integration of the network code base with the rest of the Host operating system code base. A discussion point brought forward was that maybe it was not an issue of supporting two protocols, but rather it needed to be determined how to reduce or minimize the cost of a dual stack on a Host. There were differing opinions on whether this was just pointing to the problem and that the 3 items above were addressing the problem rather than defining the problem. The discussion moved on. Another view expressed was that this interoperation could be added value from any proposal if their market assumptions felt it was a required feature for an IPng proposal. This basically stated that if a proposal did provide a solution for this interoperation it should not be construed to be bad by the IPng Directorate, but a resolution to solving the problems listed in the 3 items above. It was also noted by several meeting participants that they have first hand historical experience that legacy systems that do not go away for a long time, and they may also continue to support IPv4 only for some time. If suppliers did deliver IPng only systems to the market with IPv4 not supported, those systems would have to interoperate their legacy systems. The discussion then drifted to a mini technical discussion of the address translation concerns. It was general consensus that this creates a complex set of problems for network providers and network managers. That if this interoperation was required then it had to be defined clearly by any proposal. But, it was questioned without resolution in the meeting whether this should be an IPng requirement. It was proposed that an IPng architecture could provide this interoperation, but would clearly have to provide a technical explanation for two problems: 1. Where are the mappings generated for translation. 2. What will happen once IPv4 addresses are not globally unique. It was felt that CIDR aggregates as an example would reduce these mapping tables. One suggestion was that if this interoperation was needed and would take place some registered authority could provide a place where the mappings could be down loaded to sites providing this translation, that would also be coordinated with the root BIND DNS name and address space infrastructure. It was then discussed that Network Address Translation (NAT) boxes would get deployed in the market to solve the problem and would actually be a business. There was an objection to how this would happen, because of the Open Systems philosophy in the market partially developed by TCP/IP. The objection stated that the IETF needed to provide some solution to this problem so that interoperability between any NAT boxes would be maintained through IETF specifications. If this product set emerged in the market then the customers and network providers who required the operation between IPv4 only and IPng only would have some specified architecture to implement the solution, when working with providers supporting the translation of IPv4 and IPng. It was generally felt the meeting did a good job of flushing out the reason for this interoperation and those technical concerns with implementing a solution. It was not decided during the meeting through any consensus (or asked for) whether this interoperation should be an IPng requirement. The meeting provided the IPng Directorate with further data to pursue this concern as one of its functions as a member body of the IPng Area in the IETF. From brian@dxcoms.cern.ch Fri Feb 25 08:55:32 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA09757 for ; Fri, 25 Feb 1994 02:56:06 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13046; Fri, 25 Feb 1994 08:55:33 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13413; Fri, 25 Feb 1994 08:55:32 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402250755.AA13413@dxcoms.cern.ch> Subject: Re: IPng Reqs news To: ipng@cmf.nrl.navy.mil Date: Fri, 25 Feb 1994 08:55:32 +0100 (MET) In-Reply-To: <9402242018.AA15186@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Feb 24, 94 03:18:52 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 368 > > Frank and Craig did their new draft. It is available from research.ftp.com in > pub/ip7reqs/criteria.txt (or .rf in which case also grab idmacs to format the nroff). > Bleat .... bleat .... yet another I-D with no ctrl/L characters at the page breaks .... no way to print it correctly.... bleat ...bleat (I'm glad the work has been done of course.) Brian From lkeiper@IETF.CNRI.Reston.VA.US Fri Feb 25 14:23:58 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA01685 for ; Fri, 25 Feb 1994 14:23:58 -0500 Date: Fri, 25 Feb 1994 14:23:58 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa09215; 25 Feb 94 14:08 EST X-Sender: lkeiper@ietf.cnri.reston.va.us Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Steve Coya MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US Subject: IPng Teleconference Cc: lkeiper@IETF.CNRI.Reston.VA.US Message-ID: <9402251408.aa09215@IETF.CNRI.Reston.VA.US> UPDATE**** The names marked with an asterisk are those who have confirmed participation for the IPng teleconference scheduled for Monday February 28, 1994, 11;30 am EST - 1:30pm EST. Please send your confirmation of participation or regrets to Lois Keiper @ lkeiper@cnri.reston.va.us. Thank you for your cooperation. THANKS FOR YOUR PROMPT RESPONSES!!!! :-) J. Allard 206-936-9031 Steve Bellovin 908-582-5886 *Jim Bound 603-465-3130* *Scott Bradner 617-495-3864* Ross Callon 508-436-3936 Brian Carpenter +41 22 767 4967 Dave Clark 617-253-6003 *Steve Coya 703-620-8990* John Curran 617-873-4398 Steve Deering 415-812-4839 *Dino Farinacci 408-226-6870* *Eric Fleischman 206-957-5334* -Paul Francis Regrets Dan Karrenberg +31 20 592 5065 Mark Knopper 313-763-6061 *Greg Minshall 510-975-4507* *Paul Mockapetris 310-592-1774* *Rob Ullmann 617-693-1315* Lixia Zhang 415-812-4415 If you need to be added to the teleconference in progress, please call 1-800-232-1234 or 516-424-3151 for the international participants. The call can be referenced by the confirmation number ER13193 in the orginators name, Steve Coya. Thanks, Lois ------- End of Forwarded Message From scoya@CNRI.Reston.VA.US Fri Feb 25 17:38:14 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA06349 for ; Fri, 25 Feb 1994 17:40:21 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13897; 25 Feb 94 17:38 EST To: ipng@cmf.nrl.navy.mil Subject: DRAFT Agenda for February 28 Date: Fri, 25 Feb 94 17:38:14 -0500 From: Steve Coya Message-ID: <9402251738.aa13897@IETF.CNRI.Reston.VA.US> IPNG Directorate Teleconfence Agenda for February 28, 1994 1. Administrivia o Roll Call o Agenda bashing o Approval of minutes January 17 (?) January 25 (mbone) February 14 2. White paper Review Status 3. Special Topic (one hour): Conflict Resolution with respect to choosing requirements. 4. Roundtable From mankin Fri Feb 25 18:32:10 1994 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA06615; Fri, 25 Feb 1994 18:32:16 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA18685; Fri, 25 Feb 94 18:32:10 EST Date: Fri, 25 Feb 94 18:32:10 EST Message-Id: <9402252332.AA18685@radegond.cmf.nrl.navy.mil> To: ipng, jon@cs.ucl.ac.uk, kasten@ftp.com Subject: IPng Requirements Hi, all, Hopefully despite the apparent disorganization of one of the ADs, Jon is still agreed to join Frank as co-chair of the IPngReq working group. We have scheduled a plenary 30-45 minutes on Monday of the Seattle IETF and a meeting session with multicast on Thursday morning of Seattle for this wg's activities. Jon wrote initial comments about criteria.txt, herewith forwarded. It's good to ask if there's a core Internet that wants to stabilize out rather than ride a wave of growth into mass medium. Is that an option we could somehow choose, though, even if we want it? Scott and I would like to request that you three (Jon, Craig and Frank) join the IPng directorate for telechats. There was an existing agenda item that precluded the coming one, even though time is sort of short. But I hope we will have one on 3/7, and we will have them on 3/14 and 3/21. They go from 16:30-18:30 GMT (Paul Francis participates from Japan in the wee hours). Here are Jon Crowcroft's comments. Thanks, Allison Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA03717 for ; Sun, 20 Feb 1994 11:09:27 -0500 Message-Id: <199402201609.LAA03717@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 20 Feb 1994 16:09:11 +0000 To: Allison J Mankin cc: J.Crowcroft@cs.ucl.ac.uk Subject: IPng In-reply-to: Your message of "Fri, 18 Feb 94 12:14:14 EST." <9402181714.AA03078@radegond.cmf.nrl.navy.mil> Date: Sun, 20 Feb 94 16:09:08 +0000 From: Jon Crowcroft Allison, I have certain reservations about the IPng process, and some detailed things to add to craig & frank's criteria. (and feel free to forward this to any & all of the IPng folks...) My main propblem is that there is a small, but not insignificant number of serious exports saying that we really do not know how to do IPng yet, and that we should use the apparently increasing amount of time that CIDR is buying us (if mailon the ALE list is anything to go by) to think longer about it. Another problem I have is that I am not confident that I know who the constituency for IPng is any more. The more I talk to people, the more ireconcilable views I get. Basically, are we _supposed_ to be popularising the Internet - do we owe it to "humanity" to bring them the Internet, or to the current Internet users to keep things simple and cost effective? There is a point of view that says that people are already making do with the Internet they have - who are we to change it, or say that others (who are inherently more and more, from _different_ communities) need have the same conenctivity... basically, is more quantity the same as better? obviously in the long run, it is a commercial ideal and social benefit, that the net is as ubiquitous as the phones and roads, but is that time now? Also, there are some real problems with the predicted growth - at the moment, there are of order 200 Million active computers in the world. The cost of connecting to the net is significantly less than the cost of s/w upgradses to any system I know of...I'm not sure the current grwoth will continue past somewhere like 100 M computers, and most of them will be behind firewalls, which leads to a bunch of sub-optimal proposals like NAT being actually quite attractive...most of the commercial users in the UK are behind dial up, and i think that will be the european domestic and low-end busniess norm. and i'm not sure the number of computers is really going to grow that fast....unless the 'internet capable' TV/Videophone/PIM is launched real soon:-) anyhow, do let me know what you want me to do! cheers j. --------------------------------------> on the details, which are all complemetary to the criteria in the partrdige/kastenholz document: 1. IPv4 is 14 years old. In 1980, folks had the foresight to predict 32Bit machines being common (they were not then) and design a protocol that ran on LSI/11s fast enough to drive 56kbps lines, but without change, can now run 10,000 times faster. Do we really believe we can design a network layer that can last til 2008 without change, were it may have to run at 500 terrabits (the equivalent speedup)? - this may sound crazy, but i bet if you'd asked postel in 1980 about a 500Mbps lan, he might have worried a bit about the design. I know this merely spports the datagram model, but it does bring in questions of silicon costs...and pure optical complexity 2. Traffic aggregation models were not a big issue in a net designed to go to a few hundred sites - muxing/demuxing, and forwarding must be a lot more efficient if there are to be servers and routers with millions of simultaneous clients - I know most demuxing and route lookup is done through hashing algorithms (or in very fast boxes, through CAMs) but we don't ant to design/pick somethign that breaks this possibilty. 3. There is a good deal of fruitful research right now on Application Layer Framing and Integrated Layer Processing. There is also a fair amount of work on parallel implemenations of TCP/IP and other protocol stacks. Anything we do to IPng, should enhance both these possibilities. 4. ATM is coming whether we like it or not, at least as a WAN substrate, and backbone/hub LAN replacement for FDDI. the size of a minimum packet (e.g. TCPng/IPng) must not exceed a single ATM cell size or dire performance effects may happen...other 'super-fragmentation' effects should be anticipated. 5. the relative performance (throughput) of backbones and sites is now very close - in the past, the backbbone has more typically been 1-2 orders of magnitute behind the site or host access speed - the effect is that remote information servers (centrally/nationally provided for instance) are more attractive than they were - this means that the "natural" balance where 10% of site trasffic was off-site, is disturbed - this means traffic aggregation models may well change ... this trend may increase as there will nearly be a glut of wide area bandwidth (and wide area switches may get fast enough..) But if most traffic is going to be non-local, then most traffic will be in a large delay line....how does this affect congesiton/traffic control inside the net? does that affect the protocol design/choice? can we still get away with the datagram/end-sys congestion model? 6. As the scale of the net changes, the %age availability may actually decrease (since longer haul nets will move into more and more areas where there are physical problems) - this needs thinking about. 7. The hop count in the internet has grown somewhat (went from 3 hops from my machine to a.isi.edu to over 20 now....) - wil lthis continue? what affect does it have if any? on global routing From mankin@radegond.cmf.nrl.navy.mil Fri Feb 25 18:35:47 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA06626; Fri, 25 Feb 1994 18:35:52 -0500 Received: from localhost by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA18693; Fri, 25 Feb 94 18:35:48 EST Message-Id: <9402252335.AA18693@radegond.cmf.nrl.navy.mil> To: craig@aland.bbn.com, ipng@radegond.cmf.nrl.navy.mil Subject: FWD: re IPng Requirements Date: Fri, 25 Feb 1994 18:35:47 -0500 From: Allison J Mankin Hi, Craig, I slipped and didn't add ipng to the address of the first message. I've now forwarded that and herewith yours. Thanks for taking time out to discuss this. Allison (and for redoing the draft!) ------- Forwarded Message Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA06569 for ; Fri, 25 Feb 1994 18:23:48 -0500 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA21412 for mankin@cmf.nrl.navy.mil; Fri, 25 Feb 94 18:23:08 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id PAA19896; Fri, 25 Feb 1994 15:22:09 -0800 Message-Id: <199402252322.PAA19896@aland.bbn.com> To: Allison J Mankin Cc: craig@aland.bbn.com, j.crowcroft@cs.ucl.ac.uk, kasten@ftp.com Subject: Re: IPng Requirements In-Reply-To: Your message of Fri, 25 Feb 94 17:37:03 -0500. <9402252237.AA18547@radegond.cmf.nrl.navy.mil> From: Craig Partridge Date: Fri, 25 Feb 94 15:22:07 -0800 Sender: craig@aland.bbn.com Hi Allison: Thanks for forwarding Jon's note. And I think it is great Jon's joining Frank. (Jon and Frank, sorry I'm so swamped that I can't help out more). I'll do my best on joining telechats (god help me, I gotta go buy a telephone headset). And, since I have a free 15 minutes, I thought I'd try to reply to Jon's note, since I'd actually thought a bit about some of these topics and there are reasons I didn't want them in the criteria. 1. IPv4 is 14 years old. In 1980, folks had the foresight to predict 32Bit machines being common (they were not then) and design a protocol that ran on LSI/11s fast enough to drive 56kbps lines, but without change, can now run 10,000 times faster. Do we really believe we can design a network layer that can last til 2008 without change, were it may have to run at 500 terrabits (the equivalent speedup)? - this may sound crazy, but i bet if you'd asked postel in 1980 about a 500Mbps lan, he might have worried a bit about the design. I know this merely spports the datagram model, but it does bring in questions of silicon costs...and pure optical complexity I really don't know. There's a point where my telescope into the future runs out, and it is about the year 2000. At about that time some folks think we'll see 10-50 GHz silicon. Using my crude models, that's good for 100 to 500 gigabits of IP data through a single bit of silicon. I can wave my hands and cry parallelism, and optimistically get up to around 50 terabits. But I've assumed we solve at least 3 hard problems (scaling memory rates to silicon rates, at least partially scaling peripheral access rates to silicon rates, and coordinating 100 IP processors in parallel). 2. Traffic aggregation models were not a big issue in a net designed to go to a few hundred sites - muxing/demuxing, and forwarding must be a lot more efficient if there are to be servers and routers with millions of simultaneous clients - I know most demuxing and route lookup is done through hashing algorithms (or in very fast boxes, through CAMs) but we don't ant to design/pick somethign that breaks this possibilty. Yep, but I think this is a secondary issue -- you have to organize the address space such that aggregation works. Provided the address space is big enough, I think this is doable (though I know we risk making the space a bit too small once we see how we divvy up the bits). 3. There is a good deal of fruitful research right now on Application Layer Framing and Integrated Layer Processing. There is also a fair amount of work on parallel implemenations of TCP/IP and other protocol stacks. Anything we do to IPng, should enhance both these possibilities. I think if we stick with a datagram model, this is a non-issue. (At least, that's my guess -- happy to be argued out of it and into making this a requirement. I certainly don't want to see an IPng model that doesn't permit parallel IP forwarding). 4. ATM is coming whether we like it or not, at least as a WAN substrate, and backbone/hub LAN replacement for FDDI. the size of a minimum packet (e.g. TCPng/IPng) must not exceed a single ATM cell size or dire performance effects may happen...other 'super-fragmentation' effects should be anticipated. Ware! Ware! This month the ATM backlash has finally started in the popular press. ATM may be the next FDDI (though I doubt it), or it may just become the new fractional T1 equivalent (quite possible), or it may really grow to be the mature switched service that some folks hope. But in any case, I think it is wrong to design an internetworking protocol with a particular LAN or WAN technology in mind. 5. the relative performance (throughput) of backbones and sites is now very close - in the past, the backbbone has more typically been 1-2 orders of magnitute behind the site or host access speed - the effect is that remote information servers (centrally/nationally provided for instance) are more attractive than they were - this means that the "natural" balance where 10% of site trasffic was off-site, is disturbed - this means traffic aggregation models may well change ... this trend may increase as there will nearly be a glut of wide area bandwidth (and wide area switches may get fast enough..) But if most traffic is going to be non-local, then most traffic will be in a large delay line....how does this affect congesiton/traffic control inside the net? does that affect the protocol design/choice? can we still get away with the datagram/end-sys congestion model? I haven't a clue about this. Is there a particular requirement we can articulate that folks might be able to answer. 6. As the scale of the net changes, the %age availability may actually decrease (since longer haul nets will move into more and more areas where there are physical problems) - this needs thinking about. I'm not sure I understand this point. 7. The hop count in the internet has grown somewhat (went from 3 hops from my machine to a.isi.edu to over 20 now....) - wil lthis continue? what affect does it have if any? on global routing I heard arguments both for the hop count decreasing and growing. Decreasing says we consolidate providers, they have smart backbones (unlike the IBM multihop per POP monstrosity) with short paths (maybe one hop to anywhere via ATM SVCs), and we're all happy. The other one says that because IP is so easy to string along in tail circuits, we keep growing. I dunno which answer is right. Fun and thought provoking note Jon -- thanks (I had fun working through it)! I hope the full directorate gets to see this? Craig ------- End of Forwarded Message From bound@zk3.dec.com Sat Feb 26 13:01:50 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA09299 for ; Sat, 26 Feb 1994 13:06:04 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA07455; Sat, 26 Feb 94 10:02:00 -0800 Received: by xirtlu.zk3.dec.com; id AA15041; Sat, 26 Feb 1994 13:01:56 -0500 Message-Id: <9402261801.AA15041@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: craig@aland.bbn.com, ipng@radegond.cmf.nrl.navy.mil, j.crowcroft@cs.ucl.ac.uk, kasten@ftp.com, bound@zk3.dec.com Subject: Re: FWD: re IPng Requirements In-Reply-To: Your message of "Fri, 25 Feb 94 18:35:47 EST." <9402252335.AA18693@radegond.cmf.nrl.navy.mil> Date: Sat, 26 Feb 94 13:01:50 -0500 X-Mts: smtp Allison, Quick view on the content of the last two mail messages about not being able to architect a solution that is beyond 2000-2010 (or whatever). First I think this is mostly guess work on the part of any architect or scientist. The way to reduce guess work is to accumulate enough data to support ones core assumptions. But, within a time frame that you deliver a solution before the problem gets so bad the patient dies. In this case the patient is the Internet and I believe the TCP/IP protocol suite in general. One White Paper we received was from Bob Hinden on his overview of SIPP. Whether we select SIPP, TUBA, or CATNIP (or all three somehow), Bob's paper had an introductory section on what would drive networking in the market in the near future. Basically he stated that networking has been driven by the computer market, and a shift would take place soon to the information utility infrastructure market. Most of us have worked in the industry for at least 20 years and have seen some amazing accomplishments to evolve to distributed computing. The next shift will bring distributed services to two types of users via the information utility infrastructure: those six feet from the interface (TV - home computing) and those six inches from the interface (desk top). Our requirements need to address both of these user types because both will require the Internet and TCP/IP. Right now its my impression our objective is: 1) to solve the network layer and its components problem (I assume we all understand this problem), 2) verify what affect it has on layers above the network and what needs to be defined to keep the existing applications executing, 3) define what emerging technology needs to be addressed while we are re-defining the network layer and its components. Its my impression from discussions with various some IETF folks that #3 above is not important. I think it is an absolute requirement to address #3 in the IPng solution. A solution that just provides same old IPv4 will not last 20 years. A solution that takes into account #3 can last 20 years or we just have not done a good job at our guess work and we have failed. I would rather try and maybe fail than give the market a solution that has to be re-done in 8-10 years. The trick is to make sure IPng is extensible like the architectural strategy of X-Windows at M.I.T. in the 80s, as just an example. In conclusion, I talk to customers and I know of very few customers who do not want IPng to incorporate #3 into the solution. I know of many political entities in the market who would like #3 removed from the goals. But, most of the political entities don't do squat to increase the revenue streams of mine or other companies that build computer systems products. So guess which one I am going to take seriously. p.s. I have read the first cut at criteria.txt doc and think its on the right track. I do believe regarding the section on IPng only and IPv4 only that the doc should not say it is not a requirement, because some of us believe it is. I view any proposal (per our Mbone minutes on this topic which was open to the public IETF ) that can do this as added value to IPng. We have come up with many reasons why IPng only systems will and must exist in the market. We also determined that some systems could stay IPv4 for a very long time. These two systems will be required to communicate and interoperate by my customers. Sincerely, /jim From jcurran@nic.near.net Sun Feb 27 02:32:38 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.4/8.6.4) with SMTP id CAA11007 for ; Sun, 27 Feb 1994 02:32:46 -0500 Received: from nic.near.net by nic.near.net id aa20974; 27 Feb 94 7:32 GMT To: craig@aland.bbn.com, j.crowcroft@cs.ucl.ac.uk, kasten@ftp.com cc: ipng@cmf.nrl.navy.mil Subject: Comments on the revised Criteria draft Date: Sun, 27 Feb 1994 02:32:38 -0500 From: John Curran Message-ID: <9402270732.aa20974@nic.near.net> First, thanks to Craig, Frank (and now Jon) for working on this document. I agree with the vast majority of the document, and in particular think that the "General Principles" section is very important to get directorate consensus on. Specific comments follow. /John --- ] 4.1. Architectural Simplicity ] ] In anything at all, perfection is finally attained not ] when there is no longer anything to add, but when ] there is no longer anything to take away. It might be worth noting that Artchitectural Simplicity removes both (mis)configuration and failure modes and as such is a _very_ good thing. ] 4.2. One Protocol to Bind Them All ] ] One of the most important aspects of The Internet is that it ] provides global IP-layer connectivity. The IP-layer provides ] the point of commonality among all of the nodes on the ] Internet. In effect, the main goal of the Internet is to ] provide an IP Connectivity Service to all who wish it. There is some basis for arguing that "global IP-layer" service has not been anywhere near as important as global TCP and UDP service. The ultimate test for this would be consider whether a hypothetical Internet offering end-to-end worldwide TCP and UDP services over multiple network layers was more or less valuable than a hypothetical Internet which provided "global IPng-layer connectivity" but lacked globally-defined transport protocols. ] 4.3. Live Long ] ] It is very difficult to change a protocol as central to the ] workings of the Internet as IP. Even more problematic is ] changing such a protocol frequently. This simply can not be ] done. We believe that it is impossible to expect the community ] to make significant, non-backward compatible changes to the IP ] layer more often than once every 10-15 years. In order to be ] conservative, we strongly urge protocol developers to consider ] what the Internet will look like in 20 years and design their ] protocols to fit that vision. While it will always be possible for parts of the Internet to be running more modern version of IP, the use of IPng in embedded systems, appliances, wall sockets, etc. may demand IPng have a greater than a 20-year period of interoperability. ] 4.4. Live Long AND Prosper ] ] We believe that simply allowing for bigger addresses and more ] efficient routing is not enough of a benefit to encourage ] vendors, service providers, and users to switch to IP:ng, with ] its attendant disruptions of service, etc. These problems can ] be solved much more simply with more router-thrust, ] balkanization of the Internet, and so on. ] ] We believe that there must be positive, functional or ] operational, benefits to switching to IP:ng. Absolutely. Address depletion may have caused us to look at IPng, but it cannot be the primary motivation for deployment. ] 5.3. Robust Service ] ] CRITERION ] The network service and its associated routing and ] control protocols must be robust. ] ] DISCUSSION ] Murphy's Law applies to networking. Any proposed IP:ng ] protocol must be well-behaved in the face of malformed ] packets, mis-information, and occasional failures of ] links, routers and hosts. IP:ng should perform ] gracefully in response to willful management and ] configuration mistakes (i.e. service outages should be ] minimized). ] ... ] Time Frame ] We believe that the elements of Robust Service should be ] available immediately in the protocol with two ] exceptions. ] ] The security aspects of Robust Service are, in fact, ] described elsewhere in this document. ] ] Protection against Byzantine failure modes is not needed ] immediately. A proposed architecture for it should be ] done immediately. Prototype development should be ] completed in 12-18 months, with final deployment as ] needed. Provision of robust service requires that the possible failure modes of IPng are well-documented and understood. Is it too much to ask proposals to list potential failures modes and the resulting conditions as seen by the end-user? ] 5.6. Unreliable Datagram Service ] ] CRITERION ] The protocol must support an unreliable datagram delivery ] service. ] ] DISCUSSION ] We like IP's datagram service and it seems to work very ] well. So we must keep it. Does the unreliable datagram delivery service have to simply be a sufficient replacement for IPv4, or does it have to benefit from any and all of the other IPng capabilities such as mobility, resource flows, security, etc. ? (i.e. "can new IPng capabilities be considered satisfied if they're only available to non-datagram based traffic?") ] 5.7. Configuration, Administration, and Operation ] ] CRITERION ] The protocol must permit easy and largely distributed ] configuration and operation. Automatic configuration of ] hosts and routers is required. ] ] DISCUSSION ] People complain that IP is hard to manage. We cannot ] plug and play. We must fix that problem. ] ] We do note that fully automated configuration, especially ] for large, complex networks, is still a topic of ] research. Our concern is mostly for small and medium ] sized, less complex, networks; places where the essential ] knowledge and skills would not be as readily available. ] .... ] Placement ] The actual protocols to do this will not be necessary ] until the IP:ng is widely fielded. However, a Proof of ] Concept or a general description of how these things are ] to be accomplished should be immediately provided. I strongly disagree with the placement of this item, as it will be impossible to field the actual protocols for autoconfiguration unless it is deployed as an integral part of IPng. ] 5.9. Unique Naming ] ] CRITERION ] IP:ng must assign all IP-Layer objects in the global, ] ubiquitous, Internet unique names. ] ] DISCUSSION ] We use the term "Name" in this criterion synonymously ] with the term "End Point Identifier" as used in the ] NIMROD proposal, or as IP Addresses uniquely identify ] interfaces/hosts in IPv4. ] ] The authors are not convinced that this ought to be a ] criterion of the protocol. We feel that it may in fact be ] a part of a solution to other criteria and as such, is ] not a criterion of its own. The BOF expressed a very ] strong desire to include this criterion and we are ] placing it here in the hope that it will stimulate ] discussion on the subject. Perhaps a rephrasing would make this item more desirable? IPng must provide addresses which are suitable for use as globally-unique ubiquitous names, or must provide an additional identifier space which is suitable for this purpose. Does this preserve the intent of the BOF? ] 5.10. Access ] ] CRITERION ] The protocols that define IP:ng, its associated protocols ] (similar to ARP and ICMP in IPv4) and the routing ] protocols (as in OSPF, BGP, and RIP for IPv4) must be ] published as standards track RFCs. These documents must ] be as freely available and redistributable as the IPv4 ] and related RFCs. There must be no licensing fees for ] implementing or selling IP:ng software. Welcome to politics. The second sentence ("These documents must be as freely available and redistributable ...") can be struck as the open distribution requirements for standards track RFC's is already clearly documented. The third sentence ("There must be no licensing fees for implementing or selling IP:ng software") may preclude using important technology that the IETF decides to make use of in IPng, even in the presence of an agreement for open and fair licensing. This is particularly true of security-related encryption, and it is hubris on the IETF's part to declare that IPng will not make use of any licensed technology and yet will meet all of the requirements before us. ] 5.11. Addressing ] ] CRITERION ] The protocol must allow for both unicast and multicast ] addressing. Part of the multicast capability is a ] requirement to be able to send to "all IP hosts on THIS ] network". Dynamic and automatic routing of multicasts is ] also required. Request that "on THIS network" be replaced with "on a given subnetwork". It is quite posible that IPng will use a classless, multiple subnetwork per datalink network model, where the interpetion of "THIS" network is not clear. ] 5.13. Support for Guaranteed Flows ] ] CRITERION ] The protocol should support guaranteed flows. ] ... ] Time Frame ] This should be available within 24 months. Does this mean that the basic architecture for supporting such flows will be part of IPng-initial, so that the flows will function over the deployed network once controlling software is made available, or does this mean that the basic protocols will be defined within 24 months (and then require upgrade of any existing IPng-initial infrastructure)? From brian@dxcoms.cern.ch Sun Feb 27 16:47:39 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA11940 for ; Sun, 27 Feb 1994 10:49:35 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05784; Sun, 27 Feb 1994 16:47:41 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22759; Sun, 27 Feb 1994 16:47:40 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402271547.AA22759@dxcoms.cern.ch> Subject: Re: IPng Requirements To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Sun, 27 Feb 1994 16:47:39 +0100 (MET) Cc: ipng@picard.cmf.nrl.navy.mil, jon@cs.ucl.ac.uk, kasten@ftp.com In-Reply-To: <9402252332.AA18685@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Feb 25, 94 06:32:10 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1769 Hi, Just some remarks on the current state of criteria.txt. 1. I think we should rename it issues.txt in the next version. "Criteria" is just too emotive. 2. Most of what I want to say is in my own white paper, which I will revise in a day or two (thanks Dino et al for the comments received). However I note that the words "firewall", "policy routing" and "statistics" do not appear in the document, and "accounting" only appears to say it was taken out after the Washington BOF. This is just not POSSIBLE if you want the people who run businesses to use IPng. These issues have to be addressed: how does IPng improve firewalls, enable policy routing, provide statistics, and make accounting possible? 3. Additional point on multicast: I think it is important to say that multicast packets should never go twice over the same wire (whether WAN or LAN). One proposal I saw means that every multicast packet on a LAN travels the wire twice, which would halve the maximum number of simultaneous video conferences on a single LAN. 4. On Jon's point re ATM: I worried a lot about this some time back; I'm less sure now that it is manadatory for one-byte TCP packets to fit in a single cell. This will not determine bulk data performance on ATM. Are we trying to optimise telnet over ATM? I'm logged in from home at 14.4 kbaud, and I can't type or read fast enogh to notice the line speed. 5. On Jon's point about the IPng process: If ALE says we have ten years to live, fine, we can relax. But IPng implementation (+any changes needed above the API) + beta testing by multiple vendors will take 3 years, optimistically, and widespread deployment will take another 3 years, again optimistically. So if ALE says we have five years, we are in trouble. -- Brian From lkeiper@IETF.CNRI.Reston.VA.US Mon Feb 28 10:27:56 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA16126 for ; Mon, 28 Feb 1994 10:27:56 -0500 Date: Mon, 28 Feb 1994 10:27:56 -0500 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa02688; 28 Feb 94 10:26 EST X-Sender: lkeiper@ietf.cnri.reston.va.us Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Steve Coya MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US Subject: MINUTES VOLUNTEER/ipng Final****** Cc: lkeiper@IETF.CNRI.Reston.VA.US Message-ID: <9402281026.aa02688@IETF.CNRI.Reston.VA.US> FINAL**** The names marked with an asterisk are those who have confirmed participation for the IPng teleconference scheduled for Monday February 28, 1994, 11;30 am EST - 1:30pm EST. Please send your confirmation of participation or regrets to Lois Keiper @ lkeiper@cnri.reston.va.us. Thank you for your cooperation. ***NEED VOLUNTEER TO ASSUME MINUTES ROLE-If interested please let me know, Steve is very ill, and unable to attend and fulfill his duties. I will take the role call in his place. THANK YOU! J. Allard 206-936-9031 Steve Bellovin 908-582-5886 *Jim Bound 603-465-3130* *Scott Bradner will call in* Alison Mankin 202-404-7030 *Ross Callon 508-436-3936* *Brian Carpenter +41 22 767 4967* Dave Clark 617-253-6003 *Steve Coya REGRETS-ILL TODAY* *John Curran 617-873-4398* *Steve Deering 415-812-4839* *Dino Farinacci 408-226-6870* *Eric Fleischman 206-957-5334* -Paul Francis Regrets Dan Karrenberg +31 20 592 5065 *Mark Knopper 313-741-5445* *Greg Minshall 510-975-4507* *Paul Mockapetris 310-592-1774* *Rob Ullmann 617-693-1315* Lixia Zhang 415-812-4415 If you need to be added to the teleconference in progress, please call 1-800-232-1234 or 516-424-3151 for the international participants. The call can bereferenced by the confirmation number ER13193 in the orginators name, Steve Coya. Thanks, Lois From kasten@tri-flow.ftp.com Mon Feb 28 10:37:33 1994 Return-Path: kasten@tri-flow.ftp.com Received: from babyoil.ftp.com (babyoil.ftp.com [128.127.2.105]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA16275 for ; Mon, 28 Feb 1994 10:43:06 -0500 Received: from tri-flow.ftp.com by babyoil.ftp.com with SMTP id AA00437; Mon, 28 Feb 94 10:38:26 -0500 Received: by tri-flow.ftp.com.ftp.com (5.0/SMI-SVR4) id AA12061; Mon, 28 Feb 94 10:37:33 EST Date: Mon, 28 Feb 94 10:37:33 EST Message-Id: <9402281537.AA12061@tri-flow.ftp.com.ftp.com> To: jcurran@nic.near.net Subject: Re: Comments on the revised Criteria draft From: kasten@tri-flow.ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com, j.crowcroft@cs.ucl.ac.uk, ipng@cmf.nrl.navy.mil Content-Length: 6153 John, Thanks for your comments.... > There is some basis for arguing that "global IP-layer" service > has not been anywhere near as important as global TCP and UDP > service. The ultimate test for this would be consider whether > a hypothetical Internet offering end-to-end worldwide TCP and UDP > services over multiple network layers was more or less valuable > than a hypothetical Internet which provided "global IPng-layer > connectivity" but lacked globally-defined transport protocols. I thought about this a bit. Then realized that it makes sense to have the protocol element that is common to all Internet Protocol Suite nodes (i.e. IP) be the level at which there is global connectivity. As long as there is global-IP connectivity, I can experiment with new supra-IP protocols (transports, control protocols, whatever). If global connectivity is provided by TCP and UDP then I can't experiment with Frank's Transport Protocol (I'd call it FTP -- but I've heard that name's been taken :-) on a global basis. > While it will always be possible for parts of the Internet to > be running more modern version of IP, the use of IPng in embedded > systems, appliances, wall sockets, etc. may demand IPng have a > greater than a 20-year period of interoperability. An alternative is that IPng is not the protocol to stick into wall sockets... > Provision of robust service requires that the possible failure > modes of IPng are well-documented and understood. Is it too much > to ask proposals to list potential failures modes and the resulting > conditions as seen by the end-user? At a recent IETF (Columbus?), there was a presentation at of all the then IPng candidates on their protocols at one of the plenary meetings. I asked them all something to the effect of "What's a risk/problem/down-side/failure-mode/bad-thing about your protocol?" All answers parsed down to "None". > Does the unreliable datagram delivery service have to simply be > a sufficient replacement for IPv4, or does it have to benefit > from any and all of the other IPng capabilities such as mobility, > resource flows, security, etc. ? (i.e. "can new IPng capabilities > be considered satisfied if they're only available to non-datagram > based traffic?") I hadn't really thought about it. I suppose that I can come up with arguments each way. > ] 5.9. Unique Naming > > Perhaps a rephrasing would make this item more desirable? > > IPng must provide addresses which are suitable for use > as globally-unique ubiquitous names, or must provide an > additional identifier space which is suitable for this > purpose. > > Does this preserve the intent of the BOF? To be perfectly honest, I have no idea what the intent of the BOF was -- it was so long ago... Though some cleaning of the text might be in order. > > ] 5.10. Access > ] > ] CRITERION > ] The protocols that define IP:ng, its associated protocols > ] (similar to ARP and ICMP in IPv4) and the routing > ] protocols (as in OSPF, BGP, and RIP for IPv4) must be > ] published as standards track RFCs. These documents must > ] be as freely available and redistributable as the IPv4 > ] and related RFCs. There must be no licensing fees for > ] implementing or selling IP:ng software. > > Welcome to politics. The second sentence ("These documents must > be as freely available and redistributable ...") can be struck as > the open distribution requirements for standards track RFC's is > already clearly documented. I guess that we can change this to point to rfc 1310. > The third sentence ("There must be > no licensing fees for implementing or selling IP:ng software") > may preclude using important technology that the IETF decides to > make use of in IPng, even in the presence of an agreement for open > and fair licensing. This is particularly true of security-related > encryption, and it is hubris on the IETF's part to declare that IPng > will not make use of any licensed technology and yet will meet all > of the requirements before us. First, I doubt that any one protocol will meet everyone's expectations or goals. The idea of having the requirements is that they will serve to focus people's attentions on what the problems are. Someone might say "Can't do X without paying royalties to Y" but then, some other person might figure out how to do X and NOT pay royalties.... Second, IPv4 is implementable without paying anyone for a license. IPv4 has been very very very widely implemented. I think that there is some cause and effect here. I believe that Internetworking as a whole has strongly benefited from this. I think that we should continue in this manner. Yes, it is religion. I'd rather someone comes along and says "You absolutely can not do X" before I consider changing my religion. > ] 5.13. Support for Guaranteed Flows > ] Time Frame > ] This should be available within 24 months. > > Does this mean that the basic architecture for supporting such flows > will be part of IPng-initial, so that the flows will function over the > deployed network once controlling software is made available, or does > this mean that the basic protocols will be defined within 24 months > (and then require upgrade of any existing IPng-initial infrastructure)? Generally, I imagine that if we've thought enough of a particular bit of technology to include it in the document (e.g. flows in this case), then we probably understand enough of the technology to decide that it is (probably going to be) very very useful. Therefore, we should be able to sit down with Dr. Protocol-Designer and the good Dr should be able to show us how we will get that bit of technology in the desired time frame. I do not see these time frames as "deployment schedules" since those will depend on non-technological issues (eg when can Nearnet get the funding to buy the next release of router hardware/software and things like that). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From kasten@tri-flow.ftp.com Mon Feb 28 10:37:35 1994 Return-Path: kasten@tri-flow.ftp.com Received: from babyoil.ftp.com (babyoil.ftp.com [128.127.2.105]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA16236 for ; Mon, 28 Feb 1994 10:38:14 -0500 Received: from tri-flow.ftp.com by babyoil.ftp.com with SMTP id AA00439; Mon, 28 Feb 94 10:38:27 -0500 Received: by tri-flow.ftp.com.ftp.com (5.0/SMI-SVR4) id AA12064; Mon, 28 Feb 94 10:37:35 EST Date: Mon, 28 Feb 94 10:37:35 EST Message-Id: <9402281537.AA12064@tri-flow.ftp.com.ftp.com> To: Brian.Carpenter@cern.ch Subject: Re: IPng Requirements From: kasten@tri-flow.ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@picard.cmf.nrl.navy.mil, jon@cs.ucl.ac.uk, craig@aland.bbn.com Content-Length: 1454 > 2. Most of what I want to say is in my own white paper, which I will > revise in a day or two (thanks Dino et al for the comments received). > > However I note that the words "firewall", "policy routing" and > "statistics" do not appear in the document, and "accounting" only > appears to say it was taken out after the Washington BOF. > > This is just not POSSIBLE if you want the people who run businesses > to use IPng. These issues have to be addressed: how does IPng > improve firewalls, enable policy routing, provide statistics, > and make accounting possible? When we were working on the original paper, I thought alot about network management, statistics, accounting and the like. I came to the conclusion that these were not really attributes of the protocol itself. Whatever IPng is, the SNMP people will have to make the necesary MIBs for it, and so on. Sort of like saying that you must redefine the TCP pseudo-header to work with ipng (and FTP's use of IP addresses and DNS and so on and so forth). I thought that these were not really necessary to state. As to firewalls, I see this as a solution, rather than a problem. The problem is that one needs security (which we state). Firewalls are one way to get it. I strongly resist the notion of including, per se, firewalls in the document. I hadn't considered policy at all. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From jcurran@nic.near.net Mon Feb 28 11:47:13 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.4/8.6.4) with SMTP id LAA16891 for ; Mon, 28 Feb 1994 11:49:04 -0500 Received: from platinum.near.net by nic.near.net id aa03321; 28 Feb 94 16:48 GMT To: kasten@ftp.com cc: craig@aland.bbn.com, j.crowcroft@cs.ucl.ac.uk, ipng@cmf.nrl.navy.mil Subject: Re: Comments on the revised Criteria draft In-reply-to: Your message of Mon, 28 Feb 1994 10:37:33 -0500. <9402281537.AA12061@tri-flow.ftp.com.ftp.com> Date: Mon, 28 Feb 1994 11:47:13 -0500 From: John Curran Message-ID: <9402281648.aa03321@nic.near.net> -------- ] From: Frank Kastenholz ] Subject: Re: Comments on the revised Criteria draft ] Date: Mon, 28 Feb 94 10:37:33 EST ] ] John, ] ] Thanks for your comments.... ] ] > There is some basis for arguing that "global IP-layer" service ] > has not been anywhere near as important as global TCP and UDP ] > service. The ultimate test for this would be consider whether ] > a hypothetical Internet offering end-to-end worldwide TCP and UDP ] > services over multiple network layers was more or less valuable ] > than a hypothetical Internet which provided "global IPng-layer ] > connectivity" but lacked globally-defined transport protocols. ] ] I thought about this a bit. Then realized that it makes sense to have ] the protocol element that is common to all Internet Protocol Suite ] nodes (i.e. IP) be the level at which there is global connectivity. ] As long as there is global-IP connectivity, I can experiment with new ] supra-IP protocols (transports, control protocols, whatever). If ] global connectivity is provided by TCP and UDP then I can't ] experiment with Frank's Transport Protocol (I'd call it FTP -- but ] I've heard that name's been taken :-) on a global basis. True.... but that sword cuts both ways: If the transport layer provides the global end-to-end connectivity, then we gain the freedom to deploy new network layer protocols (not that we'd ever find ourselves doing such a thing... :-) ] > While it will always be possible for parts of the Internet to ] > be running more modern version of IP, the use of IPng in embedded ] > systems, appliances, wall sockets, etc. may demand IPng have a ] > greater than a 20-year period of interoperability. ] ] An alternative is that IPng is not the protocol to stick into wall ] sockets... No problem. Put a statement to that effect on paper, get consensus, and then we're all set. (Until then, we need to fight a _perceived_ need to have a >20 year lifetime.) ] > Provision of robust service requires that the possible failure ] > modes of IPng are well-documented and understood. Is it too much ] > to ask proposals to list potential failures modes and the resulting ] > conditions as seen by the end-user? ] ] At a recent IETF (Columbus?), there was a presentation at of all the ] then IPng candidates on their protocols at one of the plenary ] meetings. I asked them all something to the effect of "What's a ] risk/problem/down-side/failure-mode/bad-thing about your protocol?" ] All answers parsed down to "None". Please... I don't expect that proposal candidates to be honest about the possible ways that the proposals can fail, I'm just saying for each configuration option, there exists a _mis_configuration failure mode. Count up the number of configuration elements, and then (2**N)-1 is the number of failure modes. I am very thankful that most software does not allow changing of TCP timers or ARP timeouts, or I'd be fixing dozens of New England systems daily. ] > Does the unreliable datagram delivery service have to simply be ] > a sufficient replacement for IPv4, or does it have to benefit ] > from any and all of the other IPng capabilities such as mobility, ] > resource flows, security, etc. ? (i.e. "can new IPng capabilities ] > be considered satisfied if they're only available to non-datagram ] > based traffic?") ] ] I hadn't really thought about it. I suppose that I can come up with ] arguments each way. In particular, security and mobility may be easier to provide in a connection-oriented transport service, and the question remains as to whether this would satisfy IPng requirements. ] > ] 5.10. Access ] > ] ] > ] CRITERION ] > ] The protocols that define IP:ng, its associated protocols ] > ] (similar to ARP and ICMP in IPv4) and the routing ] > ] protocols (as in OSPF, BGP, and RIP for IPv4) must be ] > ] published as standards track RFCs. These documents must ] > ] be as freely available and redistributable as the IPv4 ] > ] and related RFCs. There must be no licensing fees for ] > ] implementing or selling IP:ng software. ] > ] > Welcome to politics. The second sentence ("These documents must ] > be as freely available and redistributable ...") can be struck as ] > the open distribution requirements for standards track RFC's is ] > already clearly documented. ] ] I guess that we can change this to point to rfc 1310. ] ] > The third sentence ("There must be ] > no licensing fees for implementing or selling IP:ng software") ] > may preclude using important technology that the IETF decides to ] > make use of in IPng, even in the presence of an agreement for open ] > and fair licensing. This is particularly true of security-related ] > encryption, and it is hubris on the IETF's part to declare that IPng ] > will not make use of any licensed technology and yet will meet all ] > of the requirements before us. ] ] First, I doubt that any one protocol will meet everyone's expectations ] or goals. The idea of having the requirements is that they will serve ] to focus people's attentions on what the problems are. Someone might ] say "Can't do X without paying royalties to Y" but then, some other ] person might figure out how to do X and NOT pay royalties.... ] ] Second, IPv4 is implementable without paying anyone for a license. ] IPv4 has been very very very widely implemented. I think that there ] is some cause and effect here. I believe that Internetworking as a ] whole has strongly benefited from this. I think that we should ] continue in this manner. Yes, it is religion. I'd rather someone ] comes along and says "You absolutely can not do X" before I consider ] changing my religion. I agree "in general" with the philosophy. I would note that we all make use of technology (such as Ethernet) which is licensed and results in royalties being paid. I'd like to avoid having "licensing fees" for IPng, but see that a minimal fee may be unavoidable depending on the security technology adopted. ] > ] 5.13. Support for Guaranteed Flows ] > ] Time Frame ] > ] This should be available within 24 months. ] > ] > Does this mean that the basic architecture for supporting such flows ] > will be part of IPng-initial, so that the flows will function over the ] > deployed network once controlling software is made available, or does ] > this mean that the basic protocols will be defined within 24 months ] > (and then require upgrade of any existing IPng-initial infrastructure)? ] ] Generally, I imagine that if we've thought enough of a particular bit ] of technology to include it in the document (e.g. flows in this ] case), then we probably understand enough of the technology to decide ] that it is (probably going to be) very very useful. Therefore, we ] should be able to sit down with Dr. Protocol-Designer and the good Dr ] should be able to show us how we will get that bit of technology in ] the desired time frame. I do not see these time frames as "deployment ] schedules" since those will depend on non-technological issues (eg ] when can Nearnet get the funding to buy the next release of router ] hardware/software and things like that). Agreed... the concern is that a timeline for making the technology available does not address the realities of retroactive deployment. We've all lived with IP subnetting deployment, DNS deployment, and now CIDR deployment; the experience shows that it takes 5-7 years (in a period of extremely active growth) to make new networking technology pervasive. Hence (pending the findings of the ALE wg on the time available to us), it may be worth holding IPng 24 months to avoid an overall 5 year delay in flow deployment. /John From craig@aland.bbn.com Mon Feb 28 08:50:55 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA16984 for ; Mon, 28 Feb 1994 11:55:49 -0500 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA27494 for ipng@cmf.nrl.navy.mil; Mon, 28 Feb 94 11:52:01 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA21121; Mon, 28 Feb 1994 08:50:58 -0800 Message-Id: <199402281650.IAA21121@aland.bbn.com> To: John Curran Cc: craig@aland.bbn.com, j.crowcroft@cs.ucl.ac.uk, kasten@ftp.com, ipng@cmf.nrl.navy.mil Subject: Re: Comments on the revised Criteria draft In-Reply-To: Your message of Sun, 27 Feb 94 02:32:38 -0500. <9402270732.aa20974@nic.near.net> From: Craig Partridge Date: Mon, 28 Feb 94 08:50:55 -0800 Sender: craig@aland.bbn.com ] 4.2. One Protocol to Bind Them All ] ] One of the most important aspects of The Internet is that it ] provides global IP-layer connectivity. The IP-layer provides ] the point of commonality among all of the nodes on the ] Internet. In effect, the main goal of the Internet is to ] provide an IP Connectivity Service to all who wish it. There is some basis for arguing that "global IP-layer" service has not been anywhere near as important as global TCP and UDP service. The ultimate test for this would be consider whether a hypothetical Internet offering end-to-end worldwide TCP and UDP services over multiple network layers was more or less valuable than a hypothetical Internet which provided "global IPng-layer connectivity" but lacked globally-defined transport protocols. I think this doesn't work. It says that TCP and UDP are the globally sufficient solutions (which given the frequency with which new transport protocols appear, probably isn't true -- note transport protocols seem to be a more popular fiddling point than the internetwork protocol). ] 5.6. Unreliable Datagram Service ] ] CRITERION ] The protocol must support an unreliable datagram delivery ] service. ] ] DISCUSSION ] We like IP's datagram service and it seems to work very ] well. So we must keep it. Does the unreliable datagram delivery service have to simply be a sufficient replacement for IPv4, or does it have to benefit from any and all of the other IPng capabilities such as mobility, resource flows, security, etc. ? (i.e. "can new IPng capabilities be considered satisfied if they're only available to non-datagram based traffic?") Well, we need to be clear about what is intended here. The idea is that IP's ability to launch an idempotent datagram, without pre-arrangement, is extremely valuable (arguably what makes IP so popular) and should be retained. ] 5.9. Unique Naming ] ] CRITERION ] IP:ng must assign all IP-Layer objects in the global, ] ubiquitous, Internet unique names. ] ] DISCUSSION ] We use the term "Name" in this criterion synonymously ] with the term "End Point Identifier" as used in the ] NIMROD proposal, or as IP Addresses uniquely identify ] interfaces/hosts in IPv4. ] ] The authors are not convinced that this ought to be a ] criterion of the protocol. We feel that it may in fact be ] a part of a solution to other criteria and as such, is ] not a criterion of its own. The BOF expressed a very ] strong desire to include this criterion and we are ] placing it here in the hope that it will stimulate ] discussion on the subject. Perhaps a rephrasing would make this item more desirable? IPng must provide addresses which are suitable for use as globally-unique ubiquitous names, or must provide an additional identifier space which is suitable for this purpose. Does this preserve the intent of the BOF? My recollection (very vague) of the BOF is that two points were raised. First a globally unique name in each packet was required for security (for reasons not explained). Second, that folks wanted, given a j-random datagram, to be able to examine that datagram and figure out exactly who sent it, without having to do stuff like unwind flow IDs backwards on the path. So I'd say the rephrasing isn't quite consistent with the BOF in that it isn't clearly that the unique ID must be in every datagram. ] 5.10. Access ] ] CRITERION ] The protocols that define IP:ng, its associated protocols ] (similar to ARP and ICMP in IPv4) and the routing ] protocols (as in OSPF, BGP, and RIP for IPv4) must be ] published as standards track RFCs. These documents must ] be as freely available and redistributable as the IPv4 ] and related RFCs. There must be no licensing fees for ] implementing or selling IP:ng software. Welcome to politics. The second sentence ("These documents must be as freely available and redistributable ...") can be struck as the open distribution requirements for standards track RFC's is already clearly documented. The third sentence ("There must be no licensing fees for implementing or selling IP:ng software") may preclude using important technology that the IETF decides to make use of in IPng, even in the presence of an agreement for open and fair licensing. This is particularly true of security-related encryption, and it is hubris on the IETF's part to declare that IPng will not make use of any licensed technology and yet will meet all of the requirements before us. I feel very strongly about the last point. Any licensing arrangement makes it harder for folks to put the software on-line for anonymous FTP and increases the startup cost for little companies. ] 5.11. Addressing ] ] CRITERION ] The protocol must allow for both unicast and multicast ] addressing. Part of the multicast capability is a ] requirement to be able to send to "all IP hosts on THIS ] network". Dynamic and automatic routing of multicasts is ] also required. Request that "on THIS network" be replaced with "on a given subnetwork". Fine. Craig From mankin Mon Feb 28 11:58:36 1994 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA17007 for ; Mon, 28 Feb 1994 11:58:39 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA22381; Mon, 28 Feb 94 11:58:36 EST Date: Mon, 28 Feb 94 11:58:36 EST Message-Id: <9402281658.AA22381@radegond.cmf.nrl.navy.mil> To: ipng The IPng selection process Scott Bradner, Harvard University Allison Mankin, NRL A new area was formed by the IESG on 7 Sept. 1993 to consolidate all aspects of the process of selecting a replacement for IPv4. This new area was designated as the IP: Next Generation, or IPng, area. It is a temporary area which will be dissolved after the selection process has been completed. We were asked to assume the duty of area directors on this new area (while not being excused from our existing duties as the area directors of the transport and operational requirements areas.) The working groups responsible for the development of the three current proposals for IPng were moved into the IPng area. They will disband, return to the Internet area, or become part of an IPng deployment area, when the IPng temporary area finishes its work. Formation of the IPng area. In the document "A Direction for IPng" (see ppxx) the IESG chair presented a brief description of the IPDecide BOF and other IPng activities during the Amsterdam IETF meeting, followed by a set of general direction statements, the announcement of the formation of the IPng area, and a specific charge to the new area. This article describes how the co-directors of the IPng area have decided to fulfill this charge and to "develop a recommendation on which, if any, of the current proposals should be adopted as the "next IP". As with all IETF areas, we were given considerable latitude to define the structure of the IPng area and the process by which the selection will be made. Some parts of the area structure and process were dictated by the charge, including the requirement of a directorate and the adoption of a policy of fully open discussions. Following traditional IETF practice, new working groups have been established to focus on specific aspects of the selection process. In addition we have established an expert panel, and are soliciting white papers to be used during the determination of the requirements for IPng and during the deliberation process. White Papers In a new process for the IETF, the IPng area is inviting the submission of white papers from the wider networking community (see RFC 1550, ppxx). The papers fall into two categories: they can help define the requirements for an IPng or they can offer suggestions or solutions to these problems. The white papers are used as resource material for the working groups, as an information repository, and as a part of the permanent record of the IPng effort. Some white papers have been specifically solicited from directorate members to indicate biases and opinions, from people active on big- internet, from IETF and non IETF researchers in the data networking field, from specific businesses, and from industry groups. The white paper process is open to all and papers have been received from a wide range of individuals. In addition, overviews of the specific IPng proposals were requested in the same form as the white papers. Each of the white papers will be reviewed one or more times by members of the IPng directorate. The first review is to ensure that the ideas are presented completely and clearly. This review explicitly does not include a technical evaluation of the specific suggestions in the white paper. The results of the clarity review are then forwarded to the author(s). If the author(s) wish, a revised version of the paper can be submitted. If this is done, the new version will replace the older one. At this point the papers are made available to the community as internet- drafts. The internet drafts will then be reviewed for technical feasibility by members of the directorate and by the review panel. As is normal with internet drafts, the Internet community in general is expected to read and comment on the documents. After any revisions, the papers will be then reissued as Informational RFCs unless withdrawn by the author(s). Insure the best proposals. A similar review process has been set up to ensure that the proposals for IPng are as good as they can be. An IPng choice should be based on a technical evaluation of the proposal and not be influenced by unclear or incomplete specifications. Using the same procedures established for the white papers, each of the proposal documents will be first reviewed for clarity and completeness with the reviewers giving specific suggestions for improvement. Once the documents have passed muster in this phase, they will be reviewed for technical feasibility. Note that this technical review is done within the context of the proposal, that is, reviewers cannot request changes just because of a disagreement over the width of the address, for example. Open process The entire IPng process is as open as we can make it. We do not want any hint that this important choice was made in secret by some unknown group. Minutes are kept during all of the directorate meetings and placed in the IPng public archives along with the archives of the directorate mailing list. In addition, the directorate will hold open meetings during the regular IETF meetings, and it will offer one or more MBONE meetings, as well (one took place Jan. 25 1994). All of the IPng white papers and other documents are public documents except for the initial pre-clarity review version of the white papers. Using the normal IETF internet-drafts process ensures the public view of the development of requirements via white papers. Community input Just as the IPng process can not be executed in private, it must not be done by a group isolated from the ideas and concerns of the data networking community. The white paper solicitation, the open review process, open directorate meetings, open working group meetings and mailing lists all are part of an ongoing effort to keep the community informed about the state of the selection process, the assumptions and priorities being used, and to give the community a bases on which to comment on the process. IPng Working Groups All of the existing working groups involved in the development of the IPng proposals were moved into the IPng area. During the development of the proposals some of the working groups have merged or changed names. (see figure xx for a genealogical history of the current working groups.) (S. Knowles) New IPng working groups Three new working groups have been formed within the IPng area to develop information that will be used in the selection process and procedures that will be important after the selection is completed. Ascertain available time frame: A new IETF working group (Address Lifetime Expectations (ALE) ) has been formed to make estimates of the remaining useful lifetime of the address space used by the existing version of IP. The estimate will be made taking into account the use of CIDR, the changing address assignment policies, and the availability of additional procedural documentation showing how to make more efficient use of assigned space. Frank Solensky (FTP Software) and Tony Li (Cisco) chair. Determine IPng requirements and technology availability. A second group, IPng Requirements (IPNGREQ), is in place to complete the determination of the set of features and functions that a new IP should support. Since some of the desired features will require additional research and development, realistic estimates will be made for the availability timeframe for each of the features. This will be a short-running group with its major effort at the March IETF meeting in Seattle. Co-chairs are Jon Crowcroft (University College London) and Frank Kastenholtz (FTP Software). Develop strategies to deal with testing, transition and coexistence. A third working group, Transition And Coexistence Including Testing (TACIT), is in formation to develop an understanding of the operational issues involved in the migration of the Internet to a new internet protocol. There will be three chairs in all likelihood. Two have agreed to date, Atul Bansal (Digital) and Geoff Huston (AARnet). Since the Internet must now be viewed as a utility and must continue to function during any transitions to new technologies, particular emphasis will be placed on planning a testing process. There may be bugs in the initial set of standards and almost certainly there will be interoperability problems with the initial implementations. It is very important that by the time the new IP is deployed in a production network that it be as reliable as it can be. The IETF consensus is that IPng cannot be debugged in place. Since it is reasonable to expect that additional features will be added to IPng as time goes by (as features were added to the current IP), this group will be charged to create generic plans rather than target the existing proposals. IPng directorate The charge to the IPng area included a requirement that the area have a directorate to act as a direction-setting and preliminary review body. We took some time to recruit this panel. We wanted to be sure that the people we selected were recognized technical aces but also that in addition to being able to being able to articulate needs of corporation, customers, and community, they must be able to represent themselves. We did not want corporate mouth pieces. We asked advice from many sources inside and outside of IETF community while compiling the directorate. We wanted to insure that we had expertise in may areas including security, routing, international, national & regional network operations, large corporate networks, theoretical research, and protocol architecture, while insuring a depth of understanding on current IPng proposals. The directorate that we recruited includes J. Allard (Microsoft), Steve Bellovin (AT&T), Jim Bound (Digital), Ross Callon (Wellfleet), Brian Carpenter (CERN), Dave Clark (MIT), John Curran (NEARnet), Steve Deering (Xerox), Dino Farinacci (Cisco), Paul Francis (NTT), Eric Fleischmann (Boeing), Daniel Karrenberg (RARE), Mark Knopper (Ameritech), Greg Minshall (Novell), Paul Mockapetris (ISI), Rob Ullmann (Lotus) and Lixia Zhang (Xerox). The IPng directorate holds teleconferences about every two weeks. Minutes are kept for these teleconferences and the open directorate meetings that will be held during IETF meetings. The minutes are placed in the IPng public archives. We also ask that the IPng directorate members monitor and respond to the big-internet mailing list. We chose to use the big-internet list instead of creating a new list for the IPng effort since big- internet was well established and focused on the very issues that an IPng list would. External review panel The directorate provides the major review and quality control of the IPng Area results. At Dave Clark's suggestion, we added the external review panel, as a way to get review and advice from a larger cmmunity. The selection of IPng occurs during a time of remarkable growth for the Internet, in terms of its using population, markets, and potential applications. The expert review panel will offer views and input from individuals belonging to a wide range of industries, the cable industry, the classic telecommunications industry, and so on. It will also be the source of reviews by a key group of Internet thinkers, who for one reason or another did not join the directorate, but whose perspectives we did not want to risk not having. The responsibilities of the panel are to review the requirements document and the recommendation document. Note that the area co-directors view the entire IETF as the internal review panel. We have solicited input and review from many folks to date. We welcome the entire community to pitch in! IPng process The ALE and IPng requirements working groups are scheduled to produce final reports after the Seattle IETF meeting. At that time these reports will be combined to determine the final selection criteria. The proponents of each of the proposals will be asked to produce a white paper detailing how their proposal will meet the requirements and the associated timeframes. The proposal white papers will be reviewed by the IPng directorate and review panel and public comment will be invited. A draft of the final IPng selection, with whatever specific suggestions may be warranted, will be produced by the area co-directors. This draft will be reviewed by the IPng directorate and the review panel. The area co- directors will take the results of this review into account to produce a final recommendation. This recommendation is currently due to be presented at the IETF meeting in July 1994. The recommendation will be forwarded to the IESG for their consideration after an extended public review period. The IESG has stated that it will, if there is a suitable outcome, advance the selected protocol to Proposed Standard, and leave the other proposals as Experimental Standards. IPng selection criteria We are determined that politics not play a significant part in the IPng decision process. This may not be an easy separation to make for some people but we want the replacement for IP to be selected by performing a technical evaluation of the proposals in relation to the technical requirements generated during the IPng process. We may have to explicitly deal with some political issues, such as ownership of base documents, at some point in the process, but any issues of this type will be kept subservient to the technical evaluation. Summary We have established a procedure that we believe will result in the development of a common understanding of what the requirements for an IPng should be. This will produce a foundation upon which we can perform a careful analysis of the best way to meet these requirements. In addition to making the correct selection we must be sure that there is a solid understanding of how to test and deploy this technology. Now that the Internet is a utility, it must continue to function and function well even during the transition to the technology that will support our needs far into the future. The IPng process cannot be one where the future is decided by some small bunch of people, no matter how right thinking and well intentioned. This process will only work if the community as a whole takes part. All of you are urged to read and comment on the white papers, the directorate mailing list and the requirements documents. All of you are urged to participate! This is an expanded version of a column that was published in Network World on November 22nd 1993, page 14. ------------ Charge to IPng area A Direction for IPng At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide BOF", on the process and progress of the IPng activities. ("IPng" stands for "IP, the next generation". The IPDecide BOF was chaired by Brian Carpenter. Minutes are available in the IETF directories, with the file name .) The IPDecide BOF explored several facets of the IPng process, such as - "What is the basis for choosing the next generation IP (i.e., what are the technical requirements and decision criteria)." - "With the advent of CIDR and new, more stringent address assignment policies, are we comfortable that we truly understand the level of urgency?" - "Should the IETF or the marketplace make the final IPng decision". The BOF was held in a productive atmosphere, but did not achieve what could be called a clear consensus among the assembled attendees. In fact, despite its generally productive spirit, it did more to highlight the lack of a firm direction than to create it. The IPDecide BOF was followed the next evening by the open IESG plenary. During this session, the IESG and the assembled attendees discussed the IPng issues and seemed to arrive at a consensus based on the following set of bullets presented by the IETF chair: - "The IETF needs to move toward closure on IPng." That is, the IETF should take active steps toward a technical decision, rather than waiting for the "marketplace" to decide. - "The IESG has the responsibility for developing an IPng recommendation for the Internet community." That is, the IESG should provide leadership and take specific actions to help move the IETF toward a technical decision. - "The procedures of the recommendation-making process should be open and published well in advance by the IESG." - "As a part of the process, the IPng WGs may be given new milestones and other guidance to aid the IESG." - "There should be ample opportunity for community comment prior to final IESG recommendation (e.g., there will be an extended Last Call)." A Direction For IPng Building on this consensus, I'd like to announce a set of specific directions in the IESG that I hope will move us toward timely resolution of many of the key IPng issues. The IESG will establish a temporary, ad hoc, "area" to deal specifically with IPng issues. The charter for this new IESG area is to develop a recommendation on which, if any, of the current proposals should be adopted as the "next IP". This recommendation will be submitted to the IESG and to the Internet community for review. Following an adequate period of review to surface any community concerns, the IESG will issue a final IPng recommendation. All of the current IPng-related working groups will be moved immediately into this new area. This new area will be headed by two co-Area Directors from within the IESG. I have asked Allison Mankin (NRL), current Transport Services AD, and Scott Bradner (Harvard), current Operational Requirements AD, to serve as co-AD's for this temporary area. I am very pleased to report that they have agreed to take this important assignment. (Because this is expected to be a temporary assignment, Scott and Allison will also continue to serve in their current IESG positions during this period.) All IETF Areas are now expected to have Area Directorates. For the IPng Area, a Directorate will be especially important to bring additional viewpoints into the process. Therefore, I am asking that, as their first action, Scott and Allison form a specific IPng Directorate to act as a direction-setting and preliminary review body. The IPng process will continue to be completely open, and therefore reports and meeting notes from any IPng Directorate meetings will be published in timely fashion. Issues Toward IPng Resolution Two important issues need resolution immediately before we can expect progress toward an IPng recommendation: - What is the scope of the effort? That is, should IPng be limited to solving the well known scaling and address exhaustion issues; or should IPng also include advanced features such as resource reservation for real-time traffic? The argument in favor of considering advanced features is that migration to a new IP is (hopefully, only!) a once-in-a-generation occurance, and therefore all advanced features should at least be considered. Arguments opposed to considering advanced features include the fact that we may not have time for this level of effort before the scaling and address exhaustion problems confront us, and that we may not have the necessary understanding and experience to make all the correct choices at this time. - What is the available timeframe? That is, before we can even begin to make an informed decision about the scope, we need a better understanding of the urgency and time constraints facing us. Factors that affect the available time include the current rate of address assignments (which can give us an estimate of when we are currently projected to run out of addresses), the current policies governing address assignment (which can give us an understanding of how policies affect the assignment and utilization rates), the impact of CIDR aggregation, the development time for IPng, and the time needed to field and migrate to the new IPng. Therefore, I am asking the new AD's and the Directorate to start immediately the following specific activities to help guide their ultimate IPng recommendation: 1. Develop an understanding of the available timeframe, covering at least the following issues: - Review Internet growth metrics, such as the current address assignment and utilization rates. Develop an understanding of how the new address assignment policies impact the assignment and utilization rates. - Review the expected impact of CIDR address aggregation. Develop an understanding of the expected savings due to CIDR aggregation. - Develop new technical guidelines for classless Internet addressing. Specific examples include guidelines for how to utilize variable length subnet masks, and how to utilize currently unused Class A and B addresses in a classless fashion in hosts and routers. - Develop a strong understanding of the time required for the development, fielding, and migration for a new IP. - Based on all the above issues, (a) develop an estimate for how long we have to to develop and deploy an IPng. This could be a set of estimates based on best/worst case estimates for how each of the above factors will affect the available timeframe. (b) Consider whether more stringent assignment policies might provide additional time. If so, recommend such policies. (c) make a recommendation on whether it is worthwhile to mount a serious effort to reclaim addresses and/or to renumber significant portions of the Internet. 2. Based on an informed judgement of the time constraints above, make a recommendation regarding the scope for IPng, i.e., should IPng consider scaling issues only or advanced topics also. 3. Based on the scope and time constraints, develop a clear and concise set of technical requirements and decision criteria for IPng. These should include, but not be limited to, the criteria outlined in the IESG statement (RFC1380). 4. Based on the decision criteria, scope, and time constraints, make a recommendation on which of the current IPng candidates to accept, if any. Finally, I am asking Scott and Allison to make a detailed report at the opening plenary of the next IETF meeting in November on the status of setting up their new area, and on their progress toward organizing the above work items. In particular, the status of the work items on timeframe should be fully reported. This will be followed by regular progress reports to the Internet community, at IETF meetings and in other appropriate forums. Please join me in giving Scott and Allison our full cooperation, and in thanking them for accepting this daunting assignment. I feel confident that we will now make significant progress on the important IPng issues facing the Internet community. Phill Gross IETF/IESG Chair --------- RFC 1550 Network Working Group S. Bradner Request for Comments: 1550 Harvard University Category: Informational A. Mankin NRL December 1993 IP: Next Generation (IPng) White Paper Solicitation Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Document Review Process . . . . . . . . . . . . . . . . . . 2 3. Document Format Requirement . . . . . . . . . . . . . . . . 2 4. Outline for IPng Requirements and Concerns White Papers . . 3 5. Engineering considerations . . . . . . . . . . . . . . . . . 3 6. Security Considerations . . . . . . . . . . . . . . . . . . 5 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 5 Appendix A - Formatting Rules (from RFC 1543) . . . . . . . . . . 6 1. Introduction The IP: next generation (IPng) area in the IETF is soliciting white papers on topics related to the IPng requirements and selection criteria. All interested parties are invited to submit white papers detailing any specific requirements that they feel an IPng must fulfill or any factors that they feel might sway the IPng selection. An example of the former might be a submission by a representative of a utility company detailing the scaling and addressing features which would be required to service future inclusion of utility meters on the network. An example of the other case might be a paper outlining the potential effect on IPng of some sections of the future network connectivity being provided via wireless networks. At this time, we are not accepting white papers that evaluate specific IPng proposals. This type of document will be accepted after the various proposal documents are deemed to be clear and complete. Bradner & Mankin [Page 1] RFC 1550 IPng White Paper Solicitation December 1993 All white papers will be reviewed in a process described below. As a result of these reviews, each white paper will receive the focused attention of the IPng directorate and the community. The white papers will be used as resource materials by the IPng Area working groups, the directorate, the external review board and the area directors, during the selection process. The deadline for the submission of these white papers is February 1, 1994, though early submission is encouraged. Submit white papers, general or topic questions, and so on, to ipng-wp@harvard.edu. 2. Document Review Process All submitted documents will first be reviewed for clarity by members of the IPng directorate and the external review board. This review may produce suggestions to the author on areas of the document where there may be some confusion as to the meaning. Authors are urged to consider any such suggestions as constructive and to reexamine their text in light of the suggestions. A separate technical review will then be done of the white paper. This review will be conducted within the context of the document. That is, the review still will not make value judgments on the white papers, but will assess technical feasibility. This review may also produce suggestions to the author. The document will be submitted as an Internet-Draft after these reviews have been completed and after whatever (if any) revisions that the author decides to make. After a suitable period of time these documents will be submitted as informational RFCs unless withdrawn by the author. These documents will comprise a part of the historical record of the IPng process. 3. Document Format Requirements All white papers must follow the format requirements listed in RFC 1543 and must not exceed 10 pages in length. (The relevant portion of RFC 1543 is included in this document as Appendix A.) They should not include the "status of memo" section; this will be added when the documents are posted as Internet Drafts. The reference version of the document must be in ASCII as is current practice with all RFCs. A PostScript version of the document may be submitted in addition to the ASCII version. (See RFC 1543 for the formatting procedures to use with PostScript documents.) Bradner & Mankin [Page 2] RFC 1550 IPng White Paper Solicitation December 1993 4. Outline for IPng Requirements and Concerns White Papers This section details the white paper outline to be followed by someone who would like to express an opinion about the various factors involved in the IPng definition and selection process. Since these documents will be used as resource material by the various IPng working groups, the directorate, the external review board and the area directors, they should be well-focused and give specific references to data supporting their points. Each white paper should begin with an executive summary of the important points of the document. This executive summary should not exceed 1/2 page in length. The white paper should then address the issue or issues that the author feels should be understood during the IPng process. The total document should not exceed 10 pages in length. An author may submit more than one white paper if he or she feels that the level of detailed discussion on each topic warrants it. 5. Engineering considerations In past discussions the following issues have been raised as relevant to the IPng selection process. This list is in no particular order. Any or all of these issues may be addressed as well as any other topic that the author feels is germane, but do not exceed the 10 page limit, please. 5.1 Scaling - What is a reasonable estimate for the scale of the future data networking environment? The current common wisdom is that IPng should be able to deal with 10 to the 12th nodes. 5.2 Timescale - What are reasonable time estimates for the IPng selection, development and deployment process or what should the timeframe requirements be? This topic is being evaluated by the ALE working group and a copy of all white papers that express opinions about these topics will be forwarded to that group. 5.3 Transition and deployment - Transition from the current version to IPng will be a complex and difficult process. What are the issues that should be considered The TACIT working group will be discussing these issues and a copy of all white papers that express opinions about these topics will be forwarded to that group. 5.4 Security - What level and type of security will be required in the future network environment? What features should be in an IPng to facilitate security? Bradner & Mankin [Page 3] RFC 1550 IPng White Paper Solicitation December 1993 5.5 Configuration, administration and operation - As networks get larger and more complex, the day to day operational aspects become ever more important. What should an IPng include or avoid in order to minimize the effect on the network operators? 5.6 Mobile hosts - How important is the proliferation of mobile hosts to the IPng selection process? To what extent should features be included in an IPng to assist in dealing with mobile hosts? 5.7 Flows and resource reservation - As the data networks begin to get used for an increasing number of time-critical processes, what are the requirements or concerns that affect how IPng should facilitate the use of resource reservations or flows? 5.8 Policy based routing - How important is policy based routing? If it is important, what types of policies will be used? What requirements do routing policies and potential future global architectures of the Internet bring to IPng? How do policy requirements interact with scaling? 5.9 Topological flexibility - What topology is anticipated for the Internet? Will the current general topology model continue? Is it acceptable (or even necessary) to place significant topological restrictions on interconnectivity of networks? 5.10 Applicability - What environment / marketplace do you see for the application of IPng? How much wider is it than the existing IP market? 5.11 Datagram service - Existing IP service is "best effort" and based on hop-by-hop routed datagrams. What requirements for this paradigm influence the IPng selection? 5.12 Accounting - How important a consideration should the ability to do accounting be in the selection of an IPng? What, if any, features should be included in an IPng to support accounting functions? 5.13 Support of communication media - IPv4 can be supported over most known types of communications media. How important is this same flexibility to an IPng? Bradner & Mankin [Page 4] RFC 1550 IPng White Paper Solicitation December 1993 5.14 Robustness and fault tolerance - To the extent that the Internet built from IPv4 has been highly fault tolerant, what are ways that IPng may avoid inadvertent decrease in the robustness (since some things may work despite flaws that we do not understand well). Comment on any other ways in which this requirement may affect the IPng. 5.15 Technology pull - Are there technologies that will pull the Internet in a way that should influence IPng? Can specific strategies be developed to encompass these? 5.16 Action items - suggested charges to the directorate, working groups or others to support the concerns or gather more information needed for a decision. 6. Security Considerations This RFC raises no security issues, but does invite comment on the security requirements of IPng. 7. Authors' Addresses Scott Bradner Harvard University 10 Ware St. Cambridge, MA 02138 Phone: (617) 495-3864 EMail: sob@harvard.edu Allison Mankin Naval Research Laboratory c/o Code 5591 Washington D.C. 20375-5000 Phone: 202-404-7030 EMail: mankin@cmf.nrl.navy.mil Bradner & Mankin [Page 5] RFC 1550 IPng White Paper Solicitation December 1993 Appendix A - Formatting Rules (from RFC 1543) Note: there are a set of NROFF formatting macros for the following format. Please contact ipng-wp@harvard.edu if you would like to get a copy. 3a. ASCII Format Rules The character codes are ASCII. Each page must be limited to 58 lines followed by a form feed on a line by itself. Each line must be limited to 72 characters followed by carriage return and line feed. No overstriking (or underlining) is allowed. These "height" and "width" constraints include any headers, footers, page numbers, or left side indenting. Do not fill the text with extra spaces to provide a straight right margin. Do not do hyphenation of words at the right margin. Do not use footnotes. If such notes are necessary, put them at the end of a section, or at the end of the document. Use single spaced text within a paragraph, and one blank line between paragraphs. Note that the number of pages in a document and the page numbers on which various sections fall will likely change with reformatting. Thus cross references in the text by section number usually are easier to keep consistent than cross references by page number. Bradner & Mankin [Page 6] From jcurran@nic.near.net Mon Feb 28 12:16:26 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.4/8.6.4) with SMTP id MAA17191 for ; Mon, 28 Feb 1994 12:17:16 -0500 Received: from platinum.near.net by nic.near.net id aa05891; 28 Feb 94 17:17 GMT To: Craig Partridge cc: j.crowcroft@cs.ucl.ac.uk, kasten@ftp.com, ipng@cmf.nrl.navy.mil Subject: Re: Comments on the revised Criteria draft In-reply-to: Your message of Mon, 28 Feb 1994 08:50:55 -0800. <199402281650.IAA21121@aland.bbn.com> Date: Mon, 28 Feb 1994 12:16:26 -0500 From: John Curran Message-ID: <9402281717.aa05891@nic.near.net> -------- ] From: Craig Partridge ] Subject: Re: Comments on the revised Criteria draft ] Date: Mon, 28 Feb 94 08:50:55 -0800 ] ] There is some basis for arguing that "global IP-layer" service ] has not been anywhere near as important as global TCP and UDP ] service. The ultimate test for this would be consider whether ] a hypothetical Internet offering end-to-end worldwide TCP and UDP ] services over multiple network layers was more or less valuable ] than a hypothetical Internet which provided "global IPng-layer ] connectivity" but lacked globally-defined transport protocols. ] ] I think this doesn't work. It says that TCP and UDP are the globally ] sufficient solutions (which given the frequency with which new transport ] protocols appear, probably isn't true -- note transport protocols seem to ] be a more popular fiddling point than the internetwork protocol). I haven't seen a third transport protocol become deployed in the Internet, and yet we're actively considering at least one new Internet Protocol. Quite honestly, many user communities do not care about the Internet Protocol as much as they care about global connectivity. ] ] 5.6. Unreliable Datagram Service ] ] ] ] CRITERION ] ] The protocol must support an unreliable datagram delivery ] ] service. ] ] ] ] DISCUSSION ] ] We like IP's datagram service and it seems to work very ] ] well. So we must keep it. ] ] Does the unreliable datagram delivery service have to simply be ] a sufficient replacement for IPv4, or does it have to benefit ] from any and all of the other IPng capabilities such as mobility, ] resource flows, security, etc. ? (i.e. "can new IPng capabilities ] be considered satisfied if they're only available to non-datagram ] based traffic?") ] ] Well, we need to be clear about what is intended here. The idea is that ] IP's ability to launch an idempotent datagram, without pre-arrangement, ] is extremely valuable (arguably what makes IP so popular) and should ] be retained. I agree it should be retained... Do all new IPng capabilities need to be supplied to the idempotent datagram service user? For example, flows (as a capability) may be part of IPng, but not supported by the Unreliable Datagram Service. Is this okay? If there is another IPng requirement (such as security) does this apply equally to all aspects of IPng (i.e. both flows and datagrams, for example) ] ] 5.9. Unique Naming ] ] ] ] CRITERION ] ] IP:ng must assign all IP-Layer objects in the global, ] ] ubiquitous, Internet unique names. ] ] ] ] DISCUSSION ] ] We use the term "Name" in this criterion synonymously ] ] with the term "End Point Identifier" as used in the ] ] NIMROD proposal, or as IP Addresses uniquely identify ] ] interfaces/hosts in IPv4. ] ] ] ] The authors are not convinced that this ought to be a ] ] criterion of the protocol. We feel that it may in fact be ] ] a part of a solution to other criteria and as such, is ] ] not a criterion of its own. The BOF expressed a very ] ] strong desire to include this criterion and we are ] ] placing it here in the hope that it will stimulate ] ] discussion on the subject. ] ] Perhaps a rephrasing would make this item more desirable? ] ] IPng must provide addresses which are suitable for use ] as globally-unique ubiquitous names, or must provide an ] additional identifier space which is suitable for this ] purpose. ] ] Does this preserve the intent of the BOF? ] ] My recollection (very vague) of the BOF is that two points were raised. ] First a globally unique name in each packet was required for security (for ] reasons not explained). Second, that folks wanted, given a j-random ] datagram, to be able to examine that datagram and figure out exactly who ] sent it, without having to do stuff like unwind flow IDs backwards on the ] path. So I'd say the rephrasing isn't quite consistent with the BOF in ] that it isn't clearly that the unique ID must be in every datagram. Got it... perhaps you and/or Frank can augment the criterion text? /John From craig@aland.bbn.com Mon Feb 28 09:25:49 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA17398 for ; Mon, 28 Feb 1994 12:36:45 -0500 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA01792 for jcurran@nic.near.net; Mon, 28 Feb 94 12:26:52 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA21266; Mon, 28 Feb 1994 09:25:51 -0800 Message-Id: <199402281725.JAA21266@aland.bbn.com> To: John Curran Cc: Craig Partridge , j.crowcroft@cs.ucl.ac.uk, kasten@ftp.com, ipng@cmf.nrl.navy.mil Subject: Re: Comments on the revised Criteria draft In-Reply-To: Your message of Mon, 28 Feb 94 12:16:26 -0500. <9402281717.aa05891@nic.near.net> From: Craig Partridge Date: Mon, 28 Feb 94 09:25:49 -0800 Sender: craig@aland.bbn.com [John, et al. my apologies for quick and sometimes partial responses -- I've got two deadlines tommorrow, and I'm replying while software is compiling and/or papers printing... Craig] I haven't seen a third transport protocol become deployed in the Internet, and yet we're actively considering at least one new Internet Protocol. Quite honestly, many user communities do not care about the Internet Protocol as much as they care about global connectivity. I suspect you have. How's about these: ST, PVP, EGP, IGMP, and IGRP? (All have IP protocol numbers). ] Well, we need to be clear about what is intended here. The idea is that ] IP's ability to launch an idempotent datagram, without pre-arrangement, ] is extremely valuable (arguably what makes IP so popular) and should ] be retained. I agree it should be retained... Do all new IPng capabilities need to be supplied to the idempotent datagram service user? For example, flows (as a capability) may be part of IPng, but not supported by the Unreliable Datagram Service. Is this okay? If there is another IPng requirement (such as security) does this apply equally to all aspects of IPng (i.e. both flows and datagrams, for example) My personal sense is no, one doesn't need all the bells and whistles. In fact, that might be a bad idea. For instance, we put a lot of IP stuff in Boot ROM these days, and while Boot ROM is no longer small (in memory) we'd like to keep the complexity down. (No need to establish a flow, or deal with someone trying to establish a flow, just as you're trying to boot). Craig From jcurran@nic.near.net Mon Feb 28 12:47:33 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.4/8.6.4) with SMTP id MAA17660 for ; Mon, 28 Feb 1994 12:48:30 -0500 Received: from platinum.near.net by nic.near.net id aa08679; 28 Feb 94 17:48 GMT To: Craig Partridge cc: j.crowcroft@cs.ucl.ac.uk, kasten@ftp.com, ipng@cmf.nrl.navy.mil Subject: Re: Comments on the revised Criteria draft In-reply-to: Your message of Mon, 28 Feb 1994 09:25:49 -0800. <199402281725.JAA21266@aland.bbn.com> Date: Mon, 28 Feb 1994 12:47:33 -0500 From: John Curran Message-ID: <9402281748.aa08679@nic.near.net> -------- ] From: Craig Partridge ] Subject: Re: Comments on the revised Criteria draft ] Date: Mon, 28 Feb 94 09:25:49 -0800 ] ] [John, et al. my apologies for quick and sometimes partial responses -- I've ] got two deadlines tommorrow, and I'm replying while software is compiling ] and/or papers printing... Craig] No problem... :-) ] I haven't seen a third transport protocol become deployed in the Internet, ] and yet we're actively considering at least one new Internet Protocol. ] ] Quite honestly, many user communities do not care about the Internet ] Protocol as much as they care about global connectivity. ] ] I suspect you have. How's about these: ST, PVP, EGP, IGMP, and IGRP? ] (All have IP protocol numbers). ST If I do a survey of my customer base, I find this < 0.1 % of my sites PVP Sorry, PVP = ? EGP, IGMP, IGRP Internal to the network... customers generally do not care as long as we get it right. All I am saying is that there is no particular reason to presume that the general Internet _marketplace_ values IP end-to-end connectivity over TCP&UDP end-to-end connectivity. ] ... ] I agree it should be retained... Do all new IPng capabilities need to ] be supplied to the idempotent datagram service user? For example, flows ] (as a capability) may be part of IPng, but not supported by the Unreliable ] Datagram Service. Is this okay? If there is another IPng requirement ] (such as security) does this apply equally to all aspects of IPng (i.e. ] both flows and datagrams, for example) ] ] My personal sense is no, one doesn't need all the bells and whistles. In ] fact, that might be a bad idea. For instance, we put a lot of IP stuff in ] Boot ROM these days, and while Boot ROM is no longer small (in memory) we'd ] like to keep the complexity down. (No need to establish a flow, or deal ] with someone trying to establish a flow, just as you're trying to boot). Then it may be important to distinguish (in the criteria list) the circumstances under which the criteria apply. For example, can we say one way or the other that multicast or security requirements can be constrained to apply only to datagrams or flows? (Or indeed, must all the requirements to be supported over all forms of IPng communication?) /John From craig@aland.bbn.com Mon Feb 28 09:54:05 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA17699 for ; Mon, 28 Feb 1994 12:55:40 -0500 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA04562 for ipng@cmf.nrl.navy.mil; Mon, 28 Feb 94 12:55:10 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA21317; Mon, 28 Feb 1994 09:54:06 -0800 Message-Id: <199402281754.JAA21317@aland.bbn.com> To: John Curran Cc: Craig Partridge , j.crowcroft@cs.ucl.ac.uk, kasten@ftp.com, ipng@cmf.nrl.navy.mil Subject: Re: Comments on the revised Criteria draft In-Reply-To: Your message of Mon, 28 Feb 94 12:47:33 -0500. <9402281748.aa08679@nic.near.net> From: Craig Partridge Date: Mon, 28 Feb 94 09:54:05 -0800 Sender: craig@aland.bbn.com ] My personal sense is no, one doesn't need all the bells and whistles. In ] fact, that might be a bad idea. For instance, we put a lot of IP stuff i n ] Boot ROM these days, and while Boot ROM is no longer small (in memory) we 'd ] like to keep the complexity down. (No need to establish a flow, or deal ] with someone trying to establish a flow, just as you're trying to boot). Then it may be important to distinguish (in the criteria list) the circumstances under which the criteria apply. For example, can we say one way or the other that multicast or security requirements can be constrained to apply only to datagrams or flows? (Or indeed, must all the requirements to be supported over all forms of IPng communication?) Yep. I think security and multicast apply to all modes. Happy to talk about other requirements in terms of modality of service (assuming IPng has clearly distinguished modes). Craig From brian@dxcoms.cern.ch Mon Feb 28 18:59:43 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA17767 for ; Mon, 28 Feb 1994 13:00:30 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27748; Mon, 28 Feb 1994 18:59:45 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03588; Mon, 28 Feb 1994 18:59:44 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402281759.AA03588@dxcoms.cern.ch> Subject: Re: IPng Requirements To: kasten@ftp.com Date: Mon, 28 Feb 1994 18:59:43 +0100 (MET) Cc: Brian.Carpenter@cern.ch, ipng@picard.cmf.nrl.navy.mil, jon@cs.ucl.ac.uk, craig@aland.bbn.com In-Reply-To: <9402281537.AA12064@tri-flow.ftp.com.ftp.com> from "Frank Kastenholz" at Feb 28, 94 10:37:35 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1080 >--------- Text sent by Frank Kastenholz follows: ... > When we were working on the original paper, I thought alot about network > management, statistics, accounting and the like. I came to the conclusion > that these were not really attributes of the protocol itself. Whatever > IPng is, the SNMP people will have to make the necesary MIBs for it, and > so on. Sort of like saying that you must redefine the TCP pseudo-header > to work with ipng (and FTP's use of IP addresses and DNS and so on and > so forth). I thought that these were not really necessary to state. > I give some reasons why they may influence the protocol in my WP. > As to firewalls, I see this as a solution, rather than a problem. > The problem is that one needs security (which we state). Firewalls > are one way to get it. I strongly resist the notion of including, per > se, firewalls in the document. True, firewall is too specific. The general requirement is to enable sites to bar any traffic they deem undesirable. > > I hadn't considered policy at all. > I guess you should... Brian From J.Crowcroft@cs.ucl.ac.uk Mon Feb 28 18:08:35 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA17823 for ; Mon, 28 Feb 1994 13:09:21 -0500 Message-Id: <199402281809.NAA17823@picard.cmf.nrl.navy.mil> Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 28 Feb 1994 18:08:36 +0000 To: John Curran cc: Craig Partridge , kasten@ftp.com, ipng@cmf.nrl.navy.mil Subject: Re: Comments on the revised Criteria draft In-reply-to: Your message of "Mon, 28 Feb 94 12:16:26 EST." <9402281717.aa05891@nic.near.net> Date: Mon, 28 Feb 94 18:08:35 +0000 From: Jon Crowcroft >I haven't seen a third transport protocol become deployed in the Internet, >and yet we're actively considering at least one new Internet Protocol. RTP (accountsfor ~10% of the backbone) HTTP (accounts for similar) would both run straight on IP rather than tcp/or udp if their implementeors were unix kernel hackers... j. From deering@parc.xerox.com Mon Feb 28 10:56:44 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.4/8.6.4) with SMTP id NAA18355 for ; Mon, 28 Feb 1994 13:57:56 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14552(6)>; Mon, 28 Feb 1994 10:56:50 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 28 Feb 1994 10:56:58 -0800 To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: Comments on the revised Criteria draft In-reply-to: kasten's message of Mon, 28 Feb 94 07:37:33 -0800. <9402281537.AA12061@tri-flow.ftp.com.ftp.com> Date: Mon, 28 Feb 1994 10:56:44 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Feb28.105658pst.12171@skylark.parc.xerox.com> > At a recent IETF (Columbus?), there was a presentation at of all the > then IPng candidates on their protocols at one of the plenary > meetings. I asked them all something to the effect of "What's a > risk/problem/down-side/failure-mode/bad-thing about your protocol?" > All answers parsed down to "None". Your question was kinda like asking a programmer "What bugs exist in your program?", for which the only acceptable answer is "None that I know of." I think that's what the answers really parsed down to. Steve From Robert_Ullmann.LOTUS@CRD.lotus.com Mon Feb 28 16:01:27 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.4/8.6.4) with SMTP id PAA00665 for ; Mon, 28 Feb 1994 15:56:24 -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 AA07131; Mon, 28 Feb 94 15:57:53 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA14666; Mon, 28 Feb 94 16:01:27 EST Date: Mon, 28 Feb 94 16:01:27 EST Message-Id: <9402282101.AA14666@Mail.Lotus.com> Received: by DniMail (v1.0); Mon Feb 28 16:01:25 1994 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: NAT boxes Hi, Since this came up during the chat (John Curran, I believe) I have an observation to make. First, note that there are a *LOT* of interactions that have been carefully though out by the various proposals, and not always documented, mostly because it would take a large book. Here is an example: For those who think the world will choose NAT as the answer, how do you propose to build a NAT box that will work when one of the various network layer security protocols (NLSPs) is being used? Arranging to have the NAT box hold all of the session keys is just a tad unacceptable I would think. Given a choice between security and NAT, what would your typical organization choose? It is certainly possible to design an NSLP that makes NAT doable, but the result would be very different from the current work. (You would probably have to design the KMP around canonical host names or something, and arrange for the SAIDs to re-identify the other party without reference to the addresses in the datagram.) ---- Note that when CATNIP, which carefully specifies that there be no address translation, and later says that the IPSEC and ISO NLSP can be used directly, neither statement is made idly. Best Regards, Robert From jcurran@nic.near.net Mon Feb 28 16:58:27 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.4/8.6.4) with SMTP id QAA01337 for ; Mon, 28 Feb 1994 16:59:40 -0500 Received: from platinum.near.net by nic.near.net id aa01937; 28 Feb 94 21:59 GMT To: Robert_Ullmann.LOTUS@crd.lotus.com cc: ipng@cmf.nrl.navy.mil Subject: Re: NAT boxes In-reply-to: Your message of Mon, 28 Feb 1994 16:01:27 -0500. <9402282101.AA14666@Mail.Lotus.com> Date: Mon, 28 Feb 1994 16:58:27 -0500 From: John Curran Message-ID: <9402282159.aa01937@nic.near.net> -------- ] From: Robert_Ullmann.LOTUS@crd.lotus.com ] Subject: NAT boxes ] Date: Mon, 28 Feb 94 16:01:27 EST ] ] Given a choice between security and NAT, what would your ] typical organization choose? "Given a choice between: IPng, NSLP, security, and Internet access -or- IPv4, NAT, no security, and Internet access what would your typical organization choose?" If we are to judge by the practices of current Internet sites, the market choice is abundantly clear. /John p.s. No, Rob, I do not like this situation either. From bound@zk3.dec.com Mon Feb 28 22:11:54 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA02847 for ; Mon, 28 Feb 1994 22:16:07 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA10433; Mon, 28 Feb 94 19:12:02 -0800 Received: by xirtlu.zk3.dec.com; id AA01776; Mon, 28 Feb 1994 22:12:00 -0500 Message-Id: <9403010312.AA01776@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: ipng@picard.cmf.nrl.navy.mil In-Reply-To: Your message of "Mon, 28 Feb 94 11:58:36 EST." <9402281658.AA22381@radegond.cmf.nrl.navy.mil> Date: Mon, 28 Feb 94 22:11:54 -0500 X-Mts: smtp Allison, That was very useful and clear. thanks /jim From brian@dxcoms.cern.ch Wed Mar 2 10:22:49 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id IAA00374 for ; Wed, 2 Mar 1994 08:41:20 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14465; Wed, 2 Mar 1994 10:22:50 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05007; Wed, 2 Mar 1994 10:22:49 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403020922.AA05007@dxcoms.cern.ch> Subject: Conflict resolution resolved? To: ipng@cmf.nrl.navy.mil Date: Wed, 2 Mar 1994 10:22:49 +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: 1140 Hi Directorate, I found it very hard to get into the conflict resolution discussion on Monday, partly because of satellite delay on my line (Gee, thanks, ATT) and partly because I don't really understand the way the discussion went. It's clear that criteria.txt, hopefully to be transformed into requirements.txt, won't help. Either all proposals will satisfy all requirements, or they will promise modifications to do so. (There is the risk of mutually incompatible requirements creeping in, but I guess the Directorate and the requirements WG have to resolve those conflicts.) It's also clear to me that eliminating a proposal because it is not 100% ready before some arbitrary deadline is unfair process, since the timescales are long and we don't even know them yet (pending output from ALE and TACIT). It's also clear that when it comes to the final judgement call (let's not kid ourselves it is anything else), humming in the IETF plenary is also unfair process. A formal vote in the IESG on advice from this Directorate and from the plenary IETF could be viewed as fair process, but they'd better retain a good lawyer. Brian From brian@dxcoms.cern.ch Wed Mar 2 10:25:24 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id IAA00387 for ; Wed, 2 Mar 1994 08:41:55 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14715; Wed, 2 Mar 1994 10:25:25 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05097; Wed, 2 Mar 1994 10:25:24 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403020925.AA05097@dxcoms.cern.ch> Subject: International IPng acceptance To: ipng@cmf.nrl.navy.mil Date: Wed, 2 Mar 1994 10:25:24 +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: 1097 Hi again, Directorate, I thought a bit more about the question of international acceptance of any IPng choice. As you can see from one or two white papers, a number of people will say "any choice is good as long as it is CLNP." We just have to ignore this - it is a religious statement, or at best a special-interest statement. The other way to look at it is to position IPng as CLNPng. However, that is only conceivable if IPng supports NSAP addresses. Whatever else you might want to change in CLNPng, it has to support CLNP addresses! Therefore, making it a requirement that IPng could be CLNPng directly requires that IPng supports NSAPs. (It does not require that IPng supports only NSAPs.) This would be a big decision. Personally I am against it. That does not mean I am voting for SIPP, just that I think it would be an undue distortion of the engineering requirements process. My conclusion is that we should not tie international acceptance of IPng to CLNP. It should stand or fall on its own merits. Again, that does not imply I will not prefer TUBA or CATNIP in the end. Brian From jcurran@nic.near.net Wed Mar 2 09:04:25 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.4/8.6.4) with SMTP id JAA00625 for ; Wed, 2 Mar 1994 09:05:16 -0500 Received: from platinum.near.net by nic.near.net id aa07078; 2 Mar 94 14:05 GMT To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: International IPng acceptance In-reply-to: Your message of Wed, 02 Mar 1994 10:25:24 +0100. <9403020925.AA05097@dxcoms.cern.ch> Date: Wed, 02 Mar 1994 09:04:25 -0500 From: John Curran Message-ID: <9403021405.aa07078@nic.near.net> -------- ] From: Brian Carpenter CERN-CN ] Subject: International IPng acceptance ] Date: Wed, 2 Mar 1994 10:25:24 +0100 (MET) ] Hi again, Directorate, ] ] I thought a bit more about the question of international ] acceptance of any IPng choice. As you can see from one or two white ] papers, a number of people will say "any choice is good as long as it ] is CLNP." We just have to ignore this - it is a religious statement, ] or at best a special-interest statement. The other way to look at it ] is to position IPng as CLNPng. However, that is only conceivable if ] IPng supports NSAP addresses. Whatever else you might want to change ] in CLNPng, it has to support CLNP addresses! Therefore, making it a ] requirement that IPng could be CLNPng directly requires that IPng ] supports NSAPs. (It does not require that IPng supports only NSAPs.) ] ] This would be a big decision. Personally I am against it. That does ] not mean I am voting for SIPP, just that I think it would be an undue ] distortion of the engineering requirements process. ] ] My conclusion is that we should not tie international acceptance of ] IPng to CLNP. It should stand or fall on its own merits. Your analysis is sound, but the need to have a more formal international standardization of IPng is also quite real. The only conclusion I can draw is that IPng may not make a very good CLNPng (due to lack of NSAP addressing), but that does not mean that IPng can not be submitted as "yet another" OSI connectionless network protocol. While the IETF has strong feels about having only one mechanism for a given function, the ISO folks have shown a willingness to have many competing standards. /John From sob@hsdndev.harvard.edu Wed Mar 2 11:49:13 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA01777 for ; Wed, 2 Mar 1994 11:49:38 -0500 Date: Wed, 2 Mar 94 11:49:13 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403021649.AA18851@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch Subject: Re: International IPng acceptance Cc: ipng@cmf.nrl.navy.mil Brian, To also not pre-judge. There are a number of other white papers from the U.S. that state directly of indirectly that support of NSAPs would be a good thing and this is a feeling that I've heard from many prople in utilities and the like. It might be an interesting topic for discussion to try and figure out the whys & why-nots of having support for NSAP as an IPng requirement. (Note that Steve said once (darkly, as I remember) that there might be a way to support NSAPs in SIPP so this is also not to be viewed as any sort of pre-selection) now lets see: +s political ( CLNPng == IPng ) scale some experience & plans in Internet -s legacy system political (licking their boots...) size other thoughts? Scott From bound@zk3.dec.com Wed Mar 2 22:18:21 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA05105 for ; Wed, 2 Mar 1994 22:22:02 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA00115; Wed, 2 Mar 94 19:18:33 -0800 Received: by xirtlu.zk3.dec.com; id AA26927; Wed, 2 Mar 1994 22:18:27 -0500 Message-Id: <9403030318.AA26927@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: International IPng acceptance In-Reply-To: Your message of "Wed, 02 Mar 94 11:49:13 EST." <9403021649.AA18851@hsdndev.harvard.edu> Date: Wed, 02 Mar 94 22:18:21 -0500 X-Mts: smtp Scott, I dont see anyone but the EPRI paper asking for NSAPs? Who else in the white papers asked for NSAPs as a formal requirement? I read them all? If I missed them indirectly I would like to know and re-read the white papers. Based on what I heard at the directorate meeting we maybe should not have even seen the EPRI paper because it basically did not give us requirements (to the extent cablelabs or hpn did) and gave us a solution ala CLNP. And spent a lot of time on stuff that had nothing to do with selecting a network layer and tried to work a transport layer agenda into their paper. Plus if we want to be legal the ERPI folks have not responded to my review input at all. But I really don't care as they do not really represent Detroit Edison or Public Safety of NH or CEI in Ohio, I found out through some contacts. But all input is good. As far as NSAPs go I guess I don't care, unless it does anything to hinder a proposal. Like one of our architects put it where I am its just a template. IMHO Regarding SIPP as one who understands it in depth and is implementing it SIPP dont need NSAPs. Now if your saying that SIPP should adopt NSAPs for political reasons thats cool. But NSAPs will do nothing to make SIPP technically better. END IMHO /jim From sob@hsdndev.harvard.edu Wed Mar 2 22:38:28 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA05140 for ; Wed, 2 Mar 1994 22:38:48 -0500 Date: Wed, 2 Mar 94 22:38:28 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403030338.AA14998@hsdndev.harvard.edu> To: bound@zk3.dec.com Subject: Re: International IPng acceptance Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil now Jim, what I'm trying to do is to get the directorate discussing an issue that seems to come up every month or so, I'm not trying to push one opinion or the other (not (yet) my job man) Re: responding to suggestions We don't actually require that someone actually make any changes based on the suggestions or to respond in any way at all, we are just giving them the chance. If they want to take the chance, great, if not, thats the way it goes - we publish it as-is unless. Scott From dino@cisco.com Wed Mar 2 19:43:58 1994 Return-Path: dino@cisco.com Received: from regal.cisco.com (regal.cisco.com [131.108.11.57]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA05174 for ; Wed, 2 Mar 1994 22:48:21 -0500 Received: by regal.cisco.com id AA10650 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Wed, 2 Mar 1994 19:43:58 -0800 Date: Wed, 2 Mar 1994 19:43:58 -0800 From: Dino Farinacci Message-Id: <199403030343.AA10650@regal.cisco.com> To: bound@zk3.dec.com Cc: sob@hsdndev.harvard.edu, Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Wed, 02 Mar 94 22:18:21 -0500 <9403030318.AA26927@xirtlu.zk3.dec.com> Subject: International IPng acceptance >> IMHO >> Regarding SIPP as one who understands it in depth and is implementing it >> SIPP dont need NSAPs. Now if your saying that SIPP should adopt NSAPs >> for political reasons thats cool. But NSAPs will do nothing to make >> SIPP technically better. >> END IMHO I agree, but adding NSAPs to SIPP makes it internationally politically better. Dino From bound@zk3.dec.com Wed Mar 2 23:13:40 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA05257 for ; Wed, 2 Mar 1994 23:16:34 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA01674; Wed, 2 Mar 94 20:13:49 -0800 Received: by xirtlu.zk3.dec.com; id AA27888; Wed, 2 Mar 1994 23:13:46 -0500 Message-Id: <9403030413.AA27888@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: bound@zk3.dec.com, Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: International IPng acceptance In-Reply-To: Your message of "Wed, 02 Mar 94 22:38:28 EST." <9403030338.AA14998@hsdndev.harvard.edu> Date: Wed, 02 Mar 94 23:13:40 -0500 X-Mts: smtp OK ... my input is its just a template. /jim From bound@zk3.dec.com Wed Mar 2 23:58:34 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA05384 for ; Thu, 3 Mar 1994 00:02:03 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA02918; Wed, 2 Mar 94 20:58:41 -0800 Received: by xirtlu.zk3.dec.com; id AA28306; Wed, 2 Mar 1994 23:58:40 -0500 Message-Id: <9403030458.AA28306@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: bound@zk3.dec.com, craig@zk3.dec.com, kasten@ftp.com, j.crowcroft@cs.ucl.ac.uk Subject: Abstraction Cablelabs - Requirements Date: Wed, 02 Mar 94 23:58:34 -0500 X-Mts: smtp Many of the notions of the white paper identified capability required at a higher level than IP. For instance: ++++++[start excerpt] 3.3 Transition and deployment - The transition from the current version to IPng has to consider two aspects: support for existing applications and availability of new capabilities. The delivery of digital video and audio programs requires the capability to do broadcasting and selective multicasting efficiently. The interactive applications that the future cable networks will provide will be based on multimedia information streams that will have real-time constraints. That is to say, both the end-to-end delays and the jitter associated with the delivery across the network have to be bound. In addition, the commercial nature of these large private investments will require enhanced network capabilities for routing choices, resource allocation, quality of service controls, security, privacy, etc. Network management will be an increasingly important issue in the future. The extent to which the current IP fails to provide the needed capabilities will provide additional incentive for the transition to occur, since there will be no choice but to use IPng in future applications. - ------[end excerpt] So from an IPng perspective we need to make sure that the network layer does not prevent the upper layers from supporting this excerpt. Here are a few of the topics that this industry requires to be coverred: real-time Selective Multicasting, routing choices, resource allocation, quality of service controls, security, privacy, Configuration, administration and operation Mobile hosts Flows and resource reservation Policy based routing Topological flexibility Robustness and fault tolerance /jim From brian@dxcoms.cern.ch Thu Mar 3 08:50:52 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA05819 for ; Thu, 3 Mar 1994 02:51:26 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14338; Thu, 3 Mar 1994 08:50:53 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13136; Thu, 3 Mar 1994 08:50:52 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403030750.AA13136@dxcoms.cern.ch> Subject: Re: International IPng acceptance To: ipng@cmf.nrl.navy.mil Date: Thu, 3 Mar 1994 08:50:52 +0100 (MET) In-Reply-To: <9403021649.AA18851@hsdndev.harvard.edu> from "Scott Bradner" at Mar 2, 94 11:49:13 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 274 > > now lets see: > > +s > political ( CLNPng == IPng ) > scale multiple formats existing delegated allocation scheme > some experience & plans in Internet > > -s > legacy system > political (licking their boots...) > size complexity variable length Brian From francis@cactus.ntt.jp Thu Mar 3 17:40:21 1994 Return-Path: francis@cactus.ntt.jp Received: from mail.ntt.jp ([192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with ESMTP id DAA05913 for ; Thu, 3 Mar 1994 03:37:44 -0500 Received: by mail.ntt.jp (8.6.5/COREMAIL.1); Thu, 3 Mar 1994 17:37:20 +0900 Received: by slab.ntt.jp (8.5/core-slab.s5+) id RAA16795; Thu, 3 Mar 1994 17:37:30 +0900 Received: by cactus.ntt.jp (4.1/NTTcs01b) with TCP; Thu, 3 Mar 94 17:40:21 JST Date: Thu, 3 Mar 94 17:40:21 JST From: francis@cactus.ntt.jp (Paul Francis) Message-Id: <9403030840.AA29313@cactus.ntt.jp> To: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: International IPng acceptance > > > > > now lets see: > > > > +s > > political ( CLNPng == IPng ) > > scale > multiple formats > existing delegated allocation scheme I'd put multiple formats and existing delegated allocation scheme on the negative side. The multiple formats don't do anything for hosts and routers, they just give a bunch of administrators something to fight over. As for the existing delegated allocation scheme, it wouldn't be necessary if there weren't multiple formats :-) As for scale, SIPP also scales, so I don't see it as a plus or minus. The political factor may be important.... :-( but will probably never be more than something on paper to please whoever is pleased by such political manuevering. PF